---
id: TST-COM-ORD-145
title: The keys
kind: unit
product_area: commerce
module: orders
revision: 1
status: draft
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
repository: services-commerce
files:
  - modules/orders/tests/unit/tender/tender-rules.spec.js
implements:
  - ATS-COM-ORD-006-09
  - ATS-COM-ORD-007-07
environment: mock
implementation_state: implemented
latest_result: not-run
latest_run_at: null
latest_run_ref: null
conformance: not-verified
estimated_minutes: 1
isolation: 'The suite owns its in-memory inputs, scripted responses and rendered component state.'
evidence:
  - provenance: test
    source: 'services-commerce:modules/orders/tests/unit/tender/tender-rules.spec.js'
    test_cases:
      - keys the sale invoice as the order’s first bill and each tender attempt by its sequence
      - 'is the total less the legs that succeeded, ignoring the declined and uncertain ones'
      - is the frozen deposit less the succeeded deposit legs; an installment leg is never a deposit leg
      - >-
        accepts a terms order, a no-tender order and a zero-total pay-now order; a pay-now and a deposit order
        wait for their tender
      - escalates an uncertain tender after fifteen minutes (08 §7)
      - 'reads what the credit applications applied, not what the leg asked for'
      - adds the payment a settlement took to its credits
      - states no applied amount when the answer carries neither credits nor payment
      - >-
        leaves a credit leg that applied less than it asked at what it applied, so the order still owes the
        rest
      - 'keeps the leg as asked when the settlement applied all of it, or states nothing'
      - declines a credit leg whose settlement applied nothing
      - does not narrow a leg of another kind
      - lets staff record an offline tender under a profile that lists no offline method (E1)
      - still refuses a member an offline tender under a profile that lists none (E1)
      - still holds staff to the profile’s card acceptance (E1)
      - 'refuses a member a second payment when the policy takes one, naming the policy (E3)'
      - >-
        lets staff split, lets a member pay by store credit beside a payment, and binds nobody when the policy
        allows splits (E3)
      - offers the six Rhythm 1.0 kinds and keeps other
      - records each under Accounting’s system payment method id
scenario_coverage:
  - scenario: ATS-COM-ORD-006-09
    test_cases:
      - >-
        accepts a terms order, a no-tender order and a zero-total pay-now order; a pay-now and a deposit order
        wait for their tender
    scope: >-
      The cited cases exercise the scenario’s listed fixture outcomes; this register makes no verified
      conformance claim.
  - scenario: ATS-COM-ORD-007-07
    test_cases:
      - >-
        leaves a credit leg that applied less than it asked at what it applied, so the order still owes the
        rest
      - declines a credit leg whose settlement applied nothing
      - 'is the total less the legs that succeeded, ignoring the declined and uncertain ones'
    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/unit/tender/tender-rules.spec.js'
  declared_by_test: 'the rules. Doubled: nothing (the inputs are literals).'
---

# The keys

## Verification Boundary

The unit suite checks the named contract or helper with controlled inputs.

## What This Suite Proves

The registered cases check the keys 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

Inputs and external responses are controlled in process; this suite establishes no deployed service behavior.

## Must Not Be Doubled

The named contract validation or component behavior under assertion must use its actual implementation.
