**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

Forward-Port-Of: odoo/odoo#253298

# How to reproduce
- Go to the eCommerce page of any product
- In Edit mode, in the Customize tab, enable reviews
- Scroll down and click on the "+" button next to reviews

# The problem
The star rating element is squished / hidden behind other elements of the review

# Why
The star rating element is added to the mail composer element as follows :

```xml
<t t-inherit="mail.Composer" t-inherit-mode="extension">
        <xpath expr="//div[hasclass('o-mail-Composer-coreMain')]" position="before">
            <div t-if="env.displayRating and !message" class="o-mail-Composer-starCard d-flex">
```

The composer element has the display: grid attribute with different grid-areas defined :

```scss
.o-mail-Composer {
    grid-template-areas:
        "sidebar-header core-header"
        "sidebar-main core-main"
        "sidebar-footer core-footer";
    grid-template-columns: auto 1fr;
    grid-template-rows: auto 1fr auto;
```

But, o-mail-Composer-starCard does not define any grid-area, so the star rating element fills the grid in the first space available that is not already taken. That space used to be core-header, which worked totally fine, but this commit (https://github.com/odoo/odoo/commit/451c2c9) made it so the composer element always has a div in the core-header area. This made it so there was no available space for the star rating element (since core-header was taken) and so it defaulted to a position in the center of the composer.

Since there is now always a div element in the core-header area, this fix change the xpath of the star-rating so that it is put inside of that div.

opw-6046551

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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/6626b4649d [REL] 18.3.39 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/62a1fd4307 [FIX] clipboard : paste as value [Task: 5936382](https://www.odoo.com/odoo/2328/tasks/5936382)
https://github.com/odoo/o-spreadsheet/commit/09873f6c22 [FIX] Chart: Update geojson data [Task: 5224009](https://www.odoo.com/odoo/2328/tasks/5224009)
https://github.com/odoo/o-spreadsheet/commit/4d29b1d901 [FIX] charts: hierarchical charts should show formatted labels instead of raw [Task: 5913296](https://www.odoo.com/odoo/2328/tasks/5913296)
https://github.com/odoo/o-spreadsheet/commit/d901f29b3f [FIX] pivot: can add the same granularity [Task: 5949522](https://www.odoo.com/odoo/2328/tasks/5949522)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

**Steps to reproduce:**
- Install Accounting and l10n_be
- Switch to a Belgian company (e.g. BE Company CoA)
- In Accounting settings:
  * activate Peppol
  * set "Rounding Method" to "Round Globally"

- Create an invoice:
  * Customer: [a Belgian customer with a VAT]
  * Invoice Lines:

    | Label | Quantity | Price | Taxes | 
    | ------- | ---------- | ------- | ------- |
    |  Line 1   |   1.0    | 90.30 |   0%  |
    |  Line 2   |   0.45   |  2.54 |   6%  |
    |  Line 3   |   0.28   |  6.87 |   6%  |

- Confirm the invoice
- Send the invoice to Peppol

**Issue:**
The generated XML has a line with `<cbc:LineExtensionAmount>` set to 90.31, `<cbc:InvoicedQuantity>` set to 1.0 and `<cbc:PriceAmount>` set to 90.30, which fails the validation with the following error:

`[BR-E-08]-In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Exempt from VAT" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are "Exempt from VAT".`

**Cause:**
The use of decimal number in quantity generates a 0.01 rounding difference in the base amounts.
The extra cent is dispatched in one of the `<cbc:LineExtensionAmount>` node.

**Solution:**
There is no easy solution to handle these rounding cases. The solution used in this fix is to handle the extra cents as if they are cash rounding amount and declare them in `<cbc:PayableRoundingAmount>` node.

opw-5933545




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

Forward-Port-Of: odoo/odoo#253625