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
In order for the map view to work properly:
- I moved scss property to a file only scoped to website module.
- moved the definiton of "partner_latitude" and "partner_longitude" from
base_geolocalise to base/res.partner
closesodoo/odoo#32487
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Since recent changes in multi company of odoo, the self.env.company is
only the preffered company and not the only selected anymore. So the
currency of a pos config is based on the pos config one and has nothing
to do with the one choosen by the current user.
closesodoo/odoo#33947
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
The variable 'shop' that was set for POS receipt, was actually the stock
location and has been removed. But we forgot to remove its use in
pos_retaurant.
related commit: 8e30349fd1
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>
Purposes:
* Remove bridge module event_sale_product_configurator
* Ease developement of product configurators AND product-based sale_order_line configurators
* Fix the tests for those extensions
* Note that despite the widget being extensible, the tests from the other configurators can easily crash when other configurators are installed because of query counts or limited data available in tests environments.
Technical clarifications:
A main product_configurator widget base in odoo/addons/sale, set on the product_product and product_template on the sale_order_line inline list, providing:
* 5 hooks:
* _onTemplateChange for product_product configurators based on product templates
* _onProductChange for sale_order_line configurators based on product_product
Those two hooks are expected to return a boolean promise to know whether the line has been configured or not, avoiding the opening of multiple wizards.
* _isConfigurableProduct
* _isConfigurableLine
If true, a pencil button is shown next to the product/product_template, calling _onEditProductConfiguration when clicked.
* _onEditProductConfiguration
Called when clicking on edit pencil button.
Examples :
Product configurator : odoo/addons/sale_product_configurator module --> product_configurator (true one, the one in sale doesn't do anything until extended)
Sale Order Line configurator : odoo/addons/event_sale/ --> event_configurator, future rental configurator
Traceback coming from tests are currently logged
line by line. This will implies that runbot will have one
ir_logging entry per line which is not practical. More than
that, the log prefix can make the traceback less readable
because of line returns and difficult to copy paste.
This commit simply remove this feature. After discussion with odo
and chs, we will also remove the docstring from test shortDescription
since most of the time this information is not clear and can be accessed
in source code if needed.
closesodoo/odoo#33911
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
If you are logged into a company that differs from the company of your
employee, you won't be able to read the informations on that employee,
and you will have a crash.
Instead of taking the employee linked to the current user, we use search
in order to first apply the ir.rules hence we ensure that we will be
able to read the needed informations.
closesodoo/odoo#33903
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, call a controller defined as:
```
@http.route('/route', type='http', auth='public')
def controller_func(self, foo):
do_it()
```
and called with url like /route?foo=1&bar=2
will crash with an exception:
`TypeError: controller_func() got an unexpected keyword argument 'bar'`
Now, we remove the extra parameters if the controller doesn't support it.
This case is not uncommon, you can easily arrive in this case with utm or
debug as extra parameter.
closesodoo/odoo#33962
Signed-off-by: Christophe Simonis <chs@odoo.com>
In JS tests, when the ready code takes too much time, a warning is
logged. As a consequence, the runbot updates the github status as a
failure, causing real pain to people who simply wants to merge their
features.
With this commit the warning is changed into an info and the runbot will
be happy.
closesodoo/odoo#33931
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
export.selection.withdefault and export.selection both have a selection field
with Foo and Bar as possible selections.
When doing
self.env["base.update.translations"].create({'lang': 'fr_FR'}).act_update()
the base.update.translations wizard exports the translations of ALL modules,
including the ones of the test_impex module.
The generate po entry is something like:
#. modules: test_impex, test_translation_import
#: selection:export.selection,value:0
#: selection:export.selection.withdefault,value:0
#: selection:test.translation.import,import_type:0
msgid "Bar"
msgstr "Bar in french"
but may also be
#. modules: test_translation_import, test_impex
#: selection:export.selection,value:0
#: selection:export.selection.withdefault,value:0
#: selection:test.translation.import,import_type:0
msgid "Bar"
msgstr "Bar in french"
(not sure where the indeterminism comes from)
which creates 3 translation entries that are sometimes linked to the module
test_impex (ignored when exporting the translations of test_translation_import)
but are sometimes linked to the module test_translation_import instead
In the second case, this makes 3 more translations that is was supposed to
exist.
This commit hides the symptom by making sure there is no longer a clash
when exporting the translations of the module test_translation_import.
A real fix to avoid creating unnecessary translations during an execution of
the base.update.translations wizard must also be made in the future.
It is assumed the unnecessary translations problem was already present before
a7621137cb but polib introduced the indeterminism
making the test fails from time to time.
closesodoo/odoo#33958
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Since forward-port, `/sale/get_combination_info_website` and `_cart_update`
would lead to a concurrency error.
Indeed, the session would not have an order_id at first. Then both rpc would
be sent at the same time:
- `cart_update` would create an order and add it in the session
- `/sale/get_combination_info_website` would end up calling `_compute_cart_qty`
which would call `sale_get_order` and would set the `sale_order_id` to none,
just aftet the `_compute_cart_qty` would actually add an order in the
session, simultaneously.
closesodoo/odoo#33993
Signed-off-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
In order to setup the tour environment, the tour would create and write on
some records.
This part of code could be moved from JS to python to avoid potential
concurrent error and to gain time.
Comparing the length of the recordset is not enough for determining if
there is changes on m2m.
This also fix the merge of f14ae73a98 and
d0bb596f1d
Oversight of previous forward-port.
Before this commit, the test `list: edit view menu item` would sometimes crash
as now the debug manager loads its templates with an `xmlDependencies` where it
was not the case before (included in base.xml), see 73327db065.
Simon Lejeune