Rhythm 2.0 Specifications

Appearance

CAP-COM-FUL-002Authorize delivery from current order facts

Markdown

CAP-COM-FUL-002

Authorize delivery from current order facts

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationObserved

Planning

Feature
FEAT-COM-FUL-01
Exercised by
FAS-COM-FUL-01-01, FAS-COM-FUL-01-02, FAS-COM-FUL-01-05
Key concepts
CON-COM-FUL-001, CON-COM-FUL-002
Actors
ACT-COM-012, ACT-COM-013
Journeys
JNY-COM-FUL-001
Depends on
CAP-COM-FUL-001
Related
CAP-COM-FUL-003, CAP-COM-FUL-004
Proved by
ATS-COM-FUL-002

Implementation

Executable suites
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

KindCapabilityProduct areaCommerceModuleFulfillment, Shipping and InventoryRevision1

Read atservices-commerce c8b66a98

Authorize delivery from current order facts ​

Purpose ​

The register decides whether an accepted order has met its saved delivery conditions.

How It Works ​

Commerce evaluates obligations when relevant financial facts arrive. It reads current line positions from Accounting rather than treating event amounts as the balance. Evaluation combines money, approval, readiness and parent-line facts. The resulting explanation remains available to staff investigating a delay. An eligible obligation enters authorized work for its delivering application. A scheduled backstop revisits stale pending work, subject to its page budget. The product should make recovery backlog and unsuccessful evaluations visible to operations staff.

Relationships ​

  • Choose delivery conditions for sold items supplies or consumes related delivery records.
  • Protect a member-priced purchase until its membership arrives supplies or consumes related delivery records.
  • Carry authorized work to its delivering application supplies or consumes related delivery records.

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes
Eligible purchases can progress promptly to delivery.Financial eligibility protects against unintended release.
Surfaces
job
Intent sources
services-commerce:docs/milestones/plans/COMM-M2-plan.md#D6 (decision (a), Andrew 2026-10-21)

Controls

35 controls apply, from the corpus control catalogue.

TC-IAM-006 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-006 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-TEN-004 TC-CRY-001 TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-LOG-004 TC-LOG-005 TC-CHG-001 TC-CHG-002 TC-CHG-003 TC-CHG-004 TC-CHG-007 TC-AVL-004 TC-MON-001 TC-MON-002 TC-MON-004 TC-PI-001 TC-PI-002 TC-PI-003 TC-PI-004 TC-PI-005 TC-VEN-001 TC-VEN-002 TC-VEN-003 TC-PRV-001 TC-PRV-002

Business Rules

14 rules, 12 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

IdRuleKindEnforced atProvenance
01must prove
Proposed
An obligation cannot open until its order is accepted, including when the policy has no financial condition.
proved by ATS-COM-FUL-002-01, TST-COM-FUL-052
policyservicetest
services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#the order must be accepted whatever the policy, even none
02must prove
Proposed
A staff hold, unfulfilled migrated line, absent required approval or failed prerequisite produces a block requiring staff attention, and approval is checked before financial eligibility.
proved by ATS-COM-FUL-002-02, ATS-COM-FUL-002-15, ATS-COM-FUL-004-13, ATS-COM-FUL-020-11, TST-COM-FUL-052
policyservicetest
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
03must prove
Proposed
Full payment requires paid money plus applied credits minus refunds to cover the invoiced amount with no pending capture; write-offs contribute nothing.
✓ invoiced 100, paid 60, credit applied 40: open✗ invoiced 100, paid 60, written off 40: closed
proved by ATS-COM-FUL-002-03, TST-COM-FUL-029, TST-COM-FUL-052
calculationservicetest
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)
04must prove
Proposed
Bank-debit money contributes when the processor accepts it unless the policy requires settlement first.
proved by ATS-COM-FUL-002-03, TST-COM-FUL-029, TST-COM-FUL-052
calculationservicetest
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
05must prove
Proposed
Amount and percentage conditions compare effective payments with their thresholds, immediate delivery requires billing, no financial condition requires acceptance alone, and a deposit condition requires the plan's initial amount to be paid.
proved by ATS-COM-FUL-001-10, ATS-COM-FUL-002-04, ATS-COM-FUL-002-11, TST-COM-FUL-019, TST-COM-FUL-052
calculationservicetest
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
06must prove
Proposed
A policy allowing approved terms can satisfy full payment for a console order billed on terms, while portal terms orders and merely submitted or declined terms tenders do not qualify through that console rule.
origin: COMM-M2 D6 (a), Andrew 2026-10-21: services-commerce:docs/milestones/plans/COMM-M2-plan.md#D6; docs/milestones/COMM-M2-take-a-staff-order.md#W4-2
proved by ATS-COM-FUL-002-05, TST-COM-FUL-052, TST-COM-FUL-056
policyservicetest
services-commerce:modules/fulfillment/tests/unit/register/order-billed-on-terms.spec.js#is a console order whose profile requires terms
07must prove
Proposed
A child obligation waits for its parent's open gate unless configured otherwise, and required application readiness must be reported before delivery opens.
proved by ATS-COM-FUL-002-06, ATS-COM-FUL-002-13, ATS-COM-FUL-003-06, ATS-COM-FUL-004-08, TST-COM-FUL-023, TST-COM-FUL-052
policyservicetest
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
08
Proposed
Each gate verdict retains the financial condition, amounts and invoice references used to reach it.
invariantservicetest
services-commerce:modules/fulfillment/tests/unit/policies/evaluate-gate.spec.js#carries the facts it used on every verdict: the condition, the money read and the invoice named
09must prove
Proposed
Financial-event receipts prevent duplicate evaluation by event identity, while failed evaluation leaves no receipt and permits another attempt on redelivery.
proved by ATS-COM-FUL-002-07, ATS-COM-FUL-002-14, ATS-COM-FUL-004-09, TST-COM-FUL-022, TST-COM-FUL-032
invariantservice, databasetest
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
10must prove
Proposed
A financial event identifies candidate lines, whose current positions determine eligibility; unknown workspaces, orders and lines return success without changing records.
origin: D-P4-04 (build decision, not a product ruling): services-commerce:docs/migrations/obligation-register/README.md#D-P4-04
proved by ATS-COM-FUL-002-07, TST-COM-FUL-022, TST-COM-FUL-032
policyservicetest
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
11must prove
Proposed
Gate opening creates the authorization and delivery-queue entry atomically, with only one authorization surviving concurrent evaluations.
proved by ATS-COM-FUL-002-08, TST-COM-FUL-040
invariantservice, databasetest
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
12must prove
Proposed
Each minute the sweep can revisit a bounded page of pending obligations on accepted orders after ten minutes without evaluation; backlog and execution failures can extend recovery time.
proved by ATS-COM-FUL-001-11, ATS-COM-FUL-002-09, ATS-COM-FUL-002-12, ATS-COM-FUL-005-08, TST-COM-FUL-047
lifecycleserviceobserved
services-commerce:modules/fulfillment/services/register/register-sweeper.ts:sweepRegister
13
Proposed
The deployed financial-facts provider reads Accounting's line-position view and supplies no approved-customer-terms fact until Accounting exposes one.
policyserviceobserved
services-commerce:modules/fulfillment/services/facts/financial-facts-port.ts:FINANCIAL_FACTS_SOURCE_VARIABLE
14must prove
Proposed
A percentage threshold is the invoiced amount multiplied by the configured percentage and rounded upward to a whole minor currency unit.
proved by ATS-COM-FUL-002-10
calculationserviceobserved
services-commerce:modules/fulfillment/services/policies/evaluate-gate.ts:evaluateGate

Scenarios

IdGivenWhenThenProvenance
01Four orders are paid and one product also requires approval.Deliver Accounting's relevant change events.Three obligations open while the approval-dependent obligation remains blocked.test
services-commerce:modules/fulfillment/tests/e2e/obligation-register.e2e.spec.js#resolves each line by Accounting’s invoice line through the facts port, opens three gates and blocks the one that needs approval
02The line's payment covers its invoice but capture remains pending.Evaluate full-payment eligibility.The outstanding capture keeps delivery closed.test
services-commerce:modules/fulfillment/tests/integration/services/facts/position-view-gate.integration.spec.js#closes paid_in_full on pending capture although the line is paid in full

Edge Cases

IdGivenWhenThenProvenance
03A lost financial event leaves a paid obligation among stale page candidates.Run the sweep eleven minutes after the earlier evaluation.The selected obligation is evaluated and authorized.test
services-commerce:modules/fulfillment/tests/integration/services/register/register-sweeper.integration.spec.js#leaves the paid obligations authorized and queued, with the sweep as the trigger and the facts on them

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