Wednesday, February 25, 2026
12 changes · 18.0
Enhancements to existing features
This update allows accountants to easily group invoice lines by tax, reducing clutter in journal entries. A server action provides a toggle to group or ungroup lines from the original file, streamlining the import process and improving data clarity. This addresses a previous issue where multiple PDFs were generated during line grouping.
Original PR description
[IMP] account_edi_ubl_cii: (un)group lines by tax
Once an invoice is imported, a server action allows the user to group
lines by tax, and then if the same action is triggered again it will
ungroup all lines from the origin file
This feature is useful because accountants don't always need the
detail of the vendor bills, and also all the lines clutter up the
journal items
task-5047859
Forward-Port-Of: odoo/odoo#245234Resolved issues and error corrections
This update fixes an issue where manually invoicing subscriptions or upsells didn't correctly update their invoice status. Now, subscriptions and upsells are automatically marked as 'Fully Invoiced' after invoicing, ensuring accurate financial reporting. This improves the reliability of subscription billing.
Original PR description
## Issue When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead. ##…
## Issue
When manually invoicing a subscription or an upsell, its *Invoice Status* would not be updated to *Fully Invoiced* (`invoiced`), and would stay as *To invoice* (`to invoice`) instead.
## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Product P
- *Subscriptions* checked
- *Invoicing Policy*: *Delivered quantities*
3. Create a Subscription S
- Any Customer
- Any plan
- Product P (any quantity)
4. Confirm the subscription S, set the amount delivered to the quantity ordered, then create and confirm the invoice
5. On the subscription S, click *Upsell*, add the product P to the upsell, and repeat step 4 on the upsell
6. **The upsell's _Invoice Status_ is still _To Invoice_, even though we invoiced it in the previous step**
## Causes
In the `SaleOrderLine._compute_invoice_status`, the following condition skips line from orders that are not considered to be "subscriptions":
https://github.com/odoo/enterprise/blob/c33e668bbba37c34d18af8c5371ab80eedf1b965/sale_subscription/models/sale_order_line.py#L51-L62
This is the case of upsells, as explained here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201
---
Updating the above condition to take upsells in account is not enough. The condition to set the `invoice_status` to `invoiced` does not work as expected either.
https://github.com/odoo/enterprise/blob/5f4bb0ca22d068247540a4dcae88905c7b312f3c/sale_subscription/models/sale_order_line.py#L77-L78
In fact, when invoicing the subscription/upsell manually, there are multiple cases where the `last_invoiced_date` will be after `today`, and the subscription will be invoiced, so its status should be `invoiced`.
| Upsell | Invoiced based on delivered quantities | last_invoiced_date |
|--------|----------------------------------------|-------------------------|
| True | True | today + 1 month |
| False | True | today |
| True | False | today + 1 month - 1 day |
| False | False | today + 1 month - 1 day |
An alternative logic is to consider the subscription to be invoiced as long as the `next_invoice_date` is not reached.
---
opw-5500585This update ensures Verifactu invoices generated from Point of Sale (PoS) orders correctly reflect the invoice type ('F3') when replacing a previous simplified invoice. Previously, the system incorrectly defaulted to 'F1'. This change aligns with Spanish tax regulations and guarantees accurate invoice generation for Verifactu documents.
Original PR description
To reproduce ------------- 1. Install `l10n_es_edi_verifactu_pos`, and select the ES company 2. Make an order in PoS with a price less than 400, and don't invoice it. 3. Close the PoS session, then…
To reproduce ------------- 1. Install `l10n_es_edi_verifactu_pos`, and select the ES company 2. Make an order in PoS with a price less than 400, and don't invoice it. 3. Close the PoS session, then go to PoS > Orders, and select the previously made order 4. It will have a Verifactu generated document with invoice type as 'F2', which is correct since it's a simplified order. 5. Click invoice to invoice the order; the invoice is no longer simplified. Notice now that the new Verifactu document has an invoice type of 'F1', which corresponds to a normal non simplified invoice. However, since the new invoice is replacing an old simplified one, it should be of type 'F3' instead. The fix ------- When fully invoicing, we check if the order had a linked Veri*factu document of type F2, which means we are now replacing it and should set the type of the new invoice to F3 instead of F1. Sources: -------- Difference between 'F1', 'F2', and 'F3' invoice types: https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html?faqId=bdbd20022fe06910VgnVCM100000dc381e0aRCRD opw-5343973
This update fixes an issue where payroll rates weren't accurately calculated for employees using attendance-based contracts. The system now correctly uses the employee's planned working schedule (hours per day) to determine the appropriate hourly rates for salary and allowances, ensuring accurate pay calculations.
Original PR description
Step to Reproduce: - install UAE Payroll localization and attendance - create employee and running employee contract and give basic salary, housing, transportation and other allowance. - work entry source should be attendance - create a payslip and compute sheet. Issue: - The values for payslip lines are not as expected. - The rate per hour for basic salary , housing, transportation and other allowances was being calculated based on employee's attendance work entries, not the planned working schedule. Reason: - When using attendance-based contracts, the hourly rates for basic salary, housing, transportation, and other allowances should be calculated based on the working schedule's hours per day, if a working schedule is available. Solution: - Instead of sum_worked_hours which takes working hours of employee's work entries, use total_number_of_days multiplied by the hours per day from the working schedule. task-5270185
This update fixes an issue where product variant pricelists were incorrectly storing data after a rule was removed. Previously, the data remained tied to the variant, but now it's reset to the standard global pricelist setting, ensuring accurate pricing calculations. This resolves a data corruption problem impacting product variant pricing.
Original PR description
Steps: - Create a price list (or existing one) - Create (or find) a product with only one variant - Add price list rule for that variant (Should show as Variant:... in Pricelist listing) - Go to…
Steps: - Create a price list (or existing one) - Create (or find) a product with only one variant - Add price list rule for that variant (Should show as Variant:... in Pricelist listing) - Go to pricelist listing, select the pricelist - Edit price list rule - Remove the product - Save and check the data (applied_on, product_id, product_tmpl_id) (applied_on still 0_product_variant, product_id, and NO product_tmpl_id) Related ticket: opw-5411034 (Video: https://drive.google.com/file/d/1xmg9A9NgavFQkIFkUZrzuAxVF-PNqdnL/view) Description of the issue/feature this PR addresses: Fix corrupted data <img width="583" height="108" alt="image" src="https://github.com/user-attachments/assets/961e75f8-b2a6-4812-a0b4-d73e02d52b08" /> Current behavior before PR: product_tmpl_id set to None product_id / applied_on data stays the same Desired behavior after PR is merged: When product_tmpl_id is removed, reset the applied_on type back to 3_global --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the names of Ecuadorian localization regimes didn't comply with government regulations. The changes ensure that all names are now correctly formatted for electronic invoicing to the SRI (Servicio de Rentas Internas), maintaining consistency and avoiding potential compliance problems. The system now always uses Spanish names for these regimes, regardless of the user's language settings.
Original PR description
[FIX] l10n_ec_edi: fiscal localizations name The name of the regimes for the Ecuadorian localization does not respect the government requirements Steps to reproduce: 1. Install l10n_ec_edi module 2. Go to Settings > Invoicing > Ecuadorian Localization 3. In Electronic Invoicing > Regime, the names of the regimes do not respect government requirements Solution: Change the name of the fiscal localizations to respect the requirements Add a computed field used to map the name of the regime to the technical name of the regime used in SRI documents We write them in Spanish because we always want the name of the regime to be in Spanish in the XML invoice sent to the government, even if the user didn't install any other language. opw-5221871 Forward-Port-Of: odoo/enterprise#105914
This update fixes a problem where the automated invoice processing cron job would fail and lose progress. The change ensures the cron job processes invoices in smaller batches, committing changes after each one to prevent data loss and wasted credits. This improves the reliability of the BR EDI service.
Original PR description
The cron searched with limit=batch_size and only retriggered when >batch_size records were found which never happens. It also ran all invoices in a single transaction so one failure rolled back all progress while IAP credits were already consumed. Search batch_size + 1 so remaining invoices are detected, and commit after each invoice to preserve progress. opw-5954211 Forward-Port-Of: odoo/enterprise#108191
This update allows branch companies to see and use contacts belonging to their parent companies when creating invoices or vendor bills. Previously, branch companies were restricted from selecting these contacts. This change resolves a technical issue related to how company affiliations were handled within the accounting module.
Original PR description
Currently, when operating in a branch company, contacts belonging to the parent company are not visible in the partner dropdown on Invoices or Vendor Bills. ### **Steps to reproduce:** 1) Create a…
Currently, when operating in a branch company, contacts belonging to the parent company are not visible in the partner dropdown on Invoices or Vendor Bills.
### **Steps to reproduce:**
1) Create a multi-company hierarchy (Company A -> Branch B).
2) Create a contact owned by Company A.
3) Switch the current company to Branch B.
4) Go to Accounting > Customers > Invoices and create a new invoice.
5) Try to select the contact created in step 2.
### **Current/Buggy Behavior:**
The contact does not appear in the search results.
### **Expected Behavior:**
The contact should be selectable.
### **Root Cause:**
since commit https://github.com/odoo/odoo/commit/67169c42061cb51bc68f6c74f0674a670dd04f58,
the partner model supports the standard
`check_company=True` mechanism, and record rules were updated to allow
branches to access partners of their parent company.
However, the `partner_id` field on the `account.move` form view still
retained a explicit domain: `[('company_id', 'in', (False,
company_id))]` as shown at [1].
This domain overrides the standard `check_company` behavior.
due to which it restricts the selection to partners owned by the current company
(the branch) or partners with no company set. It explicitly excludes
partners owned by the parent company.
### **Fix:**
Remove the domain at [1],
This allows the field to rely on the standard `check_company=True`
logic, which correctly handles the multi-company hierarchy and allows
branches to select parent company partners.
[1]- https://github.com/odoo/odoo/blob/6b7b83449739932aa8420ef8fcd888116e3c0f8a/addons/account/views/account_move_views.xml#L896
**opw-5484611**
Forward-Port-Of: odoo/odoo#244671This update resolves an issue where customer emails with accented characters were being rejected by strict email servers like Yahoo. By eliminating subject header folding, Odoo now ensures all emails, regardless of character encoding, are delivered successfully, improving customer communication and support.
Original PR description
Description of the issue/feature this PR addresses: Yahoo and other strict mail servers reject emails with `554 Invalid Subject header` when Subject headers are folded at 78 characters and contain…
Description of the issue/feature this PR addresses: Yahoo and other strict mail servers reject emails with `554 Invalid Subject header` when Subject headers are folded at 78 characters and contain RFC 2047 encoded-words representing non-ASCII characters. The issue occurs because: 1. Long email subjects with accented characters (French: "arrière", "connecté", etc.) are RFC 2047 encoded 2. Python's `email.policy.SMTP` folds these headers at 78 characters per RFC 5322 SHOULD recommendation 3. Yahoo's strict validation rejects folded subjects when the fold occurs at certain positions within or between encoded-words 4. This results in customer-facing emails being rejected with no delivery failing silently, leading to missed communications. Current behavior before PR: > Subject: [SOS-1477030] Commande et livraison - Demande de retour - user pseudo 251003-GD1U0E - Cosmo Connected Casque Fusion avec feu =?utf-8?q?arri?==?utf-8?q?=C3=A8re_connect=C3=A9?= et accessoire (#1031590) This subject: - Is 168 characters when unfolded - Is folded into 3 lines (78, 74, 60 chars) - Contains RFC 2047 encoded "arrière connecté" - Is technically RFC 2822 compliant - **Gets rejected by Yahoo with "554 Invalid Subject header"** While this is technically RFC 2822 compliant, Yahoo's strict validation rejects it. Python's `email.policy.SMTP` folds headers at 78 characters to follow RFC 5322's SHOULD recommendation. However, when subjects contain non-ASCII characters that get RFC 2047 encoded, the folding can create patterns that strict mail servers reject. Desired behavior after PR is merged: - No folding of Subject headers, regardless of length - Yahoo and all strict SMTP servers accept these emails - Customer support emails deliver successfully --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where custom analytic distributions on sales order lines were being reset to the default model distribution when the order was confirmed. Previously, users couldn't maintain their specific distribution settings. Now, custom distributions will be preserved, ensuring accurate tracking of costs within project sales.
Original PR description
*: project_purchase, sale_project --- Decription of the issue this commit addresses: When confirming a sales order with a product-partner combination that has an Analytic Distribution Model assigned,…
*: project_purchase, sale_project --- Decription of the issue this commit addresses: When confirming a sales order with a product-partner combination that has an Analytic Distribution Model assigned, any custom analytic distribution done on the line of the product will be lost, resetting the analytic distribution to the default value set on the Analytic Distribution Model. --- Steps to reproduce: 1. Install sale_project,project_purchase. 2. Activate "Analytic Accounting" in the settings. 3. Create a new Product "test"; Type: Service, Create on Order: Project. 4. Create a new Analytic Distribution Models; Partner: Acme, Product: test, Analytic Distribution: anything but blank. 5. Create a new Quotation in the Sales apps; Partner: Acme. 6. Assign the Product test to the first order line. This will automatically set the analytic distrib of the Analytic Distribution Model. 7. In the Analytic Distribution cell, add a line with any non null distribution. 8. Confirm the Quotation. 9. The analytic distribution that was anually added has been removed. Only the default analytic distribution of the model remains. --- Desired behavior after this commit is merged: Any custom analytic distribution done on a line is never lost. The Analytic Distribution Model's distribution serves as a template but never overrides the values set by the user. --- opw-4934291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a problem where archived employees caused conflicts when managing appraisal plans. The fix ensures that archived employees' appraisal dates are cleared, preventing errors when setting appraisal plans for active employees. This improves the stability and usability of the appraisal management feature.
Original PR description
**Steps to reproduce:** Based on this feedback https://www.odoo.com/odoo/project.task/5270281 companies with archived employees face an issue when they try to toggle Appraisals Plans from Appraisls -> Configuration -> Settings -> Appraisals Plans **Issue:** The propblem is that when employees with next appraisal date are archived, their next appraisal date is not cleared which leads to past date conflicts upon trying to set the next appraisals dates for all the employees (which is done through toggling the Appraisals Plans checkbox) **Solution:** - Unset the next appraisal date upon archiving an employee - exclude archived employees from _compute_next_appraisal_date method Task: 5354002 Forward-Port-Of: odoo/enterprise#100437
This update corrects a bug where invoices created by users in time zones before Saudi Arabia could be incorrectly dated in the future, leading to ZATCA rejection. The change ensures invoice dates are properly aligned with Saudi Arabia's time, preventing future invoicing issues and maintaining compliance.
Original PR description
In odoo/odoo#236865 we decided to allow clients to backdate invoices by letting them use the `invoice_date` field for the invoice date and use the current time as the issue time because we are not supposed to use a dummy value for time. This created an issue where if a user in a timezone before SA tries to invoice a document around midnight using the current date in SA the datetime created will be in the future which will lead to the invoice being rejected by ZATCA. This commit makes sure we normalize the selected date wrt to the current datetime in saudi arabia so that we never accidentally invoice into the future. task-5890423 opw-5373067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246311