# Sales Order Lifecycle

## Overview

Sales Order Lifecycle governs how a customer commitment is created, reviewed, confirmed, suspended on commercial hold, fulfilled, invoiced, and closed. A `SalesOrder` records the commercial agreement with a customer for one or more items, including ordered quantity, requested ship timing, unit price, currency, shipping and billing context, payment-term reference, and optional originating channel. The order is the primary document that downstream shipments and invoices reference.

The lifecycle tracks both document control and execution progress. A sales order begins in draft, may be submitted for review, can be rejected back to draft with a reason, becomes confirmed when the commercial commitment is accepted, may be moved into `CREDIT_HOLD` when shipment or billing must pause without cancelling the order, and then moves through partial or full shipment and partial or full invoicing states as execution proceeds. This gives sales and operations teams one authoritative record of what is still owed to the customer and what is temporarily blocked for credit or compliance review.

## Business Purpose

- Create a formal, auditable customer commitment before fulfillment or invoicing occurs
- Freeze commercial terms at order confirmation time even if future price lists or payment terms change
- Capture customer, channel, billing, and shipping context needed for downstream fulfillment and invoicing
- Allow a confirmed order to be paused in `CREDIT_HOLD` when credit exposure, compliance review, or dispute handling blocks further execution without voiding the commercial commitment
- Track ordered quantity, shipped quantity, invoiced quantity, and remaining obligation per line
- Provide the reference document required for shipment fulfillment and customer invoice generation
- Support partial fulfillment and partial billing without losing visibility into remaining commitments
- Prevent inactive customers, inactive items, or incomplete orders from entering downstream execution

## Process Flow

```mermaid
flowchart TD
    A[Create Sales Order] --> B[DRAFT]
    B --> C[Add customer, lines, prices, terms]
    C --> D{Submit?}
    D -->|No| C
    D -->|Yes| E[SUBMITTED]
    E --> F{Approve or confirm?}
    F -->|Reject| R[REJECTED]
    R --> B
    F -->|Confirm| G[CONFIRMED]
    G --> H{Place credit hold?}
    H -->|Yes| X[CREDIT_HOLD]
    X --> Y{Release hold?}
    Y -->|Yes| G
    H -->|No| I{Shipment posted?}
    I -->|Partial| J[PARTIALLY SHIPPED]
    I -->|Full| K[SHIPPED]
    J --> L{Invoice issued?}
    K --> L
    L -->|Partial| M[PARTIALLY INVOICED]
    L -->|Full| N[INVOICED]
    J --> O{Close remaining?}
    K --> O
    M --> O
    N --> O
    O -->|Close| Q[CLOSED]
    B --> P[CANCELLED]
    E --> P
    G --> P
    X --> P
```

## Scenario Patterns

- **Direct sales entry**: A sales representative creates an order manually for an existing customer, confirms the commercial terms, and releases it to downstream fulfillment
- **Channel-originated order**: A marketplace order is normalized into an internal sales order, preserving channel reference and channel-specific commercial context
- **Rejected for correction**: An approver rejects a submitted order because the shipping address or payment term is wrong, and the order returns to draft with the rejection reason preserved
- **Partial fulfillment with backorder**: Only some lines ship on time. The order remains open with remaining shippable quantity visible for later shipment
- **Partial billing**: One shipment is invoiced immediately while the remaining order quantity stays open for later billing
- **Credit review pause**: A confirmed order exceeds customer credit exposure, so the order moves to `CREDIT_HOLD` until finance releases it without forcing a new order
- **Manual price override before confirmation**: A user starts from a defaulted price rule but overrides one line before confirmation due to a negotiated exception
- **Service or non-stock order**: A service line is confirmed and invoiced without warehouse shipment, but the order still tracks billing and closure correctly
- **Order cancellation before execution**: Demand disappears after submission and the order is cancelled before any shipment or invoice is issued
- **Close remaining balance**: A customer declines the final backordered units and the user closes the remaining open quantity instead of keeping the order indefinitely active

## Test Cases

- Creating a sales order with a valid ACTIVE customer, company, and at least one line should succeed
- A sales order line must require an ACTIVE item, quantity greater than zero, and a non-negative unit price
- Sales orders can only be created in `DRAFT` status
- A `DRAFT` order can be revised freely, but confirmed commercial fields must not change without an explicit revision workflow
- Submitting a sales order without any lines should fail
- Submitting a sales order without a shipping address when the line requires physical fulfillment should fail
- Submitting a sales order for a partner that does not carry the CUSTOMER role should fail
- Confirming a sales order whose customer is INACTIVE should fail
- Rejecting a submitted sales order should record the rejection reason and return the document to `DRAFT`
- Moving a confirmed sales order to `CREDIT_HOLD` should require an explicit hold reason and should block new shipment or invoice release actions until the hold is released
- Releasing `CREDIT_HOLD` should return the order to the last executable confirmed state without losing shipped or invoiced progress already recorded
- Cancelling a sales order after a posted shipment or issued invoice exists should be prevented unless a controlled downstream reversal flow exists
- Posting a partial shipment should update line shipped quantities and move the order to a partial shipment status
- Issuing an invoice should update line invoiced quantities independently of shipment quantities according to billing policy
- Closing a sales order should be allowed only when all remaining open quantities are fulfilled, cancelled, or explicitly written off
- Sales order totals and open balances must be isolated per company
- The applied unit price on a sales order line must remain unchanged even if the underlying sales price rule is later edited
- A sales order must preserve its assigned payment term snapshot for downstream invoice due-date calculation
- Each sales order line should expose remaining quantity to ship and remaining quantity to invoice
- Duplicate external customer order references should be rejected or flagged according to company policy
- Only authorized sales users should be able to submit, confirm, place on hold, release, cancel, or close sales orders

## Reference Links

- [Odoo Sales orders documentation](https://www.odoo.com/documentation/19.0/applications/sales/sales/sales_quotations.html)
- [Oracle Order Management documentation](https://docs.oracle.com/en/cloud/saas/supply-chain-and-manufacturing/index.html)
- [SAP Sales Order processing overview](https://help.sap.com/docs/SAP_S4HANA_CLOUD)
