Daily updates from Odoo
Tuesday, September 30, 2025
34 changes · 19.0
New functionality added to Odoo
Adds support for exporting Argentina's new IVA Simple tax report as a ZIP of CSV files that can be uploaded to the government portal. This helps Argentinian companies meet the latest reporting requirements directly from Odoo.
Original PR description
The Argentinian government has released support for a new type of a tax report that companies can upload called IVA Simple. This is a zip of CSV files that can be imported to the government portal. As such we want to support exporting this report for our customers. This commit adds a new auto installed module for a new report export type of IVA Simple on the Argentinian Tax Report as well as the model data required for the export. task-[5027104](https://www.odoo.com/web#id=5027104&view_type=form&model=project.task)
Enhancements to existing features
Point of Sale users can now manually retry kitchen receipt printing when a printer problem caused a failure. The retry action only sends the receipt to printers that failed before, avoiding duplicate prints on printers that already succeeded.
Original PR description
Before this commit: = - There was no option to retry printing kitchen receipts if a printer failed. After this commit: = - Users can now manually retry printing kitchen receipts that failed due to printer issues. - The `Retry` button targets only the printers that previously failed, ensuring other successful prints are not repeated. Task: 4717776 Forward-Port-Of: odoo/odoo#228783 Forward-Port-Of: odoo/odoo#206432
The self-ordering QR code experience has been simplified across desktop and mobile, making key actions easier to find and understand. Settings now include a new option for free metal or wood stands, helping businesses better manage QR code ordering materials.
Original PR description
In this commit: ------------------- - Removed the QR code icon from the desktop view of the `Get QR Code` button. - Moved the QR code button from the navbar into the burger menu for mobile view. - Added a new reference option `Free Metal / Wood Stands` in settings. - Renamed the `Edit` menu item to `Settings`, to make the button functionality clear from the label as it leads the user to the settings page for the selected config. task:5003448 Forward-Port-Of: odoo/odoo#228772 Forward-Port-Of: odoo/odoo#225856
When users open Discuss for the first time, OdooBot now opens automatically instead of showing an empty conversation screen. This gives new users a clearer starting point and makes the messaging experience feel more guided from the first launch.
Original PR description
**Purpose of this PR:** - Before this commit, opening Discuss for the first time showed “No conversation selected”, leaving users without a clear starting point. - This commit changes the behavior so that the OdooBot chat opens automatically on first launch, providing users with an immediate conversation instead of an empty state. Task - 5072374
Point of Sale no longer loads large sets of product attribute values upfront when they are not immediately needed. This reduces loading time and improves performance for businesses with many product variants, while keeping product links available when required.
Original PR description
Before this commit, when loading PoS, all product template attribute value (ptav) IDs linked to a product attribute were loaded. This caused performance issues when attributes had a large number of values, even though they were not needed at that stage. With this commit, the values are no longer preloaded, since the reverse fields in ptav and ptal are fetched when needed, ensuring they can still be linked correctly without degrading performance. opw-5006818 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226999 Forward-Port-Of: odoo/odoo#224497
Point of Sale can now use an Epson printer serial number to automatically compute the secure certificate domain, instead of requiring staff to enter an IP address or URL. This makes HTTPS printer configuration simpler and less error-prone for businesses using Epson receipt printers.
Original PR description
On EPSON printers, we can enable an option ('Automatic Certificate Update') to get a certified (https) url resolving to the ip address of the printer. This domain is computed based on the serial number of the printer.
We updated the configuration to compute the domain if a serial number has been provided instead of an IP address or an url.
Task: 4384790
Forward-Port-Of: odoo/odoo#228844
Forward-Port-Of: odoo/odoo#228710The automatic currency rate service has been updated to use XE.com as its provider. This helps keep exchange rates current through a different external source, supporting more reliable currency handling for accounting workflows.
Original PR description
Changed the Automatic Currency Rates service to xe.com task-id: 4745275
Resolved issues and error corrections
Store pickup checkout now checks the total quantity of the same product across all cart lines, even when different units of measure are used. This prevents customers from completing checkout without a warning when a store does not have enough stock overall.
Original PR description
Steps to reproduce: 1. Enable Pickup in Store in eCommerce. 2. Create a product with multiple UoMs (e.g., Unit, Pack of Six). 3. Add the product to the cart using different UoMs in separate lines. 4. Select a store with insufficient total stock but enough for individual lines. 5. Proceed to checkout → No warning is shown. After this commit, all order lines will be taken into account when checking available stock. opw-5108294
Self-order and kiosk orders paid online now appear on the preparation display only after payment is confirmed. This prevents staff from preparing unpaid orders while still ensuring paid orders reach the display even if customers leave the payment flow through an exit route.
Original PR description
pos_*= pos_online_payment_self_order_preparation_display, pos_self_order_iot Before this commit, if an online payment method was assigned to a self or a kiosk, the order was displayed on the preparation display before the payment was confirmed. After this commit, the order is no longer displayed on the preparation display until the payment confirmation. Community PR: https://github.com/odoo/enterprise/pull/87173 Backport of https://github.com/odoo/odoo/pull/87173, with additional logic to ensure the order is correctly sent to the preparation display even if an exit route is used in the payment portal Forward-Port-Of: odoo/enterprise#95583 Forward-Port-Of: odoo/enterprise#95312
Self-order and kiosk orders paid online now appear on the preparation display only after payment is confirmed. This prevents staff from preparing unpaid orders while still ensuring confirmed orders are sent correctly, including when customers leave through the payment portal exit flow.
Original PR description
pos_*= pos_online_payment, pos_online_payment_self_order, pos_self_order Before this commit, if an online payment method was assigned to a self or a kiosk, the order was displayed on the preparation display before the payment was confirmed. After this commit, the order is no longer displayed on the preparation display until the payment confirmation. Enterprise PR: https://github.com/odoo/enterprise/pull/95312 Backport of https://github.com/odoo/odoo/pull/213493, with additional logic to ensure the order is correctly sent to the preparation display even if an exit route is used in the payment portal --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228687 Forward-Port-Of: odoo/odoo#228189
This fix corrects how units of measure are converted when calculating carbon emissions in ESG reporting. It helps ensure emissions figures are based on the emission factor's unit, improving the accuracy of sustainability reporting.
Original PR description
Prior to this commit, the UoM conversion in the carbon emissions calculation was done by targeting the UoM of the account move line instead of the UoM of the emission factor. Which led to incorrect emissions values calculations. task-5107685 Forward-Port-Of: odoo/enterprise#95468
Payroll users with Administrator access can now cancel completed payslips as intended. This removes an incorrect restriction that only allowed the general system admin user to perform the action, reducing payroll processing blockers.
Original PR description
steps to reproduce: ------------------- 1. Install payroll 2. Create a user and grant "Administrator" access to Payroll. 3. Log in as the new user and try to cancel a 'Done' payslip. issue: ------ A UserError is raised: "Cannot cancel a payslip that is done." observation: ------------ A user with Payroll "Administrator" access is unable to cancel a payroll payslip cause of the issue: ------------------- During cancellation, the system checks whether the user is "Admin" instead of verifying if the user has Payroll "Administrator" access. https://github.com/odoo/enterprise/blob/13832d80570956e504e1c09f41acbeb0bc4baedc/hr_payroll/models/hr_payslip.py#L509-L513 solution: ---------- Check that the user has Payroll "Administrator" access. opw-5040029 Forward-Port-Of: odoo/enterprise#95101 Forward-Port-Of: odoo/enterprise#93831
Bank transactions from one company branch can now be matched with payments from the main company or related branches when they share the same parent company. This prevents valid payments from being left unreconciled in branch accounting workflows.
Original PR description
…o end uuid The aim of this commit is handling branches cases with reconciliation via the end to end uuid. Before this commit, a bank transaction from a company branch couldn't be reconciled with a payment from the main company. In some situation this case could happen. Now payments and bank transactions are reconciliable even if both are from another company. It works only for companies with the same main company, branches which are sisters or parent-children relation. task-5081684
This fixes a rounding mismatch in Mexican electronic invoicing where totals could be validated differently by Odoo and the official XML rules. It helps prevent valid CFDI invoices from being rejected or showing incorrect totals due to tiny decimal differences.
Original PR description
The validation in the XML are made based on values rounded to 6 digits. However in Odoo, we do the computation without any rounding. 352.2413793103448 + 876.7435344827586 + 162.92327586206898 + 198.73706896551727 + 526.0383620689655 + 17.241379310344826 = 2133.925 ~= 2133.93 352.241379 + 876.743534 + 162.923276 + 198.737069 + 526.038362 + 17.241379 = 2133.924999 ~= 2133.92 != 2133.93 opw-5096249 Forward-Port-Of: odoo/enterprise#95555 Forward-Port-Of: odoo/enterprise#95413
Creating a related monetary field in Studio now also creates the correct linked currency field. This prevents unusable monetary values and helps ensure amounts display and calculate with the right currency.
Original PR description
Before this commit, when creating a related field to a monetary, the created currency field was not stored and not related either, so the monetary was unusable. This was because of 5cf5a35a0a8f78655989009d0eddcf39f8430965 , b177b058be1531c3d2af2b591c22591c19240d33 and in general the changes in read_group that largely improve the situation. After this commit, we create a currency field related to the currency field of the related monetary to ensure that the monetary's value is coherent. This is made possible by the above mentionned improvements in read_group opw-5094619 Forward-Port-Of: odoo/enterprise#95407
Invoices from Point of Sale can now be printed through connected IoT printers again instead of only being downloaded. This restores expected in-store printing workflows and reuses the printer selection flow to make future printing paths more consistent.
Original PR description
This PR contains two commits, the first is a refactoring, and the second is the invoice printing itself. - **[REF] iot: extract printer select into separate function** Before this commit, the printer…
This PR contains two commits, the first is a refactoring, and the second is the invoice printing itself.
- **[REF] iot: extract printer select into separate function**
Before this commit, the printer selection wizard was tightly coupled to
the IoT report handler, and the call to send to the printer was
duplicated in the wizard and the handler.
After this commit, the printer selection wizard is contained in a
function that will always return the selected printers directly to the
caller, whether the dialog needs to be opened or not. The wizard is
simplified as a result and the print call always occurs in the handler.
This refactoring will allow other places to use the printer selection
wizard, namely for invoice printing.
- **[FIX] pos_iot: print invoices via IoT**
In the commit https://github.com/odoo/enterprise/commit/07418d7544ceecfef38257db8f59bf845a0b0769, the invoice PDF downloading was refactored to
bypass the `ir.actions.report` model, instead working directly via an
action on the invoice model. A side effect of this is that it broke
printing invoices via the IoT, as it relies on the report printing
action to function.
To fix this, this commit introduces an override in `pos_iot` for the
`account_move_service`, which will print the invoice PDF via the IoT
instead of downloading it directly (if a printer is associated with the
report).
task-5109814
Forward-Port-Of: odoo/enterprise#95689
Forward-Port-Of: odoo/enterprise#95586Fixes an issue where customers using a mobile checkout could not see the PayPal payment button. This restores the ability to complete purchases with PayPal on mobile devices, reducing checkout friction and potential lost sales.
Original PR description
## Version saas-18.4+ ## Issue *Use mobile device or mobile view* - Configure Paypal as a Payment Provider; - Go to the shop and buy an article; - Move to checkout and select PayPal; - No PayPal…
## Version saas-18.4+ ## Issue *Use mobile device or mobile view* - Configure Paypal as a Payment Provider; - Go to the shop and buy an article; - Move to checkout and select PayPal; - No PayPal button is displayed. ## Cause In saas-18.4, a refactoring of the checkout layout (7a564237579603bcaef46efd6ffaaaffefb54b11) introduced the `o_mobile_summary` block which results in the full payment form being duplicated in the DOM: - One copy for desktop: - https://github.com/odoo/odoo/blob/de3d09ab8592c87b9d747a33cded93a90387b797/addons/website_sale/views/templates.xml#L3524-L3529 - One copy inside `.o_mobile_summary` for mobile: - https://github.com/odoo/odoo/blob/de3d09ab8592c87b9d747a33cded93a90387b797/addons/website_sale/views/templates.xml#L3557-L3560 This causes the `payment.submit_button` template (and its extension by PayPal) to be injected twice. As a result, the DOM ends up with two elements sharing the same IDs (`o_paypal_button_container`) which breaks PayPal’s SDK rendering logic. ## Fix JavaScript logic based on cca908741c7fdd701a4539e5d43c71248b73b14f has been added to detect and rename the duplicated DOM structure: The PayPal button can be rendered everywhere based on unique IDs. opw-4942831 Forward-Port-Of: odoo/odoo#220516
This fix prevents users from creating or keeping ESG emission factor assignments on account types that are not eligible, such as non-expense or non-fixed-asset accounts. When an account type is changed to an ineligible type, the system warns the user and cleans related ESG assignments and journal emission factors to protect reporting accuracy.
Original PR description
Before this PR, it was possible to create on the fly an account from the assignation lines list view of another type than "Expense" or "Fixed Assets". This is not desired, as this type of account is not part of the domain of the `account_id` field of the `esg.emission.factor.line` model. We prevent creation of such accounts from ESG in general, to avoid confusion and ensure data integrity. Moreover, when changing the account type of an existing account, if this one is changed to a type other than "Expense" or "Fixed Assets", we verify if there are some assignation lines linked to this account and/or journal items linked to that account. If so, we raise a warning to the user and if he wants to proceed, we remove the assignation lines linked to this account and remove the emission factors of journal entries linked to that account. task-4859806 Forward-Port-Of: odoo/enterprise#87295
The EC Sales List report no longer creates duplicate VAT number verification checks when the Verify VAT Numbers option is enabled. This prevents an error that could block users from generating tax return checks for non-empty reports.
Original PR description
Create tax return checks for a non-empty EC Sales List report when the option "Verify VAT Numbers" (vat_check_vies) is enabled implies to create 2 checks with the same code (check_partner_vies). This is forbidden and raises a traceback. opw-5079474 opw-5090602 opw-5094853 opw-5103611 Forward-Port-Of: odoo/enterprise#95551
This update prevents Swiss payroll records from being reverted in cases where that action could create incorrect payroll handling. It helps businesses avoid accidental changes to finalized payroll data and supports more reliable payroll operations.
This fix ensures packaging details are properly kept on products that have only one variant. It prevents missing packaging information while preserving the earlier fix that avoided duplicate packaging entries.
Original PR description
e158730ba16e898a13dd9a98ed96fa30fa95ab6f recently fixed a situation where one-variant products had duplicated packagings. In the aforementioned commit, we concluded that the logic to write (again) the templates values for variant-stored fields was useless because already applied to the generated variants. Nevertheless, while trying to remove in master this logic, we noticed that those varlues are only applied to variants of templates having at least one attribute line, whose creation will trigger the variants creation. This commit therefore partially reverts the previous commit, bringing back the first solution that is still the best approach in the end. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229080
This fixes an issue where sale orders linked to projects could become difficult to update after their related analytic account was deleted. Sales users can now change the project on affected orders without encountering a blocking error.
Original PR description
# Issue: In a sale order, if any of the so lines contains the ID of a deleted analytic account in its analytic_distribution field, then updating the project_id field is impossible as it raises an…
# Issue: In a sale order, if any of the so lines contains the ID of a deleted analytic account in its analytic_distribution field, then updating the project_id field is impossible as it raises an error. # Cause This is caused because _compute_analytic_distribution() tries to retrieve 'root_plan_id' from all ids without checking if records exists. # Fix This commit add an exists() check on analytic.accounts retrieved from analytic_distribution field and clear the non-existing records ids from the field. # Steps to reproduce - Install sale_project and accountant modules - Check "Analytic Accounting" in the Accounting settings - Create a new project "Test P", set it up "Billable", with a new Analytic account "Test AC" (field "Project" tab "Analytic") - Create a new sale order "Test SO", add a few products and set up the Project field to "Test P". Save the sale order. - Delete the analytic.account "Test AC" - Go back on "Test SO", try to change the field "Project" - a Missing error is thrown --- Current behavior before PR: When creating a sale order and binding it to a project with an analytic account, then deleting the analytic account, the field "Project" on the sale order can't be updated anymore. Desired behavior after PR is merged: When creating a sale order and binding it to a project with an analytic account, then deleting the analytic account, the field "Project" on the sale order can be updated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224895
This fix stops loyalty points or coupon counts from being applied more than once when an order confirmation is retried, such as after an internet interruption. It helps keep customer rewards accurate and prevents incorrect loyalty balances in Point of Sale.
Original PR description
Before this commit, if the `confirm_coupon_programs` method was called twice (e.g., due to an internet issue), the loyalty points were calculated incorrectly. This commit fixes the issue by checking the existing loyalty history to prevent duplicate point calculations. To enable this, the creation of oyalty history records has been moved into the `confirm_coupon_programs` function. opw-4877599 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224694 Forward-Port-Of: odoo/odoo#222372
Partially refunded point-of-sale orders now recalculate the amount due based on the remaining items. This prevents customers from being charged the original full total when only a remaining balance should be paid.
Original PR description
Before this commit, refunding a partially refunded order did not update the total price based on the remaining lines. As a result, it was possible to pay the original total amount instead of the correct remaining amount. opw-5100790 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228312 Forward-Port-Of: odoo/odoo#228186
When a shopper adds either a kit product or one of its components to the cart, the website now updates the available quantity shown for related products. This prevents customers from seeing misleading stock information and helps avoid orders for items that can no longer be fulfilled.
Original PR description
### Steps to reproduce: - In the settings website > Shop: - Disable `Out-of-Stock: Continue Selling`. - Enable `Show Available Qty` if below 5 units. - Create 2 storable products published on the…
### Steps to reproduce:
- In the settings website > Shop:
- Disable `Out-of-Stock: Continue Selling`.
- Enable `Show Available Qty` if below 5 units.
- Create 2 storable products published on the website:
- COMP, put 1 unit in stock.
- KIT with bom of type Kit using 1 x COMP.
- With a private window go to the shop.
- Add 1 x COMP or KIT to the chart.
#### > This is not reflected on the available quantity in stock of the other product
### Cause of the issue:
The availability on the website is computed from the product availability using the `free_qty` fetched because of this override: https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/controllers/variant.py#L10-L13 from which the cart quantity of the product itself is deduced before re-render:
https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/static/src/js/variant_mixin.js#L49-L51 https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/static/src/js/variant_mixin.js#L83-L86 While the `free_qty` is correctly computed from kit products based on the component availability:
https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/mrp/models/product.py#L211-L221 The qties in the virtual cart quantities are not recomputed base on kits.
opw-4889956
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#228881
Forward-Port-Of: odoo/odoo#222945Timesheet filters such as Today, This Week, and Last Week now use the user's local date instead of UTC. This prevents entries from appearing under the wrong day or week for employees in different time zones.
Original PR description
This commit fixes issues with the timesheet Date filters, in which the `date` field of account.analytic.line records, which is stored as the local timezone's date, is being compared to a UTC DateTime value. This leads to off-by-one errors. For example, if you are in Berlin and try to filter for all timesheet entries from "Today", you will only find entries from the previous day. Similarly, for the "This Week" and "Last Week" filters, which would be shifted by one day. The filter domains have been changed to compare the `date` to the local timezone's "today". opw-5003310 Forward-Port-Of: odoo/odoo#225753
Shop floor barcode actions now clear the manufacturing order filter after they run, preventing teams from staying on a narrowed work order view by mistake. This makes scanner-based operations more reliable and reduces confusion on the production floor.
Original PR description
To reproduce: - Create multiple WOs in assembly line 1 - Open shop floor, assembly line 1 - Scan one of the MO barcodes to filter - Scan OBTPAUS/OBTCLMO/OBTCLWO Current behaviour: The expected action gets executed, but the MO filter set in the search bar remains. Expected behaviour: The expected action gets executed and the filter is removed. Task: 5107223
Fixes an error that could occur when users clicked Tickets Closed on the Helpdesk dashboard or applied Closed On date filters. This restores reliable access to recent closed-ticket views and prevents disruption from server error messages.
Original PR description
Steps to reproduce: - 1. Install the helpdesk module. 2. Navigate to the Helpdesk Overview dashboard. 3. On any team card (e.g., VIP Support), click the 'Tickets Closed'. 4. (Alternative): Go to the 'All Tickets' list view, open the search filters, and select a 'Closed On' date filter like 'Last 7 Days'. Issue: - Clicking the 'Tickets Closed' button or applying a 'Closed On' date filter results in a server traceback (ValueError). Cause: - The search filters used an invalid date syntax with multiple operators like `today -7d + 1d` (introduced in commit https://github.com/odoo/enterprise/commit/3db2ad2424f5d40b51bedfba4475fa6b0602c955). Fix: - Corrected the syntax like `today -7d +1d`. task-5069003
Odoo now prevents users from validating a stock transfer when there is no quantity to process. Instead of opening a backorder prompt that cannot do anything, the system shows a clear user error, reducing confusion during delivery validation.
Original PR description
### Steps to reproduce: - Create and confirm a delivery with 2 moves: - 1 x product 1 - 1 x product 2 - Set the quantity of product 2 to 0 and mark it as picked - Validate the transfer #### > The…
### Steps to reproduce:
- Create and confirm a delivery with 2 moves:
- 1 x product 1
- 1 x product 2
- Set the quantity of product 2 to 0 and mark it as picked
- Validate the transfer
#### > The backorder wizard open's even though there is nothing to validate. Creating a backorder does nothing.
#### Cause of the issue:
Since there is a picked move, the picking validation does not pick every moves in the `pre_action_done` hook keeping only moves with empty qty as picked:
https://github.com/odoo/odoo/blob/9b41eb38403e64091b74e1ae53c79488aa48b499/addons/stock/models/stock_picking.py#L1208-L1209 Then, only the picked moves are processed in there `_action_done`: https://github.com/odoo/odoo/blob/9b41eb38403e64091b74e1ae53c79488aa48b499/addons/stock/models/stock_move.py#L1914 https://github.com/odoo/odoo/blob/9b41eb38403e64091b74e1ae53c79488aa48b499/addons/stock/models/stock_move.py#L1929-L1937 Which leads to an empty picking validation.
opw-5076640
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#228490
Forward-Port-Of: odoo/odoo#227995This fixes a checkout issue where customers who selected a free product from a coupon reward could not add it to their cart. Coupon-based promotions with multiple eligible free products now work as intended, reducing checkout friction and support cases.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a coupon program with a free product reward using a product tag; 2. generate coupons & copy a coupon code; 3. have 2 or more products with the tag; 4. go to /shop & add any product to your cart; 5. go to checkout; 6. apply coupon code; 7. select a free product; 8. click "Use". Issue ----- Product isn't added to the cart. Cause ----- On forward porting a fix for a similar issue in bb92ba5fbba94, it accidentally checks for the `product_id` in `request.env` instead of `request.env.context`. As no `product_id` is found, no product is added. Solution -------- Check `request.env.context` instead of `request.env`. opw-4979939 Forward-Port-Of: odoo/odoo#229157 Forward-Port-Of: odoo/odoo#224166
Calendar views can now correctly filter records linked to multiple people or items, such as tasks assigned to several users. This helps teams see complete and accurate results when selecting one or more filter values in the calendar.
Original PR description
This commit add support for Many2many filters in the calendar arch. This PR follows the PR #215790 Example: Add `<field name="user_ids" filters="1" invisible="1"/>` in the calendar arch with: Tasks: - T1 assigned to A - T2 assigned to A and B - T3 assigned to B and C Giving: - A => show T1 and T2 - B => show T2 and T3 - A and B => show T1, T2 and T3 task-5005992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The rental schedule now correctly lists every rental order for products tracked by serial number, even when the same serial number is rented again. This prevents missing bookings and gives rental teams an accurate view of product usage and availability.
Original PR description
**Current Behavior:** With rental transfers enabled, renting a product with a serial number multiple times will result in the rental schedule only showing one of multiple rental orders for that SN.…
**Current Behavior:** With rental transfers enabled, renting a product with a serial number multiple times will result in the rental schedule only showing one of multiple rental orders for that SN. **Expected Behavior:** All rentals for the same SN should appear in the rental schedule. **Steps to Reproduce:** - Go to Rental > Configuration > Settings and enable Rental Transfers - Create a new product that is storable, can be rented, and is tracked by unique serial number - Receive 25 of the product with assigned serial numbers - Create and confirm a rental order for 25 units of product - Validate both OUT and IN transfers - Duplicate the rental order and confirm it - Check Rental > Schedule -> Odoo says 25 total units across the original and duplicate orders, but they each have 25 **Cause of the Issue:** Previously, commit ed5fd2693fc fixed a bug where all serial numbers would display regardless of whether they were involved in a rental. This introduced this bug, where only the first stock move line with a distinct serial number would be shown in the rental schedule. **Fix:** Change the "SELECT DISTINCT ON" to "sml". We can get all distinct stock move lines as we can expect SNs to appear multiple times. opw-5003247 Forward-Port-Of: odoo/enterprise#95315
Point of Sale now waits until a blackbox discount has finished applying before allowing payment to proceed. This prevents payments from being created with an outdated amount, reducing cashier confusion and terminal payment errors.
Original PR description
Before this commit, if a discount was applied with the blackbox, it was applied after communication with blackbox which could be slow. If the user was clicking payment before this disound was applied and had only one payment method, a payment line with the old amount was added which could lead to confusion and errors when this payment line was sent to a terminal. This is fixed by waiting for the discount to be applied before being able to click on payment. Community PR: https://github.com/odoo/odoo/pull/221020 Forward-Port-Of: odoo/enterprise#93809 Forward-Port-Of: odoo/enterprise#91256
The point of sale flow now waits for a discount to finish applying before allowing payment to continue. This helps prevent incorrect payment amounts being sent to terminals, reducing cashier confusion and transaction errors.
Original PR description
pos*: point_of_sale, pos_restaurant Before this commit, if a discount was applied with the blackbox, it was applied after communication with blackbox which could be slow. If the user was clicking payment before this disound was applied and had only one payment method, a payment line with the old amount was added which could lead to confusion and errors when this payment line was sent to a terminal. This is fixed by waiting for the discount to be applied before being able to click on payment. Enterprise PR: https://github.com/odoo/enterprise/pull/91256 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225358 Forward-Port-Of: odoo/odoo#221020