The 'ImpuestosP' node of the payment complement (Pagos 2.0) is reported with
6 decimals while the SAT expects the amounts to be expressed with the number
of decimals supported by the currency of the payment ('MonedaP'), as published
in the 'c_Moneda' catalog, for example 2 decimals for MXN.

Steps to reproduce:

- Have an MX Company setup with Quadrum as PAC.
- Create and sign a customer invoice in MXN with a 16% IVA tax.
- Register a full payment and send the payment complement to the PAC.

Issue:

Payment will be rejected
```
Code : CRPER654
Message : El importe del campo BaseP que corresponde a Traslado, no tiene la cantidad de decimales que soporta la moneda (MonedaP)
```

Analysis:

Quadrum recently aligned its validation on that rule and now rejects the document
having fields with too much decimals and, currently, fields like BaseP, ImporteP
are pinned to 6 decimals in the template.

Reporting them with the decimals of the payment currency is not enough when the
payment settles a document expressed in another currency. Those amounts are also
checked against the converted ones with 'EquivalenciaDR'. With the full 10 decimals,
we exceed the lower/upper limits so the document is rejected with CRP20274.

opw-6561617

## Problem

#114591 migrated `sale_amazon`'s order synchronization from Orders API v0
to v2026-01-01 (`getOrders` → `searchOrders`). As part of that migration,
`_sync_orders`'s handling of the `last_orders_sync` watermark changed in a
way that can silently and permanently exclude orders from ever being
synchronized.

**Before #114591** (v0 `getOrders`), the response's `LastUpdatedBefore`
field was guaranteed present, and the cursor was always set to that
API-provided, already-consistent value:

```python
status_update_upper_limit = dateutil.parser.parse(
    orders_batch_data['LastUpdatedBefore']   # direct access, always present in v0
)
...
account.last_orders_sync = status_update_upper_limit.replace(tzinfo=None)  # unconditional
```

**After #114591** (v2026-01-01 `searchOrders`), the equivalent field,
`lastUpdatedBefore`, is optional in the response and is omitted entirely
whenever a page has no orders to report (`{'orders': []}`). The new code
added a fallback for that case, but the fallback is unbuffered:

```python
if last_updated_before := orders_batch_data.get('lastUpdatedBefore'):
    status_update_upper_limit = dateutil.parser.parse(last_updated_before)
...
if status_update_upper_limit:
    account.last_orders_sync = status_update_upper_limit
else:
    account.last_orders_sync = sync_start   # raw request time, no buffer
```

Per Amazon's own [`searchOrders` reference](https://developer-docs.amazon/sp-api/reference/searchorders)
(`createdBefore`/`lastUpdatedBefore` parameter descriptions; same wording in the
[`orders_2026-01-01` OpenAPI model](https://github.com/amzn/selling-partner-api-models/blob/96d516badc8d69a566a4160e3c7b315600e043a7/models/orders-api-model/orders_2026-01-01.json)):

> If you include `lastUpdatedAfter` in the request, `lastUpdatedBefore` is
> optional, and if provided must be equal to or after the
> `lastUpdatedAfter` date and **at least two minutes before the time of
> the request.**

i.e. Amazon itself documents that order data can lag up to ~2 minutes
behind eventual consistency. The `sync_start` fallback ignores this
entirely.

## Failure sequence

1. An order's status changes on Amazon at time `T`.
2. Amazon hasn't indexed that change yet (within its own documented ~2 min
   window).
3. A poll fires inside that window, genuinely finds nothing yet, gets back
   `{'orders': []}` — no `lastUpdatedBefore`.
4. `status_update_upper_limit` stays `None` → `last_orders_sync` is set to
   `sync_start`, already later than `T`.
5. Amazon finishes indexing the change. Doesn't matter: every future
   `lastUpdatedAfter` query now starts after `T`, so this status change can
   never be returned by `searchOrders` again.
6. The order isn't delayed — it's **permanently excluded**, with no
   exception and no log entry anywhere.

This isn't a rare edge case: an empty page is the *normal* result of most
polls for any account without constant order volume, so the unbuffered
fallback fires routinely rather than exceptionally. It's easy to miss in
testing/QA at the default 60-minute poll interval (`ir_cron_sync_amazon_orders`),
where most hourly windows contain at least one order and the safe branch
is what usually runs — it becomes far more visible at shorter polling
intervals, which is how we found it.

## Real-world impact

Reconstructed from production logs, with request IDs, for order
`028-5161591-7232333` (`lastUpdatedTime=2026-08-21T10:10:53.060Z`):

- **10:12:21** — `searchOrders` request `c6833e60-4a17-4c25-b70d-7da55d5b303d`.
  Response: `{'orders': []}`. The request's own upper bound is ~10:10:21
  (2 min before request time), so this order — updated at 10:10:53 — is
  correctly excluded: genuinely too new for this request, per Amazon's own
  rule. Nothing wrong yet.
- Because the page is empty, `status_update_upper_limit` stays `None` and
  the fallback sets `last_orders_sync` to this run's raw request time,
  ~10:12:21 — no buffer.
- **10:17:33** — next run, request `628290bf-fa59-4d66-8494-e865ff1ef73d`.
  Lower bound is now `10:12:21` (the unbuffered cursor from the previous
  run). The order's own `10:10:53` is *before* that lower bound. Response:
  `{'orders': []}` again — the order is now permanently unreachable.

The order fell into a ~90-second gap: too new for one request's upper
bound, already behind the next request's lower bound, with no query ever
covering the interval between. It sat as `UNSHIPPED` on Amazon,
completely invisible to Odoo, until manually re-surfaced days later by
resetting the account's watermark back to before this window and
re-running the sync. In that one recovery run, 23 previously-unseen
orders on this account came back, every one still `UNSHIPPED`, all with
the same signature: a `lastUpdatedTime` sitting in a gap between two
consecutive empty `searchOrders` responses.

## Fix

Buffer the fallback by the same indexing-lag margin Amazon documents,
instead of using the raw request time:

```python
account.last_orders_sync = sync_start - ORDERS_SYNC_INDEXING_LAG  # timedelta(minutes=2)
```

Added a regression test (`test_sync_orders_watermark_buffered_on_missing_upper_limit`)
covering the empty-page case.

Steps to reproduce:
===================
1. Go to the payment providers and set "Pay on Site" to disabled.
2. Go to Apps, clear the filter, look up "website_sale_collect" and upgrade it. This also happens on its own, as upgrading any custom module that depends on it upgrades it too.
3. Go back to the payment providers.

=> "Pay on Site" is enabled again, and published as well from 19.0 on. Customers are offered it at checkout and place orders that are never paid, without the merchant ever enabling anything.

Root cause:
===========
`data/payment_provider_data.xml` is loaded in update mode because it carries no `noupdate`, and it hardcodes the state of the provider:

    <field name="state">enabled</field>

So every upgrade of the module writes that value back over whatever the merchant configured. Every other provider ships its data with `noupdate="1"` and leaves the state alone, this module is the exception.

The file has been loaded this way since the module was added:

- [1] created the module with an updatable provider record.

Fix:
====
Load the file with `noupdate="1"`. The record is still created, enabled, when the module is installed, it is simply not written again on later upgrades. The flag is read from the file rather than from the `ir.model.data` row, so databases where the provider already exists are covered on their next upgrade, no data migration needed.

[1]: 087c48c4ed2e
opw-6528110

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

Steps to reproduce:
===================
1. Create a storable product with two variants and untick "Continue selling when out-of-stock".
2. Leave the first variant at 0 in stock, put some stock on the second one.
3. try the "Add to Cart" option of the shop page.

=> The product has no add to cart button, as if it were sold out, while its second variant can be bought. Reordering the variants so that the one in stock comes first brings the button back.

Root cause:
===========
`product.template._is_sold_out()` delegates to `product_variant_id`, which is `product_variant_ids[:1]`, so a whole template is declared sold out on the sole basis of its first variant. `_website_show_quick_add()` then hides the button for the template, whatever the stock of the other variants.

The helper has looked at that single variant since it was written:

- [1] added it to hide the button of sold out products.

Fix:
====
Consider the template sold out only when all of its variants are. The check stops at the first variant in stock, so a product that can be bought still costs a single stock lookup.

[1]: https://github.com/odoo/odoo/commit/4ae197cc770cec2058e1f113209c4f93a4a0f4b2
opw-6520052

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

Steps to reproduce
---
1. Set the warehouse to deliver in 3 steps.
2. Create a delivery pick not tied to a procurement group (not from a sale order) with a consumable product, and validate it.
3. On the pack transfer, put the goods in a package and validate.
4. Duplicate the pick, validate it, put its goods in a second package on the pack transfer, and validate.
5. Open the final delivery: both lines sit in the same package instead of one line per package.

Issue
---
The two picks share no procurement group, so their delivery moves merge onto a single move keyed by partner. Validating the second pack tops up that already partially reserved move: for a consumable, `_action_assign` builds its lines from `_get_available_move_lines`, which reports the availability of every upstream package without discounting what the move already reserved.

https://github.com/odoo/odoo/blob/05af9e6877fd0f044bb46c983fe7300eb1db9307/addons/stock/models/stock_move.py#L1907-L1909

The package already reserved on the first line is therefore offered again and reused, collapsing both lines onto one package. The reserved-product branch below already subtracts the move's own reservation before allocating; doing the same here leaves each package on its own line.

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

### Description of the issue/feature this PR addresses:
This PR fixes a server crash in the Peruvian localization (l10n_pe_reports_lib) that occurs when generating the "Inventory and Balance" General Ledger report. The crash is triggered by strict validation rules within Python's csv module, which rejects the custom line terminator used to fulfill the SUNAT PLE formatting requirements.

### Current behavior before PR:
When a user attempts to generate and export the "Inventory and Balance" report, the server crashes with a ValueError: bad delimiter or lineterminator value. This happens because the csv.DictWriter is initialized with lineterminator='|\n' to ensure every row ends with a pipe. Python's underlying csv implementation rejects this, as it expects standard line endings (\r, \n, or \r\n) and throws an error if the delimiter character (|) is included in the terminator string.

### Desired behavior after PR is merged:
The "Inventory and Balance" report generates successfully without server errors. The code now uses the standard lineterminator='\n' to satisfy Python's validation rules. To maintain the mandatory trailing pipe (|) at the end of each row required by SUNAT, a dummy empty column (['']) is appended to the field names with restval=''. This prompts the writer to naturally append the final pipe as a column delimiter before the newline, resulting in the exact |\n output format required, safely and reliably.

opw-6509674

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