WMS Inventory Transfers

[agos176985]

WMS

We’re running Macola ES v9.5.0.331 and WMS v9.5.9

Question:
When WMS is used to do inventory transfers it generates an ODB file for each item transferred and then barcode module polling imports the ODB file, executing the transfer ES. The only data I see in the ES IMBINTRX and ININVTRX tables both reference an ES generated "order number". As I see it, there does not appear to be any way to identify which inventory transfers in ES were generated by which activities/users in WMS. Is this correct? If this is correct, then there is no direct way to verify that a WMS inventory transfer actual reaches the ES tables. Again, is that correct? If using barcode module exception reporting is the only way to verify transfers, it leaves a great deal to be desired.

I see that the ODB record layout allows for an order number field in inventory transactions, but is not used for transfers. If it was used by WMS in the case of transfers generated by EPN picking, then we would be able to see the customer order number in both IMBINTRX and ININVTRX and link those transactions directly to WMS. User initiated inventory transfers could be linked to WMS by placing the WMS user id in that field.


Problem:
Previously we were told that the only way to undo a completed EPN pick (transfer to a staging bin) was to transfer the items on the order, one by one, from the staging bin back to the original pick bin. We see many opportunities to make errors doing this regardless of whether we are using the ES inventory module to transfer or WMS. Using either, there is no margin for error. Imagine doing this for an order of 50-75 line items. Missing a transfer or duplicating a transfer affects the staging bin and in the case of duplication, it can cause problems with other orders containing that item when packing the order and triggering the confirm ship operation. That is, when attempting to confirm ship the order, it’s possible that the staging bin will have 0 quantity of the item. I assume the confirm ship initiated by WMS through the barcode module will fail, leading to still more problems. I see a lot of holes here. With all the actual bin transfers that we will initiate with WMS and all the bin transfers initiated by using EPN, I don’t see any way of confirming that we have correctly reversed an EPN and completed the transfers from the staging bin back to the pick bin. Of course, this is further complicated by the issues raised in the question above. Do you have any suggestions as to how to manage the EPN reversals? Is there any knowledge of how other customers have approached this?

[edward.read]

WMS can be configured to prompt for an order number when doing transfers, but it does not populate it when it comes from the EPN module. There is a table wmstrxlog that has detailed information about the transfers that occurred, and from where they came and who did them. The information in that table supplements the standard Macola ES auditing and really should provide you with the information you are looking for.

As for Bar Code exceptions, they should be extremely rare. If you are getting alot of exceptions on transfers you should contact support, because it should not be happening. In fact you could use something like Event Manager to notify you when they occur.

While it certainly happens that people want to delete a stage pick / stage pack that they have already picked and / or packed, I would want to exam what the workflow issue is that is causing the issue if it was happening alot.

Nevertheless, if you have completed the pick process already, then when you delete the pick/pack, the product is assumed to have been physically transferred to the staging area. WMS can't assume that you will physically move them back to the original bins, in fact you may not do so. If WMS were to put them back in the original bins automatically your inventory would no longer reflect the real situation in the warehouse, which is that the items are not in their original locations, unless you physically returned them there.

While WMS can recommend from the staging bin, we don't advise it, since it can get confusing. For that reasone we suggest using the *<bin> which precludes WMS from recommending from that location.

Since the products are expected to be physically at the staging bin, and need to be returned, it is expected that the products can be physically scanned and returned to another location other then the staging location. This is preferable to doing an office "return." They do not have to return to the original location, in fact if desired you can create a RESTOCK bin, and transfer them to there. If the RESTOCK bin is created with a high priority it will recommend product from that bin before it looks for new product to be picked. You can also use the Zone processing to force a pick to only consider that Zone.

You definitely want to use the WMS transfer function, not the internal Macola transfer for the returns, and in fact for all transfers. The WMS transfer honors recommendations and what has been picked/packed already and will not let you transfer more out of the staging bin then is available... i.e. it won't let you transfer quantity that is already reserved for the packing for other pick/packs, etc. Which should prevent you from transferring extra out of the the staging bin and causing problems with billing. There is also the Pre-Update Macola reports that look for bin problems before you pencil out and update Macola, so that they can be fixed before needing to go into bar code exception handling.