From the 1.4.0 PO-receive rehearsal: locations are free-text strings on inventory records — arbitrary, no vocabulary, no page of their own, no relationship to anything. The receive form now offers a datalist of previously-used locations (1.4.0), but that's autocomplete, not a model.
Open design questions before giving locations structure:
- Should locations be first-class (list page, rename/merge, occupancy view)?
- Relationship to workcenters: the user's explicit caution — "we should be careful of any relations we do draw" — a workcenter is where work happens; a location is where stock sits. They sometimes coincide (kitting cart at a workcenter) but are not the same concept; do not conflate them casually.
- Hierarchy (BLDG/ROOM/SHELF/BIN) vs flat labels? Small-team reality favors flat labels with conventions over enforced hierarchy.
- Transfer/move semantics already exist per-record (ADJUST QTY / stock transfer); a location model would want a move-all view.
Deliberately deferred from 1.4.0.
🤖 Generated with Claude Code
From the 1.4.0 PO-receive rehearsal: locations are free-text strings on inventory records — arbitrary, no vocabulary, no page of their own, no relationship to anything. The receive form now offers a datalist of previously-used locations (1.4.0), but that's autocomplete, not a model.
Open design questions before giving locations structure:
Deliberately deferred from 1.4.0.
🤖 Generated with Claude Code