---
id: TST-COM-CAT-063
title: Pricing Schedules 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/pricing-schedules.e2e.spec.js
implements:
  - ATS-COM-CAT-011-01
  - ATS-COM-CAT-011-02
  - ATS-COM-CAT-011-03
  - ATS-COM-CAT-011-04
  - ATS-COM-CAT-011-05
  - ATS-COM-CAT-011-06
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-011-01
    source: >-
      services-commerce:modules/pricing/tests/e2e/pricing-schedules.e2e.spec.js#answers 400 to an
      event owner (a schedule has none, COMM-M1 D2), to a property outside the contract and to a
      tenant_id other than the path’s
  - scenario: ATS-COM-CAT-011-02
    source: >-
      services-commerce:modules/pricing/tests/e2e/pricing-schedules.e2e.spec.js#answers 400 with the
      problem code periods_not_contiguous to periods with a gap, creating nothing
  - scenario: ATS-COM-CAT-011-03
    source: >-
      services-commerce:modules/pricing/tests/e2e/pricing-schedules.e2e.spec.js#accepts an elapsed
      period sent back as read, and refuses it a new name, 409 period_immutable
  - scenario: ATS-COM-CAT-011-04
    source: >-
      services-commerce:modules/pricing/tests/e2e/pricing-schedules.e2e.spec.js#extends the sold-in
      Early Bird by a week, Regular starting where it now ends, its first sale untouched
  - scenario: ATS-COM-CAT-011-04
    source: >-
      services-commerce:modules/pricing/tests/e2e/pricing-schedules.e2e.spec.js#ends Early Bird now,
      Regular starting then, and locks it fully once the end has passed
  - scenario: ATS-COM-CAT-011-04
    source: >-
      services-commerce:modules/pricing/tests/e2e/pricing-schedules.e2e.spec.js#refuses an end in
      the past, 409 period_immutable, the periods as they were
  - scenario: ATS-COM-CAT-011-04
    source: >-
      services-commerce:modules/pricing/tests/e2e/pricing-schedules.e2e.spec.js#refuses a sold-in
      period a new start, a new name, or both beside a moved end, 409 period_immutable
  - scenario: ATS-COM-CAT-011-05
    source: >-
      services-commerce:modules/pricing/tests/e2e/pricing-schedules.e2e.spec.js#answers 400 with the
      problem code period_id_taken, naming the id, to a second schedule taking a period id, creating
      nothing
  - scenario: ATS-COM-CAT-011-06
    source: >-
      services-commerce:modules/pricing/tests/e2e/pricing-schedules.e2e.spec.js#refuses switching a
      schedule off while products follow it, 409 schedule_in_use with the count and product ids,
      until they move; reactivation works; another workspace’s products do not count
  - scenario: ATS-COM-CAT-011-06
    source: >-
      services-commerce:modules/pricing/tests/e2e/pricing-schedules.e2e.spec.js#refuses the delete
      of a schedule a product follows, 409 schedule_in_use, and deletes it with its periods once
      nothing does
evidence:
  - 'services-commerce:modules/pricing/tests/e2e/pricing-schedules.e2e.spec.js'
  - >-
    services-commerce:modules/pricing/tests/e2e/pricing-schedules.e2e.spec.js#Real: the composed
    handler, the routes, the mapper, the persistence services, the triggers and PostgreSQL.
  - >-
    services-commerce:modules/pricing/tests/e2e/pricing-schedules.e2e.spec.js#Doubled: the signing
    key pair.
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.
---

# Pricing Schedules 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 pricing schedules 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.