Issue
-----
In barcode processing reception of subcontracted products doesn't create a back order for the remaining products.

Steps to reproduce
-----
- Create 2 products, one subcontracted and one storable
- Create a purchase order for the 2 products & confirm it
- Go to barcode and open the delivery
- Only validate the reception of the subcontracted product

--> No backorder is created for the remaining product, it is considered received

Cause
-----
Commit db8b33e changed the compute of the move's picked status to not update for subcontracted moves. So the move line has picked set to True but not the move itself.

When we validate the operation in barcode, we go through this pre hook https://github.com/odoo/odoo/blob/1d256123da587d625c0527ca3a18cd82e7161df5/addons/stock/models/stock_picking.py#L1193

Since the move has a quantity but picked is still False, the full picking is being picked at once

https://github.com/odoo/odoo/blob/1d256123da587d625c0527ca3a18cd82e7161df5/addons/stock/models/stock_picking.py#L1206-L1207

-----
Ticket:
opw-4726229

Forward-Port-Of: odoo/enterprise#89255
Forward-Port-Of: odoo/enterprise#86979

When clicking the `Process Follow-ups` button after creating a due invoice, a traceback could occur due to missing data on the related records.

Steps to reproduce:
---
- Install `account_followup` module(without demo)
- Go to `Follow-up Levels` and enable SMS in `15 Days`
- Create an invoice with Invoice Date(2 months ago) and Payment terms: `15 Days`
- Now, click on the selected customer and fill in all important details
- In the action button, click `Process Follow-ups`

Traceback:
---
```
KeyError: 'mobile'

ValueError: KeyError('mobile') while evaluating
'if records:\n                    action = records.action_manually_process_automatic_followups()'
```

The mobile field was removed from `res.partner` (see related commit), but it was not removed from here. This commit cleans it up to avoid referencing a non-existent field.

commit- https://github.com/odoo/odoo/commit/6b820eb6fc6f782ba6a83d605d87b4a1dd2a87be

sentry-6720070075

Forward-Port-Of: odoo/enterprise#89241

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

Steps to reproduce:
1. Connect IoT Box and any printer that accepts PDF
2. Turn on Reception Report option on Inventory Settings
3. Set configuration of Receipts to print out Reception Report and Label
4. Assign Reception Report and label to the printer
5. Create a PO and run through the Reception process (PO > Reception of Delivery)
6. Print the Reception Report under "Allocations"

-> Result: Reception Report and label is downloaded as a PDF instead of
   being sent to the printer.

The reason for this bug is that the report models were being constructed directly in the frontend, rather than being fetched from the backend. This didn't work with IoT printing because its override used to assign devices to reports is on the backend `ir.actions.report` model.

The fix is to fetch the report from the backend when the component is loaded. This report is then passed down to the child components as well.

opw-4790299

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

Forward-Port-Of: odoo/odoo#215887

Steps to reproduce:
1. Connect IoT Box and any printer that accepts PDF
2. Turn on Reception Report option on Inventory Settings
3. Set configuration of Receipts to print out Reception Report and Label
4. Assign Reception Report and label to the printer
5. Create a PO and run through the Reception process (PO > Reception of Delivery)
6. Validate the Reception of the order

-> Result:
   Odoo will prompt the customer to select a printer, however we are not able to choose a printer in time as the process continues without selecting one. This in return does not send the report to the printer via IoT.

The root cause of this bug is that the IoT report handler JS function returns too early, it resolves once the printer selection popup has appeared, instead of resolving once the printer has actually been selected and is starting to print. Therefore the multi-report printing code assumes the print is done and triggers the next print, which causes the popup to close before the user can select a printer.

To solve this bug, we listen for a 'printer-selected' event in the handler, and resolve only once we have received this event. This fixes the flow, allowing a printer to be selected for each report that is being printed in sequence.

opw-4790299

Forward-Port-Of: odoo/enterprise#88538

### Issue:
It is possible to break the followup reports by directly creating entries in the past.

### Steps to reproduce:
- Example on Belgian loca
- Accounting Dashboard > Misc > new Entry with
	- Date far in the past (ie 2024-01-01)
	- Account: "400000 Customers", Partner: "test partner", Debit: 500.0
	- Account: "499000 Suspense Accounts", Credit: 500.0
- Post
- In Customers > Follow-up reports, the partner is marked as "In need of action" even if no due date was specified
- Accounting Dashboard > Bank > new with Amount: 500.0
- "Save & Close" then click on it
- In the page "Manual Operations" change the partner to the one from the MISC entry
- Change the Account to "400000 Customers"
- Validate
- The follow-up report is no longer "In need of action"
- Create an invoice with a due date in the future
- The follow-up report is back to "In need of action" with the amount of the invoice
- When sending the follow-up, the Customer statement reads "your account shows an outstanding balance of 0.00€"

### Cause:
The origin of this issue is that the MISC entry and the Bank payment are not reconciled. The MISC entry is used to calculate the state of the followup making it to "In need of action" but the bank entry is balancing the amount to 0.00€.

The MISC entry should not be used to compute the followup state as it has no due date specified (it makes no sense, it is never linked to any invoice). But in the code when there are no `line.date_maturity` we fallback on `line.date`.

### Solution:

So we remove the fallbacks on `line.date` when `line.date_maturity` is False. Some tests needed to be adjusted as they were not using any payment terms or due date. They were working because of the fallback on `line.date`.

opw-4784250

Forward-Port-Of: odoo/enterprise#87873