Product cards will no longer show a generic placeholder image when no product image has been uploaded. This keeps product lists cleaner and avoids drawing attention to missing images.

Previously done in commit 683deecb51e240c5cbf1fd369e0eeefb0267530d but reverted in the refactor done in commit 0279c53930735b65e9342ca66fbb62ff61ac65f6

Objective: hide placeholder images if no image is provided on product


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

The Field Service guided tour now properly highlights and explains the customer selection field. This helps users follow onboarding instructions without seeing a blank or misplaced tooltip.

Before this PR:
- The tour step for customer selection was skipped because the parent step triggered by `.o_field_widget[name=partner_id]` did not include a `run` action.
- As a result, the child step executed, showing an empty tooltip with incorrect positioning since it was missing both `content` and `position`.
- So, the customer selection step was not properly highlighted or explained.

After this PR:
- Added `content` and `position` attributes to the child step triggered by `.o_field_widget[name="partner_id"] input`, ensuring the tooltip appears with the correct message and placement.
- The step now properly displays the tooltip when the customer selection field is focused.

task-4159812

This fix ensures inter-company settings show the right warehouse and receipt options for the current company’s selected transaction flow. It helps businesses avoid incorrect purchase or sales order setup when companies trade with each other.

The meaning of inter-company transaction options (i.e. generate Purchase Order / Sale Order) changed in #55350, as they now indicate the opposite of what they used to (as they now take the PoV of the current company).

But the conditions of warehouse/receipt type options weren't adapted to the new meaning:
- `intercompany_receipt_type_id` is used to generate the purchase order triggered through `intercompany_generate_purchase_orders`.
- `intercompany_warehouse_id` is used to know from which warehouse to generate the sale order triggered trhough
`intercompany_generate_sale_orders`.

Task-4206898

Since #156437, the moves can have a final location representing their final endpoint. This causes some issues for inter-company transactions, as they are meant to deliver to/pick from the 'Inter-Company Transit' location. This means that for sale orders meant to other companies, they are always supposed to deliver their goods there: - Normal delivery: CompA/Stock -> ICT, ICT -> CompB/Stock - Dropship: CompA/Stock -> ICT, ICT -> Customer But this opens a few issues, as the compA SO's `par

Since #156437, the moves can have a final location representing their final endpoint. This causes some issues for inter-company transactions, as they are meant to deliver to/pick from the 'Inter-Company Transit' location.

This means that for sale orders meant to other companies, they are always supposed to deliver their goods there:
- Normal delivery: CompA/Stock -> ICT, ICT -> CompB/Stock
- Dropship: CompA/Stock -> ICT, ICT -> Customer

But this opens a few issues, as the compA SO's `partner_shipping_id` is the customer itself, meaning that the final location would end up as Customers, which we want to avoid.

Also, to accomodate both these cases, we need to add a bit complexity computation of the location_dest of a move. We consider that if the location_dest is Customers but its final is ICT, then we apply the ICT.

opw-4163612

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

Forward-Port-Of: odoo/odoo#179963

Problem: When creating a sale order without selecting a partner or if the partner has no language set, the note field displays the default terms in English, regardless of the user's language. It should display the note in the current user's language instead. Steps to reproduce: - Add default terms and conditions in both English and Arabic. - Change the user language to Arabic. - Create a new quotation without selecting a partner. - The note is displayed in English, but it should be in Ar

Problem:
When creating a sale order without selecting a partner or if the partner has no language set, the note field displays the default terms in English, regardless of the user's language. It should display the note in the current user's language instead.

Steps to reproduce:
- Add default terms and conditions in both English and Arabic.
- Change the user language to Arabic.
- Create a new quotation without selecting a partner.
- The note is displayed in English, but it should be in Arabic as per the user’s language while no partner selected yet.

opw-4176183

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

Forward-Port-Of: odoo/odoo#181185

In the multilevel dropdown, when the submenu dropdown is accessed within the parent dropdown, it closes the parent dropdown, making it inaccessible to the child dropdown menu. We don't want the BS dropdown to close when the sub dropdown is clicked Task-4037692 Forward-Port-Of: odoo/odoo#181541 Forward-Port-Of: odoo/odoo#173269

In the multilevel dropdown, when the submenu dropdown is accessed within the parent dropdown, it closes the parent dropdown, making it inaccessible to the child dropdown menu.
We don't want the BS dropdown to close when the sub dropdown is clicked

Task-4037692

Forward-Port-Of: odoo/odoo#181541
Forward-Port-Of: odoo/odoo#173269

In 17.0 the add a line of the res.partner.bank is no longer adding a line directly in the list view but opening a wizard. The xpath of the base_iban was no longer working like it should. task:4197710 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180865

In 17.0 the add a line of the res.partner.bank is no longer adding a line directly in the list view but opening a wizard.
The xpath of the base_iban was no longer working like it should.

task:4197710




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

Forward-Port-Of: odoo/odoo#180865

### Steps to reproduce: - Create a Helpdesk team with the options "Return" and "Repairs" - Create a product, sell 1 unit and deliver it. - Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket. - Create a repair order and mark it as done. #### > If you go back to the product return, the stock move of the original return appears twice. ### Cause of the Issue: Clicking on t

### Steps to reproduce:

- Create a Helpdesk team with the options "Return" and "Repairs"
- Create a product, sell 1 unit and deliver it.
- Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket.
- Create a repair order and mark it as done.

#### > If you go back to the product return, the stock move of the original return appears twice.

### Cause of the Issue:

Clicking on the `End Repair` button of the repair will call the `action_repair_end` with a `default_picking_id` equal to the `picking_id` of the `repair.order` in the context. However, during this call a stock move groing from repair location to the repair location will be created and mark as done for the final product to be assocaited with the repair order:
https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L379-L382 https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L417-L442 https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L444-L449 Since no `picking_id` is specified in its `move_vals`, the default `picking_id` (that is the return) will be added to the vals of the create here:
https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/odoo/models.py#L4564 So that the newly created move will be linked to the return move even thought this makes no sense.

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

Forward-Port-Of: odoo/odoo#180008

Current behaviour: --- When going to /customers or /partners and selecting a partner, in the References section, if the text is too long, the image will be taking the text height Expected behaviour: --- The image fits the width but not the height Steps to reproduce: --- 1. Go to Website 2. Go to /customers 3. Select a partner that has references 4. Open the editor (top left) 5. Add long text to one of the reference 6. The image will match the text height Cause of the issue:

Current behaviour:
---
When going to /customers or /partners and selecting a partner, 
in the References section, if the text is too long, the image will be taking the text height

Expected behaviour:
---
The image fits the width but not the height

Steps to reproduce:
---
1. Go to Website
2. Go to /customers
3. Select a partner that has references
4. Open the editor (top left)
5. Add long text to one of the reference
6. The image will match the text height

Cause of the issue:
---
Caused by: https://github.com/odoo/odoo/commit/1efdb96227dab8f1b3bcb8e8854dbad5dd874e69

Fix:
---
Removed h-100 and added w-100

opw-3970462

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

Forward-Port-Of: odoo/odoo#173363

This commit juste move the code from this PR https://github.com/odoo/odoo/pull/179107 from l10n_es_pos to l10n_es_edi_facturae. opw-4074779 Forward-Port-Of: odoo/odoo#181553

This commit juste move the code from this PR https://github.com/odoo/odoo/pull/179107
from l10n_es_pos to l10n_es_edi_facturae.

opw-4074779

Forward-Port-Of: odoo/odoo#181553

Issue: ===== Written html code inside the forum post gets rendered in the readonly view. Steps to reproduce the issue: ============================= - Create a new forum post - Write `<p>abc</p>` - Save - The `p` element disappears (it got rendered, you can check it by inspecting the element). Origin of the issue and solution: ================================= Let's first name the `p` element added by the editor as `pe` to differenciate between them. The issue is divided

Issue:
=====
Written html code inside the forum post gets rendered in the readonly
view.

Steps to reproduce the issue:
=============================
- Create a new forum post
- Write `<p>abc</p>`
- Save
- The `p` element disappears (it got rendered, you can check it by
  inspecting the element).

Origin of the issue and solution:
=================================

Let's first name the `p` element added by the editor as `pe` to
differenciate between them.

The issue is divided into 2 subproblems:

- We need to save the correct value: currently if we have written in the
  editor `<p>abc</p>`, it will save the value `<pe><p>abc</p></pe>`
  which means that the two `p` element will be handled the same either
  both will appear as a string in the readonly view or will be rendered
  which is not right. To solve the issue, we need to override the
  `value` of the text area and not the html before the submit. By
  doing this the textarea.value will be equal to
  `<pe>&lt;p&gt;abcdef&lt;/p&gt;</pe>` which is the correct value.

- Now the second problem is when we edit the post , it will render again
  the `p` element that we wrote. The fetched template actually have the
  correct value inside the textarea, but seems like the browser when
  rendering it, it will convert the value to `<pe><p>abd</p></pe>` which
  is not right, and if we use textarea.html it will encode the `<pe>`
  element which is wrong too. To get the original value, we fetch if
  again and use it in the options of the wysiwyg.

  opw-4148163

Forward-Port-Of: odoo/odoo#181357
Forward-Port-Of: odoo/odoo#179854

### Steps to reproduce: - Have two companies: COMP1, COMP2 - In the settings Enable Multi-step routes Prior to 17.2: - Inventory > Configuration > Warehouse Management > Locations - Unarchive: Virtual Locations/Inter-company transit and set is Return Locations - With COMP1: Create and confirm a PO with COMP2 as vendor for 10 units of a storable product - Validate the receipt and return. Select the Virtual Locations/Inter-company transit as return location and validate #### > On the POL

### Steps to reproduce:

- Have two companies: COMP1, COMP2
- In the settings Enable Multi-step routes Prior to 17.2:
- Inventory > Configuration > Warehouse Management > Locations
- Unarchive: Virtual Locations/Inter-company transit and set is Return Locations
- With COMP1: Create and confirm a PO with COMP2 as vendor for 10 units of a storable product
- Validate the receipt and return. Select the Virtual Locations/Inter-company transit as return location and validate
#### > On the POL the received quantity went from 10 to 20 rather than 0

### Note:

Starting from 17.2, the Inter-company transit location is the default location destination of the return rather than (Partner/Vendor). It also changed its reference to `stock_location_inter_company` so that the fix should be adapted in that version.

### Cause of the Issue:

Currently, the qty_received is computed with respect to moves linkes to the POL. However, a move is flagged as a return only if the usage of its destination supplier (dropshipping and subcontracting flow excluded): https://github.com/odoo/odoo/blob/f494496b5142af23ee46ce249a1063f9d6caf403/addons/purchase_stock/models/stock_move.py#L247-L249 and if it is not flagged a return, its quantity is counted positively rather than negatively in the received quantity:
https://github.com/odoo/odoo/blob/f494496b5142af23ee46ce249a1063f9d6caf403/addons/purchase_stock/models/purchase.py#L348-L370

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

Forward-Port-Of: odoo/odoo#181265
Forward-Port-Of: odoo/odoo#180846

Instead of only allowing selection by limited account type, the system allows selection by group. 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#181370 Forward-Port-Of: odoo/odoo#181327

Instead of only allowing selection by limited account type, the system allows selection by group.

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#181370
Forward-Port-Of: odoo/odoo#181327

Before this commit, if there was an issue with printing via an ePoS printer, the system did not allow for printing the receipt through the web as a fallback. This was due to the erroneous passing of the error object instead of the receipt content. opw-4209073 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181595

Before this commit, if there was an issue with printing via an ePoS printer, the system did not allow for printing the receipt through the web as a fallback. This was due to the erroneous passing of the error object instead of the receipt content.

opw-4209073

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

Forward-Port-Of: odoo/odoo#181595

Steps to reproduce: -go to shop -choose product which has multi option attribute -tick atleast one attribute -add to cart Issue: -multi option values are not visible in cart description in mobile view. Cause: -the issue caused due to use of d-none and d-md-block classes, due to this it will not show in small size devices. Fix: -replace d-none and d-md-block with empty string, so now the values will show for all devices. opw-3853263 --- I confirm I have signed the CLA a

Steps to reproduce:
-go to shop
-choose product which has multi option attribute
-tick atleast one attribute
-add to cart

Issue:
-multi option values are not visible in cart description in mobile view.

Cause:
-the issue caused due to use of d-none and d-md-block classes, due to this it
 will not show in small size devices.

Fix:
-replace d-none and d-md-block with empty string, so now the values will show for all
 devices.

opw-3853263

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

Forward-Port-Of: odoo/odoo#178308

Before this commit, the PoS would fail to load if an orderline contained a product that was not loaded into the PoS. This issue could arise, for example, when category restrictions are applied after creating draft orders, preventing the PoS from loading. opw-4119028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180434 Forward-Port-Of: odoo/odoo#180230

Before this commit, the PoS would fail to load if an orderline contained a product that was not loaded into the PoS. This issue could arise, for example, when category restrictions are applied after creating draft orders, preventing the PoS from loading.

opw-4119028

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

Forward-Port-Of: odoo/odoo#180434
Forward-Port-Of: odoo/odoo#180230

Previously, when SO confirmed the default project manager remain unset. This commit adapts the functionality of setting the project manager if the template is included otherwise the manager remains unset. task-3953729 Forward-Port-Of: odoo/odoo#181593

Previously, when SO confirmed the default project manager remain unset. This commit adapts the functionality of setting the project manager if the template is included otherwise the manager remains unset.

task-3953729

Forward-Port-Of: odoo/odoo#181593

Before this commit: - In the branch's TDS Entry wizard, In the journal field no journal is displayed. After this commit: - In the branch's TDS Entry wizard, In the journal field main company's journal should be displayed. - When a new branch is created, the TDS Journal from the main company should be automatically assigned to the branch. Task-4154543 Forward-Port-Of: odoo/odoo#178933

Before this commit:
- In the branch's TDS Entry wizard, In the journal field no journal is displayed.

After this commit:
- In the branch's TDS Entry wizard, In the journal field main company's journal should be displayed.
- When a new branch is created, the TDS Journal from the main company should be automatically assigned to the branch.

Task-4154543

Forward-Port-Of: odoo/odoo#178933

Before this commit, the "tour pointers" that indicated to users that they needed to scroll the "snippets modal" were misaligned. Their position did not account for the iframe offset of the modal. task-4072655 Forward-Port-Of: odoo/odoo#181146

Before this commit, the "tour pointers" that indicated to users that they needed to scroll the "snippets modal" were misaligned. Their position did not account for the iframe offset of the modal.

task-4072655

Forward-Port-Of: odoo/odoo#181146

Adds a test for the counterpart in community side. Checks that a delivery in the 'Inter-Company transit' location is properly shown as "delivered quantity" in the SO form. See odoo/odoo#181412 Task-4207132 Forward-Port-Of: odoo/enterprise#70663

Adds a test for the counterpart in community side. Checks that a delivery in the 'Inter-Company transit' location is properly shown as "delivered quantity" in the SO form.

See odoo/odoo#181412

Task-4207132

Forward-Port-Of: odoo/enterprise#70663

Fixes two uses cases: - Sale Order in Company A that dropships goods *stored* in Company B to the Customer. - Sale Order in Company A that dropships goods from company B to the Customer. But in company B, we also dropship from the vendor to the customer. In both cases, make sure to properly send goods to the Inter-Company Transit location for inter-co transactions, so that goods (and lot/serials) can be properly linked. opw-4163612 Forward-Port-Of: odoo/enterprise#69878

Fixes two uses cases:
- Sale Order in Company A that dropships goods *stored* in Company B to the Customer.
- Sale Order in Company A that dropships goods from company B to the Customer. But in company B, we also dropship from the vendor to the customer.

In both cases, make sure to properly send goods to the Inter-Company Transit location for inter-co transactions, so that goods (and lot/serials) can be properly linked.

opw-4163612

Forward-Port-Of: odoo/enterprise#69878

When validation an order in a Chilean shop, the date is not show on the receipt. Steps to reproduce: ------------------- * Change the company for the Chilean one **CL Company** * Go to the **Point of sale** App * Open shop session * Make and order and validate it > Observation: The date is not reported on the receipt Why the fix: ------------ Commit https://github.com/odoo/enterprise/commit/1ce4eaa025426354c640e6e6c69269b1e6b2c7d1 moved the date on receipt in the header for the chi

When validation an order in a Chilean shop, the date is not show on the receipt.

Steps to reproduce:
-------------------
* Change the company for the Chilean one **CL Company**
* Go to the **Point of sale** App
* Open shop session
* Make and order and validate it
> Observation: The date is not reported on the receipt

Why the fix:
------------
Commit https://github.com/odoo/enterprise/commit/1ce4eaa025426354c640e6e6c69269b1e6b2c7d1 moved the date on receipt in the header for the chilean localization.

Header uses the data from `props.headerData`
https://github.com/odoo/odoo/blob/5f748c9d5731fe2e7e519ee9625da25e2bb219bc/addons/point_of_sale/static/src/app/navbar/cash_move_popup/cash_move_receipt/cash_move_receipt.xml#L6

The date field in `headerData` is computed in `getReceiptHeaderData` https://github.com/odoo/enterprise/blob/923dfe962b714797ee41e8f7beed2cb2d6df7048/l10n_cl_edi_pos/static/src/overrides/models/pos_store.js#L48

However, this commit https://github.com/odoo/odoo/commit/5cb7639160cef5401ada8cdde5a5522d8d29c9a9 removed the field `receiptDate` on the pos order. We thus use the same logic to set the date in `headerData`.

opw-4136943

Forward-Port-Of: odoo/enterprise#70131

Steps to reproduce: - Employees > Configuration > Working schedules - Set your working schedule to have non round numbers (Not mandatory but makes the issue much easier to reproduce) - Timesheets > Edit to have the required hour total - Sometimes rounding errors will cause the formatting to change (Overtime of +0:00, display in red...) This issue is not deterministic but we currently use exact comparisons between floats to determine the formatting so it could happen anytime. The error mar

Steps to reproduce:
- Employees > Configuration > Working schedules
- Set your working schedule to have non round numbers (Not mandatory but makes the issue much easier to reproduce)
- Timesheets > Edit to have the required hour total
- Sometimes rounding errors will cause the formatting to change (Overtime of +0:00, display in red...)

This issue is not deterministic but we currently use exact comparisons between floats to determine the formatting so it could happen anytime. The error margin was chosen to be much lower than what a difference of 1min could cause (Since the rounding errors are in the vicinity of 1e-16).

opw-4123649

Forward-Port-Of: odoo/enterprise#69845

### Steps to reproduce: - Create a Helpdesk team with the options "Return" and "Repairs" - Create a product, sell 1 unit and deliver it. - Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket. - Create a repair order and mark it as done. #### > If you go back to the product return, the stock move of the original return appears twice. ### Cause of the Issue: Clicking on t

### Steps to reproduce:

- Create a Helpdesk team with the options "Return" and "Repairs"
- Create a product, sell 1 unit and deliver it.
- Create a ticket for the Helpdesk Team, select the customer who bought the product > create and validate a return of the product to your warehouse through the ticket.
- Create a repair order and mark it as done.

#### > If you go back to the product return, the stock move of the original return appears twice.

### Cause of the Issue:

Clicking on the `End Repair` button of the repair will call the `action_repair_end` with a `default_picking_id` equal to the `picking_id` of the `repair.order` in the context. However, during this call a stock move groing from repair location to the repair location will be created and mark as done for the final product to be assocaited with the repair order:
https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L379-L382 https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L417-L442 https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/addons/repair/models/repair.py#L444-L449 Since no `picking_id` is specified in its `move_vals`, the default `picking_id` (that is the return) will be added to the vals of the create here:
https://github.com/odoo/odoo/blob/e3a5d82f8ea6a92ced59c287c50f7cd33277a4bd/odoo/models.py#L4564 So that the newly created move will be linked to the return move even thought this makes no sense.

opw-4159779

Forward-Port-Of: odoo/enterprise#69936

### Steps to reproduce: - In the setting: enable Rental transfers - Create and confirm a rental order for 1 unit of a product. ##### > 2 transfers are created: one delivery and one receipt - Validate the delivery and then the receipt for your product. - Go back to the setting: disable Rental transfers #### Expected behavior: You are expected to be able to change this setting. In addition, you have already ended each of your flows that was sensitive to this settings so that nothing s

### Steps to reproduce:

- In the setting: enable Rental transfers
- Create and confirm a rental order for 1 unit of a product.
##### > 2 transfers are created: one delivery and one receipt
- Validate the delivery and then the receipt for your product.
- Go back to the setting: disable Rental transfers

#### Expected behavior:

You are expected to be able to change this setting. In addition, you have already ended each of your flows that was sensitive to this settings so that nothing should be blocking.

#### Current behavior:

Error: caused by a foreign key violation: "stock_move_rule_id_fkey" on the table "stock_move".

### Cause of the issue:

Push and pull Rules were refactored in saas-17.2 see commit a2ea658 along with this refactoring a method was added to delete the rules of the rental route in oreder to update them if the route is disabled: https://github.com/odoo/enterprise/blob/4647c62c3bd05b7346033cfa851770dfc399837e/sale_stock_renting/models/stock_warehouse.py#L15-L20 However, if the rule was already used on a stock move (just like in our flow) these rules will still be referenced by a move and you will not be allowed to delete the rules form the "stock_rule" table without violating the foreign key violation "stock_move_rule_id_fkey" on the "stock_move" table.

### opw-4131426

Forward-Port-Of: odoo/enterprise#70199

### Steps to reproduce: - Have two companies: COMP1, COMP2 - In the settings Enable Multi-step routes Prior to 17.2: - Inventory > Configuration > Warehouse Management > Locations - Unarchive: Virtual Locations/Inter-company transit and set is Return Locations - With COMP1: Create and confirm a PO with COMP2 as vendor for 10 units of a storable product - Validate the receipt and return. Select the Virtual Locations/Inter-company transit as return location and validate #### > On the POL

### Steps to reproduce:

- Have two companies: COMP1, COMP2
- In the settings Enable Multi-step routes Prior to 17.2:
- Inventory > Configuration > Warehouse Management > Locations
- Unarchive: Virtual Locations/Inter-company transit and set is Return Locations
- With COMP1: Create and confirm a PO with COMP2 as vendor for 10 units of a storable product
- Validate the receipt and return. Select the Virtual Locations/Inter-company transit as return location and validate
#### > On the POL the received quantity went from 10 to 20 rather than 0

#### Note:

Starting from 17.2, the Inter-company transit location is the default location destination of the return rather than (Partner/Vendor). It also changed its reference to `stock_location_inter_company` so that the fix should be adapted in that version.

### Cause of the Issue:

Currently, the qty_received is computed with respect to moves linkes to the POL. However, a move is flagged as a return only if the usage of its destination supplier (dropshipping and subcontracting flow excluded): https://github.com/odoo/odoo/blob/f494496b5142af23ee46ce249a1063f9d6caf403/addons/purchase_stock/models/stock_move.py#L247-L249 and if it is not flagged a return, its quantity is counted positively rather than negatively in the received quantity:
https://github.com/odoo/odoo/blob/f494496b5142af23ee46ce249a1063f9d6caf403/addons/purchase_stock/models/purchase.py#L348-L370

opw-4190647

Forward-Port-Of: odoo/enterprise#70599
Forward-Port-Of: odoo/enterprise#70376

### Steps to reproduce * install `l10n_th_reports` * create a Thai company and its branch * using the company selector, ensure the current company is the branch company, while selecting both parent and branch company * open the Thai Tax Report * attempt to export the "Sales Tax Report (xlsx)" You should be met with a traceback about a tax group External ID not being found ### Cause The system looks for an XML ID which is only present in the parent company, while using the branch

### Steps to reproduce

* install `l10n_th_reports`
* create a Thai company and its branch
* using the company selector, ensure the current company is the branch company, while selecting both parent and branch company
* open the Thai Tax Report
* attempt to export the "Sales Tax Report (xlsx)"

You should be met with a traceback about a tax group External ID not being found

### Cause

The system looks for an XML ID which is only present in the parent company, while using the branch company

opw-4181071

Forward-Port-Of: odoo/enterprise#70467

Make ShopFloor use IoT task: 4017327 Forward-Port-Of: odoo/enterprise#70733 Forward-Port-Of: odoo/enterprise#68706

Make ShopFloor use IoT

task: 4017327

Forward-Port-Of: odoo/enterprise#70733
Forward-Port-Of: odoo/enterprise#68706

Fix staff user cards alignment when there is only 1 user and the appointment is unpublished. The card must be aligned with the "Unpublished" text. Task-4196414 Forward-Port-Of: odoo/enterprise#70469 Forward-Port-Of: odoo/enterprise#70309

Fix staff user cards alignment when there is only 1 user and the appointment is unpublished. The card must be aligned with the "Unpublished" text.

Task-4196414

Forward-Port-Of: odoo/enterprise#70469
Forward-Port-Of: odoo/enterprise#70309