---
id: TST-COM-CAT-030
title: Ordering Profiles Verification
kind: api-lifecycle
product_area: commerce
module: catalog
revision: 1
status: draft
product_intent: proposed
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
repository: services-commerce
files:
  - modules/configuration/tests/e2e/ordering-profiles.e2e.spec.js
implements:
  - ATS-COM-CAT-001-01
  - ATS-COM-CAT-001-03
  - ATS-COM-CAT-001-06
  - ATS-COM-CAT-001-07
  - ATS-COM-CAT-001-08
  - ATS-COM-CAT-002-01
  - ATS-COM-CAT-002-02
  - ATS-COM-CAT-002-03
environment: local
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 2
isolation: 'Suite-owned workspace keys and database fixtures, removed by its cleanup hooks.'
binding_evidence:
  - scenario: ATS-COM-CAT-001-01
    source: >-
      services-commerce:modules/configuration/tests/e2e/ordering-profiles.e2e.spec.js#answers 400 to
      a profile without a business unit or without a currency: the two money facts a profile always
      has
  - scenario: ATS-COM-CAT-001-01
    source: >-
      services-commerce:modules/configuration/tests/e2e/ordering-profiles.e2e.spec.js#answers 400
      currency_not_supported_by_business_unit to a currency the business unit does not transact in
  - scenario: ATS-COM-CAT-001-03
    source: >-
      services-commerce:modules/configuration/tests/e2e/ordering-profiles.e2e.spec.js#answers 400 to
      a within_range acceptance without its minimum, naming card_minimum_total_minor, with or
      without the maximum (0755)
  - scenario: ATS-COM-CAT-001-03
    source: >-
      services-commerce:modules/configuration/tests/e2e/ordering-profiles.e2e.spec.js#answers 400 to
      an inverted card range, naming the field, not the database rule, and saves nothing
      (DEF-COM-0866)
  - scenario: ATS-COM-CAT-001-06
    source: >-
      services-commerce:modules/configuration/tests/e2e/ordering-profiles.e2e.spec.js#answers 400 to
      a replacement that drops the tenant default flag from the default, and moves it when another
      states it
  - scenario: ATS-COM-CAT-001-07
    source: >-
      services-commerce:modules/configuration/tests/e2e/ordering-profiles.e2e.spec.js#answers 409
      naming the store while a store sells under the profile, then 200 once the store is gone
  - scenario: ATS-COM-CAT-001-08
    source: >-
      services-commerce:modules/configuration/tests/e2e/ordering-profiles.e2e.spec.js#answers 409 to
      a stale version
  - scenario: ATS-COM-CAT-002-01
    source: >-
      services-commerce:modules/configuration/tests/e2e/ordering-profiles.e2e.spec.js#resolves a
      context: the profile it names (explicit), else its application’s default, else the tenant
      default
  - scenario: ATS-COM-CAT-002-02
    source: >-
      services-commerce:modules/configuration/tests/e2e/ordering-profiles.e2e.spec.js#answers 400 to
      a context naming a profile the tenant does not have, and nothing for a tenant with no profile
      at all
  - scenario: ATS-COM-CAT-002-03
    source: >-
      services-commerce:modules/configuration/tests/e2e/ordering-profiles.e2e.spec.js#refuses a
      document naming an inactive or an unknown profile, 400, the document unchanged
evidence:
  - 'services-commerce:modules/configuration/tests/e2e/ordering-profiles.e2e.spec.js'
  - >-
    services-commerce:modules/configuration/tests/e2e/ordering-profiles.e2e.spec.js#Real: the
    composed handler (the dispatcher, the tenant access gate, the application access and licence
    steps), the routes, the signed context's verification and evaluation, the request mapper, the
    persistence services and PostgreSQL; Accounting in process (the fixture transport for this suite
    alone).
  - >-
    services-commerce:modules/configuration/tests/e2e/ordering-profiles.e2e.spec.js#Doubled: the
    signing key pair, which is the run's own. Every call acts in tenants of the spec's own
    (`testId`), registered in the local `platform.tenants` stand-in, emptied through the API and the
    owner's purge and removed in `after`.
execution_constraints:
  - No execution is performed in this documentation back-fill.
verification_boundary: >-
  Bindings identify the existing assertions contributing to each scenario; several suites can
  jointly cover a compound scenario.
---

# Ordering Profiles Verification

## Verification Boundary

The composed API handler runs locally with signed caller contexts and the integration database. Its route, mapping, permission and persistence assertions establish the local API boundary.

## What This Suite Proves

The ordering profiles assertions contribute to the scenarios listed in the register. Each binding retains its exact source test anchor so a reviewer can distinguish an individual contribution from the complete scenario.

## What It Does Not Prove

The register records source inspection only. It establishes no run result, delivery qualification or Product approval.

## Real Dependencies and Test Doubles

PostgreSQL and the services called by the suite are real. External service ports, file storage and queues may use the fixtures declared by the suite and its support helpers.

## Must Not Be Doubled

Keep the asserted database constraints, transactions, service functions and execution contexts real. For API suites, preserve the dispatcher and permission enforcement.