> ## 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.

# Order lifecycle

> The two parallel dimensions an order moves through — its work phase and its commercial status — how they relate, and where the MO and the readiness engine sit.

An <Tooltip tip="A customer's commitment to buy specific styles, colorways, and quantities to ship by a given date.">[order](/reference/glossary#order)</Tooltip>
in GarmentFlow moves along **two dimensions at once**: the operational work that
turns a commitment into shipped goods, and the commercial state of the deal
itself. This page is the mental model for both dimensions, how they relate, and
where the MO and the readiness engine sit. The task detail for each step lives
on its module page.

This builds on the [style-centric model](/concepts/style-centric-model): an
order *runs* a style, it does not contain one.

## The mental model: two parallel dimensions

Every order in GarmentFlow carries:

* A **work phase** — where the operational work currently stands, from the
  first inquiry through to shipped. This is the spine of the order's day-to-day
  lifecycle.
* A **commercial status** — where the deal itself stands as a commitment, from
  inquiry through confirmed and on to completed or cancelled. This is the
  commercial-side label on the order.

The two dimensions are tracked **independently** and move at their own pace.
Confirming an order (a commercial-status change) is a different action from
moving past the inquiry phase (a work-phase advance), and the system does not
gate one on the other. They are two readouts of the same order, kept in step by
the team rather than wired together by the platform.

## The work phase — the spine

The work phase is a fixed sequence of named stages an order moves through, one
at a time:

1. **Inquiry.** The order has been opened but the work hasn't started — terms
   are still being scoped.
2. **Development sample.** A first sample is in development with the factory
   so the design can be reviewed.
3. **Quotation.** A price has been worked up for the customer.
4. **PI sent.** A
   <Tooltip tip="A preliminary invoice confirming price, quantity, and terms before shipment.">[proforma invoice](/reference/glossary#pi-proforma-invoice)</Tooltip>
   has gone to the customer.
5. **PO received.** The customer's purchase order is in hand and the deal is
   committed.
6. **Procurement.** Materials are being bought against the order's approved
   <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>.
7. **Production samples.** Pre-production samples are being made and reviewed
   ahead of the bulk run.
8. **Bulk production.** The main run is on the floor.
9. **Shipped.** Goods have left the factory toward the customer.

The work phase is the spine because it is what the merchandiser drives day to
day — every stage is a real piece of operational work, and the order's
readiness, schedules, and downstream documents all hang off it.

### How a phase advances

Some advances are taken by hand, when the team confirms a step has happened.
Others happen automatically the moment the system sees the trigger:

* The advance to **PI sent** happens automatically when a proforma invoice is
  created for the order.
* The advance to **procurement** happens automatically when the order's first
  BOM is approved — that's the signal the material list is settled enough to
  buy against.
* The advance to **bulk production** happens automatically when the
  pre-production sample is approved.
* The advance to **shipped** happens automatically when a shipment for the
  order goes in transit.

The remaining advances — moving past inquiry, the development sample, the PI,
and procurement — are taken manually by the team when each step is done.

### Phases advance one at a time and don't rewind

The work phase moves forward one stage at a time; it never skips ahead and
never moves back. A phase advance that's already been taken stays taken, even
if an upstream decision is revisited later — for example, withdrawing a BOM
approval does **not** rewind the order to its earlier phase. To change values
on an upstream artifact after the order has moved past the phase its approval
triggered, the canonical path is to open a new version of that artifact and
approve it (the per-order pin tracks which version each order is working from;
see [BOM, cost sheet, and artifact versions](/concepts/bom-cost-sheet-artifact-versions)).

## The commercial status — the parallel track

Alongside the work phase, the order carries a **commercial status** the team
sets to communicate where the deal stands as a commitment. Statuses include
inquiry, quotation, **confirmed**, sample, pre-production sample, production,
shipping, **completed**, and **cancelled**.

Two statuses do most of the commercial work:

* **Confirmed** — the customer has committed and the deal is on. Confirmation
  is the commercial signal that the rest of the team can plan against — that
  the styles, quantities, and ship date are real. It is set by the team on
  the order, not derived from the work phase.
* **Cancelled** — the deal is off. An order can be moved to cancelled from
  almost any earlier status, so the team has a clean way to stop work when a
  customer walks away. Cancellation is terminal; it isn't reversed.

**Completed** marks the deal closed from the commercial side once the order
has shipped, billed, and been paid. Like cancelled, completed is terminal.

The status changes when the team marks it. The one place the system writes
status itself is when production work is started on the order — creating the
order's production record flips its status to **production**, so the order
stops being shown as something that hasn't begun.

### Status and phase don't gate each other

Because the two dimensions are tracked independently, an order can carry
combinations that look unusual at first — for example, a status of *production*
while the work phase is still in procurement (the team has flipped the
commercial label even though the floor hasn't started). Read each label for
what it is: phase says **what the work has reached**; status says **what the
deal is**. The team's discipline keeps them aligned; the platform does not
force them in lockstep.

## Where the MO sits on the spine

A <Tooltip tip="The production document issued for a specific order's version of a style; its content is frozen when it is issued.">[manufacturing order (MO)](/reference/glossary#mo-manufacturing-order)</Tooltip>
— the production-spec document for an order's run of a style — is created and
issued on the work-phase spine. Practically, that happens once the order has
the approved BOM (and ideally cost sheet) it should be built against; in
phase terms, that is typically around **procurement** through **bulk
production**.

Issuing an MO does two things:

* It **pins the MO to specific versions** of the order's tech pack, BOM, cost
  sheet, packing instructions, and QC standard. A later revision of any of
  those on the style does not change what the issued MO references — the
  factory sees the picture it was issued against.
* It **freezes the MO's rendered content** at the moment of issue. Edits to a
  pinned artifact's content after issue do not show through on the issued
  MO's document.

Issuing is **not gated by the system on which versions are approved.** The
discipline the team practices is to **approve the BOM and cost sheet for the
order before issuing the MO**, so the picture frozen at issue is the picture
the team stands behind. The platform trusts the team to follow that
discipline; see [style vs. order vs. MO](/concepts/style-vs-order-vs-mo) for
the rule of thumb.

Issuing the MO does not by itself advance the work phase or change the
commercial status — those are tracked separately, advanced by the events
listed above.

## Where readiness sits

The [readiness engine](/concepts/readiness-engine-and-ai) is layered on top of
both dimensions. It reads the same work the team is doing — BOM approvals,
fitting sign-offs, material receipts, issued documents — and computes, per
order, what is done and what is still outstanding. The work phase tells you
**which stage** an order has reached; the readiness engine tells you **what
inside that stage is still missing** and whether the ship date is in danger.

The two readouts complement each other: the phase progression is the linear
spine, the readiness view is the checklist on top of it.

## Orders aren't deleted

Once an order has been created, it stays in the system. There is no delete
action on an order — the canonical way to stop work on a deal that is no
longer happening is to **cancel** it, which leaves the record on file with a
clear commercial label that nothing further should be done against it. This
keeps the audit trail intact for downstream documents and reports that
already reference the order.

## Where you encounter the model

* **On the order detail page** — the order's header carries its commercial
  status, and the work-phase progression sits alongside the order's overview
  and readiness views.
* **In the Orders module** — the list view surfaces commercial status as the
  at-a-glance label per order.
* **Across downstream work** — the readiness engine, the production timeline,
  and the documents and conversion chain all read the order's work phase to
  decide what is unblocked.

## Related pages

* [Style vs. order vs. MO](/concepts/style-vs-order-vs-mo)
* [BOM, cost sheet, and artifact versions](/concepts/bom-cost-sheet-artifact-versions)
* [Readiness engine and AI](/concepts/readiness-engine-and-ai)
* [Documents and conversion chain](/concepts/documents-and-conversion-chain)
* [Orders module guide](/modules/orders)