[13.0] Add vertical lift support - alpha version #797
Merged
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
guewen
force-pushed
the
13.0-add-stock_vertical_lift
branch
2 times, most recently
from
43c2332 to
f5a28ca
Compare
guewen
force-pushed
the
13.0-add-stock_vertical_lift
branch
2 times, most recently
from
70e3b95 to
d2670cb
Compare
guewen
force-pushed
the
13.0-add-stock_vertical_lift
branch
2 times, most recently
from
032e39f to
7a423d0
Compare
|
@guewen can you rebase on 13.0? pre-commit settings have been updated |
guewen
force-pushed
the
13.0-add-stock_vertical_lift
branch
from
7a423d0 to
2efe980
Compare
jgrandguillaume
approved these changes
Mar 23, 2020
62 tasks
guewen
force-pushed
the
13.0-add-stock_vertical_lift
branch
4 times, most recently
from
360662c to
f1c4afc
Compare
guewen
force-pushed
the
13.0-add-stock_vertical_lift
branch
2 times, most recently
from
c4064d4 to
8effbe6
Compare
|
Build should be fixed when OCA/product-attribute#654 and #944 are merged |
* 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.
* 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.
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.
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 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.
Compatibility layer between server_environment and stock_vertical_lift
* 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.
guewen
force-pushed
the
13.0-add-stock_vertical_lift
branch
from
c50641f to
c228f27
Compare
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.
|
/ocabot merge nobump |
|
This PR looks fantastic, let's merge it! |
|
Congratulations, your PR was merged at 1e6b9ec. Thanks a lot for contributing to OCA. ❤️ |
CarlosRoca13
pushed a commit
to Tecnativa/stock-logistics-warehouse
that referenced
this pull request
Aug 16, 2021
CarlosRoca13
pushed a commit
to Tecnativa/stock-logistics-warehouse
that referenced
this pull request
Aug 16, 2021
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.
Port #633
Requires #792, OCA/web#1437 and OCA/web#1462.
This is a draft pull request, absolutely not production-ready, and does not meet yet the standards in term of documentation. At the moment, this is for demo purpose, the Pick, Put and Inventory workflows more or less works for a demo. It implements a poc for #641
The goal is to support Vertical Lift such as Kardex or similar systems.
It adds a stock location structure for the Vertical Lift "shelves", with different levels:
Vertical Lift → Shuttles → Trays → Cells. The Cells are automatically generated from Tray Types (example: 4 cols and 2 rows) selected on the trays.
A visual representation of a tray displays the selected cell and color the cells that contain stock.
The initial proposal assumes that each Shuttle will be driven by a screen displaying the operations to do (pick or put, inventory will need some work as well). Here's the (incomplete) dedicated UI, with the information about the product to pick + visualization of the tray and cell to pick.