Daily updates from Odoo
Thursday, August 7, 2025
9 changes
3 changes
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
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-4904024Accounting 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#914141 change
Enhancements to existing features
The first bank account sync now creates a proper opening bank statement instead of a placeholder transaction. This prevents fake accounting entries, improves starting balance accuracy, and makes initial bank reconciliation more reliable.
Original PR description
Before: - When syncing a bank account for the first time, the system created a dummy bank statement line to fill missing statement data. - This was not linked to a real transaction and could confuse users or lead to inaccurate reporting. After: - Replaced the dummy statement line logic with the creation of a proper opening bank statement. - The system now accurately sets the starting balance and the current balance based on the imported transactions. - This logic only applies when no previous bank statement lines exist for the journal and the current balance differs from the sum of imported transactions. Impact: - Prevents creation of fake bank transactions and journal entries during initial sync, ensuring accurate accounting from the start. - Improves performance and reliability by calculating the correct opening balance using real transaction data and provided bank balance. TaskID-4815622
3 changes
Enhancements to existing features
This update streamlines how users see and move to the next status for account returns, making the workflow clearer. Audit-related returns are now automatically marked complete after validation, reducing manual follow-up.
Original PR description
* Simplify the view logic for displaying the state transition buttons by adding a new computed field for the next_state of current return type. * For Audit category return, automatically set is_completed to True after validation. task-4975340
The Point of Sale due payment flow no longer loads all account move records upfront when opening the interface. This reduces memory use and loading times, making the experience faster and more reliable for users handling settlements.
Original PR description
Before this commit, all account.move records were loaded into the PoS interface, even though they were not used immediately. This caused significant performance issues, increasing memory usage and loading times. opw-4986727 Forward-Port-Of: odoo/enterprise#91515
Odoo Studio’s report editor has been improved so users can edit existing dynamic fields directly in reports. The underlying editor tools were reorganized to make the report editor easier to maintain and test, supporting more reliable future improvements.
2 changes
Enhancements to existing features
Bulgarian invoices will automatically use the invoice date as the delivery date when no delivery date is entered. This helps businesses meet local invoicing requirements and reduces the risk of missing mandatory information on printed invoices.
Original PR description
Description of the issue/feature this PR addresses: Delivery dates on invoices are a legal requirement on Bulgaria. It needs to be displayed on the header of the form view and will be displayed on the printed invoices. Current behavior before PR: Delivery date is not required and it is possible to not have value. Desired behavior after PR is merged: If delivery date is empty it copy the value of invoice date field in delivery date field --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale users in Brazil can now download NFC-e XML files for multiple orders at once from the order list. This saves time and reduces manual work when collecting fiscal documents for reporting or compliance.
Original PR description
- Before this PR: No available action to download NFC-e XML files in batch. User has to download each xml file one by one. - After this PR: An action to download multiple NFC-e XMLs for multiple orders is added in the PoS orders list view. Task Id: 4934938