By using this website, you agree to our Terms of Use (click here)
Hi
In the Warehouse we have setup a location that is selected as the default return location. For this location it is also set that Sales is not allowed and it is not included in the Availability calculation.
We have a item where we set the reorder quantity to 10(on the Item class it is set that is uses the Availability calculation for the replenishment).
We have bought in, say 11 pieces of the item and sold them all. So we have 0 quantity in the Warehouse. Then the customer returns all 11 items and they are placed in the Return location. At this point, if we do Prepare replenishment, the item will not be suggested for replenishment(11 exceeding the reorder point of 10). However, we want it to be suggested, as it should not consider the items we have in the return location(we cannot sell those at the moment and possibly never).
Any ideas on this? Some setting or similar I'm missing? Please let me know if you would need some more information or print screens etc.
We just realized we were having the same problem with our RMA area not calculating into replenishment. At first we thought it was a great setup since we changed the RMA location to not allow sales orders and to not count as available in terms of the item allocation count. (Prior to setting this up we had problems with returned items pulling for orders before we had a chance to check them out and determine if they were resale-able)
We set up a “virtual warehouse” called WIP (Work In Progress) and have a couple locations like RMA, DAMAGED, MISSING. We just receive the returned items to that warehouse (WIP) and location (RMA). Since they are now considered to be out of our MAIN warehouse it does not include those items in the replenishment calculations.
(We also use this virtual warehouse so we can receive in “damaged goods” from a vendor so our purchase receipt matches the vendor’s invoice. We can then deal with the vendor to get a return authorization and send the items back out of this WIP warehouse. These items won’t pull on an order and it triggers replenishment to order replacements.)
We can then take our time to process the returns and new POs will still be generated as if we don’t have those items. If we determine we can resell the item we just transfer it back to its default location in the MAIN warehouse.
We have only been using this method for about a week, but so far it seems to work well. It seems a little wonky, but it doesn’t really add any additional work, and we haven’t found any other problems with this setup (yet).
I've run into this before, and unfortunately I have not found a way to exclude a location from the replenishment calculation. In fact, even if you un-check all of the boxes in the location settings, including active, any on-hand quantity in that location still factors into replenishment. It seems like there should be a way to exclude a location, but I am not aware of any. If someone knows of something that I have missed, it would be great to know.
One workaround is to create a separate warehouse for returns, which will keep quantities separate. You could receive the returned items into the 'returns' warehouse, and set those locations to not available for sale and not part of the availability calculation. From a process standpoint, if those items were then reviewed and deemed OK to sell, you could then transfer them to the main warehouse. Replenishment would then only reflect what is on hand in the main warehouse.
Thanks for the reply! Yeah, same experience and I'm a bit uncertain if this is actually a bug or not. We've also considered the option to have a fictive warehouse for returns, but feels a bit overkill. Of course, if that is the only option, then we'll go for that.
I'm no help on this one, never encountered it before. But it doesn't surprise me, the Replenishment settings are pretty basic.
You might look into a customization for this. It might not be that bad to tweak the functionality to the way you want it. Let me know if you want a recommendation on a developer.
Just for information, this is reported as a support ticket and at the moment it looks like this is handled as a bug.
Awesome! You are over the first major hurdle, getting engineering to agree to it being a bug. Now it just needs to get fixed...
Looks like maybe I spoke too soon. This solution above still has some kinks we need to work out...
Thanks for the feedback Troy. I hope that you're able to work through the kinks.
Online Members
