Skip to main content

Release Notes - September '21

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

note

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.

Important Dates:

  • Release to Sandboxes: August 29, 2021
  • Release to Production: September 12, 2021

In addition to several important enhancements and bug fixes, with this release we are expanding the scope of our Payment Schedule: Data Quality Validation and moving the feature to beta.

Payment Schedule: Data Quality Validation to beta​

With this release we are moving our Payment Schedule: Data Quality Validation features to beta. We have also expanded the payment methods and processors covered by the validation component. The new additions in this release are bolded below:

  • Bacs Direct Debit | Stripe
  • Bacs Direct Debit | FinDock
  • Bacs Direct Debit | GoCardless
  • CH-DD Direct Debit | FinDock
  • Credit Card | Adyen
  • Credit Card | Axerve
  • Credit Card | Checkout.com
  • Credit Card | Mollie
  • Credit Card | Redsys
  • Credit Card | SIX Saferpay
  • Credit Card | Stripe
  • Credit Card | Worldpay
  • Gift Aid | FinDock
  • LSV+ Direct Debit | FinDock
  • PostFinance Card | SIX Saferpay
  • SEPA Direct Debit | Buckaroo
  • SEPA Direct Debit | FinDock
  • SEPA Direct Debit | Mollie
  • SEPA Direct Debit | Stripe

In addition to the new validation rules, we have made several enhancements and fixes for payment and mandate schedules as outlined in the following sections.

Data Quality validation rules case-insensitive​

We’ve modified the validation rule checks to be case-insensitive. For example, the values “Pending recollection” and “Pending Recollection” were not considered equal, but now they will be treated as the same.

Data Quality validation component enhancement​

To avoid unnecessary running of the Data Quality validation, FinDock automatically removes the capability from a record based on the record status.

Before this release, this meant just hiding the button for running the validation, which was potentially confusing. With this release, additional information is provided that explains why validation is not necessary due to the status of the given record.

Payment Collection: Auto-collect payments (beta)​

Date field changes on recurring payment schedules​

Issue: FinDock would throw an error if you try to change a field with a date type value on a recurring payment schedule after it has been saved in specific circumstances.

Solution: We identified the underlying issue and fixed it so that you can edit date fields on recurring payment schedule records as expected.

Preview enhancements for recurring schedules​

To make the preview of recurring payment schedules and recurring mandate schedules easier to understand and use, we have introduced the following enhancements:

  • New preview component titles to better reflect the preview state (“generated” for normal previews, “forecasted” for auto-create previews)
  • New list numbering (or auto-create previews to help with readability
  • New preview list limit (max. 25) to improve preview usability and performance
  • Removed Selection Date as a trigger for warning that a scheduled event lands on a non-business day. The warning is now only shown if Run Date or Collection Date fall on a non-business day.

Mandate schedule with no mandates​

Issue: If no mandates are found for a given mandate schedule when auto-create is enabled, the schedule is set to ‘Failed’ even though the schedule did run successfully.

Solution: Mandate schedules are now handled the same was as payment schedules:

  • If the schedule is run automatically and no mandates are found, the status is set to ‘Done'.
  • If the schedule is run manually and no mandates are found, the status is set to ‘Failed.’

Mandate Schedule Processing Date enhancement​

Issue : If you create a new mandate schedule for a Bacs target, the Processing Date field is not shown. This occurs because the field is dependent on the Subtype field having the value 'Manual.' This value is updated through a trigger on create/update of the record, which has not happened when starting to make a new schedule.

Solution : Instead of making the Processing Date field visible based on the target subtype, we have made the following changes:

  • Mandate Schedule:
    • Always show Processing Date
    • Validation rule that enforces Processing Date is entered when target is Bacs with subtype Manual.
  • Recurring Mandate Schedule:
    • Show Processing Date Conflict Strategy if auto-create is enabled
    • Show Run Date Conflict Strategy if auto-create is enabled
    • Always show Run # Of Business Days before Proc. Date

Core​

Guided Matching performance improvement​

Issue: When configuring a Guided Matching Query rule with multiple where-clauses, the UI performance can start to lag excessively (e.g. more than a minute for a page load).

Solution: We’ve made some tweaks to the query rule implementation to better handle where-clauses and avoid UI performance lags.

Guided Matching Query rule update​

Issue: In Guided Review table view situations (e.g. query rule with several results strategy = multiple), the lookup fields would not display anymore, and the related cells would remain empty.

Solution: We identified the underlying bug causing this issue and fixed it. The lookup fields and related cells now behave as expected.

Manual Review installment status​

Issue: Manual Review installment status calculation could be incorrect for cases where a payment was already received for an installment. Sometimes that installment status would be set to Collected, even if there was still an amount open.

Solution: We found and fixed the bug causing this issue, so Manual Review will not change the installment status to Collected if there is an open amount.

Manual Review query limit update​

Issue : When there are more than 1,000 objects (both visible and hidden) in an org, editing or adding a rule in Manual Review may result in the query limit error Collection size <number> exceeds maximum size of 1000 .

Solution: We changed the affected Manual Review query to exclude some objects that are not relevant to Manual Review. This reduction in scope should avoid reaching the Salesforce query limit.

PaymentHub Integration Base permission set upgrade​

As part of our internal quality assurance, we identified a gap in the PaymentHub Integration Base permission set. With this release, we have added to this permission set:

  • Read and edit field level security for the Payment Journey field on the Payment Schedule object.
  • Read access to the Payment Journey object

Payment Request Generator fixes​

We fixed a few issues with the Payment Request Generator:

  • Fixed issue with false decimal exception error when Source Type was Report and for Amount field the Currency field was used.
  • Fixed issue causing the mini-tile component for batch Apex job progress to not load.
  • Fixed an issue causing the generation status to remain in ‘generating’ when the same field was selected twice in the input field mapping. If the same filed is selected more than once, the generation will now throw an exception error.

Payment API deduplication enhancements​

Issue: Standard Salesforce deduplication of Contact or Account records can lead to issues with the enforce uniqueness functionality of FinDock for payment profiles. In some cases, we have seen that standard Salesforce deduplication does not deduplicate payment profile records. It also doesn’t trigger recalculation of the unique identifier on the payment profile record, even when the profile relinked to another contact or account record. However, when this payment profile is used later by the Payment API or in any other way, the unique identifier is recalculated, which can then lead to a “Unique Exception” error.

Solution: The root cause of this data quality issue is fundamentally beyond FinDock functionality. However, we have made some improvements to help alleviate the issue. The Payment API v2 will now use the Payment Profile record with an up-to-date Unique Identifier, instead of a random one where there are two duplicates in the system. This will avoid the asynchronous part of the API v2 (Inbound Report / Guided Matching based) to not fail anymore because of this issue.

Issue: When both Tikkie and FinDock PayLinks are enabled, the Pay URL field for Quick Tikkie was overwritten by the PayLinks URL.

Solution: We fixed the bug causing this issue so that the Tikkie URL is maintained even when PayLinks is enabled.

Performance optimization on payment record creation​

We optimized the trigger logic used for creating payment records. This includes:

  • General code optimizations that do not change FinDock behavior
  • Previously a payment insert would trigger two separate updates on the related installment: (1) update open amount and (2) update the “Last Date” fields (e.g. Last Collection Date). These have been combined in one update statement now, leading to fewer trigger, flow and process invocations.

Based on our testing with customers, the number of trigger invocations have decreased by a third with overall payment creation performance more than 80% faster. However, actual performance improvement will vary from org to org.

WebHub backend maintenance​

As part of our system upkeep and maintenance, we have made several security-related updates to backend components used in our WebHub implementation. These changes impact underlying infrastructure only and do not impact customer orgs.

ProcessingHub​

New MT940 format support​

In this release, we have added support for newer file format of Barclays called MT940 B+. Additionally we added the Barclays BIC code GB26BARC so customers can use either the old code BUKBGB22 or GB26BARC to indicate the target is a Barclays account. FinDock automatically detects MT940 uses the normal format or the new B+ format.

SEPA​

Payment API support for non-EEA IBAN and SEPA Direct Debit​

Further expanding our support for SEPA Direct Debit payments from non-EEA banks (such as UK banks), we have added the following parameters to the Payment API:

  • street
  • housenameNumber
  • zipCode
  • city

All four are required to collect SEPA Direct Debit from a non-EAA country bank account. They are optional for EAA country accounts. If one of the four fields is provided for a valid EAA IBAN, FinDock only stores the provided fields on the Payment Profile record.

Adyen​

Improved notification handling​

Issue: Notifications for payments made with Adyen MOTO were misclassified and put into inbound reports as SETUP_AUTHORISATION with status Failed, causing errors in associated payment data.

Solution: Incoming Adyen MOTO notifications are now handled with inbound reports with subtype MOTO_AUTHORISATION. If a custom Guided Matching rule for MOTO_AUTHORISATION is defined, then the status of inbound reports with this subtype is set to New, otherwise it is set to Manual.

Swiss Payments​

info

The Swiss Payments for FinDock package is not pushable, so we cannot automatically update your org with the normal release process. To receive updates, enhancements and fixes, you need to manually install the latest package version using the FinDock Installer.

Update for Swiss payment methods​

Issue: In our Payment APIv2 specification, IBAN and holderName were required parameters for Direct Debit and ESR payment methods through CH-DD and LSV+. This was causing issues as they are technically only required for direct debit through LSV+.

Solution: We’ve changed the parameter requirements for CH-DD and LSV+. Now IBAN and holderName are required for Direct Debit through LSV+, but optional for direct debit through CH-DD and for ESR (through both CH-DD and LSV+). However, if BIC or holderName is provided, then IBAN is required.