---
id: ADR-ACC-BKS-004
title: Physical deletion with declared dependency protection
product_area: accounting
module: books
revision: 1
status: proposed
design_intent: proposed
source_sha:
  services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
decision: >-
  Eligible records are physically deleted. Declared restricting references
  prevent removal and recognized constraints produce a readable refusal; owned
  collections cascade. Payment methods provide no ordinary deletion operation.
constrains:
  - DOM-ACC-BKS-001
  - DOM-ACC-BKS-002
  - DOM-ACC-BKS-003
  - DOM-ACC-BKS-004
  - DOM-ACC-BKS-006
  - WF-ACC-BKS-003
  - SVC-ACC-BKS-books
origin: >-
  services-accounting docs/milestones/ACCT-M1-books-and-invoices.md#D3 (unit
  deletion and its cascade, as Rhythm 1.0 did)
alternatives:
  - option: Archive instead of deleting.
    why_not: >-
      The existing active flag already retains unavailable records. A separate
      archive state would need a distinct product purpose.
  - option: Delete every dependent by cascade.
    why_not: >-
      That proposed alternative could remove financial records and independently
      maintained setup.
  - option: Check dependencies only before the delete.
    why_not: >-
      A reference created after a preliminary check would race with deletion;
      restricting keys guard the actual write.
consequences:
  - Staff can deactivate records that remain in use.
  - >-
    Unrecognized constraints can produce an untranslated error; installment
    references to payment terms exhibit this gap.
  - >-
    Bulk deletion performs individual requests and can leave some selected
    records deleted and others retained.
supersedes: []
evidence:
  - >-
    services-accounting at f47cb263:
    modules/books/services/persistence/configuration-refusals.ts:configurationRefusal,
    STILL_REFERENCED
  - >-
    services-accounting at f47cb263:
    modules/books/services/persistence/business-units.ts:deleteBusinessUnit
---

# Physical deletion with declared dependency protection

## Context

Configuration can remain useful to existing financial records after it stops being offered for new work. Availability and deletion therefore serve different purposes.

The cited product choice establishes unit deletion and its owned cascade. Applying physical deletion and restricting references across the other configuration collections is observed implementation, so this broader design remains proposed.

## Decision

Eligible records are physically deleted. Declared restricting references prevent removal and recognized constraints produce a readable refusal; owned collections cascade. Payment methods provide no ordinary deletion operation.

## Alternatives Considered

Archive instead of deleting. The existing active flag already retains unavailable records. A separate archive state would need a distinct product purpose.

Delete every dependent by cascade. That proposed alternative could remove financial records and independently maintained setup.

Check dependencies only before the delete. A reference created after a preliminary check would race with deletion; restricting keys guard the actual write.

## Consequences

Staff can deactivate records that remain in use.

Unrecognized constraints can produce an untranslated error; installment references to payment terms exhibit this gap.

Bulk deletion performs individual requests and can leave some selected records deleted and others retained.