Tuesday, June 2, 2026
9 changes · 17.0
Resolved issues and error corrections
This update addresses a requirement from the Peruvian tax authority (SUNAT) regarding delivery guides. Customers using the l10n_pe_edi_stock module now need to include a 'carrier handover date' field, which was previously causing validation errors. The update automatically handles this by reusing existing data and provides a helpful message to users on older module versions to update.
Original PR description
SUNAT R. S. N° 000108-2026/SUNAT and the GRE validation rules published on 2026-06-01 add field 34 "Fecha de entrega de bienes al transportista" (cac:LoadingTransportEvent/cbc:OccurrenceDate). It is required, and rejected with error 3617 when absent, only when the transport modality is '01' (public transport). Enforcement started 2026-06-01, so affected customers can no longer submit their delivery guides.
In our implementation the departure start date is equivalent to this date, so we reuse it instead of adding a new field. The node is gated to public transport to match the validation rule and avoid emitting it on private transport ('02') guides.
Because the new node only ships with this module version, customers on an older version keep hitting error 3617 from SUNAT. Detect that code in the SUNAT response and store an actionable message asking the user to update the module, instead of surfacing the raw rejection.
task-6266662This update resolves a requirement from Luxembourg auditors regarding the classification of partners in SAFT reports. Specifically, it ensures less than 30% of transactions with payable or receivable accounts have missing supplier or customer IDs, aligning with Luxembourg's FAIA reporting standards. The change updates XML reports to accurately reflect partner classifications.
Original PR description
This PR is one of many triggered by responses from Luxembourg auditors. See PR #113316 for a full list of these PRs. As described in PR #117799, the \CustomerID and \SupplierID elements on…
This PR is one of many triggered by responses from Luxembourg auditors. See PR #113316 for a full list of these PRs. As described in PR #117799, the \CustomerID and \SupplierID elements on \Transaction\Line elements is determined by a partner's `customer_rank` and `supplier_rank`. This is a binary designation, one or the other. The Luxembourg FAIA report requires that less than 30% of \Transaction\Line elements with payable accounts (class 6) can not have \SupplierID. The same applies for \Transaction\Line elements with receivable accounts (class 7) and the \CustomerID element. TSB clarified that any partner on an receivable or payable line should be added to the Customer list or Supplier list respectively https://github.com/odoo/enterprise/pull/100749#issuecomment-3655127511. In addition, I verified that Luxembourg's analysis of four separate FAIA files (from ticket 5427296) aligns with this expectation. <img width="1322" height="690" alt="image" src="https://github.com/user-attachments/assets/1a82f99e-5b32-4dbb-96e1-1b25bab2629b" /> This commit adds partners to the \Supplier and \Customer lists if they have any payable or receivable lines, respectively. It also picks between the \CustomerID and \SupplierID based on a line's `account_type`. This logic is applied to `account_saft` and updates the other, country-specific SAFT reports where appropriate. It also retains the previous `customer_rank` and `supplier_rank` logic as a fallback for older XML reports and for accounts other than `asset_receivable` or `liability_payable`. opw-6118024
This update fixes an issue where the ICP export generated inconsistent XML reports by potentially mixing data from different company contexts. The change ensures a single, consistent company context is used for identifier values, improving the accuracy and reliability of the exported data for Dutch reporting requirements. This resolves potential confusion and ensures data integrity.
Original PR description
Description of the issue this commit addresses: The ICP export could mix values from different company contexts. In some cases, the main identifier and the fiscal entity division value did not come from the same source, which could create confusing or inconsistent XML output. --- Desired behavior after this commit is merged: This commit makes the ICP export use one consistent company context for identifier values, reuses precomputed values when available, and avoids overwriting them with unrelated defaults. --- task-6065382 Forward-Port-Of: odoo/enterprise#112995
This update resolves an access error that occurred when setting up Argentinian companies with branch companies, specifically when archiving a branch. The fix ensures that archived companies are no longer included in access validation, preventing errors and improving data loading for these configurations.
Original PR description
***Steps to reproduce*:** - Create an Argentinian company and create a branch company under the same company. - Set the same Tax ID for both the main and branch company. - Archive the branch company.…
***Steps to reproduce*:**
- Create an Argentinian company and create a branch company under the same company.
- Set the same Tax ID for both the main and branch company.
- Archive the branch company.
- Go to Settings -> Accounting.
- Select any Argentinian Fiscal Localization for the main company.
***Observed behavior*:**
- An access error is raised: `Access to unauthorized or invalid companies.`
***Cause*:**
- In `_get_branches_with_same_vat`, the following logic: `current.root_id._accessible_branches()` and `self.env['res.company'].sudo(). search([('id', 'child_of', current.root_id.ids)])` was also including archived branch companies.
- These archived companies were later involved in access and company validation flows, causing the access error.
- The same issue also affected demo data loading for such company setups.
***Fix*:**
- Add a filter to include only active companies and branches while fetching related companies.
- This prevents archived branch companies from being included in the validation flow.
- Also fixes the issue preventing demo data from loading correctly for these company configurations.
Related Community PR :- [odoo/community](https://github.com/odoo/odoo/pull/266321)
opw-6197313This update fixes a problem where Fedex labels were missing a crucial reference field (REF) needed for accurate shipping. The change ensures the 'REF' field is populated correctly when creating Fedex labels for stock transfers, aligning with API documentation and preventing potential shipping issues. This ensures proper tracking and delivery confirmation.
Original PR description
Backport of bb4f8bf Original PR #116870 Forward-Port-Of: odoo/enterprise#117873
This update corrects a calculation error in the executive summary report, specifically related to the period length. Previously, the report was incorrectly calculating the number of days between dates, leading to inaccurate metrics like Average Debtor Days. This fix ensures the report accurately reflects the actual period length, improving the reliability of key business insights.
Original PR description
`_report_custom_engine_executive_summary_ndays` returned `date_to - date_from`, which is the gap between the two dates, not the count of days they span. For example April 2026-04-01 to 2026-04-30 will returned 29 instead of 30, making Average Debtor Days incorrect. Add +1 so the day count is inclusive of both endpoints, matching the rest of the report's date handling. opw-6215362
This update corrects a bug in the MTO purchase order process where changing the quantity of a Purchase Order Line (POL) led to incorrect receipt quantity updates. Specifically, modifying the POL quantity resulted in the receipt quantity being incorrectly inflated. This fix ensures accurate quantity tracking during MTO purchases.
Original PR description
### Steps to reproduce: - In the settings enable: Multi-Steps Routes - Inventory > Configuration > Warehouse Management > Routes - Unarchive MTO - Create a storable product P with MTO buy and a set…
### Steps to reproduce: - In the settings enable: Multi-Steps Routes - Inventory > Configuration > Warehouse Management > Routes - Unarchive MTO - Create a storable product P with MTO buy and a set vendor - Create and confirm a sale order for 1 unit of P - Confirm the assocaited PO and change the pol quantity from 1 to 10 > the associated receipt is updated from 1 to 10 - Change the pol quantity from 10 to 7 #### > The quantity on the receipt is updated from 10 to 16. ### Cause of the issue: Changing the quantity of the POL will adapt the picking related quantity via these lines: https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L115-L117 https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L342-L349 by creating new stock moves to be merged: https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L220-L251 Now, the issue is that this flows relies both on a negative `qty_to_attach` of `1 - 10 = -9` and a positive `qty_to_push` of `7 - 1 = 6`. However, the `qty_to_attach` is only used if is positive: https://github.com/odoo/odoo/blob/3bf89b4f467390807c20f7b007a875a77542e76f/addons/purchase_stock/models/purchase_order_line.py#L243-L251 The receipt is therefore updated by a `+6` move to push but not by the `-9` move to attach. Leading to a 10 -> 16 rather than 10 -> 7 result. opw-6218307 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes inaccuracies in the XML invoices generated for Spanish VAT (EDI) reporting. Specifically, it ensures tax calculations are accurate by grouping taxes by type and enabling rounding for invoice-level tax data. This resolves a previous bug and aligns with existing development, ensuring compliance with Spanish tax regulations.
Original PR description
Adjusting invoice-level <TaxesOutputs> nodes to be generated per tax rather than per line Enabling rounding for invoice-level tax data aggregation Adding a second rounding test derived from bug ticket Backport of odoo-253305 task-6009108 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem preventing demo data from loading correctly for Argentinian companies with branch offices using the same Tax ID. The fix ensures proper chart of accounts application and avoids data loading errors, improving the demo experience for Argentinian users. A new test case has been added to prevent future regressions.
Original PR description
***Steps to reproduce*:** - Create an Argentinian company and create a branch company under the same company. - Set the same Tax ID for both the main and branch company. - Archive the branch company. - Go to Settings -> Accounting. - Select any Argentinian Fiscal Localization for the main company. ***Fix*:** - This PR is related to the enterprise version fix from [odoo/enterprise](https://github.com/odoo/enterprise/pull/118307) - Fix the issue preventing demo data from loading correctly for this company configuration. - Add a test case covering the main reported issue to avoid regressions. opw-6197313