Reference data & access

Purpose

The Reference data menu group covers the whole reference/standards layer of the application: flat lists (units, places, shifts, part kinds, defect types), entities with their own form (employees, operators, equipment, tools), composite structures (routing templates, norm- calculation rules), and platform-core system mechanics that the application manages but that are not business logic (entity statuses/transitions, relation types). The activity log — a cross-cutting feed of events across the system — also lives here. Everything set up here is used as a selection source (a dropdown, a default) in the rest of the application: BOM and routing draw units and places from here, work intake draws employees, cost and MRP draw the K1/K2/K3 coefficients and norms.

This chapter does not cover signing in, the RBAC role table, or personal Settings (language/theme/navigation placement) — those are Getting started.

Who uses it (roles)

The whole menu item is gated by the admin.view permission — only the Administrator role holds it (see the roles table, Getting started). No other role sees the Reference data group at all (the group is hidden entirely if, after filtering by permissions, no item remains in it — the same mechanism as for other menu groups).

Reference lists used by other screens — units, places, shifts, part kinds, defect types, employees, equipment, tools, parameters and coefficients — can be read by signed-in operators. Editing them and opening their administration pages require admin.view. Operators, roles, statuses and relation types require administrative access even for reading. The activity log, default parameters, operation catalog, routing templates and norm rules require parts.view for reading. Seeing a selection list elsewhere does not grant permission to administer it.

Key concepts

• Flat reference (Dictionary) — a code and name. Five reference lists share this editing pattern.
• Status / transition — the platform (platform-core) entity-lifecycle mechanism: every entity type (Part, Production order, etc.) has a set of valid statuses and allowed transitions between them; here it can only be extended (adding a status/transition), not edited or deleted once created.
• Relation kind (RelationKind) — the platform reference of valid relation types between graph entities (for example, "consists of," "performed at"); view-only here — creating a new relation type with no code able to interpret it would accomplish nothing.
• K1/K2/K3 — correction coefficients inherited from the original VOGBIT (Getting started glossary): K1 — the conversion coefficient between units (this page), K2 — the operation coefficient (operation catalog/routing templates), K3 — the cost coefficient (Cost & prices).
• Norm rule (NormRule) — a versioned formula or table for computing material consumption or piece time; goes through the statuses draft → released (content is frozen) → archived.

Units / Places / Shifts / Part kinds / Defect types

Five reference lists use a code + name table, in-cell editing (double-click), a "+ New" button opening a dialog with the same two fields.

Notes and limitations:

• The Places reference has two extra fields the other four lack: "Working days" (numbers 1–7, Mon=1…Sun=7, comma-separated — used by the scheduler) and "Post capacity" (how many assignments a place can carry in parallel, the same meaning as the analogous field on Equipment). The other four hide these fields — the component is parameterized with showWorkingDays/showCapacity flags, enabled only for places.
• None of the five references has deletion from the interface — only creation and editing the code/name.
• Rows already in use elsewhere (for example, a unit referenced by a part) can still be edited — the platform does not check usage on PATCH.

Statuses

/admin/statuses. View the entity lifecycle and extend it by adding statuses and transitions.

What you see: an "Entity type" dropdown (Part, ProductionOrder, etc. — every type set up in platform-core), below it two tables — "Statuses" (code, name, "initial"/"final" flags) and "Transitions" (from status → to status, name), with a form for adding a new row under each.

Notes and limitations:

• Addition only: existing statuses and transitions cannot be deleted or renamed. Check that new statuses are reachable through the intended transitions.
• "From" in a transition can be left empty — meaning "from any status."

Relation types

/admin/relation-types. View-only: code, name, cardinality (one-to-one/one-to-many, etc.) for every platform-core graph relation type. There is deliberately no add form — a new relation type with no backend/frontend code able to use it (traverse()) would be "dead" and accomplish nothing.

Operators

/admin/operators. Sign-in accounts — login/password/role, separate from Employees (below). There is no equivalent screen in old VOGBIT — there, access was configured differently (per-user interface configurations, see "Notes" below); in Vyrab this is a separate section, new to the web version, built around RBAC roles (Getting started).

What you see: a "Login / Name / Employee / Permissions" table (permissions — either All permissions or the role's list of permission strings); a "+ New" button (visible only with admin.view, though the page itself is already accessible only to an administrator — the same double protection as everywhere: the backend returns 403 regardless of what the frontend shows).

Typical scenarios:

1. Create an operator: login, password, display name, role (required — an operator cannot be created without one), optionally an employee (for "own" timesheet, Work & quality). The employee list for linking shows only those not yet linked to any operator — one employee = one login, the same one cannot be picked twice.

Notes and limitations:

• There is neither editing nor deleting an operator from the interface — only creation. Changing an existing operator's role/password is not available here.
• The list of roles and the permissions themselves are inherited from the Getting started roles table — this screen does not edit them, only assigns an existing role to an operator.

Employees

/admin/employees. The reference of physical shop-floor workers (who actually did the work — WorkRecord.worker_ids), separate from Operators: the vast majority of employees never get a system login, and are instead picked from a list during work intake (Work & quality) and in the timesheet.

What you see: a "Name / Code / Status" table (Active/Archived), a "Show archived" checkbox, a "+ New" button.

Typical scenarios:

1. Set up an employee: name (required) and a short code (used for identification at the shop-floor terminal — scanning/typing a badge, GET /api/employees/lookup).
2. Archive someone who has left — an "Archive" button on the row; an archived employee drops out of selection in new submissions/QC marks, but their entire past history stays as-is. "Restore" brings them back.

Notes and limitations:

• Archiving is a data flag, not an entity status change: Employee has no status lifecycle of its own, unlike Parts and Orders.
• The code must be unique for badge identification — on a collision, lookup returns the first matching active employee; the system does not check this on save.

Conversion coefficients (K1)

/admin/coefficients. Corresponds to the TranslationCoefficients table in the original VOGBIT (support/446). A "Part / From unit / To unit / Coefficient" table.

What you see: a row with no part is the general default coefficient for a pair of units; a row with a specific part overrides it only for that part. An empty reference is not an error — the default K1 is treated as 1.

Typical scenarios:

1. Add a coefficient: pick a part (optional — via PartPicker), the source unit, the target unit, the coefficient value.

Notes and limitations:

• Used for more than display — it is read by MRP, cost, and the saw assignment, so an error in a value here will silently skew calculations across several other sections.
• The source/target unit and the part are real graph relations (created by one atomic command), not free text.

Equipment

/admin/equipment. A scheduler resource separate from Places — a specific machine, not a shop zone. A "Name / Capacity (parallel operations)" table, both cells editable in place.

Notes and limitations:

• "Capacity" is how many operations this equipment can carry at once (the same meaning as "Post capacity" on Places): 1 for a single machine, higher only if the resource is genuinely shared. Used by the scheduler (CumulativeConstraint, Production & planning).
• Neither deletion nor archiving is available from the interface.

Tools

/admin/tools. Corresponds to the tool reference from the original VOGBIT's "Detailed routing" (support/577) — used by routing transitions in the Parts editor ("Operations" tab, Products & orders) instead of free text. A flat "Name" list, in-cell editing, deletion via a row button (unlike most other references in this phase).

Parameters

/admin/parameters. The reference of clarifying parameters for operations/transitions/ materials in the routing editor (support/577 — "clarifying parameters"). A "Name / Value type" table (Text / Number / Range "from–to"), deletion via a button. The value type is set only at creation and does not change afterward.

Default parameter values

/admin/parameter-defaults. Three sets (Operation / Transition / Material) — which parameters from the reference above are auto-filled by the "Fill in parameters" button when editing a routing element of the corresponding type.

What you see: an element-type and parameter picker + a "+ Add to set" button; three lists below, one per element type, with a delete × on each row.

Notes and limitations: this is not the parameter values themselves, but the set — "which parameters to offer at all"; the actual value for a specific operation/transition/material is set in the routing editor (Parts, Products & orders), not here.

Operation catalog

/admin/operation-types. A library of standard operations with default norm values — the source for routing templates (below) and a quick-pick point when manually editing a part's routing.

What you see: a "Name / Place / Tman, h / Rate, ₽/h / K2" table — all five fields editable in-cell, the place picked from the Places reference. Deletion via a row button.

Notes and limitations: these are default values — when adding the operation to a specific routing or template, they can be overridden locally without touching the record in this reference.

Routing templates

/admin/routing-templates. Ready-made sets of operations (for example, "Standard routing for enclosure parts") that can be applied to a part in one action from the Parts editor (the /apply button, Products & orders), instead of assembling a routing from scratch every time.

What you see: a list of templates on the left, on the right the selected template's steps: № (sequence), Operation (from the operation catalog), Tman/Place/Rate (shown in gray, "from the type," if not overridden), batch quantity, reorder buttons (↑/↓) and a delete button.

Typical scenarios:

1. Create a template — a name only.
2. Add a step — pick an operation from the operation catalog (required) and a sequence number; Tman/place/rate/K2 are pulled from the catalog and can be overridden right in the table after adding.

Notes and limitations: reordering steps (↑/↓) swaps the sequence values of two adjacent rows rather than using a separate order field.

Consumption and time norms

/admin/norm-rules. Corresponds to the original VOGBIT's "Norming tables" (support/576): versioned formulas or tables for computing material consumption or piece time, using the same safe expression interpreter as the Generator's formulas (Products & orders).

What you see: a list of norms on the left (Norm / Type "Formula"/ "Table" / Status "Draft"/"Released"/"Archived" / Scope), on the right a card for the selected norm: name, type, expression (for a formula) or a table of rows "Parameter / From / To / Result" (for a table), the result unit, scope, comment; below it a "Test calculation" block (a calculator: enter variable values → get a result with nothing saved) and "Calculation history" (if the norm has already been applied).

Typical scenarios:

1. Create a norm: name, type (Formula/Table), for a formula, the expression right away (for example, length * width * thickness * density), the result unit, scope. For a table, rows are added separately after creation.
2. Publish (move to "Released") — after confirming a dialog; the content (the formula or table rows) becomes immutable.
3. Send to archive — available from "Released" status.
4. Test the calculation before publishing — enter "variable = value" pairs, click "Calculate."

Notes and limitations:

• The content (expression, table rows, formula/table type) can only be edited while the norm is in "Draft" status; a released norm cannot be changed — a correction is issued as a new norm, so that already-completed calculations remain reproducible. The type (formula/table) can never be changed after creation.
• Only a draft can be deleted from the interface.
• Applying a norm to a specific operation/material of a part (/apply) is fully supported by the API, but the routing editor's interface (Parts, Products & orders) deliberately does not wire up buttons for it — this page only has "Test calculation" as a standalone calculator and a view of the history of applications already made.

Activity log

/activity. A chronological feed of events across the system — a section new to Vyrab, with no direct equivalent in the original VOGBIT.

What you see: a vertical feed of cards — a colored action icon, an action label, a link to the object (opens it in the object inspector, Getting started), who did it, when (relative time, with the exact time in a tooltip), and a short comment where present. At the top — filter chips by action type and a "Refresh" button.

Notes and limitations:

• In practice, only three event types are currently written to the log, all three for Parts: creating a part, releasing a part, creating a new revision. Other sections (orders, work intake, warehouse, etc.) do not yet write to the log — the interface is built generically (an arbitrary entity_kind/action), but it is only populated wherever log_action is called.
• The permission to read the log is parts.view, not admin.view — stricter than most read-open references in this phase, but not the same permission that gates the page itself in the menu (admin.view) — in practice only administrators end up there anyway, since the menu item is hidden for everyone else.

Not carried over from the original VOGBIT

Two administration sections from old VOGBIT do not exist in Vyrab as a category — not "not yet built," but replaced by a different system design:

• Workstation configurations (support/474 — turning tabs and configuration modes on/off per individual user, "attached forms"). In Vyrab access is built around RBAC roles (Getting started) — permissions are granted to a role as a whole, not configured by hand per tab per user.
• Report templates (support/459 — uploading your own Excel templates (*.xlsx) via Administration → Report templates for printing documents). Vyrab has no such reference at all — Excel export, where it exists (for example, an export button on some tables), is generated directly by code, with no user templates.

Related sections

• Getting started — roles and permissions (the roles table, the admin.view permission), personal Settings, the object inspector (opening an object from the Activity log).
• Production & planning — Places/Equipment/Shifts as scheduler resources (Dispatch, Production schedule).
• Products & orders — Parts uses Units, Part kinds, Parameters, Tools, the Operation catalog, Routing templates, and Norm rules directly in the routing editor.
• Work & quality — Employees and Shifts — picking a performer and a shift during work intake; Defect types — recording defects.
• Warehouse & supply — K1 coefficients in the MRP calculation.
• Cost & prices — Coefficients and the Operation catalog (Tman, rate, K2) in the cost calculation.