Thursday, February 26, 2026
9 changes · 17.0
New functionality added to Odoo
This pull request updates the Brazilian fiscal position calculations in Odoo, addressing inconsistencies in reporting. The changes improve the accuracy of financial reports for Brazilian businesses, aligning with local tax regulations. This update ensures compliance and provides more reliable financial data.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update resolves an issue where taxes weren't correctly calculated during Stripe Express Checkout with Google Pay. The fix ensures that Avatax taxes are accurately applied, aligning payment amounts with the final order total. This improves payment accuracy and prevents discrepancies for customers using Google Pay.
Original PR description
## Versions 17.0+ ## Issue Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes. ## Steps to reproduce…
## Versions
17.0+
## Issue
Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes.
## Steps to reproduce
*Ensure the Stripe account has activated Google Pay* *This requires a complete Google profile on Google Chrome (with a valid payment method)*
- Setup Stripe payment method in test mode with Express Checkout;
- In the Settings, in the Accounting section:
- Setup Avatax;
- Set main Sales/Purchase taxes to 0.
- Create a new product with 0% selling taxes and any Avatax category;
- Activate fiscal position and enable automatic detection;
- Open a Chrome session with the Google profile:
- Go to the shop;
- Add the product you created to the cart;
- Enter the cart;
- Click the "Buy with GPay" button:
- The amount is equal to the sales price excluding taxes.
- Go to the Sales app and open the newly created order:
- The total amount differs from the amount paid (cf. transaction).
opw-5020793This update resolves an issue where updating a manufacturing order's Bill of Materials (BoM) would trigger the deletion of outdated work orders, leading to errors. The fix ensures that work orders are only removed when truly obsolete, preventing these deletion attempts and associated errors. This improves the stability of the MRP process.
Original PR description
Steps to reproduce: - Create a storable product P1 with the following BoM: - Component: C1 - Operation: OP1 - Create a draft MO for P1 - Update the BoM by adding a new component - Go back to the MO…
Steps to reproduce:
- Create a storable product P1 with the following BoM:
- Component: C1
- Operation: OP1
- Create a draft MO for P1
- Update the BoM by adding a new component
- Go back to the MO and click "Update from BoM"
Problem:
Missing Record
Record does not exist or has been deleted.
(Record: mrp.workorder(8,), User: 2)
Clicking on `update bom` will launch a call of the `action_update_bom`
which will itself call the `_link_bom` to update the record:
https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/mrp_plm/models/mrp_production.py#L73-L80
https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L2406-L2418
The function will sets `bom_id` to False, which triggers
`_compute_workorder_ids` and `_compute_move_finished_ids`
(depends on bom_id). As the MO is in draft, related moves and
workorders are deleted.
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L849
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L659
After that, it will try to delete the work orders again, and
since the operation no longer exists, an error will be triggered.
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L2586-L2587
opw-5947687This update fixes an issue where the stock forecast report incorrectly displayed reserved quantities from sublocations as negative values in 'Free Stock in Transit'. Previously, reservations from sublocations were not properly accounted for in the forecast. This change ensures accurate stock reporting by removing these reservations from the 'Free Stock' and correctly reflecting them in the forecast.
Original PR description
If you create & reserve a move from a sublocation of the main stock location, the forecast report would put this reserved quantity as a negative line in "Free Stock in Transit" instead of removing it from the "Free Stock". ## Steps to reproduce: - Create sub location WH/Stock/A - Put 20 unit of a storable product P in WH/Stock/A - Create Delivery todo in future of 5 units of P, from WH/Stock/A => Check Forecasted report, Free Stock = 20 | Free Stock in Transit = -5 OPW-5953172 --- <img width="1827" height="784" alt="image" src="https://github.com/user-attachments/assets/57c0b130-3916-4b35-9dad-e642f5319591" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an error in how outstanding amounts are calculated when a down payment is reversed with a credit note. Previously, the system incorrectly produced negative amounts, leading to incorrect settlement calculations. Now, the system accurately reflects the remaining balance, ensuring proper financial reporting.
Original PR description
When having a down payment that is reversed by a credit note, the amount unpaid is wrongly computed. This is because we take the sum of invoice lines price total, regardless they come from invoice or credit note. Therefore we end up with negative value. Steps: - Have a SO for 500 - Make a downpayment for 300, confirm - Make a credit note for the downpayment invoice, confirm -> SO's amount unpaid is -100, it should be 500. If you now settle the SO, the amount unpaid will be -300 instead of 0. opw-5175562
This update fixes an issue where payments for invoices paid within 30 days (PUE) were incorrectly sent to the Mexican tax authority (CFDI). By disabling a specific function, we now ensure that only payments for invoices with longer payment terms are processed for CFDI compliance, improving accuracy and reducing potential errors.
Original PR description
Issue: Sending PUE payments to CFDI/SAT is no more suitable Step to reproduce: - In a Mexican company - Create an invoice (Invoice A) - Add a line - Set Payment Terms to "Immediate payment" - Confirm…
Issue: Sending PUE payments to CFDI/SAT is no more suitable Step to reproduce: - In a Mexican company - Create an invoice (Invoice A) - Add a line - Set Payment Terms to "Immediate payment" - Confirm - Duplicate (Invoice B) - Confirm - Duplicate again (Invoice C) - Set Payment Terms to "30 days" - Confirm - Go to Invoice A - Pay it. It should appear as "Paid" - Send it to CFDI - Go to Accounting > Customer > Invoices - Select Invoice B and C - Pay and select the "Group Payments". They should appear as paid. - In every invoice, click the "Update Payment" button Current behavior: - In Invoice A -> Sheet CFDI: A button "Force CFDI" allow sending the payment to CFDI - In Invoice B/C -> sheet CFDI: Click on the "Download" part of the Payment line, the XML that was sent to CFDI include both invoice B and C Expected behavior: - It shouldn't be possible to send payment for invoice A to CFDI. - Payment for invoice B shouldn't be sent to CFDI Cause: Payment for invoice paid in less than 30 days, referred as PUE, shouldn't be sent to CFDI. Solution: Disable the force sending to CFDI About tests: l10n_mx_edi_cfdi_invoice_try_update_payments already send payment to CFDI for PPD invoices. Calling action_force_payment_cfdi was pointless and causing a mess. opw-5381600
This update resolves an issue where the system would display an error message instead of a traceback when a previous payslip wasn't available for after-departure payments. Now, users will receive a clear, informative message guiding them to add a required reference payslip, ensuring accurate payroll processing.
Original PR description
For after departure payment to work, a previous payslip is required in the system. So, instead of having a traceback, display an informative message to the user. task-5933607
This update fixes a technical issue that was disrupting automated payment flows within Odoo. The previous version was encountering an error, which has now been resolved by simply removing problematic data. This ensures payments can process smoothly and reliably.
Original PR description
The last iteration[^1] was preventing automated flows from running smoothly because it was raising an error. Instead, we now just remove the unsure data. [^1]: 1794fce234735ed174599891435d4e2accc1632
This update ensures Odoo's Dutch tax reporting (SBR and ICP) files are aligned with the latest 2026 version of the Dutch taxonomy. This is crucial for accurate tax reporting compliance in the Netherlands, avoiding potential errors and penalties.
Original PR description
Fix the xml SBR and SBR ICP file template for the 2026 version of dutch taxonomy Documentation: https://www.sbr-nl.nl/werken-met-sbr/taxonomie/documentatie-nederlandse-taxonomie task-5974129