Rhythm 2.0 Specifications

Appearance

ATS-COM-FUL-002Authorize delivery from current order facts: Capability Test Specification

Markdown

ATS-COM-FUL-002

Authorize delivery from current order facts: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-COM-FUL-002

Design

Executed by
TST-COM-FUL-019, TST-COM-FUL-022, TST-COM-FUL-023, TST-COM-FUL-029, TST-COM-FUL-032, TST-COM-FUL-040, TST-COM-FUL-047, TST-COM-FUL-052, TST-COM-FUL-056

KindAcceptance test setProduct areaCommerceModuleFulfillment, Shipping and InventoryRevision2

Read atservices-commerce c8b66a98react-console baf6dae3

Authorize delivery from current order facts: Capability Test Specification ​

Coverage ​

The category map distinguishes available cases from missing proof. A covered category has a scenario; the lifecycle and permission audits retain gaps in exhaustive coverage. Proposed cases describe the intended verification and carry no execution result.

RuleScenarios
BR-CAP-COM-FUL-002-01ATS-COM-FUL-002-01
BR-CAP-COM-FUL-002-02ATS-COM-FUL-002-02, ATS-COM-FUL-002-15
BR-CAP-COM-FUL-002-03ATS-COM-FUL-002-03
BR-CAP-COM-FUL-002-04ATS-COM-FUL-002-03
BR-CAP-COM-FUL-002-05ATS-COM-FUL-002-04, ATS-COM-FUL-002-11
BR-CAP-COM-FUL-002-06ATS-COM-FUL-002-05
BR-CAP-COM-FUL-002-07ATS-COM-FUL-002-06, ATS-COM-FUL-002-13
BR-CAP-COM-FUL-002-09ATS-COM-FUL-002-07, ATS-COM-FUL-002-14
BR-CAP-COM-FUL-002-10ATS-COM-FUL-002-07, ATS-COM-FUL-002-14
BR-CAP-COM-FUL-002-11ATS-COM-FUL-002-08
BR-CAP-COM-FUL-002-12ATS-COM-FUL-002-09, ATS-COM-FUL-002-12
BR-CAP-COM-FUL-002-14ATS-COM-FUL-002-10

The interaction cases exercise protect a member-priced purchase until its membership arrives; carry authorized work to its delivering application. They vary the upstream record or outcome and inspect the resulting work across the capability boundary. Workflow crossings also include stock, financial or application records when the flow depends on them. Existing test bindings retain their source anchors so a reviewer can distinguish supporting assertions from a complete workflow run.

Coverage

  • Rule covered
  • Transition covered
  • Validation gap: FND-COM-FUL-057
  • Permission not-applicable
  • Edge covered
  • Failure covered
  • Boundary covered
  • Concurrency covered
  • Invariant gap: FND-COM-FUL-057
  • Interaction covered

Test Scenarios

15 scenarios proving CAP-COM-FUL-002; 11 bound to an existing test.

01 Acceptance is required before every delivery conditionruleunitnegativetest
Proves
BR-CAP-COM-FUL-002-01
Preconditions
The order is placed but unaccepted.
Steps
Evaluate all six financial conditions, including no condition.
Expected
No condition permits the gate to open before acceptance.
Data
Fixtures for acceptance is required before every delivery condition.
Bound to
services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#the order must be accepted whatever the policy, even none
Source
services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#the order must be accepted whatever the policy, even none
02 Human safeguards precede financial eligibilityedgeunittest
Proves
BR-CAP-COM-FUL-002-02
Preconditions
An invoiced line has been paid.
Steps
Evaluate holds, migration, missing approval and failed readiness, then supply approval.
Expected
Human blocks are retained where applicable; approval permits evaluation of the remaining conditions.
Data
Fixtures for human safeguards precede financial eligibility.
Bound to
services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#blocks for a person exactly when the reason is a hold, a migrated line, a missing approval or a prerequisite that failed, and never otherwise
services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#an approval is asked before the money is looked at, and an approved obligation goes on to the money
Source
services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#blocks for a person exactly when the reason is a hold, a migrated line, a missing approval or a prerequisite that failed, and never otherwise
03 Payment evaluation excludes written-off moneyruleunittest
Proves
BR-CAP-COM-FUL-002-03 BR-CAP-COM-FUL-002-04
Preconditions
A financial position exists for an invoiced line.
Steps
Vary credits, refunds, write-offs, pending captures and unsettled bank debits.
Expected
The verdict reflects effective paid money and the configured capture and settlement safeguards.
Data
Fixtures for payment evaluation excludes written-off money.
Bound to
services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#a write-off never fulfils: a line written off in full stays closed with the balance due (08 row 19, B37)
services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#ACH counts when accepted by default, and only once settled when the policy says so
services-commerce:modules/fulfillment/tests/integration/services/facts/position-view-gate.integration.spec.js#closes paid_in_full on ACH pending when the policy waits for settlement, subtracting it from the paid money
services-commerce:modules/fulfillment/tests/integration/services/facts/position-view-gate.integration.spec.js#opens paid_in_full on the same ACH line when the policy counts ACH once accepted
Source
services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#a write-off never fulfils: a line written off in full stays closed with the balance due (08 row 19, B37)
04 Each financial condition opens at its own boundaryboundaryunittest
Proves
BR-CAP-COM-FUL-002-05
Preconditions
Fixtures cover threshold, immediate and unconditional delivery.
Steps
Evaluate values either side of thresholds and billing states.
Expected
Only facts satisfying the selected condition open its gate.
Data
Fixtures for each financial condition opens at its own boundary.
Bound to
services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#a minimum amount and a minimum percent are met by what was paid, never by the balance
services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#immediate waits for the order to be billed, and none waits for nothing but acceptance
services-commerce:modules/fulfillment/tests/e2e/fulfillment-paid-amount.e2e.spec.js#keeps the gate closed while less than the amount is paid
Source
services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#a minimum amount and a minimum percent are met by what was paid, never by the balance
05 Console billing can supply the terms factruleunittest
Proves
BR-CAP-COM-FUL-002-06
Preconditions
Fixtures include console terms, portal terms and card orders.
Steps
Evaluate the billed-on-terms classification of each order.
Expected
The qualifying console terms order alone supplies that approval fact.
Data
Fixtures for console billing can supply the terms fact.
Bound to
services-commerce:modules/fulfillment/tests/unit/register/order-billed-on-terms.spec.js#is not an order whose terms tender is only submitted or declined
services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#approved terms satisfy paid in full when the policy allows it, and not otherwise
Source
services-commerce:modules/fulfillment/tests/unit/register/order-billed-on-terms.spec.js#is a console order whose profile requires terms
06 Parent and readiness dependencies delay eligibilityedgeunittest
Proves
BR-CAP-COM-FUL-002-07
Preconditions
A child follows its parent and another line requires application readiness.
Steps
Evaluate before and after parent opening and prerequisite reporting.
Expected
Each dependent gate waits until its applicable prerequisite is satisfied.
Data
Fixtures for parent and readiness dependencies delay eligibility.
Bound to
services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#the participant’s prerequisite is waited for, and a child line follows its parent unless the policy says not
Source
services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#the participant’s prerequisite is waited for, and a child line follows its parent unless the policy says not
07 Event replay retains idempotence and permits failed evaluation recoveryfailureapitest
Proves
BR-CAP-COM-FUL-002-09 BR-CAP-COM-FUL-002-10 INV-DOM-COM-FUL-001-11
Preconditions
A financial batch includes four valid events and an evaluation failure.
Steps
Deliver the batch again and redeliver the event that failed.
Expected
Previously applied events do not reopen work; failed evaluation is retried and unknown references succeed harmlessly.
Data
Fixtures for event replay retains idempotence and permits failed evaluation recovery.
Bound to
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#is idempotent on the event id: the batch redelivered answers succeeded, evaluates nothing and opens nothing
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#answers failed with the error for an event whose evaluation threw, and leaves no receipt, so its redelivery evaluates
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#answers succeeded for every event, the unknown tenant and the unsold line among them, and applies the four
services-commerce:modules/fulfillment/tests/integration/services/persistence/financial-fact-receipts.queries.integration.spec.js#answers claimed: false with the first receipt when the same event id is written again, and changes nothing
Source
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#is idempotent on the event id: the batch redelivered answers succeeded, evaluates nothing and opens nothing
08 Concurrent evaluation creates one delivery authorizationconcurrencyapitest
Proves
BR-CAP-COM-FUL-002-11 INV-DOM-COM-FUL-001-05
Preconditions
A pending obligation has satisfied its financial condition.
Steps
Evaluate opening concurrently on two database connections.
Expected
Exactly one authorization and its dispatch entry remain.
Data
Fixtures for concurrent evaluation creates one delivery authorization.
Bound to
services-commerce:modules/fulfillment/tests/integration/services/persistence/obligation-register.integration.spec.js#answers the second not waiting once the first committed, and the register holds ONE authorization
services-commerce:modules/fulfillment/tests/integration/services/persistence/obligation-register.integration.spec.js#moves it to authorized with the authorization at sequence one, issued by the gate, the deadline one SLA on, and a fresh attempt count
Source
services-commerce:modules/fulfillment/tests/integration/services/persistence/obligation-register.integration.spec.js#answers the second not waiting once the first committed, and the register holds ONE authorization
09 The stale-work sweep evaluates eligible page candidatestransitionapitest
Proves
BR-CAP-COM-FUL-002-12
Preconditions
The selected page contains paid and unpaid obligations without a recent event.
Steps
Sweep five minutes after creation and again after eleven minutes.
Expected
The early sweep leaves them waiting; the later sweep opens paid candidates and retains unpaid candidates.
Data
Fixtures for the stale-work sweep evaluates eligible page candidates.
Bound to
services-commerce:modules/fulfillment/tests/integration/services/register/register-sweeper.integration.spec.js#finds no stale pending obligation and no overdue authorization, and nudges nothing
services-commerce:modules/fulfillment/tests/integration/services/register/register-sweeper.integration.spec.js#evaluates every stale pending obligation of an accepted order across both tenants, opens the paid ones, and nudges once
services-commerce:modules/fulfillment/tests/integration/services/register/register-sweeper.integration.spec.js#leaves the unpaid one pending with why, evaluated, and the placed order’s untouched
Source
services-commerce:modules/fulfillment/tests/integration/services/register/register-sweeper.integration.spec.js#finds no stale pending obligation and no overdue authorization, and nudges nothing
10 Percentage rounding rejects the lower fractional boundaryboundaryunitproposed
Proves
BR-CAP-COM-FUL-002-14
Preconditions
An accepted line is invoiced for 101 minor units with a 50 percent condition.
Steps
Evaluate payment of 50 minor units, then 51.
Expected
The lower amount leaves the gate closed and the rounded-up amount opens it.
Data
Fixtures for percentage rounding rejects the lower fractional boundary.
Source
services-commerce:modules/fulfillment/services/policies/evaluate-gate.ts:evaluateGate
11 A changed payment threshold affects the next sale while the placed sale keeps its gateinteractionapiproposed
Proves
BR-CAP-COM-FUL-001-04 BR-CAP-COM-FUL-002-05
Preconditions
A product requires payment of 100 minor units. One accepted order already exists.
Steps
Replace the threshold with 200, place another order and pay 100 on both.
Expected
Compare the two gate snapshots and verdicts; only the first order is ready for delivery.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Source
services-commerce:modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js#freezes the product policy on the obligation with the row’s version and source, and the replacement changes nothing on it,services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#a minimum amount and a minimum percent are met by what was paid, never by the balance
12 Explicit policy application changes the staff-visible waiting gateinteractionapiproposed
Proves
BR-CAP-COM-FUL-001-08 BR-CAP-COM-FUL-005-01 BR-CAP-COM-FUL-002-12
Preconditions
A waiting order uses the earlier product policy. Staff can apply the replacement and inspect delivery.
Steps
Replace the policy, apply it with a reason, read the obligation, and run the eligible pending sweep.
Expected
The detail shows the replacement gate and intervention; the sweep evaluates the new condition. Reapplication adds no gate replacement.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Source
services-commerce:modules/fulfillment/tests/e2e/fulfillment-policies.e2e.spec.js#re-freezes the pending obligation to the replaced policy with a receipt, records the intervention, and re-freezes nothing on a repeat,services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#lists each order’s one pending obligation with the built-in default gate frozen on it, and refuses a portal member the register,services-commerce:modules/fulfillment/tests/integration/services/register/register-sweeper.integration.spec.js#finds no stale pending obligation and no overdue authorization, and nudges nothing
13 Membership delivery opens the dependent merchandise gateinteractionapitest
Proves
BR-CAP-COM-FUL-002-07 BR-CAP-COM-FUL-003-02 BR-CAP-COM-FUL-003-03 BR-CAP-COM-FUL-004-04
Preconditions
A paid cart contains a membership and a member-priced shirt. Both have waiting delivery work.
Steps
Evaluate payment, deliver the membership and then dispatch the shirt.
Expected
The shirt waits before membership completion, records its satisfied prerequisite, then completes delivery.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Bound to
services-commerce:modules/fulfillment/tests/e2e/same-cart-grants.e2e.spec.js#delivers the membership, meets the T-shirt’s prerequisite with order.prerequisite_met on the history, and opens its gate
Source
services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#the participant’s prerequisite is waited for, and a child line follows its parent unless the policy says not,services-commerce:modules/fulfillment/tests/e2e/same-cart-grants.e2e.spec.js#delivers the membership, meets the T-shirt’s prerequisite with order.prerequisite_met on the history, and opens its gate,services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#completes the obligation and answers it as it stands; the repeat answers the same
14 Authorization reaches its application once despite a replayed pointerinteractionapitest
Proves
BR-CAP-COM-FUL-002-09 BR-CAP-COM-FUL-004-03
Preconditions
An accepted paid order has a waiting obligation.
Steps
Evaluate payment and replay its event, dispatch the instruction, complete it and replay its pointer.
Expected
One authorization remains and replay retains the completed result.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Bound to
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#is idempotent on the event id: the batch redelivered answers succeeded, evaluates nothing and opens nothing
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#answers failed with the error for an event whose evaluation threw, and leaves no receipt, so its redelivery evaluates
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#answers succeeded for every event, the unknown tenant and the unsold line among them, and applies the four
Source
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#is idempotent on the event id: the batch redelivered answers succeeded, evaluates nothing and opens nothing,services-commerce:modules/fulfillment/tests/integration/services/register/obligation-worker.integration.spec.js#acknowledges a redelivery of the same item as stale, writing one stale attempt and nothing else (A17)
15 Migrated delivery remains distinguishable from new waiting workinteractionapiproposed
Proves
BR-CAP-COM-FUL-020-11 BR-CAP-COM-FUL-002-02 BR-CAP-COM-FUL-004-10
Preconditions
A historical order contains one delivered item and one undelivered item.
Steps
Import the order and inspect its two obligations; evaluate the undelivered line.
Expected
Imported delivery remains completed while the undelivered migrated line remains blocked for staff.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Source
services-commerce:modules/data-operations/tests/integration/services/operations/order-import.integration.spec.js#writes the order with its 1.0 number, accepted at its placement, billed, and marked migrated,services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#blocks for a person exactly when the reason is a hold, a migrated line, a missing approval or a prerequisite that failed, and never otherwise,services-commerce:modules/fulfillment/tests/integration/db/register-tables.table.integration.spec.js#refuses pending to authorized, authorized to pending, failed to completed and completed to anything but superseded (RHC02)

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software