Saturday, September 12, 2026
7 changes · 19.0
Resolved issues and error corrections
Mexican electronic payment complements now format tax amounts using the decimal precision required for the payment currency, such as two decimals for MXN. This prevents PAC rejections after stricter SAT validation and improves handling when payments and invoices use different currencies.
Original PR description
The 'ImpuestosP' node of the payment complement (Pagos 2.0) is reported with 6 decimals while the SAT expects the amounts to be expressed with the number of decimals supported by the currency of the…
The 'ImpuestosP' node of the payment complement (Pagos 2.0) is reported with 6 decimals while the SAT expects the amounts to be expressed with the number of decimals supported by the currency of the payment ('MonedaP'), as published in the 'c_Moneda' catalog, for example 2 decimals for MXN.
Steps to reproduce:
- Have an MX Company setup with Quadrum as PAC.
- Create and sign a customer invoice in MXN with a 16% IVA tax.
- Register a full payment and send the payment complement to the PAC.
Issue:
Payment will be rejected
```
Code : CRPER654
Message : El importe del campo BaseP que corresponde a Traslado, no tiene la cantidad de decimales que soporta la moneda (MonedaP)
```
Analysis:
Quadrum recently aligned its validation on that rule and now rejects the document having fields with too much decimals and, currently, fields like BaseP, ImporteP are pinned to 6 decimals in the template.
Reporting them with the decimals of the payment currency is not enough when the payment settles a document expressed in another currency: those amounts are also compared with the ones of the related documents converted with 'EquivalenciaDR', and the PAC expects the values truncated or rounded
```
Code : CRP20274
Extra Info : Traslados: La sumatoria de ImporteDR es mayor al ImporteP 1.30.
Valores minimos permitidos: Truncado: 1.29 o redondeado: 1.3
```
opw-6561617
Forward-Port-Of: odoo/enterprise#131267The Chilean electronic invoicing workflow now handles cases where the tax authority returns an empty status response. This prevents scheduled invoice status checks from crashing and helps keep document processing running smoothly.
Original PR description
When checking the status of a DTE, sometimes the response will have no `text`. This causes a traceback error that halts execution of the cron `cron_run_sii_workflow`. opw-6322106 Forward-Port-Of: odoo/enterprise#130873 Forward-Port-Of: odoo/enterprise#129582
This change prevents some Odoo pages from incorrectly showing a 404 error when the server runs on Windows. It keeps web address handling consistent across operating systems, improving reliability for Windows deployments.
Original PR description
* URL paths are POSIX (forward slashes). Use posixpath so the `..` jail still applies while keeping `/` separators — os.path.normcase / normpath rewrite `/`->`\` on Windows and break the split below. 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
This fixes an issue where invoicing a previous point-of-sale order could send the wrong cancellation information to Spain's AEAT tax system. The correction ensures the original simplified receipt is cancelled instead of the newly created full invoice, helping avoid inaccurate tax reporting.
Original PR description
When creating an invoice for a previous POS order, the data sent to AEAT cancels the full invoice instead of the order's simplified invoice. Steps to reproduce: - Open a POS and make a sale without invoicing it; - In the POS, go to the Order tab; - Select the order and fully invoice it. Issue: The AEAT cancellation line added to the pos order actually cancels the full invoice just created [opw-6471927](https://www.odoo.com/odoo/project/49/tasks/6471927) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where company card payments could be blocked if a previous expense created by the same card had its date removed. Expenses without a date are now only counted in all-time limits, allowing future card transactions to continue normally.
Original PR description
Fix a traceback preventing card users to make any payment with their card if at least one expense created by said card has no date Steps to reproduce: - Install hr_expense_stripe_demo (to access the test wizards) - Setup the stripe (demo) account with a valid card and funds - Create one transaction with the card - Remove the date of the generated expense -> Any further transaction with that card will fail After this commit: An expense with no date is considered only in the 'all time' Ticket [link](https://www.odoo.com/odoo/project.task/6326124) opw-6326124
This fix makes an automated mail discussion test run consistently by waiting for the subscription event at the right time. It reduces false test failures in Odoo's validation pipeline without changing customer-facing behavior.
Original PR description
Backport of 9a8f127a6c9a (odoo/odoo#280680), currently on saas-19.4 and on master (6da9738c26e2). Before this commit, the discuss test "Message shows up even if channel data is incomplete" failed on runbot with "Websocket subscription not received.". This happens because waitUntilSubscribe() only resolves on a subscription received after it is called, and the test calls it after running all timers. The forced channel update is debounced, so that timer run sends the subscription, and the wait then times out. This commit calls waitUntilSubscribe() before forcing the channel update, so the subscription that update sends resolves the wait. https://runbot.odoo.com/odoo/error/947146 Forward-Port-Of: odoo/odoo#287864
Manufacturing order overviews now calculate totals correctly even when related work orders do not have an employee assigned. This prevents misleading cost summaries and helps managers rely on accurate production cost information.
Original PR description
Description of the issue/feature this PR addresses: Resolves an issue where Manufacturing Order (MO) summary calculations produced incorrect totals when associated Work Orders had no assigned employee. Current behavior before PR: <img width="2419" height="802" alt="mo-wo-employee-fix-before" src="https://github.com/user-attachments/assets/9a0d64b4-2ca3-4732-9ac7-39673e0ae319" /> Short-circuiting the logic when a work order has no associated employee causes an error in the overview's cost calculation. Behavior after PR: <img width="2389" height="641" alt="mo-wo-employee-fix-after" src="https://github.com/user-attachments/assets/f2b67e84-c149-4d05-be30-f834e62e0882" /> By updating it to no longer short-circuit it now correctly calculates the cost of the manufacturing order. opw-6464637 Forward-Port-Of: odoo/enterprise#130554 Forward-Port-Of: odoo/enterprise#128465