Pack Application

[ced (Cédric Krier)]

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) 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:

  • Add another product to the same pack.
  • Add a new pack inside the current pack.
  • Close the current pack.

• 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/<int:shipment>
  To retrieve the data of a shipment. It should contain everything needed for the application.
• PUT /stock_package/shipment/out/<int:shipment>
  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.

https://bugs.tryton.org/issue6180

Future

• Add feature to weight each product (change the quantity if the UoM is also weight).
• Add picking application.

[nicoe (Nicolas Évrard)]

@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/<int: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.

[ced (Cédric Krier)]

@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.

[ced (Cédric Krier)]

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.

[andrew.szydlo]

What is the current status of the mentioned picking application?

[ced (Cédric Krier)]

It is in the status of the issue.