Fuchs_Intranet/Fuchs/Docs/Decisions/0009-block-setprice-modes-are-irreversible-mutations.md

---
status: Superseded
date: 2026-07-14
applyTo:
  - "Fuchs/code/InvoiceSetPricing.cs"
  - "Fuchs/Services/InvoiceDraft*"
  - "Fuchs/Services/IInvoiceDraft*"
  - "Fuchs/code/InvoiceDraftSession.cs"
  - "Fuchs/code/InvoiceDraftCalculator.cs"
  - "Fuchs/code/FuchsPdf.cs"
  - "Fuchs/js/intranet/**"
  - "Fuchs/Docs/INVOICE_SET_PRICING.md"
supersededBy: "0019-set-price-modes-are-keyed-on-the-set.md"
---

# 0009 — The two menu set-price modes are per-service-request-block, irreversible cache mutations that insert a dedicated set row

## Context
ADRs [0006](0006-backend-authoritative-draft-editing.md) and
[0008](0008-invoices-and-reminders-fully-backend-authoritative.md) made draft editing
backend-authoritative. Under that model the set-price feature had **three** functions, of
which the two menu-driven ones ("Set mit Preis" / "Nur Set mit Preis") were framed as
whole-invoice **display modes** (`SetDisplayMode.SetPrice`/`SetOnly`): a non-mutating,
render-time transform (`InvoiceSetPricing.Build`) over explicit `type == "set"` header items
and their `SetItmId` members, persisted only as an `admin.setmode` flag. ADR 0008 calls them
"display-mode toggles" and treats them as presentational.

The product owner has redefined those two menu functions. They are **not** display toggles and
they are **not** keyed on set-item membership:

- Their grouping is the **service request** (`ServiceRequestId` = the editor's tbody block),
  never `SetItmId`. Every block is treated as one set, whether or not it contains any
  `type == "set"` item.
- Applying a mode is an **irreversible data change** written hard into the cached draft
  dataset — not a reversible view flag. There is no toggle back; the user adjusts the result
  by hand afterwards.

This decision records that redefinition. It **refines** ADR 0008's characterisation of these
two operations (from "non-mutating display toggle" to "mutating, one-way conversion"); ADR
0008's broader rule — every calculation server-side, and the PDF renders 100% the same content
as the editor — remains fully in force and is not superseded.

## Decision
There are three distinct set-price operations, kept clearly separated:

1. **Inline set-item switch — unchanged.** The row context button on a single `type == "set"`
   item (`$inv.toSetPrice` → `item.setprice` delta → `InvoiceDraftEditService.ApplyItemSetPrice`).
   It is `SetItmId`-based, sums the header's members onto the header, sets the members' prices to
   `null` (empty cell, excluded from the sum — consistent with modes 2 & 3, not `0`), and is
   one-way. This is the **only** set-price operation that reads `SetItmId`. The button is shown —
   and the operation available — **only** for items that are `type == "set"` **and** carry a
   `SetItmId` (and are still unconverted, i.e. own price `0`); an item missing either condition
   never offers it.

2. **"Set mit Preis" (menu) — per-block, irreversible mutation.** Applied server-side to the
   cached `InvoiceDraftSession`, grouped by `ServiceRequestId`. For **every** service-request
   block:
   - Insert one dedicated, emphasised **set row** at the top of the block, carrying the block's
     aggregated value (net + VAT + service-net/-VAT splits) as its price. This row is a real,
     editable line item with its own id, so the user can manually change the set value afterwards
     as an ordinary item edit.
   - **Null out** the price of every existing item row in the block (set the price fields to
     `null`, **not** `0`) so the row renders with an **empty** price/total cell. `null` and `0`
     are semantically distinct here: `null` means "no price — render an empty cell and exclude
     from the block sum", whereas `0` would legitimately print `0,00 €`. The rows themselves are
     retained.

3. **"Nur Set mit Preis" (menu) — per-block, irreversible mutation.** As above, grouped by
   `ServiceRequestId`. For every block:
   - Insert the same dedicated, emphasised set row carrying the block's aggregated value.
   - **Remove** every existing item row in the block from the dataset entirely (the lines are
     gone, not merely hidden).

Properties common to the two menu modes (2 and 3):

- **Mutation, not display.** The change is written into `InvoiceDraftSession.Req` (the "cache
  dataset") as a mutating `InvoiceDraftDelta`, computed on the server (never in the browser).
  There is no render-time `admin.setmode` grouping flag driving how lines are shown, and no
  reversible toggle.
- **Irreversible.** There is no patch to undo it. The only ways back are discarding the draft
  (reloads the DB state) or hand-editing the resulting rows.
- **`SetItmId` is irrelevant.** Membership is the block, full stop.
- **Total unchanged.** The inserted set row's value equals the sum of the block's original items,
  which are then excluded from the sum — either because their price is `null` (mode 2, `null`
  counts as no contribution) or because they are gone (mode 3). So `InvoiceBalance`/
  `InvoiceBalance_net` are unaffected.
- **Editor and PDF render identically** (ADR 0008): the dedicated set row is emphasised in both,
  and both read the same mutated session.

## Consequences
- For the two menu modes, `InvoiceSetPricing` stops being a non-mutating render transform over
  `type == "set"` groups; the grouping/insert/blank/remove is a real mutation in
  `InvoiceDraftEditService`, keyed on the block. The inline `item.setprice` switch (operation 1)
  remains the sole `SetItmId`-based, set-item-scoped operation.
- The previous `admin.setmode` display-flag model for these two modes — persisted `setmode:`
  `InvoiceOptions` token, "Set-Preisanzeige menu entry disappears while unset", `Build(...)`
  choosing `ShowPrice` per member at render time — is retired. Because the operation is a
  one-shot irreversible mutation, there is no persisted display state to toggle. Any residual
  `setmode:` token must degrade safely (ignored) and is no longer (re-)persisted.
- New/changed behaviour must be modelled as a server-side delta + calculator/service change and
  covered by tests (`InvoiceDraftServiceTests`, `InvoiceSetPricingTests`): for each menu mode,
  assert the inserted set row's value equals the block sum, the total is unchanged, mode 2
  nulls-but-keeps member rows while mode 3 removes them, and an empty block is a no-op.
- Reminders follow the identical pattern when/if the same feature is offered there (ADR 0006/0008
  reminder mirror).

## Alternatives considered
Each of the following was raised and **explicitly decided against** as part of accepting this
decision — they are rejected choices, not open options to revisit without a superseding ADR:

- **Keep them as non-mutating display toggles** (the prior design): **explicitly rejected** by the
  product owner — the set price must be a real, hand-editable value baked into the document, and
  "Nur Set mit Preis" must actually drop the member lines, not just hide them.
- **Zero the blanked members' prices instead of nulling them**: **explicitly rejected** — `0` is
  ambiguous (it prints `0,00 €`), so the frontend could not tell an empty cell from a genuine
  zero price. Blanked members are set to `null` precisely to make "no price" unambiguous.
- **Carry the set price on the existing block heading row** instead of a dedicated row:
  **explicitly rejected** — a separate, individually-editable set row keeps the section-heading
  semantics intact and gives the user a concrete line to adjust afterwards.
- **Group by `SetItmId`/`type == "set"` headers like the inline switch:** **explicitly rejected**
  — the menu modes present each *service request* as one set, independent of any mfr set-item;
  conflating the two groupings is exactly the ambiguity this decision removes.