Odoo Changelog — 2026-01-20

Tuesday, January 20, 2026

20 changes · 18.0

New Features(1)

New functionality added to Odoo

[ADD] l10n_au_hr_payroll_api: Australian Payroll API integration

Enterprise18.0l10n_au_hr_payrolll10n_au_hr_payroll_apiMEDIUM

This update introduces seamless integration with the Australian Taxation Office (ATO) for Single Touch Payroll (STP) submissions and superannuation contributions. It ensures compliance with Australian regulations by securely accessing the ATO's Super Choice API and implementing audit logging for tracking payroll changes.

Original PR description

This module adds single-touch payroll integrations with the ATO
using the Super Choice API. The IAP server is used in the middle
to ensure security and prevent unauthorised access to the ATO's
API.

It includes the following features:
- Employer registration for STP
- STP submission and retrieval of STP reports
- Super Choice API integration for super contributions

(Compliance Requirement)
Add audit logging for Australian Payroll. A mixin that logs the selected
field changes in the l10n_au.audit.log model. This is later synced to the
IAP server.
Add security constraints for STP compliance.


Tasks:
4201473
4201471

#payroll#ato#superannuation#compliance

Improvements(4)

Enhancements to existing features

[IMP] account_edi_proxy_client: add timeout argument to _make_request

PR #214120

Core18.0account_edi_proxy_clientMEDIUM

This update enhances the reliability of communication between Odoo and external services (IAP server) by allowing longer timeout periods for requests. Previously, a default 30-second timeout could cause delays when multiple external API calls were needed. Now, administrators can adjust the timeout to ensure these requests complete successfully, preventing potential disruptions to financial processing.

Original PR description

Some requests may require a longer timeout than the default 30 seconds when pinging the IAP server as they may need several external API calls.

This commit adds a `request_timeout` argument to the `_make_request` method to allow specifying a custom timeout value for the request.

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

#account_edi#IAP#timeout

[IMP] l10n_ro: add missing tax mappings for new VAT rates

PR #244580

Core18.0l10n_roMEDIUM

This update incorporates the latest Romanian VAT regulations, specifically the addition of 11% and 21% tax rates. The changes ensure that Odoo correctly handles these new rates within fiscal positions, maintaining accurate accounting and tax reporting for Romanian businesses.

Original PR description

The new 11% and 21% taxes introduced with the updated Romanian VAT law were added with this commit https://github.com/odoo/odoo/commit/2026212d0f7ffc217be3c6a2ff2abe5288c18afb , but some tax mappings were missing.

This commit completes the setup by adding the required tax mappings, ensuring the new rates work correctly with fiscal positions.

task-5480159

Forward-Port-Of: odoo/odoo#243452

#Romania#VAT#Tax#Accounting

[REF] account: assert or save XML test helpers

PR #237258

Core18.0accountMEDIUM

This update simplifies and streamlines testing of accounting XML files by introducing a new helper function. This reduces complexity for developers, allowing them to easily save and update XML files within their tests, and provides a standardized way to manage ignored XML nodes for consistent test results.

Original PR description

> This is a backport of the merged https://github.com/odoo/odoo/pull/235565 - with a couple of improvements & adaptations to the test files.

This commit adds helpers and improves on the way we assert XML files in `AccountTestInvoicingCommon` and all accounting test that extend from it. From now on, all accounting test code that assert an XML tree/string to an XML file should call the `assert_xml` helper, and design their test file name/location/etc. around this framework.

This approach has a few major benefits:

Assert / Save XML

When testing XML files, we often need to perform create/read/update operations on the asserted XML to make sure it corresponds to the most updated/intended data. Previously, to save something to an XML, a developer would need to write their own local helpers to save the XML in the right directory. This was cumbersome and error-prone, so we decided to design a helper that allows developer to immediately save AND/OR update the asserted XML: to save/update an XML, we can simply add `SAVE_XML` as an additional test tags.

Better test naming and optional subfolder management

To better organize test files, the `assert_xml` method allows us to write just the test key name (without `.xml`), and the framework will automatically get the XML to assert/save from the `test_files` directory. An optional `subfolder` parameter is also added to allow writing to specific subfolder within `test_files`.

Better `___ignore___` management in assertion XMLs

Sometimes, we want to ignore a few XML node that are not relevant, or have content that are not deterministic (changes on every test run). To handle this, previously, developers would need to modify the assertion XML content by hand or write their own local script to do so.

With this new framework, we just need to add an `ignore_schema.xml` file somewhere in the `test_files` directory. If put inside a subfolder, it will be applied with more priority towards the XML that are put on that specific subfolder.

Save "pure" XML (before applying `___ignore___`) in temporary folder

When calling `SAVE_XML`, before applying the ignore patches, the XML will be saved in a temporary folder (same folder as the screenshots for tours), so that developers can use them in external tests in the future, and for any other saving reasons.

In addition, this commit also:

- add `extra_tags` helper to save all the common tags for EDIs, for a better way to enable `EXTERNAL_MODE` testing inspired by `l10n_mx_edi`
- convert some non-assert XML test helpers into a class method
- refactor `l10n_mx_edi*` modules to use these helpers

related-enterprise-PR: https://github.com/odoo/enterprise/pull/100409

task-4891206

#testing#xml#automation

[IMP] account_reports: batch 'domain' engine when possible

PR #101725

Enterprise18.0account_reportsMEDIUM

This update optimizes how Odoo generates reports by grouping related domain searches. Previously, each report filter required a separate database query, leading to slow performance. This change combines multiple queries, significantly speeding up report generation times – specifically reducing the time to open the Generic Balance Sheet from 1 minute 35 seconds to 36 seconds.

Original PR description

Before this commit, the 'domain' engine was never batched: one expression to evaluate caused one SQL query to be run just for it. With this commit, we group domains that could be evaluated together.

Essentially, when we have domains targetting the same many2one field of account.move.line (typically account_id, with conditions like 'account_id.code' or 'account_id.account_type'), we run only one SQL query for all of them, targetting all the move lines according to the report filters. Then, we iterate on its result for each domain to evaluate. When iterating over the results, we filter the ones we keep by searching separately on each traversing model (in our example, account.account), to isolate the ones that are actually targetted by each expression.

Tested on our prod. With this, opening the Generic Balance Sheet goes from 1min 35s to 36s.

opw-5130725

#reporting#performance#optimization

Bug Fixes(15)

Resolved issues and error corrections

[FIX] mrp: prevent _compute_qty_remaining error when updating BoM on draft MO

PR #244509

Core18.0mrpMEDIUM

This update resolves an issue where updating BoM quantities on draft manufacturing orders could trigger errors. The fix ensures BoM updates are handled correctly, preventing crashes and maintaining accurate inventory calculations. This improves the stability of the production workflow.

Original PR description

Description of the issue/feature this PR addresses:
Updating quantities in a Bill of Materials (BoM) on a draft Manufacturing Order (MO) and clicking the “Update BoM” button could trigger an error. This happens because the _link_bom function unlinks existing mrp.workorders before writing to product_qty, causing the _compute_qty_remaining compute on now-unlinked workorders to fail.

Closes #243774

Current behavior before PR:
- Editing a BoM quantity on a draft MO and pressing “Update BoM” sometimes raises an error.
- The system fails to properly update mrp.workorder quantities after unlinking existing workorders.

Desired behavior after PR is merged:
- The BoM can be updated safely on draft MOs without raising errors.
- Moves and workorders are unlinked only after the BoM is reassigned.
- `product_qty` and `product_uom_id` are safely reset, and `_compute_qty_remaining` runs correctly.
- Overall, the draft MO workflow behaves as expected, avoiding crashes when updating BoMs.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#production#inventory#bohm

[FIX] l10n_ch: fix negative values in VAT report figures 382a and 383a

PR #244613

Core18.0l10n_chMEDIUM

This update fixes an error in the Swiss VAT reporting module (l10n_ch) that caused negative values to be displayed for reverse charge tax figures. The fix adjusts how these figures are calculated to ensure accurate VAT reporting for foreign vendor transactions.

Original PR description

**Steps to reproduce:** * Install the **l10n_ch** module for a Swiss company. * Create a vendor bill for a **foreign vendor**. * Apply a reverse charge tax: * **8.1% R C** (figure **383a**), or *…

**Steps to reproduce:**
* Install the **l10n_ch** module for a Swiss company.
* Create a vendor bill for a **foreign vendor**.
* Apply a reverse charge tax:
  * **8.1% R C** (figure **383a**), or
  * **7.7% R C** (figure **382a**).
* Confirm the vendor bill.
* Go to **Accounting → Reporting → Tax Report**.
* Generate the VAT report for the relevant period.

**Observed behavior:**
* Figure **383a** (8.1% reverse charge) is reported as **negative**.
* Figure **382a** (7.7% reverse charge) is reported as **negative**.
* This results in incorrect VAT reporting.

**Cause:**
* Reverse charge taxes use **negative tax rates** to model the reverse mechanism.
* The base amounts were tagged with **positive** signs, leading to negative values in the report.

**Fix:**
* Invert the base tax tag signs for reverse charge taxes:
  * **382a**: change base tag from `-382a` to `+382a`.
  * **383a**: change base tag from `-383a` to `+383a`.
* Reverse charge base amounts now appear as **positive** values in the VAT report.

opw-5257445

Forward-Port-Of: odoo/odoo#244452

#VAT#Reverse Charge#Switzerland#Tax Reporting

[FIX][WIP] sale_subscription: add test to retain discount when compute triggers from start date

PR #103639

Enterprise18.0sale_subscriptionMEDIUM

This update fixes an issue where discounts on non-subscription products within subscriptions were being reset to zero after the subscription's start date was set. The change ensures that discounts are correctly retained during temporal computations, providing accurate pricing for subscription orders. This improves the reliability of subscription pricing calculations.

Original PR description

Observation:
-----------------------------------
After saving the start date, the Discount value on the order line is reset to 0.00

Issue:
-----------------------------------
https://github.com/odoo/odoo/blob/55f34fa471316406f4ace442cb962545fa47bca1/addons/sale/models/sale_order_line.py#L771-L777
For regular products, In the discount recomputation logic, the discount is
explicitly set to 0 before checking for a pricelist. When a pricelist is present
the computation continues to the next iteration, leaving the discount already
reset

This issue only affected non-subscription products because subscription
products have their own discount computation logic in `sale_subscription`
https://github.com/odoo/enterprise/blob/00e2e658312eda2d3dae04eb966fd538972e5243/sale_subscription/models/sale_order_line.py#L80-L97
This implementation preserves discounts during temporal computations
(start_date) and doesn't rely on pricelist rules

Solution:
-----------------------------------
Reset discount to 0 only when pricelist has rules but none apply, preserving manual discounts when pricelist contains no rules at all

Related community PR: https://github.com/odoo/odoo/pull/242759

opw-5428077

#subscriptions#pricing#discounts

[FIX][WIP] sale: discount value when compute triggers from subscription

PR #242759

Core18.0saleMEDIUM

This update fixes an issue where discounts on non-subscription products within subscriptions were being reset to zero after the subscription start date was saved. The change ensures that discounts set manually on order lines are correctly preserved during subscription calculations, particularly when pricelists aren't involved. This improves the accuracy of pricing for subscription orders.

Original PR description

Observation:
-----------------------------------
After saving the start date, the Discount value on the order line is reset to 0.00

Solution:
-----------------------------------
Reset discount to 0 only when pricelist has rules but none apply, preserving manual discounts when pricelist contains no rules at all

Related Enterprise PR: https://github.com/odoo/enterprise/pull/103639

opw-5428077

#sale#subscription#discount

[FIX] l10n_ch_hr_payroll: salary certificate period

PR #103994

Enterprise18.0l10n_ch_hr_payrollMEDIUM

This update automatically adjusts the start and end dates for salary certificate reporting within the Odoo Enterprise system for Swiss payroll. Previously, these dates were static, now they dynamically pull from the configured data, ensuring accurate and up-to-date reporting requirements for Swiss tax authorities. This improves compliance and reduces the risk of errors.

Original PR description

make Period until and from dynamic from data

#payroll#reporting#Switzerland#tax

[FIX] mrp: Skip the state change for Work Orders

PR #221151

Core18.0mrpMEDIUM

This update resolves an issue where canceled work orders incorrectly reverted to 'in process' after production. The change prevents automatic status updates triggered by duration changes, ensuring canceled work orders remain canceled as intended. This improves the accuracy of production order tracking.

Original PR description

Description of the issue/feature this PR addresses: -The first step is to produce all but one unit from an MRP production order to enable a split. As the example images show, the first line of the…

Description of the issue/feature this PR addresses:

-The first step is to produce all but one unit from an MRP production order to enable a split. As the example images show, the first line of the "Work Orders" has both quantities completed, while the second line only has one of the two quantities completed.

<img width="1522" height="681" alt="image" src="https://github.com/user-attachments/assets/fb44e688-b851-45bb-9d86-0f5b03f9141d" />

<img width="1524" height="744" alt="image" src="https://github.com/user-attachments/assets/85ce3838-3b53-48ef-ad2f-c99308b5fb2d" />


-After performing the split, the "-002" segment should resemble what's depicted in the screenshots, with one line being canceled and the other remaining in the "Ready" status.

<img width="1529" height="805" alt="image" src="https://github.com/user-attachments/assets/a66c3414-a73b-4810-9fca-ac18c235704b" />

<img width="1532" height="856" alt="image" src="https://github.com/user-attachments/assets/46480229-0380-47f3-8552-c92f7c4282a6" />


-Now for the actual issue: once you produce everything in the second split, the line that was canceled goes back to "in process," which is incorrect. It should remain canceled because its full quantity was already completed in the first split. I've included screenshots showing how the "Work Order" lines appear after everything is produced.

<img width="1525" height="787" alt="image" src="https://github.com/user-attachments/assets/596cd97c-3f9a-4b1d-b51d-43b76fd083ce" />



My change prevents canceled or completed work orders from reverting to the “in progress” status. This is because when a change is made to the duration of a work order, the status is automatically updated. Therefore, I have added a status check to the condition to prevent this unwanted status change.


The issue occurs because a change in duration triggers a call to the "inverse" method of the "duration" field. This "inverse" method is responsible for updating the state of the "Work Orders," leading to the observed problem.

I've included both a screenshot of the code that changes the status and a link for easier access and review.

<img width="864" height="448" alt="image" src="https://github.com/user-attachments/assets/daafd66d-fe23-4d7c-a609-677c8fc29487" />

https://github.com/odoo/odoo/blob/18.0/addons/mrp/models/mrp_workorder.py#L349

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#production#work orders#inventory

[FIX] sale_pdf_quote_builder: Fix no detect PDF form field with Hierarchy object

PR #238323

Core18.0sale_pdf_quote_builderMEDIUM

This update fixes an issue where quote PDFs weren't correctly capturing form fields when dealing with complex sales structures (Hierarchy objects). The change ensures that the system now accurately detects and includes all relevant form fields, regardless of the sales structure, leading to more complete and accurate quotes.

Original PR description

- For Hierarchy objects, we have to check '/T' in '/Parent' instead directly within '/Annot' like flat fields.

Desired behavior after PR is merged:

- Support form fields with Hierarchy objects.


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#sales#quotes#pdf#hierarchy

[FIX] l10n_mx_edi: made the fields readonly

PR #103944

Enterprise18.0l10n_mx_ediMEDIUM

This update resolves an error that occurred when users attempted to create invoices with payment methods having the same code. The fix ensures payment method codes are read-only to align with Mexican government regulations and prevents duplicate records. It also includes safeguards to handle existing database configurations.

Original PR description

Currently, an error occurs when a user tries to post an invoice using a payment method that shares the same code as another payment method. Steps to replicate: - Install `l10n_mx_edi` and…

Currently, an error occurs when a user tries to post an invoice using a payment method that shares the same code as another payment method.

Steps to replicate:
- Install `l10n_mx_edi` and `accountant` with demo and switch to `ZAPATERIA URTADO ÑERI` (Mexican company).
- Go to `Accounting > Configuration > Payment Way Codes (MX)`.
- Open `Efectivo` and change its code to `02`.
- Create a new Invoice, select `Efectivo` in the Payment Way.
- Add a customer and a move line, then confirm the invoice and send it (make sure CFDI is checked).

Error:
```
  File '/home/odoo/src/enterprise/19.0/l10n_mx_edi/models/account_move.py', line 424, in _l10n_mx_edi_get_extra_invoice_report_values
    cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
  File '/home/odoo/src/odoo/19.0/odoo/orm/fields.py', line 1659, in __get__
    record.ensure_one()
  File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(1, 22)
```

Cause:
- Issue originated through this [PR] that gave access to write on the model.
- As the user made the codes of two payment methods same, the [search] returned two records and while accessing `payment_method.name` on two records it results into this error.

Solution:
- Made the fields read-only via XML to prevent users from changing the payment method codes established by the Mexican government.
- Added limit to the search query to prevent multiple records. (for existing DBs that might have changed payment method codes).
- Removed unlink rights on the `l10n_mx_edi.payment.method` model.
- Added a SQL constraint to allow only unique values for the code.

[PR]: https://github.com/odoo/enterprise/pull/38046

[search]: https://github.com/odoo/enterprise/blob/18117c6a9fbf270ace1c551616828a85713d5225/l10n_mx_edi/models/account_move.py#L423

sentry-7171030995

#mexico#edi#payment#invoice

[FIX] web: restrict group quick create to default groupby backport

PR #244493

Core18.0webcrmMEDIUM

This update fixes an issue where the CRM quick create feature was behaving unexpectedly when grouping by specific fields. The change ensures quick create is only available when properly grouped, preventing errors and improving the user experience. This resolves a previous RPC error related to salesperson creation in the CRM.

Original PR description

Backport of commit https://github.com/odoo/odoo/commit/95f09fda03b7d2c74ea8cb33d2431d3a4cef95bf.

This commit updates the conditions for enabling group quick create in list and kanban views. In addition to existing checks, the view must now be grouped using its default groupby (if defined) for quick create to be available.

This ensures that group quick create is only shown in contexts where it is properly supported and avoids undesired behavior when grouping by arbitrary fields.

Fixes the RPC_ERROR when trying to add a salesperson while grouped by salesperson in CRM, which incorrectly passed default_type='opportunity' to res.users.name_create in the case of our issue.

Steps to reproduce:
1- Install the CRM module.
2- Go to CRM (kanban view) and groupby salesperson.
3- Add new salesperson from the view.

Ticket [link](https://www.odoo.com/odoo/project.task/5499818)
opw-5499818

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#crm#quick create#kanban#list view

[FIX] web: display invalid operation instead of oh snap for user errors

PR #244663

Core18.0webMEDIUM

This update resolves an issue where users were seeing a generic 'Oh snap!' error message instead of the correct 'Invalid Operation' message when saving Time Off allocations with incorrect dates. The fix backports changes from the 18.3+ release to ensure a better user experience and accurate error display.

Original PR description

This commit https://github.com/odoo/odoo/commit/e566570e82e9 introduced a regression where the saveButtonClicked method automatically bound onSaveError as the error handler. This displays…

This commit https://github.com/odoo/odoo/commit/e566570e82e9 introduced a regression where the saveButtonClicked method automatically bound onSaveError as the error handler. This displays FormErrorDialog with "Oh snap!" for all save errors, causing UserErrors and ValidationErrors to show the generic "Oh snap!" message instead of the proper "Invalid Operation" dialog.

If you compare the original commit to the one here for the forward port 18.3+: https://github.com/odoo/odoo/pull/224620, you can see that the author reverted the problematic onError binding in saveButtonClicked and added forceLeave support to handle RedirectWarning redirects when the form is dirty. This PR backports those same changes to 18.0.

Steps To Reproduce:
1. Go to Time Off > Allocations > Create new allocation.
2. Set an End Date before the Start Date.
3. Click Save.
4. Error displays as "Oh snap!" instead of "Invalid Operation".
5. Switching tabs then shows the expected "Invalid Operation" dialog.

Ticket [link](https://www.odoo.com/odoo/project.task/5488127)
opw-5488127

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#error#time off#allocations

[FIX] account_edi_ubl_cii: Fix tax reverse charge in BIS3

PR #240525

Core18.0account_edi_ubl_ciiMEDIUM

This update corrects a technical issue related to how tax reverse charges are reported on BIS3 invoices. Previously, the system couldn't accurately handle these charges, leading to potential reporting errors. Now, tax reverse charges are correctly categorized as 'Prepaid Amounts' to ensure accurate invoice generation.

Original PR description

There is no WithholdingTaxTotal node in BIS3.
You cannot report any negative tax amount as taxes.
You can only report VAT taxes but tax reverse charge are not considered
as VAT.
This commit reports the tax reverse charge amount as a PrepaidAmount instead.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#tax#BIS3#invoice#reporting

[FIX] documents_account: import bank statements on current company

PR #104326

Enterprise18.0documents_accountMEDIUM

This update resolves an issue where the 'Import Bank Statement' action incorrectly selected a journal in multi-company environments due to elevated server permissions. The fix ensures the action filters by the currently chosen company, preventing incorrect journal selection and improving data accuracy. A new test confirms the fix's reliability.

Original PR description

Issue: 
when using the server action 'Import Bank Statement' the code
would not filter on the currently selected company for choosing the
journal on which to encode the bank statement and simply take the first
result. Because the server action is running with sudo rights, in a
multi-company environment more then one journals are found and the
selected one is often wrong.

Solution: filter on company during the selection of the journal.

Note: a test was added in which we run the function with sudo rights
to ensure an error is raised when the journal does not exist on the 
currently selected company, even if it is present on another company.

Task-5494685

#bank statements#accounting#multi-company

[FIX] pos_loyalty: fix runbot coupon issue

PR #229483

Core18.0pos_loyaltyMEDIUM

This update resolves a problem where gift card coupons weren't being generated correctly, leading to errors. The fix ensures coupons have enough time to be created and that the gift card is added to the order before the page is refreshed, preventing a common error.

Original PR description

When the last tour of this step was ignored, the coupons did not have enough time to be generated, resulting in an error because we are trying to access them later on in the backend. We thus had an out of range error on the coupons list.

Another issue was that we refreshed the page too soon after clicking the gift card product, so it did not have time to add it to the order before refreshing the page.

We now use a the *endTour* function to make sure the coupons have time to be generated to avoid said error.
We also make sure that the gift card has been added to the order before refreshing the page.

runbot-232857

#gift card#coupons#loyalty program

[FIX] mrp: avoid recursion error while producing large quantities

PR #239648

Core18.0mrpstockMEDIUM

This update fixes a RecursionError that occurred when producing large quantities of products tracked with serial numbers. The issue stemmed from a process that repeatedly updated deadlines across multiple manufacturing steps, exceeding Python's recursion limit. This change ensures stable production for high-volume serial-tracked orders.

Original PR description

**Issue** When producing a large number of serial-tracked products, a RecursionError can occur. **Steps to reproduce** - Create three products tracked by serial number (ensure MTO and Manufacture…

**Issue**
When producing a large number of serial-tracked products, a RecursionError
can occur.

**Steps to reproduce**
- Create three products tracked by serial number (ensure MTO and Manufacture
routes are enabled).
- Create a BoM for product A containing product B.
- Create a BoM for product B containing product C.
- Create a BoM for product C containing another product.
- Create a manufacturing order of 100 units for product A and confirm it.
- Produce the 100 units on the child MO of product C (100 backorders are created).
- On the main MO (product A), click on "Prepare MO".
- Attempt to produce product B.
→ RecursionError: maximum recursion depth exceeded.

**Cause**
While setting `move_finished_ids`:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/mrp/models/mrp_production.py#L806

the `deadline_date` of the final move is updated:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L742C1-L743C63

This deadline is then propagated to chained moves:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L539C1-L541C55
via:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L559C1-L562C61

This propagation retriggers the `move_finished_ids` setter recursively on other
moves. The recursion depth grows with the number of generated moves, eventually
exceeding Python's maximum recursion limit.

opw-[5265424](https://www.odoo.com/web#id=5265424&view_type=form&model=project.task)

#production#serial numbers#manufacturing

[FIX] l10n_cl: added a constraint for latam document number

PR #241505

Core18.0l10n_clMEDIUM

This update corrects an error in the Chilean invoicing process. The system previously failed when a document number contained non-numeric characters. A new constraint has been added to ensure document numbers are purely numeric, aligning with Chilean regulations and preventing invoice processing issues. This ensures accurate and compliant invoice generation.

Original PR description

An error currently occurs when a user tries to confirm an account move using a document number that isn’t purely numeric and contains ASCII characters other than digits.

Steps to replicate:
- Install `l10n_cl` with demo and switch to CL company.
- Create a new invoice and add customer as `Andes Innovación SpA`.
- Add a move line > Add a product, price and tax.
- Give Document Number as `11-11`.
- Save and Confirm.

Error:
```
File /home/odoo/odoo18/enterprise/account_accountant/models/account_move.py, line 119, in action_post
res = super().action_post()
File /home/odoo/odoo18/community/addons/account/models/account_move.py, line 5478, in action_post
self._post(soft=False)
File /home/odoo/odoo18/enterprise/l10n_cl_edi/models/account_move.py, line 161, in _post
move._l10n_cl_create_dte()
File /home/odoo/odoo18/enterprise/l10n_cl_edi/models/account_move.py, line 646, in _l10n_cl_create_dte
folio = int(self.l10n_latam_document_number)
ValueError: invalid literal for int() with base 10: '11-11'
```

Cause:
- Trying to convert the document number to integer which includes some characters that are not numeric causes the error.

Solution:
- Specifically for Chile, the document number (folio) cant include anything other than numbers (Check the Sources listed below).
- Added a constraint on the field `l10n_latam_document_number` which only allows numbers using regex.

Sources:
- https://www.sii.cl/pagina/clave/folio.htm : The official Internal Revenue Service website for Chile provides information on the standard folio, along with a sample.
- https://www.sii.cl/factura_electronica/formato_dte.pdf : Refer to PG:11, Sr No:3, which specifies that the Folio should be of type NUM, meaning it must contain only numeric characters.
- The folio is created [here] that will be sent later to the authorities in the form of xml.

[here]: https://github.com/odoo/enterprise/blob/5a8bdb586e2d0bf9948a2d0b4c5e30b3849c0414/l10n_cl_edi/template/dte_template.xml#L8

No ID
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#invoice#chile#document number#validation

This module adds single-touch payroll integrations with the ATO using the Super Choice API. The IAP server is used in the middle to ensure security and prevent unauthorised access to the ATO's API. It includes the following features: - Employer registration for STP - STP submission and retrieval of STP reports - Super Choice API integration for super contributions (Compliance Requirement) Add audit logging for Australian Payroll. A mixin that logs the selected field changes in the l10n_au.audit.log model. This is later synced to the IAP server. Add security constraints for STP compliance. Tasks: 4201473 4201471

Some requests may require a longer timeout than the default 30 seconds when pinging the IAP server as they may need several external API calls. This commit adds a `request_timeout` argument to the `_make_request` method to allow specifying a custom timeout value for the request. 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

The new 11% and 21% taxes introduced with the updated Romanian VAT law were added with this commit https://github.com/odoo/odoo/commit/2026212d0f7ffc217be3c6a2ff2abe5288c18afb , but some tax mappings were missing. This commit completes the setup by adding the required tax mappings, ensuring the new rates work correctly with fiscal positions. task-5480159 Forward-Port-Of: odoo/odoo#243452

> This is a backport of the merged https://github.com/odoo/odoo/pull/235565 - with a couple of improvements & adaptations to the test files. This commit adds helpers and improves on the way we assert XML files in `AccountTestInvoicingCommon` and all accounting test that extend from it. From now on, all accounting test code that assert an XML tree/string to an XML file should call the `assert_xml` helper, and design their test file name/location/etc. around this framework. This approach has a few major benefits: Assert / Save XML When testing XML files, we often need to perform create/read/update operations on the asserted XML to make sure it corresponds to the most updated/intended data. Previously, to save something to an XML, a developer would need to write their own local helpers to save the XML in the right directory. This was cumbersome and error-prone, so we decided to design a helper that allows developer to immediately save AND/OR update the asserted XML: to save/update an XML, we can simply add `SAVE_XML` as an additional test tags. Better test naming and optional subfolder management To better organize test files, the `assert_xml` method allows us to write just the test key name (without `.xml`), and the framework will automatically get the XML to assert/save from the `test_files` directory. An optional `subfolder` parameter is also added to allow writing to specific subfolder within `test_files`. Better `___ignore___` management in assertion XMLs Sometimes, we want to ignore a few XML node that are not relevant, or have content that are not deterministic (changes on every test run). To handle this, previously, developers would need to modify the assertion XML content by hand or write their own local script to do so. With this new framework, we just need to add an `ignore_schema.xml` file somewhere in the `test_files` directory. If put inside a subfolder, it will be applied with more priority towards the XML that are put on that specific subfolder. Save "pure" XML (before applying `___ignore___`) in temporary folder When calling `SAVE_XML`, before applying the ignore patches, the XML will be saved in a temporary folder (same folder as the screenshots for tours), so that developers can use them in external tests in the future, and for any other saving reasons. In addition, this commit also: - add `extra_tags` helper to save all the common tags for EDIs, for a better way to enable `EXTERNAL_MODE` testing inspired by `l10n_mx_edi` - convert some non-assert XML test helpers into a class method - refactor `l10n_mx_edi*` modules to use these helpers related-enterprise-PR: https://github.com/odoo/enterprise/pull/100409 task-4891206

Before this commit, the 'domain' engine was never batched: one expression to evaluate caused one SQL query to be run just for it. With this commit, we group domains that could be evaluated together. Essentially, when we have domains targetting the same many2one field of account.move.line (typically account_id, with conditions like 'account_id.code' or 'account_id.account_type'), we run only one SQL query for all of them, targetting all the move lines according to the report filters. Then, we iterate on its result for each domain to evaluate. When iterating over the results, we filter the ones we keep by searching separately on each traversing model (in our example, account.account), to isolate the ones that are actually targetted by each expression. Tested on our prod. With this, opening the Generic Balance Sheet goes from 1min 35s to 36s. opw-5130725

Description of the issue/feature this PR addresses: Updating quantities in a Bill of Materials (BoM) on a draft Manufacturing Order (MO) and clicking the “Update BoM” button could trigger an error. This happens because the _link_bom function unlinks existing mrp.workorders before writing to product_qty, causing the _compute_qty_remaining compute on now-unlinked workorders to fail. Closes #243774 Current behavior before PR: - Editing a BoM quantity on a draft MO and pressing “Update BoM” sometimes raises an error. - The system fails to properly update mrp.workorder quantities after unlinking existing workorders. Desired behavior after PR is merged: - The BoM can be updated safely on draft MOs without raising errors. - Moves and workorders are unlinked only after the BoM is reassigned. - `product_qty` and `product_uom_id` are safely reset, and `_compute_qty_remaining` runs correctly. - Overall, the draft MO workflow behaves as expected, avoiding crashes when updating BoMs. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

**Steps to reproduce:** * Install the **l10n_ch** module for a Swiss company. * Create a vendor bill for a **foreign vendor**. * Apply a reverse charge tax: * **8.1% R C** (figure **383a**), or * **7.7% R C** (figure **382a**). * Confirm the vendor bill. * Go to **Accounting → Reporting → Tax Report**. * Generate the VAT report for the relevant period. **Observed behavior:** * Figure **383a** (8.1% reverse charge) is reported as **negative**. * Figure **382a** (7.7% reverse charge) is reported as **negative**. * This results in incorrect VAT reporting. **Cause:** * Reverse charge taxes use **negative tax rates** to model the reverse mechanism. * The base amounts were tagged with **positive** signs, leading to negative values in the report. **Fix:** * Invert the base tax tag signs for reverse charge taxes: * **382a**: change base tag from `-382a` to `+382a`. * **383a**: change base tag from `-383a` to `+383a`. * Reverse charge base amounts now appear as **positive** values in the VAT report. opw-5257445 Forward-Port-Of: odoo/odoo#244452

Steps to reproduce: ----------------------------------- 1. Install `sale_subscription` module. 2. Go to Settings and enable Pricelists 3. Create a new Subscription, set a pricelist & add a recurring plan 4. Add a non-subscription product to the order line 5. Manually set the Discount field to any non-zero value 6. Save the subscription 7. Open the Other Info tab, set the Start Date, and save again Observation: ----------------------------------- After saving the start date, the Discount value on the order line is reset to 0.00 Issue: ----------------------------------- https://github.com/odoo/odoo/blob/55f34fa471316406f4ace442cb962545fa47bca1/addons/sale/models/sale_order_line.py#L771-L777 For regular products, In the discount recomputation logic, the discount is explicitly set to 0 before checking for a pricelist. When a pricelist is present the computation continues to the next iteration, leaving the discount already reset This issue only affected non-subscription products because subscription products have their own discount computation logic in `sale_subscription` https://github.com/odoo/enterprise/blob/00e2e658312eda2d3dae04eb966fd538972e5243/sale_subscription/models/sale_order_line.py#L80-L97 This implementation preserves discounts during temporal computations (start_date) and doesn't rely on pricelist rules Solution: ----------------------------------- Reset discount to 0 only when pricelist has rules but none apply, preserving manual discounts when pricelist contains no rules at all Related community PR: https://github.com/odoo/odoo/pull/242759 opw-5428077

Steps to reproduce: ----------------------------------- 1. Install `sale_subscription` module. 2. Go to Settings and enable Pricelists 3. Create a new Subscription, set a pricelist & add a recurring plan 4. Add a non-subscription product to the order line 5. Manually set the Discount field to any non-zero value 6. Save the subscription 7. Open the Other Info tab, set the Start Date, and save again Observation: ----------------------------------- After saving the start date, the Discount value on the order line is reset to 0.00 Issue: ----------------------------------- https://github.com/odoo/odoo/blob/55f34fa471316406f4ace442cb962545fa47bca1/addons/sale/models/sale_order_line.py#L771-L777 For regular products, In the discount recomputation logic, the discount is explicitly set to 0 before checking for a pricelist. When a pricelist is present the computation continues to the next iteration, leaving the discount already reset This issue only affected non-subscription products because subscription products have their own discount computation logic in `sale_subscription` https://github.com/odoo/enterprise/blob/00e2e658312eda2d3dae04eb966fd538972e5243/sale_subscription/models/sale_order_line.py#L80-L97 This implementation preserves discounts during temporal computations (start_date) and doesn't rely on pricelist rules Solution: ----------------------------------- Reset discount to 0 only when pricelist has rules but none apply, preserving manual discounts when pricelist contains no rules at all Related Enterprise PR: https://github.com/odoo/enterprise/pull/103639 opw-5428077

Description of the issue/feature this PR addresses: -The first step is to produce all but one unit from an MRP production order to enable a split. As the example images show, the first line of the "Work Orders" has both quantities completed, while the second line only has one of the two quantities completed. <img width="1522" height="681" alt="image" src="https://github.com/user-attachments/assets/fb44e688-b851-45bb-9d86-0f5b03f9141d" /> <img width="1524" height="744" alt="image" src="https://github.com/user-attachments/assets/85ce3838-3b53-48ef-ad2f-c99308b5fb2d" /> -After performing the split, the "-002" segment should resemble what's depicted in the screenshots, with one line being canceled and the other remaining in the "Ready" status. <img width="1529" height="805" alt="image" src="https://github.com/user-attachments/assets/a66c3414-a73b-4810-9fca-ac18c235704b" /> <img width="1532" height="856" alt="image" src="https://github.com/user-attachments/assets/46480229-0380-47f3-8552-c92f7c4282a6" /> -Now for the actual issue: once you produce everything in the second split, the line that was canceled goes back to "in process," which is incorrect. It should remain canceled because its full quantity was already completed in the first split. I've included screenshots showing how the "Work Order" lines appear after everything is produced. <img width="1525" height="787" alt="image" src="https://github.com/user-attachments/assets/596cd97c-3f9a-4b1d-b51d-43b76fd083ce" /> My change prevents canceled or completed work orders from reverting to the “in progress” status. This is because when a change is made to the duration of a work order, the status is automatically updated. Therefore, I have added a status check to the condition to prevent this unwanted status change. The issue occurs because a change in duration triggers a call to the "inverse" method of the "duration" field. This "inverse" method is responsible for updating the state of the "Work Orders," leading to the observed problem. I've included both a screenshot of the code that changes the status and a link for easier access and review. <img width="864" height="448" alt="image" src="https://github.com/user-attachments/assets/daafd66d-fe23-4d7c-a609-677c8fc29487" /> https://github.com/odoo/odoo/blob/18.0/addons/mrp/models/mrp_workorder.py#L349 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

- For Hierarchy objects, we have to check '/T' in '/Parent' instead directly within '/Annot' like flat fields. Desired behavior after PR is merged: - Support form fields with Hierarchy objects. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Currently, an error occurs when a user tries to post an invoice using a payment method that shares the same code as another payment method. Steps to replicate: - Install `l10n_mx_edi` and `accountant` with demo and switch to `ZAPATERIA URTADO ÑERI` (Mexican company). - Go to `Accounting > Configuration > Payment Way Codes (MX)`. - Open `Efectivo` and change its code to `02`. - Create a new Invoice, select `Efectivo` in the Payment Way. - Add a customer and a move line, then confirm the invoice and send it (make sure CFDI is checked). Error: ``` File '/home/odoo/src/enterprise/19.0/l10n_mx_edi/models/account_move.py', line 424, in _l10n_mx_edi_get_extra_invoice_report_values cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}' File '/home/odoo/src/odoo/19.0/odoo/orm/fields.py', line 1659, in __get__ record.ensure_one() File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one raise ValueError('Expected singleton: %s' % self) ValueError: Expected singleton: l10n_mx_edi.payment.method(1, 22) ``` Cause: - Issue originated through this [PR] that gave access to write on the model. - As the user made the codes of two payment methods same, the [search] returned two records and while accessing `payment_method.name` on two records it results into this error. Solution: - Made the fields read-only via XML to prevent users from changing the payment method codes established by the Mexican government. - Added limit to the search query to prevent multiple records. (for existing DBs that might have changed payment method codes). - Removed unlink rights on the `l10n_mx_edi.payment.method` model. - Added a SQL constraint to allow only unique values for the code. [PR]: https://github.com/odoo/enterprise/pull/38046 [search]: https://github.com/odoo/enterprise/blob/18117c6a9fbf270ace1c551616828a85713d5225/l10n_mx_edi/models/account_move.py#L423 sentry-7171030995

Backport of commit https://github.com/odoo/odoo/commit/95f09fda03b7d2c74ea8cb33d2431d3a4cef95bf. This commit updates the conditions for enabling group quick create in list and kanban views. In addition to existing checks, the view must now be grouped using its default groupby (if defined) for quick create to be available. This ensures that group quick create is only shown in contexts where it is properly supported and avoids undesired behavior when grouping by arbitrary fields. Fixes the RPC_ERROR when trying to add a salesperson while grouped by salesperson in CRM, which incorrectly passed default_type='opportunity' to res.users.name_create in the case of our issue. Steps to reproduce: 1- Install the CRM module. 2- Go to CRM (kanban view) and groupby salesperson. 3- Add new salesperson from the view. Ticket [link](https://www.odoo.com/odoo/project.task/5499818) opw-5499818 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

This commit https://github.com/odoo/odoo/commit/e566570e82e9 introduced a regression where the saveButtonClicked method automatically bound onSaveError as the error handler. This displays FormErrorDialog with "Oh snap!" for all save errors, causing UserErrors and ValidationErrors to show the generic "Oh snap!" message instead of the proper "Invalid Operation" dialog. If you compare the original commit to the one here for the forward port 18.3+: https://github.com/odoo/odoo/pull/224620, you can see that the author reverted the problematic onError binding in saveButtonClicked and added forceLeave support to handle RedirectWarning redirects when the form is dirty. This PR backports those same changes to 18.0. Steps To Reproduce: 1. Go to Time Off > Allocations > Create new allocation. 2. Set an End Date before the Start Date. 3. Click Save. 4. Error displays as "Oh snap!" instead of "Invalid Operation". 5. Switching tabs then shows the expected "Invalid Operation" dialog. Ticket [link](https://www.odoo.com/odoo/project.task/5488127) opw-5488127 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

There is no WithholdingTaxTotal node in BIS3. You cannot report any negative tax amount as taxes. You can only report VAT taxes but tax reverse charge are not considered as VAT. This commit reports the tax reverse charge amount as a PrepaidAmount instead. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Issue: when using the server action 'Import Bank Statement' the code would not filter on the currently selected company for choosing the journal on which to encode the bank statement and simply take the first result. Because the server action is running with sudo rights, in a multi-company environment more then one journals are found and the selected one is often wrong. Solution: filter on company during the selection of the journal. Note: a test was added in which we run the function with sudo rights to ensure an error is raised when the journal does not exist on the currently selected company, even if it is present on another company. Task-5494685

When the last tour of this step was ignored, the coupons did not have enough time to be generated, resulting in an error because we are trying to access them later on in the backend. We thus had an out of range error on the coupons list. Another issue was that we refreshed the page too soon after clicking the gift card product, so it did not have time to add it to the order before refreshing the page. We now use a the *endTour* function to make sure the coupons have time to be generated to avoid said error. We also make sure that the gift card has been added to the order before refreshing the page. runbot-232857

**Issue** When producing a large number of serial-tracked products, a RecursionError can occur. **Steps to reproduce** - Create three products tracked by serial number (ensure MTO and Manufacture routes are enabled). - Create a BoM for product A containing product B. - Create a BoM for product B containing product C. - Create a BoM for product C containing another product. - Create a manufacturing order of 100 units for product A and confirm it. - Produce the 100 units on the child MO of product C (100 backorders are created). - On the main MO (product A), click on "Prepare MO". - Attempt to produce product B. → RecursionError: maximum recursion depth exceeded. **Cause** While setting `move_finished_ids`: https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/mrp/models/mrp_production.py#L806 the `deadline_date` of the final move is updated: https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L742C1-L743C63 This deadline is then propagated to chained moves: https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L539C1-L541C55 via: https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L559C1-L562C61 This propagation retriggers the `move_finished_ids` setter recursively on other moves. The recursion depth grows with the number of generated moves, eventually exceeding Python's maximum recursion limit. opw-[5265424](https://www.odoo.com/web#id=5265424&view_type=form&model=project.task)

An error currently occurs when a user tries to confirm an account move using a document number that isn’t purely numeric and contains ASCII characters other than digits. Steps to replicate: - Install `l10n_cl` with demo and switch to CL company. - Create a new invoice and add customer as `Andes Innovación SpA`. - Add a move line > Add a product, price and tax. - Give Document Number as `11-11`. - Save and Confirm. Error: ``` File /home/odoo/odoo18/enterprise/account_accountant/models/account_move.py, line 119, in action_post res = super().action_post() File /home/odoo/odoo18/community/addons/account/models/account_move.py, line 5478, in action_post self._post(soft=False) File /home/odoo/odoo18/enterprise/l10n_cl_edi/models/account_move.py, line 161, in _post move._l10n_cl_create_dte() File /home/odoo/odoo18/enterprise/l10n_cl_edi/models/account_move.py, line 646, in _l10n_cl_create_dte folio = int(self.l10n_latam_document_number) ValueError: invalid literal for int() with base 10: '11-11' ``` Cause: - Trying to convert the document number to integer which includes some characters that are not numeric causes the error. Solution: - Specifically for Chile, the document number (folio) cant include anything other than numbers (Check the Sources listed below). - Added a constraint on the field `l10n_latam_document_number` which only allows numbers using regex. Sources: - https://www.sii.cl/pagina/clave/folio.htm : The official Internal Revenue Service website for Chile provides information on the standard folio, along with a sample. - https://www.sii.cl/factura_electronica/formato_dte.pdf : Refer to PG:11, Sr No:3, which specifies that the Folio should be of type NUM, meaning it must contain only numeric characters. - The folio is created [here] that will be sent later to the authorities in the form of xml. [here]: https://github.com/odoo/enterprise/blob/5a8bdb586e2d0bf9948a2d0b4c5e30b3849c0414/l10n_cl_edi/template/dte_template.xml#L8 No ID --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr