Release Notes - September '20

We are happy to present the FinDock September '20 Release!

Important Dates:

• 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 Enhanced Recurring Donations Upgrade Guide.

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.

ProcessingHub changes

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 called 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 Transaction records in FinDock with Entry Type = ‘Entry’
• From categories (Type 6, 7, 8) we create Transaction records 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.

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:

1. Go to Custom Settings.
2. Press Reference Settings.
3. Press Manage.
4. Press the top New button to create an organization level value.
5. Enter your organizations prefix into the ESR Reference Prefix field
6. 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.

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 FinDock 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

This InstallmentId set on WorldPay order code is unique and controlled from FinDock, making it more convenient for matching than the WorldPay {payment reference}.

The WorldPay 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.

Repeat notifications

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.