Skip to main content
A ’s documents — its bill of materials and its cost sheet — are living records that change over time and are shared across many orders. This page explains how they are structured, how versioning keeps shared work safe, and how the approval and copy flows let the documents move forward without disturbing work already in flight. This is the canonical page for the versioning model and the approval flows. The style-centric model summarizes and links here; the BOM page and Cost Sheet page are the object references.

​
The mental model

A style is the reusable product record. Its BOM and its cost sheet are not single documents — they are sequences of numbered revisions. Every meaningful change saves as a new revision, and the previous one is preserved exactly as it was. Each order that runs the style works against one specific revision, so the style can keep evolving while every order continues to read the version it was built on. Three ideas carry the model:
  • A version is a numbered, saved revision of a single style document at a point in time.
  • Each order keeps its own pin onto the version it is working from, so a change made for one order does not pull the rug out from another.
  • Approval is the signal downstream work waits for. Approval marks a version as final for the order it belongs to and opens the gates to purchasing, the readiness engine, and production.

​
The BOM in business terms

A style’s is the definitive per-piece list of what the style is made from — its fabrics, its accessories (zippers, buttons, labels, hang tags, and the like), and the other components that make up one finished piece. Each line records what the material is, where it sits on the garment, the unit and per-piece usage, the supplier the line will be sourced from, the line’s , and a short procurement note. The BOM is the single material spine that purchasing, costing, and the readiness engine all read from. The full object reference is the BOM page.

​
The cost sheet in business terms

The is the money side of the same material picture — a per-piece price build-up with two parallel columns: the factory cost on one side, the customer-quoted price on the other, and the margin between them. Lines are typically seeded from the BOM (see “Copy from BOM” below), and a per-line customer multiplier keeps the customer side in step with the factory side as the build-up evolves. The cost sheet is what feeds the price you quote a customer, and it is what the style’s cost analysis view reads to project margin. The full object reference is the Cost Sheet page.

​
What an artifact version is

An is a numbered, saved revision of a single style document. The same model applies to every document a style owns — BOM, cost sheet, and the other style-owned artifacts — so the behavior you learn on one tab works on all of them.
  • Numbers are per style and per document. The BOM’s version numbers run on their own sequence (1, 2, 3, …), and the cost sheet’s numbers run on another. The next version of a document is always one more than the previous one.
  • One version is the current version at a time. When you mint a new version, it becomes the current one; the previously current version is preserved with its values intact and is still openable, but it loses the “current” flag.
  • Older versions stay readable. A revision does not overwrite the previous one; it sits beside it in history.
You see the version list on the style’s BOM tab and Cost tab — each shows the version timeline and which one is current — and inside an order’s view of the style, where the order shows the version it is working from.

​
How a shared style stays safe across orders: the per-order pin

A single style can run on many at once — a spring order shipping now, an autumn reorder being costed, a later season being prepared. Each of those orders needs to work from its own version of the style’s BOM and cost sheet, and a change made for one must not silently change another. That is what the per-order pin does.
  • When a new version of a BOM or cost sheet is created from inside an order’s context, the version is tied to that order and the order’s pin moves to it. Other orders on the same style are not touched — their pins stay where they were.
  • Marking a different version as current from the style’s surface moves the matching order’s pin in step.
  • A version that is not tied to any order is a style-level version — visible on the style but not bound to a specific order’s chain.
The pin is what makes “share one style across many orders” safe in practice. Two orders on the same style each read their own pinned version; revisions made for one order’s chain do not show up in another’s.

​
The BOM’s approval flow

A BOM version is in one of two states: Draft or Approved.
  • A new version is created as Draft.
  • Approval is per version, per order — approving order A’s BOM version does not approve order B’s, even when both orders share the same style.
  • Approval is performed by a user with BOM-approval permission.
  • A version that is already approved cannot be approved again; the action does nothing extra.

​
What approval freezes

On approval, the BOM captures a small snapshot on each line — the supplier’s name, the line’s item identity, the lead time, and the moment the approval happened. The snapshot is taken from the live master records at the moment of approval, so a later edit to a supplier or master record does not change what the order was approved against. The line’s working content remains editable on the style surface, but the snapshot stays as it was at sign-off.

​
What approval opens downstream

The BOM’s approved status is the signal that downstream work has been waiting for:
  • Purchasing reads the approved BOM when raising purchase orders for the style’s materials.
  • The readiness engine treats the BOM as approved when evaluating the gates that depend on a settled material list.
  • The first approval on a BOM advances the linked order out of its post-order-received phase into the procurement phase, so the production pipeline can start.

​
Withdrawing approval

A user with BOM-approval permission may also revert an approved BOM version back to Draft. The action is recorded, but it does not rewind work that already followed from the approval — a purchase order already raised remains, and the order’s phase advance is not undone. To change values once a BOM has been approved and used, the canonical path is to open a new version, edit it, and approve that one; the prior approval and its snapshot stay on file as the audit trail for what earlier orders ran on.

​
The cost sheet’s approval flow

A cost-sheet version is in one of three visible states: Draft, Partially approved, or Approved. Cost-sheet approval is per audience, not a single document sign-off. The audiences are typically the factory, the customer, and an internal audience — your administrator configures which are enabled for your tenant, and at least one must be enabled to create a new cost-sheet version. The header status is derived from the per-audience approval rows; you do not set it directly:
  • Any audience rejected → the sheet is back in Draft.
  • Every enabled audience approved → the sheet is Approved.
  • At least one approved and the rest still pending → Partially approved.
  • Otherwise (all pending) → Draft.
This is why a single rejection — for example, the factory pushing back on the cost build-up — moves the whole sheet back to Draft regardless of how many other approvals stand. Once an audience that was rejected is approved again, the rejection record is cleared on that row and the header status is re-derived. Edits to the cost sheet are restricted to Draft. Once the sheet leaves Draft, every header and line write is refused with a “draft only” message; the path to change a value is to mint a new version. Per-audience approval is gated by cost-sheet approval permission, not by which audience is being approved — the customer audience is not restricted to sales users, and the internal audience is not restricted to finance users.

​
Copy from BOM: how the cost sheet starts from the material list

The cost sheet’s line list does not need to be retyped. From a Draft cost sheet, Copy from BOM seeds the sheet with one cost line per eligible BOM line.
  • Only fabric and accessory BOM lines are seeded; the cost sheet’s CM (cut-and-make) and miscellaneous amounts live as per-sheet add-ons on the header, not as copied lines.
  • Each seeded cost line takes its own copies of the BOM line’s material identity, position, supplier, unit, and per-piece usage — the cost line is the source of truth for those values from that moment on. A later change to the BOM, the fabric master, or the accessory master does not alter what the cost line says.
  • Copy from BOM does not require the BOM to be approved; it copies from the style’s current BOM regardless of status. The action is refused only when the style has no current BOM.
  • Re-running Copy from BOM on the same Draft sheet does not duplicate lines that were already copied. It picks up only the BOM lines added since the previous run.
The same principle applies inside the cost-sheet header: once a sheet reaches Approved, its values are locked from further edit. To change a value, mint a new version and edit that.

​
The three layers of “lock”

Readers often ask, “what locks a cost-sheet value?” The answer has three plain layers, and each handles a different concern:
  1. Values lock on the cost line at Copy from BOM. Once a BOM line has been copied, the cost line carries its own values; the BOM, fabric, or accessory master can change without disturbing the cost line.
  2. Approved locks the whole document from edit. Once every enabled audience has approved, the cost sheet is locked from further edits. To change a value, mint a new version.
  3. The per-order pin locks the version to the order. The order works from the version its pin points at; later versions on the style do not silently take over the order’s costing.
The BOM has the same shape, simplified: the snapshot on each line is the per-line lock, the Approved status is the document-level lock, and the per-order pin is what ties the approved BOM to the order it was approved for.

​
Why versioning exists: many orders, one style

The point of the model is to let one style serve many orders without collisions. A working example:
  • A spring order is in production on the jacket style’s BOM version 1 and cost-sheet version 1 — both approved for that order.
  • The same style is reordered for autumn, with a swap of one accessory. The merchandiser opens a new BOM version (version 2) from inside the autumn order; only the autumn order’s pin moves. The spring order keeps reading version 1, undisturbed.
  • The autumn cost sheet is updated to reflect the swap; a new cost-sheet version is minted and approved per audience as each side signs off.
  • Months later, a third season runs again. The team opens the style, picks the version each order should work from, and the work proceeds.
One shared style. Three orders. Each order pinned to the version it was built on. Every earlier revision intact for the order it serves.

​
Where you encounter the model

  • On the style’s BOM tab — the version timeline, the current version marker, the approve and revert actions, the per-line snapshot on approved versions, and the option to open a new version.
  • On the style’s Cost tab — the version timeline, the audience approval rows, the per-audience status, the Copy from BOM action, and the audience-tailored export.
  • Inside an order’s view of the style — the version of the BOM and cost sheet that order is pinned to, and the actions the order team uses to advance the pin.
  • In downstream gates — purchasing and the readiness engine resolve the per-order version through the style’s pins, so they see the version the order is working from rather than the latest one on the style.