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

# Understand the order lifecycle

> From New to Confirmed to Delivered to Remitted — what each transition requires.

# Understand the order lifecycle

EcommOS enforces a strict pay-on-delivery lifecycle. Every transition has a gate. You cannot skip steps, and that is the point — it keeps order, stock, and money truth aligned.

## Stage 1: Orders (lead work)

Statuses: `New`, `Confirmed`, `Rescheduled`, `Could not reach`, `Cancelled`.

* Orders start as `New`.
* A Sales rep contacts the customer, confirms the order, and moves it to `Confirmed`.
* If the customer asks to delay, use `Rescheduled`.
* If the customer cannot be reached, use `Could not reach`.
* If the customer cancels, use `Cancelled`.

`Confirmed` is the handoff. Once an order is Confirmed, it appears in **Deliveries** for dispatch.

### Rules

* Moving away from `Confirmed` clears later-stage data (dispatch, delivery).
* Status transitions are recorded as order events in the timeline.
* Status fields cannot be patched directly with a generic edit; they must go through transition endpoints.

## Stage 2: Deliveries (dispatch and delivery)

After an order is Confirmed, your logistics team handles it in **Deliveries**:

1. Pick a delivery agent and their pickup location.
2. The system checks stock sufficiency at that location.
3. Dispatch the order.
4. When the customer receives and pays, mark the order `Delivered`.
5. The system decrements inventory at the delivery agent's location that actually delivered.

### Rules

* Dispatch requires a delivery agent and their location.
* Dispatch validates stock before allowing the transition.
* Inventory decrements only from the location that delivered — not from "stock in general".
* Delivery movements are stored as inventory movements tied to the order.

See [Hand off confirmed orders to deliveries](../operations/deliveries).

## Stage 3: Remittance and Cashflow

After delivery, the delivery agent remits the cash collected:

1. Record the remitted amount on the order.
2. The system updates remittance status to `Remitted`.
3. The system creates an income record on Cashflow (once, never duplicated on later edits).
4. The order event timeline records the remittance and the Cashflow entry creation.

### Rules

* Remittance cannot proceed before delivery.
* Remittance-linked income records are created exactly once per order.
* Editing the Cashflow entry later does not mutate the operational remittance amount on the order.

See [Manage stock and waybills](../operations/inventory-basics) for stock movements and [FAQ](../faq) for edge cases.

## Why the gates matter

The gates exist so that reports and stock numbers match reality:

* Stock is not decremented for orders that never delivered.
* Revenue is not recognized for orders that never remitted.
* Dispatch cannot happen without a known delivery agent and stock check.
* Money is not double-counted when remittance is edited.

If you could freely edit status fields, every report would be soft. The gates are the product.