With the replacement of rental rules by price rules in 2a934b799eb5f6d774ff6de86726b3887f1d8dab, we allowed users to use Availability dates to set specific prices for rental based on the rental period.
    
Doing so, we introduced a limitation as we currently take only the rule that matches the starting date/time of the rental.

This commit updates rental price computation to sum the price at each `rent_periodicity` step (hour/day/night/week) over the full rental duration.

Two drawbacks to this changes:

1. Formula-based rules may now behave differently. Rounding is applied per periodicity. For example, with a product priced at $99.99/day and a rule applying a 10% discount rounded to the nearest .99, starting on Monday till Tuesday (included). The price for a rental from Monday to Wednesday becomes:
    
   ```python
   # Monday to Tuesday (included)    + Wednesday
   (round($99.99 - 10%) - $0.01) * 2 + $99.99
   = $89.99 * 2 + $99.99
   = $279.97
   ```

2. The shop page previously computed rental prices of each products based on the current search query. If the base loading times without rental was already slow, adding rental products won't help. An `ir.config_parameter` was added to disable the computation of rental prices based on the search query.

task-6020137

See also:
- https://github.com/odoo/odoo/pull/257618

### Bench
- Best of 5 GET request times on a 1096 days period (maximum allowed by the rental date picker on the shop)
- 21 products (5 by hours, 15 by days/nights, 1 by weeks)
- Hardware: MacBook M4 Pro (so very fast, much faster than SaaS in single core perf)
- Script to generate the DB can be found in [POC](https://github.com/odoo/enterprise/pull/110156)
- Command: `for i in {1..5}; do curl 'http://localhost:8069/shop?start_date=2026-03-23+17%3A00%3A00&end_date=2029-03-22+18%3A00%3A00' -o /dev/null -s -w "%{time_total}\n"; done | sort -g | head -n 1 | awk '{print "best: "$1"s"}'`

  | No pricelist | Empty pricelist | Complex pricelist
-- | -- | -- | --
POC approach (diff [here](https://github.com/odoo/enterprise/pull/110693#issuecomment-4178075093)) | 3.841549s | 37.388301s | 126.696783s
Final approach | 1.835127s | 1.837871s | 1.913034s

### Steps to reproduce:

- In the settings: Enable "Storage Locations"
- Inventory > Configuration > Warehouse Management > Operation Types
- On receipts, in the Barcode App tab enable: "Force a destination on all products"
- Open the barcode app, create a new receipt
- Scan a product > Validate
#### > You are not blocked by the fact that you did not scan any destination even just to validate the default one

### Cause of the issue:

The `barcode_validation_after_dest_location` operation type setting is not used at any point in the barcode app.

### Note:

Line in the barcode app are always created a with a `location_dest_id`: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1310-L1322
In particular, even if the setting says: Force a destination on all products. It should rather be interpreted as force a destination scan before validation. Note that a destination scan will not necessarily update a single line but rather all concerned lines at once: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1558-L1576
It is therefore a valid call to check if a location dest was scanned to determine if the a destination was set on each product before validation of the picking, even if it is just to confirm the default destination.

### Note 2:

We modify the `_get_barcode_config` to only provide a `barcode_validation_after_dest_location` if locations re enabled otherwise users enabling the option without the ability to scan locations would be soft lock and unable to validate their picking. That same logic already being applied to the `restrict_scan_dest_location` config parameter:
https://github.com/odoo/enterprise/blob/6afe02e3e836df2822d7cae8aebbd5bdde6b34cc/stock_barcode/models/stock_picking_type.py#L109

opw-6110690

Forward-Port-Of: odoo/enterprise#115723
Forward-Port-Of: odoo/enterprise#114429

During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not provide a clear answer for a given listing. After some research, we assumed an offer was FBM when the listing contained a `merchant_shipping_group`, because this setting is specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58.

This assumption was flawed: Amazon can keep the shipping group even after a listing switches to FBA, which can block stock synchronization.

This commit uses the `fulfillmentAvailability` field from the Listings API instead. This field stores the available quantity for each fulfillment channel in which the listing is sold.

When multiple fulfillment channels are present, the offer defaults to FBM so stock synchronization can continue. The
`sale_amazon_channel_management` module can then be installed to manually select and disambiguate the channel.

This commit also upgrades the patching method used to update the FBM stock to ensure user specific configuration aren't overriden during the synchronization.

opw-6064896
opw-5152359

Forward-Port-Of: odoo/enterprise#116285
Forward-Port-Of: odoo/enterprise#114473

**Description**

With odoo/odoo#247578, we were storing static column names in the list
definition during migration and list insertion. As a result, list header
labels stopped being translatable.

This was originally done because spreadsheet pivots created from list
ranges can break when translated headers change from one language to
another.

In this commit:
- make `string` optional in list column definitions so headers fall back
  to the translated field display name when no explicit label is stored
- keep explicit/custom labels by storing `string` only when a stable
  header is really needed
- update list migration, insertion, and reinsertion flows so they no
  longer force static labels by default
- simplify the list side panel so users can choose between the automatic
  translated label and a custom stored label
- when creating a spreadsheet pivot from a list range in multi-language
  mode, automatically store the current displayed labels only for the
  list columns used by that pivot so the pivot stays stable across
  languages

Task: 247578

Forward-Port-Of: odoo/enterprise#115411

Steps to reproduce:
- Set a journal with documents folder sync.
- Create and post a customer invoice.
- Add an image attachment via a log note.
- Click Send & Print.
-> KeyError: `proforma_pdf_attachment`

Cause:
Adding an image via log note sets it as the main attachment, but it 
is intentionally orphaned (res_model=False) to prevent UI clutter. 
`documents_account` incorrectly syncs this unlinked file, creating a 
workspace document with a missing model.

During "Send & Print", the official invoice PDF replaces the image as
the main attachment. The document versioning logic intercepts this swap
and attempts to re-parent the new PDF to match the orphaned document.
This destroys the PDF's linkage to the invoice, causing a crash when
the system later attempts to fetch the PDF.

Solution:
Since the base module now suppresses premature document creation during 
the message post, we explicitly handle the sync ourselves. We override 
`_fix_attachments_on_record_from_files_data` to iterate over the 
validated attachments and trigger document creation only for files 
that retained their `res_model`. We also add a check inside 
`_update_or_create_document` to strictly block orphaned attachments.

opw-5930888

Forward-Port-Of: odoo/enterprise#116397
Forward-Port-Of: odoo/enterprise#115065

### Issue:
When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction

Additionally, after selecting and unselecting a line with another currency, the balance can remain hidden even when no lines are selected

### Cause:
In `changeInSelectedMoveLine(selectedLines),` when the currency differs from the company currency, `selectedLineCurrencies` is built as a simple mapped array

This array may contain duplicate currencies, which should not prevent computing the balance but incorrectly impacts the logic that determines whether to display it
There is no reason to block the sum of lines with the same currency

When there is no selectedLines, the function returns early and doesn't unhide the balance

### Steps to reproduce:
- Install `account_accountant` with demo data
- Enable a foreign currency like EUR
- Create and confirm 2 invoices (Customer: Acme Corporation, Currency: EUR, Add a line for 100€)
- Go to the Dashboard, and select Bank
- Create a new transaction (Label: Multi-currencies, Partner: Acme Corporation, Price: 500$)
- Switch to the List View, and display the 2 columns `Foreign Currency` and `Amount in Currency`
- Modify the line Multi-currencies (Foreign Currency: EUR, Amount in Currency: 300$)
- Switch to the Kanban View and Reconcile the line Multi-currencies
- Select your 2 invoices one by one
Before the fix, after selecting the second invoice, the balance is displayed as `/`

For the additional case:
- Unselect all lines
- Select a line in another currency (e.g., USD), then unselect it
The balance remains hidden

opw-6063366

Forward-Port-Of: odoo/enterprise#115101

## Issue
When creating an invoice for a sale order with a recurring plan using a `billing_period_value` >= 1 and aligning, that value is not taken into account, and the invoice only covers one unit of time (week/month/year).

## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Recurring Plan RP:
    - *Billing Period*: 6 Months
    - *Align to Period Start*: Checked
3. Create a Subscription Product P
4. Create a Subscription SO:
    - Any Customer
    - Recurring Plan RP
    - Product P (any quantity/price)
5. Confirm the SO and create the invoice
6. **In the line of the SO, only one month is covered by the invoice. If we generate the next invoice, only one month will be covered as well.**

## Cause
Since https://github.com/odoo/enterprise/commit/45f28f6c288f5213a4e29c816ec68d2c3966b55f, the `next_date_1st` is evaluated by taking the last day of the month/year and incrementing it by one day, to reach the first day of the next month/year.

https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/sale_subscription/models/sale_order_line.py#L377-L382

This is inaccurate when working with recurring plan which are not monthly/yearly, as it will always set the `next_date_1st` to the next month/year, without taking in account the `billing_period_value`.

## Fix
There are two ways to align dates to the period start. Given a subscription starting on January 15, with a billing period of 3 months, we could:
1. Invoice from January 15 to January 31, then from February 1 to April 30. This aligns the invoice to the closest month, then apply the 3 months period for the next invoices.
2. Invoice from January 15 to March 31, then from April 1 to June 30. This applies most of the billing period for the first invoice, while still aligning it to the start of the month, then apply the 3 months period normally for the next invoices.

**Here, we chose the second option** to avoid making the code more complex and keep the diff minimal.

opw-6151530

Forward-Port-Of: odoo/enterprise#115830

Payment reminders are not sent to the duplicate of a subscription when a reminder has already been sent for the original subscription

Steps to reproduce:
1. Install Subscriptions
2. Create a new subscription for customer Acme Corporation with product Office Cleaning Service (SUB), a Monthly recurring plan and in the Other Info tab, set the subscription Start Date to one week ago
3. Confirm the subscription
4. Go to Scheduled Actions and run the action "Sale Subscription: send reminder for subscriptions with no token"
5. Go back to the previously created subscription (see that a reminder email has been added in the chatter)
6. Duplicate the subscription and confirm the duplicate
7. Run the action "Sale Subscription: send reminder for subscriptions with no token" again
8. There are no reminder for the duplicate subscription

Issue:
The copy of a subscription uses the same `last_reminder_date`, preventing payment reminders to be sent here
https://github.com/odoo/enterprise/blob/5a2ab62254cd5f684a3b1a0d7c0001b888c70d08/sale_subscription/models/sale_order.py#L2114-L2120

Solution:
Set `copy=False` on the field `last_reminder_date`

opw-6167356

Forward-Port-Of: odoo/enterprise#116335
Forward-Port-Of: odoo/enterprise#115509