Odoo Changelog — 2026-07-03

Friday, July 3, 2026

3 changes · 17.0

Bug Fixes(3)

Resolved issues and error corrections

[FIX] point_of_sale: assign lot number on incoming stock moves during refund

Core17.0point_of_salestockMEDIUM

This update ensures that lot numbers are consistently applied to incoming stock movements created during Point of Sale refunds. Previously, the system wasn't correctly reusing the original lot number when a refund was processed, leading to inconsistencies in inventory tracking. This fix maintains accurate lot number traceability for products, improving inventory management.

Original PR description

Steps:
----------
- Install point_of_sale.
- Create a trackable product with a lot and add an on-hand quantity.
- Open a PoS config with "Ship Later" enabled.
- Place an order for the trackable product with a lot and ship later, then validate the delivery picking in Inventory.
- Refund the previous order from PoS and ship later, and check the receipt in Inventory.

Issue:
---------
- The delivery picking correctly assigns a lot number, but the corresponding receipt created during the refund does not.

Cause:
---------
- The system was not reusing the existing lot number when the picking type was incoming.

Fix:
--------
- Ensure the existing lot number is assigned to incoming pickings created during refunds.

task-5005122

#inventory#refunds#lot numbers#POS

[FIX] l10n_tr_nilvera_einvoice: store fetched PDF as valid PDF

PR #271711

Core17.0l10n_tr_nilvera_einvoiceMEDIUM

This update resolves an issue where PDF invoices from Nilvera were being corrupted due to incorrect storage. The fix ensures PDFs are properly decoded and stored as valid files, preventing invoice processing errors. This improves the reliability of invoice generation and submission.

Original PR description

## Short fix summary: The PDF fetched from Nilvera comes back as a base64 string. It was stored verbatim in the attachment's `raw` field (no decoding), producing a corrupt PDF. Store it in `datas`…

## Short fix summary:

The PDF fetched from Nilvera comes back as a base64 string. It was stored verbatim in the attachment's `raw` field (no decoding), producing a corrupt PDF. Store it in `datas` instead, which base64-decodes its input into a valid PDF.

### How it slipped in
The mocked test for PDF fetching never mirrored the real API response: it returned raw bytes instead of the base64 string Nilvera actually sends, and asserted nothing about the stored file. Because the mock misrepresented the response, a later fix for a `binascii.Error` on Python 3.14 was applied in the wrong layer, switching the attachment field from `datas` to `raw`. That silenced the error but stored the base64 text undecoded, corrupting the PDF. 
The mock on the test will be corrected on Forward port of 18.0 onward.

### Related PRs
- **#266718** — introduced the regression: switched the attachment field from `datas` to `raw` to silence a `binascii.Error` on Python 3.14, but stored the base64 text undecoded, corrupting the PDF.
- **#246884** — added the mocked test suite that misrepresented the Nilvera `/pdf` response (raw bytes instead of a base64 string), which masked the bug and made the wrong fix in #266718 appear correct.

task-6312640
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#invoice#nilvera#pdf#accounting

[FIX] industry_fsm_sale: return empty mail.message recordset instead of False

PR #119542

Enterprise17.0industry_fsm_saleMEDIUM

This update resolves a problem where automation rules on sales orders were failing due to an incorrect handling of messages. The fix ensures that automation messages are processed correctly, preventing errors and maintaining the expected behavior of sales order workflows. This improves the reliability of automated tasks.

Original PR description

Steps to reproduce:
----------------------------------------
1. Install `industry_fsm_sale` and `base_automation` modules
2. Create a product with:
    * Type: Service
    * Create on order: Task
    * Project: Field Service
3. Create an automation rule with:
    * Model: Sales order
    * Trigger: Incoming message
4. Create and confirm a sale order with this product
5. Add another product to the SO via the catalog view:
    * Change the quantity to 2 or more

Observation:
----------------------------------------
Traceback occurs:
```
  File '/home/odoo/src/odoo/addons/base_automation/models/base_automation.py', line 871, in _message_post
    message_sudo = message.sudo().with_context(active_test=False)
AttributeError: 'bool' object has no attribute 'sudo'
```

Root Cause:
----------------------------------------
* Catalog qty change calls `set_fsm_quantity()` method
* Setting `fsm_quantity` triggers its inverse `_inverse_fsm_quantity()`, which writes the new qty to the SOL, but passes `fsm_no_message_post=True` in context to suppress chatter noise
https://github.com/odoo/enterprise/blob/ac5d670832a5e0db714c0bd056e1406b50bb4c17/industry_fsm_sale/models/product_product.py#L72-L83
* `sale.order.line.write()` detects a qty change on a confirmed order and calls `_update_line_quantity()`, which posts a message on the parent sale order
* FSM's `message_post` override sees the context flag and returns `False`
* When `base_automation` has an `on_message_received` rule on `sale.order`, it wraps `message_post` at registry load time. That wrapper calls `sudo()` on whatever `message_post` returns, Which was `False`

Solution:
----------------------------------------
Return `self.env['mail.message']` (empty recordset) instead of False, it's still falsy, but it's a proper ORM object that `sudo()` can be called on

opw-6276916

#automation#sales order#fsm

Steps: ---------- - Install point_of_sale. - Create a trackable product with a lot and add an on-hand quantity. - Open a PoS config with "Ship Later" enabled. - Place an order for the trackable product with a lot and ship later, then validate the delivery picking in Inventory. - Refund the previous order from PoS and ship later, and check the receipt in Inventory. Issue: --------- - The delivery picking correctly assigns a lot number, but the corresponding receipt created during the refund does not. Cause: --------- - The system was not reusing the existing lot number when the picking type was incoming. Fix: -------- - Ensure the existing lot number is assigned to incoming pickings created during refunds. task-5005122

## Short fix summary: The PDF fetched from Nilvera comes back as a base64 string. It was stored verbatim in the attachment's `raw` field (no decoding), producing a corrupt PDF. Store it in `datas` instead, which base64-decodes its input into a valid PDF. ### How it slipped in The mocked test for PDF fetching never mirrored the real API response: it returned raw bytes instead of the base64 string Nilvera actually sends, and asserted nothing about the stored file. Because the mock misrepresented the response, a later fix for a `binascii.Error` on Python 3.14 was applied in the wrong layer, switching the attachment field from `datas` to `raw`. That silenced the error but stored the base64 text undecoded, corrupting the PDF. The mock on the test will be corrected on Forward port of 18.0 onward. ### Related PRs - **#266718** — introduced the regression: switched the attachment field from `datas` to `raw` to silence a `binascii.Error` on Python 3.14, but stored the base64 text undecoded, corrupting the PDF. - **#246884** — added the mocked test suite that misrepresented the Nilvera `/pdf` response (raw bytes instead of a base64 string), which masked the bug and made the wrong fix in #266718 appear correct. task-6312640 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Steps to reproduce: ---------------------------------------- 1. Install `industry_fsm_sale` and `base_automation` modules 2. Create a product with: * Type: Service * Create on order: Task * Project: Field Service 3. Create an automation rule with: * Model: Sales order * Trigger: Incoming message 4. Create and confirm a sale order with this product 5. Add another product to the SO via the catalog view: * Change the quantity to 2 or more Observation: ---------------------------------------- Traceback occurs: ``` File '/home/odoo/src/odoo/addons/base_automation/models/base_automation.py', line 871, in _message_post message_sudo = message.sudo().with_context(active_test=False) AttributeError: 'bool' object has no attribute 'sudo' ``` Root Cause: ---------------------------------------- * Catalog qty change calls `set_fsm_quantity()` method * Setting `fsm_quantity` triggers its inverse `_inverse_fsm_quantity()`, which writes the new qty to the SOL, but passes `fsm_no_message_post=True` in context to suppress chatter noise https://github.com/odoo/enterprise/blob/ac5d670832a5e0db714c0bd056e1406b50bb4c17/industry_fsm_sale/models/product_product.py#L72-L83 * `sale.order.line.write()` detects a qty change on a confirmed order and calls `_update_line_quantity()`, which posts a message on the parent sale order * FSM's `message_post` override sees the context flag and returns `False` * When `base_automation` has an `on_message_received` rule on `sale.order`, it wraps `message_post` at registry load time. That wrapper calls `sudo()` on whatever `message_post` returns, Which was `False` Solution: ---------------------------------------- Return `self.env['mail.message']` (empty recordset) instead of False, it's still falsy, but it's a proper ORM object that `sudo()` can be called on opw-6276916