Odoo Changelog — 2026-05-18

Monday, May 18, 2026

2 changes · master

Bug Fixes(2)

Resolved issues and error corrections

[FIX] sale_(lazada,shopee): marketplace discount fix

EnterprisemastersaleaccountMEDIUM

This update resolves discrepancies in order totals between Odoo and Shopee/Lazada due to rounding differences when handling marketplace discounts. The changes ensure accurate tax calculations and total amounts, improving order reconciliation and preventing financial inaccuracies.

Original PR description

Marketplace orders with discounted tax-exclusive lines could not match the platform total: Odoo accumulated a small rounding residue vs Shopee's total_amount / Lazada's order price. sale_shopee…

Marketplace orders with discounted tax-exclusive lines could not match the
platform total: Odoo accumulated a small rounding residue vs Shopee's
total_amount / Lazada's order price.

sale_shopee
-----------
- Use model_discounted_price as price_unit (discount=0) instead of a
  percentage discount.
- Rename _recompute_subtotal to _compute_subtotal to derive tax-exclusive
  subtotals from tax-inclusive totals (aligned with sale_lazada).
- Add _compute_reconciled_line_specs: price-include taxes keep the discounted
  unit price; tax-exclusive taxes use the nominal rounded tax-exclusive unit.
- In _create_order_from_data, append a tax-free "Shopee Amount Adjustment"
  line for any residue vs Shopee total_amount.
- Add a dedicated shipping line with fiscal-position-mapped taxes.
- Structure SO line descriptions (SKU, promotion, original price) via
  _build_item_description.
- Consolidate tests with build_order_mock(**extra); tax fixtures use an
  explicit tax group where required (Odoo 19+).

sale_lazada
-----------
- Port the same reconciliation model: reconciled line specs, discount=0 with
  discounted unit from paid_price, shipping line from shipping_fee, order-level
  tax-free "Lazada Amount Adjustment" vs order price.
- Group by SKU: _build_item_description (SKU, voucher, original price);
  skip all-canceled SKU buckets.
- Tests: build_order_mock(), same tax fixture pattern as sale_shopee.

task-6112062

#marketplace#discount#tax#reconciliation

[FIX] l10n_fr_intrastat: include quantityInSU in DEBWEB2 XML export

PR #117503

Enterprisemasterl10n_fr_intrastatMEDIUM

This update corrects a problem in the French Intrastat export process. Previously, the system was missing crucial quantity data related to supplementary units when generating the DEBWEB2 XML file. This fix ensures that all relevant data is included, improving the accuracy of Intrastat reporting for French companies.

Original PR description

Steps to reproduce 1. In a French company with Intrastat enabled, set up a product whose commodity code has a CN supplementary unit (e.g. 8802 30 00, "p/st") and set…

Steps to reproduce
1. In a French company with Intrastat enabled, set up a product whose commodity code has a CN supplementary unit (e.g. 8802 30 00, "p/st") and set `intrastat_supplementary_unit_amount` on it.
2. Post EU customer invoices for that product.
3. Export the DEBWEB2 XML from the Intrastat report.

Issue
The FR export collapses engine rows a second time in `_group_items`, because the DEBWEB2 format groups more aggressively than the SQL. The aggregator only declares `value` and `weight`: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/models/account_intrastat_report.py#L308-L313 Items are then rebuilt as `dict(zip(grouping_key, key_tuple)) | grouped_item_values`. `SU_code` survives (it is in the grouping key), but the numeric `supplementary_units` is in neither side and is silently dropped as soon as two engine rows merge. The template then skips the element because of its `t-if="item.get('supplementary_units')"` guard: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/data/intrastat_export.xml#L61

opw-6139657

Forward-Port-Of: odoo/enterprise#117357
Forward-Port-Of: odoo/enterprise#117033

#intrastat#export#france#reporting

Marketplace orders with discounted tax-exclusive lines could not match the platform total: Odoo accumulated a small rounding residue vs Shopee's total_amount / Lazada's order price. sale_shopee ----------- - Use model_discounted_price as price_unit (discount=0) instead of a percentage discount. - Rename _recompute_subtotal to _compute_subtotal to derive tax-exclusive subtotals from tax-inclusive totals (aligned with sale_lazada). - Add _compute_reconciled_line_specs: price-include taxes keep the discounted unit price; tax-exclusive taxes use the nominal rounded tax-exclusive unit. - In _create_order_from_data, append a tax-free "Shopee Amount Adjustment" line for any residue vs Shopee total_amount. - Add a dedicated shipping line with fiscal-position-mapped taxes. - Structure SO line descriptions (SKU, promotion, original price) via _build_item_description. - Consolidate tests with build_order_mock(**extra); tax fixtures use an explicit tax group where required (Odoo 19+). sale_lazada ----------- - Port the same reconciliation model: reconciled line specs, discount=0 with discounted unit from paid_price, shipping line from shipping_fee, order-level tax-free "Lazada Amount Adjustment" vs order price. - Group by SKU: _build_item_description (SKU, voucher, original price); skip all-canceled SKU buckets. - Tests: build_order_mock(), same tax fixture pattern as sale_shopee. task-6112062

Steps to reproduce 1. In a French company with Intrastat enabled, set up a product whose commodity code has a CN supplementary unit (e.g. 8802 30 00, "p/st") and set `intrastat_supplementary_unit_amount` on it. 2. Post EU customer invoices for that product. 3. Export the DEBWEB2 XML from the Intrastat report. Issue The FR export collapses engine rows a second time in `_group_items`, because the DEBWEB2 format groups more aggressively than the SQL. The aggregator only declares `value` and `weight`: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/models/account_intrastat_report.py#L308-L313 Items are then rebuilt as `dict(zip(grouping_key, key_tuple)) | grouped_item_values`. `SU_code` survives (it is in the grouping key), but the numeric `supplementary_units` is in neither side and is silently dropped as soon as two engine rows merge. The template then skips the element because of its `t-if="item.get('supplementary_units')"` guard: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/data/intrastat_export.xml#L61 opw-6139657 Forward-Port-Of: odoo/enterprise#117357 Forward-Port-Of: odoo/enterprise#117033