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.
Enhanced File Status Tracking
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.
Manual Bacs DDI Registration Scheduling
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.
Standard 18 support
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.
Customizable mapping between the Opportunity stage and the installment status in NPSP
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.
Target delivery channels
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.
Requested Collection Date
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.
Installment record type “Receivable”
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.
Source field added to Installment
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.
Stricter validations on Targets
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.
Support multi statement CAMT
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.
Improved MT940 support
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.
Check on mandatory uniqueness of mandate IDs per ORG
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.
Several improvements on NPSP integration
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.
Setup and configuration
Several improvements related to setup and configuration have been implemented.
Small fixes on translations
Throughout the entire application several small fixes where made to provide the correct text on labels.
Split of Sepa PAIN.008 into multiple files based on number of transactions failed
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.
Mass update Opportunities results in Error
Issues causing errors when mass updating Opportunities have been fixed.
Validate Mandate service submission for recurring donation
Our Mandate service has been improved to include more, and improve the handling of existing, mandate specific scenarios.
R-transactions not correctly processed in manual review
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.
Manual Review UI fixes
Several improvements in the user interface for Manual Review.
API generated Direct Debit mandates - no Target
When Direct Debit mandates are generated through the PaymentHub API we now select a correct Target.