Versions
--------
- 18.0+

Steps
-----
1. Enable rental transfers;
2. have a rental product with a kit BoM;
3. create a subscription order in the Rental app;
4. add the rental product;
5. confirm order;
6. validate deliveries;
7. close the subscription.

Issue
-----
Invalid SQL command, cannot return more than was delivered.

Cause
-----
When closing or reopening a subscription, the `_compute_qty_delivered` method gets triggered. By default, these methods required the relevant moves to have the same `product_id` as the sale order line.

For products with kit BoMs, the move's `product_id` is tied to the BoM instead of the final product, leading to `qty_delivered` getting reset reset to 0 on recompute.

This causes an error, as `qty_returned` is non-zero.

Solution
--------
The `qty_delivered` for these lines was set in the `_action_done` method of `stock.move`. By instead moving this logic into a `_compute_qty_delivered` override, any recompute should have the same result, instead of getting reset to 0.

opw-4833280

Forward-Port-Of: odoo/enterprise#88691

Currently an error occurs when the **'Payroll: Generate pdfs'** scheduled action runs and tries to create a document for a payslip belonging to an employee who does not have a related partner.

**Prerequisites:**
- Ensure HR is enabled in `settings>Documents`

**Steps to Reproduce:**
1) Install `documents_hr_payroll` module.(with Demo) 
2) Navigate to the Employees App.
3) Select any Employee(e.g Abigail Peterson) and open form view.
>- click on **contacts** smart button.
>- Delete that Record
4) Create a confirmed Payslip for the selected Employee(e.g Abigail Peterson). 
5) Activate Developer mode and navigate to schedule Actions.
>- Search for 'Payroll: Generate pdfs'.
>- Run Manually.

Error:
`NotNullViolation: null value in column 'partner_id' of relation 'documents_access' violates not-null constraint`

Root Cause:
When the partner is deleted, the value received from `_get_document_partner` at [1]
is `False`, which later on tries to create the `documents.access`
record for the new document, it fails because no partner is available to assign
access rights, resulting in the error.


Solution:
This commit prevent Error by ensuring `_check_create_documents` method doesn't allow document creation without valid partner.

[1]: https://github.com/odoo/enterprise/blob/99a8d83edb42f172d0dd35c91743fa0c9653dcbb/documents_hr_payroll/models/hr_payslip.py#L20C1-L21 

sentry-6814524392

Forward-Port-Of: odoo/enterprise#92865

Currently, an error occurs when user editing the budget report items.

Steps to Reproduce [Video](https://drive.google.com/file/d/1bz0GEQjwxQrckzcEHdYPfvaA5M43lmFF/view):
 - Install the `Accounting` module.
 - Go to `Profit and Loss` > `Budget` and `create a budget`.
 - Select `custom dates (e.g., start: 01/01/2025, end: 12/10/2025)` and change the amount of a budget line.
 - Change the `date range (e.g., start: 01/10/2025, end: 12/10/2025)` and change the amount again.
 - `Switch back to the first date range` (start: 01/01/2025, end: 12/10/2025) and try changing the amount once more.

`TypeError: unsupported operand type(s) for +: 'float' and 'NoneType'`

This error occurs when a user editing the budget report items. When user enters a date period, the system creates budget items for the first date of every month within that range. If the user then changes the date period to the next date of the same month, the system attempts to fetch the existing budget item `[1]` for that range. However, due to the start date alignment, it fails to fetch the correct budget item and instead creates an extra one `[2]`. Later, when the system checks again from the first date of the same month as the start date, it finds this extra budget item, for that the amount is None, which raises the error `[3]`.

This commit ensures that when fetching existing items and generating the start month dates `[4]`, the system always uses the first day of the month as the `start date` so that the flow is maintained..

[1]- https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L44-L49

[2]-
https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L75-L79

[3]- https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L72

[4]- https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L58-L61

sentry-6883207225

Forward-Port-Of: odoo/enterprise#95090

This PR fixes two related bugs happening when printing a receipt with the Italian Fiscal printer
First, before this PR, if the option to skip the receipt screen
was ticked, then the receipt would never print.
This was caused by the printing logic being implemented on
the receipt screen instead of on the pos itself.

steps to reproduce:
1. install l10n_it_pos
2. configure one pos
3. configure the IT printer
4. select to skip the receipt screen (print automatically)
5. open the pos
6. make a sale
=> no ticket printed and the chrome console shows a printer error

With this new verison the printing logic was moved to the pos
so that printing of fiscal receipts with the italian fiscal printer
works, even when receipt screen is skipped.

This put to light another potential bug related to how the `order` variable was treated.
Before this PR, the printReceipt logic in the module would not
pass the order to be printed.
This can become a problem upon context changes, where `pos.get_order()`
does not return the completed order, but a newly created one.
This can for example happen when skipping the receipt screen with
the option to "print automatically" (iface_print_auto).

After this PR, we keep order as an argument, so we always print
the last completed order and not a newly created one.

opw-4882480

Forward-Port-Of: odoo/enterprise#91412

**PROBLEM**
Insuring a delivery using the dhl carrier don't work. It doesn't affect the estimated rate of the delivery, and the shipment created when validating the delivery order isn't insured.

**STEP TO REPRODUCE**
1. Install the `delivery_dhl_rest` and the `l10n_be` modules (we will use the be demo company).
2. Set the insurance percentage of the dhl be delivery method to 100%, and set the region to Europe (the demo data is incorrect), and activate the debug (click the "No Debug" smart button to activate the log of requests).
3. Switch to the be company.
5. Create a sale order, with a customer located in Belgium, and add shipping using the dhl method.
6. Go to the delivery order, and validate it.
7. Go to settings/Technical/Logging and look at the rating_request and shipment_request, notice there is no information about insurance.

**CAUSE**
We don't send any info about insurance in the api requests.

**FIX**
Computing and sending the insured amount, only if the insurance percentage is not null.
If the package can't be insured between the origin and the destination, a error message will be displayed when updating the delivery price.

**TESTS PROBLEM/FIX**
The localization of `your_company` was not recognized by DHL, leading to the DHL api returning a 0 delivery price.
Switching the localization to Eghezee, Rue du Laid Burniat 5 fixes this.
Assertion regarding the delivery price were restored.

The picking date could sometimes be refused by DHL (stop working after arround 4/5 PM).
Changing the picking date to, two day after, at noon works.

`test_01_dhl_basic_be_domestic_flow` was modified to also test domestic shipment insurance in addition of the basic flow.
Some code in it was refactor into inner function to avoid boilerplate.

Adding `INSURED_RATE_MOCK_RESPONSE` to mock response in test_01.

opw-4989281

Forward-Port-Of: odoo/enterprise#93105