Daily updates from Odoo
Wednesday, January 28, 2026
7 changes · 19.0
Resolved issues and error corrections
This update fixes an error in the SYSCOHADA Profit and Loss report where the gross margin calculation was incorrectly adding instead of subtracting values. The change ensures the report accurately reflects the financial data as defined in the SYSCOHADA guidelines, preventing reporting discrepancies.
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…
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#104479This update resolves issues preventing accurate SAF-T file generation for Romanian companies when partner information (country or name) is incomplete. Specifically, it corrects errors related to generating the RegistrationNumber and prevents report errors caused by missing partner details, ensuring compliance with Romanian accounting regulations.
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
This update resolves an issue where sale orders with missing customer address information in Mexico prevented successful online payments. The fix automatically enables 'CFDI to Public' when the address is incomplete, ensuring proper payment confirmation and preventing silent transaction errors. This improves the reliability of Mexican sales transactions.
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
This update fixes an issue where dialog windows were hidden behind chat windows, making them difficult to use. Now, the AI chat window remains prominently displayed above all other dialogs, ensuring users can easily interact with both. This improves the overall user experience for the Enterprise platform.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ Dialogs were rendered behind chat windows, making them difficult to see and interact with. **Current behavior before PR:** --------------------------------- - The dialog appears behind the chat window **Desired behavior after PR is merged:** ----------------------------------------- - Dialogs are displayed above all chat windows except AI - The AI chat window remains intentionally above dialogs **Task:** 5367135 Forward-Port-Of: odoo/enterprise#103076
This update resolves an issue where signed documents were sometimes displayed incorrectly, showing fields that hadn't been filled in. The change ensures the document is refreshed after loading, guaranteeing a complete and accurate view of the signed document for users. This improves the user experience and prevents confusion.
Original PR description
Ensure sign items are refreshed after the PDF iframe is fully loaded to avoid displaying partially signed documents without fields when not in sign mode. task-5877678
This update fixes an issue where editing component quantities on the shop floor incorrectly displayed all internal locations instead of just the source location. The fix ensures that only the intended source location is considered when updating component quantities, improving accuracy in work order management. This resolves a previous bug impacting inventory tracking.
Original PR description
In the shop floor when you edit the quantity of components, all the components for the internal localization will appear instead of only the one from the source location
Steps to reproduce:
-------------------
- Active lot/serial number in settings
- Create component A tracked by lot, and add quantities in two location (WH/stock and WH/random)
- Create a product with a bom that use component A
- Create an operation for that bom
- Update the bom to consume the component during the operation
- Create a workorder for the product, confirm it and go to the shop floor
- Click on the operation
- Edit the quantity of components
-> all internal localisation appear (WH/{stock/random})
Observation:
-------------
The domain consider all localisation where the usage is internal: https://github.com/odoo/enterprise/blob/e99c20547528f6664d091cd230ce94cf76a08eb1/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L119
opw-5268989This update ensures salary configuration personal information is automatically populated using the employee's most recent version, regardless of whether it's a standard offer or a contract template. This eliminates inconsistencies and provides a more accurate and up-to-date salary setup process for all employees.
Original PR description
The personal informations in the salary config is prefilled using the version selected in the offer. When making a new offert for an already employed person, the default version is the last active version, the address and other personal info are already set on that version and the salary has the last up-to-date data. But when selecting a contract template in an offer, the version does not have the personal info from the employee (as it's a template). In this commit, we force to use the employee itself (from the active version of the employee, or the employee linked to the contract template copy - created during the offer creation). may it be an applicant or an existing employee, when an offer is generated, an employee is created (or re-used) and set on the contract template. So it works in every case. Taks-5162703 Forward-Port-Of: odoo/enterprise#99908