CAMT file processing
CAMT, from the term Cash Management, is a set of standard messages defined in the ISO 20022 standard, the so-called ‘universal financial industry message scheme.’ The CAMT scheme is used for Bank-to-Customer Cash Management reporting.
There are different CAMT messages for different report types. For example, camt.053 is a detailed statement listing all entries booked on a bank account at a given point in time. The camt.054 debit and/or credit notification providing information about single or multiple debit/credit entries on an account. All CAMT messages are built using the same structure.
When you upload a CAMT file for reconciliation, FinDock transforms the CAMT file content into Salesforce data as illustrated below.
The transaction records in Salesforce contain information from both the Entry and the EntryDetails element. In most camt.053 cases, the relationship between these two elements in the camt report is one-to-one. But technically this relationship can be:
- One-to-none (1-0)
- One-to-one (1-1)
- One-to-many (1-n)
To handle all three relationships, we add two fields to the Transaction object in Salesforce:
- Entry Type (
cpm__entry_type__c): picklist field with ‘entry’ or ‘entry detail’ as possible values
- Primary (
cpm__primary__c): boolean field that by default is set to false
One-to-none (1-0) processing
One-to-none relationships mean there is one Entry, but no EntryDetails. This can be encountered, for example, if the entry represents totals of one direct debit batch. In 1-0 processing, we create one transaction record per entry. The Entry Type picklist is set to ‘Entry’ and the Primary field to ‘true.’
One-to-one (1-1) processing
In one-to-one relationships, there is one Entry with one EntryDetails element. This can be encountered, for example, if the entry is for a wire transfer. In 1-1 processing, we create one transaction record per entry. The Entry Type picklist field is set to ‘Entry Detail’ and the Primary field to ‘true.’
One-to-many (1-n) processing
In one-to-many relationships, there are two or more EntryDetails elements for the Entry. This can be encountered, for example, if the entry represents information with the totals of one direct debit batch, and the specific direct debit transactions of that batch are reported in EntryDetails elements. In 1-n processing, we create one transaction record per EntryDetails element. The Entry Type picklist field is set to ‘Entry Detail’ and the Primary field to ‘false’.
Only the first transaction of the reported transactions has the Primary field set to ‘true.’ All others are set to ‘false.’ Every transaction contains information both from the Entry and the EntryDetails element. For the group of transactions belonging to the same Entry, the Entry information is the same for all transaction records, but the information from the EntryDetails element is unique.