Daily updates from Odoo
Monday, December 1, 2025
7 changes · 18.0
Enhancements to existing features
This update enhances the user experience by providing clearer placeholders for Peppol identifiers and automatically verifying this information when key data changes. A new feature has been added specifically for Belgium, leveraging the VAT number to streamline the Peppol identifier process through the company registry endpoint. This improves data accuracy and simplifies integration for Belgian businesses.
Original PR description
This commit improves the UX by displaying more intuitive placeholders for the peppol identifier. The peppol information is also automatically verified when important data changes. It also adds a special case for Belgium in which we try to use the vat number as the peppol identifier with the company registry endpoint. task: 5172378
Resolved issues and error corrections
This update fixes a bug where changes to spreadsheet sale inputs were unexpectedly lost due to system updates or user actions. Now, changes made to the input are reliably saved, ensuring data accuracy and a smoother user experience. This resolves a previous issue impacting data consistency.
Original PR description
Currently, the FieldSync record input suffers from two issues: 1) The input value can be reset by parasitic renders While the user is inputting a value, if they did not confirm it and a global render occurs (other user joining the session, dragging the mouse on the grid), the input value will be reset to the one stored in the plugin, therefore erasing the last change of the user 2) In Chrome-based navigators, users can change the value of the input by using their mouse scrolling wheel. Such action *does not* trigger an `onChange` event; which means that the new value is never directly saved. Both issues are addressed in this commit by keeping an internal state inside the component `FieldSyncSidePanel` and ensure this state is properly reflected in the plugin once we stop editing the input. Task-5123069
This update resolves a critical issue that caused the generation of payroll export files to fail. The fix corrects a naming discrepancy in the code, ensuring accurate retrieval of employee data. A new test suite has been implemented to guarantee the reliability of the export process.
Original PR description
The export generation crashed due to a mismatch between field names — the code was referencing employee_ids, while the model actually defines employee_id. Since the Prisma code is now stored on the employee model, the logic was updated to correctly access the employee_id field and retrieve the related Prisma code. Additionally, a comprehensive test suite was added to validate Prisma code behavior, including: - validation of code length for employees, companies, and work entry types, - handling of codes across different companies, - and the complete Prisma export flow (from work entry creation and validation to export file generation). task-5153727
This fix resolves an issue where stock valuations were incorrect after splitting a purchase order receipt into a batch and validating the batch. The problem stemmed from how the system calculated values during batch validation, leading to miscalculated stock values. This update ensures accurate stock valuations are generated when using batch billing.
Original PR description
…n batch billed on ordered qty **Problem:** When the picking of a purchase order (of a product billed on ordered quantity) is split into different moves and put in a batch, at batch validation, svls…
…n batch billed on ordered qty
**Problem:**
When the picking of a purchase order (of a product billed on ordered quantity) is split into different
moves and put in a batch, at batch validation, svls are created with the wrong values.
**Steps to reproduce:**
- enable "Batch, Wave & Cluster Transfers" settings
- create a storable product with a standard price of 1
- set the category as avco
- in the Purchase tab select the control policy as
"on ordered quantities"
- create and confirm a purchase order for 50 of this product
- on the Receipt, change the quantity to 20 and split the
picking
- go back the the PO and create and confirm a bill for
the full amount
- click on the receipt smart button
- select the two pickings and then the 'Action' button
- select add to batch
- check 'new batch transfer' and confirm
- open the batch and validate it
- open stock valuation
**Current behavior:**
the newly created svls have total values of
50 and 50.10
**Expected behavior:**
it should be 20 and 30
**Cause of the issue:**
When the batch is validated, _action_done is called
on the two stock moves.
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/stock/models/stock_picking.py#L1258
In the stock_account override:
- first the super method is called
As a consequence the state of the two moves becomes 'done'
and the qty_received of the linked purchase order line becomes 50.
- then product_price_update_before_done is called before creating
the svls.
Inside product_price_update_before_done we call _get_price_unit.
In the purchase_stock override of _get_price_unit :
- because the super method of action_done was already called,
qty_received of the purchase order line is 50, so _get_qty_received_without_self
will return 30.
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L50
So received_qty is 30 and later remaining_qty will be 20
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L86
- but because no svl was created yet receipt_value will stay 0 and later
remaining_value will be 50
https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/purchase_stock/models/stock_move.py#L55-L63
Therefore price_unit will be 2.5 (50/20) instead of 1
**fix**
We do not take into account the move(s) of the
same batch in the remaining value (because svls are not created yet)
so we should not take them into account in the remaining quantity.
opw-5179581This update resolves an issue where Sale Orders with lot-tracked products were incorrectly duplicated during import into POS. The fix prevents unnecessary line splits based on unit of measure, ensuring accurate order processing and avoiding data inconsistencies. This improves the reliability of the POS system when handling lot-based inventory.
Original PR description
## Issue: After confirming a Sale Order for a lot-tracked product (in grams for example) and having available quantities, importing the SO in POS duplicates the order lines ## Cause: In the…
## Issue: After confirming a Sale Order for a lot-tracked product (in grams for example) and having available quantities, importing the SO in POS duplicates the order lines ## Cause: In the `settleSO` function, the line is first split because the UoM differs and is not `pos_groupable` Among the default UoMs, only Units, Pack of 6, and Dozen have `is_pos_groupable` = True, meaning most other UoMs will trigger a line split After duplicating the line due to the UoM split, an additional line is then added for each lot to link, causing duplicate entries in the POS order ## Steps to reproduce: - In Settings, enable Lots & Serial Numbers and Units of Measure & Packagings - Create a Product (Tracking: Lot, Sale Unit: g) - Update the Quantity On Hand (Lot: "LOT", Quantity: 5) - Create and confirm a Sale Order for the product (Quantity: 2) - Open POS and import the SO - Before the fix, there is 3 lines (2x no lots, 1x with lot + qty 2 ## Other issues: - The discount was not imported on the lot lines - Some lines were missing when importing lines where part of the quantity had no available lot - (This fix was already made in PR: https://github.com/odoo/odoo/pull/229075/files but was not forward-ported) opw-5018295
This update reverts recent changes to the event sale report that were causing database compatibility problems. The fix previously intended to include PoS-sold tickets, but this resulted in errors for some Odoo databases. This reversion ensures stability and continued functionality of the event sale reporting feature.
Original PR description
This recent commit is causing dependencies issues in some Odoo database that rely on the pos_event_sale module. To maintain stability and ensure compatibility, reverting the recent changes made to the event sale reports and related files. Original commit: https://github.com/odoo/odoo/pull/226544/commits/e968ff178a0f0d11949dfac67b98e1b8acf771b0 Add event registration sold through PoS to the event sale report. Steps to reproduce: ------------------- * Create an event with tickets * Sell a ticket through the PoS * Go to the event sale report > Observation: The ticket sold through PoS is not included in the report Why the fix: ------------ We modify the SQL query of the event sale report to include event registrations sold through PoS. We also make sure to remove duplicates from the original query. opw-4935195
This update corrects a bug where credit notes weren't automatically generating deferred revenue entries. The system was incorrectly using a setting designed for invoices. Now, credit notes will correctly create deferred revenue entries when configured to 'On bill validation', ensuring accurate accounting for deferrals.
Original PR description
The system incorrectly uses the `Deferred Expense Entries` configuration to determine whether to create deferrals for credit notes, while it should follow the `Deferred Revenue Entries` setting, as invoices do. As a result, deferred entries for credit notes are not created when expected. Steps to reproduce: - Go to Accounting → Configuration → Settings. - In the Deferred Expense Entries section, set Generate entries to: Manually & Grouped - In the Deferred Revenue Entries section, set Generate entries to: On bill validation - Navigate to Accounting → Customers → Credit Notes. - Create a credit note with at least one line containing Date From and Date To (i.e., deferrable line). - Validate the credit note. - No deferred revenue entries are created. Ticket [link](https://www.odoo.com/odoo/project.task/5187051) opw-5187051 Forward-Port-Of: odoo/enterprise#100211