We are happy to present the FinDock September '20 Release!
Our release communication aims to inform you early of upcoming releases. Please keep in mind that the scope of a release is subject to change prior to the release date. Release notes are updated accordingly until the release date.
- Release to Sandboxes: August 23, 2020
- Release to Production: September 06, 2020
FinDock now supports the new Enhanced Recurring Donations feature of NPSP.
To make FinDock compatible with Enhanced Recurring Donations, several new fields were added to the mappings between FinDock & NPSP.
For more information on Enhanced Recurring Donations, please visit the Salesforce Power of Us website.
FinDock now is compatible with both the Classic Recurring Donation and the Enhanced Recurring Donation. There’re no special settings needs for FinDock, based on the configuration FinDock understands the version that is applicable.
Issue: In some cases when a debit transaction was processed by Guided Matching, the payable Installment was changed to paid, but the NPSP Opportunity was not updated and remained in pledged state.
Solution: Unlike in Manual Review, Guided Matching did not create an NPSP Payment when processing debit transactions. This led to a status mismatch between the Installment and Opportunity. We have now implemented the same processing logic in Guided Matching that is used in Manual Review to ensure Opportunity Stage is changed to Posted (or the status that has been mapped) when the status is changed to Paid.
Further, we found that the status Paid was not listed as an option in the mapping between Installment Status to Opportunity Stage. We have added Paid now as a new mapping option in Status Mapping.
Issue: If the Generate on Recurring Level option was enabled for the payment method reference, single Installments with that method did not have the Payment Reference.
Solution: We fixed the code to ensure the Payment Reference will be generated for single Installments.
Issue: In some cases, when a bank file is uploaded to Chatter for FinDock to process, the file extraction in ProcessingHub is blocked by UNABLE_TO_LOCK_ROW errors, causing the extraction to fail.
Solution: There are multiple reasons this error can occur. However, in each case, the error is temporary. To resolve this issue, we have implemented new processing logic that re-initiates file extraction after a few minutes when a row locking error occurs.
Issue: Deleting mandates could fail in ProcessingHub if the mandate schedule close steps start before all deletions are completed.
Solution: We modified the order and timing of processing steps to ensure the mandate deletions are processed first before moving on to generation and closing steps.
Issue: When a mandate is manually deleted in Salesforce, the corresponding mandate record in ProcessingHub was not deleted. This could result in conflicts when, for example, parsing an Inbound Record lead to an attempt to modify or delete a mandate that was already removed in Salesforce.
Solution: The issues was caused by an error in the data sync between Salesforce and ProcessingHub. We have updated the syncing procedure to include the delete action on Mandate in Salesforce.
Issue: A bug was found in ProcessingHub data processing of Gift Aid claims. This bug appeared when generating Gift Aid claim files for batches with more than 500 records. It affected claim batches from January '20 onward and resulted in incorrect claims.
Solution: The root cause was in a query on the ProcessingHub which we have fixed in this release. All impacted customers were identified and contacted directly. We have generated updated claims files and are working with customers on the adjustments. We sincerely thank everyone involved for their cooperation.
Issue: Axerve provides support for redirecting customers to a custom checkout page of your own design instead of using Axerve’s default checkout page.
Solution: We have added a new setting to the Axerve for FinDock extension
Custom Checkout URL. If you have your own checkout page, you can
enter the URL here to redirect your customers to your page.
Issue: To reconcile Bollettino Postale files, FinDock uses the 18-character Quarto Campo payment reference. In certain files, Poste.it, sends the reference without the last 2 check- digits, resulting in a 16-character reference which FinDock does not accept.
Solution: To be able to match files with 16-character references to the 18-character references stored in Salesforce, we made a new Guided Matching rule that adds the 2 check-digits to the 16 character reference before the matching process starts. This ensures that the 16+2 digit payment reference from the file and the 18 digit payment reference stored in Salesforce are the same format and can be matched.
In Italy banks may use an alternative pain.002 standard for status reports called CBI pain.002. To further support our Italian customers, we have added the XSD validation required by CBI to our bank file processing. This validation is in addition to our already existing SEPA pain.002 validation.
When a CBI pain.002 file is uploaded to Chatter, FinDock runs the specific validation and rejects the file (with a validation error message) if it does not conform to the CBI standards.
FinDock now handles transaction types, families, transaction & categories as per CODA standard 2.6, section “3. CODING OF THE TRANSACTIONS”.
Practically, this means that:
- From transaction families (Type 2, 3) we create
Transactionrecords in FinDock with
Entry Type= ‘Entry’
- From categories (Type 6, 7, 8) we create
Transactionrecords in FinDock with Entry Type = ‘Entry Detail’. (Type 9, detail of 7 is not supported)
This way you can choose whether you want to handle these transactions on the family = totalisation level, or on the detail level.
Taking into account the differences in CODA files across banks, this functionality has for now only been enabled for one specific file and bank. If you run into similar file structures, please do not hesitate to contact us!
Issue : Generated Stripe API keys can be up to 255 characters. However, FinDock would only allow for 80 characters. This would prevent you from configuring the Stripe for FinDock Payment Extension.
Solution : FinDock now allows for up to 255 characters in the Stripe API key field. This is the maximum possible number of characters.
Some Swiss banks require a customer / organisation prefix in front of ESR LSV references.
To add a prefix to your ESR LSV references:
- Go to Custom Settings.
- Press Reference Settings.
- Press Manage.
- Press the top New button to create an organization level value.
- Enter your organizations prefix into the
ESR Reference Prefixfield
- Press Save.
The provided prefix will now be prepended to all ESR LSV references upon creating Installments and when using the Payment Request Generator with the 'standard' ESR generation.
FinDock only supports one prefix at this point!
When a Tikkie is paid, FinDock receives a notification from Tikkie. For Tikkie amounts below 1 Euro the extraction of the amount was not done correctly and failed. To decrease the probability of this occuring we lowered the limit to 10 cents.
Issue: A transaction Id is included in the return message from Worldpay for recurring payments, but this Id was not added to the payment record in Salesforce.
Solution: The transaction Id is now added to the payment record when the installment is collected.
To improve consistency and aid in reconciliation of Worldpay transactions,
FinDock will now always use the
InstallmentId as Worldpay
order code and
Payment Transaction Id on:
- One-time payments (Installments records) created through the API
- First payments (Installments records) used to authorize Recurring Credit Card payments
- Installments created with Payment Schedules to collect Recurring payments
InstallmentId set on WorldPay
order code is unique and be controlled from FinDock, making it more convenient for matching than the
payment reference, that was only available to FinDock for one-time payments (including first payments) through the API flow, is no longer used or stored by FinDock.
Issue: Notifications from Worldplay to FinDock were arriving multiple times due to a missing confirmation message from FinDock.
Solution: We have implemented the expected confirmation response so notifications only arrive once.