Skip to main content

We recently started to implement “drop-off” locations for Kanban-driven Transport Tasks.  Ever since beginning to use these we are seeing problems with too many Transport Tasks being created, but only for parts/circuits that use these drop-off locations for staging.

Transport Tasks are being created as expected, and look correct, however we are seeing multiple Transport Tasks being created instead of just one.  It appears that one TT is being created every 5 minutes, which is the frequency that the Kanbans are being run at, which seems to indicate that something is signaling a new TT to be created even though one has already been created but just not yet fulfilled.

Is this normal?  Is there some way to prevent this from happening, so that it will only create a new TT if one has not already been created?

Presumably we could shift to e.g. 30 mins on the kanban generation, which would allow more time for the parts to be delivered from the warehouse, through the drop-off location and then to the line, but then we add more risk to the line running out before the reorder and subsequent delivery.

Thanks in advance,

Nick

Logically, it would seem like the kanban just needs to account for the inventory that is already in a Transport Task but we can’t find anywhere to get this taken into consideration. 

Anyone have any thoughts or pointers?

Thanks,

Nick

​@NickPorter not strong on Kanban side, but from Transport Task perspective - in the site there is below option, which might apply to your ‘logical’ conclusion made in the later added comment. 

 

The help text goes like this - 

Reserve from Transport Task
If this check box is selected, it indicates that for all demand sources, the automatic reservation in inventory is allowed to reserve from created transport tasks with destination move to inventory. Note that for customer order the selected value can be overridden e.g. it can be allowed for customer order to reserve from transport task no matter selected value. To reserve from created transport tasks is beneficial as you will get less shortages due to movements within the site.
 

​@Vimukthi Mahakumbura thanks for the info.  In our case we already have that enabled, but it does make me wonder if something in the Customer Order is overriding the reservation so it does NOT reserve.  Per the help note it indicates that this can be overridden in this way. 

This gives me something to look into - thanks!

​@NickPorter I couldn’t find anything on a Customer Order where this value could be overridden. I’m thinking the help documentation is misleading, guessing it should refer to this setting on the Site > Sales and Procurement > Sales, not something on a Customer Order.

 

​@matt.watters That makes more sense and I also couldn’t find anything at the CO level (yet), unfortunately I checked and that “Reserve from Transport Task” setting is set to “Yes” already.  Nice idea but unfortunately it doesn’t seem to be the culprit here.

The question I haven’t found an answer for yet is how the auto reservations work when using forwarding locations for Transport Tasks. i.e. When Kanban pulls from a Rack (R) to a Destination(D) it actually creates the first Transport Task from Rack (R) to a Staging area (S), then only when that is completed does it create a second TT to move from Staging (S) to the Destination (D).  Does the fact that the first TT isn’t actually moving inventory to the pulling Destination (D) fundamentally prevent Kanban from knowing that inventory is already on the way, so it keeps requesting until something turns up?

An interesting discovery to add to this topic... this only appears to be happening for Parts that are “consignment” parts, i.e. not company-owned.

For company-owned parts this constant repeating of TT creation does not happen.

In our case this is good news in general, and it is perhaps just unfortunate that our first Parts to be set up to use location forwarding within the same warehouse were consignment parts, but it does mean that this may well be more of a bug that we’ll have to fight/workaround rather than configuration.

If this additional info provides anyone with any additional insights I’d love to hear them!

Thanks,

Nick

Reply


Terms & ConditionsCookie settings