Friday, March 20, 2026
11 changes · saas-18.4
Resolved issues and error corrections
Malaysian POS consolidated e-invoices now show the full invoice total as payable, instead of being reduced to zero by already-recorded counter payments. This keeps MyInvois submissions aligned with tax authority expectations and helps avoid validation or support issues.
Original PR description
For POS consolidated invoices, the PrePayment Amount was mapped to the payment linked to the document. This incorrectly decreased the Total Amount Payable to 0, since POS orders are already paid at the counter. MyInvois tax officer and helpdesk requires that the Total Amount Payable (cbc:PayableAmount) to reflect the total amount of the issued e-document , regardless of prior payments. This commit forces the PaidAmount to 0 for consolidated documents, ensuring the PayableAmount correctly matches the TaxInclusiveAmount as expected by the MyInvois API. task-[6021698](https://www.odoo.com/odoo/all-tasks/6021698) Forward-Port-Of: odoo/odoo#253499
Overtime calculations are now refreshed whenever employee leave records are created, changed, or removed. This prevents attendance that overlaps with approved leave from being counted incorrectly, improving payroll and time-tracking accuracy.
Original PR description
When we re-evaluate leaves we update overtimes after switching to draft but we do not update the overtimes again after the leave is switched back to validated. This causes the overtimes from attendances that overlap with the leave to be miscalculated as if the leave was not validated. To rectify this issue, we recalculate the overtimes for the affected employees after every create/write/unlink of `resource.calendar.leaves`. opw-4844447 Forward-Port-Of: odoo/odoo#254538 Forward-Port-Of: odoo/odoo#229723
This update brings the spreadsheet component to the latest version and fixes several user-facing issues. Users should see more reliable copy-paste behavior, improved chart labels and map data, and better dashboard filter and pivot table handling.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/8b717af644 [REL] 18.4.31 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/8b717af644 [REL] 18.4.31 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/eac5fbcad4 [FIX] clipboard : paste as value [Task: 5936382](https://www.odoo.com/odoo/2328/tasks/5936382) https://github.com/odoo/o-spreadsheet/commit/24a439d49d [FIX] Chart: Update geojson data [Task: 5224009](https://www.odoo.com/odoo/2328/tasks/5224009) https://github.com/odoo/o-spreadsheet/commit/af37488eb1 [FIX] charts: hierarchical charts should show formatted labels instead of raw [Task: 5913296](https://www.odoo.com/odoo/2328/tasks/5913296) https://github.com/odoo/o-spreadsheet/commit/d98fe868ff [FIX] filters: allow criterion filter in dashboard [Task: 6017734](https://www.odoo.com/odoo/2328/tasks/6017734) https://github.com/odoo/o-spreadsheet/commit/a84e0f1623 [FIX] pivot: can add the same granularity [Task: 5949522](https://www.odoo.com/odoo/2328/tasks/5949522) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This fixes how Spanish Facturae electronic invoices group and round tax totals at the invoice level. It helps produce compliant invoice XML and reduces rounding discrepancies that could cause validation or processing issues.
Original PR description
- Adjusting invoice-level `<TaxesOutputs>` nodes to be generated per tax rather than per line - Enabling rounding for invoice-level tax data aggregation - Adding a second rounding test derived from bug ticket task-6009108 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253305
Belgian Peppol invoices with global rounding could fail validation when decimal quantities created a one-cent difference. The fix reports that difference in the invoice rounding field instead of changing a line amount, helping affected invoices send successfully.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_be - Switch to a Belgian company (e.g. BE Company CoA) - In Accounting settings: * activate Peppol * set "Rounding Method" to "Round Globally" -…
**Steps to reproduce:**
- Install Accounting and l10n_be
- Switch to a Belgian company (e.g. BE Company CoA)
- In Accounting settings:
* activate Peppol
* set "Rounding Method" to "Round Globally"
- Create an invoice:
* Customer: [a Belgian customer with a VAT]
* Invoice Lines:
| Label | Quantity | Price | Taxes |
| ------- | ---------- | ------- | ------- |
| Line 1 | 1.0 | 90.30 | 0% |
| Line 2 | 0.45 | 2.54 | 6% |
| Line 3 | 0.28 | 6.87 | 6% |
- Confirm the invoice
- Send the invoice to Peppol
**Issue:**
The generated XML has a line with `<cbc:LineExtensionAmount>` set to 90.31, `<cbc:InvoicedQuantity>` set to 1.0 and `<cbc:PriceAmount>` set to 90.30, which fails the validation with the following error:
`[BR-E-08]-In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Exempt from VAT" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are "Exempt from VAT".`
**Cause:**
The use of decimal number in quantity generates a 0.01 rounding difference in the base amounts.
The extra cent is dispatched in one of the `<cbc:LineExtensionAmount>` node.
**Solution:**
There is no easy solution to handle these rounding cases. The solution used in this fix is to handle the extra cents as if they are cash rounding amount and declare them in `<cbc:PayableRoundingAmount>` node.
opw-5933545
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#253625Selecting a suggested item after typing @ in the mail composer no longer triggers an error. This keeps message composition smooth and prevents users from being interrupted when mentioning people or records.
Original PR description
Problem: Opening the composer, typing "@" and selecting any item causes a traceback. Cause: After 8c99b17fcc3a612fd897da9ee29e2f53254d5933, the attribute `channel` was renamed to `thread`. Some code still referenced the old `channel` attribute, leading to errors when selecting mentions. Steps to reproduce: - Open the composer. - Type "@" to trigger mentions. - Select any item from the suggestions. - Observe a traceback. opw-6030307 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254127
This fix ensures accounting entries are created when the billed price for a dropshipped product differs from the purchase order price. It prevents missing expense and interim account corrections, improving financial accuracy for dropshipping flows using automated inventory valuation.
Original PR description
**Problem:** compensation amls are not created for dropshipped products when there is a difference between the price of the PO and the price on the bill **Context:** For non dropship avco real time…
**Problem:** compensation amls are not created for dropshipped products when there is a difference between the price of the PO and the price on the bill **Context:** For non dropship avco real time products: When you create a PO for a product @ 10 - stock interim received is credited of 10 - stock valuation is debitted of 10 And you then validate a bill for a price of 8 - stock interim received is debitted of 8 - account payable is creditted of 8 This leaves stock interim received with credit of 2 and stock valuation is over valued by 2. So we create 2 extra account move lines - One debit of 2 for stock interim received - One credit of 2 for stock valuation (or Expenses if the product is not in stock anymore because then it's the expense account which was over valuated) nb: if the product is still in stock those 2 lines are created via stock valuation layer In the case of a dropshipped product, the product is not in stock anymore so it should be creditting expense, but no extra amls are created at all. **Steps to reproduce:** - enable the "dropshipping" and "anglo saxon accounting" settings - create a storable product with avco automated category - in the inventory tab, select the dropship route - in the purchase tab, set a vendor - create and a confirm a quotation for this product - on the linked purchase order, set a unit price of 10$ and confirm - validate the dropship move - create a bill for the purchase order - set the price to 8$ and confirm - navigate to journal items and search for your product **Current behavior:** no compensation account move lines were created **Expected behavior:** 2 account move lines should have been created: - One debitting 2 in stock interim received - One creditting 2 in expense **Cause of the issue:** *the following logic was introduced by* https://github.com/odoo/odoo/pull/126536 to create those extra amls and layers, _apply_price_difference() is called inside _post() https://github.com/odoo/odoo/blob/32408a8dea43f57bba1a56c775ae228131720749/addons/purchase_stock/models/account_invoice.py#L129 There we have 2 problems : Problem 1: When fetching the layers linked to the account move line, we fetch both the incoming and the outgoing valuation layers because they are both linked to the dropship move. https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L46 But we only want the incoming layer because the outgoing layer should not interfere with the bill. nb: In a standard case like the one of the steps to reproduce, it would work to leave both layers, but : - it works for the wrong reasons : the quantity of the aml would first be consumed on the incoming layer and nothing would happen with the second layer as the quantity of the incoming layer is the same as the one of the aml. - it would probably break in more complex use cases. So it feels unnecessarily risky to leave it like that. Problem 2: Inside _generate_price_difference_vals we call _replay_history which returns two values that are assigned to two variables. https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L82 The second variable, layers_and_invoices_qties is a default dict which keys are tuples (layer L, invoice I) mapped with [the initial quantity invoiced by I on L, the remanining qty invoiced by I on L] (here 'remaining' is related to invoice and has nothing to do with stock qties) https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L168-L171 So in our very basic use case, with a single invoice and a single layer, we should have a key (our layer, our invoice) linked to the value [1,1]. But this key is not in the dictonary. *The reason is the following :* inside _replay_history the parameter "history" contains the layers and the amls (in our case 1 layer and one aml which is self). Each layer is added to qty_to_invoice_per_layer https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L177-L178 https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L191-L192 Then, for each aml: the layers are added to layer_to_consume, alongside their remaining quantity. https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L215-L221 And for each layer which has a quantity billed by the invoice, a key is added to layers_and_invoices_qties https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L222-L231 In our case, the move linked to the layer is the dropship move so _is_in() will be false and the layer won't be added to layers_to_consume. https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L220-L221 So the key will not be created. *The consequence is the following:* Later in _generate_price_difference_vals() we acces the value of this key (the key that should be there (layer, invoice)) https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L91 to get the invoiced qty which will later be used to determine which quantity is still in stock and which is out of stock (giving us the quantities for the compensation layers and amls) but as the key does not exist, invoicing_layer_qty will have a value of 0 so we will exit the loop and no amls or svls will be created https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L92-L93 opw-5498878 Forward-Port-Of: odoo/odoo#254694 Forward-Port-Of: odoo/odoo#253298
This update resolves an issue impacting VAT calculations for Peru (PE) invoices. A previous change removed a key element needed for accurate tax tier determination, leading to incorrect tax amounts. This fix reintroduces the necessary 'TierRange' setting, ensuring proper VAT calculations are generated for PE invoices.
Original PR description
In [^1] the PE implementation for XML generation was rewritten to use the new dict_to_xml design rather than a large QWeb view. In that refactor the `TierRange` key on `TaxCategory` was lost. This PR re-introduces it. task-6046603 [^1]: odoo/enterprise#87598
This update fixes a user experience issue where the 'Generate PDFs' button didn't process all employee declarations when multiple pages were involved. Now, selecting 'Select All' reliably generates PDFs for all records in the list, and users can easily regenerate PDFs for existing documents. This ensures a smoother and more intuitive process for generating payroll reports.
Original PR description
This PR solves the following issues: - In the list view of employee declarations, when the records span to multiple page, pressing `Select all` and the `Generate PDFs` button only generates the PDFs of the records selected on the current page, which is confusing for users who expect all records to be processed. - When you select lines that have a generated PDF, you should have an option to regenerate the PDF if needed. At the moment, the Generate PDFs button only works on lines in draft state. task-5909426 Forward-Port-Of: odoo/enterprise#107232
This update fixes an issue where quarterly VAT returns in the Italian tax module didn't automatically generate the necessary XML files. The fix corrects a logic error that was relying on the wrong date field for determining the return period. Now, quarterly returns will correctly produce the XML files required for submission.
Original PR description
## Issue: When the tax return periodicity is set to quarterly and the return is validated, the XML file is not generated and downloaded ## Cause: The quarter detection logic was based on the `date_from` field of the return However, for quarterly returns, the correct reference should be `date_to` Using `date_to` also works correctly for monthly returns ## Steps to reproduce: - Install `l10n_it_xml_export` - Switch to the IT Company - Go in the Tax Report (Monthly VAT Report (IT)) to do a Tax Return (Opening Date: 01/01/2025, Periodicity: Quarterly) - If needed change the Tax Return Periodicity in Settings to Quaterly - Select the first report and ignore the error in Review Before the fix, it is only possible to close the return without generating the XML export opw-5707544 Forward-Port-Of: odoo/enterprise#108548
This update resolves a discrepancy in accounting calculations within the Point of Sale (POS) module for Mexican tax reporting (l10n_mx_edi_pos). Previously, asset loading issues resulted in incorrect amounts being displayed in the POS, now the calculations align with those performed in Python. This ensures accurate financial reporting for users in Mexico.
Original PR description
Before this commit, the needed assets were not correctly loaded in the POS, which caused the amounts to be different from the ones computed in python. opw-5970322 Forward-Port-Of: odoo/enterprise#111266