Odoo Changelog — 2025-03-06

Thursday, March 6, 2025

6 changes · 18.0

Bug Fixes(6)

Resolved issues and error corrections

[FIX] point_of_sale: start order tracking number at 1

PR #194666

Core18.0point_of_saleMEDIUM

Fixes an issue where a point of sale session could reuse an empty order from a previous session, causing customer order tracking numbers to continue from the wrong place. New sessions now start tracking numbers correctly at 1, making receipts and order tracking clearer for staff and customers.

Original PR description

Currently, when you make a os order, close the session an then re-open it without going through the backend, the starting tracking number is related to the previous session.

Steps to reproduce:
-------------------
* Open pos shop
* Make an order and pay it
* Select **New order**
* Close the session, do not go in the backend
* Re-open the session
> Observation: The tracking number is like `X03`. If we make an order,
the tracking number will then be `(X+1)01`.

Why the fix:
------------
When closing the register the current order is marked as cancelled and a reloading of the page is done. When reloading, the `onMounted` of the product screen is triggered which creates a new order.

We will condition the effect of the `onMounted` in a `useEffect` so that we don't create new orders when we are closing the session.

opw-4435140

#pos#order tracking#session

[FIX] l10n_mx: prevent error while creating an account through pos store

PR #200331

Core18.0l10n_mxMEDIUM

Fixes an issue where creating a Point of Sale store for a Mexican company could fail if a default accounting tag had been deleted. The system now continues account creation without that missing tag, helping users complete POS setup without manual technical intervention.

Original PR description

Currently, an error occurs when creating an account with a default tag `Debit Balance Account`, if it has been deleted. **Steps to reproduce:** - Install `l10n_mx`, `accountant`, `point_of_sale`…

Currently, an error occurs when creating an account with a default tag `Debit Balance Account`, if it has been deleted.

**Steps to reproduce:**
- Install `l10n_mx`, `accountant`, `point_of_sale` modules without demo data.
- Change company country to `Mexico`.
- Delete the records `Debit Balance Account` of **account tag**, `Cash` of **journals** and  **chart of Accounts**  
 from `Accounting > Configuration `.
- Create a POS store.
- Observe the error.

**Error:**
`ValueError: External ID not found in the system: l10n_mx.tag_debit_balance_account`

The error occurs because the system attempts to fetch the tag `l10n_mx.tag_debit_balance_account` at [1], but it is unavailable as the user has already deleted it.

This commit ensures that if the tag does not exist, it proceeds without assigning it, preventing the error.

[1] - https://github.com/odoo/odoo/blob/63fc0d1cefaf8f59acd0743a225d1002425ff156/addons/l10n_mx/models/account_account.py#L12

sentry-6356695465

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

#Mexico#Point of Sale#accounting#setup

[FIX] l10n_ar_edi: populate Private Key settings field after generation

PR #79253

Enterprise18.0l10n_ar_ediMEDIUM

When an Argentinian company generates a certificate request without choosing a private key, the newly created key is now automatically shown in settings. Automatically generated keys also receive time-based names, making it easier to identify the correct key when uploading the official certificate later.

Original PR description

Steps to reproduce:

1. Install l10n_ar_edi
2. Use an Argentinian company
3. Go to the "Argentinean Localization" section of the settings
4. Make sure "Private Key" and "Certificate" are empty. Save.
5. Click on "Generate Request".
6. A key has been created but looks like it's not set on the company.

---

Description of the issue this commit addresses:

When generating a certificate request without selecting a private key to generate the certificate request with, a private key is generated by the system but in the settings windows, the field remains empty.

Also, later, after retrieving the certificate from the official platform and trying to insert it in the database, it is required to link it with the private key that was used for its generation but since all automatically generated keys share the same name, this can be quite hard.

---

Desired behavior after this commit is merged:

When using the "Generate Request" button with no private key selected, the Private Key fields is populated with the key that was created for the generation of the request.

Also, the names of the automatically generated keys use the current time for differenciation purposes.

---

Note on the fix:

The error happened because when using the Generate Request button, the key is created by a method called via another request so virtually, the assignment happens in another window. To fix that issue, the key has to be created and assigned before making any other request.

---

task-4393259

#argentina#edi#certificate#settings

[FIX] hr_work_entry_contract_attendance: exclude refused overtime from work entries

PR #80831

Enterprise18.0hr_work_entry_contract_attendanceMEDIUM

Work entries based on employee attendances now exclude overtime that has been refused. This prevents payroll-related work entry durations from incorrectly including time that should not be paid or tracked as worked.

Original PR description

### Issue:
- Refused overtime in attendance, is not correctly excluded from work entries, for employees where the contract work entry resource is attendances.

### Steps To Reproduce:
- Create a new employee with a 40h work schedule.
- Create a new contract for the employee, and set the `Work Entry Source` to `Attendances`
- Change the contract status to running.
- Go to the attendance tab.
- Create a new attendance for the employee.
- Make sure the attendance interval includes some overtime.
- Confirm the attendance.
- Refuse the overtime in the attendance.
- Go to work entries and regenerate new ones.
- Notice the work entry duration includes refused overtime.

### Solution:
- In `_get_attendance_intervals` we rely on the `check_out` date to determine the attendance interval. however this date coresponds to the end of the attendance including refused overtime.

- We modified the attendance `check_out` date to remove hours that are refused overtime.

opw-4571285

#attendance#overtime#work entries#payroll

[FIX] documents(,*): fix two bridge company folder_id issues

PR #78234

Enterprise18.0documentsdocuments_accountdocuments_account_peppoldocuments_approvalsdocuments_fleetdocuments_hrdocuments_hr_payrolldocuments_hr_recruitmentdocuments_productMEDIUM

This change prevents users from accidentally creating company-related folders in the wrong personal area from configuration screens. It also lets teams delete unused app folders after disabling related integrations, while restoring the right folder when those integrations are re-enabled.

Original PR description

See included commits that 
* allow deleting unused company folders
* prevent quick creating folders in the config settings

opw-4444537
Task-4531261

#documents#company folders#configuration#integrations

[FIX] documents(,_hr_payroll): fix inherited and default members

PR #79915

Enterprise18.0documentsdocuments_approvalsdocuments_hr_payrolltest_mail_enterpriseMEDIUM

This update ensures document owners and inherited folder members keep the correct access when documents are created or copied. It fixes access issues for HR Payroll employee declarations so the right payroll folder members can view generated documents, while hiding owner-only access details from the permissions panel.

Original PR description

\+ tests update in documents_approval

Fix owner edit role member after copy or creating inside a
folder, including while specifying access_ids.

Allow client code to add members to the default members added by
the base logic of documents (owner's log) and folders inherited
values => Fix HR Payroll Employee Declaration where members of the
payroll folder would not have access to the generated documents.

The paradigm is:
* The owner should always have a "document.access" record created
* It should be possible to add a member in addition to the inherited
  ones.
* If one passes values for a member when creating, it should override
  the default value for that partner.
* If access_ids is passed as `False`, it should prevent inheriting
  access (but not prevent a role=False record for owner).
* Follow-up of https://github.com/odoo/enterprise/pull/77783, there is no need to enforce
  logic for owner's `documents.access` role as the owner is
  basically an empowered editor.

Additionally, make sure that
 * No membership (document.access with role) is created for odoobot
 * The access of owner is not shown on the permission panel

Task-4593290

#document access#permissions#payroll#folders

Currently, when you make a os order, close the session an then re-open it without going through the backend, the starting tracking number is related to the previous session. Steps to reproduce: ------------------- * Open pos shop * Make an order and pay it * Select **New order** * Close the session, do not go in the backend * Re-open the session > Observation: The tracking number is like `X03`. If we make an order, the tracking number will then be `(X+1)01`. Why the fix: ------------ When closing the register the current order is marked as cancelled and a reloading of the page is done. When reloading, the `onMounted` of the product screen is triggered which creates a new order. We will condition the effect of the `onMounted` in a `useEffect` so that we don't create new orders when we are closing the session. opw-4435140

Currently, an error occurs when creating an account with a default tag `Debit Balance Account`, if it has been deleted. **Steps to reproduce:** - Install `l10n_mx`, `accountant`, `point_of_sale` modules without demo data. - Change company country to `Mexico`. - Delete the records `Debit Balance Account` of **account tag**, `Cash` of **journals** and **chart of Accounts** from `Accounting > Configuration `. - Create a POS store. - Observe the error. **Error:** `ValueError: External ID not found in the system: l10n_mx.tag_debit_balance_account` The error occurs because the system attempts to fetch the tag `l10n_mx.tag_debit_balance_account` at [1], but it is unavailable as the user has already deleted it. This commit ensures that if the tag does not exist, it proceeds without assigning it, preventing the error. [1] - https://github.com/odoo/odoo/blob/63fc0d1cefaf8f59acd0743a225d1002425ff156/addons/l10n_mx/models/account_account.py#L12 sentry-6356695465 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Steps to reproduce: 1. Install l10n_ar_edi 2. Use an Argentinian company 3. Go to the "Argentinean Localization" section of the settings 4. Make sure "Private Key" and "Certificate" are empty. Save. 5. Click on "Generate Request". 6. A key has been created but looks like it's not set on the company. --- Description of the issue this commit addresses: When generating a certificate request without selecting a private key to generate the certificate request with, a private key is generated by the system but in the settings windows, the field remains empty. Also, later, after retrieving the certificate from the official platform and trying to insert it in the database, it is required to link it with the private key that was used for its generation but since all automatically generated keys share the same name, this can be quite hard. --- Desired behavior after this commit is merged: When using the "Generate Request" button with no private key selected, the Private Key fields is populated with the key that was created for the generation of the request. Also, the names of the automatically generated keys use the current time for differenciation purposes. --- Note on the fix: The error happened because when using the Generate Request button, the key is created by a method called via another request so virtually, the assignment happens in another window. To fix that issue, the key has to be created and assigned before making any other request. --- task-4393259

### Issue: - Refused overtime in attendance, is not correctly excluded from work entries, for employees where the contract work entry resource is attendances. ### Steps To Reproduce: - Create a new employee with a 40h work schedule. - Create a new contract for the employee, and set the `Work Entry Source` to `Attendances` - Change the contract status to running. - Go to the attendance tab. - Create a new attendance for the employee. - Make sure the attendance interval includes some overtime. - Confirm the attendance. - Refuse the overtime in the attendance. - Go to work entries and regenerate new ones. - Notice the work entry duration includes refused overtime. ### Solution: - In `_get_attendance_intervals` we rely on the `check_out` date to determine the attendance interval. however this date coresponds to the end of the attendance including refused overtime. - We modified the attendance `check_out` date to remove hours that are refused overtime. opw-4571285

\+ tests update in documents_approval Fix owner edit role member after copy or creating inside a folder, including while specifying access_ids. Allow client code to add members to the default members added by the base logic of documents (owner's log) and folders inherited values => Fix HR Payroll Employee Declaration where members of the payroll folder would not have access to the generated documents. The paradigm is: * The owner should always have a "document.access" record created * It should be possible to add a member in addition to the inherited ones. * If one passes values for a member when creating, it should override the default value for that partner. * If access_ids is passed as `False`, it should prevent inheriting access (but not prevent a role=False record for owner). * Follow-up of https://github.com/odoo/enterprise/pull/77783, there is no need to enforce logic for owner's `documents.access` role as the owner is basically an empowered editor. Additionally, make sure that * No membership (document.access with role) is created for odoobot * The access of owner is not shown on the permission panel Task-4593290