[18.0][MIG] stock_vertical_lift: Migration to 18.0 #2255
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Add vertical_lift_shuttle_id field on stock.location, help to find the shuttle for a location * Add StockLocation.fetch_vertical_lift_tray(), that needs to be implemented in addons to send commands to the hardward to fetch a tray, and if existing show a cell (laser pointer, ...) * Add helpers on stock.move.line fetch_vertical_lift_tray_source() and fetch_vertical_lift_tray_dest() that fetch the tray directly from a move line's source or destination location
Namely, the pick/put/inventory operations are now split in different models. Pick and Put share a model and customize their behavior, which is pretty similar. The inventory operation will have a different view and different workflow. This changes will ease a lot the customization of the different workflows and views.
When we refresh the page on the browser when we are using the "screen" view, odoo loses the information that we want the view to be headless, fullscreen, etc. so it's displayed pretty badly. This view is a work-around: its priority is lower, so it will be picked up by default on loading, and a button allows to re-open the screen view with the proper options.
There is no such action as 'ir.actions.do_nothing', it kinda works, until you look into the js console and stares at the errors. There is a nice OCA module that serves this purpose (more or less, because it reloads the window, this is not an issue).
Example of usage in an odoo shell, when a screen is open: >>> self.env['vertical.lift.shuttle'].browse(1)._operation_for_mode().operation_descr = 'foo' >>> self.env['vertical.lift.shuttle'].browse(1)._send_notification_refresh() >>> env.cr.commit() Provided the longpolling is correctly configured with a proxy, the screen should immediately refresh with 'foo' as operation description.
not a list
* 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
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 documentation of the state machine is in VerticalLiftOperationBase._transitions.
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.
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.
* 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.
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.
* 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.
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.
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.
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.
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.
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.
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.
Fix unit tests fixup! [13] Fix stock_vertical_lift skip screen Rename variable to current_move_line fixup! Rename variable to current_move_line
Currently translated at 7.1% (9 of 126 strings) Translation: stock-logistics-warehouse-14.0/stock-logistics-warehouse-14.0-stock_vertical_lift Translate-URL: https://translation.odoo-community.org/projects/stock-logistics-warehouse-14-0/stock-logistics-warehouse-14-0-stock_vertical_lift/it/
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.
|
/ocabot migration stock_vertical_lift |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Put from receipt
Pick from Delivery
Adjust Inventory