Friday, March 1, 2024
1 change · master
New functionality added to Odoo
Adds support for Canadian CPA 005 electronic payment files so businesses can submit batch vendor payments to participating banks. The feature includes configurable bank file numbering, payment validations, and guidance to reduce rejected files and manual troubleshooting.
Original PR description
This implements Canadian Payment Association Standard 005 (CPA005) Electronic Fund Transfer (EFT) files. They allow users to easily submit batch vendor payments to their bank. This feature is similar…
This implements Canadian Payment Association Standard 005 (CPA005) Electronic Fund Transfer (EFT) files. They allow users to easily submit batch vendor payments to their bank. This feature is similar to l10n_us_payment_nacha, which implements a similar file format for the US.
CPA005 files consist of logical records with a fixed length [1]. A logical record corresponds to a line in the file and has a type, denoted by a letter. For our purposes we only support 3 types: header ("A"), deposit data ("C") and footer ("Z").
The header record contains metadata about the batch payment, which includes the currency. CPA005 allows one file to have either CAD or USD payments, but not both. Of interest here is the the File Creation Number (FCN). This is the 4 digit identifier of the file. We made defining this field as flexible as possible because different banks have different requirements. We know of at least the following requirements made by different banks:
- FCN must be different from the previous 9 FCNs submitted [4],
- FCN must be TEST for test files [4],
- Subsequent FCNs should increment by 1 [5][6],
Because of these differences the FCN is overridable on the batch payment (for e.g. specifying TEST). When not overridden, numbers are generated based on a sequence linked to the journal so the step can be adjusted to match what the bank requests.
To adhere to industry standards we deviate from the official specification in two ways. First of all, we don't encode the files in EBCDIC [2], instead we use the standard UTF-8 encoding. Secondly, we only add one payment per "C" record. The format allows for up to 6 payments in the same "C" record [3], but this seems uncommon nowadays.
From our experience with NACHA we know that banks don't always provide good errors to customers. To minimize trial and error we provide as much help as we can to users with tooltips and validations.
Contrary to NACHA, no good validators exist. This implementation has been tested in two ways. The output was compared to the output of known good software, and generated files were tested in production with a real bank (CIBC).
[1] https://www.payments.ca/sites/default/files/standard005eng.pdf
[2] p6 in [1]
[3] p13 in [1]
[4] p6 in https://www.rbcroyalbank.com/ach/file-451770.pdf
[5] https://help.treasurysoftware.com/hc/en-us/articles/360046359093-TD-Toronto-Dominion-80-byte-and-1464-byte-EFT-file-formats
[6] p129 in https://www.atb.com/siteassets/pdf/resources/support/atb-business/atb-business-eft-user-guide-0422.pdf
task-3639094