Odoo Changelog — 2025-12-22

Monday, December 22, 2025

6 changes · 18.0

New Features(2)

New functionality added to Odoo

[IMP] l10n_gt: add new accounts,tax groups and taxes.

Core18.0l10n_gtMEDIUM

This update adds support for Guatemalan tax regulations, specifically related to Factura Especial (FESP) transactions. It introduces new accounts and tax groups to handle VAT and ISR withholdings, aligning Odoo with local legal requirements.

Original PR description

**PURPOSE**
- In Guatemala, a Factura Especial (FESP) is a legal mechanism established in 
  Art. 52 of the VAT Law.
- To achieve this functionality, we need to create withholding taxes.

**SPECIFICATION**
- Added new accounts for VAT and ISR withholdings.
- Added new tax groups for VAT and ISR.
- Added new taxes with negative values in withholding. 

task-5026698

see
- https://github.com/odoo/enterprise/pull/96007

#accounting#guatemala#vat#isr#tax

[IMP] l10n_gt_edi: add special invoice i.e FESP (withholding on vendors).

PR #96007

Enterprise18.0l10n_gt_ediMEDIUM

This update adds support for Factura Especial (FESP) invoices in Guatemala, a legal requirement for purchases without supplier invoices. It ensures accurate accounting by handling withholding taxes and generating the necessary reports for the SAT, improving compliance and financial reporting.

Original PR description

### PURPOSE - In Guatemala, a Factura Especial (FESP) is a legal mechanism established in Art. 52 of the VAT Law. - Generate Factura Especial (FESP) when registering a purchase without a supplier…

### PURPOSE
- In Guatemala, a Factura Especial (FESP) is a legal mechanism established in 
  Art. 52 of the VAT Law.
- Generate Factura Especial (FESP) when registering a purchase without a 
  supplier invoice.
- Include all required data: supplier as receiver, transaction details, and the 
  retention complement (100% VAT + ISR withholding).
- Ensure proper accounting: supplier payable = net after retentions, 
  taxes withheld = recorded as liabilities to be paid to SAT.
- Fulfill FEL technical requirements (DTE XML, mandatory phrase, retention
  complement, see example attached).

### SPECIFICATION
- Added flow for FESP (Factura Especial) document type in vendor bills.
- Automatically added Phrase Type 5, Scenario 1 (as required by SAT).
- Enforced mandatory data by raising UserError if FESP is selected but
  no withholding taxes are set on the product lines.
- Added complement generation for withheld taxes (IVA, ISR) with base, rate, 
  and amounts.
- Allow users to send a document to SAT in case of FESP. 
- Added required details in FEL XML for FESP.

task-5026698

see
- https://github.com/odoo/odoo/pull/229493

#guatemala#vat#withholding#fesp

Bug Fixes(4)

Resolved issues and error corrections

[FIX] account: preserve manually changed prices when changing fiscal position

PR #240813

Core18.0accountMEDIUM

This update fixes an issue where manually adjusted prices on customer invoices were being reset when the invoice's fiscal position was changed. The fix ensures that prices remain as the user intended, mirroring the behavior of Sale Orders. This improves accuracy and reduces potential errors in invoicing.

Original PR description

**Steps to reproduce:**
* Install the **Accounting** module.
* Create a customer invoice with at least one product line.
* Manually adjust the **price_unit** on the invoice line.
* Change the fiscal position on the invoice.
* Click the **Update Taxes and Accounts** button.

**Observed behavior:**
* The manually adjusted price is reset to the product’s default sales price (e.g., 1000).
* This occurs even though neither the product nor the UoM changed.
* In contrast, **Sale Orders correctly preserve** manually edited prices in the same situation.

**Cause:**
* `action_update_fpos_values` method call the recomputation of unit price each
  time when we click update taxes and accounts button on invoice.

**Fix:**
* Add a condition to **skip price recomputation** when fiscal position changes.
* This preserves manual prices when only the fiscal position changes.

opw-5252832

Forward-Port-Of: odoo/odoo#237914

#invoice#pricing#fiscal position

[FIX] pos_sale: fix price unit for groupable UoM on LOT tracked products

PR #239858

Core18.0pos_saleMEDIUM

This update fixes an issue where the total order amount was incorrect when using 'LOT' tracked products with groupable UoMs in the Point of Sale (PoS) system. The fix ensures that the price unit is consistently applied to the converted quantity, resulting in accurate order totals. This improves the reliability of PoS transactions for products managed with LOT tracking.

Original PR description

Steps to reproduce
------------------
1. Make a product tracked by 'LOT' and having a groupable in pos UoM
2. Make a SO with that product, choosing another UoM from the same category (if we chose Kg in first step, choose gram here, etc)
3. Settle the order in PoS.

We observe that the order's total amount is totally off, we explain why below.

Why it's happening
------------------
The `lot_remaining_quantity` is quantity after converting to the original UoM (that of step 1, not that of step 2). We are using that quantity for lines having products tracked by 'LOT' and a groupable UoM; however, we are keeping price unit as if we are using the quantity before conversion, i.e. the quantity in the UoM of step 2. That creates a mismatch between the UoM and thus we miscalculte the total price.

The fix
-------
When using the converted quantity, also use the converted price unit.

opw-5144326

#lot#pos#uom#price#inventory

[FIX] website_crm_partner_assign: fix lead data update from portal for partners

PR #239434

Core18.0website_crm_partner_assignMEDIUM

This update resolves an issue where portal users couldn't update lead data after a recent security change. The team implemented a temporary workaround using 'sudo()' to grant necessary write access, ensuring portal users can now modify leads as intended. This maintains seamless data synchronization between the portal and the CRM.

Original PR description

##  Steps to reproduce:

- Install 'website_crm_partner_assign' module.
- Create a partner X with a partner level.
- Save and go to "Opportunities".
- Create an new opportunity.
- Edit it and set the partner X as the assigned partner
- Grant the partner x portal access and change his password.
- Logout then login with the partner X credentials.
- Go to "My account" page and click on "Opportunities"
- Select the opportunity Y and edit the revenue or another field.
- Traceback on save. (Or no reaction, popup traceback from notification)

### Issue:
Since the commit ed94e84, we've removed the write access for portal partner users to the leads to avoid unexpected behaviors. However, this is provoking `update_lead_portal` to not be able to update the lead anymore, since we will not have direct access to modify the lead.

### Solution:
To fix this, we will follow same approach as in `update_contact_details_from_portal` and use `sudo()` to update the lead from the portal. We are already checking the portal access at the beginning of the method as `self._assert_portal_write_access()`, so we are sure that only authorized users will be able to update the lead.

opw-2764563


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#237599

#crm#portal#lead update

[FIX] {l10n_ar_,}website_sale: handle missing l10n fields on checkout

PR #239998

Core18.0website_salel10n_ar_website_saleMEDIUM

This update resolves a problem preventing Argentinian users from completing the checkout process. The system was failing to recognize required tax information fields, leading to an error. The fix ensures these fields are correctly displayed and validated, allowing users to proceed with their purchase.

Original PR description

Versions
--------
- 18.0

`l10n_ar_website_sale` was removed in later versions via 5a93da8e9220

Steps
-----
1. Create a partner with an address;
2. set up a company with Argentinian localization;
3. assign website to Argentinian company;
4. as partner, go to website & add something to your cart;
5. go to checkout.

Issue
-----
Cannot get past the address form.

Cause
-----
The `l10n_latam_identification_type_id` and `l10n_ar_afip_responsibility_type_id` fields are required, but not shown. Because they're not editable, the `website_sale` controller doesn't consider them "missing", making the `l10n_ar_website_sale` override not handle the missing fields.

Going to "My Account" to edit details also doesn't allow you to add them, as the form lacks the `can_edit_vat` value.

Solution
--------
Instead of relying on the `missing_fields` value from the base method call, have the `_validate_address_values` override explicitly check the presence of those fields in either the address values or the current partner record (adding them to address values if it's the latter).

If the values are missing, show an error message telling the client to add the missing info via "My Account".

In the portal controller, provide the `can_edit_vat` value to make the fields editable.

opw-5376149

#localization#argentina#checkout

**PURPOSE** - In Guatemala, a Factura Especial (FESP) is a legal mechanism established in Art. 52 of the VAT Law. - To achieve this functionality, we need to create withholding taxes. **SPECIFICATION** - Added new accounts for VAT and ISR withholdings. - Added new tax groups for VAT and ISR. - Added new taxes with negative values in withholding. task-5026698 see - https://github.com/odoo/enterprise/pull/96007

### PURPOSE - In Guatemala, a Factura Especial (FESP) is a legal mechanism established in Art. 52 of the VAT Law. - Generate Factura Especial (FESP) when registering a purchase without a supplier invoice. - Include all required data: supplier as receiver, transaction details, and the retention complement (100% VAT + ISR withholding). - Ensure proper accounting: supplier payable = net after retentions, taxes withheld = recorded as liabilities to be paid to SAT. - Fulfill FEL technical requirements (DTE XML, mandatory phrase, retention complement, see example attached). ### SPECIFICATION - Added flow for FESP (Factura Especial) document type in vendor bills. - Automatically added Phrase Type 5, Scenario 1 (as required by SAT). - Enforced mandatory data by raising UserError if FESP is selected but no withholding taxes are set on the product lines. - Added complement generation for withheld taxes (IVA, ISR) with base, rate, and amounts. - Allow users to send a document to SAT in case of FESP. - Added required details in FEL XML for FESP. task-5026698 see - https://github.com/odoo/odoo/pull/229493

**Steps to reproduce:** * Install the **Accounting** module. * Create a customer invoice with at least one product line. * Manually adjust the **price_unit** on the invoice line. * Change the fiscal position on the invoice. * Click the **Update Taxes and Accounts** button. **Observed behavior:** * The manually adjusted price is reset to the product’s default sales price (e.g., 1000). * This occurs even though neither the product nor the UoM changed. * In contrast, **Sale Orders correctly preserve** manually edited prices in the same situation. **Cause:** * `action_update_fpos_values` method call the recomputation of unit price each time when we click update taxes and accounts button on invoice. **Fix:** * Add a condition to **skip price recomputation** when fiscal position changes. * This preserves manual prices when only the fiscal position changes. opw-5252832 Forward-Port-Of: odoo/odoo#237914

Steps to reproduce ------------------ 1. Make a product tracked by 'LOT' and having a groupable in pos UoM 2. Make a SO with that product, choosing another UoM from the same category (if we chose Kg in first step, choose gram here, etc) 3. Settle the order in PoS. We observe that the order's total amount is totally off, we explain why below. Why it's happening ------------------ The `lot_remaining_quantity` is quantity after converting to the original UoM (that of step 1, not that of step 2). We are using that quantity for lines having products tracked by 'LOT' and a groupable UoM; however, we are keeping price unit as if we are using the quantity before conversion, i.e. the quantity in the UoM of step 2. That creates a mismatch between the UoM and thus we miscalculte the total price. The fix ------- When using the converted quantity, also use the converted price unit. opw-5144326

## Steps to reproduce: - Install 'website_crm_partner_assign' module. - Create a partner X with a partner level. - Save and go to "Opportunities". - Create an new opportunity. - Edit it and set the partner X as the assigned partner - Grant the partner x portal access and change his password. - Logout then login with the partner X credentials. - Go to "My account" page and click on "Opportunities" - Select the opportunity Y and edit the revenue or another field. - Traceback on save. (Or no reaction, popup traceback from notification) ### Issue: Since the commit ed94e84, we've removed the write access for portal partner users to the leads to avoid unexpected behaviors. However, this is provoking `update_lead_portal` to not be able to update the lead anymore, since we will not have direct access to modify the lead. ### Solution: To fix this, we will follow same approach as in `update_contact_details_from_portal` and use `sudo()` to update the lead from the portal. We are already checking the portal access at the beginning of the method as `self._assert_portal_write_access()`, so we are sure that only authorized users will be able to update the lead. opw-2764563 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237599

Versions -------- - 18.0 `l10n_ar_website_sale` was removed in later versions via 5a93da8e9220 Steps ----- 1. Create a partner with an address; 2. set up a company with Argentinian localization; 3. assign website to Argentinian company; 4. as partner, go to website & add something to your cart; 5. go to checkout. Issue ----- Cannot get past the address form. Cause ----- The `l10n_latam_identification_type_id` and `l10n_ar_afip_responsibility_type_id` fields are required, but not shown. Because they're not editable, the `website_sale` controller doesn't consider them "missing", making the `l10n_ar_website_sale` override not handle the missing fields. Going to "My Account" to edit details also doesn't allow you to add them, as the form lacks the `can_edit_vat` value. Solution -------- Instead of relying on the `missing_fields` value from the base method call, have the `_validate_address_values` override explicitly check the presence of those fields in either the address values or the current partner record (adding them to address values if it's the latter). If the values are missing, show an error message telling the client to add the missing info via "My Account". In the portal controller, provide the `can_edit_vat` value to make the fields editable. opw-5376149