--- id: CAP-ACC-TRX-010 title: Record a remitter’s combined customer receipt feature: FEAT-ACC-TRX-03 product_area: accounting module: transactions revision: 1 status: draft product_intent: proposed implementation_evidence: observed supersedes: [] source_sha: services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8 react-console: baf6dae382d6f41dce976c7f848667ccc37e076f intent_sources: - 'services-accounting:docs/architecture/accounting-2.0/02-decisions.md#D-09' - 'services-accounting:docs/architecture/accounting-2.0/02-decisions.md#D-03' - 'services-accounting:docs/milestones/plans/ACCT-M2-plan.md#D1' - 'services-accounting:docs/milestones/plans/ACCT-M2-plan.md#D3' purpose: Staff account for one employer receipt and the individual customers it pays. 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. concepts: - CON-ACC-TRX-003 - CON-ACC-TRX-005 actors: - ACT-ACC-012 surfaces: - api permissions: - key: accounting.remittances.create where_checked: api scope: tenant - key: accounting.remittances.read where_checked: api scope: tenant - key: accounting.remittances.void where_checked: api scope: tenant - key: accounting.payments.create where_checked: api scope: tenant - key: accounting.payments.read where_checked: api scope: tenant - key: accounting.payments.void where_checked: api scope: tenant - key: accounting.invoices.read where_checked: api scope: tenant - key: accounting.expected-remittances.query where_checked: service scope: tenant rules: - id: BR-CAP-ACC-TRX-010-01 proved_by: [ATS-ACC-TRX-010-01, TST-ACC-TRX-014] statement: >- Remittance entry, reading and voiding require both the remittance and matching payment authorities; expected-invoice lookup additionally requires invoice read authority. kind: permission enforced_at: - api must_prove: true 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) origin: 'services-accounting:docs/architecture/accounting-2.0/02-decisions.md#D-09' - id: BR-CAP-ACC-TRX-010-02 proved_by: [] statement: Expected remittances list outstanding invoices whose orders identify that remitter. kind: policy enforced_at: - database - service must_prove: false provenance: test source: >- 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 origin: 'services-accounting:docs/architecture/accounting-2.0/02-decisions.md#D-03' - id: BR-CAP-ACC-TRX-010-03 proved_by: [ATS-ACC-TRX-010-02, TST-ACC-TRX-111] statement: >- Receipt total equals the selected lines plus an explicitly stated remainder; omitted remainder is never calculated automatically. kind: validation enforced_at: - service must_prove: true 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 origin: 'services-accounting:docs/architecture/accounting-2.0/02-decisions.md#D-09' - id: BR-CAP-ACC-TRX-010-04 proved_by: [ATS-ACC-TRX-010-03, TST-ACC-TRX-111] statement: Remittances accept offline methods only and enforce applicable reference requirements. kind: validation enforced_at: - service must_prove: true 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 origin: 'services-accounting:docs/architecture/accounting-2.0/02-decisions.md#D-09' - id: BR-CAP-ACC-TRX-010-05 proved_by: [ATS-ACC-TRX-010-04, ATS-ACC-TRX-010-07, TST-ACC-TRX-111] statement: >- Each unique target belongs to the stated member, unit and currency and receives no more than its outstanding value. kind: validation enforced_at: - service must_prove: true 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 origin: 'services-accounting:docs/architecture/accounting-2.0/02-decisions.md#D-09' - id: BR-CAP-ACC-TRX-010-06 proved_by: [ATS-ACC-TRX-010-05, ATS-ACC-TRX-010-07, TST-ACC-TRX-014, TST-ACC-TRX-110] statement: >- Entry atomically creates a payment for each member and an unapplied remainder payment for the remitter; any invalid line rejects the entire receipt. kind: calculation enforced_at: - service must_prove: true 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 origin: 'services-accounting:docs/architecture/accounting-2.0/02-decisions.md#D-09' - id: BR-CAP-ACC-TRX-010-07 proved_by: [ATS-ACC-TRX-010-06, ATS-ACC-TRX-010-07, TST-ACC-TRX-112] statement: >- Voiding requires a reason, reverses all generated payments and restores invoices, but fails after external reuse of money, posting or an earlier void. kind: lifecycle enforced_at: - service must_prove: true 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 origin: 'services-accounting:docs/architecture/accounting-2.0/02-decisions.md#D-09' - id: BR-CAP-ACC-TRX-010-08 proved_by: [ATS-ACC-TRX-010-08] statement: Remittance requests contain no more than two hundred and fifty lines. kind: validation enforced_at: - api must_prove: false provenance: test source: >- services-accounting:modules/transactions/tests/unit/api/remittances-schemas.spec.js#it refuses no lines, and more than 250 origin: 'services-accounting:docs/architecture/accounting-2.0/02-decisions.md#D-09' - id: BR-CAP-ACC-TRX-010-09 proved_by: [] statement: >- The product should replace the interim per-member payment split with a single receipt allocated across customers in the later receipt milestone. kind: policy enforced_at: - service must_prove: false provenance: documented source: 'services-accounting:docs/accounting/remittances.md#Remittances' origin: none note: >- The cited build recommendation does not establish Product approval; the authority gap remains open in FND-ACC-TRX-035. scenarios: - id: SC-CAP-ACC-TRX-010-01 given: 'A payroll receipt covers 212 members, including four departures.' when: Select the remaining 208 invoice targets and explicitly record excess. then: >- Member receipts settle the selected invoices, the employer retains remainder value, and four invoices remain expected. provenance: test source: >- 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 - id: SC-CAP-ACC-TRX-010-02 given: The remitter’s remainder has been reused after recording. when: Attempt to void the receipt. then: The remittance and its generated records remain intact after refusal. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/remittances/void-remittance.integration.spec.js#it refuses the void: remittance_payment_allocated edge_cases: [] depends_on: - CAP-ACC-TRX-006 related: - CAP-ACC-TRX-008 - CAP-ACC-TRX-017 journeys: [] evidence: - >- services-accounting at f47cb263875bbc0c5640fba7dae6785ec32695f8: modules/transactions/aws/api/remittances.routes.ts (recordRemittance, listRemittances, getRemittance, voidRemittance, listExpectedRemittances), remittances.schemas.ts; services/remittances/remittance-commands.ts, remittance-rules.ts, remittance-answers.ts; db/remittances.table.ts, remittance-lines.table.ts, expected-remittances.view.ts; metadata/expected-remittances.object.ts; queries/expected-remittances.query.ts; docs/accounting/remittances.md; docs/debt/payment-model-one-receipt-many-customers.md; tests e2e/remittances.e2e.spec.js, integration/services/remittances/*, integration/db/expected-remittances-view, unit/api/remittances-schemas. - >- react-console at baf6dae382d6f41dce976c7f848667ccc37e076f: no remittance page in the registered console scope. controls: [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] exercised_by: [FAS-ACC-TRX-03-01, FAS-ACC-TRX-03-03, FAS-ACC-TRX-03-04] suites: [TST-ACC-TRX-014, TST-ACC-TRX-110, TST-ACC-TRX-111, TST-ACC-TRX-112] --- # 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.