Marketplace orders with discount lines could not match the
platform total: Odoo accumulated a small rounding residue vs Shopee's
total_amount / Lazada's order price.

sale_shopee
-----------
Changes:
- Fetch buyer-side escrow amounts via `_fetch_order_income` and pass them
  through `self.env.context` (`order_income`).
- Build item lines from the buyer-paid item price with `discount=0` and a
  recomputed tax-exclusive `price_unit`.
- Distribute order-level discounts (seller/platform vouchers and coins) as
  dedicated negative lines per product tax group via
  `_prepare_discount_lines_values`.
- Append a shipping line from `buyer_paid_shipping_fee` with fiscal-position
  mapped taxes.
- Reconcile any leftover residue with `_adjust_order_total` using a single
  tax-free amount-adjustment line.
- Register `default_discount_product` and configure it on upgrade (v1.1).


sale_lazada
-----------
- Port the same reconciliation model as shopee: reconciled line specs, discount=0 with
  discounted unit from paid_price, shipping line from shipping_fee, order-level
  "Discount line" distributed at order-level.

task-6112062

Forward-Port-Of: odoo/enterprise#124953
Forward-Port-Of: odoo/enterprise#117561

### Steps to reproduce:

- Ensure `sale_stock_renting` is installed
- Enable Multi-Steps Routes > Unarchive MTO
- Create a product P with a BoM and the routes MTO + manufacture
- Create anc confirm a sale order for A unit of P
- Log in with an other user with with mrp User rights and sales User: Own Documents Only (he should not have access to the SO)
- Open the MO, add a component line and save
#### > Access Error: Blame the following rule: - Personal Order

### Cause of the issue:

Writing on the `move_raw_ids` will trigger a call of the `_autoconfirm_production` in order to confirm the newly created move: https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L990-L991 https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/mrp/models/mrp_production.py#L1422-L1423
During this confirmation process, one calls the `_merge_moves` method in order to  merge this new move (if relevant) to any already existing one. https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/stock/models/stock_move.py#L1575-L1576
Now, the issue is that, `sale_stock_renting` module overrides the method `_prepare_merge_moves_distinct_fields` determining the fields relevant to the merge by requiring a read access to the `is_rental_order` compute field of the `sale_order` linked to the MO:
https://github.com/odoo/enterprise/blob/b66097122ba3a758734ac6fb2b26579c35cb72c2/sale_stock_renting/models/stock_move.py#L34-L40
However, due to the 'Personal Orders' ir.rule, the user does not have a read access to this record:
https://github.com/odoo/odoo/blob/e447f4849056a0aab35966fb6ba595ebaadb79ab/addons/sale/security/ir_rules.xml#L44-L49

Community: https://github.com/odoo/odoo/pull/271017

opw-6275658

Forward-Port-Of: odoo/enterprise#121845
Forward-Port-Of: odoo/enterprise#121135

When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly.

Steps to reproduce:
- Create a database with the Belgian localization installed
- Install the account_winbooks_import module
- Navigate to Accounting > Configuration > Settings > Initial Setup > Import
- Import the WinBooks zip

Issue:

The import fails with the following error:
The VAT number [AAAAAA] for partner [BBBBBB] does not seem to be valid. Note: the expected format is BExxxxxxx.

Analysis:
In WinBooks, contacts can be of type Supplier or Customer, and it is possible for a supplier and a customer to share the same number. During the import, the system will merge contacts if found with the same number.

In the specific case, the VAT number from one contact without country is combined with the country information from another contact, resulting in a VAT validation error.
This change prevents the merger of partner data if their VAT numbers are explicitly different.

opw-6251772

Forward-Port-Of: odoo/enterprise#119579

**Problem:**
On a website with rental planning enabled, a customer can book a planning-backed rental product through eCommerce even when no planning resource is free for the requested window. The cart lets them increase the quantity past the available capacity and proceed all the way through checkout without any availability gate.

**Steps to reproduce:**
1. Install `website_sale_renting_planning`.
2. Create a planning role with `sync_shift_rental` and one resource.
3. Create a service product with `rent_ok=True`, `planning_enabled=True` and the role above.
4. Pre-book the resource for some window via a `planning.slot`.
5. From eCommerce, add the product to the cart for the same window.
6. Proceed to checkout/payment.

**Current behavior:**
The cart is considered ready, no warning is shown, and payment can proceed even though no planning resource is free for the chosen period.

**Expected behavior:**
The cart should be flagged as not ready and pre-payment validation should refuse to confirm until the customer picks a different date or quantity.

**Cause of the issue:**
`sale.order._available_dates_for_renting` in `website_sale_renting` is the documented hook for "stock availability" gating of the cart and pre-payment flow (called from `_is_cart_ready` and from `_check_cart_is_ready_to_be_paid`). `website_sale_stock_renting` overrides it to apply a per-line stock check, but
`website_sale_renting_planning` has no such override, so planning-backed rental services reach payment with no availability gate at all.

**Fix:**
Apply the same gating pattern that `website_sale_stock_renting` already uses: override `_available_dates_for_renting` in `website_sale_renting_planning` so that, for each rental line whose product is a planning-synced rentable service, the cart is only considered valid when at least the requested quantity of planning resources is free during the rental window (mirroring the resource and leave filtering already done by `_planning_slot_vals_list_per_sol` at SO confirmation time). This puts the gate at the same point the stock-renting flow enforces it, keeping the public cart/checkout flow consistent across rentable product types.

opw-6247034

Forward-Port-Of: odoo/enterprise#125478
Forward-Port-Of: odoo/enterprise#118943