Tuesday, September 30, 2025
18 changes · saas-18.4
Resolved issues and error corrections
Fixed an issue where Peruvian electronic invoices for foreign-currency down payments could show the company currency instead of the invoice currency. This helps ensure invoice XML data matches the actual transaction currency and avoids compliance or validation problems.
Original PR description
#### Issue: - After invoicing a downpayment in a foreign currency, in the XMl of the total invoice, the currency_id on the prepaid tag is set to PEN instead of the right currency. #### Step to…
#### Issue: - After invoicing a downpayment in a foreign currency, in the XMl of the total invoice, the currency_id on the prepaid tag is set to PEN instead of the right currency. #### Step to reproduce: 1. Install l10n_pe_edi 2. Sell a product to "Comercial Constructora los Patitos" through the sales app and make sure you use USD (or a different currency than PEN). 3. Create a downpayment invoice, could be any percentage. 4. To make sure it works correctly, add a random document number on the invoice with the format ABC-01234567. 5. Confirm this invoice. 6. Now go back to the sale order and deliver your product. 7. Create the final invoice, where the downpayment will be deducted. Make sure it is also in USD (or whatever currency you chose). 8. Confirm the invoice. #### Current behavior: - Display "PEN" in the attribute currencyID of tag PaidAmount in a PrepaidPayment: <cbc:PaidAmount currencyID=PEN> #### Expected behavior: - The currency displayed should match the invoice currency #### Cause of the issue: - the currency of the company emitting the invoice was used instead of the currency of the invoice. opw-5061019
Field service sale order lines now use the customer’s assigned pricelist instead of the product’s default price. This ensures customers are billed according to agreed pricing when tasks with timesheets are validated.
Original PR description
Before this commit, the service line on the sale order ignored the customer’s pricelist and used the product’s default price. Steps to reproduce: - Assign a fixed-price pricelist to a customer. - Create an FSM task for them and add a timesheet. - Validate the task and check the service line price. After this commit, the service line correctly reflects the price from the assigned pricelist. task-4830183 Forward-Port-Of: odoo/enterprise#95650 Forward-Port-Of: odoo/enterprise#88039
Coupon and global discount lines are now identified more reliably on sales orders, so discounted amounts are passed correctly to delivery services such as Shiprocket. This prevents cash-on-delivery shipments from being created with missing discount totals and keeps discount line values stable when quantities change.
Original PR description
Issue ----- When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons. Steps to reproduce ----- - Set an Indian…
Issue ----- When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons. Steps to reproduce ----- - Set an Indian company up (with valid address and some dummy mail & phone) - Create a customer "IN Cust" (with valid address and some dummy mail & phone) - Create a product "IN Prod" - Sale price: 1000 INR - Weight: 100g - Set some reference, eg "INPROD" - Create a Shiprocket delivery method - Payment Method: COD - Set some "Shiprocket Channel" - Enable Debug requests - In settings, enable "Promotions, Loyalty & Gift Card" - Go to Sales > Products > Discount & Loyalty - Create a new program - Name: 50% off - Program Type: Coupons - Change the existing reward to 50% discount on order - Generate some coupon - Copy the code to the generated coupon - Create a SO our product and customer - Use the coupon code & apply the 50% discount - Add shipping - Shiprocket COD - Get rate - Confirm the SO - Go to the picking & validate it - Open logs (Settings/Technical/Database Structure/Logging) - Open the "shiprocket_request_external/shipments/create/forward-shipment" log --> total_discount is 0 Cause ----- The problem comes from https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301 There are 2 issues here. The first and most important one is how we find the discount lines. https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320 Discounts from coupons don't use the `sale_discount_product_id`, we'll have to define a new function to override in `sale_loyalty` for this. The second issue is that we use the untaxed discount amount. https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321 This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price). ----- Enterprise PR: https://github.com/odoo/enterprise/pull/92310 Ticket: opw-4755357 Forward-Port-Of: odoo/odoo#228375 Forward-Port-Of: odoo/odoo#223517
Shiprocket Cash on Delivery orders now send coupon discounts correctly, including the tax-inclusive discount amount. This helps ensure the amount collected from customers matches the discounted order total and avoids overcharging or reconciliation issues.
Original PR description
Issue ----- When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons. Steps to reproduce ----- - Set an Indian…
Issue
-----
When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons.
Steps to reproduce
-----
- Set an Indian company up (with valid address and some dummy mail & phone)
- Create a customer "IN Cust" (with valid address and some dummy mail & phone)
- Create a product "IN Prod"
- Sale price: 1000 INR
- Weight: 100g
- Set some reference, eg "INPROD"
- Create a Shiprocket delivery method
- Payment Method: COD
- Set some "Shiprocket Channel"
- Enable Debug requests
- In settings, enable "Promotions, Loyalty & Gift Card"
- Go to Sales > Products > Discount & Loyalty
- Create a new program
- Name: 50% off
- Program Type: Coupons
- Change the existing reward to 50% discount on order
- Generate some coupon
- Copy the code of the generated coupon
- Create a SO our product and customer
- Use the coupon code & apply the 50% discount
- Add shipping
- Shiprocket COD
- Get rate
- Confirm the SO
- Go to the picking & validate it
- Open logs (Settings/Technical/Database Structure/Logging)
- Open the "shiprocket_request_external/shipments/create/forward-shipment" log
--> total_discount is 0
Cause
-----
The problem comes from
https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301
There are 2 issues here.
The first and most important one is how we find the discount lines.
https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320
Discounts from coupons don't use the `sale_discount_product_id`. We can use the `_can_be_invoiced_alone` function to find both regular and loyalty discounts
https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale/models/sale_order_line.py#L1033-L1041
def _can_be_invoiced_alone(self):
""" Whether a given line is meaningful to invoice alone.
It is generally meaningless/confusing or even wrong to invoice some specific SOlines
(delivery, discounts, rewards, ...) without others, unless they are the only left to invoice
in the SO.
"""
self.ensure_one()
return self.product_id.id != self.company_id.sale_discount_product_id.id
https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale_loyalty/models/sale_order_line.py#L50-L51
def _can_be_invoiced_alone(self):
return super()._can_be_invoiced_alone() and not self.is_reward_line
We just have to be careful not to accidentally include delivery fees because of
https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/delivery/models/sale_order_line.py#L18-L19
def _can_be_invoiced_alone(self):
return super()._can_be_invoiced_alone() and not self.is_delivery
The second issue is that we use the untaxed discount amount.
https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321
This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price).
-----
Community PR:
https://github.com/odoo/odoo/pull/223517
Ticket:
opw-4755357
Forward-Port-Of: odoo/enterprise#95435
Forward-Port-Of: odoo/enterprise#92310Fixes the employee onboarding helper so teams can load sample data and add a new employee from the onboarding view. The helper now appears only in the right empty-company situations, reducing confusion for users managing employee records.
Original PR description
## Issue
The load sample data button of the employee onboarding helper doesn't work.
## PR Purpose
1) Add a "New employee" button to the onboarding view
2) Display the onboarding employee view only when :
- 'My Company' is being displayed
- There is 0 or 1 (Administrator) employee in 'My Company'
- The demo data have not been loaded
3) When you jump on an empty screen due to a search, display only the onboarding "helper blocks" (design)
Task: #4879557
Signed-off by thhaESG now limits account creation and assignment to eligible expense or fixed asset accounts, reducing confusion and protecting reporting data quality. If an existing account is changed to an ineligible type, users are warned and related ESG assignment or emission data is cleaned up if they proceed.
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
Scanning a package in the Barcode app now correctly converts quantities when the package and delivery line use different units of measure, such as kilograms and grams. This prevents under-counting delivered quantities and helps warehouse teams validate package scans accurately.
Original PR description
Manual forward port of https://github.com/odoo/enterprise/pull/90878 **Problem:** When scanning a package with a different UoM than the barcode line, the conversion is not made. **Steps to…
Manual forward port of https://github.com/odoo/enterprise/pull/90878 **Problem:** When scanning a package with a different UoM than the barcode line, the conversion is not made. **Steps to reproduce:** - Enable the "Packages" setting; - Create a new storable product and set kg as its UoM; - In the inventory tab, add "g" in the packagings - Click on the on hand smart button and select update quantity - Add a new line; - In the package column create a new package; - Set a quantity of 10 kg; - Create a delivery and select your product; - Set a demand on 10000 and select g as the UoM; - Mark as todo; - Open the delivery in the Barcode app; - Scan the package. **Current behavior:** The quantity on the line is now 10 / 10000 g **Expected behavior:** It should be 10000 / 10000 g **Cause of the issue:** https://github.com/odoo/enterprise/blob/4c9fa9dc010958710d848fbcb3241b17ea7205ca/stock_barcode/static/src/models/barcode_picking_model.js#L1500-L1505 remaining_qty is expressed in the uom of the quant so it will be 10 but qty_needed is expressed in the uom of the line is it will be 10000. qty_used beeing the minimum of those two it will be 10. **Fix:** To define how much quantity to take from the package, we convert the line's quantity by using the package's UoM. Then, when we add this quantity to the line's quantity, we re-convert it by using the line's UoM. opw-4860064 Forward-Port-Of: odoo/enterprise#93693
This fix ensures that when a user chooses one delivery move line and puts it in a package, only that selected item is assigned to the package. It prevents unrelated products in the same delivery from being packed together by mistake, improving accuracy in shipping operations.
Original PR description
Steps to reproduce the bug:
- Create two storable products, e.g., “P1” and “P2”.
- Create a delivery:
- Add one unit of each product.
- Add any carrier (e.g., DHL).
- Mark the picking as "To Do".
- Set the quantity to 1.
- The move lines are created.
- Click on the Moves smart button.
- Select any move line (ML).
- Click Put in Pack.
- A wizard is triggered.
- Select any pack.
Problem:
The pack is applied to both move lines instead of only the selected one.
opw-5104034
Forward-Port-Of: odoo/odoo#228470
Forward-Port-Of: odoo/odoo#228350Fixes an issue where enabling VAT number verification on a non-empty EC Sales List could create duplicate checks and cause an error. Businesses can now run the report with VAT verification enabled without encountering a blocking traceback.
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 fix makes website page settings behave correctly when a page URL and menu visibility are changed at the same time. It also ensures newly marked page templates appear immediately when creating a new page, reducing confusion for website editors.
Original PR description
Since [1], the page dependencies algorithm was updated, requiring adjustments to the tour logic. Additionally, following [2], the "Add new content" button was changed from an `<a>` tag to a…
Since [1], the page dependencies algorithm was updated, requiring adjustments to the tour logic. Additionally, following [2], the "Add new content" button was changed from an `<a>` tag to a `<button>`, which also needed to be reflected in the tour. Furthermore (see [3]), removing a page from the menu could silently fail when the page URL was changed in the same save because the wizard only looked up menus by the current URL. Resolve menus by page_id (fallback to URL) in both compute and inverse, and unlink accordingly, ensuring "In Menu" toggles work reliably across URL changes. Also, since [4], the "New Page" dialog cached the templates list, so pages newly marked as "Is a Template" didn't appear until a reload. Fetch templates without client-side caching so the Custom tab reflects changes immediately. This fixes the tour steps for "Verify is not in menu" and "Verify template Cool Page exists." Steps to reproduce: A. "In Menu" toggle fails when URL also changes (unlink by URL only) - Website > Go to any page (e.g., /cool-page). - Click Edit > Page (properties). - Change URL from /cool-page to /cool-page-2. - In the same dialog, disable "In Menu" (It should be automatic). - Click Save & Close. - Bug (before): The corresponding menu item is not removed because the unlink resolves only by the old/current URL. Now: Menus are resolved and unlinked by page_id (fallback to URL), so the menu entry is correctly removed. B. "New Page" > Custom templates list becomes stale (client cache) - Create a normal website page (not a template). - Open Page (properties) and enable "Is a Template". Save. - Without reloading the site, click New (Add new content) > New Page. - Open the Custom tab. - Bug (before): The page you just turned into a template doesn't appear because the dialog used a cached list. Now: The dialog fetches templates without client caching, so the new template appears immediately. [1]: https://github.com/odoo/odoo/commit/cd4b0c91c1cf60ff72e91cf0544cb255ee5aff3f [2]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 [3]: https://github.com/odoo/odoo/commit/d6c8177824be3 [4]: https://github.com/odoo/odoo/commit/b7fe6e6704fad runbot-224020
Users who work across multiple companies can now assign themselves to planning slots in a company where they have an employee profile, even if another company is set as their current company. This prevents silent failures and makes multi-company planning assignments behave as expected.
Original PR description
_______________________________________ ## Short functional explanation of the error Let's say we have the scenario where a user has access to company_1 and company_2, but only has a corresponding…
_______________________________________ ## Short functional explanation of the error Let's say we have the scenario where a user has access to company_1 and company_2, but only has a corresponding employee in company_2. If the user selects company_1 and company_2 but keeps company_1 as his current company, and tries to assign himself a task that has been created for company_2, nothing happens. ## Reproduction Steps 1. As an admin, create a user with which you'll be able to log. Make sure that you have at least 2 companies created, and that the user has access to both. Create an employee for that user in company_2. 2. Select both companies. In planning, create a slot for company_2 and publish it. 3. Log in as the user you created. Make sure that the current company is company_1. Select company_2. 4. Go to planning and try to assign yourself to the slot you've just created as an admin ### Expected behavior Either an error message shows, or the employee is assigned to the slot for company_2 (as company_2 is selected). ### Unexpected behavior Nothing happens ## Origin of the issue When the current company isn't the one corresponding to the one the employee is in, even if another company is selected and contains the employee, self.env.user.employee_id is set at False _________________________________________ opw-4963674 --- Forward-Port-Of: odoo/enterprise#91616
Point of Sale now only shows the option to delete cash in/out entries to users who have the right permissions, and displays a clear error if deletion is refused. This avoids confusing failed actions and fixes receipt printing errors related to cash movement receipts.
Original PR description
Before this commit, a user with "account.group_account_invoice" group could try to delete a cash in/out in the pos but had no feedback. Actually, his request was refused but we never tell the user why. We now display the error but also do not give the possibility to the user to delete a cash in/out if he does not have the right group. There was also errors appearing when printing the CashMoveReceipt. We call the ReceiptHeader in the CashMoveReceipt but without giving it a real order which could cause problems cause in the ReceiptHeader we consider the order that is given as a real one and we can call methods and stuff from the model. We now create a dummy order to give to the ReceiptHeader. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228789
This fix prevents sale orders linked to projects from becoming stuck when a related analytic account has been deleted. Users can update the project on affected sale orders without encountering a missing-record error, improving reliability in sales and project workflows.
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
Spanish POS orders using TicketBAI now automatically retry the previously failed submission when a new order is paid. This helps prevent one failed tax report from creating a growing backlog of unreported sales, reducing manual follow-up for users.
Original PR description
Currently, the post failure of a single pos order can easily cause a backlog of more unposted orders since new orders will not be posted until the chain head is posted. Steps to reproduce ----- 1. Validate a pos order and have the TicketBAI post fail 2. Validate another pos order 3. The post for the second order is never attempted Cause ----- `_check_can_post()` ensures that new orders are not posted if the chain head was not posted successfully. During normal operation, it is common for many new orders to be paid before the user has a chance to manually retry the chain head post in the backend, causing a backlog of unposted orders. Solution ----- During `action_pos_order_paid()` retry the chain head post if is not sent. opw-4669823 Forward-Port-Of: odoo/odoo#228477
Deleting a countdown snippet in the website editor no longer leaves background activity running after the block is removed. This prevents repeated errors and keeps the editing experience stable when users delete embedded website content.
Original PR description
Before this commit, interactions where not always destroyed when their target was removed from the DOM. An example of this problem is given by the `s_countdown` snippet. When the snippet is removed…
Before this commit, interactions where not always destroyed when their target was removed from the DOM. An example of this problem is given by the `s_countdown` snippet. When the snippet is removed by `DeletePlugin`, the interaction is not destroyed, and a recurrent interval keeps expiring every second triggering multiple errors. This commit introduces the following changes: 1. `EditInteractionPlugin.refreshInteractions`, which is called on normalization, now checks for every interaction and destroyes the ones linked to a disconnected DOM element. 2. `websiteEditService.refresh` now checks if the target element is disconnected, and in this case stops the interaction. 3. `Countdown` now uses the `waitForTimeout` function, which does not execute any callback if the interation has been destroyed. How to reproduce the problem with `s_countdown`: 1. Insert the snippet `s_text_block` 2. Insert the snippet `s_countdown` in the middle of the text 3. Place the cursor after the countdown 4. Press "backspace" until the countdown is deleted 5. The error appears (Alternatively, place the cursor before the countdown and press delete, or select a portion of text including the countdown and press backspace). task-4367641
Point of Sale now only shows paid orders from the current register setup or its trusted related setups. This prevents staff from seeing unrelated orders from other locations or configurations, reducing confusion and improving order accuracy.
Original PR description
Before this commit, when searching paid orders in the PoS UI, orders from other configs could appear even if they were not part of the trusted configs or the same PoS config. This commit ensures that only orders related to the current PoS configuration (or its trusted configs) are loaded and displayed. opw-5083747 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228289 Forward-Port-Of: odoo/odoo#227709
The rental schedule now correctly lists every rental order when the same serial-numbered item is rented more than once. This helps teams see accurate rental demand and availability instead of undercounting repeated rentals.
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
This fixes an issue where shoppers could select a free reward product from a coupon offer but it was not added to their cart. The checkout now correctly recognizes the selected reward product, helping promotional campaigns work as expected.
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