Skip to main content

I’m running into a couple of different issues when using either the Loop or Subsequent process functionality when attempting to pick multiple parts.

The following configuration flow is being used:

Start Warehouse Task

Start Picking

Report Picking of Part

Business Scenario:

A picker within the warehouse needs the ability to pick multiple parts then scan the appropriate Shipment Location to specify where they are physically placing the items.  

The picker will not know which Shipment Location should be used until they have picked material and are physically bringing it to the shipment staging area.  

Issue with Loop:

If I attempt to create a loop with Report Picking of Parts, the loop is not considering unique lines. 

The next data set is always a duplicate set of data. 

I assume this is due to the Unique Line ID being Auto Picked so it continues to grab the first data set as nothing has been committed.

Issue with subsequent process:

If I attempt to use the subsequent process, the configuration prompts me for a Shipment Location in between picking parts - but this is incorrect. 

It would be inefficient for the user to pick one part at a time and return to the Shipment Location for each item.  

--

Is there anyway a loop/subsequent process can be created successfully to manage this process where a user can pick multiple parts then scan the Shipment Location?  

 

Issue with Loop:

If I attempt to create a loop with Report Picking of Parts, the loop is not considering unique lines. 

The next data set is always a duplicate set of data. 

I assume this is due to the Unique Line ID being Auto Picked so it continues to grab the first data set as nothing has been committed.

 

Is there anyway a loop/subsequent process can be created successfully to manage this process where a user can pick multiple parts then scan the Shipment Location?  

 

You have probably created a not so good configuration where you don’t start the loop with Unique Line ID so something else is controlling it before its picked. There is some underlaying functionality that will skip already picked lines in the LOV functionality for Unique Line ID in an internal loop scenario, but I would guess your configuration will make that thing not work properly. It was intended for the system to auto-pick the lines for you but that would work best if you start the internal loop with Unique Line ID.

I know many customers that have internal loop like that and have ship location or ship handling unit outside and after the loop so they only need to enter it one time.

Hi @astfarazt,

 

maybe try starting the loop at PART_NO and keep relevant Data Items in it as well like picking location, quantity to be picked etc. and SHIP_LOCATION_NO right after the loop? This way you the warehouse worker can pick all that is needed and right after exiting the loop they are asked to provide the Shipment Location for all.

 

Placing UNIQUE_LINE_ID somewhere to the tail end of the configuration makes it not force the warehouse worker’s hand, so to speak. 

 

Br,

Mikko

Thanks for the feedback, @Dario Zani and @Mikko K. 

Unfortunately, I have tried both of those scenarios before posting as I’m familiar that the configurations works best with minimal or careful changes.    

I started to review the Data Collection Sessions further and I noticed that the Start Picking configuration is Auto Picking the Location No.  I found that interesting so I tried to remove the Start Picking Configuration altogether and proceed directly from Start Warehouse Task to Report Picking of Parts.

This resolved the issue but now the question is, why would the previous configuration have any impact on a current configuration?

For transparency sake, below are the only changes I made to the Report Picking configuration:

  1. Unique Line ID - Start Loop
  2. Release Reservation - Fixed Value set to “No” and move one place above Shipment Location No
  3. Release Reservation - End Loop  

I know we have different sorting for LOV in Report Picking of Parts depending on if the previous session was Start_Picking, since then it uses a bit different sorting that will match how the aggregated tab is handled.

So I would guess you have turn off that sorting and now you get the sorting you would have if you had run Report Picking of Parts as standalone configuration without Start Picking.

 

 

Thanks for the additional information, Dario.  

Reply


Terms & ConditionsCookie settings