Friday, February 27, 2026
12 changes · 18.0
New functionality added to Odoo
This update adds optional fields to Peppol invoices, resolving a previous issue where users couldn't send fully compliant invoices. Now, through the studio interface, users can incorporate necessary optional fields and attributes, ensuring adherence to Peppol standards and facilitating smoother invoice processing.
Original PR description
Currently, several specific UBL fields are lacking from our Peppol integration, resulting in users not being able to send compliant invoices Using studio, they can now add the optional fields that are allowed by us and their optional attributes TODO: Add Test case task-4963157
Resolved issues and error corrections
This update fixes a silent error in the Point of Sale module that prevented users from generating invoices when an untrusted bank account was associated with a customer. Now, a popup will clearly display the error, such as 'untrusted bank account,' guiding the user to correct the issue and complete the invoice process. This enhancement ensures smoother transactions and prevents potential data discrepancies.
Original PR description
Steps to reproduce: - Add untrusted bank account to the database's selected company's contact - Finalize an order in point of sale through register - While in register, go to orders and click on the invoice button for the finalized order Current behavior: - There is no indication of why you can't generate an invoice Expected behavior: - There should be a popup to the user identifying the error (e.g. untrusted bank account) This addresses a side effect of: https://github.com/odoo/odoo/pull/248108 opw-5946239
This update corrects a potential issue where calculations on payslip lines could become out of sync, leading to inaccurate payroll reports. The change ensures that all related data is consistently updated, improving the reliability of payroll processing. This resolves a technical problem that could have impacted payroll accuracy.
Original PR description
Forward-Port-Of: odoo/enterprise#108729
This update addresses random errors occurring during Point of Sale (PoS) testing, primarily identified by Runbot. The issue stemmed from prematurely ending tests before all requests were processed, and a subsequent problem where all products were unavailable in PoS and Self-Order modules. This fix ensures more stable testing and improved PoS functionality.
Original PR description
https://runbot.odoo.com/odoo/runbot.build.error/241044 We were not waiting the last request to be processed before ending the test, which could cause some random errors. https://runbot.odoo.com/odoo/runbot.build.error/241151 All products were not available in PoS and Self, which caused some errors on community builds.
This update fixes an issue where the stock forecast report incorrectly displayed reserved stock from sublocations as negative values in 'Free Stock in Transit'. Previously, when a delivery was created from a sublocation, the system wasn't properly updating the 'Free Stock' report. This change ensures accurate stock reporting, providing a clearer view of available inventory.
Original PR description
If you create & reserve a move from a sublocation of the main stock location, the forecast report would put this reserved quantity as a negative line in "Free Stock in Transit" instead of removing it from the "Free Stock". ## Steps to reproduce: - Create sub location WH/Stock/A - Put 20 unit of a storable product P in WH/Stock/A - Create Delivery todo in future of 5 units of P, from WH/Stock/A => Check Forecasted report, Free Stock = 20 | Free Stock in Transit = -5 OPW-5953172 --- <img width="1827" height="784" alt="image" src="https://github.com/user-attachments/assets/57c0b130-3916-4b35-9dad-e642f5319591" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250148
This update ensures One Stop Shop (OSS) invoices for intra-EU B2C sales meet Italian Revenue Agency requirements. The system now correctly generates invoices by splitting out VAT information, resolving previous rejection issues with the FatturaPA system. This ensures accurate and compliant e-invoicing for Italian customers.
Original PR description
This commit aligns the Italian e-invoicing (FatturaPA) generation for One Stop Shop (OSS) transactions with the requirements of the Italian Revenue Agency ( Agenzia delle Entrate). Current behavior:…
This commit aligns the Italian e-invoicing (FatturaPA) generation for One Stop Shop (OSS) transactions with the requirements of the Italian Revenue Agency ( Agenzia delle Entrate). Current behavior: Invoices for intra-EU B2C sales (OSS) are generated with a single line containing the foreign VAT rate. This is rejected or considered non-compliant by the SDI because foreign VAT cannot be typically exposed in the standard way for Italian electronic invoices. New behavior: The XML generation logic has been updated to follow the specific codification required for OSS operations: 1. Invoice Lines (`DettaglioLinee`): - The product line is reported with 0% VAT and Nature 'N7' (VAT paid in another EU member state). - A new, separate line is injected to represent the VAT amount, classified with Nature 'N2.2' (Non-taxable/Other). 2. Tax Summary (`DatiRiepilogo`): - The original foreign tax lines are excluded from the summary. - Synthetic summary lines are added for the 'N7' (Taxable Base) and 'N2.2' (VAT Amount) categories. Implementation details: - Added `_l10n_it_is_oss_tax` helper to identify OSS taxes. - Modified `_l10n_it_edi_get_line_values` to split OSS lines. - Modified `_l10n_it_edi_get_tax_values` to adjust the tax summary. task-4711509 Forward-Port-Of: odoo/odoo#243740
This update resolves an issue where updating a Bill of Materials (BoM) in a draft manufacturing order would incorrectly trigger the deletion of associated work orders, leading to errors. The fix ensures that work orders are only deleted when they are truly outdated, preventing these deletion attempts when components are added to the BoM.
Original PR description
Steps to reproduce: - Create a storable product P1 with the following BoM: - Component: C1 - Operation: OP1 - Create a draft MO for P1 - Update the BoM by adding a new component - Go back to the MO…
Steps to reproduce:
- Create a storable product P1 with the following BoM:
- Component: C1
- Operation: OP1
- Create a draft MO for P1
- Update the BoM by adding a new component
- Go back to the MO and click "Update from BoM"
Problem:
Missing Record
Record does not exist or has been deleted.
(Record: mrp.workorder(8,), User: 2)
Clicking on `update bom` will launch a call of the `action_update_bom`
which will itself call the `_link_bom` to update the record:
https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/mrp_plm/models/mrp_production.py#L73-L80
https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L2406-L2418
The function will sets `bom_id` to False, which triggers
`_compute_workorder_ids` and `_compute_move_finished_ids`
(depends on bom_id). As the MO is in draft, related moves and
workorders are deleted.
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L849
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L659
After that, it will try to delete the work orders again, and
since the operation no longer exists, an error will be triggered.
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L2586-L2587
opw-5947687
Forward-Port-Of: odoo/odoo#249336This update fixes an issue where invoices generated using the PEPPOL standard incorrectly displayed company registry information. Previously, the system didn't verify that company registries used the correct BCE number. This change ensures invoices comply with PEPPOL requirements, preventing potential errors and improving data accuracy.
Original PR description
We expect people to put BCE number in the company registry. But it is not enforced client-side, resulting in invoices in error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes issues related to error handling and XML generation within the l10n_hr_edi module. Specifically, it now presents credentials errors in a more user-friendly format and corrects how invoices are generated for partners without an OIB, ensuring accurate VAT and OIB data.
Original PR description
- Credentials errors have a separate format in MER, they should now be displayed in a more user-fiendly manner - Correcting XML generation for partners with no explicit OIB provided - Adding tests for both changes task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects an issue where payments for invoices paid within 30 days (PUE) were incorrectly sent to the Mexican tax authority (CFDI). The fix disables a feature that allowed this, ensuring accurate tax reporting and preventing potential compliance problems. This change improves the reliability of our Mexican accounting integration.
Original PR description
Issue: Sending PUE payments to CFDI/SAT is no more suitable Step to reproduce: - In a Mexican company - Create an invoice (Invoice A) - Add a line - Set Payment Terms to "Immediate payment" - Confirm…
Issue: Sending PUE payments to CFDI/SAT is no more suitable Step to reproduce: - In a Mexican company - Create an invoice (Invoice A) - Add a line - Set Payment Terms to "Immediate payment" - Confirm - Duplicate (Invoice B) - Confirm - Duplicate again (Invoice C) - Set Payment Terms to "30 days" - Confirm - Go to Invoice A - Pay it. It should appear as "Paid" - Send it to CFDI - Go to Accounting > Customer > Invoices - Select Invoice B and C - Pay and select the "Group Payments". They should appear as paid. - In every invoice, click the "Update Payment" button Current behavior: - In Invoice A -> Sheet CFDI: A button "Force CFDI" allow sending the payment to CFDI - In Invoice B/C -> sheet CFDI: Click on the "Download" part of the Payment line, the XML that was sent to CFDI include both invoice B and C Expected behavior: - It shouldn't be possible to send payment for invoice A to CFDI. - Payment for invoice B shouldn't be sent to CFDI Cause: Payment for invoice paid in less than 30 days, referred as PUE, shouldn't be sent to CFDI. Solution: Disable the force sending to CFDI About tests: l10n_mx_edi_cfdi_invoice_try_update_payments already send payment to CFDI for PPD invoices. Calling action_force_payment_cfdi was pointless and causing a mess. opw-5381600 Forward-Port-Of: odoo/enterprise#104628
This update fixes an issue where lot numbers weren't consistently displayed in POS sales orders when products were tracked by lot and stored in multiple locations. The fix ensures that all relevant lot numbers are accurately reflected, improving inventory accuracy and order fulfillment. It also addresses a related issue with stock movement processing.
Original PR description
When opening an SO in POS that has a product tracked by lot that is split into several location, the lot number will only appear in one of the line and not the others Steps to reproduce:…
When opening an SO in POS that has a product tracked by lot that is split into several location, the lot number will only appear in one of the line and not the others Steps to reproduce: ------------------- 1. Create a Product A tracked by lot, create lot 111 and add 1 unit to location A and another one to location B 1. Create a sales order 2. Add two units of the product to the sale order 3. Confirm the sales order 4. Open the transfer, make the transfer retrieve the product from several location with the same lot. 5. Save the transfer 6. Open the sales order in POS 7. Load the SN/lots -> Two line of qty 1 appear for the product A but only the first one has the lot number Additional Issue: 8. Change the number of the product for the first line to 2 and erase the second line 9. Confirm and Pay 10. Close POS 11. Open move lines for this product (Inventory>product>In/out) -> It moves 2 product from one location (when there is only product) Observation: ------------- When loading the SO in POS, we will retrieve the SO: https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/pos_sale/static/src/app/order_management_screen/sale_order_management_screen/sale_order_management_screen.js#L104 While retrieving the SO, we will also retrieve the SOL, with additional information: https://github.com/odoo/odoo/blob/d9b2e5ee730a4e79586bfd3f09adfb794d2dc1f3/addons/pos_sale/models/sale_order.py#L79 -> Issue is that when several moves_line have the sale lot_id.name, their quantity will be overwritten. Addition Issue : When closing pos, all the move will be processed, when processing those moves, the origin only check if the quantity is more than 0 and not if there is enought units. https://github.com/odoo/odoo/blob/cb1f5d9c6db64b9ace9b7aa46bd6f94e4462176b/addons/point_of_sale/models/stock_picking.py#L293-L297 opw-5347992 Forward-Port-Of: odoo/odoo#243347
This update resolves an issue preventing users from replying to messages received from other companies within Odoo. Previously, attempts to respond resulted in an error. Now, replies are correctly logged when the user has access to the company from which the message originated, improving communication across multiple businesses.
Original PR description
Before these changes, messages from other companies were received, but when trying to reply to them, an error occurred that prevented the response. Steps to reproduce the issue in runbot: 1. In one tab, log in as admin, and in another incognito tab, open demo. 2. Make sure demo has Handle Notifications in Odoo enabled. 3. Set admin in one company and demo in another company. 4. Assign a task to demo. 5. Click on the notification to open the chatter and try to reply. An error is thrown With these changes, the response can be logged when the user has access to the company from which the task was assigned. cc @Tecnativa TT61176 ping @pedrobaeza --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr