--- id: TST-ACC-TRX-126 title: Settlements suite kind: integration product_area: accounting module: transactions revision: 1 status: draft source_sha: services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8 repository: services-accounting files: - >- modules/transactions/tests/integration/services/settlements/settlements.integration.spec.js implements: - ATS-ACC-TRX-009-02 - ATS-ACC-TRX-009-04 - ATS-ACC-TRX-009-05 - ATS-ACC-TRX-009-06 - ATS-ACC-TRX-009-07 - ATS-ACC-TRX-009-11 - ATS-ACC-TRX-009-13 implements_parts: - scenario: ATS-ACC-TRX-009-02 assertion: it refuses settling an invoice that owes nothing (nothing_to_allocate) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/settlements/settlements.integration.spec.js#it refuses settling an invoice that owes nothing (nothing_to_allocate) - scenario: ATS-ACC-TRX-009-04 assertion: >- it applies the open credit’s 500 first and takes a check of 8000 for the rest: completed with its payment provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/settlements/settlements.integration.spec.js#it applies the open credit’s 500 first and takes a check of 8000 for the rest: completed with its payment - scenario: ATS-ACC-TRX-009-04 assertion: >- it allocated the check by the plan: 4000 to the first line (what the credit left) and 4000 to the second; the invoice paid provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/settlements/settlements.integration.spec.js#it allocated the check by the plan: 4000 to the first line (what the credit left) and 4000 to the second; the invoice paid - scenario: ATS-ACC-TRX-009-05 assertion: >- it refuses with the decline (processor_declined), the settlement failed with the code, the reservation released, nothing applied provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/settlements/settlements.integration.spec.js#it refuses with the decline (processor_declined), the settlement failed with the code, the reservation released, nothing applied - scenario: ATS-ACC-TRX-009-06 assertion: >- it completes in the request’s transaction: numbered from 1,000,000, 1500 of credit, no payment, the resolve, reserve_credits and complete steps done provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/settlements/settlements.integration.spec.js#it completes in the request’s transaction: numbered from 1,000,000, 1500 of credit, no payment, the resolve, reserve_credits and complete steps done - scenario: ATS-ACC-TRX-009-06 assertion: >- it refuses a payment of nothing: a settlement’s payment is greater than zero, and nothing is written provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/settlements/settlements.integration.spec.js#it refuses a payment of nothing: a settlement’s payment is greater than zero, and nothing is written - scenario: ATS-ACC-TRX-009-07 assertion: >- it completes with an overpayment credit of 1000 made from the payment, the payment’s unapplied money gone into it provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/settlements/settlements.integration.spec.js#it completes with an overpayment credit of 1000 made from the payment, the payment’s unapplied money gone into it - scenario: ATS-ACC-TRX-009-07 assertion: >- it refuses more than the lines owe when the treatment is refuse (over_application), writing nothing provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/settlements/settlements.integration.spec.js#it refuses more than the lines owe when the treatment is refuse (over_application), writing nothing - scenario: ATS-ACC-TRX-009-11 assertion: >- it leaves a lost answer pending with its intent, and the sweeper completes it: the payment recorded, the credit applied (FC-22) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/settlements/settlements.integration.spec.js#it leaves a lost answer pending with its intent, and the sweeper completes it: the payment recorded, the credit applied (FC-22) - scenario: ATS-ACC-TRX-009-11 assertion: >- it is failed abandoned by the sweeper a day later, the reservation released provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/settlements/settlements.integration.spec.js#it is failed abandoned by the sweeper a day later, the reservation released - scenario: ATS-ACC-TRX-009-13 assertion: >- it leaves a lost answer pending with its intent, and the sweeper completes it: the payment recorded, the credit applied (FC-22) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/settlements/settlements.integration.spec.js#it leaves a lost answer pending with its intent, and the sweeper completes it: the payment recorded, the credit applied (FC-22) environment: local implementation_state: implemented latest_result: not-run latest_run_at: null latest_run_ref: null conformance: not-verified estimated_minutes: 3 isolation: >- Suite-marked records in the prepared local test database; fixture teardown removes owned records. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/settlements/settlements.integration.spec.js evidence: - provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/settlements/settlements.integration.spec.js assertion_titles: - the settlement operation (integration) - credit alone - >- completes in the request’s transaction: numbered from 1,000,000, 1500 of credit, no payment, the resolve, reserve_credits and complete steps done - >- applied the credit to the line through an application of the settlement: the line paid 1500, the credit’s balance 500, nothing reserved - replays the same key and body as the same settlement - credits and a check - >- applies the open credit’s 500 first and takes a check of 8000 for the rest: completed with its payment - >- allocated the check by the plan: 4000 to the first line (what the credit left) and 4000 to the second; the invoice paid - refuses settling an invoice that owes nothing (nothing_to_allocate) - >- refuses a payment of nothing: a settlement’s payment is greater than zero, and nothing is written - an overpayment - >- completes with an overpayment credit of 1000 made from the payment, the payment’s unapplied money gone into it - >- refuses more than the lines owe when the treatment is refuse (over_application), writing nothing - 'a card the processor answers late, or declines' - >- refuses with the decline (processor_declined), the settlement failed with the code, the reservation released, nothing applied - >- leaves a lost answer pending with its intent, and the sweeper completes it: the payment recorded, the credit applied (FC-22) - a settlement whose payment never came - >- left the settlement pending with no intent, the credit reserved for it (premise) - 'is failed abandoned by the sweeper a day later, the reservation released' imports: - >- const { manualClock } = require('@rhythmsoftware/macroservice-time/clock'); - 'const { stage } = require(''@rhythmsoftware/macroservice-testing/stage'');' - >- const { TEST_NOW } = require('@rhythmsoftware/macroservice-testing/execution-context'); - >- const { createCredit } = require('../../../../services/credits/credit-commands'); - >- const { sweepProcessingIntents } = require('../../../../services/payments/intent-sweeper'); - >- const { findSettlementOfKey, settle } = require('../../../../services/settlements/settlement-commands'); - '} = require(''../../payments-fixtures'');' - "\t\t\tconst { invoice, credit } = world.require();" - "\t\t\tconst outcome = byCredit.require();" - "\t\t\tconst { invoice, credit } = world.require();" - "\t\t\tconst outcome = byCredit.require();" - "\t\t\tconst { invoice, credit } = world.require();" - "\t\t\texpect(again.settlement.id).to.equal(byCredit.require().settlement.id);" - "\t\t\tconst { invoice } = world.require();" - "\t\t\tconst { credit } = world.require();" - "\t\t\tconst outcome = mixed.require();" - "\t\t\tconst { invoice } = world.require();" - "\t\t\tconst outcome = mixed.require();" - "\t\t\tconst { invoice } = world.require();" - "\t\t\tconst { outcome } = over.require();" - "\t\t\tconst { invoice } = over.require();" - "\t\t\tconst { invoice, credit, refusal, row } = declined.require();" - "\t\t\tconst { invoice, credit } = declined.require();" - "\t\t\tconst { credit, refusal, row } = stale.require();" - "\t\t\tconst { credit, row } = stale.require();" test_double_declarations: [] --- # Settlements suite ## Verification Boundary The suite exercises transaction commands and database protections in the local prepared test environment. Registration records the existing executable file; it does not report a run or establish product approval. ## What This Suite Proves Its cited assertions contribute evidence for empty debt cannot start settlement; credit precedes the remainder tender; definite failure releases value for retry; credit-only settlement explains extra money; overpayment treatment is explicit; scheduled work resolves or abandons pending settlement. The structured assertion bindings identify which parts of combined scenarios it executes. ## What It Does Not Prove Local commands and route invocations do not establish deployed routing, live processor guarantees or the complete staff browser experience. An unbound feature chain remains proposed, and this registration carries no execution result. ## Real Dependencies and Test Doubles The suite uses the imported commands, route handlers or persistence code against the local test database. Fixture helpers supply accounting context; any stepped clock, dummy processor or substituted external client is retained in the evidence declarations. ## Must Not Be Doubled The command or persistence behavior under assertion and its relevant database protections must remain real. Substituting the final financial result removes evidence of transactional effects.