Thursday, June 12, 2025
6 changes · saas-18.3
Enhancements to existing features
This update adds support for the paper-muncher layout option in accounting report PDF exports. It helps ensure exported reports can use the intended paper formatting, improving consistency for printed or shared financial documents.
Original PR description
See https://github.com/odoo/odoo/pull/211226
Bank reconciliation now better identifies matching invoice payments by checking payment memos against bank statement labels, invoice references, partner, and amount. This reduces manual matching work and helps payments involving one or multiple invoices reconcile more accurately.
Original PR description
With this PR, we enhance the reconciliation logic by adding a check to match the payment memo against the bank statement line label. If a part of the memo is found exactly in the label and only one such match exists, the system proceeds to reconcile it based on a second matching criterion such as amount and/or partner.
Resolved issues and error corrections
This fix ensures Brazilian tax IDs are sent in the format Avatax expects when creating accounts, preventing setup failures caused by automatic formatting changes. Electronic invoice and point-of-sale tax integrations continue using the compact format required for their API calls.
Original PR description
Since [^1] VAT values are automatically compacted to the smallest form without any dots and dashes. For account creation in Avatax we must uncompress the VAT before sending to the API. Funny enough, Avatax requires compacted values for EDI api calls, as such the compression code will be removed in master. task-4817278 [^1]: https://github.com/odoo/odoo/pull/179078
Emission factors no longer need to be tied to a specific company, making it easier to use shared factor databases across multi-company setups. This prevents duplicate imports and reduces confusion when sources appear to have no linked factors because of company restrictions. The change applies to new databases or after an upgrade.
Original PR description
Having a mandatory company on factors comes with multiple problems. The main one is that users rely on factors imported from huge databases, that would therefore have to be imported once per company. The current dabatase model is incidentally built around factors being available in all companies, which means one cannot actually import the factors multiple times. Another is that users could see sources (which are not company dependent) that are seemingly linked to no factors because they are in other companies, which can be confusing. To alleviate those problems, this PR makes the field non required. Note that this will only take effect for new databases or after an upgrade.
Fixes an error that appeared when users opened the Details view for sales commissions. This restores access to commission breakdowns by removing a reference to outdated data that no longer exists.
Original PR description
When user clicks on Details in the commissions, A traceback will appear. Steps to reproduce the error: - Install ``sale_commission`` with demo data - Go to Sales > Commissions > My Commissions - Click on ``Details`` of any record Traceback: ``` UndefinedColumn: column "team_id" does not exist LINE 21: AND team_id in (1) ``` ``team_id`` field was removed in the commit: https://github.com/odoo/enterprise/commit/b1e41f9b23aa62bfd6f9be1feb1059b3507f2ce5 https://github.com/odoo/enterprise/blob/9d3a15d4d38fce8a2746778146c58123bc09178d/sale_commission/report/achievement_report.py#L341 Here, ``team_id`` field is still used. ``sale.commission.achievement`` model does not ``team_id`` field. So, It will lead to the above traceback. sentry-6378493886
Using a Sign template layout on a new document now keeps grouped radio button choices connected. This preserves the expected single-choice behavior for signers and prevents copied template fields from becoming unusable.
Original PR description
_____________________________________________________ ## Short functional explanation of the error Using the layout of a template document, containing radio buttons, on a new document will unlink…
_____________________________________________________ ## Short functional explanation of the error Using the layout of a template document, containing radio buttons, on a new document will unlink radio buttons, making them useless. ## Reproduction Steps 1. Go to the Sign module, and click on the Templates tab. 2. Click on the "Upload PDF" purple button, and upload a PDF of your choice. 3. On the left side of the screen, there's a panel where we can drag and drop sign items. Drag and drop a Radio button. 2 buttons will automatically show, and a yellow link will appear between the buttons. This link indicates that, when a user opens the document to sign, when clicking on a radio button, the other one will automatically be unselected if previously selected. 4. Save and return to the Templates window. 5. A new row has appeared with the name of the document. On the right side of this row, hover the house next to the share button and click on the 3 dots. Then, click on Use Layout. 6. Upload a PDF of your choice. 7. When the PDF shows, there's no yellow link between the radio buttons, unlike on the template from which the layout was used. ## Causes of the problem In the file sign/models/sign_document.py, in the method _copy_sign_items_to(self, new_document), we copy every sign item from the template to the new document. However, the copy method we call doesn't take into consideration the special link between radio buttons, replicating the buttons correctly but not the link. This link is expressed by the radio set to which the radio buttons belong: indeed, after the copy of sign items, each radio button belongs to a different radio set, separating them. ## Explanation of the fix The fix consists of a rework of the _copy_sign_items_to method and a brand-new method specifically used to copy radio buttons. To keep the link between them, we assign all the buttons of the same set on the original documents to the same brand new radio set. The first button is copied normally: this creates a new radio set. Then, for the remaining buttons, we call copy_radio_item, to which we pass the button created first to use the information the next buttons will share with it. ______________________________________________________________ opw-4842590 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr