--- id: ATS-ACC-TRX-012 scope: CAP-ACC-TRX-012 product_area: accounting module: transactions revision: 1 status: proposed approved_by: null approved_at: null source_sha: services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f scenarios: - id: ATS-ACC-TRX-012-01 title: Refund requests cannot exceed their source level: api proves: - BR-CAP-ACC-TRX-012-01 preconditions: 'Receipt money, line allocation and credit are available.' steps: - do: Ask above each source and submit a value-free request. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it refuses more than an allocation holds (over_refund) and more than the unapplied money (over_refund) expected: Each invalid request fails. negative: true data_needs: Refundable source variants. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it refuses more than an allocation holds (over_refund) and more than the unapplied money (over_refund) - >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it refuses a credit refund beyond the balance (over_refund) and one through a processor the credit did not come from (cash_account_mismatch) - >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it refuses a refund naming no money (nothing_to_refund) - TST-ACC-TRX-109 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it refuses more than an allocation holds (over_refund) and more than the unapplied money (over_refund) category: validation test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js assertion: >- it refuses more than an allocation holds (over_refund) and more than the unapplied money (over_refund) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it refuses more than an allocation holds (over_refund) and more than the unapplied money (over_refund) - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js assertion: >- it refuses a credit refund beyond the balance (over_refund) and one through a processor the credit did not come from (cash_account_mismatch) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it refuses a credit refund beyond the balance (over_refund) and one through a processor the credit did not come from (cash_account_mismatch) - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js assertion: it refuses a refund naming no money (nothing_to_refund) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it refuses a refund naming no money (nothing_to_refund) binding_review: [] - id: ATS-ACC-TRX-012-02 title: Requested value cannot be spent a second time level: api proves: - BR-CAP-ACC-TRX-012-02 - INV-DOM-ACC-TRX-003-13 preconditions: A receipt holds 50.00 available. steps: - do: >- Reserve 40.00, attempt reuse through allocation, credit and refund, cancel, then execute a fresh request. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it refuses allocating the reserved money (over_application) but allocates money beyond it expected: >- Reserved value stays unavailable while excess remains usable; cancellation releases it and execution records return. negative: false data_needs: A payment with unapplied value. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it holds the 4000 as pending from the request, nothing refunded yet - >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it refuses allocating the reserved money (over_application) but allocates money beyond it - >- 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) - >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it releases the money when the refund is cancelled - >- 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 - TST-ACC-TRX-107 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it refuses allocating the reserved money (over_application) but allocates money beyond it category: concurrency test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js assertion: 'it holds the 4000 as pending from the request, nothing refunded yet' provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it holds the 4000 as pending from the request, nothing refunded yet - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js assertion: >- it refuses allocating the reserved money (over_application) but allocates money beyond it provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it refuses allocating the reserved money (over_application) but allocates money beyond it - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js assertion: >- it refuses a credit of the reserved money, and a second refund of it (over_refund) provenance: test source: >- 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) - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js assertion: it releases the money when the refund is cancelled provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it releases the money when the refund is cancelled - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js assertion: >- it turns the reservation into the refunded amount when the refund is paid offline provenance: test source: >- 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 binding_review: [] - id: ATS-ACC-TRX-012-03 title: Processor return precedes offline fallback level: api proves: - BR-CAP-ACC-TRX-012-03 preconditions: A card receipt holds available money. steps: - do: >- Request a check return, request card return, then retry offline after processor decline. provenance: test source: >- 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 expected: >- Initial offline choice fails, card request succeeds and definite processor failure permits fallback. negative: false data_needs: A processor-declined refund response. bound_to: - >- 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 - >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-card-original-method.integration.spec.js#it accepts a refund to the card - >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-card-original-method.integration.spec.js#it allows a check refund once the processor has declined a refund to the card - TST-ACC-TRX-105 provenance: test source: >- 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 category: boundary test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-card-original-method.integration.spec.js assertion: >- it refuses a check refund of the card’s unapplied money, saying the money goes back to the card provenance: test source: >- 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 - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-card-original-method.integration.spec.js assertion: it accepts a refund to the card provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-card-original-method.integration.spec.js#it accepts a refund to the card - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-card-original-method.integration.spec.js assertion: >- it allows a check refund once the processor has declined a refund to the card provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-card-original-method.integration.spec.js#it allows a check refund once the processor has declined a refund to the card binding_review: [] - id: ATS-ACC-TRX-012-04 title: Line return distinguishes credit from reopened debt level: api proves: - BR-CAP-ACC-TRX-012-04 preconditions: A check paid 50.00 on one line. steps: - do: 'Return 30.00, crediting 20.00 and reopening 10.00.' provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it keeps the invoice settled for the credited 2000 (a credit memo line) and reopens the 1000: the line owes 1000 expected: >- Opposite allocations release 30.00, the memo preserves 20.00 settlement and 10.00 becomes owed. negative: false data_needs: An applied check receipt. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it takes the money back from the allocation: a reversing row per refund, the original reversed by 3000 - >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it keeps the invoice settled for the credited 2000 (a credit memo line) and reopens the 1000: the line owes 1000 - >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0312.spec.ts#ACT-ACC-0312 - TST-ACC-TRX-109 - TST-ACC-TRX-249 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it keeps the invoice settled for the credited 2000 (a credit memo line) and reopens the 1000: the line owes 1000 category: interaction test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js assertion: >- it takes the money back from the allocation: a reversing row per refund, the original reversed by 3000 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it takes the money back from the allocation: a reversing row per refund, the original reversed by 3000 - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js assertion: >- it keeps the invoice settled for the credited 2000 (a credit memo line) and reopens the 1000: the line owes 1000 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it keeps the invoice settled for the credited 2000 (a credit memo line) and reopens the 1000: the line owes 1000 - file: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0312.spec.ts assertion: ACT-ACC-0312 provenance: test source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0312.spec.ts#ACT-ACC-0312 binding_review: - binding: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0312.spec.ts#ACT-ACC-0312 completeness: not-verified provenance: observed source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0312.spec.ts#ACT-ACC-0312 note: >- This citation remains component evidence. A browser request driven through an API helper does not establish direct database checks or every branch of the combined scenario. - id: ATS-ACC-TRX-012-05 title: Another person approves before payment level: api proves: - BR-CAP-ACC-TRX-012-05 - INV-DOM-ACC-TRX-003-14 preconditions: Workspace approval is enabled. steps: - do: >- Request, execute early, self-approve, approve independently and execute. provenance: test source: >- 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) expected: >- The flow waits, rejects early and self actions, then allows the approved payment. negative: false data_needs: Requester and independent approver. bound_to: - >- 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) - >- 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 - >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0313.spec.ts#ACT-ACC-0313 - TST-ACC-TRX-109 - TST-ACC-TRX-250 provenance: test source: >- 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) category: permission test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js assertion: >- it requests it pending_approval, refusing to execute it (refund_not_requested) or to let the requester approve it (self_approval) provenance: test source: >- 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) - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js assertion: >- it is approved by another person (requested, approved_by_id theirs), then executed provenance: test source: >- 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 - file: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0313.spec.ts assertion: ACT-ACC-0313 provenance: test source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0313.spec.ts#ACT-ACC-0313 binding_review: - binding: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0313.spec.ts#ACT-ACC-0313 completeness: not-verified provenance: observed source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0313.spec.ts#ACT-ACC-0313 note: >- This citation remains component evidence. A browser request driven through an API helper does not establish direct database checks or every branch of the combined scenario. - id: ATS-ACC-TRX-012-06 title: Completed return is final level: api proves: - BR-CAP-ACC-TRX-012-06 - INV-DOM-ACC-TRX-003-15 preconditions: One refund is paid and another merely requested. steps: - do: >- Re-execute and cancel the paid record, then cancel the pending request with a reason. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it refuses executing it again (refund_not_requested) and cancelling it (refund_not_cancellable) expected: Completed record rejects change and pending cancellation moves no money. negative: false data_needs: Refunds at different lifecycle points. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it refuses executing it again (refund_not_requested) and cancelling it (refund_not_cancellable) - >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it cancels a requested refund with the reason, nothing moved - TST-ACC-TRX-109 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it refuses executing it again (refund_not_requested) and cancelling it (refund_not_cancellable) category: transition test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js assertion: >- it refuses executing it again (refund_not_requested) and cancelling it (refund_not_cancellable) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it refuses executing it again (refund_not_requested) and cancelling it (refund_not_cancellable) - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js assertion: 'it cancels a requested refund with the reason, nothing moved' provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it cancels a requested refund with the reason, nothing moved binding_review: [] - id: ATS-ACC-TRX-012-07 title: Offline return updates receipt standing level: api proves: - BR-CAP-ACC-TRX-012-07 preconditions: A check holds 50.00. steps: - do: Request and execute a 10.00 check refund. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it records it offline: executed, the payment partially_refunded with 1000 refunded (FC-11, FC-14) expected: >- Offline completion retains its events and makes the payment partly refunded. negative: false data_needs: Available check money. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it records it offline: executed, the payment partially_refunded with 1000 refunded (FC-11, FC-14) - >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0311.spec.ts#ACT-ACC-0311 - TST-ACC-TRX-109 - TST-ACC-TRX-248 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it records it offline: executed, the payment partially_refunded with 1000 refunded (FC-11, FC-14) category: transition test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js assertion: >- it records it offline: executed, the payment partially_refunded with 1000 refunded (FC-11, FC-14) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it records it offline: executed, the payment partially_refunded with 1000 refunded (FC-11, FC-14) - file: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0311.spec.ts assertion: ACT-ACC-0311 provenance: test source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0311.spec.ts#ACT-ACC-0311 binding_review: - binding: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0311.spec.ts#ACT-ACC-0311 completeness: not-verified provenance: observed source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0311.spec.ts#ACT-ACC-0311 note: >- This citation remains component evidence. A browser request driven through an API helper does not establish direct database checks or every branch of the combined scenario. - id: ATS-ACC-TRX-012-08 title: Definite processor failure restores local position level: api proves: - BR-CAP-ACC-TRX-012-08 preconditions: A card allocation supplies refundable value. steps: - do: Execute a declined line return and a timeout known to precede sending. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it leaves the payment as it was: nothing unapplied, refunded or pending, its facts unchanged expected: Both fail with restored applications and released reserved value. negative: true data_needs: Definite-decline and unsent-timeout scripts. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it leaves the invoice lines as they were: nothing owed again, no credit memo kept - >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it leaves the payment as it was: nothing unapplied, refunded or pending, its facts unchanged - >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-timeout-before-send.integration.spec.js#it is failed processor_unavailable at once, the pending money released, nothing refunded - >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0314.spec.ts#ACT-ACC-0314 - TST-ACC-TRX-109 - TST-ACC-TRX-108 - TST-ACC-TRX-251 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it leaves the payment as it was: nothing unapplied, refunded or pending, its facts unchanged category: failure test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js assertion: >- it leaves the invoice lines as they were: nothing owed again, no credit memo kept provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it leaves the invoice lines as they were: nothing owed again, no credit memo kept - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js assertion: >- it leaves the payment as it was: nothing unapplied, refunded or pending, its facts unchanged provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it leaves the payment as it was: nothing unapplied, refunded or pending, its facts unchanged - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-timeout-before-send.integration.spec.js assertion: >- it is failed processor_unavailable at once, the pending money released, nothing refunded provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-timeout-before-send.integration.spec.js#it is failed processor_unavailable at once, the pending money released, nothing refunded - file: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0314.spec.ts assertion: ACT-ACC-0314 provenance: test source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0314.spec.ts#ACT-ACC-0314 binding_review: - binding: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0314.spec.ts#ACT-ACC-0314 completeness: not-verified provenance: observed source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0314.spec.ts#ACT-ACC-0314 note: >- This citation remains component evidence. A browser request driven through an API helper does not establish direct database checks or every branch of the combined scenario. - id: ATS-ACC-TRX-012-09 title: Uncertain refund waits for a definite outcome level: api proves: - BR-CAP-ACC-TRX-012-09 preconditions: One answer is lost and another reports pending. steps: - do: >- Sweep beyond a day and deliver repeated confirmation by processor reference. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-timeout-before-send.integration.spec.js#it leaves the refund processing a day on, never failed as never received and never abandoned expected: >- Money remains held until one successful completion; neither abandonment nor duplicate execution occurs. negative: false data_needs: Clock control and signed gateway events. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-timeout-before-send.integration.spec.js#it leaves the refund processing a day on, never failed as never received and never abandoned - >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it leaves a lost answer processing (refund_uncertain, the money pending) and the sweeper finishes it with one refund - >- services-accounting:modules/transactions/tests/integration/services/integrations/refund-confirmation-by-reference.integration.spec.js#it completes the processing refund and its pending reversal from an event naming only provider_ref, and a redelivery is ignored - >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0346.spec.ts#ACT-ACC-0346 - TST-ACC-TRX-108 - TST-ACC-TRX-109 - TST-ACC-TRX-042 - TST-ACC-TRX-264 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-timeout-before-send.integration.spec.js#it leaves the refund processing a day on, never failed as never received and never abandoned category: edge test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-timeout-before-send.integration.spec.js assertion: >- it leaves the refund processing a day on, never failed as never received and never abandoned provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-timeout-before-send.integration.spec.js#it leaves the refund processing a day on, never failed as never received and never abandoned - file: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js assertion: >- it leaves a lost answer processing (refund_uncertain, the money pending) and the sweeper finishes it with one refund provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it leaves a lost answer processing (refund_uncertain, the money pending) and the sweeper finishes it with one refund - file: >- services-accounting:modules/transactions/tests/integration/services/integrations/refund-confirmation-by-reference.integration.spec.js assertion: >- it completes the processing refund and its pending reversal from an event naming only provider_ref, and a redelivery is ignored provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/integrations/refund-confirmation-by-reference.integration.spec.js#it completes the processing refund and its pending reversal from an event naming only provider_ref, and a redelivery is ignored - file: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0346.spec.ts assertion: ACT-ACC-0346 provenance: test source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0346.spec.ts#ACT-ACC-0346 binding_review: - binding: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0346.spec.ts#ACT-ACC-0346 completeness: not-verified provenance: observed source: >- react-console:acceptance/accounting/playwright/journeys/payments/ACT-ACC-0346.spec.ts#ACT-ACC-0346 note: >- The lost-answer branch asserts initial processing and permits processing or success on retry. It does not prove day-long retention or duplicate confirmation handling; the before-send failure branch is a distinct definite-failure case. - id: ATS-ACC-TRX-012-10 title: Return includes its processing-fee share level: api proves: - BR-CAP-ACC-TRX-012-11 preconditions: The card paid 40.00 and the required associated fee. steps: - do: Refund 20.00 of billed value and reopen another 10.00. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/settlements/card-fees.integration.spec.js#it takes the fee’s share back with the line: 2000 of 4000 refunded is 2065, the fee invoice credited 65 expected: >- The first returns 20.65 and credits 0.65 of fee; reopening also credits its fee share. negative: false data_needs: A required fee rule. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/settlements/card-fees.integration.spec.js#it takes the fee’s share back with the line: 2000 of 4000 refunded is 2065, the fee invoice credited 65 - >- services-accounting:modules/transactions/tests/integration/services/settlements/card-fees.integration.spec.js#it credits the fee’s share even when the line is reopened: 1000 more is 1032, the fee invoice credited 97 in all, the line owing 1000 - TST-ACC-TRX-122 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/settlements/card-fees.integration.spec.js#it takes the fee’s share back with the line: 2000 of 4000 refunded is 2065, the fee invoice credited 65 category: rule test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/settlements/card-fees.integration.spec.js assertion: >- it takes the fee’s share back with the line: 2000 of 4000 refunded is 2065, the fee invoice credited 65 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/settlements/card-fees.integration.spec.js#it takes the fee’s share back with the line: 2000 of 4000 refunded is 2065, the fee invoice credited 65 - file: >- services-accounting:modules/transactions/tests/integration/services/settlements/card-fees.integration.spec.js assertion: >- it credits the fee’s share even when the line is reopened: 1000 more is 1032, the fee invoice credited 97 in all, the line owing 1000 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/settlements/card-fees.integration.spec.js#it credits the fee’s share even when the line is reopened: 1000 more is 1032, the fee invoice credited 97 in all, the line owing 1000 binding_review: [] - id: ATS-ACC-TRX-012-11 title: Refund roles separate sensitive actions level: api proves: - BR-CAP-ACC-TRX-012-12 preconditions: The caller has reader authority only. steps: - do: 'Attempt request, approval, execution and cancellation.' provenance: test source: >- services-accounting:modules/transactions/tests/e2e/refunds.e2e.spec.js#it is refused approve without .approve, execute without .execute and cancel without .create, as a reader (403) expected: Each mutation denies access. negative: true data_needs: A refund reader identity. bound_to: - >- services-accounting:modules/transactions/tests/e2e/refunds.e2e.spec.js#it is refused POST /refunds/{tenantId} without accounting.refunds.create (403) - >- services-accounting:modules/transactions/tests/e2e/refunds.e2e.spec.js#it is refused approve without .approve, execute without .execute and cancel without .create, as a reader (403) - TST-ACC-TRX-013 provenance: test source: >- services-accounting:modules/transactions/tests/e2e/refunds.e2e.spec.js#it is refused approve without .approve, execute without .execute and cancel without .create, as a reader (403) category: permission test_bindings: - file: 'services-accounting:modules/transactions/tests/e2e/refunds.e2e.spec.js' assertion: >- it is refused POST /refunds/{tenantId} without accounting.refunds.create (403) provenance: test source: >- services-accounting:modules/transactions/tests/e2e/refunds.e2e.spec.js#it is refused POST /refunds/{tenantId} without accounting.refunds.create (403) - file: 'services-accounting:modules/transactions/tests/e2e/refunds.e2e.spec.js' assertion: >- it is refused approve without .approve, execute without .execute and cancel without .create, as a reader (403) provenance: test source: >- services-accounting:modules/transactions/tests/e2e/refunds.e2e.spec.js#it is refused approve without .approve, execute without .execute and cancel without .create, as a reader (403) binding_review: [] - id: ATS-ACC-TRX-012-12 title: Returned money resolves the enclosing cancellation category: interaction level: api proves: - BR-CAP-ACC-TRX-012-02 - BR-CAP-ACC-TRX-012-08 - BR-CAP-ACC-TRX-012-09 - BR-CAP-ACC-TRX-007-06 - BR-CAP-ACC-TRX-013-06 - BR-CAP-ACC-TRX-014-05 - BR-CAP-ACC-TRX-014-07 - BR-CAP-ACC-TRX-020-08 - BR-CAP-ACC-TRX-003-04 - BR-CAP-ACC-TRX-009-10 - BR-CAP-ACC-TRX-011-03 exercises: - CAP-ACC-TRX-012 - CAP-ACC-TRX-007 - CAP-ACC-TRX-013 - CAP-ACC-TRX-014 - CAP-ACC-TRX-020 - CAP-ACC-TRX-003 - CAP-ACC-TRX-009 - CAP-ACC-TRX-011 preconditions: >- An isolated workspace has eligible customers, products, matching accounts, an open period and two open batches. Each branch owns separate financial records. steps: - do: >- Cancel 40.00 of a card-paid bill with refund treatment, retain the processing return, deliver a success event twice and inspect the cancellation and source receipt. In separate branches use recovery lookup, a definite decline and processor void. Include an uncertain credit-and-card settlement in a separate branch and inspect its pending credit application before recovery. provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it refuses allocating the reserved money (over_application) but allocates money beyond it; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it leaves the payment as it was: nothing unapplied, refunded or pending, its facts unchanged; services-accounting:modules/transactions/tests/integration/services/refunds/refund-timeout-before-send.integration.spec.js#it leaves the refund processing a day on, never failed as never received and never abandoned; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-007-resolve-lost-processor-answers-and-clear-bank-debits.md#WF-ACC-TRX-007; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-009-request-approve-and-pay-a-refund.md#WF-ACC-TRX-009; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-010-reverse-billing-in-one-operation.md#WF-ACC-TRX-010; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-013-apply-payment-events-from-the-integration-platform.md#WF-ACC-TRX-013; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-014-reverse-billing-in-one-operation.md#BR-CAP-ACC-TRX-014-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-014-reverse-billing-in-one-operation.md#BR-CAP-ACC-TRX-014-07; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-003-reduce-or-add-to-an-issued-invoice-with-credit-and-debit.md#BR-CAP-ACC-TRX-003-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03 expected: >- One confirmation completes the return and its cancellation; duplicate delivery changes nothing; decline restores held value and leaves a cancellation exception; recovery and void retain their distinct outcomes. negative: false data_needs: >- Separate command keys, two customers, invoice lines, receipts and credit; controlled processor outcomes and a fixed calendar where the branch requires them. bound_to: [] provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it refuses allocating the reserved money (over_application) but allocates money beyond it; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it leaves the payment as it was: nothing unapplied, refunded or pending, its facts unchanged; services-accounting:modules/transactions/tests/integration/services/refunds/refund-timeout-before-send.integration.spec.js#it leaves the refund processing a day on, never failed as never received and never abandoned; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-007-resolve-lost-processor-answers-and-clear-bank-debits.md#WF-ACC-TRX-007; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-009-request-approve-and-pay-a-refund.md#WF-ACC-TRX-009; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-010-reverse-billing-in-one-operation.md#WF-ACC-TRX-010; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-013-apply-payment-events-from-the-integration-platform.md#WF-ACC-TRX-013; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-014-reverse-billing-in-one-operation.md#BR-CAP-ACC-TRX-014-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-014-reverse-billing-in-one-operation.md#BR-CAP-ACC-TRX-014-07; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-003-reduce-or-add-to-an-issued-invoice-with-credit-and-debit.md#BR-CAP-ACC-TRX-003-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03 test_bindings: [] binding_review: [] evidence: - >- services-accounting at f47cb263875bbc0c5640fba7dae6785ec32695f8: the test files named in bound_to. - >- react-console at baf6dae382d6f41dce976c7f848667ccc37e076f: the Playwright journeys ACT-ACC-0311 to 0314, 0346. - >- rhythm-v2-docs:specs/accounting/transactions/design: related workflows, domain invariants and state transitions examined for the back-fill. coverage: rule: covered transition: 'gap: FND-ACC-TRX-077' validation: covered permission: covered edge: covered failure: covered boundary: covered concurrency: covered invariant: 'gap: FND-ACC-TRX-077' interaction: covered coverage_notes: invariant: >- No dedicated invariant scenario covers the applicable conditions; the finding identifies the remaining specification work. transition: >- Selected transition scenarios exist, but the listed state paths still need explicit guard, effect and actor mappings. interaction_coverage: - to: CAP-ACC-TRX-003 scenarios: - ATS-ACC-TRX-012-12 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it refuses allocating the reserved money (over_application) but allocates money beyond it; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it leaves the payment as it was: nothing unapplied, refunded or pending, its facts unchanged; services-accounting:modules/transactions/tests/integration/services/refunds/refund-timeout-before-send.integration.spec.js#it leaves the refund processing a day on, never failed as never received and never abandoned; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-007-resolve-lost-processor-answers-and-clear-bank-debits.md#WF-ACC-TRX-007; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-009-request-approve-and-pay-a-refund.md#WF-ACC-TRX-009; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-010-reverse-billing-in-one-operation.md#WF-ACC-TRX-010; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-013-apply-payment-events-from-the-integration-platform.md#WF-ACC-TRX-013; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-014-reverse-billing-in-one-operation.md#BR-CAP-ACC-TRX-014-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-014-reverse-billing-in-one-operation.md#BR-CAP-ACC-TRX-014-07; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-003-reduce-or-add-to-an-issued-invoice-with-credit-and-debit.md#BR-CAP-ACC-TRX-003-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03 - to: CAP-ACC-TRX-007 scenarios: - ATS-ACC-TRX-012-12 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it refuses allocating the reserved money (over_application) but allocates money beyond it; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it leaves the payment as it was: nothing unapplied, refunded or pending, its facts unchanged; services-accounting:modules/transactions/tests/integration/services/refunds/refund-timeout-before-send.integration.spec.js#it leaves the refund processing a day on, never failed as never received and never abandoned; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-007-resolve-lost-processor-answers-and-clear-bank-debits.md#WF-ACC-TRX-007; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-009-request-approve-and-pay-a-refund.md#WF-ACC-TRX-009; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-010-reverse-billing-in-one-operation.md#WF-ACC-TRX-010; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-013-apply-payment-events-from-the-integration-platform.md#WF-ACC-TRX-013; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-014-reverse-billing-in-one-operation.md#BR-CAP-ACC-TRX-014-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-014-reverse-billing-in-one-operation.md#BR-CAP-ACC-TRX-014-07; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-003-reduce-or-add-to-an-issued-invoice-with-credit-and-debit.md#BR-CAP-ACC-TRX-003-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03 - to: CAP-ACC-TRX-009 scenarios: - ATS-ACC-TRX-012-12 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it refuses allocating the reserved money (over_application) but allocates money beyond it; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it leaves the payment as it was: nothing unapplied, refunded or pending, its facts unchanged; services-accounting:modules/transactions/tests/integration/services/refunds/refund-timeout-before-send.integration.spec.js#it leaves the refund processing a day on, never failed as never received and never abandoned; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-007-resolve-lost-processor-answers-and-clear-bank-debits.md#WF-ACC-TRX-007; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-009-request-approve-and-pay-a-refund.md#WF-ACC-TRX-009; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-010-reverse-billing-in-one-operation.md#WF-ACC-TRX-010; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-013-apply-payment-events-from-the-integration-platform.md#WF-ACC-TRX-013; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-014-reverse-billing-in-one-operation.md#BR-CAP-ACC-TRX-014-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-014-reverse-billing-in-one-operation.md#BR-CAP-ACC-TRX-014-07; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-003-reduce-or-add-to-an-issued-invoice-with-credit-and-debit.md#BR-CAP-ACC-TRX-003-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03 - to: CAP-ACC-TRX-011 scenarios: - ATS-ACC-TRX-012-12 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it refuses allocating the reserved money (over_application) but allocates money beyond it; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it leaves the payment as it was: nothing unapplied, refunded or pending, its facts unchanged; services-accounting:modules/transactions/tests/integration/services/refunds/refund-timeout-before-send.integration.spec.js#it leaves the refund processing a day on, never failed as never received and never abandoned; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-007-resolve-lost-processor-answers-and-clear-bank-debits.md#WF-ACC-TRX-007; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-009-request-approve-and-pay-a-refund.md#WF-ACC-TRX-009; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-010-reverse-billing-in-one-operation.md#WF-ACC-TRX-010; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-013-apply-payment-events-from-the-integration-platform.md#WF-ACC-TRX-013; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-014-reverse-billing-in-one-operation.md#BR-CAP-ACC-TRX-014-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-014-reverse-billing-in-one-operation.md#BR-CAP-ACC-TRX-014-07; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-003-reduce-or-add-to-an-issued-invoice-with-credit-and-debit.md#BR-CAP-ACC-TRX-003-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03 - to: CAP-ACC-TRX-013 scenarios: - ATS-ACC-TRX-012-12 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it refuses allocating the reserved money (over_application) but allocates money beyond it; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it leaves the payment as it was: nothing unapplied, refunded or pending, its facts unchanged; services-accounting:modules/transactions/tests/integration/services/refunds/refund-timeout-before-send.integration.spec.js#it leaves the refund processing a day on, never failed as never received and never abandoned; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-007-resolve-lost-processor-answers-and-clear-bank-debits.md#WF-ACC-TRX-007; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-009-request-approve-and-pay-a-refund.md#WF-ACC-TRX-009; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-010-reverse-billing-in-one-operation.md#WF-ACC-TRX-010; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-013-apply-payment-events-from-the-integration-platform.md#WF-ACC-TRX-013; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-014-reverse-billing-in-one-operation.md#BR-CAP-ACC-TRX-014-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-014-reverse-billing-in-one-operation.md#BR-CAP-ACC-TRX-014-07; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-003-reduce-or-add-to-an-issued-invoice-with-credit-and-debit.md#BR-CAP-ACC-TRX-003-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03 - to: CAP-ACC-TRX-014 scenarios: - ATS-ACC-TRX-012-12 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it refuses allocating the reserved money (over_application) but allocates money beyond it; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it leaves the payment as it was: nothing unapplied, refunded or pending, its facts unchanged; services-accounting:modules/transactions/tests/integration/services/refunds/refund-timeout-before-send.integration.spec.js#it leaves the refund processing a day on, never failed as never received and never abandoned; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-007-resolve-lost-processor-answers-and-clear-bank-debits.md#WF-ACC-TRX-007; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-009-request-approve-and-pay-a-refund.md#WF-ACC-TRX-009; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-010-reverse-billing-in-one-operation.md#WF-ACC-TRX-010; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-013-apply-payment-events-from-the-integration-platform.md#WF-ACC-TRX-013; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-014-reverse-billing-in-one-operation.md#BR-CAP-ACC-TRX-014-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-014-reverse-billing-in-one-operation.md#BR-CAP-ACC-TRX-014-07; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-003-reduce-or-add-to-an-issued-invoice-with-credit-and-debit.md#BR-CAP-ACC-TRX-003-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03 - to: CAP-ACC-TRX-020 scenarios: - ATS-ACC-TRX-012-12 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it refuses allocating the reserved money (over_application) but allocates money beyond it; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it leaves the payment as it was: nothing unapplied, refunded or pending, its facts unchanged; services-accounting:modules/transactions/tests/integration/services/refunds/refund-timeout-before-send.integration.spec.js#it leaves the refund processing a day on, never failed as never received and never abandoned; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-007-resolve-lost-processor-answers-and-clear-bank-debits.md#WF-ACC-TRX-007; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-009-request-approve-and-pay-a-refund.md#WF-ACC-TRX-009; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-010-reverse-billing-in-one-operation.md#WF-ACC-TRX-010; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-013-apply-payment-events-from-the-integration-platform.md#WF-ACC-TRX-013; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#BR-CAP-ACC-TRX-012-09; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-007-take-card-and-bank-payments-through-the-processor.md#BR-CAP-ACC-TRX-007-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-013-undo-a-payment-whose-money-did-not-stay.md#BR-CAP-ACC-TRX-013-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-014-reverse-billing-in-one-operation.md#BR-CAP-ACC-TRX-014-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-014-reverse-billing-in-one-operation.md#BR-CAP-ACC-TRX-014-07; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-020-let-commerce-and-the-processor-work-with-accounting-safely.md#BR-CAP-ACC-TRX-020-08; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-003-reduce-or-add-to-an-issued-invoice-with-credit-and-debit.md#BR-CAP-ACC-TRX-003-04; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-009-settle-a-customer-s-invoices-in-one-step.md#BR-CAP-ACC-TRX-009-10; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-011-give-a-customer-credit-and-apply-it.md#BR-CAP-ACC-TRX-011-03 transition_coverage: - state_model: STATE-ACC-TRX-010 transition: 1 gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/refunds.table.ts; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it refuses more than an allocation holds (over_refund) and more than the unapplied money (over_refund) - state_model: STATE-ACC-TRX-010 transition: 2 gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/refunds.table.ts; 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) - state_model: STATE-ACC-TRX-010 transition: 3 gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/refunds.table.ts; 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) - state_model: STATE-ACC-TRX-010 transition: 4 gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/refunds.table.ts; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it refuses executing it again (refund_not_requested) and cancelling it (refund_not_cancellable) - state_model: STATE-ACC-TRX-010 transition: 5 gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/refunds.table.ts; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it refuses executing it again (refund_not_requested) and cancelling it (refund_not_cancellable) - state_model: STATE-ACC-TRX-010 transition: 6 gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/refunds.table.ts; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it records it offline: executed, the payment partially_refunded with 1000 refunded (FC-11, FC-14) - state_model: STATE-ACC-TRX-010 transition: 7 gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/refunds.table.ts; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it leaves the payment as it was: nothing unapplied, refunded or pending, its facts unchanged - state_model: STATE-ACC-TRX-010 transition: 8 gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/refunds.table.ts; services-accounting:modules/transactions/tests/integration/services/reversals/reversal-refund-status.integration.spec.js#it turns succeeded and completed when the signed event settles the refund - state_model: STATE-ACC-TRX-010 transition: 9 gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/refunds.table.ts; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it leaves the payment as it was: nothing unapplied, refunded or pending, its facts unchanged - state_model: STATE-ACC-TRX-010 transition: 10 gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/refunds.table.ts; services-accounting:modules/transactions/tests/integration/services/refunds/refund-timeout-before-send.integration.spec.js#it leaves the refund processing a day on, never failed as never received and never abandoned - state_model: STATE-ACC-TRX-006 transition: 1 gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/receive-offline.integration.spec.js#it refuses a date in no open period (period_not_open) - state_model: STATE-ACC-TRX-006 transition: 2 gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it settles the one the bank cleared: succeeded, settled_at, its capture item eligible, the settle event - state_model: STATE-ACC-TRX-006 transition: 3 gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it settles the one the bank cleared: succeeded, settled_at, its capture item eligible, the settle event - state_model: STATE-ACC-TRX-006 transition: 4 gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it settles the one the bank cleared: succeeded, settled_at, its capture item eligible, the settle event - state_model: STATE-ACC-TRX-006 transition: 5 gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it records it offline: executed, the payment partially_refunded with 1000 refunded (FC-11, FC-14) - state_model: STATE-ACC-TRX-006 transition: 6 gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it records it offline: executed, the payment partially_refunded with 1000 refunded (FC-11, FC-14) - state_model: STATE-ACC-TRX-006 transition: 7 gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it records it offline: executed, the payment partially_refunded with 1000 refunded (FC-11, FC-14) - state_model: STATE-ACC-TRX-006 transition: 8 gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it reverses the live allocation so the line owes again, and the payment item’s facts sum to zero (FC-16) - state_model: STATE-ACC-TRX-006 transition: 9 gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/payment-reversals.integration.spec.js#it refuses a kind the method does not allow (reversal_kind_mismatch): an ACH return of a check, a bounced check of a card - state_model: STATE-ACC-TRX-006 transition: 10 gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing scenarios establish selected paths; this exact guard, side-effect and actor combination still needs an explicit scenario mapping. evidence: - >- services-accounting:modules/transactions/services/payments/payment-receive.ts; services-accounting:modules/transactions/services/payments/payment-reverse.ts; services-accounting:modules/transactions/services/refunds/refund-commands.ts; services-accounting:modules/transactions/db/payments.table.ts; services-accounting:modules/transactions/tests/integration/services/payments/dispute-inquiry-lost.integration.spec.js#it writes no payment reversal and leaves the payment succeeded, nothing reversed permission_coverage: - key: accounting.refunds.create where_checked: api gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing permission scenarios are retained; assertion-level coverage of this grant at every declared surface remains unverified. evidence: - >- rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#CAP-ACC-TRX-012 - key: accounting.refunds.read where_checked: api gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing permission scenarios are retained; assertion-level coverage of this grant at every declared surface remains unverified. evidence: - >- rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#CAP-ACC-TRX-012 - key: accounting.refunds.approve where_checked: api gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing permission scenarios are retained; assertion-level coverage of this grant at every declared surface remains unverified. evidence: - >- rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#CAP-ACC-TRX-012 - key: accounting.refunds.execute where_checked: api gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 note: >- Existing permission scenarios are retained; assertion-level coverage of this grant at every declared surface remains unverified. evidence: - >- rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-012-pay-money-back-with-refunds.md#CAP-ACC-TRX-012 rule_coverage: - rule: BR-CAP-ACC-TRX-012-01 scenarios: - ATS-ACC-TRX-012-01 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it refuses more than an allocation holds (over_refund) and more than the unapplied money (over_refund) - rule: BR-CAP-ACC-TRX-012-02 scenarios: - ATS-ACC-TRX-012-02 - ATS-ACC-TRX-012-12 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it refuses allocating the reserved money (over_application) but allocates money beyond it - rule: BR-CAP-ACC-TRX-012-03 scenarios: - ATS-ACC-TRX-012-03 provenance: proposed source: >- 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 - rule: BR-CAP-ACC-TRX-012-04 scenarios: - ATS-ACC-TRX-012-04 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it keeps the invoice settled for the credited 2000 (a credit memo line) and reopens the 1000: the line owes 1000 - rule: BR-CAP-ACC-TRX-012-05 scenarios: - ATS-ACC-TRX-012-05 provenance: proposed source: >- 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) - rule: BR-CAP-ACC-TRX-012-06 scenarios: - ATS-ACC-TRX-012-06 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it refuses executing it again (refund_not_requested) and cancelling it (refund_not_cancellable) - rule: BR-CAP-ACC-TRX-012-07 scenarios: - ATS-ACC-TRX-012-07 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it records it offline: executed, the payment partially_refunded with 1000 refunded (FC-11, FC-14) - rule: BR-CAP-ACC-TRX-012-08 scenarios: - ATS-ACC-TRX-012-08 - ATS-ACC-TRX-012-12 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it leaves the payment as it was: nothing unapplied, refunded or pending, its facts unchanged - rule: BR-CAP-ACC-TRX-012-09 scenarios: - ATS-ACC-TRX-012-09 - ATS-ACC-TRX-012-12 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-timeout-before-send.integration.spec.js#it leaves the refund processing a day on, never failed as never received and never abandoned - rule: BR-CAP-ACC-TRX-012-11 scenarios: - ATS-ACC-TRX-012-10 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/settlements/card-fees.integration.spec.js#it takes the fee’s share back with the line: 2000 of 4000 refunded is 2065, the fee invoice credited 65 - rule: BR-CAP-ACC-TRX-012-12 scenarios: - ATS-ACC-TRX-012-11 provenance: proposed source: >- services-accounting:modules/transactions/tests/e2e/refunds.e2e.spec.js#it is refused approve without .approve, execute without .execute and cancel without .create, as a reader (403) executable_gaps: - scenario: ATS-ACC-TRX-012-12 gap: FND-ACC-TRX-077 provenance: unknown source: FND-ACC-TRX-077 evidence: - >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it refuses allocating the reserved money (over_application) but allocates money beyond it; services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it leaves the payment as it was: nothing unapplied, refunded or pending, its facts unchanged; services-accounting:modules/transactions/tests/integration/services/refunds/refund-timeout-before-send.integration.spec.js#it leaves the refund processing a day on, never failed as never received and never abandoned; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-007-resolve-lost-processor-answers-and-clear-bank-debits.md#WF-ACC-TRX-007; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-009-request-approve-and-pay-a-refund.md#WF-ACC-TRX-009; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-010-reverse-billing-in-one-operation.md#WF-ACC-TRX-010; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-013-apply-payment-events-from-the-integration-platform.md#WF-ACC-TRX-013 invariant_coverage: - invariant: INV-DOM-ACC-TRX-003-13 scenarios: - ATS-ACC-TRX-012-02 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refund-reservation.integration.spec.js#it refuses allocating the reserved money (over_application) but allocates money beyond it note: >- The cited scenario and its constituent test assertions are the proof boundary. - invariant: INV-DOM-ACC-TRX-003-14 scenarios: - ATS-ACC-TRX-012-05 provenance: test source: >- 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) note: >- The cited scenario and its constituent test assertions are the proof boundary. - invariant: INV-DOM-ACC-TRX-003-15 scenarios: - ATS-ACC-TRX-012-06 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/refunds/refunds.integration.spec.js#it refuses executing it again (refund_not_requested) and cancelling it (refund_not_cancellable) note: >- The cited scenario and its constituent test assertions are the proof boundary. --- # Return customer money with accountable refunds: Capability Test Specification ## Coverage The category map separates specified examples from recorded gaps. The table lists a scenario or finding for each rule requiring proof; a listed scenario may still be proposed. Executable bindings cover their cited assertions, while the transition, permission and invariant registers identify combinations that need further proof. | Required rule | Scenario or finding | |---|---| | `BR-CAP-ACC-TRX-012-01` | `ATS-ACC-TRX-012-01` | | `BR-CAP-ACC-TRX-012-02` | `ATS-ACC-TRX-012-02`, `ATS-ACC-TRX-012-12` | | `BR-CAP-ACC-TRX-012-03` | `ATS-ACC-TRX-012-03` | | `BR-CAP-ACC-TRX-012-04` | `ATS-ACC-TRX-012-04` | | `BR-CAP-ACC-TRX-012-05` | `ATS-ACC-TRX-012-05` | | `BR-CAP-ACC-TRX-012-06` | `ATS-ACC-TRX-012-06` | | `BR-CAP-ACC-TRX-012-07` | `ATS-ACC-TRX-012-07` | | `BR-CAP-ACC-TRX-012-08` | `ATS-ACC-TRX-012-08`, `ATS-ACC-TRX-012-12` | | `BR-CAP-ACC-TRX-012-09` | `ATS-ACC-TRX-012-09`, `ATS-ACC-TRX-012-12` | | `BR-CAP-ACC-TRX-012-11` | `ATS-ACC-TRX-012-10` | | `BR-CAP-ACC-TRX-012-12` | `ATS-ACC-TRX-012-11` | ## Interactions With Related Capabilities Cancel 40.00 of a card-paid bill with refund treatment, retain the processing return, deliver a success event twice and inspect the cancellation and source receipt. In separate branches use recovery lookup, a definite decline and processor void. Include an uncertain credit-and-card settlement in a separate branch and inspect its pending credit application before recovery. One confirmation completes the return and its cancellation; duplicate delivery changes nothing; decline restores held value and leaves a cancellation exception; recovery and void retain their distinct outcomes. The complete chain remains proposed until one executable run proves its combined outcomes.