# Work Instruction — Holistic Menu Map **Purpose:** every menu/screen a WI implementer, admin, or power user actually needs for a complete operational picture — WI's own screens plus every other module's screen WI depends on (masters it reads, or a workflow it should logically connect to but doesn't yet). Grouped by operational area, not by which module owns the code, since that's how a person setting up or running WI actually thinks about it. Each line: **Menu name** — `registry key` (owning module) — a note where the name alone doesn't tell the whole story. Legend: **[WI]** = WI's own screen · **[DEP]** = a dependency owned by another module, WI reads its data · **[LINK?]** = related in concept but **not actually connected** today — flagged so it isn't mistaken for a working integration. --- ## A. Engineering & Item Master Data *The manufacturing "how it's built" data WI's assignment resolver and production-plan flow key off of. None of this lives in WI — it's Inventory/Production's own master data.* - **Process Master** — `productionprocessmaster` (Production) **[DEP]** - **Process Type** — `productionprocesstype` (Production) **[DEP]** - **Process Group** — `inventoryprocessgroup` (Inventory) **[DEP]** - **Process Operation** — `inventoryprocessoperation` (Inventory) **[DEP]** — the individual operation steps a Routing is built from. - **Routing** — `inventoryroutings` (Inventory) **[DEP]** — the sequenced set of operations an item goes through; `RoutingId`/`RoutingOperationId` are two of the seven dimensions WI's Assignment resolver can match on. - **Item Master** — `inventoryitemmaster` (Inventory) **[DEP]** - **Item Group** — `inventoryitemgroup` (Inventory) **[DEP]** — another Assignment dimension (`ItemGroupId`); also the field the WI Assignment screen's "Assignment" component was fixed to use (was pointing at the wrong picklist until this session). - **Work Center** — `productionworkcenter` (Production) **[DEP]** — groups workstations for scheduling/capacity purposes above the individual-workstation level. > **Don't confuse with:** WI's own "Process"/"Sub-Process" below (§B) — those organize *work > instruction documents* into a filing hierarchy; they are not manufacturing routing steps and share > no table with this section. --- ## B. WI Authoring & Governance *WI's own document/procedure hierarchy and its lifecycle.* - **WI Process** — `wiworkinstructionprocess` (WorkInstruction) **[WI]** - **WI Sub-Process** — `wiworkinstructionsubprocess` (WorkInstruction) **[WI]** - **Work Instruction** — `wiworkinstruction` (WorkInstruction) **[WI]** — the full process→section→step→content authoring screen; governance workflow and version history live here. - **WI Section Editor**, **WI Step Content Editor** — internal authoring sub-screens, not separately menu-wired today (part of the WI editor's own UI, not standalone menu items). - **WI Skill/Competency Requirement** — attached from within the WI editor, not a separate menu item. --- ## C. WI Assignment & Resolution *Which WI applies where — the specificity-scored matcher.* - **WI Assignment** — `wiassignment` (WorkInstruction) **[WI]** — sets the workstation/work-center/ routing/model/item-group combination a WI resolves for, plus the trigger event and schedule. --- ## D. Workstation & Line Infrastructure *The physical/process layout WI's Digital Twin and assignment resolver render against.* - **Workstation** — `wiworkstation` (WorkInstruction) **[WI]** - **Workstation Config** (display config) — `wiworkstationconfig` (WorkInstruction) **[WI]** — display mode (Kiosk/Twin-Monitor/Tablet/Single), font scale, step/cycle timer visibility; now actually applied by the Workstation Display Screen (fixed 2026-08-20). - **Production Line** — `wiproductionline` (WorkInstruction) **[WI]** — the sequence of workstations on the line (`PositionNo`, "Line–Station Map") is managed as a detail grid inside this same screen, not a separate menu item. - **Line–Operation Map** — `wilineoperationmap` (WorkInstruction) **[WI]** — which operation runs at which workstation on a line, with a manpower expectation (the basis for staffing-gap detection). - **Work Center** — see §A **[DEP]** — a work center groups workstations above the line level; distinct from Production Line (a line is a physical sequence, a work center is a scheduling group). --- ## E. Roster, Staffing & Attendance *Who's on shift, where — and the separate HR leave/attendance world it does not talk to.* - **Roster Planning** — `wirosterplan` (WorkInstruction) **[WI]** — plan/confirm a shift's roster (Planned vs. Actual), Copy-Forward. - **Line Shift Staffing (live)** — `wiliveshift` (WorkInstruction) **[WI]** — assign employees to workstations for a confirmed roster; Mark Absent/Replacement is an action inside this screen, not a separate menu item; append-only (never deletes a staffing row). - **Shift Confirmation** — the Actual-roster confirm action inside Roster Planning (a Planned roster can never be directly confirmed) **[WI]** — a status transition within that screen, not a standalone menu item. - **Shift Master** — picklist key `shiftmaster` → `MSHIFT` (shared/framework master) **[DEP]** — the shift *definition* (code, timing) WI's roster screens pick from; owned centrally, not by WI or HR exclusively. - **Leave Application** — `essapplyleave`, `essleaverequest` (ESS self-service); **[DEP] [LINK?]** - **Leave Credit/Debit, Bulk Leave Request** — `hrmsleavecredit`, `hrmsleavedebit`, `hrmsleaverequestbulk` (HRMS) **[DEP] [LINK?]** - **Shift Pattern / Shift Change** — `hrmsshiftpattern`, `hrmsshiftchange` (HRMS) **[DEP] [LINK?]** - **Attendance Adjustment / Team Attendance Calendar** — `essattendanceadjustment`, `essteamattendancecalender` (ESS) **[DEP] [LINK?]** > **[LINK?] called out deliberately**: none of the four HR/ESS items above are read by WI's roster > or staffing code today (confirmed — zero references). An employee can be on approved leave in HR > and still show as staffed in WI's roster unless a supervisor manually reflects it via Mark Absent. > If a client expects HR leave approval to automatically block/flag a WI roster slot, that is new > integration work, not a configuration gap. --- ## F. Production & Planning *The work that gets scheduled onto a line.* - **Production Plan** — `productionplan` (Production) **[DEP]** — item/quantity/date-range plan lines; menu-wired 2026-08-20 as part of this session's work. - **Line Production Plan Allocation** — `wilineproductionplanallocation` (WorkInstruction) **[WI]** — allocates a plan line to a line/shift/date/(optional) workstation/time-window, without needing a formal work order first. - **Work Order (Indent)** — no dedicated WI-side menu item; WI reads `TINDENT`/`TINDENTDETAIL` directly wherever a work-order-linked execution or a `WOD:` scan needs one to exist **[DEP]**. The Production/MM module's own Work Order screens are the place to create/manage these. --- ## G. Execution, Acknowledgement & Scan-Verify *What happens at the point of work.* - **Work Execution** — `wiexecution` (WorkInstruction) **[WI]** - **WI Step Execution** — `wistepexecution` (WorkInstruction) **[WI]** - **Workstation Display Screen** — `wiworkstationdisplayscreen` (WorkInstruction) **[WI]** — the shop-floor/kiosk run screen; embeds the Workstation and Employee scan cards. - **Acknowledgement** — no dedicated menu item; the check/save actions are embedded in the execution start flow, not a standalone screen **[WI]** (backend complete, FE embedded not standalone — a pre-existing, previously-flagged gap). - **Scan-Code — Workstation** — `wiworkstationscancode` (WorkInstruction) **[WI]** - **Scan-Code — Employee** — `wiemployeescancode` (WorkInstruction) **[WI]** - **Scan-Code — Work Instruction** — `wiscancode` (WorkInstruction) **[WI]** - **Scan-Code — Work Order Detail** — `wiworkorderdetailscancode` (WorkInstruction) **[WI]** --- ## H. Readiness, Digital Twin & Analytics *Supervisor/leadership situational awareness.* - **Skill Gap for Roster** — `wiskillgapforroster` (WorkInstruction) **[WI]** - **Line Digital Twin / Plant Overview** — `wilinedigitaltwin` (WorkInstruction) **[WI]** — one screen, two view-states; push-updated (SignalR, 2026-08-20). - **WI Analytics** — `wianalytics` (WorkInstruction) **[WI]** — Compliance Summary, Time Study Summary, Execution History; menu-wired 2026-08-20. --- ## I. Maintenance / Equipment Availability *Whether the physical thing WI is scheduling against is even available — genuinely unresolved.* - **Asset**, **Asset Type**, **Asset Activity** — `maintenanceasset`, `maintenanceassettype`, `maintenanceassetactivity` (Maintenance) **[DEP] [LINK?]** - **Maintenance Activity**, **Activity Type** — `maintenanceactivity`, `maintenanceactivitytype` (Maintenance) **[DEP] [LINK?]** - **Meter Reading**, **Problem**, **Solution**, **Claim**, **Key Component** — `maintenancemeter`/`maintenancereading`, `maintenanceproblem`, `maintenancesolution` (Maintenance) **[DEP] [LINK?]** > **The real "machine unavailable" mechanism today lives outside the Maintenance module**: MM's own > Scheduling/Calendar engine treats unresolved CRM `TCALL` rows (support/breakdown tickets, > `CALLSTATUS != 4`) as "breakdown windows" that block scheduling on a machine — a real, wired > mechanism, but scoped to MM's scheduler, not to the dedicated Maintenance module's Asset concept, > and **WI itself has zero reference to any of it** (confirmed — no query, no join, nothing). A > workstation genuinely down for repair today will not show as unavailable anywhere in WI's > Assignment resolution, Roster staffing, or Line Digital Twin — it will simply look staffed and > idle/live exactly like a working one. This is the single largest real gap between "what a > holistic view implies should be connected" and what's actually connected, and it spans three > different subsystems (Maintenance's own Asset model, MM Scheduling's CRM-ticket-based breakdown > windows, and WI) with no shared thread today. --- ## J. Skill Management (prerequisite dependency, not optional) *Populate before configuring anything in §B/§C/§H that references a skill.* - **Skill**, **Skill Group**, **Skill Domain**, **Skill Level** — skill taxonomy **[DEP]** - **Skill–Product Map**, **Skill–Process Stage Map** — ties skills to what's being built/run **[DEP]** - **Role/Job Skill Requirement** — the baseline WI's eligibility checks and skill-gap reports measure against **[DEP]** - **Employee Skill Profile** — current level per employee, per skill; the actual data WI's eligibility gate reads at execution time **[DEP]** - **Skill Assessment** — manual assessment history **[DEP]** - **Skill Matrix**, **Skill Matrix Config** — the wall-chart view; not read by WI directly, but the same underlying profile data feeds both **[DEP]** --- ## How to use this for menu-tree setup A sensible top-level menu grouping for a real rollout, following the sections above: ``` Work Instruction ├── Authoring (B) ├── Assignment (C) ├── Workstations & Lines (D) ├── Roster & Staffing (E — WI's own items only) ├── Production Planning (F — WI's own item; link out to Production module for the rest) ├── Execution & Scan (G) ├── Digital Twin & Analytics (H) Engineering Data (A — usually already exists under Inventory/Production, link don't duplicate) Skill Management (J — separate module's own menu tree, link don't duplicate) Maintenance (I — separate module's own menu tree; not yet meaningfully connected to WI) HR / Attendance (E's HR items — separate module's own menu tree; not connected to WI's roster) ``` Don't recreate (A)/(J)/(I)/HR screens as WI menu items — link to the owning module's existing menu node instead. Duplicating them invites the two copies to drift. --- *Companion to `Docs/WorkInstruction-Feature-Functionality-Guide.md` and `Docs/WorkInstruction-Detailed-Feature-List.md`. Registry keys confirmed against `gb4.7mfe/features/gbformviewer/gbformviewer.registry.json` and the relevant module source as of 2026-08-20 — re-verify before using these as literal menu-seed values in a migration, since a key's existence in the registry does not by itself mean it has a seeded `MMENU`/`MWEBFORM` row yet (see the companion Feature Guide §4 on menu wiring as a real go-live step, not a formality).*