01Inventory codes and system mappings
Extract code, label, description, active and effective dates, creator, owner, language, facility or business-unit scope and every system mapping. Include deprecated, hidden, default, blank and interface-only values. Identify reports, APIs, scanners, rules, roles and workflows that read or write each code. Preserve historical definitions because an old transaction may use a code whose meaning changed. Detect duplicate labels, one code mapped to several meanings, several codes with the same meaning, truncation and case differences. Record the authoritative master and change path. An apparently unused status may still exist in archived inventory, integration queues or financial reports. Do not delete it before searching the complete population and dependencies.
02Define state and separate dimensions
Write one plain-language definition with entry evidence and exit condition. Decide whether the status represents quality, condition, regulatory or customs hold, availability, ownership, lifecycle or another state. Keep location, owner, reservation, lot, serial, custody and physical condition separate when possible. For example, stock can be physically damaged, customer-owned, in a quarantine location and unavailable; one damaged code may not encode every dimension. Align terminology with actual operations instead of vague labels such as special, problem or blocked. GS1 CBV dispositions are event context and include values such as active, damaged, expired, disposed, unavailable and unknown; they are not a ready-made warehouse status table. Map only when meaning and use agree. Document where unknown is permitted and who resolves it.
03Specify permitted business actions
For each code, state whether the system may receive, put away, move, replenish, reserve, promise, allocate, pick, pack, ship, transfer, count, adjust, consume, return, repair, relabel, value or dispose. Define inclusion in physical on-hand, unrestricted on-hand, available-to-promise, projected supply, safety stock, replenishment and finance views. Record whether a task is prohibited, held for approval or allowed with warning. Do not assume non-saleable means zero value or zero ownership. Use qualified finance and regulatory owners for valuation and compliance effects. Check product- or jurisdiction-specific requirements without claiming universal rules. Make system behavior observable: a status should not silently block one channel while remaining available in another. Test permissions separately from the code definition.
04Build transition and authorization matrix
List allowed source-to-destination transitions such as received to inspection, inspection to available, available to quarantine, quarantine to released or rejected, customer return to inspection and damaged to disposal. Name the triggering event, evidence, role, separation of duties, timestamp, reason, approval, physical move and any lot or serial scope. Define reversal and correction instead of allowing users to edit history. Prevent impossible transitions such as disposed to available without a new authorized receipt or rework event. NIST SP 800-53 provides control concepts for least privilege, separation of duties, audit records and controlled changes; apply them proportionately. Emergency override needs limited duration, reason and review. Preserve who changed the status and which exact units were affected.
05Validate interfaces, availability and accounting
Send test inventory through WMS, ERP, order management, quality, transport and reporting interfaces. Confirm code, meaning, quantity sign, unit, item, location, lot, owner and effective time remain intact. Reject or quarantine unknown inbound codes rather than defaulting to available. Reconcile physical on-hand, available, reserved and ledger totals by status. UNECE INVRPT can represent inventory quantity with location, date, status, owner and movement context; use those dimensions when testing reports. Check that a release updates all dependent availability views once and a hold removes only the intended quantity. Compare financial mapping and costing through qualified owners. Detect interface latency that briefly exposes held inventory for allocation.
06Migrate, retire and preserve history
For duplicate or ambiguous statuses, approve the target model and map current inventory by item, location, lot, owner and quantity. Freeze new use of retiring codes, convert active records through controlled events and retain old values in history. Do not rewrite transaction history or mass-convert stock without physical and operational evidence. Test open orders, reservations, replenishment, quality cases, transfers, returns, counts, valuation and reporting before and after. Maintain an effective-date mapping for historical analytics. Communicate the definition and user action, not only the new short code. Roll back or isolate exceptions when the target status cannot represent the real condition. Retire scanner menus, default rules and integration translations at the same release point.
07Monitor integrity and review the model
Report inventory using inactive, blank or unmapped codes; unsupported transitions; manual overrides; status without required evidence; long-held unknown or quarantine; available inventory in restricted locations; negative available quantity and mismatches across systems. Sample each active code and critical transition to physical stock and source records. Review definitions after product, process, regulatory, system or ownership changes. Track user questions and workaround locations as evidence of unclear design. Consolidate only when meanings and controls truly match. A small code list is not automatically better if users then hide distinctions in notes. Keep a governance owner, change log, test suite and periodic recertification for the master.