---
id: TST-COM-ORD-095
title: The financial sweeps
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/orders/financial-sweeps.integration.spec.js
implements:
  - ATS-COM-ORD-006-03
  - ATS-COM-ORD-007-06
  - ATS-COM-ORD-010-05
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/orders/financial-sweeps.integration.spec.js'
    test_cases:
      - >-
        bills the pending orders of both tenants and the old one, leaves the fresh attempt alone, escalates
        nothing yet
      - 'billed the pay-now order pro forma, linking the invoice and its line, still placed'
      - >-
        billed the terms order real and accepted it at billing (A5), the gates evaluated and the mirror
        derived
      - left the fresh attempt pending with its one attempt
      - finds nothing to bill on a second run at the same instant
      - >-
        escalates an order placed over an hour ago whose billing gets no answer, placed_without_invoice, and
        counts the attempt
      - left the order tender_uncertain with the attempt uncertain naming the intent
      - >-
        moves nothing while Accounting’s intent is still processing, and escalates nothing before fifteen
        minutes
      - >-
        resumes the attempt once Accounting’s sweeper has finished the intent: the payment on the attempt, the
        order accepted, one charge
      - raises tender_uncertain on an attempt still uncertain past fifteen minutes
      - 're-derives the stale mirror of an accepted order from the view, and leaves a fresh one'
      - every pass reads nothing and says it is not configured
scenario_coverage:
  - scenario: ATS-COM-ORD-006-03
    test_cases:
      - >-
        bills the pending orders of both tenants and the old one, leaves the fresh attempt alone, escalates
        nothing yet
      - >-
        escalates an order placed over an hour ago whose billing gets no answer, placed_without_invoice, and
        counts the attempt
    scope: >-
      The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified
      conformance claim.
  - scenario: ATS-COM-ORD-007-06
    test_cases:
      - >-
        moves nothing while Accounting’s intent is still processing, and escalates nothing before fifteen
        minutes
      - >-
        resumes the attempt once Accounting’s sweeper has finished the intent: the payment on the attempt, the
        order accepted, one charge
      - raises tender_uncertain on an attempt still uncertain past fifteen minutes
    scope: >-
      The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified
      conformance claim.
  - scenario: ATS-COM-ORD-010-05
    test_cases:
      - 're-derives the stale mirror of an accepted order from the view, and leaves a fresh one'
    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/orders/financial-sweeps.integration.spec.js'
  declared_by_test: >-
    PostgreSQL (the sweep policy, the stand-in view), the persistence services, the billing and tender
    workflows, the execution contexts under `rhythm_commerce_app`, P4's exceptions. Doubled: Accounting (the
    fixture, in process), the clock (fixed where stated).
---

# The financial sweeps

## Verification Boundary

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

## What This Suite Proves

The registered cases check the financial sweeps 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.