**Current behavior:**
Since https://github.com/odoo/odoo/commit/84dda968146d2f3743ab7fc516300e50780725e3, we valuate an unbuild operation by attempting
to match the ensuing OUT layer with the IN layer from the
original MO.

The point being to eliminate a potential valuation imbalance for
the manufactured product (might affect cost, etc.).

**New behavior**
Don't attempt to match an unbuild valuation layer with the
original MO valuation layer. If there is some cost difference
between build time and unbuild time, make a corrective journal
entry for it.

**Issue with current behavior**
The following sequence:
1. Create Product A with average costing, real-time valuation
2. Create 2 components, avg costing, real-time val
3. Create a BoM for Product A with the components
4. Manufacture 3 units of Product A with different component
quantities (can set flexible consumption on BoM)
5. Unbuild the first manufactured unit

Results in Product A's cost not matching the expected average
cost according to the valuation layers.

**Cause of the issue:**
Unbuilding the first MO created an out move at the original
"build time" cost, but since we've built 2 additional qty, that
original cost is not the current average cost- thus the
"theoretically current" standard price of the product (sum of
layers value divided by remaining qty) is no longer the value we
see on the product form.

**Fix:**
Don't try and match the valuation layers. Aside from issues such
as the one described above, it might not actually make
functional sense to do so (e.g., FIFO isn't actually adhering to
first-in-first-out if we're preferring the original IN layer for
an unbuild valuation).

Instead we make a journal entry with any excess cost of
production (it was actually a solution proposed in the
discussion on https://github.com/odoo/odoo/commit/84dda968146d2f3743ab7fc516300e50780725e3 in the first place).

Additionally, now that we aren't doing this mapping, we can
revert the non-test difference of https://github.com/odoo/odoo/commit/3a69456a291da593748475c86e7efc6234019e47, as this commit was
fixing an issue introduced by the change which added the
mapping.

opw-[4877597](https://www.odoo.com/web#id=4877597&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#222014
Forward-Port-Of: odoo/odoo#221718

When installing the `project` module, `_sync_plan_column(self, model)` is called for all existing analytic plans. The method iterates through `self` in arbitrary order, which means a child plan can be processed before its parent. In such a case, the code tries to create a related field pointing to a parent-level column that does not yet exist, leading to errors like: `Field name "x_plan26_id" unknown for related field "x_plan26_id.plan_id"`

This happened because `self` was iterated without guaranteeing that parents are processed first. As a result, the related field chain (`.plan_id.parent_id...`) could reference missing intermediate fields.

The fix is ordering the recordset by `parent_path`.

Steps to reproduce:
1. In Odoo Inspector, search for model `account.analytic.plan`. and go to records.
2. Create a first plan.
3. Create a second plan and set the first plan as its parent.
4. Install the `project` app (triggers `_sync_plan_column`).
5. Observe the crash due to an unknown related field.

OPW-5006494

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

Forward-Port-Of: odoo/odoo#224509

## Issue:
In a multi-company setup with Inter-Company Transactions set to Sales Orders and Purchase Orders, after creating two Sales Orders from one company to the other,
then generate a Consolidated Invoice for both SO, and import it as Vendor Bill in the client Company, the bill isn't linked to the matching Purchase Order

## Cause:
The `invoice_origin` is used to get the references, but it doesn't split causing the purchase's name to search in `_match_purchase_orders()` to be ["P00001, P00002"] instead of ["P00001", "P00002"]
https://github.com/odoo/odoo/blob/2718aaa7397e38be0fcd64fe6b5ef5c0be66cfe2/addons/purchase/models/account_invoice.py#L373-L374

## Steps to reproduce:
- Enable Inter-Company Transactions for Sales Orders and Purchase Orders in two Companies
- Create and Confirm two Sales Orders from one company to the other one
- Create a Consolidated Bill for both S0
- Send the Invoice (Download)
- Switch to the second Company
- In Purchase, Confirm both RFQ
- In Accounting > Vendor > Bills, Upload the downloaded bill
- The Smart Button isn't linked to the PO

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4690707)
opw-4690707

Forward-Port-Of: odoo/odoo#223398

Problem:
Open "PDF Quote" report in Studio and observe when hovering on the
first table cell: the table menu button is always on top of the
first cell (with a small offset difference).

Cause:
In `OverlayPlugin` we get the container on which we later calculate
the overlay position during setup.
`QWebPlugin` may show/hide elements in reports (CSS `display`
controlled by attributes like `data-oe-t-group-active`).

The issue:
Before commit
https://github.com/odoo/odoo/commit/27a85d650dee8345a4ec701bf7456eec07851718
we used to find the scrollable starting from the `iframe`. This
always returned the same scrollable outside the `iframe`, even when
its content was scrollable. Now, since
`QWebPlugin.applyGroupQwebBranching` can change the `iframe`
content, the scrollable may differ.

Solution:
`getScrollContainer` should check the scrollable starting from the
`iframe` before `this.editable`.

Steps to reproduce:
1. Open "PDF Quote" report in Studio.
2. Hover on the table headers.
3. Observe the menu button is always positioned on top of the
   first cell.

opw-5046779

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

## Short functional explanation of the error
When we create an invoice with a different currency than the main one, the Statement of Account PDF report in aged receivable has an error. The amount for each line is displayed as the main currency, but the conversion isn't done.
For instance, if we create an invoice line of 3.5$ but our main currency is the Euro, in the report, it will show 3.5€ instead of 2.99€

## Reproduction Steps
1. In a db without demo data, Download the app l10n_my.
2. In the general settings, click on Currencies. Activate a second currency and set its currency rate (relative to the main currency of the company) different of 1.
3. In accounting > settings, click on -> Currencies. Activate this second currency.
4. Click on configuration > journals and activate the debug mode. In the Journal Entries tab, as Currency, select a different currency than your main one (set in the general settings).
5. Create an invoice. Set a customer and select the journal for which you set an additional currency. Select this additional currency. Finally, add a product and click confirm.
6. Click on Reporting > Aged Receivable. Then, click on the line corresponding to your partner on Statement of Account. A PDF should download.

### Expected behavior
The lines under Balance should be displayed as the main currency of the company, with the correct currency rates applying.

### Unexpected behavior
The lines under Balance are displayed as the main currency of the company but the currency rates are not applying.

## Origin of the issue
In the code, the currency rate isn't used to generate this line of the report:
https://github.com/odoo/enterprise/blob/79c1ba68d48e7e068104d867e186610dd5110cc4/l10n_my_reports/report/statement_account_templates.xml#L52
__
opw-4975540

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

Forward-Port-Of: odoo/enterprise#93096

When installing the `project` module, `_sync_plan_column(self, model)` is called for all existing analytic plans. The method iterates through `self` in arbitrary order, which means a child plan can be processed before its parent. In such a case, the code tries to create a related field pointing to a parent-level column that does not yet exist, leading to errors like: `Field name "x_plan26_id" unknown for related field "x_plan26_id.plan_id"`

This happened because `self` was iterated without guaranteeing that parents are processed first. As a result, the related field chain (`.plan_id.parent_id...`) could reference missing intermediate fields.

The fix is ordering the recordset by `parent_path`.

Steps to reproduce:
1. In Odoo Inspector, search for model `account.analytic.plan`. and go to records.
2. Create a first plan.
3. Create a second plan and set the first plan as its parent.
4. Install the `project` app (triggers `_sync_plan_column`).
5. Observe the crash due to an unknown related field.

OPW-5006494

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

Forward-Port-Of: odoo/odoo#224509

**Current behavior before PR:**

- Applying a spin effect to an icon doesn't not create a history step, which causes the undo functionality to fail.
- The spin icon in the toolbar was not highlighted after applying the effect.
- When some text is selected along with icon, trying to apply color only affects the icon, the text remains uncolored.


**Desired behavior after PR:**

Now,
- History step is created after adding spin effect to an icon, allowing undo to work properly.
- The spin icon in the toolbar is properly highlighted to reflect the applied effect.
- This PR removes `color_apply_overrides` from icon_plugin to let color_plugin handle coloring the icons ensuring that the selected text is also colored along with icon.
- This PR also makes sure that default 60% opacity is applied when applying solid background color on icons or table cells.

task-4794673

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

Forward-Port-Of: odoo/odoo#224702
Forward-Port-Of: odoo/odoo#210341

## Issue:
In a multi-company setup with Inter-Company Transactions set to Sales Orders and Purchase Orders, after creating two Sales Orders from one company to the other,
then generate a Consolidated Invoice for both SO, and import it as Vendor Bill in the client Company, the bill isn't linked to the matching Purchase Order

## Cause:
The `invoice_origin` is used to get the references, but it doesn't split causing the purchase's name to search in `_match_purchase_orders()` to be ["P00001, P00002"] instead of ["P00001", "P00002"]
https://github.com/odoo/odoo/blob/2718aaa7397e38be0fcd64fe6b5ef5c0be66cfe2/addons/purchase/models/account_invoice.py#L373-L374

## Steps to reproduce:
- Enable Inter-Company Transactions for Sales Orders and Purchase Orders in two Companies
- Create and Confirm two Sales Orders from one company to the other one
- Create a Consolidated Bill for both S0
- Send the Invoice (Download)
- Switch to the second Company
- In Purchase, Confirm both RFQ
- In Accounting > Vendor > Bills, Upload the downloaded bill
- The Smart Button isn't linked to the PO

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4690707)
opw-4690707

Forward-Port-Of: odoo/odoo#223398

## Short functional explanation of the error
When we create an invoice with a different currency than the main one, the Statement of Account PDF report in aged receivable has an error. The amount for each line is displayed as the main currency, but the conversion isn't done.
For instance, if we create an invoice line of 3.5$ but our main currency is the Euro, in the report, it will show 3.5€ instead of 2.99€

## Reproduction Steps
1. In a db without demo data, Download the app l10n_my.
2. In the general settings, click on Currencies. Activate a second currency and set its currency rate (relative to the main currency of the company) different of 1.
3. In accounting > settings, click on -> Currencies. Activate this second currency.
4. Click on configuration > journals and activate the debug mode. In the Journal Entries tab, as Currency, select a different currency than your main one (set in the general settings).
5. Create an invoice. Set a customer and select the journal for which you set an additional currency. Select this additional currency. Finally, add a product and click confirm.
6. Click on Reporting > Aged Receivable. Then, click on the line corresponding to your partner on Statement of Account. A PDF should download.

### Expected behavior
The lines under Balance should be displayed as the main currency of the company, with the correct currency rates applying.

### Unexpected behavior
The lines under Balance are displayed as the main currency of the company but the currency rates are not applying.

## Origin of the issue
In the code, the currency rate isn't used to generate this line of the report:
https://github.com/odoo/enterprise/blob/79c1ba68d48e7e068104d867e186610dd5110cc4/l10n_my_reports/report/statement_account_templates.xml#L52
__
opw-4975540

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

Forward-Port-Of: odoo/enterprise#93096

Description of the issue/feature this PR addresses:

Incoherent selection of workcenters when using the breadcrumbs to come back to the shopfloor app:
https://drive.google.com/file/d/1C1nVdDHgCss7s7zyXDOpbMj0k79HlJBH/view?usp=drivesdk

Current behavior before PR:

When leaving the shopfloor app via a WO (WO setting -> Open MO), we set the a **context flag workcenter_id** in the the currentCaller.action.context to save the selected workcenter for breadcrumb logic. The same  **context flag workcenter_id** is used in the Manufacturing/workcenters view, when clicking on a workcenter. However, the intended use of the **workcenter_id flag** is different: 

- 1 From Manufacturing: Open shop floor with **only** workcenter_id selected + visible (no other workcenters visible).
- 2 From Shopfloor breadcrumb : Go to shop floor with all previous workcenters same as when leaving.

Additionally the current logic for setting the workcenter_id flag from the MrpDisplay record currently handles only the selection of isMyWO ([PR](https://github.com/odoo/enterprise/pull/52258))

Desired behavior after PR is merged:

Keep the same behavior when coming from Manufacturing/workcenters ([PR](https://github.com/odoo/enterprise/pull/67318)) but make sure the user come back to same view when leaving shopfloor and coming back via breadcrumbs.

task: [4629641](https://www.odoo.com/odoo/project/966/tasks/4629641)

I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: odoo/enterprise#93483
Forward-Port-Of: odoo/enterprise#88073

## Short functional explanation of the error
When we create an invoice with a different currency than the main one, the Statement of Account PDF report in aged receivable has an error. The amount for each line is displayed as the main currency, but the conversion isn't done.
For instance, if we create an invoice line of 3.5$ but our main currency is the Euro, in the report, it will show 3.5€ instead of 2.99€

## Reproduction Steps
1. In a db without demo data, Download the app l10n_my.
2. In the general settings, click on Currencies. Activate a second currency and set its currency rate (relative to the main currency of the company) different of 1.
3. In accounting > settings, click on -> Currencies. Activate this second currency.
4. Click on configuration > journals and activate the debug mode. In the Journal Entries tab, as Currency, select a different currency than your main one (set in the general settings).
5. Create an invoice. Set a customer and select the journal for which you set an additional currency. Select this additional currency. Finally, add a product and click confirm.
6. Click on Reporting > Aged Receivable. Then, click on the line corresponding to your partner on Statement of Account. A PDF should download.

### Expected behavior
The lines under Balance should be displayed as the main currency of the company, with the correct currency rates applying.

### Unexpected behavior
The lines under Balance are displayed as the main currency of the company but the currency rates are not applying.

## Origin of the issue
In the code, the currency rate isn't used to generate this line of the report:
https://github.com/odoo/enterprise/blob/79c1ba68d48e7e068104d867e186610dd5110cc4/l10n_my_reports/report/statement_account_templates.xml#L52
__
opw-4975540

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

Forward-Port-Of: odoo/enterprise#93096

When two timeoff (one with Ignore Public Holidays and the other without) have the same dates, if you modify a public holidays that happend during that time, it will trigger a traceback.

Steps to reproduce:
-------------------
* Marc demo and Abigail Peterson using the same calendar
* Create a "Paid time off" leave for marc demo: June 19 - June 20
* Create a "Extra time off" for abigail: same date
* Update Time off type "Extra Time Off" to "Ignore Public Holidays"
* Approve both leave request previously created
* Create public holidays on June 19 --> traceback

Observation:

When both time off have the same dates it will overide the value in the dictonary https://github.com/odoo/odoo/commit/0d846ecd1ec7ff5149d580d3494b1a4bab1e68d2#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R464 and when it will try to call the employe_id it will trigger the traceback https://github.com/odoo/odoo/commit/f72ac3a14d76d4fb53ec3a092d08afafe4c35888#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R561

Why the fix:
------------
Added a new key on work_days_data to avoid the collision of two similar timeoffs.

opw-4933820

**Problem:**
When making a purchase in the self order and put a table_stand_number, which is the table number you have to fill at the end of the order, it is displayed in the *pos_preparation_display*. But when loading this said order in the PoS, changing the order (like adding a note) and ordering it again, the table number is replaced by *IN*.

**Steps to reproduce:**
- Make a purchase in the kiosk
- Put a table number at the end of the order
- Go to the pos_preparation_display, it is displayed
- Go to the PoS session of the Kiosk and load the order
- Change the order by adding a note to it and order it again
- The table number is replaced by IN in the pos_preparation_display

**Why the fix:**
The field *table_stand_number* was not given to PoS in any case, which means that when reloading the order and saving it again, it saved it without the *table_stand_number*, as it was never loaded.
As it was never loaded, it went back to the fallback, which is writting *IN* if the table_stand_number was undefined. It is now loaded if the pos_self_order is installed, so that we can keep on showing the table number as it should be.

opw-4943404

Forward-Port-Of: odoo/odoo#220869

### Steps to reproduce:

- Install stock_delivery
- Create and confirm a receipt for 2 products:
    - 1 x P1
    - 1 x P2
- Modify the scheduled date of P1 to the day before
- Save the picking

#### Expected behavior:

The scheduled date of the picking is updated but not the one of the other move.

#### Current behavior:

The the move scheduled date is also updated.

### Cause of the issue:

Modifying the scheduled date of the move will trigger a call of the onchange on the picking because the `stock_move_ids` field has changed via a `Command.update` on its scheduled date:
https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/web/static/src/model/relational_model/record.js#L1214-L1219 However, this onchange will trigger a call of the
`_compute_scheduled_date` on the new records to determine if its value has changed and set the scheduled date of the picking to one day before: https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/stock/models/stock_picking.py#L846-L851 This is problematic because since each of these changes happen before the save of the real record, the inverse method of the scheduled date will be called and set the scheduled date of the other moves at save: https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/stock/models/stock_picking.py#L897-L901

### Note:

This is not reproducible without `stock_delivery`, changing the scheduled of a `move_ids_without_package` will only trigger the onchange of the `stock.picking` model (and hence the compute on the new records) in case the `move_ids_without_package` is flagged as `onchange=1` by the `get_view`:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/odoo/addons/base/models/ir_ui_view.py#L1218-L1225 But, since `move_ids_without_package` do not have `_onchange_methods` they will only be flagged as such if they are in the dependencies of a field present in the view:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/odoo/models.py#L7363-L7370 This is the case as soon as `stock_delivery` is installed because of the `is_return_picking` field:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/addons/stock_delivery/models/stock_picking.py#L37-L38

opw-5017423

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

Forward-Port-Of: odoo/odoo#224986

## Issue:
In a multi-company setup with Inter-Company Transactions set to Sales Orders and Purchase Orders, after creating two Sales Orders from one company to the other,
then generate a Consolidated Invoice for both SO, and import it as Vendor Bill in the client Company, the bill isn't linked to the matching Purchase Order

## Cause:
The `invoice_origin` is used to get the references, but it doesn't split causing the purchase's name to search in `_match_purchase_orders()` to be ["P00001, P00002"] instead of ["P00001", "P00002"]
https://github.com/odoo/odoo/blob/2718aaa7397e38be0fcd64fe6b5ef5c0be66cfe2/addons/purchase/models/account_invoice.py#L373-L374

## Steps to reproduce:
- Enable Inter-Company Transactions for Sales Orders and Purchase Orders in two Companies
- Create and Confirm two Sales Orders from one company to the other one
- Create a Consolidated Bill for both S0
- Send the Invoice (Download)
- Switch to the second Company
- In Purchase, Confirm both RFQ
- In Accounting > Vendor > Bills, Upload the downloaded bill
- The Smart Button isn't linked to the PO

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4690707)
opw-4690707

Forward-Port-Of: odoo/odoo#223398

### Description of the issue/feature this PR addresses:

Behavior in <= v17.4:

The onclick method for the delete button in the one2many list calls the `onDeleteRecord` method. This is inherited by the model-specific list renderer components to insert the deletion confirmation dialog before calling super which sets the clicked data attribute to be true. In this case, we display the dialog before setting the button as clicked.

Behavior in v18:

The onclick method for the delete button in the one2many list calls the `onRemoveCellClicked`. This method sets the clicked as True and then calls the `onDeleteRecord` method that is inherited by the various model-specific list renderer components to insert the Confirmation Dialog. In these cases, the dialog is called after we set the 'clicked' data-attribute on the delete button to be True. Hence now we are unable to click on the same button again due to it being in the clicked state.

### Current behavior before PR:

[Deletion Dialog does not reopen](https://github.com/user-attachments/assets/29b6c2c7-553b-4745-a20b-26a470952a01)

1. Try to delete a record of Project Subtask or Product Attribute Value
2. This would open the Deletion Confirmation Dialog box
3. Click on cancel 
4. Try to delete the same record again 

Result: Nothing happens and the confirmation dialog does not show up again for the second time


### Desired behavior after PR is merged:

If user attempts to delete any record that opens the confirmation dialog and then cancels it, the user is able to delete it as the confirmation dialog box is no longer disabled after spawning once.


opw-4731375

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