Skip to main content

Release Notes - October '19

We are happy to present you the PaymentHub October ’19 Release Notes.

Important Dates:

  • Release to Sandboxes: 5/10/2019
  • Release to Production: 20/10/2019

Recurring Payment Schedule​

With the new Recurring Payment Schedule functionality customers will be able to plan ahead and easily create the correct payment schedule records for the coming period, e.g. for the coming year.

The solutions starts with defining the recurring payment schedule. A recurring payment schedule can be either monthly or weekly. The definition of a recurring payment schedule consists of:

  • Name
  • Payment schedule fields: Payment method, Source, Payment Processor, Status, Target, Finished Status, Additional SOQL. These values will be copied into the generated payment schedule records.
  • Business Hours. The solution will show in the preview if calculated dates are not on a business day as defined on the Business Hours record.
  • Start and end date of the period to generate payment schedules for.
  • Repeat frequency, e.g. once every 3 months.
  • Determine collection date:
    • Monthly: collection day strategy (day of month, first of month, last friday)
    • Weekly: collect on which week days.
  • Determine run date: How many days to run schedule before the collection date.
  • Determine selection date: selection day strategy (same as collection date or end of month).

Once saved, the solution will show a preview of the payment schedule records that will be generated. In the preview the user can fine-tune dates and remove payment schedules that do not need to be generated. Until this point, no changes to data are being made.

Recurring Payment schedules

When the user clicks “Create Payment Schedules”, the payment schedule records are generated and inserted into Salesforce.

How to enable

“How to enable” steps below are only required if you are planning to use this new feature. If not, these steps can be executed anytime in the future.

  1. Recurring Payment Schedule also has the FinDock picklist fields Payment Method, Payment Processor, Target and Source that need to be consistent with the setup. Use the “Deploy config” button under the Setup tab to trigger this sync.
  2. Make sure all relevant profiles have Recurring Payment Schedule record types Monthly and Weekly selected.
  3. Make sure all relevant profiles have Recurring Payment Schedule record type Monthly assigned to page layout “Recurring Payment Schedule Monthly Layout” and record type Weekly to page layout “Recurring Payment Schedule Weekly Layout”.

Changes to data model

  • New custom object: Recurring Payment Schedule (api name: cpm__Recurring_Payment_Schedule__c).
  • New optional lookup on Payment Schedule to Recurring Payment Schedule: Recurring Payment Schedule (api name: cpm__Recurring_Payment_Schedule__c).

ProcessingHub Manager Improvements​

Connection Status

ProcessingHub manager now shows connection status right-top, both for Salesforce to ProcessingHub and for ProcessingHub to Salesforce.

Successful connection:

Successful connection notification in ProcessingHub

Connection issue:

Connection issue notification in ProcessingHub

Task timestamps with month and day Task timestamps now contain month and day.

ProcessingHub Manager task timestamps with month and day

Rebranding to FinDock​

Following items are changed:

  • Label and logo of PaymentHub app. New Label: FinDock. Only applicable for fresh installs.
  • Package names “StepOrange | PaymentHub” and “StepOrange | ProcessingHub” renamed to respectively “FinDock” and “FinDock | ProcessingHub”
  • Logos and naming in ProcessingHub web UI changed to FinDock

Bug Fixes and Enhancements​

Buckaroo multiple payment records issue​

Description: In some cases multiple payment records were created for payments processed through Buckaroo.

Solution: Payment records are now only created by the PaymentHub-for-Buckaroo package if the Installment is not yet Collected.

Pain.002 Updates​

Description: In a “Customer Payment Status Report” (pain.002) a bank informs the customer about the status (e.g. rejection, acceptance) of initiated credit transfers or direct debits. A pain.002 file can contain reporting on 3 different levels: file, batch and transaction.

In the past the file was processed top down. First the accompanied file and batch records were searched in Salesforce. If no batch or file records could be found, the file was rejected and the import stopped. As a consequence pain.002 files with no matching file or batch records, but only matching transactions, couldn’t be imported.

Solution: From now on pain.002 will also be processed when only transactions are rejected. The file will be processed as follows:

  • A whole file is rejected: File is matched on OrgnlMsgId attribute. If found the Inbound Report status is set to Processed. In all other cases we set the Inbound Report to Manual.
  • One or more batches are rejected: Batch is matched on OrgnlPmtInfId attribute. If found the Inbound Report status is set to Processed. In all other cases we set the Inbound Report to Manual.
  • One or more transactions are rejected: Transaction is matched on OrgnlEndToEndId attribute. If found the Inbound Report status is set to Processed. In all other cases we set the Inbound Report to Manual. If no installment is found to match to the rejected transaction, the Inbound Report status is set to Error.

Entries in CAMT files sometimes too long for Transaction RAW XML Entry field​

Description: Since the September ‘19 release the whole raw xml entry value (with tag ) is stored on the Raw XML transaction field. Because this field has a limit of 32,768 characters, entries larger than 32,768 could lead to an error.

Solution: From this release on the entry is truncated to 32,768 characters to make sure no errors occur in these exception cases.

SmartDebit ARRUD matching issue, because of date after reference​

Description: SmartDebit ARRUD matching failed because reference received from SmartDebit (with date) was different from the reference in FinDock (without date).

Solution: Date is removed from reference received from SmartDebit.

ProcessingHub Manager counters not correct for retry & query step above 100k​

Description: In the ProcessingHubManager the number of records not always showed the correct number of records in case of a retry or of a fetch step.

Solution: The ProcessingHub-manager now correctly reflect the number of records in case of retry or fetches above 100,000 records.