Rhythm 2.0 Specifications

Appearance

CAP-ACC-TRX-010Record a remitter’s combined customer receipt

Markdown

CAP-ACC-TRX-010

Record a remitter’s combined customer receipt

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationObserved

Planning

Feature
FEAT-ACC-TRX-03
Exercised by
FAS-ACC-TRX-03-01, FAS-ACC-TRX-03-03, FAS-ACC-TRX-03-04
Key concepts
CON-ACC-TRX-003, CON-ACC-TRX-005
Actors
ACT-ACC-012
Depends on
CAP-ACC-TRX-006
Related
CAP-ACC-TRX-008, CAP-ACC-TRX-017
Proved by
ATS-ACC-TRX-010

Implementation

Executable suites
TST-ACC-TRX-014, TST-ACC-TRX-110, TST-ACC-TRX-111, TST-ACC-TRX-112

KindCapabilityProduct areaAccountingModuleTransactionsRevision1

Read atservices-accounting f47cb263react-console baf6dae3

Record a remitter’s combined customer receipt ​

Purpose ​

Staff account for one employer receipt and the individual customers it pays.

How It Works ​

The service offers expected invoices for the selected remitter. Staff select the members actually covered and state any remainder explicitly. Accounting accepts offline money and validates every target before completing the receipt. The current model produces separate member payments and a remainder payment for the employer. One invalid line prevents the entire recording. A permitted whole-receipt void restores the original invoice debt. The product should replace this interim split with the planned single-receipt model.

Relationships ​

  • Record receipts collected outside Rhythm supplies or continues the related financial work.
  • Allocate and relocate received money supplies or continues the related financial work.
  • Explain a customer’s current financial position supplies or continues the related financial work.

The Formal Contract

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

Outcomes
Staff account for one employer receipt and the individual customers it pays.A permitted whole-receipt void restores the original invoice debt. The product should replace this interim split with the planned single-receipt model.
Surfaces
api
Intent sources
services-accounting:docs/architecture/accounting-2.0/02-decisions.md#D-09services-accounting:docs/architecture/accounting-2.0/02-decisions.md#D-03services-accounting:docs/milestones/plans/ACCT-M2-plan.md#D1services-accounting:docs/milestones/plans/ACCT-M2-plan.md#D3

Controls

22 controls apply, from the corpus control catalogue.

TC-IAM-001 TC-IAM-002 TC-IAM-004 TC-IAM-005 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-006 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-LOG-004 TC-LOG-005 TC-PI-001 TC-PI-003 TC-PI-005 TC-PRV-001 TC-PRV-002

Permissions

KeyChecked atScope
accounting.remittances.createapitenant
accounting.remittances.readapitenant
accounting.remittances.voidapitenant
accounting.payments.createapitenant
accounting.payments.readapitenant
accounting.payments.voidapitenant
accounting.invoices.readapitenant
accounting.expected-remittances.queryservicetenant

Business Rules

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

IdRuleKindEnforced atProvenance
01must prove
Confirmed
Remittance entry, reading and voiding require both the remittance and matching payment authorities; expected-invoice lookup additionally requires invoice read authority.
origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#D-09
proved by ATS-ACC-TRX-010-01, TST-ACC-TRX-014
permissionapitest
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)
02
Confirmed
Expected remittances list outstanding invoices whose orders identify that remitter.
origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#D-03
policydatabase, servicetest
services-accounting:modules/transactions/tests/integration/db/expected-remittances-view.integration.spec.js#it lists only open invoices with a balance and a named remitter: the paid one and the two without a remitter are no rows
03must prove
Confirmed
Receipt total equals the selected lines plus an explicitly stated remainder; omitted remainder is never calculated automatically.
origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#D-09
proved by ATS-ACC-TRX-010-02, TST-ACC-TRX-111
validationservicetest
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
04must prove
Confirmed
Remittances accept offline methods only and enforce applicable reference requirements.
origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#D-09
proved by ATS-ACC-TRX-010-03, TST-ACC-TRX-111
validationservicetest
services-accounting:modules/transactions/tests/integration/services/remittances/remittance-refusals.integration.spec.js#it refuses a card method: remittance_method_not_offline
05must prove
Confirmed
Each unique target belongs to the stated member, unit and currency and receives no more than its outstanding value.
origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#D-09
proved by ATS-ACC-TRX-010-04, ATS-ACC-TRX-010-07, TST-ACC-TRX-111
validationservicetest
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
06must prove
Confirmed
Entry atomically creates a payment for each member and an unapplied remainder payment for the remitter; any invalid line rejects the entire receipt.
origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#D-09
proved by ATS-ACC-TRX-010-05, ATS-ACC-TRX-010-07, TST-ACC-TRX-014, TST-ACC-TRX-110
calculationservicetest
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
07must prove
Confirmed
Voiding requires a reason, reverses all generated payments and restores invoices, but fails after external reuse of money, posting or an earlier void.
origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#D-09
proved by ATS-ACC-TRX-010-06, ATS-ACC-TRX-010-07, TST-ACC-TRX-112
lifecycleservicetest
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
08
Confirmed
Remittance requests contain no more than two hundred and fifty lines.
origin: services-accounting:docs/architecture/accounting-2.0/02-decisions.md#D-09
proved by ATS-ACC-TRX-010-08
validationapitest
services-accounting:modules/transactions/tests/unit/api/remittances-schemas.spec.js#it refuses no lines, and more than 250
09
Proposed
The product should replace the interim per-member payment split with a single receipt allocated across customers in the later receipt milestone.
policyservicedocumented
services-accounting:docs/accounting/remittances.md#Remittances

Scenarios

IdGivenWhenThenProvenance
01A payroll receipt covers 212 members, including four departures.Select the remaining 208 invoice targets and explicitly record excess.Member receipts settle the selected invoices, the employer retains remainder value, and four invoices remain expected.test
services-accounting:modules/transactions/tests/integration/services/remittances/record-remittance.integration.spec.js#it pays the 208 invoices and leaves the four of the members who left open, owing 180.00 each
02The remitter’s remainder has been reused after recording.Attempt to void the receipt.The remittance and its generated records remain intact after refusal.test
services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it refuses the void: remittance_payment_allocated

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software