Currently, an error occurs when the currency in the CAMT file differs from the bank journal currency.

**Steps to reproduce:**
- Install `account_bank_statement_import` module.
- Create a new country with EUR as currency and switch to it.
- In the Bank journal, upload this CAMT file: https://drive.google.com/file/d/1hKZIUPwdtcWAvxcoTLPFGpW-F5LnqDy9/view?usp=drive_link

**Error:**
`TypeError - unsupported operand type(s) for /: 'NoneType' and 'float'`

**Cause:**
When the `<Bal>` or `<Ntry>` amounts in the CAMT file are in a different currency, `get_value_and_currency_name` [1] cannot fetch a matching amount for the journal currency. This returns `None`, which leads to an invalid division during exchange rate computation.

**Fix:**
This commit handles missing currency data in CAMT files by raising a validation error instead of throwing a traceback.

[1] -  https://github.com/odoo/enterprise/blob/e7ae981000a4e53dc608c76605d8b2dbfb972c6a/account_bank_statement_import_camt/lib/camt.py#L632-L638

sentry-6874016845

Steps to reproduce:
----------------------------------
1. Install `l10n_ch_hr_payroll_elm_transmission` module
2. Switch to Swiss company
3. Navigate to Payroll > Transmission > BVG-LLP Basis Declaration
4. Create two Reports with same Year and Month
5. Now try to create new Employee from the employee app

Observation:
----------------------------------
Tracaback Occurs:
```
 File '/home/odoo/src/enterprise/19.0/l10n_ch_hr_payroll/models/l10n_ch_employee_monthly_values.py', line 319, in _compute_bvg_lpp_annual_basis
    existing_declaration = max(existing_declaration, key=lambda r: r.month) if existing_declaration else False
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
    raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n.ch.lpp.basis.report(1, 2)
```

Issue:
----------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/44a26539093f9313d9cd5f823c11866e3c98ec97/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_employee_monthly_values.py#L319-L320

Python's max() function doesn't just call the key function once per item. When there are ties (equal key values), it may need to compare the original objects, and during this process, Odoo's recordset operations combine records, causing the lambda receives `r` as a combined recordset. To access `.month` on a multi-record recordset it gives singleton error.

Solution:
----------------------------------
Creates tuples of (month, recordset) pairs and uses max() to compare month integers directly, avoiding the singleton error.

opw-5391742

Forward-Port-Of: odoo/enterprise#102335

When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM).

However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders.

To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa.

To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58.

However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings.

To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous.

opw-5480254

See also:
- https://github.com/odoo/upgrade/pull/9692

Forward-Port-Of: odoo/enterprise#106662

**Problem:**
compensation amls are not created for dropshipped 
products when there is a difference between the 
price of the PO and the price on the bill

**Context:**
For non dropship avco real time products: 
When you create a PO for a product @ 10
- stock interim received is credited of 10
- stock valuation is debitted of 10

And you then validate a bill for a price of 8
- stock interim received is debitted of 8
- account payable is creditted of 8

This leaves stock interim received with credit of 
2 and stock valuation is over valued by 2. 
So we create 2 extra account move lines 
- One debit of 2 for stock interim received
- One credit of 2 for stock valuation (or Expenses 
if the product is not in stock anymore because then 
it's the expense account which was over valuated)
nb: if the product is still in stock those 2 lines are 
created via stock valuation layer

In the case of a dropshipped product, the product 
is not in stock anymore so it should be creditting 
expense, but no extra amls are created at all.

**Steps to reproduce:**
- enable the "dropshipping" and "anglo saxon accounting" 
settings
- create a storable product with avco automated category
- in the inventory tab, select the dropship route
- in the purchase tab, set a vendor
- create and a confirm a quotation for this product
- on the linked purchase order, set a unit price of 10$ and 
confirm
- validate the dropship move
- create a bill for the purchase order
- set the price to 8$ and confirm
- navigate to journal items and search for your product

**Current behavior:**
no compensation account move lines were created

**Expected behavior:**
2 account move lines should have been created: 
- One debitting 2 in stock interim received
- One creditting 2 in expense

**Cause of the issue:**
*the following logic was introduced by* https://github.com/odoo/odoo/pull/126536
to create those extra amls and layers, 
_apply_price_difference() is called inside _post()
https://github.com/odoo/odoo/blob/32408a8dea43f57bba1a56c775ae228131720749/addons/purchase_stock/models/account_invoice.py#L129

There we have 2 problems : 

Problem 1: When fetching the layers linked to the account move line, 
we fetch both the incoming and the outgoing valuation 
layers because they are both linked to the dropship move. 
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L46
But we only want the incoming layer because the outgoing 
layer should not interfere with the bill.
nb: In a standard case like the one of the steps to reproduce, 
it would work to leave both layers, but : 
- it works for the wrong reasons : the quantity of the aml would 
first be consumed on the incoming 
layer and nothing would happen with the second layer as the 
quantity of the incoming layer is the same as the one of the aml.
- it would probably break in more complex use cases.

So it feels unnecessarily risky to leave it like that.

Problem 2: Inside _generate_price_difference_vals we call _replay_history
which returns two values that are assigned to two variables. 
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L82
The second variable, layers_and_invoices_qties is a default dict
which keys are tuples (layer L, invoice I) mapped with [the initial 
quantity invoiced by I on L, the remanining qty invoiced by I on L]
(here 'remaining' is related to invoice and has nothing to do with stock qties)
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L168-L171

So in our very basic use case, with a single invoice and a single layer, 
we should have a key (our layer, our invoice) linked 
to the value [1,1].
But this key is not in the dictonary. 

*The reason is the following :* 
inside _replay_history the parameter "history"
contains the layers and the amls (in our case 
1 layer and one aml which is self). 
Each layer is added to qty_to_invoice_per_layer
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L177-L178
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L191-L192

Then, for each aml: the layers are added to 
layer_to_consume, alongside their remaining 
quantity.
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L215-L221
And for each layer which has a quantity billed
by the invoice, a key is added to layers_and_invoices_qties
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L222-L231

In our case, the move linked to the layer is the
dropship move so _is_in() will be false and 
the layer won't be added to layers_to_consume.
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L220-L221
So the key will not be created.

*The consequence is the following:*
Later in _generate_price_difference_vals() we acces the value 
of this key (the key that should be there (layer, invoice)) 
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L91
to get the invoiced qty which will later be used to determine which 
quantity is still in stock and which is out of stock (giving us 
the quantities for the compensation layers and amls) 
but as the key does not exist, invoicing_layer_qty will have a value of 0 
so we will exit the loop and no amls or svls will be created
https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L92-L93

opw-5498878