As part of a new FinDock implementation, you may need to load historical data into FinDock objects, for example, to preserve status of payments or continue future payments using the same bank account and mandate details.
This article outlines the required loading order and explains the data model in more detail to allow you to create a mapping from your current database to the FinDock objects in Salesforce. We only address FinDock' objects. Contact, Account, Campaign, Opportunity and any other standard of custom object in Salesforce are out of scope.
Data migration can be done as soon as FinDock has been successfully installed. However, if you wish the system to perform actions based on your data load (such as create new mandates), you will need to complete configuration first.
When loading the data, make sure your source data uses UTF-8 encoding. For high volume imports (10 000+ rows), we recommend disabling as much automation as possible. This speeds up the data import process considerably.
Disabling automation can be accomplished by deactivating the relevant FinDock extensions such as the source connector(s) and payment extensions. This ensures the system will not evaluate every record as you insert it. This does mean, however, you will have to provide all the related information, including the manual creation of mandates, through the import.
A specific loading order must be followed to ensure data and data relations are correctly build. The object loading order is:
- Contacts and Accounts
- Payment Profiles
- Mandate Schedule (optional)
- Recurring Payments (if using FinDock Standalone)
- Recurring Payment objects in source packages (e.g. Agreements in Converse or Recurring Donations in NPSP)
- Source Records (e.g. Opportunities in NPSP)
- Payment Schedule (optional)
- Inbound reports
- Transaction Sets (optional)
- Transactions (optional)
The following objects are FinDock operational objects and are not supported for data migration:
The following objects might have special considerations for data migration.
Payment Profiles contain information that supports particular payment methods, such as a bank account for direct debit, or obfuscated credit card details. When importing payment profiles, you need to deduplicate them on the contact or account level to ensure a particular IBAN, bank account or credit card is created only once for any particular contact or account. The same bank account can be in multiple payment profiles if they are connected to different contacts or accounts.
The Mandate Schedule is used to initiate the registration of mandates at an external processor. Import of historical mandate schedules is not required, but can be done for completion and reporting purposes. When importing, make sure to set the status field
cpm__Status__c to 'Verified' to ensure the historical mandate schedules are not re-executed.
Careful migration of Mandates and/or DDIs is of the utmost importance. If the data is not loaded correctly, it can have a huge impact on collection runs because the payment processor might not be able to identify the mandate. When importing existing mandates from a source system, make sure to use the field
cpm__Custom_Reference__c for the current mandate identification as this always takes precedent over the reference generated by FinDock.
If payment method/processor requires mandates to be registered before they can be used (such as with BACS Direct Debit), you need to set the status field (
cpm__Status__c) to 'Success.' When no external registration is required, this field is ignored and can be left blank. Make sure to also import the last used date into the field
cpm__Last_Used__c to ensure correct usage of sequence types where applicable.
cpm__Active__c checkbox according to the status of the mandate. If you the mandate should never to be used again, set it to false. Take extra care when importing historical one-off mandates. They need to be set to inactive, otherwise they might be reused in future direct debit runs.
Make sure to set the correct value in
cpm__Target__c. If the same mandate reference is applicable for multiple targets, you need to create multiple mandate records to reflect this. The correct value for Target can be ascertained by translating the bank account for which the mandate is valid to the target name as defined in FinDock Setup.
The value in Payment Processor (
cpm__Payment_Processor__c) for Mandate is an exception. Contrary to other objects, on the Mandate object, this is a text field. Otherwise, use the correct value as defined on other objects.
Recurring Payments are only required if FinDock is used as a standalone solution, i.e. FinDock is the source. Be aware that the last collection date (
cpm__ls_coll_date__c) plays an important role in determining the next collection date, and as such this field should be populated with accurate data.
After migration, we strongly recommend checking for active recurring payments that have a next collection date before today. Any results here might indicate a problem with the source data.
When importing source objects, we strongly recommend to turn off the source connector in the FinDock Setup. This prevents the system from automatically creating installments for these source records. Take care to populate the control fields (Payment Method, Processor, Target, Payment Profile and Mandate) with the correct values. Also make sure to use API values for picklists and not the translated values.
The Payment Schedule is used to initiate bulk collection runs such as Direct Debit or Recurring Credit Cards. Import of historical payment schedules is not required, but can be done for completion and reporting purposes. When importing, make sure to set the status field
cpm__Status__c to 'Verified' to ensure the historical payment schedules are not re-executed.
When importing Installments, make sure to properly address the references to other objects via lookups. This is especially important for the source records you previously imported, as reporting results might be incorrect if the link between Installment and source record is not properly defined. Take care to populate the control fields (Payment Method, Processor, Target, Payment Profile and mandate) with the correct values.
Also make sure to use API values for picklists and not the translated values. The status field
cpm__Status__c only supports the predefined values. Importing values that are not standard FinDock values might cause inconsistent and unexpected behavior.
If you have existing payment references you would like to migrate/import, you can best store them in the cpmCustom_Payment_Referencec field as this always takes precedent over the reference generated by FinDock.
Make sure to link Payments to their respective Installments, as the installment field Amount Open (
cpm__Amount_Open__c) depends on the related Payment records. Take care to populate the control fields (Payment Method, Processor, Target, Payment Profile and mandate) with the correct values. Incorrect values in the control fields have no direct impact on the operation of FinDock, but might impact reporting. Also make sure to use API values for picklists and not the translated values.
The Transaction Sets and Transactions are not usually migrated, but can be migrated if there is comparable source data. Take care to set the status of the transactions to a Matched or Manually Matched status, and make sure the payments created from those bank transactions are correctly linked to their relevant transaction records. If done incorrectly, this might have severe impact on reporting and financial exports to bookkeeping software.