Work & quality

Purpose

This chapter is production's execution loop: it records what was actually done on the shop floor (as opposed to Production & planning, where assignments are formed — what should be done). Three related processes:

• Work intake — a foreman/operator records the actual quantity submitted against an order routing step (creates a WorkRecord entry, see the Getting started glossary); this is also the entry point into the Shop floor terminal mode (Kiosk), for installation on a shop-floor PC.
• QC: defects — quality control of what was submitted: acceptance or rejection (QcRecord), handling the resulting nonconformities (Nonconformance → a QualityDisposition decision: rework/ write-off/as-is/convert), the closed-loop rework of defects (ReworkOrder), and summary statistics/a Pareto by defect type.
• Timesheet — the same WorkRecord log, aggregated by employee and day (standard hours, number of entries) for computing output/payroll.

All three screens read and write the same append-only WorkRecord/QcRecord log — nothing in it is ever overwritten or deleted; corrections (reversal, QC correction) always add a new compensating entry that references the original.

Who uses it (roles)

Roles and permissions are described in detail in Getting started ("Roles and permissions (RBAC)") — here only what is specific to this phase:

As in Getting started: qc.write is a separate permission inside "Work intake"/"QC: defects," distinct from the permission to view the sections themselves (work-records.view and defects.view respectively); work-records.correct is a separate permission for reversal. Server-side access is also checked: the "Nonconformities" and "Rework" tabs, as well as the QC log itself, require qc.write entirely — the defects.view permission, which opens the "QC: defects" menu item, does not by itself authorize any action on those three tabs; in practice both roles that can see the page (Area foreman, QC inspector) hold both permissions at once.

Key concepts

Work intake (/work-records)

What you see

A table of all steps not yet fully submitted, across all unfinished orders (GET /api/worklist — a flat list, not broken down by place): Order #, Product, Operation, Performer (whoever the step is assigned to on the schedule, Production & planning — not necessarily the same person doing the submitting), Remaining (= plan minus already submitted), Status (Pending/In progress/Done), and in the last column, "Accept" and "QC" buttons (the latter unavailable until at least one unit has been submitted against the step). Above the table is a filter field and a "Terminal mode →" button in the top-right corner, which switches the whole application into full-screen Kiosk.

Typical scenarios

1. Accepting work. The operator finds their row (or filters by order/operation), clicks "Accept" → the "Accept work" dialog: a list of employees with checkboxes (whoever signed in with their own login and is linked to an Employee record is already checked), a field for quickly adding a new employee right from the dialog ("+ Add," no need to go to the "Employees" page), a "Submitted, qty" field (defaults to the whole remainder), "Shift" (the shifts reference, or free text if the reference is empty). After saving: the step moves "Pending → In progress" on the first submission and "In progress → Done" once the submitted amount reaches the plan — at which point the row disappears from the list.
2. Recording a QC mark. Once something has been submitted, the "QC" button on the same row → see the QC "Log" tab below.
3. Correcting an erroneous submission. Not available from this page — a step that has reached "Done" drops out of the list entirely. It is reached through the "Orders" section (Products & orders): on the order's detail card, each step has an "Other actions" menu → "Submissions" (the full submission log for the step, including corrections already made) and, in the same menu, "QC" (available even for steps in "Done" status, unlike "Work intake," where the QC button is visible only while the step is still in the list).

Notes and limitations

• The list is company-wide, with no "my place" filter — on a large production floor this can be a long list; the only way to narrow it down is the text filter above the table.
• Anyone with work-records.view can accept work on behalf of any employee — the "Performer" assignment from the schedule (Production & planning) is not checked and does not restrict which workers can be picked in the dialog.
• A correction ("Correct" in "Submissions") does not edit or delete the original record: a new entry with a negative quantity and a reason is added, and the original stays in the log marked as corrected; an already-corrected entry cannot be corrected again (the button disappears).
• Archived employees (see "Employees," Reference data & access) are not offered for new intake/QC, but remain visible in the history of old records — archiving does not rewrite the past.

Shop floor terminal — Kiosk mode

What you see

A full-screen mode with no side menu, no panel windows, and no object inspector (see Getting started) — turned on with the "Terminal mode →" button on the "Work intake" page and turned off with its own "← Exit terminal mode" button inside Kiosk itself. The start screen has two large square options: "Accept work" and "Batch information." The central element of every step inside Kiosk is one large text field that always has focus (clicking elsewhere or losing focus returns the cursor to it automatically) and responds to Enter — built for a barcode/RFID scanner that emulates a keyboard and itself sends Enter after the code. A regular keyboard works exactly the same way — no special hardware is needed for testing.

Typical scenarios

1. Accepting work on the terminal. Screen 1 — "Scan or enter the employee code" (looks up the "Code" field in the "Employees" reference, exact match). Screen 2 — "Scan the batch barcode (routing sheet)" — looks up by the prefix of the work-order ID: the printed routing sheet form encodes it as a Code128 barcode (no hyphens, first 20 characters), and the same prefix is compared during scanning. If exactly one unsubmitted step remains on the batch, it is selected automatically; if more than one, a list of operation buttons is shown (submitted ones are disabled). Then — quantity (defaults to the whole remainder), shift, an "Accept" button that works through the same POST /api/work-records as the ordinary dialog on "Work intake," but always with one worker — the one identified at the start. Buttons at the bottom: scan another batch, change worker, exit.
2. Batch information without identification. "Batch information" — only the batch code is scanned, with no employee sign-in; shows an "Operation / Submitted / Total / Status" table for all of the batch's steps and records nothing — meant for checking what stage a batch is at without checking in as its performer.

Notes and limitations

• Kiosk has no group intake (several workers on one submission) — only one scanned/entered employee at a time, unlike the ordinary "Accept work" dialog.
• Kiosk has no QC function at all — only intake and the information mode; marking a defect still requires "Work intake"/"Orders" in the regular (non-kiosk) interface.
• There is no tracking of start/end-of-work time at a specific workstation — that is a separate mechanism (WorkSession, "Work assignments," Production & planning), unrelated to this screen; intake in Kiosk records only the final quantity, not exactly when the person was at the machine.
• There is no automatic export of the CNC control program to the terminal/USB drive when an assignment is picked up — what the legacy article describes about CNC files is not implemented in Vyrab.
• Looking up a batch by code matches on the ID prefix (not a separate printed batch number); a collision is practically ruled out at the scale of a single company, but this is not a "real" product barcode, just an encoded internal identifier.

QC: defects (/defects) — "Log" tab

What you see

A date filter (last 30 days by default), a "Defect records for the period" counter next to the "Show" button, a table: Date, Result (Accepted/Rejected), Qty, Defect type, Inspector, Comment.

Typical scenarios

1. A new record is not created from this tab, but from the "QC" dialog, opened either via the button on "Work intake" (step not yet "Done") or via "Orders" → "Other actions" → "QC" (step in any status, including "Done"): an Accepted/Rejected toggle, a required inspector selection (from "Employees"), quantity (defaults to the whole batch submitted against the step), for "Rejected" — an optional defect type (the "Defect types" reference, Reference data & access) and a warning right in the dialog: "The rejected quantity will be deducted from what was done — the step will return to 'Work intake' for resubmitting that quantity"; free-text comment.
2. Reviewing defect history for a period, filtering by date, manually re-running the count of rejected records.

Notes and limitations

• "Accepted" is a purely recording mark — it changes no quantities (the submission was already counted by the act of intake on "Work intake").
• "Rejected" subtracts the given quantity from the step's handed_qty; if the step was already "Done" and, after the subtraction, the submitted quantity is now below plan, the step is forced back into "In progress" status (the only "rewind" of a step's status the system has, built specifically for this case).
• Every "Rejected" mark automatically opens exactly one nonconformity on the "Nonconformities" tab — the direct "log entry → nonconformity" link is not shown on this tab, it needs to be looked up there.
• An erroneous QC record cannot be deleted or edited directly: as everywhere in this phase, only a compensating correction is available, reachable via POST /qc-records/{id}/correct — there is no direct entry point into that from the UI shown here (for a reversal, you need to find the linked nonconformity and confirm nothing has been approved on it yet).

QC: defects — "Nonconformities" tab

What you see

On the left, a nonconformities table: Operation (the step id, abbreviated), Qty, Allocated (the sum of approved decisions), Status (Open/Closed/ Canceled). Clicking a row opens a card on the right: a header with the id, status, and a "Close" button (while open), a table of decisions already made (Decision, Qty, Reason, Status: Draft/Approved/Reversed, and an "Approve" or "Reverse" button depending on status), below it a form for adding a new decision: type (Rework/Write-off/As-is/Convert to another part), quantity, for "Rework" — a required "Target operation ID" field (a plain text input, the receiving step's id is typed in manually, with no pick-from-list), reason, an "Add decision" button.

Typical scenarios

1. After a "Rejected" mark, the inspector opens the nonconformity that appeared, enters one or more decisions covering the whole rejected quantity (for example, part into rework, part written off), and clicks "Approve" on each.
2. Approving a "Rework" decision automatically creates a rework order — it appears on the "Rework" tab; there is no separate action to create it.
3. Approving an "As-is" decision returns the quantity back to the step's submission (handed_qty increases) — the part is deemed acceptable with no rework at all.
4. Once the sum of approved decisions equals the nonconformity's quantity (and, if there was a "Rework" decision, the corresponding order has reached "Done" status), the "Close" button becomes available.

Notes and limitations

• A nonconformity cannot be created manually — only automatically from a "Rejected" mark; this tab only offers operations on already-open records.
• Only the "As-is" decision physically changes the submitted quantity (in both directions — approval adds, reversal subtracts it back); "Write-off" and "Convert to another part" have no automatic effect on handed_qty in the current implementation — they are accounting notes with no side effect.
• The sum of approved decisions cannot exceed the nonconformity's own quantity — an attempt to approve a decision beyond the remainder is rejected by the server.
• "Close" is blocked while the nonconformity has an approved "Rework" decision with an order that is not yet finished (not "Done") — a nonconformity cannot be closed without waiting for the rework's result.
• The "Target operation ID" field for rework is raw text, not a pick from the order tree — the step id must be copied beforehand (for example, from the object inspector, Getting started, or from the order card's address bar).

QC: defects — "Rework" tab

What you see

On the left, a rework orders table: Target operation (the id, abbreviated), Qty, Status (Draft/Issued/In progress/Awaiting inspection/Done/Canceled). On the right, clicking a row shows the order's card: id, status, a button to move to the next status ("Start," then "Send for inspection"), a line with the linked rework step's id, a table of shift assignments already created (Date/Place/Plan), a form for adding an assignment (Place and Shift are free text, not picked from the places/shifts references, Date, Qty, a "+ Rework assignment" button), and — in "Awaiting inspection" status — a re-inspection form: an Accepted/Rejected toggle, inspector, for "Rejected" — a defect type, comment, a "Re-inspect" button.

Typical scenarios

1. An order appears on the tab already in "Issued" status (right after a "Rework" decision is approved on the previous tab — "Draft" does not actually occur in practice, creation skips straight past that status). The foreman adds one or more rework shift assignments (place, shift, date, planned quantity) and moves the order to "In progress."
2. Once the rework is physically done, the order is moved to "Awaiting inspection," and the inspector performs a re-inspection: "Accepted" closes the order ("Done," after which it becomes possible to close the nonconformity itself on the "Nonconformities" tab), "Rejected" returns the order to "In progress" — the cycle can repeat until the rework is accepted.

Notes and limitations

• A rework order always has exactly one rework step (ReworkStep) — a multi-step rework route is not supported.
• The "Place" and "Shift" fields when adding a shift assignment are free text, with no validation against the "Places"/"Shifts" references (unlike most other places in the application, where these values are picked from a list) — a typo will not be caught on this screen.
• A repeat rejection does not open a new nonconformity — the same rework order simply goes back "in progress" for another attempt.

QC: defects — "Statistics" tab

What you see

A date filter (30 days by default), and after "Show" — six tiles: First pass yield, %, Inspected, Accepted, Rejected, Open nonconformities, Rejected on re-inspection; below, a Pareto table by defect type (Defect type / Qty) and a "Rework orders by status" list (a counter for each status).

Typical scenarios

An inspector or foreman periodically checks the trend for a place/period: a sharp drop in "First pass yield" or a rise in a particular defect type in the Pareto is a signal to investigate what went wrong; the rework-by-status list shows whether orders are piling up in "Awaiting inspection" (meaning re-inspection is lagging behind the actual rework).

Notes and limitations

• The statistics are deliberately minimal: there is no breakdown by place, equipment, material supplier, or nonconformity closing time — this is a deliberate scope cut, not a forgotten feature.
• "Rejected on re-inspection" counts only rejections during rework re-inspection specifically (the "Rework" tab), not rejections overall — it is a separate number from the general "Rejected" counter above.
• More detailed statistical process control (I-MR control charts, Cp/Cpk for numeric QC measurement parameters) lives not here but on the SPC tab of the "Analytics" section (Dashboard & analytics), which uses the same QcRecord/QualityMeasurement data.

Timesheet (/timesheet)

What you see

A date filter (last 30 days by default), a "Show" button, and an export-to- Excel button; if the operator lacks timesheet.view_all, an explanatory line reads "Showing only your own timesheet — you do not have permission to view all." A table: Worker, Date, Hours, Minutes, Entries (how many separate submissions went into the sum for that day).

Typical scenarios

1. A cost accountant with timesheet.view_all reviews the timesheet for all employees over a pay period and exports it to Excel (tabel_<from>_<to>.xlsx, a dedicated file, not the table's generic CSV export) for further payroll calculation.
2. An area foreman without timesheet.view_all opens "Timesheet" and sees only their own entries (matched via Employee.platform_user_id ↔ the signed-in operator) — handy for checking their own output, but not anyone else's.

Notes and limitations

• The timesheet is not separately entered data but an aggregate of the same WorkRecord log populated on "Work intake": a row appears as soon as an employee has at least one submission for the day; there is no dedicated hours-entry screen of its own.
• "Hours" = standard time (Tman × quantity submitted), not actual time worked — with a group submission (several employees on one entry, see "Work intake"), every participant is credited the full norm for that submission in their own timesheet, not a share of it; a crew's total hours for a shift in the timesheet can noticeably exceed the length of the shift itself.
• Corrected (reversed) submissions are accounted for automatically: a compensating entry with a negative quantity reduces the same (employee, date) total — individual corrections are not shown as a separate row in the timesheet, only their net effect on the sum.
• Export to Excel is the only export format for this section (inherited from legacy VOGBIT); the table's ordinary CSV button (DataTable) is not available for the timesheet.

Related sections

• Getting started — roles and permissions (including the breakdown of qc.write/work-records.correct), Kiosk mode as a general window mechanism, the glossary (WorkRecord, QC).
• Dashboard & analytics — the "To be submitted at places," "Defects in last 7 days," "Open nonconformities" widgets, and the "Analytics" SPC tab — all built on the same WorkRecord/QcRecord/Nonconformance data as this phase.
• Production & planning — the "Production schedule" creates the steps (OrderOperationStep) that are accepted and inspected here; "Work assignments" — WorkSession (tracking start/end time at a workstation), a mechanism separate from WorkRecord, not to be confused with it.
• Products & orders — "Orders": the order's detail card is a second route, besides "Work intake," to QC and submission history ("Other actions" → "QC"/"Submissions"), the only route to QC on steps that are already "Done."
• Cost & prices — labor cost is computed from the same standard time (Tman × quantity submitted) from WorkRecord that "Timesheet" shows.
• Reference data & access — the "Employees" reference (not to be confused with "Operators" — logins), "Shifts," "Defect types," used in all the dialogs in this phase.