### Issue:

Currently, running a procurment to fulfill a demand in COMP1 linked to a buy rule of COMP2 toaward the inter-company transit will use seller's set in COMP1 and generate a PO in COMP1 rather than COMP2.

### Steps to reproduce:

- In the settings enable Multi-steps routes
- Have two companies: COMP1 and COMP2
- Create a routes without set companies with 3 rules:
  - rule 1 (comp1): - Pull from Virtual Locations/Inter-company transit to WH1/Stock supply method: Trigger an other rule.
  - rule 2 (comp2):  - Pull from  WH2/Stock to Virtual Locations/Inter-company transit, supply method: Trigger an other rule.
  - rule 3 (comp2): - Buy from Partner/vendors to WH2/Stock using a custom operation type towards Virtual Locations/Inter-company transit.
- Create a storable product with both routes set.
- With COMP2: set a vendor on that product.
- In COMP1, your product > Reordering rules create a new rule using the COMP1 route to replenish WH1/Stock.
- With both COMP1 and COMP2 as active order once.
> The PO could not find a vendor as it looked for suppliers in COMP1 and if such a supplier was set in COMP1, the PO would be created in COMP1.

### Cause of the issue:

While the rule of COMP2 is found and used to run the procurment here: https://github.com/odoo/odoo/blob/2cd3d6a76db6bedba8bbb3233690b0cd72f87876/addons/stock/models/stock_rule.py#L484 the procurement was created and is linked to the company owning the move creating the demand (that is COMP1):
https://github.com/odoo/odoo/blob/2cd3d6a76db6bedba8bbb3233690b0cd72f87876/addons/stock/models/stock_move.py#L1494-L1498 However, the `company_id` used in the `_run_buy` notably for the data's of the PO will be the company linked to the procurement rather than the company linked to the buy rule. Since the buy rule should generate a purchase order in company it uses, this is incorrect.

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

date_category can be None, we should check before adding values to the dict.
And also return empty string instead "none" in _compute_kanban_dashboard_graph

error from upgrade mock viewer.
```
  File "/tmp/tmpd7nbq20v/migrations/base/tests/test_mock_crawl.py", line 256, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmpd7nbq20v/migrations/base/tests/test_mock_crawl.py", line 269, in mock_action
    return self.mock_act_window(action)
   File "/tmp/tmpd7nbq20v/migrations/base/tests/test_mock_crawl.py", line 429, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpd7nbq20v/migrations/base/tests/test_mock_crawl.py", line 531, in mock_view_kanban
    self.mock_web_search_read(model, view, [domain], fields_list)
   File "/tmp/tmpd7nbq20v/migrations/base/tests/test_mock_crawl.py", line 590, in mock_web_search_read
    data = model.search_read(domain=domain, fields=fields_list, limit=80)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6074, in search_read
    return records._read_format(fnames=fields, **read_kwargs)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4016, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6983, in __getitem__
    return self._fields[key].__get__(self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1287, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1469, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5222, in _compute_field_value
    fields.determine(field.compute, self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 109, in determine
    return needle(*args)
   File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_picking.py", line 376, in _compute_kanban_dashboard_graph
    summaries[picking_type_id]['total_' + date_category] += 1
 KeyError: 'total_none'
```

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

Since this commit: https://github.com/odoo/odoo/pull/188201/commits/766ec99dbc2701a237f082f3fb124793d9dfe596

We try to clean reservations because, for some reason, there could be a discrepancy between the sum of “stock.move.line” and the quantity/reserved quantity on “stock.quant”.

However, there are cases where a user creates a storable product, updates its quantity, and then uses it in a “stock.move.line”, confirms it, and later changes the product type to a kit. So, when trying to clean the reservations for these “stock.move.line”, a user error occurs because the system attempts to create a quant for a kit-type product: 

https://github.com/odoo/odoo/blob/c07778bbce4311c142bd8e2ce3013998d4f126ae/addons/mrp/models/stock_quant.py#L6-L11

As a result, each time users try to access the quant list, clean_reservation is triggered, causing a user error that prevents them from modifying the quantity of any quant.

Solution:
For kits, we can skip cleaning their quant to avoid unnecessary errors.

opw-4625002
opw-4624008
opw-4621175
opw-4625465
opw-4621504
opw-4623523
opw-4621508
opw-4623329
opw-4629386

In [1], the masonry_block snippet has been exploded into multiple 'sub-snippet'. But this had for consequence that when selecting a block of the snippet one too many option section was appearing because of this multiple level snippet.
(e.g: s_masonry_block > s_masonry_block_default_template > Block) Yet this middle level has no options on its own. so it was unnecessary to have an options section for the 'sub-snippets'. This commit just prevent to be able to select the 'sub-snippets'.

Furthermore, due to those 'sub-snippets' being contained inside the s_masonry_block snippet, they would not get registered in the list of all the snippets, and then the website would failed to determine their version which raised the 'outdated_snippet' alert. Preventing the selection of those 'sub-snippet' thus also prevent the website checking their version.
As of now none of these sub-snippets have different version than the basic s_masonry_block so I guess we can just ignore that since they are not designed to change from the basic s_masonry_block options. And if so should happen in the future they would probably become completely independant snippets.

Steps to reproduce :

- Enter edit mode
- Drag and drop a s_masonry_block snippet
- Select one of the blocks of the snippets
- On the options panel an errored 'Block' option section appeared.
- Click on 'access options anyway', the section is then empty.

[1] : https://github.com/odoo/odoo/pull/183755

task-4508767

### Issue:
- When we user-defined defaults based on company_id set on documents, they always trigger based on the user's default company instead of the current company.

### Steps to reproduce:
- In a multi-company environment say we have companies A(id: 1) and B(id: 2), and the user default company is A. (he has access to both).
- Create 2 user-defined defaults for the field : `documents.document.company_id`, setting value to 1 for company A and 2 for company B.
- Create a document using company B, the document's `company_id` will be set to company B which is wrong.

### Solution:
- in controllers `request.env.company` always returns the user's default company, so whenever we upload a document (call the `documents_upload` controller), `documents.document` create assumes that the current company is the user's default company.
- To fix this, we add the `allowed_company_ids` to the upload request params in the JS `DocumentService` and  we intercept in the python controller and set the `allowed_company_ids` context on the request to make sure create will use the current company instead.

OPW-4507424

Steps to Reproduce the Bug:
    - Install stock_picking_batch.
    - Go to Barcode > Operations > Delivery Orders > Batches.
    - Select any batch:
        - Click on the Parameters button > In the Operation section: - Click on Return Products.

Problem:
A traceback is raised:
"The method 'stock.picking.batch.action_create_return_picking' does not exist."

The function “action_create_return_picking” belongs to the “stock.picking” model, not to “stock.picking.batch” records. We are not supposed to be able to return products from a batch.

Moreover, even for “stock.picking” records, products can only be returned from done pickings. However, this button is displayed in all picking states except the done state:
https://github.com/odoo/enterprise/blob/2d5dbb93e6b33c2be786f9b2361c993f715d1a7f/stock_barcode/static/src/components/main.xml#L119

Solution:
Have the same condition for done pickings as in:
https://github.com/odoo/enterprise/blob/2d5dbb93e6b33c2be786f9b2361c993f715d1a7f/stock_barcode/static/src/components/main.xml#L165-L170

opw-4624039

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

When updating an allocation's number_of_days, a validation check is performed to ensure that we do not reduce the `number_of_days` to be less than the number of leaves that are taken by the employee. However this logic also takes into consideration any virtual leaves (leaves that are in the `confirm` or `validate1` state, ie. leaves that are awaiting an approval)  that may have been requested by an employee. These virtual leaves that are not yet approved should not count towards the calculation since it could be possible that the employer could refuse them or the employee's accrual plan could grant sufficient leaves if it is requested for a future date.


#### Current behavior before PR:

1. Setup a timeoff type that requires approval from the manager
2. Set up an accrual plan where an employee accrues '_N_' days of leave at the start of each year with **no carryover** (NOTE: the no carryover is the most crucial step because this is what writes the number_of_days on the leave allocation to zero)
3. Request a leave by an employee for any date after the carryover period.

What should have happened: The accrual should reset the leaves based on no carryover policy back to _N_ days 
However, it throws a validation error:

Now the issue happens because when we see that the carryover is none because of which:
1. The allocated leaves are set to 0 when calling this CRON (for no carryover): https://github.com/odoo/odoo/blob/cf18c4ac88919513a9f2b922d625fa5dc113cb39/addons/hr_holidays/models/hr_leave_allocation.py#L527
2. The leave that was requested by the employee but not yet approved causes the validation to fail. It is best explained in the below screen recording which uses the test case mentioned in the commit:

https://github.com/user-attachments/assets/f8914bac-815d-48c9-b4b2-c132a2fccbdb

![image](https://github.com/user-attachments/assets/cc2e221d-a725-4e9e-aaee-a054f644dff6)
![image](https://github.com/user-attachments/assets/8522bc81-5416-4bf0-ac71-bea1d2a133b8)


#### Desired behavior after PR is merged:

Virtual Leaves that are not yet approved would not block us from updating the allocation's `number_of_days`

opw-4442471

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

Forward-Port-Of: odoo/odoo#200000
Forward-Port-Of: odoo/odoo#198382

**Current behavior:**
Adding a product which is invoiced based on delivered
quantities to the delivery of a sale which has already been
confirmed, then validating the delivery, does not reflect the
change in price (which will be invoiced) on the sale order.

**Expected behavior:**
The sale order should show the actual amount of money to be
charged to the orderer.

**Steps to reproduce:**
1. Create a stored product with some price and change its
invoicing policy to 'delivery'

2. Create a new sale order, add 1 of the created product,
then confirm it

3. Open the delivery, add another line to it for the same
created product, fill in the quantities for each move, then
validate the picking

4. Check the sale order line to see that, while the price unit
is populated with the product's price, the subtotal/total fields
are not

**Cause of the issue:**
Order lines added in this manner have `product_uom_qty == 0`
which will zero-out the price computation.

**Fix:**
First, `_compute_purchase_price` is modified such that lines for
standard cost product will have a value computed (where
previously they were skipped).

Then for `_compute_margin`:
use `qty_delivered` and an on-the-fly calculated
`price_subtotal` to find a margin value for a SOL added from a
delivery (which is determined when `product_uom_qty == 0` and
`qty_delivered != 0`

opw-4210056

Forward-Port-Of: odoo/odoo#186236

Versions
--------
- 16.0+

Steps
-----
1. Have a cart ready to be paid;
2. open `/shop/payment` in two windows;
3. click "Pay now" in  one window;
4. click "Pay now" in the next window.

Issue
-----
Depending on version, installed modules & click speed, one of the following happens:
- Error: "The operation cannot be completed: Reference must be unique!"
- 500: Internal Server Error.
- Both payments get confirmed.

Cause
-----
There's no check on whether a payment is already being processed for a particular order.

This can happen in two manners:
1. The 1st one has finished, but the 2nd one is still allowed to start.
2. Clicking fast enough, both will try to transaction concurrently.

Solution
--------
1. If the `amount_total` is equal to `amount_paid`, raise an error.
2. Put a database-level lock on the Sale Order using `FOR NO KEY UPDATE` which will get released as soon as the payment transaction is committed to the database, or is rolled back due to failure.

opw-4555664

Forward-Port-Of: odoo/odoo#200428
Forward-Port-Of: odoo/odoo#198873

The Sales Details report in POS sometimes displays incorrect quantities due to floating point precision errors. This happens when summing product quantities that have decimal values, leading to unintended rounding inaccuracies in the report output.

Steps to Reproduce:
1. Create a sample product to be sold in POS.
2. Check the rounding precision set for the unit of measure for this product.
3. Open a new POS session and confirm an order with `14.9` quantities of the product.
4. Create another order for the same product, this time with `59.7` as the quantity.
5. Go to POS → Reporting → Sales Details, select the relevant POS, and print the report.
6. Issue: The generated PDF report incorrectly shows `74.60000000000001` instead of `74.6`.

The sum of product quantities was not respecting the unit of measure's decimal precision, leading to floating point inaccuracies in the report.

I Applied rounding to the quantity aggregation using the decimal precision of Product Unit of Measure, ensuring consistent and correctly formatted values in the report.

opw-4430513

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

Forward-Port-Of: odoo/odoo#198114
Forward-Port-Of: odoo/odoo#197755

Steps to Reproduce:

- Create two companies: A and B.
- In Company A, create a sale order for Company B with product P1.
- Confirm the sale order and navigate to the associated picking.
- Add a new product P2 and confirm the picking.

Issue:
No sale order line is created for the newly added move in the picking.

Technical Reason:

Before v17.2, intercompany transfers used the "Partner/Customers" location (type: "customer") as the destination. The logic for creating a sale order line checked move.location_dest_id.usage != 'customer', which correctly allowed the sale order line to be created. In v17.2, intercompany transfers now use "Virtual Locations/Inter-company transit" (type: "transit") as the destination. Since 'transit' != 'customer', the condition incorrectly bypasses sale order line creation. Fix:

Modify the condition to check if the destination location is either 'customer' or 'transit'. This ensures that sale order lines are correctly generated for intercompany transfers.

Task-4455830

Forward-Port-Of: odoo/odoo#197245

### Issue:

Currently, leaving the barcode app will split moves/move lines in the backend in order to keep track of the changes made on the move lines to match the next time you go into the barcode app.

#### Use case 1 (split move):
- Create a storable product P tracked by lot
- Adjust the onHand quantity to put 2 quants in stock:
    - quant1: Location: WH/Stock, lot_id: LOT0001, quantity: 3.0
    - quant2: Location: WH/Stock, lot_id: LOT0002, quantity: 3.0
- Create and confirm a Delivery order for 3 x P
> The move of the delivery should have reserved 3 units form LOT0001
- Enter the barcode app, scan you DO-name
- Scan your product barcode then scan LOT002 three times
- Leave the barcode app and come back
#### > The barcode line 3/3 was updated to 3/6: 0/3 LOT001 and 3/3 LOT002.

#### Use case 2 (split move line):
- Create 2 storable products P and COMP.
- Adjust the onHand quantity to put 10 units of COMP in stock.
- Create a bill of material for P with one line: - 1 x COMP
- Create and confirm an MO for 10 units of P.
- Set the qty_producing to 5 units -> 5 units of comp are reserved
- Enter the barcode app, scan you MO-name
- The component line should be 5/5 since 5 units are reserved.
- Adjust the registration to 1/5.
- Leave the barcode app and come back
#### > The barcode line 1/5 was updated to 1/1 and 0/9 instead of 0/4.

### Cause of the Issue:

In both cases, the problem comes from the fact we leave the barcode with a different reservation than the initial one.

In the first use case, a new move will be created with a quantity of 3 in order to handle the new line created with LOT002 as soon as you have scanned your products. Therefore even though you entered the barcode app with a reservation demand of 3 units you leave it with 2 move lines with a cumulative quantity of 3 + 3 = 6:
- line1: quantity: 3, lot_id: LOT001, picked: False
- line2: quantity: 3, lot_id: LOT002, picked: True The next time you enter the app you will therefore see a reservation demand of 6 rather than 3.

In the second use case however, a move line is simply created by the `split_uncompleted_moves` when you exit the barcode app: https://github.com/odoo/enterprise/blob/0f4e8ce54be746db02e9f4a6974e387d90608a08/stock_barcode_mrp/models/stock_move.py#L18-L29 
And the quantity of the new move line is based on the `prodcut_uom_qty` of the move rather than the initial reservation demand (quantity when entering barcode). This explains why reservation demand changed from 5 to 10 when you left and came back.

Enterprise: https://github.com/odoo/enterprise/pull/77068

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

Forward-Port-Of: odoo/odoo#193465

Changes are introduced to ensure compliance with the regulations
established by SUNAT in the context of inventory management,
specifically as outlined in Resolution No. 234-2006/SUNAT. Additionally,
functionality and data presentation improvements are included to
facilitate analysis and interpretation for end users.
Main Changes:
1. Initial Balance for the Period
  - The initial balance of products in stock at the start of the fiscal
    period is added.
  - Code is introduced to identify the initial balance.
  
![Captura de pantalla 2025-01-16 a la(s) 6 28 43 p m](https://github.com/user-attachments/assets/1ec83cc8-e8fd-4734-9d30-d06a39ce3196)
![Captura de pantalla 2025-01-16 a la(s) 6 28 52 p m](https://github.com/user-attachments/assets/de905b70-9adb-4ea5-a9b1-0f690b3e72f9)

2. Corrections in Inventory Valuation
  - Fields related to product entries and exits in inventory valuation are
    adjusted.
3. Optimized Presentation Order
  - A new sorting criterion is established for the records:
    - Priority 1: Sort by product code (column 7).
    - Priority 2: Sort by date (column 10).
  - This allows for better analysis and interpretation, as well as ensuring
    correct printing.
4. Delivery Guide Number as the Primary Indicator
  - Fields 11, 12, and 13 now use the delivery guide number as the primary
    indicator, complying with regulations.
  - This includes the delivery guide number corresponding to the transfer
    document, payment voucher, internal document, or similar.

Forward-Port-Of: odoo/enterprise#79404
Forward-Port-Of: odoo/enterprise#72064

### Issue:

Currently, leaving the barcode app will split moves/move lines in the backend in order to keep track of the changes made on the move lines to match the next time you go into the barcode app.

#### Use case 1 (split move):
- Create a storable product P tracked by lot
- Adjust the onHand quantity to put 2 quants in stock:
    - quant1: Location: WH/Stock, lot_id: LOT0001, quantity: 3.0
    - quant2: Location: WH/Stock, lot_id: LOT0002, quantity: 3.0
- Create and confirm a Delivery order for 3 x P
> The move of the delivery should have reserved 3 units form LOT0001
- Enter the barcode app, scan you DO-name
- Scan your product barcode then scan LOT002 three times
- Leave the barcode app and come back
#### > The barcode line 3/3 was updated to 3/6: 0/3 LOT001 and 3/3 LOT002.

#### Use case 2 (split move line):
- Create 2 storable products P and COMP.
- Adjust the onHand quantity to put 10 units of COMP in stock.
- Create a bill of material for P with one line: - 1 x COMP
- Create and confirm an MO for 10 units of P.
- Set the qty_producing to 5 units -> 5 units of comp are reserved
- Enter the barcode app, scan you MO-name
- The component line should be 5/5 since 5 units are reserved.
- Adjust the registration to 1/5.
- Leave the barcode app and come back
#### > The barcode line 1/5 was updated to 1/1 and 0/9 instead of 0/4.

### Cause of the Issue:

In both cases, the problem comes from the fact we leave the barcode with a different reservation than the initial one.

In the first use case, a new move will be created with a quantity of 3 in order to handle the new line created with LOT002 as soon as you have scanned your products. Therefore even though you entered the barcode app with a reservation demand of 3 units you leave it with 2 move lines with a cumulative quantity of 3 + 3 = 6:
- line1: quantity: 3, lot_id: LOT001, picked: False
- line2: quantity: 3, lot_id: LOT002, picked: True The next time you enter the app you will therefore see a reservation demand of 6 rather than 3.

In the second use case however, a move line is simply created by the `split_uncompleted_moves` when you exit the barcode app: https://github.com/odoo/enterprise/blob/0f4e8ce54be746db02e9f4a6974e387d90608a08/stock_barcode_mrp/models/stock_move.py#L18-L29 
And the quantity of the new move line is based on the `prodcut_uom_qty` of the move rather than the initial reservation demand (quantity when entering barcode). This explains why reservation demand changed from 5 to 10 when you left and came back.

Community: odoo/odoo#193465

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

Forward-Port-Of: odoo/enterprise#79444
Forward-Port-Of: odoo/enterprise#77068