Daily updates from Odoo
Wednesday, October 1, 2025
8 changes · master
Resolved issues and error corrections
Shiprocket Cash On Delivery orders now correctly include coupon discount amounts when sending shipment details. This helps ensure the amount collected from customers matches the discounted order total, including taxes.
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#95563
Forward-Port-Of: odoo/enterprise#92310The point of sale now waits for blackbox discount processing to finish before allowing payment. This prevents outdated payment amounts from being sent to a terminal, reducing cashier confusion and 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
Helpdesk users can now open closed-ticket views and use closed-date filters without triggering an error. This keeps ticket reporting and follow-up workflows accessible when teams filter recent closed tickets.
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 Forward-Port-Of: odoo/enterprise#94048
Bank transactions from a company branch can now be reconciled with payments from the main company or related branches when they share the same end-to-end payment reference. This prevents valid payments from being left unreconciled in multi-branch company setups.
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 Forward-Port-Of: odoo/enterprise#94592
Brazilian electronic invoicing now better detects failed submissions even when the tax service response does not include the usual error field. This prevents rejected invoices from being incorrectly treated as successfully processed, improving reliability for Brazilian fiscal workflows.
Original PR description
Avalara typically returns errors by including an "error" key, but this doesn't always happen. In case of a "302" code response we were erronously considering EDI to have succeeded. To fix this, we implement an additional error code check using codes from the official specification [1]. It's tempting to think that every code in the [100, 199] range is a successful one, but 142 is a rejection code. [1] https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=J+I+v4eN00E%3D opw-4766828
Field service tasks now price service lines using the customer’s assigned pricelist instead of the product’s default price. This ensures customers are billed according to their agreed pricing when tasks 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#95744 Forward-Port-Of: odoo/enterprise#88039
Swedish Bankgiro and Plusgiro accounts are now handled correctly when generating SEPA payment files and Peppol BIS 3 invoices. This prevents missing bank details in payment files and ensures invoice XML includes the required bank identifier while leaving other bank accounts unchanged.
Original PR description
Bankgiro and Plusgiro accounts in Sweden normally do not have a BIC. However, for Peppol BIS 3 invoices, a BIC tag is required in the XML. The existing _skip_CdtrAgt logic prevents _get_CdtrAgt from being called when no BIC is set, causing the clearing_number to be missing in SEPA payment files for Bankgiro and Plusgiro accounts. This commit introduces overrides for SE-specific account types: _get_cleaned_bic_code: Returns 'SE:Bankgiro' or 'SE:Plusgiro' for Swedish Bankgiro and Plusgiro accounts, ensuring a BIC is present for the invoice XML. _skip_CdtrAgt: Returns False for Bankgiro and Plusgiro accounts to ensure _get_CdtrAgt is called, including the clearing number in the payment file. This guarantees that SEPA payment files and Peppol BIS 3 invoices for Sweden are generated correctly while preserving standard behavior for other banks and countries. Forward-Port-Of: odoo/enterprise#95910
This fixes Engineering Change Orders so very small bill of materials quantity changes use the product unit of measure precision instead of rounding to two decimals. Businesses using high-precision units can now track and apply component changes such as 0.0003 accurately.
Original PR description
Steps to reproduce the bug:
- Go to Decimal Accuracy → Product Unit of Measure → set digits to 4
- Go to Units of Measure Categories → select a unit → set rounding to 0.0001
- Create a storable product “P1” with a BoM:
- Component C1: 1.0000 unit
- Create an ECO for the BoM with type BoM update
- Start the revision
- Go to V2
Problem:
You cannot update the quantity of C1 to 1.0003 (for example) because the system uses the default 2 digits instead of the UoM digits.
opw-5082488
Forward-Port-Of: odoo/enterprise#95470
Forward-Port-Of: odoo/enterprise#95180