> ## Documentation Index
> Fetch the complete documentation index at: https://docs.garmentflow.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# BOM, cost sheet, and artifact versions

> How a style's documents are versioned, approved, and pinned to the orders that run them — the safety guarantee behind one style serving many orders.

A <Tooltip tip="The reusable product record that owns the BOM, cost sheet, and manufacturing orders.">[style](/reference/glossary#style)</Tooltip>'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](/concepts/style-centric-model) summarizes and links
here; the [BOM page](/modules/bom) and [Cost Sheet page](/modules/cost-sheet)
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 <Tooltip tip="The bill of materials — the list of fabrics and trims a style is made from.">[BOM](/reference/glossary#bom-bill-of-materials)</Tooltip>
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
<Tooltip tip="A specific color or color combination that a style is produced in.">[colorways](/reference/glossary#colorway)</Tooltip>,
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](/modules/bom).

## The cost sheet in business terms

The <Tooltip tip="The costing breakdown for a style, used for quoting and margin analysis.">[cost sheet](/reference/glossary#cost-sheet)</Tooltip>
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](/modules/cost-sheet).

## What an artifact version is

An <Tooltip tip="A saved, numbered revision of a style document such as a BOM or cost sheet.">[artifact version](/reference/glossary#artifact-version)</Tooltip>
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
<Tooltip tip="A customer's commitment to buy specific styles, colorways, and quantities to ship by a given date.">[orders](/reference/glossary#order)</Tooltip>
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](/concepts/readiness-engine-and-ai) 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](/concepts/readiness-engine-and-ai) 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.

## Related concepts

* [The style-centric model](/concepts/style-centric-model)
* [Style vs. order vs. MO](/concepts/style-vs-order-vs-mo)
* [Order lifecycle](/concepts/order-lifecycle)
* [Style page](/modules/styles)
* [Cost Sheet page](/modules/cost-sheet)
* [BOM page](/modules/bom)