---
id: ATS-COM-ORD-010
scope: CAP-COM-ORD-010
product_area: commerce
module: orders
revision: 2
status: proposed
approved_by: null
approved_at: null
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
  macroservice-libraries: 54536a441935c6e09fdb7f96f0bec71c52ba4e03
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
scenarios:
  - id: ATS-COM-ORD-010-01
    title: Workspace paging retains order and buyer information
    level: api
    proves:
      - BR-CAP-COM-ORD-010-01
    preconditions: Contact and organization purchases include an unknown CRM buyer and more than one page.
    steps:
      - do: List workspace orders and continue with the cursor.
        provenance: test
        source: >-
          services-commerce:modules/checkout/tests/e2e/checkout-security.e2e.spec.js#a reader lists every
          order of the tenant with no buyer named, newest first, 50 a page
    expected: 'Pages follow descending placement order, expose available names and enforce the two-hundred-item bound.'
    negative: false
    data_needs: Use the controlled records and transports established by the cited tests.
    bound_to:
      - >-
        services-commerce:modules/checkout/tests/e2e/checkout-security.e2e.spec.js#a reader lists every order
        of the tenant with no buyer named, newest first, 50 a page
      - >-
        services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#lists
        every order of the tenant newest placed first, and none of another tenant’s
      - >-
        services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#answers
        each order with its buyer’s name, a contact’s or an organization’s, null when CRM has none
      - >-
        services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#pages
        with a limit and says whether another page follows
      - 'services-commerce:modules/orders/tests/unit/orders/orders-list-query.spec.js#refuses a page above 200'
      - TST-COM-ORD-025
      - TST-COM-ORD-104
      - TST-COM-ORD-135
    provenance: test
    source: >-
      services-commerce:modules/checkout/tests/e2e/checkout-security.e2e.spec.js#a reader lists every order of
      the tenant with no buyer named, newest first, 50 a page
    category: boundary
    expected_provenance: test
    expected_source: >-
      services-commerce:modules/checkout/tests/e2e/checkout-security.e2e.spec.js#a reader lists every order of
      the tenant with no buyer named, newest first, 50 a page
  - id: ATS-COM-ORD-010-02
    title: Literal order search handles names and number text
    level: api
    proves:
      - BR-CAP-COM-ORD-010-02
    preconditions: Fixtures include an order number and a buyer name containing an underscore.
    steps:
      - do: 'Search number variants, mixed-case name fragments, literal underscore and excessive text.'
        provenance: test
        source: >-
          services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#finds
          an order by its display number with or without the ORD- prefix
    expected: Valid terms match the expected records and the overlong search is refused.
    negative: false
    data_needs: Use the controlled records and transports established by the cited tests.
    bound_to:
      - >-
        services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#finds
        an order by its display number with or without the ORD- prefix
      - >-
        services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#finds
        orders by part of a number
      - >-
        services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#finds
        an order by part of its buyer’s name in any case
      - >-
        services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#reads
        a search term literally: an underscore matches an underscore, not any character
      - >-
        services-commerce:modules/orders/tests/unit/orders/orders-list-query.spec.js#refuses a search term
        longer than 100 characters
      - TST-COM-ORD-104
      - TST-COM-ORD-135
    provenance: test
    source: >-
      services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#finds
      an order by its display number with or without the ORD- prefix
    category: boundary
    expected_provenance: test
    expected_source: >-
      services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#finds
      an order by its display number with or without the ORD- prefix
  - id: ATS-COM-ORD-010-03
    title: List filters combine status and money boundaries
    level: api
    proves:
      - BR-CAP-COM-ORD-010-03
    preconditions: 'Orders cover paid, owing, unbilled and voided cases across kinds and dates.'
    steps:
      - do: Apply filters individually and together.
        provenance: test
        source: >-
          services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#filters
          by status
    expected: >-
      Results meet all supplied filters, inclusive dates are retained and voided records are excluded from
      unpaid.
    negative: false
    data_needs: Use the controlled records and transports established by the cited tests.
    bound_to:
      - >-
        services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#filters
        by status
      - >-
        services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#filters
        the paid orders by the money mirror
      - >-
        services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#filters
        the unpaid orders: owing or not yet billed, never a voided one
      - >-
        services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#filters
        by kind
      - >-
        services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#filters
        by placed date, both days inclusive
      - >-
        services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#combines
        the filters: all of them must hold
      - TST-COM-ORD-104
    provenance: test
    source: >-
      services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#filters
      by status
    category: rule
    expected_provenance: test
    expected_source: >-
      services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#filters
      by status
  - id: ATS-COM-ORD-010-04
    title: Buyer and workspace filter modes remain distinct
    level: unit
    proves:
      - BR-CAP-COM-ORD-010-04
    preconditions: A buyer owns orders and the caller can be a portal member.
    steps:
      - do: >-
          Submit incomplete buyer fields and incompatible filter combinations, then list the member’s buyer
          scope.
        provenance: test
        source: >-
          services-commerce:modules/orders/tests/unit/orders/orders-list-query.spec.js#refuses a buyer kind
          without an id
    expected: >-
      Malformed combinations return 400 and the workspace portal request returns 403 while permitted buyer
      scope is available.
    negative: true
    data_needs: Use the controlled records and transports established by the cited tests.
    bound_to:
      - >-
        services-commerce:modules/orders/tests/unit/orders/orders-list-query.spec.js#refuses a buyer kind
        without an id
      - >-
        services-commerce:modules/orders/tests/unit/orders/orders-list-query.spec.js#refuses a search beside a
        buyer
      - >-
        services-commerce:modules/orders/tests/unit/orders/orders-list-query.spec.js#refuses a profile filter
        without a buyer
      - >-
        services-commerce:modules/checkout/tests/e2e/checkout-security.e2e.spec.js#is refused the list of
        every order, 403, and still lists their own
      - TST-COM-ORD-135
      - TST-COM-ORD-025
    provenance: test
    source: >-
      services-commerce:modules/orders/tests/unit/orders/orders-list-query.spec.js#refuses a buyer kind
      without an id
    category: permission
    expected_provenance: test
    expected_source: >-
      services-commerce:modules/orders/tests/unit/orders/orders-list-query.spec.js#refuses a buyer kind
      without an id
  - id: ATS-COM-ORD-010-05
    title: Money derivation reports reconciliation gaps
    level: unit
    proves:
      - BR-CAP-COM-ORD-010-06
    preconditions: 'Position fixtures include billed lines, credit applications, missing lines and a void invoice.'
    steps:
      - do: Derive and refresh money and invoke stale-mirror processing.
        provenance: test
        source: >-
          services-commerce:modules/orders/tests/unit/mirror/money-mirror.spec.js#sums the positions: paid
          counts payments and credit applications once, credited the memos, the balance what is due
    expected: >-
      The figures count payment and credit application once, and inconsistencies raise their recorded
      exceptions.
    negative: false
    data_needs: Use the controlled records and transports established by the cited tests.
    bound_to:
      - >-
        services-commerce:modules/orders/tests/unit/mirror/money-mirror.spec.js#sums the positions: paid
        counts payments and credit applications once, credited the memos, the balance what is due
      - >-
        services-commerce:modules/orders/tests/integration/services/mirror/refresh-money-mirror.integration.spec.js#raises
        accepted_without_invoice_line on the billed line the view lacks, one open row counting both findings,
        and still writes the mirror it could derive
      - >-
        services-commerce:modules/orders/tests/integration/services/mirror/refresh-money-mirror.integration.spec.js#raises
        mirror_mismatch on the order when its invoice is void
      - >-
        services-commerce:modules/orders/tests/integration/services/orders/financial-sweeps.integration.spec.js#re-derives
        the stale mirror of an accepted order from the view, and leaves a fresh one
      - TST-COM-ORD-133
      - TST-COM-ORD-094
      - TST-COM-ORD-095
    provenance: test
    source: >-
      services-commerce:modules/orders/tests/unit/mirror/money-mirror.spec.js#sums the positions: paid counts
      payments and credit applications once, credited the memos, the balance what is due
    category: failure
    expected_provenance: test
    expected_source: >-
      services-commerce:modules/orders/tests/unit/mirror/money-mirror.spec.js#sums the positions: paid counts
      payments and credit applications once, credited the memos, the balance what is due
  - id: ATS-COM-ORD-010-06
    title: Orders table rendering handles edge display cases
    level: unit
    proves:
      - BR-CAP-COM-ORD-010-07
    preconditions: 'Sample rows include voided, foreign-currency and missing-customer records.'
    steps:
      - do: Render the table and its order link.
        provenance: test
        source: >-
          react-console:components/commerce/orders/__tests__/orders-list-screen.test.tsx#heads the six columns
          staff read
    expected: >-
      The columns, currency labels, missing-name explanation and voided balance treatment match the supplied
      data.
    negative: false
    data_needs: Use the controlled records and transports established by the cited tests.
    bound_to:
      - >-
        react-console:components/commerce/orders/__tests__/orders-list-screen.test.tsx#heads the six columns
        staff read
      - >-
        react-console:components/commerce/orders/__tests__/orders-list-screen.test.tsx#shows the number, the
        customer, the status, the total and the balance due
      - >-
        react-console:components/commerce/orders/__tests__/orders-list-screen.test.tsx#opens Order 360 under
        the buyer from the order number
      - >-
        react-console:components/commerce/orders/__tests__/orders-list-screen.test.tsx#marks a voided order's
        balance as none rather than zero
      - 'react-console:components/commerce/orders/__tests__/orders-list-screen.test.tsx#never says tenant'
      - TST-COM-ORD-016
    provenance: test
    source: >-
      react-console:components/commerce/orders/__tests__/orders-list-screen.test.tsx#heads the six columns
      staff read
    category: edge
    expected_provenance: test
    expected_source: >-
      react-console:components/commerce/orders/__tests__/orders-list-screen.test.tsx#heads the six columns
      staff read
  - id: ATS-COM-ORD-010-07
    title: Order detail presents financial and line evidence
    level: unit
    proves:
      - BR-CAP-COM-ORD-010-08
    preconditions: 'Rendered samples include a promotion, declined attempt, failed delivery and absent mirror.'
    steps:
      - do: 'Render the summary, line and payment cards.'
        provenance: test
        source: >-
          react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows the totals with
          the promotion's name, the money, and the invoice as a link to Accounting
    expected: >-
      The cards expose their supplied amounts, explanations, failures and links, including the
      unavailable-Accounting message.
    negative: false
    data_needs: Use the controlled records and transports established by the cited tests.
    bound_to:
      - >-
        react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows the totals with
        the promotion's name, the money, and the invoice as a link to Accounting
      - >-
        react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#says Accounting has not
        reported when the order has no money mirror yet
      - >-
        react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows a line's discount
        reason, tax and the reason its delivery failed
      - >-
        react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#lists each tender with
        its status, the declined one struck through and a payment linked to Accounting
      - >-
        react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows a payment the
        processor has not confirmed as pending at the processor
      - TST-COM-ORD-017
    provenance: test
    source: >-
      react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows the totals with the
      promotion's name, the money, and the invoice as a link to Accounting
    category: rule
    expected_provenance: test
    expected_source: >-
      react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows the totals with the
      promotion's name, the money, and the invoice as a link to Accounting
  - id: ATS-COM-ORD-010-08
    title: Search-to-detail flow finds a previous sale
    level: browser
    proves:
      - AS-JNY-COM-ORD-003-01
      - AS-JNY-COM-ORD-003-02
      - AS-JNY-COM-ORD-003-03
    preconditions: A live workspace has multiple order pages and a customer’s dated unpaid order.
    steps:
      - do: 'Page, search the surname, narrow payment and dates and open the result.'
        provenance: proposed
        source: FND-COM-ORD-032
    expected: >-
      The selected search result opens its own detail with the current financial position and no duplicate
      paging entries.
    negative: false
    data_needs: 'A controlled workspace with the parties, commercial setup and application responses described above.'
    bound_to: []
    provenance: proposed
    source: FND-COM-ORD-032
    category: interaction
    expected_provenance: proposed
    expected_source: FND-COM-ORD-032
  - id: ATS-COM-ORD-010-09
    title: An order read joins the retained sale evidence
    category: rule
    level: api
    proves:
      - BR-CAP-COM-ORD-010-05
    preconditions: 'The fixture order has frozen lines, invoice connections and sequenced attempts.'
    steps:
      - do: Read the order and included collections.
        provenance: test
        source: >-
          services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#answers
          the order whole: every column mapped, the system properties, the mirror absent until derived
    expected: 'The header, lines, purchases, payment sequence and invoice records identify the same sale.'
    negative: false
    data_needs: Use an isolated workspace with the records and responses named in the preconditions.
    bound_to:
      - >-
        services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#answers
        the order whole: every column mapped, the system properties, the mirror absent until derived
      - >-
        services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#answers
        the line whole with its purchase, the invoice line id billing wrote, and the provenance of its price
      - >-
        services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#answers
        the tenders in sequence order and the invoices
      - TST-COM-ORD-104
    provenance: test
    source: >-
      services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#answers
      the order whole: every column mapped, the system properties, the mirror absent until derived
    coverage_limit: >-
      Obligations and complete price explanations still require the placement API examples; this persistence
      example covers the listed collections.
    expected_provenance: test
    expected_source: >-
      services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#answers
      the order whole: every column mapped, the system properties, the mirror absent until derived
  - id: ATS-COM-ORD-010-10
    title: A member’s list stays inside their buyer scope
    category: interaction
    level: api
    proves:
      - BR-CAP-COM-ORD-010-04
      - BR-CAP-COM-ORD-011-03
    preconditions: Two contacts in one workspace each have an order.
    steps:
      - do: 'List the first buyer as that member, request the other buyer and request the workspace list.'
        provenance: proposed
        source:
          - >-
            services-commerce:modules/orders/tests/unit/orders/orders-list-query.spec.js#refuses a search
            beside a buyer
          - >-
            services-commerce:modules/checkout/tests/e2e/checkout-security.e2e.spec.js#is refused another
            member’s checkout and order, 403 not_your_party, and a change of it
    expected: The own-buyer list succeeds and both broader requests are refused.
    negative: false
    data_needs: Use an isolated workspace with the records and responses named in the preconditions.
    bound_to: []
    provenance: proposed
    source:
      - >-
        services-commerce:modules/orders/tests/unit/orders/orders-list-query.spec.js#refuses a search beside a
        buyer
      - >-
        services-commerce:modules/checkout/tests/e2e/checkout-security.e2e.spec.js#is refused another member’s
        checkout and order, 403 not_your_party, and a change of it
    exercises:
      - CAP-COM-ORD-010
      - CAP-COM-ORD-011
    related_capabilities:
      - CAP-COM-ORD-011
    expected_provenance: proposed
    expected_source:
      - >-
        services-commerce:modules/orders/tests/unit/orders/orders-list-query.spec.js#refuses a search beside a
        buyer
      - >-
        services-commerce:modules/checkout/tests/e2e/checkout-security.e2e.spec.js#is refused another member’s
        checkout and order, 403 not_your_party, and a change of it
  - id: ATS-COM-ORD-010-11
    title: A partial cancellation remains visible beside the surviving sale
    category: interaction
    level: api
    proves:
      - BR-CAP-COM-ORD-010-06
      - BR-CAP-COM-ORD-014-13
    preconditions: A paid accepted order has two item lines.
    steps:
      - do: Cancel one line and immediately read order detail.
        provenance: proposed
        source:
          - >-
            services-commerce:modules/orders/tests/integration/services/mirror/refresh-money-mirror.integration.spec.js#raises
            accepted_without_invoice_line on the billed line the view lacks, one open row counting both
            findings, and still writes the mirror it could derive
          - >-
            services-commerce:modules/orders/tests/e2e/cancellations.e2e.spec.js#shows the cancellation’s
            credit on the order’s money mirror at once, read right after the cancel
    expected: The other line remains accepted and the displayed credit identifies the cancelled portion.
    negative: false
    data_needs: Use an isolated workspace with the records and responses named in the preconditions.
    bound_to: []
    provenance: proposed
    source:
      - >-
        services-commerce:modules/orders/tests/integration/services/mirror/refresh-money-mirror.integration.spec.js#raises
        accepted_without_invoice_line on the billed line the view lacks, one open row counting both findings,
        and still writes the mirror it could derive
      - >-
        services-commerce:modules/orders/tests/e2e/cancellations.e2e.spec.js#shows the cancellation’s credit
        on the order’s money mirror at once, read right after the cancel
    exercises:
      - CAP-COM-ORD-010
      - CAP-COM-ORD-014
    related_capabilities:
      - CAP-COM-ORD-014
    expected_provenance: proposed
    expected_source:
      - >-
        services-commerce:modules/orders/tests/integration/services/mirror/refresh-money-mirror.integration.spec.js#raises
        accepted_without_invoice_line on the billed line the view lacks, one open row counting both findings,
        and still writes the mirror it could derive
      - >-
        services-commerce:modules/orders/tests/e2e/cancellations.e2e.spec.js#shows the cancellation’s credit
        on the order’s money mirror at once, read right after the cancel
  - id: ATS-COM-ORD-010-12
    title: Cancellation and payment feed the retained money projection
    category: interaction
    level: api
    proves:
      - BR-CAP-COM-ORD-010-01
      - BR-CAP-COM-ORD-006-01
      - BR-CAP-COM-ORD-007-01
      - BR-CAP-COM-ORD-014-01
    preconditions: A billed two-line sale receives full payment.
    steps:
      - do: 'Cancel one line, refresh Accounting positions and read order money.'
        provenance: proposed
        source:
          - 'services-commerce:modules/orders/services/mirror/refresh-money-mirror.ts:refreshMoneyMirrorOf'
          - >-
            services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#mirrors Accounting’s
            position: invoiced and paid in full, nothing due
          - 'services-commerce:modules/orders/services/mirror/refresh-money-mirror.ts'
          - 'services-commerce:modules/fulfillment/services/facts/financial-facts-handler.ts'
          - 'services-commerce:modules/orders/services/orders/financial-sweeps.ts:sweepFinancials'
    expected: The projection includes paid and credited amounts once while the standing line retains its balance.
    negative: false
    data_needs: Use an isolated workspace with the records and responses named in the preconditions.
    bound_to: []
    provenance: proposed
    source:
      - 'services-commerce:modules/orders/services/mirror/refresh-money-mirror.ts:refreshMoneyMirrorOf'
      - >-
        services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#mirrors Accounting’s
        position: invoiced and paid in full, nothing due
      - 'services-commerce:modules/orders/services/mirror/refresh-money-mirror.ts'
      - 'services-commerce:modules/fulfillment/services/facts/financial-facts-handler.ts'
      - 'services-commerce:modules/orders/services/orders/financial-sweeps.ts:sweepFinancials'
    exercises:
      - CAP-COM-ORD-010
      - CAP-COM-ORD-006
      - CAP-COM-ORD-007
      - CAP-COM-ORD-014
    workflows:
      - WF-COM-ORD-008
    expected_provenance: proposed
    expected_source:
      - 'services-commerce:modules/orders/services/mirror/refresh-money-mirror.ts:refreshMoneyMirrorOf'
      - >-
        services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#mirrors Accounting’s
        position: invoiced and paid in full, nothing due
      - 'services-commerce:modules/orders/services/mirror/refresh-money-mirror.ts'
      - 'services-commerce:modules/fulfillment/services/facts/financial-facts-handler.ts'
      - 'services-commerce:modules/orders/services/orders/financial-sweeps.ts:sweepFinancials'
evidence:
  - >-
    Examined reference: react-console:components/commerce/orders/__tests__/orders-list-screen.test.tsx#heads
    the six columns staff read
  - >-
    Examined reference: react-console:components/commerce/orders/__tests__/orders-list-screen.test.tsx#marks a
    voided order's balance as none rather than zero
  - >-
    Examined reference: react-console:components/commerce/orders/__tests__/orders-list-screen.test.tsx#never
    says tenant
  - >-
    Examined reference: react-console:components/commerce/orders/__tests__/orders-list-screen.test.tsx#opens
    Order 360 under the buyer from the order number
  - >-
    Examined reference: react-console:components/commerce/orders/__tests__/orders-list-screen.test.tsx#shows
    the number, the customer, the status, the total and the balance due
  - >-
    Examined reference: react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#lists
    each tender with its status, the declined one struck through and a payment linked to Accounting
  - >-
    Examined reference: react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#says
    Accounting has not reported when the order has no money mirror yet
  - >-
    Examined reference: react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows a
    line's discount reason, tax and the reason its delivery failed
  - >-
    Examined reference: react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows a
    payment the processor has not confirmed as pending at the processor
  - >-
    Examined reference: react-console:components/console/order/__tests__/order-360-live-cards.test.tsx#shows
    the totals with the promotion's name, the money, and the invoice as a link to Accounting
  - >-
    Examined reference: services-commerce:modules/checkout/tests/e2e/checkout-security.e2e.spec.js#a reader
    lists every order of the tenant with no buyer named, newest first, 50 a page
  - >-
    Examined reference: services-commerce:modules/checkout/tests/e2e/checkout-security.e2e.spec.js#is refused
    the list of every order, 403, and still lists their own
  - >-
    Examined reference:
    services-commerce:modules/orders/tests/integration/services/mirror/refresh-money-mirror.integration.spec.js#raises
    accepted_without_invoice_line on the billed line the view lacks, one open row counting both findings, and
    still writes the mirror it could derive
  - >-
    Examined reference:
    services-commerce:modules/orders/tests/integration/services/mirror/refresh-money-mirror.integration.spec.js#raises
    mirror_mismatch on the order when its invoice is void
  - >-
    Examined reference:
    services-commerce:modules/orders/tests/integration/services/orders/financial-sweeps.integration.spec.js#re-derives
    the stale mirror of an accepted order from the view, and leaves a fresh one
  - >-
    Examined reference:
    services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#answers
    each order with its buyer’s name, a contact’s or an organization’s, null when CRM has none
  - >-
    Examined reference:
    services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#combines
    the filters: all of them must hold
  - >-
    Examined reference:
    services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#filters
    by kind
  - >-
    Examined reference:
    services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#filters
    by placed date, both days inclusive
  - >-
    Examined reference:
    services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#filters
    by status
  - >-
    Examined reference:
    services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#filters
    the paid orders by the money mirror
  - >-
    Examined reference:
    services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#filters
    the unpaid orders: owing or not yet billed, never a voided one
  - >-
    Examined reference:
    services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#finds
    an order by its display number with or without the ORD- prefix
  - >-
    Examined reference:
    services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#finds
    an order by part of its buyer’s name in any case
  - >-
    Examined reference:
    services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#finds
    orders by part of a number
  - >-
    Examined reference:
    services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#lists
    every order of the tenant newest placed first, and none of another tenant’s
  - >-
    Examined reference:
    services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#pages
    with a limit and says whether another page follows
  - >-
    Examined reference:
    services-commerce:modules/orders/tests/integration/services/persistence/orders.queries.integration.spec.js#reads
    a search term literally: an underscore matches an underscore, not any character
  - >-
    Examined reference: services-commerce:modules/orders/tests/unit/mirror/money-mirror.spec.js#sums the
    positions: paid counts payments and credit applications once, credited the memos, the balance what is due
  - >-
    Examined reference: services-commerce:modules/orders/tests/unit/orders/orders-list-query.spec.js#refuses a
    buyer kind without an id
  - >-
    Examined reference: services-commerce:modules/orders/tests/unit/orders/orders-list-query.spec.js#refuses a
    page above 200
  - >-
    Examined reference: services-commerce:modules/orders/tests/unit/orders/orders-list-query.spec.js#refuses a
    profile filter without a buyer
  - >-
    Examined reference: services-commerce:modules/orders/tests/unit/orders/orders-list-query.spec.js#refuses a
    search beside a buyer
  - >-
    Examined reference: services-commerce:modules/orders/tests/unit/orders/orders-list-query.spec.js#refuses a
    search term longer than 100 characters
coverage:
  rule: covered
  transition: 'gap: FND-COM-ORD-067'
  validation: 'gap: FND-COM-ORD-067'
  permission: 'gap: FND-COM-ORD-067'
  edge: covered
  failure: covered
  boundary: covered
  concurrency: 'gap: FND-COM-ORD-067'
  invariant: 'gap: FND-COM-ORD-067'
  interaction: covered
coverage_definition: Covered means a design scenario exists; executable coverage and execution results are separate.
permission_coverage:
  - key: commerce.orders.read
    where_checked: api
    scenarios: []
    gap: FND-COM-ORD-067
    note: >-
      The listed examples do not establish a complete allow-and-deny matrix for this key; unused catalogue
      keys need no invented route.
    provenance: unknown
    source: FND-COM-ORD-067
  - key: commerce.orders.read
    where_checked: console
    scenarios: []
    gap: FND-COM-ORD-067
    note: >-
      The listed examples do not establish a complete allow-and-deny matrix for this key; unused catalogue
      keys need no invented route.
    provenance: unknown
    source: FND-COM-ORD-067
transition_coverage: []
invariant_coverage:
  - invariant: INV-DOM-COM-ORD-002-01
    scenarios: []
    gap: FND-COM-ORD-067
    provenance: unknown
    source: 'services-commerce:modules/orders/db/orders.table.ts:orders_total_check, orders_amounts_check'
    note: Broader invariant coverage remains open beyond the concrete examples.
  - invariant: INV-DOM-COM-ORD-002-02
    scenarios: []
    gap: FND-COM-ORD-067
    provenance: unknown
    source: >-
      services-commerce:modules/checkout/tests/e2e/idempotency.e2e.spec.js#answers the stored status and body,
      marked Idempotent-Replayed, and runs the placement once: one order row;
      services-commerce:modules/orders/db/orders.table.ts:orders_checkout_uq
    note: Broader invariant coverage remains open beyond the concrete examples.
  - invariant: INV-DOM-COM-ORD-002-03
    scenarios: []
    gap: FND-COM-ORD-067
    provenance: unknown
    source: 'services-commerce:modules/orders/db/orders.table.ts:orders_number_uq, orders_number_check'
    note: Broader invariant coverage remains open beyond the concrete examples.
  - invariant: INV-DOM-COM-ORD-002-04
    scenarios: []
    gap: FND-COM-ORD-067
    provenance: unknown
    source: 'services-commerce:modules/orders/services/persistence/orders.ts:ORDER_TRANSITIONS'
    note: Broader invariant coverage remains open beyond the concrete examples.
  - invariant: INV-DOM-COM-ORD-002-05
    scenarios: []
    gap: FND-COM-ORD-067
    provenance: unknown
    source: 'services-commerce:modules/orders/db/order-lines.table.ts:order_lines_quantity_check'
    note: Broader invariant coverage remains open beyond the concrete examples.
  - invariant: INV-DOM-COM-ORD-002-06
    scenarios: []
    gap: FND-COM-ORD-067
    provenance: unknown
    source: >-
      services-commerce:modules/orders/db/order-line-purchases.table.ts:order_line_purchases_write_once_trigger
    note: Broader invariant coverage remains open beyond the concrete examples.
  - invariant: INV-DOM-COM-ORD-002-07
    scenarios: []
    gap: FND-COM-ORD-067
    provenance: unknown
    source: >-
      services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#resumes the same attempt on a
      retry, whatever card the retry names, and moves nothing while the intent is processing
    note: Broader invariant coverage remains open beyond the concrete examples.
  - invariant: INV-DOM-COM-ORD-002-08
    scenarios: []
    gap: FND-COM-ORD-067
    provenance: unknown
    source: 'services-commerce:modules/orders/db/order-invoices.table.ts:order_invoices_idempotency_key_uq'
    note: Broader invariant coverage remains open beyond the concrete examples.
  - invariant: INV-DOM-COM-ORD-002-09
    scenarios: []
    gap: FND-COM-ORD-067
    provenance: unknown
    source: 'services-commerce:modules/orders/db/order-events.table.ts'
    note: Broader invariant coverage remains open beyond the concrete examples.
  - invariant: INV-DOM-COM-ORD-002-10
    scenarios: []
    gap: FND-COM-ORD-067
    provenance: unknown
    source: 'services-commerce:modules/orders/db/order-lines.table.ts:order_lines_order_fk'
    note: Broader invariant coverage remains open beyond the concrete examples.
  - invariant: INV-DOM-COM-ORD-002-11
    scenarios: []
    gap: FND-COM-ORD-067
    provenance: unknown
    source: 'services-commerce:modules/orders/db/orders.table.ts:orders_installment_schedule_check'
    note: Broader invariant coverage remains open beyond the concrete examples.
  - invariant: INV-DOM-COM-ORD-002-12
    scenarios: []
    gap: FND-COM-ORD-067
    provenance: unknown
    source: >-
      services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#never stores the card: the
      attempt keeps a reference of the merchant account and the token’s last four only
    note: Broader invariant coverage remains open beyond the concrete examples.
  - invariant: INV-DOM-COM-ORD-002-13
    scenarios: []
    gap: FND-COM-ORD-067
    provenance: unknown
    source: >-
      services-commerce:modules/orders/db/reservations.table.ts:reservations_subject_check;
      modules/orders/services/persistence/reservations.ts:RESERVATION_TRANSITIONS
    note: Broader invariant coverage remains open beyond the concrete examples.
workflow_coverage:
  - workflow: WF-COM-ORD-006
    scenarios:
      - ATS-COM-ORD-001-20
    gap: FND-COM-ORD-067
    provenance: proposed
    source:
      - 'services-commerce:modules/checkout/aws/lambda/SWEEPER.ts:handler'
      - 'services-commerce:modules/orders/services/reservations/reservation-sweeper.ts:sweepReservations'
      - 'services-commerce:modules/orders/services/orders/tender-window-sweeper.ts:sweepTenderWindows'
      - 'services-commerce:modules/checkout/aws/lambda/SWEEPER.ts:handler'
      - 'services-commerce:modules/orders/services/orders/financial-sweeps.ts:sweepFinancials'
      - 'services-commerce:modules/entitlements/services/register/entitlement-sweeper.ts:sweepEntitlements'
      - 'services-commerce:modules/checkout/aws/lambda/SWEEPER.ts:handler'
  - workflow: WF-COM-ORD-008
    scenarios:
      - ATS-COM-ORD-010-12
    gap: FND-COM-ORD-067
    provenance: proposed
    source:
      - 'services-commerce:modules/orders/services/mirror/refresh-money-mirror.ts:refreshMoneyMirrorOf'
      - >-
        services-commerce:modules/orders/tests/e2e/billing-and-tender.e2e.spec.js#mirrors Accounting’s
        position: invoiced and paid in full, nothing due
      - 'services-commerce:modules/orders/services/mirror/refresh-money-mirror.ts'
      - 'services-commerce:modules/fulfillment/services/facts/financial-facts-handler.ts'
      - 'services-commerce:modules/orders/services/orders/financial-sweeps.ts:sweepFinancials'
interaction_coverage:
  - with: CAP-COM-ORD-011
    scenarios:
      - ATS-COM-ORD-010-10
  - with: CAP-COM-ORD-014
    scenarios:
      - ATS-COM-ORD-010-11
unproved_rules: []
---

# Locate orders and understand their progress: Capability Test Specification

## Coverage

| Rule | Scenario or finding |
|---|---|
| `BR-CAP-COM-ORD-010-01` | `ATS-COM-ORD-010-01`, `ATS-COM-ORD-010-12` |
| `BR-CAP-COM-ORD-010-02` | `ATS-COM-ORD-010-02` |
| `BR-CAP-COM-ORD-010-03` | `ATS-COM-ORD-010-03` |
| `BR-CAP-COM-ORD-010-04` | `ATS-COM-ORD-010-04`, `ATS-COM-ORD-010-10` |
| `BR-CAP-COM-ORD-010-05` | `ATS-COM-ORD-010-09` |
| `BR-CAP-COM-ORD-010-06` | `ATS-COM-ORD-010-05`, `ATS-COM-ORD-010-11` |
| `BR-CAP-COM-ORD-010-07` | `ATS-COM-ORD-010-06` |
| `BR-CAP-COM-ORD-010-08` | `ATS-COM-ORD-010-07` |

## Interactions With Related Capabilities

A member’s list stays inside their buyer scope. Two contacts in one workspace each have an order. List the first buyer as that member, request the other buyer and request the workspace list.

A partial cancellation remains visible beside the surviving sale. A paid accepted order has two item lines. Cancel one line and immediately read order detail.

Crossing workflow examples also cover preparation, commitment and recovery at their service handoffs. Their structured bindings distinguish specified outcomes from executable evidence.