Saturday, July 4, 2026
5 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 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