**Steps to reproduce the issue:**
- Install Stock, Sales applications
- Set the allowed companies to Marc Demo to be only one company
- Change the user to Marc Demo
- Create a SO with partner another company than Marc's company
- Confirm the SO

**Issue:**
A traceback is raised:
`No rule has been found to replenish "product" in "Virtual Locations/ Inter-company transit". Verify the routes configuration on the product.`

**Root Cause:**
- When the procurement group searches for a pull rule with a destination location set to the inter-company transit location (due to the partner's company being different), the rules for the inter-company transit location are not automatically applied.
- The `_get_rule_domain` method https://github.com/odoo/odoo/blob/05cff3b7d866f6bc95c4b32f343ae14a4da946f2/addons/stock/models/stock_rule.py#L641-L653 modifies the destination location to the customer's location if:
  - The user belongs to the `base.group_multi_company` group.
  - The destination location is the inter-company transit location.
- In this use case, the user does not belong to the `base.group_multi_company` group because they are restricted to a single allowed company.

Additionally, the logic in `_compute_location_dest_id` https://github.com/odoo/odoo/blob/05cff3b7d866f6bc95c4b32f343ae14a4da946f2/addons/stock/models/stock_move.py#L227-L231 for inter-company transfers does not account for users with a single allowed company.

**opw-4749870**

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#216317
Forward-Port-Of: odoo/odoo#211063

Versions
--------
- saas-18.3+

Steps
-----
1. Enable `website_sale_collect`;
2. set up a warehouse in a country with optional zip codes;
3. configure warehouse as a pickup location;
4. add products to its inventory;
5. via eCommerce, go to one of these products;
6. select warehouse as pickup location;
7. go to checkout;
8. attempt to pay for the order.

Issue
-----
Rendering error due to attempting to using `+` on strings & bools.

Cause
-----
Commit e3230547a53ce added a "Deliver to pickup point" line where it concatenates pickup location values into a single string like https://github.com/odoo/odoo/blob/8103619c51525bcdaa754c39c7d27560b3f6861e/addons/website_sale/views/templates.xml#L2686
The intention is that if the key doesn't exist, the empty string should be used. Issue is that when no zip code is provide, using `get` will return the boolean `False` instead of falling back on the empty string, leading to the rendering error.

Solution
--------
When sending the pickup location data to the front-end, provide empty strings instead of boolean values.

opw-4893036

Forward-Port-Of: odoo/odoo#216112

Steps to reproduce:
---
- Install `sale_management` module
- Enable `Units of Measure & Packagings`
- Delete `Hours` in Units & Packagings
- Install `sale_planning` module

Traceback:
---
```
ValueError: External ID not found in the system: uom.product_uom_hour

ParseError: while parsing /home/odoo/src/enterprise/saas-18.2/sale_planning/views/planning_role_views.xml:26, somewhere inside <record id="planning_role_view_tree_inherit_sale_planning" model="ir.ui.view">
        <field name="name">planning.role.list.inherit.sale.planning</field>
        <field name="model">planning.role</field>
        <field name="inherit_id" ref="planning.planning_role_view_tree"/>
        <field name="arch" type="xml">
            <field name="resource_ids" position="after">
                <field name="product_ids" widget="many2many_tags" placeholder="e.g. Cleaning Services" domain="[('planning_role_id', '=', False), ('type', '=', 'service'), ('sale_ok', '=', True)]" context="{                         'default_type': 'service',                         'default_planning_enabled': True,                         'default_planning_role_id': id,                         'default_uom_id': %(uom.product_uom_hour)d,                     }"/>
            </field>
        </field>
    </record>
```

The error occurred at [1] because the user deleted `Hours` from `Units & Packagings` before attempting to install the other module.

This commit resolves the issue by calling the `ensure_uom_hours` method before updating the `Hours` unit of measure in the data file. This method ensures the UoM is recreated if it no longer exists in the database.

[1]- https://github.com/odoo/enterprise/blob/adfa1ff2ee56b8d43666cd7c2565d6e9430aae48/sale_planning/views/planning_role_views.xml#L38

sentry-6595283261

Forward-Port-Of: odoo/enterprise#89046
Forward-Port-Of: odoo/enterprise#85286

**Issue 1**
- Have a pricelist with the "Discount policy" == "without_discount"
- Using this pricelist, create a SO with 1 subscription line and 1 non-subscription line
- Set a discount on both lines
- Save the SO
- Issue: the discount on the non-subscription line has been reset to 0.0

**Issue 2**
- Using the previous SO, add back a discount value for the non-subscription line
- Confirm the SO and invoice it
- Close the subscription
- Issue: the discount on the non-subscription line has been reset to 0.0

**Cause**
Both issues come from the fact that `order_id.subscription_state` is a dependency of `_compute_discount` in `sale_subscription`. The super is called for non-subscription lines, recomputing the discount.

**Solution**
It is not possible to know which dependency triggered the compute, therefore the solutions are to:
- avoid a recompute at creation after the `web_save` by not writing on the `subscription_state` field if not necessary
-  avoid calling super for lines if the subscription is closed

opw-4645579

Forward-Port-Of: odoo/enterprise#88816
Forward-Port-Of: odoo/enterprise#84754

**Issue 1**
- Have a pricelist with the "Discount policy" == "without_discount"
- Using this pricelist, create a SO with 1 subscription line and 1 non-subscription line
- Set a discount on both lines
- Save the SO
- Issue: the discount on the non-subscription line has been reset to 0.0

**Issue 2**
- Using the previous SO, add back a discount value for the non-subscription line
- Confirm the SO and invoice it
- Close the subscription
- Issue: the discount on the non-subscription line has been reset to 0.0

**Cause**
Both issues come from the fact that `order_id.subscription_state` is a dependency of `_compute_discount` in `sale_subscription`. The super is called for non-subscription lines, recomputing the discount.

**Solution**
It is not possible to know which dependency triggered the compute, therefore the solutions are to:
- avoid a recompute at creation after the `web_save` by not writing on the `subscription_state` field if not necessary
-  avoid calling super for lines if the subscription is closed

opw-4645579

Forward-Port-Of: odoo/enterprise#88816
Forward-Port-Of: odoo/enterprise#84754

**Issue 1**
- Have a pricelist with the "Discount policy" == "without_discount"
- Using this pricelist, create a SO with 1 subscription line and 1 non-subscription line
- Set a discount on both lines
- Save the SO
- Issue: the discount on the non-subscription line has been reset to 0.0

**Issue 2**
- Using the previous SO, add back a discount value for the non-subscription line
- Confirm the SO and invoice it
- Close the subscription
- Issue: the discount on the non-subscription line has been reset to 0.0

**Cause**
Both issues come from the fact that `order_id.subscription_state` is a dependency of `_compute_discount` in `sale_subscription`. The super is called for non-subscription lines, recomputing the discount.

**Solution**
It is not possible to know which dependency triggered the compute, therefore the solutions are to:
- avoid a recompute at creation after the `web_save` by not writing on the `subscription_state` field if not necessary
-  avoid calling super for lines if the subscription is closed

opw-4645579

Forward-Port-Of: odoo/enterprise#88816
Forward-Port-Of: odoo/enterprise#84754

Bug:
1. Worked overtime hours are included within the gross paid amount of a contract rather than being added on top.

2. Casual loading rate applies to Overtime hours.

Steps to reproduce:
1. Create a payslip for an employee with a contract of Fixed wage of 2000 per week.
2. The created payslip is of correct amount with the standard 40-hours work week.
3. Add a work entry of type Overtime with duration of 4 hours. Recompute the worked days amounts.

Current behavior:
The total remains 2000 and the computed hourly rate becomes 2000/44=45.45

Expected behavior:
The hourly rate should remain the same 50.
The total should increase to be:
fixed_wage + hourly_rate * overtime hours
2000 + 50 * 4 = 2200

Fix:
1. While computing the amounts for each worked days type, exclude hours of type Overtime from total hours when calculating the hourly rate.

2.The casual loading rate should not apply to Overtime work entry types.

task-4617681

Forward-Port-Of: odoo/enterprise#88100
Forward-Port-Of: odoo/enterprise#83171

### **Description of the issue/feature this PR addresses:**
When doing an Invoice B to exempts customer we have a problem the RG Legend new table is not showing: this because if the VAT Content or other taxes sum is 0.0 (we are not showing any information if sums 0.0)

After checking with ARCA Online PDF sxampels, and some feedback of Argentinen users, we found out that the Legend should be always present. event if the totals of theTax Breakdown are shown with 0.0

### **Steps to reproduce**
Go to an Argentina Company
Create a new invoice for "Final Consumer" with document type "Invoice B"
Create a product line with tax 0 (could use either VAT Exempt, VAT 0, VAT Not Taxed)
Print the PDF

### **Current behavior before PR:**
The PDF is NOT showing the Tax Breakdown table

![image](https://github.com/user-attachments/assets/ae51cd41-0bc0-478f-8781-b05f0b13b3de)

### **Desired behavior after PR is merged:**
The PDF is showing the Tax Breakdown with the line VAT Content 0.0

![image](https://github.com/user-attachments/assets/9780eeb0-943b-4755-a5c1-7e1e5eafdf5c)



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Manual Forward-Port-Of: https://github.com/odoo/odoo/pull/207367

**Current behavior:**
During the assignment of a picking, if any of its moves have an origin that does not match its own, the origin will be cleared altogether.

**Expected behavior:**
The different origin should be appended to the existing origin string (as is done in batch replenishment, for example).

**Steps to reproduce:**
1. Create 2 products, create a secondary warehouse

2. Create an orderpoint for each product, make the route on both of them the (first?) pointed to by `resupply_route_ids` on the primary warehouse

3. Set `qty_to_order` 1 on each of the orderpoints, and one at a time click the 'Order' button

4. The move generated for each replenishment action will ultimately be added to a single picking -> in the end see that its `origin` field is cleared

**Cause of the issue:**
We currently decide to clear the picking origin during assignment if any of its moves have a different origin.

**Fix:**
Instead, append the different origin string to the picking.

opw-4749519

**Problem:**
When refunding an order that has been done in the frontend from the backend, then
when trying to pay for it again using an online payment method, it will
currently work. The problem is that doing this will prevent the user from
closing their session afterwards. The issue is that refunding through
online payment method is not supported but is going though either way.

**Steps to reproduce:**
- Have an online payment method.
- Go to your POS session and make a purchase, pay for it in cash.
- Go back to the backend, to orders and chose your order.
- Return the products and click payment to pay for it again.
- Chose your online payment method and make the payment.
- Try to close your POS session, an error prevents you from doing so.

**Why the fix:**
The problem is that an error should be thrown when trying to pay the
refund with an online payment method. But this error is never reached.
It was reached before this commit https://github.com/odoo-dev/odoo/commit/2dce0f22e92299b17162343e3629dcdab8a697b5
This commit is fixing an error that has since been avoided by this
commit https://github.com/odoo-dev/odoo/commit/0c8f0d730465028657ff8da28e7ab14e2df08f69
The use case does not even go through the fixed *create* function
anymore, so there should be no problem reverting the fix.
Before said commit, we set the *online_account_payment_id* whether
it exists or not. This then allows us to check if one of them is None
later on. If it is, it means we can't create the online payment, as we
can't create one without an accounting payment. After said commit,
we didn't add it if the accounting payment didn't exist, so the error was
never thrown as the code couldn't be reached.

opw-4815049

**Steps to reproduce:**
- Install accountant
- In Accounting settings, activate "Audit Trail"

- Create an invoice:
  * Customer: [any]
  * Invoice Lines:
    - Product: [any]
    - Start Date: [2 months ago]
    - End Date: [2 months later]
- Confirm the invoice
=> Deferred Entries are created. Posted for the previous months and in draft for the future ones.

- Reset the invoice to draft

**Issue:**
The draft entires are correctly unlinked, but the posted ones are reversed instead of being cancelled.

**Cause:**
This fix https://github.com/odoo/odoo/commit/cc448bf77aa3d11e634e6bab6da1690a1b67a723 is supposed to cancel the deferred entries when the move is protected by the audi trail.
However we never get into the `elif move._is_protected_by_audit_trail():` branch because its condition is also included in the previous `if not move._can_be_unlinked():` branch.

Linked enterprise PR (test): https://github.com/odoo/enterprise/pull/88992

opw-4891975



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

Steps to reproduce:
- Install Sales and Stock
- Activate the multi-step routes setting
- Go to a Delivery route in the warehouse
- Change the `location_dest_id` of the operation type set on the rule
- Enable the "Location Dest. Taken from Rule" checkbox
- Ensure `rule.location_dest_id` and `operation_type.location_dest_id`
  are different
- Create a Sales Order (SO) for a product with quantity = 5 and confirm
- Change the SO line quantity to 3 and save

Issue:
A second picking is created with a move taking the product from
`rule.operation_type.location_dest_id -> rule.operation_type.
location_src_id` with quantity = -2.

This happens because the decrease in the SO quantity triggers a
negative move, and this move is not merged with the existing
positive move. Instead, a new move is created in the opposite
direction.

In `_merge_moves`:
https://github.com/odoo/odoo/blob/3c4275fb00255e519f01bf5547eff1db3a59d4b5/addons/stock/models/stock_move.py#L1191-L1193

It checks if the negative move has similar characteristics to the
existing positive moves. However, the `neg_key(neg_move)` differs in
`location_dest_id`, so the merge fails. This happens because the
negative move does **not** read the `location_dest_id` from the rule —
unlike the procurement, which **does** use the rule and therefore
creates positive moves with the correct destination.

When the negative move is created with the procurement, it initially
has the correct `location_dest_id`. But then:

https://github.com/odoo/odoo/blob/b984c72df398c4fe942d8894442e4e893ca0660e/addons/stock/models/stock_move.py#L1191
triggers `_compute_location_dest_id`, which doesn't consider the
`rule.location_dest_id` and defaults to `operation_type.
location_dest_id`, causing the merge to fail due to mismatched
destination_locations.

The positive move has read the correct value, because when it
was assigned to a picking, the picking has the correct destination
from the procurement. But for the neg_move it has picking None so
it maps to the operation_type without consdiering the location from
rule checkbox.

opw-4793171

## How to reproduce
- Create 3 products: "FNS" / "CMP 1" / "CMP 2", the three of them with an UoM of 2 digits precision
- Create Kit BoM for 1 Unit of "FNS" using 10 Units of "CMP 1"
- Create Kit BoM for 5000 Units of "CMP 1" using 50 of "CMP 2"
- Check "FNS" BoM Overview:
  - "CMP 2" quantity shows the correct 0.10 Units (1 * 10 / 5000 * 50) (ok)
- Create Delivery order for 1 Unit of FNS
  - "CMP 2" quantity is 0.50 Units (KO)

OPW-4804958

---

### BoM Overview
![image](https://github.com/user-attachments/assets/63d6ad16-b070-40c1-a06b-28dc6026998b)


### BoM exploded
![image](https://github.com/user-attachments/assets/46dc1812-91ff-4ef4-b278-1dd45acbb637)


---

### Test result without fix:

```
2025-06-25 00:00:00,000 28629 ERROR oes_test_17 odoo.addons.mrp.tests.test_bom: FAIL: TestBoM.test_02_explode_rounding
Traceback (most recent call last):
  File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/mrp/tests/test_bom.py", line 63, in test_02_explode_rounding
    self.assertEqual(lines[0][1]['qty'], 0.10)
AssertionError: 0.5 != 0.1
```

---

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

Forward-Port-Of: odoo/odoo#215821

Linked to a commit in enterprise for account_followup: https://github.com/odoo/enterprise/pull/88515

### Issue:
It is possible to break the followup reports by directly creating entries in the past.

### Steps to reproduce:
- Example on Belgian loca
- Accounting Dashboard > Misc > new Entry with
	- Date far in the past (ie 2024-01-01)
	- Account: "400000 Customers", Partner: "test partner", Debit: 500.0
	- Account: "499000 Suspense Accounts", Credit: 500.0
- Post
- In Customers > Follow-up reports, the partner is marked as "In need of action" even if no due date was specified
- Accounting Dashboard > Bank > new with Amount: 500.0
- "Save & Close" then click on it
- In the page "Manual Operations" change the partner to the one from the MISC entry
- Change the Account to "400000 Customers"
- Validate
- The follow-up report is no longer "In need of action"
- Create an invoice with a due date in the future
- The follow-up report is back to "In need of action" with the amount of the invoice
- When sending the follow-up, the Customer statement reads "your account shows an outstanding balance of 0.00€"

### Cause:
The origin of this issue is that the MISC entry and the Bank payment are not reconciled. The MISC entry is used to calculate the state of the followup making it to "In need of action" but the bank entry is balancing the amount to 0.00€.

The MISC entry should not be used to compute the followup state as it has no due date specified (it makes no sense, it is never linked to any invoice). But in the code when there are no `line.date_maturity` we fallback on `line.date`.

### Solution:
The lines without due date or payment term should not be used to compute the state of the followup or calculate the total due.

So we remove the fallbacks on `line.date` when `line.date_maturity` is False. Some tests needed to be adjusted as they were not using any payment terms or due date. They were working because of the fallback on `line.date`.

opw-4784250

**Issue**
When modifying and reposting a vendor payment that does not have the highest sequence number, the payment's name (i.e., number) is regenerated using the next available sequence, rather than preserving the original. This issue only occurs when the Outstanding Payments account is configured for the journal.

**Steps to Reproduce**
1.Install the Accounting module.
2.Go to Accounting > Configuration > Journals, and open a Bank journal.
3.In the Outgoing Payments tab, set an Outstanding Payments Account.
4.Go to Accounting > Vendors > Payments.
5.Create and post two vendor payments (e.g., 00001 and 00002).
6.Reset the first one (00001) to draft, change any field (e.g., amount), and repost it.
7.The number changes to 00003 instead of preserving 00001.

**Root Cause**
When a vendor payment is modified and reposted, Odoo cancels and regenerates the associated account.move. If an Outstanding Payments account is configured — or was configured at any point — this triggers additional logic causing the move name to be reset to '/'. This placeholder indicates that the move is treated as if it were new, prompting Odoo to assign it the next number in the journal’s sequence. As a result, the payment loses its original number even though it conceptually refers to the same transaction.

**Fix**
The fix ensures the original number is preserved by restoring the payment's previous name only when it's clear that the move is being regenerated, not newly created. This is determined by checking that the move is linked to exactly one payment (i.e., a one-to-one relationship) and that its name is '/', indicating the move was regenerated.

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

_*= sale_planning, sale_renting_planning

Steps to Reproduce:
- Install the `sale_renting_planning` module.
- Create a rental product with the `Plan Service` enabled and the resource type set to `Material`.
- Create a SO for the newly created product and confirm it.
- Observe the state button the shift is already planned but it incorrectly displays `To Plan`.

Issue:
- Confirming the SO the shift is already planned but the state button still displays `To Plan`. this issue occurs when the resource type is `Material` However it works correctly when the resource type is `User`.

Cause:
- When we are calculating the planned hours the domain `'resource_type', '!=', 'material'` is passed causes resources type of Material so it will be excluded from the calculation.

Fix:
- In this commit removed the condition that excluded resources of type Material so that they are included when calculating the planned hours. This ensures the state button shows the correct status.

task-3978597