Fernanda,
I've taken a look at your model and ultimately found a simple solution. The reason the items weren't going to the racks after the initial stocking was because that's how the logic was set up. There was code that told the rack whether or not it could pull that item, and once that code was executed the item was never again reevaluated. Also, the "for" loops going through each item in each rack every time an object entered was slowing down the model.
An easier way to accomplish this logic is with Process Flow. I've set it up so that the objects don't get sent to a rack until there is an "opening" for an item with that SKU. I've attached the updated model but I'll try to explain this clearly:
When an object arrives at the queue, a token is created in the Process Flow and given a label called "item". There are also labels set on the token denoting its SKU and the Department it should be sent to. Then they can enter a "Zone". The Zone is partitioned for each SKU with a constraint of 10 for each one. That way no more than 10 tokens of each SKU can be in the Zone at a time. If a token is allowed to enter the zone, it then moves the flowitem to its corresponding rack.
The way for objects to be sent to a rack when there is space available also involves the zone, as well as a list. After an object is moved to a rack, its "sku" label is pushed and partitioned on a global list. Each combiner then pull the specific sku that it pulled from the rack (using the partition ID), allowing the token to continue through the Process Flow. The token then leaves the zone, letting a token with its specific SKU to then enter the zone and be sent to the correct rack.
Even for those with little to no knowledge of Process Flow, this logic shouldn't be too complicated to follow. There is essentially no logic for the item flow from the queue to the racks contained in the 3D model-it's all in the Process Flow and global list.
I hope this is helpful. Let me know if you have any questions.
