Daily updates from Odoo
Friday, June 5, 2026
6 changes · saas-18.2
Resolved issues and error corrections
This update corrects a bug in the VAT reporting module that was incorrectly assigning a '01' operation code to invoices with 'No Sujeto por reglas de localización' (PT VAT) taxes. The fix ensures that these invoices are correctly identified with the standard '17' code, aligning with Spanish VAT regulations and SII reporting. This ensures accurate VAT reporting for our Portuguese customers.
Original PR description
**Steps to reproduce:** * Install the **l10n_es_edi_sii** module. * Create a **Portuguese customer**. * Go to **Settings** and enable **EU Intra-community Distance Selling**, then refresh the tax…
**Steps to reproduce:** * Install the **l10n_es_edi_sii** module. * Create a **Portuguese customer**. * Go to **Settings** and enable **EU Intra-community Distance Selling**, then refresh the tax mapping. * Create a customer invoice with a **"No Sujeto por reglas de localización"** tax (e.g. **23.0% PT VAT**). * Go to **Accounting → Reporting → Tax Report → OSS Sales**. * Export the **VAT Record Books (XLSX)** file and open it. **Observed behavior:** * The "Clave de Operación" column shows "01" for lines with no_sujeto_loc taxes instead of "17". * The SII JSON for the same invoice correctly shows "ClaveRegimenEspecialOTrascendencia": "17". **Cause:** * In `_l10n_es_libros_get_common_line_vals()`, `operation_code` was computed manually as `'02' if exempt_reason else '01'`, which only handled the E2 exempt case and defaulted everything else to "01". * This missed OSS/no_sujeto_loc taxes (e.g. FR VAT, PT VAT) that should produce "17" per the Spanish VAT regime code table. **Fix:** * Extract operation code computation into a new dedicated method `_l10n_es_libros_get_operation_code()`. * For customer invoices, delegate to the existing `_l10n_es_get_regime_code()` method already used by SII, which correctly returns "17" for OSS-tagged taxes, "02" for E2 exempt, and "01" otherwise. * For vendor bills, mirror the SII logic by checking whether the invoice taxes include tags from `mod_303_casilla_10_balance` or `mod_303_casilla_11_balance` (intra-community indicators), returning "09" if so and "01" otherwise. opw-6197141,6216485 Forward-Port-Of: odoo/enterprise#117236
This update fixes a calculation error in Odoo's Point of Sale integration with UrbanPiper. Previously, tax calculations on online orders with 'Tax Included' were incorrect, leading to inaccurate pricing. The fix ensures the unit price reflects the total amount, including tax, for a more accurate customer experience.
Original PR description
Steps to reproduce: --- - Configure Point of Sale with UrbanPiper credentials. - Sync a product priced at 100 with a 5% GST (tax type = Tax Included). - Place a test order. Issue: --- - Wrong calculation in order line: - unit_price: 95.24 - Tax Excl. price: 90.70 - Tax Incl. price: 95.24 - Expected: - unit_price: 100 - Tax Excl. price: 95.24 - Tax Incl. price: 100 Cause: --- - While computing the unit_price with Tax Included, the tax amount was not added back. Fix: --- - Ensure unit_price includes the tax amount when tax type is Tax Included. task-5031196 Forward-Port-Of: odoo/enterprise#92854
This update corrects a previous issue where all e-commerce invoices were automatically formatted as CFDI (Mexican electronic invoicing). Now, invoices generated from the website will only be CFDI to public when explicitly required, aligning with standard business practices and customer data privacy.
Original PR description
There is no reason why we would always cfdi to public when creating orders from the e-commerce. When the customer give all their info, the invoice should not be cfdi to public. opw-6180766 Forward-Port-Of: odoo/enterprise#119171 Forward-Port-Of: odoo/enterprise#116061
This update fixes an issue where check amounts were not being properly rounded in the Philippines (PH) version of Odoo. Previously, the check amount in words displayed with an incorrect decimal format, including 'ONLY'. This change ensures that check amounts are rounded to the nearest cent, presenting a more accurate and professional representation of payments.
Original PR description
Current behaviour: --- When paying with checks, the amount is not rounded in the check amount in words string. Steps to reproduce: --- 1. Switch to PH company 2. Set setting Check Layout as "Print Check - PH" 3. Create a new vendor bill 4. Add a product with a specific price like 91490.15 5. Confirm the bill, click on Register Payment 6. Select Payment Method "Checks", Create Payment 7. Go to the payment, Amount in Words is wrong 8. Ninety-One Thousand Four Hundred Ninety And 15000000001/100 ONLY Expected behaviour: --- The decimal amount should be rounded, and "ONLY" shouldn't appear. Fix: --- Rounded the pay amount And backported: https://github.com/odoo/enterprise/commit/bb6c9848665709c14c5113b2c98976f869cd473b opw-6058344 Forward-Port-Of: odoo/enterprise#117679 Forward-Port-Of: odoo/enterprise#116717
This update fixes a potential issue where closing a POS session could incorrectly identify and block the cancellation of transactions belonging to other POS terminals. The change now ensures that only transactions associated with the specific POS terminal are retrieved, preventing errors and improving the reliability of session closure. This enhances the overall stability of the POS system.
Original PR description
Before this commit, when closing a POS session, it fetched all active transactions via generic /tx endpoint, which returns transactions across all TSS. Attempting to cancel a transaction belonging to another TSS raised:
"Not a Transaction of TSS <tss_id>"
Fix by scoping the fetch to /tss/<tss_id>/tx so only transactions of the current TSS are returned, and appending client_id as an additional filter to avoid touching transactions from other POS terminals sharing the same TSS. A JS-side client_id check is kept as a defensive safety net before the cancellation loop.
opw-6243187
Forward-Port-Of: odoo/enterprise#118662This update resolves an issue where users were blocked from uploading documents to requests linked to records they didn't have full access to. By adding a special permission bypass, users can now upload documents regardless of their direct access rights to the related record, improving workflow efficiency.
Original PR description
Issue: Users are currently blocked from uploading requested documents if the request is linked to a record they do not have access to (e.g., User A links Record X to a request assigned to User B, but User B lacks read/write access to Record X). The system throws an error because the user cannot create an attachment for that record. Fix: Add .sudo() on the attachment creation process. task-6107099 Forward-Port-Of: odoo/enterprise#113698