Issue:
--------
While having multiple companies, multiple warehouses and when different warehouses are set for different companies other than the first one(id=1) under Inter-Company Transactions "Use Warehouse".
Now, when we check the 'Generate Purchase Orders' then the 'Use Warehouse' value which was set before  is getting overridden to the first Warehouse which has minimal 'id'.

Cause:
------
[Here](https://github.com/odoo/enterprise/commit/6324a6bab04fa0f3aa6d87deabc44c7c2eafc295#diff-51563a07f4b65f4ffe54bfb161ac1e9e58ff0f0bcf2522c9f6aa3746b60a68adR28-R38) Since, whenever there's a change within any of those check-boxes the compute will be triggered and the values will get modified. During this trigger the value set in the 'Use Warehouse' is getting overridden to the warehouse with minimal 'id'(For ex: id-1).

Solution:
-----------
To fix this, we'll just check if there's no value set before. If yes, then we'll
 set the first warehouse which has minimal 'id'. Otherwise, set the one
which is selected.

Steps to reproduce:
-------------------------
1. Create a fresh db with multiple warehouses and 'sale_purchase_stock_inter_company_rules' module installed.
2. Go to General Settings> Inter-Company Transactions and check/select 'Generate Sale Orders' and set a different warehouse and save.
3. Now check/select the 'Generate Purchase Orders' and save.
4. Look at the Use Warehouse value in the Settings. It will be the first one with minimal 'id'.

Ref PRs:
1. https://github.com/odoo/enterprise/pull/55350

Forward-Port-Of: odoo/enterprise#87276

### Issue:
When importing a CSV file with bank statements, if an error is raised during the reconciliation, the creation of the bank statement lines is roll backed.

### Steps to reproduce:
- Install "account_bank_statement_import_csv"
- In the bank journal configuration:
	- Set the "Outstantding Receipts accounts" of "Manual payments" to a "Bank" account
	- Set the "Outstantding Payments accounts" of "Manual payments" to the same "Bank" account
- Create a new transaction for $333.0 for example
- Find its Journal Entry and change its reference to 'testref'
- have a CSV file like this:
```
label, amount
testref,333
```
- Import this file
- Make sure label is linked to label and amount to amount
- Import
- An error shows, no lines are imported

### Cause:
On import, we try to auto reconcile the lines using `_cron_try_auto_reconcile_statement_lines` ([here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L146)). If an error occurs during the reconciliation, we call `self.env.cr.rollback()` [here](https://github.com/odoo/enterprise/blob/843a17367525c80653d37ecdd9d87434d3e92454/account_accountant/models/account_bank_statement.py#L190-L192).

This rollback cancels the transaction, including the creation of the statement lines.

### Solution:
If the error raised is a `UserError` then we don't roll back and just ignore it. This causes no issues as we caught all exceptions to always continue the reconciliation with the next batch. For UserErrors we should let the user reconcile manually afterward.

Also, as the rollback can undo the creation of `st_lines`, we add `if st_lines.exists():` before writing on the variable.

Test is not possible as we don't roll back during tests. 

opw-5138855

Forward-Port-Of: odoo/enterprise#99073

Steps to reproduce
-----
- Create a SO with a sendcloud delivery
- Create an invoice for a down payment & confirm it
- Go to the delivery and validate it
> Traceback

Cause
-----
Creating a down payment adds lines to the SO

https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/addons/sale/wizard/sale_make_invoice_advance.py#L163-L165

When we confirm the delivery, we retrieve the price of products for customs.

https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L515-L520

To do this, we iterate over the SOL and skip lines where the product qty is 0

https://github.com/odoo/enterprise/blob/f1a385e44ff9cb0e6a6c50c743762fb45329c957/delivery_sendcloud/models/sendcloud_service.py#L525-L528

The problem is that the down payment SOL has no uom. This means that when we do

`float_is_zero(line.product_uom_qty, precision_rounding=line.product_uom.rounding)`

precision_rounding is `0.0`. So when `float_is_zero` calls `_float_check_precision` we go through

https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/odoo/tools/float_utils.py#L33-L36

where the assert is false, creating the traceback.

-----
Ticket:
opw-5207574

Forward-Port-Of: odoo/enterprise#99178

Steps to reproduce:
- Enable Analytic Accounting.
- Assign a project A to User A.
- Create user B with Manufacturing User + Timesheet User rights.
- Create a storable product “P1” with the following BoM:
    - Component: 1 unit of C1
    - Workorder: Operation of 60 minutes
    - Project: Project A
- As user B:
- Create a mo to produce one unit of “P1”
    - confirm the MO
    - start the workorder and try to mark it as done.

Issue:
An access error is raised when creating analytic lines:
"Sorry 'user B' doesn't have read access to account.analytic.line"

Explanation:
Since the project is assigned to Mitchell Admin and not to Marc Demo,
the access rule below applies:
https://github.com/odoo/odoo/blob/19.0/addons/hr_timesheet/security/hr_timesheet_security.xml#L50-L62

Because Marc Demo belongs to the "Timesheet User" group but not to
the "Accounting" group, he lacks the required access rights,
which triggers the analytic line read restriction.

opw-5262213

Forward-Port-Of: odoo/enterprise#99716

before this commit, when trying to reprint a past order it would not work. Instead it would print the last order no matter what order is selected.

Steps to reproduce:
1. setup an DB with an italian POS
2. make 2 sales with a different product (easier tracking)
3. open the "orders" view
4. try to reprint the ticket of the firt order result: the receipt of the second order is printed

the reason for this is that we were using the printer's built in command "printDuplicateReceipt" which is inteded for printing the very last receipt.

With this commit, we changed the behavior and invoke another printer command. That command is meant to reprint any receipt, based on the provided reference. After this commit, trying to print any past receipt will print that exact receipt.

IMPORTANT NOTE:
In theory, the printer command can reprint any number of receipts. We decide that we will only use it to reprint the one receipt selected by the user. This moves the complexity of parsing date strings and ranges to the command component and therefore will keep the rest of the code cleaner.

opw-5008702
opw-4882480

Forward-Port-Of: odoo/enterprise#99842
Forward-Port-Of: odoo/enterprise#96122