StepOrange is pleased to present you our new latest Spring ’18 release. This release contains comprehensive set of New features, Improvement on existing features and solved Bugs.
To give you as a user better insight into the status of your payment processing related files, we have added a File tracking feature. Each uploaded and created file will be represented with a record in a new object called “PaymentHub File”. This record not only displays the current status of the file, but also the recognized file type and any error messages that might have occurred during file processing. And as an added bonus, the most important status updates on uploaded files through a chatter group are added as comments under the post, giving you even faster insight into the processing status of your file.
With the new 1.20 upgrade, users now have the ability to manually control the Bacs DDI Registration File creation process. Through a new object called “Mandate Schedule” users can make sure that any DDI Registration process that involves user interaction, such as manual upload to the bank or service bureau is only executed when an actual user is present.
BACS payments messages use a proprietary format known as “Standard 18”. This widely used standard is now supported by PaymentHub. The implementation of this standard allows for a more generic solution towards BACS bureau’s and BACS software used by our customers.
To make sure the installment to opportunity status mapping matches your business process and requirements, we have now made this mapping customizable. It’s even possible to define specialized mappings for different Opportunity record types.
We extended our Target objects to include the notion of target delivery channels. These delivery channels specify where a file is send or retrieved from for this particular target. When using the type “Manual” files are exchanged using the specified chatter group, other types will exchange files with a third party such as the bank or a payment service provider.
In order to allow more flexibility with this new release user can specifically select a Requested Collection Date of a payment schedule. This value is used to instruct the bank or external processor on which date the Bulk collection file should be processed. Please note that it is a “Requested” date, meaning that the actual date of processing is subject to the timelines of your individual bank or processor.
In preparation of future development, we have introduced record types on the Installment object. The standard record type for every installment is now “Receivable”. When upgrading to this release, make sure your customizations take this new record type into account.
We have added a “Source” field to Installment to indicate the originating source for this installment record. This field is automatically set when using the PaymentHub standard functionality, if you have introduced customization in your org for the creation of Installments, make sure this field is also populated.
To help reduce errors during configuration of your targets, we have added stricter validation on the target settings screens. This reduces the risk of errors during processing due to incorrect data in the target configuration.
A single CAMT.053 file can consist of statements for multiple accounts. We improved our bank statement processing in order to correctly process CAMT files that contain multiple statements. Each statement is processed as a single unit, meaning that if one statement fails, the other statements are not affected. Consequently, the deduplication of CAMT files is no longer done on file level but is now on the statement level.
The MT940 bank statement file format is a SWIFT standard, however this file format varies widely between different banks. In this release we included support for the MT940 variant as used by the Lloyds Bank in the UK.
Mandate IDs used for payment transactions should be unique in order to avoid failed transactions at banks or payment service providers. With this release we have implemented checks to enforce mandatory uniqueness within your Salesforce org.
We included our trigger in the NPSP “Table Driven Trigger Management” feature, this will not have an impact on regular users, but can be of great benefit when implementing complex automation scenarios by expert Admins or System Integrators.
Several improvements related to setup and configuration have been implemented.
Throughout the entire application several small fixes where made to provide the correct text on labels.
In some cases, Sepa Direct Debit runs need to be split across multiple files based on the number of transactions per file. In certain scenarios, this split failed resulting in incorrect files and a failed run. Customers affected by this behavior will have already received a separate communication regarding this issue.
Issues causing errors when mass updating Opportunities have been fixed.
Our Mandate service has been improved to include more, and improve the handling of existing, mandate specific scenarios.
Reversed transactions, for instance rejected SEPA Direct Debit transactions, handled via Manual Review are now resulting in the correct status and value of the related Installment.
Several improvements in the user interface for Manual Review.
When Direct Debit mandates are generated through the PaymentHub API we now select a correct Target.