Release Notes - November '19
We are happy to present you the FinDock November '19 Release Notes. There are no manual actions required to continue using existing functionality. For new features, like improved Gift Aid and Guided Matching, manual actions are required.
Important Dates:
- Release to Sandboxes: November 10, 2019
- Release to Production: November 24, 2019
Improved Gift Aid Management
With this release we did a major upgrade of our Gift Aid Management solution. New or updated functionality includes (but is not limited to) the following:
- Support for Multiple Gift Aid Declarations (including gaps in time)
- Out-of-the-box cooling-off Period for Oral GADs (including Confirmation Date)
- Gift Aid Lightning Component on contact and related objects
- Gift Aid performance upgrades for better scalability
- Payment API support to easily accept Gift Aid Declarations with the online donation
- Ability take handle partial Gift Aidable donations
Below you can see an example of the out-of-the-box Gift Aid component that we
ship to oa the contact, opportunity or installment object.
How to take this update into use
This functionality is enabled automatically for new customers. For existing customers already using our Gift Aid functionality, these upgrades need to be enabled from the setup page. Before you do, please contact our support@findock.com and we’ll assist you with this transition.
Guided Matching
Guided Matching is key new functionality which enables you to improve the matching percentage in your bank statement reconciliation process, thereby reducing the time and manual actions needed to process a bank statement. The new Guided Matching contains the following features:
- Intuitive setup to implement your own business rules for automatically processing and match transaction records from your bank statement file to installments
- Guided manual review experience when user input is required to reduce time spent per transaction and to reduce human errors
- Ability to define a rule set per target
- Multi-agent support
- Ability to use all data from bank statement files together with all data in Salesforce to maximize personalization and automation
- Clear insight into how bank statement files are enriched, processed and matched to simplify implementing and operating payment processing on Salesforce
For more information about Guided Matching, see What is Guided Matching?
CAMT processing updates
In this release we make a general update to our CAMT processing involving the transaction object mapping. The transaction records in Salesforce contain information from both the Entry and the Entry Detail element. In most CAMT.053 cases, we see that the relationship between the Entry and Entry Details elements in the CAMT report are one-to-one. But technically this relationship can be:
- One to none (1-0)
- One to one (1-1)
- One to many (1-n)
To be able to handle all three situations correctly, we added two new fields to the transaction object:
- Entry Type (
cpm__entry_type__c): picklist field with ‘entry’ or ‘entry detail’ as possible values - Primary (
cpm__primary__c): boolean field that default is set to false
From now on we support all three scenarios.
Support for CAMT.054 processing
CAMT is an ISO 20022 Payment Message definition for Cash Management and specifically covers Bank to Customer Cash Management reporting. There are different CAMT report types available for different types of information: camt.052, camt.053, camt.054. Unitil now FinDock supported the camt.053 reports. With this release FinDock adds support for the camt.054 report.
The camt.054 report is titled “Bank to Customer Debit / Credit Notification.” It provides the customer with specific account debit and credit information. The camt.054 is similar to the MT900 (Confirmation of Debit) and MT910 (Confirmation of Credit) messages.
The usage of the camt.054 files can be configured per target in FinDock. By default a target is set to camt.053 processing. That setting can now be changed to camt.054. Currently it is not possible to process both camt.053 and camt.054 reports on the same target (bank account), although the structure of camt.054 is largely the same as camt.053. However, the data created in Salesforce when processing a camt.054 is equal to a camt.053. Processing a camt.054 results in one or multiple transaction sets with the transactions attached to them via a master-detail relationship.
There are different versions of the ISO 20022 CAMT report types. With this new release, FinDock supports:
- camt.053.001.02
- camt.053.001.03
- camt.053.001.04
- camt.054.001.02
- camt.054.001.04
Track counter & last date per closed Installment Status
The Installment comes with a list of different statuses. Each status can be categorized as ‘open’ or ‘closed,’ similar to opportunity stages. For all the different closed Installment statuses, FinDock comes with two fields:
- Last status Date: stores on insert of a payment under the Installment. The value from the field Collection Date of the payment is taken. For the statuses ‘Failed’ and ‘Cancelled’, today's date is stored on the Installment on status change instead of on insert of a payment
- Nr. of times statused: stores the number of times the Installment was put to this specific status
This functionality was already available for the statuses ‘Collected’ and ‘Reversed’. With this release we extend the functionality to all our closed statuses. The following table provides an overview of all the statuses and fields that are tracked in this way:
| Status | Installment Date Field | Installment status counter | Status Description |
|---|---|---|---|
| Collected | Last Collection Date (cpm__Last_Collection_Date__c) | Collection Count (cpm__Collection_Count__c) | This installment is paid for at least with the full amount or even more. |
| Reversed | Last Reversal Date (cpm__Last_Reversal_Date__c) | # of times Reversed (cpm__of_times_reversed__c) | This installment was paid, but has been reversed; the reason is stated in the last reason code received field. |
| Rejected | Last Rejected Date (cpm__Last_Rejection_Date__c) | # of times Rejected (cpm__of_times_rejected__c) | This installment was never paid, but has been rejected by the payment processor; the reason is stated in the last reason code received field. |
| Cancelled | Last Cancelled Date (cpm__Last_Cancelled_Date__c)* | # of times Cancelled (cpm__of_times_cancelled__c) | This installment is cancelled, and no payment is expected |
| Refunded | Last Refunded Date (cpm__Last_Refunded_Date__c) | # of times Refunded (cpm__of_times_refunded__c) | This installment was ‘Paid back’ to the debtor, and no new payment is expected |
| Failed | Last Failed Date (cpm__Last_Failed_Date__c)* | # of times Failed (cpm__of_times_failed__c) | This installment could not be processed; check the last status reason for more details |
How to enable
This functionality is enabled automatically. For new customers these fields are part of the Installment layout, as a specific section (see the screenshot below). For existing customers these fields are automatically filled from this release onwards, but should be added manually to the layout of the Installment.
Added BACS Processing Date for better matching
As part of the BACS package a new field ‘BACS processing date’ (paybacs__BACS_Processing_Date__c) is added to the Payment Schedule. Customers can enter a value in this field when they want to match incoming BACS reports on the BACS processing date instead of the collection date noted on the payment schedule.
When a BACS report is uploaded to our ProcessingHub, the records in that file are matched against installments in the system. Before this release, that part of that match was made on the ‘collection date’ provided in the payment schedule. If a value is provided in the new field ‘BACS processing date’ on a payment schedule, then we match incoming BACS reports on that provided date instead of the ‘collection date’.
How to take this update into use
This functionality is enabled automatically and does not impact current system behavior for customers not using the new field. To make use of this new functionality, you need to add this field on the relevant Payment Schedule layouts.
Improved setting of Opportunity Close Date
When an Installment status is put to collected, and the NPSP source connector is active, then the opportunity stage is also updated with a closed stage value. With this update FinDock also copies the value of the Last Collection Date to the opportunity Close Date. In some cases, standard Salesforce behaviour will override this value and put the Close Date to today’s date instead of the intended Installment Last Collection Date.
From this release onward, it is possible to override this standard Salesforce behavior and make sure that the Opportunity Close Date is always set to the Installment Last Collection Date, even when that date is in the future. This functionality respects the record types selected in the ‘Exclude Opportunity RecordTypes’ list and does not influence those opportunities.
How to take this update into use
This functionality is automatically enabled for new installations. Existing customers can manually activate this functionality in the ‘FinDock for NPSP’ setup page for current implementations. In that page there is a new checkbox, ‘Close Date equal to Last Collection Date’.
Bug Fixes and Enhancements
Status of Payment Schedules created by Recurring Payment Schedules
Description: The Payment Schedules created by a Recurring Payment Schedule are added with the status ‘New’. Payment Schedules are only picked up by our automatic scheduler functionality when they have the status ‘Scheduled’. This means that the automatically created Payment Schedules are not automatically processed.
Solution: Payment Schedules created via the Recurring Payment Schedules are now added with the status ‘Scheduled’ instead of ‘New’. With this change also the automatically created Payment Schedules are picked up by the scheduler.
Removed required token from API in authenticated context
Description: When making requests to the Payment API, the FinDock API token is required regardless of whether the called API is authenticated or anonymous. In a Salesforce authenticated context, this token is a redundant layer of security.
Solution: When requesting the Payment API in an authenticated context, the FinDock API token is not required anymore.