Organize reporting by department and project

Purpose

Accountants classify the unit’s financial work below the level of a separate set of books.

How It Works

The controller opens the department or project list for a unit. They add the reporting code used to classify its financial activity. The code supplies stable identity while the name can be corrected. Product accounting can refer to the dimension when classifying activity. Projects may carry an end date as descriptive information. Removing a used dimension can fail because product setup still depends on it. These records organize reporting within the unit rather than create another set of books.

Relationships

Product accounting selects these reporting dimensions from the unit’s configuration.

Show evidence (sources, provenance, origins, pinned commits)

The Formal Contract

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

Outcomes: Reporting dimensions retain their unit and code identities.Display labels follow name corrections immediately.Product references preserve their reporting dimensions.
Surfaces: consoleapi
Intent sources: services-accounting:docs/milestones/plans/ACCT-M1-plan.md#2. Scopeservices-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#R16services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#Entity capabilities (R2-ARCH-001)

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

Key	Checked at	Scope
`accounting.departments.read`	api	tenant
`accounting.departments.create`	api	tenant
`accounting.departments.update`	api	tenant
`accounting.departments.delete`	api	tenant
`accounting.accounting-projects.read`	api	tenant
`accounting.accounting-projects.create`	api	tenant
`accounting.accounting-projects.update`	api	tenant
`accounting.accounting-projects.delete`	api	tenant

Business Rules

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

Id	Rule	Kind	Enforced at	Provenance
`01`must prove Confirmed	Department and project codes are upper-cased and unique in their separate collections within a unit; omitted identifiers derive from unit and code, and the two collections may share a code. proved by `ATS-ACC-BKS-008-01`, `ATS-ACC-BKS-008-07`, `TST-ACC-BKS-050`, `TST-ACC-BKS-070`, `TST-ACC-BKS-170`	validation	api, service, database	test services-accounting:modules/books/tests/e2e/departments.e2e.spec.js#answers 400 to a code the unit already has, under the id it derives
`02`must prove Confirmed	A department or project retains its saved business unit and code. proved by `ATS-ACC-BKS-008-02`, `TST-ACC-BKS-044`, `TST-ACC-BKS-050`, `TST-ACC-BKS-061`	invariant	service, database	test services-accounting:modules/books/tests/e2e/accounting-projects.e2e.spec.js#answers 409 to a change of code, naming the column
`03`must prove Confirmed	Reads calculate the display name from the current code and name, or the code alone for an unnamed project. proved by `ATS-ACC-BKS-008-03`, `TST-ACC-BKS-044`, `TST-ACC-BKS-050`	calculation	service	test services-accounting:modules/books/tests/e2e/departments.e2e.spec.js#answers the new name, and the display name recomputed from it
`04`must prove Confirmed	Departments require names; projects may omit names and may store an end date. proved by `ATS-ACC-BKS-008-03`, `TST-ACC-BKS-044`, `TST-ACC-BKS-050`	validation	api, service, database	test services-accounting:modules/books/tests/e2e/accounting-projects.e2e.spec.js#answers it with no name, no end date, and the code alone as its display name
`05`must prove Confirmed	A product accounting setup referencing a department or project prevents its deletion and prevents deletion of its owning unit. proved by `ATS-ACC-BKS-008-04`, `TST-ACC-BKS-080`	invariant	database	test services-accounting:modules/books/tests/integration/services/persistence/departments.integration.spec.js#refuses the delete 409, naming the unit’s products
`06`must prove Confirmed	Department and project requests refuse custom-field values because these records do not support them. proved by `ATS-ACC-BKS-008-05`, `TST-ACC-BKS-044`	validation	api	test services-accounting:modules/books/tests/e2e/accounting-projects.e2e.spec.js#answers 400 to custom field values, which Accounting does not carry yet
`07` Confirmed	Both collections order by code, support unit and activity filters and identifier, code or name search, and active-unit filters supply picker choices.	policy	api, service	test services-accounting:modules/books/tests/e2e/departments.e2e.spec.js#answers nothing to a picker’s query for a unit whose only department is inactive
`08` Confirmed	The console scopes both lists to one unit with a single-row toolbar and initializes new dimensions with the working unit. origin: services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#R16 proved by `ATS-ACC-BKS-008-09`	policy	console	documented services-accounting:docs/milestones/ACCT-M1-books-and-invoices.md#R16

Scenarios

Id	Given	When	Then	Provenance
`01`	The chapter uses an Events department and a Gala project.	The controller records both and changes the department name to Special Events.	The display becomes EVT - Special Events while its identity is retained.	test services-accounting:modules/books/tests/e2e/departments.e2e.spec.js#answers the new name, and the display name recomputed from it

Planning

Implementation

Organize reporting by department and project ​

Purpose ​

How It Works ​

Relationships ​