Friday, July 17, 2026
2 changes · 18.0
Enhancements to existing features
This PR introduces an improvement to the account and l10n_latam_check modules that allows for multiple liquidity lines (one per check) to be recorded in a single journal entry. Currently, a split journal entry is created for each liquidity line, which presents several disadvantages: - Incorrect computation of payment and invoice states - Simplified workflow: By using a single journal entry for all liquidity lines, the workflow is significantly simplified and accounting complexity is redu
Original PR description
This PR introduces an improvement to the account and l10n_latam_check modules that allows for multiple liquidity lines (one per check) to be recorded in a single journal entry. Currently, a split…
This PR introduces an improvement to the account and l10n_latam_check modules that allows for multiple liquidity lines (one per check) to be recorded in a single journal entry. Currently, a split journal entry is created for each liquidity line, which presents several disadvantages:
- Incorrect computation of payment and invoice states
- Simplified workflow: By using a single journal entry for all liquidity lines, the workflow is significantly simplified and accounting complexity is reduced.
- First step towards a refactor: This improvement is a first step towards a broader refactor that will allow adapting the own check flow in payment registration without the need to create journal entries.
Changes made:
- Enhanced _synchronize_to_moves() method: - Allows for the creation and update of multiple liquidity lines within a single journal entry. - Removes excess liquidity lines if _prepare_move_line_default_vals() returns fewer lines than currently exist. - Account type-based counterparty identification: Replaces the previous position-based identification with an approach based on account types. - The starting index for extra line values is now dynamic, determined by the number of liquidity lines
- Removed _l10n_latam_check_split_move method:
- This method is no longer necessary given the new implementation that supports multiple liquidity lines in a single journal entry.
- Modified _prepare_move_line_default_vals() method: - Now returns one liquidity line for each registered own check, simplifying the generation of journal entries.
- Preserved _l10n_latam_check_unlink_split_move() method:
- Maintained for backward compatibility purposes, allowing payments containing split moves to be set to draft status.
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe Nilvera client returns base64-encoded PDF content from the GET pdf endpoint. A previous change https://github.com/odoo-dev/odoo/commit/d2c2dc0bc33c369369ba748a513fad0c6edcaf6a incorrectly stored this base64 string directly into the `ir.attachment.raw` field without decoding. Because the field is binary, the base64 ASCII text was UTF-8 encoded on the disk, leaving the files unreadable in browsers. This commit introduces a migration script to fix this. For newly downloaded attachment
Original PR description
The Nilvera client returns base64-encoded PDF content from the GET pdf endpoint. A previous change https://github.com/odoo-dev/odoo/commit/d2c2dc0bc33c369369ba748a513fad0c6edcaf6a incorrectly stored this base64 string directly into the `ir.attachment.raw` field without decoding. Because the field is binary, the base64 ASCII text was UTF-8 encoded on the disk, leaving the files unreadable in browsers. This commit introduces a migration script to fix this. For newly downloaded attachments, 35fd6ce handles the decoding. task-6377121 Forward-Port-Of: odoo/odoo#275376