**Steps to reproduce:**
- Set up CRM / Appointment / Website apps
- Create new company (2)
- Create partner contact with specific email and the new company
- Create appointment type linked to a staff user of another company (1) who has no access to the new one
- Enable `Create Opportunities` on the new appointment type
- Go to the website as an anonymous user
- Submit an appointment request using the partner's email
- `Incompatible companies on records:` error

**Issue:**
Previous solution (17.0) was trying to use existing partner if the email was provided and existed in the database
 `customer = request.env['res.partner'].sudo().search([('email_normalized', '=', email_normalized)], limit=1` 
This means that, in a multi-company environment, the lead created by the new appointment for the appointment user of company 1 can be linked to the partner contact of company 2 and throw an error on validation.

**Fix:**
Restricted partner search domain using current allowed companies using the `staff_user` or the user which created the `appointement_type`.

opw-4713060

Forward-Port-Of: odoo/enterprise#89196
Forward-Port-Of: odoo/enterprise#84006

Previously, marketing campaign testing (through debug) could cause
an issue where tracked links could cause a traceback if a marketing
activity was edited after a test was attempted.

To work around this, #13665 deactivated link tracking in marketing
campaign tests. However, this meant that flows including click actions
could no longer be tested.

As this issue has been resolved in odoo/odoo#48845, this commit
reverts https://github.com/odoo/enterprise/pull/13665 to once again
 permit marketing automation testing.


--

Additional changes are needed to fix other issues:
Tests using one's own coordinates are prone to breaking due to newer
mailing traces attaching themselves to the oldest marketing trace.

This commit makes it so that marketing campaign tests for the same
marketing campaign and coordinates cannot run concurrently, by
cancelling older test campaigns upon starting a new one.

Different tests can still run concurrently on distinct partners/leads/
etc.

Additionally:
- Running tests are now visible on campaigns in the "New" state;
- Activities don't mark themselves as needing sync unless their campaign
is in the "Running" state.

task-4557855

Forward-Port-Of: odoo/enterprise#89473
Forward-Port-Of: odoo/enterprise#78793

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

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