---
id: TST-COM-ORD-110
title: 'TX-P with promotions, the void and the cancellation release'
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/placement/promotion-placement.integration.spec.js
implements:
  - ATS-COM-ORD-008-04
  - ATS-COM-ORD-008-09
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/placement/promotion-placement.integration.spec.js
    test_cases:
      - 'writes each line net of its promotion discount, the unit price gross'
      - >-
        ends the pay-now order’s tender window exactly thirty minutes after its placed_at, not after a later
        clock read (DEF-COM-0856)
      - >-
        writes the order’s totals under the identity: subtotal Σ (net + discount), discount Σ line discounts,
        total 27000
      - >-
        records one redemption applied for the checkout’s purchaser, with the snapshot of the promotion as of
        now
      - >-
        records one allocation per discounted line: basis 10000, discount 1000, sequence 1, proportional, the
        public name
      - 'commits under the deferred sums trigger: each line’s discount is the sum of its allocations'
      - takes one use of the code and of the promotion
      - locks the promotion’s terms at its first redemption (locked_at set)
      - 'leaves order.promotion_applied on the order’s history with the promotion, the code and the discount'
      - carries the promotions’ summary of §6.7 in the order’s pricing snapshot
      - 'answers a retry under the same key with the same order, redeeming nothing more'
      - >-
        refuses a second redemption of the promotion on the order at the unique key (the backstop):
        already_applied
      - takes the use in the other order first (premise)
      - answers 409 promotion_refused with code_exhausted and the customer’s message
      - 'answers the fresh figures without the code: 45000, no discount'
      - 'places nothing: the checkout is still open and the code’s one use is the other order’s'
      - 'records the refusal on the checkout’s trail, after the rollback'
      - takes the single use at placement (premise)
      - voids the order and releases its redemption with order_voided
      - gives both counters back
      - leaves order.promotion_released on the order’s history before the transition
      - lets the same single-use code place again
      - releases the redemption with order_cancelled when the promotion said so at redemption
      - 'gives the use back: uses 0'
      - 'keeps the redemption of a promotion that keeps its use on cancellation, its uses unchanged'
      - defaults the personal code’s promotion to releasing and the shared code’s to keeping (premise)
      - >-
        releases the personal code’s redemption with order_cancelled and gives its single use back: the code
        and the promotion at 0
      - keeps the shared code’s redemption and its use
      - lets the personal code place again after the release
      - 'leaves the redemption applied when one line of three is cancelled, its uses unchanged'
      - 'releases it with order_cancelled once every allocated line is cancelled, uses 0'
      - 'leaves the allocations untouched: three of 1000'
      - 'releases nothing when asked again: the redemption is no longer applied'
      - 'refuses an order the tenant does not have, 404'
scenario_coverage:
  - scenario: ATS-COM-ORD-008-04
    test_cases:
      - voids the order and releases its redemption with order_voided
      - gives both counters back
    scope: >-
      The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified
      conformance claim.
  - scenario: ATS-COM-ORD-008-09
    test_cases:
      - gives both counters back
    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/placement/promotion-placement.integration.spec.js
  declared_by_test: >-
    the composed handler for the checkout writes and the preview, `placeOrder` with the running macroservice's
    dependencies, the stub participant, the pricing engine, the promotions library and persistence,
    `voidOrder`, PostgreSQL.
---

# TX-P with promotions, the void and the cancellation release

## Verification Boundary

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

## What This Suite Proves

The registered cases check tX-P with promotions, the void and the cancellation release 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.