Saturday, February 10, 2024
4 changes · 17.0
Resolved issues and error corrections
This fix resolves an issue where some banks were rejecting payment XML files generated by Odoo for SEPA transfers. The system now includes a required payment service level code (NURG) in the payment files, which indicates the payment is non-urgent. This ensures better compatibility with banking systems and prevents payment processing failures.
Original PR description
We used to skip the SvcLvl node on generic ISO20022 payments. This caused some banks to reject the XML file generated for them (though this node is not supposed to be mandatory). We now always set in on them, with the default NURG code, indicating that the payment is non-urgent. OPW 3679650 Forward-Port-Of: odoo/enterprise#55451 Forward-Port-Of: odoo/enterprise#55038
This update upgrades the o_spreadsheet library to the latest version 17.0.11, which includes bug fixes and improvements to spreadsheet functionality. The changes ensure that spreadsheet features in documents and related modules work reliably with the most current library version.
This fix corrects an issue where asset depreciation schedules were being incorrectly calculated when a company's fiscal year ends on December 30th. The system was mistakenly treating this date like February 28th and shifting it to December 31st, causing depreciation entries to be created on the wrong date. This ensures accurate financial reporting for companies with non-standard fiscal year end dates.
Original PR description
To reproduce: - Put your fiscal year to the 30th of December (yes it's unlikely) - Create an asset - Compute depreciations => they are created for the 31th of December It comes from the `get_fiscal_year` in `date_utils` which considers it as the case of the 28th of February opw-3704466 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-pr Forward-Port-Of: odoo/odoo#152710
This fix addresses a bug where context settings used to prevent recursive operations were not being properly cleaned up, potentially causing them to persist in newly created environments. The fix ensures that context keys are removed from all environments created within the recursion prevention manager, preventing unintended feature disabling that could cause operations to be skipped.
Original PR description
It is possible to have context keys being leaked from outside the context manager in the following case: * a new transaction starts with a new environment * the code calls `_disable_recursion` * all the existing environment are modified with the context key * inside of the context manager, a new environment is created without specifying a full context: we keep the previous one, which contains the context key * the code exits the context manager and cleans all the environment it was aware of <-- this is the issue * the environment that was created inside the context manager still contains the context key, if it is used and is never cleaned. Now, we also remove the context key of all the environments created inside the context manager. It is better to risk having some recursion (probably leading to operations being done multiple times) than doing nothing at all because the context disables some features. Forward-Port-Of: odoo/odoo#146336