Skip to content

CAP-ACC-BKS-011Define invoice payment terms

Markdown

CAP-ACC-BKS-011

Define invoice payment terms

Markdown
  • DocumentDraft
  • Product intentConfirmed
  • ImplementationInconsistent

KindCapabilityProduct areaAccountingModuleBooks, Business Units and Chart of AccountsRevision1

Read atservices-accounting f47cb263react-console baf6dae3

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes
Named terms give finance staff control over invoice due-date choices.Financial references prevent removal of terms still in use.
Surfaces
consoleapi
Intent sources
services-accounting:docs/milestones/plans/ACCT-M1-plan.md#2. Scopeservices-accounting:docs/milestones/plans/ACCT-M1-plan.md#D12

Controls

23 controls apply, from the corpus control catalogue.

TC-IAM-001 TC-IAM-002 TC-IAM-004 TC-IAM-005 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-005 TC-AZ-006 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-TEN-004 TC-DAT-001 TC-DAT-004 TC-LOG-001 TC-LOG-002 TC-LOG-003 TC-LOG-004 TC-LOG-005 TC-PI-001 TC-PI-003

Permissions

KeyChecked atScope
accounting.payment-terms.readapitenant
accounting.payment-terms.createapitenant
accounting.payment-terms.updateapitenant
accounting.payment-terms.deleteapitenant

Business Rules

7 rules, 4 to be proved before approval. A rule's product intent is derived from its origin: 7 confirmed by a product decision, the rest inheriting this capability's confirmed.

IdRuleKindEnforced atProvenance
01must prove
Confirmed
Payment-term days are numeric values from 0 through 1000 with at most two decimal places; text and out-of-range or over-precision values are refused with the field named.
✓ A valid configuration completes the stated operation.✗ A conflicting configuration receives the stated refusal.
validationapi, databasetest
services-accounting:modules/books/tests/e2e/payment-terms.e2e.spec.js#answers 400 naming number_of_days for more than two decimal places
02must prove
Confirmed
Payment terms belong to the workspace and refuse a business-unit property.
validationapitest
services-accounting:modules/books/tests/e2e/payment-terms.e2e.spec.js#answers 400 to a business unit, which payment terms do not carry
03
Confirmed
The service preserves the supplied name independently of days, permits duplicate names under different identifiers and derives an omitted identifier from the name.
policyservice, databasetest
services-accounting:modules/books/tests/e2e/payment-terms.e2e.spec.js#keeps the name it is sent, whatever the number of days (the Net <n> rewrite is the console’s)
04must prove
Confirmed
Invoices and customer-term references prevent term deletion with the dependent kind identified.
invariantdatabase, serviceobserved
05must prove
Confirmed
An installment-schedule reference also prevents deletion, but its untranslated database refusal currently reaches the caller as an unexplained error.
invariantdatabaseobserved
06
Confirmed
The console proposes a Net name based on the entered day count and accepts whole days.
policyconsoleobserved
07
Confirmed
Term lists order by name, support active-state filters and search identifier or name.
policyapi, servicetest

Scenarios

IdGivenWhenThenProvenance
01The organization offers Net 30 and payment on receipt.The controller records both and issues an invoice to a member assigned Net 30.The due date is thirty days after the invoice date.test

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.