ensure that the procurement group is only created in the procurment process.
Sometimes the method _get_rule is just needed to obtain the information of the rule,
and it isn't followed by the run of the procurement.
* stock_vertical_lift: make pkg compute more solid
Somehow sometimes you can get a move line without product
while computing product packaging in inventory.
Make it more defensive and skip packaging rendering if no product is
there.
As the template is not used by JS we can pass full objects to it.
This way we can use any recordset information directly in the template
without having to override the method.
In the following graph:
PICK/001 ━► PACK/001 ┓
┃
PICK/002 ┓ ┣━► OUT/001
┣━► PACK/002 ┛
INT/001 ━► PICK/003 ┛
If we have the consolidate flag on "PACK", we want to raise the priority
only when we start to move goods in PACK/001 or PACK/002 (not INT/001),
because this is in the packing zone that we are limited in space.
Also, when for instance a move of PICK/002 or PICK/003 is set to done,
*any* move (all products) that go to PACK/002 are concerned by the
priority raise: we want to finish the transfer.
* Rename methods that fetch a tray to prevent confusion
* Add methods to release a tray
* The Kardex method to fetch a tray has to send "0" in the carrier and
carrierNext field
* The pick and inventory screens release the tray only when there is no next
line, because the release is implicit when we fetch the next line,
the put screen releases everytime because the operator may take time
to start the next line and we don't know if they are going to scan a
next line or not.
* Exiting the screen or switching screen between put/pick/put-away has
to release the tray as well.
The rules created in demo data of stock_reserve_rule make the tests of
stock_vertical_lift (and possibly other modules) fail because the
transfers can't be made available.
Deactivate the rule in stock_reserve_rule and activate it only in its
tests. Users can still activate the rule manually to test.
When the putaway selects a tray and a cell according to the storage
type, we still want the user to be able to override the selection by
scanning another tray type.
The use cases we want to cover are:
1. Putaway for a package/good without storage type
2. Putaway for a package with a storage type configured to be
stored in a tray (associated with a tray type)
3. Putaway for a package with a storage type NOT configured on a tray
type
The case 1. is implement in "stock_vertical_lift", the 2. was already
implement in this module, this commit implements the case 3.
A typical flow is:
* We configure a generic Kardex Box storage type, not associated with
any tray type, that is set on the package at reception (the reception
person doesn't know the tray type at this point). this Kardex Box
storage type is set on the Vertical Lift view (above the shuttles).
* On the putaway transfer, as per the configuration above, the putaway
changes the destination location to the Vertical Lift view.
* When we scan the package in the shuttle's screen, as we have a storage
type which is not configured on any locations in the shuttle
(reminder, if we had, it would select the tray automatically), the
user is asked to scan a tray type of the correct size.
