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

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