We need to increment the value of another layer. We don't want to write
on this layer in place as we used to do for multiple reasons:
- valuation at date: before the application of an lc, the value should
not change
- if the layer was consumed, we would need to adapt the consumers and
if one day we would have needed to understand what happened in the
fifo stack it would be hell
So we allow to create a valuation layer linked to another valuation
layer through a simple M2O O2M. At the time it is only used on the
landed costs to add value and no quantity so the code expects it would
be the case and it is not enforced. We adapt `_run_fifo` to use the full
value.
We also add a stat button on the landed cost to access the valuation
layers, like what is done for the picking and manufacturing orders.
task-1875873
Marking the invoice as open before creating the account moves breaks the
anglo saxon code as the invoice is considered openned before the account
moves are even created, see _get_anglo_saxon_price_unit of sale_stock
and the computation of qty_done (which should be renamed invoiced qty).
We did not test all the implications of this commit since the invoice
model will be removed anyway.
related to rev 299f9f1eb0
task-1875873
The tests of this module showed multiple issues with the anglos axon
accounting entries creation so we fix them by getting the value on the
valuation layer and not directly on the stock moves.
About the changes in
test_crossdock.py
> To change a standard price, we need to open the wizard
test_lifo_price.py
> To change a standard price, we need to open the wizard + read the
valuation on the layers.
test_stockvaluation.py
> Now that we create a layer in and out for a dropshipped move, the
accounting entries are similar to an in followed by an out, thus we need
to increment the number of generated AML. Not that the balance of the
accounts stay the same.
There's a slight change in fifo_perpetual_anglosaxon_ordered though.
Let's say for a start that this config doesn't make sense. Ordered means
we don't read the value on the stock move to create the accounting
entries but only the standard price. We had to change 8 by 10 in this
test because, before this task, the standard price was updated when
running fifo, even in dropshipped. As the PO line was valued at 8, the
anglos axon in stock out was at 8 because the standard price was changed
to 8 after the delivery.
task-1875873
No more hijacking _account_entry_move with context keys.
_get_accounting_data_for_valuation
> no changes
_prepare_account_move_line
> only use the cost, not the value in context
> take description as arg to pass it to _generate_valuation_lines_data
_generate_valuation_lines_data
> use the description received in arg
> remove forced ref in context
_create_account_move_line
> add a qty, descritpion, cost, svl_id as arguments
> remove forced_quantity fron context
_account_entry_move
> add a qty, descritpion, cost, svl_id as arguments
task-1875873
The new code was sitting next to the old one, now that everything is
adapted (minus the cost method changes), we can remove the old one.
We also adapt the valuation wizard to use the stock valuation layer
action, now that the others are removed.
task-1875873
A finished move is considered as an incoming move and will pass by
_create_in_svl. We thus compute the price_unit that will be set on the
valuation layer.
We also set a stat button on the MO displaying the valuation
layers, similar to the one on the picking.
task-1875873
We standardize the dropshipping by handling it as it was an receipt
directly followed by an out.
We also follow the same logic whatever the cost method, ie we don't run
fifo or update the AVCO.
task-1875873
Now that the vacuum is implemented and ran in AVCO, we can unskip the
old avco negative tests and implement new ones in
test_stockvaluationlayer to explain why we wanted to run the vacuum in
AVCO (see test_negative_1).
task-1875873
Re-implement _run_fifo_vacuum on the product this time with
float_is_zero and without remaining_value.
Trigger the vacuum at each receipt. Before it was done in the scheduler
each night, meaning the valuation on the move was not really
understandable nor consistent (the estimated value could be fixed by
some other move than the next receipt).
task-1875873
We don't implement fifo negative handling in this commit.
We make sure we run fifo in average mode to get a proper remaining_qty
field.
`_run_fifo` is now a method on product (since it could be user outside
of a stock move context). It is really similar to its ancestor on the
stock move, with a few float_is_zero and compare more and a missing
remaing_value.
We move the valuation sanity check into a proper helper,
_sanity_check_for_valuation.
We complete the _create_correction_svl method with accounting entries.
task-1875873
One of the goal of this refactoring is also to run the vacuum when the
cost method is AVCO. This will be used allow already out landed cost
on AVCO and also to have a consistent value when going into negative.
We update `_prepare_in_svl_vals` to set the remaining_qty field that
will be used when fifo is implemented. On the stock move, we create the
layer in with the real price unit of the move and adapt
product_price_update_before_done. This method will now compute the AVCO
according to the quantity valued in stock (quantity_svl) instead of all
the quantities in stock (qty_available), which was wrong (qty_available
could contain consigned quants).
We also make sure to recompute the avco when editing a done move.
We don't implement yet the negative handling as we'll need fifo for
that.
task-1875873
Valuation of standard move: We introduce _create_in_svl and
_create_out_svl and call these method in _action_done only on the
standard move, the other valuation methods still use the old code. We
hijack _account_entry_move to create journal entries anyway for the
valuation layer with a minimal diff. Helpers for the valuation layers
creation are added on the product because we will need to create similar
layer without stock move later on when we'll implement changes of cost
method. We also make a first implementation of the edition in the past
to make some tests pass, it will be completed with other cost method
implementation
Change of standard price: Before this commit, the wizard to change the
standard price was only displayed in perpetual, because it was used to
create accountign entries. We also use this wizard in manual now,
because we want to create a stock valuation layer. Fortunetaly, the
accounting fields of this wizard are not required if the product has a
manual valuation. And the new method is private.
We adapt the existing tests as well as we can and include the start of a
new battery of tests: test_stockvaluationlayer.py
task-1875873
This commit brings the model, views and compute method for the value and
the quantity valued. An ir rule prevents to read the value of another
company. Stat button are added on done picking to access the generated
layers.
Further commits will adapt one by one the cost method to actually use
the stock valuation layer when
As the goal is to move the valuation fields away from the stock move, we
set the necessary fields on the layer. Note the absence of `remaining_value`.
task-1875873
Before this commit, there were the `_is_in`, `_is_out`, `_is_dropshipped`
and `_is_dropshipped_returned` helpers on stock move. These methods were
called on the stock moves upon their validation to know if they should
be valued.
But the valuation of a stock move actually depends on its move lines[0].
These helpers weren't convenient enough since every cost method should
implement the logic to get the valud quantity (see _run_valuation and
_run_fifo).
We add helpers returning in and out move lines and `_is_in` and
`_is_out` to use these helpers to decide their return value.
We also expose a list of valued type (`_get_valued_types`) that will be
used in the move validation to check every `_is_*`helper without calling
them explicitely. Once we'll know the valued type of each move to
validate, we'll be able to call the methods actually doing something
with the valuation in batch. We prepare this in _action_done to lay the
foundation of the batch calls when the stock valuation layer will be
implemented.
We took the opportunity to fix an edge case of the consignment: if the
owner of a move is the company of the move, it should be valued.
[0] 48f4ce4afa
task-1875873
`_get_price_unit` is used to get the price to value a stock move and
returns `unit_price` if present (most of the times it is set by purchase_stock
to copy the price unit of po line) or the standard price.
Note that a return copies the original move and `price_unit` is set as
copy False.
Before this patch, a return of a return used the standard price (due to
the copy False), which doens't bring any issue but could be confusing
as explained in the following receipt scenario.
On a receipt, return and rereturn. The original and rereturn move may
not have the same price if the standard price has changed between the
operations, which is weird since there's a unit price on a potentially
linked po line.
On an delivery, there won't be any effect since the valuation methods do
not use the result of `_get_price_unit` but force it to the standard
price (standard and avco) or run fifo.
task-1875873
This table tracked standard price changes.
It was used to compute the valuation at date in AVCO and standard
through `get_history_price`.
The next commits will introduce the stock valuation layers, separating
the valuation from the stock move. As a valuation layer will be created
when a standard price is updated on the product or when a stock move
impacts the valuation, the information from this table will be
duplicated.
We don't plan to adapt `get_history_price` to work with the valuation
layer since the valuation report at date and today will be the same: a
grouped list on the valuation layers with eventually a domain on the
date.
task-1875873
New Rental App (sale_rental) : community side.
1. Product configurator:
Refactoring to ease product configurator extension (e.g. rental configurator)
Closes#33371
2. Event_sale
Fix tests of event configurator s.t. they still work when sale_rental is installed (with its extension of the product configurator).
3. Sale
XML names for XPath in rental extension
Minor UI changes
[Enterprise PR](https://github.com/odoo/enterprise/pull/3939)
Related to #30855
Task 1909410
closesodoo/odoo#32210
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
- Create a product A of type "Service", Invoice based on "Milestones",
Service Tracking "Create a task in a new project".
- Create a new SO with A, confirm.
- Go the to task associated to the SO, go to "Timesheets" tab, add an
entry
- In the SO, edit the delivered quantity
- Create invoice, validate
Back to the SO, delivered quantity is reset to 0.
We make sure to filter out SO lines which have a delivered quantity set
manually.
Introduced by d6ad22227c.
opw-1982020
closesodoo/odoo#33991
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit reverts commit 492764c
*Note for forward port*
This commit will conflict with 76ee0af. Keep this version.
TL;DR: the fix had unintended effects and the original problem has been
fixed by b5c2004 in the mean time.
Why the original commit?
------------------------
To know if the current user has the rights to approve/delete a leave,
two boolean fields are computed (respectively `can_approve`
and `can_reset`). Associated buttons are shown in the form view according to
the field values.
In the compute methods, the `check_approval_update(state)` method is called.
This method checks various conditions, including `ir.rules` by calling the ORM
method `self.check_access_rule('write')`. If one condition or one `ir.rule`
is not met, an Error is raised.
If the method raises, the user does not have the rights.
The exception is catched and the field `can_approve|reset` is set to False.
However, an unexpected behaviour happens when fields are re-computed
in the context of an onchange. In an onchange, `self.ids` is an empty list.
When checking ir.rules, the `_filter_access_rules()` method is used
to retrieve valid records in self by checking every record against ir.rules.
If some records are not in the valid set, they are considered invalid and an
exception is raised.
But because self.ids is empty, no record is actually checked and therefore
no record is valid.
=> in an onchange it always raises an AccessError and the users is considered
as not having the rights to approve nor refuse a leave as soon as an
onchange has been triggered. Thus associated buttons does not appear.
The original commit fixed the problem by preventing checking the rules
when in an onchange.
In the mean time, the root cause of the problem has been fixed by b5c2004.
Why revert?
-----------
While commit 492764c allowed HR users and Team leaders to approve
after an onchange, it had the unintended effect to
show the "Approve" and "Refuse" buttons to other users.
In summary:
- With commit 492764c: buttons are shown more than necessary
(which is confusing to users who don't actually the rights
to approve)
- Without: Thanks to b5c2004, the original problem no longer exists.
Users with access rights always see buttons. Users without never see
buttons.
closesodoo/odoo#33894
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
Display extra information on error messages:
- Access error based on ACLs: user, fields (if applies)
- Access error based on record rules: user, ids
- Missing error: model, operation, user, ids
closesodoo/odoo#33942
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: jev-odoo <jev@odoo.com>
1) Add a 1st product to compare from the ecommerce /shop page.
2) Open the compare list pop up at the bottom.
3) Add a 2nd product to compare from the /shop page.
4) Remove the 1st product from the compare list before the rpc of the
2nd product is done.
5) Javascript error `self.product_data[res] is undefined`
The function `add_new_products` and `rm_from_comparelist` are
concurrent, they both modify the internal `comparelist_product_ids`
product list. The first one perform an RPC and delay the update once the
request is done, the second does the update immediately.
The solution has been to use a mutex to exclude the two functions.
opw-1974108
closesodoo/odoo#33302
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Try to get the report_pricelist with empty data
(Studio Report editor can)
Before this commit, it crashes because we tried to access dict keys directly
in an empty dict
After this commit, it doesn't crash
OPW 2009862
closesodoo/odoo#34118
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Backport of fa39019ee1.
If crop_image is called without a default format, it would try the default,
'PNG', to save the result and crash at save when processing non-PNG images.
For example, if a jpeg image was in CMYK colors.
Here it will still crash non-gracefully when failing to save, but the default
should almost always work; if it doesn't it means we failed to detect the format
of the stream, so it is unlikely that we could save the image anyway.
opw 2009029
closesodoo/odoo#34088
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Display extra information on error messages:
- Access error based on ACLs: user, fields (if applies)
- Access error based on record rules: user, ids
- Missing error: model, operation, user, ids
closesodoo/odoo#33945
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: jev-odoo <jev@odoo.com>
`_patch_method` and `_revert_method` do not work properly.
This commit fixes a test which patches `create` and `unlink`
of `ir.attachment`.
The methods are not correctly unpatched.
One consequence:
if a module is installed after this test is executed and
the new module overrides `create` and `unlink`, the overritten
methods are never called.
closesodoo/odoo#33952
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
If a user has an ooom in his Preferences, it should be
used as the default value for a leave ooom.
closesodoo/odoo#33890
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
Purpose
=======
Currently, the ooom field is editable in the leave view but an ir.rule
prevents the employee to save as soon as the leave is approved.
Specification
=============
An employee should be able to edit the out of office message
even if the leave is already approved.
Simon Lejeune