Before this commit:
When returning a dropshipping, the valuation layers created do not have
the correct accounts on it:
 - Valuation -> Input   for the first SVL
 - Output -> Valuation  for the second SVL

After this commit:
For a dropshipped move, valuation layers have the following chain
of accounts:
 - Input -> Valuation   for the first SVL
 - Valuation -> Output  for the second SVL
Therefore, the return should have it reversed:
 - Output -> Valuation  for the first SVL
 - Valuation -> Input   for the second SVL

Steps to reproduce:
1. Create a dropship product with automated inventory valuation
2. Create a Sales Order, go on the PO and confirm it
3. Set quantities and validate dropshipping
4. Return delivered product (dropship return)

opw-3391174

closes odoo/odoo#132864

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

When performing a manual stock revaluation, the value difference is distributed
equally among the available stock. This method breaks down however in case of a
devaluation where some items in stock are already valued less than the unit
cost difference: this results in a negative value.

This commit will prevent such devaluations by raising a UserError whenever the
remaining value of a stock.valuation.layer becomes negative. Additionally, after
a revaluation, the standard_price field will now also be updated for fifo valued
products.

opw-3340298

closes odoo/odoo#126157

Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

Before this commit:
When returning a transfer in AVCO/FIFO, the return's value is not always
the same as the original delivery. The unit cost for the return was
rounded, which introduced rounding errors.

After this commit:
When returning a transfer in AVCO/FIFO, the return's unit cost is not
rounded, allowing the correct value to be set.

Steps to reproduce:
1. Create a product and change its category costing method to AVCO
2. Purchase the product qty: 1 price: 13.13
3. Purchase the product qty: 1 price: 12.20
4. Sell the 2 product and deliver it
5. Create a return for the delivery
6. The value on the delivery is 25.33, but 25.34 on the return

opw-3358531

closes odoo/odoo#126546

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

[1] is not enough. First, when installing `stock_account`, the
post-install hook will only add `False` values to the first company.
We should do it for all existing ones

Second, the field `property_valuation` is company-dependent:
https://github.com/odoo/odoo/blob/640907ec1852c4e477957c865549a87d3ae840dd/addons/stock_account/models/product.py#L708-L714
And when creating a new company, its value will be (by default)
`manual_periodic`. Therefore, the other properties should also be
set to `False`.

Note about test modification: for the tests in `stock_landed_costs`
module, we set the categ to auto so the stock accounts are defined.
Otherwise, when validating the landed costs, it will lead to an error
https://github.com/odoo/odoo/blob/608ed487b61c81e38a5d0b856732a8b94c6df64a/addons/stock_landed_costs/models/stock_landed_cost.py#L416-L417

[1] 9dc7835c

OPW-2746384

Part-of: odoo/odoo#117920

To reproduce the issue:
1. Create a product:
   - Type: Storable
   - Category:
     - Costing Method: AVCO
2. IN 2 @ 4.63/u
3. IN 5 @ 3.04/u
4. OUT 0.1
5. Repeat step 4 70 time in total, so that the final quantity is 0
6. Open the inventory valuation of the product

Error: the total value is $-0.04 instead of $0.
The compensation of rounding issue is stuck by a check that ensure we don't erase a valuation error.

However, this check can never succeed with small quantities, here is the mathematical proof:
°Current check: rounding_error <= qty * curr_rounding / 2
With:
1) rounding_error >= curr_rounding
2) 0 < qty < 2
3) v1 = rounding_error / curr_rounding
4) v2 = qty / 2
We can be sure that:
5) v1 >= 1 because of 1)
6) v2 < 1 because of 2)
7) v1 > v2 because of 5) and 6)

° rounding_error <= qty * curr_rounding / 2
° rounding_error * curr_rounding <= qty * curr_rounding / 2 * curr_rounding
° rounding_error / curr_rounding <= qty / 2
° v1 <= v2
==>> This contradict 7), hence this check can never be True for qty < 2

To fix this issue, we change the check to:
 ° rounding_error <= qty * curr_rounding / 2 OR rounding_error <= curr_rounding
 Where the 1st part doesn't change, but the second one is true when rounding_error == curr_rounding

closes odoo/odoo#115516

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

## To reproduce:
=> Import 5 units of P1 at $5
=> Import 2 units of P1 at $2
----> Current valuation: Qty 7, Value $37, Std Price $5.29 (rounded)
=> Change standard Price to 7
----> Current valuation: Qty 7, Value $48.97, Std Price $7

## Solution:
To compute the value delta, we don't use the current standard_price (which may be rounded), but the current value_svl.

OPW-3233260

closes odoo/odoo#115311

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

To reproduce the issue:
1. Create a product:
   - Type: Storable
   - Category:
     - Costing Method: AVCO
2. IN 1000 @ 0.17
3. IN 800 @ 0.23
4. OUT 1000
5. OUT 800
6. Open the inventory valuation of the product

Error: the total value is $-6.00, it should be zero

Once all products received, the standard price is $0.20. Its value
has been rounded because the real value is
`(1000 * .17 + 800 * .23) / 1800 = 0,196666667`
The standard price will create a difference when using the products,
because:
`(1800 * .20 = 360) != (1000 * .17 + 800 * .23 = 354)`
That's the reason why a feature tries to compensate such rounding
errors. So, step 4, when preparing the values of the out-SVL, we
check if there is a rounding error, and we find a difference of $6,
which is correct. However, the difference is above the treshold, so
we will not consider it as a rounding error:
https://github.com/odoo/odoo/blob/3ff51daa93a1d670b8f67f79418d4dd48e94875f/addons/stock_account/models/product.py#L197-L200



Here is the issue: the threshold is based on the outgoing quantity
(1000) while the value difference is based on the whole quantity
(1800). This difference should also be proportional to the outgoing
quantity.

Note: The fix will still not work with a small quantity. The only and
best solution is to change the type of the SVL unit cost into a
float.

OPW-3101374

Part-of: odoo/odoo#108072
Co-authored-by: Adrien Widart (awt) <awt@odoo.com>

Issues:
1) When the inventory valuation is Manual the stock accounts field of the
product category should be empty and they should be set when the
inventory valuation is Automated.
2) For the moment at installation all the categories have the Manual default
value and the comapy account default values for the stock accounts (not
respecting condition 1)

Solutions:
For issue 1 we add checks on the write and create functions of the product
category model so that after creation/modification the instance respect the
condition
For issue 2 we add at the end of the post_hook script some code to set an
empty stock account property for every product category.

opw-2746384

closes odoo/odoo#98379

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Steps to reproduce the bug:
- Create a Storable product “P1”:
    - UOM: unit
    - Update the qty to 100
- Create an out transfert:
    - Product: P1
    - Qty: 2
    - UOM: dozens
    - Validate the transfert
- Click on the valuation button
- an SVL is created with Qty: 24 → 2 pack of 12
- Go back to the picking:
    - Unlock it
    - change the done qty from 2 to 3
    - Lock the picking

Problem:
The quantity on the new SVL is not converted to the default UoM set on
the product.

In the write function of `stock.move.line` we calculate the difference
between the old and the new qty (3 - 2), then, the
`_create_correction_svl` is called:
https://github.com/odoo/odoo/blob/15.0/addons/stock_account/models/stock_move_line.py#L45-L48

without converting the diff qty into the product uom,
The `_create_out_svl` function is called with the `forced_quantity`
parameter:
https://github.com/odoo/odoo/blob/15.0/addons/stock_account/models/stock_move_line.py#L66
As it is a forced quantity, it will not convert it:
https://github.com/odoo/odoo/blob/14.0/addons/stock_account/models/stock_move.py#L188



Solution:
Convert diff qty in the `_create_correction_svl`, to avoid converting it
in every function it may call

opw-3041279

closes odoo/odoo#104096

Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

Steps to reproduce:
- Define the decimal accuracy for the "Product Price" to 5
- Create a product with "cost = 0.00875"
- On-hand product = 10'000
- Change the cost to "0.00975"

Issue:
In Inventory valuation, for the product you will have two layers valued at:
- 87.5
- 12.5
Instead of:
- 87.5
- 10

Cause:
We round with currency precision

Solution:
Use the "Product Price" decimal precision as it is the case when we define a "standard_price"
https://github.com/odoo/odoo/blob/4c7ef5673b8fc28bf7fe2bc36fe2450987f15a28/addons/product/models/product.py#L110-L112



opw-2724975

closes odoo/odoo#93192

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

If a picking is owned by the company and if the user receives a FIFO
product, a SVL will be created without any journal entry

To reproduce the issue:
(Need account_accountant)
1. In Settings, enable "Consignment"
2. Create a product category PC:
    - Costing Method: FIFO
    - Inventory Valuation: Automated
3. Create a product P:
    - Type: Storable
    - Category: PC
    - Cost: 1
4. Create and validate a receipt:
    - Owner: <The company of the picking>
    - With: 1 x P
5. Open the generated SVL

Error: There isn't any journal entry associated with the SVL

When validating the picking, a method filters the SML that will be
considered during the SVL creation process. This method filters out the
SML that has an owner and if this owner is not the company:
https://github.com/odoo/odoo/blob/f8e2f2a4836d23fe507cad3bd5cac92d41ca91a3/addons/stock_account/models/stock_move.py#L69-L70

However, the filter in the journal entries creation is not that accurate
and does not correspond to its comment line:
https://github.com/odoo/odoo/blob/f8e2f2a4836d23fe507cad3bd5cac92d41ca91a3/addons/stock_account/models/stock_move.py#L475-L476



OPW-2859144

closes odoo/odoo#92603

X-original-commit: 2ce86860
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

The SVL of in/out moves may be different because of rounding

To reproduce the issue:
(Need purchase,sale_management,stock)
1. In Settings, enable "Multi-Currencies"
2. Edit the USD currency:
    - Rounding factor: 1.0
3. Create a product category PC:
    - Costing Method: FIFO
4. Create a product P:
    - Type: Storable
    - Category: PC
5. Create a purchase order PO with one line:
    - Product: P
    - Quantity: 0.5
    - Unit Price: 3.0
    - Taxes: None
6. Confirm the PO and receive P
7. Create a sale order SO with 0.5 x P
8. Confirm the SO and deliver P
9. Inventory > Reporting > Inventory Valuation

Error: The quantity of P is zero but its total value is 0.50$

When receiving P, a SVL is created but does not round the value. So, we
have 0.5 x P in stock with a value equal to $1.50
Then, when deliver the product, the FIFO process is executed and create
a second SVL. However, this time the value is rounded:
https://github.com/odoo/odoo/blob/2e4fdcb84ba6375bb51fe71355168cebe2d922a0/addons/stock_account/models/product.py#L290


Therefore, the SVL of the out move has a value equal to $2. This
explains why, when checking the inventory valuation, the value is $-0.50

OPW-2724864

closes odoo/odoo#89743

X-original-commit: bf9b03a8
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

Steps to reproduce:

Decimal Accuracy - Product Price = 2
- create a product `alc 50%` with BOM (10 unites = 1 unit Water [cost=0.14]; 1 unit Alc [cost=0.08])
- Set `quantity on hands` = 10,000
- Trigger `Compute Price from BoM`

-> In Reporting > Inventory Valuation; click on the layer; in Other Info: You will see "Product value manually modified (from 0.0 to 0.022000000000000002)"
=> It can cause computing mistakes as we changed the costs

Cause:

The value is calculated as the difference between the New Price (cost) and and the current Product Standard Price (cost).
But, on one hand the Product Standard Price is rounded to the number of digits defined in the Decimal Accuracy for the Product Price.
On the other hand, the New Price is used as is with no rounding.

If we add an extra step and modify the cost of the Water to 0.45 and trigger again the `Compute Price from BoM` we will have:
"Product value manually modified (from 0.02 to 0.053000000000000005)"

Solution:

Use for the New Price the same rounding precision as we use for the Standard Price.

Example:

Product		Price/unit
--------------------------
Water		0.14
Alc. 100%	0.08

BoM: Alc. 50%
Product		Quantity Needed
--------------------------
Water		0.1
Alc. 100%	0.1

Cost/unit of Alc. 50%: 0.022 => 0.02 (standard_price is rounded)
Set Quantity on Hand: 10,000

Stock Valuation: 200 = 10,000 * 0.02
=> The standard_price is rounded to the second digit when intialized

Product         Price/unit
--------------------------
Water           0.45
Alc. 100%       0.08

BoM: Alc. 50%
Product         Quantity Needed
--------------------------
Water           0.1
Alc. 100%       0.1

Cost/unit of Alc. 50%: 0.053
Set Quantity on Hand: 10,000

Stock Valuation WITHOUT FIX: 530 = 200 (first layer) + 330 (second layer) = 0.02 * 10,000 + (0.053-0.02) * 10,000
Stock Valuation WITH FIX: 500 = 200 (first layer) + 300 (second layer) = 0.02 * 10,000 + (0.05-0.02) * 10,000

=> Without fix, the value is computed with the rounded standard_price and the not rounded new_price.
=> With fix, the new_price is rounded the same way as the standard_price

opw-2724975

closes odoo/odoo#87600

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

How to reproduce:
1- Create Product Category "PC" AVCO|FIFO Automated.
2- Create Storable Product "P" with product category PC and unit cost to 1.
3- Create SO with 10 units of P.
4- Create PO with 10 units of P and unit cost of 2.
    Delivery of the SO should now have 2 IV layers, with one being "Revaluation of XXX (negative inventory)"
    Global IV of P should be 0 qty, 0 value.
5- Return the delivery order of SO.
6- Open valuation of the return

Error: The value is 0, should be 20
In `_get_price_unit`, `price_unit` is taken on the last svl of the origin_returned_move_id, in our case it's the revaluation layer.
`_get_price_unit` now take all svls of origin_returned_move_id into account.

OPW-2784033

closes odoo/odoo#88110

X-original-commit: f8e2f2a4
Signed-off-by: Arnold Moyaux <arm@odoo.com>

Expected Behaviour

When updating the cost of a product with a negative quantity and then
making an inventory adjustment, the final value should be corrected according
to the current cost of the product

Observed Behaviour

In the case we had a negative quantity when changing the cost, the compensation
layer will be ignored when doing an inventory adjustment afterward, leading to
an incorrect total value in the inventory valuation

Reproducibility

This bug can be reproduced following these steps:
- Create Storable product with costing method = AVCO Automated, Update cost to 100$
- Sell 10 units of this product (Inventory valuation at -1000 $ for -10 units)
- Update cost of the product to 10 $ (Inventory valuation at -100 $ for -10 units)
- Create an inventory adjustment to set the quantity of the product to 0.
==> Inventory valuation is a 900 $ for 0 unit of our product

Related Issues/PR

- opw-2635692

closes odoo/odoo#86328

X-original-commit: 2e4fdcb8
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Hendrickx Anthony (anhe) <anhe@odoo.com>

To reproduce the issue:
(Need purchase,sale_management)
1. Create a product category PC:
    - Costing Method: FIFO
2. Create a product P
    - Type: Storable
    - Category: PC
3. Create a PO with 1 x P @ 10 + Receive P
4. Create a PO with 1 x P @ 0 + Receive P
5. Create a SO with 1 x P + Deliver P
6. Create a SO with 1 x P + Deliver P
7. Process a return for sold P at step 6
8. Open the valuation of the return

Error: The value is 10, should be 0

In `_get_price_unit`, `price_unit` is defined with the correct value
(i.e., `0`), but the if-condition of the `return` is not respected, so
another value is used

OPW-2735502

closes odoo/odoo#84590

X-original-commit: c1f7c1dc
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

When reversing an invoice that contains some anglo-saxo AML, the new
anglo-saxo AML should have the same unit price than the original one

To reproduce the issue:
(Need account_accountant,purchase)
1. Create a product category PC:
    - Costing Method: AVCO
    - Inventory Valuation: Automated
2. Create a product P:
    - Type: Storable
    - Product Category: PC
3. Create a purchase order PO01 with 2 x P for $10
4. Confirm PO01 and process the receipt
5. Create and Post an invoice INV01 with 2 x P
    - As listed in the journal items, the anglo-saxo lines have been
generated with a value of $20
6. Create a purchase order PO02 with 2 x P for $20
    - The cost of P becomes $15
7. Confirm PO02 and process the receipt
8. Add a credit note to INV01:
    - Credit Method: Partial Refund
9. Set the quantity of P to 1
10. Post the new invoice INV02

Error: The anglo-saxo lines are listed in the journal items, which is
correct, but their value is $15 (the new cost of P) while it should be
$10

When reversing an invoice with the "partial refund" method, the
anglo-saxo lines are generated via the regular flow (as if it were a
"standard" invoice). Therefore, when getting the unit price of the line,
it uses the product's standard price. In such situation, it should use
the unit price of the original line.

OPW-2646926
OPW-2628215

Part-of: odoo/odoo#82547

Commit ad5ac192 adds a sudo() in the
test condition but not inside the condition.

Close #69144

closes odoo/odoo#69151

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

This commit makes the product's value computation in sudo mode in order
to be performed even by stock users.

closes odoo/odoo#67108

X-original-commit: a87c7fba
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

This fix (odoo/odoo#46850) was too permissive and fix too much
stock valuation issues (other than rounding error) under the hood.
The problem of the "too permissive" is will hide some errors
without get any feedback about them. Also, it changes the SVL value
without any explanation.

To avoid the first issue, apply a threshold on the rounding adjustment.
This threshold is '(quantity_out * smallest_value_of_the_currency) / 2'
(`smallest_value_of_the_currency` = `rounding` field of the related
currency).
Also to improve debugging, add a line in the description
about the rounding adjustment done in a SVL

task-2452786

closes odoo/odoo#66662

X-original-commit: 74ba8039
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

To reproduce, product A in AVCO:
- Buy 2 product A at 1.00 $
- Buy 1 product A at 1.01 $
- Sell 3 product A.
- The stock valuation won't be correct: still remain 0.01 in
stock without quantity and the svl related to the sell
have a value of 3.00 (instead of 3.01)

To fix:
In case of AVCO, add the rounding error value to the out
stock move layer.

closes odoo/odoo#65103

X-original-commit: f6b019fc
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

- Activate Anglo-Saxon accounting
- Set a foreign currency rate to 2.0
- Create a product A:
  Inventory Valuation: 'Automated'
  Costing Method: 'Standard Price'
  Cost: 10.0
  Public Price: 100.0
- Create an invoice in foreign currency
- Add 1 unit of A => the total amount is 200.0
- Confirm the invoice

The Amount Due is 100.0 instead of 200.0.

This happens because the Anglo-Saxon lines have the company currency,
while the other lines have the foreign currency. Because of this, the
`_compute_amount` method considers the move as multi-currency to compute
the various amount. However, the Anglo-Saxon lines should be neglected.

This happens from 14.0 because all lines have a currency. In previous
versions, lines in the company currency didn't have the `currency_id`
set.

opw-2390107

closes odoo/odoo#62543

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

The validation of a stock move without quantity done create an empty
stock valuation layer. This is not a wanted behavior as :
1. it create record without useful information (0 value, 0 remaining
qty, 0 remaining value)
2. The landed cost value is set on a wrong layer in case of complete
backorder.

This commit bypass the valuation process on a move if it is validated
without any quantity.

opw : 2328258

closes odoo/odoo#58770

X-original-commit: 01e21735dbf3ac2fe975323cee2f4bb93e4ca747
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Add an easy way to not post the entries in the future when calling
post() on it, but rather set it to be auto-posted at accounting date.
This is useful when we are creating a lot of entries in batch and some
might be in the future, some in the past, and we don't want to separate
that in two batch every time. (asset, accrual, transfer,... )

l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.

--task: 2301180

If run post_install, this setup class is not necessary.

Should only interact with them via python code in a controlled
environment, no direct call with RPC

This restricts the attributes of a BaseModel instance to `env`, `_ids`
and `_prefetch_ids`.  This way, one can only assign fields on a record;
other assignments are programming errors.

This also reduces the memory footprint of records from 168 to 64 bytes
(-62%), and makes their instanciation faster.

closes odoo/odoo#51075

Related: odoo/enterprise#10529
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

Add a way to create a munual stock valuation layer, create
a stock valuation layers implies :
- Change the stardard price with the new valuation by product unit in case of AVCO.
- Create a manual stock valuation layer with the added value.
- Update the remaining value of current valuation layer.
- If the Inventory Valuation of the product category is automated, create
related account move.

task-2123752

For the stock_account module:
- Remove unused import
- Remove deadcode, unused _anglo_saxon_sale_move_lines method
and useless 'continue' keyword
- Fix duplicate name test (test_average_perpetual_8 defines twice)
- Make comments flake8 compliant

task-2123752

task-id: 2028z813

Task 2146469

Rework the name computation:
* It doesn't use ir.sequence anymore
* It is an editable computed field
* Add a renaming tool

This allows the user to tweak the sequences more easily than having to
get through the ir.sequence settings.

The sequence depends on a parameter of the journal: continuous, montly
and yearly restart of the sequence. Everytime a new period is started,
try to make a pattern form another period.

The incrementing is done by taking the previous name, ordered
lexicographically, splitting it by taking the digits at the end, adding
1 and re contstruct with the prefix.

** This means there could be cases where the prefix has a big importance
on the next number. For instance, if you have
INVOICE/2019/0001
INVOICE/2019/0002
and then rename the last one to INV/2019/0002, don't expect the next
number to be INV/2019/0003. It will be INVOICE/2019/0002 (again) because
the highest number was INVOICE/2019/0001.
You will then end up with
INVOICE/2019/0001
INV/2019/0002
INVOICE/2019/0002

closes odoo/odoo#41485

Related: odoo/enterprise#7189
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

This commit will fixed the error when product has some stock quants
and product category with 'Automated' valuation method, is set to that product.

==============================

Steps to product the above mentioned error:
1. Create product with any category which has 'Manual' valuation method.
2. Update 'On Hand' quantity for the same product.
3. Create product category with valuation method set to 'Automated'.
4. Now set the above product category to the same product which you created in step 1.
5. And Click on the save button.

==============================

Also edit the test case.

closes odoo/odoo#43755

Task: 2155804
X-original-commit: c62dea6a
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

Running the vacuum in avco indeed fixed the estimated value on the
delivery but it did not update the standard price afterwards, making it
possible to have an inconsistent standard price with the actual value in
stock, as described in [0] and in the task [1].

A test was added (and validated) in the layers test file and an two old
one were fixed. test_average_perpetual_2 displayed also a different
missing bit: the vacuum should run when the user unlock and increments a
receipt.

[0] https://github.com/odoo/odoo/pull/41669


[1] 2154638

closes odoo/odoo#42292

X-original-commit: 6e4c9b8219db0c94c29f5ee145998e6f1597bb55
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

Before
======
If a product is FIFO, the standard price is the unit cost of the last released.
```
+ 1 product @ 10€
+ 1 product @ 15€
- 1 product
-> Actual standard price is 10€

```

After
=====
If a product is FIFO, the standard price of the ``product.product`` is the
unit cost of the next product which will  be released
```
+ 1 product @ 10€
+ 1 product @ 15€
- 1 product
-> Actual standard price is 15€

```

Task #2038418

When returning a delivery where the value was taken from different
receipt, the last receipt's unit cost was wrongly used when returning
the delivery.

Now we use the `unit_cost` of the delivery when returning it.

task-2150889

closes odoo/odoo#41564

X-original-commit: 468ab4f2
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

Overwrite the method ``write`` of the model ``product.product``.

When we write on ``standard_price``, if
- the context key ``disable_auto_svl`` is not set
- the ``cost_method`` is not "fifo"
We automatically compute ``stock.valuation.layer``

(before we needed to manually call ``_change_standard_price``)

Task #2031422

closes odoo/odoo#41265

Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

There is no unique constraint on the properties to avoid having two
properties for the same field, company and res_id.

Having two properties for the same field, company and res_id, leads to
inconsistencies through the code, as reading a company-dependent field
nondeterministically returns one of the available property value.

So now, before creating a property, we have to check that there is not
already a value for the field, company and res_id and write or create
depending on if it is already exists.

The properties of specific records already satisfy the constraint thanks
to the implementation of company-dependent fields that use the method
`set_multi`.  We added a method `set_default` to set generic properties,
and its implementation does the right thing.  It also simplifies the
code to set such properties, by the way.

closes odoo/odoo#40473

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>