Thursday, May 14, 2026
22 changes · saas-19.1
Resolved issues and error corrections
This update corrects a discrepancy in how ARCA-related invoices (document types 51-59) are displayed. The change ensures the documents align with current ARCA regulations by updating naming conventions and PDF headers. This ensures accurate reporting and compliance with Argentinian tax regulations.
Original PR description
**Context:** * ARCA (formerly AFIP) has deprecated the "Documentos M" classification for document types with codes 51-59. * These are now classified as "Documentos A con leyenda 'Operación sujeta a…
**Context:** * ARCA (formerly AFIP) has deprecated the "Documentos M" classification for document types with codes 51-59. * These are now classified as "Documentos A con leyenda 'Operación sujeta a retención'" while retaining the same codes for backward compatibility with ARCA validations. **Steps to Reproduce:** * Install `l10n_ar` module. * Go to `Accounting -> Configuration -> Document types`. **Observed behavior:** * Document types 51-59 still display letter "M" and use the old naming convention (e.g. "INVOICES M", "DEBIT MEMOS M"), which no longer reflects the current ARCA classification. **Fix:** * Updated `name` fields to include the "WITH LEGEND" / "CON LEYENDA" suffix. * Changed `l10n_ar_letter` from "M" to "A" so the PDF header renders an "A". * Changed `doc_code_prefix` from `*-M` to `*-A` (FA-A, ND-A, NC-A, RE-A). * The existing `res.config.settings` option for injecting the PDF legend remains untouched. Sources: - ARCA: https://www.afip.gob.ar/facturacion/regimen-general/comprobantes.asp Ref: https://www.odoo.com/mail/message/1025488740 opw-5953504 Forward-Port-Of: odoo/odoo#254975
This update resolves an issue that prevented invoices with combo products lacking taxes from being correctly processed when generating Peru UBL invoices. The fix corrects a validation error related to the 'grouping_key' field, ensuring these invoices can now be successfully submitted. This improves the reliability of invoice generation for users in Peru.
Original PR description
A traceback occurs when sending an invoice to Peru UBL if a combo product invoice line does not have any taxes applied. Steps to reproduce the error: - Install ``l10n_pe_edi`` module with demo data -…
A traceback occurs when sending an invoice to Peru UBL if a combo product invoice line does not have any taxes applied. Steps to reproduce the error: - Install ``l10n_pe_edi`` module with demo data - Switch to PE Company - Create an invoice > Add a Office Combo product > unset the taxes > Confirm - Process now https://github.com/odoo/enterprise/blob/d7f71a68fbd5ff9c7cd52f96e1616671a6b8d77c/l10n_pe_edi/models/account_edi_xml_ubl_pe.py#L549-L552 Here, the ``grouping_key`` becomes ``None`` when no taxes are present on the invoice line. Normally, invoices without taxes are restricted at [1], but combo products are excluded from this validation at [2]. As a result, combo product lines without taxes bypass the restriction and trigger a traceback. [1]: https://github.com/odoo/enterprise/blob/d7f71a68fbd5ff9c7cd52f96e1616671a6b8d77c/l10n_pe_edi/models/account_edi_format.py#L928-L929 [2]: https://github.com/odoo/odoo/blob/42b8852df9b323984364c41a13cf27d19fbe04a7/addons/account/models/account_move_line.py#L3433-L3434 sentry-7430552834 Forward-Port-Of: odoo/enterprise#114798
A technical issue preventing background video previews was resolved. The commit removed a broken Vimeo video link from the website builder, preventing error messages and ensuring a smooth user experience when selecting background videos. This improves the usability of the website design tool.
Original PR description
Steps to reproduce: 1. Drop any snippet. 2. Click on the background video option. 3. Observe Traceback. The Vimeo video with ID `499761556` is no longer available, causing a traceback when opening the background video options. This commit removes the unavailable video from the preview list. task-6088772 Forward-Port-Of: odoo/odoo#264080 Forward-Port-Of: odoo/odoo#263555
This update fixes an issue where discount lines on invoices were incorrectly calculated in VAT reports. The previous method of using ABS() on negative values resulted in inflated report totals. The fix now correctly handles discount lines by simply flipping the sign of the account balance when it's negative, ensuring accurate reporting.
Original PR description
Step to reproduce: - install l10n_cz_reports_2025 and switch to cz company - create a invoice, with cz company ( as partner), of 100. - when adding products, add "Transaction code" (optional fields) to "Goods" - Add discount line, set to -10, add "Transaction code" in this line too. - confirm it Observation: - invoice is 90$ - open vies summary report for this year - value turn out to 110 Cause: - commit [1](https://github.com/odoo/enterprise/commit/892268c44b1bbc838a9f03ef36a079bfff625ca6) converts every balance to +ve and only negate it, in case of refund - in case of discount lines, price is -ve, ABS() turn it to +ve and value comes out to be wrong Fix: - instead of applying ABS() directly, we flip the signs only for out_* moves, in short when a account is credited, its balance is < 0 then we flip its sign opw- 5979262 Forward-Port-Of: odoo/enterprise#117038 Forward-Port-Of: odoo/enterprise#113087
This update fixes an issue where packaging unit information was hidden on delivery slips after a transfer was validated. Previously, users wouldn't see the packaging unit quantity on the report. Now, the delivery slip accurately reflects the packaging unit and its quantity, even after the transfer is validated, ensuring accurate reporting of stock movements.
Original PR description
Issue before this commit: ========================= For products tracked by serial/lot with packaging units, the delivery slip correctly shows the packaging unit and quantity before validating the…
Issue before this commit: ========================= For products tracked by serial/lot with packaging units, the delivery slip correctly shows the packaging unit and quantity before validating the transfer. However, after validating the transfer, the packaging unit and its corresponding quantity are no longer displayed in the delivery slip report. Steps to Reproduce: ========================= 1. Install stock and sale_management modules. 2. Enable Units of Measure & Packagings and Display Lots & Serial Numbers on Delivery Slips from settings. 3. Create a product with tracking by lot/serial number and configure a packaging unit. 4. Create a SO using this product with a packaging unit and confirm it. 5. Open the related transfer and print the delivery slip before and after validation. Cause of the Issue: ========================= The delivery slip report template (stock_report_delivery_has_serial_move_line) does not display packaging unit information after validation for move lines when the packaging unit differs from the product unit of measure. With This Commit: ========================= This commit ensures that packaging units and their corresponding quantities are displayed on the delivery slip after validation when the packaging unit differs from the product unit of measure. Steps To Reporduce: [Video Link](https://drive.google.com/file/d/10DmFKW1Y_Tm-AyKzPrqtFMY8orBkKbIm/view?usp=sharing) opw-6142052 Forward-Port-Of: odoo/odoo#262722
A test for the Point of Sale receipt generation process failed due to a generic selector used to identify the shipping date. This update adds a specific class to the shipping date element, ensuring the test accurately reflects the receipt format across different localization settings. This resolves a technical issue that could have impacted receipt accuracy.
Original PR description
Issue: ====== - The test used the selector `.pos-receipt-order-data div` to retrieve the shipping date. - This selector is not specific and matches different elements depending on localization. Fix: ==== - Add a specific class `shipping-date` to the shipping date element and update the test to use `.pos-receipt-order-data .shipping-date` to avoid incorrect matches. Task-6183114 Error-241995 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262761
This update fixes a minor error in the Norwegian tax settings. The tax code 32's rate was incorrectly set to 11.0. This change ensures accurate tax calculations for Norwegian businesses using Odoo, aligning with official tax regulations. This was coordinated with a related Enterprise PR.
Original PR description
The tax rate(`amount`) for code 32 was mistakenly set to '11.0'. To properly align with the official Norwegian tax rates, it needs to be updated to '11.11'. Related Enterprise PR: https://github.com/odoo/enterprise/pull/110792 task-6033027 Forward-Port-Of: odoo/odoo#264221 Forward-Port-Of: odoo/odoo#258390
This update corrects errors in the Norwegian VAT XML export that were preventing successful validation by the Skatteetaten (Norwegian tax authority). The changes ensure accurate decimal formatting, mathematical calculations, and required legal notes are included, allowing VAT returns to pass government scrutiny. This resolves a critical issue impacting accurate tax reporting.
Original PR description
Before commit: The Norwegian VAT XML export fails Skatteetaten validation due to incorrect decimal formatting, mathematical rounding mismatches between base and tax amounts, missing mandatory legal…
Before commit: The Norwegian VAT XML export fails Skatteetaten validation due to incorrect decimal formatting, mathematical rounding mismatches between base and tax amounts, missing mandatory legal notes, and invalid KID number formats. Fix: To strictly follow Skatteetaten validation rules for the Norway VAT XML, the following changes were implemented: - Ensured standard rates drop the decimal (e.g, `25.0` to `25`), and formatted fractional rates like `11.11` to `11,11` in XML. - Rounded down the `tax_amount` to align precisely with government mathematical expectations. - `base_amount` converted into absolute value to ensuring the calculation (`base * rate = tax`) resolves perfectly. - Add the mandatory `<merknad>` explaining the reverse charge method for codes 81, 83, 86, 88, and 91. - Clean the `company_kid` by safely stripping the 'NO' prefix, and 'MVA' suffix. Expect: The generated XML payload now adheres perfectly to Skatteetaten's strict structural and mathematical rules, allowing the VAT return to pass government validations successfully. Related Community PR: https://github.com/odoo/odoo/pull/258390 Task-6033027 Forward-Port-Of: odoo/enterprise#117168 Forward-Port-Of: odoo/enterprise#110792
This update ensures Odoo's audit trail feature remains active in India, aligning with Ministry of Corporate Affairs requirements. Previously, the audit trail could be disabled, but this change enforces its continuous maintenance to meet legal obligations. This ensures compliance and reduces potential risks for users in the Indian market.
Original PR description
After the refactor introduced in https://github.com/odoo/odoo/commit/f280f762b6417fa1a0b09649ffbdecafcc7e7579, The audit trail feature was split into two modes: a lightweight general-purpose mode and a force-restricted mode for specific localizations (e.g., Germany), where deactivation is not allowed once enabled. In India, as per the requirements of the Ministry of Corporate Affairs, the audit trail must be maintained and cannot be disabled once activated. This commit extends the force-restricted audit trail mode to the Indian localization (l10n_in) to ensure compliance with statutory requirements. task-6182002 Forward-Port-Of: odoo/odoo#262508
This update resolves an issue where Ctrl+A wouldn't select images with captions in the HTML editor. The fix ensures that the selection correctly targets the image itself, regardless of the surrounding caption structure, preventing a crash. This improves the user experience when working with images and captions.
Original PR description
#### Description of the issue this PR addresses: - When an image with caption is selected, it is wrapped in a `<figure>`, making `<figure>` the anchor node - `selectAll` was resolving the container using `[contenteditable]`, which keeps `<figure>` as the container even though it is `contenteditable=false` - This leads to `<figure>` being passed to `getDeepestEditablePosition`, which cannot resolve a valid `nodeLevelAncestor` and returns null, causing a traceback #### Desired behavior after PR is merged: - `selectAll` now targets the nearest `contenteditable=true` ancestor instead of any `[contenteditable]` #### Steps to reproduce: - Add image and enable caption - Select the image - Press Ctrl+A task-6174371 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261968
This update resolves a technical issue preventing the Journal Audit report from displaying correctly when the 'Load More Limit' is set to 1. The fix ensures accurate report generation by addressing a key error related to data formatting during report expansion.
Original PR description
Steps to reproduce: - Install `Accounting` module - Accounting > Configuration > Accounting Reports > Journal Report > Options > Set `Load More Limit` to 1 - Accounting > Review > Journal Audit >…
Steps to reproduce:
- Install `Accounting` module
- Accounting > Configuration > Accounting Reports > Journal Report > Options >
Set `Load More Limit` to 1
- Accounting > Review > Journal Audit > Expand Sales
Traceback: `KeyError: 'no_format'`
Cause:
This error occurs when we expand the lines. During the expansion, we [append] a `Load more...` pagination row inside the report lines. In that row, we pass empty [dictionaries] in`columns`, like: `columns': [{}, {}, {}, {}, {}, {}]`. and we have offset. So, after expanding, there are two lines, and the second one is the Load more line.
Because its [columns] contain empty dictionaries, the `no_format` key is not found, which results in a `KeyError`.
Solution:
We are passing a `None` value if `no_format` is not present in the line's columns.
[append]: https://github.com/odoo/enterprise/blob/34c60542d87366d50484c21bc0576bdc59517c5e/account_reports/models/account_report.py#L5765
[dictionaries]: https://github.com/odoo/enterprise/blob/34c60542d87366d50484c21bc0576bdc59517c5e/account_reports/models/account_report.py#L5867-L5878
[columns]: https://github.com/odoo/enterprise/blob/34c60542d87366d50484c21bc0576bdc59517c5e/account_reports/models/account_journal_report.py#L158
opw-6125082This update fixes a limitation in how Odoo handles attachments uploaded through cron jobs. Previously, a specific setting prevented multiple attachments from being uploaded in a single job. Now, allowing `--limit-time-real=0` or `--limit-time-real-cron=0` enables the upload of multiple attachments, improving efficiency for automated processes.
Original PR description
make the `limit_time_real > 0` when --limit-time-real-cron=0 --limit-time-real=0 to allow multiple attachments to be uploaded in a single cron job. 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#264328
This update fixes a potential issue where users could accidentally assign multiple POS shops to a single cash payment method, leading to errors. Now, the system prevents this, ensuring data integrity and preventing disruptions to the point-of-sale process. This change improves the reliability of payment processing.
Original PR description
**Before this commit** The user will be able to assign two different POS shop to a cash payment method by going to POS -> Configuration -> Payment Methods -> Cash -> Point of sale, this will not raise a validation error when they try to save it but it will prevent the user from opening the POS session. **After this commit** It will raise a validation error if a user tries to assign more than one POS shop to one cash payment method and save it. opw-6015025 Forward-Port-Of: odoo/odoo#252603
This update fixes an issue where UBL invoices could incorrectly apply taxes due to differences in fiscal positions. The change ensures that only taxes matching the invoice's fiscal position are used during import, leading to more accurate tax calculations and reporting. This improves the reliability of financial data imported from UBL invoices.
Original PR description
When importing a UBL invoice, multiple taxes may share the same rate (e.g. 21%) but differ by fiscal position. Without filtering, the wrong tax (e.g. the domestic one for a foreign partner) could be selected. task-6138749 Forward-Port-Of: odoo/odoo#263872
This update resolves a bug that caused invoices with specific customer address configurations to fail during the cash rounding process. The fix ensures the correct partner information is used, preventing errors and allowing invoices to be properly processed. This improves invoice accuracy and reliability.
Original PR description
When applying a cash rounding with 'biggest tax' strategy, it happens that we end up with a MissingError when the invoice's partner is not defined as commercial_partner_id. Steps: - Install…
When applying a cash rounding with 'biggest tax' strategy, it happens that we end up with a MissingError when the invoice's partner is not defined as commercial_partner_id. Steps: - Install membership module - Create a cash rounding with the 'biggest tax' strategy and 0.05 rounding - Enable customer addresses and create a partner P with an invoice address I - Create an invoice, select I as customer (P will be assigned as delivery address but this is not relevant) - Add an invoice line for 100.03 and any tax and apply the cash rounding - Confirm -> MissingError: record has been deleted Cause: - When creating the cash rounding lines, we set the `partner_id` from the invoice's partner (in our case partner I, which has P as `commercial_partner_id`). - When posting the invoice we look for lines that have partner id different than the invoice's commercial partner id and we call the write method to set the commercial partner id instead https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L5234-L5239 - In some cases, for example in the `membership` module, the override of the write method calls the super() before using `self`. https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/membership/models/account_move.py#L45-L49 But the super triggers the `_sync_tax_lines` mechanism, during which the rounding line in deleted https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_tax.py#L3102-L3110 https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L3113-L3114 Therefore `self` doesn't exist anymore when comming back in the override Fix: Setting the commercial partner on the rounding line to avoid calling the write method opw-6128868 Forward-Port-Of: odoo/odoo#262759
This update resolves an issue where users could create a circular dependency when attaching files to records, leading to errors. The fix prevents an attachment from being linked to itself in both the user interface and the backend, ensuring data integrity and stability.
Original PR description
Currently, users have the option to attach an ir.attachment to itself. This causes a recursion depth error when accessing attachments. This commit prevents this in the UI and the write. Firstly, the ir.attachment does not show itself in the dropdown when selecting the resource ID. Second, the write raises a UserError if attempting to write an ir.attachment with the same ID as the Resource ID. Steps to reproduce: 1. Create an attachment and save 2. Set the Resource Model `(res.model)` to "ir.attachment" 3. Select the same attachment in Resource ID `(res_id)` 4. Attempt to view attachments: `RecursionError: maximum recursion depth exceeded` opw-6206075 closes #263591 Forward-Port-Of: odoo/odoo#264439 Forward-Port-Of: odoo/odoo#263591
A test within the l10n_latam_check module failed due to a dependency on the l10n_ar localization module not being installed. This update ensures that the test runs correctly by requiring the l10n_ar module to be present, preventing a runtime error.
Original PR description
Steps to reproduce: 1- Install l10n_latam_check on a fresh database instance 2- Run the test `test_invoice_status_after_voided_check` Issue: `ValueError: External ID not found in the system: l10n_ar.dc_liq_uci_a` Why this happens: The test used a document type from the l10n_ar module, so running the test without it being installed caused an error. runbot-243341 Forward-Port-Of: odoo/odoo#262800
This update resolves a technical issue impacting invoice accuracy for Mexican VAT (SAT) compliance. Previously, invoices with many items could trigger validation errors due to rounding discrepancies when applying per-line discounts. This fix ensures invoices pass SAT validation and correctly calculate discounts, improving financial reporting.
Original PR description
…any lines Fix SAT validation errors CFDI40111 and CFDI40108 that occur when invoices with many lines contain a small negative line, causing per-line discounts to be hidden due to currency precision. opw-6187014 Forward-Port-Of: odoo/enterprise#117344 Forward-Port-Of: odoo/enterprise#117297
This update fixes an issue where completion and refusal emails for signatures were incorrectly sent using the signer's partner email instead of the designated email defined within the sign request. Now, emails are sent using the correct, validated email address, ensuring signers receive important notifications reliably. This improves communication and reduces potential errors.
Original PR description
Previously, completion and refusal emails were sent using the partner email directly, ignoring the computed email defined on the sign request item. The computed email includes validation rules and should be the main email for signer communication. This commit ensures that completion and refusal emails are sent using the computed signer email instead of the partner email. task-6148765 Forward-Port-Of: odoo/enterprise#114606
This update resolves a problem that occurred when creating consolidated invoices from multiple POS orders for the same customer. The fix ensures that all refund reason values are correctly collected and validated, preventing errors and maintaining data consistency. This improves the reliability of invoice generation for multi-order transactions.
Original PR description
When creating a consolidated POS invoice from multiple orders for the same customer, `_prepare_invoice_vals` is called on a multi-record set. Accessing `self.l10n_es_tbai_refund_reason` directly on such a set raised a ValueError because `fields.Selection.__get__` internally calls `ensure_one()`. Use `mapped()` to safely collect all distinct refund reason values across the recordset. Raise a UserError if orders have conflicting values, consistent with the existing TicketBAI validation pattern for mixed required/non-required orders. opw-6192225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262967
This update fixes an issue where large tablets with touch screens incorrectly displayed the mobile toolbar instead of the desktop version. The change now considers screen size alongside touch capability, ensuring the correct toolbar is shown on all devices. This improves the user experience for tablet users.
Original PR description
Problem: On large tablets with touch capability and high resolution, the mobile toolbar is displayed instead of the desktop toolbar. Cause: The mobile toolbar condition relied on touch capability alone, without considering screen size. Devices with large screens but touch support were therefore incorrectly treated as mobile. Solution: Use `utils.isSmall()` to determine whether the device should display the mobile toolbar, ensuring screen resolution is taken into account. Steps to reproduce: - Open the editor on a large tablet. - Observe that the mobile toolbar is shown. - The desktop toolbar should be displayed instead. task-6106531 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259605
This update resolves an issue where changing a text tag (like from H2 to H1) didn't properly remove the previous heading style. The fix ensures that selected text now correctly loses its original heading formatting, improving the consistency and accuracy of text editing within the Odoo website.
Original PR description
Problem: When applying `h1` to part of a selection already inside an `h2`, the selected content still keeps the `class="h2"` style. Cause: `removeFormats` internally uses `formatSelection`, but in this case we only want to change the tag and not reformat the selection. This causes existing heading styles to remain applied. Solution: Use `removeFormat` instead, as it removes formatting without applying additional formatting to the selection. Steps to reproduce: - Go to Website and drop the "Text-Image" snippet. - Copy the text "Enhance Your Experience". - Paste the text into a new To-Do. - Select part of the pasted text. - Change it from "Header 2" to "Header 1 Display 1". - Observe that part of the text still keeps the "Header 2" style. task-6204505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263810