Odoo Changelog — 2025-11-22

Saturday, November 22, 2025

3 changes · 18.0

Bug Fixes(3)

Resolved issues and error corrections

[FIX] pos_blackbox_be: incorrect data parsing on retry

Enterprise18.0pos_blackbox_beMEDIUM

This update corrects how the POS black box reads responses after a retry. It now handles repeated replies properly, which helps prevent errors when a device does not restart its message the same way on subsequent attempts.

Original PR description

when sending NACK to the bb, it keeps replying but without starting by ACK. We the need to adapt to only parse ACK on the first time.

#pos#hardware#retry#parsing

[FIX] l10n_eu_oss: wrong call to self in loop

PR #236301

Core18.0l10n_eu_ossMEDIUM

This change fixes an error that could occur when refreshing OSS mapping while multiple companies were active. The system now handles the action correctly for the selected company, preventing the crash and letting users continue their work normally.

Original PR description

To reproduce:
- Activate multiple companies in the selector
- Enable OSS on the active company
- Click the refresh mapping button ===> Traceback, because a function expects to be called on a single company and is instead called on all the active companies.

Forward-Port-Of: odoo/odoo#236103

#oss#multi-company#crash#refresh

[FIX] account: do not copy `invoice_origin` on 'account.move'

PR #236967

Core18.0accountMEDIUM

When a customer invoice is duplicated, it will no longer keep the original sales order as its source document. This avoids incorrect information being shown on copied invoices and prevents external reporting or electronic invoicing systems from using outdated source data.

Original PR description

Currently we copy the `invoice_origin` field on moves (when copying / duplicating moves).
I.e. when copying a move that was created from a SO we end up with the `invoice_origin` filled on the copied move (but the
 SO is not linked and does not really have anything to do with the
 move anymore)

This can i.e. lead to issues in EDIs (`l10n_es_edi_verifactu` like in the ticket) that send the `invoice_origin` as part of the data about the move.

Reproduce
1. Create a sales order (SO).
2. Create an invoice from the SO (and confirm). You can see that the SO is linked at the top (smart button).
3. Copy the invoice (and confirm). You can see that the SO is not linked.
4. Go to the invoices list view and make the "Source Document" visible.
5. Both the invoices have the same SO as their "Source Document".

opw-5115495

Forward-Port-Of: odoo/odoo#236656

#invoice#copy#source document#EDI#sales order

To reproduce: - Activate multiple companies in the selector - Enable OSS on the active company - Click the refresh mapping button ===> Traceback, because a function expects to be called on a single company and is instead called on all the active companies. Forward-Port-Of: odoo/odoo#236103

Currently we copy the `invoice_origin` field on moves (when copying / duplicating moves). I.e. when copying a move that was created from a SO we end up with the `invoice_origin` filled on the copied move (but the SO is not linked and does not really have anything to do with the move anymore) This can i.e. lead to issues in EDIs (`l10n_es_edi_verifactu` like in the ticket) that send the `invoice_origin` as part of the data about the move. Reproduce 1. Create a sales order (SO). 2. Create an invoice from the SO (and confirm). You can see that the SO is linked at the top (smart button). 3. Copy the invoice (and confirm). You can see that the SO is not linked. 4. Go to the invoices list view and make the "Source Document" visible. 5. Both the invoices have the same SO as their "Source Document". opw-5115495 Forward-Port-Of: odoo/odoo#236656