Odoo Changelog — 2026-07-27

Monday, July 27, 2026

5 changes · saas-18.4

Bug Fixes(5)

Resolved issues and error corrections

[FIX] stock_barcode_mrp: prevent traceback on scrap open

Enterprisesaas-18.4stock_barcode_mrpMEDIUM

Opening the Scrap option from a new manufacturing barcode operation no longer triggers an error when no location record is available. This keeps the workflow usable for staff creating manufacturing orders and also prevents a related crash when scanning products with consignment enabled.

Original PR description

Versions
--------
- 18.0+

Steps
-----
1. Open Barcode app;
2. click Operations;
3. click MANUFACTURING
4. click New;
5. click cogwheel on top right;
6. click Scrap.

Issue
-----
Traceback:
> Error: Record stock.location with id=undefined doesn't exist in the cache

Cause
-----
When setting up the default context for the scrap menu, it it assumes `this.record` is not empty.

Solution
--------
Make `cache.getRecord` not raise an error when a location isn't found. Use optional chaining for other parts of the context that rely on a `record` being present.

Also fixes a related issue introduced by 4b457fe, where the same traceback would be thrown on opening a new MO and scanning a product whilst consignment is enabled.

opw-6397774

Forward-Port-Of: odoo/enterprise#125442
Forward-Port-Of: odoo/enterprise#124818

#barcode#manufacturing#scrap#stability

[FIX] l10n_ch_hr_payroll_elm_transmission: Prevent traceback in case of rule archive

PR #125614

Enterprisesaas-18.4l10n_ch_hr_payroll

This fix prevents Swiss payroll processing from failing when a related salary rule has been archived. It helps payroll teams avoid interruptions and ensures historical or inactive rules do not cause unexpected errors during ELM transmission workflows.

Original PR description

Forward-Port-Of: odoo/enterprise#103677

#swiss-payroll#elm#stability

[FIX] documents_account_peppol: use correct peppol journal requirements

PR #120720

Enterprisesaas-18.4documents_account_peppolMEDIUM

The Peppol settings now apply the right journal requirement depending on whether invoice imports are handled through Documents, especially when French PDP features are installed. This prevents non-French companies from being incorrectly forced to select a purchase journal when a Documents folder is already configured, and ensures imports go only to the chosen destination.

Original PR description

Fixes the settings view for the account_peppol_purchase_journal_id. account_peppol, documents_account_peppol and l10n_fr_pdp all wants to use a specific condition for the required attribute of the view.

With PDP especially, once l10n_fr_pdp is installed, the view forces the base condition, even if documents_account_peppol is installed, and even if the company is not even French. On a non-French company registered/registering on Peppol, the journal shouldn't be mandatory if documents_account_peppol_folder_id is set up.

To ease things up, it is now using a computed field.

task-6304479

Forward-Port-Of: odoo/enterprise#120719

#peppol#settings#documents#invoicing

[FIX] l10n_gt_edi: report the correct invoice date in credit notes

PR #125251

Enterprisesaas-18.4l10n_gt_ediMEDIUM

Guatemalan credit notes now reference the original invoice’s actual issue date instead of a technical certification timestamp. This helps prevent SAT rejections when credit notes are issued on a different date from the original invoice.

Original PR description

### Issue before this commit: When reverting a Guatemalan invoice (creating a credit note), the XML node FechaEmisionDocumentoOrigen incorrectly reports the EDI document's technical certification…

### Issue before this commit:
When reverting a Guatemalan invoice (creating a credit note), the XML node FechaEmisionDocumentoOrigen incorrectly reports the EDI document's technical certification date instead of the original invoice's emission date. This causes the SAT to reject the document.

### Steps to reproduce the issue:
1. Download Accounting and l10n_gt
2. Revert an invoice (credit note) inserting a different date than the one of the invoice
3. See that FechaEmisionDocumentoOrigen report the date of the credit note instead of the one of the invoice

### Cause of the issue:
The _l10n_gt_edi_add_reference_values method extracted the date from original_document.datetime (the technical timestamp of when the XML was generated) rather than using the actual accounting date of the original invoice.

### Reason to introduce the fix:
SAT validation rules strictly require the reference date to match the exact commercial emission date of the original invoice. Fetching invoice_date directly ensures compliance, avoids timezone conversion errors, and prevents the XML from being rejected.
Source: https://www.lawinsider.com/es/contracts/dJXl4Vo79L2

<img width="730" height="205" alt="2026-07-17_10-19" src="https://github.com/user-attachments/assets/802e7bb3-fcf9-48db-b86f-227b494001b6" />

opw-6394409

Forward-Port-Of: odoo/enterprise#124794

#Guatemala#EDI#credit notes#invoicing#SAT

[FIX] stock_barcode: prevent double selected line with packages

PR #125356

Enterprisesaas-18.4stock_barcodeMEDIUM

The barcode app now correctly keeps only one delivery line selected when an operation contains both packaged and unpackaged products. This prevents confusion for warehouse users and reduces the risk of acting on the wrong line during scanning.

Original PR description

**Steps to reproduce:**

- Enable "Move Entire Packages" setting on deliveries
- Make a product A, that has a package P1, on hand qty of 1
- Make product B that don't have a package, but on hand qty of 1
- Make a delivery that has both of those products, requested qty of 1 for both
- Mark it as todo
- Go to the barcode app, select the delivery
- Select the line with product B
- Select the line with product A
--> The line with product B is not unselected

**Why the fix:**

When we have a mix of packaged products and products without a package on the same operation, they are handled separately.
The products without a package are handled in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L388-L392 
that calls https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1277-L1284 
But as you can see, there are no mention of the selected package line, which is stored in **this.lastScanned.packageId**.

As we do not touch this variable, the selected package line stays selected.

The same is true for the other way around, when we select a package line we call https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L394-L398 
This function does not care for the **selectedLineVirtualId** which represents the selected line without a package.

To avoid this and make it so that only one line is selected even if they have different package, we now set the corresponding value to false to unselect the other line in all situation.

This is basically how it's done in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1202-L1208 
to unselect every line regardless of packages.

opw-6266203

Forward-Port-Of: odoo/enterprise#125223
Forward-Port-Of: odoo/enterprise#122038

#barcode#inventory#deliveries#packages

Versions -------- - 18.0+ Steps ----- 1. Open Barcode app; 2. click Operations; 3. click MANUFACTURING 4. click New; 5. click cogwheel on top right; 6. click Scrap. Issue ----- Traceback: > Error: Record stock.location with id=undefined doesn't exist in the cache Cause ----- When setting up the default context for the scrap menu, it it assumes `this.record` is not empty. Solution -------- Make `cache.getRecord` not raise an error when a location isn't found. Use optional chaining for other parts of the context that rely on a `record` being present. Also fixes a related issue introduced by 4b457fe, where the same traceback would be thrown on opening a new MO and scanning a product whilst consignment is enabled. opw-6397774 Forward-Port-Of: odoo/enterprise#125442 Forward-Port-Of: odoo/enterprise#124818

Fixes the settings view for the account_peppol_purchase_journal_id. account_peppol, documents_account_peppol and l10n_fr_pdp all wants to use a specific condition for the required attribute of the view. With PDP especially, once l10n_fr_pdp is installed, the view forces the base condition, even if documents_account_peppol is installed, and even if the company is not even French. On a non-French company registered/registering on Peppol, the journal shouldn't be mandatory if documents_account_peppol_folder_id is set up. To ease things up, it is now using a computed field. task-6304479 Forward-Port-Of: odoo/enterprise#120719

### Issue before this commit: When reverting a Guatemalan invoice (creating a credit note), the XML node FechaEmisionDocumentoOrigen incorrectly reports the EDI document's technical certification date instead of the original invoice's emission date. This causes the SAT to reject the document. ### Steps to reproduce the issue: 1. Download Accounting and l10n_gt 2. Revert an invoice (credit note) inserting a different date than the one of the invoice 3. See that FechaEmisionDocumentoOrigen report the date of the credit note instead of the one of the invoice ### Cause of the issue: The _l10n_gt_edi_add_reference_values method extracted the date from original_document.datetime (the technical timestamp of when the XML was generated) rather than using the actual accounting date of the original invoice. ### Reason to introduce the fix: SAT validation rules strictly require the reference date to match the exact commercial emission date of the original invoice. Fetching invoice_date directly ensures compliance, avoids timezone conversion errors, and prevents the XML from being rejected. Source: https://www.lawinsider.com/es/contracts/dJXl4Vo79L2 <img width="730" height="205" alt="2026-07-17_10-19" src="https://github.com/user-attachments/assets/802e7bb3-fcf9-48db-b86f-227b494001b6" /> opw-6394409 Forward-Port-Of: odoo/enterprise#124794

**Steps to reproduce:** - Enable "Move Entire Packages" setting on deliveries - Make a product A, that has a package P1, on hand qty of 1 - Make product B that don't have a package, but on hand qty of 1 - Make a delivery that has both of those products, requested qty of 1 for both - Mark it as todo - Go to the barcode app, select the delivery - Select the line with product B - Select the line with product A --> The line with product B is not unselected **Why the fix:** When we have a mix of packaged products and products without a package on the same operation, they are handled separately. The products without a package are handled in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L388-L392 that calls https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1277-L1284 But as you can see, there are no mention of the selected package line, which is stored in **this.lastScanned.packageId**. As we do not touch this variable, the selected package line stays selected. The same is true for the other way around, when we select a package line we call https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L394-L398 This function does not care for the **selectedLineVirtualId** which represents the selected line without a package. To avoid this and make it so that only one line is selected even if they have different package, we now set the corresponding value to false to unselect the other line in all situation. This is basically how it's done in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1202-L1208 to unselect every line regardless of packages. opw-6266203 Forward-Port-Of: odoo/enterprise#125223 Forward-Port-Of: odoo/enterprise#122038