Device Lifecycle¶

Who this is for

Anyone who needs to answer "where is this device in the flow?" — warehouse, sales, support, or a developer debugging a stuck record.

This page is a reference map. Every state, every transition, every condition for moving from one to the next. Use it when something looks stuck and you need to know what has to happen to unblock it.

What each device tracks¶

A single device (stock.lot) carries three independent status fields. They describe different things and change independently.

Field	Purpose	Values
`device_status`	Where in the sales flow is this device?	Available, Reserved, Sold, Returned
`qc_status`	Has it been tested?	Pending QC, In QC, QC Complete, QC Failed
`settlement_status`	Has Axis been paid?	Not Applicable, Pending, Settled

A device can be Sold + QC Complete + Settled: a fully finished consignment sale. Retail reservations are tracked in separate reservation fields and do not change Device Status from Available to Reserved. That distinction matters when troubleshooting.

Device status — the sales flow¶

              Received
                 ↓
           +-----------+
           │ Available │  ← Default when a device arrives
           +-----+-----+
                 │
       ┌───────────────┬───────────────────────────┐
       ↓               ↓
 SO allocation    Retail reservation flag
       ↓          (Device Status stays Available)
  +----------+             │ retail sale confirm
  │ Reserved │             ↓
  +-----+----+          +------+
        │ ship          │ Sold │
        ↓               +------+
     +------+
     │ Sold │
     +--+---+
        │
        │  (customer return)
        ↓
   +----------+
   │ Returned │  → rework → Available
   +----------+

Transitions:

From	To	What triggers it
Available	Reserved	Allocation to a sales-order line
Reserved	Sold	Customer delivery manifest complete
Available	Sold	Retail sale confirmed for a correctly retail-reserved device
Sold	Returned	Customer-return processing
Returned	Available	Re-processed / re-QC'd — back into saleable stock

QC status — the testing flow¶

QC status is a recorded fact for wholesale — it never gates a wholesale row, whether As Received or Reyder QC Verified. It is a hard gate only for strict retail workflows. A normal wholesale row explicitly marked As Received (Supplier/PO Grade) can use immutable intake supplier/PO evidence while the device is Pending QC. A known QC Failed result is recorded on the device but never blocks a wholesale sale; availability, ownership, reservation, company, cost, and quantity controls still apply.

  +-------------+
  │ Pending QC  │  ← Default when received
  +-----+-------+
        │ QC Handoff wizard
        ↓
  +-------------+
  │    In QC    │  ← Being tested / graded
  +-----+-------+
        │
    ┌───┴───┐
    ↓       ↓
+-----------+   +-----------+
│QC Complete│   │ QC Failed │
+-----------+   +-----+-----+
                      │  Reset to QC
                      ↓
                +-------------+
                │ Pending QC  │
                +-------------+

Transitions:

From	To	What triggers it
Pending QC	In QC	QC Handoff wizard
In QC	QC Complete	`action_mark_qc_complete()` on the device form
In QC	QC Failed	`action_mark_qc_failed()`
QC Failed	Pending QC	Return to Pending QC on the device form (Stock Manager only), after the failure has been reviewed. This clears prior Reyder/M360 results so a new handoff and new evidence are required.

Settlement status — the money flow¶

  +-----------------+
  │ Not Applicable  │  ← Reyder-owned devices; no consignment payout due
  +-----------------+

  +-----------------+
  │    Pending      │  ← Consignment device was sold; waiting for Axis to be paid
  +--------+--------+
           │ Mark Paid on the settlement report
           ↓
  +-----------------+
  │    Settled      │  ← Vendor bill cleared; Axis has been paid
  +-----------------+

Not Applicable when the device's owner_company_id equals the selling company (Reyder sold a Reyder device — no commission is owed).
Pending is set by stock.lot.action_mark_sold() when a consignment device ships or sells retail.
Settled is set when the paired consignment settlement report is marked Paid.

Manifest states¶

Receiving and delivery manifests do not use one identical path.

Receiving manifest¶

 Draft → Awaiting Manifest → Ready → In Progress → Complete
   └──────────────→ Cancelled (only with zero accepted scans)

State	Meaning
Draft	Just created, not yet associated with a confirmed PO
Awaiting Manifest	PO confirmed; choose exact supplier list or no-list receiving
Ready	The supplier/preloaded IMEI requirements are ready to verify
In Progress	At least one device scanned
Complete	All accepted devices received and final confirmation completed
Cancelled	Manifest voided with zero accepted inbound scans. The receiving scanner has no public Undo Last Scan action. If receiving already started, stop and use the supervisor/support-approved unreceive or reset process; do not cancel around accepted inventory.

Delivery manifest¶

 Draft → In Progress → Complete
   └──────→ Cancelled (only with zero accepted scans)

State	Meaning
Draft	Created from the sale; no outbound device scanned yet
In Progress	At least one outbound IMEI has been accepted
Complete	Final review completed; an external-customer shipment posts, or an inter-company destination receiving handoff starts
Cancelled	Draft/incomplete fulfillment voided with no accepted outbound scans. Use the outbound-only Undo Last Scan action to remove accepted scans before cancelling.

Undo Last Scan is an outbound delivery control only. Do not look for it on an inbound receiving manifest or use a delivery correction to reverse received inventory.

Consignment agreement state¶

 Draft  →  Active  ⇄  Suspended  →  Terminated

State	Sales allowed under this agreement?
Draft	No
Active	Yes, but only while today falls within Start Date and End Date
Suspended	No (temporarily halted; can be reactivated)
Terminated	No (permanent end)

A blank Start Date or End Date leaves that side of the range open. The Active label by itself does not authorize sales before the start date or after the end date.

Settlement report state¶

 Draft  →  Confirmed  →  Paid

State	What's happened
Draft	Rarely seen — auto-confirmed at creation
Confirmed	Report exists and is waiting for payment. Normally its vendor bill is posted; if no purchase journal was available, a warning leaves it Confirmed without a bill, which accounting must resolve before payment.
Paid	You marked it paid after the vendor bill cleared

Sale-order-line device allocation state¶

 Draft → Reserved → Delivered
           └──────→ Cancelled

State	What it means
Draft	Technical/transient value while an allocation record is being constructed; not a guided operator waiting state
Reserved	SO confirmed — device is reserved on its `stock.lot`
Delivered	Manifest complete — device is Sold
Cancelled	Allocation cancelled — device back to Available

The guided allocation flow begins after SO confirmation and moves the allocation immediately to Reserved, where it stays while its delivery manifest is open. Confirmed is a legacy technical value, not an operator step to wait for.

Packing box state¶

 Draft → Packing → Ready to Ship → Shipped
                                  → Cancelled

State	What it means
Draft	Box created, no devices packed yet
Packing	Actively scanning in
Ready to Ship	All expected devices scanned and ready-confirmed, waiting for Mark Shipped
Shipped	Phones left; posts invoice and consignment settlement when applicable, and COGS only when accounting is configured and the shipped value is non-zero
Cancelled	Box voided and its packed/scanned flags cleared. The SO allocations remain Reserved; cancel them separately through the approved SO correction if the order itself is not continuing.

Retail reservation state¶

 Draft ──→ Active ──→ Released
   └─────────┴──────→ Cancelled
             └──────→ Released automatically when the last device sells

State	What it means
Draft	Not activated yet
Active	Device flagged to the retail partner
Released	All reserved devices sold, or the whole active reservation was released
Cancelled	A Draft or Active reservation was cancelled

Auto-close runs when the last reserved device is recorded as a retail sale. The expected return/expiry date is an operational reminder; this module has no expiry auto-close job.

Quick reference — where each status lives¶

Status field	Model	Who changes it
`device_status`	`stock.lot`	Allocation, delivery manifest, retail sale
`qc_status`	`stock.lot`	QC handoff wizard, QC action buttons
`settlement_status`	`stock.lot`	Settlement report `action_mark_paid()`
Manifest `state`	`device.manifest`	Upload, scan, mark complete
Agreement `state`	`device.consignment.agreement`	Manual activate/suspend/terminate
Report `state`	`consignment.settlement.report`	Auto-confirm at creation, manual Mark Paid
Allocation `state`	`sale.order.line.device`	SO confirmation, manifest complete
Box `state`	`packing.box`	Scan, Mark Ready to Ship, Mark Shipped
Reservation `state`	`device.retail.reservation`	Activate, auto-close on sale

Reviewed 2026-07-22 · Device Inventory 19.0.2.101.0 · Use the exact on-screen label shown in bold.