Products & orders

Purpose

This chapter covers the data around which all of production is built: what we make (Parts — parts, assemblies, materials, their composition and routing) and for whom/how much we make it (Orders, Order fulfillment, Contracts).

• Parts (/parts, permission parts.view) — the reference catalog of parts, assemblies, materials, and purchased items. A single item's card has up to eight tabs: properties, product composition (BOM), routing, configurator, price, files, versions, history; separately, the Generator dialog and Excel import.
• Orders (/orders, permission orders.view) — an internal production order to manufacture a batch of a product: what, how much, by what deadline. This is where an order is "exploded" into concrete items and shop-floor operations (see Production & planning for the execution itself — Dispatch and the Production schedule).
• Order fulfillment (in the menu — "Order fulfillment," /customer-orders, permission customer-orders.view) and Contracts (in the menu — "Contracts," /contracts, permission contracts.view) — the commercial layer on top of production: what has been promised to whom, how it is covered by warehouse/production/purchasing, and how it is shipped. These two sections do not exist in the legacy VOGBIT product — they were written from scratch for Vyrab, and below they are described purely from the code, with no references to the support site.

Who uses it (roles)

An important point about permissions in this phase: each section has one permission for the whole section, not separate view/edit ones. For example, parts.view allows not only seeing the parts catalog but also editing composition, routing, the configurator, and generating products; orders.view allows not only seeing orders but also creating them, launching them into production, changing statuses, and assigning performers; the same goes for customer-orders.view and contracts.view. There is no narrower "edit parts only" or "launch orders only" permission in the system.

Key concepts

---

Parts

Parts list

What you see. A table (/parts) with a filter: Name, Kind (kind), Unit, Article, K1 (default coefficient), Version, Status. The "+ New" button opens the creation form; the "Import from Excel" button (visible only with admin.view) opens the bulk-upload dialog.

Typical scenarios.

• Quick edit: double-clicking the Name/Unit/Article/K1 cell saves the value right away, without opening the form.
• Creating a new item: Name, Kind (the parts-kind reference), Unit (the units reference — choosing it on the form also writes unit_id; the string unit field remains for backward compatibility), Article, "Default K1," "Min. reserve," "Loss factor" (1 — no extra losses), and, for the "assembly" kind only, a "Configurable product (Configurator)" checkbox — turns on is_configurable and, with it, access to the Configuration tab and the Generator button on the card.
• Clicking a row opens the part's card in the object inspector.

Notes and limitations. Kind and Status are deliberately not editable by double-click in the table: Kind is a fixed list of values, Status changes only through explicit transitions (Release/New version) on the card. Article uniqueness is checked only against matches found by the platform's text search — the best check the platform API currently offers, but not a strict guarantee against a race between two simultaneous saves.

Properties and version lifecycle

What you see. A header with the name, version (v...), a status badge, and action buttons: Edit, Clone, Generator (only if the product is configurable), Release (draft/active only), New version (released only). Below is a field card: Kind, Unit, Article, Default K1, Warehouse balance, Status, Created by, Released by, Created/Modified.

Typical scenarios.

• Clone — creates an independent copy (new Name and Article) with a one-level-deep copy of the composition and the routing; further edits to the clone do not affect the original.
• Release — moves a draft/active version to "Released," records released_by.
• New version — available only for a released version; creates a draft with a copy of the composition and routing; the version designation is set manually (for example, "B," "2," "1.1"); the previous version stays released and available for comparison on the Versions tab.

Notes and limitations. The composition and routing of a released version are read-only (the server rejects an edit attempt with 409) — this is the only way to protect a routing that is already being shipped/ produced from accidental changes; further work requires explicitly creating a new version.

Product composition (BOM)

What you see. A table of composition rows: Position, Component (a link to another parts-catalog item), Kind, Qty, Unit, Operation (if the row is tied to one of this same part's operations — for a K2/per-batch consumption norm), Per batch (yes/no), a "Generator" column (shows the quantity formula and/or a "repeating" mark), "Substitutes" and "Condition" buttons on each row.

Typical scenarios.

• Adding a component: search by name/article, quantity, unit, position; optionally, a link to an operation and a "per batch" checkbox; an additional "Generator" block (expanded by a button) — a quantity formula (for example, n*2) and/or a numeric configuration parameter that determines the number of repeated instances of the row.
• "Substitutes" — opens the list of alternative components for this row: search for a substitute by name/article, a quantity conversion factor, a comment (for example, "out of stock at the supplier"). A row can have several substitutes.
• "Condition" — opens the condition editor (AND/OR/exclusive OR, with support for nested groups): the row is included in the composition/order only if the condition is true — based on a configuration parameter's value, a numeric parameter's range, or whether another composition row is present. Without a condition, the row is always included.

Notes and limitations. A released version's composition is read-only (see above). The "Substitutes" dialog, unlike the rest of the BOM, is not locked for a released version — substitute components can be changed even on a released part.

Routing

What you see. A tree-table of the routing (operations — green background; transitions — blue background; materials; on assemblies, also "components," borrowed from that same part's own composition): №, Operation/Transition/Material, Place, Equipment/Tooling (plus an expandable "Possible posts" list — alternative equipment beyond the primary one), Setup time (h), Piece time (h), Qty, Unit/Warehouse. Toolbar: Print routing card, save to Excel, "Template" (apply a routing template — visible only if at least one template exists), "Copy from part" (bring over operations/transitions/materials from another item), "Check routing" (a list of remarks, clicking one jumps to the operation), "Collapse/Expand all."

Typical scenarios.

• In-place editing: double-click any cell; Enter — save, Escape — cancel. Values inherited from a routing template are shown in italics with a "✕ reset" button next to them, which restores the value from the template; an operation tied to a template is marked with an icon and "Update from template" / "Break link" buttons.
• Adding an operation: from the operation-type reference (auto-fills the name, piece time, place, rate, K2) or manually; additional fields — setup time, № (sequence), rate, K2, batch quantity, equipment.
• Adding a transition (+T) — work content and tooling (from the reference or as free text); adding a material (+M) — consumption norm, norming unit (per part/per batch/per m²/per m³), loss percentage. On assemblies a +C button is available — add a component right from the part's own bill of materials.
• Drag-and-drop reorders operations or moves a transition/material to another operation — DnD accounts for the fact that components are not reorderable (they have no sequence field).
• Each row has comment (💬) and "Parameters" (⚙, unlimited custom clarifying fields — for example, blank dimensions or a machining mode) buttons.

Notes and limitations. Editing the routing of a released version is unavailable for the same reason as the BOM. There is no separate "edit routing" permission — it is governed by the same parts.view.

Configuration

The tab is visible only for assemblies (kind === "assembly").

What you see. A list of configuration parameter cards: name, code (Latin letters — for use in formulas), value type ("list choice," "number," "yes/no"), a formula, if set. For "list choice" parameters — a list of values with labels and a form for adding new ones. A "+ Parameter" button.

Typical scenarios. Set up a parameter (for example, "Length," type "number," min./max. value) or a list parameter (for example, "Configuration" — "Standard"/"Deluxe"); a parameter with a formula (for example, Round(a*b, 2)) is computed automatically and is not asked of the user. These parameters are then used in two other places: in conditions on composition rows (the Product composition tab) and in the Generator wizard.

Notes and limitations. The condition logic itself is not edited here but on the Product composition tab ("Condition" on a row) — the Configuration tab only manages the definition of parameters and their values. Not editable on a released version.

Generator

The "Generator" button on the Properties tab is visible only for configurable products (is_configurable); it opens a modal wizard.

What you see. An optional folder choice for the new parts/assemblies; below, a live tree preview, recomputed on every change of the answers: the template's name, fields for parameters not yet filled in (number/choice/yes-no, respecting min./max.), nested groups for repeating rows and nested templates (labeled "(N pcs.)"). The "Generate" button is active only once every exposed tree parameter is filled in.

Typical scenarios. After generation — a result screen: a list of the created items (Name/Designation) and a bulk designation-assignment tool — a mode ("Unique code," "Prefix + code," "Prefix + sequential number"), a prefix, an "Assign designations" button; designations can also be entered manually, row by row.

Notes and limitations. The preview saves nothing — real parts/ assemblies are created only on clicking "Generate." A template nested inside a template produces its own new part (not shared with the original); a repeating composition row creates as many instances as the linked numeric configuration parameter specifies (see the Product composition tab).

Price

What you see. A price history table: Effective from, Price, K3, Supplier. A form to add a record: date (defaults to today), price (required), K3 (defaults to 1), supplier.

Typical scenarios. When a new purchase (or a new sale) price is received, add a record with the effective start date; the lookup of the current price for Cost (Cost & prices) uses the latest record with valid_from no later than the current date.

Notes and limitations. The history is append-only — there is no editing or deleting records from this tab. The three similar-looking coefficients are actually stored in three different places: K1 — on the part itself (the Properties tab, "Default K1"), K2 — on the operation (the Routing tab), K3 — here, on the price record.

Files

What you see. A single "Files" tab with two columns: on the left, a flat list of all attachments (icon/thumbnail, file name, size, 📌 "Make primary" and ✕ "Delete" buttons); on the right, a preview area for the selected file. There are no separate "Images" and "Drawings" tabs in the interface — everything is shown in one list, and the type is determined automatically by extension/MIME type.

Typical scenarios.

• An image opens in full in the preview area.
• A .dxf drawing opens right in the browser: pan by holding the left mouse button, zoom with the wheel; lines, circles, arcs, polylines, ellipses, splines, and text are supported, colors by AutoCAD color index (ACI) or RGB.
• A 3D model — .stl/.obj/.gltf/.glb/.ply open directly, while .step/.stp/.iges/.igs/.brep/.brp go through the built-in CAD converter; rotate with the left mouse button, zoom with the wheel, pan with the right mouse button.
• Any other file (PDF, document, archive) — an icon by type and an "Open" button.
• 📌 "Make primary" pins the file as the part's cover — it moves to the top of the list and is selected by default the next time the tab is opened.

Notes and limitations. The "primary" mark is stored in the operator's browser (localStorage), not on the server — different operators on different computers may see it differently. Of the drawing formats, only .dxf is recognized; .dwg files are shown with a plain icon, no preview.

Versions

What you see. A vertical timeline of the revision chain (by the previous_revision_id field): the current version is marked with a filled dot and a "current" label, the rest with hollow dots. Each card shows the version designation, status, "Created by"/"Released by," modification date.

Typical scenarios. Clicking any other (non-current) version opens its own card in the object inspector — handy for comparing a draft against a previously released version or returning to an old revision.

Notes and limitations. The tab is entirely read-only — versions are created only by the "New version" action on the Properties tab.

History

What you see. A feed of actions on this parts-catalog item: creation, version release, new-version creation (each type has its own color and icon), who performed the action and when (relative time: "just now," "N min. ago," an exact date once older than a week).

Notes and limitations. This is an activity log (who did what and when), not a revision chain — the version composition is tracked separately, on the Versions tab. Entirely read-only.

Importing parts and BOM from Excel

The "Import from Excel" button on the parts list is visible only with admin.view.

What you see. An explanation of the expected columns (row 1: article, name, unit, kind, default_k1, parent_article, qty, position), an .xlsx file picker, and after upload, a full report: number of rows, created, updated, and a row-by-row list of errors (not just a count).

Typical scenarios. Bulk-loading a parts catalog and/or BOM from a prepared spreadsheet: existing items are updated by matching the article code; if a row has parent_article set, the same row is additionally added as a BOM component of the specified parent.

Notes and limitations. The error report is shown in full, not collapsed into "N updated" — an error in one row (for example, a typo in parent_article) needs to be visible immediately, not discovered three weeks later as a missing composition component. The format differs from the legacy VOGBIT specification-import format (which used one Excel file per assembly, with columns like "Section"/"Designation"/"Material"); ready-made export files from the old VOGBIT will not work directly with this import.

---

Orders

An internal production order — "what and how much to manufacture." Section /orders, permission orders.view.

Orders list

What you see. A table with a filter: Order # (editable in place), Product, Qty, Start and Deadline (dates, editable in place), Priority (number, editable in place), Status (a badge; the status changes only through transitions on the order's card, not by typing text).

Typical scenarios. The "+ New order" button opens the creation dialog; clicking a row opens the order's card in the object inspector.

Creating an order

What you see. A product search by name/article (autocomplete), the order number, quantity, start/deadline dates, priority (for scheduling). If the chosen product is configurable — a "Configuration" block: dropdown lists for each parameter and a "Show composition" button (a preview of the included rows, without saving).

Notes and limitations. The order is created immediately in "Draft" status with not a single item/operation — exploding the composition (BOM → items, routing → steps) happens only through the explicit "Create assignments" action on the order's card, not at creation time. Configuration-choice validation is likewise deferred until launch: a draft can be left with parameter values unset. Quantity and product are not editable after creation — the order is either split or created again.

Order card

What you see. A header: number, status badge, an "Important" mark (if set), a "Product · Quantity" line, and, if linked to a customer order, a brief summary of the customer. Summary metrics: Deadline (with a hint about being overdue/approaching), Start, Priority, a readiness bar (% of quantity submitted across all operations).

The main header action depends on status:

• Draft → "Create assignments" — explodes the composition/routing into concrete items (WorkOrder) and steps (OrderOperationStep), moves to "Planning."
• Planning → "In production."
• In production → "Done."
• No button for "Done"/"Canceled."

The "Other actions" menu: "Delete assignments" (only in "Planning" status — rolls the order back to "Draft" and deletes all items/steps), "Work sequence" (a graph, see below), transition to "Canceled."

Four tabs:

• Overview — a "Customer order" block (customer, customer order number, contract, ordered/allocated/in-production quantity, promised date — or, if there is no link to a specific customer order, just the contract with an explanation that composition and quantity cannot be determined); a "Needs attention" block (a missed deadline, operations with no performer assigned); a brief summary of the routing items and, if there are materials with no operations, a banner linking to the Materials tab.
• Route — expandable item (WorkOrder) cards with their operations (OrderOperationStep): operation status (Pending/In progress/Done), a performer picker from the list of active employees, a status-transition button, an actions menu on the operation — "Dependencies," "QC" (unavailable until something has been submitted for the operation), "Submissions" (a submission log), "Open assignment" (PDF); a separate "Accounting level" selector on the operation (Same as order/Minimal/ Medium/High/Maximum — affects only the set of columns on the Production schedule, not any business logic). The item's menu has print forms: "Routing sheet," "Label," "Saw assignment."
• Materials — order items with no production operations (pure materials/components).
• Details — created/modified, the order's accounting level, batch number, position, comment, chosen configuration values.

Notes and limitations. The "Draft → Planning" transition is available only via "Create assignments" (a full explosion), not as an ordinary status transition; "Delete assignments" works only while no operation has been touched yet (otherwise the server rejects the request) — the frontend does not pre-check this, the button is always present in "Planning" status. The backend has order splitting into several items (split, draft only), but there is no dedicated button for it in the order list or card — it appears to be available from the Production schedule screens (Production & planning).

Work sequence (graph)

What you see. A full-screen graph of all the order's operations (all items at once, node border color by item/product name, to distinguish operations of different items from one another), with automatic top-down layout. Existing dependencies are arrows between operations.

Typical scenarios. Dragging from one operation to another adds a dependency ("this one not before that one"); clicking an arrow, with confirmation, removes it.

Notes and limitations. The graph works only within a single order — all nodes come from its own items. A dependency between operations of different orders needs a separate dialog, see below.

Step dependencies

What you see. A list of the operation's current dependencies (order · product · operation, with a "Remove" button) and a cascading form for adding a new one: pick an order → an item → an operation (the order list is not limited to the current one and is not filtered by status).

Typical scenarios. State "the assembly cannot start before a part from another order is ready" — something the sequence graph cannot do, since it is limited to one order.

---

Order fulfillment

In the menu and on the page itself, the section is called "Order fulfillment" (/customer-orders, permission customer-orders.view); in the documentation and database, the entity is called "customer order" (CustomerOrder). There is no section with the same name and purpose in legacy VOGBIT — this is a new "sold → covered → shipped" layer on top of production.

The screen is a list on the left (order number, customer, status) and an order panel on the right, with no navigation through the shared object inspector. The "+ New order" button opens a form: order number, customer (picked from the reference list, with a quick add-new-customer option right in this form), an optional contract (the field hides and is replaced with a static label if the order is created from a contract's card — in that case the link is preset and not editable).

Statuses and transitions

Only two transitions are available through interface buttons: "Draft → Confirmed" and "→ Canceled" (from draft or confirmed). Every status to the right of "Confirmed" is purely automatic — the system advances the order through the chain confirmed → in_fulfillment → ready → partially_shipped → shipped only as a side effect of posting a shipment, depending on the ratio of shipped to ordered quantity. There is no separate "mark ready to ship" button in the interface.

Order lines

What you see. A table of lines: Part, Qty, Price, Shipment deadline, Shortfall (how much is still not covered by fulfillment), Risk ("Overdue" — red, if the promised date has already passed; "Deadline soon" — orange, if no more than 3 days remain until the deadline and there is still an unshipped remainder), a "Delete" button on the line. Lines can be added and removed only while the order is in "Draft" status — once confirmed, a line's quantity and part cannot be changed from this screen (by design: that requires a separate order version/amendment, which is not yet implemented).

Clicking a line opens the fulfillment panel for it.

Line fulfillment and reservations

Clicking a line expands two independent blocks — they are deliberately not reconciled against each other.

Fulfillment (FulfillmentAllocation) — the planned source of coverage: warehouse, production, or purchasing. For a "production"/"purchasing" source, the ID of the corresponding production order/supplier order must be entered manually (there is no search-and-suggest for this yet — the ID is typed in by hand). Statuses: Planned, Active, Fulfilled, Canceled. Important: linking a customer order line to production is entirely manual and informational: nothing in the system automatically creates a production order or links it to the line by itself.

Reservations (StockReservation) — a soft reservation of a quantity of goods, which can then be "pinned" to a specific batch (picked from the list of available batches with a balance) — once pinned, a reservation can only be released or canceled, not unpinned back from the batch. Statuses: Active, Used, Released, Canceled. The system does not allow reserving more against one batch than that batch's actual free balance (accounting for already-existing active reservations).

Shipments

What you see. A list of the order's shipments (№, status) and a panel for the selected shipment: lines (Part, Qty), a "Download waybill" button (always available, including for a draft — as a preliminary picking list), and, draft only, "Post" and "Cancel" buttons.

Typical scenarios. A new shipment is created by entering an arbitrary number. A shipment line is added by picking an order line, and then a reservation of that line that has already been pinned to a batch; there is no separate quantity field — it always equals the quantity of the chosen reservation (the system has no auto-selection of a batch by FIFO/LIFO at this step — only an explicitly pinned reservation). So the path to a shipment is strictly sequential: order line → fulfillment (optional) → reservation → pinning the reservation to a batch → shipment → shipment line → "Post."

Post — a confirming dialog ("A warehouse issue order will be created and posted"); an irreversible action: it creates and posts a warehouse issue order (deduction mode — exactly from the chosen batch, not FIFO/LIFO), moves the consumed reservations to "Used," the shipment itself to "Posted," and recomputes the parent customer order's status (see above).

Notes and limitations. A line for which no reservation has been created and pinned to a batch cannot be shipped — this is the only way to deduct goods in this section.

Deadline risks

Overdue order lines and ones approaching their deadline (within 3 days) are highlighted right in the lines table (see above) and are separately aggregated in the "Customer orders: deadline risk" dashboard widget (Dashboard & analytics) — across all of the company's open orders at once, with no drill-down to a specific line.

---

Contracts

In the menu and on the page, the section is called "Contracts" (/contracts, permission contracts.view); in the documentation — "Contract" (Contract). Like Order fulfillment, there is no section with a direct equivalent in legacy VOGBIT.

List and creation

What you see. A table: Contract #, Customer, Status (a badge). The "+ New contract" button opens a form: number, customer (picked from the reference list, with a quick add-new-customer option right in the form).

Contract card

What you see. Number, customer, status, creation/modification dates. Status transition buttons:

Two independent tables of child documents:

• Production orders — orders (from the "Orders" phase covered above) linked to the contract directly: order #, product, quantity, readiness (%), status. The "+ Production order" button opens the same order creation dialog as in the Orders section, with the link to this contract preset and locked.
• Customer orders (fulfillment) — customer orders linked to this contract: order #, status. The "+ Customer order" button opens the customer order creation form with the contract preset.

Notes and limitations. A contract has no lines, amounts, or delivery schedule of its own — it is only a commercial header with a number, a customer, and a status; all the substantive information ("what and how much") lives a level below — either in production orders (what we are manufacturing) or in customer order lines (what and when has been promised to the customer). A customer order can exist with no contract at all — the link is always optional.

---

Related sections

• Production & planning (Flow management, Dispatch, Production schedule, Work assignments, Detailed schedule) — what happens to an order's items and steps after "Create assignments": queue, buffers, publishing the schedule, actual execution on the shop floor.
• Work & quality (Work intake, Shop floor terminal, QC/Defects, Timesheet) — submitting quantity against order routing steps, quality acceptance ("QC" on the order card), the submission log.
• Warehouse & supply (Warehouse, MRP, Supply availability, Arrivals) — the batches and balances that Reservations and Fulfillment for customer orders rely on; purchasing, which the "Purchasing" fulfillment source refers to.
• Cost & prices (Cost, Price list) — uses the Price tab's records (K3) and K1/K2 from parts/routing to compute cost.
• Reference data & access (Reference data) — operation types, routing templates, equipment, tools, units, part kinds — everything that populates the dropdown lists on the Routing tab and in the parts form.