This has always been wrong on v8, but because of the very obscure
odoo/odoo#5797, this seemed to work every time we had single-step
reception.
Please note that this block of XML is noupdate, so for existing
installations you need to change the parent of the reservation location
to something outside your warehouses manually.
Incidentally, this makes the branch green independently of odoo/odoo#5797.
In order to get visibility on https://www.odoo.com/apps the OCA board has
decided to add the OCA as author of all the addons maintained as part of the
association.
[UPG] Upgraded to version 8, fixed references to new 8.0 views and moved fields that were in product.product to product.template
[fix] remove duplicate view and correct view name
[UPG][FIX] added outgoing field XML, that was in the base stock field in 7.0.
[UPG] stock available immediately, corrected the calculation method of
immediately_usable_qty to take in accountthe sign change in outgoing_qty
(from negative to positive) in version 8.
[FLAKE8]
[FIX] renaming of a class, comment removing, useless code.
[UPD] move out from unported to 8 for update
[fix] remove duplicate view and correct view name
[UPG][FIX] added outgoing field XML, that was in the base stock field in 7.0.
[FIX] renaming of a class, comment removing, useless code.
[fix] remove duplicate view and correct view name
[UPG][FIX] added outgoing field XML, that was in the base stock field in 7.0.
[UPD] move out from unported to 8 for update
[fix] remove duplicate view and correct view name
[UPG][FIX] added outgoing field XML, that was in the base stock field in 7.0.
[FIX] renaming of a class, comment removing, useless code.
[UPD] move out from unported to 8 for update
[fix] remove duplicate view and correct view name
[UPG][FIX] added outgoing field XML, that was in the base stock field in 7.0.
[FIX] renaming of a class, comment removing, useless code.
[UPD] move out from unported to 8 for update
[fix] remove duplicate view and correct view name
[UPG][FIX] added outgoing field XML, that was in the base stock field in 7.0.
[FIX] renaming of a class, comment removing, useless code.
[fix] remove duplicate view and correct view name
[UPG][FIX] added outgoing field XML, that was in the base stock field in 7.0.
[UPD] move out from unported to 8 for update
[fix] remove duplicate view and correct view name
[UPG][FIX] added outgoing field XML, that was in the base stock field in 7.0.
[FIX] renaming of a class, comment removing, useless code.
For weird reasons, force-assigning a move does not associate quants.
action_assign'ing the picking does, and is the same procedure that you
can do via the interface.
The update of the source location of a move is not a good idea, as
shown in the test case that is modified by this commit and explained
below.
In general, a stock.move will be linked to a stock.picking whose
location_id and location_dest_id are defined by the picking type.
As such, the stock.move will inherit these locations and it is the
assignation of the stock.move that will create a stock.move.line
where the location (in case of outgoing picking) or the destination
location (in case of incoming picking through putaway) will be a
sub location of the respective location defined on the move.
So, if we want to empty a stock.location and move all its content
to another stock.location, we do not want to update the location
of the reserved moves, since it can break the reservation mechanism
of Odoo, as the assignation of a move will always look into the
children locations of the move, and it is not supposed to be updated
by any internal transfer, to what could be a children location.
Then, if internal transfers were planned from the location that is
being emptied, but are supposed to be executed after the location
has been emptied, there is probably an issue with the planning and
the sequence in which both transfers are being executed.
Since the internal transfer being updated in the test case was also
moving from a shelf location to its parent (where technically the goods
are already, since they are in a child location), we should prefer not
breaking the standard workflow of Odoo instead of supporting a corner
case with an internal transfer.
I guess we can revisit my assumption if we have a good reason to update
the stock location, but the one that was tested doesn't seem to be
good enough to justify breaking a standard mechanism.
