Christoph GALLOP

It should be possible to maintain a delivery calendar for each delivery site/warehouse and receiving site/warehouse.

In practice, warehouses are supplied according to a defined delivery calendar. Currently, the transport days are taken into account, but not the fact that no delivery is possible on certain days.

The planned transfer orders should take this date + the resulting transport days into account.When it comes to transport days, it should be taken into account that these depend on working days. For example, trucks are not allowed to drive on Saturday and Sunday.

Example:

Warehouse A supplies warehouse B via transfer orders. However, warehouse A does not deliver every day, but only on Tuesday (ship date) and Thursday (ship date). It takes 3 working days for the delivery to arrive at the site/warehouse..

Delivery from Warehouse A on Tuesday with delivery to location B on Friday.

Delivery from Warehouse A on Thursday with delivery to location B on Tuesday.

It would be ideal if the transport days were given a default mode of delivery for each shipping and receiving warehouse and this calendar (for each mode of delivery) was taken into account accordingly. In other words, the calculations would always be based on the possible shipping dates. This could actually be controlled in the same way as in the sales orders using "Closed for Pickup" options.

It is possible to maintain a delivery calendar for each vendor. However, this calendar does not take into account that the transport days refer to working days.The calculation of the receipt date is always based on transport days (Purchase Transport Days) and the "Open Days" in the Shipping Calendar.

Example:

A supplier needs 3 days to deliver. However, no deliveries take place on Saturdays and Sundays. So if the shipping date is Thursday the receipt date is Tuesday.

The delivery calendar should work differently and the working days should be maintained via "Open Days" and the delivery days should be assigned via the "Closed for Pickup" functionality.

It is possible to freely define a cluster in the inbound process. The whole cluster can then also be stored together via put-away work.

In practice, several problems arise:

•  If several items (which are booked on different works) on the cluster find the same target location:

You can only see which items are affected by looking at the position number. This is very complicated in practice because, for example: due to the supplier's sufficient labeling (GS1 2D barcode), we do not carry out any extra labeling in the inbound process.

• only the entire target location can be overwritten for all multiple items

•  It is generally not possible to put away partial quantities when the location is full (split put in purchase receive and put away is here not possible)

A significant process improvement would be if:

• During the putaway work, the cluster's works are automatically sorted according to various criteria. e.g. according to target location per License Plate/Work
• If the cluster is accepted or executed then, the put away is now processed work by work and so item by item.
•  You can use the usual functions such as: Split Quantity and override location per work

It would be ideal if you could control this via the Mobile Device Menu Item:

• Cluster Put Away Work by Work (Yes/No)

If Yes then Split Quantity and Override Location should be possible. You accept the cluster, and then work through work for work in the correct order and all the options for “normal” put away work (split, override location) are available. Also,a prior labeling (position number) would not be necessary.