Simplify shipment moves tree view

Feature Ideas
1

Currently on every shipment move we have the following columns:

  • Origin
  • Product
  • From location (sometimes hidden by domain inversion)
  • To Location (sometimes hidden by domain inversion)
  • Quantity
  • Uom
  • Planned Date
  • Effective Date
  • State
  • Cancel Button
  • Draft Button
  • Do Button

But some of them are useless:

  • The buttons are always readonly because the shipment workflow manages them.
  • The planned_date and effective date are updated with the shimpent equivalent fields.

I’m wondering if it won’t make sense to have a specialized view that only includes the following fields:

  • Origin
  • Product
  • From location
  • To Location
  • Quantity
  • Uom
  • State

This will allow the user to just focus on the relevant information.

Toughts?

2

I like your proposal for the buttons, but the dates can still be informative.

3

Those dates are already included on the header of the shipment. So for me this information is redundant with the shipment dates.

Once all the move are grouped on a unique shipment it’s planned_date and effective should be always the same (the one for the shipment).

4

I think we can also drop the origin.
And I would order: from, product, quantity, uom, to and state.
As in case the user must put at a location, he first needs to know what. And if he must pick from, he must first known where.

1 Like
5

I’m not sure for the rest of fields but from and to IMHO should be kept together.

6

Please could you elaborate why?

7

For sure. It’s a shipment moves view so I consider that from and to are the essence of a shipment movement.

8

For me the essence of a movment is: from, product, quantity and to.

And I think this order is right because when moving you first have to go to the source location (from), pick the quantity of the product and move it to the destionation (to).

9

If I had to plan the shipments I would do it based in from and to (destiny) but I’m a developer not a logistic man so perhaps I be wrong.

10

We are not talking about shipment planning but about the moves inside a shipment.

For shipment planning you use the planned_date (and the warehouse in case of multiple warehouses).

Once you’ve planned the shipment and you are working on it, you have to pick the lists of products to move. The from and to locations may be fixed or variable. For example, on supplier shipments the incoming moves locations are fixed (from the supplier to your warehouse incoming location), but then the inventory moves (from incoming location to storage location) have a to location variable as you may define on which location of the warehouse you want to store the product. Then in the customer shipment is the other way arround, you should only define the from location from where you pick the products and the rest of locations in the workflow are fixed.

When the locations are fixed the client does not show them (thanks to domain inversion), so this makes the list view more simpler for the user.

Taking this in account do you have any reason to keep locations together?

11

In bold all the occurrences referred to from and to you’ve used to explain why we don’t have to keep them together as they are not the essence of a shipment move:

Obviously the product is essential but when we talk about shipment moves the focus, IMHO, seems to be the from and to because (excluding incoming moves) the user has to choose one of them to place the goods.

12

I do not see any reason in your messages that explain why they have to be together.

They are important OK, but that’s not a reason to keep them together.

Could you please explain your reasons (if any)?

13

I’m trying to do that. Believe me.

First of all… Are we talking about column position (from left to right), aren’t we?

I hope it…

Well. The first occurrence of a movement definition defines it as:

The act or an instance of moving; a change in place or position.

So to reach that goal you have to move something from a place to another place.

A movement will not be a movement without from or to and like both fields are necessary to do a movement and defines it I consider they should be keep together. That’s it.

I don’t find the words to explain it better. Sorry.

14

Thanks to @pokoli guidance I’ve understood better the proposal so I regret of my words and see good the initial @ced comment:

15

Filled Issue 9459: Simplify shipment moves tree view - Tryton issue tracker which implments this proposal.
Comments are welcome :wink:

1 Like
16

This topic was automatically closed after 2 days. New replies are no longer allowed.