**Description of the issue/feature this PR addresses:**
This PR enhances the Starshipit integration to reliably handle scenarios where the exact shipping cost is not immediately available from Starshipit after label creation. Cost is fetched via a cron job and correctly applied to both the stock.picking's carrier_price and, crucially, the corresponding Sales Order delivery line. First commit removes the 3-tries loop, and was already reviewed on this [PR](https://github.com/odoo/enterprise/pull/85088).

**Current behavior before PR:**
When confirming a picking with a Starshipit Delivery method, the exact Shipping cost was not instantly available. The previous code had 3 attempts to retrieve it, before stopping the process, asking the user to try at a later time.

**Desired behavior after PR is merged:**
The price fetching becomes non-blocking. If Starshipit did not return an immediate `total_shipping_price`, a temporary price of 0.0 will be used. A Cron job will then run on all pickings with a 0.0 carrier price in order to fetch the exact price from Starshipit, and update the SO delivery lines.  

opw-4748113

When merging on `master`, further improvement might be to introduce a `starshipit_pending_price` boolean field instead of running the CRON job on all 0.0 carrier price pickings. 

With the new view `view_picking_form_inherit_stock` being introduced, runbot tests fail when migrating to saas-18.1. (Because view is not yet present in the saas-18.1 codebase)

**How to test?**
- On a runbot DB, install the `delivery_starshipit` module
- Configure the DB to interact with the connector
- Place a Sales Order with a delivery method configured to use Starshipit.
- Confirm the Delivery. The shipping price, if not available, will be temporarily set to 0.0.
- Run the Cron Job manually. You can check and activate the Cron by navigating to Settings > Technical > Automation > Scheduled Actions.
- Check that the SO has been updated with the actual shipping price from Starshipit.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

### **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