Tuesday, January 20, 2026
22 changes · 19.0
New functionality added to Odoo
This update adds comprehensive tests for the new sections and combo products widgets within Odoo. These tests ensure correct functionality regarding hidden sections, drag-and-drop behavior, and optional product logic, enhancing the reliability and accuracy of sales order management.
Original PR description
This PR adds the missing tests for the newly introduced behavior in **sections** and **combo products** widgets. HOOT Tests * **Sections widget (account & sale)** * Validate *Hide Composition* and…
This PR adds the missing tests for the newly introduced behavior in **sections** and **combo products** widgets.
HOOT Tests
* **Sections widget (account & sale)**
* Validate *Hide Composition* and *Hide Prices* actions.
* Ensure duplicating a section also duplicates its invisible `collapse_` fields.
* Confirm drag-and-drop under hidden sections resets `collapse_` values for subsections.
* **Combo products and Optional Sections(sale)**
* Support moving combo lines Up/Down.
* Validate optional product logic.
* Drag-and-drop behavior:
* Moving a product line under an optional section → quantity set to `0`.
* Moving it out of an optional section → quantity set to `1` if previously `0`.
* Moving a subsection under an optional section → resets `collapse_` fields.
Python Tests
* Validate `parent_id` compute logic.
* Test utility methods used in portal and report for Sales Orders with sections.
task-5083152
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prEnhancements to existing features
This update improves the accuracy of Ecuadorian accounting by streamlining expense account categories and adding support for 8% VAT. Specifically, redundant expense groups have been consolidated, and expense accounts like salaries and wages are now automatically closed at the end of each accounting period, reducing reconciliation efforts.
Original PR description
Improve the distribution of expense and cost of revenue accounts in Ecuadorian localization We avoided not creating subcategories of expenses by eliminating the group called "Other employee benefit plan expense", which generated duplicity in the accounts. We fixed this by merging the accounts into the main "Employee benefit plan expense" group. Additionally, the account "Other employee benefits' was added to record any other benefits granted directly by the Ecuadorian companies. This ensures a better organization of the accounting setup. Mark as non-reconcilable the expense accounts (salaries and wages, travel expenses, contributions, etc) to avoid unnecessary reconciliation processes, these accounts are income statements and they are not accounts payable/receivable, therefore, they are closed at the end of the accounting period ### opw-4846355 Forward-Port-Of: odoo/odoo#208047
Resolved issues and error corrections
This update resolves an issue where the final chatbot answer wasn't saved or shown in the side panel. The fix ensures the backend route is triggered, the user's answer is correctly recorded, and the chat session is properly closed, improving the user experience.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ When reaching the last chatbot step, the frontend stopped before calling `/chatbot/step/trigger` due…
**Description of the issue this PR addresses:** ------------------------------------------------ When reaching the last chatbot step, the frontend stopped before calling `/chatbot/step/trigger` due to the `isLast` check in `_goToNextStep()`. As a result, `_process_answer()` was not executed, and the user's final answer was not saved, which resulted in the `rawAnswer` field remaining empty and the answer not appearing in the side panel. The chat session was also not marked as closed since the backend route was never called. **Current behavior before PR:** --------------------------------- - The final chatbot answer is not visible in the side panel - The chat session remains open after the final step **Desired behavior after PR is merged:** ----------------------------------------- - The final chatbot answer is saved and displayed in the side panel - The backend route is triggered for the last step - The chat session is properly marked as closed **Task:** 5172125 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235102
This update enhances the payment process for self-order kiosks by utilizing a new IoT protocol. It centralizes payment requests through a more reliable HTTP service, streamlining transactions and improving kiosk functionality. This change focuses on stability and efficiency for self-service ordering.
Original PR description
We now use the `iot_http` service to handle all IoT available protocols to send payment requests.
This update fixes an issue where foreign currency rates weren't correctly applied when generating Datev CSV reports. Now, the system accurately reflects the foreign currency rates set on invoices, ensuring accurate reporting for our German clients. This improves the reliability of financial data exported to Datev.
Original PR description
When we set the foreign currency rate on invoices, it won't be used when exporting the report. Make sure to use the correct currency rate. task-5404816 Forward-Port-Of: odoo/enterprise#101910
This update fixes an issue where foreign currency rates weren't correctly applied during Datev CSV exports. Now, invoices with foreign currency settings will accurately reflect the correct exchange rates in the exported reports, ensuring data consistency for financial reporting. This resolves a potential discrepancy in data accuracy.
Original PR description
When we set the foreign currency rate on invoices, it won't be used when exporting the report. Make sure to use the correct currency rate. task-5404816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239649
This update corrects a bug where repeatedly validating a stock transfer in the Barcode app could create duplicate stock entries, particularly with unreserved products. The fix ensures that the validation process is only executed once, preventing data inconsistencies and reducing potential errors. This improves the reliability of transfer processing.
Original PR description
**Problem:** When processing a picking in Barcode, it's possible to press the validate button or scan the validate barcode multiple times before the transfer validates or raises an error. This is…
**Problem:**
When processing a picking in Barcode, it's possible to press the validate button or scan the validate barcode multiple times before the transfer validates or raises an error. This is especially a problem when unreserved products are added to a transfer, since each additional validate call will duplicate those products (and their lot/SNs).
**Steps to Reproduce:**
- In the Barcode app, create a new internal transfer
- Scan a product, then scan the destination location 'WH/Stock/Shelf 1' ('2601892' is the barcode)
- Click the "Validate" button (or scan 'O-BTN.validate') multiple times as quickly as possible
- See that the "The transfer has been validated" toast appears (and possibly warnings about validating a done transfer) -> On the transfer, see that there are duplicated stock.move and stock.move.line
**Fix:**
Prevents the 'validate' method from executing as usual by checking if a previous call is still executing (tracked by 'isValidate').
opw-4948696
Forward-Port-Of: odoo/enterprise#102465
Forward-Port-Of: odoo/enterprise#95329This update fixes an issue preventing QR code generation for invoices when using automated workflows. The change allows QR codes to be created without requiring a direct HTTP request, ensuring invoices with payment links are generated correctly. This improves the functionality of invoice automation.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. In Accounting/Invoicing settings, enable "Add QR-code link on PDF"; 2. create an automation rule for the `account.move` model; 3. set "Trigger" to…
Versions
--------
- saas-18.3+
Steps
-----
1. In Accounting/Invoicing settings, enable "Add QR-code link on PDF";
2. create an automation rule for the `account.move` model;
3. set "Trigger" to "Create & Edit";
4. set "Apply on" domain to `[("state", "=", "posted")]`;
5. set "When updating" to "Status";
6. add an action to execute the following code:
```python
env['account.move.send']._generate_and_send_invoices(records)
```
7. call `action_post` on an invoice via RPC or Odoo Shell.
Issue
-----
> odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
> RuntimeError: object is not bound
Cause
-----
In order to add a payment link QR code to the invoice[^1], it needs to generate an access token for the portal. This happens via the `generate_access_token` function from `odoo.addons.payment.utils`. Issue is that it relies on having access to a `odoo.http.request` object, so that it can use its `env` to retrieve the `database.secret` config parameter.
When this flow gets triggered via an API call (or Odoo Shell), the `request` object is unbound, causing the error.
[^1]: feature added via commit bcb73cd159885
Solution
--------
Introduce an optional `env` kwarg to `generate_access_token`, falling back on `request.env` if it's not provided.
opw-5487075
Forward-Port-Of: odoo/odoo#243528This update resolves a bug in the website builder that caused a crash when users modified shadow settings beyond the standard options. The fix ensures the system gracefully handles custom shadow definitions, preventing errors and maintaining builder functionality. This improves the stability and usability of the website builder for all users.
Original PR description
Forward-Port-Of: odoo/odoo#244244
An error occurred when editing event details (address or organizer) within the event editor. This issue was caused by a problem with how many2one fields were being searched. The team has reverted a recent change to restore the original functionality, ensuring event editing works correctly.
Original PR description
Currently, Editing the address or organizer on an event page currently triggers an error. steps to reproduce: 1) Install `website_event` module 2) Login as admin and create one event click on `Go to…
Currently, Editing the address or organizer on an event page currently triggers an error.
steps to reproduce:
1) Install `website_event` module
2) Login as admin and create one event click on `Go to Website` smart button.
3) Switch to Editor mode> Click on `My Company` under Organizers
(also works with Location).
4) on the right side bar click on `Contact drop-down`
Error:
`ValueError: Domain() invalid item in domain: ')'`
Root Cause:
after [this commit](https://github.com/odoo/odoo/pull/219810/commits/221127900bb6f72bf00715ff90727a87ef5d982c), the domain for many2one fields was fetched from the backend. In this case, the domain received looks like:
```
'(company_id and ['|', ('company_id', '=', False), ('company_id', 'parent_of',
[company_id])] or ['|', ('company_id', '=', False), ('company_id', 'parent_of', '')]) + ([])'
```
At [1], this domain is passed to `search`, and `Object.values` turns it into an array of single-character strings. Passing this array to `name_search` causes the error.
FIX:
Revert the changes from PR https://github.com/odoo/odoo/pull/219810. as the original purpose of that PR is still met without them.
[1]- https://github.com/odoo/odoo/blob/12ec5d2d9cd93fffb10bf10326cf3cde7707ea0c/addons/html_builder/static/src/core/building_blocks/select_many2x.js#L101-L112
sentry-6916986959This update resolves an issue where the system incorrectly set a tax calculation flag when ‘price include’ was enabled. Removing the automatic setting prevents inaccurate downstream calculations and simplifies tax implementation for users. This ensures tax amounts are calculated correctly based on the intended pricing model.
Original PR description
Removed the onchange method because it automatically sets include_base_amount to True whenever price_include is enabled. This triggers incorrect downstream calculations. By removing it, we prevent the system from forcing this setting, which previously required the user to remember to manually uncheck the field during tax implementation.
This update resolves an issue where users with limited inventory access were prevented from completing dropshipping orders. The fix adds necessary permissions to correctly calculate product costs during the order validation process, ensuring dropshipping orders can be successfully processed.
Original PR description
Steps to Reproduce 1. Create a database in Odoo 19.0 with the stock_account module installed. 2. Enable Dropshipping from Inventory → Settings. 3. Create a product with a category whose Cost Method…
Steps to Reproduce 1. Create a database in Odoo 19.0 with the stock_account module installed. 2. Enable Dropshipping from Inventory → Settings. 3. Create a product with a category whose Cost Method is set to Average Cost (AVCO). 4. Create a user with Inventory / User access rights only (no Inventory Administrator rights). 5. Create a dropship order using the product and validate the picking. ``` You are not allowed to access 'Product Value' (product.value) records. This operation is allowed for the following groups: - Inventory/Administrator Contact your administrator to request access if necessary. ``` Issue:- During picking validation, moves are getting [done](https://github.com/odoo/odoo/blame/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock/models/stock_picking.py#L1265) if move is is_dropship enable which lead to [update_standard_price]( https://github.com/odoo/odoo/blob/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock_account/models/stock_move.py#L169) if product cost_method is [avco.](https://github.com/odoo/odoo/blob/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock_account/models/product.py#L462-L476) So, it call run_avco during that getting [the _get_manual_value]( https://github.com/odoo/odoo/blob/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/stock_account/models/stock_move.py#L409) it through access error Fix:- To fix this sudo is added during getting _run_avco opw-5431121 upg-3762999 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where grouping accounting records by their root account was failing, resulting in an error. The change allows for optimized domain searches, ensuring that grouped record sets display the expected nested data. This improves the accuracy and usability of reporting and analysis within the accounting module.
Original PR description
Access records in a grouped by `account_root` list failed, showing an error message:
Unsupported operator on Root 'Account' (account.account) in [('root_id', 'any', [('display_name', 'in', [10])])]
Step to reproduce:
- New DB with `accountant` module
- Accounting -> Chart of accounts
- Group By "Root"
- Open any grouped record set
When opening the record set, Odoo fetches data using the domain `[('id', '=', '10')]`
The domain goes through optimization as follows:
```
[('id', '=', '10')]
basic : [('id', 'in', ['10'])]
full : [('root_id', 'any', [('display_name', 'in', [10])])]
```
However, the `_search_account_root` method protects the technical field `account_root`.
This commit adapts it to allow full optimized domain search and solving the error.
Ticket [link](https://www.odoo.com/odoo/project.task/5178896)
opw-5178896
Forward-Port-Of: odoo/odoo#238841This update resolves a compatibility problem between shipping carriers and shipping partners within the Odoo website's sales functionality. Previously, certain carriers weren't correctly recognized, leading to potential errors during order processing. This change ensures all carriers work seamlessly with shipping partners, improving order accuracy and reliability.
Original PR description
Forward-Port-Of: odoo/odoo#244300 Forward-Port-Of: odoo/odoo#244035
This update fixes an issue where the default identification type (VAT) was incorrectly applied to new contacts, regardless of the company's location. Now, the identification type automatically adjusts to the correct format (e.g., CUIT for Argentina, RUT for Uruguay) based on the selected company, ensuring accurate data and a better user experience.
Original PR description
When the country of a partner is changed, the identification type should be updated accordingly. This ensures that the identification type remains consistent with the partner's country, improving…
When the country of a partner is changed, the identification type should be updated accordingly. This ensures that the identification type remains consistent with the partner's country, improving data integrity and user experience. Description of the issue/feature this PR addresses: When creating a new contact, the field `l10n_latam_identification_type_id` (Identification Type) defaults to 'VAT' regardless of the active company. This PR ensures that the default identification type dynamically changes based on the selected company. For instance, it should automatically set to 'CUIT' for Argentinian companies or 'RUT' for Uruguayan companies. Current behavior before PR: The value 'VAT' is hardcoded as the default for the `l10n_latam_identification_type_id` field, regardless of the country or localization of the current company. Desired behavior after PR is merged: The `l10n_latam_identification_type_id` field should be updated via an onchange method to reflect the appropriate identification type according to the current company's localization. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug where users were getting stuck in the Point of Sale system due to IoT actions being ignored. The change ensures that actions are correctly processed, even when orders are cancelled, by using a data hash instead of a fixed UUID to identify actions.
Original PR description
This PR fixes the user getting stuck on the point of sale if some actions are being ignored by the iot box because these are considered as already executed. Currently the uuid asigned to an action doesn't change if an order is being cancelled so the iot box will systematically ignore the cancellation of pos orders if they were sent to the preparation printer before. This PR fixes this issue by instead using a hash of the data used to generate the receipt as a uuid of an action. If anything in the data changed the iot box will not ignore such actions anymore Community: https://github.com/odoo/odoo/pull/243822
This update resolves an issue where the payer company was incorrectly identified in the 1099 report when generating reports across multiple companies. The fix ensures that each 1099 line accurately reflects the correct payer company, improving the accuracy of tax reporting for businesses with multiple entities.
Original PR description
When generating 1099 report with multicompany setup, the payer company is wrongly assigned in the csv file. Steps: - Have 2 companies - Make one bill per company with one different 1099 vendor for each one - With both companies selected, generate the 1099 report - open the csv file -> Payer name is the same for both line opw-5442190 Forward-Port-Of: odoo/enterprise#104660 Forward-Port-Of: odoo/enterprise#103805
This update fixes an issue where changing the rental period of an order didn't automatically update the associated rental transfers. The fix mimics the rescheduling behavior of purchase orders, ensuring that rental transfers are accurately adjusted when the rental period is modified. This improves the reliability of rental order management.
Original PR description
### Steps to reproduce: - In the settings enable "Rental Transfers" - Create a storable and rentable product P - Create and confirm a rental order for 1 unit of P - Change the rental period to 10 days in the future #### > The rental tranfers were not updated accordingly ### Cause of the issue: Nothing is currently implemented to reschedule the rental transfers. ### Fix: We somewhat mimic the reschedule purchase behavior: https://github.com/odoo/odoo/blob/6ca34a0f5347e0611cde95453119dda8b40fa589/addons/purchase_stock/models/purchase_order_line.py#L98-L101 But we rely on the order itself rather than its order lines since the `start_date` and the `return_date` are related fields so that no `write` is triggered when the order is rescheduled: https://github.com/odoo/enterprise/blob/96a80f583a0ca502ff06bc05d03775c76c6a7537/sale_renting/models/sale_order_line.py#L18-L19 opw-5158508 Forward-Port-Of: odoo/enterprise#102437 Forward-Port-Of: odoo/enterprise#101334
This update resolves an issue where combo choices weren't displaying correctly in the self-order and kiosk modes. Previously, users had to reconfigure combo choices after setting a product variant. This change ensures combo choices are displayed correctly without requiring manual reconfigurations, improving the self-order experience.
Original PR description
Before the fix, when we set a product variant as combo choice. In self/kiosk, we'll see the product template instead of the product itself. And we need to configure it again. It occured because for all of the products in the kiosk/self, we display the product template. The expected behavior if we set a product variant as combo choice is to have the product variant in the combo directly without having to reconfigure it. The bug occurs only since 19.0 because a fix was already done from 18.3 to 18.4 in this pr : #219908 but the fwport for 19.0 has never been merged. task: 5493798 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an error in the Point of Sale order report that incorrectly calculated margins for refunded orders. The fix ensures that refunds are properly accounted for, displaying accurate margins based on order value, improving reporting accuracy for financial analysis.
Original PR description
Step To Reproduce: - have a product with cost price - settle a order in pos with that product and refund it - go to reporting > orders > pivot view - check margin for that refund order Observation: - the margin is calculated wrong, as we do not consider order sign - as `margin = price_subtotal - total_cost` - so with price_subtotal `200` and total_cost `-100` margin becomes 300 Fix: - consider order sign i.e. -ve for refund order else +ve for `price_subtotal` - so with price_subtotal `-200` and total_cost `-100` margin becomes -100 **Before** <img width="317" alt="image" src="https://github.com/user-attachments/assets/9e23bc1c-363a-44dd-83c0-da478d9c73d0" /> **After:** <img width="343" alt="image" src="https://github.com/user-attachments/assets/56027cb4-a6c2-4b73-8db8-393e5af0b057" /> Note: for this to be applied, app update is needed opw-5418964 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where overtime calculations were inaccurate when employees were on leave. Now, if an employee works on a day they are off, all hours worked are treated as overtime, excluding breaks. This ensures accurate overtime payments for all employees.
Original PR description
This PR aims to fix how the overtime is being calculated with quantity based rules : - The expected _hours didn't take into account the leaves of the day , so if the user was on a leave, it would considered him absent ( give him negative overtime) , because he has no attendances that day. - if the employee took a whole day off, and decided to work on it, all the hours should be considered as overtime, the brake shouldn't be included (ex : his normal work sched is morning (9h-12h) , break(12h-13h), afternoon(13-17h) , he's already getting paid for that time , so every single hour worked that day from 12am to 12 pm is added time , and there is no break in added time) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug where the partner ID wasn't consistently passed through the stock move creation process, specifically in multi-step delivery scenarios. The change ensures that the correct customer or supplier is associated with stock moves, resolving issues with order fulfillment. This impacts sales and purchase order processing.
Original PR description
*mrp{,_subcontracting_dropshipping}, point_of_sale, sale_purchase, {purchase_,sale_,}stock ### Issue: The partner_id (contact field) of stock move is no longer propagated in pull chain since the…
*mrp{,_subcontracting_dropshipping}, point_of_sale, sale_purchase, {purchase_,sale_,}stock
### Issue:
The partner_id (contact field) of stock move is no longer propagated in pull chain since the procurement/reference refactoring of 19.0 see 2713876dbc70d3984e584a9037a2206dcda4e84a
#### Steps to reproduce:
- In the settings enable Multi-Steps routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Set your warehouse in two step deliveries
- Modify the routes to have two pull rules: Stock -> Out -> Customer
- Create and confirm an SO, 1 unit of a storable product for a customer
#### > While the customer is set on the ship move and picking it is not on the pick move and picking.
### Cause of the issue:
Due to the configuration, the ship move is created by the `action_launch_stock_rule` and linked to the customer via the procurement created from the sale order line:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/sale_stock/models/sale_order_line.py#L295 Then, the confirmation of the ship move generates a second procurement for the pick move creation. Prior to 19.0, the partner_id of this second procurement was set to the customer via the procurement group: https://github.com/odoo/odoo/blob/712cd806c38e193acdb966e4d3b339ab780f158e/addons/stock/models/stock_rule.py#L333 However, since procurement groups have been removed by the reference refactor 2713876dbc70d3984e584a9037a2206dcda4e84a, the partner id is now expected to be set from the procurement values:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/stock/models/stock_rule.py#L332 As it is not set by any mean in this procurement values it will therefore not be propagated.
### Additional changes:
1. The `partner_id` of the procurement values needs to be harmonized are some methods set a recordset and others a record id:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/point_of_sale/models/pos_order.py#L1707
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/mrp_subcontracting_dropshipping/models/stock_orderpoint.py#L10-L13
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/sale_stock/models/sale_order_line.py#L295
The correct behavior is to set an id since the `partner_id` value of the procurement group is used in the `_get_stock_move_values` and written in its "raw state" as the `partner_id` values for the stock move for creation (when sale_stock is installed):
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/sale_stock/models/stock.py#L171-L174
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/stock/models/stock_rule.py#L378-L381
2. The `partner` key of the procurement values is set by to `partner_id` in every overrides but since 2713876dbc70d3984e584a9037a2206dcda4e84 was incorrectly cahnged to `partner`:
https://github.com/odoo/odoo/blob/4466a2684fd36ef3c9e1e7f7437ae48ff51f1941/addons/stock/models/stock_rule.py#L332
We change back this key to the expected `partner_id` and revert the associated pos fix 203f807a2b764821ec4673515dd29f392ec37b3a using the changed `_get_partner_id` method.
3. In certain use cases, such as inter-warehouse transfer the the `partner_id` should not be propagated by the pull chain as it is expected to be set by the `_get_stock_move_values`:
https://github.com/odoo/odoo/blob/df01277bc053218dda6157f2f0657432e91e1d58/addons/stock/models/stock_rule.py#L339-L346
4. Since the `partner_id` is used to set the `dest_address_id` here:
https://github.com/odoo/odoo/blob/92486bab9b73f4370629452c454c25371d5063ac/addons/purchase_stock/models/stock_rule.py#L350
But is suppose to be reset for non dropshipping use case:
https://github.com/odoo/odoo/blob/df01277bc053218dda6157f2f0657432e91e1d58/addons/purchase_stock/models/purchase_order.py#L80-L82
We need to modify the fix of 3fb81df557553d471ff72998200097b3a0ea666f in order for the value set by th epartner_id to be reset in case we are not in a dropshipping use case.
Similarly, we should only add the `partner_id` of the procurement value as a possible `dest_address_id` in the dropship use case:
https://github.com/odoo/odoo/blob/2c0c26e6cc61f70c91617617ef77f23cfaa1dde6/addons/mrp_subcontracting_dropshipping/models/stock_rule.py#L19-L23
5. Since we are setting a default falsy 'partner_id' values in the `_prepare_procurement_values` of stock moves (e.g.`self.partner_id.id`) we needed to slightly alter the `_prepare_purchase_order` of the `mrp_subcontracting_dropshipping` module so that it sets the partner of the subcontractor when the move sets it to `False` rather than unset:
https://github.com/odoo/odoo/blob/1ac7834a9b9d07760700f6d7c73dfe270a247752/addons/mrp_subcontracting_dropshipping/models/stock_rule.py#L10-L11
opw-5428063
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr