Daily updates from Odoo
Saturday, July 4, 2026
8 changes · saas-19.4
Enhancements to existing features
This update streamlines the process of adding tracked products (with lots/serials) to a Point of Sale order. Now, products using FIFO or LIFO removal strategies are automatically added to the cart without requiring users to manually select a lot. This simplifies the checkout process and improves efficiency.
Original PR description
Before this commit: ==== - The lot/serial selection popup was always shown when adding products tracked by lots. Following this commit: ==== - Products configured with FIFO/LIFO removal strategies are automatically assigned the corresponding lot and added directly to the cart without opening the selection popup. - If no removal strategy is configured, the existing lot selection behavior is preserved. task-6226577 Forward-Port-Of: odoo/odoo#273880 Forward-Port-Of: odoo/odoo#265708
Resolved issues and error corrections
Belgian CODA bank statement imports now use the full communication text as the payment reference for unstructured payments. This makes imported transactions easier to identify and match correctly, reducing manual reconciliation work.
Original PR description
### Issue: When a CODA file was imported, the communication was fetched but it wasn't use as the payment ref Causing difficulty to match with the transactions ### Cause: For simplicity reason, the payment_ref and the communication where different The `payment_ref` was fetched once and replace The `communication` was always completed by new lines ### Steps to reproduce: - Install `l10n_be_coda` - Set the account on the Bank Journal to GR5605700000000928073840752 - Import the Simplied CODA (On the ticket) from the bank dashboard Before the fix, the ref was just `Liquidation des ventes par carte Mastercard` instead of the full communication that can be found in the chatter opw-6245848 Forward-Port-Of: odoo/enterprise#122344 Forward-Port-Of: odoo/enterprise#120536
This fix lets authorized Point of Sale users open the Preparation Display app without hitting an access error. The app now opens the display directly instead of using an intermediate step that required higher permissions than these users have.
Original PR description
A recent fix in the base module requires users to have "write" access on ao model to execute its server actions. commit: odoo/odoo@846eb51a02baaf2e4f6e6780f8d0ceb23322c38b Previously, the Preparation Display was opened through the server action `action_pos_preparation_display_kitchen_display`, which then redirected to the URL action `action_pos_preparation_display_bar_restaurant_filter_link`. However, PS users only have read access on `pos.prep.display`. As a result, executing the server action triggers an access error when opening the Preparation Display. This commit bypasses the intermediate server action and opens the URL action directly. Task-6311320 Forward-Port-Of: odoo/enterprise#121293
This fixes an issue where receipt quantities could be reduced incorrectly after using the barcode screen with packaged units of measure, such as packs of six. Businesses can rely on inventory receipts to keep the correct total quantity when products are handled in alternate units.
Original PR description
**Steps to reproduce:** - Install `stock` and `purchase` modules - Enable `Units of Measure and Packages` and `Storage Locations` from setting - Create a storable product with vendor purchase UoM set…
**Steps to reproduce:** - Install `stock` and `purchase` modules - Enable `Units of Measure and Packages` and `Storage Locations` from setting - Create a storable product with vendor purchase UoM set to "Pack of 6" - Create and confirm a Purchase Order with quantity 6 Units - Open the generated receipt - Update a move line in Detailed Operations: - Quantity: 1 - UoM: Pack of 6 - Save and open the Barcode view using smart button. - Increase quantity using "+" button by 1. - Exit barcode view without validating and refresh the receipt **Issue:** After refresh, the stock move quantity becomes 1 instead of 6, while the move line correctly shows 1 Pack of 6. **Cause:** https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/static/src/components/main.js#L161-L162 - Exiting the barcode view triggers `__onExit()`, which forwards `reserved_uom_qty` and `qty_done` from move lines to `post_barcode_process()`. https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/static/src/models/barcode_picking_model.js#L1885-L1898 This `post_barcode_process()` function triggers `_truncate_overreserved_moves()` https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/models/stock_move.py#L56-L58 - During this flow, `_truncate_overreserved_moves()` updates the stock move quantity by taking the maximum of `qty_done` and `reserved_uom_qty`. However, it assigns this value directly to the move without converting it into the stock move UoM. - In this case, both values are 1 because the move line is UoM is "Pack of 6" Logically, 1 Pack corresponds to 6 units, but since the stock move UoM is in units, this conversion is skipped. As a result, the move quantity is incorrectly set to 1 instead of 6. https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/stock_barcode/models/stock_move.py#L52-L54 **Fix:** - Convert quantities coming from barcode processing into the stock move UoM before updating the move quantity, ensuring packaged UoM values are preserved correctly. ---- opw-5472598 Forward-Port-Of: odoo/enterprise#122769 Forward-Port-Of: odoo/enterprise#116022
This update resolves an issue where routing identifiers were being recalculated unnecessarily, leading to potential performance problems. The team also cleaned up related code and improved the handling of identifiers for the account_peppol and l10n_fr_pdp modules, ensuring accurate data routing.
Original PR description
### [FIX] account_edi_ubl_cii,*: fix routing identifier dependencies *: account_peppol,l10n_fr_pdp We broke the computation of the routing scheme/endpoint in Multi ID refactor. This commit fix it so that it is computed again when necessary. Also prevent re-computation when the verification state is 'valid' to prevent modifying a value that most likely make sense. task-none ### [REF] account_peppol,l10n_fr_pdp: cleanup code - Clean unused methods - Add a computed field to help simplifying - Clean notification method in peppol.registration that had unused parameters task-none
This update resolves a bug in a test related to account reporting, specifically impacting how demo data is handled. The fix included a missing step to ensure test data was properly cleared, preventing errors and improving the reliability of reporting tests. This ensures accurate reporting functionality.
Original PR description
The test introduced by d60564a42b7c7b16d1d975146291835b65a19461 was using the field `deferred_move_ids` which is defined by account_accountant. As it is used to clear the pre-existing moves (typically demo data), we are re-using the same conditional as test_tour.py to check whether this field is available. By the way, we also add a missing flush_recordset that caused errors in test_kpi_summary_reports_unreconciled_bank_statements. Runbot-error: [939986](https://runbot.odoo.com/odoo/error/939986) Forward-Port-Of: odoo/odoo#271218
This update corrects a bug where global discount percentages displayed in Dutch (and similar locales) were incorrectly calculated in the Point of Sale system. The fix ensures that discounts are applied accurately, preventing orders from being incorrectly discounted to 100% when using the Dutch locale.
Original PR description
When using Dutch (or similar locales where the decimal separator is a comma), a configured global discount percentage with decimals is misapplied in POS. For example, a default discount of 8,33% is…
When using Dutch (or similar locales where the decimal separator is a comma), a configured global discount percentage with decimals is misapplied in POS. For example, a default discount of 8,33% is shown in the discount popup as 8.33% and, when confirmed without editing, applies a 100% discount on the order instead of 8,33%. Steps to reproduce: ------------------- * Activate Belgian localization for accounting * Set the user language to Dutch (Netherlands) or Dutch (Belgium) * In Point of Sale settings, enable global discounts and set the default discount percentage to 8,33% * Open a POS session, add a product to the cart, and click Discount * Confirm the popup without changing the value > Observation: The popup displays 8.33% (with a dot). After confirmation, the order receives a full discount instead of 8,33%. Why the fix: ------------ The discount popup initialized its value with `String(discount_pc)`, which always uses a dot as decimal separator. POS then parses the input with locale-aware rules where `.` is the thousands separator, so "8.33" is read as 833 and capped to 100%. Format the default discount percentage with `formatFloat` so the popup starts with the correct localized value (e.g. "8,33"). opw-6334367 Forward-Port-Of: odoo/odoo#273594 Forward-Port-Of: odoo/odoo#273022
Code cleanup and technical improvements
The Swedish SIE import tool was reorganized internally so its behavior can be more easily extended in future customizations. This does not introduce visible workflow changes, but it improves maintainability and flexibility for deployments that need tailored import behavior.
Original PR description
We changed some tools to be regular model method to allow inheritance. task-none