Follow us on Facebook Follow us on Twitter Get the latest job postings quicker!
Follow us on Facebook and Twitter!
Sponsors

Like this Page? Share it!
HomeHomeManhattan Assoc...Manhattan Assoc...GeneralGeneralWM to LM Messaging for Load Pallet activitiesWM to LM Messaging for Load Pallet activities
Previous
 
Next
New Post
10/2/2017 7:18 AM
 

Hi,

 

We're having an issue with the messaging between WM and LM for load pallet activities. When a user loads a pallet, there should be a total of 3 detail lines in the message (exactly 3 - never more, never less). These 3 details should be:

  1. User's previous location
  2. Consolidation location where the pallet is picked up
  3. Dock door location where the pallet is delivered

 

The issue we're having is that WM is generating details for each carton on the pallet, rather than just the pallet itself, so the message looks like this:

  1. User's previous location
  2. Consolidation location - pick up Carton 1
  3. Dock door location - deliver Carton 1
  4. Consolidation location - pick up Carton 2
  5. Dock door location - deliver Carton 2
  6. Etc, for each carton on the pallet

 

So if there are 100 cartons on the pallet, the travel time is being calculated 100 times, which is 99 times too many. In one of our DCs, we had created a database trigger to handle this. It looks at the details being written to workinfo_q_dtl_010 and fudges the locations so that although the details are there for each carton, the locations are such that the travel time is only calculated once. Unfortunately, this same trigger has troubles in another of our DCs - it causes the load pallet activities to take upwards of 4 minutes to process per transaction, which is obviously unacceptable. 

I have trouble believing that such a large bug could exist in the system, so I'm thinking that there must be some config somewhere that tells the system "write these details at the pallet level, not at the carton level". Does anyone know where I might find that config, if it exists?

 

Thanks.

 

 
New Post
10/2/2017 2:28 PM
 

Hi John,

So are you using the RF Load Trailer functionality and you have multiple cartons consolidated onto a pallet and each carton is generating the 010 message?

According the documentation I can find, that's how it's supposed to work:

"As a carton or pallet is scanned for loading, if the carton or pallet is originally located, a 010 Event Detail should be created for each container loaded - to capture the original carton/pallet location.  If a pallet is loaded, there will be a 010 detail for each carton on the pallet".

Obviously not ideal for companies that use carton consolidation.

Taking your trigger approach, you could park these 010 details in a particular status that doesn't get picked up by the LM process and have a scheduled job to do the manipulation of the data before re-setting the status. Might add a minute delay but at least your data to LM would calculate correctly...Sorry I can't offer more for this.

Cheers

Dan

 
New Post
10/3/2017 5:18 AM
 

Hi Dan,

 

Yes, we're getting a 010 message for each carton on the pallet. In fact, we're getting one for each sku in each carton, although due to the ordering of the details, that part doesn't affect the travel time calculation. It seems odd that Manhattan would force it to work that way. Even the wording of the documentation you quoted is suspiscious - "to capture the carton/pallet location". To me, this implies that it should capture the location of the scanned entity. If we scan a carton, it'll capture the carton's location; if we scan a pallet, then it should be capturing only the location of the pallet, not the location of every carton on the pallet. In either of those situations, there should be only 3 detail records. Since Manhattan is designed to be very configurable, I have to believe there's some obscure parameter somewhere that changes this behaviour to match the business needs, but I haven't found one yet.

 

My approach is exactly what you suggest - great minds think alike! My trigger analyzes each 010 record as it comes in (only for activities that have a custom flag turned in in syscode 746) and updates the location info so that only the distinct locations come through. All other records are useless - and in fact, just for fun, that's how I've flagged them. I hijacked an unused misc text field and had the trigger drop the word "USELESS" into it. It then resends the detail to LM, which should allow the travel time to be accurately calculated in relatively real time. Just for cleanliness, I also have a timed job that runs (I think) every hour that deletes the useless records and resends the message again. Not exactly the most efficient way in terms of CPU usage, but I haven't found a better way.

 

Thanks, as always for the response.

 
Previous
 
Next
HomeHomeManhattan Assoc...Manhattan Assoc...GeneralGeneralWM to LM Messaging for Load Pallet activitiesWM to LM Messaging for Load Pallet activities


Copyright 2010-2011 by WMS Support Forum   |  Privacy Statement  |  Terms Of Use