Rhythm 2.0 Specifications

Appearance

ATS-ACC-BKS-007Configure where received money lands: Capability Test Specification

Markdown

ATS-ACC-BKS-007

Configure where received money lands: Capability Test Specification

Markdown
  • DocumentProposed
  • Product intentProposed

Planning

Proves capability
CAP-ACC-BKS-007

Design

Executed by
TST-ACC-BKS-045, TST-ACC-BKS-056, TST-ACC-BKS-063, TST-ACC-BKS-069, TST-ACC-BKS-091

KindAcceptance test setProduct areaAccountingModuleBooks, Business Units and Chart of AccountsRevision2

Read atservices-accounting f47cb263react-console baf6dae3

Configure where received money lands: Capability Test Specification ​

Coverage ​

  • Require same-unit receiving destinations.
  • Limit account-number storage.
  • Preserve receiving-account context.
  • Require processor context without implying connection.
  • Require processor context without implying connection.
  • Preserve reconciliation-owned settings.
  • Retain a settlement destination.
  • Protect accounts referenced by financial work.

The structured coverage map distinguishes specified examples from remaining findings. Proposed examples require executable proof before qualification.

  • Used receiving currency cannot be switched off.

Related-capability and workflow references identify the seams each scenario exercises. The lifecycle coverage record retains transitions that still need individual proof.

Binding Review ​

The pinned service and browser assertions support the registered bindings. Original test references remain beside each scenario so partial evidence and unresolved conformance remain reviewable.

Coverage

  • Rule gap: FND-ACC-BKS-068
  • Transition not-applicable
  • Validation covered
  • Permission covered
  • Edge covered
  • Failure covered
  • Boundary covered
  • Concurrency covered
  • Invariant covered
  • Interaction covered

Test Scenarios

10 scenarios proving CAP-ACC-BKS-007; 6 bound to an existing test.

01 Require same-unit receiving destinationsvalidationapinegativetest
Proves
BR-CAP-ACC-BKS-007-01 INV-DOM-ACC-BKS-002-03
Preconditions
Two units each have GL accounts.
Steps
Create local bank and merchant accounts using the other unit’s GL account.
Expected
Both refusals identify the unit mismatch.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/e2e/bank-accounts.e2e.spec.js#answers 400 to another unit’s GL account, naming both units
02 Limit account-number storageboundaryapinegativetest
Proves
BR-CAP-ACC-BKS-007-02 INV-DOM-ACC-BKS-002-07
Preconditions
The unit has a cash GL account.
Steps
Submit alphabetic, five-digit and three-digit suffixes, then four digits.
Expected
Invalid suffixes fail and the four-digit suffix succeeds.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/e2e/bank-accounts.e2e.spec.js#answers 400 to an account_number_last4 holding a letter
03 Preserve receiving-account contextinvariantapinegativetest
Proves
BR-CAP-ACC-BKS-007-03
Preconditions
A bank and merchant account exist.
Steps
Try changes to each unit and currency.
Expected
Every immutable-field change conflicts.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/e2e/bank-accounts.e2e.spec.js#answers 409 to a change of currency, naming the column (0049)
04 Require processor context without implying connectionvalidationapinegativetest
Proves
BR-CAP-ACC-BKS-007-04 BR-CAP-ACC-BKS-007-05 INV-DOM-ACC-BKS-002-08
Preconditions
The unit has no merchant configuration yet.
Steps
Submit an unaccompanied processor reference, an unknown processor and valid processor/no-processor cases.
Expected
Invalid cases fail; valid records report Not Connected.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/e2e/merchant-accounts.e2e.spec.js#answers 400 to a processor account reference without a processor
05 Preserve reconciliation-owned settingsedgeapitest
Proves
BR-CAP-ACC-BKS-007-06
Preconditions
Reconciliation has set a merchant settlement destination and timing.
Steps
Save a replacement through receiving-account configuration.
Expected
The settlement columns retain their prior values.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/integration/services/persistence/merchant-accounts.integration.spec.js#leaves the settlement columns payout reconciliation owns as they were stored
06 Retain a settlement destinationinvariantapinegativetest
Proves
BR-CAP-ACC-BKS-007-07
Preconditions
A merchant account names the bank account for settlement.
Steps
Request deletion of that bank account.
Expected
Deletion fails and the destination remains.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/integration/db/reconciliation-configuration.table.integration.spec.js#refuses deleting the bank account a merchant account settles to
07 Protect accounts referenced by financial workfailureapinegativeproposed
Proves
BR-CAP-ACC-BKS-007-09
Preconditions
Bank and merchant accounts are used by assignment rules and payouts.
Steps
Attempt deletion of each receiving account.
Expected
Each reference produces a named refusal and preserves the account.
Data
Isolated fixture records matching this scenario’s setup.
Source
services-accounting:modules/books/services/persistence/configuration-refusals.ts:STILL_REFERENCED
08 Exercise the grants for configure where received money landspermissionapinegativeproposed
Proves
BR-CAP-ACC-BKS-016-01
Preconditions
An application-authorized reader and administrator share the run-owned setup. A third principal lacks the relevant resource grant.
Steps
Read the relevant configuration as the reader, attempt each supported mutation, then repeat with the matching administrator grants. Repeat the reads without their resource grants.
Expected
The permission outcomes match the cited authorization rule, and refused mutations leave every configured value unchanged.
Data
Run-owned records for the stated setup; retain the initial values for comparison.
Source
services-accounting:modules/books/tests/e2e/configuration-security.e2e.spec.js#is refused the create 403 permission_missing
09 Refuse the second replacement of a shared read versionconcurrencyapinegativeproposed
Proves
BR-CAP-ACC-BKS-016-05
Preconditions
Two administrators read the same version of the relevant mutable record. Each prepares a different otherwise valid replacement.
Steps
Release both replacement requests from a barrier. Read the record again and retry the losing payload at its original version.
Expected
One replacement commits, the other is stale, and repeating the stale request preserves the winning values.
Data
Run-owned records for the stated setup; retain the initial values for comparison.
Source
services-accounting:modules/books/tests/e2e/payment-terms.e2e.spec.js#answers 400 naming is_active to a replacement that leaves it out
10 Used receiving currency cannot be switched offinteractionapiproposed
Proves
BR-CAP-ACC-BKS-007-03 BR-CAP-ACC-BKS-002-05
Preconditions
Run-owned records satisfy the preconditions of the referenced capability proofs.
Steps
Create a foreign-currency receiving account and attempt both currency removal and multicurrency disablement.
Expected
Each attempt preserves the receiving account and its enabled currency.
Data
Run-owned records for the stated setup; retain the initial values for comparison.
Source
services-accounting:modules/books/tests/e2e/bank-accounts.e2e.spec.js#answers 409 to a change of currency, naming the column (0049),services-accounting:modules/books/tests/e2e/business-units.e2e.spec.js#answers 409 naming the currency, the unit and the kinds of account that use it

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