Production & planning

Purpose

Five sections in the Production menu group, responsible for what should be done in the shop and when: from a strategic view of the entire order portfolio (Flow management) and the pull discipline of a specific place (Dispatch), to actually creating production orders and turning them into assignments (Production schedule), distributing those assignments across posts and shifts (Work assignments), and doing so manually by day of week (Detailed schedule).

The first two sections — Flow management and Dispatch — have no equivalent in the original VOGBIT desktop application and are not described on the support site: they are an independent Vyrab add-on in the spirit of Theory of Constraints / pull-based planning (POLCA, buffers, WIP limits, the constraint drum). Below they are described purely from the code. The other three sections are direct descendants of VOGBIT support/552 "Production schedule" and support/593 "Work assignments"/ support/605 "Shift assignments," with the same terminology (batch, queue, accounting level, readiness, post) and the same logic: "the higher the accounting level, the more granularly an assignment must be scheduled before it can be submitted."

The sections form one and the same top-down data flow: order → schedule item (WorkOrder) → routing step (OrderOperationStep) → shift assignment (ShiftTask) → work record (WorkRecord, Work & quality). Flow management and Dispatch read and partly influence the same graph but do not create it — the graph is created on the Production schedule by the "Create assignments" button and is populated with execution data on Work assignments/Detailed schedule.

Who uses it (roles)

Permissions are split across four slugs (see Getting started, "Roles and permissions"):

• scheduler.view — opens Flow management and Dispatch (view only: board, KPIs, drum queue, scenario history).
• scheduler.manage — adds management: computing a new scheduler scenario, confirming a constraint place, freezing/unfreezing a step's date, place locks, WIP limits, POLCA cards. Held by the Area foreman and the Dispatcher.
• scheduler.publish — separate and higher: makes a published scenario effective (writes dates into the real steps and creates shift assignments). Held only by the Area foreman — the Dispatcher can compute and compare as many scenarios as they like, but the foreman (or the administrator) publishes the final plan.
• production-board.view, work-assignments.view, detailed-schedule.view — the ordinary "can see the section" permissions for Production schedule, Work assignments, and Detailed schedule respectively; there are no view/act exceptions inside them.

Key concepts

• Accounting level (accounting_level) — set on the order, and optionally overridden on an individual step: minimal / medium / high / maximum. Determines exactly how an assignment is carried out: at the minimal level it is a simple "done/not done" via a bulk button on the Production schedule; starting from the high level, a step must go through an explicit shift assignment — such steps are what land in "New assignments" (Work assignments) and in the Detailed schedule grid (see below).
• Shift assignment (ShiftTask) — a specific instruction: step + place + shift (optional) + date + planned quantity/hours. Can be created manually (Work assignments/Detailed schedule), created in bulk by publishing a scheduler scenario, or created with no step attached at all — under "Unplanned work."
• Readiness — an indicator on a pending step: OK (can be included in the plan), Needs clarification (the operation has no place assigned), Set a shift (the place does not work on the calendar on the chosen date), Move / split (the place is already overloaded by hours on that day).
• Scheduler scenario / run (ScheduleRun) — the result of one CP-SAT scheduler computation: a draft (succeeded) can be compared against the effective plan and published; the published one (published) is the only one in effect at any time, and the previously published one automatically moves to superseded.
• Freeze (Override) — manually pinning the start date of a specific step for a period, so the scheduler does not move it on the next recomputation.
• POLCA card / WIP limit / buffer / constraint drum — see the Getting started glossary; here these are not an abstraction but concrete, configurable entities: the card limit between a pair of places, the limit on concurrent "in progress" operations at a place, thresholds (in days) for the green/yellow/red/black buffer zones, the confirmed constraint place with its queue.
• Place lock (BlockageEvent) — an open incident (equipment / material / QC / other); while it is active, the place does not release new cards into work on the Dispatch board.
• Remainder transfer (TaskTransfer) — part of the unfinished quantity of one shift assignment is moved onto another (for example, when closing a shift with unfinished work).
• Cleared to start — not a separate step status but a server-computed slice of a place's "pending" steps: without blockers and within the free WIP/POLCA limit. This is the column on the Dispatch board that actually constrains anything.

Flow management

/flow-management, permission scheduler.view (management — scheduler.manage, publishing a scenario — scheduler.publish).

What you see

A single screen titled "Flow management" with a badge reading "Management available" / "View only" depending on permissions.

• Filters: search by order number/product, place, condition (Deadline risk / Low reserve / On plan / Not scheduled), timeline horizon (2/4/6 weeks).
• KPI cards: "Orders at risk" (out of the total), "Constraint candidate" — the most heavily loaded place (with a "Confirm" button for scheduler.manage, promoting it to the official drum), "Operation WIP" (currently in progress), "Completing" (orders within the selected horizon), "Shortages" (the number of material shortage items — from the same calculation as Supply availability, Warehouse & supply; when that module is unavailable, "no data").
• Planning scenarios (collapsible panel): a form for a new run (optional "rope date" — do not release orders earlier than this), run history (queued/running/succeeded/published/superseded statuses with a color indicator), the selected scenario's card (when it was computed, how many operations, the objective function value), a "Compare" button against the effective plan, and a "Publish" button (scheduler.publish only). The comparison result is a summary (total/changed/earlier/later, lateness in the baseline/in the draft) and a list of the largest date shifts.
• Drum · TOC (collapsible panel): the queue of operations at the confirmed constraint place, sorted by planned start, with a color-coded buffer-penetration zone (normal/attention/urgent/overdue) relative to the buffer profile (5/14-day yellow/green threshold by default). Empty, with a prompt to "confirm the candidate place," until a constraint is assigned.
• Plan table (collapsible panel): a flat, sortable, filterable table of orders and their steps — view-only, no recomputation.
• Working area: a list of orders on the left (a colored risk dot + badge), a resource timeline in the center (horizontal operation bars by place, a "today" line, the candidate place marked "candidate"), an inspector on the right — for the selected order: start/forecast/promised date/reserve in days/priority, "Risk reasons" (no planned dates, predecessor not finished, material shortage, an open QC nonconformity on the predecessor, a place lock), the route of steps with a lock icon (freeze/unfreeze the start, scheduler.manage), an "Open order card" link.
• Needs attention (bottom of the screen): a separate list of steps pending past their planned start, and steps with no plan dates at all.

Typical scenarios

1. The dispatcher starts the day with the "Orders at risk" KPI → clicks an order → reads "Risk reasons" → decides what to do (expedite material, clear a lock, change priority).
2. The dispatcher computes a new scenario with a given rope date → compares it against the effective plan → sees fewer lateness cases → the area foreman publishes it. Publishing always writes new planned_start/planned_end into the steps; shift assignments are created or updated only for steps with a high/maximum accounting level and with no already-existing unfinished assignment — manual assignment or work already in progress is never overwritten by publishing.
3. The foreman confirms the candidate place as the official constraint — a drum queue then appears on it, setting the priority of work.
4. The dispatcher pins the start date of a critical step (for example, a nonstandard delivery is expected) for a period — "Pin start" in the inspector, with an optional reason; released with the "Unpin" button.

Notes and limitations

• Only one published scenario is in effect at a time — publishing a new one automatically moves the previous one to superseded.
• The scheduler.publish permission is held only by the Area foreman (and the Administrator) — the Dispatcher does not have it: they can compute and compare scenarios, but cannot "turn them on."
• The publish outcome (how many steps were written, how many assignments created/updated/skipped, and why) is not shown as a separate report in the interface — it is visible only from the run history being updated.
• The whole section — like Dispatch — has no predecessor in the original VOGBIT; the POLCA/buffer/WIP-limit/drum terms are new here.

Dispatch

/dispatch (the menu item is called "Dispatch board"), permission scheduler.view; dragging cards and any management (locks, POLCA limits) require scheduler.manage.

What you see

• A toolbar: place selector (defaults to the first one in the reference list), "Refresh."
• The "Place locks" panel: a list of active locks (reason — Equipment/Material/QC/Other, comment, start time) with a "Clear" button; a form for adding a new one (reason + comment + "Lock") — both parts are visible only with scheduler.manage.
• The "POLCA cards between places" panel: rows of limits where the current place is the upstream one ("→ receiving place") or the downstream one ("source place →"), with the current card fill in flow / limit (highlighted when no cards remain); a form for setting a new limit (receiving place + number of cards). The panel is hidden entirely if there are no cards and no management permission either.
• Four columns:
  1. "Waiting" — the place's steps not yet cleared to start (not in "Cleared"), cards cannot be dragged.
  2. "Cleared to start" — a server-computed slice of "Waiting" without blockers and within the free WIP/POLCA limit; shows a WIP: used/limit badge; the card can be dragged to "In progress."
  3. "In progress" — steps in the "in progress" status; the card can be dragged to "Done."
  4. "Completed (7 days)" — steps actually completed (by the closing time of the work session) over the last 7 days; not draggable.
• A step card: order number, priority badge P{n}, product, operation, a submitted/total progress bar, planned dates, blocker tags ("No planned dates," "Predecessor not finished," "Place locked"). Clicking without dragging opens the order in the object inspector.

Typical scenarios

1. The dispatcher picks a place → sees in "Cleared to start" exactly what can actually be started right now (the WIP limit is already accounted for) → drags a card to "In progress."
2. The foreman finishes an operation → drags the card from "In progress" to "Done."
3. A machine breaks down — a place lock is registered (reason "Equipment" + comment). While it is active, the place releases no new cards into "Cleared to start," even if the WIP limit is formally free.
4. A POLCA limit is set up between two consecutive places (for example, "Turning → Assembly," 3 cards) — Assembly cannot pull more than three batches at once from Turning.

Notes and limitations

• "Cleared" is not a separate step status but a slice of "Waiting," so a step can never land in both columns at once — duplication is deduplicated on the client.
• A card can be dragged only from "Cleared to start" (into progress) or from "In progress" (into done) — never from "Waiting" or "Completed," even with scheduler.manage.
• The place's own WIP limit (the number "Cleared" fills up to) is not editable from this interface — it is only displayed (the WIP: x/y badge, plus a separate widget in Analytics, Dashboard & analytics). Changing the limit is done via the POST /api/flow/wip-limits API — there is no web form for it yet.

Production schedule

/production-board, permission production-board.view.

What you see

Three switchable (and reorderable) views — List / Gantt / Kanban — above a shared production-order table.

• List — a DataTable with columns: an urgency indicator (a colored dot — overdue/deadline near/time to launch/still early, important orders always sort above by this indicator), an "Important" checkbox, order #, batch, # within order, product, quantity, queue, state (a badge: Draft / Ready to schedule — a virtual status for a draft flagged ready / Planning / In production / Done / Canceled), readiness %, labor intensity (assigned or computed — the toggle is visible only under aggregated norming), folder, accounting level, "Material request"/ "Accounting doc" flags, comment, configurator parameters (one column per parameter encountered), start/deadline. Batch, # within order, queue, accounting level, and comment are edited directly in the cell. The "Details" button expands a row-per-step mode — one row per routing step of each order, rather than one row per whole order.
• Gantt — bars by order, grouped by product (collapsible groups); dragging a bar moves its deadline, dragging its edge changes duration (saved on release); arrows show dependencies between orders, lifted from the step level (depends_on); scale Day/Week/Month.
• Kanban — columns by the order's real statuses; a card can be dragged to an adjacent column only if the transition is allowed (draft → canceled; planning → in production/canceled; in production → done/canceled) — "Create assignments"/"Delete assignments" transitions are not available via kanban, only through selection and the buttons below.
• Selection panel (when rows are selected): "Create assignments" (only if all selected are drafts), "Delete assignments" (only if all are in planning), "Change state" (only if all have a minimal accounting level and there is a next status), a queue number field + "Assign queue," "Put in folder," "Export files," "Clear selection."
• Row actions (⋮ menu): "…manually" (create assignments manually, draft only), "Submit to warehouse," "Material request," "Files," "Composition and routing" (opens the product in the inspector), "Split" (draft only).
• Toolbar: "Reorder queue" (+ a customer selector, if the queue type is "Own, by customer"), "Queue, schedule," filters (a routing filter + a period by start date — an active-filter count on the button), "Chart," export to Excel, settings (gear icon), "+ New order."

Dialogs behind the buttons:

• Production schedule settings — queue type (global / own, by customer), assignment-issue lock in days (empty — disabled), norming type (per-operation / aggregated), default accounting level, sequencing (arbitrary / by dependencies — turns on sequence_mode: sequenced, under which a new shift assignment cannot be created until the predecessor per depends_on is finished).
• Create assignments manually — a list of operations per order product with checkboxes; an unchecked box excludes the operation from the explosion (if all operations for a product are unchecked, no schedule item is created for it at all).
• Split — row-by-row entry of the new items' quantities, with a running remainder against the original order's quantity; creates sibling orders (same product/order number/folder/queue/accounting level/configuration), the original item is reduced by the sum split off.
• Submit to warehouse — a draft arrival document with one line (quantity + unit cost), not posted automatically.
• Material request — creates a limit-and-issue card (number, department, limit, effective start date), linked to the order.
• Queue, schedule — reorders orders by dragging, "Save" rewrites the queue number as position in the list.
• Files — attachments on the order's product and (if the order is already launched) on the products of all its schedule items.
• Chart — a donut chart by quantity, grouped by state/order/folder.

Typical scenarios

1. The foreman creates an order ("+ New order") → picks a product/quantity/ dates → the order sits as a draft ("Draft").
2. Selects drafts → "Create assignments" — the order is exploded by BOM, a schedule item (WorkOrder) is created for each part, and a routing step for each routing operation; the order moves to "Planning." For a non-standard case — "…manually" from the row menu, to exclude some operations from the launch.
3. On a mistake — "Delete assignments" undoes the launch and returns the order to draft, but only while no step has been touched yet (no submissions, no performer assigned).
4. The dispatcher sets the launch queue — either by typing a number ("Assign queue") or by dragging in the graphical queue editor.
5. Once the product is ready — "Submit to warehouse" from the row menu sets up an arrival document; for a batch of materials for the order — "Material request" sets up a limit-and-issue card.

Notes and limitations

• Changes to the section's settings (gear icon) are physically saved only with admin.view — anyone who can see the section can open the dialog, but only the administrator can save the changes.
• "Change state" from the selection panel works only for orders with a minimal accounting level; at higher levels the state moves through the execution of shift assignments (Work assignments/Detailed schedule), not a bulk button.
• The "routing filter" is an OR condition within each group (material/operation/place/equipment) and AND between groups.
• Export to Excel is the only way to export the whole board at once (besides the table's own built-in CSV export).

Work assignments

/work-assignments, permission work-assignments.view.

What you see

Six tabs:

• New assignments — pending steps of launched orders with a high or maximum accounting level that do not yet have a single (non-canceled) shift assignment. Columns: readiness indicator (a colored dot + a label: OK/Needs clarification/Set a shift/Move-split), order, product, operation, place, quantity, "Include in plan" button (opens a quick assignment dialog), and "Flag"/"Unflag."
• Assignments for the day — a date picker, all shift assignments on that date regardless of status; columns plan/actual, state (Planned/In progress/Done/Stopped), actions "Start" → "Done" → "Stop," and "Transfer remainder" (if the plan is not yet fully done).
• Unfinished assignments — shift assignments with a past date, not yet brought to done/canceled, with the same actions.
• Flagged assignments — the same card as "New assignments," but filtered by the "Flag" mark (VOGBIT-style "set aside for later").
• Unplanned work — a list of unplanned work items (basis + status: Draft → Approved → In progress → Done, or Canceled) with a creation form and, for approved/in-progress items, a form for adding shift assignments under them (place/shift/date/quantity/hours, with no link to a specific order or operation).
• Shifts — opening and closing shift instances by date (see below).

Quick assignment dialog (the "Include in plan" button): place (defaults to the operation's place), shift (optional), date, quantity (defaults to the whole open remainder) → creates the step's first shift assignment.

Remainder transfer dialog: pick the receiving assignment's date, then the receiving assignment itself from the list of unfinished assignments on that date, the quantity to transfer (no more than the source's remainder), and, optionally, hours and a reason. The transfer is applied immediately, with no intermediate approval.

"Shifts" tab: a list of shift instances for the selected date (place, shift, status — Scheduled/Open/Closed/Canceled). "Open" moves the shift into progress. "Close" first requests a preview: if there are assignments with unfinished remainders or open work sessions, a list of blocking assignments is shown instead of closing, with a "Transfer remainder" button on each and "Check again"; if there are no blockers, confirmation is requested and the shift is closed.

Typical scenarios

1. The dispatcher opens "New assignments" → sees by the readiness color what can and cannot be done (for example, "Set a shift" — the place does not work on the calendar that day) → "Include in plan" for a suitable date/place.
2. At the end of the day — "Assignments for the day" → moves finished ones to "Done," unfinished ones — "Transfer remainder" to tomorrow.
3. The foreman registers unplanned work (for example, an urgent tooling repair) → approves it → adds a shift assignment under it for a specific place and shift, without creating a production order.
4. At the end of a shift — the "Shifts" tab → "Close"; if the system finds unfinished assignments or unclosed work sessions, it deals with them first (transferring the remainder), then closes the shift on a repeat attempt.

Notes and limitations

• Both tabs showing pending steps ("New" and "Flagged") are strictly limited to the high/maximum accounting level — at the minimal and medium levels, steps never land here; they are managed with the bulk button on the Production schedule.
• A new shift assignment is rejected (409) if the place has an active issue lock (task_lock_days — there are overdue, unclosed assignments) or if dependency sequencing is on and the predecessor step is not yet finished.
• Unplanned work has no sequence check (depends_on) — this is intentional, it has no step graph of its own to check against.
• A remainder transfer is created already posted — there is no draft or approval stage for a transfer in the interface.

Detailed schedule

/detailed-schedule, permission detailed-schedule.view.

What you see

A graphical "place × week" grid, an alternative to the text-based inclusion flow from Work assignments, for assignments with a maximum accounting level:

• Place selector, "← week" / "week →" / "today" navigation, a date range — 7 days from the chosen start.
• Rows — steps (pending at this place + already scheduled at it within the current range): order, product, operation.
• Columns — the days in the range, each header showing the place's load percentage for that date (yellow >80%, red >100%).
• A cell at the intersection: empty → "+" (create the first assignment for that date), one assignment → shows the total quantity (color by status: green — all done, yellow — some in progress, gray — only planned, bright yellow — mixed statuses), several assignments → quantity (N).
• Clicking an empty cell or a cell with one assignment opens the add/edit form right away. Clicking a cell with several assignments first opens their list ("several assignments for one shift on one post" — for example, two performers on the same post in the same shift), from which one can be picked to edit or another added.
• Assignment form: place, shift, quantity, labor intensity in hours; only editable while the assignment is "Planned" — otherwise the fields are locked, and only viewing the actuals is available. "Finish work" (with confirmation) moves the assignment to "Stopped."

Typical scenarios

1. The foreman picks a place and the current week → sees by the load color which days are already tight → clicks an empty cell at the desired step/date → enters quantity and labor intensity.
2. Two performers need to be put on the same post/shift/day — the first assignment is created by clicking the empty cell, the second via "+ Another assignment" in the list of ones already on that cell.
3. An assignment is no longer needed (the order was reprioritized) — open it and click "Finish work."

Notes and limitations

• This is a graphical, not text-based, entry point into the same shift assignment API as Work assignments (POST /api/shift-tasks) — the same place-lock and sequencing constraints apply silently (an error from the server, no separate warning in the form).
• An assignment can only be edited in the "Planned" status — a started or finished assignment can only be viewed.
• The weekly range is fixed (7 days); there is no custom period.

Related sections

• Getting started — roles and permissions (scheduler.*, *.view for each of the five sections), the shared glossary of terms (WorkOrder, OrderOperationStep, Tman, POLCA/buffer/WIP limit).
• Dashboard & analytics — Production analytics uses the same WIP, constraint, and buffer data as dashboard widgets; the OEE/SPC/TPM metrics for places are computed from the same places and locks visible on the Dispatch board.
• Products & orders — Parts define the routing (operations, places, labor intensity) that gets exploded into steps on "Create assignments"; Orders and Order fulfillment are the source of the production orders that land on the Production schedule.
• Work & quality — Work intake/Shop floor terminal record actual completion (work records), which is reflected here as readiness % on the Production schedule and as "Completed" on the Dispatch board.
• Warehouse & supply — Supply availability/MRP is the source of the "Shortages" KPI in Flow management; material requests and warehouse-submission documents are created right from the Production schedule.
• Reference data & access — Reference data (places, shifts, the work calendar) is where the place/shift lists used in every form of this phase come from, and where the work calendar itself — the one "Readiness" relies on — is configured.