Description of the issue/feature this PR addresses:
This PR fixes an error occurring during the evaluation of the UBL/CII export condition when the country_code field on the invoice or its commercial partner is not set. In Odoo, unset fields may return False, which can lead to type comparison errors when performing membership checks against string values.

Current behavior before PR:
If invoice.country_code or invoice.commercial_partner_id.country_code is False, the condition that checks whether the country code is in ('FR', 'DE') may raise an error because a boolean value is being evaluated where a string is expected.

Desired behavior after PR is merged:
The condition safely handles cases where country_code is not set by normalizing the value before performing the membership check. This prevents type errors and ensures the logic behaves correctly even when the country code is missing.


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

### Issue:

When scanning products tracked by lot in the barcode app, if multiple move lines existed for the same product, all scanned quantities were incorrectly added to a single line. This left other lines unfulfilled and caused an unnecessary backorder.

#### To reproduce the issue:
1- Enable `Lots and Serial Numbers` in setting
2- Create a product and track it by lots
3- Create a PO, with 2 lines of each 1 quantity of our product
4- Go to barcode. From `receipt` operation find the PO picking
5- Scan the product and fulfill the line. You will have a line
   of 2/2 fulfilled. Validate.
6- As you see a backorder is created.
7- If you check the moves from PO, you can see there are 2
   lines with 2/1 and 0/1 qty_done which made the backorder

#### Cause:

This is caused because in addQuantity, the quantity increment is only applied to 1 line, ignoring the fact there might be multiple lines:
https://github.com/odoo/enterprise/blob/def740d23c006b97b60fd1a0cd5acadca8abfac6/stock_barcode/static/src/components/line.js#L118-L127

This will going to add all quantities to single line, making it ovefilled. Here the line will have the `qty_done` = 2 while its `quantity` is 1. The other line's qty_done remain 0, causing backorder.

### Fix:

We can first, make sure to fulfilling all lines, then if all are fullfilled and there are stil quantities to add, then it can be arbitrary added to one line.
We keep the current logic for negative quantitites, as the increment is only done by -1.

opw-5035778

…tion

Currently, under certain conditions, reconciling a batch payment with a bank statement may not be possible as the system tries to create an unbalanced move.

Steps to reproduce:
- Have the main company in USD and EUR as foreign currency
- Have a bank journal with currency EUR (Bank EUR)
- Create an xchange rate for today (1.1)
- Make a Payment (EUR), it should not have an associated move
- Put the payment in a batch
- Update the exchange rate for today (1.2)
- Create a Bank transaction in the journal Bank EUR matching the payment amount
- Open the bank reconciliation screen and reconcile the transaction with the batch

Expected result:
Everything is reconciled.

Actual result:
User gets an error message saying that the account move is not balanced.

Analysis:
The issue occurs because the reconciled payment amount is converted to the company currency using the date provided in the payment.  However the rate was changed in the meanwhile, so it does not match the amount that was used to create the exchange entry values.

opw-5164405

### Steps to reproduce:

- Create a kit product with 6 bom lines (with a `cost_share` of `0.0%`)
- Create + confirm a purchase order for 1 unit of the kit product at 60
- Validate the delivery

#### > 6 layers were created with values 9.99, 10, 10, 10, 10 and 10

There are two issues with purchased kit valuation addressed in this PR:

### Issue 1:

Since 8c199f7783527735b35c9fbda334cbdcd55a004f, the product price unit is not supposed to be rounded anymore. However, kit products rely on the rounded `cost_share` field of the `mrp.bom.line` to determine which part of the price of the kit product is handled by which component: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/mrp/models/stock_move.py#L245-L246 https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/stock_move.py#L28 https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/stock_move.py#L38

This leads to inevitable rounding issues where `60/6` does not match `10`: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/tests/test_purchase_mrp_flow.py#L1273-L1275 simply because 1/6 is represented  as `16.67%` and not by `16.66666666666666%`. However, values such as 1/6 can be obtained if you do not set any `cost_share`, since the kit explosion will equidistribute its cost share:
https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/mrp_bom.py#L42-L48

### Fix of this issue:

We set the digits to `False` for stability reason as the columns have 
been initiallised as "numeric" values and needs to stay numeric:
https://github.com/odoo/odoo/blob/b007b0a4f7e56f6dc44df3154e13745c9981eae3/odoo/fields.py#L1627-L1650

Note that when the digit is Falsy on the field, the field value is formatted to the second digit by the front end:
https://github.com/odoo/odoo/blob/3542c542eac5b204e69a8dd6ae1907cfcef60af3/addons/web/static/src/views/fields/float/float_field.js#L58-L76
https://github.com/odoo/odoo/blob/12e453302a950df4d9ee45954f54bdf610888eda/addons/web/static/src/core/utils/numbers.js#L214-L227

In particular, when we create the bom and set the `cost_share`, all possible values will be rounded to the second decimal just as before. This change will therefore only alter the rounding behavior in the DB for equidistributed values such as `16.66666666666666%`.

### Issue 2:

While the value of the kit product is exploded and distributed among components, the values of each individual `stock.valuation.layer` are themselves rounded before creation based on the company currency: https://github.com/odoo/odoo/blob/4188436a9e800b062bf9f3b0055cad86acc47e19/addons/stock_account/models/product.py#L240-L255 https://github.com/odoo/odoo/blob/4188436a9e800b062bf9f3b0055cad86acc47e19/addons/stock_account/models/stock_valuation_layer.py#L30

Now, this is problematic since the sum of the values of the layers is expected to match the total value of the purchase order line (that is, the non-rounded value of the components of the purchased kit).

### Fix of this issue:

We compute and distribute the rounding error among layers corresponding to the purchased kit product before creation (since layer values are not expected to be modified afterwards), based on the non-rounded computation, since this value should now be exact (as the unit cost is not rounded anymore).

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

When the company currency rounds on unit and we try to apply a reward on a sale order that uses another currency and that has a total of less than 0.5, no reward is applied

Steps to reproduce:
1. Install Sales app and l10n_cl and loyalty module
2. Switch to CL Company
3. Go to Sales > Products > Discount & Loyalty
4. Create a new program and change the rule's minimum purchase to 0.00
5. Go to Sales and create a new quotation for customer Acme Corporation and add any product
6. Change the sale order line unit price to 0.4 and click on Reward
7. No discount is applied

Problem:
The company currency is used to compute the discountable amount but when this currency rounds on unit, any amount that is less than 0.5 will be considered as zero so no discount will be applied. This is because the `compute_all` method is called without specifying the currency, so we fallback on the company currency.

Solution:
Pass the order currency when computing the discountable amount

opw-5946975

To reproduce:
- Register your company on Peppol (even sender).
- Change the VAT on your company (will be done if you choose your document layout).
- Send an invoice on the network 
- => The invoice will be refused by the AP.

The issue is that the EAS and Endpoint are automatically re-computed when you write on the VAT. It causes issues as the UBL will be filled with the values on the partner, resulting in a non-synchronised SBD and UBL, which will result in all new invoices to be in error.

Their only solution would be to revert back the EAS/Endpoint on the partner, which will sometimes be blocked meaning they have to un-register->re-register

Also adapt the query count, as we need to do a search in each compute.

opw-5923552
opw-5924552

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#250749
Forward-Port-Of: odoo/odoo#249017

Steps to reproduce:
- Enable analytic distribution in Accounting settings
- Create a storable product "P1":
  - Routes: MTO + Buy
  - Vendor: add any supplier
- Create a Sale Order:
  - Add 1 unit of P1
  - Set any analytic distribution
- Confirm the Sale Order

Result:
A Purchase Order is created, but the analytic distribution is not propagated
to the purchase order line.

Problem:
When the Sale Order is confirmed, `_action_launch_stock_rule()` is triggered.
It creates and confirms the corresponding stock move with values from the
sale order line.

Since the product uses the MTO route, the procurement rule is executed.
The rule prepares procurement values from the stock move, but the analytic
distribution is not included in these values:

https://github.com/odoo/odoo/blob/18.0/addons/stock/models/stock_move.py#L1539

Later, `_run_buy` is triggered. It uses the procurement values coming from the
stock move to find an existing purchase order line candidate or to create a
new one. Because the analytic distribution is missing from the values, the
created (or matched) purchase order line does not contain the analytic
distribution:

https://github.com/odoo/odoo/blob/621a93b7b723999d943f1c4da78547763498c008/addons/purchase_stock/models/stock_rule.py#L113

Solution:
Propagate the analytic distribution from the sale order line through the stock
move so it can be included in the procurement values and correctly applied to
the purchase order line.

opw-5936971

****Behavior:****
**Current:**
In a multi company environment, when a sale contains multiple tasks in some project, and the user has billing rates indicating they should be assigned to a specific task, creating a new timesheet for the project does not set the correct SOL. This only happens if the sale is happening from a company that does not have an employee linked to the user.

**Expected:**
The new timesheet should be able to connect the current user to the related employee in the billing rates to find the right SOL. In the situation in which multiple companies have created an employee for the same user, and more than one of these has been linked to a SOL in the billing rates (unlikely workflow): We choose the SOL linked to the employee record created for the currently activated company, otherwise, we default to the first employee in the list.

**Steps to reproduce:**
- Be in a multicompany environment: company A and B
- Create User with access to both but only one employee record for company A
- Switch to company B
- Create 2 services product, both creating a task in the same project.
- Activate Billable Rate Indicators in the settings
- Create a quote with both services and confirm
- Go to the related project, and in the Invoicing tab, link employee from company A to SOL2
- As the user, check both companies but set company B as current active
- Go to timesheet and create a new timesheet, when setting the project from the quote, you should see SOL1 by default, however we would want SOL2 as it was configured.

opw-5159195