Release Notes - May '21

We are happy to present the FinDock May '21 Release!

Important Dates:

• Release to Sandboxes: May 02, 2021
• Release to Production: May 16, 2021

Pilot feature updates

In our last release, we introduced two new features for piloting:

• Payment Collection: Data validation
• Payment Collection: Auto-collect payments

Development is progressing well, and we have gotten a lot of helpful feedback.

Payment Collection: Data validation

With this release we are adding the following (recurring) payment methods and processors to the scope of the data validation pilot:

• Credit Card with Axerve as processor
• Bacs Direct Debit with FinDock as processor
• Swiss CH-DD and LSV+ Direct Debits with FinDock as processor
• Credit Card, SEPA Direct Debit and Bacs Direct Debit with Stripe as processor

SEPA Direct Debit validation rules Thanks to our pilot customers, we have received value feedback that helped us identify improvements for data validation of payment schedules using SEPA Direct Debit. In this release, we have added validation for:

• Currency: checks if the correct currency is set
• RecordType: checks whether the related payment profile has IBAN as record type
• Target Properties: checks if the target on the records has the required target properties

Payment Collection: Auto-collect payments

With this release we introduce the ability to automatically create payment schedules using the Recurring Payment Schedule functionality. If a recurring payment schedule is created and the new auto-create checkbox selected, FinDock automatically creates payment schedules based on the frequency defined for the recurring payment schedule.

Both the creation and execution of payment schedules in this pilot are making use of the newly introduced FinDock Heart Beat. Every 24h the FinDock Heart Beat will auto-create payment schedules, based on the recurring payment schedule configuration, and auto-run payment schedules that are scheduled for that day.

This means that for many payment methods, you can simply configure auto-collection for recurring payments once and FinDock takes care of collection based on the recurring payment schedule.

Payment Schedule enhancements

New Lightning Record Page - Payment Schedule

A new Lightning Record Page for the payment schedules object is now included in FinDock: “Payment Schedule Record Page - Dynamic Form.”

This page leverages Salesforce Dynamic Form functionality to provide a dynamic, context-aware experience when working with payment schedules.

• Collection Date field is only shown for payment processor & payment method combinations that require this field. This includes all direct debit methods with FinDock as processor (PaymentHub-SEPA, PaymentHub-BACS, PaymentHub-CH-DD and PaymentHub-LDV).
• A set of system-internal fields is automatically shown for System Admins (recognized by having Modify All permission).

If you would like to use this page, you need to activate it first. For instructions, see Salesforce Help. If you would like to further customize this page, you need to clone it first.

New Lightning Record Page - Recurring Payment Schedule

The FinDock Recurring Payment Schedule now includes a Lightning Record Page shipped as the org default for recurring payments schedules. This page uses a Dynamic Form instead of the classic page layouts so that:

• Manual page layout assignments for both record types (weekly and hourly) are not needed anymore.
• FinDock can upgrade the Recurring Payment Schedule with new fields, which was not possible before.

Progress Path enhancements

In the Payment Schedule progress path component, you can see the details of underlying Apex jobs. With this release, we have further enhanced the detailed view to show not only a single Apex batch but also multiple batch Apex jobs information when applicable.

As you can see in the screenshot above, we have also renamed the "Prepare" step to "Generate" to better reflect the actions FinDock performs during that initial step of the payment schedule process.

Improved handling of failures during generation

We have introduced new error handling to catch installments that do not have the required status for collection. If a payment schedule encounters such installments, an error message is shown indicating there are installments included in the schedule that have "Failed" status. These installments need to be fixed or removed from the schedule, after which you can start processing.

Improved tooltips

All fields on the Payment Schedule object have new tooltips to help users correctly create payment schedules. Salesforce tooltips are not upgradeable by ISVs, so unfortunately these new tooltips are only available for new installs.

However, existing installs get the same content in the description of the field, and we have updated the Payment Schedule object description in our Knowledge Base to include more details about each field.

Refined the validation rule on Collection Date field

The “Collection Date must be in the future” validation rule on payment schedule has been refined. In the past, this validation rule could prevent completing the payment schedule process also when the rule was not relevant.

The application of this validation rule has been modified as follows:

• The rule is restricted to direct debit methods with FinDock as processor (PaymentHub-SEPA, PaymentHub-BACS, PaymentHub-CH-DD and PaymentHub-LDV).
• The status ‘Pending Verification’ is excluded from the schedule states where it is checked that collection must be in the future.

Core

FinDock Setup Assistant

We are introducing the FinDock Setup Assistant. The aim of the FinDock Setup Assistant is to highlight problems with the FinDock Setup early and clearly to you. The design is based on the Salesforce Lightning Design system. Below is an example of how the new assistant appears in FinDock Core configuration.

With this release the FinDock Setup Assistant will check four items every org should have:

• Is the Initial Remote Site Setting created?
• Is the WebHub connected?
• Is the FinDock Hear Beat scheduled?
• Is the default source connector set?

New FinDock Heart Beat

FinDock Heart Beat is an Apex class that manages various FinDock Apex jobs automatically, eliminating the need to schedule each FinDock Apex class separately. The Heart Beat includes a new general configuration setting in FinDock Core. For further details, please visit our Knowledge Base.

New status summary counters on Transaction Set

Having summary data for transaction sets is helpful in many ways, particularly when determining which transactions related to the set still need attention (e.g. status is ‘Guided Review’ or ‘Failed’). With Guided Matching, however, roll-up summary fields would cause excessive locked rows.

To provide summary data for transaction sets, we are adding eight new status counters to Transaction Set, pictured below. An Apex job (handled by the new FinDock Heart Beat), keeps the counters up to date. Counters are only updated on transaction records that have been modified since the last job run.

In addition, there is a new an option on the Transaction Set Progress component to update the counters immediately.

Guided Matching: Regular Expression rule type storing DateTime fields

Issue: Using the Regular Expression rule type, Guided Matching extracted the value for DateTime fields and stored the value in the time zone of the org user. In the case of dates, this could result in a date value appearing one day before the extracted value due to the difference between the user’s time zone and the GMT zone of the org.

Solution: We updated the rule so that GMT is used to store the DateTime value.

Guided Matching: Locked row handling to handle records without Ids

Issue: In the February ‘21 release, we introduced auto-retry functionality in Guided Matching that checks the type of record which caused a locked row exception. In certain cases, a null pointer exception might occur during this check and break the auto-retry.

Solution: This issue was caused by the timing (presence) of an Id on the record being checked. In this release we modified the auto-retry record checking functionality to explicitly check if the record that caused the locked row exception has an Id.

Salesforce issue affecting Deploy Config

Recently we are seeing cases where using the FinDock Deploy Config button results in an error with the message “admin operation already in progress.” This error may appear due to a known Salesforce issue which we are monitoring.

The error is temporary and restarting deployment usually clears the problem. You may need to restart more than once. A possible workaround to restarting deployment is to close the browser tab/window where FinDock Setup is open after clicking Deploy Config. This can help avoid the error, but may not always work.

We’ve added an FAQ about this issue to our Knowledge Base that we will update as we learn more.

ProcessingHub

Performance optimization

Issue: ProcessingHub had a static number of so-called worker processes available on Heroku. This could lead to situations when high workloads created waiting times before customer jobs could start.

Solution: We have revamped our worker handling to use a dynamic auto-scaling solution. This ensures there are workers immediately available for customer processes and eliminated waiting times.

Process status on ProcessingHub Manager

Issue: When multiple LDV orgs check process status information through ProcessingHub Manager, this may cause significant performance degradation as ProcessingHub Manager collects information about large numbers of processes.

Solution: We have introduced new time and entry limits for ProcessingHub Manager to reduce the number of server callouts. Status information is now only displayed for the last 90 days or max. 100 processes.

NPSP

Recurring payment validation update

Issue: Setting up a recurring payments through a PSP, e.g. through Mollie, could fail with a validation error from the NPSP as source package.

Solution: The validation causing the error was checking installment status before updating the record. This check is no longer needed, so we removed the step from the validation process.

Bacs (PaymentHub-BACS)

Bank account and sort code validation component for manual entry

In our Jan. '21 release, we added automated sort code and bank account validation to the Payment API (and Giving Pages). In this release, we are adding the same bank account and sort code validation capability for customer service agents who need to manually enter payment information in Salesforce.

This new feature is implemented as a Lightning component that can be added to the Payment Profile layout. When the payment profile has a bank account recordtype, the component will have an activate Validate button that the agent can click to confirm that the sort code and account numbers are correct.

Simplified 'generate' step in payment schedule runs

In our April '21 release, we moved the generation of payment references from the payment schedule generate step to the Installment trigger for SEPA Direct Debit, as explained in our April '21 release notes.

With this release, we have made the same update for Bacs Direct Debit payments using Bacs for FinDock, both Bacs Manual and SmartDebit.

Please note that this modification introduces slight changes to the payment reference format.

Bacs payment reference format:

• Old: {Value of Mandate ID formula on Installment}-{installment.Due_Date} Total length: up to 18 characters.
• New: {Value of Mandate ID formula on Installment}-{unique random number}. Total length: 18 characters.

SEPA

Updated address handling for pain.008 files with UK banks

Issue: For SEPA Direct Debit where the debtor bank is a UK bank, ProcessingHub added address fields to pain.008 in both structured and unstructured forms. This duplicate information could cause problems with certain banks.

Solution: We removed the structured form as advised by the European Payments Council so that pain.008 files (in this particular UK scenario) only include unstructured address lines.

Old format

<PstlAdr>
    <StrtNm>Street</StrtNm>
    <BldgNb>10</BldgNb>
    <PstCd>12345</PstCd>
    <TwnNm>City</TwnNm>
    <Ctry>AB</Ctry>
    <AdrLine>Street 10</AdrLine>
    <AdrLine>12345 City</AdrLine>
</PstlAdr>

New format

<PstlAdr>
    <Ctry>AB</Ctry>
    <AdrLine>Street 10</AdrLine>
    <AdrLine>12345 City</AdrLine>
</PstlAdr>

Swiss Payments

Simplified 'generate' step in payment schedule runs

In our April '21 release, we moved the generation of payment references from the payment schedule generate step to the Installment trigger for SEPA Direct Debit, as explained in our April '21 release notes.

With this release, we have made the same updates for Direct Debits processed either via CH-DD or LSV+.

PayPal

Permission set update to fix redirect error

Issue: Setting up a recurring payment with PayPal through the Payment API, the redirect went to a 500 error page in specific permission configurations.

Solution: The error was caused by a missing permission to the permission set, so we have updated the PayPal permission set with this permission.

Buckaroo

Simplified 'generate' step in payment schedule runs

In our April '21 release, we moved the generation of payment references from the payment schedule generate step to the Installment trigger for SEPA Direct Debit, as explained in our April '21 release notes.

With this release, we have made the same update for SEPA Direct Debit payments with Buckaroo.

Please note that this modification introduces slight changes to the payment reference format.

Buckaroo payment reference format:

• Old: {Installment.Name}{Timestamp}
• New: '1'{unique random number of 19 digits}