Hi,

I'm trying to alter the way our putaway process works, in an attempt to reduce double-handling of product (replens). Currently, our putaway methods are set like this:

1. Direct to Active
2. Direct to Radial Around Active
3. Directed

We have some shelf reserve locations set up close to our active locations, which we refer to as "primary reserve" - it's these locations that get picked up using the Direct to Radial Around Active method. What I'm trying to do is change these reserve locations to dynamic active locations. That way, if there's no room in the permanement active location for a sku, it can be directed to one of these dynamic locations and be picked from there, rather than being directed to a reserve location and therefore requiring a replen. The problem I'm having is that I can't get the RF Putaway transaction to assign a dynamic location, allocate the case to go there, and create a task for it. I've set up a variety of configuration that I was hoping would accomplish this, but so far no luck:

1. Created a Pick Location Assignment Type (SysCode B-326) and assigned it to the active location for the sku I'm testing with.
2. Created a Pick Location Assignment Zone (SysCode B-330) and assigned it to several of the dynamic locations I'm testing with.
3. Added an assignment Type/Zone/Priority record (Pick Zone Assignments).
4. Changed byte 12 of the RF Putaway Case (lib/libWhsePAClient) transaction to "checked". This parameter is called "check active - dynamically assign location?", which seems to be exactly what I want.

It doesn't seem to be checking for a dynamic location though - it goes through the putaway methods, realizes there's no room in active, and then just continues with the radial around active method. What I'd expect is that it'd find a dynamic location in the zone I've specified, add a pick location detail record for that location with the sku I'm testing with, and allocate the case with INT=1 to go to that location. I'd hope that it also creates a task using that allocation, although I'd have to check our task creation rules to see if any of them would apply to the allocation, or if it would fall through a crack. I must be missing something - is this even possible to do with base functionality? Or does it only apply when we're running a wave?

Thanks.