**Current behavior:**
With anglo saxon accounting and real-time valuation, purchasing
a kit product with a BoM that has components whose costs add up
to the exact price of the kit product and that is invoiced on
ordered qty and has avg costing, then billing before receiving
will prevent the reception from being validate-able.

**Expected behavior:**
Can validate

**Steps to reproduce:**
1. Create a kit product with avg costing, invoiced on ordered
qty, and a BoM with 2 components that have a cumulative cost
equalling that of the final kit product

2. Make a purchase for it, invoice -> post

3. Try to validate the receipt -> can't due to attempted
re-reconicilation

**Cause of the issue:**
When validating the receipt, we end up here:
https://github.com/odoo/odoo/blob/c9ea75efb8e260d6bea5b777f4f950f106ffcfa5/addons/stock_account/models/stock_valuation_layer.py#L81-L90
And attempt to reconcile both the original kit product AML from
corresponding to the purchase line as well as the AML for the
component in the stock input account.

But we only will capture 1 exploded component AML in each loop
iteration, so the original kit product AML will not actually be
set `reconciled = True`, so we will also add it to be
reconciled again:
https://github.com/odoo/odoo/blob/c9ea75efb8e260d6bea5b777f4f950f106ffcfa5/addons/stock_account/models/stock_valuation_layer.py#L90

The same thing happens in subsequent calls to
`_stock_account_anglo_saxon_reconcile_valuation()`, except on
a final call for the last component line- if the components'
cumulative cost aligns with the total cost of the kit product
(which it should) then the reconciliation attempt will succeed.

Then here: https://github.com/odoo/odoo/blob/c9ea75efb8e260d6bea5b777f4f950f106ffcfa5/addons/stock_account/models/stock_valuation_layer.py#L92
`reconcile()` is called on the already-reconciled AML which will
cause the re-reconiliation error.

**Fix**
Reconcile all the resulting kit AMLs (component AMLs + actual
kit product AML from the bill) together.

opw-4668004

Forward-Port-Of: odoo/odoo#206838
Forward-Port-Of: odoo/odoo#205401

The default rounding method of '_compute_quantity' function is "UP" while the rounding method used for stock quantities is "HALF-UP". Hence, small discrepancies in the valuation would be introduced over time.

## How to reproduce
- Create product P, storable, tracked in Kg
- Create a receipt/delivery move for 14g of P -> Stock Quant is updated by 0.01Kg
-> Stock Valuation is updated by 0.02Kg

OPW-4734980

---

Test result without fix:
```
2025-04-22 13:40:45,088 38626 ERROR oes_test_16 odoo.addons.stock_account.tests.test_stockvaluation: FAIL: TestStockValuation.test_valuation_rounding_method
Traceback (most recent call last):
  File "/home/odoo/projects/odoo-src/multiverse/src/16.0/odoo/addons/stock_account/tests/test_stockvaluation.py", line 4397, in test_valuation_rounding_method
    self.assertEqual(receipt.move_ids.stock_valuation_layer_ids.quantity, 0.01)
AssertionError: 0.02 != 0.01
 ```

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

Forward-Port-Of: odoo/odoo#207066
Forward-Port-Of: odoo/odoo#206884

Versions
--------
- saas-17.4+

Steps
-----
1. Create a SO for non-user client;
2. add a product that isn't published on the website;
3. confirm SO;
4. create downpayment;
5. copy share SO link;
6. open link in private window.

Issue
-----
> 500: Internal Server Error
> Error while render the template
> ValueError: Expected singleton: product.product()

Cause
-----
Commit 9aa52dd6418e removed the creation of a "Down payment" product. Before it, order lines were either of type `display_section` or they had a `product_id` value. After the commit, a third option is for `is_downpayment` to be true.

This regressed the fix to this issue added by 34d4ffa01d57d, as instead of ensuring lines have a `product_id` value before checking if reorder is allowed, it decided to check whether they're not of `display_type`.

Solution
--------
Ensure there's a `product_id` in `sale.order.line` instead of only relying on the caller to filter those out beforehand.

opw-4711297

Forward-Port-Of: odoo/odoo#206435

There was an issue in the `PropertyDefinition:state.propertyDefinition`,
which could sometimes not be updated properly, resulting in a traceback after
multiple property definition changes.

### How to reproduce:
- Open a CRM Lead form view and add a property of type `tags`.
- Save and fully reload the form view.
- Change the property type to `separator`
- Change the property name to another value.
- Click outside the popover to close it.
=> Traceback
```
Cannot read properties of undefined (reading 'type')
at  PropertiesField.onPropertyDefinitionChange
```

### Technical explanation:
The `propertyDefinition` argument given to `onChange` props of
`PropertyDefinition` component is expected to be modified in place, since it is
used as the `propertyDefinition` state value.
`pick` function creates a shallow copy, therefore using it on
`propertyDefinition` in `PropertiesField:onPropertyDefinitionChange` and
applying changes on that copy (i.e. in `_regeneratePropertyName`) will prevent
these changes to be registered in the
`PropertyDefinition:state.propertyDefinition`, resulting in inconsistent values
with `PropertyField:propertyList`, which would manifest at the next definition
change, since `_getPropertyIndex` would not be able to find the index of the
now obsolete `propertyDefinition`.

task-4743860

Forward-Port-Of: odoo/odoo#206977
Forward-Port-Of: odoo/odoo#206871

Steps to reproduce [17.1]:

- Add a property field to a job application in the backend.
- Go to the linked website job application form (in edit mode).
- The property field is inaccessible.

To be able to access the new property field in the application form, the
`job_id` value of the related job record needs to be specified by
default. Unfortunately, these values are removed before accessing "edit"
mode:

Starting from [1], a fix was added to clear default values coming from
`data-for` attributes when the form is edited (at `cleanForSave()`) to
prevent saving it with changed default values.

Since the code from [1] can also remove default values set by the user,
a new fix (see [2]) updated this implementation to ensure that only
values from auto-fill and data-for fields will be removed (this time,
when the form public widget is destroyed [3]).

The behaviour from [3] will always unlink the `data-for` values in edit
mode, and as a consequence, the related property fields won't be
correctly retrieved.

The goal of this commit is to fix this behaviour by excluding `data-for`
values from the reset in [3]. An extra check will be added to be sure
the form won't be saved with updated default values if it already has
`data-for` ones [4].

Important: The diff from [5] made the `email_to` field as an exception
for the data-for/prefill priority system and only used the `data-for`
value if nothing has been configured by the user (it also used the
`data-for` value if what was configured by the user is the dummy default
email: `info@yourcompany.example.com`). That's why we need to
exceptionally allow saving the default value added by the user in the
check from [4] to preserve the same behavior.

Following [6], The `email_to` value won't be kept in edit mode to
prevent breaking its dynamic behavior.

[1]: https://github.com/odoo/odoo/commit/b637a5e32f767b62736241042f88fa0cecf9f10b
[2]: https://github.com/odoo/odoo/commit/043e1fdf923d2037dd8da128ab99388f0c92e544
[5]: https://github.com/odoo/odoo/commit/a08574a04ff2ce8ea2d6fd2b79f56cc57bba953b
[6]: https://github.com/odoo/odoo/commit/6658d61e304c9dfd8e512648c4a001dcaac44bc1

task-3922573

Forward-Port-Of: odoo/odoo#166565

Currently an exception was generated when the user tries to save the new employee record after clicking on call icon.

Steps to reproduce:
1) Install HR module
2) Create a new employee record by giving employee name 
3) Click on the call icon of work phone
4) Now tries to save the new employee record

Error: `KeyError:  name`

This issue occurs because, while clicking the call widget, it creates the record but does not update it in the browser.

As a result, when the user tries to save manually, It again  creates the record with an empty vals_list.

So it will leads to the above traceback from the below lines

https://github.com/odoo/odoo/blob/2d64d94487d24278dc3c6615343a793e1ec94daf/addons/hr/models/hr_employee.py#L386

This fix resolves the issue by ensuring that clicking the call icon before saving retains the user input. Additionally, I have added a test to verify this behavior.

sentry-6234873849

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

Forward-Port-Of: odoo/odoo#206227
Forward-Port-Of: odoo/odoo#195278

### Steps to reproduce:
- Accounting dashboard
- Click on the three dots of the "Bank" card
- Click "import file"
- Try importing a CAMT file with the namespace "camt"
- Traceback

Other issue:
- Try importing a CAMT file with a custom Code in `ns:Domn/ns:Cd` (example: "IC1")
- Traceback

### Cause:
Namespaces can be used in CAMT files but the way Odoo handled them was incorrect. We were creating a dictionary using `root.nsmap`. It only worked when the file didn't have a namespace key because if the key was different from 'ns' the `findall` didn't work.

Second issue: Some banks use their own codes in the CAMT files. The specification has numerous codes which Odoo added in a dictionary, and it reads from this dictionary to get a description. When there is a custom code, Odoo tries to read a key which doesn't exist explaining the traceback.

### Solution:
- Change the way namespace is computed using the tag.

- If the code is not in the dictionary, we take the custom code.

opw-4553152

Forward-Port-Of: odoo/enterprise#82888

Before this commit, the function _generate_deferred_entries was basically a big for-loop in which a lot of account.moves and lines are created in each iteration. This was extremely inefficient because it wasn't leveraging any batch optimization of the ORM. This PR breaks down the for-loop into smaller ones that aggregate vals and performs a single call to create records, instead of individual creations. Same approach was taken for unlinked records and posting moves.

The assumption is that records are created in the same order of the values list. This allows for breaking the for-loop because consecutive for-loops can simply inherit the order from the lists created in the loop just before. Another leverage point is that simply adding move_id to account.move.line(s) before creation is equivalent to `move.write({'line_ids': \[...\]})`. Based on the 2 assumptions, we could decouple the creation of moves and their lines into separate loops to aggregate their values.

After this PR creations, unlinks and posting operations are all batched to leverage the power of ORM optimization.


Benchmarks:
|Num deferred expenses | Time before | Time After | Num queries before | Num queries After |
|--------------------- | ----------- | ---------- | ------------------ | ----------------- |
| 100 		| 23.9s 	| 13.1s 	| 3768 		| 2918 			   |
| 1,000 	|181.4s      	| 66.5s       	| 17885         | 9530              	   |
| 10,000	|TIMEOUT(>1200s)| 616,7s    	| 1379          | 1010              	   |

opw-4480919
opw-4403217

Forward-Port-Of: odoo/enterprise#81148
Forward-Port-Of: odoo/enterprise#79255