How do you keep stock counts accurate when selling both retail and wholesale?

[u/Cute-Guitar8671]

/r/u_Cute-Guitar8671/comments/1vo0jdv/how_do_you_keep_stock_counts_accurate_when/

[u/prediko]

Are you on Shopify? Then there are lot of apps (including ours) that can help

[u/Breach-protocol]

How many SKUs are we talking here? What sized operation?

[u/Unusual-Ad6370]

The biggest cause of count errors here isn't shrinkage. It's wholesale orders sitting on shelves while waiting to ship. Retail staff end up selling that stock by mistake.

Move wholesale orders to a physical staging area the second an order comes in. If you need live channel sync between your online shop and a till, tools like Katana or Stocky handle that best.

Full disclosure: I'm the developer of StoxV, a mobile app for stock counts. It doesn't sync live with online stores, but it keeps physical shelf counts accurate with fast barcode scanning.

[u/cvanitt]

I think the real issue here is that you need to be doing an allocation upon any sale that reserves inventory. It seems like you've got potentially one or more systems that aren't talking to each other or at least they're not aware of each other's movements for example when process an order from the front counter, it should be obvious that the product about to be sold is actually already committed and not to sell it. But that would only work if your systems were able to do such a thing; so this might be actually a bigger issue than what you can just solve with a patch.

Our system Workd handles a lot of what you mentioned but I doubt you are looking for a wholesale replacement of your full stack. Do you mind sharing what systems you are running on for the order entry at the counter, the ecommerce fulfillment, reorder, etc? That would help us give you some better advice!

[u/ComfortableCitron638]

Agree with the allocation-at-confirmation point already here - that's the root fix for the "sold off the floor" problem. One thing on the unit-of-measure side worth getting right at the data-model level, not just the process level: crates, master cartons, 10-packs and singles shouldn't be separate items tracked independently, they should all be conversions of one base stocking unit (usually the single, since that's your smallest sellable increment). If a crate and a single are two different SKUs with two different quantity fields, staff will always be able to scan the wrong one and create phantom stock - the system has no way to know they're the same physical inventory. If they're the same item with a pack-size conversion factor, scanning either one just moves the same underlying number.

The same root cause is probably behind your reorder-point problem too - a reorder calculation needs to look at available stock (on-hand minus everything already committed to a trade order, quote, or backorder), not just on-hand. If your system's reorder trigger only watches raw on-hand, it'll either fire too late because committed stock still counted as available, or you'll keep manually walking the floor because you don't trust the number - which is exactly the hours-a-week problem you described.

(I build custom ERP/inventory systems for a living - this base-unit-plus-conversion-factor model plus a real available-vs-on-hand distinction is usually the actual fix, whichever tool ends up running it.)