At a Glance
Persona: Store Keeper · Module: product · Workflow stages: Read-only lookup at floor level — barcode scan (tb_product.barcode); view handling notes, shelf life, perishable flags; reference per-location stock policy (tb_product_location.min_qty / max_qty / par_qty / re_order_qty); post barcode-mismatch and handling-note comments · Key permissions: read-only on catalogue; comment (tb_product_comment); no lifecycle transitions
What this persona does: Scans and reads product master data during receiving, picking, transfers, and counts; reports operational issues back through comments.
The Store Keeper persona is a read-only consumer of the product catalogue, operating at the floor / location level during receiving, picking, transfers, and counts. Within the product module their authority is lookup only: they scan barcodes (tb_product.barcode) for fast identification on mobile devices, view product detail (handling instructions from tb_product.info JSON, shelf life, storage requirements, perishable flags), reference per-location stock policy (tb_product_location.min_qty / max_qty / par_qty / re_order_qty) for context during counts and replenishment, and post comments (tb_product_comment) for barcode mismatches and operational issues. They do not create products, do not edit any master-data field, do not edit per-location stock policy (Inventory Controller role per inventory/02-business-rules INV_AUTH_004), do not edit unit conversions, and do not participate in product lifecycle transitions. Their transactional activity (receiving GRN, stock-in / stock-out, running physical / spot counts) lives in the good-receive-note, inventory, physical-count, and spot-check persona files — this page covers only the product-catalogue lookup surface they touch in support of that work.
Entry points: Three primary paths into the Store Keeper's interaction with the product module, all read-only and most via mobile.
tb_product.barcode and surfaces the resolved product to the transactional flow.tb_product_location for a product at a specific location, to compare on-hand against par / min / max during a count or replenishment check.Primary flow (barcode scan during receiving, 5 steps — the dominant pattern):
PRD_VAL_005); the app posts the scanned value to the lookup endpoint. The endpoint queries tb_product.barcode = <scanned> filtered to active products (product_status_type = active, is_active = true, deleted_at IS NULL). If exactly one match is found, the resolved product is returned with id, code, name, base unit, classification path, and handling notes.tb_product.info JSON — storage temperature, shelf life, fragile / hazardous flags, allergens.tb_product_location.min_qty / max_qty / par_qty for context (is this receipt above max? below min?).tb_product.standard_cost) for high-value items as a sanity-check against the GRN line's unit cost.tb_product_tb_vendor) — does the receiving vendor match the configured vendor for this product?product_id, base unit, and the picked order-unit (from tb_unit_conversion). The Store Keeper enters qty (in order-unit) and the line is saved. The product master is unchanged.The count / spot-check flow is a parallel pattern:
tb_product_location.par_qty for the count location — does the counted qty match par? Below par? Above par?INV_VAL_006 extension)?The stock-in / stock-out flow (manual adjustments per inventory/03-user-flow-store-keeper):
active + is_active = true + non-deleted).INV_VAL_006); the perishable flag comes from tb_product.info JSON (or by category convention).The comment / feedback flow:
tb_product.barcode (or the SKU mapping) and replies. The Store Keeper rescans to confirm.PRD_VAL_005 would block adding the barcode if it conflicted; here the issue is the barcode is simply not in the catalogue), the Store Keeper either uses the manual search to find the product by code/name and post a comment requesting the Product Administrator add the barcode mapping, or the Product Administrator creates a new product entirely if it's a new SKU.tb_product.info are wrong (e.g. the bag says "Refrigerate at 4°C" but the master says "Ambient"), the Store Keeper posts a comment so the Product Administrator can update the JSON. Critical safety-related corrections (allergen omission, hazard flag missing) are escalated out-of-band in addition to the comment.min_qty / max_qty / par_qty feels wrong for a location (constant stock-outs at the min, or constant overstock above max), the Store Keeper posts feedback on tb_product_location (via the product detail's location tab). The handoff is to Inventory Controller (not Product Administrator), per INV_AUTH_004.PRD_VAL_005 barcode uniqueness is application-enforced, so true duplicates should not exist in live state. If the lookup returns multiple matches (typically because one product is soft-deleted but the application's barcode index includes it), the app shows a picker; the Store Keeper selects the active one. This case typically indicates an underlying data quality issue — the Store Keeper posts a comment so the Product Administrator can clean up.PRD_XMOD_001. The picker rejects.standard_cost, the Store Keeper flags it on the GRN's comment thread so the Receiver / Inventory Manager can investigate before commit. This is a good-receive-note concern but the data is read from the product master.min_qty / max_qty / par_qty are advisory — they trigger alerts and replenishment suggestions but don't block transactions. A receipt that pushes on-hand above max_qty will succeed; the system flags it for review but doesn't reject. The Store Keeper uses these values as context for count investigations (a count that's far from par may indicate an issue worth investigating) rather than as transactional gates.tb_product_comment) are user-driven, free-text discussion. Activity log is system-driven (status transitions, field changes). The Store Keeper posts in comments; system events post in activity log. Both are queryable but serve different purposes.The Store Keeper's interaction with the product master ends at one of these boundaries:
product_id. The product master is unchanged; the Store Keeper's transactional work proceeds in the source module per its persona file.tb_product.info JSON per their flow.active state) and the cross-persona handoff table (Section 4 — Store Keeper → Product Administrator on barcode mismatch / handling-note correction, Store Keeper → Inventory Controller on per-location policy feedback).tb_product shape (especially barcode, info JSON, inventory_unit_id referenced in step 4 of the primary flow), tb_product_location for per-location policy (step 4 detail), enum_product_status_type (the active filter on the barcode-lookup endpoint).PRD_VAL_005 (barcode uniqueness — application-enforced), calculation rule PRD_CALC_001 (classification path), authorization rules PRD_AUTH_007 (Store Keeper read with barcode lookup) and PRD_AUTH_008 (Store Keeper read of per-location policy — but not edit); cross-module rule PRD_XMOD_001 (inactive product rejected on new line) referenced in the decision branch.PRD_CALC_003) gate the GRN line's variance approval.tb_product_location is read here; the edit authority belongs to the Inventory Controller per inventory/02-business-rules INV_AUTH_004. Per-location policy feedback routes to that persona.tb_product.info is referenced at line save per the per-product expiry rule.