We had the requirement to generate credit transfer payment files in Microsoft Dynamics 365 for Finance and Operation including SEPA and ESR payments for a implementation based in Switzerland. The problem with the solution provided in the standard application is that you are not able to use one vendor bank account for both SEPA and ESR payments. In addition to that the ESR-ID in the payment file is picked from another field from vendor bank account as the user would expect: The standard takes the value for tag CdtrAcct-Id-Othr-Id from field VendBankAccount.AccountNum but we and our users would expect the field VendBankAccount.BankContractAccount to be used for the payment file.
To get the above described requirement working we had to change the ER configuration for “ISO20022 Credit transfer (CH)”. Before we started we found the following high level instruction to change ER configurations:
“…please derive: model, model mapping, format (setting your derived model in creation dialog). Then add a new field to the data model you crated and map it through relation – then you can use it in the format mapping”. What this instruction mean I want to describe in the following step-by-step guide.
Before you start to work with ER you should check the “Migration cleanup” (Organization administration > Periodic > Migration cleanup) form to avoid errors during development and usage of ER. You will see records in this form e. g. when you restored a database from another environment and the links to azure blob storage are broken.
Another prerequisite step is to import the ER configuration for “ISO20022 Credit transfer (CH)” from LCS or (local) resources. In my case I used (local) resources because I´m working on a local/downloaded OneBox environment where I´m not able to connect to LCS.
The last prerequisite step is that you have to have one active configuration provider as you can see in the following picture:
The first step of the customization is to create a new derived data model from payment model. To create a derived data model you have to set the values in the creation dialog as shown in the picture below.
After the model was successfully created we add a new field with name GwsBankContractAccount, to store the value from BankAccountTable.BankContractAccount, as shown below.
The next step is to map the field BankAccountTable.BankContractAccount to the previous created field. This step has to be done in the model mapping “CT mapping Copy”. For better understanding I would recommend to rename the model mapping to e. g. “CT mapping (SEPA/ER)”, but this is only a cosmetical change. A mandatory step is the mapping which you can see in the next screenshot, where we map the value @.’vendBankAccountInTransactionCompany()’.BankContractAccount to the field GwsBankContractAccount.
To complete the derived data model and model mapping, we have to set the state of the model to completed, to use it in one of the next steps.
The last step of the customization is to create a new derived configuration from “ISO20022 Credit transfer (CH)”. After the configuration was successfully created we have to change/set the following properties as also shown below:
— Enabled CdtrAcct-Id-IBAN = AND(@.CreditorAccount.Identification.IBAN <> “”, @.PaymentIdentifications.PaymentId = “”)
— Enabled CdtrAgt-FinInstnId-BIC = AND(‘$PaymentByDebtor’.lines.CreditorAgent.BICFI<>””, CASE(‘$PaymentByDebtor’.lines.PaymentType.PaymentSpecification, “Tp22.ISR2SPS”, false, true), ‘$PaymentByDebtor’.lines.PaymentIdentifications.PaymentId=””)
— Enabled CdtrAcct-Id-Othr = AND(@.PaymentIdentifications.PaymentId <> “”, @.CreditorAccount.Identification.GwsBankContractAccount <> “”)
— Mapping CdtrAcct-Id-Othr-Id = @.CreditorAccount.Identification.GwsBankContractAccount
Now we are ready to set the state of the derived configuration to complete and link the confirmation to a method of payment, to use it during payment file generation.