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

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