Release Notes - September '19
We are happy to present you the PaymentHub September ’19 Release Notes. There are no manual actions required to enable features in this new release.
Customers using the Raw XML field for CAMT files on the transaction object should be aware the mapping will change. Which means after this release the information currently stored in the Raw XML field can be found in the RemittanceInformation field.
Important Dates:
- Release to Sandboxes: September 1, 2019
- Release to Production: September 15, 2019
Payment Schedule Path: Progress tiles
In the June ‘19 release we introduced the Payment Schedule Path component that makes executing a payment schedule much easier and intuitive. In this release we updated this component with progress tiles. The prepare, process and close progress tiles provide direct insight into what’s running with related details.
How to enable
No actions needed. Please see this article to enable the Payment Schedule Path if the path isn't shown.
Delete processes in your sandbox via the ProcessingHub Manager (Already released)
If a process on your sandbox environment didn’t reach an end state and you can’t retry the data load, you can use the delete functionality. With this functionality you can delete a whole process to make sure the next process will start. Please be careful with this functionality, because any changes this process already made to Salesforce data (through ‘Push’ tasks) cannot be rolled back. Which means that deleting a process may be a risk for data-integrity. This is also the reason this button is only available on sandboxes. The delete button can be found in the ProcessingHub tab:
- Click on the process which blocks you from further processing.
- Go to the ‘Details’ tab.
- Click on the button ‘Delete Process’.
How to enable
No actions needed.
Installer & Igor version management
Via our PaymentHub installer (installer.steporange.com) and Igor it’s possible to install or update PaymentHub packages in your different Salesforce environments. Until now it was only possible to install or update the packages to the latest version of our production release. Both the installer and Igor are updated and distinguish between our latest production version and pre-release version.
This means that when an environment of the type sandbox is used with the installer or Igor then the latest pre-release version is installed or updated. This is similar to our versioning of the ProcessingHub.
How to enable
No actions needed.
Easily deploy and apply PaymentHub Settings with new 'Deploy Config'-button
In this release a new button 'Deploy Config' is introduced. When this button is used, the Salesforce environment is updated with the settings as they are in the custom settings. This change enables easier deployment and configuration of PaymentHub settings between environments. It’s also robust so it will hold in very large Salesforce environments, for example when adding a new custom payment method.
How does it work?
When you currently change certain settings in the PaymentHub setup page, the changes are automatically applied throughout the whole Salesforce environment. For example when a new custom payment method was added, or a payment method activated from a payment service provider.
From this release on those changes will not be made in real- time but they will only update custom settings in the Salesforce environment. In the PaymentHub setup there’s a new button ‘Deploy Config’ on the right top of the page:
This button is always visible and every time relevant settings are changed this button will show a notification.
Using this button, will result in an update of your Salesforce Org according to the custom settings.
How to enable
No actions needed.
Updates to our CAMT mapping
We’ve updated our CAMT mapping based on different feedback and cases received from customers over the last couple of months. From here we want to thank you for your attention and your feedback.
From this release on the following changes will be introduced:
1. New fields added to transaction from CAMT tags
We now also map the following data from the CAMT entry to the transaction:
- PmtInfId
- AddtlNtryInf
2. Mapping of IBAN
Until now we only mapped the IBAN to the transaction when we also had the accompanied name. We removed this restriction and now always map the IBAN tag when presented in the CAMT entry.
3. Handling of related parties tag
Different banks handle reported r-transactions in CAMT files differently. For example, in the case of a reversal of a direct debit, some banks report this reversal with the same party as debtor and creditor.
Where other banks then switch the parties from debtor to creditor. To be able to handle both situations PaymentHub now compares the target of the file with the reported party. And then reports the opposing party on the transaction record in Salesforce.
4. Update to raw xml field on transaction
The mapping to the field ‘raw xml’ on the transactions is updated and now contains the whole raw xml entry value (with tag \<entry>). The current value from the mapping is put to a new field on the transaction object: RemittanceInformation.
This only applies to transactions coming from a CAMT file.
How to enable
No actions needed.
Bug Fixes and Enhancements
Smart Debit integration processes all reports not processed before
Description: The PaymentHub Smart Debit integration runs daily to download and process all the reports from Smart Debit for that day. Problems could occur when these reports do not always come on the same day.
Solution: The PaymentHub Smart Debit integration now downloads and processes all available reports from Smart Debits that were not processed before. Also when these reports are not for the current day.
Reason code stored on the payment in case of pain.002 rejection
Description: The reason code as reported in the pain.002 file for a payment rejection was only available on the Installment object but not on the specific payment.
Solution: The field ‘Reversal Reason Code’ is populated on the payment record when a reversal payment is created via a pain.002 file.
Book debit transaction via manual review results in opportunity with negative amount
Description: A new installment, payment and, in case of PaymentHub-for-NPSP, an opportunity is created, when the manual review-screen is used to book an outbound transaction. The recordtype 'Payable' on the installment and the negative amount on the payment, informs the user it is an outbound transaction. For the opportunity it is difficult to determine if it is related to an outbound transaction, because it doesn't have a specific recordtype and since several months PaymentHub stores the amount as a positive value.
Solution: To inform the user the opportunity relates to an outbound transaction, the amount on the opportunity will be saved as a negative value from this release on.
Payment Schedule reports show all Installments
Description: In June we released the Payment Schedule Record Page. Depending on the status of the Payment Schedule this page contains three different report charts. The following two report charts only show ‘My Installment’ in the context of the user instead of ‘All Installments’:
- Installments Amount
- Installments Count / Status
Solution: This is fixed by updating the reports to filter ‘All Installments’ instead of ‘My Installments’ and will be effective on a fresh install. Unfortunately Salesforce limitations prevents us to update these reports to orgs in which these components are already installed. Therefore it is recommended to manually adjust the filter of these reports to 'All Installments' and save the report, in case your org already have these reports installed.
ProcessingHub can only be connected to one Salesforce org
Description: It’s possible to authorize multiple connections from the ProcessingHub to different Salesforce orgs by adding multiple environments in the ProcessingHub.
Solution: Although there’s no real use case for this scenario we decided to make sure this can’t happen and to ensure that the relation between the ProcessingHub and Salesforce is always 1-1. When you want to change the Salesforce org that is connected to the ProcessingHub then you first need to delete the ‘old’ environment before creating the new one.
ProcessingHub rejects on valid requests from different Salesforce orgs
Description: When you have a new Salesforce environment then it’s possible to authorise that environment to an already existing ProcessingHub account. But when the ‘old’ Salesforce environment is not actively detached from the ProcessingHub account then it’s possible to have multiple Salesforce environments attached to the same ProcessingHub which can cause data integrity issues.
Solution: There can only be one active connection between Salesforce to the ProcessingHub. So when the ProcessingHub receives requests from a different Salesforce environment then the one that is connected then it immediately rejects the incoming request.
Connection to the ProcessingHub is deactivated on full copy sandbox refresh
Description: The token that represents the authority to connect to the ProcessingHub is stored in Salesforce as a record of the ProcessingHubSetting object. When the connection to the ProcessingHub is used then this data is searched and used. When you make a full copy sandbox from production this data is also coming to the sandbox and can lead to very unexpected connection issues.
Solution: On the record where the token is stored we also save the Salesforce OrgId. Every time the token is searched, this search includes the org id to make sure we only use the token when it belongs to the current Salesforce org.