Rhythm 2.0 Specifications

Appearance

ATS-ACC-BKS-003Set a unit’s accounting and tender-fee policies: Capability Test Specification

Markdown

ATS-ACC-BKS-003

Set a unit’s accounting and tender-fee policies: Capability Test Specification

Markdown
  • DocumentProposed
  • Product intentProposed

Planning

Proves capability
CAP-ACC-BKS-003

Design

Executed by
TST-ACC-BKS-003, TST-ACC-BKS-074, TST-ACC-BKS-171

KindAcceptance test setProduct areaAccountingModuleBooks, Business Units and Chart of AccountsRevision2

Read atservices-accounting f47cb263react-console baf6dae3

Set a unit’s accounting and tender-fee policies: Capability Test Specification ​

Coverage ​

  • Protect the accounting method after current-period posting.
  • Use the policy effective at posting.
  • Validate a complete fee rule.
  • Require an eligible fee product.
  • Calculate and distribute one tender fee.
  • Apply fees by payment behaviour.
  • Keep an empty tender free of charges.

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

  • Changed write-off policy uses the selected destination.
  • Invalid content selection preserves accounting policy.

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 covered
  • Failure gap: FND-ACC-BKS-064
  • Boundary covered
  • Concurrency gap: FND-ACC-BKS-064
  • Invariant gap: FND-ACC-BKS-064
  • Interaction covered

Test Scenarios

12 scenarios proving CAP-ACC-BKS-003; 7 bound to an existing test.

01 Protect the accounting method after current-period postingtransitionapinegativetest
Proves
BR-CAP-ACC-BKS-003-01
Preconditions
One unit has current-period posted work and another has posting only elsewhere.
Steps
Try method changes in both directions.
Expected
Current-period work blocks each change with period and count; other-period work permits it.
Data
Isolated fixture records matching this scenario’s setup.
Bound to
Source
services-accounting:modules/books/tests/integration/services/persistence/business-units.integration.spec.js#refuses the change 409 naming the period and the count when a batch of the open period is posted, leaving the method
02 Use the policy effective at postingrulebrowsertest
Proves
BR-CAP-ACC-BKS-003-02
Preconditions
A write-off is pending under bad-debt treatment.
Steps
Select revenue reversal and post the write-off batch.
Expected
The posting uses the revenue destination.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/integration/services/persistence/business-units.integration.spec.js#takes bad_debt_expense on a create that leaves the treatment out
03 Validate a complete fee rulevalidationapinegativetest
Proves
BR-CAP-ACC-BKS-003-03 INV-DOM-ACC-BKS-001-06
Preconditions
A business unit is available.
Steps
Submit incomplete product/amount combinations, a standalone minimum, 101 percent, a negative amount and five-place precision.
Expected
Every invalid rule is refused.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/integration/services/persistence/business-units.integration.spec.js#refuses a rule that is not whole (a percent without a product, a product without an amount, a minimum alone) by the database’s rule
04 Require an eligible fee productvalidationapinegativetest
Proves
BR-CAP-ACC-BKS-003-04 INV-DOM-ACC-BKS-001-06
Preconditions
Products include a local active product, a foreign-unit product and an inactive product.
Steps
Choose each as the fee product.
Expected
Only the active same-unit product is accepted.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/integration/services/persistence/business-units.integration.spec.js#refuses a fee product of another unit, an inactive one and one the tenant does not have, naming card_fee_product_id
05 Calculate and distribute one tender feeruleunittest
Proves
BR-CAP-ACC-BKS-003-05
Preconditions
Fee rules contain percentage, fixed and minimum choices.
Steps
Calculate base and foreign fees and allocate a tender across two invoices.
Expected
Half-up percentage rounding applies; base-only fixed and minimum values are shared once, with remainder on the last share.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/unit/rules/card-fee-rules.spec.js#adds the fixed amount in the base currency: 2.9% + 30 on 10000 is 320
06 Apply fees by payment behaviourruleunittest
Proves
BR-CAP-ACC-BKS-003-06
Preconditions
Electronic-check charging is alternately enabled and disabled.
Steps
Evaluate card, bank-debit and offline tenders.
Expected
Cards attract the fee, bank debits follow the switch and offline money attracts none.
Data
The setup needs no extra fixture records.
Bound to
Source
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
07 Keep an empty tender free of chargesedgeunitproposed
Proves
BR-CAP-ACC-BKS-003-09
Preconditions
The rule includes fixed and minimum charges.
Steps
Calculate zero and negative tender fees.
Expected
Each result is zero.
Data
Isolated fixture records matching this scenario’s setup.
Source
services-accounting:modules/books/services/rules/card-fee-rules.ts:cardFeeAmountOf
08 Exercise the grants for set a unit’s accounting and tender-fee policiespermissionapinegativeproposed
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 Fee percentage endpointsboundaryapinegativeproposed
Proves
BR-CAP-ACC-BKS-003-03
Preconditions
An isolated workspace has records needed for both eligible and ineligible examples.
Steps
Submit percentages zero and one hundred, then a value immediately above one hundred and a fifth decimal place.
Expected
Eligible endpoints save; each exceeded precision or range is refused without altering the previous rule.
Data
Run-owned records for the stated setup; retain the initial values for comparison.
Source
services-accounting:modules/books/tests/integration/services/persistence/business-units.integration.spec.js#refuses a rule that is not whole (a percent without a product, a product without an amount, a minimum alone) by the database’s rule
10 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
11 Changed write-off policy uses the selected destinationinteractionbrowsertest
Proves
BR-CAP-ACC-BKS-003-02 BR-CAP-ACC-BKS-006-06
Preconditions
Run-owned records satisfy the preconditions of the referenced capability proofs.
Steps
Create a write-off, switch its treatment before posting and post; separately try an allowance write-off without its default and retry after assignment.
Expected
Posting follows the current policy and succeeds after the required destination is supplied.
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/business-units.integration.spec.js#takes bad_debt_expense on a create that leaves the treatment out,services-accounting:docs/architecture/accounting-2.0/02-decisions.md#A-1
12 Invalid content selection preserves accounting policyinteractionapiproposed
Proves
BR-CAP-ACC-BKS-003-02 BR-CAP-ACC-BKS-015-04
Preconditions
Run-owned records satisfy the preconditions of the referenced capability proofs.
Steps
Change write-off treatment while selecting wrong-kind content in one replacement, then inspect both choices.
Expected
Neither the policy nor the document choice changes when validation refuses the replacement.
Data
Run-owned records for the stated setup; retain the initial values for comparison.
Source
services-accounting:modules/books/tests/integration/services/persistence/business-units.integration.spec.js#takes bad_debt_expense on a create that leaves the treatment out,services-accounting:modules/books/tests/e2e/document-templates.e2e.spec.js#answers 400 to a business unit naming an inactive template

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