# Pack Application **URL:** https://discuss.tryton.org/t/pack-application/273 **Category:** Feature **Tags:** stock **Created:** [December 29, 2016, 4:55pm UTC](https://discuss.tryton.org/t/pack-application/273 "2016-12-29T16:55:53Z") **Posts on this page:** 6 **Page:** 1
### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced) #### Post date: [December 29, 2016, 4:55pm UTC](https://discuss.tryton.org/t/pack-application/273/1 "2016-12-29T16:55:54Z")
## Rational The Tryton UI is not optimal when working in a warehouse. When doing the task of packing the shipments, the UI has too much functionalities while the task does not need them. And also the current UI is not really designed for this task. ## Proposal We could write a simple web application (like [chronos](https://hg.tryton.org/chronos/)) dedicated to the packing task. The web application should be a single page aka SPA. ## Scenario - The user configures the application by defining his _Employee_ and the _Warehouse_ where he works. - The user enters the shipment _Number_ (or pick one if many matches). The available shipments are those in _assigned_ state or in _waiting_ if no assignation and that are not assigned to any other employee. - The user starts by creating a first pack where it is asked the _Type_. - The user selects from a list a shipped product. The quantity is asked. The list of product is updated according to the quantity packed. - The user can now: - The user should always be able to undo the last operation. - The application propose to the user to finish the packing when there is no remaining products. - The user can force to finish the packing, in this case the remaining will be removed from the shipment. - The user can leave the shipment without finish it. The current state will be stored and the user could come back via a list of assigned shipments. ## Implementation We must create some API’s: - `GET` `/stock/employees` To retrieve the list of employees of the user - `GET` `/stock/warehouses` To retrieve the list of warehouses - `POST` `/stock_package/shipments/out/search` To search shipments: - by number and warehouse - by warehouse and assigned to the employee - `GET` `/stock_package/shipment/out/` To retrieve the data of a shipment. It should contain everything needed for the application. - `PUT` `/stock_package/shipment/out/` To send the modification done on the shipment: - It should allow to assign it to the employee. - It should allow to update/split moves and create/update packages. - It should allow to pack the shipment. The architecture should be flexible to allow easy customization like adding new field to display (modification of the template), hooks on major events etc. The design should be very minimal but functional. It should be responsive and support mouse, touch screen and keyboard usage. > **[Pack Application (#6180) · Issues · Tryton / Tryton · GitLab](https://foss.heptapod.net/tryton/tryton/-/issues/6180)** > > Following: https://discuss.tryton.org/t/pack-application/273 ## Future - Add feature to weight each product (change the quantity if the UoM is also weight). - Add picking application. ---
### Author: ![nicoe](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/nicoe/32/2880_2.png) [@nicoe](https://discuss.tryton.org/u/nicoe) #### Post date: [December 30, 2016, 9:43am UTC](https://discuss.tryton.org/t/pack-application/273/2 "2016-12-30T09:43:56Z")
> [@ced](#): > > - The user enters the shipment Number (or pick one if many matches). The available shipments are those in assigned state or in waiting if no assignation and that are not assigned to any other employee. > - The user starts by creating a first pack where it is asked the Type. What about `Internal` shipments? I guess the _Type_ is either `Out` or `Return`. In that case, I guess that quite often, the combination _Number_ / _State_ / _Type_ will be unique and so the second step will be useless. And one of the goal of the application is to go fast. Couldn’t those two steps be merged by displaying a visual clue about the type of shipment like 📤 or 📥 (those are maybe not good enough but it’s just an idea). > [@ced](#): > > - The user can leave the shipment without finish it. The current state will be stored and the user could come back via a list of assigned shipments. I think other users should be able to work on shipments on hold as well. > [@ced](#): > > - GET `/stock_package/employees` > To retrieve the list of employees of the user Sooner or later people will have the same implementation of this kind of generic requirement scattered in all their applications. As I am sure you already thought about it I wonder what is your position about that. > [@ced](#): > > - GET `/stock_package/shipment/` > To retrieve the data of a shipment. It should contain everything needed for the application. I think the the _Type_ is required there. > [@ced](#): > > - PUT `/stock\_package/shipment/int:shipment > To send the modification done on the shipment Same remark about the _Type_. ---
### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced) #### Post date: [December 30, 2016, 10:06am UTC](https://discuss.tryton.org/t/pack-application/273/3 "2016-12-30T10:06:59Z")
> [@nicoe](#): > > What about Internal shipments? There is no packing for internal shipment. > [@nicoe](#): > > I guess the Type is either Out or Return. Here the type is the type of the package. But I did not thing about Supplier Return Shipment in this design (the other type of shipment with package). It is normally very rare and so probably does not need to have a specialized application. > [@nicoe](#): > > I think other users should be able to work on shipments on hold as well. We can add an option to leave and unassign. > [@nicoe](#): > > Sooner or later people will have the same implementation of this kind of generic requirement scattered in all their applications. As I am sure you already thought about it I wonder what is your position about that. The `user_application` can support only one application name. I do not see how it could be designed to support more. Also for now, this method is only 3 lines without any special logic. I guess if something similar but more complex will appear to be reused many times, we will create a common method to reuse but still plugged to different routes. > [@nicoe](#): > > I think the the Type is required there. As for me, it was only customer shipment, I did not add it but if we want to keep the option to extend for other shipments, it is better to use a unambiguous name. ---
### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced) #### Post date: [January 4, 2017, 12:43pm UTC](https://discuss.tryton.org/t/pack-application/273/4 "2017-01-04T12:43:38Z")
I think it is better to share the same user application name space between all the pick-pack-ship applications. This way we could for example redirect from the pick application to the pack application if the user is working on an outgoing shipment. ---
### Author: ![andrew.szydlo](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/andrew.szydlo/32/1108_2.png) [@andrew.szydlo](https://discuss.tryton.org/u/andrew.szydlo) #### Post date: [October 26, 2020, 7:10pm UTC](https://discuss.tryton.org/t/pack-application/273/5 "2020-10-26T19:10:26Z")
What is the current status of the mentioned picking application? ---
### Author: ![ced](https://discuss-cdn.tryton.org/user_avatar/discuss.tryton.org/ced/32/1237_2.png) [@ced](https://discuss.tryton.org/u/ced) #### Post date: [October 26, 2020, 9:03pm UTC](https://discuss.tryton.org/t/pack-application/273/6 "2020-10-26T21:03:47Z")
It is in the status of the issue.