Daily updates from Odoo
Tuesday, June 2, 2026
13 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 resolves a potential error in the Hong Kong payroll calculations. Specifically, it now checks for scenarios where a resource calendar is missing or weekly hours are zero, preventing a division-by-zero error that could have disrupted payroll processing. This ensures accurate and reliable payroll calculations.
Original PR description
. Add a check for a null resource calendar and zero hours per week. task-6229271
This update corrects a setting that automatically generated CFDI invoices for all website sales orders. Previously, customer information provided on the e-commerce platform triggered this automatic CFDI generation, which was unnecessary. Now, invoices are only CFDI to public when explicitly required.
Original PR description
There is no reason why we would always cfdi to public when creating orders from the e-commerce. When the customer give all their info, the invoice should not be cfdi to public. opw-6180766
This update resolves a bug in the appointment scheduling system that caused incorrect interval inversions, particularly with edge cases. The fix ensures accurate interval calculations, improving the reliability of appointment scheduling and preventing potential scheduling errors. New tests have been added to verify this correction.
Original PR description
The [commit](https://github.com/odoo/enterprise/commit/53450065be0c3ec9d648d4fd39ec3a9a912bd06c) introduced the method for inverting the interval inside the given limits. The method was failing for the following edge cases: ```python >>> invert_intervals([(1, 2), (4, 5)], 0, 10) result - [(2, 4), (5, 10)] expected - [(0, 1), (2, 4), (5, 10)]? >>> invert_intervals([(-2, -1)], 0, 10) result - [(0, 10)] expected - same >>> invert_intervals([(11, 12)], 0, 10) result - [] expected - [(0, 10)] >>> invert_intervals([(-1, 1), (2, 5), (8, 12)], 0, 10) result - [(1, 2), (5, 8)] expected - same >>> invert_intervals([(2, 5), (8, 12)], 0, 10) result - [(5, 8)] expected - [(0, 2), (5, 8)] >>> invert_intervals([(2, 5), (11, 12)], 0, 10) result - [] expected - [(0, 2), (5, 10)] ``` This commit fixes the function to correctly handle all the cases. The test cases are also added to test all the edge cases.
This 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 fixes an issue where the 'Out of Office until...' date displayed in the Discuss chat was incorrect for users in negative timezones. The fix adds a timezone setting to ensure dates are consistently displayed in UTC, resolving the date display problem. This ensures accurate leave information is shown to all employees.
Original PR description
Issue: ---------------------------------------- When in a negative timezone, the "Out of Office until..." text in discuss shows the day before. Steps to reproduce:…
Issue: ---------------------------------------- When in a negative timezone, the "Out of Office until..." text in discuss shows the day before. Steps to reproduce: ---------------------------------------- - Change the timezone of the user to "America/Toronto" for example - Have an employee currently on leave until tomorrow - Open discuss to chat with this employee - The "Out of Office until..." shows today's date Cause: ---------------------------------------- When calling `toLocaleString()` without a timezone specified in the options, the date is converted to local time (in the browser's timezone). Here `persona.out_of_office_date_end` is just a date, `deserializeDateTime()` converts it to a timestamp, so the same day at 0am. Then if the timezone is negative, the timestamp becomes an hour the previous day when calling `toLocaleString()`. The format we give `DateTime.DATE_MED` doesn't include hours, so we just display the previous date. Solution: ---------------------------------------- Add `timeZone:"UTC"` in the options to avoid the timezone conversion. opw-6252040
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