Daily updates from Odoo
Navigate
Branch
Saturday, October 4, 2025
22 changes
4 changes
Resolved issues and error corrections
Discount allocation settings now allow other income and other expense accounts to be selected. This prevents valid accounts from being excluded during configuration, making discount accounting setup more accurate and flexible.
Original PR description
With this PR: - Updated the domain of discount allocation fields to include `income_other`/`expense_other` account types. Task-5121917 Forward-Port-Of: odoo/odoo#229560 Forward-Port-Of: odoo/odoo#229026
The mail app no longer shows the translate action on messages that have no text, such as tracking updates or attachment-only messages. This avoids offering users an action that cannot do anything and makes message actions clearer.
Original PR description
**Current behavior before PR:** The translate action was shown on all messages, including those with an empty body such as tracking updates or messages containing only attachments. Clicking the translate action on these messages had no effect. **Desired behavior after PR is merged:** The translate action is hidden for messages with an empty body. Only messages containing text display the translate option. **Task-5106303** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229826 Forward-Port-Of: odoo/odoo#228137
Dutch electronic invoices now include only the Peppol endpoint as the customer identifier, avoiding a duplicate identifier when a customer reference is also set. This prevents NLCIUS validation errors so affected invoices can be sent successfully.
Original PR description
**Steps to reproduce:** - Install Accounting and Contacts - Use a company based in Netherlands - In Contacts, configure the company: * eInvoice format: Netherlands (NLCIUS) * Peppol endpoint:…
**Steps to reproduce:**
- Install Accounting and Contacts
- Use a company based in Netherlands
- In Contacts, configure the company:
* eInvoice format: Netherlands (NLCIUS)
* Peppol endpoint: [anything]
* Reference ("Sales & Purchase" tab): [anything]
- Create a Dutch contact with a peppol endpoint and a reference
- Create an invoice for the Dutch contact
- Confirm the invoice
- Send the invoice
- Check the generated NLCIUS xml
**Issue:**
In the XML there are 2 "<cac:PartyIdentification>" for each party.
One with the peppol endpoint and one with the partner reference.
For "<cac:AccountingCustomerParty>", only one Party Identification is allowed, triggering the following validation error:
[UBL-SR-16] Buyer identifier shall occur maximum once
**Cause:**
By default (UBL 2.0), the partner reference is used as Party Identification.
But in the case of a Dutch partner, the peppol endpoint is also added in BIS3.
**Solution:**
Only use the peppol endpoint for Dutch partners.
opw-5059667
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#226561The Swiss payroll screen now hides the verified source tax statement button when there is no correction in the institution response. This prevents users from clicking an option that cannot produce a report, reducing confusion during payroll processing.
Original PR description
This button will give a report only in the case where the institution response has a correction, so it should be hidden. Forward-Port-Of: odoo/enterprise#96128
5 changes
Resolved issues and error corrections
This fixes Indian e-invoicing so reverse charge and Special Economic Zone sales report the correct GST rate and tax values instead of incorrectly showing a 0% rate. It also separates export and SEZ tax/fiscal setups so invoices with or without LUT are handled according to Indian e-invoice rules, reducing compliance and reporting errors.
Original PR description
[FIX] l10n_in{,_edi}: Sale RCM and SEZ(With LUT) Steps to reproduce: 1. Install `l10n_in_edi` 2. Create an invoice with a RC tax/SEZ (with LUT) tax 3. Confirm and Process for E-invoice 4. See the EDI…
[FIX] l10n_in{,_edi}: Sale RCM and SEZ(With LUT)
Steps to reproduce:
1. Install `l10n_in_edi`
2. Create an invoice with a RC tax/SEZ (with LUT) tax
3. Confirm and Process for E-invoice
4. See the EDI content, The GST rate is 0%
Before this
For RC and SEZ (with LUT) the tax rate and tax amount were sent
as `0` and (data going wrong for SEZ/Exports) for Indian E-invoicing.
Following the fix:
1. We rename the the IGST x% (SZ/EX) -> IGST x% (EX)
2. Introducing new taxes for SEZ with LUT
3. Fiscal for Export and SEZ renamed to Export (same for LUT)
4. Introducing new fiscal for SEZ and SEZ (LUT)
5. In case of Special Economic Zone normal taxes (IGST) should be applied
because as per the [API Doc](https://einv-apisandbox.nic.in/version1.03/generate-irn.html#validations)
It states -
**However, in case of Reverse charge and Export transactions (EXPWP), Total value of Item can match with either with tax values or without tax values. That is, the total value of item can include or exclude the tax values as per the business requirements.**
So SEZ without LUT should be passed as normal IGST
For Export without LUT
Label | Taxes | credit | debit| Tags
-------------------------------------------------------------------------------------------------------------
Product A | 18% IGST S (EX) | 100 | | Base IGST
IGST 18% | | 18 | | IGST
IGST Paid on SEZ/Export Sales | | | 18|
Creditor | | | 180|
Invoice Total 100
EDI with {'rate': 18.0, 'IgstAmt': 18.0, 'TotItemVal': 100}
For SEZ without LUT
Label | Taxes | credit | debit | Tags
-----------------------------------------------------------
Product A | 18% IGST S (SEZ) | 100 | | Base IGST
IGST 18% | | 18 | | IGST
Creditor | | | 118|
Invoice Total 118
EDI with {'rate': 18.0, 'IgstAmt': 18.0, 'TotItemVal': 118}
For Export/SEZ with LUT
Label | Taxes | credit | debit | Tags
-----------------------------------------------------------
Product A | 18% IGST S (SEZ) | 100 | | Base IGST
IGST 18% | | 18 | | IGST
IGST 18% | | | 18 | IGST
Creditor | | | 100|
Invoice Total 100
EDI with {'rate': 18.0, 'IgstAmt': 0.0, 'TotItemVal': 100}
For RCM
Label | Taxes | credit | debit | Tags
-------------------------------------------------------------------------------
Product A | 18% IGST S RC | 100 | | Base IGST || BASE IGST RC
IGST 18% RC | | 18 | | IGST
IGST 18% RC | | | 18| IGST RC
Creditor | | | 118|
Invoice Total 100
EDI with {'rate': 18.0, 'IgstAmt': 0, 'TotItemVal': 100}
task-4878805
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#228871
Forward-Port-Of: odoo/odoo#213931Romanian SAF-T reports now include partners even when their balance is zero, so each partner can still be correctly identified as a customer or supplier. This prevents validation errors in Romanian tax reporting while also improving how the report gathers the needed accounting data.
Original PR description
We need to know for each partner if it is a customer or a supplier, even more for Romania[^1] where it is enfored and validated. > 1. If the element SD.P.22 CustomerID is reported with value ”0”…
We need to know for each partner if it is a customer or a supplier, even more for Romania[^1] where it is enfored and validated. > 1. If the element SD.P.22 CustomerID is reported with value ”0” (zero), then the element SD.P.23 SupplierID must be different from ”0” (zero), meaning the identity of the partner from which the purchase was made (conventionally considered ”supplier”) is reported. Else if SD.P.22 CustomerID AND SD.P.23 SupplierID are concomitantly equal to ”0” (zero), then is return a semantic validation error. (CustomerID and SupplierID can not be concomitantly 0 (zero)) In order to fix this, we don't use the Partner Ledger anymore to query the balance per partner because it is removing the partners with 0 balance automatically. To keep it simple, we query manually and locally, allowing to reduce the number of queries from 3 to 1 for that part. For the performance, the `|=` operator done in a loop has also been removed, keeping the time complexity in `O(n)` instead of `O(n²)`. opw-5122910 [^1]: https://www.anaf.ro/anaf/internet/ANAF/despre_anaf/strategii_anaf/proiecte_digitalizare/saf_t Forward-Port-Of: odoo/enterprise#96317 Forward-Port-Of: odoo/enterprise#95804
This update adds validation coverage for Indian GSTR-1 reporting in cases involving reverse charge sales and SEZ sales with LUT. It helps ensure tax reports handle these compliance scenarios correctly and reduces the risk of incorrect filings.
Original PR description
Adding GSTR1 test case with RCM tax and SEZ (with LUT) see https://github.com/odoo/odoo/pull/213931 Forward-Port-Of: odoo/enterprise#95669 Forward-Port-Of: odoo/enterprise#87486
Dutch electronic invoices now include only the required Peppol endpoint as the customer identifier, avoiding duplicate buyer identifiers. This prevents NLCIUS validation errors so invoices can be sent successfully through compliant e-invoicing channels.
Original PR description
**Steps to reproduce:** - Install Accounting and Contacts - Use a company based in Netherlands - In Contacts, configure the company: * eInvoice format: Netherlands (NLCIUS) * Peppol endpoint:…
**Steps to reproduce:**
- Install Accounting and Contacts
- Use a company based in Netherlands
- In Contacts, configure the company:
* eInvoice format: Netherlands (NLCIUS)
* Peppol endpoint: [anything]
* Reference ("Sales & Purchase" tab): [anything]
- Create a Dutch contact with a peppol endpoint and a reference
- Create an invoice for the Dutch contact
- Confirm the invoice
- Send the invoice
- Check the generated NLCIUS xml
**Issue:**
In the XML there are 2 "<cac:PartyIdentification>" for each party.
One with the peppol endpoint and one with the partner reference.
For "<cac:AccountingCustomerParty>", only one Party Identification is allowed, triggering the following validation error:
[UBL-SR-16] Buyer identifier shall occur maximum once
**Cause:**
By default (UBL 2.0), the partner reference is used as Party Identification.
But in the case of a Dutch partner, the peppol endpoint is also added in BIS3.
**Solution:**
Only use the peppol endpoint for Dutch partners.
opw-5059667
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#226561The Swiss payroll interface now hides the verified source tax statement button when there is no correction in the institution response. This prevents users from trying to generate a report that would not be available, reducing confusion during payroll processing.
Original PR description
This button will give a report only in the case where the institution response has a correction, so it should be hidden. Forward-Port-Of: odoo/enterprise#96128
2 changes
Resolved issues and error corrections
The SAF-T reporting logic now includes customers and suppliers even when their balance is zero, helping Romanian reports pass required validation checks. It also avoids reporting empty general ledger lines while keeping the related documents visible, improving report accuracy and compliance.
Original PR description
We need to know for each partner if it is a customer or a supplier, even more for Romania[^1] where it is enfored and validated. > 1. If the element SD.P.22 CustomerID is reported with value ”0”…
We need to know for each partner if it is a customer or a supplier, even more for Romania[^1] where it is enfored and validated. > 1. If the element SD.P.22 CustomerID is reported with value ”0” (zero), then the element SD.P.23 SupplierID must be different from ”0” (zero), meaning the identity of the partner from which the purchase was made (conventionally considered ”supplier”) is reported. Else if SD.P.22 CustomerID AND SD.P.23 SupplierID are concomitantly equal to ”0” (zero), then is return a semantic validation error. (CustomerID and SupplierID can not be concomitantly 0 (zero)) In order to fix this, we don't use the Partner Ledger anymore to query the balance per partner because it is removing the partners with 0 balance automatically. To keep it simple, we query manually and locally, allowing to reduce the number of queries from 3 to 1 for that part. For the performance, the `|=` operator done in a loop has also been removed, keeping the time complexity in `O(n)` instead of `O(n²)`. opw-5122910 [^1]: https://www.anaf.ro/anaf/internet/ANAF/despre_anaf/strategii_anaf/proiecte_digitalizare/saf_t Forward-Port-Of: odoo/enterprise#95804
Partner ledger opening balances now include reconciled accounting lines that do not have a partner assigned. This keeps balances and totals consistent when users review reports across different date ranges.
Original PR description
### Issue: The partner ledger does consider lines without partners when calculating the initial balance. ### Steps to reproduce: - Create an invoice in 2025 - Create an entry in 2025 without partner…
### Issue: The partner ledger does consider lines without partners when calculating the initial balance. ### Steps to reproduce: - Create an invoice in 2025 - Create an entry in 2025 without partner for the same amount - Reconcile the two - Open the partner ledger for 2025, everything is correct - Change the dates to 2026, the amount of the initial balance ignores the entry but not the totals ### Cause: The method `_get_sums_without_partner` is called for the totals, but not for the initial balance. Its purpose is to add the amounts of the lines without partners that were reconciled with lines with a partner. ### Solution: Call `_get_sums_without_partner()` in `_get_initial_balance_values()` add the results before returning the initial balances. As this is the same logic as `_query_partners()` we create a new method. This method needs to be called with the dates of the initial balance in the options. So we create a duplicate of the options and input the new dates options. opw-5068790 Forward-Port-Of: odoo/enterprise#96125 Forward-Port-Of: odoo/enterprise#95881
5 changes
Resolved issues and error corrections
Corrected how return reporting options are matched when reports include sections, preventing the wrong period settings from being applied. This helps ensure accounting return reports display accurate options for businesses using sectioned reports.
Original PR description
The _init_options_return_periodicity would compare the report_id with self.id, which would lead to bugs in the case of reports with sections since in those cases it's the section id that's taken into account. Added that check. Also backported https://github.com/odoo/enterprise/pull/93187 's fix. Forward-Port-Of: odoo/enterprise#96196 Forward-Port-Of: odoo/enterprise#96115
This fix keeps Mexican e-invoicing weight information consistent after official stamping by making the extra weight field read-only when it should no longer be changed. It also hides duplicate product weight fields when variants are involved, reducing customer confusion in product setup screens.
Original PR description
In refactor for l10n_mx_edi_stock, l10n_mx_edi_extra_weight was added to handle the weight of the driver and luggage. However, the condition to prevent the field from being edited once it has been stamped was not added, which could cause confusion if it could be edited later and a value different from that of the CFDI could be seen. The condition to make it readonly has been added, like the rest of the location fields in stock.picking. In addition to this, when testing the flow, we also detected a conflict with Odoo Standard in the l10n_mx_edi_extended module. This module added the weight field again, now on the product accounting page. The standard weight field had a condition to make it invisible if the product had variants, but this one did not, which could cause confusion for customers, so these conditions were also added. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#95973
This update adjusts internal tests so they no longer depend on demo data or default user group settings. It helps keep automated checks stable and consistent across installations without changing day-to-day product behavior.
Original PR description
The community counter part makes the tests independent from `env['res.users']._default_groups()`. `helpdesk.group_helpdesk_manager` is the only group that is given to `base.default_user_group` in the master data (is that normal?), so we need to give it explicitly in the tests since we don't rely on the default user groups anymore in tests Forward-Port-Of: odoo/enterprise#96164 Forward-Port-Of: odoo/enterprise#92410
This fixes an issue where report annotations could be lost when multiple annotation loads happened at the same time. It also adjusts the walkthrough flow to open balances from the main working files view, making the audit guidance more reliable for users.
Original PR description
yet again ...  It was possible for multiples loadAnnotations to be present at the same time, losing the annotations from all except one of them. o_embedded_actions wasn't acting perfectly, and we will probably change it in the future so we are just going back to the main working files kanban view and opening the balances from there Linked Runbot Errors: - https://runbot.odoo.com/odoo/runbot.build.error/231762 - https://runbot.odoo.com/odoo/runbot.build.error/232575 - https://runbot.odoo.com/odoo/runbot.build.error/232554 Forward-Port-Of: odoo/enterprise#95546
The payroll interface now hides the verified source tax statement button when the institution response does not include a correction. This prevents users from clicking a button that would not produce a report, reducing confusion in Swiss payroll processing.
Original PR description
This button will give a report only in the case where the institution response has a correction, so it should be hidden. Forward-Port-Of: odoo/enterprise#96128
5 changes
Resolved issues and error corrections
Discount allocation settings now allow other income and other expense accounts to be selected. This fixes a limitation that could prevent businesses from using the appropriate accounts for discounts in their accounting setup.
Original PR description
With this PR: - Updated the domain of discount allocation fields to include `income_other`/`expense_other` account types. Task-5121917 Forward-Port-Of: odoo/odoo#229560 Forward-Port-Of: odoo/odoo#229026
The translate option is no longer shown on messages that have no text, such as tracking updates or attachment-only messages. This avoids offering an action that cannot do anything and makes the message interface clearer for users.
Original PR description
**Current behavior before PR:** The translate action was shown on all messages, including those with an empty body such as tracking updates or messages containing only attachments. Clicking the translate action on these messages had no effect. **Desired behavior after PR is merged:** The translate action is hidden for messages with an empty body. Only messages containing text display the translate option. **Task-5106303** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229826 Forward-Port-Of: odoo/odoo#228137
Dutch electronic invoices now include only the required Peppol customer identifier instead of adding both the Peppol endpoint and customer reference. This prevents validation errors when sending NLCIUS invoices and refunds, helping businesses avoid rejected e-invoices.
Original PR description
**Steps to reproduce:** - Install Accounting and Contacts - Use a company based in Netherlands - In Contacts, configure the company: * eInvoice format: Netherlands (NLCIUS) * Peppol endpoint:…
**Steps to reproduce:**
- Install Accounting and Contacts
- Use a company based in Netherlands
- In Contacts, configure the company:
* eInvoice format: Netherlands (NLCIUS)
* Peppol endpoint: [anything]
* Reference ("Sales & Purchase" tab): [anything]
- Create a Dutch contact with a peppol endpoint and a reference
- Create an invoice for the Dutch contact
- Confirm the invoice
- Send the invoice
- Check the generated NLCIUS xml
**Issue:**
In the XML there are 2 "<cac:PartyIdentification>" for each party.
One with the peppol endpoint and one with the partner reference.
For "<cac:AccountingCustomerParty>", only one Party Identification is allowed, triggering the following validation error:
[UBL-SR-16] Buyer identifier shall occur maximum once
**Cause:**
By default (UBL 2.0), the partner reference is used as Party Identification.
But in the case of a Dutch partner, the peppol endpoint is also added in BIS3.
**Solution:**
Only use the peppol endpoint for Dutch partners.
opw-5059667
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#229995
Forward-Port-Of: odoo/odoo#226561The Swiss payroll screen now hides the verified source tax statement button when the institution response does not include a correction. This prevents users from opening a report action that would not produce a meaningful report.
Original PR description
This button will give a report only in the case where the institution response has a correction, so it should be hidden. Forward-Port-Of: odoo/enterprise#96128
Documentation and clarification updates
This update adds an individual contributor license agreement signature. It supports the project's legal process by documenting contribution rights and has no impact on product functionality.
1 change
Resolved issues and error corrections
The change updates an automated test so it uses clearly distinct products, avoiding confusion when task names are generated from product names. This helps keep the Field Service sales workflow test reliable after related sales project behavior changed.
Original PR description
The `industry_fsm_sale_products_compute_catalog_tour` was failing due to changes in task naming behavior from `sale_project`. Issue: - Updates in `sale_project` simplified task names to rely on product display_name, causing identical task names when the test reused the same product for multiple sale order lines. Fix: - Update the test setup to use three unique products with distinct names. task-4903208