Why you shouldn’t use reversals for Vender/Customer returns
I’ve seen many posts in SCN and other sources of people trying to manage Vendor/Customer returns using the reversal of inbound/outbound documents and subsequent reposting (with a different quantity). I don’t know if this is because they were taught that way, or because they don’t know what they are missing, but it’s clearly not a best practice. Instead of just saying it isn’t, I’ll take the time to explain “Why”.
In a warehouse there are 4 main logistics (macro) processes that deal with the entry/exit of goods:
- Vendor delivery (Inbound)
- Customer delivery (Outbound)
- Vendor return (Outbound)
- Customer return (Inbound)
Inbound and outbound processes are very different in the “physical world”. One has repacking, quality checks, and putaway, the other has picking, packing, and loading. This difference becomes much more relevant when we take into consideration that WM processes must closely relate to the physical process since getting any work done should rely on a worker getting a TO.
Using a specific example, let’s imagine your usual inbound process is: unload the truck, repack the goods, make a quality check, and putaway the goods.
Now imagine that a truck with a customer return arrives at the distribution center, what is the process? Unload the truck, repack, make a quality check and putaway the goods right?
So why should anyone try to replace this with the reversal of the outbound delivery using LT0G? Let’s see what happens:
– No support for unload/repack process;
– No quality check (serious issue for customer returns);
– Manual bin input (you’re not blindly returning the stock to the original location right?), instead of using a specific (and automatic) putaway strategy;
– And finally …. Wrong information! Instead of a 100 CRT delivery and 10 CRT return, management will see a 90 CRT delivery. That’s just wrong. Why should the company be losing the information regarding customer returns? The same is valid for vendor returns.
Reversals should only be used to correct input errors, never to implement an entire process like a customer/vendor return.