If the same user opens multiple shuttles operations on different screens,
notifications for a specific shuttle will be displayed on all of them,
regardless of the shuttle operation that triggered the notification.
This commit allows filtering notifications per screen, so that only
screens displaying shuttle operations related to the current notifications
will display them.
Notifications that are not shuttle-related are not filtered out.
A vertical lift retrieves a tray and places it in front of the
user, and depending on the quantity the user takes from it,
it adapts the pending quantity in the tray. However, because of
errors, it could be that the system thinks the tray is empty
while it is not. With this module, when the system thinks the
tray is empty, while in the step for the release of the tray
the operator is asked explicitly to check if the tray is
actually empty. Depending on his/her answer (yes/no) an inventory
adjustment is created stating the situation.
To activate this optional feature, a new configuration setting
has been added to Inventory > Configuration > Settings, named
'Check Empty Tray'. It is deactivated by default.
Developing decisions:
- The screens shown to the operator are actually wizards, but
since in the original module (`stock_vertical_lift`) they
were considered (on the source tree) as views, this has been
continued here.
- It has been decided, to not change the current workflow of
the operators, to embed the new check inside the step for
the 'release'. So, a new screen is shown to ask for the
visual inspection of whether the tray is empty. In
order to test this easily, the method `button_release` of
the module `stock_vertical_lift` has been slightly modified
so that it always returns. This way we can check easily
in the unit-tests for the outcome of the intermediate
screen (i.e. wizard) ─ similarly to how it is done when
validating a picking that can result in a backorder.
The button to skip an operation is only implemented for the pick
operation (not for the put or for the inventory ones) but it was
shown in the screens for all the operations, yielding to a stack
trace when it was pressed from the wrong operationg. The button
has been moved now to the screen for the pick operation, only.
In the screen for the vertical lift shuttles, accessible through
Inventory > Operations > Vertical Lift Shuttles, a new button has been
added to allow to skip an operation. This button can also be triggered
by scanning the barcode O-BTN.skip.svg that is inside the folder
'images'.
When a skip is done, the next stock.move.line to pick is chosen and
shown to the operator. A skipped move line is added to the end of the
list of pending move lines to be picked, so they will be shown again
in the future as soon as the other move lines have been successfully
processed.
This option was added because, sometimes, the operator can not process
a move line for whatever reason. Right now, the only way of proceeding
is to wait until he/she can effectively process it, which involves a
delay in the operations. With this new skip operation, the operator
can continue processing the rest of move lines.
If there is two move lines for the same product in the vertical lift
(stored in2 differents trays for instance), the pick scenario was
failing when the user was processing the first line.
To circumvent this, instead of validating directly the move, we put the line
in its own stock move, then we put the stock move in its own transfer and
validate this one.
Methods used to do that have been copied from the `shopfloor` module,
they probably deserves their own module as they are quite generic.
If we have several goods to put in the same tray, it is inefficient to
release (close) the tray between each line if we reopen the same tray.
Release the tray only when the last line is reached.
The check was means as an optimization: no need to fetch at tray already
open. But "fetch_tray" will not only open the tray, it may also move the
laser on the exact position. So we should do it for every inventory line.
* 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.
* 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.
When the shuttle screen propose a tray based on a tray type and we
are in the 'save' step, where we are supposed to physically putaway
the good and save, we should still be able to change the tray type
to fetch another tray.
Compatibility module between stock_vertical_lift and stock_storage_type
(in OCA/wms).
In the vertical lift's Putaway screen, when a good is scanned for a putaway, the
user has to scan the tray type of the corresponding size, so an empty place in a
matching tray is found. When we use storage types, we should know what tray is
compatible with the storage type.
Changes with this module:
* The storage types of trays cannot be selected in the locations form, they have
to be set in the Tray types.
* In the lift put-away screen, when a package has a storage type, the user isn't
asked to scan a tray type, instead, the putaway of the Package Storage Type is
applied.
Instead of going through the onchange machinery.
The intended usage of onchange methods is to update something on the
screen, without side-effects in the database, then let the user save
the form with the proposed changes.
Weirdly, the barcode scanner event triggers an onchange on the field
`_barcode_scanned`.
It doesn't work well with our use case, as the whole form is read-only
and we only care about having the barcode events doing side-effects on
the backend and displaying back the changes.
This particular onchange will then be executed as a normal method, with
side-effects. However, contrarily to other actions on the form, the
frontend does not reload the view after an onchange, as it relies on the
data returned back in the values. As we cannot know which values may
have been changed in the different implementations (location
destination, state, ...), the onchange returns a read with every field.
* The change of destination location was not updated on the screen when
the barcode was scanned (it was when the "manual barcode wizard" is
used though)
* We should be able to pick partially available move lines
* prevent to scan a location when no move line is selected or the move
line has already been set to done
