---
id: TST-COM-CAT-065
title: Product Purchasing Settings 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/pricing/tests/e2e/product-purchasing-settings.e2e.spec.js
implements:
  - ATS-COM-CAT-012-01
  - ATS-COM-CAT-012-02
  - ATS-COM-CAT-012-03
  - ATS-COM-CAT-012-07
  - FAS-COM-CAT-03-02
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-012-01
    source: >-
      services-commerce:modules/pricing/tests/e2e/product-purchasing-settings.e2e.spec.js#reads a
      product without a row as the defaults, not configured
  - scenario: ATS-COM-CAT-012-01
    source: >-
      services-commerce:modules/pricing/tests/e2e/product-purchasing-settings.e2e.spec.js#gives a
      setting the PUT leaves out its default, the whole record being stated
  - scenario: ATS-COM-CAT-012-02
    source: >-
      services-commerce:modules/pricing/tests/e2e/product-purchasing-settings.e2e.spec.js#prices the
      student member at the student price under lowest (premise)
  - scenario: ATS-COM-CAT-012-02
    source: >-
      services-commerce:modules/pricing/tests/e2e/product-purchasing-settings.e2e.spec.js#prices the
      same buyer at the member price under rank, Member coming before Student members
  - scenario: ATS-COM-CAT-012-02
    source: >-
      services-commerce:modules/pricing/tests/e2e/product-purchasing-settings.e2e.spec.js#prices the
      buyer at the student price again once the selection is put back to lowest
  - scenario: ATS-COM-CAT-012-03
    source: >-
      services-commerce:modules/pricing/tests/e2e/product-purchasing-settings.e2e.spec.js#refuses a
      schedule the workspace does not have, 400, and leaves the settings as they were
  - scenario: ATS-COM-CAT-012-03
    source: >-
      services-commerce:modules/pricing/tests/e2e/product-purchasing-settings.e2e.spec.js#refuses a
      selection, a subject and a qualification date outside the lists, 400, naming the field
  - scenario: ATS-COM-CAT-012-03
    source: >-
      services-commerce:modules/pricing/tests/e2e/product-purchasing-settings.e2e.spec.js#refuses an
      unknown organization role id with 400 naming it, and stores nothing (COM-ACC-0799)
  - scenario: ATS-COM-CAT-012-07
    source: >-
      services-commerce:modules/pricing/tests/e2e/product-purchasing-settings.e2e.spec.js#lets a
      read-only principal read, and refuses it the PUT, 403 permission_missing, the settings as they
      were
  - scenario: FAS-COM-CAT-03-02
    source: 'services-commerce:modules/pricing/tests/e2e/product-purchasing-settings.e2e.spec.js'
evidence:
  - 'services-commerce:modules/pricing/tests/e2e/product-purchasing-settings.e2e.spec.js'
  - >-
    services-commerce:modules/pricing/tests/e2e/product-purchasing-settings.e2e.spec.js#Real: the
    composed handler, the routes, the quote workflow, the engine, the settings persistence and
    PostgreSQL.
  - >-
    services-commerce:modules/pricing/tests/e2e/product-purchasing-settings.e2e.spec.js#Doubled: the
    signing key pair; the quote ports (the fixtures the deployed route uses); the other services'
    tables.
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.
---

# Product Purchasing Settings 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 product purchasing settings 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.