Odoo Changelog — 2026-01-28

Wednesday, January 28, 2026

14 changes · master

Bug Fixes(14)

Resolved issues and error corrections

[FIX] project_mrp_workorder_account: User with Manufacturing admin access can finish MO

Enterprisemastermrp_workorder_accountMEDIUM

A previous issue prevented users with manufacturing admin access from completing work orders. This fix adds sudo access to the failing process, ensuring these users can now successfully 'Produce All' and complete manufacturing tasks. This resolves a workflow disruption for our manufacturing teams.

Original PR description

Steps to reproduce:
    Create a user with admin access rights for Manufacturing and Quality only. Then, create a work center that has a cost per hour.
    Create a product that has a BoM and create a MO then confirm it.
    Add a work order that takes place in the created work center and has duration of 60 mins.
    Using the created user, try to "Produce All".
Issue:
    The user gets an access error when trying to "Produce All", eventhough they have manufacturing access rights.
Fix:
    Add sudo access where the process fails to ensure that the workflow is as expected.
Note: a test will be added in anoher PR
opw-5480608

Forward-Port-Of: odoo/enterprise#104897

#manufacturing#workorder#production

[FIX] l10n_mx_edi: Fixed reported bank account vat

PR #105226

Enterprisemasterl10n_mx_ediMEDIUM

This update resolves a technical issue where the VAT on bank payments (CFDI) was incorrectly reported when a bank account was missing or invalid. The fix ensures that VAT reporting is only triggered when a valid bank account with a country code is present, improving the accuracy of financial data. This impacts the l10n_mx_edi module.

Original PR description

This PR https://github.com/odoo/enterprise/pull/99418 broke the bank vat reported in payment cfdi.
The vat should not be reported in case there is no bank account (or the bank has no country), but a foriegn bank vat was reported instead.

This commit fixed this issue by checking the bank country along with its VAT before reporting its VAT.

task-5745608

#VAT#Mexico#CFDI#Accounting

[PERF] budget_report: speed up budget_report

PR #103714

Enterprisemasteraccount_budgetMEDIUM

This update significantly speeds up the generation of budget reports by optimizing how data is filtered. Previously, a slow process involved generating a large table and filtering it afterward. Now, the filtering is applied directly within the underlying queries, reducing the amount of data processed and dramatically improving report generation times. This results in faster report loading and a better user experience.

Original PR description

Previously, generating the budget.report table was necessary to trigger _compute_all for budget.line fields. This table was built using three separate queries with a UNION operator. Because of the…

Previously, generating the budget.report table was necessary to trigger _compute_all for budget.line fields. This table was built using three separate queries with a UNION operator. Because of the UNION, any filtering (like on specific budget_line_ids) happened after the full, unfiltered table was generated.

This post-filtering caused slowness, especially in nested loop joins with large tables like account.analytic.line. This commit optimizes performance by pushing the filter condition (using specific budget_line_ids) directly down into the three underlying queries. This reduces the number of budget.line records processed, speeding up joins and overall computation.

The benchmark below is done on a database that has **66396** `budget.line` records and **928567** `account.analytic.line` records. Opening a budget report for a specific year, only applied the filter with **40** `budget.line` records.

| Scenario | Execution Time |
| :--- | :--- |
| **Before this Commit** | **60.00 seconds**
| **After this Commit** | **1.84 seconds**

opw-5150569

Forward-Port-Of: odoo/enterprise#102918
Forward-Port-Of: odoo/enterprise#99096

#performance#reporting#budget

[FIX] pos_settle_due: show warning on partner exceeding credit limit

PR #105691

Enterprisemasterpos_settle_dueMEDIUM

This update addresses a bug where users weren't receiving warnings when exceeding a customer's sales credit limit within the Point of Sale (POS) system. The fix ensures that a warning indicator is displayed, preventing over-spending and potential financial issues. This improves accuracy and protects the business from exceeding credit limits.

Original PR description

Steps to reproduce:
-------------------
1. Install pos_settle_due and accountant
2. In Accounting settings, enable "Sales Credit Limit"
3. Create a new customer, enable its "Partner Limit" and set it to 100
4. Open PoS, select that partner, and select products such that the total exceeds 100

Notice that even though we have exceeded that partner's limit of 100, there are no indicators on the customer button (orange background on hover), nor there are warnings on the partners list modal nor on the payment page.

Why the bug
-----------
In `getPartnerCredit`, we are using `order.amount_total` to get the current ordre amount, however, this field is `undefined` for a new order and it's been assigned a value in `setOrderPrices`, which since [9538698](https://github.com/odoo/odoo/commit/9538698), is only called before sending the order to the backend.

The fix
-------
Now we read the total amount from the getter `order.priceIncl`, and round it as we would do in `setOrderPrices`.

opw-5489975

Forward-Port-Of: odoo/enterprise#105548
Forward-Port-Of: odoo/enterprise#104591

#pos#credit limit#sales

[FIX] mrp_workorder: give fallback app name when opening shop floor

PR #105714

Enterprisemastermrp_workorderMEDIUM

This update resolves a JavaScript error that occurred when opening the Shop Floor from the replenishment flow. The fix ensures the application name is correctly identified, preventing a traceback and improving the reliability of this key workflow. This change enhances the user experience when managing manufacturing orders.

Original PR description

Opening the Shop Floor via the replenishment/forecast flow can raise a js traceback. **Steps to produce:** - Install `mrp` module. - Enable `multi-step routes` from the settings. - Inventory >…

Opening the Shop Floor via the replenishment/forecast flow can
raise a js traceback.

**Steps to produce:**
- Install `mrp` module.
- Enable `multi-step routes` from the settings.
- Inventory > Configuration > Warehouse Management > Routes.
- In Manufacture route, make sure route is Applicable On `products`.
- Inventory > Products > Products > New.
- Click on forcasted button on product > Click on replenish button > Confirm.
- Click the Manufacturing Order shown in the notification.
- Confirm the MO and click Shop Floor.

**Issue:**
A JavaScript error occurs: `TypeError: Cannot read properties of null.`

**Root cause:**
The Shop Floor view relies on the menu service to determine the current
application name by calling `this.menu.getCurrentApp().name`. When the
Shop Floor is opened from the replenishment/forecast flow,
the navigation occurs through action-based triggers rather than through
the main menu. As a result, no menu selection is performed and
`setCurrentMenu()`[1] is not executed beforehand.This leaves the current
application undefined, causing `menu.getCurrentApp()` to return undefined
and leading to a js traceback when `.name` is accessed.

[1]: https://github.com/odoo/odoo/blob/c646cb61d0752250b2600413d6d63deabd1d3e6d/addons/web/static/src/webclient/menus/menu_service.js#L57-L64

simillar fix : https://github.com/odoo/enterprise/pull/93043

Note: A tour is possible but unnecessary for this small use-case.

opw-5462965
---

Forward-Port-Of: odoo/enterprise#104706

#manufacturing#shop floor#workflow

[FIX] l10n_it_pos: fix refunds in Italian fiscal printer

PR #105361

Enterprisemasterl10n_it_posMEDIUM

This update resolves a problem preventing refunds from printing correctly on Italian fiscal printers. The issue stemmed from a missing method in the POS system that was inadvertently removed during a recent update. The fix re-introduced this method, ensuring refunds now print as expected.

Original PR description

Step to reproduce: - install `l10n_it_pos` - setup Italian fiscal printer for a pos - refund a order and print receipt Observation: receives a traceback ```js Caused by: TypeError:…

Step to reproduce:
- install `l10n_it_pos`
- setup Italian fiscal printer for a pos
- refund a order and print receipt

Observation:
receives a traceback
```js
Caused by: TypeError: ctx.this.order.getRefundInfo is not a function
    at Header.template (eval at compile (https://97822380-19-0-design-theme.runbot118.odoo.com/web/assets/debug/point_of_sale.assets_prod.js:16388:20), <anonymous>:11:62) (/web/static/lib/owl/owl.js:5807)
    at Fiber._render (https://97822380-19-0-design-theme.runbot118.odoo.com/web/assets/debug/point_of_sale.assets_prod.js:12364:38) (/web/static/lib/owl/owl.js:1783)
    at Fiber.render (https://97822380-19-0-design-theme.runbot118.odoo.com/web/assets/debug/point_of_sale.assets_prod.js:12356:18) (/web/static/lib/owl/owl.js:1775)
    at ComponentNode.initiateRender (https://97822380-19-0-design-theme.runbot118.odoo.com/web/assets/debug/point_of_sale.assets_prod.js:13036:23) (/web/static/lib/owl/owl.js:2455)

```

Cause:
- A <Header/> component is used in invoices, which requires a method `getRefundInfo`.
- commit [1]  removes <Header> and its related files,
- commit [2]  removes dead code, hence removed `getRefundInfo`
- commit [3] brings back <Header>, but the method was not reintroduced

[1] https://github.com/odoo/enterprise/commit/3d532f6ee99884bce58a577eb68464e670fb059a
[2] https://github.com/odoo/enterprise/commit/1b03fe15916b7b86f79efcbb63895ae0c4363ef9
[3] https://github.com/odoo/enterprise/commit/d745a72e3f43febb3b39054dc9315eca13d86e36

Fix:
- Add the method back

After fix: 
**image from simulator**
<img width="600" height="300" alt="image" src="https://github.com/user-attachments/assets/f6caccca-caf6-477f-bf37-f942090535cc" />


opw-5485350

Forward-Port-Of: odoo/enterprise#105048

#refund#italian#pos#fiscal printer

[IMP] *: add tag to tour that fails without macro delay

PR #101191

Enterprisemasteraccount_reportsai_website_livechatdatabaseshelpdeskhr_contract_salaryhr_payrollknowledgel10n_br_edi_posl10n_cl_edi_posl10n_mx_edi_posl10n_test_website_salemrp_workorderpos_enterprisepos_restaurant_preparation_displaypos_settle_dueMEDIUM

This update addresses a recurring issue causing tours to fail in several Odoo modules, impacting around 300 tours. The change introduces a mechanism to handle delays within tours, ultimately aiming to eliminate random errors and ensure a more reliable user experience. This improves the stability of key feature walkthroughs.

Original PR description

Add special key for tours that require a delay between steps to not
crash. It concerns more or less 220 tours on average 1600.
The goal is to remove this key and fix the tour to make it
deterministic (remove random errors).

#tour#stability#performance

[FIX] l10n_syscohada_reports: Inverted sign on gross margin

PR #105731

EnterprisemasteraccountMEDIUM

This update fixes an error in the SYSCOHADA Profit and Loss report where the gross margin calculation was incorrectly adding instead of subtracting account values. The change ensures the report accurately reflects the Ginea - SYSCOHADA fiscal localization requirements as defined in the official documentation, leading to more reliable financial reporting.

Original PR description

The SYSCOHADA gross margin is defined on page 330 - 331 of the document [Guide-d-application-du-SYSCOHADA.pdf](https://www.ohada.com/uploads/actualite/3504/Guide-d-application-du-SYSCOHADA.pdf). It is TA (701) - RA (601) +/- RB (6031). TA and RA should always be positive and negative, respectively.

In the report "Profit and Loss (SYSCOHADA)", the line RA is negated. XA then subtracts this value from TA, adding the two values instead of subtracting them.

Steps to reproduce:

1. Create a new company on runbot.
2. In Accounting > Configuration > Settings, set their Fiscal Localization to Ginea - SYSCOHADA for Companies.
3. Make a MISC journal entry.
    1. Set a credit of 110,000,000 on account 701100 and balance it with 411100.
    5. Set a debit of 75,000,000 on account 601100 and balance it with 401100.
    6. Set a credit of 5,000,000 on account 603100 and balance it with 411100.
7. Post the entry.
8. Navigate to Accounting > Reports > Profit and Loss.
9. Set the l10n version, Profit and Loss (SYSCOHADA).
10. Set the current date.
11. See XA = 110 million + 75 million + 5 million = 190 million; this does not match the example given on pg 357 of Guide-d-application-du-SYSCOHADA.pdf, where XA = 40 million.

[opw-5482300](https://www.odoo.com/odoo/project.task/project.task/5482300)

Forward-Port-Of: odoo/enterprise#104736
Forward-Port-Of: odoo/enterprise#104479

#financial reporting#SYSCOHADA#Ginea

[FIX] l10n_ro_saft: handle missing partner info

PR #105697

Enterprisemasterl10n_ro_saftMEDIUM

This update resolves issues in the Romanian SAF-T export process that occurred when partner information (country or name) was incomplete. Specifically, it corrects errors related to invoice generation and ensures accurate SAF-T file creation, improving compliance for Romanian companies.

Original PR description

Fix SAF-T export errors when partners have no country or name.

For Romanian companies, the RegistrationNumber should be
generated as “04 + partner ID” for customers not subject to VAT
and with unknown CNP, without including the country code.

Steps to reproduce country issue:
- Configure a Romanian company with l10n_ro_saft installed
- Create a contact without a country
- Create and validate an invoice for this contact
- Export the SAF-T file from the General Ledger report

You you will get a TypeError because you cant concatenate Bool and String.

Steps to reproduce name issue:
- Create a main contact
- Add a child contact without a name
- Change the child type to “Company”
- Create and validate an invoice
- Export the SAF-T file from the General Ledger report

This prevents KeyError when printing the first 70 characters
of the partner name in the report.

opw-5499918

Forward-Port-Of: odoo/enterprise#105579
Forward-Port-Of: odoo/enterprise#105020

#Romania#SAF-T#Compliance#Accounting

[FIX] ai: change important logs to info from debug

PR #105702

EnterprisemasteraiMEDIUM

This update enhances the monitoring of our AI integrations by changing key log levels to 'info' for easier tracking by our team and database administrators. Additionally, the system now accurately reports token usage from LLM providers, addressing a previous underreporting issue. This provides better insights into AI costs and performance.

Original PR description

In this commit we change some important llm api usage logs from debug to info so they can be more easily monitored by us and database admins.

We also change the usage reporting from a naive estimation (which greatly under-reported the token usage) to the actual token usage given to us by the LLM prodivers in the response.

Forward-Port-Of: odoo/enterprise#105627
Forward-Port-Of: odoo/enterprise#105364

#AI#logging#usage#token

[FIX] l10n_br_edi_pos: allow NFC-e refund

PR #105561

Enterprisemasterl10n_br_edi_posMEDIUM

This update resolves a bug that prevented successful NFC-e refunds in Point of Sale (PoS). The fix corrects a logic error in how the system checks for existing invoices, ensuring that refund requests are processed correctly. This improves the reliability of NFC-e transactions.

Original PR description

**Steps to reproduce:**
- Setup a database that supports NFC-e
- Go to PoS, make a purchase, then refund it
- A traceback appears, saying we couldn't find the original invoice

**Why the fix:**
Before this commit the way we checked if there was already an invoice in the payload we give to the API was wrong, as it was always true. This happens because before the
*def _get_l10n_br_avatax_service_params(self):* call, we set res['invoice_refs'] as {}, then we were supposed to fill it. But if we check https://github.com/odoo/enterprise/blob/32b73b12f9f8f5600b820d9a938bfbb0cf10054d/l10n_br_edi_pos/models/account_move.py#L13 'invoice_refs' is found in res, even though it is empty, so we never entered the if statement.

We now check if there is a value in res['invoice_refs'] and if not we set it.

opw-5359407

Forward-Port-Of: odoo/enterprise#104987
Forward-Port-Of: odoo/enterprise#102770

#refund#NFC-e#POS

[FIX] voip: getOrCreateCall should fetch contact info if needed

PR #105778

EnterprisemastervoipMEDIUM

This update resolves an issue where contact information wasn't consistently displayed when receiving incoming calls. The team corrected a missing piece of code in the 'getOrCreateCall' function, ensuring that contact details are now correctly fetched and shown. This improves the user experience when managing calls.

Original PR description

In https://github.com/odoo/enterprise/pull/105036, some part of the code in getOrCreateCall was forgotten. Consequently, on an incoming call, contact info could sometimes not be displayed.

#voip#calls#contacts

[FIX] l10n_mx_edi_sale: ensure CFDI to Public is set when partner address is invalid

PR #105625

Enterprisemasterl10n_mx_edi_saleMEDIUM

This update resolves an issue where sale orders with missing address information in Mexico prevented successful online payments. The fix automatically enables 'CFDI to Public' when the address is incomplete, ensuring transactions are validated and payments are recorded as required by Mexican regulations. This improves payment processing reliability for Mexican customers.

Original PR description

### Issue: On a Mexican sale order, it was possible to have an invalid partner address while `CFDI to Public` was not enabled In this situation, an online payment could be initiated, but a silent…

### Issue:
On a Mexican sale order, it was possible to have an invalid partner address while `CFDI to Public` was not enabled
In this situation, an online payment could be initiated, but a silent error occurred during move validation:
the transaction was created, but the payment was never recorded, and no error appeared in the portal or the SO chatter

### Cause:
The CFDI validation error is raised internally but never surfaced to the user
https://github.com/odoo/enterprise/pull/91655
The PO (MIAL) recommended automatically enabling `CFDI to Public` when the partner address is incomplete,
forcing the user to complete the data This also ensures that the payment can be confirmed properly

### Steps to reproduce:
- Install `l10n_mx_edi_sale` and switch to the MX company
- Configure a Payment Provider and Payment Method (e.g., demo)
- Create a customer without ZIP or country
- Create a Sale Order for that customer
- In Other Info, set Online Payment to 100%
- Send the quotation and open the link in a private window
- Sign and Pay

Before the fix: the transaction is created, but no payment is recorded, and no error is shown

opw-5023724

Forward-Port-Of: odoo/enterprise#101881

#mexico#edi#payments#cfdi

[FIX] web_gantt: handle rescheduling when date_{start,stop} are not d…

PR #105672

Enterprisemasterweb_ganttMEDIUM

This update resolves a bug that prevented the Gantt chart from correctly rescheduling tasks when using new Date fields instead of DateTime fields. The fix ensures that date-based rescheduling functions properly, improving the usability of the Gantt chart for project planning. This change was implemented after addressing a related issue in a previous pull request.

Original PR description

…atetime

Steps to reproduce
==================

- Install web_studio,project
- Open a project task
- Open studio
- Add a new Date field in the form view
- Switch to the gantt view
- Change the Start Date Field to the newly create Date field
- Exit studio
- Open a task
- Set a value for the date field
- Switch to the gantt view
- Drag the record

```
start_date_field_name in vals and datetime.strptime(vals[start_date_field_name], '%Y-%m-%d %H:%M:%S')
                                           ^^^^^^^^
ValueError: time data '2025-12-22' does not match format '%Y-%m-%d
```

Cause of the issue
==================

Since https://github.com/odoo/enterprise/pull/84820 , it only works for DateTime fields

opw-5345470

Forward-Port-Of: odoo/enterprise#104751
Forward-Port-Of: odoo/enterprise#103068

#gantt#scheduling#date

Steps to reproduce: Create a user with admin access rights for Manufacturing and Quality only. Then, create a work center that has a cost per hour. Create a product that has a BoM and create a MO then confirm it. Add a work order that takes place in the created work center and has duration of 60 mins. Using the created user, try to "Produce All". Issue: The user gets an access error when trying to "Produce All", eventhough they have manufacturing access rights. Fix: Add sudo access where the process fails to ensure that the workflow is as expected. Note: a test will be added in anoher PR opw-5480608 Forward-Port-Of: odoo/enterprise#104897

This PR https://github.com/odoo/enterprise/pull/99418 broke the bank vat reported in payment cfdi. The vat should not be reported in case there is no bank account (or the bank has no country), but a foriegn bank vat was reported instead. This commit fixed this issue by checking the bank country along with its VAT before reporting its VAT. task-5745608

Previously, generating the budget.report table was necessary to trigger _compute_all for budget.line fields. This table was built using three separate queries with a UNION operator. Because of the UNION, any filtering (like on specific budget_line_ids) happened after the full, unfiltered table was generated. This post-filtering caused slowness, especially in nested loop joins with large tables like account.analytic.line. This commit optimizes performance by pushing the filter condition (using specific budget_line_ids) directly down into the three underlying queries. This reduces the number of budget.line records processed, speeding up joins and overall computation. The benchmark below is done on a database that has **66396** `budget.line` records and **928567** `account.analytic.line` records. Opening a budget report for a specific year, only applied the filter with **40** `budget.line` records. | Scenario | Execution Time | | :--- | :--- | | **Before this Commit** | **60.00 seconds** | **After this Commit** | **1.84 seconds** opw-5150569 Forward-Port-Of: odoo/enterprise#102918 Forward-Port-Of: odoo/enterprise#99096

Steps to reproduce: ------------------- 1. Install pos_settle_due and accountant 2. In Accounting settings, enable "Sales Credit Limit" 3. Create a new customer, enable its "Partner Limit" and set it to 100 4. Open PoS, select that partner, and select products such that the total exceeds 100 Notice that even though we have exceeded that partner's limit of 100, there are no indicators on the customer button (orange background on hover), nor there are warnings on the partners list modal nor on the payment page. Why the bug ----------- In `getPartnerCredit`, we are using `order.amount_total` to get the current ordre amount, however, this field is `undefined` for a new order and it's been assigned a value in `setOrderPrices`, which since [9538698](https://github.com/odoo/odoo/commit/9538698), is only called before sending the order to the backend. The fix ------- Now we read the total amount from the getter `order.priceIncl`, and round it as we would do in `setOrderPrices`. opw-5489975 Forward-Port-Of: odoo/enterprise#105548 Forward-Port-Of: odoo/enterprise#104591

Opening the Shop Floor via the replenishment/forecast flow can raise a js traceback. **Steps to produce:** - Install `mrp` module. - Enable `multi-step routes` from the settings. - Inventory > Configuration > Warehouse Management > Routes. - In Manufacture route, make sure route is Applicable On `products`. - Inventory > Products > Products > New. - Click on forcasted button on product > Click on replenish button > Confirm. - Click the Manufacturing Order shown in the notification. - Confirm the MO and click Shop Floor. **Issue:** A JavaScript error occurs: `TypeError: Cannot read properties of null.` **Root cause:** The Shop Floor view relies on the menu service to determine the current application name by calling `this.menu.getCurrentApp().name`. When the Shop Floor is opened from the replenishment/forecast flow, the navigation occurs through action-based triggers rather than through the main menu. As a result, no menu selection is performed and `setCurrentMenu()`[1] is not executed beforehand.This leaves the current application undefined, causing `menu.getCurrentApp()` to return undefined and leading to a js traceback when `.name` is accessed. [1]: https://github.com/odoo/odoo/blob/c646cb61d0752250b2600413d6d63deabd1d3e6d/addons/web/static/src/webclient/menus/menu_service.js#L57-L64 simillar fix : https://github.com/odoo/enterprise/pull/93043 Note: A tour is possible but unnecessary for this small use-case. opw-5462965 --- Forward-Port-Of: odoo/enterprise#104706

Step to reproduce: - install `l10n_it_pos` - setup Italian fiscal printer for a pos - refund a order and print receipt Observation: receives a traceback ```js Caused by: TypeError: ctx.this.order.getRefundInfo is not a function at Header.template (eval at compile (https://97822380-19-0-design-theme.runbot118.odoo.com/web/assets/debug/point_of_sale.assets_prod.js:16388:20), <anonymous>:11:62) (/web/static/lib/owl/owl.js:5807) at Fiber._render (https://97822380-19-0-design-theme.runbot118.odoo.com/web/assets/debug/point_of_sale.assets_prod.js:12364:38) (/web/static/lib/owl/owl.js:1783) at Fiber.render (https://97822380-19-0-design-theme.runbot118.odoo.com/web/assets/debug/point_of_sale.assets_prod.js:12356:18) (/web/static/lib/owl/owl.js:1775) at ComponentNode.initiateRender (https://97822380-19-0-design-theme.runbot118.odoo.com/web/assets/debug/point_of_sale.assets_prod.js:13036:23) (/web/static/lib/owl/owl.js:2455) ``` Cause: - A <Header/> component is used in invoices, which requires a method `getRefundInfo`. - commit [1] removes <Header> and its related files, - commit [2] removes dead code, hence removed `getRefundInfo` - commit [3] brings back <Header>, but the method was not reintroduced [1] https://github.com/odoo/enterprise/commit/3d532f6ee99884bce58a577eb68464e670fb059a [2] https://github.com/odoo/enterprise/commit/1b03fe15916b7b86f79efcbb63895ae0c4363ef9 [3] https://github.com/odoo/enterprise/commit/d745a72e3f43febb3b39054dc9315eca13d86e36 Fix: - Add the method back After fix: **image from simulator** <img width="600" height="300" alt="image" src="https://github.com/user-attachments/assets/f6caccca-caf6-477f-bf37-f942090535cc" /> opw-5485350 Forward-Port-Of: odoo/enterprise#105048

Add special key for tours that require a delay between steps to not crash. It concerns more or less 220 tours on average 1600. The goal is to remove this key and fix the tour to make it deterministic (remove random errors).

The SYSCOHADA gross margin is defined on page 330 - 331 of the document [Guide-d-application-du-SYSCOHADA.pdf](https://www.ohada.com/uploads/actualite/3504/Guide-d-application-du-SYSCOHADA.pdf). It is TA (701) - RA (601) +/- RB (6031). TA and RA should always be positive and negative, respectively. In the report "Profit and Loss (SYSCOHADA)", the line RA is negated. XA then subtracts this value from TA, adding the two values instead of subtracting them. Steps to reproduce: 1. Create a new company on runbot. 2. In Accounting > Configuration > Settings, set their Fiscal Localization to Ginea - SYSCOHADA for Companies. 3. Make a MISC journal entry. 1. Set a credit of 110,000,000 on account 701100 and balance it with 411100. 5. Set a debit of 75,000,000 on account 601100 and balance it with 401100. 6. Set a credit of 5,000,000 on account 603100 and balance it with 411100. 7. Post the entry. 8. Navigate to Accounting > Reports > Profit and Loss. 9. Set the l10n version, Profit and Loss (SYSCOHADA). 10. Set the current date. 11. See XA = 110 million + 75 million + 5 million = 190 million; this does not match the example given on pg 357 of Guide-d-application-du-SYSCOHADA.pdf, where XA = 40 million. [opw-5482300](https://www.odoo.com/odoo/project.task/project.task/5482300) Forward-Port-Of: odoo/enterprise#104736 Forward-Port-Of: odoo/enterprise#104479

Fix SAF-T export errors when partners have no country or name. For Romanian companies, the RegistrationNumber should be generated as “04 + partner ID” for customers not subject to VAT and with unknown CNP, without including the country code. Steps to reproduce country issue: - Configure a Romanian company with l10n_ro_saft installed - Create a contact without a country - Create and validate an invoice for this contact - Export the SAF-T file from the General Ledger report You you will get a TypeError because you cant concatenate Bool and String. Steps to reproduce name issue: - Create a main contact - Add a child contact without a name - Change the child type to “Company” - Create and validate an invoice - Export the SAF-T file from the General Ledger report This prevents KeyError when printing the first 70 characters of the partner name in the report. opw-5499918 Forward-Port-Of: odoo/enterprise#105579 Forward-Port-Of: odoo/enterprise#105020

In this commit we change some important llm api usage logs from debug to info so they can be more easily monitored by us and database admins. We also change the usage reporting from a naive estimation (which greatly under-reported the token usage) to the actual token usage given to us by the LLM prodivers in the response. Forward-Port-Of: odoo/enterprise#105627 Forward-Port-Of: odoo/enterprise#105364

**Steps to reproduce:** - Setup a database that supports NFC-e - Go to PoS, make a purchase, then refund it - A traceback appears, saying we couldn't find the original invoice **Why the fix:** Before this commit the way we checked if there was already an invoice in the payload we give to the API was wrong, as it was always true. This happens because before the *def _get_l10n_br_avatax_service_params(self):* call, we set res['invoice_refs'] as {}, then we were supposed to fill it. But if we check https://github.com/odoo/enterprise/blob/32b73b12f9f8f5600b820d9a938bfbb0cf10054d/l10n_br_edi_pos/models/account_move.py#L13 'invoice_refs' is found in res, even though it is empty, so we never entered the if statement. We now check if there is a value in res['invoice_refs'] and if not we set it. opw-5359407 Forward-Port-Of: odoo/enterprise#104987 Forward-Port-Of: odoo/enterprise#102770

### Issue: On a Mexican sale order, it was possible to have an invalid partner address while `CFDI to Public` was not enabled In this situation, an online payment could be initiated, but a silent error occurred during move validation: the transaction was created, but the payment was never recorded, and no error appeared in the portal or the SO chatter ### Cause: The CFDI validation error is raised internally but never surfaced to the user https://github.com/odoo/enterprise/pull/91655 The PO (MIAL) recommended automatically enabling `CFDI to Public` when the partner address is incomplete, forcing the user to complete the data This also ensures that the payment can be confirmed properly ### Steps to reproduce: - Install `l10n_mx_edi_sale` and switch to the MX company - Configure a Payment Provider and Payment Method (e.g., demo) - Create a customer without ZIP or country - Create a Sale Order for that customer - In Other Info, set Online Payment to 100% - Send the quotation and open the link in a private window - Sign and Pay Before the fix: the transaction is created, but no payment is recorded, and no error is shown opw-5023724 Forward-Port-Of: odoo/enterprise#101881

…atetime Steps to reproduce ================== - Install web_studio,project - Open a project task - Open studio - Add a new Date field in the form view - Switch to the gantt view - Change the Start Date Field to the newly create Date field - Exit studio - Open a task - Set a value for the date field - Switch to the gantt view - Drag the record ``` start_date_field_name in vals and datetime.strptime(vals[start_date_field_name], '%Y-%m-%d %H:%M:%S') ^^^^^^^^ ValueError: time data '2025-12-22' does not match format '%Y-%m-%d ``` Cause of the issue ================== Since https://github.com/odoo/enterprise/pull/84820 , it only works for DateTime fields opw-5345470 Forward-Port-Of: odoo/enterprise#104751 Forward-Port-Of: odoo/enterprise#103068