Daily updates from Odoo
Wednesday, July 15, 2026
49 changes · saas-19.1
New functionality added to Odoo
This update adds functionality to seamlessly integrate with Taiwan's E-invoice system. It now automatically transfers relevant data from point-of-sale orders to the corresponding invoices, simplifying the process for businesses operating in Taiwan and ensuring compliance with local regulations.
Original PR description
This module adds extra functions on the point of sale for l10n_tw_edi_ecpay, passing values from pos order to invoice for creating Taiwan E-invoice task-5122414 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255980
Enhancements to existing features
The Mexican payroll localization now includes the latest SAT perception and deduction concepts in the CFDI payroll catalog. This helps businesses keep payroll reporting aligned with current Mexican tax authority requirements.
Original PR description
Adds the new SAT perception and deduction concepts to the Mexican payroll CFDI concept catalog. task-6295124
Draft bank statement lines now appear in blue in the bank reconciliation view. This helps accounting users quickly identify which lines are not yet finalized, reducing the chance of overlooking pending work.
Original PR description
This commit will put the text in blue when the statement line is in draft to be able to see quickly which lines are in draft. task-6327308 Forward-Port-Of: odoo/enterprise#121775
LEGAL REQUIREMENTS - As of January 2026, the 9% VAT will increase to 12%. PURPOSE - For each 9% VAT, add 12% VAT with the same tax tag and descriptions, so in the VAT report, it's put under the same lines. - And add the missing taxes from the sheet provided in the task description. Related PR: https://github.com/odoo/enterprise/pull/101773 Task-5269617 Forward-Port-Of: odoo/odoo#239388
Original PR description
LEGAL REQUIREMENTS - As of January 2026, the 9% VAT will increase to 12%. PURPOSE - For each 9% VAT, add 12% VAT with the same tax tag and descriptions, so in the VAT report, it's put under the same lines. - And add the missing taxes from the sheet provided in the task description. Related PR: https://github.com/odoo/enterprise/pull/101773 Task-5269617 Forward-Port-Of: odoo/odoo#239388
It is mandatory in BE to add a legal note on the invoice when using a "Co-Contractant" tax task-5905176 Forward-Port-Of: odoo/odoo#263893 Forward-Port-Of: odoo/odoo#251797
Original PR description
It is mandatory in BE to add a legal note on the invoice when using a "Co-Contractant" tax task-5905176 Forward-Port-Of: odoo/odoo#263893 Forward-Port-Of: odoo/odoo#251797
Servers would return a 403 because we annoy them for downloading the WSDL/XSD at every call. opw-6237180 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 Forward-Port-Of: odoo/odoo#267482
Original PR description
Servers would return a 403 because we annoy them for downloading the WSDL/XSD at every call. opw-6237180 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 Forward-Port-Of: odoo/odoo#267482
Resolved issues and error corrections
Fixes an error that could appear when users returned to the budget report list using breadcrumbs after opening a report entry. Budget reports now have a safe default order, so users can continue reviewing analytic budget details without interruption.
Original PR description
Problem:
The `budget.report` model had its default sorting (`_order`) set to False. When a user navigates back to the report list view via the breadcrumbs, the web client invokes `web_read_group`, which runs `self._order.split(',')`. Because `_order` is a boolean rather than a string, this raises an AttributeError and throws an RPC_ERROR.
Solution:
Set `_order = 'date desc'` on `budget.report`. Both queries within the `_table_query` UNION ALL expose a `date` column, providing a semantically correct and safe default ordering constraint.
Steps to replicate:
- Go to Accounting > Accounting > Analytic Budgets.
- Select any budget.
- Click 'Audit' on any budget line to land on the budget report view.
- Click to open any individual record.
- Navigate back using the breadcrumbs.
- -> RPC_ERROR: AttributeError: 'bool' object has no attribute 'split'
opw-6372610
Forward-Port-Of: odoo/enterprise#124191This fixes an error that could appear when payroll users added Daily Salary or Integration Factor fields to payslip forms with Odoo Studio. The fields can now be displayed safely before an employee or contract version is selected, helping users verify payroll calculations without interruptions.
Original PR description
Users frequently use Odoo Studio to display the Daily Salary (`l10n_mx_daily_salary`) and Integration Factor (`l10n_mx_integration_factor`) fields on the payslip form to verify salary rule…
Users frequently use Odoo Studio to display the Daily Salary (`l10n_mx_daily_salary`) and Integration Factor (`l10n_mx_integration_factor`) fields on the payslip form to verify salary rule computations. However, doing so raises a traceback immediately upon closing the Studio editor, as well as when attempting to create a new Off-Cycle payslip.
### Steps to reproduce:
* Install `l10n_mx_hr_payroll` and `web_studio`.
* Switch to "INNOVACION VALOR Y DESARROLLO SA SA" company.
* Go to Payroll > Payslips > Payslips and create a "New Off-Cycle"
* Use the Studio editor to add `l10n_mx_daily_salary` or `l10n_mx_integration_factor` fields.
* Close the Studio editor.
### Current behavior:
A traceback is raised depending on the field added
#### For the Daily Salary field:
```py
File "/Users/ivgm/odev/worktrees/19.0/enterprise/l10n_mx_hr_payroll/models/hr_payslip.py", line 21, in _compute_daily_salary
payslip.l10n_mx_daily_salary = payslip.version_id.wage / payslip._rule_parameter('l10n_mx_schedule_table')[payslip.version_id.schedule_pay]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: False
```
#### For the Integration Factor field:
```py
File "/Users/ivgm/odev/worktrees/19.0/enterprise/l10n_mx_hr_payroll/models/hr_payslip.py", line 33, in _compute_integration_factor
payslip.employee_id.with_context(before_date=payslip.date_from)._get_first_contract_date()
File "/Users/ivgm/odev/worktrees/19.0/odoo/addons/hr/models/hr_employee.py", line 493, in _get_first_contract_date
versions = self._get_first_versions_filtered(no_gap=no_gap).filtered(lambda x: x.contract_date_start)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/ivgm/odev/worktrees/19.0/odoo/addons/hr/models/hr_employee.py", line 461, in _get_first_versions_filtered
self.ensure_one()
File "/Users/ivgm/odev/worktrees/19.0/odoo/odoo/orm/models.py", line 5942, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.employee()
```
### Expected behavior:
No error is raised, and the fields are correctly displayed on the form view.
### Solution:
* Add Guard Clause: When creating a "New Off-Cycle" payslip, `payslip.version_id` is not initially set because no employee has been selected yet. Added a condition to check if `version_id` exists before computing the values to prevent the traceback.
* View Update: Since displaying these fields is a highly requested feature for traceability, they have now been added to the form view.
target: 19.0
task-6267003
Forward-Port-Of: odoo/enterprise#121718This fix updates the Belgian payroll rules so the 3000 deduction is correctly applied for the second and third quarters of 2026. It helps ensure payroll calculations remain aligned with Belgian payroll requirements during that period.
Original PR description
Forward-Port-Of: odoo/enterprise#124034
Payroll schedule options now appear in the user's selected language across multiple country payroll modules. This fixes untranslated salary payment frequency labels, improving usability for employees and HR teams working in non-English languages.
Original PR description
Issue: ---------------------------------------- The values of the field `schedule_pay` aren't translated. Steps to reproduce: ---------------------------------------- - Switch the language to French - Open an employee form, "Paie" tab - The selection in the "Salaire" tab is not translated to French Cause: ---------------------------------------- When the selection values were moved to a method in 7a123d71925b25f26ba0a8abff0c4a159147bdd0. The strings were not declared as translatable. opw-6359395 Forward-Port-Of: odoo/enterprise#123718
Shopee order lines now show the SKU for the specific product variant ordered, rather than the general template SKU. This makes order descriptions clearer and helps teams identify the exact item sold when listings include variants.
Original PR description
Currently, _prepare_order_lines_values resolves SKU as `item_sku or model_sku`. Shopee always sends item_sku (product.template SKU), so when a listing has variants the order line description shows the template SKU ([item_sku]) even though the correct variant is linked via `model_sku`. task_id: 6335110 Forward-Port-Of: odoo/enterprise#124031
Creating certificates in settings no longer fails when a Peruvian company is used alongside the Chilean localization. The Chile-specific serial number requirement is now limited to the relevant Chilean context, avoiding unnecessary setup errors for other Latin American companies.
Original PR description
With a l10n_pe company and having a l10n_cl company installed: - Try to create a certificate in the settings, there is a missing field error. The template certificate_certificate_view_form have a required subject_serial_number field in l10n_cl but it shouldn't in other latam localization. opw-6274126 Forward-Port-Of: odoo/enterprise#120211
Regular employees can now open the Attendance Gantt view even when coworkers with fully flexible schedules have approved time off. This prevents an access error and keeps attendance planning usable without exposing restricted time-off records.
Original PR description
When a regular employee accesses the Attendance Gantt view, they encounter an AccessError if there are other employees with flexible schedules who have taken time off. ### **Steps to reproduce:** -…
When a regular employee accesses the Attendance Gantt view, they encounter an AccessError if there are other employees with flexible schedules who have taken time off. ### **Steps to reproduce:** - Install hr_holidays, hr_attendance with demo. - Create a time off and validate for an employee, and set the employee's contract to fully flexible - As demo user, go to the attendance app. ### **Error:** ``` odoo.exceptions.AccessError: Sorry, Marc Demo doesn't have 'read' access to: - Time Off (hr.leave) ``` ### **Root cause:** since [this commit](https://github.com/odoo/enterprise/pull/112482/changes/b326263d67dc0654a7d4b6d77dc4ad8de53bc1c1), `handle_flexible_leave_interval` accesses fields on `leave.holiday_id` at [1] to determine the bounds of flexible leave intervals. when the unavailability computation is performed by a regular employee, they may not have access to the corresponding `leave` record leading to access error. [1]- https://github.com/odoo/enterprise/blob/7a34c9a6a58df22fbef143d820a29106249e3af5/hr_holidays_gantt/models/resource_calendar.py#L17-L24 ### **Fix:** This commit allows regular employees to compute unavailability intervals for flexible employees. **opw-6243778** Forward-Port-Of: odoo/enterprise#119229
This fix prevents an error when opening Studio from the Working Files menu and view. It improves reliability for users customizing or reviewing working files, with no expected change to normal business workflows.
Original PR description
Open Studio while on "Working Files" menu and view. Before this commit, the python raised an error becaude at some point `record[False]` (returning the current virtual record) was put in the return values of the onchange. After this commit, there is no error. runbot-error-941248
The Trial Balance report now handles load-more rows even when some column information is empty. This prevents an error for users reviewing partner-grouped balances, improving reliability when navigating accounting reports.
Original PR description
…umn dict Steps to reproduce: - Install l10n_co_reports and select CO company - Open the trial balance grouped by partner variant - Set the load more limit to 2 - Go back to report, unfold an account, and press load-more line -> Traceback because it's expected the column dict to contain a column group. The report engine, however, accepts lines with empty dicts. Therefore, the trial balance should handle this case. task-6384451
The automatic bank statement reconciliation process now retries lines that fail once before excluding them. This helps avoid losing reconciliation work due to temporary system issues, improving reliability for accounting teams.
Original PR description
The auto reconcile cron drops the lines whenever they raise an error which is an issue for things like serialization errors. Now the code retries failed lines once before dropping them to make sure it's an issue with the lines. task-6273202 Forward-Port-Of: odoo/enterprise#119383
This fixes an issue where the signing interface could fail in debug mode when extra page markers were present. The change helps keep document signing reliable for users working with customized or inherited templates.
Original PR description
Use lastElementChild when retrieving the sign item from the target element. In debug mode, inherited templates may introduce HTML comments into the DOM. Since lastChild return a comment node, accessing classList on the returned node raises an error. Using lastElementChild ensures that the last HTML element is always retrieved, regardless of comment nodes in the DOM. Forward-Port-Of: odoo/enterprise#122106
The Dutch reports module information no longer shows an outdated website link that now points to unrelated content. This prevents users from being sent to the wrong site and keeps the module details accurate.
Original PR description
The URL leads to a website that has nothing to do with what it used to be so it needs to be removed. Task-6360682 Forward-Port-Of: odoo/enterprise#124155 Forward-Port-Of: odoo/enterprise#123019
Indian GST reports now better reflect current legal requirements for imports. Import of services is no longer shown in GSTR-2B, and GSTR-3B reporting has been adjusted for updated import sections for goods and services.
Original PR description
As per the law, import of services is not required to be shown in GSTR-2B. Therefore, the related report lines are removed in this commit. Additionally, GSTR-3B reporting is now handled according to the updated section changes for import of goods and services. task-6330737 Forward-Port-Of: odoo/enterprise#121925
When event dates are changed, attendee email content now reflects the latest start date instead of showing outdated information. This helps avoid sending incorrect event schedules to participants after rescheduling.
Original PR description
Steps to reproduce: ------------------------------------------------ 1. Install Event module 2. Create a multi day event 3. Create one attendee for the event 4. Change the event dates 5. Go to…
Steps to reproduce: ------------------------------------------------ 1. Install Event module 2. Create a multi day event 3. Create one attendee for the event 4. Change the event dates 5. Go to attendee and Click on Send by Email Observation: ------------------------------------------------ The event start date displayed in the email body is not updated after the event dates are modified. Issue: ------------------------------------------------ In `saas-18.2`, `event_begin_date` and `event_end_date` were simple related fields that automatically updated when their source fields changed. https://github.com/odoo/odoo/blob/saas-18.2/addons/event/models/event_registration.py#L57-L58 However, in `saas-18.3`, slots were introduced and these fields were converted to computed fields https://github.com/odoo/odoo/pull/205945/changes/e2bf8a89d6a50bd40f4673bef38176465f83ba0f * `event_begin_date` is made stored for cohort view grouping * However, the base compute method only depends on `event_id` and `event_slot_id` https://github.com/odoo/odoo/blob/ac37b479321dbe9dbf864e833900e043b1cc70df/addons/event/models/event_registration.py#L177-L180 * When you change `event.date_begin` or `event.date_end`, the registration records don't recompute because the dependency is on the `event_id`, not on the related date fields (`event_id.date_begin`, `event_id.date_end`) * Non-stored computed fields recalculate on-the-fly when accessed, so `event_end_date` appeared to work * Stored computed fields only recalculate when their explicit dependencies change Solution: ------------------------------------------------ * Corrected the dependencies of `_compute_event_begin_date` to recompute value on changing the date of the event opw-6284576 Forward-Port-Of: odoo/enterprise#120184
Opening Studio from a project task list now keeps the browser URL clean and avoids adding an incorrect extra project or task identifier. Users can also use the browser back button or load the Studio URL directly without running into navigation errors.
Original PR description
Go on a project, then open its task list view Open studio with the menu item. At this point, studio is open but the url looks like: `/odoo/project/5/tasks/studio/5` the last `/5` is wrong ; this commit fixes this. Then, hit the browser's back button. There is an error because the active_id was not correctly set when leaving studio that way Try loading `/odoo/project/5/tasks/studio`, again, there is an error because the active_id is read from the wrong object Forward-Port-Of: odoo/enterprise#122405
This fix ensures Saudi GOSI contributions are calculated on the full eligible amount rather than being prorated. This helps payroll teams produce more accurate payslips and reduces the risk of incorrect social insurance reporting.
Original PR description
task-id: 6380239 Forward-Port-Of: odoo/enterprise#124122
opw-6368979 Description of the issue/feature this PR addresses: Update the Worldline Cofidis payment method mapping to match the latest payment product ID defined in the Worldline documentation. Current behavior before PR: The Cofidis payment method was mapped to the outdated payment product ID (3012), causing payment requests to use an incorrect mapping. Desired behavior after PR is merged: The Cofidis payment method is mapped to the correct payment product ID (5129) as per
Original PR description
opw-6368979 Description of the issue/feature this PR addresses: Update the Worldline Cofidis payment method mapping to match the latest payment product ID defined in the Worldline documentation. Current behavior before PR: The Cofidis payment method was mapped to the outdated payment product ID (3012), causing payment requests to use an incorrect mapping. Desired behavior after PR is merged: The Cofidis payment method is mapped to the correct payment product ID (5129) as per the latest Worldline documentation, ensuring payment requests use the correct mapping. Forward-Port-Of: odoo/odoo#275881
Issue: ---------------------------------------- The units (day, year, etc.) aren't being translated in the Milestones view. Steps to reproduce: ---------------------------------------- - Switch the language to French - Go on an Accrual plan form view - In the milestones view, the units aren't translated Cause: ---------------------------------------- We input the key value of the selections fields `start_type` and `added_value_type`. These values aren't translated. Solution: --
Original PR description
Issue: ---------------------------------------- The units (day, year, etc.) aren't being translated in the Milestones view. Steps to reproduce: ---------------------------------------- - Switch the language to French - Go on an Accrual plan form view - In the milestones view, the units aren't translated Cause: ---------------------------------------- We input the key value of the selections fields `start_type` and `added_value_type`. These values aren't translated. Solution: ---------------------------------------- We create a dictionary with the same keys as the fields and a translated value as values. In the view, we read the values of the dictionary to get the translated units. opw-6367235 Forward-Port-Of: odoo/odoo#275575
### Before this PR When importing a FatturaPA XML, Odoo sets the fiscal position on the bill from the partner but does not apply it to the line taxes so a fiscal position that remaps taxes (partial deductibility, reverse charge, split payment) never map the imported lines. ### After this PR the fiscal position is correctly applied ### To reproduce 1. Apply to Italian vendor a fiscal position that maps the 22% purchase tax to a partial-deductibility tax (e.g. "22%" →"22% ind. 50%").
Original PR description
### Before this PR When importing a FatturaPA XML, Odoo sets the fiscal position on the bill from the partner but does not apply it to the line taxes so a fiscal position that remaps taxes (partial deductibility, reverse charge, split payment) never map the imported lines. ### After this PR the fiscal position is correctly applied ### To reproduce 1. Apply to Italian vendor a fiscal position that maps the 22% purchase tax to a partial-deductibility tax (e.g. "22%" →"22% ind. 50%"). 2. Import a FatturaPA XML from that vendor with 22% lines. 3. The bill header shows the fiscal position, but the lines keep the plain 22% tax instead of the mapped one. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275614 Forward-Port-Of: odoo/odoo#274738
**Steps to reproduce:** - Create a dynamic variant with 2 values, A and B - B should have an extra price of 200 - Create a product which has those two variants, with a price of 1000 - Set up a barcode for the product with the B variant only - Go to the PoS, enter the barcode for the product with the B variant - The price is 1400 instead of 1200 **Why the fix:** The extra price for dynamic variants ordered through the barcode will be counted twice. This is because it is first count
Original PR description
**Steps to reproduce:** - Create a dynamic variant with 2 values, A and B - B should have an extra price of 200 - Create a product which has those two variants, with a price of 1000 - Set up a…
**Steps to reproduce:** - Create a dynamic variant with 2 values, A and B - B should have an extra price of 200 - Create a product which has those two variants, with a price of 1000 - Set up a barcode for the product with the B variant only - Go to the PoS, enter the barcode for the product with the B variant - The price is 1400 instead of 1200 **Why the fix:** The extra price for dynamic variants ordered through the barcode will be counted twice. This is because it is first counted in the _scan(code) method when we fetch the product from the models, then counted again when adding the line to the current order. https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/point_of_sale/static/src/app/services/pos_store.js#L1264-L1269 This step is necessary for the usual flow without the barcode as we need to add this extra price, but when using the barcode, the list price of the product we fetch is already 1200, as the extra price is already included when fetching it from the backend. It works for always attributes because we explicitly check that we are not adding the extra price again in the above code, and that the list price already includes the extra price. It also works for the never attributes because values.product_id.product_template_variant_value_ids.length is 0, so the code to update the extra price is never triggered. As we still need to add the extra price for the usual flow, we now just check if we have a code, meaning we added the product through the barcode and that we do not need to add it again, as the list price already accounts for the extra price. opw-6328600 Forward-Port-Of: odoo/odoo#272395
When creating or editing a portal billing address, the Company Name field was pre-filled from `commercial_company_name`. For contacts without a parent company, the commercial partner is the contact itself, so the contact name was shown as the company name. Use the partner's actual parent company name instead, so the field stays empty when no company is linked while still showing the existing parent company when one exists. see: https://github.com/odoo/odoo/commit/18a59cf26f2d9400f76deec483
Original PR description
When creating or editing a portal billing address, the Company Name field was pre-filled from `commercial_company_name`. For contacts without a parent company, the commercial partner is the contact itself, so the contact name was shown as the company name. Use the partner's actual parent company name instead, so the field stays empty when no company is linked while still showing the existing parent company when one exists. see: https://github.com/odoo/odoo/commit/18a59cf26f2d9400f76deec483f6ddab87da0c55 Task-6372638
Click Working Files menu, then open studio. Before this commit there was an error, because the accounting code tried to check access rights on an new record (no id) After this commit there is no crash. runbot-error-941248 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
Original PR description
Click Working Files menu, then open studio. Before this commit there was an error, because the accounting code tried to check access rights on an new record (no id) After this commit there is no crash. runbot-error-941248 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
Before this commit, when making a test print from the POS backend, the following issues would occur: - Very slow response - Missing cut, and extra 'A' character is printed This commit fixes both these issues. The slow response is avoided by not performing the network tests when they aren't used in the printed receipt. The cut issue is solved by appending a newline character to the message. task-6391141 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/s
Original PR description
Before this commit, when making a test print from the POS backend, the following issues would occur: - Very slow response - Missing cut, and extra 'A' character is printed This commit fixes both these issues. The slow response is avoided by not performing the network tests when they aren't used in the printed receipt. The cut issue is solved by appending a newline character to the message. task-6391141 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Animated GIFs applied with an image shape freeze on Firefox and Safari when the shape's SVG is otherwise static. A dummy `<animateMotion dur="1ms" repeatCount="indefinite"/>` child on the <image> element keeps the animation running so the GIF plays. This hack was introduced in [1] but was missing from most shapes. This commit adds it to every <image> element that lacked it so any shape can be used with a GIF. task-5967171 [1]: https://github.com/odoo/odoo/commit/144e5ef799060da860a5fb1f
Original PR description
Animated GIFs applied with an image shape freeze on Firefox and Safari when the shape's SVG is otherwise static. A dummy `<animateMotion dur="1ms" repeatCount="indefinite"/>` child on the <image> element keeps the animation running so the GIF plays. This hack was introduced in [1] but was missing from most shapes. This commit adds it to every <image> element that lacked it so any shape can be used with a GIF. task-5967171 [1]: https://github.com/odoo/odoo/commit/144e5ef799060da860a5fb1fbe0fd009919afe79 Forward-Port-Of: odoo/odoo#275259
Loading a certificate could raise an unhandled exception instead of failing gracefully. Clearing the content, uploading a bundle with a corrupted certificate block, or handling certificates with unsupported signature algorithms or malformed extensions all could end up in a traceback. Guard those paths to ensure loading errors are handled. opw-6370529 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I
Original PR description
Loading a certificate could raise an unhandled exception instead of failing gracefully. Clearing the content, uploading a bundle with a corrupted certificate block, or handling certificates with unsupported signature algorithms or malformed extensions all could end up in a traceback. Guard those paths to ensure loading errors are handled. opw-6370529 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 Forward-Port-Of: odoo/odoo#275325
Previously: 1.`purchase_cdnur_regular` section was assigned to credit/debit notes of: - import of goods - import of services without RCM However: - import of goods should be handled through bill of supply - import of services without RCM is not possible Therefore, with this commit, such journal items are moved to `purchase_out_of_scope`. 2.`purcha
Original PR description
Previously:
1.`purchase_cdnur_regular` section was assigned to credit/debit notes of:
- import of goods
- import of services without RCM However:
- import of goods should be handled through bill of supply
- import of services without RCM is not possible Therefore, with this commit, such journal items are moved to `purchase_out_of_scope`.
2.`purchase_imp_services` section included import of services both with and
without RCM. Since import of services without RCM is not possible, those
journal items are now moved to `purchase_out_of_scope`.
3.Credit/debit notes of import of services with RCM were previously moved to
`purchase_out_of_scope`, which was incorrect. With this commit, they are now
correctly moved to `purchase_imp_services`.
task-6330737
Forward-Port-Of: odoo/odoo#272453Problem: When posting expenses, if the expense domain is set as mandatory in any of the analytic plans, users can still submit expenses without entering an analytic distribution. This only happens when the expense is auto-approved on submission, which happens when the expense's employee is also the expense's manager or when the employee doesn't have an expense manager. Steps to reproduce: 1. Create an analytic plan with optional default applicability 2. Add an applicability rule with the d
Original PR description
Problem: When posting expenses, if the expense domain is set as mandatory in any of the analytic plans, users can still submit expenses without entering an analytic distribution. This only happens…
Problem: When posting expenses, if the expense domain is set as mandatory in any of the analytic plans, users can still submit expenses without entering an analytic distribution. This only happens when the expense is auto-approved on submission, which happens when the expense's employee is also the expense's manager or when the employee doesn't have an expense manager. Steps to reproduce: 1. Create an analytic plan with optional default applicability 2. Add an applicability rule with the domain set as Expense and set its applicability as mandatory. 3. Create a new expense 4. Set the expense's manager the same as the expense's employee. 5. Don't enter any analytic distribution. 6. Submit the expense 7. Notice how the expense is submitted and auto-approved without any error, even though no analytic distribution is entered and the analytic plan has a mandatory rule for expenses. Cause: The validation of the analytic distribution was only triggered on the approval of the expense, but when the expense is auto-approved on submission, the validation is not triggered at all. Solution: Move the validation of the analytic distribution to the do_approve method, which gets called both when an expense is approved and when it's auto-approved on submission. opw-6187340 Forward-Port-Of: odoo/odoo#270268
#### Issue: When creating a reordering rule for a shared manufactured product in a multi-company database, saving the rule may raise an `AccessError` on `mrp.bom`. The orderpoint is still created, but the user sees a record-rule error if the product also has BoMs in companies that are not currently active. #### Example: A product is shared across multiple companies, and each company has its own BoM for that product. In the reproduced case, the active company has the correct variant Bo
Original PR description
#### Issue: When creating a reordering rule for a shared manufactured product in a multi-company database, saving the rule may raise an `AccessError` on `mrp.bom`. The orderpoint is still created,…
#### Issue: When creating a reordering rule for a shared manufactured product in a multi-company database, saving the rule may raise an `AccessError` on `mrp.bom`. The orderpoint is still created, but the user sees a record-rule error if the product also has BoMs in companies that are not currently active. #### Example: A product is shared across multiple companies, and each company has its own BoM for that product. In the reproduced case, the active company has the correct variant BoM. However, the orderpoint computation first checks the broader product-template BoM relation, which may include BoMs from the other companies. As a result, Odoo can try to access a BoM from another company while the user is only working in the active company, causing an access error. #### Steps to reproduce: Use a multi-company database with MRP enabled. Create or use a shared product available to multiple companies. Create BoMs for that product in more than one company. Set the active company to the company where the reordering rule should be created. Create a reordering rule for the product. Save the reordering rule. Note the AccessError related to mrp.bom. #### Root Cause: The MRP orderpoint computations read `product_id.bom_ids` directly. This is the product-template BoM relation and can include BoMs from other companies for a shared product. Reading fields on those BoMs, such as `product_uom_id`, can hit the standard `mrp.bom` multi-company record rule. #### Fix: Prefer `product_id.variant_bom_ids` before falling back to `product_id.bom_ids` in the affected orderpoint computations. This avoids reading template-level BoMs from other companies when the product has a variant-specific BoM for the current reordering-rule use case. opw-6253743 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267411
**Steps to reproduce:** - Install Contacts app - Open any record - Go to the chatter - Create an activity with a description - Duplicate the tab - Go back to the initial tab - Description doesn't appear anymore - Refreshing shows it but will remove it from the other tab **Issue:** Behavior comes from the broadcasting of activity changes between tabs `new browser.BroadcastChannel("mail.activity.channel");`. Computed fields are not recomputed on the receiver side after value inserti
Original PR description
**Steps to reproduce:** - Install Contacts app - Open any record - Go to the chatter - Create an activity with a description - Duplicate the tab - Go back to the initial tab - Description doesn't…
**Steps to reproduce:**
- Install Contacts app
- Open any record
- Go to the chatter
- Create an activity with a description
- Duplicate the tab
- Go back to the initial tab
- Description doesn't appear anymore
- Refreshing shows it but will remove it from the other tab
**Issue:**
Behavior comes from the broadcasting of activity changes between tabs `new browser.BroadcastChannel("mail.activity.channel");`.
Computed fields are not recomputed on the receiver side after value insertion in `_onActivityBroadcastChannelMessage` (also related components are not (re)mounted, e.g. when a new activity is created the other tab doesn't show it without a refresh).
This means that `isNoteEmpty` keeps its default value `true` (added by `this.toData()`) and the `note` stays hidden here [1]:
```xml
<div t-if="!props.activity.isNoteEmpty" class="o-mail-Activity-note text-break" t-out="props.activity.note"/>
```
**Fix:**
Remove computed fields in activity `serialize` before broadcasting them to ensure they don't force the default value.
(note installing `calendar` in 19.3+ removes this issue due to [2] which overrides the condition on `isNoteEmpty`)
[1] https://github.com/odoo/odoo/commit/eb9f0658c3da1a9fef69f1cc1117c2d44f9d61b1
[2] https://github.com/odoo/odoo/commit/44e2c2c5ca07849fd8964140f3ca61122c47f0c6
opw-6247412
Forward-Port-Of: odoo/odoo#276032
Forward-Port-Of: odoo/odoo#275528Remove the generic active 296 and 297 impairment accounts and make the existing French PCG 296/297 subaccounts active instead, because what we use in the balance sheet formulas are the subaccounts, and it's better to remove the generic ones to not give users the ability to post on these generic accounts, also adapt their translations to be aligned with PCG wording. Move pcg_2962 from the companies chart file to the base French chart file, as 2962 is a general PCG account and not a compa
Original PR description
Remove the generic active 296 and 297 impairment accounts and make the existing French PCG 296/297 subaccounts active instead, because what we use in the balance sheet formulas are the subaccounts, and it's better to remove the generic ones to not give users the ability to post on these generic accounts, also adapt their translations to be aligned with PCG wording. Move pcg_2962 from the companies chart file to the base French chart file, as 2962 is a general PCG account and not a company related one. Note: this is how things were already in 19.0 and this is how they should be, the changes happened by mistake as an unwanted side effect of commit 4f6068a6c88bf0530c19254df403e1194823b415 task-[6226138](https://www.odoo.com/odoo/project/967/tasks/6226138) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
v19 WIoT Boxes will be listening on localhost when updating to v19.1+, we need to ensure they use `http_interface = 0.0.0.0` after the update.
Original PR description
v19 WIoT Boxes will be listening on localhost when updating to v19.1+, we need to ensure they use `http_interface = 0.0.0.0` after the update.
Modified `SampleServer._mockWebReadGroup` to intercept `groupby_read_specification`. It now dynamically fetches the requested related fields using `_mockWebSearchReadUnity` and safely injects them into the `__values` payload for each mock group, perfectly mirroring the standard ORM behavior. Task: [6307582](https://www.odoo.com/odoo/project/133/tasks/6307582) Forward-Port-Of: odoo/odoo#272135
Original PR description
Modified `SampleServer._mockWebReadGroup` to intercept `groupby_read_specification`. It now dynamically fetches the requested related fields using `_mockWebSearchReadUnity` and safely injects them into the `__values` payload for each mock group, perfectly mirroring the standard ORM behavior. Task: [6307582](https://www.odoo.com/odoo/project/133/tasks/6307582) Forward-Port-Of: odoo/odoo#272135
**Steps to reproduce:** 1. Install Sales and EasyPost modules and enable delivery methods in the Settings. 2. Configure a new delivery method in [Sales -> Configuration -> Delivery Methods], choose provider as EasyPost and set the API keys. 3. Set any margin % on the delivery method. 4. Add the shipping line to a sale order via "Add shipping". **Issue:** Unit Price displays at a 4dp precision while Subtotal correctly displays at a 2dp precision **Why this happens:** `_apply_margins(
Original PR description
**Steps to reproduce:** 1. Install Sales and EasyPost modules and enable delivery methods in the Settings. 2. Configure a new delivery method in [Sales -> Configuration -> Delivery Methods], choose provider as EasyPost and set the API keys. 3. Set any margin % on the delivery method. 4. Add the shipping line to a sale order via "Add shipping". **Issue:** Unit Price displays at a 4dp precision while Subtotal correctly displays at a 2dp precision **Why this happens:** `_apply_margins()` returns a float from margin arithmetic calculation with no currency rounding applied. `rate_shipment()` writes this unrounded value directly to res['price'], which becomes the delivery line's price_unit. opw-6355318 Forward-Port-Of: odoo/odoo#275233
**Steps to reproduce:** - create storable avco product - set the cost to 10 - set an onhand quantity of 100 in WH/stock - create another warehouse (if you don't already have another one) - create an internal transfer from WH/Stock to WH2 - open the 'stock' view - click on inventory at date - confirm **Current behavior:** the total value is 11.000 **Expected behavior:** total value should be 10.000 **Cause of the issue:** To compute the total_value of the product, _co
Original PR description
**Steps to reproduce:** - create storable avco product - set the cost to 10 - set an onhand quantity of 100 in WH/stock - create another warehouse (if you don't already have another one) - create an…
**Steps to reproduce:** - create storable avco product - set the cost to 10 - set an onhand quantity of 100 in WH/stock - create another warehouse (if you don't already have another one) - create an internal transfer from WH/Stock to WH2 - open the 'stock' view - click on inventory at date - confirm **Current behavior:** the total value is 11.000 **Expected behavior:** total value should be 10.000 **Cause of the issue:** To compute the total_value of the product, _compute_value calls _run_average_batch https://github.com/odoo/odoo/blob/68f258e99f42693131a5309b3606c3b95f93d824/addons/stock_account/models/product.py#L260 Inside run_average_batch we need the qty_available at the time of last manual value (which is when we set the cost to 10 manually) in order to value all this quantity at the value of the manual value. https://github.com/odoo/odoo/blob/68f258e99f42693131a5309b3606c3b95f93d824/addons/stock_account/models/product.py#L435 This qty should be 0 cause we had no onhand quantity when we set the cost to 10. But it's actually going to be 10, here is why : Inside _compute_quantities_dict, because we're asking for a quantity in the past, the computation is current quantity - quantities that went in between the date in the past and now + quantities that went out between the date in the past and now. https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/product.py#L255 So we should have : 100 - 100 (moves_in_res_past) + 0 (moves_out_res_past) = 0 because we have 100 now and between the date we're asking for (the time of the manual value) and now there is one move in (when we set a quantity of 100) and no move out. But moves_out_res_past will actually be 10 for our product instead of 0. That's because in the read_group, our internal move will be considered as a move out and be taken into account https://github.com/odoo/odoo/blob/60cf607d7148ebe389cc8513aa3b82e156cd4400/addons/stock/models/product.py#L233-L234 That's because: When we called _run_average_batch from _compute_value, we called it on 'products_to_value', which is based on 'products', which was computed calling with_valuation_context() https://github.com/odoo/odoo/blob/60cf607d7148ebe389cc8513aa3b82e156cd4400/addons/stock_account/models/product.py#L206 which passes the valued internal location in the context https://github.com/odoo/odoo/blob/60cf607d7148ebe389cc8513aa3b82e156cd4400/addons/stock_account/models/product.py#L366-L370 As wh2 is not internal (it's a view) it's not included in the locations from the context. strict is also set to True Therefore at the beginning of compute_quantities_dict, when we call _get_domain_location to compute domain_move_out_loc (on which domain_move_out_done will be based), https://github.com/odoo/odoo/blob/60cf607d7148ebe389cc8513aa3b82e156cd4400/addons/stock/models/product.py#L165 inside _get_domain_location, because a location is given in the context that's the one we're going to use. https://github.com/odoo/odoo/blob/60cf607d7148ebe389cc8513aa3b82e156cd4400/addons/stock/models/product.py#L365 and because strict is in the context, dest_location_domain_out will be "location_dest_id not in [the list of valued location which does not include wh2]". https://github.com/odoo/odoo/blob/7e95d32d669a7ee7c50b5e665697cb577be0af93/addons/stock/models/product.py#L402-L405 And back in compute_quantities_dict(), domain_move_out_loc will be "location_id in [the list of valued location] and location_dest_id not in [the list of valued location]". Our internal move will therefore be considered as an out move and taken into account in the computation mentioned above. Which explains why quantity will be 10 inside run_average_batch and why the computation of total_value is wrong **fix:** in 19.0 the fix is in the xml to take less risk with regards to stable policy, however starting from 19.1 the fix will be in python opw-6321636 Forward-Port-Of: odoo/odoo#273388
**Steps to reproduce:** 1. Go to Website > Edit a page. 2. Add multiple Badges side by side. 3. Save the page. 4. Switch the website language, click on Edit/Translate and translate the badges. 5. Save. **Issue:** After saving in translate mode, all badge elements are merged into one. **Why this happens:** During save, `cleanForSave` triggers `mergeAdjacentInlines` on a detached clone of the dirty element. This clone lacks all the css styling, so `getComputedStyle` returns `""` f
Original PR description
**Steps to reproduce:** 1. Go to Website > Edit a page. 2. Add multiple Badges side by side. 3. Save the page. 4. Switch the website language, click on Edit/Translate and translate the badges. 5.…
**Steps to reproduce:** 1. Go to Website > Edit a page. 2. Add multiple Badges side by side. 3. Save the page. 4. Switch the website language, click on Edit/Translate and translate the badges. 5. Save. **Issue:** After saving in translate mode, all badge elements are merged into one. **Why this happens:** During save, `cleanForSave` triggers `mergeAdjacentInlines` on a detached clone of the dirty element. This clone lacks all the css styling, so `getComputedStyle` returns `""` for all padding/margin on detached nodes. Consequently, `areSimilarElements` incorrectly considers sibling `s_badge` spans as identical and merges them. A recent fix (https://github.com/odoo/odoo/commit/91972ec2bbd85f9cfd7a1af794bbb2385a312f30) applied to `BadgeOptionPlugin` registers `s_badge` as unsplittable via `unsplittable_node_predicates`, preventing the merge in normal edit mode. However, translate mode loads a separate plugin, `BadgeTranslationPlugin`, which was added in the commit https://github.com/odoo/odoo/commit/cbb2eb2edfeecbc21a70c1a3cba81ad0a7ac9c75 that lacks the same predicate. opw-6261146 Forward-Port-Of: odoo/odoo#276040 Forward-Port-Of: odoo/odoo#273986
The "Opening thread with needaction messages should mark all messages of thread as read" test opens a channel that holds an inbox (needaction) message and asserts mark_all_as_read is sent. Two flows can mark that message as read: the channel messages fetch, through set_message_done, and mark_all_as_read, sent by markAsRead when the channel gets focused on open. When the self member's new_message_separator is 0, opening the channel fetches its messages around 0, and that fetch marks the messag
Original PR description
The "Opening thread with needaction messages should mark all messages of thread as read" test opens a channel that holds an inbox (needaction) message and asserts mark_all_as_read is sent. Two flows can mark that message as read: the channel messages fetch, through set_message_done, and mark_all_as_read, sent by markAsRead when the channel gets focused on open. When the self member's new_message_separator is 0, opening the channel fetches its messages around 0, and that fetch marks the message as read and drops the needaction counter to 0 before markAsRead runs. mark_all_as_read is then skipped and the step assertion receives nothing. Give the member a non-zero separator (the pre-existing message is already read) so opening the channel no longer fetches around 0, leaving mark_all_as_read as the flow that marks the inbox message read. https://runbot.odoo.com/odoo/error/243651 Forward-Port-Of: odoo/odoo#276181
## Steps to reproduce: - Install sale_timesheet - Create a timesheet with a Sale order item linked to it - Change the sale order item on that timesheet - Change the project linked to the timesheet to a non-billable project - Notice the sale order item still linked to the timesheet ## Cause: When computing the so_line we filter out the records that has is_so_line_edited as true, so when changing the SOL before changing the project we don't reset so_line field when setting a non-bill
Original PR description
## Steps to reproduce: - Install sale_timesheet - Create a timesheet with a Sale order item linked to it - Change the sale order item on that timesheet - Change the project linked to the timesheet to a non-billable project - Notice the sale order item still linked to the timesheet ## Cause: When computing the so_line we filter out the records that has is_so_line_edited as true, so when changing the SOL before changing the project we don't reset so_line field when setting a non-billable project. ## Fix: We reset the is_so_line_edited field to false when changing the project to a non-billable one. opw-6311549 Forward-Port-Of: odoo/odoo#275919
Klipy requires attribution with "Search KLIPY" as the default placeholder [1]. This commit complies these guidelines. [1]: https://docs.klipy.com/attribution Forward-Port-Of: odoo/odoo#275995 Forward-Port-Of: odoo/odoo#275677
Original PR description
Klipy requires attribution with "Search KLIPY" as the default placeholder [1]. This commit complies these guidelines. [1]: https://docs.klipy.com/attribution Forward-Port-Of: odoo/odoo#275995 Forward-Port-Of: odoo/odoo#275677
When multiple invoices were sent to MyInvois in a single batch and at least one document failed validation, the failure branch of _myinvois_submit_documents added self.invoice_ids (all invoices in the batch) to invoice_to_cancel instead of the current record's invoices. Every sibling in the batch was then cancelled locally, even those whose own MyInvois submission had been accepted and moved to in_progress. The account.move ended up in state 'cancel' while its myinvois.document stayed 'valid'
Original PR description
When multiple invoices were sent to MyInvois in a single batch and at least one document failed validation, the failure branch of _myinvois_submit_documents added self.invoice_ids (all invoices in the batch) to invoice_to_cancel instead of the current record's invoices. Every sibling in the batch was then cancelled locally, even those whose own MyInvois submission had been accepted and moved to in_progress. The account.move ended up in state 'cancel' while its myinvois.document stayed 'valid', which violates the intended synchronization between the two records and blocked users from posting the credit note. Scope the cancellation to record.invoice_ids so only the invoice tied to the failing document is cancelled. 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 Forward-Port-Of: odoo/odoo#274727
When creating an event in Odoo and syncing it to Outlook, the event appeared in the correct slot on Outlook's calendar grid, but its detail panel showed start/end times labelled as UTC, causing a mismatch between the user's wall-clock time and what was displayed in Microsoft Outlook. The sync now sends the event in the organizer's local timezone with a matching timezone label, so Outlook displays the same wall-clock time and timezone that was entered. task-6167258 Description of the issue/
Original PR description
When creating an event in Odoo and syncing it to Outlook, the event appeared in the correct slot on Outlook's calendar grid, but its detail panel showed start/end times labelled as UTC, causing a mismatch between the user's wall-clock time and what was displayed in Microsoft Outlook. The sync now sends the event in the organizer's local timezone with a matching timezone label, so Outlook displays the same wall-clock time and timezone that was entered. task-6167258 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 Forward-Port-Of: odoo/odoo#262488
This update clarifies the terminology used in Odoo's overtime reporting by renaming confusing labels like 'Difference' and 'Balance' to 'Worked Extra Hours' and 'Validated Extra Hours'. This change ensures consistent and understandable reporting across all views, improving accuracy and ease of use for HR teams.
Original PR description
The reporting labels "Difference" and "Balance" are confusing because "Difference" tracks system-qualified overtime while "Balance" represents accepted overtime hours. There is also a lack of consistency across views. This commit renames these fields to "Worked Extra Hours" and "Validated Extra Hours" to harmonize the naming everywhere task-6352142 Description of the issue/feature this PR addresses: Confusing and inconsistent naming for extra hours Current behavior before PR: - Reporting uses "Difference" and "Balance". - Views use inconsistent labels. Desired behavior after PR is merged: Labels are consistently named "Worked Extra Hours" and "Validated Extra Hours" everywhere. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275944 Forward-Port-Of: odoo/odoo#273631
Miscellaneous changes
During the _run_average_batch(), we call _get_value() on each dropship move on which an AVCO product is used. In this function, if the following condition is met, we call the function _get_manual_value(): https://github.com/odoo/odoo/blob/12dd03fb678870ddd3f1f8dca66aa3f934aa7985/addons/stock_account/models/stock_move.py#L359-L361 This method's goal is to search product.value records related to the current move. https://github.com/odoo/odoo/blob/12dd03fb678870ddd3f1f8dca66aa3f934aa7985/a
Original PR description
During the _run_average_batch(), we call _get_value() on each dropship move on which an AVCO product is used. In this function, if the following condition is met, we call the function…
During the _run_average_batch(), we call _get_value() on each dropship move on which an AVCO product is used. In this function, if the following condition is met, we call the function _get_manual_value(): https://github.com/odoo/odoo/blob/12dd03fb678870ddd3f1f8dca66aa3f934aa7985/addons/stock_account/models/stock_move.py#L359-L361 This method's goal is to search product.value records related to the current move. https://github.com/odoo/odoo/blob/12dd03fb678870ddd3f1f8dca66aa3f934aa7985/addons/stock_account/models/stock_move.py#L431-L447 This search is performed once per move selected previously even if they are not related to any product.value. We propose to cache the id of every move that is linked to at least one product.value to ensure the search method is only performed for those and potentially reduce the number of calls to the search method. Benchmark ------------ Reducing the execution time with this modification supposes that the majority of stock.move records are not linked to any product.value, which is usually the case. The following benchmark shows the execution times of _run_average_batch() depending on that. | No stock.move | No of moves linked to product.value | Before PR | After PR | |---------------|-------------------------------------|-----------|----------| | 100 | 10 | 1.03 s | 421 ms | | 1000 | 100 | 7.13 s | 1.14 s | | 10000 | 100 | 57.21 s | 1.55 s | | 10000 | 1000 | 60.42 s | 8.98 s | When every stock.move is linked to a product.value, the modification will introduce more operations than needed and slow down the execution. The following benchmark illustrates that. | No stock.move | Before PR | After PR | |---------------|-----------|----------| | 100 | 1.14 s | 1.15 s | | 1000 | 8.21 s | 8.37 s | | 10000 | 80.64 s | 81.51 s | opw-6050007 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257619
This reverts commit 787223c. In the point of sale, concurrent sales of the same product can happen, e.g. if several physical points of sales are open at the same time, each with their own session. In the case where the underlying product's valuation is tracked automatically and perpetually, the creation of the pos order leads to the creation of the stock picking, which in turn leads to a search for the next available svl. Because of the flush_all, this can cause lots of retry failures and ass
Original PR description
This reverts commit 787223c. In the point of sale, concurrent sales of the same product can happen, e.g. if several physical points of sales are open at the same time, each with their own session. In the case where the underlying product's valuation is tracked automatically and perpetually, the creation of the pos order leads to the creation of the stock picking, which in turn leads to a search for the next available svl. Because of the flush_all, this can cause lots of retry failures and associated delay/latency/overall perceived slowness for the end user. opw-6206709 Forward-Port-Of: odoo/odoo#275264