The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.
| # | Surface | Action | Capability | Expected | Provenance |
|---|---|---|---|---|---|
| 1 | /console/{tenantId}/accounting/payments/{paymentId} | Request a 30.00 check return from a 150.00 receipt with 100.00 allocated. | CAP-ACC-TRX-012 | Approval wait reserves 30.00 and leaves only 20.00 otherwise refundable. | test |
| 2 | /console/{tenantId}/accounting/refunds/{refundId} | Attempt requester approval, then authorize through a different approver. | CAP-ACC-TRX-012 | Self-approval fails and independent approval permits the requested stage. | test services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it is approved by another person (requested, approved_by_id theirs), then executed |
| 3 | /console/{tenantId}/accounting/refunds/{refundId} | Execute the offline refund using its permitted check-number entry. | CAP-ACC-TRX-012 | Offline completion makes the receipt partly refunded. | test |
| 4 | /console/{tenantId}/accounting/payments/{paymentId} | Issue credit from the remaining 20.00. | CAP-ACC-TRX-011 | The open credit consumes available receipt value and prevents source-payment void while live. | test |
| Path | From step | Condition | Path taken | Outcome | Provenance |
|---|---|---|---|---|---|
| alternate | 1 | Independent refund approval is disabled. | Request can proceed directly to execution. | The separate approval stage is unnecessary. | test services-accounting:modules/transactions/tests/e2e/refunds.e2e.spec.js#it pays a refund in the request itself with execute: true |
| alternate | 1 | The original excess came through a card. | Select its processor return path rather than an ordinary check return. | Original-method treatment applies unless the supported fallback conditions are met. | test services-accounting:modules/transactions/tests/integration/services/refunds/refund-card-original-method.integration.spec.js#it refuses a check refund of the card’s unapplied money, saying the money goes back to the card |
| failure | 1 | Another operation tries to consume reserved refund value. | Application, credit or repeat-refund eligibility rejects reuse. | The first return keeps its held value. | test services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it refuses a credit of the reserved money, and a second refund of it (over_refund) |
| Id | Statement | Provenance |
|---|---|---|
01 | An approval-required request cannot authorize its own requester. | test services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it requests it pending_approval, refusing to execute it (refund_not_requested) or to let the requester approve it (self_approval) |
02 | Offline execution converts the reserved value into returned value. | test services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it turns the reservation into the refunded amount when the refund is paid offline |
03 | After return and credit consume the excess, the receipt retains no net held value. | test services-accounting:modules/transactions/tests/integration/services/credits/credits.integration.spec.js#it mirrors the money’s move in the facts: plus on the payment item, minus on the credit item |
End-to-end policy: required: Requester and approver actions need browser coverage with separate identities; enabling the approval setting still uses the service.