Reference data connects a physical container to the intended material, quantity, receiving location and supplying queues. Prepare it carefully: a similar description is not an interchangeable identity.
Create the reference structure
In Items, use the approved code, description, unit, family and barcode aliases. In Locations, define the actual receiving points. In Stores queues, prepare the teams that may supply work. The owner manages who works each queue and its printing setup.
In Loops and containers, create the loop with its item, location, whole refill quantity, allowed queues and default queue. The default must belong to the allowed set. Attach the appropriate containers, preserving their real codes.
A change to quantity or queues creates another loop revision. The page can show that the latest revision waits for release while requests still use the released revision. Do not promise the floor a new quantity until the reviewed release includes it.
Preview a CSV
Open CSV imports, choose What the file holds, Delimiter and the UTF-8 file. Use the displayed columns and file limits for that type. Supported types include items, barcode aliases, receiving locations, loops and containers.
Read the preview summary and each row's Create, Update, Unchanged or Rejected result. Inspect before-and-after changes and field errors. Codes are retained as text, including leading zeroes and significant spaces. Do not allow spreadsheet formatting to silently rewrite them.
Adopt the exact complete file
Nothing changes until adoption. The entire file is adopted or none of it; a rejected or stale preview needs correction and a new preview. Inspect the whole file when rows are hidden from the first screen.
Imports create drafts and inactive containers. They do not physically activate a container or release changed rules. A row omitted from a later import never retires the existing record. Retirement is a separate reviewer decision.
After adoption, inspect the reference pages. The owner enables the intended supplying queues on Stores queues before the current candidate is proved; the release's default queue must be enabled before activation. Then build the candidate and obtain reviewer release. The owner subsequently enables the released loop and records container opening conditions in Physical activation where needed. Existing admitted refills retain their original obligations, so tell stores whether a change applies only to new requests or whether open work needs separate supervisor attention.
Correct references without reusing an identity
Authors can add and remove family keys in Items. A family still used by an active item's latest revision cannot be removed; revise those items deliberately first. Item description and family changes use Save as revision, creating new item and affected loop revisions for release. An item's code and unit are not ordinary editable description fields.
Barcode aliases are managed on the item. Add the actual barcode through the scan control and use Retire alias for one that must no longer identify it. An active alias cannot collide with another item or item code. This is distinct from publishing a new description or routing release: do not promise that all reference changes wait for a later release before taking effect.
Before physical activation, an author can change an inactive container's proposed condition or loop and choose Save. A loop change advances its card generation. Remove old cards from use and issue the current card through tickets and cards; printing it still does not activate the container.
Retire in dependency order
Retirement is Reviewer work. On Loops and containers, use the reasoned Retire [loop] and its containers decision when the loop stops supplying new work. It blocks new cycles immediately. A container with an open cycle drains that obligation before retiring; retirement does not erase receipts or authorise an unbalanced short closure. An individual container also has its own reasoned Retire control.
Retire the dependent loops before Retire item or Retire location. A stores queue cannot be retired while an unretired loop or active release still uses it. Arrange the replacement route and current release, then retry the retirement after checking the dependency. Codes remain reserved after retirement and must not be recycled for a different physical identity.
Give operators and stores the old and new item, loop and container references, the active release and the open obligations still being drained. A reference retirement is separate from cycle cancellation or short closure.