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 Core changes
NPSP Enhanced Recurring Donation support
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.
NPSP Opportunity status not updated when related Payable Installment marked Paid by Guided Matching
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.
Payment reference Generated on Recurring Level missing on one-time Installment
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.
File extraction leads to UNABLE_TO_LOCK_ROW errors
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.
Mandate deletion processing error
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.
Mandates in ProcessingHub not deleted when corresponding mandates deleted in Salesforce
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.
Gift Aid changes
Faulty Gift Aid claim batches on ProcessingHub
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.
Axerve extension changes
New Custom URL option
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.
SEPA extension changes
Bollettino Postale: process 16-character references from Poste.it
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.
Validation for Italian specific CBI pain.002 files
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.
CODA: Handle transaction coding hierarchy
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!
Stripe extension changes
API keys longer than 80 characters could not be saved
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.
Swiss Payments extension changes
Add organization prefix to ESR LSV references
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!
Tikkie extension changes
Reconciling real-time notifications on small Tikkies
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.
Worldpay extension changes
Transaction Id missing in Recurring Payments
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.
Order code used Transaction id for matching of one-time and recurring
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.