Currently, when a user dropships a kit product with FIFO/AVCO category costing, the computed cost of the kit on the Sales Order becomes 0.

## Steps to replicate:
- Install Sales, Purchase, and Manufacturing modules.
- Enable Margins and Dropshipping in settings.
- Go to Product Categories > Goods and set costing method to FIFO
- Create two products MOBO and CPU: 
   - Cost: $300 
   - Category: Goods 
   - Add a vendor in Purchase section with unit price same as cost 
   - Enable Dropshipping route
- Create a kit product Computer Kit with the same configuration as above (except cost) 
  and add MOBO and CPU as components on its BoM.
- Open the Computer Kit and click Compute Price from BoM.
- Create and confirm a Sales Order with the Computer Kit.
- Confirm the related Purchase Order and validate the dropship picking.
- Return to the Sales Order > make the `Cost` field visible on SO lines .

## Observed Behavior:
The product cost appears as 0 on the Sales Order, even though a price is set on the related Purchase Order.

## Root cause:
When the dropshipping picking is confirmed, the method `_compute_purchase_price` is triggered to compute the cost on the Sales Order line. It calls `_get_price_unit_delivery` at [1], which then calls `_get_price_unit_dropshipped` at [2] since the products are dropshipped. Because dropshipping moves do not carry stock values, it calls `_get_value` at [3] to determine an appropriate value.

This method uses `_get_value_data` at [4], which retrieves the value from the quotation via `_get_value_from_quotation` at [5]. Here, a cost ratio is applied at [6] to distribute the cost based on the BoM cost share (i.e., the percentage split of cost across kit components). Since no cost share is defined on the BoM, the ratio is 0, causing the final computed cost ratio to also be 0 at [7] and the cost value being returned as zero as shown in at [6].

**Why not in lower versions?**
This issue did not occur in versions 18.4 and earlier due to the presence of the stock valuation layer and the defined logic for kit products to calculate cost, as shown in [8].

[1]:
https://github.com/odoo/odoo/blob/d92feb4a6f463cae59aa107f46b5699f83f8ef9c/addons/sale_stock_margin/models/sale_order_line.py#L18-L21 [2]:
https://github.com/odoo/odoo/blob/d92feb4a6f463cae59aa107f46b5699f83f8ef9c/addons/stock_account/models/stock_move.py#L672 [3]:
https://github.com/odoo/odoo/blob/d92feb4a6f463cae59aa107f46b5699f83f8ef9c/addons/stock_account/models/stock_move.py#L681-L684 [4]:
https://github.com/odoo/odoo/blob/d92feb4a6f463cae59aa107f46b5699f83f8ef9c/addons/stock_account/models/stock_move.py#L336 [5]:
https://github.com/odoo/odoo/blob/d92feb4a6f463cae59aa107f46b5699f83f8ef9c/addons/stock_account/models/stock_move.py#L392-L397 [6]:
https://github.com/odoo/odoo/blob/d92feb4a6f463cae59aa107f46b5699f83f8ef9c/addons/purchase_stock/models/stock_move.py#L225-L241 [7]:
https://github.com/odoo/odoo/blob/d92feb4a6f463cae59aa107f46b5699f83f8ef9c/addons/purchase_mrp/models/stock_move.py#L12-L25 [8]:
https://github.com/odoo/odoo/blob/7f1cd04259202bcafc94965d6420df360f9152c1/addons/mrp_account/models/product.py#L65-L89

## Solution:
It should not be assumed that users will always define a cost share on the Bill of Materials. In many cases, they may expect the kit price to be derived directly from the costs of its component products.

To support this, we can override `_get_price_unit_dropshipped` to properly handle kit products, ensuring the cost is computed based on the component product costs instead.

opw-6113398

Forward-Port-Of: odoo/odoo#282616
Forward-Port-Of: odoo/odoo#261705

## [FIX] l10n_fr_reports: fix missing lines in association balance sheet

### Issue:
The Active part of the Balance Sheet for associations shows an incorrect `TOTAL ACTIVE` — some accounts are not propagated to their parent aggregations

### Cause:
`ACTIF_IMMOBILISE` was missing `BIEN_PAR_DONATION` in its formula
`ACTIF_CIRCULANT` was missing both `DISPONIBILITES` and `INSTRU_FINAN` in its formula

### Steps to reproduce:
- Install `l10n_fr_reports` and `accountant`
- Create a new FR asso company and switch to it
- In Accounting Settings, select:
  France - Associations accounting plan
- Create a Journal Entry:
  Account: 240000, Debit: 100 (BIEN_PAR_DONATION)
  Account: 512001, Debit: 100 (DISPONIBILITES)
  Account: 520000, Debit: 100 (INSTRU_FINAN)
  Account: 509000, Credit: 300
- Open the Balance Sheet and select Balance Sheet for associations

Before the fix, `TOTAL ACTIVE` is 0 instead of 300

--------------

## [FIX] l10n_fr_reports: add force_date_scope to asso cross_report

### Issue:
The Passive part of the Balance Sheet for associations shows an incorrect `TOTAL PASSIVE` — the same move line is counted twice, once in `Retained earnings` and once in `Profit or loss for the year`

### Cause:
In 19.1, `cross_report` aggregations were refactored: https://github.com/odoo/enterprise/commit/e699a14a1922d6b8a5bc6b88ad9c02a411e4b073
By default, a `cross_report` no longer forces its `date_scope` to the terms it calls — `force_date_scope` must now be explicitly passed in the subformula
The association balance sheet was added in 19.1 without this parameter, so `RESULT_LEXERCICE` (`from_fiscalyear`) and `REPORT_NOUVEAU` (`to_beginning_of_fiscalyear`) both used the current report's `date_scope` instead of their own
This caused both expressions to match the same entries and double the `TOTAL PASSIVE`

### Steps to reproduce:
- Install `l10n_fr_reports` and `accountant`
- Create a new FR asso company and switch to it
- In Accounting Settings, select:
  France - Associations accounting plan
- Create a Journal Entry:
  Account: 512001, Debit: 100
  Account: 701100, Credit: 100
- Open the Balance Sheet and select Balance Sheet for associations

Before the fix, `TOTAL PASSIVE` is 200 instead of 100

opw-6520639

Forward-Port-Of: odoo/enterprise#130147

Steps to reproduce
---
1. Enable Work Orders.
2. On a product's BoM, add an operation carrying an Instructions step.
3. On a small screen, create a manufacturing order for that product.
4. Open the generated work order: its quality-check step is missing because the work order was created without an operation.

Issue
---
On a small screen the MO form renders `workorder_ids` with the work order kanban sub-view, so the onchange field spec only carries that kanban's fields; with `operation_id` absent from it,
the generated work order is saved without an operation and its `quality_point_ids` stays empty, so no `quality.check` is created. This exact bug was already fixed by https://github.com/odoo-dev/odoo/commit/e3f6cef5cf94391b5c018c5eb44ce1ddee99290b, which
restored the invisible `operation_id` on the kanban, and then reintroduced by https://github.com/odoo-dev/odoo/commit/6318895101435a0a9d4bdff0b8dbfbb17179378e, a kanban rework that dropped the field again; this simply restores it.

opw-6488529

_get_invoice_counterpart_amls_for_early_payment_discount_per_payment_term_line
only split the early payment discount amount per invoice line (and thus
preserved each line's own analytic distribution) when the payment term's
early_pay_discount_computation was "included".
For "mixed" and "excluded", it instead built a single counterpart line,
discarding the analytic distribution of the invoice lines.

Compute the per-invoice-line base amounts (and the corresponding price_unit
for "mixed") for all three computations, keeping only the tax
calculation restricted to "included". This way "mixed" and "excluded" discount
entries now keep the analytic distribution of the invoice line they come
from, while behavior for "included" is unchanged.

Steps:

- Create 3 payment terms with EPD, each one with a different
  `early_pay_discount_computation` setting
- For each payment terms, create one invoice with two lines, only one
  having an analytic distribution
- Confirm and pay the 3 invoices (early payment, discount applied)

Issue:

For 'mixed' and 'excluded', the discount line is the sum of the discount
from the 2 invoice lines, and the analytic distribution is lost.

opw-6380278

Forward-Port-Of: odoo/odoo#286816
Forward-Port-Of: odoo/odoo#282541

**Issue**
If a move's package is already reserved, relocating that move raises an AccessError.

**Steps to reproduce**
- Activate the "Packages" feature in Inventory settings.
- Activate track localization in settings
- Create a new storable product.
- Using an inventory adjustment, add some quantity of that product in Stock, in a new package X.
- Create a sales order for that product and confirm it, so the quantity in Stock gets reserved.
- Go to Inventory > Reporting > Locations.
- Select the quant and try to relocate it, e.g. to WH/Input.
-> Raises an AccessError: "Failed to write field stock.package.picking_ids"

**Cause**
Relocating a quant creates a move:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/addons/stock/models/stock_quant.py#L1531
which creates a new move line without a `picking_id`:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/addons/stock/models/stock_quant.py#L1276-L1287

Since both move lines (the new one and the one linked to the SO delivery) share the same `result_package_id`,
in `_compute_picking_ids`, both move lines are grouped:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/addons/stock/models/stock_package.py#L174-L176
Thus, two "pickings" end up associated with the package: the SO's, and `None`.
While setting those pickings on the package, it tries to access them:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/addons/stock/models/stock_package.py#L182
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/odoo/orm/fields_relational.py#L1497-L1503
And since `self` isn't just `None`, this check won't be skipped:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/odoo/orm/models.py#L4152
This eventually raises an AccessError since `None` gets filtered out by `filtered_domain`:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/odoo/orm/models.py#L4154-L4156
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/odoo/orm/fields_relational.py#L1504-L1505

opw-6427070

Forward-Port-Of: odoo/odoo#283937
Forward-Port-Of: odoo/odoo#282209

Steps to reproduce:
- open Discuss, open any chat, open the emoji picker (no 'Frequently used'
  emojis)
- search a term and select emojis without closing the picker (shift+click on
  desktop, plain click on mobile)
- clear the search with backspace

=> traceback: 'Cannot read properties of null (reading
`getBoundingClientRect`)' in adaptNavbar().

This happens because when we clear the search input it calls
`highlightActiveCategory()`, which sets `categoryId` to the topmost category of
the grid, which is now the 'Frequently used' category (sortId 0), added to the
picker since the emojis we just picked updated the recent state. To update the
navbar, `currentNavbarPanel` then looks for the panel holding it in
`emojiNavbarRepr`, but that representation is only built in `adaptNavbar()`,
which runs on mount and from the `ResizeObserver` only, so it was built without
the 'Frequently used' category and no panel contains it. It returns undefined,
the navbar renders empty, its size change wakes the `ResizeObserver`, and
`adaptNavbar()` crashes on querySelector('.o-Emoji').getBoundingClientRect()`.

This commit solves the issue by rendering the `recentEmojis` from a snapshot
taken when the picker is opened, so they are not added to the picker while the
while `emojiNavbarRepr` does not contain their category id.

partial backported PR: https://github.com/odoo/odoo/pull/281104

Task-[6204249](https://www.odoo.com/odoo/project/1519/tasks/6204249)



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

Forward-Port-Of: odoo/odoo#286986
Forward-Port-Of: odoo/odoo#284372

**Issue:**

During migration to Odoo 19, the SA tax tag migration logic is present in: "migrations/2.1/pre-migrate.py" was not executed during the migration of databases because this:
  * SA compact tax tags were not renamed
  * VAT tax grids still use old tags
  * Localization reload was partially updating taxes
  * manual intervention was required

Added logs/debugging in:
* 2.1/pre-migrate.py
* 2.1/end-migrate.py
* 2.2/end-migrate.py

- Verified in both local and customer databases that only the 2.2 migration path was executed during upgrade, while the 2.1 migration scripts were skipped because the Odoo 19 manifest upgrade path already targeted the 2.2 migration version.
- 19:https://github.com/odoo/odoo/blob/67510fd36f7af31f83ef110602f9922ed5a43024/addons/l10n_sa/__manifest__.py#L6

**Solution:**

- Bumped the l10n_sa module version to 2.3 to apply these changes to databases that are already in production.
- Moved `migrations/2.1/pre-migrate.py` to `migrations/2.3/pre-migrate.py` to ensure the SA tax tag migration logic is executed during the `2.3` upgrade flow.
- Moved `migrations/2.2/end-migrate.py` to `migrations/2.3/end-migrate.py` to align with the `2.3` version bump and refresh the SA tax mappings correctly during migration.
   * SA tax tags migrate correctly
  * VAT tax grids update automatically
  * invoices use new tags correctly
  * No manual localization reload required

OPW - [6117408](https://www.odoo.com/odoo/project/70/tasks/6117408), [6224788](https://www.odoo.com/odoo/project/70/tasks/6224788)

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

# Description

**Steps to Reproduce**

1. Install Belgium Localization, then go to **Settings → Accounting/Invoicing**.
2. Enable **Verify VAT Numbers** (`vat_check_vies`).
3. Go to **Accounting → Configuration → Fiscal Positions** and confirm or create an **Intra-Community** fiscal position with:
   - Detect Automatically (`auto_apply`): enabled
   - VAT Required (`vat_required`): enabled
   - Country Group: EU, no specific country configured
4. Open an incognito/private browser window and make sure the session is unauthenticated.
5. Go to the website's `/shop` page and add any product to the cart.
6. Proceed to checkout until reaching the Address step (`/shop/address`).
7. Enter a delivery address in an EU country different from the company's country (e.g. company in Belgium, delivery address in the Netherlands).
8. In the VAT Number field, enter a real, valid, VIES-registered VAT number corresponding to the delivery country (e.g. a valid NL VAT number for a Netherlands address).
9. Click **Save Address / Continue** and proceed to the Payment step (`/shop/payment`).
10. Check the tax applied to the delivery line and the resulting order total.

**Issue**

The delivery product and the overall order are taxed at the standard/domestic VAT rate instead of the expected 0% intra-community rate — even though the customer provided a valid, VIES-registered EU VAT number matching the delivery country.

**Root Cause**

In `base_vat`, `res.partner.create()` unconditionally removes `vies_valid` from the ORM's pending computation queue via `env.remove_to_compute()`, relying on a subsequent `write()` to trigger the actual VIES check. This holds for the standard backend flow, where creation is followed by a `write()` — but the website guest checkout flow differs:

- `website_sale` creates the guest partner through `_create_new_address()`.
- The partner is created via a single `create()` call, with no follow-up `write()`.
- `_compute_vies_valid()` is therefore never triggered.
- `vies_valid` remains permanently unset (`NULL`), despite a VAT number being provided.

Downstream, `account.fiscal.position._get_vat_required_valid()` reads this unset value as falsy, so the Intra-Community fiscal position's `vat_required` condition fails and is rejected in favor of another applicable position (e.g. EU B2C or Domestic).

**Solution**

After partner creation, explicitly trigger `_compute_vies_valid()` when the partner has a VAT number and the operation is not part of a file import (`import_file` context) — performing the VIES check immediately instead of relying on a `write()` that guest checkout never issues.

**Result**

Guest customers providing a valid EU VAT number now get `vies_valid` computed immediately at creation. Fiscal position detection correctly identifies the Intra-Community position, and the expected 0% VAT treatment is applied to the delivery and order.

OPW: 6522992

Forward-Port-Of: odoo/odoo#286201