I’m a bit confused by the return process and its effect on inventory.
In my mind, returns processed through the POS system should return the item to the inventory pool associated with the POS Profile the return is processed on.
Putting the inventory back into default throws off all our inventory counts.
For example, if an item is purchased in Shop A, it comes out of Inventory Pool A. If it is returned at Shop B, it should go back to Inventory Pool B.
Based on feedback from support… “Unfortunately, at this time any returns done on the POS will return the stock to the default inventory pool, which will be your website stock instead of the inventory pool specified by the POS profile.”
Has anyone else experienced this challenge? Any ideas on a work-around?
Agreed that inventory returns should be tied to the location where they’re being returned. From a development roadmap perspective though, I’m guessing that it’s unlikely that this will be bumped to the top of the list (unless some major clients clamor for it). My assumption is that the overwhelming majority of vin65 wineries don’t have multiple locations (we’re a single-site business without any satellite tasting rooms or branch retail facilities), and as such, if the “big boys” who DO have multiple retail locations aren’t raising hell about this or haven’t been, then it’s probably pretty low on the totem poll.
As far as work-arounds go, you’re probably looking at more of a “how best to manage this” rather than “what trick can we use to make it function the way we want”…so whatever you come up with is likely going to be a choice between the lesser-of-two-evils. In short, it aint gunna be pretty or fun, but you’ve got to come up with something, so at that point, it’s just a matter of finding the least painful process and running with it until further notice. Be sure to plug a feature request into the website though so that it doesn’t get lost in the sauce. It may be a while, but the first step is making sure it gets put in line to get somewhere.
For helpful suggestions, I clearly don’t have the issue so I can’t say “what has worked for us”. But just off the top of my head, if faced with the same dilemma this is where I’d probably start until someone smarter bopped me on the head:
- Train staff accepting returns to type the location the return is being received at in the order notes section on the final POS screen. If you have several locations, maybe develop a shorthand code for each to keep things consistent and easy to identify
- Run a report > sales detail every week for “refunded” orders and include “pickup location” and “order notes” in the output.
- Export the report and sort by order notes column, then delete all rows where the “return location” is the same as the pickup location (in other words, get rid of results where the shorthand return location code you came up with for the order notes is the same as the place where it was original sold, thereby leaving you with only rows where products sold at location ‘a’ were returned to location ‘b’)
- tally totals for each SKU that was returned to each location
- Devote 20 minutes each week (if that) to manually doing bulk inventory adjustments, moving total SKU returns at each site from website inventory to said site.
Ugly, not pretty, but unless you’re receiving more than a few dozen returns like this a month, it’s probably the idea of having to do this that is more painful than the process itself. I’ve found that to be true with most of these sorts of annoying little glitches. Once a habit, it’s really nothing more than a simple task - irksome as the idea of having the task in the first place may be. And you can obviously reduce your workload once you get a sense for how often it’s truly necessary to do the darned thing (once a month instead of weekly?)
1 Like
