Odoo Changelog — 2025-07-26

Saturday, July 26, 2025

7 changes · master

Bug Fixes(7)

Resolved issues and error corrections

18.0 mx custom gaz tax las

Enterprisemasterl10n_mx_ediMEDIUM

This update fixes how fixed-amount Cuota taxes are reported on Mexican electronic invoices, ensuring the tax rate, base quantity, and amount match official requirements. It reduces the risk of incorrect tax documents and also tidies related tests to make future validation easier.

Original PR description

**[FIX] l10n_mx_edi: Fix wrong management of Cuota taxes**

Cuota taxes are wrongly reported.
For example, a GAZ cuota tax expressed as 4.6555 per quantity has to be reported as
TasaOCuota=4.6555
Base=quantity
Importe=TasaOCuota * Base

Currently, it's reported as:
TasaOCuota=abs(tax_amount_currency/base_amount_currency)
Base=base_amount_currency
Importe is recomputed as TasaOCuota * Base instead of tax_amount_currency

task-id: 4761658

**[IMP] l10n_mx_edi: Make test suite a bit less messy**

Having a single test testing all taxes combination, testing 100% discount on it + IEPS breakdown and
global invoice makes the whole thing difficult to debug. Also, it forces the generation of files
that are not always relevant.

Forward-Port-Of: odoo/enterprise#89801
Forward-Port-Of: odoo/enterprise#88357

#Mexico#electronic invoicing#taxes#Cuota

[FIX] pos_self_order*: prevent prep order on unsuccessful payments

PR #91000

Enterprisemasterpos_online_payment_self_order_preparation_displaypos_self_order_preparation_displaypos_self_order_iotMEDIUM

Self-service orders now reach the preparation display only after payment succeeds when an online or terminal payment method is configured. This prevents staff from preparing unpaid orders, while still allowing mobile self-orders without online payment setup to be prepared as before.

Original PR description

pos_self_order*: pos_online_payment_self_order_preparation_display, pos_self_order_preparation_display

Ensure self-orders are sent to the preparation display only after a successful payment, 
when a valid payment method is configured.

**Issue 1: Orders sent for preparation before successful payment**

**Steps:**
- Configure the kiosk with an online or terminal payment method.
- Open the kiosk, add products, and proceed to payment.

**Issue:**
- Preparation orders were being sent even if the payment was not completed.

**Fix:**
- Restrict preparation flow to only orders with a successful payment when a valid payment method is configured.

---
**Issue 2: Orders not sent for preparation in mobile mode without the online method**
- Allow unpaid orders to be sent for preparation only in mobile mode when no online payment method is configured.


Task-4845410

Related: https://github.com/odoo/odoo/pull/213493

Forward-Port-Of: odoo/enterprise#90923
Forward-Port-Of: odoo/enterprise#87173

#self-order#payments#preparation-display#point-of-sale

[FIX] helpdesk: auto-subscribe recipients to tickets on share and message

PR #91019

EnterprisemasterhelpdeskMEDIUM

Customers who receive a shared helpdesk ticket or a message about one are now automatically added as followers. This ensures they can view the ticket in the portal without extra manual steps, reducing access issues and follow-up work for support teams.

Original PR description

Before this commit, when a ticket was shared through the share wizard or when a message was sent to a customer via the chatter, the recipients were not added as followers of the ticket. As a result, they couldn't see the ticket in the portal.

This commit ensures:
 - Recipients are now added as followers of the ticket when it is shared with them through the wizard.
 - A message to a customer in the chatter also adds them as a follower of the ticket.

task-4781259

Forward-Port-Of: odoo/enterprise#90947
Forward-Port-Of: odoo/enterprise#86169

#helpdesk#portal#ticket sharing#followers

[FIX] partner_commission,sale_subscription_partnership

PR #90787

Enterprisemasterpartner_commissionsale_subscription_partnershipMEDIUM

Membership benefits now apply correctly when a parent company or contact purchases or loses membership. Parent memberships are passed to child contacts, while child purchases stay with that child, preventing incorrect pricing or commission benefits from being retained.

Original PR description

Corrects the behaviour of the member level assignment in membership when childs partners are concerned.
A partner buying a membership should forward the membership level and Pricelist to its children.
A child buying a membership should get that membership without forwarding it to its parent.
When removed, children should not keep the membership if the parent lose it.

TASK-4801759

Forward-Port-Of: odoo/enterprise#86776

#membership#partners#commissions#subscriptions

[FIX] l10n_co_edi: incorrect edi types

PR #90220

Enterprisemasterl10n_co_dianl10n_co_ediMEDIUM

Colombian electronic invoices now send invoice type codes in the two-character format required by DIAN. This prevents rejections caused by incorrectly formatted EDI types and helps businesses submit invoices more reliably.

Original PR description

The DIAN endpoint only accepts Electronic Invoice types with a length of
 2 characters. This fix adds zero-padding to the problematic edi types.

task: 4882683

Forward-Port-Of: odoo/enterprise#89925

#Colombia#EDI#electronic invoicing#DIAN

[FIX] planning: display employe name without employe right

PR #91043

EnterprisemasterplanningMEDIUM

Users with Planning access but without Employee permissions can now open and view planning roles without encountering an access error. This ensures planning-only users can use the role configuration area as expected while keeping employee access restrictions in place.

Original PR description

Trying to display the roles in the planning app is not possible if the user doesn't have hr_rights even with full planning rights.

** Step to reproduce **
- Connect to Odoo with an user that only have acces right for "Planning" (no employees).
- Open Planning app
- Configuration>Roles
- It will trigger an Access Error (If it didn't trigger add a user to Ressources)

** Cause of the issue **

The acces for the default_role_id is limited to hr.group_hr_user:
https://github.com/odoo/enterprise/blob/a7122011a0b0cdd111eccf59c917c6b8e2c25137/planning/models/resource_resource.py#L27
But is used in _compute_display_name:
https://github.com/odoo/enterprise/blob/a7122011a0b0cdd111eccf59c917c6b8e2c25137/planning/models/resource_resource.py#L73

** Fix **

Retrieve the information about the role with sudo

opw-4908979

Forward-Port-Of: odoo/enterprise#90243

#planning#roles#access rights

[FIX] account_reports: fix "group By" tax reports with analytics

PR #91085

Enterprisemasteraccount_reportsMEDIUM

Tax reports now calculate net amounts correctly when invoices use the same tax with different analytic distributions. This prevents undercounted or duplicated taxable bases in grouped tax reports, improving accuracy for accounting and tax review.

Original PR description

### Issue:
When having two lines on an invoice with the same tax and different analytic distribution, the base value is doubled on the tax report.

### Steps to reproduce:
- Create a new tax on sales (eg 10%)
- Make sure the option "Analytic Accounting" is ticked in the settings
- Create an invoice with a line, add the tax on it and change the analytic distribution
- Do the same for another invoice with another analytic distribution
- Confirm the invoices
- Go to the tax report
- Select the report "Group By: Account > Tax"
- On the report the "Net" amount is only the one of the first invoice, the tax amount is correct

### Cause:
The bug appeared after this [commit](https://github.com/odoo-dev/enterprise/commit/9a7142ef57503efad9538e571d2e35c4aaa59531) which fixed another issue with analytics. Now several lines with the same tax can be returned by the query if they have different analytics. This was used to avoid having the base amount doubled on the invoice when several lines from the same move had with different analytics: there is a line for each analytic but they all have the same base, in the end the base amounts was doubled for each different analytic. Now the query returns multiple lines but as they all have the same key the base amounts are not added together.

This fixes the previous issue when several lines from the same move but with different analytics were added but it creates another issue when different invoices have the same tax and different analytics. Because these lines also have the same key. This result in only the base amount of the first invoice to be taken into account.

### Solution:
The previous fix was incorrect.

The correct fix is to not join the lines when there are two tax lines. To do this the [condition](https://github.com/odoo/odoo/blob/cf8d38205c09a2724f41907fa07c5f23ff2d46a3/addons/account/models/account_move_line_tax_details.py#L153) in the query needs to be the same as the [condition](https://github.com/odoo/odoo/blob/cf8d38205c09a2724f41907fa07c5f23ff2d46a3/addons/account/models/account_move_line.py#L984) that will duplicate the lines in python.

The check on `use_in_tax_closing` was missing so we add it.

opw-4766421

Forward-Port-Of: odoo/enterprise#91065
Forward-Port-Of: odoo/enterprise#90936

#tax reports#analytics#accounting#invoicing

**[FIX] l10n_mx_edi: Fix wrong management of Cuota taxes** Cuota taxes are wrongly reported. For example, a GAZ cuota tax expressed as 4.6555 per quantity has to be reported as TasaOCuota=4.6555 Base=quantity Importe=TasaOCuota * Base Currently, it's reported as: TasaOCuota=abs(tax_amount_currency/base_amount_currency) Base=base_amount_currency Importe is recomputed as TasaOCuota * Base instead of tax_amount_currency task-id: 4761658 **[IMP] l10n_mx_edi: Make test suite a bit less messy** Having a single test testing all taxes combination, testing 100% discount on it + IEPS breakdown and global invoice makes the whole thing difficult to debug. Also, it forces the generation of files that are not always relevant. Forward-Port-Of: odoo/enterprise#89801 Forward-Port-Of: odoo/enterprise#88357

pos_self_order*: pos_online_payment_self_order_preparation_display, pos_self_order_preparation_display Ensure self-orders are sent to the preparation display only after a successful payment, when a valid payment method is configured. **Issue 1: Orders sent for preparation before successful payment** **Steps:** - Configure the kiosk with an online or terminal payment method. - Open the kiosk, add products, and proceed to payment. **Issue:** - Preparation orders were being sent even if the payment was not completed. **Fix:** - Restrict preparation flow to only orders with a successful payment when a valid payment method is configured. --- **Issue 2: Orders not sent for preparation in mobile mode without the online method** - Allow unpaid orders to be sent for preparation only in mobile mode when no online payment method is configured. Task-4845410 Related: https://github.com/odoo/odoo/pull/213493 Forward-Port-Of: odoo/enterprise#90923 Forward-Port-Of: odoo/enterprise#87173

Before this commit, when a ticket was shared through the share wizard or when a message was sent to a customer via the chatter, the recipients were not added as followers of the ticket. As a result, they couldn't see the ticket in the portal. This commit ensures: - Recipients are now added as followers of the ticket when it is shared with them through the wizard. - A message to a customer in the chatter also adds them as a follower of the ticket. task-4781259 Forward-Port-Of: odoo/enterprise#90947 Forward-Port-Of: odoo/enterprise#86169

Corrects the behaviour of the member level assignment in membership when childs partners are concerned. A partner buying a membership should forward the membership level and Pricelist to its children. A child buying a membership should get that membership without forwarding it to its parent. When removed, children should not keep the membership if the parent lose it. TASK-4801759 Forward-Port-Of: odoo/enterprise#86776

Trying to display the roles in the planning app is not possible if the user doesn't have hr_rights even with full planning rights. ** Step to reproduce ** - Connect to Odoo with an user that only have acces right for "Planning" (no employees). - Open Planning app - Configuration>Roles - It will trigger an Access Error (If it didn't trigger add a user to Ressources) ** Cause of the issue ** The acces for the default_role_id is limited to hr.group_hr_user: https://github.com/odoo/enterprise/blob/a7122011a0b0cdd111eccf59c917c6b8e2c25137/planning/models/resource_resource.py#L27 But is used in _compute_display_name: https://github.com/odoo/enterprise/blob/a7122011a0b0cdd111eccf59c917c6b8e2c25137/planning/models/resource_resource.py#L73 ** Fix ** Retrieve the information about the role with sudo opw-4908979 Forward-Port-Of: odoo/enterprise#90243

### Issue: When having two lines on an invoice with the same tax and different analytic distribution, the base value is doubled on the tax report. ### Steps to reproduce: - Create a new tax on sales (eg 10%) - Make sure the option "Analytic Accounting" is ticked in the settings - Create an invoice with a line, add the tax on it and change the analytic distribution - Do the same for another invoice with another analytic distribution - Confirm the invoices - Go to the tax report - Select the report "Group By: Account > Tax" - On the report the "Net" amount is only the one of the first invoice, the tax amount is correct ### Cause: The bug appeared after this [commit](https://github.com/odoo-dev/enterprise/commit/9a7142ef57503efad9538e571d2e35c4aaa59531) which fixed another issue with analytics. Now several lines with the same tax can be returned by the query if they have different analytics. This was used to avoid having the base amount doubled on the invoice when several lines from the same move had with different analytics: there is a line for each analytic but they all have the same base, in the end the base amounts was doubled for each different analytic. Now the query returns multiple lines but as they all have the same key the base amounts are not added together. This fixes the previous issue when several lines from the same move but with different analytics were added but it creates another issue when different invoices have the same tax and different analytics. Because these lines also have the same key. This result in only the base amount of the first invoice to be taken into account. ### Solution: The previous fix was incorrect. The correct fix is to not join the lines when there are two tax lines. To do this the [condition](https://github.com/odoo/odoo/blob/cf8d38205c09a2724f41907fa07c5f23ff2d46a3/addons/account/models/account_move_line_tax_details.py#L153) in the query needs to be the same as the [condition](https://github.com/odoo/odoo/blob/cf8d38205c09a2724f41907fa07c5f23ff2d46a3/addons/account/models/account_move_line.py#L984) that will duplicate the lines in python. The check on `use_in_tax_closing` was missing so we add it. opw-4766421 Forward-Port-Of: odoo/enterprise#91065 Forward-Port-Of: odoo/enterprise#90936