---
id: TST-ACC-PRD-025
title: Grouped financial setup API lifecycle
kind: api-lifecycle
product_area: accounting
module: products
revision: 1
status: draft
product_intent: proposed
implementation_evidence: observed
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
repository: services-accounting
files:
  - modules/products/tests/e2e/product-accounting-setups.e2e.spec.js
implements:
  - ATS-ACC-PRD-017-01
  - ATS-ACC-PRD-017-02
  - ATS-ACC-PRD-017-03
  - ATS-ACC-PRD-017-04
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 5
estimation_note: Planning estimate; no runtime measurement is claimed.
isolation: 'Suite-named local workspaces, isolated fixture records and explicit cleanup or rollback.'
evidence:
  - 'services-accounting:modules/products/tests/e2e/product-accounting-setups.e2e.spec.js'
assertion_bindings:
  - scenario: ATS-ACC-PRD-017-01
    assertions:
      - >-
        services-accounting:modules/products/tests/e2e/product-accounting-setups.e2e.spec.js#answers the
        active products with no setup, by name
      - >-
        services-accounting:modules/products/tests/e2e/product-accounting-setups.e2e.spec.js#answers the
        inactive ones when asked
      - >-
        services-accounting:modules/products/tests/e2e/product-accounting-setups.e2e.spec.js#answers each
        product as the products list does
    provenance: test
    source: 'services-accounting:modules/products/tests/e2e/product-accounting-setups.e2e.spec.js'
  - scenario: ATS-ACC-PRD-017-02
    assertions:
      - >-
        services-accounting:modules/products/tests/e2e/product-accounting-setups.e2e.spec.js#refuses a body
        without setups 400
      - >-
        services-accounting:modules/products/tests/e2e/product-accounting-setups.e2e.spec.js#refuses more than
        100 setups 400
    provenance: test
    source: 'services-accounting:modules/products/tests/e2e/product-accounting-setups.e2e.spec.js'
  - scenario: ATS-ACC-PRD-017-03
    assertions:
      - >-
        services-accounting:modules/products/tests/e2e/product-accounting-setups.e2e.spec.js#refuses another
        unit’s account in a later setup 400, naming it, and writes nothing
    provenance: test
    source: 'services-accounting:modules/products/tests/e2e/product-accounting-setups.e2e.spec.js'
  - scenario: ATS-ACC-PRD-017-04
    assertions:
      - >-
        services-accounting:modules/products/tests/e2e/product-accounting-setups.e2e.spec.js#refuses an
        unknown product 400, naming it
    provenance: test
    source: 'services-accounting:modules/products/tests/e2e/product-accounting-setups.e2e.spec.js'
coverage_note: Scenario references name existing assertion evidence; broader unexecuted variants remain findings.
---

# Grouped financial setup API lifecycle

## Verification Boundary

Requests pass through the local enforcing Accounting dispatcher, request mapping and persistence to PostgreSQL. This is local API evidence rather than a deployed network run.

## What This Suite Proves

The enforcing API tests missing-setup lists, grouped creation and replacement, input bounds and all-or-nothing refusals.

## What It Does Not Prove

Local execution does not prove deployed infrastructure, downstream purchase behavior, real domain extension completion or atomic remote-template recovery.

## Real Dependencies and Test Doubles

The composed handler, permission evaluation and Accounting database are real. Local signing keys and Platform workspace registration stand in for external infrastructure.

## Must Not Be Doubled

Do not double PostgreSQL, row-level security, transaction boundaries, constraints or the persistence implementation when claiming these local guarantees.