Thursday, August 7, 2025
11 changes · saas-18.4
Enhancements to existing features
The contract template form has been reorganized to restore important information that was lost after HR and contract features were merged. This makes it easier for HR users to review and configure contract templates with the fields they previously relied on.
Original PR description
Since the merge of hr and contract, we only have a form view for contracts for templates. Thus, during the merge, a lot of info has been lost on contract template form view. This commit, reintroduce fields that were present in saas-18.3 and re-organize them. task-4904024 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Accounting can now automatically create separate reconciliation suggestions even when they use the same account, company, and journal. This helps teams handle different recurring transaction labels, such as rent and location payments, without one suggestion blocking another.
Original PR description
Backport of: https://github.com/odoo/enterprise/pull/89358 - Before this commit: The automatic creation of reco model is constrained by company, account and journal. So if the reco model with this…
Backport of: https://github.com/odoo/enterprise/pull/89358
- Before this commit: The automatic creation of reco model is constrained by company, account and journal. So if the reco model with this config exists then new reco model will not be created.
- After this commit: Now we have removed the constraint entirely. Because we want to have more than one reco model with the same account in it.
- Example: Suppose we have 3 statement lines with 'Rent' as a label in them, and 3 statement lines with 'Location' as a label in them.
So before this commit when user sets same account on the first two lines with 'Rent' label, will create a new reco model with
'{Common substring} - {account code}' as a model name and common substring from labels of both lines will be set as a
match_label_param of the model. And then user next set that same account on the first two lines with 'Location' label, will not
create a new reco model automatically, because for this config one reco model already exists.
But now after this commit when user sets same account for first two lines with 'Location' label will also create a new reco
model automatically with '{Common substring} - {account code}' as a model name and common substring from labels of both
lines will be set as a match_label_param of the reco model.
Task: 4876374
Forward-Port-Of: odoo/enterprise#91414Resolved issues and error corrections
This fixes an issue in Point of Sale where staff could not add multiple existing serial-numbered items to the same order when creating new serial numbers was disabled. The checkout flow now correctly accepts serial numbers that were already selected, helping avoid blocked sales for tracked products.
Original PR description
**Steps to reproduce:** - Install `point_of_sale`. - Go to POS -> configuration -> settings - Search 'Operation type' -> open picking type -> Disable `Create new` - Create a storable product 'test'…
Contract template screens now restore important information that was lost after HR and contract features were merged. The layout is reorganized across payroll, salary, work entry, and country-specific payroll modules, making templates easier for HR teams to review and configure.
Original PR description
* = hr_contract_salary, hr_payroll{,_account}, hr_work_entry_{attendance,planning}, l10n_{ae,au,be,ch,eg,hk,id,in,jo,ke,lt,lu,mx,nl,ro,sa,sk,us}_hr_payroll, l10n_au_hr_payroll_account,
Since the merge of hr and contract, we only have a form view for contracts for templates. Thus, during the merge, a lot of info has been lost on contract template form view.
This commit, reintroduce fields that were present in saas-18.3 and re-organize them.
task-4904024**Steps to reproduce:** - Install `point_of_sale`. - Go to POS -> configuration -> settings - Search 'Operation type' -> open picking type -> Disable `Create new` - Create a storable product 'test' with serial tracking. - Add on-hand quantity with serial numbers. - In POS, select the product and choose one SN, - Select it again and choose another SN. **Observation:** - The order line should have 2 quantities with a list of Serial numbers chosen by the user. For one quantity, it's working fine, but for multiple quantities, an issue occurs. **Issue:** - While confirming edit serial numbers popup for multiple quantities, it checks whether each selected SN is valid or not. - The condition is that the entered SN is in the existing available SNs option. But the already chosen SN is not in the existing SN option, - Also, creating a new SN is disabled, so it's considered an invalid input. https://github.com/odoo/odoo/blob/876b7337eb689e0682ab48e9e833f9f0dc6bb8d2/addons/point_of_sale/static/src/app/store/select_lot_popup/select_lot_popup.js#L190-L193 **Solution:** - Added a condition to allow SNs that are already selected (matched by name and ID) to be considered valid inputs. opw-4865902 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221058 Forward-Port-Of: odoo/odoo#219205
Customers no longer receive automatic emails asking them to pay when a payment is already being processed through the payment register with a saved payment method. This avoids confusing payment reminders and improves the customer experience around invoice payments.
Original PR description
**Before this commit:** When creating an invoice payment with the "automatic invoice" option enabled in Sales settings and using a saved payment token, an email is sent to the customer before the…
**Before this commit:** When creating an invoice payment with the "automatic invoice" option enabled in Sales settings and using a saved payment token, an email is sent to the customer before the transaction move is posted and the invoice payment status is updated to "In Payment." This results in the email incorrectly asking the customer to remit payment, even though the payment is already being processed. **Steps to Reproduce:** 1. Enable "Automatic Invoicing" from Sales settings. 2. Enable and publish any payment provider (e.g., Demo) in test mode. 3. Create an invoice and generate a payment link. Open the link in a new incognito tab and pay using any dummy card number (ensure the "Save my payment details" checkbox is checked). This saves the payment token for the partner. 4. Create a new invoice with the same partner, then register payment. Select the payment method and the previously saved token, then confirm. 5. Observe that the payment status is "In Payment," but the email sent to the customer incorrectly asks them to remit payment. **Fix:** This change prevents payment notification emails from being sent automatically when the payment is manually created from the payment register wizard. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4850293) opw-4850293 Forward-Port-Of: odoo/odoo#221997 Forward-Port-Of: odoo/odoo#221587
Vendor bills now select the correct product unit of measure when the same vendor supplies a shared product in multiple companies. This prevents bill creation errors in multi-company purchasing setups and keeps company-specific vendor settings respected.
Original PR description
**Step to reproduce:** 1. Install purchase and account module. 2. Enable the uom option (Purchase > Configuration > Settings). 3. Create a vendor (partner). 4. Set up companies (have at least two…
**Step to reproduce:**
1. Install purchase and account module.
2. Enable the uom option (Purchase > Configuration > Settings).
3. Create a vendor (partner).
4. Set up companies (have at least two companies).
5. Create a product (Vendors bills > Product) that is shared across two companies.
6. Go to Vendors > Product : in the product’s Purchase tab:
- Add the same vendor twice - one line for each company.
- Assign different UoMs (e.g., “Unit(s)” for US company and “Kilogram(s)” for AT company).
7. Switch to one company.
8. Create a vendor bill in one of the companies using that product and vendor.
**Issue:**
A ValueError is raised when creating the vendor bill:
`ValueError: Wrong value for account.move.line.product_uom_id: uom.uom(1, 2)`
https://github.com/odoo/odoo/blob/0e23327c322acbdf6acfecd52385ffee0266220c/addons/account/models/account_move_line.py#L806-L807
**Cause:**
During the computation of product_uom_id where retrieves all seller records
matching the partner_id but fails to limit the result.
**Solution:**
To fix this, retrieve sellers by both partner_id and company_id and first matching
seller is used. This ensures the UoM is correctly set according to the company also.
opw-4877577
Co-authored-by: PIYUSH <pish@odoo.com>
Forward-Port-Of: odoo/odoo#217137This fix ensures that when users create a sales order item from a project task, the company is filled in automatically and product taxes appear as expected. This avoids missing tax information during billable project and timesheet workflows, especially in multi-company environments.
Original PR description
## Short functional explanation of the error When clicking on "create and edit" on a Sales Order Item field in a task, the company field is left blank. As a result, the taxes linked to the product…
## Short functional explanation of the error When clicking on "create and edit" on a Sales Order Item field in a task, the company field is left blank. As a result, the taxes linked to the product don't appear. ## Reproduction Steps 1. Install the modules sales, timesheet and project. 2. Make sure that you have at least 2 different companies in the settings. 2. Click on the project app and create a new project. Check the Billable and Timesheets boxes. 3. Create a task and click on it. Set a customer: the field "Sales Order Item" should appear. 4. Click on the "Sales Order Item" field. Type random letters and click on "create and edit". 5. Select a product that has at least one tax. ### Expected behavior The company field should be filled as soon as we click on the create and edit button, and the taxes field should be filled with the taxes of the product as soon as we select said product. ### Unexpected behavior The company and taxes field remain empty. ## Origin of the issue Some fields were set at "default_." __ opw-4904861 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221342
Customers no longer receive automatic emails asking them to pay when a payment has already been started through the manual payment registration flow. This avoids confusion and reduces the risk of duplicate payment attempts or unnecessary customer support follow-up.
Original PR description
**Before this commit:** When creating an invoice payment with the "automatic invoice" option enabled in Sales settings and using a saved payment token, an email is sent to the customer before the…
**Before this commit:** When creating an invoice payment with the "automatic invoice" option enabled in Sales settings and using a saved payment token, an email is sent to the customer before the transaction move is posted and the invoice payment status is updated to "In Payment." This results in the email incorrectly asking the customer to remit payment, even though the payment is already being processed. **Steps to Reproduce:** 1. Enable "Automatic Invoicing" from Sales settings. 2. Enable and publish any payment provider (e.g., Demo) in test mode. 3. Create an invoice and generate a payment link. Open the link in a new incognito tab and pay using any dummy card number (ensure the "Save my payment details" checkbox is checked). This saves the payment token for the partner. 4. Create a new invoice with the same partner, then register payment. Select the payment method and the previously saved token, then confirm. 5. Observe that the payment status is "In Payment," but the email sent to the customer incorrectly asks them to remit payment. **Fix:** This change prevents payment notification emails from being sent automatically when the payment is manually created from the payment register wizard. opw-4850293 Forward-Port-Of: odoo/enterprise#91761 Forward-Port-Of: odoo/enterprise#91570
Fixed an issue where editing depreciation for assets with a negative value could swap debit and credit amounts in journal entries. This helps keep accounting entries accurate after depreciation adjustments.
Original PR description
Before this commit, creating an asset with a negative value then editing the depreciation caused a inversion between credit and debit in the Journal entries The account_depreciation_id and account_depreciation_expense_id were not inverse for negative depreciation, in the function `_inverse_depreciation_value()` We add that missing account inversion for negative assets Steps to reproduce: - Create an asset with negative Original Value - You can choose any Depreciation Account and Expense Account - Click on Compute Depreciation - Check the Posted Entries and note the values position (credit/debit) - Go back to the Asset > Depreciation Board - Add 10 to the first line Depreciation - Remove 10 to the second line Depreciation - Save the Asset - Check the Posted Entries again - The changes ones should have credit/debit inversion before the fix opw-4759988 Forward-Port-Of: odoo/enterprise#91340 Forward-Port-Of: odoo/enterprise#88907
This fix ensures that time off overlapping with a public holiday is not incorrectly carried over to a future payslip. It helps keep payroll calculations accurate when employees request sick leave or other absences during periods that include public holidays.
Original PR description
The aim of this commit is to prevent a sick day or any other type of time off taken on a public holiday to be deferred. To reproduce: - Create a public Holiday for previous month - Regenerate the work entries for that month - Compute a batch of payslip for last month, validate and mark it as paid --> The public holiday should be on the payslip - OPTIONAL: run the cron `Payroll: Generate pdfs` to make create the payslip in document and make it available to the concerned employee. - With the concerned employee, put a time off on the whole week of the last month. It should overlap with the public holiday. - Validate the time off and defer it for next payslip - Compute a batch of payslip for following month, validate and mark it as paid Before this commit: The overlapping sick day gets deferred completely ignoring the fact it was a public holiday. After this commit: The overlapping sick day doesn't get deferred. opw-4903546 Forward-Port-Of: odoo/enterprise#89264
The journal report now keeps draft invoice lines grouped consistently when several draft invoices share the same date. This prevents errors when users include draft entries and use the Load More option, improving reliability for finance reporting.
Original PR description
**Issue description:** When fetching AMLs for the journal report with _query_aml(), it sorts the AMLs based on (am.date, am.name), which are not unique in case we have multiple (draft) moves with the same date. The lines will end up mixed and ordered with respect to the account, which causes errors with the "Load More" functionality, as it assumes that the lines are ordered based on their move. For posted entries, it's not an issue as the am.name is unique. **Steps to reproduce:** -Create 3 or more invoices (with 3+ AMLs each) in draft and on the same invoicing date. -Open journal report settings and set the Load More Limit to 5. -Open the journal report and set the date to this day and check the "Include Draft Entries" option. -Press "Load More", you will get an error. opw-4929907 Forward-Port-Of: odoo/enterprise#91746 Forward-Port-Of: odoo/enterprise#90360