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.

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.