---
id: TST-COM-ORD-103
title: Orders persistence
kind: integration
product_area: commerce
module: orders
revision: 1
status: draft
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
repository: services-commerce
files:
  - modules/orders/tests/integration/services/persistence/orders.integration.spec.js
implements:
  - ATS-COM-ORD-005-14
  - ATS-COM-ORD-007-16
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 2
isolation: The suite creates its own test workspace records and removes them using the fixture cleanup.
evidence:
  - provenance: test
    source: 'services-commerce:modules/orders/tests/integration/services/persistence/orders.integration.spec.js'
    test_cases:
      - 'answers the order, numbered 10000 by the seed, placed, pending billing, with its system properties'
      - >-
        answers the lines in position order, the item line with its frozen purchase and the fee line without
        one
      - >-
        wrote the placed event and the caller’s, each with the actor of the execution (the clock is fixed, so
        their order is not asserted)
      - 'numbers the next order 10001 and the other tenant’s first 10000: one seed per tenant'
      - 'refuses a second placement of the same checkout, 409, leaving one order'
      - >-
        refuses an order with no line, and one with a total that is not its parts, naming the rule, leaving
        nothing behind
      - 'refuses an ordering profile the tenant does not have, naming the property'
      - leaves nothing behind when a line is refused after the order was written
      - lets the first placement succeed
      - 'refuses the second 409 once the first committed, by the checkout’s uniqueness'
      - leaves exactly one order for the checkout
      - 'records the first tender pending at sequence 1, with its event'
      - 'answers the same tender to the same key, created: false, writing nothing'
      - gives a second key the next sequence
      - writes Accounting’s answer on the tender and appends its event
      - 'refuses a tender on an order that is not placed, 409, and on an order the tenant does not have, 404'
      - lets the first record the tender
      - 'answers the second the same tender, created: false, once the first committed'
      - leaves exactly one tender on the order
      - 'gives each its own sequence, 1 then 2, both created'
      - counts the failed attempt and holds the state it was given
      - 'links the invoice once, marks the order billed and writes the invoice line ids on the lines'
      - writes the money mirror the reconciler derived
      - 'accepts a placed order, stamping accepted_at and its event'
      - 'refuses a move the lifecycle does not allow, 409, the order as it was'
      - 'refuses a transition of an order the tenant does not have, and of another tenant’s'
      - replaces the notes at the version read and refuses a stale one
      - cancels part of a line and leaves it open
      - marks a line cancelled once its whole quantity is
      - 'leaves order.lines_cancelled naming each line and quantity, with the reason'
      - 'refuses a quantity beyond what is left of the line, 409, and changes nothing'
      - 'refuses a line the order does not have, 404'
      - 'refuses a quantity that is not a whole number above zero, 400'
      - 'refuses a line named twice, 400'
scenario_coverage:
  - scenario: ATS-COM-ORD-005-14
    test_cases:
      - lets the first placement succeed
      - 'refuses the second 409 once the first committed, by the checkout’s uniqueness'
      - leaves exactly one order for the checkout
    scope: >-
      The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified
      conformance claim.
  - scenario: ATS-COM-ORD-007-16
    test_cases:
      - lets the first record the tender
      - 'answers the second the same tender, created: false, once the first committed'
      - leaves exactly one tender on the order
    scope: >-
      The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified
      conformance claim.
dependency_evidence:
  provenance: test
  source: 'services-commerce:modules/orders/tests/integration/services/persistence/orders.integration.spec.js'
  declared_by_test: >-
    PostgreSQL, the persistence services, `platform.number_seeds` through the shared library, two application
    connections.
---

# Orders persistence

## Verification Boundary

The suite exercises persistence or workflow operations against the local integration database.

## What This Suite Proves

The registered cases check orders persistence with their fixture records and assertions. Scenario bindings name only the examples those cases exercise.

## What It Does Not Prove

A registered file supplies no run result or verified conformance by itself. Local fixtures do not establish deployed cross-service behavior or complete browser journeys.

## Real Dependencies and Test Doubles

PostgreSQL and the exercised Commerce persistence or workflow code are real. Remote service records, clocks and transports follow the suite’s fixtures.

## Must Not Be Doubled

The database constraints, role restrictions, locks and transactions exercised by this suite must use PostgreSQL.