Hi,

Does anybody know how to force the system to look up the proper transaction to use in the task action? 

The way our putaway is configured, we have three types:

• Putaway to Active (INT=1)
• Putaway to Primary Reserve (INT=11)
• Putaway to Secondary Reserve (INT=11)

​Each of these gets a different task type. Active and primary reserve both put away at the case level, and secondary reserve puts away a whole pallet, which will contain multiple cases and multiple different skus. The RF user only uses a single RF transaction, called "RF Putaway". We have a task action set up so that when a user scans a pallet with RF Putaway, and it's allocated to go to active locations, the system will automagically take the user to the proper transaction, which we've called "RF Putaway Active". That part works perfectly. Unfortunately, this same configuration doesn't work for our other two types of putaway. We have a task action configured for primary reserve, which we've called "RF Putaway Case", and another task action for secondary reserve, which we've called "RF Putaway Pallet". However, our RF Putaway transaction refuses to call these other two transactions, and the putaway gets completed solely with the RF Putaway transaction.

Previously, this wasn't an issue. It's become an issue now because we're working on configuring LM2007, and we need the proper transactions to be called so that the proper activities get sent through to LM.

Does anyone have any idea why it's ignoring the task actions that we have configured? 

Thanks.

Hi Dan,

That's exactly how we have it configured.

• Task creation rules are set to create particular task types.
• Transactions are configured to complete these tasks, with the TRAN_MASTER.TASK_NAME field set up appropriately.
• Task actions are set up for particular task types and INT's.

The two task actions above don't seem to work, but this one works fine:

And we have others that work fine as well. All of our putaways start with our RF Putaway transaction. I can't figure out why it has no trouble calling the configured transaction for INT=1, but can't seem to manage it for INT=11. When selecting a task with Ctrl-S, it works fine with both INT's... it only has problems when RF Putaway is set to assign the task to the current user.

We have a bunch of messages that are set to non-display. I looked through those, but didn't see anything that looked like it was related to this situation. I have tried turning the logs on high and searching through both the application and DB logs, but the only thing that told me was that in certain scenarios, it wasn't even checking the task_action table (i.e. the DB log had no queries something like SELECT * FROM TASK_ACTION...). In other scenarios, it does have some reference to task_action. 

I did notice that byte 2-2 in the task group (syscode 337) was null for this particular task group. In other task groups, we have it set as "ignore owner". I wonder if maybe not having it set is somehow causing it to skip task action? Then again, the description of that parameter is "RF Select Task: Include Owner Level", which implies that it only applies when a user does Ctrl-S on the RF gun, and that's the scenario where the task action always seems to work.

What's byte 5-19 in your version? In ours, using the lib/libWhsePAClient program, it's this:

None of those are a link to a putaway transaction. Our putaways are configured a bit weirdly, though. When we receive a case, the putaway logic gets called in order to determine if the case is going to an active location or to a reserve location close to the active (using the Direct to Radial Around Active method). In both of these instances, an allocation record will get created with either INT=1 for active or INT=11 for reserve. However, this doesn't actually create a task. When a pallet is scanned with RF Putaway, the putaway logic gets called again, and then it creates the task and immediately assigns it to the user. Somehow, all these transactions are linked together. The receiving transaction has a link to the sorting transaction as well as the putaway transaction. The sorting transaction also has a link to the putaway transaction. I haven't been able to determine exactly what gets called and in which order, though. The RF Putaway transaction itself doesn't have a link to any other transaction in the transaction parameters - the only link is in the task action table, and of course that's not a direct link between the transaction and another transaction, it's a link between the task that RF Putaway is entering and another transaction.