--- id: ATS-ACC-TRX-010 scope: CAP-ACC-TRX-010 product_area: accounting module: transactions revision: 1 status: proposed approved_by: null approved_at: null source_sha: services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8 scenarios: - id: ATS-ACC-TRX-010-01 title: Remittance authority also requires payment access level: api proves: - BR-CAP-ACC-TRX-010-01 preconditions: A reader and remittance-only identity exist. steps: - do: >- Attempt entry and void as reader and inspect with remittance access alone. provenance: test source: >- services-accounting:modules/transactions/tests/e2e/remittances.e2e.spec.js#it is refused recording and voiding as a reader, and reading as one without the payments’ key (403) expected: Combined authority checks deny each operation. negative: true data_needs: Read-only and incomplete-access personas. bound_to: - >- services-accounting:modules/transactions/tests/e2e/remittances.e2e.spec.js#it is refused recording and voiding as a reader, and reading as one without the payments’ key (403) - TST-ACC-TRX-014 provenance: test source: >- services-accounting:modules/transactions/tests/e2e/remittances.e2e.spec.js#it is refused recording and voiding as a reader, and reading as one without the payments’ key (403) category: permission test_bindings: - file: >- services-accounting:modules/transactions/tests/e2e/remittances.e2e.spec.js assertion: >- it is refused recording and voiding as a reader, and reading as one without the payments’ key (403) provenance: test source: >- services-accounting:modules/transactions/tests/e2e/remittances.e2e.spec.js#it is refused recording and voiding as a reader, and reading as one without the payments’ key (403) binding_review: [] - id: ATS-ACC-TRX-010-02 title: Unstated excess is a total mismatch level: api proves: - BR-CAP-ACC-TRX-010-03 - INV-DOM-ACC-TRX-003-17 preconditions: The selected target value is 180.00. steps: - do: Send 190.00 with no remainder and 200.00 with 10.00 remainder. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a total that is not the lines plus the remainder, writing nothing: remittance_total_mismatch expected: Both mismatched totals fail without recording. negative: true data_needs: An expected invoice. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a total that is not the lines plus the remainder, writing nothing: remittance_total_mismatch - >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a remainder left unstated: the total of 200.00 over a line of 180.00 is a mismatch, not an inferred remainder - TST-ACC-TRX-111 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a total that is not the lines plus the remainder, writing nothing: remittance_total_mismatch category: validation test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js assertion: >- it refuses a total that is not the lines plus the remainder, writing nothing: remittance_total_mismatch provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a total that is not the lines plus the remainder, writing nothing: remittance_total_mismatch - file: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js assertion: >- it refuses a remainder left unstated: the total of 200.00 over a line of 180.00 is a mismatch, not an inferred remainder provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a remainder left unstated: the total of 200.00 over a line of 180.00 is a mismatch, not an inferred remainder binding_review: [] - id: ATS-ACC-TRX-010-03 title: Remittance method must be offline and valid level: api proves: - BR-CAP-ACC-TRX-010-04 preconditions: Card and directly selected reference-required check methods exist. steps: - do: 'Record with card, then with check lacking its number.' provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a card method: remittance_method_not_offline expected: Method and reference checks reject the requests. negative: true data_needs: Configured receipt methods. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a card method: remittance_method_not_offline - >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a paper check without its number: payment_reference_required - TST-ACC-TRX-111 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a card method: remittance_method_not_offline category: validation test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js assertion: 'it refuses a card method: remittance_method_not_offline' provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a card method: remittance_method_not_offline - file: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js assertion: >- it refuses a paper check without its number: payment_reference_required provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a paper check without its number: payment_reference_required binding_review: [] - id: ATS-ACC-TRX-010-04 title: Invalid member lines roll back the receipt level: api proves: - BR-CAP-ACC-TRX-010-05 preconditions: >- Cases include paid, foreign-currency, foreign-member, duplicate and excessive targets. steps: - do: 'Record each case, placing excessive value after earlier valid members.' provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a line whose stated bill-to is not its invoice’s: business_unit_mismatch expected: Every invalid request fails and earlier generated payments roll back. negative: true data_needs: Expected invoices across several members. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses an invoice that is not open (paid): remittance_invoice_not_open - >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses an invoice in another currency: currency_mismatch - >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a line whose stated bill-to is not its invoice’s: business_unit_mismatch - >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses an invoice named twice - >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a line for more than its invoice owes after another bill-to’s payment was made, rolling that payment back too: over_application - TST-ACC-TRX-111 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a line whose stated bill-to is not its invoice’s: business_unit_mismatch category: failure test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js assertion: >- it refuses an invoice that is not open (paid): remittance_invoice_not_open provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses an invoice that is not open (paid): remittance_invoice_not_open - file: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js assertion: 'it refuses an invoice in another currency: currency_mismatch' provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses an invoice in another currency: currency_mismatch - file: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js assertion: >- it refuses a line whose stated bill-to is not its invoice’s: business_unit_mismatch provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a line whose stated bill-to is not its invoice’s: business_unit_mismatch - file: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js assertion: it refuses an invoice named twice provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses an invoice named twice - file: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js assertion: >- it refuses a line for more than its invoice owes after another bill-to’s payment was made, rolling that payment back too: over_application provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a line for more than its invoice owes after another bill-to’s payment was made, rolling that payment back too: over_application binding_review: [] - id: ATS-ACC-TRX-010-05 title: Employer excess stays with the employer level: api proves: - BR-CAP-ACC-TRX-010-06 preconditions: Payroll expects 212 invoices but four members have left. steps: - do: Record the 208 selected invoices and an explicit remainder. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js#it allocates each member’s payment wholly to that member’s invoice, and leaves the remainder unapplied on Metro Transit expected: >- One transaction creates 208 member receipts and one employer-held remainder receipt with payer attribution. negative: false data_needs: A payroll remittance population. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js#it writes 209 payments in the one transaction: 208 members’ and the remainder on Metro Transit - >- services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js#it allocates each member’s payment wholly to that member’s invoice, and leaves the remainder unapplied on Metro Transit - >- services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js#it allocates every member payment to its own member’s invoice and to no one else’s - >- services-accounting:modules/transactions/tests/e2e/remittances.e2e.spec.js#it records three payments, the members’ allocated and the remainder unapplied on Metro Transit, each paid by Metro - TST-ACC-TRX-110 - TST-ACC-TRX-014 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js#it allocates each member’s payment wholly to that member’s invoice, and leaves the remainder unapplied on Metro Transit category: interaction test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js assertion: >- it writes 209 payments in the one transaction: 208 members’ and the remainder on Metro Transit provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js#it writes 209 payments in the one transaction: 208 members’ and the remainder on Metro Transit - file: >- services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js assertion: >- it allocates each member’s payment wholly to that member’s invoice, and leaves the remainder unapplied on Metro Transit provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js#it allocates each member’s payment wholly to that member’s invoice, and leaves the remainder unapplied on Metro Transit - file: >- services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js assertion: >- it allocates every member payment to its own member’s invoice and to no one else’s provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js#it allocates every member payment to its own member’s invoice and to no one else’s - file: >- services-accounting:modules/transactions/tests/e2e/remittances.e2e.spec.js assertion: >- it records three payments, the members’ allocated and the remainder unapplied on Metro Transit, each paid by Metro provenance: test source: >- services-accounting:modules/transactions/tests/e2e/remittances.e2e.spec.js#it records three payments, the members’ allocated and the remainder unapplied on Metro Transit, each paid by Metro binding_review: [] - id: ATS-ACC-TRX-010-06 title: Whole-receipt void requires untouched money level: api proves: - BR-CAP-ACC-TRX-010-07 preconditions: 'Separate remittances are reusable, externally allocated and posted.' steps: - do: Void each and repeat the first void. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it voids every payment it made, taking their allocations back and returning the remainder expected: >- Only the untouched receipt restores all debt; other and repeat requests preserve records. negative: false data_needs: Posted and reused-money variants. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it voids every payment it made, taking their allocations back and returning the remainder - >- services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it reopens the invoices it paid, each owing its 180.00 again - >- services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it refuses the void: remittance_payment_allocated - >- services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it refuses the void: remittance_posted - >- services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it refuses a second void: remittance_not_recorded - TST-ACC-TRX-112 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it voids every payment it made, taking their allocations back and returning the remainder category: transition test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js assertion: >- it voids every payment it made, taking their allocations back and returning the remainder provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it voids every payment it made, taking their allocations back and returning the remainder - file: >- services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js assertion: 'it reopens the invoices it paid, each owing its 180.00 again' provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it reopens the invoices it paid, each owing its 180.00 again - file: >- services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js assertion: 'it refuses the void: remittance_payment_allocated' provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it refuses the void: remittance_payment_allocated - file: >- services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js assertion: 'it refuses the void: remittance_posted' provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it refuses the void: remittance_posted - file: >- services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js assertion: 'it refuses a second void: remittance_not_recorded' provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it refuses a second void: remittance_not_recorded binding_review: [] - id: ATS-ACC-TRX-010-07 title: Remitter allocation changes customer standing together category: interaction level: api proves: - BR-CAP-ACC-TRX-010-05 - BR-CAP-ACC-TRX-010-06 - BR-CAP-ACC-TRX-010-07 - BR-CAP-ACC-TRX-008-01 - BR-CAP-ACC-TRX-008-02 - BR-CAP-ACC-TRX-017-01 - BR-CAP-ACC-TRX-017-04 exercises: - CAP-ACC-TRX-010 - CAP-ACC-TRX-008 - CAP-ACC-TRX-017 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: >- Record a combined receipt for two members with 80.00 and 40.00 debt and an explicit 20.00 remitter remainder. Read member and remitter standing, then void the untouched remittance. provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a line whose stated bill-to is not its invoice’s: business_unit_mismatch; services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js#it allocates each member’s payment wholly to that member’s invoice, and leaves the remainder unapplied on Metro Transit; services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it voids every payment it made, taking their allocations back and returning the remainder; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-012-record-and-void-a-remittance.md#WF-ACC-TRX-012; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-010-record-one-remitter-s-money-for-many-customers.md#BR-CAP-ACC-TRX-010-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-010-record-one-remitter-s-money-for-many-customers.md#BR-CAP-ACC-TRX-010-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-010-record-one-remitter-s-money-for-many-customers.md#BR-CAP-ACC-TRX-010-07; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-01; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-017-know-where-a-customer-stands.md#BR-CAP-ACC-TRX-017-01; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-017-know-where-a-customer-stands.md#BR-CAP-ACC-TRX-017-04 expected: >- Member receipts settle only their own debt; the remitter holds 20.00; the combined void restores both debts and removes the held remainder. 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/remittances/remittance-refusals.integration.spec.js#it refuses a line whose stated bill-to is not its invoice’s: business_unit_mismatch; services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js#it allocates each member’s payment wholly to that member’s invoice, and leaves the remainder unapplied on Metro Transit; services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it voids every payment it made, taking their allocations back and returning the remainder; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-012-record-and-void-a-remittance.md#WF-ACC-TRX-012; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-010-record-one-remitter-s-money-for-many-customers.md#BR-CAP-ACC-TRX-010-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-010-record-one-remitter-s-money-for-many-customers.md#BR-CAP-ACC-TRX-010-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-010-record-one-remitter-s-money-for-many-customers.md#BR-CAP-ACC-TRX-010-07; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-01; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-017-know-where-a-customer-stands.md#BR-CAP-ACC-TRX-017-01; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-017-know-where-a-customer-stands.md#BR-CAP-ACC-TRX-017-04 test_bindings: [] binding_review: [] - id: ATS-ACC-TRX-010-08 title: Remittance line count is tested at the accepted limit category: boundary level: api proves: - BR-CAP-ACC-TRX-010-08 preconditions: >- Two independently keyed offline receipt requests contain distinct eligible member invoices with matching total amounts. steps: - do: >- Submit the first with two hundred and fifty lines and the second with two hundred and fifty-one. provenance: proposed source: >- services-accounting:modules/transactions/aws/api/remittances.schemas.ts; services-accounting:modules/transactions/tests/unit/api/remittances-schemas.spec.js expected: >- The first records the receipt; the second is refused during input validation without creating member payments. negative: true data_needs: >- Branch-owned records in one configured workspace, valid accounting context and controlled requests at the stated boundary. bound_to: [] provenance: proposed source: >- services-accounting:modules/transactions/aws/api/remittances.schemas.ts; services-accounting:modules/transactions/tests/unit/api/remittances-schemas.spec.js test_bindings: [] binding_review: [] evidence: - >- services-accounting at f47cb263875bbc0c5640fba7dae6785ec32695f8: the test files named in bound_to. - >- rhythm-v2-docs:specs/accounting/transactions/design: related workflows, domain invariants and state transitions examined for the back-fill. coverage: rule: 'gap: FND-ACC-TRX-075' transition: 'gap: FND-ACC-TRX-075' validation: covered permission: covered edge: 'gap: FND-ACC-TRX-075' failure: covered boundary: covered concurrency: 'gap: FND-ACC-TRX-075' invariant: 'gap: FND-ACC-TRX-075' interaction: covered coverage_notes: rule: >- No dedicated rule scenario covers the applicable conditions; the finding identifies the remaining specification work. edge: >- No dedicated edge scenario covers the applicable conditions; the finding identifies the remaining specification work. concurrency: >- No dedicated concurrency scenario covers the applicable conditions; the finding identifies the remaining specification work. 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-008 scenarios: - ATS-ACC-TRX-010-07 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a line whose stated bill-to is not its invoice’s: business_unit_mismatch; services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js#it allocates each member’s payment wholly to that member’s invoice, and leaves the remainder unapplied on Metro Transit; services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it voids every payment it made, taking their allocations back and returning the remainder; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-012-record-and-void-a-remittance.md#WF-ACC-TRX-012; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-010-record-one-remitter-s-money-for-many-customers.md#BR-CAP-ACC-TRX-010-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-010-record-one-remitter-s-money-for-many-customers.md#BR-CAP-ACC-TRX-010-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-010-record-one-remitter-s-money-for-many-customers.md#BR-CAP-ACC-TRX-010-07; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-01; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-017-know-where-a-customer-stands.md#BR-CAP-ACC-TRX-017-01; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-017-know-where-a-customer-stands.md#BR-CAP-ACC-TRX-017-04 - to: CAP-ACC-TRX-017 scenarios: - ATS-ACC-TRX-010-07 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a line whose stated bill-to is not its invoice’s: business_unit_mismatch; services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js#it allocates each member’s payment wholly to that member’s invoice, and leaves the remainder unapplied on Metro Transit; services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it voids every payment it made, taking their allocations back and returning the remainder; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-012-record-and-void-a-remittance.md#WF-ACC-TRX-012; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-010-record-one-remitter-s-money-for-many-customers.md#BR-CAP-ACC-TRX-010-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-010-record-one-remitter-s-money-for-many-customers.md#BR-CAP-ACC-TRX-010-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-010-record-one-remitter-s-money-for-many-customers.md#BR-CAP-ACC-TRX-010-07; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-01; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-008-put-a-payment-s-money-on-the-right-invoices.md#BR-CAP-ACC-TRX-008-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-017-know-where-a-customer-stands.md#BR-CAP-ACC-TRX-017-01; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-017-know-where-a-customer-stands.md#BR-CAP-ACC-TRX-017-04 transition_coverage: - state_model: STATE-ACC-TRX-009 transition: 1 gap: FND-ACC-TRX-075 provenance: unknown source: FND-ACC-TRX-075 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/remittances/remittance-commands.ts; services-accounting:modules/transactions/db/remittances.table.ts; services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js#it allocates each member’s payment wholly to that member’s invoice, and leaves the remainder unapplied on Metro Transit - state_model: STATE-ACC-TRX-009 transition: 2 gap: FND-ACC-TRX-075 provenance: unknown source: FND-ACC-TRX-075 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/remittances/remittance-commands.ts; services-accounting:modules/transactions/db/remittances.table.ts; services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it voids every payment it made, taking their allocations back and returning the remainder - state_model: STATE-ACC-TRX-006 transition: 1 gap: FND-ACC-TRX-075 provenance: unknown source: FND-ACC-TRX-075 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-075 provenance: unknown source: FND-ACC-TRX-075 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-075 provenance: unknown source: FND-ACC-TRX-075 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-075 provenance: unknown source: FND-ACC-TRX-075 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-075 provenance: unknown source: FND-ACC-TRX-075 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-075 provenance: unknown source: FND-ACC-TRX-075 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-075 provenance: unknown source: FND-ACC-TRX-075 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-075 provenance: unknown source: FND-ACC-TRX-075 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-075 provenance: unknown source: FND-ACC-TRX-075 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-075 provenance: unknown source: FND-ACC-TRX-075 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.remittances.create where_checked: api gap: FND-ACC-TRX-075 provenance: unknown source: FND-ACC-TRX-075 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-010-record-one-remitter-s-money-for-many-customers.md#CAP-ACC-TRX-010 - key: accounting.remittances.read where_checked: api gap: FND-ACC-TRX-075 provenance: unknown source: FND-ACC-TRX-075 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-010-record-one-remitter-s-money-for-many-customers.md#CAP-ACC-TRX-010 - key: accounting.remittances.void where_checked: api gap: FND-ACC-TRX-075 provenance: unknown source: FND-ACC-TRX-075 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-010-record-one-remitter-s-money-for-many-customers.md#CAP-ACC-TRX-010 - key: accounting.payments.create where_checked: api gap: FND-ACC-TRX-075 provenance: unknown source: FND-ACC-TRX-075 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-010-record-one-remitter-s-money-for-many-customers.md#CAP-ACC-TRX-010 - key: accounting.payments.read where_checked: api gap: FND-ACC-TRX-075 provenance: unknown source: FND-ACC-TRX-075 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-010-record-one-remitter-s-money-for-many-customers.md#CAP-ACC-TRX-010 - key: accounting.payments.void where_checked: api gap: FND-ACC-TRX-075 provenance: unknown source: FND-ACC-TRX-075 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-010-record-one-remitter-s-money-for-many-customers.md#CAP-ACC-TRX-010 - key: accounting.invoices.read where_checked: api gap: FND-ACC-TRX-075 provenance: unknown source: FND-ACC-TRX-075 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-010-record-one-remitter-s-money-for-many-customers.md#CAP-ACC-TRX-010 - key: accounting.expected-remittances.query where_checked: service gap: FND-ACC-TRX-075 provenance: unknown source: FND-ACC-TRX-075 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-010-record-one-remitter-s-money-for-many-customers.md#CAP-ACC-TRX-010 rule_coverage: - rule: BR-CAP-ACC-TRX-010-01 scenarios: - ATS-ACC-TRX-010-01 provenance: proposed source: >- services-accounting:modules/transactions/tests/e2e/remittances.e2e.spec.js#it is refused recording and voiding as a reader, and reading as one without the payments’ key (403) - rule: BR-CAP-ACC-TRX-010-03 scenarios: - ATS-ACC-TRX-010-02 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a remainder left unstated: the total of 200.00 over a line of 180.00 is a mismatch, not an inferred remainder - rule: BR-CAP-ACC-TRX-010-04 scenarios: - ATS-ACC-TRX-010-03 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a card method: remittance_method_not_offline - rule: BR-CAP-ACC-TRX-010-05 scenarios: - ATS-ACC-TRX-010-04 - ATS-ACC-TRX-010-07 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a line whose stated bill-to is not its invoice’s: business_unit_mismatch - rule: BR-CAP-ACC-TRX-010-06 scenarios: - ATS-ACC-TRX-010-05 - ATS-ACC-TRX-010-07 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js#it allocates each member’s payment wholly to that member’s invoice, and leaves the remainder unapplied on Metro Transit - rule: BR-CAP-ACC-TRX-010-07 scenarios: - ATS-ACC-TRX-010-06 - ATS-ACC-TRX-010-07 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it voids every payment it made, taking their allocations back and returning the remainder executable_gaps: - scenario: ATS-ACC-TRX-010-07 gap: FND-ACC-TRX-075 provenance: unknown source: FND-ACC-TRX-075 evidence: - >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a line whose stated bill-to is not its invoice’s: business_unit_mismatch; services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js#it allocates each member’s payment wholly to that member’s invoice, and leaves the remainder unapplied on Metro Transit; services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it voids every payment it made, taking their allocations back and returning the remainder; rhythm-v2-docs:specs/accounting/transactions/design/workflows/WF-ACC-TRX-012-record-and-void-a-remittance.md#WF-ACC-TRX-012 - scenario: ATS-ACC-TRX-010-08 gap: FND-ACC-TRX-075 provenance: unknown source: FND-ACC-TRX-075 evidence: - >- services-accounting:modules/transactions/aws/api/remittances.schemas.ts; services-accounting:modules/transactions/tests/unit/api/remittances-schemas.spec.js invariant_coverage: - invariant: INV-DOM-ACC-TRX-003-17 scenarios: - ATS-ACC-TRX-010-02 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a remainder left unstated: the total of 200.00 over a line of 180.00 is a mismatch, not an inferred remainder note: >- The cited scenario and its constituent test assertions are the proof boundary. --- # Record a remitter’s combined customer receipt: 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-010-01` | `ATS-ACC-TRX-010-01` | | `BR-CAP-ACC-TRX-010-03` | `ATS-ACC-TRX-010-02` | | `BR-CAP-ACC-TRX-010-04` | `ATS-ACC-TRX-010-03` | | `BR-CAP-ACC-TRX-010-05` | `ATS-ACC-TRX-010-04`, `ATS-ACC-TRX-010-07` | | `BR-CAP-ACC-TRX-010-06` | `ATS-ACC-TRX-010-05`, `ATS-ACC-TRX-010-07` | | `BR-CAP-ACC-TRX-010-07` | `ATS-ACC-TRX-010-06`, `ATS-ACC-TRX-010-07` | ## Interactions With Related Capabilities Record a combined receipt for two members with 80.00 and 40.00 debt and an explicit 20.00 remitter remainder. Read member and remitter standing, then void the untouched remittance. Member receipts settle only their own debt; the remitter holds 20.00; the combined void restores both debts and removes the held remainder. The complete chain remains proposed until one executable run proves its combined outcomes.