Friday, September 18, 2026
4 changes · master
New functionality added to Odoo
Employees in Mexico can now attach official CFDI invoice XML files directly to draft expenses. The system uses the stamped invoice data to create or reuse vendor bills and keep amounts and taxes aligned with fiscal requirements, reducing manual errors and compliance risk.
Original PR description
The standard expense flow is incompatible with Mexican fiscal law in two ways: 1. CFDI (electronic invoices) are already registered with the SAT at receipt time — the employee cannot decide when they enter accounting. 2. Amounts and taxes are locked by the government-stamped XML — they cannot be adjusted freely in the expense form. This module fixes both by letting employees attach a CFDI XML to a draft expense. From the XML, the module automatically creates or reuses the existing vendor bill, syncs the amounts and taxes from the CFDI if the expense is to reimbure to employee or sets the bill to pay when using company account. task-4455671
This update adds a standard sign-in and consent flow so approved third-party AI/MCP tools can access Odoo on a user's behalf without seeing their password. It also improves compatibility with newer MCP clients by returning clearer protocol errors when a requested method is not available.
Original PR description
To understand the OAuth flow, check the commit message. task-6312868 Forward-Port-Of: odoo/enterprise#131912
Enhancements to existing features
Odoo now supports Obox features in the Android app, including kiosk mode. This enables businesses using Point of Sale and POS Self Order to run supported Obox workflows on Android devices more smoothly.
Resolved issues and error corrections
This fixes Argentina electronic export invoices so small-quantity lines are reported with the correct decimal precision instead of being rounded to two decimals. It prevents ARCA rejections that could block affected companies from issuing export invoices after upgrading.
Original PR description
### Problem `l10n_ar_edi` reports WSFEX / WSBFE line quantities (`Pro_qty`) truncated to 2 decimals in 19.0, no matter what precision the database has configured. `_get_line_details()` reads the…
### Problem
`l10n_ar_edi` reports WSFEX / WSBFE line quantities (`Pro_qty`) truncated to 2 decimals in 19.0, no matter what precision the database has configured.
`_get_line_details()` reads the precision like this:
```python
uom_precision_digits = min(self.env['decimal.precision'].precision_get('Product Unit of Measure'), 2)
```
In 19.0 that `decimal.precision` record was renamed to **`Product Unit`** (`uom/data/uom_data.xml`, `decimal_product_uom`), so the lookup matches no record. `precision_get` does not raise in that case, it falls back to a default of 2 (`base/models/decimal_precision.py`: `return res[0] if res else 2`), so `min(2, 2) = 2`.
The rename was applied everywhere else — `account.move.line.quantity` already declares `digits='Product Unit'`. Only this lookup kept the old name.
### Impact
A quantity of `0.042` is sent as `0.04`. ARCA rejects the invoice with **error 1815** (item math inconsistency: `unit price x quantity - discount` no longer matches the item total), which blocks export invoicing completely.
It only shows up after upgrading to 19.0: on 18.0 the record still had the old name, so the lookup worked and the configured precision was used.
On our hosted fleet we identified **67 Argentinian databases** that use WSFEX or WSBFE and have a unit precision above 2. Eight of them already run 19.0 and are affected today; the rest will hit the same rejection as they upgrade.
### Fix
Use the current record name, and raise the cap to **6**, the maximum `Pro_qty` accepts according to the WSFEX developer manual ([V3.1.1](https://www.afip.gob.ar/ws/documentacion/manuales/WSFEX-Manualparaeldesarrollador_V3.1.1_ARCA.pdf), p. 15).
### Test plan
`l10n_ar_edi/tests/test_fex.py` adds `test_ar_edi_wsfex_pro_qty_decimal_precision`, covering three cases:
| `Product Unit` | quantity | expected `Pro_qty` |
|---|---|---|
| 3 | 0.042 | `0.042` |
| 2 | 0.042 | `0.04` |
| 8 | 0.1234567 | `0.123457` (capped at 6) |
It does not go through the ARCA mock: it calls `_get_rounded_base_and_tax_lines()` and `_get_line_details()` directly.
### Note
Supersedes #130582 by the same author, which carried the same one-line fix without a test. Please review this one instead.
### Left out on purpose
`price_precision_digits` in the same method caps the unit price at 3 digits, which does not come from the specification either. That lookup still uses a record name that exists (`Product Price`), so there is no regression, and we have no rejection reported because of it. Changing it would widen the scope of a fix that has a concrete incident behind it, so it is left untouched here.
Forward-Port-Of: odoo/enterprise#131457