--- id: CON-COM-ORD-002 name: Order feature: FEAT-COM-ORD-02 product_area: commerce module: orders revision: 1 status: draft product_intent: confirmed implementation_evidence: observed source_sha: services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b react-console: baf6dae382d6f41dce976c7f848667ccc37e076f definition: >- An order records a numbered sale, including its purchased lines, frozen policy, billing links, payment attempts and subsequent history. owned_by: MOD-COM-ORD synonyms: - sale - sales order not_to_be_confused_with: - Checkout — preparation before the numbered sale - Invoice — Accounting’s receivable record - Purchase order — a vendor stock purchase facets: - name: Purchased lines meaning: >- Frozen item details, calculated prices, discounts, tax and line states, together with shipping and fee lines. used_for: 'Connect billing, delivery and after-sale actions to each item.' - name: Frozen ordering terms meaning: 'The checkout policy’s payment, billing, merchant and tender-window settings at placement.' used_for: Preserve the terms governing the sale. - name: Sale state and classification meaning: The order’s lifecycle state and the classification contributed by its selling applications. used_for: Identify possible next actions and locate kinds of sale. - name: Billing progress and linked invoices meaning: 'Billing progress plus the sale, fee, installment and change invoices owned by Accounting.' used_for: Connect the purchase to its receivables. - name: Tender history and deadline meaning: 'Payment attempts and their outcomes, together with the payment window for pay-now orders.' used_for: Explain retries and expiry without duplicating charges. - name: Accounting balance mirror meaning: 'The last refreshed invoiced, paid, credited and balance amounts.' used_for: Display financial position without creating another ledger. - name: Attributed order events meaning: 'Placement, billing, payment, delivery and intervention events with their actors and reasons.' used_for: Explain the sale’s history. relationships: - to: CON-COM-ORD-001 statement: Cart-based sales retain their cart link; amendment change orders can have a different origin. provenance: observed source: 'services-commerce:modules/orders/db/orders.table.ts:orders' - to: CON-COM-ORD-003 statement: The responsible selling application delivers each purchased line. provenance: documented source: 'services-commerce:docs/milestones/plans/COMM-M2-plan.md#Words used in this plan.' - to: CON-COM-ORD-004 statement: Delivery of a line can create the entitlement specified for its purchase. provenance: observed source: 'services-commerce:modules/entitlements/services/register/grant-specification.ts' - to: CON-COM-ORD-005 statement: 'Cancellations, amendments and returns record later changes to an accepted purchase.' provenance: observed source: 'services-commerce:modules/orders/db/cancellations.table.ts' lifecycle: - state: Placed meaning: The sale exists and awaits its billing and payment requirements. how_it_changes: 'Placement creates it; sufficient payment, terms acceptance or voiding moves it onward.' - state: Awaiting an uncertain payment meaning: A payment result remains unresolved and a different attempt cannot proceed. how_it_changes: A lost response enters this condition; an Accounting answer resolves it. - state: Accepted meaning: The payment or terms requirement is satisfied and delivery can proceed. how_it_changes: 'Payment coverage, terms acceptance or a zero amount enables acceptance.' - state: Voided meaning: 'The purchase is cleared before acceptance, possibly after partial payment.' how_it_changes: An administrator or the tender-window sweep performs the void. - state: Cancelled meaning: Cancellation has removed every remaining open line. how_it_changes: Cancelling the final open line establishes this result. acted_on_by: - CAP-COM-ORD-002 - CAP-COM-ORD-005 - CAP-COM-ORD-006 - CAP-COM-ORD-007 - CAP-COM-ORD-008 - CAP-COM-ORD-009 - CAP-COM-ORD-010 - CAP-COM-ORD-011 - CAP-COM-ORD-014 - CAP-COM-ORD-015 - CAP-COM-ORD-016 visible_to: - ACT-COM-014 - ACT-COM-015 - ACT-COM-016 - ACT-COM-017 evidence: - 'Examined reference: services-commerce:docs/milestones/plans/COMM-M2-plan.md#Words used in this plan.' - 'Examined reference: services-commerce:modules/entitlements/services/register/grant-specification.ts' - 'Examined reference: services-commerce:modules/orders/db/cancellations.table.ts' - 'Examined reference: services-commerce:modules/orders/db/orders.table.ts:orders' supersedes: [] --- # Order ## What It Is An order is the durable point of reference for a sale. It lets staff answer what the customer bought, what happens next and how the purchase connects to Accounting. Placement establishes the numbered record; later events add billing, payment, delivery and after-sale history. Staff can follow that history without treating the current state as a complete explanation of what happened. The purchased lines retain the details accepted for the sale. Their prices, discounts and taxes explain the amount charged, while the policy snapshot preserves the ordering terms that applied at placement. The record can therefore explain a purchase even after the underlying product or policy changes. It also keeps links to the records responsible for delivery and financial settlement. ## What It Is Not The checkout is the preparation for a sale. Accounting owns the invoices and money movements connected to it. A purchase order describes stock bought from a vendor, whereas this order describes a sale to a customer. The distinction is particularly useful when a customer supplies their own purchase order reference: that reference does not turn the customer sale into a vendor purchasing record. ## How It Is Used Clerks use the order after placement to take payment and explain its outcome. Readers locate it through the order list and inspect the detail view. Administrators intervene when a placed order must be cleared or an accepted purchase must change. Billing status, payment status and delivery progress answer different questions, so a useful view presents them together without suggesting they are a single state. The financial view is a mirror of Accounting information, not an independent ledger. A delayed billing operation or an uncertain payment answer can leave the sale needing attention even though its lines already exist. Staff need to distinguish a safe retry from a new attempt. The payment and billing capabilities describe the conditions and recovery behavior; the concept provides a shared vocabulary for reading those results. ## Its Facets **Purchased lines.** Frozen item details, calculated prices, discounts, tax and line states, together with shipping and fee lines. Connect billing, delivery and after-sale actions to each item. **Frozen ordering terms.** The checkout policy’s payment, billing, merchant and tender-window settings at placement. Preserve the terms governing the sale. **Sale state and classification.** The order’s lifecycle state and the classification contributed by its selling applications. Identify possible next actions and locate kinds of sale. **Billing progress and linked invoices.** Billing progress plus the sale, fee, installment and change invoices owned by Accounting. Connect the purchase to its receivables. **Tender history and deadline.** Payment attempts and their outcomes, together with the payment window for pay-now orders. Explain retries and expiry without duplicating charges. **Accounting balance mirror.** The last refreshed invoiced, paid, credited and balance amounts. Display financial position without creating another ledger. **Attributed order events.** Placement, billing, payment, delivery and intervention events with their actors and reasons. Explain the sale’s history. ## How It Relates Cart-based sales retain their cart link; amendment change orders can have a different origin. The responsible selling application delivers each purchased line. Delivery of a line can create the entitlement specified for its purchase. Cancellations, amendments and returns record later changes to an accepted purchase. The capability references identify where the detailed behavior is defined; this concept supplies the vocabulary used across those outcomes. ## What It Could Become The product should make unresolved billing and payment conditions easy to recognize in the order view. The product should confirm which interventions belong in that view before expanding the interface beyond the implemented panels. Browser-level proof should demonstrate the complete staff workflow, including movement between the composer, the payment window and the order record.