The Count Is Right, So Why Can't You Ship?
Your WMS shows 1,000 units on hand, yet the pick list comes back empty, or worse, stock that should never leave the building ends up on a truck. In most cases the quantity is accurate but the status isn't being managed.
Say those 1,000 units include 120 awaiting inbound inspection, 30 in a lot held for a customer claim, and 15 damaged. Only 835 can actually ship. If the client or sales team promises orders against 1,000, you're short by 165. If the system allocates without regard to status, uninspected goods reach customers. The system has to know that "on hand" and "shippable" are two different numbers.
Designing an Inventory Status Model
Principles for status codes
Keep the list to five to seven statuses. Every extra status adds another way for floor staff to pick the wrong one, so capture the detailed cause in a separate reason code rather than a new status.
Should status follow location?
For stock that physically moves, such as damaged goods and returns, tying status to a quarantine location is the safer choice. Holds are different: they're often placed on stock that stays in the rack, so hold status should be an attribute independent of location. Inferring status from location alone falls apart quickly in a high-movement facility.
Hold Management Rules
Hold scope and release authority
You need to be able to place holds by lot, SKU, location, or inbound receipt. A recall maps naturally to a lot, a suspected equipment defect to a location, and a supplier quality issue to a receipt. Separate the authority to place a hold from the authority to release it. For example, floor supervisors can place holds, but only QA can release them.
Reasons and deadlines
Every hold should record a reason code, the user who placed it, and an expected release date. Overdue holds work best with tiered escalation, for example notifying the owner at 7 days, the team lead at 14, and the client at 30. Long-term holds take up space and distort turnover metrics.
Connecting to Allocation and Picking
The allocation engine should consider only Available stock. The trickier case is a hold placed on stock that's already allocated. Define the response by stage:
Every status change should log the before and after status, reason, user, and timestamp. When a claim or audit comes up, you need to be able to answer who released this lot, when, and why.
Syncing Status with ERP and Client Systems
Decide what level of detail to expose. A common approach is to show clients totals for three buckets (Available, Hold, Damaged) and keep the detailed reasons internal. Send quantities by status to the ERP as well, so sales can promise orders against available stock.
Billing disputes usually come from stock that's damaged in the WMS but still counted as good stock in the ERP. We recommend a two-layer approach: push status-change events immediately, then reconcile quantities by status once a day.
Rollout Sequence and How POLYGLOTSOFT Can Help
When you add a status model to an existing WMS, a phased approach is safest:
POLYGLOTSOFT supports the full scope, from designing the inventory status model to hold management screens, allocation logic improvements, and ERP and client-system interfaces. We can work alongside your current system and add capabilities step by step rather than replacing it. If you have stock on hand that you can't ship, get in touch with us.