Migrating AvtaleGiro Agreements

In addition to the general payment data migration guidance, special steps need to be taken when migrating AvtaleGiro agreements.

To ensure uniqueness, please plan the migration process with extra care and precision. Incorrect data migration could lead to customers being charged erroneously.

Typically agreement migration follows four phases:

1. Define reserved blocks of customer IDs FinDock cannot use for new agreements.
2. Map specific customer data to the correct fields on FinDock and Salesforce objects.
3. Migrate data (after a test run).
4. Confirm that the reserved blocks are complete.

Configure reserved blocks

If you don’t provide a Customer ID on inserting a contact, FinDock assigns Customer IDs based on incrementing values that work across different objects. We highly recommend you only insert customer IDs for migration and not afterwards. This is to ensure Customer IDs remain unique.

To help migrate existing Customer IDs while ensuring uniqueness for future Customer IDs, you can define specific blocks of values for migration. Reserved blocks tell FinDock to not assign Customer ID values in these number ranges. FinDock skips over them when assigning new Customer IDs.

IMPORTANT

You must configure the reserved blocks before you start migrating any data.

To define reserved blocks:

1. Go to the org Custom Settings and select KID Number Range Reservation.
2. Click Manage to add new ranges.
3. Add the ranges that FinDock should not use.
4. For each range, provide a descriptive name and the start-end numbers of the range. Ranges must not overlap.

If the numbers do not conform to the prescribed Customer ID length in your FinDock setup (as defined by the AvtaleGiro contract with your bank), FinDock automatically pads the number to conform to your configured KID Customer ID length. For example, if you start with number 1 and your Customer ID length is six digits, FinDock changes the value to 000001.

Unify KID formats

FinDock supports one KID format, defined as part of the payment extension configuration. If existing payers (contacts) have more than one KID format, they need to change to the KID format used by FinDock before you can migrate their data to FinDock.

The change process is managed by MPS as described at the MPS KID change.

For existing KIDs that fit your desired format, the KID components need to be migrated to FinDock according to the mapping as indicated in above.

Define a specific starting number (optional)

If you want FinDock to start assigning Customer ID values from a specific number, you can do so by changing the CustomerID record in the KID Number Provisioning custom setting.

Follow FinDock mapping

The table below outlines the expected mapping between KID components and FinDock objects. The mappings to Mandate are required.

KID component	Object	Field	Example
Customer Number	Account or Contact	Customer ID (npff__Customer_ID__c)	12345678 (NOT required)
Payment Type	Mandate	Payment Type (npff__Payment_Type__c)	01
Customer Number	Mandate	Customer ID (npff__Customer_ID__c)	12345678
Customer Reference	Mandate	Custom Reference (cpm__Custom_Reference__c)	12345678
Full KID	Installment	Final Payment Reference (cpm__Final_Payment_Reference__c)	1234567800001 (NOT required unless the agreement still has payments to collect)
Full KID	Mandate	KID (npff_KID_c)	1234567812341