Friday, March 1, 2024
3 changes
1 change
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-36390942 changes
Resolved issues and error corrections
This fix corrects a critical issue where UPS return labels were being generated with reversed addresses—showing the customer as the receiver and seller as the sender, when it should be the opposite. Return labels are used to ship items back from customers to sellers, so the addresses must be correct for the return process to work properly.
Original PR description
Steps to reproduce: 1. set up a shipping method with UPS rest module 2. enable "generate return label" on the shipping method 3. make a shipping and validate it A return label will be generated that has the customer's address as the receiver and the seller's address as the sender. This is conceptually wrong as the return label will be used to ship from the customer to the seller. This commit uses the correct addresses when generating labels. Also the name of the arguments are added when calling `_send_shipping` method for better readability. opw-3756731 Forward-Port-Of: odoo/enterprise#57477 Forward-Port-Of: odoo/enterprise#57037
A bug in the Mexican localization module prevented users from creating new accounts in the chart of accounts. The fix adds a missing technical decorator to the account creation method, restoring the ability to add accounts when the Mexican localization is installed.
Original PR description
Currently, if you install the Mexican localization, you are no longer able to create a new account in the chart of accounts. ### Steps to reproduce * install `l10n_mx` * attempt to create a new…
Currently, if you install the Mexican localization, you are no longer able to create a new account in the chart of accounts. ### Steps to reproduce * install `l10n_mx` * attempt to create a new account in the chart of accounts You should be met with a traceback: `TypeError: AccountAccount.create() missing 1 required positional argument: 'vals_list'` ### Cause The `@api.model` and `@api.model_create_multi` decorators in indicate that a method is intended to operate at the model level rather than on specific record instances. Without these decorators, the system defaults to treating methods as if they are meant to be executed on the record level. This distinction significantly impacts how methods are invoked through RPC. In RPC scenarios, Odoo's default expectation for record-level methods is that the RPC call will include the IDs of the records to which the method applies, alongside any actual method arguments necessary for the operation. Here, `create()` is called through RPC, as a model-level method (i.e, without record IDs). This makes sense because `create()` is always a model-level method. However, in our case, create is a record-level method, so the system expects the RPC call to contain record IDs. This mismatch produces a traceback. Issue introduced by 858bf9efdd9fcc29a73336863a51227c15cc19f0 opw-3772520 opw-3772469 opw-3772287 opw-3771854 opw-3771361 Forward-Port-Of: odoo/odoo#155848