Rhythm 2.0 Specifications

Appearance

ATS-ACC-BKS-012Configure the methods used to receive money: Capability Test Specification

Markdown

ATS-ACC-BKS-012

Configure the methods used to receive money: Capability Test Specification

Markdown
  • DocumentProposed
  • Product intentProposed

Planning

Proves capability
CAP-ACC-BKS-012

Design

Executed by
TST-ACC-BKS-057, TST-ACC-BKS-093, TST-ACC-BKS-171, TST-ACC-BKS-174

KindAcceptance test setProduct areaAccountingModuleBooks, Business Units and Chart of AccountsRevision2

Read atservices-accounting f47cb263react-console baf6dae3

Configure the methods used to receive money: Capability Test Specification ​

Coverage ​

  • Keep method behaviour immutable.
  • Preserve the protected initial methods.
  • Offer methods on eligible channels.
  • Apply offline and reference constraints.
  • Apply offline and reference constraints.
  • Preserve migrated method vocabulary.

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

  • Provisioning retry preserves a renamed method.
  • Method behavior determines the tender fee.

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 covered
  • Transition covered
  • Validation covered
  • Permission covered
  • Edge gap: FND-ACC-BKS-073
  • Failure gap: FND-ACC-BKS-073
  • Boundary covered
  • Concurrency covered
  • Invariant covered
  • Interaction covered

Test Scenarios

10 scenarios proving CAP-ACC-BKS-012; 7 bound to an existing test.

01 Keep method behaviour immutableinvariantapinegativetest
Proves
BR-CAP-ACC-BKS-012-01 INV-DOM-ACC-BKS-006-01
Preconditions
System and customer-defined methods exist.
Steps
Change behaviour through the service and direct database writes.
Expected
Both enforcement paths refuse the change.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/e2e/payment-methods.e2e.spec.js#answers 409 payment_method_behaviour_immutable to another behaviour
02 Preserve the protected initial methodsruleapinegativetest
Proves
BR-CAP-ACC-BKS-012-02 INV-DOM-ACC-BKS-006-01
Preconditions
The workspace has been provisioned.
Steps
Rename and configure a system method, then deactivate it or alter deposit handling.
Expected
Permitted edits succeed; prohibited changes conflict.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/integration/services/persistence/payment-methods.integration.spec.js#renames and reconfigures within the rules: name, description, sort order, prompt, label, availability and may_bounce
03 Offer methods on eligible channelsvalidationapinegativetest
Proves
BR-CAP-ACC-BKS-012-03 INV-DOM-ACC-BKS-006-02
Preconditions
No prior method is needed.
Steps
Create each behaviour with defaults and invalid offline-portal and empty-channel cases.
Expected
Behaviour defaults apply; invalid availability fails.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/integration/services/persistence/payment-methods.integration.spec.js#defaults an offline method to the console, no reference, no bounce, direct deposit, active
04 Apply offline and reference constraintsvalidationunitnegativetest
Proves
BR-CAP-ACC-BKS-012-04 BR-CAP-ACC-BKS-012-05 INV-DOM-ACC-BKS-006-02
Preconditions
No prior method is needed.
Steps
Validate a bouncing card, undeposited card, unlabelled prompt and label without prompt.
Expected
All incompatible configurations are refused.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/unit/rules/payment-method-rules.spec.js#refuses may_bounce and undeposited funds on a processor behaviour
05 Preserve migrated method vocabularytransitionapitest
Proves
BR-CAP-ACC-BKS-012-07
Preconditions
The workspace is migrated from the earlier product.
Steps
Run migration method seeding twice.
Expected
Five additional non-system methods appear once, with the two retired legacy methods inactive.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/integration/services/persistence/payment-methods.integration.spec.js#writes the five extra methods once
06 Exercise the grants for configure the methods used to receive moneypermissionapinegativeproposed
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
07 Channel membership endpointsboundaryapinegativeproposed
Proves
BR-CAP-ACC-BKS-012-03
Preconditions
An isolated workspace has records needed for both eligible and ineligible examples.
Steps
Submit a single eligible channel, an empty set and a duplicate channel.
Expected
The eligible member saves and both malformed collections are refused.
Data
Run-owned records for the stated setup; retain the initial values for comparison.
Source
services-accounting:modules/books/tests/integration/services/persistence/payment-methods.integration.spec.js#refuses an offline method offered in the portal, naming the rule
08 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
09 Provisioning retry preserves a renamed methodinteractionapitest
Proves
BR-CAP-ACC-BKS-012-02 BR-CAP-ACC-BKS-019-01
Preconditions
Run-owned records satisfy the preconditions of the referenced capability proofs.
Steps
Provision the workspace, rename a system method through ordinary configuration, provision again and read all methods.
Expected
Retry neither duplicates the system set nor replaces the permitted renamed presentation.
Data
Run-owned records for the stated setup; retain the initial values for comparison.
Bound to
Source
services-accounting:modules/books/tests/integration/services/persistence/payment-methods.integration.spec.js#refuses to be deactivated, 409 payment_method_system,services-accounting:modules/maintenance/tests/integration/services/participants/configuration-participant.integration.spec.js#answers provision done, having written the tenant’s five system payment methods (WP-01)
10 Method behavior determines the tender feeinteractionapitest
Proves
BR-CAP-ACC-BKS-012-01 BR-CAP-ACC-BKS-003-06
Preconditions
Run-owned records satisfy the preconditions of the referenced capability proofs.
Steps
Evaluate the same configured fee against card, bank-debit and offline method behaviors with the bank-debit switch off and on.
Expected
The results follow the fee applicability rule while saved method behavior remains unchanged.
Data
Run-owned records for the stated setup; retain the initial values for comparison.
Bound to
Source
services-accounting:modules/books/tests/e2e/payment-methods.e2e.spec.js#answers 409 payment_method_behaviour_immutable to another behaviour,services-accounting:modules/books/tests/unit/rules/card-fee-rules.spec.js#charges a card behaviour always, a bank debit only when the rule says so, and never an offline method or without a rule

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