### Steps to reproduce:

- Create a fresh db with demo data
- Activate the "stock_barcode" module
- Activate the "point_of_sale" module
#### > Error: operation cannot be completed

### Cause of the issue:

Activating the "stock_barcode" module will create a second company. When you activate point of sale with the demo data, it will first install accounting and create a tax group for company 2 and then create the pos demo data:
https://github.com/odoo/odoo/blob/42fa237296f9b1fa556ae310b3273f863420e659/addons/point_of_sale/data/point_of_sale_demo.xml#L74-L78 However, during since no tax group is specified for this account.tax, it is expected to be computed here:
https://github.com/odoo/odoo/blob/42fa237296f9b1fa556ae310b3273f863420e659/addons/account/models/account_tax.py#L221-L222 But since no tax group was created for the current company, this computation will fail to give a result
https://github.com/odoo/odoo/blob/42fa237296f9b1fa556ae310b3273f863420e659/addons/account/models/account_tax.py#L232-L235 and the transaction will be aborted.

### Fix:

We create a tax group demo data that will be associated to the same company as the one for which our demo tax is created and hence provide a fall back value in case no other tax group was created.

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

Current behaviour:
---
Ivory Coast phone numbers aren't formatted correctly 
`0708151718 => 225708151718`

Expected behaviour:
---
`0708151718 => 2250708151718`
National number leading zero should be preserved

Steps to reproduce:
---
```py
from ... import phone_validation as wa_phone_validation 
wa_phone_validation.wa_phone_format(
    record, number='0708151718',
    force_format="WHATSAPP",
)
```
Result => `'225708151718'`
Should be => `'2250708151718'`
NB: record has an Ivory Coast `country_id`

Cause of the issue:
---
`WHATSAPP format` is country_code + national_number
But because `national_number` is an `int`, the leading zero gets removed.

Fix:
---
See [phonenumbers/phonenumber.py](https://github.com/daviddrysdale/python-phonenumbers/blob/7f60158f325ed2ee14212b71ef7e7dc2ce5f01bb/python/phonenumbers/phonenumber.py#L124 )
The `italian_leading_zero` is set True when the national number starts with a zero, 
and it should be kept. (ie: Italian numbers) `number_of_leading_zeros` counts the zeros.
Taking those into account when formatting.

opw-3963124

Forward-Port-Of: odoo/enterprise#67132

**Current behavior:**
Creating an immediate transfer and attempting to allocate it for
some existing document will not work- a valid document will not
show up in the list of sources.

**Expected behavior:**
A source that logically matches the immediate transfer should
be found for allocation.

**Steps to reproduce:**
1. Enable the reception report setting

2. Create a delivery for some product and confirm it

3. Create a receipt transfer and create a move line (not move)
     for the same amount of the product in the delivery

4. Validate the picking, click the `Allocation` smart button ->
     See that the delivery is not listed

**Cause of the issue:**
After the quantity field changes on stock move/move lines, in
`ReceptionReport::_get_report_values()` a move that is created
for an immediate transfer will have a `product_qty == 0`. This
means it is never added as a dict key which is later used to
search for moves belonging to allocation sources.

**Fix:**
Use `move.quantity` when `move.product_qty == 0` to gather valid
out documents when creating the report data.

opw-4075871

Forward-Port-Of: odoo/odoo#177545

**Current behavior:**
Having a product produced via kit bom with FIFO & automated costing method and valuation in a sale order with delivery via dropship:

When the orders and transfers are completed and the sale order is invoiced, the stock output and expense account on the invoice will have a credit and dedit (respectively) which is too high (the degree is proportional to the `product_qty` of each move in the dropship transfer).

**Expected behavior:**
The account entry lines should be accurate to the cost of the kit components.

**Steps to reproduce:**
1. Create a kit_product such that: - It has FIFO cost method and automated valuation - Has a component in a kit bom, also with FIFO and automated valuation as well as a vendor with non-zero price

2. Create a sale order for 2 of the kit product and set the SOL route to dropship

3. Confirm the sale order, purchase order, and validate the dropship transfer

4. Create an invoice for the sale order and confirm/post it

5. Observe that the stock output and expense accounts have a credit and debit (respectively) for 2x the correct amount

**Cause of the issue:**
The `product_qty` of each move in the dropship is errantly multiplied with the result of `_compute_average_price()`- this qty has already been taken into account.

**Fix:**
Remove this piece of the calculation.

opw-4050777

Forward-Port-Of: odoo/odoo#178976
Forward-Port-Of: odoo/odoo#176296

Since [1], the `MANDATORY_BILLING_FIELDS` are now returned through
the method `/portal._get_mandatory_fields`:
https://github.com/odoo/odoo/blob/b454a060a41961b7e0c9cc1ee6ec77b5cca1ec75/addons/portal/controllers/portal.py#L421-L423
Where `MANDATORY_BILLING_FIELDS` is a list defined on the class:
https://github.com/odoo/odoo/blob/b454a060a41961b7e0c9cc1ee6ec77b5cca1ec75/addons/portal/controllers/portal.py#L134-L136
This is a problem: the value is an object, so if the list is modified
during a call, the method will then return that modified list
instead of the initial one.

For instance, in `l10n_ec_website_sale`, we add some values to that
list:
https://github.com/odoo/odoo/blob/10b7c27a4fc873c6220d63a0686f484e92ae906b/addons/l10n_ec_website_sale/controllers/portal.py#L14-L17
Then, if we call again `_get_mandatory_fields` with a company that
is not EC, we will still have `l10n_latam_identification_type_id`
and `vat` in the list of mandatory fields. That is incorrect.

Looking at builds on runbot, some of them failed because of that error.
This is the case with the FW of [2] on 17.4 which is blocked because
of the above issue. Indeed, this commit contains a tour that
checkouts a cart with an EC company. And, in 17.4, this flow leads
to a call of `_get_mandatory_fields`. As explained, we will therefore
add the EC mandatory fields. So, if [2] is part of the code, and if we
try to run this:
`--test-tags=.test_checkout_address_ec,.test_qr_code_receipt_mx`
Where the first test comes from [2] and the second one is an
existing test in the code, it will fail: the first test will add
some values in `MANDATORY_BILLING_FIELDS`. Then, during the second
test, at some point we also check the mandatory fields: the method
will return the modified list (i.e., with the EC fields), and we will
not have any value for these unexpected fields -> the test will fail

[1] 9b9b0ee4c2d8a8a66e5e0456acbb780e5d8d6456
[2] 732b4fbbf3009769708f9c9cba57609d22f2a570

Forward-Port-Of: odoo/odoo#177349

Currently, when applying two discounts (from loyalty programs) that are applied on specific products, the second discount value does not match with the setup of the reward.

Steps to reproduce:
-------------------
* Go to the **Point of Sale** App
* Create a new product, P -> Price 100$, no tax applied
* Under **Products** select **Discount & loyalty**
* Create a new loyalty program
  * Rule 10 points per $ spent
  * Reward 1: 10$ on P for 10 points
  * Reward 2: 50$ on P for 40 points
* Open shop session
* Add P to the order
* Add reward 1
* Add reward 2
> Observation: The first reward is 10$ but the second is 55$

Why the fix:
------------
We will use the example from the given steps to explain what happens.

https://github.com/odoo/odoo/blob/e01df041b9428cf14cb150bdb0803c6f5ff2d80f/addons/pos_loyalty/static/src/js/Loyalty.js#L1376-L1377

On the first line of the above `discountable` and `discountablePerTax` will be
100. On the second line `discountable` will be 90 as the order total is 90, as the discount is counted here.

https://github.com/odoo/odoo/blob/e01df041b9428cf14cb150bdb0803c6f5ff2d80f/addons/pos_loyalty/static/src/js/Loyalty.js#L1417

Here we have `masDiscount` being 50 (`reward.discount`). Thus we end up with `discountFactor = min(1, 0.555)`. This factor is later on used to set the price of the discount line. The price is set up as follow.

https://github.com/odoo/odoo/blob/e01df041b9428cf14cb150bdb0803c6f5ff2d80f/addons/pos_loyalty/static/src/js/Loyalty.js#L1426

Where entry one corresponds to the value of `discountablePerTax` which is 100. Thus the discount is valued at `0.555 * 100 = 55.5$`.

To solve this we make `discountable` and `discountablePerTax` account for the discounts that aleady apply on the same product. We then look at what happens in the function `_getDiscountableOnSpecific` as in our case it corresponds to `getDiscountable`.

https://github.com/odoo/odoo/blob/e01df041b9428cf14cb150bdb0803c6f5ff2d80f/addons/pos_loyalty/static/src/js/Loyalty.js#L1250-L1251

As this comment says we don't want to discount more than what is available. In our case only 90$ are available since we have already applied the 10$ discount.

https://github.com/odoo/odoo/blob/e01df041b9428cf14cb150bdb0803c6f5ff2d80f/addons/pos_loyalty/static/src/js/Loyalty.js#L1269-L1273

We see that when we scan through the order lines, only discount from the same reward as the one we are trying to apply are counted. In short, if we were trying to apply another 10$ discount instead of the 50, then the line would be counted. But since the 10$ and 50$ discounts apply on the same product, they should both be counted.

We want to add more discount lines to `linesToDisount` because at the end, it is used compute `discountable` and `discountablePerTax`.

https://github.com/odoo/odoo/blob/e01df041b9428cf14cb150bdb0803c6f5ff2d80f/addons/pos_loyalty/static/src/js/Loyalty.js#L1331-L1341

We want to add the discount lines that applies to at least one product of the current reward. But we also need to check if that common product is on the order. If we imagine reward 1 applied on P1, reward 2 applied on P1 and P2 but we only have P2 in the order then reward 1 should not count when applying reward 2.

We filter on the `reward_type` to exclude lines that are related to free products rewards. 

With the current change there is a difference in behaviors when the discount is a percentage or a fixed amount. Since we now count the discounts at the end, we can remove this part of the code as it would count twice the discounts that are percentages.

https://github.com/odoo/odoo/blob/e01df041b9428cf14cb150bdb0803c6f5ff2d80f/addons/pos_loyalty/static/src/js/Loyalty.js#L1298-L1309

opw-4083557

Forward-Port-Of: odoo/odoo#179379
Forward-Port-Of: odoo/odoo#178352

**Steps to reproduce:**
	1- Install POS and POS restaurant
	2- Activate self ordering
	3- Create a self order from the mobile menu
	4- Create another order from the Shop POS

**Current behavior before PR:**
There is a conflict happening in order numbers between Self order and other orders where at some point we might have two orders with the same number. This is happening because when adding the order from Shop we get the sequence number from the JS side in Order class
https://github.com/odoo/odoo/blob/d82ffde0b316c52f726c247bf6f3d38e2e73e405/addons/point_of_sale/static/src/app/store/models.js#L1383 but in case of self order. We get it from ir_sequence https://github.com/odoo/odoo/blob/d82ffde0b316c52f726c247bf6f3d38e2e73e405/addons/pos_self_order/controllers/orders.py#L19 So we don't have a shared sequence between them.

**Desired behavior after PR is merged:**
We are now creating another sequence for self-order and as agreed with the PO we will have
'S' before the order number if the order is self-order

opw-3809595

Forward-Port-Of: odoo/odoo#162119

**Current behavior:**
Having some product with FIFO cost method, if you use it as a
component in an MO, confirm and produce all, then unlock the MO
and adjust the component quantity to be smaller than originally
entered, the standard price of the product will be set to zero.

**Expected behavior:**
This operation should not affect the standard price of the
product.

**Steps to reproduce:**
1. Create a product with FIFO cost method and real time
     valuation

2. Create a purchase order for 10 of the fifo product, set the
     price unit on the order line to 100

3. Confirm the order and receive the product

4. Create a manufacturing order for 1 of some other product, and
     set the components to be 100 of the fifo product

5. Confirm the MO, consume the fifo product and produce all

6. Unlock the order and set the quantity of components consumed
     to 1 (from 100)

7. Observe that the standard price of fifo product is now 0

**Cause of the issue:**
A move for an MrpProduction record has a price unit == 0. Commit
https://github.com/odoo/odoo/commit/1fb4d356b5115a82dbbb004efe2e26917021b339 forces use of this when a move's picking type is
manufacturing, however it should be a narrower condition to only
do so when the move corresponds to the finished moves of a
manufacturing order.

**Fix:**
Moves for components of a production should not be able to
modify the `standard_price` of the moved product- only the final
product's cost should be able to change based on the value of
such a move.

Use a product's `standard_price` field when creating SVLs for
moves corresponding to raw production moves.

opw-4134037

Forward-Port-Of: odoo/odoo#178015