Vendor-Managed Inventory for Consumables Playbook
Part of: Use-Case Playbooks — four end-to-end plans for the most common Tagnet deployments
This playbook sets up vendor-managed inventory (VMI) for consumables. You are the supplier. You stock cabinets or bins at your customers' sites with tagged packs, and you are responsible for keeping them filled. Tagnet records each pack arriving in the right cabinet, records consumption when a pack is taken, and reports it to your ERP so you can replenish.
The outcome of VMI for consumables
When this deployment works you have:
- Receipts without data entry. Packs commissioned for a customer site wait in a staging location. The first time a cabinet reader sees them, a workflow moves them into that cabinet and records a receipt.
- Consumption events. A pack taken from the cabinet and read at a scan-out point is closed out with a Consume transaction.
- A feed to replenishment. Each consumption can be posted to your ERP or replenishment system through the durable Integration Outbox, so a customer-network outage never loses an event.
- Stock by cabinet and by customer. Group Inventory By location to see what is in each cabinet, and give each customer access to its own site only.
- A stop for stray stock. A pack read in another customer's cabinet is not moved, and an alert tells you.
What it does not do: Tagnet reports on-hand stock and consumption. Reorder points and replenishment orders stay in your ERP. Tagnet also does not treat a tag that stops being read as consumed. Cabinets are read when something triggers a read (a door contact), and consumption is recorded when a pack is read at a consumption point or when someone records it.
How to model VMI for consumables
Modeling decisions at a glance
| Decision | Recommendation | Why |
|---|---|---|
| Access scopes | A site scope for your own warehouse and one per customer site. Catalog items and types stay shared | Operational data lives in a site; the shared catalog serves every customer. Customers see only their own scope |
| Item types | Consumable (a starter type), with Tracks Quantity on | Quantity is meaningful for consumables |
| Unit of tagging | Tag the unit of issue (a box, bottle, or kit), with the pack size as the item's Default Quantity | A pack is one instance. On-hand units are the sum of pack quantities |
| Locations | Per customer site: a Staging location plus one location per cabinet | Receipt is a move from Staging into a cabinet |
| Instance ID | Auto GUID if people never read it; Instance Dated if lot and date matter on the label | Consumables rarely need readable IDs |
| Tag ID | Sequence Generator (Tag Partitioned), minted when you commission | You encode tags at your own print station |
| Custom fields | Lot number, expiration date, delivery reference, supplier part number | Traceability and recalls |
Scopes and locations
Give every customer site its own site scope. Assign that customer's staff to the scope and to nothing else; see Users, Roles & Access Scopes. Within each customer scope, build the same small tree and use the same location codes everywhere:
Customer Site 1 (Site, Inventory: Not Allowed)
Staging (Storage Area) code STAGING
Cabinet A (Storage Area) code CAB-A
Cabinet B (Storage Area) code CAB-B
Identical codes in every scope let one shared workflow serve all customers: the Location by code in the device's scope target resolves STAGING to each customer's own staging location. Codes are unique per scope, not across the system, so repeating them is allowed. See Location Code.
Quantity, instance IDs, and tag IDs
- Quantity. Turn on Tracks Quantity for the item type, and set each catalog item's Default Quantity to the pack size. An instance is one pack, and a Consume transaction closes the whole pack. A cabinet reader cannot see a pack partly used, so choose a unit of issue small enough that closing it whole is right. See Quantity Tracking.
- Tag ID. Set Tag ID Strategy to Sequence Generator with a Tag Partitioned generator. If your own team tags everything, pin one generator on the item type so every customer shares one sequence. If each customer needs an independent sequence, leave the type on Scope default and give each customer scope its own default generator with a distinct partition code or prefix, so values never collide. Creating generators in a site scope requires the Scoping > Site Catalog policy. See Shared Catalog with Scope Default and Policies.
- How tags are made. Your print or production system commissions packs through the API: it sends the item, the customer
scope, and the staging location, and Tagnet creates the instances, mints the EPCs from that scope's generator, places the packs, and returns finished rows to print. See Integrating Tagnet with Your Systems, Commissioning Reliability and Retry Handling, and the Commissioning Log to check each batch.
Custom fields
| Field | Level | Type | Notes |
|---|---|---|---|
| Lot number | Inventory | String | Indexed and Global Search for recalls |
| Expiration date | Inventory | Date | Indexed |
| Delivery reference | Inventory | String | Your shipment or order reference |
| Supplier part number | Item | String | Maps the item to your ERP |
Give each item type a Code that matches your ERP's classification, so integrations can create items with itemTypeCode. See Item Type Code and Custom Fields.
Reader placement for VMI
| Where | Recipe | Read point | Notes |
|---|---|---|---|
| Each cabinet | Cabinet or shelf, triggered audit | The cabinet's location (a place) | A door contact starts one read per opening and produces one scan event |
| Scan-out point | Workstation or verification point | A consumption location, or the cabinet (a place) | A kiosk or an exit tray where a pack is read as it is taken |
| Your warehouse dock | Dock door with a trigger | The warehouse dock | Optional, to record packs leaving your site |
Start the cabinet from the triggered-audit table in the recipe: Custom operating mode, a radio start condition on the door contact's GPI, session S2 with target A so each pack is read once, Multi Tag Passage with a quiet period longer than the read duration, and no tag cooldown so every audit reports the whole cabinet. Set the tag population to the count when the cabinet is full. Expect the last few tags in a crowded cabinet to take longer than the first hundred.
Give each cabinet its own reader, or its own device group when several readers cover it, and set the read point on that reader or group. Add a device type for cabinets and one for scan-out points (the starter types include Cabinet and Kiosk) so workflows can address them as a class.
Consumption needs a read. If packs can leave a cabinet without passing a reader, those removals are not seen. Plan the scan-out point so that taking a pack means presenting it, or record the consumption another way: the Move action on the pack with the Consume transaction type, or a call from your own system through the REST API.
Workflows and alerts for VMI
Workflow 1: receive packs into the cabinet
| Part | Setting |
|---|---|
| FROM | a device where Device type is Cabinet |
| FOR | every tag in the event |
| Action 1, Move Inventory | Target: Read point's location. Transaction type: Receive |
The first audit after delivery moves each pack from Staging into the cabinet. Later audits leave packs that are already there alone, so there is one receipt per stock-in and never two. Open Transactions and choose By operation to see each audit as one row with the number of packs moved. See Transactions.
Optional: add a Notification action with action tag conditions Movement result is Moved and Expiration date is less than {{today+30d}}, so the supplier's planner hears once when a short-dated pack is received. Date tokens like {{today+30d}} are supported in date conditions; see Operators.
Workflow 2: record consumption and tell your ERP
| Part | Setting |
|---|---|
| FROM | a device where Device type is Kiosk (or the scan-out device group) |
| Action 1, Move Inventory | Target: Remove from inventory. Transaction type: Consume, a close-out type, so the pack becomes Closed |
| Action 2, HTTP Integration (durable) | Your replenishment endpoint, with the tag condition Transaction type code is CONSUME |
Build the endpoint's body template from the movement variables: tag.movement.from.code is the cabinet the pack left, tag.movement.transaction_type.code says what happened, and the pack's lot and expiration are available from its custom fields. See Movement Results in Templates and Integration Endpoints. Use the durable action, not the immediate one: a consumption should not be lost because your ERP was down at that moment. See Update, Then Tell.
Wrong-cabinet protection
When cabinets of different customers sit in different site scopes, a pack from customer A read in customer B's cabinet is a cross-scope move. With the Cross-Scope Transfer policy on its default Reject mode, the pack does not move, the workflow reports it as skipped with the scope pair in the message, and a Cross-scope movement rejected alert (in the Inventory category) is raised, one open alert per pair of scopes. Route that category to your delivery team with Alert Routing. See Scoping / Cross-Scope Transfer. Leave the policy on Reject for VMI: another customer's stock turning up in a cabinet is the thing to investigate, not to accept.
Within one customer site every cabinet is in the same scope, and the cabinet that reads a pack takes it. To keep a cabinet to its own stock, give each cabinet group its own receive workflow with a FOR condition on Item type. Packs of other types are recorded as NoMatchingTags in the workflow's runs, where you can see them, and are not moved.
Alerts
- Reader offline is Critical and reaches administrators by default. A dead cabinet reader means silent stock, so route the Devices category to your field service group with Alert Routing.
- Antenna disconnected (Zebra FX) is a Warning and notifies nobody until a rule covers it. In a cabinet it means part of the shelf is unread.
- Cross-scope movement rejected should go to the team that handles deliveries (see above).
- If you post consumption through the Outbox, route the Integration Outbox alerts to whoever owns the integration. See Alerts.
What to check in the first week of VMI
- Commission a test batch into a customer's Staging location. Check it in the Commissioning Log and confirm the packs show as Active in Staging.
- Close the cabinet door with the packs inside. You should get one scan event per door closure and one operation of receipts. Open the event's Tags tab and compare the tag count with a physical count. If tags are missing, lengthen the radio stop duration or the quiet period, and confirm the tag population.
- Check Closed by on the audit events. Quiet Period is healthy; Max Duration means a read was cut short.
- Test the wrong cabinet. Put a pack from one customer into another customer's cabinet and close the door. Confirm it does not move and the Cross-scope movement rejected alert appears in the Alerts inbox.
- Test consumption. Present a pack at the scan-out point. Confirm a Consume transaction, a Closed pack, and a delivery in the Outbox tab of Integrations that your ERP received.
- Check the lot and expiration fields on a few packs, and that the short-dated notification reaches the planner.
- Test the reader alert. Unplug a cabinet reader and confirm the right team is told once the offline threshold passes (10 minutes by default).
- Reconcile. Open a cabinet's inventory slice and compare quantity with the cabinet's contents. A gap usually means unread tags in a crowded shelf, not a software fault.