Skip to content

ATS-ACC-BKS-009Extend and maintain a unit’s fiscal calendar: Capability Test Specification

Markdown

ATS-ACC-BKS-009

Extend and maintain a unit’s fiscal calendar: Capability Test Specification

Markdown
  • DocumentProposed
  • Product intentProposed

KindAcceptance test setProduct areaAccountingModuleBooks, Business Units and Chart of AccountsRevision2

Read atservices-accounting f47cb263react-console baf6dae3

Coverage

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

Test Scenarios

12 scenarios proving CAP-ACC-BKS-009; 9 bound to an existing test.

01 Extend the existing calendarruleapitest
Proves
BR-CAP-ACC-BKS-009-01
Preconditions
The unit already has two years.
Steps
Generate with default count, count two and count six.
Expected
Default and two-year requests append consecutive years; six is refused.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/e2e/fiscal-years.e2e.spec.js#answers 200 with one year by default, the year after the latest, and the count
02 Use fiscal naming for years and monthsruleunittest
Proves
BR-CAP-ACC-BKS-009-02
Preconditions
January-start and July-start examples exist.
Steps
Plan each year.
Expected
January uses one year name and July spans two, with numbered monthly suffixes.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/unit/fiscal-year-rules.spec.js#names the year by its calendar year alone
03 Apply the start-date horizon atomicallyfailureapinegativetest
Proves
BR-CAP-ACC-BKS-009-03 INV-DOM-ACC-BKS-003-05
Preconditions
The next requested year extends beyond the allowed horizon.
Steps
Request single and multi-year generation.
Expected
The refusal identifies the start-date limit and leaves all requested years unwritten.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/integration/services/persistence/fiscal-years.integration.spec.js#refuses the generation in Rhythm 1.0’s words, naming the first start too far ahead and the latest allowed
04 Enforce complete contiguous periodsinvariantapinegativetest
Proves
BR-CAP-ACC-BKS-009-04 INV-DOM-ACC-BKS-003-01
Preconditions
The unit already has a calendar year.
Steps
Attempt a gap, overlap, eleven-period year and mid-month boundary.
Expected
Commit refuses each malformed calendar and rolls back its writes.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/integration/db/fiscal-years.table.integration.spec.js#refuses a year leaving a gap after the latest, in Rhythm 1.0’s sentence
05 Rename without changing the calendartransitionapinegativetest
Proves
BR-CAP-ACC-BKS-009-05 INV-DOM-ACC-BKS-003-03
Preconditions
The year is read at its current version.
Steps
Rename it, change its start and change a period’s status.
Expected
Renaming succeeds without structural changes; other replacements conflict.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/e2e/fiscal-years.e2e.spec.js#changes nothing else: the dates, the status and the periods are as read
06 Remove only the latest fully open yeartransitionapinegativetest
Proves
BR-CAP-ACC-BKS-009-06 INV-DOM-ACC-BKS-003-04
Preconditions
Three years exist and the middle includes a closed period.
Steps
Attempt deletion of the oldest and latest.
Expected
The older-year refusal names the latest; the latest is removed with its periods.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/e2e/fiscal-years.e2e.spec.js#answers 409 naming the latest year
07 Derive year standing from periodsinvariantapitest
Proves
BR-CAP-ACC-BKS-009-07 INV-DOM-ACC-BKS-003-02
Preconditions
Every period begins open.
Steps
Close all periods and reopen one.
Expected
The year closes only with all periods closed and reopens with a reopened period.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/integration/db/fiscal-years.table.integration.spec.js#keeps the year open while one period is open
08 Use the workspace’s local dateboundaryapitest
Proves
BR-CAP-ACC-BKS-009-08
Preconditions
The local date remains in October while UTC is in November.
Steps
Establish a new business unit at that instant.
Expected
Its first calendar year is based on the local October reference.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/integration/services/persistence/fiscal-years.integration.spec.js#starts from the tenant’s month, where the UTC date is already the next month
09 Review calendar maintenance across screensinteractionbrowsertest
Proves
AS-JNY-ACC-BKS-003-01 AS-JNY-ACC-BKS-003-02 AS-JNY-ACC-BKS-003-03
Preconditions
The unit begins its year in July.
Steps
Follow generation, rename, deletion and period-lookup work.
Expected
Each screen and read-back reflects the journey’s calendar changes.
Data
The setup needs no extra fixture records.
Bound to
Source
react-console:acceptance/accounting/playwright/journeys/configuration/ACT-ACC-0023.spec.ts#ACT-ACC-0023
10 Exercise the grants for extend and maintain a unit’s fiscal calendarpermissionapinegativeproposed
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
11 Append two generation requests without overlapping coverageconcurrencyapiproposed
Proves
BR-CAP-ACC-BKS-009-01 BR-CAP-ACC-BKS-009-04 INV-DOM-ACC-BKS-003-01
Preconditions
The unit has two years and enough horizon for two further one-year requests.
Steps
Start two generation requests simultaneously from separate connections, then read every resulting year and period.
Expected
Both serialized extensions follow the referenced generation contract and the final calendar satisfies the structural invariant.
Data
Run-owned records for the stated setup; retain the initial values for comparison.
Source
specs/accounting/books/design/workflows/WF-ACC-BKS-005-generate-a-units-next-fiscal-years.md:concurrency
12 An extension becomes available to dated lookupinteractionbrowserproposed
Proves
BR-CAP-ACC-BKS-009-01 BR-CAP-ACC-BKS-010-02
Preconditions
Run-owned records satisfy the preconditions of the referenced capability proofs.
Steps
Look up the day after coverage, generate one year and repeat the identical lookup.
Expected
The initial absence creates no year; the explicit extension makes the date resolvable.
Data
Run-owned records for the stated setup; retain the initial values for comparison.
Source
specs/accounting/books/design/workflows/WF-ACC-BKS-005-generate-a-units-next-fiscal-years.md

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.