Rhythm 2.0 Specifications

Appearance

ATS-ACC-BKS-011Define invoice payment terms: Capability Test Specification

Markdown

ATS-ACC-BKS-011

Define invoice payment terms: Capability Test Specification

Markdown
  • DocumentProposed
  • Product intentProposed

Planning

Proves capability
CAP-ACC-BKS-011

Design

Executed by
TST-ACC-BKS-013, TST-ACC-BKS-058, TST-ACC-BKS-061

KindAcceptance test setProduct areaAccountingModuleBooks, Business Units and Chart of AccountsRevision2

Read atservices-accounting f47cb263react-console baf6dae3

Define invoice payment terms: Capability Test Specification ​

Coverage ​

  • Validate bounded day precision.
  • Keep terms workspace-wide.
  • Give useful deletion refusals for referenced terms.
  • Give useful deletion refusals for referenced terms.

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

  • Apply Net 30 to invoice issue.
  • Shared terms remain protected during a reader inspection.

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

Test Scenarios

7 scenarios proving CAP-ACC-BKS-011; 3 bound to an existing test.

01 Validate bounded day precisionboundaryapinegativetest
Proves
BR-CAP-ACC-BKS-011-01
Preconditions
No prior term is needed.
Steps
Submit days above the bound, negative, over-precision and textual values, then both numeric bounds.
Expected
Invalid inputs identify the day field; zero and 1000 are accepted.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/e2e/payment-terms.e2e.spec.js#answers 400 naming number_of_days for more than 1000 days
02 Keep terms workspace-widevalidationapinegativetest
Proves
BR-CAP-ACC-BKS-011-02
Preconditions
A business unit exists.
Steps
Create terms containing that unit.
Expected
The unit property is refused.
Data
The setup needs no extra fixture records.
Bound to
Source
services-accounting:modules/books/tests/e2e/payment-terms.e2e.spec.js#answers 400 to a business unit, which payment terms do not carry
03 Give useful deletion refusals for referenced termsfailureapinegativeproposed
Proves
BR-CAP-ACC-BKS-011-04 BR-CAP-ACC-BKS-011-05 INV-DOM-ACC-BKS-006-03
Preconditions
Terms are referenced by an invoice, customer terms and an installment schedule.
Steps
Attempt removal in each state.
Expected
Deletion preserves referenced terms. Recognized invoice and customer references produce a named dependency conflict; the installment reference retains the unexplained refusal recorded by its cited rule.
Data
Isolated fixture records matching this scenario’s setup.
Source
FND-ACC-BKS-009,services-accounting:modules/books/services/persistence/configuration-refusals.ts:STILL_REFERENCED
04 Use edited term days at invoice issueinteractionbrowsertest
Proves
BR-CAP-ACC-BKS-011-01 BR-CAP-ACC-BKS-011-03
Preconditions
An administrator has a run-owned product, contact, open batch and terms initially named for forty-five days.
Steps
Create the terms, edit their days to forty-six while keeping the name, issue an invoice dated October eighteenth, then change it to the zero-day terms through Edit Details.
Expected
The issued invoice falls due on December third; selecting the zero-day terms changes its due date to the invoice date.
Data
A postable unit, priced product, CRM contact, open batch and run-marked term records.
Bound to
Source
react-console:acceptance/accounting/playwright/journeys/configuration/ACT-ACC-0018.spec.ts#ACT-ACC-0018
05 Exercise the grants for define invoice payment termspermissionapinegativeproposed
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
06 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
07 Shared terms remain protected during a reader inspectioninteractionapiproposed
Proves
BR-CAP-ACC-BKS-011-02 BR-CAP-ACC-BKS-016-01
Preconditions
Run-owned records satisfy the preconditions of the referenced capability proofs.
Steps
Inspect terms from two unit contexts as a reader, then attempt replacement and deletion without the term write grants.
Expected
The same shared terms remain readable and each refused mutation leaves them unchanged.
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 to a business unit, which payment terms do not carry,services-accounting:modules/books/tests/e2e/configuration-security.e2e.spec.js#is refused the create 403 permission_missing

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