### Issue -->

The final step of the `_action_merge` method updates the `code` field of the account onto which the other accounts are merged. During the write call on `code`, a dependent field `always_tax_exigible` on `account.move` gets added to the compute chain. This causes a fetch of all `account.move` records related to journal items related to the account that is getting updated. This can lead to a MemoryError on databases with large `account.move` tables.

### Solution -->

We delegate the write of the `code` field to SQL.

In the account merge wizard, accounts that can be grouped are grouped by the keys --> `'account_type', 'non_trade', 'currency_id', 'reconcile', 'deprecated','name'`. Therefore, the `account_type` does not change after the merge. We can safely assume that any fields dependent on `account_type` do not need recomputation and hence, bypass the ORM for this update.

### Benchmark -->
For an account with ~1.17M related `account_move_lines` and ~570k `account_moves`, 

| Before Fix | After Fix |
|--------|--------|
| TO/Memory error past TO | ~24s | 


#### Additional change -->

Disable the prefetcher in the write call in `account.account` to optimize memory usage on databases with a large number of journal items/journal entries when writing on `code` or `account_type` in general.

opw-4839985

### Steps to reproduce:
- Install l10n_hu_edi and witch to Hungarian company
- Have two different rates for EUR<->HUF
- Create a pricelist in EUR
- Create a quotation with the pricelist and confirm
- Validate the delivery on another date (which has a different rate from today)
- In the sale order click "Create Invoice"
- The generated invoice has lines using the rate for today

### Cause:
The field `delivery_date` was `precompute=True` but on creation of the invoice, at the time of the precompute, `line_ids` is still `False`.
So the invoice is first computed without the delivery date so the currency rate used is the one of the invoice date. When the delivery date is written on the invoice, the line balance is not recomputed because it is "protected".

### Solution:
As the field `delivery_date` was implemented in `account_move` for localizations including l10n_hu, there are no reason to contain the fix only to l10n_hu.
So we add the value of `delivery_date` in the dictionnary used to create a new invoice from sale with the method `_create_invoices`. This way the delivery date is there on creation of the invoice and is used for the currency rate.

opw-4756568

<b>Steps to Reproduce:</b>
1. Go to Settings > Companies > Configure Document Layout.
2. Choose layout Boxed or any layout that horizontally places the company logo and address.
3. Edit the address block choose long string.
4. Save the layout and click Preview Document or print SO or invoice.

<b>Issue:</b>
- Observe in PDF output the long text overlaps into logo or extend outside the layout bound(differ in layouts) — even though enough space is visually available

<b>Cause:</b>
- A previous change in [PR #201198](https://github.com/odoo/odoo/pull/201198) added the text-nowrap class to address blocks to fix a minor wrapping issue. However, this unintentionally caused layout overflow issues with long lines.

<b>Solution:</b>
- Added width to the address block to ensure balanced layout structure.
- Removed text-nowrap from all layouts, as the original issue is now resolved by applying proper width sizing.
- Removed float-end from Boxed layout, as it was contributing to misalignment.

<b>Additional Notes:</b>
All behaviors addressed by  [PR #201198](https://github.com/odoo/odoo/pull/201198) were re-tested to ensure this fix does not reintroduce previous issues.

<b>opw-4764975</b>
<br>
<b>[PR #201198](https://github.com/odoo/odoo/pull/201198) ISSUE : </b>

![image](https://github.com/user-attachments/assets/789e8c9e-0e24-4e2b-8ba6-9421ab02eaf8)
<br>
<b>ISSUE after [PR #201198](https://github.com/odoo/odoo/pull/201198) FIX:</b>

Folder - ![image](https://github.com/user-attachments/assets/176bfe25-ddbc-4774-bed3-b21eddacbb2c)
Boxed - ![image](https://github.com/user-attachments/assets/e45c37f5-8040-47c6-988c-bf2e7a175400)
<br>
<b>After this PR FIX : </b>

![image](https://github.com/user-attachments/assets/f1eb0d39-3e3b-469e-a978-2637107ba606)
![image](https://github.com/user-attachments/assets/df254c8d-8f0c-486f-ac4e-ec04f3b9e8a1)
![image](https://github.com/user-attachments/assets/315d5854-6ea2-4f0d-8a34-e86ea9e020db)
![image](https://github.com/user-attachments/assets/e582845e-2704-413f-af2b-0bf8bd8977a8)

### Steps to reproduce:
- In the settings enable by-products
- Create a product FP with a bill of material:
	- 1 operation: op 1
	- 1 By-product line: cost share 3.3%, produced in op 1
- Create aand confirm an MO for 1 unit of FP
- On the by product line produce 10 instead of 1
- Produce All
#### > 19 units of by products were produced: The initial by-product move was validated for 10 units and an extra move with a quantity of 9 was automatically created and validated aswell.

### Cause of the issue:

Since the quantity of the by-product move exceed its initial demand, its validation will create an extra move that is expected to be merge into the main move during its confirmation:
https://github.com/odoo/odoo/blob/474ac02d03c17af0274422ecb1e97ca14a3e80e7/addons/stock/models/stock_move.py#L1922 https://github.com/odoo/odoo/blob/474ac02d03c17af0274422ecb1e97ca14a3e80e7/addons/stock/models/stock_move.py#L1844-L1865 However, while `cost_share` value of the original move floats is correctly encoded as 3.3, the copied value of the extra is 3.3000000000000003. This discrepency is a well known issue of the way the orm handles float and convert them to cache as it calls the `float_round` method, which can effectively change its value: https://github.com/odoo/odoo/blob/8c22e358840f02c5b1596e1fbe0d6cf7315754f7/odoo/fields.py#L1553-L1557 In particular, the `cost_share` of both moves differs in terms of strict equality and the move will not be merged with its extra move.

### Note:

The issue should not be reproducible in saas17.4+ because the float_round issues have been erased by
commit 784f1511acc4352905a61f9bd90aecb78e8558ec

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

Forward-Port-Of: odoo/odoo#215372

Currently, with an MTSO rule, the smart button from the Sale Order
to the Manufacturing Order was available. However, the reverse link
(from the MO to the SO) was missing.

But they share the same link between object and people don't
understand. So we copy the condition to have the same SO<->MO
link.

It was missing the sale_id on the procurement group itself. Before
production.procurement_group_id.move_dest_ids.group_id.sale_id
was enough since mtso share move links but with the new MTSO it's
not the case anymore. But the sale_id is copied from a procurement
to the new ones.

Steps to reproduce:
- Enable multi-step routes in Inventory settings
- Unarchive the MTO route:
    - Select the rule with the production usage
        - Set its supply method to "MTSO"
- Create a storable product “P1”:
    - routes: MTO + Manufacture
- Create and confirm a Sale Order with one unit of P1
- Confirm the SO

Problem:
The smart button from the SO to the MO appears correctly,
but the reverse link from the MO to the SO is missing.

opw-4619136
opw-4557138
opw-4875937
opw-4854581
opw-4887746

## Before this commit:
When calculating the `price_unit` for stock moves from purchase order lines, the `remaining_qty` and `remaining_value` could be imprecise. Standard float comparisons for these remaining amounts could lead to incorrect `price_unit` calculations if, for example, `remaining_qty` was a small float near zero. This could result in inaccurate stock valuations, particularly when currency conversions were involved or when landed costs were applied.

For example, 70.00000003 is rounded **up** to 70.00001 (with 5 digits), resulting in a quantity difference of 0.00001, which incorrectly inflates the unit cost.

## After this commit:
Change the rounding method to 'HALF-UP' instead of the default 'UP' to improve precise result for quantities.

## Steps to reproduce:
1. Configure a product with AVCO real time. Set decimal precision for price and UoM to 5 digits.
2. Create a Purchase Order (e.g., 190 units @ $110/unit).
3. Receive 70 units and create a backorder
4. Create and post a bill for the initially received quantity.
5. Apply a landed cost to the picking of the first 70 units.
6. Create a draft bill for the remaining quantity on the PO.
7. Receive the remaining 120 units from the backorder.
8. The product's cost explodes

opw-4705224

Forward-Port-Of: odoo/odoo#216661
Forward-Port-Of: odoo/odoo#208815

#### Step to reproduce:
  - Enable Analytic accounting in Accounting settings
  - Create a sale order
  - Show Analytic Distribution
  - Create an expense and put this sale order in the "Customer to Reinvoice" field.
  - Add an Analytic Distribution
  - Create Report
  - Submit to Manager
  - Approve
  - Post Journal Entries

#### Curent behavior:
  - No analytic_distribution on the sale_order

#### Expected behavior:
  - analytic_distribution form the expense should be copied to the sale_order

#### Cause:
  analytic_distribution was not set at the creation of the sale order from the account_move

`_sale_get_invoice_price()` is called only in `_sale_create_reinvoice_sale_line()` which is only called in `_prepare_analytic_lines()`. According to [this note](https://github.com/odoo/odoo/blob/18.0/addons/sale/models/account_move_line.py#L31-L32) `_prepare_analytic_lines()` is called only on `move.line` having an `analytic_distribution`. 

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4710137)
opw-4710137

**Steps to reproduce:**
- Install Contact app
- Create a contact with a specific address
- Go to the Map View of the Contact app
- Filter to view the new contact
- Position in the map might be slightly different from given one (when using OpenStreeMap)
- Click on the position marker > `Navigate To` the address is recomputed correctly
- Click on `View in Google Maps` the address given is often wrong

**Issue:**
Previous solution was trying to build the url used by the `View in Google Maps` button by using `partner_latitude` and `partner_longitude`. These were previously computed using the default geolocalization method. If it was set on OpenStreetMap, the coordinates were not precise enough and impacted the Google Maps results.

As described in the documentation : `OpenStreetMap might not always be accurate.` But this shouldn't impact Google Place API results.

**Fix:**
Adapted the computation of `googleMapUrl()` to use `contact_address_complete` to ensure the addresses are recomputed properly when sent to Google Maps.

opw-4649910

**Issue**
When the delivered quantity of a product is less than the originally demanded quantity, the generated Delivery Guide XML shows the demand (product_uom_qty) instead of the actual delivered quantity (quantity). This results in an incorrect quantity being displayed in the DTE.

**Steps to Reproduce**
1. Install the Accounting module, Chilean localization, Sales module, and l10n_cl_edi_stock.
2. Create and confirm a new Sale Order.
3. Click on the Delivery smart button.
4. Adjust the delivered quantity to a value lower than the demand, save, and validate with no backorder.
5. Generate the Delivery Guide.
6. Open the generated DTE XML and observe that the quantity is incorrect.

**Root Cause**
The quantity displayed in the DTE is taken from product_uom_qty, which represents the planned quantity to be moved, not the actual delivered quantity. The correct field to use is quantity, which reflects the real delivered amount.

**Fix**
Change the XML output to use quantity instead of product_uom_qty to accurately reflect the actual delivered quantity in the DTE.

Opw-4892276

**Problem:**
when the product in the sale order linked to a field service task is a kit and the task is marked as done, the delivery is not validate (as it would for a non kit product)

**Steps to reproduce:**
- Create a product and set up a Kit-type Bill of Materials for it (with at least two components)
- Create a service-type product.
- Set the Invoicing Policy to Prepaid/Fixed
- set the "create on order" field to Task
- assign the Project to Field Service.
- Create a Sales Order using the service product.
- Confirm the Sales Order.
- In the linked task, click on the Products smart button
- add the kit-type product from step 1.
- Mark the task as done.

**Current behavior:**
On the sale order, the delivered quantity for the kit product is 0.
If you click on the delivery smart button, you'll see that the picking is not validated yet

**Expected behavior:**
the picking should be validated

**Cause of the issue:**
https://github.com/odoo/enterprise/blob/d8dc0cabd83a29d0522cb5fd25c6956968d4408b/industry_fsm_stock/models/project_task.py#L23 the orer_line is considered as an exception because the order_line product_uom_qty is smaller than total_qty (the sum of the move_ids' product_uom_qty)
But this is normal in the case of a kit

opw-4848444

Forward-Port-Of: odoo/enterprise#88363

### Steps to reproduce:

- Configure the sendcloud delivery method (for instance with Bpost @home for a belgian company) and enable the `Use Batch Shipping`` option on the delivery method.
- Create a storable product with a weight of 1 kg and a positive volume.
- Create and confirm sale order for 4 units
- Add shipping -> chose sendcloud
- Separate the delivery of 4 kg in 3 packs:
    - set quantity to 1 -> put in pack
    - set quantity to 2 -> put in pack
    - set the quantity to 4 -> put in pack
- Try to validate the delivery
#### > invalid operation:  weight: "A valid integer is required."

### Cause of the issue:

Sendcloud's api only accept integer values for the weight: 
![api](https://github.com/user-attachments/assets/7080094f-debd-4620-84e6-63e97e868508)

However, to evaluate the price of the parcel accurately for a batch shipping we need to compute the average weigth to provide to sendcloud. Converted to grams we tehrefore provide a value of 1333.333333 to sendcloud which raises an invalid operation:
https://github.com/odoo/enterprise/blob/72b4a223ec4e2e09fc93bebd150923abba37a8df/delivery_sendcloud/models/sendcloud_service.py#L378-L379 https://github.com/odoo/enterprise/blob/72b4a223ec4e2e09fc93bebd150923abba37a8df/delivery_sendcloud/models/sendcloud_service.py#L205-L207 https://github.com/odoo/enterprise/blob/72b4a223ec4e2e09fc93bebd150923abba37a8df/delivery_sendcloud/models/sendcloud_service.py#L44

opw-4874063

Forward-Port-Of: odoo/enterprise#89495

# [FIX] account_inter_company_rules : prevent auto invoice creation from bill (synchronize transactions)

Before this fix, when the Inter-Company Transactions was set to `Synchonize invoices/bills`, an invoice was created for a bill when the contact's company for an employee was the invoice's company.

The invoice should be only created when there is an inter-company transaction, not an inner one.

Two tests as been added to test the case with the same or another company in the contact form.

## Steps :
- Create a database with 2 companies
- Create an employee in company 1
- Set employee's company in Contacts to company 1
- Go in Settings with company 1
- Set Inter-Company Transactions to `Synchronize invoices/bills`
- Go in Expenses and create a New one
- Add what you want for title and price, then select the created employee
- Use the buttons : Create Report > Submit to Manager > Approve > Post Journal Entries
- A bill is created and can be accessed using the smart button 'Journal Entry'
- A draft invoice can be found in Accounting

opw-4818456

Forward-Port-Of: odoo/enterprise#87757