Lots of runs

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/Protokoll.md

@@ -0,0 +1,103 @@
+# Messprotokoll – Versuch 01 (V1 Baseline, Prompt-only) – Iteration 02
+
+## Lauf
+- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
+- **Iteration:** 02 – vom User ausdrücklich benannt; entspricht zugleich der Regel „höchste
+  vorhandene Iterationsnummer". Wiederholungslauf zur Varianzbestimmung in derselben Zelle.
+- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
+- **Startzeit:** 2026-08-26T16:00:49.2361402+02:00
+- **Endzeit:** 2026-08-26T16:21:48.6873493+02:00
+- **Dauer gesamt:** 0:20:59 (`duration_ms` 0:10:57; API: 3:49:48)
+  — **im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar**
+- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.662 versionierte Dateien)
+- **Codebasis-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748` (dirty: nein)
+- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja (Prüfmuster ohne Treffer);
+  die Codebasis ist seit Commit `f045b99a` kein eigenes Repository mehr, sondern Teil des
+  Arbeitsrepos – der Vorher/Nachher-Vergleich läuft deshalb pfadskopiert
+- **Snapshot-Zusatzartefakte:** keine – der Snapshot entspricht dem Commit-Stand
+- **Prompt-Repo-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748`
+
+## Werkzeugkonfiguration
+- **Skill-Version:** 4.5.0
+- **Claude-Code-Version:** 2.1.246
+- **CLI-Pfad:** `C:\Users\ChristophSchwoerer\.vscode\extensions\anthropic.claude-code-2.1.246-win32-x64\resources\native-binary\claude.exe`
+- **Modell (angefordert):** `claude-opus-5`
+- **Modelle (tatsächlich eingesetzt):** `claude-opus-5` 193.392.662 Tokens (100.00 %), `claude-haiku-4-5-20251001` 6.986 Tokens (0.00 %)
+- **Kontrolle Modell:** bestanden – ausschließlich das angeforderte Modell plus Haiku als zulässiger interner Hilfsaufruf
+- **Effort:** `high` (per `--effort high` gesetzt)
+- **Laufverzeichnis-ID:** `v4.5.0-116d`
+- **Ablage:** `Iteration 3/claude-opus-5/builtin/high/`
+- **Parallele Läufe:** **ja** – zeitgleich liefen:
+  - `Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-9d9e`
+
+  Die Zeitangaben dieses Laufs sind daher **nicht** für Laufzeitvergleiche zu verwenden. Tokenverbrauch, Anforderungszahl, Belegkennzahlen und Denials bleiben unverzerrt.
+- **Agentenmodus:** `builtin` (V1b)
+- **Kontextfenster:** 1.000.000 Tokens; `maxOutputTokens` 64.000
+- **Sampling-Parameter:** nicht steuerbar über die CLI, nicht erfasst
+- **Nur bei lokalem Modellbetrieb:** entfällt (Cloud-Inferenz, `provider: firstParty`)
+- **Permission-Mode:** `acceptEdits`
+- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` /
+  `--disallowedTools` 33er-Denylist (schreibende und bauende Kommandos). Der Modus `builtin` fügt keine weiteren Sperren hinzu – die werkzeugeigenen Subagenten sind zugelassen.
+- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
+- **MCP-Server / Agentendateien:** keine – aus dem Snapshot entfernt, zusätzlich `--safe-mode`
+- **Subagenten:** 20 gestartet (10 × `Explore`, 10 × `general-purpose`), 10 abgeschlossen, 0 fehlgeschlagen; 20 im Hintergrund gestartet
+- **Verschachtelung:** `spawned` = 20, davon `spawned_by_subagents` = 10, `max_depth` = 2. Bei `max_depth` > 1 sind die Tokens der tieferen Ebenen in „Tokens gesamt" enthalten, ihre Prompts jedoch **nicht** in `_meta\subagenten.md`.
+- **Verbrauchsanteil der Subagenten:** `usage` (nur Hauptagent) 2.124.147 Tokens gegenüber `modelUsage` 193.399.648 Tokens – auf die Subagenten entfallen 191.275.501 Tokens (98.9 %).
+
+## Validierungsstichprobe
+- **Größe:** noch nicht festgelegt
+- **Ziehungsverfahren:** noch nicht festgelegt
+- **Validatoren:** noch nicht festgelegt
+- **Stand:** noch nicht gezogen
+
+## Verbrauch
+
+### Hauptagent (`usage`)
+| Messgröße | Wert |
+|---|---:|
+| Input-Tokens | 44 |
+| Output-Tokens | 65.246 (davon 9.113 Thinking-Tokens) |
+| Cache-Write-Tokens | 123.977 |
+| Cache-Read-Tokens | 1.934.880 |
+| Agent-Turns | 44 |
+
+### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
+| Messgröße | `claude-opus-5` | `claude-haiku-4-5-20251001` | Summe |
+|---|---:|---:|---:|
+| Input-Tokens | 2.604 | 6.960 | 9.564 |
+| Output-Tokens | 1.155.732 | 26 | 1.155.758 |
+| Cache-Write-Tokens | 4.641.716 | 0 | 4.641.716 |
+| Cache-Read-Tokens | 187.592.610 | 0 | 187.592.610 |
+| **Tokens gesamt** | **193.392.662** | **6.986** | **193.399.648** |
+
+**Tokens gesamt: 193.399.648** — Input + Output + Cache-Write + Cache-Read über alle Modelle.
+Das ist die **berichtete Aufwandsgröße** der Versuchsreihe. `total_cost_usd` bleibt unberührt in
+`RawResult.json` erhalten, wird aber nicht ins Protokoll übernommen: Token sind modell- und
+preisunabhängig und bleiben damit über Preisänderungen und Modellwechsel hinweg vergleichbar.
+
+`usage` erfasst **nur den Hauptagenten**. Der Unterschied zu `modelUsage` ist der Verbrauch
+der Subagenten – siehe Feld „Verbrauchsanteil der Subagenten" oben. Für den
+abrechnungsrelevanten Gesamtverbrauch gilt ausschließlich `modelUsage`.
+
+## Gefundene Anforderungen
+
+Keine Anforderungen im vorgegebenen Format gefunden.
+
+## Ergebnis
+- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
+- **Session-ID:** `ac82faba-7709-4a7c-9881-dcf0cd4faa1c`
+- **Permission-Denials:** 1 (1 × `Bash`) – **keines auf `Task`/`Agent`/`Workflow`**. Der Agent hat zu keinem Zeitpunkt zu delegieren versucht; die Modus-Sperre wurde nie ausgelöst.
+- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 20 – Bedingung `solo` **VERLETZT – Fehlmessung**
+- **Subagenten-Prompts:** `_meta\subagenten.md` erzeugt
+- **Erzeugte Dateien:** 0 Dateien in `Ergebnisse\`:
+
+  | Datei | Größe |
+  |---|---:|
+
+
+- **Root unverändert:** ja (zeilenendennormalisiert verglichen).
+- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
+
+## Anmerkungen/Auffälligkeiten
+
+<!-- ANMERKUNGEN -->

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/RawResult.json

@@ -0,0 +1 @@
+{"is_error":false,"duration_api_ms":13788889,"num_turns":44,"stop_reason":"end_turn","session_id":"ac82faba-7709-4a7c-9881-dcf0cd4faa1c","total_cost_usd":152.18535374999993,"usage":{"input_tokens":44,"cache_creation_input_tokens":123977,"cache_read_input_tokens":1934880,"output_tokens":65246,"output_tokens_details":{"thinking_tokens":9113},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":123977,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":474,"cache_read_input_tokens":152943,"cache_creation_input_tokens":1008,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":1008},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6960,"outputTokens":26,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.00709,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-opus-5":{"inputTokens":2604,"outputTokens":1155732,"cacheReadInputTokens":187592610,"cacheCreationInputTokens":4641716,"webSearchRequests":0,"costUSD":152.17826374999993,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-opus-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[{"tool_name":"Bash","tool_use_id":"toolu_01WYSxhrBPsM7eYbEU9QFZbf","tool_input":{"command":"mkdir -p \"/c/Users/CHRIST~1/AppData/Local/Temp/claude/C--DEV-MasterArbeit-QuellCode-CentronERP/ac82faba-7709-4a7c-9881-dcf0cd4faa1c/scratchpad/rre\" && echo ok","description":"Create scratchpad work dir"}}],"terminal_reason":"completed","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":20,"requested":{"background":0,"foreground":0,"unset":20},"started_in_background":20,"max_depth":2,"spawned_by_subagents":10,"completed":10,"failed":0,"killed":{"parent":0,"user":0,"system":10},"refused":{"depth_limit":0,"concurrency_limit":5,"budget":0},"by_type":{"general-purpose":10,"Explore":10}},"subtype":"success","api_error_status":null,"result":"Die Erhebung läuft. Aktueller Stand:\n\n**Schritt 0 – Modulinventar** steht: 167 Module/Komponenten über sechs Bereiche, verankert an belegbaren Strukturen der Codebasis (113 `AppModuleController`, 30 Projekte unter `src/`, 1.558 Tabellen im DB-Dump, 750 Rechtekonstanten in `UserRightsConst.cs`).\n\n**Schritt 0b/0c – Erhebung**: 10 von 12 Agenten arbeiten parallel, jeder mit einem eigenen ID-Block und der Pflicht, jedes zugewiesene Modul mit mindestens einer Anforderung abzudecken. A11 (Datenaustausch/Schnittstellen) und A12 (Plattform/Nexus/Betrieb) starte ich, sobald Slots frei werden.\n\nEin Befund schon jetzt für den Analysebericht: Die Codebasis enthält **keine `.git`-Historie und keine SQL-Migrationsskripte** — `scripts/` ist reines C#-Werkzeug. Commit-Messages, Tickets und Release Notes als `KONTEXT`-Belege stehen damit nicht zur Verfügung; das ist eine Belegquelle, die der Prompt vorsieht und die dieser Lauf nicht bedienen kann.","ttft_ms":1986,"ttft_stream_ms":1231,"time_to_request_ms":32,"type":"result","duration_ms":657822,"uuid":"878467f0-8d1e-4e6f-980b-316977345320","queued_turn_count":0}

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/Stderr.log

@@ -0,0 +1 @@
+Background tasks still running after 600s; terminating. Set CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0 to wait indefinitely.

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_meta/anforderungen.json

@@ -0,0 +1 @@
+[]

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_meta/anforderungen.md

@@ -0,0 +1,4 @@
+## Gefundene Anforderungen
+
+Keine Anforderungen im vorgegebenen Format gefunden.
+

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_meta/before.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_meta/combined_prompt.md

@@ -0,0 +1,178 @@
+# Versuch 01 - Baseline (Prompt-only) - Iteration 02
+
+## Metadaten
+- **Versuch:** V1 Baseline (Prompt-only)
+- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
+- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
+- **Zeitstempel:** 2026-08-26
+- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
+- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
+
+  | Änderung | Auslösender Befund |
+  |---|---|
+  | Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
+  | Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
+  | Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
+  | Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
+  | Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
+  | Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
+  | Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
+
+  Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
+
+> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
+> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
+> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
+
+---
+
+## Prompt
+
+Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
+
+### Auftrag
+
+Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
+
+1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
+2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
+3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
+
+Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
+
+### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
+
+Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
+
+**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
+
+### Vorgehen (statische Analyse, keine Ausführung)
+
+Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
+
+**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
+
+**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig.
+
+**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
+
+2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
+3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
+4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
+5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
+6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
+
+### Pflicht-Eigenschaften jeder Anforderung
+
+- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
+- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
+- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
+- **Belegklassifikation:** Kennzeichne jeden Beleg als
+  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
+  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
+  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
+- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
+- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
+- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
+- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
+- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
+
+### Formatvorgabe pro Anforderung
+
+```
+ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
+Titel:         <kurzer Titel>
+Ebene:         <StRS | SyRS | SwRS>
+Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
+Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
+Akteur:        <Rolle / System / Komponente>
+Vorbedingung:  <Zustand vor Auslösen>
+Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
+Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
+Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
+Belege:
+  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
+  - [SEKUNDÄR] <...> - Begründung: <...>
+  - [KONTEXT]  <...> - Begründung: <...>
+Prüfidee:      <Akzeptanzkriterium oder Testidee>
+Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
+Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
+Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
+Status:        <belegt | HYPOTHESE>
+```
+
+### Traceability
+
+Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
+- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
+- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
+- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
+
+### Nicht-funktionale Anforderungen
+
+- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
+- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
+
+### Konsolidierungsbedarf
+
+Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
+
+**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
+
+### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
+
+```
+Ergebnisse/
+  StRS.md
+  SyRS.md
+  SwRS.md
+  Traceability.md   (oder Traceability.csv)
+  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
+  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
+  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
+                     Selbstbewertung, bekannte Lücken)
+```
+
+Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
+
+### Randbedingungen
+
+- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
+- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
+- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
+- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
+- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
+
+### Abschluss
+
+Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
+- Doppelte oder mehrfach vergebene IDs
+- Anforderungen ohne Beleg
+- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
+- Tracelinks auf nicht existierende IDs
+- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
+- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
+- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
+
+Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
+
+Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
+- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
+- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
+- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
+- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
+- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
+
+---
+
+### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
+Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien, das Ausführen von
+Kommandozeilenbefehlen im Arbeitsverzeichnis sowie die werkzeugeigenen Subagenten.
+Nicht verfügbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe
+Werkzeugserver.
+Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
+Werkzeuge zu ersetzen.
+### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
+Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
+`c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 3\claude-opus-5\builtin\high\02_Lauf_2026-08-26_160037_v4.5.0-116d\Ergebnisse\`.
+Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_meta/endzeit.txt

@@ -0,0 +1 @@
+2026-08-26T16:21:48.6873493+02:00

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_meta/startzeit.txt

@@ -0,0 +1 @@
+2026-08-26T16:00:49.2361402+02:00

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_work/A10_StRS.md

@@ -0,0 +1,188 @@
+ID:            StRS-1001
+Titel:         Vertriebs- und Auftragskennzahlen mehrdimensional auswerten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Controller / Vertriebsleitung
+Vorbedingung:  Benutzer besitzt das Recht `Controlling.Analytics.ID`; Lizenz `LicenseGuids.Analytics` oder `LicenseGuids.Centron` ist aktiv.
+Fakt:          `SaleStatisticsAppModuleController` (src/centron/Centron.WPF.UI/Modules/Statistics/SaleStatistics/SaleStatisticsAppModuleController.cs) trägt `ModuleName => "Analytics"` und `Description => "Erstellung, Bearbeitung und Export verschiedenster Auswertungen"`. `StatisticDataSourceFactory.Create` erzeugt sieben Auswertungsarten (Artikelverkauf, Ticket, Einkauf, Mitarbeiter, Angebote, Ticket-Timer, Verkauf/Einkauf-Artikel); die Darstellung erfolgt als DevExpress-PivotGrid in SaleStatisticsView.xaml.
+Aussage:       Das System soll Verkaufs-, Einkaufs-, Angebots-, Ticket- und Mitarbeiterkennzahlen in einer frei konfigurierbaren Pivot-Auswertung mit wählbarem Zeitraum, Filiale, Warengruppe und Artikelbezug bereitstellen und das Ergebnis nach Excel exportierbar machen.
+Ergebnis:      Der Auswerter erhält eine Pivot-Tabelle inklusive Diagramm; die Konfiguration ist als `.cak`-Datei speicher- und wieder ladbar.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Statistics/SaleStatistics/DataSources/StatisticDataSourceFactory.cs, Methode `Create(SaleStatisticsViewModel parent, StatisticTypes? type)` - Begründung: Die Methode instanziiert je Auswertungsart genau eine `IStatisticDataSource`; sie ist die durchsetzende Stelle des Auswertungsumfangs.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Statistics/SaleStatistics/SaleStatisticsAppModuleController.cs, `Description => "Erstellung, Bearbeitung und Export verschiedenster Auswertungen"` - Begründung: UI-String belegt den fachlichen Zweck des Moduls.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Statistics/SaleStatistics/SaleStatisticsView.xaml.cs, `Export(object param)` mit `PivotGrid.ExportToXlsx(...)` und `Diagram.ExportToXlsx(...)` - Begründung: belegt die geforderte Exportfähigkeit.
+Prüfidee:      Benutzer mit allen Analytics-Rechten öffnet "Analytics": Es müssen genau sieben Auswertungsarten anwählbar sein; nach "Export nach Excel" existieren zwei .xlsx-Dateien (Pivot und Diagramm).
+Tracelinks:    SyRS-1010, SyRS-1011, SwRS-1032
+Konsolidierung: Kandidat: StRS-1002 / SyRS-1010 - Vertriebsstatistik und Management-Informationen berechnen beide "Umsatz" und "Ertrag/DB", jedoch aus getrennten Implementierungen (CacheSalesStatistic vs. NamedQueries auf cvw_InvoicePos).
+Übernahmewürdigkeit: übernehmen - zentrale Controlling-Fähigkeit des Systems.
+Status:        belegt
+Modul:         M-105
+
+ID:            StRS-1002
+Titel:         Management-Informationen als Vier-Jahres-Vergleich je Filiale
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Geschäftsführung / Controlling
+Vorbedingung:  Benutzer besitzt `Controlling.Finances.MANAGEMENT_INFO`; Lizenz `LicenseGuids.ManagementInfo` oder `LicenseGuids.Centron` aktiv; mindestens eine Warengruppe ist ausgewählt.
+Fakt:          `ManagementInfoWebServiceBL.GetManagementInfoData` bündelt 16 Einzelkennzahlen aus `ManagementInfoBL` (u. a. `GetSalesOrderBacklog`, `GetContributionMarginOrderBacklog`, `GetStockValue`, `GetOpenPosts`, `GetEmployeeCount`, `GetOpenTicketCount`, `GetSalesOnDates`, `GetGainOnDate`). `ManagementInfoViewModel.LoadData` berechnet das Zeitfenster als `year = CurrentDate.Month > DateTime.Now.Month ? CurrentDate.Year - 4 : CurrentDate.Year - 3`.
+Aussage:       Das System soll der Geschäftsführung Auftragsbestand, Deckungsbeitrag, Lieferbestand, Lagerwert, offene Posten, Mitarbeiterzahl, offene Tickets sowie Umsatz- und Ertragsverläufe als Monatsreihen über vier Jahre je ausgewählter Filiale und Warengruppe bereitstellen.
+Ergebnis:      Kennzahlenübersicht mit vier Jahresreihen zu je zwölf Monaten, nach Excel exportierbar.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Statistics/Sales/ManagementInfo/ManagementInfoWebServiceBL.cs, `GetManagementInfoData(...)` - Begründung: aggregiert die 16 Kennzahlenaufrufe und definiert damit den Leistungsumfang.
+  - [PRIMÄR]   src/backend/Centron.BL/Statistics/Sales/ManagementInfo/ManagementInfoBL.cs, `GetSalesOnDates` / `GetGainOnDate` - Begründung: liefern die Monatsreihen Umsatz und Ertrag über NamedQueries auf `cvw_InvoicePos`/`cvw_InvoiceHead`.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Statistics/ManagementInfo/ManagementInfoViewModel.cs, `LoadData()` mit Abbruchdialog `LoadData_BitteWählenSieZurAktualisierungDerDatenEineWarengruppeAus` - Begründung: belegt die Pflicht-Vorbedingung Warengruppenauswahl.
+Prüfidee:      Modul öffnen ohne Warengruppenauswahl → Dialog "Keine Warengruppen ausgewählt"; nach Auswahl müssen genau 4 Jahresreihen à 12 Monatswerte für Umsatz und Ertrag erscheinen.
+Tracelinks:    SyRS-1012, SwRS-1033
+Konsolidierung: Kandidat: StRS-1001 - identischer Kennzahlenbegriff "Umsatz"/"Ertrag" in getrennter Implementierung.
+Übernahmewürdigkeit: übernehmen - Kernanforderung des Managementberichtswesens.
+Status:        belegt
+Modul:         M-106
+
+ID:            StRS-1003
+Titel:         Leistungsnachweise über Mitarbeiterauslastung mit begrenzter Sichtbarkeit
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Teamleitung / Personalverantwortliche
+Vorbedingung:  Benutzer besitzt `UserRightsConst.RIGHT_MITARBEITERAUSLASTUNG` (10930); Lizenz `LicenseGuids.PerformanceRecords` oder `LicenseGuids.Centron` aktiv.
+Fakt:          `EmployeeAnalyticsAppModuleController` trägt `ModuleName => "Leistungsnachweise"` und `Description => "Darstellung der Mitarbeiterauslastung"`. `EmployeeAnalyticsViewModel.LoadData()` liest die Rechte des angemeldeten Benutzers und setzt `_onlyMyselfAsEmployee` (fehlendes `RIGHT_FREMDAUSLASTUNG`) sowie `_onlyOwnBranch` (`RIGHT_MITARBEITERAUSLASTUNGNUREIGENEFILIALE`, 20800042).
+Aussage:       Das System soll Auslastungsnachweise für einen wählbaren Zeitraum und eine wählbare Mitarbeitermenge erzeugen und dabei die auswählbare Mitarbeitermenge auf die dem Benutzer erlaubte Filiale bzw. auf ihn selbst begrenzen.
+Ergebnis:      PDF-Leistungsnachweis (Report "Serviceauslastung" oder "Vertriebsauslastung"), speicherbar, druckbar und per E-Mail versendbar.
+Belege:
+  - [PRIMÄR]   src/shared/Centron.Controls/EmployeeAnalytics/EmployeeAnalyticsViewModel.cs, `LoadData()`: `this._onlyOwnBranch = rights.Data.Any(f => f.I3D == UserRightsConst.RIGHT_MITARBEITERAUSLASTUNGNUREIGENEFILIALE) == true;` - Begründung: konkrete Auswertung des einschränkenden Rechts.
+  - [SEKUNDÄR] CentronRights.md, Abschnitt "Mitarbeiterauslastung": "This is a **restricting right**. If the user has this right, he should only see the workload of employees that belong to his branch." - Begründung: dokumentierte Soll-Semantik des Rechts.
+  - [SEKUNDÄR] src/shared/Centron.Controls/EmployeeAnalytics/EmployeeAnalyticsViewModel.cs, `SaveReportAsPdf()` mit `Filter = "PDF ( .pdf) | *.pdf"` und `SendReportAsMail()` - Begründung: belegt die geforderten Ausgabewege.
+Prüfidee:      Benutzer mit RIGHT_MITARBEITERAUSLASTUNGNUREIGENEFILIALE öffnet das Modul: Im Auswahlbaum darf ausschließlich die eigene Filiale erscheinen.
+Tracelinks:    SyRS-1015, SyRS-1016, SwRS-1035
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - personenbezogene Auswertung mit klarem Schutzbedarf.
+Status:        belegt
+Modul:         M-108
+
+ID:            StRS-1004
+Titel:         Zentrale Verwaltung von Berichten und SQL-Abfragen
+Ebene:         StRS
+Typ:           funktional
+Akteur:        Report-Administrator
+Qualitätsmerkmal:
+Vorbedingung:  Benutzer besitzt `UserRightsConst.Administration.REPORT_MANAGEMENT`; Lizenz `LicenseGuids.ReportManagement` oder `LicenseGuids.Centron` aktiv.
+Fakt:          `ReportEngineAppModuleController` ist in ModuleRegistration.cs unter "Reportverwaltung" mit `Helper.HasRights(UserRightsConst.Administration.REPORT_MANAGEMENT)` registriert. Berichtsdefinitionen liegen als BLOB in `dbo.ReportData.Report` bzw. `dbo.Reports.Report` (Spaltentyp `image`); die zu einem Bericht gehörenden SQL-Abfragen liegen in `dbo.ReportDataQueries (I3D, ReportDataI3D, Name, Statement, MasterI3D)`.
+Aussage:       Das System soll Berichtsdefinitionen und die zugehörigen SQL-Abfragen zentral in der Datenbank verwalten, sie Berichtsgruppen zuordnen und ihre Bearbeitung auf Benutzer mit dem Recht REPORT_MANAGEMENT beschränken.
+Ergebnis:      Berichte und Abfragen sind versioniert, gruppiert und mandantenbezogen abrufbar; ohne Recht ist die Reportverwaltung nicht sichtbar.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Eintrag "Reportverwaltung": `ModuleRegistrationItem.For<ReportEngineAppModuleController>(() => Helper.HasRights(UserRightsConst.Administration.REPORT_MANAGEMENT), ...)` - Begründung: durchsetzende Bedingung für die Modulverfügbarkeit im Client.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[ReportDataQueries]` mit `[Statement] [text] NOT NULL` und `CONSTRAINT [FK_ReportDataQueries_ReportData] FOREIGN KEY([ReportDataI3D])` - Begründung: DB-Constraint bindet jede Abfrage an genau eine Berichtsdefinition.
+  - [SEKUNDÄR] src/backend/Centron.BL/ReportEngine/ReportDataQueryBL.cs, `SaveQuery(ReportDataQueryDTO query, int reportID)` - Begründung: zeigt Insert/Update auf `ReportDataQueries` mit parametrisierten Befehlen.
+Prüfidee:      Benutzer ohne REPORT_MANAGEMENT startet den Client: Das Modul "Reportverwaltung" darf nicht in der Modulliste erscheinen.
+Tracelinks:    SyRS-1017, SyRS-1018, SyRS-1019, SwRS-1036, SwRS-1037
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Grundlage des gesamten Belegdrucks und Berichtswesens.
+Status:        belegt
+Modul:         M-109
+
+ID:            StRS-1005
+Titel:         Tagesbezogene Arbeitszeit- und Tätigkeitserfassung mit Tagesabschluss
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Mitarbeiter / Teamleitung
+Vorbedingung:  Lizenz `LicenseGuids.MyDay` oder `LicenseGuids.Centron` aktiv; Benutzer ist angemeldet.
+Fakt:          `MyDayBL` verwaltet `MyDayWorkItem`, `MyDayUserItem`, `MyDayWorkItemReaction` und `MyDayFinalizedDay`. Arbeitsposten entstehen auch automatisch aus Helpdesk-Zeiterfassung (`TryUpdateWorkItemFromHelpdeskTimer(HelpdeskTimer timer)`, Typ `MyDayWorkItemType.HelpdeskCalcuableTimeRecording`). `MyDayEditorAppModuleController` ist als "Mein Tag" registriert.
+Aussage:       Das System soll je Mitarbeiter und Tag alle Arbeitsposten (manuell erfasst, aus Helpdesk-Timern übernommen oder generiert) in einer Zeitleiste führen und den Tag als abgeschlossen markierbar machen.
+Ergebnis:      Ein abgeschlossener Tag ist als `MyDayFinalizedDay` gespeichert; Monatsübersicht und Team-Übersicht bauen auf denselben Arbeitsposten auf.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/MyDay/MyDayBL.cs, `SaveOrUpdateFinalizedDay(MyDayFinalizedDay finalizedDay)` und `GetWorkItems(MyDayWorkItemsFilter filter, LoggedInUser loggedInUser)` - Begründung: definieren Speicherung des Tagesabschlusses und Abruf der Arbeitsposten.
+  - [PRIMÄR]   src/backend/Centron.BL/MyDay/MyDayBL.cs, `TryUpdateWorkItemFromHelpdeskTimer(HelpdeskTimer timer)` - Begründung: belegt die automatische Übernahme von Ticketzeiten in die Tagesansicht.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Kommentar "// Mein Tag" mit `ModuleRegistrationItem.For<MyDayEditorAppModuleController>` - Begründung: UI-Bezeichnung des Moduls.
+Prüfidee:      Helpdesk-Timer auf ein Ticket starten und stoppen; in "Mein Tag" muss ein Arbeitsposten desselben Zeitraums erscheinen. Tag abschließen → Datensatz in `MyDayFinalizedDay` vorhanden.
+Tracelinks:    SyRS-1022, SwRS-1039
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Basis für Leistungserfassung und Abrechenbarkeit.
+Status:        belegt
+Modul:         M-113
+
+ID:            StRS-1006
+Titel:         Nachvollziehbare Massenänderung von Belegen und Stammdaten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Stammdatenverantwortlicher
+Vorbedingung:  Benutzer besitzt `UserRightsConst.DataUpdater.ACCESS_DATAUPDATER_MODULE` (20800127); Lizenz `LicenseGuids.DataUpdaterV2` oder `LicenseGuids.Centron` aktiv.
+Fakt:          `MassUpdateBL` stellt vier Massenläufe bereit: `StartReceiptPriceUpdate`, `StartArticlePriceUpdate`, `StartAccountDataUpdate`, `StartReceiptDataUpdate`. Jeder Lauf arbeitet auf einer vorab gespeicherten `MassUpdateTemplate` mit `MassUpdateTemplateItems`; jedes Element trägt `IsExecuted`, `ExecutedByI3D`, `ExecutedAt` und `FailureMessage`.
+Aussage:       Das System soll Preis- und Datenänderungen an Belegen, Artikeln und Konten als vorab definierte, wiederholbare Vorlage ausführen und je geändertem Objekt festhalten, wer die Änderung wann ausgeführt hat.
+Ergebnis:      Nach dem Lauf ist je Element der Erfolgs- oder Fehlerstatus abfragbar; erfolgreich geänderte Belege tragen einen Protokolleintrag der Art `ReceiptLogKind.DataUpdater`.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs, `StartReceiptPriceUpdate(int massUpdateI3D, LoggedInUser loggedInUser)`: `this._receiptLogBL.CreateEntry(loggedInUser.User.Employee.I3D, item.ObjectI3D, item.ObjectKind, ReceiptLogKind.DataUpdater, logText.ToString()); item.ExecutedByI3D = loggedInUser.User.Employee.I3D; item.ExecutedAt = DateTime.Now; item.IsExecuted = true;` - Begründung: durchsetzende Stelle der Protokollierung und Ausführungskennzeichnung.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `ALTER TABLE [dbo].[MassUpdateTemplate] ADD CONSTRAINT [FK_MassUpdateTemplate_ExecutedByI3D] FOREIGN KEY([ExecutedByI3D])` - Begründung: DB-Constraint verankert den Ausführenden.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Kommentar "// Data Updater" mit `Helper.HasRights(UserRightsConst.DataUpdater.ACCESS_DATAUPDATER_MODULE)` - Begründung: belegt Zugangssteuerung des Moduls.
+Prüfidee:      Massenupdate mit zwei Belegen ausführen, davon einer nicht aktiv: Der aktive Beleg trägt einen ReceiptLog-Eintrag der Art DataUpdater, das zweite Element trägt `FailureMessage = "Beleg ist nicht aktiv."`.
+Tracelinks:    SyRS-1023, SwRS-1040
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Massenänderungen an Preisen sind revisionsrelevant.
+Status:        belegt
+Modul:         M-114
+
+ID:            StRS-1007
+Titel:         Schulungsvideos mit Nachverfolgung des Ansehens
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Mitarbeiter / Schulungsverantwortlicher
+Vorbedingung:  Videoportal-Modul ist registriert; der Mitarbeiter ist über `EmployeeIdentifier` (Kundennummer, EmployeeI3D, Name, E-Mail) identifiziert.
+Fakt:          `CentronOfficeVideoPortalApi` ruft ein externes c-entron-Office-Portal auf (Kategorien `videodirectory`, `video`, `videoview`). `MarkVideoAsSeen(int videoID)` schreibt einen `videoview`-Datensatz mit `VideoID`, `CentronCustomerNumber`, `EmployeeI3D`, `FirstName`, `LastName`, `EmailAddress`, `SeenAt`. `CheckIfAllVideosFromDirctoryAreSeen` löscht bei vollständigem Verzeichnis die zugehörige Todo-Zuweisung.
+Aussage:       Das System soll Schulungsvideos aus einem externen Videoportal in Verzeichnissen anbieten, je Mitarbeiter festhalten welche Videos gesehen wurden, und eine Videozuweisung aus der Todo-Liste entfernen, sobald alle Videos ihres Verzeichnisses gesehen sind.
+Ergebnis:      Der Schulungsstand je Mitarbeiter ist über `GetEmployeeEvaluation(int centronCustomerNumber)` als `VideoEmployeeEvaluation(EmployeeI3D, VideoDirectoryID, SeenVideoCount, SeenVideoIDs)` auswertbar.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Global/VideoPortal/CentronOfficeVideoPortalApi.cs, `MarkVideoAsSeen(int videoID)` - Begründung: durchsetzende Stelle der Sehen-Erfassung inkl. Todo-Bereinigung.
+  - [PRIMÄR]   src/backend/Centron.BL/VideoPortal/VideoPortalAssignmentBL.cs, `SaveVideoPortalAssignment(VideoPortalAssignment assignment, LoggedInUser loggedInUser)` / `GetAllVideoPortalAssignments()` - Begründung: verankert die Zuweisung von Videoverzeichnissen an Mitarbeiter in der eigenen Datenbank.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Global/VideoPortal/CentronOfficeVideoPortalApi.cs, `record VideoEmployeeEvaluation(int EmployeeI3D, int VideoDirectoryID, int SeenVideoCount, int[] SeenVideoIDs)` - Begründung: belegt das Auswertungsergebnis.
+Prüfidee:      Einem Mitarbeiter ein Videoverzeichnis zuweisen, alle enthaltenen Videos ansehen: Die Todo-Zuweisung muss danach verschwunden sein und `GetEmployeeEvaluation` den vollen SeenVideoCount liefern.
+Tracelinks:    SyRS-1026
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Schulungsnachweise sind organisatorisch erforderlich.
+Status:        belegt
+Modul:         M-117
+
+ID:            StRS-1008
+Titel:         KI-Assistenz mit Benutzerkontrolle über ausgeführte Aktionen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Sachbearbeiter
+Vorbedingung:  Benutzer besitzt `UserRightsConst.ArtificialIntelligence.ID` (20800167); Lizenz `LicenseGuids.AiAssistant` aktiv; ein KI-Anbieterzugang ist konfiguriert.
+Fakt:          `ArtificialIntelligenceChatAppModuleController` ist als "AI-Chat" registriert. `ApiClientFactory` unterstützt die Anbietertypen `OpenAI`, `Ionos`, `OpenAiCompatible`, `Tensorx`, `ClaudeCode`, `MistralAi`, `GoogleAiStudio`. Der Chat kann über Tool-Handler auf Konten, Artikel, Mitarbeiter, Navigation und interaktive Module zugreifen; jeder Tool-Aufruf läuft über `IArtificialIntelligenceToolConfirmationService`.
+Aussage:       Das System soll einen in c-entron integrierten KI-Chat bereitstellen, der Systemfunktionen nur über explizit beschriebene Werkzeuge ausführt und jede Werkzeugausführung dem Benutzer zur Bestätigung vorlegt, sofern dieser nicht ausdrücklich uneingeschränkten Zugriff aktiviert hat.
+Ergebnis:      Der Benutzer sieht vor jeder Aktion Name, Beschreibung und Parameter des Werkzeugs und kann sie abbrechen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ArtificialIntelligence/Chat/Harness/ArtificialIntelligenceDefaultToolConfirmationService.cs, `ConfirmAsync(...)`: `if (this._allowUnrestrictedAccess?.Invoke() == true) return true;` gefolgt von `ShowDialog(message, "AI-Chat-Tool bestätigen", "Ausführen", "Abbrechen")` - Begründung: durchsetzende Stelle der Benutzerbestätigung.
+  - [PRIMÄR]   src/backend/Centron.BL/ArtificialIntelligence/ApiClientFactory.cs, `switch (settings.ApiType)` mit den sieben `ArtificialIntelligenceApiType`-Fällen - Begründung: definiert den Anbieterumfang.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Kommentar "// AI-Chat" mit `Helper.HasRights(UserRightsConst.ArtificialIntelligence.ID)` - Begründung: belegt die Rechtevoraussetzung.
+Prüfidee:      Benutzer ohne UNRESTRICTED_ACCESS stellt eine Frage, die einen Tool-Aufruf auslöst: Es muss ein Dialog "AI-Chat-Tool bestätigen" mit Parameterliste erscheinen; "Abbrechen" verhindert die Ausführung.
+Tracelinks:    SyRS-1027, SwRS-1042
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - KI-Zugriff auf ERP-Daten erfordert explizite Kontrolle.
+Status:        belegt
+Modul:         M-118
+
+ID:            StRS-1009
+Titel:         Zentrale Dateiablage mit Versionierung und exklusiver Bearbeitung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Sachbearbeiter
+Vorbedingung:  Benutzer ist angemeldet; ein Verzeichnis der Dateiablage ist ausgewählt.
+Fakt:          `ICentronFileSystemConnector`/`CentronFileSystemConnector` bietet Verzeichnis- und Dokumentoperationen (`CreateDirectory`, `GetSubDirectoriesAsync`, `AddDocumentToDirectoryAsync`, `RenameDocumentAsync`, `DeleteDocumentAsync`) sowie `AddNewDocumentVersion`, `CheckOutDocument`, `CheckInDocument`, `UndoCheckOut` und `CreateIndexesForDocument`. Serverseitig setzt `DocumentBL.CheckOutDocument` die Felder `LockedBy`, `LockedByWorkstation`, `LockedFilePath` am `Document`.
+Aussage:       Das System soll Dokumente in einer hierarchischen Ablage speichern, jede Änderung als neue Dokumentversion ablegen und ein in Bearbeitung befindliches Dokument mit Benutzer, Arbeitsstation und Ablagepfad als gesperrt kennzeichnen.
+Ergebnis:      Ein ausgechecktes Dokument ist erkennbar gesperrt; beim Einchecken wird die Sperre gelöst und eine neue Version erzeugt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/FileManagement/DocumentBL.cs, `CheckInDocument(int documentI3D, byte[] fileData, LoggedInUser currentUser)`: setzt `LockedFilePath/LockedBy/LockedByWorkstation = null` und ruft anschließend `this.AddNewDocumentVersion(document.I3D, fileData, currentUser)` - Begründung: durchsetzende Stelle für Sperraufhebung plus Versionsanlage.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/FileManagement/DocumentBL.cs, `CanCheckOutDocument(int documentI3D)`: `if (document.LockedBy != null && document.LockedByWorkstation != null && document.LockedFilePath != null) return Result<bool>.AsSuccess(false);` - Begründung: konkrete Sperrbedingung.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/CentronFileSystem/CentronFileSystemConnector.cs, Methodensatz inkl. `CreateIndexesForDocument(int documentI3D)` - Begründung: belegt den Funktionsumfang der Ablage im Client.
+Prüfidee:      Dokument auschecken; ein zweiter Benutzer ruft `CanCheckOutDocument` für dasselbe Dokument auf → Ergebnis `false`. Nach Check-In existiert eine zusätzliche Dokumentversion.
+Tracelinks:    SyRS-1031, SwRS-1043
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Dokumentenlenkung ist Grundfunktion des ERP.
+Status:        belegt
+Modul:         M-122

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_work/A1_StRS.md

@@ -0,0 +1,203 @@
+ID:            StRS-101
+Titel:         Einheitlicher Belegkreis über alle Verkaufsbelegarten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertriebsmitarbeiter / Sachbearbeiter
+Vorbedingung:  Der Benutzer ist angemeldet und einem Kunden bzw. Lieferanten zugeordnet.
+Fakt:          `ReceiptBase` (abstrakte Basisklasse) definiert für alle Belegarten dieselben Kopfdaten (`Version`, `State`, `ConcurrencyControlGuid`) und die abstrakten Operationen `ReceiptKind`, `GetReceiptItems()`, `SetReceiptItems()`, `AddItem()`, `RemoveItem()`. `SpecificLogics` registriert genau die konkreten Ausprägungen `CreditVoucherSpecificLogic`, `DeliveryListSpecificLogic`, `InvoiceSpecificLogic`, `OfferSpecificLogic`, `OrderSpecificLogic`, `PickupListSpecificLogic`, `ContractSpecificLogic` sowie die Lieferantenvarianten.
+Aussage:       Das System soll Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Abholschein und Vertrag als Ausprägungen eines einheitlichen Belegmodells mit gemeinsamen Kopf-, Positions- und Versionsdaten führen.
+Ergebnis:      Fachliche Regeln (Nummernvergabe, Sperre, Versionierung, Preisfindung) gelten belegartübergreifend; belegartspezifische Abweichungen sind auf die jeweilige `*SpecificLogic` begrenzt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptBase.cs, Zeilen 9-71 (`public abstract class ReceiptBase : BaseEntity, IReceiptBase`, `public abstract CentronObjectKindNumeric ReceiptKind { get; }`) - Begründung: Die gemeinsame Basisklasse mit abstraktem `ReceiptKind` erzwingt im Code, dass jede Belegart dasselbe Grundmodell erfüllt.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/SpecificLogics.cs, Zeilen 46-57 (`private readonly IReceiptSpecificLogic[] _receiptSpecificLogics = new IReceiptSpecificLogic[] { new CreditVoucherSpecificLogic(session), ... }`) - Begründung: Die Registrierungsliste ist die durchsetzende Stelle, an der der vollständige Belegkreis definiert ist.
+  - [KONTEXT]  docs/reference/receipts/receipts-backend-architecture.md, Abschnitt "Receipt Types Hierarchy" (Tabelle Entity-Klasse/Tabelle/View) - Begründung: Dokumentiert die 1:1-Zuordnung Entität → `*Kopf`/`*Pos`-Tabelle und bestätigt die Codebeobachtung.
+Prüfidee:      Für jede in `SpecificLogics` registrierte Belegart lässt sich ein Beleg anlegen, speichern, versionieren und wieder laden; die Kopfdaten `Version`, `State` und `ConcurrencyControlGuid` sind in allen Fällen befüllt.
+Tracelinks:    SyRS-111, SyRS-112, SyRS-113
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Das gemeinsame Belegmodell ist der tragende Kern der Fakturierung und in jeder Zielarchitektur erforderlich.
+Status:        belegt
+Modul:         M-01
+
+ID:            StRS-102
+Titel:         Belege nur durch berechtigte Benutzer bearbeitbar
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Sachbearbeiter / Rechteadministrator
+Vorbedingung:  Ein Beleg existiert und ein Benutzer versucht, ihn zu ändern oder eine neue Version anzulegen.
+Fakt:          `ReceiptBL.CanUserEditReceipt(...)` prüft zuerst `HasRightToEditReceipt(appUser)` und bricht mit `DefaultMessageCodes.RightCheckFailed` ab; anschließend wird bei gesetztem `HasRightToEditReceiptOnlyOwnBranch(appUser)` per `BranchBL.IsBranchEqual(appUser.Employee.BranchI3D, receiptBranchI3D)` auf die eigene Filiale eingeschränkt. Die Methode wird an mindestens acht Stellen von `ReceiptBL` aufgerufen (u. a. `CreateNewVersion<T>`, `SaveReceipt<T,TReceiptItem>`).
+Aussage:       Das System soll das Ändern eines Belegs nur zulassen, wenn der Benutzer das Bearbeitungsrecht für die betreffende Belegart besitzt und – sofern die Filialbeschränkung aktiv ist – der Beleg zu seiner Filiale gehört.
+Ergebnis:      Bei fehlendem Recht wird der Vorgang abgebrochen und eine benannte Fehlermeldung ("Der Benutzer hat nicht das Recht Belege vom Typ ... zu bearbeiten.") zurückgegeben; es erfolgt keine Persistierung.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeilen 10272-10295, Methode `CanUserEditReceipt(CentronObjectKindNumeric receiptKind, AppUser appUser, int? receiptBranchI3D)`; konkrete Prüfungen `if (!hasRightToEditReceipt) return Result.AsError(..., DefaultMessageCodes.RightCheckFailed);` und `BranchBL.IsBranchEqual(appUser.Employee.BranchI3D, receiptBranchI3D)` - Begründung: Dies ist die durchsetzende Stelle; ohne erfolgreichen Rückgabewert wird der Speicher-/Versionsvorgang in `SaveReceipt` bzw. `CreateNewVersion` verlassen.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeilen 3081-3083 und 3625-3627 (`var canEditReceiptResult = this.CanUserEditReceipt(...); if (canEditReceiptResult.Status == ResultStatus.Error) return result.SetMessage(...).GetResult();`) - Begründung: Belegt, dass die Prüfung tatsächlich vor der Persistierung greift und den Ablauf abbricht.
+Prüfidee:      Ein Benutzer ohne Bearbeitungsrecht für Rechnungen erhält beim Speichern einer Rechnung die Fehlermeldung mit MessageCode `RightCheckFailed`; ein Benutzer mit gesetztem "nur eigene Filiale"-Recht kann eine Rechnung einer fremden Filiale nicht speichern.
+Tracelinks:    SyRS-112, SyRS-113
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Rechtebasierte Belegbearbeitung ist rechtlich und organisatorisch zwingend.
+Status:        belegt
+Modul:         M-01
+
+ID:            StRS-103
+Titel:         Preisfindung nach fester Vorrangreihenfolge
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Sachbearbeiter / Preisfindung
+Vorbedingung:  Einem Beleg wird eine Artikelposition hinzugefügt; Kunde, ggf. Vertrag, Sondervereinbarung und Menge sind bekannt.
+Fakt:          `ReceiptItemPriceBL.GetBasePrice(...)` ermittelt den Basispreis in fester Reihenfolge: Ausgangswert ist `GetSellPriceForCustomer(article, customer)`; ein `SpecialAgreement` mit `EKVKReduction == 1` liefert einen prozentualen Nachlass; danach wird ein `ContractSpecialPrice` ausgewertet (10 Kombinationen aus `ContractSpecialPriceKind` × `ContractSpecialPriceChangeKind`); nur wenn kein Vertragspreis existiert, greift ein `CustomerSpecialPrice`; nur wenn auch dieser fehlt und eine Menge übergeben wurde, greift der Staffelpreis `GetArticleVolumePrice(article, quantity)`.
+Aussage:       Das System soll den Verkaufspreis einer Belegposition nach der Vorrangreihenfolge Vertragssonderpreis vor Kundensonderpreis vor Staffelpreis vor kundengruppenabhängigem Listenverkaufspreis ermitteln und Sondervereinbarungsnachlässe additiv als Prozentrabatt aufschlagen.
+Ergebnis:      Für eine Artikel-Kunden-Kombination ist der ermittelte Preis reproduzierbar und die angewandte Preisquelle nachvollziehbar.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptItemPriceBL.cs, Zeilen 154-286, Methode `GetBasePrice(decimal purchaseBasePrice, IPricedArticle article, Customer customer, int? contractI3D, SpecialAgreement specialAgreement, decimal? quantity, decimal? sellPrice, int? priceList)`; die `if (contractSpecialPrice is not null) { ... } else { specialPrice ... else if (quantity != null) { volumePrice } }`-Kaskade - Begründung: Die verschachtelte Bedingungskette ist die durchsetzende Stelle der Vorrangreihenfolge.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptItemPriceBL.cs, Zeilen 280-283 (`if (discountAsFixedPrice != 0 && basePrice != 0) { discountAsPercentage += (discountAsFixedPrice / basePrice) * 100; }`) - Begründung: Belegt, dass Festbetragsnachlässe systematisch in Prozentrabatte umgerechnet werden, weil die Belegposition nur `BasePrice` und `Discount` speichert.
+Prüfidee:      Für einen Artikel mit gleichzeitig hinterlegtem Vertragssonderpreis, Kundensonderpreis und Staffelpreis liefert `GetBasePrice` den Vertragssonderpreis; nach Löschen des Vertragsbezugs den Kundensonderpreis; nach Löschen des Kundensonderpreises den Staffelpreis.
+Tracelinks:    SyRS-115, SyRS-116
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Preisfindung ist die zentrale Wertschöpfungsregel des Belegwesens.
+Status:        belegt
+Modul:         M-02
+
+ID:            StRS-104
+Titel:         Belegartübergreifende Suche mit einheitlichem Filter
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Sachbearbeiter / Vertrieb
+Vorbedingung:  Der Benutzer öffnet die Belegsuche und gibt mindestens ein Suchkriterium an.
+Fakt:          `ReceiptSearcher` iteriert über zwölf registrierte `ReceiptSearchConfiguration`-Instanzen (Angebot, Auftrag, Lieferschein, Abholschein, Rechnung, Gutschrift, Vertrag sowie fünf Lieferantenvarianten) und führt für jede eine eigene, aus demselben `ReceiptSearchFilter` erzeugte SQL-Abfrage aus; das Ergebnis wird zu einer Liste `ReceiptSearchItemDTO` zusammengeführt und mit `.OrderBy(f => f.ObjectKind).ThenByDescending(f => f.Number)` sortiert.
+Aussage:       Das System soll eine gemeinsame Suchmaske bereitstellen, mit der Belege aller Belegarten anhand desselben Kriteriensatzes (Nummer, Datum, Konto, Betrag, Zahlungs-/Lieferkondition, Positionstext, Artikel u. a.) gefunden werden können.
+Ergebnis:      Der Benutzer erhält eine belegartübergreifende, seitenweise Trefferliste mit Kopfdaten, Beträgen, Status und Konditionen je Treffer.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/ReceiptSearcher.cs, Zeilen 27-42 (Konstruktor mit dem `ReceiptSearchConfiguration[]`-Array) und Zeilen 48-79 (`SearchReceipts(ReceiptSearchFilter filter, LoggedInUser user)`) - Begründung: Die Registrierungsliste und die Iterationsschleife setzen die belegartübergreifende Suche durch.
+  - [SEKUNDÄR] src/backend/Centron.Interfaces/Sales/Receipts/ReceiptSearch/ReceiptSearchFilter.cs (Filtereigenschaften `SearchText`, `ReceiptNumber`, `DateFrom`/`DateTo`, `AccountI3D`, `GrossPriceFrom`/`GrossPriceTo`, `PaymentConditionI3D`, `DeliveryConditionI3D`, `ArticleI3Ds`) - Begründung: Definiert den fachlichen Kriteriensatz, der für alle Belegarten gilt.
+Prüfidee:      Eine Suche ohne Einschränkung auf `ReceiptKinds` liefert Treffer aus mindestens zwei unterschiedlichen `ObjectKind`-Werten; eine Suche mit `ReceiptKinds = {InvoiceClass}` liefert ausschließlich `ObjectKind = 4`.
+Tracelinks:    SyRS-117, SyRS-118, SyRS-119
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Belegartübergreifende Recherche ist eine Kernanforderung des Tagesgeschäfts.
+Status:        belegt
+Modul:         M-03
+
+ID:            StRS-105
+Titel:         Zahlungs-, Liefer- und Belegkonditionen als zentrale Stammdaten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Stammdatenverwalter
+Vorbedingung:  Der Benutzer öffnet das Modul "Belegkonditionen".
+Fakt:          Der Modulcontroller `ReceiptConditionManagementAppModuleController` deklariert `ModuleName => "Belegkonditionen"` und `Description => "Verwaltung von Belegkonditionen, Zahlungskonditionen und Lieferbedingungen"`. Die zugehörige Entität `AssetCondition` ist per `AssetConditionMaps` auf die Tabelle `Zahkond` gemappt; die Spalten `GltAnge`, `GltAuf`, `GltLief`, `GltRech`, `GltGuts`, `GltAbhol`, `GltBestellung`, `GltLiefgutschrift`, `GltLieferbedingung`, `GltLieferbedingungLieferant` steuern, für welche Belegart eine Kondition gilt.
+Aussage:       Das System soll Zahlungs-, Liefer- und Belegkonditionen in einem gemeinsamen Stammdatensatz verwalten und je Kondition festlegen, für welche Belegarten sie auswählbar ist.
+Ergebnis:      In einem Beleg werden nur die Konditionen zur Auswahl gestellt, deren belegartspezifisches "Gilt-für"-Kennzeichen gesetzt ist.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.DAO/Mappings/Administration/MasterData/AssetConditionMaps.cs, Zeilen 10-38 (`Table("Zahkond");` sowie `Map(aa => aa.BelongsToOffer).Column("GltAnge");` bis `Map(aa => aa.SupplierDeliveryCondition).Column("GltLieferbedingungLieferant");`) - Begründung: Das Mapping ist die durchsetzende Stelle, die die belegartbezogene Gültigkeit im Datenmodell verankert.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, Zeilen 6846-6906, `CREATE TABLE [dbo].[Zahkond]` mit `CONSTRAINT [PK_Zahkond] PRIMARY KEY CLUSTERED ([I3D] ASC)` - Begründung: Bestätigt Existenz und Struktur der Konditionstabelle inklusive Primärschlüssel.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Administration/ReceiptConditions/ReceiptConditionManagementAppModuleController.cs, Zeilen 18-19 (UI-Strings `"Belegkonditionen"`, `"Verwaltung von Belegkonditionen, Zahlungskonditionen und Lieferbedingungen"`) - Begründung: Belegt die fachliche Bündelung der drei Konditionsarten in einem Modul.
+Prüfidee:      Eine Kondition mit `GltRech = 1` und `GltAnge = 0` erscheint in der Zahlungskonditionsauswahl einer Rechnung, nicht aber in der eines Angebots.
+Tracelinks:    SyRS-120, SyRS-121
+Konsolidierung: Kandidat: Zahlungskondition, Lieferbedingung und Belegkondition sind fachlich getrennte Konzepte, teilen sich aber Tabelle `Zahkond` und Entität `AssetCondition`.
+Übernahmewürdigkeit: Workaround - Die Bündelung dreier fachlicher Konzepte in einer Tabelle mit Boolean-Spalten pro Belegart ist historisch bedingt und sollte in einer Neuentwicklung getrennt modelliert werden.
+Status:        belegt
+Modul:         M-04
+
+ID:            StRS-106
+Titel:         Provisionierung von Belegen an Provisionsempfänger
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertriebsleitung / Provisionsempfänger
+Vorbedingung:  Ein Kundenbeleg wird angelegt oder gespeichert; für den Kunden ist ein Provisionsschema ermittelbar oder eine Auto-Provisionierung konfiguriert.
+Fakt:          `ReceiptProvisionBL.FillNewReceiptWithDefaultProvision(...)` befüllt neue Belege, die `IReceiptWithProvision` implementieren, entweder aus dem Provisionsschema (`GetCurrentReceiptProvisionForReceipt(customerI3D, branchI3D)`) oder – falls keine Schemata existieren – über `AutoProvisionForNewReceipts()`, `GetEmployeeForAutoProvision(...)` und `GetAutoProvisionShare()`. Beim Speichern schreibt `SaveProvision(...)` je Empfänger eine `ReceiptProvisionItemEntity` mit `ActualProvisionSales`, `ActualProvisionEarnings` und `ActualProvision`.
+Aussage:       Das System soll für provisionsfähige Belege je Provisionsempfänger den Provisionsanteil und den daraus resultierenden Provisionsbetrag ermitteln und belegbezogen speichern.
+Ergebnis:      Zu jedem gespeicherten provisionsfähigen Beleg existieren Provisionsdatensätze mit aufgelöstem Mitarbeiter, Anteil und berechnetem Provisionsbetrag, die in der Provisionsauswertung erscheinen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptProvisionBL.cs, Zeilen 161-268, Methode `SaveProvision(IReceiptBase receipt, IReceiptBase previousReceiptVersion, SaveReceiptData data, SaveReceiptResultBuilder result)`; erzeugt `new ReceiptProvisionItemEntity { ... ActualProvision = pricesAndProvisions.ProvisionSales.GetValueOrDefault() + pricesAndProvisions.ProvisionEarnings.GetValueOrDefault() }` - Begründung: Die Persistierung der berechneten Provisionsbeträge ist die durchsetzende Stelle.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptProvisionBL.cs, Zeilen 171-178 (`if (this._specificLogics.Execute(receipt, f => f.IsProvisionRequired()) && data.IgnoreCallbacks == false) { result.SetMessage("Provisionierung fehlt.", SaveReceiptErrorMissingField.Provision); return; }`) - Begründung: Belegt, dass die Provisionierung für bestimmte Belegarten erzwungen wird.
+Prüfidee:      Für einen Kunden mit zugeordnetem Provisionsschema entstehen beim Speichern eines Auftrags so viele `ReceiptProvisionItemEntity`-Sätze wie das Schema Empfänger definiert, jeweils mit gefülltem `ActualEmployeeI3D`.
+Tracelinks:    SyRS-122
+Konsolidierung: Kandidat: Schema-basierte Provisionierung (`ReceiptProvisionItemEntity`) und altes Provisionsverfahren (NamedQuery über `{TablePrefix}Provision`) implementieren dasselbe fachliche Konzept doppelt.
+Übernahmewürdigkeit: übernehmen - Provisionsabrechnung ist ein eigenständiges Geschäftsziel; das alte Verfahren sollte dabei abgelöst werden.
+Status:        belegt
+Modul:         M-05
+
+ID:            StRS-107
+Titel:         Umsatzsteuerermittlung je Belegposition
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Buchhaltung / Sachbearbeiter
+Vorbedingung:  Eine Artikelposition wird einem Beleg mit einem Belegdatum hinzugefügt.
+Fakt:          `ValueAddedTax` trägt `TaxRate`, `Country`, `ExpirationDate`, `TaxRateValidFrom`, `NextTaxRate`, `Default`, `UseForDeaktivatedVat` sowie getrennte Erlös- und Aufwandskonten für Inland, EU und Drittland (`RevenueAccount`, `RevenueAccountEU`, `RevenueAccountOverseas`, `ExpenseAccount`, `ExpenseAccountEU`, `ExpenseAccountOverseas`). `TaxBL.GetDefaultTaxtRateByArticle(int? artikelI3D)` ermittelt den Steuersatz in der Reihenfolge Artikel-MwSt (`article.VAT`) → sekundäre Warengruppe (`article.SecondaryMaterialGroup.VatI3D`) → Warengruppe (`article.MaterialGroup.VatI3D`) → Landesvorgabe (`GetDefaultTaxtRateByCountry()`).
+Aussage:       Das System soll den Umsatzsteuersatz einer Belegposition aus dem Artikel, ersatzweise aus dessen Warengruppen und zuletzt aus der Landesvorgabe ableiten und dabei getrennte Erlös-/Aufwandskonten für Inland, EU und Drittland führen.
+Ergebnis:      Jede Artikelposition trägt einen eindeutig hergeleiteten Steuersatz mit zugehöriger Kontenzuordnung für die Finanzbuchhaltung.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Warehousing/TaxBL.cs, Zeilen 239-284, Methoden `GetDefaultTaxtRateByArticle(int? artikelI3D)` und `GetDefaultTaxtRateByCountry()`; die Fallback-Kette `article.VAT` → `secondaryMaterialGroupTaxRate` → `materialGroupTaxRate` → `GetDefaultVatForDeaktivatedVat(countryI3D)` - Begründung: Die if-Kaskade ist die durchsetzende Stelle der Steuerermittlung.
+  - [PRIMÄR]   src/backend/Centron.Entities/Entities/Warehousing/ValueAddedTax.cs, Zeilen 10-29 (Eigenschaften `TaxRate`, `Country`, `RevenueAccount`, `RevenueAccountEU`, `RevenueAccountOverseas`, `ExpenseAccount`, `ExpenseAccountEU`, `ExpenseAccountOverseas`, `ExpirationDate`, `NextTaxRate`) - Begründung: Das Datenmodell belegt die geforderte Kontendifferenzierung und die Zeitabhängigkeit.
+Prüfidee:      Ein Artikel ohne eigene MwSt-Zuordnung, dessen Warengruppe 7 % trägt, erhält beim Hinzufügen in einen Beleg 7 %; nach Setzen einer Artikel-MwSt von 19 % erhält er 19 %.
+Tracelinks:    SyRS-123, SyRS-124
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Steuerermittlung ist gesetzlich zwingend und geschäftskritisch.
+Status:        belegt
+Modul:         M-06
+
+ID:            StRS-108
+Titel:         Digitale Erfassung von Lieferantenbelegen aus PDF-Dokumenten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Einkaufssachbearbeiter
+Vorbedingung:  Ein Lieferantenbeleg liegt als PDF vor (z. B. aus E-Mail-Eingang) und für den Lieferanten ist mindestens eine Scan-Konfiguration hinterlegt.
+Fakt:          Der Modulcontroller `SupplierReceiptDocumentsImportAppModuleController` deklariert `ModuleName => "Eingang/Kalk"` und `Description => "Import von Lieferantenbelegen aus E-Mails"`. `SupplierReceiptDocumentBL.ScanDocument(LoggedInUser, int supplierI3D, SupplierReceiptDocumentKind kind, byte[] pdf)` lädt die lieferantenspezifischen `SupplierPdfScanConfigs`, liest mit `PdfScanner.TryFindValue(config, Color.Empty)` definierte Bereiche aus und liefert `DocumentMetaInformation`-Objekte für "Rechnungsnummer", "Eigene Bestellnummer", "Rechnungsdatum", "Netto Summe", "Brutto Summe", "Fracht" und "Versicherung".
+Aussage:       Das System soll aus eingehenden Lieferanten-PDFs anhand lieferantenspezifischer Scan-Konfigurationen Belegnummer, Bestellnummer, Belegdatum, Netto-/Bruttosumme sowie Fracht- und Versicherungsbeträge automatisch auslesen und als Vorschlagswerte für die Belegerfassung bereitstellen.
+Ergebnis:      Der Sachbearbeiter erhält vorbefüllte Belegkopfdaten und muss diese nur noch prüfen und bestätigen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/SupplierReceiptDocuments/SupplierReceiptDocumentBL.cs, Zeilen 411-461, Methode `ScanDocument(...)`; `using (var scanner = new PdfScanner(pdf)) { ... var scanResult = scanner.TryFindValue(config, Color.Empty); var metaInformation = this.GetMetaInformation(config.Name, scanResult); ... }` - Begründung: Die Scan-Schleife über die Lieferantenkonfiguration ist die durchsetzende Stelle der automatisierten Erfassung.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/SupplierReceiptDocuments/SupplierReceiptDocumentBL.cs, Zeilen 479-500, Methode `GetMetaInformation(string configName, PdfScannerResult scanResult)` mit dem `switch`-Block über die Konfigurationsnamen - Begründung: Legt den verbindlichen Satz auslesbarer Felder fest.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/Receipts/SupplierReceiptDocuments/SupplierReceiptDocumentsImportAppModuleController.cs, Zeilen 22-23 (UI-Strings `"Eingang/Kalk"`, `"Import von Lieferantenbelegen aus E-Mails"`) - Begründung: Belegt den fachlichen Zweck des Moduls.
+Prüfidee:      Für einen Lieferanten mit hinterlegter Scan-Konfiguration liefert `ScanDocument` mit einem Muster-PDF eine `DocumentMetaInformation` vom Typ `ReceiptNumber` mit der im PDF sichtbaren Rechnungsnummer.
+Tracelinks:    SyRS-125
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Automatisierte Belegerfassung senkt den Erfassungsaufwand im Einkauf spürbar.
+Status:        belegt
+Modul:         M-07
+
+ID:            StRS-109
+Titel:         Lückenlose Protokollierung von Belegausgabe und Belegänderungen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Sachbearbeiter / Revision
+Vorbedingung:  Ein Beleg wird gedruckt, als PDF exportiert, per E-Mail versendet oder inhaltlich verändert.
+Fakt:          `ReceiptLogBL.CreateReportEntry(AppUser, ReportAction, string reportName, int receiptI3D, CentronObjectKindNumeric receiptKind, int? receiptVersion, string receiptEmail)` legt je Ausgabeaktion einen Logeintrag an: `ReportAction.Export` → `ReceiptLogKind.PDFExport`, `ReportAction.Print` → `ReceiptLogKind.Print`, `ReportAction.Mail` → `ReceiptLogKind.Mail` (inkl. E-Mail-Adresse); für `ReportAction.Preview` wird bewusst kein Eintrag erzeugt (`return; //Create no logs for preview`). `CreateEntry(...)` schreibt Mitarbeiter, Zeitpunkt, Belegversion und die c-entron-Programmversion mit.
+Aussage:       Das System soll jede Belegausgabe (Druck, PDF-Export, Mailversand) sowie wesentliche inhaltliche Änderungen mit Benutzer, Zeitpunkt, Belegversion und Programmversion protokollieren; reine Vorschauen sollen nicht protokolliert werden.
+Ergebnis:      Zu jedem Beleg ist nachvollziehbar, wer ihn wann in welcher Version ausgegeben oder geändert hat.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptLogBL.cs, Zeilen 147-189, Methode `CreateReportEntry(...)`; `switch (reportAction) { case ReportAction.Preview: return; case ReportAction.Export: logKind = ReceiptLogKind.PDFExport; ... }` - Begründung: Die Fallunterscheidung ist die durchsetzende Stelle für Umfang und Ausschluss der Ausgabeprotokollierung.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptLogBL.cs, Zeilen 102-115, Methode `CreateEntry(...)`; setzt `log.Date`, `log.ReceiptVersion`, `log.Employee`, `log.CentronVersion = AssemblyLogic.GetFromAssemblyContaining<ReceiptLogBL>().ToString()` und speichert über `this.Session.GetGenericDAO<ReceiptLog>().Save(log)` - Begründung: Belegt die tatsächlich persistierten Protokollattribute.
+  - [SEKUNDÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/InvoiceReceiptSearchConfiguration.cs, Zeilen 58-59 (`PrintedVersion = (SELECT TOP 1 al.AnlageVersion FROM AnlageLog al WHERE al.AnlageI3D = AK.I3D AND al.AnlageArt = 4 AND al.Art = 2 ...)`) - Begründung: Zeigt, dass die Protokolleinträge fachlich ausgewertet werden, um gedruckte und gemailte Belegversionen anzuzeigen.
+Prüfidee:      Nach Druck einer Rechnung existiert ein `AnlageLog`-Satz mit `AnlageArt = 4`, `Art = 2`, korrekter `AnlageVersion` und `PersonalI3D` des Druckenden; nach einer reinen Vorschau entsteht kein zusätzlicher Satz.
+Tracelinks:    SyRS-126, SyRS-127
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Nachvollziehbarkeit der Belegausgabe ist Grundlage von Reklamations- und Prüfprozessen.
+Status:        belegt
+Modul:         M-08
+
+ID:            StRS-110
+Titel:         Kreditlimitüberwachung beim Speichern von Kundenbelegen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Sachbearbeiter / Debitorenbuchhaltung
+Vorbedingung:  Für den Kunden ist ein Kreditlimit (`CreditLimit > 0`) und eine Berechnungsart (`CreditLimitCalculationKind` ungleich 2) hinterlegt; ein limitrelevanter Beleg wird gespeichert.
+Fakt:          `ReceiptBL.CheckIfCustomerLimitIsReached(...)` summiert über alle `SpecificLogics`, für die `TakesPlaceInLimitCalculation(null)` gilt, den Wert `GetUsedLimitAmount(customerI3D, limitCalculationKind)`, zieht den Wert der Vorversion ab und vergleicht `limitUsedInThisReceipt > limitAvailable`. Die Berechnungsart wird über `customer.CreditLimitCalculationKind == 1 ? CreditLimitCalculationKind.Net : CreditLimitCalculationKind.Gross` gewählt. Abschließend wird `customer.CreditLimitAvailable = limitAvailable - limitUsedInThisReceipt` fortgeschrieben.
+Aussage:       Das System soll beim Speichern eines limitrelevanten Kundenbelegs das ausgeschöpfte Kreditlimit über alle offenen Belegarten hinweg wahlweise netto oder brutto ermitteln und bei Überschreitung eine ausdrückliche Bestätigung des Benutzers verlangen.
+Ergebnis:      Der Beleg wird nur nach expliziter Bestätigung (`SaveAlthoughCustomerLimitExceeded`) gespeichert; das verfügbare Restlimit des Kunden wird aktualisiert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeilen 8636-8690, Methode `CheckIfCustomerLimitIsReached(IReceiptBase receipt, IReceiptBase previousVersion, SaveReceiptData data, SaveReceiptResultBuilder result)`; die Bedingung `if (limitUsedInThisReceipt > limitAvailable && data.SaveAlthoughCustomerLimitExceeded == false && data.IgnoreCallbacks == false)` - Begründung: Diese Bedingung ist die durchsetzende Stelle der Limitprüfung.
+  - [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeile 8681 (Meldungstext `"Das Limit von {customer.CreditLimit:N2} ... wurde um {difference:N2} ... überschritten."`) - Begründung: Belegt die fachliche Rückmeldung an den Benutzer inkl. Aufschlüsselung nach Belegarten.
+Prüfidee:      Ein Kunde mit Kreditlimit 1.000 € und 900 € offenen Belegen erhält beim Speichern eines weiteren Belegs über 200 € den Bestätigungsdialog; nach Bestätigung ist `CreditLimitAvailable` negativ.
+Tracelinks:    SyRS-114
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kreditlimitüberwachung schützt unmittelbar vor Forderungsausfällen.
+Status:        belegt
+Modul:         M-01

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_work/A1_SyRS.md

@@ -0,0 +1,348 @@
+ID:            SyRS-111
+Titel:         Kollisionsfreie Vergabe der Belegnummer beim Speichern
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (ReceiptBL / NumberGroupBL)
+Vorbedingung:  Ein neuer Beleg wird gespeichert und `data.IsOnlyForReportPreview` ist `false`.
+Fakt:          `ReceiptBL.ShouldUpdateNumberOnSave(bool isNewReceipt, SaveReceiptData data)` liefert `isNewReceipt && data.IsOnlyForReportPreview == false`; nur dann ruft `SaveReceipt` `UpdateReceiptNumber(receipt, updateDatabase: true)` auf. `UpdateReceiptNumber` bestimmt die Nummerngruppe über `_specificLogics.Execute(receipt, f => f.GetNumberGroup(receipt))` und – falls `receipt.BranchI3D > 0` – die filialbezogene `NumberGroup`. Für Belegvorlagen (Kunde == `GetReceiptTemplateCustomerNumber()`) wird stattdessen `_receiptTemplateBL.GetNextReceiptTemplateNumber(receipt)` verwendet. Die Nummernvergabe erfolgt erst nach allen positionsverändernden Schritten ("UPDATE REGION 1").
+Aussage:       Das System soll die endgültige Belegnummer erst beim tatsächlichen Speichern eines neuen Belegs vergeben, dabei die Nummerngruppe belegart- und filialabhängig auswählen und Belegvorlagen aus einem separaten Nummernkreis versorgen.
+Ergebnis:      Reine Reportvorschauen und abgebrochene Speichervorgänge verbrauchen keine Belegnummer; Filialen erhalten getrennte Nummernkreise.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeilen 8573-8576, Methode `ShouldUpdateNumberOnSave(bool isNewReceipt, SaveReceiptData data)` mit `return isNewReceipt && data.IsOnlyForReportPreview == false;` - Begründung: Diese Bedingung entscheidet als einzige Stelle, ob eine Nummer verbraucht wird.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeilen 7265-7285, Methode `UpdateReceiptNumber(IReceiptBase receipt, bool updateDatabase)`; Zweig `receipt.Number = isTemplate ? this._receiptTemplateBL.GetNextReceiptTemplateNumber(receipt) : this._numberGroupBL.GetNextNumber(numberGroupEnum, numberGroupObject, updateDatabase);` - Begründung: Zeigt die belegart-, filial- und vorlagenabhängige Auswahl der Nummernquelle.
+  - [KONTEXT]  src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeilen 3796-3803 (Kommentar "Create Number If Needed (should be the last method, of the 'UPDATE REGION 1'" ... "The new number group for 0,00 invoices is dependent on the positions.") - Begründung: Erklärt, warum die Nummernvergabe zwingend nach der Positionsverarbeitung erfolgt.
+Prüfidee:      Ein Speichervorgang mit `IsOnlyForReportPreview = true` erhöht `NumberGroup.Current` nicht; ein regulärer Speichervorgang erhöht ihn genau um das konfigurierte `Interval`.
+Tracelinks:    StRS-101, SwRS-128
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Lückenlose, nicht vorzeitig verbrauchte Belegnummern sind eine Grundanforderung der Fakturierung.
+Status:        belegt
+Modul:         M-01
+
+ID:            SyRS-112
+Titel:         Exklusive Belegsperre für den bearbeitenden Benutzer
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System (AssetLockBL) / Sachbearbeiter
+Vorbedingung:  Ein Benutzer möchte eine neue Belegversion anlegen oder einen Beleg bearbeiten.
+Fakt:          `AssetLockBL<T>.LockReceipt(int receiptI3D, AppUser appUser, int rightID)` prüft `IsAssetLocked(receiptI3D, out var lockedBy) && lockedBy != appUser.Employee.ShortSign`. Ist der Beleg fremdgesperrt, wird abhängig von `_appRightsBL.HasUserRight(appUser.I3D, rightID)` eine von zwei Fehlermeldungen zurückgegeben; erst danach wird über `LockAssetById(appUser, receiptI3D)` gesperrt. `InvoiceSpecificLogic.TryLockReceipt` übergibt als `rightID` `UserRightsConst.Sales.Customer.CustomerCommon.UNLOCK_CUSTOMER_ATTACHMENTS`. `ReceiptBL.CreateNewVersion<T>` bricht bei `canLockResult.Status != ResultStatus.Success` mit `ReceiptIsLockedFromOtherUser = true` ab.
+Aussage:       Das System soll einen Beleg beim Beginn der Bearbeitung exklusiv für den bearbeitenden Benutzer sperren und eine bestehende Fremdsperre nur von Benutzern mit dem Entsperrrecht überschreiben lassen.
+Ergebnis:      Parallele Änderungen desselben Belegs durch zwei Benutzer werden verhindert; der sperrende Benutzer wird in der Fehlermeldung namentlich genannt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AssetLockBL.cs, Zeilen 48-68, Methode `LockReceipt(int receiptI3D, AppUser appUser, int rightID)`; Bedingung `if (this.IsAssetLocked(receiptI3D, out var lockedBy) && lockedBy != appUser.Employee.ShortSign)` mit anschließender Rechteprüfung `this._appRightsBL.HasUserRight(appUser.I3D, rightID)` - Begründung: Dies ist die durchsetzende Stelle der Sperrlogik inklusive Rechteprüfung.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeilen 3093-3096 (`Result canLockResult = this._specificLogics.Execute<Result, T>(f => f.TryLockReceipt(receiptI3D, appUser)); if (canLockResult.Status != ResultStatus.Success) return result.Set(f => f.ReceiptIsLockedFromOtherUser, true, canLockResult.Message).GetResult();`) - Begründung: Belegt, dass die Sperre den Versionierungsvorgang tatsächlich blockiert.
+  - [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs, Zeilen 191-194 (`return this._lockBL.LockReceipt(receiptI3D, appUser, UserRightsConst.Sales.Customer.CustomerCommon.UNLOCK_CUSTOMER_ATTACHMENTS);`) - Begründung: Zeigt das konkret geforderte Recht für Rechnungen.
+Prüfidee:      Benutzer A öffnet eine Rechnung zur Bearbeitung; Benutzer B ohne `UNLOCK_CUSTOMER_ATTACHMENTS` erhält beim Versuch einer neuen Version die Meldung "Der Beleg ist von dem Benutzer A gesperrt und Sie haben nicht das Recht ... zu entsperren."
+Tracelinks:    StRS-102, SwRS-129
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Pessimistische Belegsperre verhindert widersprüchliche Belegstände.
+Status:        belegt
+Modul:         M-01
+
+ID:            SyRS-113
+Titel:         Rechte- und Filialprüfung vor jeder Belegänderung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System (ReceiptBL)
+Vorbedingung:  Ein Speicher-, Versionierungs- oder Änderungsvorgang auf einem Beleg wird ausgelöst.
+Fakt:          `ReceiptBL` ruft `CanUserEditReceipt(receiptKind, appUser, receipt.BranchI3D)` an acht Stellen auf (Zeilen 3081, 3625, 4804, 4839, 4880, 4921, 5114, 5268). Für neue Belege prüft `SaveReceipt` zusätzlich `CanUserCreateNewReceiptsAtCustomerOrSupplier<T>(currentUser, receipt.GetAccount().AccountI3D)` und `CanUserCreateReceiptsInBranch<T>(currentUser, receipt.BranchI3D)`. `CanUserViewReceipt` verweigert Web-Konten grundsätzlich die Beleganzeige ("Web-Benutzer haben keine Berechtigung Belege einzusehen.").
+Aussage:       Das System soll vor dem Anlegen, Ändern und Versionieren eines Belegs Bearbeitungsrecht, Kunden-/Lieferantenbezug und Filialzugehörigkeit prüfen und den Vorgang bei fehlender Berechtigung mit MessageCode `RightCheckFailed` abbrechen.
+Ergebnis:      Nicht berechtigte Vorgänge werden vor jeder Datenbankänderung abgewiesen; die Ablehnung ist maschinell auswertbar.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeilen 3604-3610, Block im `SaveReceipt<T, TReceiptItem>` für `isNewReceipt`; `var canCreateNewReceiptsResult = this.CanUserCreateNewReceiptsAtCustomerOrSupplier<T>(currentUser, receipt.GetAccount().AccountI3D); if (... == ResultStatus.Error) return result.SetMessage(...).GetResult();` sowie `CanUserCreateReceiptsInBranch<T>(currentUser, receipt.BranchI3D)` - Begründung: Durchsetzende Stelle für die Anlageberechtigung vor der Persistierung.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeilen 10297-10311, Methode `CanUserViewReceipt(LoggedInUser loggedInUser, int receiptI3D, CentronObjectKindNumeric objectKind)`; `if (loggedInUser.IsWebAccountLogin) return Result.AsError("Web-Benutzer haben keine Berechtigung Belege einzusehen.", DefaultMessageCodes.RightCheckFailed);` - Begründung: Konkrete Prüfung, die Web-Konten von der direkten Beleganzeige ausschließt.
+Prüfidee:      Ein Web-Account-Login erhält bei `CanUserViewReceipt` stets einen Fehler mit `RightCheckFailed`; ein c-entron-Benutzer ohne Anlagerecht kann in keiner Belegart einen neuen Beleg speichern.
+Tracelinks:    StRS-102, SwRS-129
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zentrale, vor jeder Persistierung ausgeführte Rechteprüfung ist Sicherheitsgrundlage.
+Status:        belegt
+Modul:         M-01
+
+ID:            SyRS-114
+Titel:         Bestätigungspflicht bei Kreditlimitüberschreitung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (ReceiptBL) / Sachbearbeiter
+Vorbedingung:  Ein limitrelevanter Kundenbeleg wird gespeichert, `data.IgnoreCallbacks` ist `false`.
+Fakt:          `ReceiptBL.CheckIfCustomerLimitIsReached(...)` setzt bei Überschreitung `result.Set(f => f.ShowCustomerLimitExceededDialog, true, ...)` mit einer Meldung, die Limit, Überschreitungsbetrag, Verbrauch je Belegart und den Anteil des aktuellen Belegs auflistet. Ein Speichern ohne Rückfrage ist nur möglich, wenn `data.SaveAlthoughCustomerLimitExceeded == true` gesetzt wurde. Kunden mit `CreditLimitCalculationKind == null`, `== 2` oder `CreditLimit <= 0` sind von der Prüfung ausgenommen.
+Aussage:       Das System soll bei Überschreitung des Kundenkreditlimits den Speichervorgang unterbrechen und erst nach ausdrücklicher Benutzerbestätigung fortsetzen; Kunden ohne konfiguriertes Limit sollen von der Prüfung ausgenommen sein.
+Ergebnis:      Der Benutzer sieht vor dem Speichern die Limitauslastung je Belegart und entscheidet bewusst über die Fortsetzung.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeilen 8673-8686 (`if (limitUsedInThisReceipt > limitAvailable && data.SaveAlthoughCustomerLimitExceeded == false && data.IgnoreCallbacks == false) { ... result.Set(f => f.ShowCustomerLimitExceededDialog, true, ...); }`) - Begründung: Die Bedingung ist die durchsetzende Stelle der Rückfragepflicht.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeilen 8652-8655 (`if (customer.CreditLimitCalculationKind == null || customer.CreditLimitCalculationKind == 2 || customer.CreditLimit <= 0) return;`) - Begründung: Definiert die Ausnahmebedingung eindeutig.
+Prüfidee:      Bei `CreditLimitCalculationKind = 2` wird kein Dialog ausgelöst, unabhängig vom Belegbetrag; bei `= 1` (netto) löst ein Beleg oberhalb des Restlimits den Dialog aus.
+Tracelinks:    StRS-110
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Bewusste Limitentscheidung statt stiller Blockade entspricht der Vertriebspraxis.
+Status:        belegt
+Modul:         M-01
+
+ID:            SyRS-115
+Titel:         Mindestpreisprüfung je Artikelposition mit Rechte-Ausnahme
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (ReceiptBL) / Sachbearbeiter
+Vorbedingung:  Ein Kundenbeleg mit Artikelpositionen wird gespeichert; der Benutzer besitzt nicht das Recht zum Ignorieren von Mindestpreisen.
+Fakt:          `ReceiptBL.CheckArticleMinPrices(...)` verlässt sich sofort, wenn `currentUser.HasUserRight(UserRightsConst.Sales.Customer.CustomerCommon.Offer.ALLOW_IGNORE_MINIMUM_PRICE)` gilt, wenn `data.IgnoreCallbacks` gesetzt ist oder wenn `receipt.ReceiptKind.IsSupplierReceipt()` zutrifft. Andernfalls wird je Position mit `Kind == ReceiptItemKind.Article` (ohne Spezialartikelcodes aus `_receiptItemSpecialArticleHelperBL.GetArticleCodes()`) `currentPrice.NetPrice` gegen `article.MinPrice` verglichen; bei `data.UpdateArticlePricesBecauseOfMinPrice == true` wird über `_receiptItemPriceBL.ChangeBasePrice(item, minPrice)` korrigiert.
+Aussage:       Das System soll beim Speichern eines Kundenbelegs prüfen, ob eine Artikelposition den artikelspezifischen Mindestpreis unterschreitet, und dem Benutzer wahlweise die Preiskorrektur auf den Mindestpreis oder die bewusste Beibehaltung anbieten; Benutzer mit dem Recht `ALLOW_IGNORE_MINIMUM_PRICE` sollen von der Prüfung ausgenommen sein.
+Ergebnis:      Unterschreitungen des Mindestpreises werden entweder korrigiert oder protokolliert (`_logger.Info("Article {0} ({1}) has a minimum price violation. Current: {2} < Minimum: {3}")`).
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeilen 9036-9081, Methode `CheckArticleMinPrices(IReceiptBase receipt, AppUser currentUser, SaveReceiptData data, SaveReceiptResultBuilder result)`; Ausstiegsbedingung `if (currentUser.HasUserRight(UserRightsConst.Sales.Customer.CustomerCommon.Offer.ALLOW_IGNORE_MINIMUM_PRICE)) return;` und Vergleich `if (currentPrice.NetPrice >= minPrice) continue;` - Begründung: Prüfung und Rechte-Ausnahme sind an dieser Stelle durchgesetzt.
+  - [SEKUNDÄR] src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs, Zeile 2196 (`public const int ALLOW_IGNORE_MINIMUM_PRICE = 20400031;`) - Begründung: Verifiziert die Existenz und Nummer des ausnehmenden Rechts.
+Prüfidee:      Eine Position mit Nettopreis unter `Article.MinPrice` löst für einen Benutzer ohne Recht 20400031 die Rückfrage aus; mit dem Recht wird der Beleg ohne Rückfrage gespeichert.
+Tracelinks:    StRS-103, SwRS-130
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Mindestpreisschutz sichert die Marge unmittelbar ab.
+Status:        belegt
+Modul:         M-02
+
+ID:            SyRS-116
+Titel:         Aktionspreise nur innerhalb ihres Gültigkeitszeitraums anzeigen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (Preismatrix) / Einkäufer
+Vorbedingung:  Der Benutzer öffnet die Preismatrix (Preisspiegel) zu einer Belegposition oder einem Artikel.
+Fakt:          `PriceMatrixViewModel.GetPriceItemsFromArticleActionPrices(...)` ermittelt den Artikel zuerst über `ManufacturerCode`, hilfsweise über `EANCode`, lädt `IActionPriceLogic.GetActionPricesByArticleI3D(articleI3D)` und filtert `.Where(f => f.EffectiveFrom.StartOfDay() <= DateTime.Now && f.EffectiveUntil >= DateTime.Now)`. Die Quelle wird nur berücksichtigt, wenn `IncludePricesFromArticleActionPrices` aktiv ist. `ActionPriceBL.GetActionPricesByArticleI3D` selbst filtert nicht nach Datum.
+Aussage:       Das System soll Aktionspreise in der Preismatrix ausschließlich dann anzeigen, wenn das aktuelle Datum innerhalb von `GueltigAb` und `GueltigBis` liegt, und den Artikel dabei über Herstellercode mit Fallback auf EAN-Code auflösen.
+Ergebnis:      Abgelaufene oder noch nicht gültige Aktionspreise erscheinen nicht als Einkaufspreisquelle; die Datumsfilterung erfolgt clientseitig in der Preismatrix, nicht in der Datenschicht.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Finances/Receipts/PriceMatrix/PriceMatrixViewModel.cs, Zeilen 416-459, Methode `GetPriceItemsFromArticleActionPrices(PriceMatrixArticleInfo article, CancellationToken token)`; Filter `.Where(f => f.EffectiveFrom.StartOfDay() <= DateTime.Now && f.EffectiveUntil >= DateTime.Now) // Only valid action-prices` - Begründung: Einzige durchsetzende Stelle der Gültigkeitsprüfung.
+  - [PRIMÄR]   src/backend/Centron.BL/Warehousing/ActionPriceBL.cs, Zeilen 26-33, Methode `GetActionPricesByArticleI3D(int articleI3D)` mit `.Where(w => w.ArticleI3D == articleI3D)` ohne Datumsbedingung - Begründung: Belegt, dass die Backend-Schicht ungefiltert liefert und die Gültigkeitsregel allein in der UI liegt.
+Prüfidee:      Ein Aktionspreis mit `GueltigBis` in der Vergangenheit erscheint nicht in der Preismatrix, wird aber von `GetActionPricesByArticleI3D` weiterhin zurückgegeben.
+Tracelinks:    StRS-103, SwRS-131
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - Die Gültigkeitsregel liegt nur in der WPF-Preismatrix und ist damit für andere Aufrufer (REST, Nexus) nicht wirksam; sie gehört in die Business-Logik.
+Status:        belegt
+Modul:         M-02
+
+ID:            SyRS-117
+Titel:         Belegartbezogene Rechteprüfung und Sichtbereichseinschränkung in der Belegsuche
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System (ReceiptSearcher)
+Vorbedingung:  Ein c-entron-Benutzer führt eine Belegsuche aus.
+Fakt:          In `ReceiptSearcher.CreateSqlStatementAndParameters` wird für `user.IsCentronUserLogin` geprüft: `if (allowShowRight != null && this._appRightsBL.HasUserRight(user.User.I3D, allowShowRight.Value) == false) return null;`. Anschließend wird bei gesetztem `OnlyOwnRight` das `OnlyOwnWhereStatement` (für Rechnungen: `AND (AK.InnendienstID = :EmployeeI3D OR AK.AussendienstID = :EmployeeI3D OR AK.BearbeiterI3D = :EmployeeI3D)`) bzw. bei `OnlyOwnBranchRight` das `OnlyOwnBranchWhereStatement` (`AND (ISNULL(AK.FilialI3D, 0) = :BranchI3D)`) mit dem Parameter `user.User.Employee.BranchI3D` angehängt. Für Web-Konten setzt `PrepareFilterForWebAccounts` zwingend `filter.AccountI3D = user.WebAccount.CustomerI3D.Value` und wirft andernfalls eine `ResultException`.
+Aussage:       Das System soll in der Belegsuche je Belegart das Anzeigerecht prüfen und Treffer bei aktiver Einschränkung auf eigene Belege bzw. die eigene Filiale serverseitig im SQL-WHERE begrenzen; Web-Konten sollen ausschließlich Belege ihres eigenen Kunden erhalten.
+Ergebnis:      Belegarten ohne Anzeigerecht liefern keine Treffer (`return null` verhindert die Ausführung der Abfrage); Einschränkungen sind nicht durch Manipulation des übergebenen Filters umgehbar.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/ReceiptSearcher.cs, Zeilen 180-211; `int? allowShowRight = configuration.ShowRight; if (allowShowRight != null && this._appRightsBL.HasUserRight(user.User.I3D, allowShowRight.Value) == false) { return null; }` sowie die nachfolgenden `OnlyOwn`/`OnlyOwnBranch`-Zweige - Begründung: Durchsetzende Stelle der Rechteprüfung; `return null` unterdrückt die gesamte Abfrage dieser Belegart.
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/ReceiptSearcher.cs, Zeilen 81-95, Methode `PrepareFilterForWebAccounts`; `filter.AccountI3D = user.WebAccount.CustomerI3D.Value;` bzw. `throw new ResultException("Receipt-search is currently not supported for web-accounts without a customer");` - Begründung: Erzwingt die Kundenbindung für Web-Konten unabhängig vom übergebenen Filter.
+  - [SEKUNDÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/InvoiceReceiptSearchConfiguration.cs, Zeilen 152-158 (`ShowRight => UserRightsConst.Sales.Customer.CustomerCommon.Invoice.SHOW_INVOICES;`, `OnlyOwnBranchRight => ... SHOW_INVOICES_ONLY_OWN_BRANCH;`) - Begründung: Zeigt die konkrete Rechtezuordnung je Belegart.
+Prüfidee:      Ein Benutzer ohne `SHOW_INVOICES` erhält bei einer Suche ohne `ReceiptKinds`-Einschränkung keine Treffer mit `ObjectKind = 4`, während Angebote weiterhin geliefert werden.
+Tracelinks:    StRS-104, SwRS-134
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Serverseitige Sichtbereichsbegrenzung ist unverzichtbar.
+Status:        belegt
+Modul:         M-03
+
+ID:            SyRS-118
+Titel:         Wortweise Volltextsuche mit UND-Verknüpfung über Kopf, Positionen und Nummer
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (ReceiptSearcher) / Sachbearbeiter
+Vorbedingung:  Der Benutzer hat einen Suchtext mit einem oder mehreren Wörtern eingegeben.
+Fakt:          `ReceiptSearcher` zerlegt `filter.SearchText` mit `Split(new[] {' '}, StringSplitOptions.RemoveEmptyEntries)`. Je Wort werden bis zu drei WHERE-Teile gebildet (Nummernsuche bei `int.TryParse`, Positionstexte bei `filter.SearchInReceiptItemText`, Kopftexte) und mit `OR` verknüpft; die Wort-Blöcke werden anschließend mit `AND` verknüpft (`builder.AppendLine($"AND ({string.Join(" AND ", whereParts.Select(f => $"( {f} )"))})")`). Jedes Wort erhält einen eigenen benannten Parameter (`SearchText0`, `SearchText1`, ...), der als `NHibernateUtil.AnsiString` mit `%{word}%` gebunden wird.
+Aussage:       Das System soll einen mehrteiligen Suchtext so auswerten, dass jedes einzelne Wort in mindestens einem der Bereiche Belegnummer, Belegkopf oder Belegpositionen vorkommen muss, und alle Werte ausschließlich als benannte Parameter binden.
+Ergebnis:      Die Trefferliste enthält nur Belege, in denen alle Suchwörter vorkommen; SQL-Injection über den Suchtext ist ausgeschlossen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/ReceiptSearcher.cs, Zeilen 385-447; Schleife `foreach (var word in filter.SearchText.Split(...))`, `whereParts.Add(string.Join(" OR ", wordWhereParts.Select(f => $"( {f} )")));` und `builder.AppendLine($"AND ({string.Join(" AND ", ...)})");` - Begründung: Durchsetzende Stelle der UND/ODER-Semantik.
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/ReceiptSearcher.cs, Zeilen 420 und 432 (`parameters.Add(new NamedQueryParameter($"SearchTextItems{whereParts.Count}", $"%{word}%", NHibernateUtil.AnsiString));`) - Begründung: Belegt die durchgängige Parametrisierung statt String-Konkatenation der Benutzereingabe.
+  - [KONTEXT]  src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/ReceiptSearcher.cs, Zeilen 421-424 (Kommentar "Use AnsiString (varchar) instead of String (nvarchar) to avoid bad performance ... every single row would be converted to nvarchar") - Begründung: Erklärt die bewusste Typwahl aus Performancegründen.
+Prüfidee:      Die Suche "Müller 4711" liefert nur Belege, in denen sowohl "Müller" (Kopf oder Position) als auch die Zahl 4711 (Nummer, Kopf oder Position) vorkommt; ein Suchtext mit `'` erzeugt keinen SQL-Fehler.
+Tracelinks:    StRS-104, SwRS-133
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Die UND-Semantik über mehrere Wörter entspricht der Erwartungshaltung der Anwender.
+Status:        belegt
+Modul:         M-03
+
+ID:            SyRS-119
+Titel:         Antwortzeitverhalten der Belegsuche
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Performance-Effizienz
+Akteur:        System (ReceiptSearcher / ReceiptSearchWebServiceBL)
+Vorbedingung:  Eine Belegsuche über mehrere Belegarten wird ausgeführt.
+Fakt:          Jede Belegart-Abfrage wird über `_rawSqlAccessDAO.ExecuteQuery<ReceiptSearchItemDTO>(sqlStatement, parameters, timeout: TimeSpan.FromMinutes(5))` mit einem Timeout von fünf Minuten ausgeführt. Die Abfragen werden mit `SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;` eingeleitet und mit `SET TRANSACTION ISOLATION LEVEL READ COMMITTED;` abgeschlossen. Die Seitenbildung erfolgt erst nach dem Zusammenführen aller Belegarten in `ReceiptSearchWebServiceBL.SearchReceipts` per `receipts.OrderByDescending(o => o.Date).Skip((page - 1) * entriesPerPage).Take(entriesPerPage)`; `Count` und `PageCount` beziehen sich auf die vollständige Ergebnismenge.
+Aussage:       [HYPOTHESE] Das System soll eine Belegsuche über alle Belegarten innerhalb einer definierten Antwortzeit beantworten; im Bestand ist lediglich eine obere Abbruchgrenze von fünf Minuten je Belegart-Abfrage festgelegt, und die Seitenbildung erfolgt im Anwendungsspeicher statt in der Datenbank.
+Ergebnis:      Die Suche bricht spätestens nach fünf Minuten je Belegart ab; die vollständige Trefferliste wird stets vollständig in den Speicher geladen, bevor eine Seite ausgeliefert wird.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/ReceiptSearcher.cs, Zeile 70 (`var receipts = this._rawSqlAccessDAO.ExecuteQuery<ReceiptSearchItemDTO>(sqlStatement, parameters, timeout: TimeSpan.FromMinutes(5));`) - Begründung: Einziger im Code fixierter Zeitwert; belegt die Abbruchgrenze, nicht aber ein Antwortzeitziel.
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/ReceiptSearchWebServiceBL.cs, Zeilen 23-29 (`Count = receipts.Count, PageCount = (int)Math.Ceiling(receipts.Count/(decimal) entriesPerPage), Result = receipts.OrderByDescending(o => o.Date).Skip((page - 1) * entriesPerPage).Take(entriesPerPage).ToList()`) - Begründung: Belegt die anwendungsseitige Seitenbildung über der Gesamtmenge.
+  - [KONTEXT]  docs/reference/receipts/receipt-search-architecture.md, Abschnitt "Performance Considerations", Punkt 2 ("Sorting is applied after aggregation (may impact performance for large result sets); Consider implementing database-level pagination for very large datasets") - Begründung: Bestätigt, dass die Seitenbildung als bekannte Schwachstelle dokumentiert ist.
+Prüfidee:      Zur Bestätigung fehlt eine dokumentierte Zielantwortzeit (SLA) und eine Messreihe auf einem Referenzbestand; Akzeptanzkriterium wäre z. B. "Suche mit Datumsbereich 1 Monat über alle Belegarten liefert die erste Seite in < 3 s bei 1 Mio. Belegen".
+Tracelinks:    StRS-104, SwRS-134
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - Fünf-Minuten-Timeout und speicherseitige Seitenbildung sind Notlösungen; eine Neuentwicklung braucht datenbankseitiges Paging und ein explizites Antwortzeitziel.
+Status:        HYPOTHESE
+Modul:         M-03
+
+ID:            SyRS-120
+Titel:         Ermittlung des Zahlungsfälligkeitsdatums aus der Zahlungskondition
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (ReceiptBL)
+Vorbedingung:  Ein Beleg, der `IReceiptWithPayment` oder `IReceiptWithSupplierPayment` implementiert, wird gespeichert und trägt eine Zahlungskondition.
+Fakt:          `ReceiptBL.UpdatePaymentDueDate(IReceiptBase receipt)` bestimmt das Basisdatum: bei Kundenbelegen `receipt.Date`, bei Lieferantenbelegen bevorzugt `ExternalInvoiceDate`, sonst `receipt.Date`. Anschließend wird nach `paymentCondition.DueKind` gerechnet: `1` → Belegdatum, `2` → `receiptDate.AddDays(paymentCondition.DuePlusDays)`, `3` → `receiptDate.AddMonths(Math.Max(1, paymentCondition.DuePlusMonths)).SetDay(paymentCondition.DueAtDay)`, sonst `null`. Das Ergebnis wird in `PaymentDueDate` geschrieben.
+Aussage:       Das System soll das Zahlungsziel eines Belegs aus der Fälligkeitsart der Zahlungskondition berechnen und bei Lieferantenrechnungen das externe Rechnungsdatum als Bezugsdatum verwenden.
+Ergebnis:      Jeder gespeicherte zahlungsrelevante Beleg trägt ein aus der Kondition abgeleitetes `PaymentDueDate` oder `null`, wenn die Kondition keine Fälligkeit definiert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeilen 8189-8256, Methode `UpdatePaymentDueDate(IReceiptBase receipt)`; `switch (paymentCondition.DueKind) { case 1: return receiptDate; case 2: return receiptDate.AddDays(paymentCondition.DuePlusDays); case 3: int months = Math.Max(1, paymentCondition.DuePlusMonths); return receiptDate.AddMonths(months).SetDay(paymentCondition.DueAtDay); default: return null; }` - Begründung: Durchsetzende Stelle der Fälligkeitsberechnung im Belegkontext.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeilen 8211-8219 (`DateTime? invoiceDate = (receipt as IReceiptSupplierInvoice)?.ExternalInvoiceDate; if (invoiceDate.HasValue) { receiptDate = invoiceDate.Value; }`) - Begründung: Belegt die abweichende Bezugsdatumsregel für Lieferantenrechnungen.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Administration/ReceiptConditions/DueKind.cs (`public enum DueKind { Now = 1, PlusDays = 2, AtDay = 3 }`) - Begründung: Ordnet den numerischen Datenbankwerten die fachliche Bedeutung zu.
+Prüfidee:      Eine Rechnung vom 10.03. mit `DueKind = 2` und `DuePlusDays = 30` erhält `PaymentDueDate = 09.04.`; eine Lieferantenrechnung mit `ExternalInvoiceDate = 01.03.` und derselben Kondition erhält `31.03.`.
+Tracelinks:    StRS-105, SwRS-135
+Konsolidierung: Kandidat: `ReceiptBL.UpdatePaymentDueDate` und `AssetConditionBL.GetDueDate` implementieren dieselbe Fälligkeitsregel doppelt mit unterschiedlichem Basisdatum.
+Übernahmewürdigkeit: übernehmen - Fälligkeitsermittlung ist Voraussetzung für Mahnwesen und Zahlungsverkehr.
+Status:        belegt
+Modul:         M-04
+
+ID:            SyRS-121
+Titel:         Rückfrage bei Abweichung von der Standard-Zahlungskondition des Kunden
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (ReceiptBL) / Sachbearbeiter
+Vorbedingung:  Ein Beleg mit Zahlungskondition wird gespeichert; für den Kunden ist eine Standardkondition hinterlegt.
+Fakt:          `ReceiptBL.CheckDefaultPaymentConditionsDeviation(...)` ruft die belegartspezifische Prüfung `f.CheckDefaultPaymentConditionsDeviation(receipt)` auf. Bei `isDefaultPaymentConditionsDeviation == true` und noch nicht gesetztem `data.TakeDefaultPaymentCondition` wird `result.Set(f => f.ShowDefaultInvoicePaymentConditionsDeviationDialog, true, "Die Zahlungskondition weicht vom Standard ab. Möchten Sie mit der Auswahl fortfahren oder den Standard vom Kunden übernehmen?")` gesetzt. Entscheidet sich der Benutzer für die Standardkondition, wird `receiptWithPaymentCondition.PaymentConditionI3D` auf `defaultPaymentCondition.Value` überschrieben.
+Aussage:       Das System soll beim Speichern eine Abweichung der Belegzahlungskondition von der kundenseitig hinterlegten Standardkondition erkennen und dem Benutzer die Übernahme der Standardkondition anbieten.
+Ergebnis:      Abweichende Zahlungskonditionen werden bewusst gesetzt; bei Bestätigung wird die Kundenkondition in den Beleg übernommen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeilen 9331-9355, Methode `CheckDefaultPaymentConditionsDeviation(IReceiptBase receipt, SaveReceiptData data, SaveReceiptResultBuilder result)`; Bedingung `if (data.IgnoreCallbacks == false && checkDefaultPaymentConditionsDeviation.isDefaultPaymentConditionsDeviation == true && !data.TakeDefaultPaymentCondition.HasValue)` und die Zuweisung `receiptWithPaymentCondition.PaymentConditionI3D = checkDefaultPaymentConditionsDeviation.defaultPaymentCondition.Value;` - Begründung: Durchsetzende Stelle mit Nebenwirkung auf die Belegdaten.
+  - [KONTEXT]  src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeile 3718 (Aufrufkommentar "//Nebenwirkung: Zahlungskonditionen abweichend vom Standard (Kunde)") - Begründung: Zeigt die bewusste Einordnung als Check mit Datenänderung im Speicherablauf.
+Prüfidee:      Ein Beleg mit einer von der Kundenstandardkondition abweichenden Zahlungskondition löst beim ersten Speichern den Dialog aus; nach Antwort "Standard übernehmen" trägt der gespeicherte Beleg die Kundenkondition.
+Tracelinks:    StRS-105, SwRS-135
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Verhindert unbeabsichtigte Zahlungszielabweichungen.
+Status:        belegt
+Modul:         M-04
+
+ID:            SyRS-122
+Titel:         Rechteprüfung und automatische Einschränkung der Provisionsauswertung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System (ReceiptProvisionSchemaBL) / Provisionsempfänger
+Vorbedingung:  Ein Benutzer öffnet die Provisionsauswertung oder verwaltet ein Provisionsschema.
+Fakt:          `ReceiptProvisionSchemaBL.GetProvisionEvaluation(...)` wirft bei fehlendem `UserRightsConst.Sales.Provision.PROVISION_EVALUATION_MODULE` eine `ResultException` mit `DefaultMessageCodes.RightCheckFailed`. Besitzt der Benutzer `PROVISION_EVALUATION_ONLY_OWN`, wird `filter.OnlyOwn = true` erzwungen; besitzt er `PROVISION_EVALUATION_ONLY_OWN_BRANCH`, wird `filter.BranchI3Ds` auf die eigene Filiale überschrieben. `SaveProvisionSchema(...)` verlangt `PROVISION_SCHEMA_MANAGEMENT`. `GetReceiptsWithoutProvision(...)` verlangt ebenfalls `PROVISION_EVALUATION_MODULE`.
+Aussage:       Das System soll die Provisionsauswertung nur berechtigten Benutzern zugänglich machen und den Auswertungsumfang bei entsprechenden Einschränkungsrechten serverseitig auf eigene Provisionen bzw. die eigene Filiale reduzieren, unabhängig vom übergebenen Filter.
+Ergebnis:      Ein eingeschränkt berechtigter Benutzer kann keine fremden Provisionsdaten abrufen; die Verwaltung von Provisionsschemata bleibt Administratoren vorbehalten.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptProvisionSchemaBL.cs, Zeilen 491-500; `if (this._appRightsBL.HasUserRight(currentUser.UserI3D.Value, UserRightsConst.Sales.Provision.PROVISION_EVALUATION_MODULE) is false) throw new ResultException(..., DefaultMessageCodes.RightCheckFailed);` sowie die Überschreibungen `filter.OnlyOwn = true;` und `filter.BranchI3Ds = new List<int>() { currentUser.User.Employee.BranchI3D.GetValueOrDefault(0) };` - Begründung: Durchsetzende Stelle; der Filter wird nach der Rechteprüfung zwingend überschrieben.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptProvisionSchemaBL.cs, Zeilen 257-260 (`if (this._appRightsBL.HasUserRight(currentUser.UserI3D.Value, UserRightsConst.Sales.Provision.PROVISION_SCHEMA_MANAGEMENT) is false) throw new ResultException("Sie haben nicht das Recht um Provisionsschemas zu verwalten.", DefaultMessageCodes.RightCheckFailed);`) - Begründung: Schützt die Schemaverwaltung als abrechnungsrelevante Stammdaten.
+  - [SEKUNDÄR] src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs, Zeilen 2449 und 2452 (`PROVISION_SCHEMA_MANAGEMENT = 20800093;`, `PROVISION_EVALUATION_ONLY_OWN_BRANCH = 20800146;`) - Begründung: Verifiziert Existenz und Nummern der Rechte.
+Prüfidee:      Ein Benutzer mit `PROVISION_EVALUATION_ONLY_OWN` erhält auch bei explizit gesetztem `filter.OnlyOwn = false` ausschließlich eigene Provisionszeilen.
+Tracelinks:    StRS-106, SwRS-136
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Provisionsdaten sind personenbezogen und abrechnungsrelevant.
+Status:        belegt
+Modul:         M-05
+
+ID:            SyRS-123
+Titel:         Belegdatumsgerechter Umsatzsteuersatz über die Steuersatzkette
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (TaxBL)
+Vorbedingung:  Für eine Belegposition ist ein Steuersatz-I3D und das Belegdatum bekannt.
+Fakt:          `TaxBL.GetTaxRateForReceiptItem(int taxRateI3D, DateTime receiptDate, int? receiptItemArticleI3D)` läuft zunächst über `NextTaxRate` bis zum Ende der Kette und geht dann rückwärts, solange der Vorgänger ein gültiges `ExpirationDate` hat und `previousTaxRate.ExpirationDate.Date >= receiptDate.Date` gilt (Vergleich ausschließlich auf Datumsebene). Ist der übergebene Satz nicht auffindbar, wird über `GetDefaultTaxtRateByArticle(receiptItemArticleI3D)` ersetzt. `GetPreviousTaxRate` wirft eine `ResultException`, wenn mehrere Sätze denselben `NextTaxRate` referenzieren ("Es gibt mehrere Mehrwertsteuer-Sätze die als Folge-Mehrwertsteuer-Satz ... haben.").
+Aussage:       Das System soll für eine Belegposition denjenigen Steuersatz aus der über `NextTaxRate` verketteten Steuersatzfolge ermitteln, der am Belegdatum gültig war, und eine mehrdeutige Kette mit einer eindeutigen Fehlermeldung abweisen.
+Ergebnis:      Rückwirkend erfasste oder nachträglich versionierte Belege erhalten den zum Belegdatum gültigen Steuersatz; mehrdeutige Stammdatenketten werden erkannt statt still falsch aufgelöst.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Warehousing/TaxBL.cs, Zeilen 207-237, Methode `GetTaxRateForReceiptItem(...)`; Bedingung `if (hasPreviousTaxRate && previousTaxRateHasExpirationDate && previousTaxRateWasActiveForReceipt) currentTaxRate = previousTaxRate; else return currentTaxRate;` mit `previousTaxRate?.ExpirationDate?.Date >= receiptDate.Date` - Begründung: Durchsetzende Stelle der datumsabhängigen Auswahl.
+  - [PRIMÄR]   src/backend/Centron.BL/Warehousing/TaxBL.cs, Zeilen 286-319, Methode `GetPreviousTaxRate(ValueAddedTax currentTaxRate)`; `switch (taxRates.Count) { case 0: return null; case 1: return taxRates.First(); default: ... throw new ResultException(message.ToString(), DefaultMessageCodes.ErrorMessage); }` - Begründung: Erzwingt die Eindeutigkeit der Steuersatzkette.
+Prüfidee:      Ein Steuersatz 16 % mit `ExpirationDate = 31.12.2020` und `NextTaxRate` = 19 % liefert für ein Belegdatum 15.12.2020 den Satz 16 %, für 02.01.2021 den Satz 19 %.
+Tracelinks:    StRS-107, SwRS-137
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zeitraumgerechte Steuersätze sind gesetzlich gefordert (vgl. MwSt-Senkung 2020).
+Status:        belegt
+Modul:         M-06
+
+ID:            SyRS-124
+Titel:         Pflicht-Mehrwertsteuerzuordnung für jede Artikelposition
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (ReceiptBL)
+Vorbedingung:  Ein Beleg mit Artikel- oder Kundenrabattpositionen wird gespeichert.
+Fakt:          `ReceiptBL.CheckIfAllArticlePositionsHaveVatRate(...)` selektiert alle Positionen mit `Kind == ReceiptItemKind.Article || Kind == ReceiptItemKind.CustomerDiscount`, bei denen `VATI3D == null || VATI3D <= 0` gilt, und setzt bei mindestens einem Treffer `result.SetMessage($"Die Artikel {string.Join(", ", articlePositions.Select(f => f.ArticleCode).Distinct())} haben keine Mehrwertsteuer zugewiesen.")`. Die Prüfung wird im Speicherablauf vor `if (result.HasError) return result.GetResult();` ausgeführt.
+Aussage:       Das System soll das Speichern eines Belegs verweigern, solange mindestens eine Artikel- oder Kundenrabattposition keinen Mehrwertsteuersatz zugewiesen hat, und die betroffenen Artikelcodes in der Meldung nennen.
+Ergebnis:      Es entstehen keine Belege mit steuerlich unbestimmten Positionen; der Benutzer erhält die konkrete Fehlerliste.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeilen 9573-9585, Methode `CheckIfAllArticlePositionsHaveVatRate(IReceiptBase receipt, SaveReceiptData data, SaveReceiptResultBuilder result)`; Filter `.Where(f => f.VATI3D == null || f.VATI3D <= 0)` mit anschließendem `result.SetMessage(...)` - Begründung: Durchsetzende Stelle der Pflichtprüfung.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeilen 3740 und 3757-3758 (Aufruf `this.CheckIfAllArticlePositionsHaveVatRate(receipt, data, result);` gefolgt von `if (result.HasError) return result.GetResult();`) - Begründung: Belegt, dass der Speichervorgang bei Verletzung tatsächlich abgebrochen wird.
+Prüfidee:      Ein Beleg mit einer Artikelposition ohne `VATI3D` lässt sich nicht speichern; die Fehlermeldung enthält den Artikelcode dieser Position.
+Tracelinks:    StRS-107, SwRS-132
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Ohne Steuerzuordnung ist keine korrekte Fakturierung und Buchung möglich.
+Status:        belegt
+Modul:         M-06
+
+ID:            SyRS-125
+Titel:         Erkennung doppelt verwendeter externer Rechnungsnummern
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (ReceiptBL / SupplierInvoiceSpecificLogic)
+Vorbedingung:  Eine Lieferantenrechnung mit externer Rechnungsnummer wird gespeichert.
+Fakt:          `ReceiptBL.CheckExternalInvoiceNumberAlreadyUsed(...)` greift nur für Belege, die `IReceiptWithExternalInvoiceReference` implementieren und deren `SpecificLogic` `CheckExternalInvoiceNumberDuplicates()` mit `true` beantwortet (für Lieferantenrechnungen: `public bool CheckExternalInvoiceNumberDuplicates() => true;`). `SupplierInvoiceSpecificLogic.QueryForExternalInvoiceNumberDuplicates(...)` sucht in `SupplierCalculationCompact` nach `f.InvoiceNumber.Equals(foundReceipt.ExternalInvoiceNumber) && (receipt.I3D <= 0 || f.Number != receipt.Number)` und liefert bei Treffer ein `ExternalInvoiceNumberInUse`, was zu `result.Set(f => f.ShowExternalInvoiceNumberDuplicateDialog, true, ...)` führt.
+Aussage:       Das System soll beim Speichern einer Lieferantenrechnung prüfen, ob deren externe Rechnungsnummer bereits in einem anderen Beleg verwendet wird, und den Benutzer unter Nennung des Fundbelegs zur Bestätigung auffordern.
+Ergebnis:      Doppelt erfasste Eingangsrechnungen werden erkannt, bevor sie in die Buchhaltung gelangen; der Benutzer kann die Nummer bewusst erneut verwenden.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/SupplierInvoices/SupplierInvoiceSpecificLogic.cs, Zeilen 748-762; `public bool CheckExternalInvoiceNumberDuplicates() => true;` und die Abfrage `.Where(f => f.InvoiceNumber.Equals(foundReceipt.ExternalInvoiceNumber) && (receipt.I3D <= 0 || f.Number != receipt.Number))` - Begründung: Durchsetzende Stelle der Dublettenerkennung inklusive Selbstausschluss des eigenen Belegs.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeilen 4182-4210, Methode `CheckExternalInvoiceNumberAlreadyUsed(...)`; `result.Set(f => f.ShowExternalInvoiceNumberDuplicateDialog, true, $"Die Rechnungsnummer ({supplierInvoice.ExternalInvoiceNumber}) wurde bereits in einem anderen Beleg ({supplierInvoice.ReceiptKind.ToDescription()}{supplierInvoice.Number}) verwendet. Wollen Sie diese weiterhin verwenden?")` - Begründung: Belegt die Einbindung in den Speicherablauf und den Meldungsinhalt.
+Prüfidee:      Das Speichern einer zweiten Lieferantenrechnung mit derselben externen Rechnungsnummer löst den Dublettendialog aus und nennt die Belegnummer der ersten Rechnung.
+Tracelinks:    StRS-108, SwRS-138
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Schutz vor Doppelzahlungen an Lieferanten.
+Status:        belegt
+Modul:         M-07
+
+ID:            SyRS-126
+Titel:         Tokenbasierte Freigabe und Signatur von Belegdokumenten
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System (SharedDocumentBL) / Belegempfänger
+Vorbedingung:  Für einen Beleg wurde ein Freigabelink (`SharedDocument`) mit Token erzeugt.
+Fakt:          `SharedDocumentBL.GetSharedDocumentByToken(string token, string authenticationKey = "")` sucht den Datensatz über `string.Equals(f.Token, token) && string.Equals(f.AuthenticationKey, authenticationKey)` und lehnt anschließend in drei Stufen ab: nicht gefunden → "Kein Dokument zum Signieren gefunden."; `foundByToken.ExpiredDate.HasValue && foundByToken.ExpiredDate.Value < DateTime.Now` → "Die Signierungsanfrage ist bereits abgelaufen."; `foundByToken.IsSigned` → "Dokument wurde bereits signiert.". `SignSharedDocument(...)` ruft diese Prüfung als erstes auf, validiert danach die Bilddaten (`CheckIfByteArrayIsAnImage`) und setzt bei Erfolg `IsSigned = true`, `SignedDate = DateTime.Now`, `State = SharedDocumentState.SendToCustomerAccepted`. Die Entität `SharedDocument` speichert zusätzlich `SignedFromIp` und `ReceiverSignatureName`.
+Aussage:       Das System soll den Zugriff auf ein freigegebenes Belegdokument nur über die Kombination aus gültigem Token und passendem Authentifizierungsschlüssel zulassen, abgelaufene und bereits signierte Freigaben ablehnen und jede Signatur mit Zeitpunkt, Unterzeichnername und Absender-IP protokollieren.
+Ergebnis:      Ein Token kann genau einmal zur Signatur verwendet werden; nach Ablauf ist kein Dokumentzugriff mehr möglich.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/FileManagement/SharedDocumentBL.cs, Zeilen 382-412, Methode `GetSharedDocumentByToken(string token, string authenticationKey)`; die drei Ablehnungsbedingungen `foundByToken == null`, `foundByToken.ExpiredDate.Value < DateTime.Now`, `foundByToken.IsSigned` - Begründung: Durchsetzende Stelle der Zugriffsvalidierung.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/FileManagement/SharedDocumentBL.cs, Zeilen 504-506 und 560-564 (`var sharedDocumentByTokenResult = this.GetSharedDocumentByToken(sharedDocumentToken, authenticationKey); if (sharedDocumentByTokenResult.Status != ResultStatus.Success) return Result.FromResult(sharedDocumentByTokenResult);` sowie `sharedDocument.IsSigned = true; sharedDocument.SignedDate = DateTime.Now; sharedDocument.State = SharedDocumentState.SendToCustomerAccepted;`) - Begründung: Belegt Einmaligkeit der Signatur und den Statusübergang.
+  - [SEKUNDÄR] src/backend/Centron.Entities/Entities/Administration/FileManagement/SharedDocuments/SharedDocument.cs, Zeilen 11-31 (`Token`, `ExpiredDate`, `AuthenticationKey`, `IsSigned`, `SignedDate`, `SignedFromIp`, `ReceiverSignatureName`, `State`) - Begründung: Datenmodell belegt die protokollierten Signaturattribute.
+Prüfidee:      Ein zweiter Signaturversuch mit demselben Token liefert "Dokument wurde bereits signiert."; ein Token mit `ExpiredDate` in der Vergangenheit liefert "Die Signierungsanfrage ist bereits abgelaufen.".
+Tracelinks:    StRS-109, SwRS-139
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Rechtssichere Belegfreigabe und -signatur nach außen.
+Status:        belegt
+Modul:         M-08
+
+ID:            SyRS-127
+Titel:         Belegstatus als konfigurierbares Pflichtfeld
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (ReceiptBL) / Sachbearbeiter
+Vorbedingung:  Ein Beleg, der `IReceiptWithUserState` implementiert, wird gespeichert.
+Fakt:          `ReceiptBL.CheckIfReceiptUserStateIsNeeded(IReceiptBase receipt)` gibt Erfolg zurück, wenn der Beleg kein `IReceiptWithUserState` ist oder `ReceiptUserStateI3D` bereits gesetzt ist oder `_specificLogics.Execute(receipt, f => f.ReceiptUserStateIsRequired())` `false` liefert; andernfalls `Result.AsError("Der Belegstatus ist ein Pflichtfeld, und muss deswegen gefüllt sein.")`. Die aufrufende Überladung meldet den Fehler mit `SaveReceiptErrorMissingField.ReceiptUserState`. Die Entität `ReceiptUserState` besteht aus `Caption` und `IsActive`; der Status wird zusätzlich als `ReceiptUserState = R.Caption` in die Suchergebnisse übernommen.
+Aussage:       Das System soll je Belegart konfigurierbar erzwingen, dass ein anwenderdefinierter Belegstatus gesetzt ist, und den Speichervorgang andernfalls mit dem Fehlerfeld `ReceiptUserState` abweisen.
+Ergebnis:      Belegarten mit Statuspflicht können nicht ohne Status gespeichert werden; der Status ist in der Belegsuche filter- und anzeigbar.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeilen 10975-10989, Methode `CheckIfReceiptUserStateIsNeeded(IReceiptBase receipt)`; `if (this._specificLogics.Execute(receipt, f => f.ReceiptUserStateIsRequired()) is false) return Result.AsSuccess(); return Result.AsError("Der Belegstatus ist ein Pflichtfeld, und muss deswegen gefüllt sein.");` - Begründung: Durchsetzende Stelle der Pflichtfeldprüfung inkl. belegartabhängiger Konfiguration.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeilen 10959-10973 (Aufrufüberladung mit `result.SetMessage(checkResult.Message, SaveReceiptErrorMissingField.ReceiptUserState);`) - Begründung: Belegt die maschinenlesbare Feldkennzeichnung im Speicherergebnis.
+  - [SEKUNDÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/InvoiceReceiptSearchConfiguration.cs, Zeilen 77 und 107 (`ReceiptUserState = R.Caption,` und `LEFT OUTER JOIN ReceiptUserState R ON R.I3D = AK.ReceiptUserStateI3D`) - Begründung: Belegt die Auswertung des Status in der Belegsuche.
+Prüfidee:      Bei einer Belegart mit `ReceiptUserStateIsRequired() == true` schlägt das Speichern ohne `ReceiptUserStateI3D` mit `SaveReceiptErrorMissingField.ReceiptUserState` fehl.
+Tracelinks:    StRS-109, SwRS-140
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Anwenderdefinierte Belegstatus sind für Workflowsteuerung und Auswertung wichtig.
+Status:        belegt
+Modul:         M-08

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_work/A2_StRS.md

@@ -0,0 +1,209 @@
+ID:            StRS-201
+Titel:         Verträge als wiederkehrende Belege verwalten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertragssachbearbeiter (Innendienst)
+Vorbedingung:  Kunde ist angelegt; Benutzer hat das Recht SHOW_CONTRACTS/EDIT_CONTRACTS.
+Fakt:          Der Vertrag ist ein Beleg der Belegfamilie (`CentronObjectKindNumeric.ContractClass`); `ContractsAppModuleController.CreateModuleInstance` erzeugt die Vertragsverwaltung nur, wenn `parameters.Receipt.ReceiptKind == CentronObjectKindNumeric.ContractClass`. Die Vertragsverwaltung gliedert sich in die Bereiche `ContractTabKind` = Other/Position/ArticleReferences/Contingent/Controlling/MasterDataLists und die Assistentenseiten unter `ContractWizard/` (AddressInfo, Contingent, ContractArticleReferenzes, Controlling, Details, InvoiceHistory, MasterDataLists, Maintenance_Reaction, Position, Provision, Reductions, Tasks).
+Aussage:       Das System soll Verträge als eigene Belegart mit Kopf-, Positions-, Kontingent-, Stammblatt- und Controlling-Daten führen und je Vertrag Laufzeit, Abrechnungsintervall und Abrechnungsart als Grundlage der wiederkehrenden Fakturierung vorhalten.
+Ergebnis:      Ein Vertrag ist mit Kunde, Laufzeit, Positionen und Abrechnungsparametern gespeichert und steht der Vertragsabrechnung (M-13) zur Verfügung.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Finances/Contracts/ContractsAppModuleController.cs, `CreateModuleInstance` - Begründung: Die Bedingung `parameters.Receipt.ReceiptKind == CentronObjectKindNumeric.ContractClass` setzt durch, dass die Vertragsverwaltung ausschließlich für die Belegart Vertrag geöffnet wird.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[VertragKopf]` mit Spalten `AbrechnungIntervallArt`, `AbrechnungIntervallDauer`, `AutoAbrechnung`, `Beginn`, `Ende`, `KuendigungsDatum`, `RechnungNormieren` - Begründung: Die persistierten Spalten belegen, dass Laufzeit und Abrechnungssteuerung Kernattribute des Vertragskopfs sind.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/Contracts/ContractTabKind.cs (Enum-Werte Position, ArticleReferences, Contingent, Controlling, MasterDataLists) - Begründung: Der Enum bildet die fachliche Gliederung der Vertragsakte ab.
+Prüfidee:      Vertrag mit Intervall "monatlich/1", Laufzeit 01.01.–31.12. und zwei Positionen anlegen, speichern und erneut laden; alle Felder müssen unverändert aus `VertragKopf`/`VertragPos` zurückgelesen werden.
+Tracelinks:    SyRS-211, SyRS-212
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Vertragsstammdaten sind die Grundlage aller nachgelagerten Abrechnungsmodule.
+Status:        belegt
+Modul:         M-09
+
+ID:            StRS-202
+Titel:         Vertragsarten als wiederverwendbare Vertragsvorlage
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Administrator / Vertragsverantwortlicher
+Vorbedingung:  Benutzer besitzt das Recht `UserRightsConst.Masterdata.Contracts.CONTRACT_TYPES` (10492) und die Lizenz `LicenseGuids.ContractTypes` bzw. `LicenseGuids.Centron`.
+Fakt:          Die Tabelle `dbo.VertragsArt` hält Vorlagenwerte für Laufzeit (`LaufzeitArt`, `LaufzeitDauer`), Abrechnung (`AbrechnungIntervallArt`, `AbrechnungIntervallDauer`, `AutoAbrechnung`, `Berechnungsart`, `RechnungNormieren`, `Sammelrechnung`), Kündigungsfristen (`KuendigungsFristArt1/2`, `KuendigungsFristDauer1/2`), Reaktionszeiten (`ReaktionszeitArt1/2`), Reports (`AbrechnungsReportI3D`, `C2ReportI3D`, `WebReportI3D`) und Kontingentkennzeichen (`KontingentVertrag`). Das Modul wird über `ContractTypeAppModuleController` registriert.
+Aussage:       Das System soll Vertragsarten als zentrale Vorlage pflegen, aus der Laufzeit-, Abrechnungs-, Kündigungs-, Reaktionszeit- und Reporteinstellungen für neue Verträge vorbelegt werden.
+Ergebnis:      Beim Anlegen eines Vertrags einer bestimmten Vertragsart sind die vertragsartspezifischen Vorgaben vorbelegt und müssen nicht je Vertrag erneut erfasst werden.
+Belege:
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[VertragsArt]` (Spalten `LaufzeitArt`, `AbrechnungIntervallArt`, `KuendigungsFristDauer1`, `RechnungNormieren`, `Sammelrechnung`, `KontingentVertrag`, `AbrechnungsReportI3D`) - Begründung: Die Spaltenmenge belegt, dass die Vertragsart genau die Steuerparameter trägt, die sonst je Vertrag zu setzen wären.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung `ModuleRegistrationItem.For<ContractTypeAppModuleController>(() => Helper.HasRights(UserRightsConst.Masterdata.Contracts.CONTRACT_TYPES), () => LicenseManager.Instance.HasLicense(LicenseGuids.ContractTypes) || ...)` - Begründung: Recht und Lizenz sind die durchsetzende Stelle für den Zugang zur Vertragsartenverwaltung.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/Contracts/ContractSettings/ContractTypes/ContractTypeWizard/WizardSteps/ (BillingTermsView, DeadlinesView, TimesAndReactionsView, PricingView, InvoiceTemplateView, InvoiceMailTemplateView) - Begründung: Die Assistentenschritte spiegeln die fachlichen Vorlagenbereiche der Vertragsart wider.
+Prüfidee:      Vertragsart mit Intervall "quartalsweise/1" und Kündigungsfrist "3 Monate" anlegen; neuen Vertrag dieser Art anlegen und prüfen, dass Intervall und Frist vorbelegt sind.
+Tracelinks:    SyRS-213
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Vorlagensteuerung reduziert Fehleingaben in der Abrechnungssteuerung erheblich.
+Status:        belegt
+Modul:         M-10
+
+ID:            StRS-203
+Titel:         Wirtschaftliche Auswertung des Vertragsbestands
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Controller / Vertriebsleitung
+Vorbedingung:  Benutzer hat die Rechte `UserRightsConst.Sales.ID`, `UserRightsConst.Controlling.ID` und `UserRightsConst.RIGHT_CONTROLLINGAUSWERTUNG` sowie die Lizenz `LicenseGuids.ContractAnalysis`.
+Fakt:          `ContractEvaluation2ViewModel.StatisticsLoad` ruft `IContractEvaluationLogic.LoadContractEvaluation(filter)` auf; `ContractEvaluationBL.LoadContractEvaluation` aggregiert je Vertrag Umsatz (`SumComplete`), Serviceumsatz (`SumCompleteService`), Einkauf (`SumPurchase`, `SumPurchaseService`) und daraus Marge, jeweils zusätzlich als zeitraumanteiliges "Potential" über `SetPartForBookingInvoice`. Die Auswertung kann nach Vertragsart, Kunde und Filiale gruppiert werden (`DataKind`, `DataContract`, `DataCustomer`).
+Aussage:       Das System soll den Vertragsbestand für einen wählbaren Zeitraum nach Umsatz und Marge auswerten und die Ergebnisse nach Vertragsart, Vertrag und Kunde verdichtet bereitstellen.
+Ergebnis:      Der Controller erhält je Vertrag, Vertragsart und Kunde Umsatz-, Einkaufs- und Margenwerte sowie den auf den Auswertungszeitraum umgerechneten Anteilswert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Statistics/ContractStatistics/ContractEvaluationBL.cs, `LoadContractEvaluation` (Aggregation von `incomeRevenue`, `sumPurchase`, `potentialIncomeProfit` je `ContractI3D`) - Begründung: Hier wird die Auswertungslogik tatsächlich berechnet.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, `ModuleRegistrationItem.For<ContractEvaluation2AppModuleController>(() => Helper.HasRights(UserRightsConst.Sales.ID, UserRightsConst.Controlling.ID, UserRightsConst.RIGHT_CONTROLLINGAUSWERTUNG), ...)` - Begründung: Benennt die durchsetzende Stelle des Zugriffsschutzes auf die Auswertung.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/ContractEvaluation2/ContractEvaluation2AppModuleController.cs, `ModuleName => "Vertragsauswertung"`, `MainCategory => CentronModuleCategory.Controlling` - Begründung: Ordnet das Modul fachlich dem Controlling zu.
+Prüfidee:      Für einen Vertrag mit einer gebuchten Jahresrechnung 01.07.–30.06. den Auswertungszeitraum auf das Kalenderjahr setzen; der Potentialumsatz muss dem 6/12-Anteil des Rechnungsbetrags entsprechen.
+Tracelinks:    SyRS-214
+Konsolidierung: Kandidat: StRS-204 (Vertragsauswertung 2 vs. Altmodul)
+Übernahmewürdigkeit: übernehmen - aktuelle Auswertungssicht mit Filialfilter und Diagrammen.
+Status:        belegt
+Modul:         M-11
+
+ID:            StRS-204
+Titel:         Altmodul Vertragsauswertung als abgelöste Zweitimplementierung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Controller
+Vorbedingung:  Keine; das Modul ist im Client nicht mehr als eigenständiges Modul registriert.
+Fakt:          `ContractEvaluationOldAppModuleController` (`ModuleName => "Vertrags-Auswertung_old"`, `Description => "Vertrags-AuswertungLong"`) ist in `ModuleRegistration.cs` nicht als `ModuleRegistrationItem` eingetragen (Volltextsuche über `src/` findet nur die Selbstreferenz im eigenen Ordner). Gleichzeitig verwendet `ContractEvaluation2View.xaml` die Detailansichten des Altmoduls per DataTemplate weiter (`contractEvaluationOld:DetailsEvaluationView`, `BigDetailsEvaluationView`, `DetailsEvaluationText`, `DetailsPerContractEvaluation`). Beide ViewModels rufen dieselbe Backend-Methode `IContractEvaluationLogic.LoadContractEvaluation` auf; das Altmodul kennt jedoch keinen Filialfilter.
+Aussage:       [HYPOTHESE] Das System soll die Vertragsauswertung nur noch über das aktuelle Modul anbieten; das Altmodul soll ausschließlich als Lieferant der Detailansichten weiterexistieren und nicht mehr als eigenständige Auswertung aufrufbar sein.
+Ergebnis:      Anwender erreichen nur noch die Vertragsauswertung 2; die Detailfenster stammen weiterhin aus dem Altmodulcode.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Finances/ContractEvaluation2/ContractEvaluation2View.xaml, Zeilen 28-39 (`<DataTemplate DataType="{x:Type contractEvaluationOld:DetailsEvaluationViewModel}">` u. a.) - Begründung: Belegt die tatsächliche Weiterverwendung der Altmodul-Views durch das aktuelle Modul.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Finances/ContractEvaluationOld/ContractEvaluationOldViewModel.cs Zeile 106 und src/centron/Centron.WPF.UI/Modules/Finances/ContractEvaluation2/ContractEvaluation2ViewModel.cs Zeile 190 rufen beide `contractEvaluationLogic.LoadContractEvaluation(filter)` - Begründung: Zeigt, dass beide Module dasselbe fachliche Konzept auf derselben Datenquelle abbilden.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/ContractEvaluationOld/ContractEvaluationOldAppModuleController.cs, `ModuleName => "Vertrags-Auswertung_old"` - Begründung: Der Namenszusatz "_old" kennzeichnet den Ablösestatus.
+Prüfidee:      Modulliste des Clients auflisten und prüfen, dass kein Eintrag mit ID `{8DDB7EDA-ADC8-4A41-822F-2CBD7C3331B5}` erscheint; parallel prüfen, dass die Detailansicht in Vertragsauswertung 2 weiterhin funktioniert.
+Tracelinks:    SyRS-214
+Konsolidierung: Kandidat: StRS-203 (dieselbe fachliche Auswertung in zwei Implementierungen)
+Übernahmewürdigkeit: veraltet - eigenständiges Altmodul ohne Registrierung und ohne Filialfilter; nur die Detailansichten sind noch produktiv.
+Status:        HYPOTHESE
+Modul:         M-12
+
+ID:            StRS-205
+Titel:         Automatisierte Erstellung wiederkehrender Vertragsrechnungen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Abrechnungssachbearbeiter
+Vorbedingung:  Benutzer hat `UserRightsConst.Sales.ID` und `UserRightsConst.Sales.AUTOMATED_BILLING`; es existieren aktive Verträge mit `AutoAbrechnung`.
+Fakt:          Das Modul `AutomatedBillingAppModuleController` (`ModuleName => "Vertragsabrechnung"`, `MainCategory => CentronModuleCategory.Billing`) führt über einen Assistenten (Seiten `BillingDateWizardPage`, `CustomerSelectionWizardPage`, `ContractSelectionWizardPage`, `OverviewWizardPage`, `SendSettingsWizardPage`, `BillingResultWizardpage`, `BillingHistoryPage`). `AutomaticFacturaWebServiceBL.CreateInvoiceToContractComplete` erzeugt daraus über `ReceiptWebServiceBL.ForwardReceipt(CentronObjectKindNumeric.InvoiceClass, ... originReceipts: ReceiptKind = ContractClass ...)` die Rechnung und ordnet sie über `AutomaticFacturaBL.StoreInvoiceToContract` dem Vertrag zu.
+Aussage:       Das System soll aus fälligen Verträgen in einem geführten Ablauf Rechnungen erzeugen, versenden und die Abrechnungsperiode am Vertrag fortschreiben.
+Ergebnis:      Je Vertrag bzw. Sammelvorgang existiert eine Rechnung, ein Eintrag in `VertragRechKopfZuordnung` mit Berechnungszeitraum und ein Abrechnungsprotokolleintrag.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaWebServiceBL.cs, `CreateInvoiceToContractComplete` (Aufruf `receiptBL.ForwardReceipt(...)` mit `ReceiptToForward { ReceiptKind = CentronObjectKindNumeric.ContractClass, ReceiptI3D = billingParam.ContractID.Key, ReceiptItemI3Ds = billingParam.PosI3Ds }`) - Begründung: Hier wird die Rechnung tatsächlich aus den Vertragspositionen erzeugt.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, `StoreInvoiceToContract` (`Session.GetGenericDAO<VertragRechKopfZuordnung>().Save(vertragZuordnung)` mit `BerechnungszeitraumVon/Bis`) - Begründung: Persistiert die Zuordnung Rechnung↔Vertrag mit dem abgerechneten Zeitraum.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/AutomatedBilling/AutomatedBillingAppModuleController.cs, `ModuleName => "Vertragsabrechnung"`, `Description => "Abrechnung von Verträgen"` - Begründung: Benennt den fachlichen Zweck des Moduls.
+Prüfidee:      Vertrag mit monatlichem Intervall und `LetzteBezahlung` = Vormonatsende abrechnen; es müssen genau eine Rechnung und genau ein `VertragRechKopfZuordnung`-Satz mit dem Folgemonat als Berechnungszeitraum entstehen.
+Tracelinks:    SyRS-215, SyRS-216, SyRS-217, SyRS-218, SyRS-224
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernprozess des Moduls und Haupterlösquelle wiederkehrender Geschäfte.
+Status:        belegt
+Modul:         M-13
+
+ID:            StRS-206
+Titel:         Pauschalabrechnung von Dienstleistungen über Aufträge
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Serviceabrechner
+Vorbedingung:  Benutzer hat `UserRightsConst.Sales.ID`, `UserRightsConst.Sales.Customer.CustomerCommon.Order.ID` und `UserRightsConst.Sales.FLATRATE_BILLING_MODULE`; ein Ausgleichsartikel für Pauschalen ist in den Programmeinstellungen hinterlegt.
+Fakt:          Das Modul `FlatRateProjectAppModuleController` (`ModuleName => "Pauschalabrechnung"`, `Description => "Verwaltung und Erstellung von Pauschalabrechnungen"`) arbeitet auf einem Auftrag (`Order`); `OrderBalanceBL.AddHelpdeskTimerToOrderPosition` fügt Helpdeskzeiten in die Stückliste einer Pauschalposition ein und reduziert die Ausgleichsposition um den Wert der eingehängten Zeit (`balanceItem.Price -= partListItem.TotalPrice`). Pauschalpositionen werden über `IsOrderAssetItemABalanceItem` an `Article.MaterialGroup.BlanketMaterialGroup` erkannt.
+Aussage:       Das System soll erbrachte Helpdeskzeiten einer Pauschalposition eines Auftrags zuordnen und den verbleibenden Pauschalrestwert fortlaufend als Ausgleichsposition ausweisen.
+Ergebnis:      Der Auftrag zeigt je Pauschalposition die verbrauchten Zeiten und den verbleibenden Pauschalrest; der Rechnungsbetrag bleibt die Pauschale.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/Orders/OrderBalanceBL.cs, `AddHelpdeskTimerToOrderPosition` (`balanceItem.Price -= partListItem.TotalPrice`) - Begründung: Setzt die Verrechnung der Zeit gegen den Pauschalrestwert tatsächlich durch.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/Orders/OrderBalanceBL.cs, `IsOrderAssetItemABalanceItem` (`orderPosition.IsArticleItem && orderPosition.Article.MaterialGroup.BlanketMaterialGroup`) - Begründung: Definiert die Bedingung, welche Positionen überhaupt Pauschalpositionen sind.
+  - [SEKUNDÄR] src/backend/Centron.BL/Sales/CustomerAssets/Orders/OrderBalanceBL.cs, Meldungstext "In c-entron wurde kein Ausgleichsartikel für Pauschalen hinterlegt. ... \"Vertrieb->Kunden->Auftrag->Sonderartikel\"" - Begründung: Belegt die Konfigurationsabhängigkeit des Verfahrens.
+Prüfidee:      Pauschalposition über 1.000 EUR anlegen, Helpdeskzeit im Wert von 300 EUR einhängen; die Ausgleichsposition muss danach 700 EUR ausweisen, die Auftragssumme unverändert 1.000 EUR.
+Tracelinks:    SyRS-219
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - eigenständiges Abrechnungsmodell neben Vertrag und Zeitabrechnung.
+Status:        belegt
+Modul:         M-14
+
+ID:            StRS-207
+Titel:         Vereinfachte Abrechnung erfasster Ticketzeiten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Abrechnungssachbearbeiter
+Vorbedingung:  Benutzer hat `UserRightsConst.Sales.ID`, `SHOW_INVOICES` und `UserRightsConst.Sales.TIMER_BILLING_MODULE`; es existieren abrechenbare Helpdeskzeiten.
+Fakt:          Das Modul `TimerBillingAppModuleController` (`ModuleName => "Vereinfachte Ticketabrechnung"`, `Description => "Abrechnung von Tickets und einzelnen Zeiten."`) führt über die Assistentenseiten `TimerBillingSettingsPage`, `TimerBillingTimerSelectionPage`, `TimerBillingTimersWithOrderItemSettings`, `TimerBillingSummaryPage`, `TimerBillingCreateInvoicesPage`, `TimerBillingResultPage`. `TimerBillingBL.GetContracts` lädt zu den gewählten Kunden (inkl. Konzernverbund über `GetCorporations`) die zuordenbaren Verträge; `TimerBillingBL.SearchTimers` liefert die Zeiten, `SaveTimer` schreibt Korrekturen zurück.
+Aussage:       Das System soll erfasste Ticketzeiten kundenweise selektierbar machen, sie einem Vertrag oder Auftrag zuordnen und daraus Rechnungen bzw. Lieferscheine erzeugen.
+Ergebnis:      Für die ausgewählten Zeiten existiert ein Beleg; die Zeiten sind als abgerechnet gekennzeichnet.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs, `GetContracts` (NamedQuery `NamedQueryEnums.Asset.GetContractsForTimerBilling`, Anreicherung `contract.IsCorporationOfCustomerI3Ds`) - Begründung: Setzt die Vertragszuordnung inklusive Konzernverbund tatsächlich um.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, `ModuleRegistrationItem.For<TimerBillingAppModuleController>(() => Helper.HasRights(UserRightsConst.Sales.ID, UserRightsConst.Sales.Customer.CustomerCommon.Invoice.SHOW_INVOICES, UserRightsConst.Sales.TIMER_BILLING_MODULE), ...)` - Begründung: Benennt die durchsetzende Stelle der Zugriffsprüfung.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/TimerBilling/Converter/ContractToContingentOpenConverter.cs - Begründung: Zeigt, dass in der Zeitabrechnung das offene Vertragskontingent angezeigt wird und damit Vertragsbezug besteht.
+Prüfidee:      Zwei Ticketzeiten desselben Kunden auswählen, einem Kontingentvertrag zuordnen und Rechnung erzeugen; beide Zeiten dürfen danach in der Selektion nicht erneut als offen erscheinen.
+Tracelinks:    SyRS-220
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - abrechnungsseitige Verwertung erfasster Zeiten ist eigenständiger Geschäftsprozess.
+Status:        belegt
+Modul:         M-15
+
+ID:            StRS-208
+Titel:         Nutzungsabhängige Abrechnung über Geräte-Zählerstände (Click)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Zählerverwalter / Abrechnungssachbearbeiter
+Vorbedingung:  Benutzer hat `UserRightsConst.Sales.ID` und `UserRightsConst.RIGHT_ZAEHLEREINGABE`; Geräte sind über Stammblätter einem Vertrag zugeordnet.
+Fakt:          Das Modul `DeviceClickCounterAppModuleController` (`ModuleName => "Klick-Zählerverwaltung"`, `Description => "Verwaltung von Klick-Zählern"`, `MainCategory => CentronModuleCategory.Contract`) erfasst Zählerstände manuell oder per Import (`ImportKind` = ikExcel, ikCSV, ikRiverBird, docuForm, docuFormApi). `AutomaticFacturaBL.StoreCounterState` schreibt neue Stände nach `GeraeteClickZaehlerHistory` (`Abgerechnet = 0`) und aktualisiert `GeraeteClickZaehler.StandAktuell`. Die Abrechnung ermittelt in `AutomaticFacturaWebServiceBL.AddCounterItem` die Klickmenge aus `LastEntryValue - StartCalculateValue` abzüglich Freikopien.
+Aussage:       Das System soll Zählerstände je Gerät und Zählerart historisiert erfassen und daraus die nutzungsabhängige Menge für die Vertragsabrechnung ermitteln.
+Ergebnis:      Jeder erfasste Zählerstand liegt als Historieneintrag vor; die zugehörige Rechnungsposition weist die abgerechnete Klickmenge aus.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, `StoreCounterState` (Anlage `DeviceClickCounterHistory` mit `Balanced = 0`, `NewStateDate`, `OldState`, anschließendes `activeCounter.CurrentCounter = (int)item.NewValue`) - Begründung: Persistiert Historie und aktuellen Stand als durchgesetzte Regel.
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaWebServiceBL.cs, `AddCounterItem` (`cnt = counter.LastEntryValue - counter.StartCalculateValue; if (cnt < counter.FreeCount) cnt = 0; else cnt -= counter.FreeCount;`) - Begründung: Ist die durchsetzende Stelle der abgerechneten Klickmenge.
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[GeraeteClickZaehlerHistory]` (Spalten `AlterStand`, `NeuerStand`, `NeuerStandDatum`, `Abgerechnet`, `RechPosI3D`, `ImportID`) - Begründung: Die Spalten belegen die Historisierung samt Abrechnungsverknüpfung.
+Prüfidee:      Zähler mit Startwert 1.000 und Freikopien 500 auf 1.400 fortschreiben und abrechnen; die Rechnungsposition muss Menge 0 ausweisen, bei Stand 1.800 dagegen Menge 300.
+Tracelinks:    SyRS-221, SyRS-225
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - trägt die Druck-/Kopierabrechnung und ist unmittelbar erlösrelevant.
+Status:        belegt
+Modul:         M-16
+
+ID:            StRS-209
+Titel:         Kontingentverträge mit Verbrauchsverrechnung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertragssachbearbeiter / Abrechnungssachbearbeiter
+Vorbedingung:  Der Vertrag ist als Kontingentvertrag gekennzeichnet (`VertragKopf.KontingentVertrag = 1`).
+Fakt:          Die Sicht `dbo.ContractContingentInfo` liefert nur Verträge mit `VK.KontingentVertrag = 1` und stellt `Kind` (`KontingentArt`), `Value` (`KontingentWert`), `Overbooking` (`KontingentUeberbuchung`), `RestTake` (`RestMitnehmen`), `DifferContingentIntervalDuration` (`AbwKontingentIntervallDauer`) sowie `ContingentLimitKind`/`ContingentLimitValue`/`isContingentLimitBilling` bereit. Die Einstellungsmaske `ContigentSettingsController` ("Kontingente"/"Kontingente Einstellungen") pflegt globale Vorgaben inkl. Warengruppenzuordnung über `GroupToContingent` mit `ContractI3D = 0`.
+Aussage:       Das System soll je Kontingentvertrag ein periodisches Kontingent buchen, den Verbrauch dagegen verrechnen und dabei Überbuchung sowie Restwertmitnahme gemäß Vertragskonfiguration berücksichtigen.
+Ergebnis:      Zu jeder Vertragsrechnung existiert ein gebuchter Kontingentwert; der Restwert ist aus gebuchten und verbrauchten Werten jederzeit ermittelbar.
+Belege:
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `CREATE VIEW [dbo].[ContractContingentInfo]` (`where VK.KontingentVertrag = 1`) - Begründung: Datenbankseitige Durchsetzung, dass nur gekennzeichnete Verträge Kontingentlogik erhalten.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `CREATE FUNCTION [dbo].[cfn_RestValue](@contractID, @diadLine)` (`RETURN ROUND(ROUND(IsNull(@booked,0) - IsNull(@used,0), 2),2)`) - Begründung: Berechnet den Kontingentrestwert als gebucht minus verbraucht und ist damit die durchsetzende Stelle der Restwertermittlung.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/Contracts/Settings/Contigents/ContigentSettingsViewModel.cs, Variablen `@@VertragsNummer@@`, `@@KontigentGebuchtZum@@` sowie `SaveSelectedGroups` mit `secondaryItem.ContractI3D = 0` - Begründung: Belegt globale Kontingent-Grundeinstellungen und die Warengruppen-Zuordnung.
+Prüfidee:      Kontingentvertrag mit 10 Stunden/Monat und aktivierter Restmitnahme über zwei Monate abrechnen und in Monat 1 nur 6 Stunden verbrauchen; `cfn_RestValue` muss zu Beginn von Monat 3 einen Rest von 4 Stunden zzgl. Monat-2-Rest liefern.
+Tracelinks:    SyRS-222
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kontingente sind ein tragendes Preismodell der Serviceverträge.
+Status:        belegt
+Modul:         M-17
+
+ID:            StRS-210
+Titel:         MSP-Auswertung: Abgleich von Lieferantenlizenzen mit Vertragsbestand
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        MSP-Verantwortlicher / Controller
+Vorbedingung:  MSP-Collector-Importe (Lieferantenrechnungen/Lizenzmengen) liegen vor; Verträge sind mit den betroffenen Artikeln bestückt.
+Fakt:          Das Modul `MSPComparerAppModuleController` (`ModuleName => "MSP-Auswertung"`, `Description => "Auswertung des MSP-Collector Imports"`) stellt je Position in `ComparerViewModel` `ArticleAmount` (Lieferantenmenge) und `CentronArticleAmount` (Vertragsmenge) gegenüber und weist `Difference`, `PriceDifference` sowie `QuantityDifferenceLastInvoice` aus. Über `MspEvaluationDecision` (`IgnoreImport`, `ChangePriceAndQunatity`, `ChangePrice`, `ChangeQuantity`) wird je Zeile entschieden; `AutomaticFacturaBL.CreateSpecialArticleToContractFromMspEvaluation` erzeugt daraus eine Sonderartikelposition zum Vertrag.
+Aussage:       Das System soll importierte MSP-Lieferantenmengen und -preise je Kunde und Vertrag mit den vertraglich hinterlegten Mengen und Preisen abgleichen, Abweichungen ausweisen und deren Nachberechnung als Sonderartikel zum Vertrag ermöglichen.
+Ergebnis:      Abweichungen sind je Vertragsposition sichtbar; für die zur Nachberechnung entschiedenen Zeilen existiert ein `SpecialArticleToContractHead` mit Positionen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs, `CreateSpecialArticleToContractFromMspEvaluation` (`Guard.NotNull(compensationItemDto.MspItem.ContractI3D, ...)`, anschließend `CreateSpecialArticleToContract(headImportList, currentUser)`) - Begründung: Setzt durch, dass eine Kompensationsposition nur mit vorhandenem Vertragsbezug erzeugt wird.
+  - [PRIMÄR]   src/backend/Centron.Interfaces/Sales/BillingCenter/Contracts/MspEvaluationDecision.cs (`IgnoreImport = 0`, `ChangePriceAndQunatity = 1`, `ChangePrice = 2`, `ChangeQuantity = 3`) - Begründung: Definiert abschließend die zulässigen fachlichen Entscheidungen der Auswertung.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Global/MSPLicensesCompare/ComparerViewModel.cs, Eigenschaften `ArticleAmount`, `CentronArticleAmount`, `Difference`, `PriceDifferenceLastInvoice` - Begründung: Bilden die fachliche Vergleichssicht ab.
+Prüfidee:      MSP-Import mit 12 Lizenzen gegen einen Vertrag mit 10 Positionen laufen lassen; die Auswertung muss `Difference = 2` zeigen und bei Entscheidung "Stückzahl ändern" eine Sonderartikelposition über 2 Einheiten am Vertrag erzeugen.
+Tracelinks:    SyRS-223
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - schließt die Lücke zwischen Lieferantenabrechnung und Kundenvertrag bei Managed Services.
+Status:        belegt
+Modul:         M-18

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_work/A2_SyRS.md

@@ -0,0 +1,314 @@
+ID:            SyRS-211
+Titel:         Versionierte Vertragsakte mit lesbarem Vorversionszugriff
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertragsverwaltung (Modul Contracts)
+Vorbedingung:  Ein Vertrag ist gespeichert und mindestens eine Vorversion existiert.
+Fakt:          `ContractsManagementViewModel` führt eine Liste `Versions` und eine `SelectedVersion`; `IsPreviousVersion => this.SelectedVersion != this.Versions.MaxOrDefault(1)`. `LoadContractVersion` lädt bei Auswahl einer älteren Version über `_receiptLogic.GetReceiptVersionByI3DAsync(this.Receipt.ReceiptKind, this.Receipt.GetOriginalReceiptI3D(), this.SelectedVersion)`, ansonsten den aktuellen Beleg. Persistiert wird in `dbo.VertragKopfVersions` / `dbo.VertragPosVersions`.
+Aussage:       Das System soll je Vertrag alle Versionsstände vorhalten, den aktuellen Stand als einzigen bearbeitbaren Stand führen und ältere Versionen ausschließlich lesend anzeigen.
+Ergebnis:      Bei Auswahl einer Vorversion wird der historische Stand angezeigt und ist als schreibgeschützt gekennzeichnet; der aktuelle Stand bleibt unverändert.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Finances/Contracts/ContractsManagementViewModel.cs, `IsPreviousVersion => this.SelectedVersion != this.Versions.MaxOrDefault(1)` und `LoadContractVersion(bool ifIsReadOnlyRemoveMaxVersion = true)` - Begründung: Die Bedingung entscheidet konkret, ob der aktuelle oder ein historischer Stand geladen und schreibgeschützt dargestellt wird.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[VertragKopfVersions]` und `CREATE TABLE [dbo].[VertragPosVersions]` - Begründung: Die separaten Versionstabellen sind die persistente Durchsetzung der Historienführung.
+  - [KONTEXT]  docs/reference/receipts/contracts-backend.md, Abschnitt "Contract Version Creation Process" - Begründung: Beschreibt den INSERT-SELECT-Mechanismus mit `OriginalI3D`/`KopfVersionsI3D`.
+Prüfidee:      Vertrag speichern, neue Version erzeugen, Position ändern; anschließend die Vorversion auswählen — die geänderte Position muss im alten Wert erscheinen und nicht editierbar sein.
+Tracelinks:    StRS-201
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Nachvollziehbarkeit von Vertragsänderungen ist prüfungs- und streitfallrelevant.
+Status:        belegt
+Modul:         M-09
+
+ID:            SyRS-212
+Titel:         Automatisches Abschließen vollständig abgerechneter, abgelaufener Verträge
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Hintergrunddienst ContractCloseService
+Vorbedingung:  Einstellung `ApplicationSettingID.AutomaticallyCloseExpiredContracts` (ID 10335) ist aktiviert.
+Fakt:          `ContractCloseService` ist ein `ManagedBackgroundService` mit `GetExecutionInterval() => TimeSpan.FromDays(1)` und ruft `ContractWebServiceBL.CloseContract()` auf. `ContractBL.CloseContract` beendet sofort, wenn die Einstellung `false` ist, lädt sonst `ReceiptContract` mit `State == ReceiptState.Active && CalculationKind == ContractCalculationKind.Auto && (ContractTermination.HasValue || ContractEnd.HasValue)` und setzt `State = ReceiptState.Completed` nur, wenn `LastBookingTo >= ContractTermination` (bei `AutomatedProlongation`) bzw. `LastBookingTo >= ContractEnd` und das Referenzdatum jeweils nach diesem Datum liegt.
+Aussage:       Das System soll abgelaufene, automatisch abzurechnende Verträge täglich prüfen und nur dann abschließen, wenn sie bis zum Vertrags- bzw. Kündigungsende vollständig abgerechnet sind und dieses Datum überschritten ist.
+Ergebnis:      Vollständig abgerechnete abgelaufene Verträge erhalten den Status `Completed`; nicht vollständig abgerechnete Verträge bleiben aktiv.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs, `CloseContract` (Bedingung `contract.LastBookingTo >= contract.ContractEnd && referenceDate > contract.ContractEnd`) - Begründung: Genau diese Bedingung verhindert das Schließen noch nicht abgerechneter Verträge und damit Erlösverlust.
+  - [PRIMÄR]   src/webservice/Centron.Host/AspNetCore/HostedServices/ContractCloseService.cs, `GetExecutionInterval() => TimeSpan.FromDays(1)` und `session.GetBL<ContractWebServiceBL>().CloseContract()` - Begründung: Benennt Auslöser und Taktung der Regel.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/Contracts/Settings/General/GeneralContractSettingsViewModel.cs, Eigenschaft `AutomaticallyCloseExpiredContracts` - Begründung: Zeigt den fachlichen Konfigurationsschalter im Einstellungsdialog.
+Prüfidee:      Vertrag mit `Ende` = gestern und `LastBookingTo` = vorletzter Monat anlegen; nach Dienstlauf muss der Vertrag aktiv bleiben. Nach Nachabrechnung bis Vertragsende muss er beim nächsten Lauf auf `Completed` wechseln.
+Tracelinks:    StRS-201
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - verhindert Karteileichen im Vertragsbestand ohne Abrechnungsverlust.
+Status:        belegt
+Modul:         M-09
+
+ID:            SyRS-213
+Titel:         Vertragsart steuert Abrechnungs-, Kündigungs- und Reportvorgaben
+Ebene:         SyRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Vertragsverwaltung / Vertragsabrechnung
+Vorbedingung:  Vertragsart ist angelegt und dem Vertrag zugeordnet (`VertragKopf.VertragsArtI3D`).
+Fakt:          `dbo.VertragsArt` führt u. a. `AbrechnungIntervallArt`, `AbrechnungIntervallDauer`, `AutoAbrechnung`, `Berechnungsart`, `RechnungNormieren`, `Sammelrechnung`, `SNPflicht`, `Stammblattbezogen`, `KontingentVertrag`, `WithStaffelPrice`, `CalcNeedKind`, `KuendigungsFristArt1/2`, `KuendigungsFristDauer1/2`, `VerlaengerungDauer`, `VertragsEndeToDoVorlauf`, `VertragsRechToDoVorlauf`, `AbrechnungsReportI3D`, `C2ReportI3D`, `WebReportI3D`, `SendKind`, `CanChangeSendKind`, `HourlySurchargeRateI3D`, `CostCenterI3D`, `CostObjectI3D`, `CalculationPrio`.
+Aussage:       Das System soll die Vertragsart als Konfigurationsträger für Abrechnungsintervall, Berechnungsart, Kündigungs- und Verlängerungsfristen, Vorlauffristen für Aufgaben sowie Rechnungs- und Versandvorgaben führen.
+Ergebnis:      Änderungen an der Vertragsart wirken als Vorgabe für neue Verträge dieser Art; bestehende Verträge behalten ihre eigenen Werte.
+Belege:
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[VertragsArt]` (vollständige Spaltenliste inkl. `AbrechnungIntervallArt`, `KuendigungsFristDauer1`, `VertragsRechToDoVorlauf`, `AbrechnungsReportI3D`, `SendKind`) - Begründung: Der Datentyp ist die verbindliche Definition des Vorlagenumfangs.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/Contracts/ContractSettings/ContractTypes/ContractTypeWizard/WizardSteps/DeadlinesViewModel.cs und BillingTermsViewModel.cs - Begründung: Die Assistentenschritte "Fristen" und "Abrechnungsbedingungen" pflegen genau diese Spalten.
+  - [KONTEXT]  src/centron/Centron.WPF.UI/Modules/Finances/AutomatedBilling/AutomatedBillingViewModel.cs Zeile 523 (`CentronCache.Instance.CurrentUserAppRights.Any(f => f.I3D == UserRightsConst.Masterdata.Contracts.CONTRACT_TYPES)`) - Begründung: Zeigt, dass die Abrechnung den Sprung in die Vertragsartenpflege rechteabhängig anbietet.
+Prüfidee:      In einer Vertragsart `VertragsRechToDoVorlauf` auf 10 Tage setzen; bei der nächsten Abrechnung eines Vertrags dieser Art muss die erzeugte Aufgabe 10 Tage vor Periodenwechsel terminiert sein.
+Tracelinks:    StRS-202
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrale Konfigurationsebene mit direkter Abrechnungswirkung.
+Status:        belegt
+Modul:         M-10
+
+ID:            SyRS-214
+Titel:         Zeitraum- und Filialabgrenzung der Vertragsauswertung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertragsauswertung (Modul ContractEvaluation2)
+Vorbedingung:  Es existieren gebuchte Vertragsrechnungen in `VertragRechKopfZuordnung`.
+Fakt:          `ContractEvaluation2ViewModel.StatisticsLoad` normiert den Zeitraum auf Monatsgrenzen (`filter.DateFrom = new DateTime(DateFrom.Year, DateFrom.Month, 1)`, `filter.DateTo = new DateTime(DateTo.Year, DateTo.Month, 1).AddMonths(1)`) und setzt bei vorhandenen Filialen `filter.BranchI3Ds = new List<int>() { Branche.Key }`. Das Altmodul `ContractEvaluationOldViewModel` setzt nur `ContractKinds` und `CustomersI3D`, keinen Filialfilter.
+Aussage:       Das System soll den Auswertungszeitraum stets auf volle Kalendermonate abgrenzen und die Auswertung zusätzlich auf eine Filiale einschränkbar machen.
+Ergebnis:      Auswertungsergebnisse sind monatsscharf und, sofern Filialen existieren, filialbezogen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Finances/ContractEvaluation2/ContractEvaluation2ViewModel.cs, `StatisticsLoad` (Zeilen 184-187) - Begründung: Setzt Monatsnormierung und Filialfilter unmittelbar vor dem Backendaufruf durch.
+  - [PRIMÄR]   src/backend/Centron.BL/Statistics/ContractStatistics/ContractEvaluationBL.cs, `LoadContractEvaluation` verwendet `GetBookIncomeSQLOver(filter)` mit den Filterparametern - Begründung: Backendseitige Anwendung des Filters auf die Datenselektion.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/ContractEvaluationOld/ContractEvaluationOldViewModel.cs, Zeilen 95-102 (nur `ContractKinds`/`CustomersI3D`) - Begründung: Belegt den Funktionsunterschied zum Altmodul.
+Prüfidee:      Auswertung mit "Von 15.03." starten; die zurückgelieferten Buchungen müssen ab dem 01.03. berücksichtigt werden. Filiale wechseln und prüfen, dass Verträge fremder Filialen entfallen.
+Tracelinks:    StRS-203, StRS-204
+Konsolidierung: Kandidat: StRS-203/StRS-204 (identische Auswertungslogik in zwei Modulen)
+Übernahmewürdigkeit: übernehmen - Monatsnormierung ist Voraussetzung für die Anteilsberechnung in SwRS-229.
+Status:        belegt
+Modul:         M-11
+
+ID:            SyRS-215
+Titel:         Selektion abrechnungsfälliger Verträge nach Berechnungs- und Bedarfsart
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertragsabrechnung (AutomaticFacturaBL)
+Vorbedingung:  Der Anwender hat Abrechnungsstichtag, Kunden-, Vertragsart-, Filial- und Intervallfilter gesetzt.
+Fakt:          `AutomaticFacturaBL.GetActiveContracts` selektiert nur `f.State == 1` und für die Buchung nur Verträge mit `(filter.CalculationKind & f.CalculationKind) == ContractCalculationKind.Auto && (f.AutomatedProlongation || f.LastPaidDate == null || f.LastPaidDate < f.ContractEnd) && (LastPaidDate < filter.DateTo || FirstPaidDate < filter.DateTo.AddDays(1))` bzw. Verträge mit `CalculationKind > Auto` (Bedarf/Manuell). `SearchBillingContracts` entfernt anschließend dynamische Bedarfsverträge ohne Sonderartikel (`contracts.RemoveAll(f => f.CalculationKind == ContractCalculationKind.Need && f.CalcNeedKind == ContractNeedCalcKind.Dynamic && !f.WithSpecialArticle)`) sowie Verträge, die zu einer leeren Rechnung führen würden (NamedQuery `GetNoEmptyContracts` in Kombination mit `ContractArticleReferenzes`). `InvoicePeriodCalculate` entfernt Klick- und Schwellenkontingentverträge ohne abrechenbaren Bestand.
+Aussage:       Das System soll zur Abrechnung nur aktive Verträge vorschlagen, deren Berechnungsart der Auswahl entspricht, deren Abrechnungsperiode offen ist und die zu einer nicht leeren Rechnung führen.
+Ergebnis:      Die Abrechnungsliste enthält keine leeren Rechnungen, keine bereits vollständig abgerechneten und keine nicht selektierten Bedarfsarten.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, `GetActiveContracts` (LINQ-Prädikat ab `f => f.State == 1 && ...`) - Begründung: Die Where-Bedingung ist die durchsetzende Stelle der Fälligkeitsselektion.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, `SearchBillingContracts`, Kommentar `// leere RE vermeiden` mit `contracts.RemoveAll(f => !f.WithSpecialArticle && !contractsI3D...Contains(f.I3D) && !contractReferenzes...Contains(f.I3D))` - Begründung: Verhindert die Erzeugung leerer Rechnungen.
+  - [SEKUNDÄR] src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, `InvoicePeriodCalculate`, Kommentare `// nur click-abrechnung` und `// nur schwellekontingent-abrechnung` - Begründung: Dokumentieren die Ausschlussregeln je Bedarfsart.
+Prüfidee:      Vertrag ohne Positionen, ohne Sonderartikel und ohne `ContractArticleReferenzes` anlegen und Abrechnung starten; der Vertrag darf in der Auswahl nicht erscheinen.
+Tracelinks:    StRS-205
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - verhindert Fehlrechnungen an Kunden.
+Status:        belegt
+Modul:         M-13
+
+ID:            SyRS-216
+Titel:         Optimistische Sperre gegen zwischenzeitlich veränderte Vertragsdaten
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertragsabrechnung (AutomaticFacturaWebServiceBL)
+Vorbedingung:  Die Abrechnungsliste wurde geladen; `ContractToInvoiceParam.LastInvoiceID` enthält die zuletzt bekannte Rechnungs-ID je Vertrag.
+Fakt:          In `CreateInvoiceToContractComplete` wird unmittelbar vor dem Speichern je Vertrag geprüft: `if (param.LastInvoiceID != automaticFacturaBLsave.GetLastInvoiceID(param.ContractID.Key)) throw new Exception("Seit dem letzten Laden wurden die Vertragsdaten von Vertrag " + param.ContractID.Value + " geändert.");`. Der umgebende `catch` löst `saveSession.DAOSession.RollbackTransaction()` aus.
+Aussage:       Das System soll die Erstellung einer Vertragsrechnung abbrechen und die Transaktion zurückrollen, wenn seit dem Laden der Abrechnungsliste für denselben Vertrag bereits eine weitere Rechnung erzeugt wurde.
+Ergebnis:      Es entsteht keine Doppelabrechnung; der Anwender erhält eine Meldung mit der betroffenen Vertragsnummer.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaWebServiceBL.cs, `CreateInvoiceToContractComplete`, Vergleich `param.LastInvoiceID != automaticFacturaBLsave.GetLastInvoiceID(param.ContractID.Key)` vor `StoreInvoiceToContract` - Begründung: Exakte durchsetzende Prüfung gegen Doppelfakturierung.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, `GetLastInvoiceID` (NamedQuery `NamedQueryEnums.Asset.GetLastInvoiceID`) - Begründung: Liefert den zum Vergleich herangezogenen Ist-Zustand aus der Datenbank.
+  - [SEKUNDÄR] Meldungstext "Seit dem letzten Laden wurden die Vertragsdaten von Vertrag {Nr} geändert." - Begründung: Fachliche Fehlermeldung an den Anwender.
+Prüfidee:      Denselben Vertrag in zwei Sitzungen zur Abrechnung laden, in Sitzung A abrechnen, danach in Sitzung B abrechnen; Sitzung B muss mit der genannten Meldung abbrechen und keine Rechnung erzeugen.
+Tracelinks:    StRS-205
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - unmittelbarer Schutz gegen doppelte Kundenrechnungen.
+Status:        belegt
+Modul:         M-13
+
+ID:            SyRS-217
+Titel:         Rechnungsvorschau ohne persistente Wirkung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Abrechnungssachbearbeiter
+Vorbedingung:  Ein Vertrag ist in der Abrechnungsliste ausgewählt; die Vorschau wird angefordert (`isPreview = true`).
+Fakt:          In `CreateInvoiceToContractComplete` wird im Zweig `if (isPreview)` der Report über `HandleSendType(..., isPreview: true, ...)` erzeugt und anschließend `saveSession.DAOSession.RollbackTransaction()` ausgeführt (sofern kein Objektreport), bevor `return result` mit `result.InvoicePreview = invoice` erfolgt. Die Blöcke `StoreInvoiceToContract` und `CommitTransaction` liegen hinter diesem Return und werden im Vorschaumodus nicht erreicht. Zusätzlich wird `ReceiptBL.CreateFullReportForReceipt(..., ignoreReportGroupExport: isPreview)` aufgerufen und der Reportparameter `previewParameter.Value = isPreview.ToOneZeroInteger().ToString()` gesetzt.
+Aussage:       Das System soll im Vorschaumodus eine vollständig berechnete Rechnung samt Report anzeigen, dabei aber keine Rechnung, keine Vertrags-Rechnungszuordnung und keinen Reportexport persistieren.
+Ergebnis:      Nach einer Vorschau sind in `Rechnungen`, `VertragRechKopfZuordnung` und im Reportexport keine neuen Datensätze vorhanden.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaWebServiceBL.cs, Zeilen 2136-2167 (`if (isPreview) { ... saveSession.DAOSession.RollbackTransaction(); ... return result; }`) - Begründung: Rollback und vorzeitiges Return sind die durchsetzende Stelle der Nichtpersistenz.
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaWebServiceBL.cs, `CreateFullReportForReceipt(..., ignoreReportGroupExport: isPreview)` - Begründung: Verhindert den Reportexport in der Vorschau.
+  - [SEKUNDÄR] `previewParameter.Value = isPreview.ToOneZeroInteger().ToString()` - Begründung: Der Report erhält ein Vorschaukennzeichen zur optischen Kennzeichnung.
+Prüfidee:      Rechnungsnummernkreis und Zeilenzahl von `VertragRechKopfZuordnung` vor und nach einer Vorschau vergleichen; beide müssen identisch sein.
+Tracelinks:    StRS-205
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Vorschau ist Voraussetzung für die Freigabekontrolle vor Massenabrechnungen.
+Status:        belegt
+Modul:         M-13
+
+ID:            SyRS-218
+Titel:         Abbruch der Rechnungserstellung bei nicht erreichbarem RMM-Dienst
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Vertragsabrechnung / externer RMM-Dienst (Riverbird)
+Vorbedingung:  Der Vertrag ist RMM-fähig (`WhetherRMM(contractI3D) == true`) und es sind `ContractArticleReferenzes` hinterlegt.
+Fakt:          `AutomaticFacturaWebServiceBL.CheckRMMArticle` bricht ohne Wirkung ab, wenn `!_automaticFacturaBL.WhetherRMM(...)` oder `rmmArticleReferences.Count == 0`. Sonst ruft `GetAggregatedRMMStatistics` je Abrechnungsintervall `new RiverConnectionBL(this.Session).GetContractBillingAmounts(interval.From, interval.To.AddDays(1), customerI3D, rmmArticleReferences)` auf und wirft bei `riverbirdStatisticsResult.Status is ResultStatus.Error` und vorhandenen Referenzen bzw. gefundenem `@@RMMArtikel@@`-Tag eine `RMMServiceUnavailableException` mit der Meldung "Die Rechnung kann nicht erstellt werden. {Message}". Der Platzhalter `@@RMMArtikel@@` bestimmt die Einfügeposition; ohne Platzhalter wird an Position `invoice.Items.Count - 2` eingefügt.
+Aussage:       Das System soll bei RMM-pflichtigen Verträgen die Rechnungserstellung abbrechen, wenn die Nutzungsdaten des externen RMM-Dienstes für den Abrechnungszeitraum nicht abrufbar sind.
+Ergebnis:      Es wird keine Rechnung mit unvollständigen Nutzungsmengen erzeugt; der Fehler wird protokolliert und dem Anwender gemeldet.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaWebServiceBL.cs, `GetAggregatedRMMStatistics` (`if (riverbirdStatisticsResult.Status is ResultStatus.Error) { if (hasRmmTag || rmmArticleReferences.Count != 0) { ... throw new RMMServiceUnavailableException(errorMsg); } continue; }`) - Begründung: Exakte Bedingung und Ausnahme, die den Abrechnungslauf für diesen Vertrag stoppt.
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaWebServiceBL.cs, `CheckRMMArticle`, Erkennung `f.RichText.IndexOf("@@RMMArtikel@@", StringComparison.InvariantCulture) > -1` - Begründung: Definiert die Schnittstelle zwischen Rechnungsvorlage und RMM-Positionen.
+  - [KONTEXT]  docs/reference/receipts/Contract-Billing-RMM-Article-Logic.md, Abschnitt "External Service Unavailability" - Begründung: Bestätigt die Absicht, unvollständige Abrechnungen zu verhindern.
+Prüfidee:      RMM-Dienstadresse auf einen nicht erreichbaren Host setzen und einen RMM-Vertrag abrechnen; es darf keine Rechnung entstehen und die Fehlermeldung muss den RMM-Bezug nennen.
+Tracelinks:    StRS-205
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - schützt vor fehlerhafter Kundenabrechnung bei Fremdsystemausfall.
+Status:        belegt
+Modul:         M-13
+
+ID:            SyRS-219
+Titel:         Sperre gegen Mehrfachverwertung bereits verarbeiteter Zeiten in Pauschalen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Pauschalabrechnung (OrderBalanceBL)
+Vorbedingung:  Ein Auftrag mit Pauschalposition ist geöffnet und eine Helpdeskzeit ist ausgewählt.
+Fakt:          `OrderBalanceBL.DoValidateCurrentSelectionForAddingHelpdeskTimeToPosition` weist die Zuordnung zurück, wenn die Zielposition keine Pauschalposition ist ("Es können nur zu Pauschalpositionen Helpdeskzeiten hinzugefügt werden."), wenn `timer.IsAssignedToOrder` ("Die Zeit wurde bereits einer Auftragsposition hinzugefügt."), `timer.IsAssignedToDeliveryList` ("Diese Zeit wurde bereits zu einem Lieferschein weiterverarbeitet."), `timer.IsAssignedToInvoice` ("Diese Zeit wurde bereits zu einer Rechnung weiterverarbeitet.") oder `timer.IsPlanned` ("Geplante Zeiten können nicht zu einer Pauschale hinzugefügt werden.") zutrifft. `AddHelpdeskTimerToOrderPosition` bricht bei nicht leerem Rückgabetext vor jeder Änderung ab.
+Aussage:       Das System soll verhindern, dass eine Helpdeskzeit, die bereits einem Auftrag, Lieferschein oder einer Rechnung zugeordnet ist oder nur geplant ist, zusätzlich einer Pauschalposition zugeordnet wird.
+Ergebnis:      Die Zuordnung wird mit einer eindeutigen Meldung abgelehnt; Auftrag und Ausgleichsposition bleiben unverändert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/Orders/OrderBalanceBL.cs, `DoValidateCurrentSelectionForAddingHelpdeskTimeToPosition` (fünf Ablehnungsbedingungen) - Begründung: Diese Methode ist die durchsetzende Stelle gegen Mehrfachverwertung.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/Orders/OrderBalanceBL.cs, `AddHelpdeskTimerToOrderPosition` (`string output = DoValidateCurrentSelectionForAddingHelpdeskTimeToPosition(...); if (!String.IsNullOrWhiteSpace(output)) return output;`) - Begründung: Der Abbruch erfolgt vor jeder Zustandsänderung.
+  - [SEKUNDÄR] src/backend/Centron.BL/Sales/CustomerAssets/Orders/OrderBalanceBL.cs, Meldung "Der Helpdeskzeit wurde kein Artikel hinterlegt." - Begründung: Weitere fachliche Vollständigkeitsprüfung vor der Verrechnung.
+Prüfidee:      Eine bereits fakturierte Helpdeskzeit erneut an eine Pauschalposition hängen; das System muss ablehnen und die Ausgleichsposition darf sich nicht ändern.
+Tracelinks:    StRS-206
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - verhindert doppelte Erlöserfassung derselben Leistung.
+Status:        belegt
+Modul:         M-14
+
+ID:            SyRS-220
+Titel:         Rechteprüfung beim Ändern fremder Ticketzeiten in der Zeitabrechnung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Zeitabrechnung (TimerBillingBL)
+Vorbedingung:  Ein bestehender Timer (`I3D > 0`) soll aus der Zeitabrechnung heraus geändert werden.
+Fakt:          `TimerBillingBL.SaveTimer` ruft bei erkannter Änderung (`TimerHasChanged`) vor jeder Zuweisung `new HelpdeskTimerWebServiceBL(this.Session).ThrowIfUserDoesntHaveRightToChangeHelpdeskTimers(...)`. Diese Methode wirft `ResultException("Web-Account Zugriff nicht erlaubt.")` bei `loggedInUser.IsWebAccountLogin || !loggedInUser.UserI3D.HasValue`, `ResultException("Nutzer hat keine Rechte um Zeiten zu bearbeiten", DefaultMessageCodes.RightCheckFailed)` ohne `UserRightsConst.Sales.Customer.Helpdesk.EDIT_TIME` und `ResultException("Nutzer hat keine Rechte um Zeiten anderer Mitarbeiter zu bearbeiten")`, wenn `OWN_TIME_EDIT` gesetzt ist und der Timer von einem anderen Mitarbeiter stammt. Bei Timer-Split wird bewusst der Ursprungstimer geprüft (`timer.IsCloneOfTimerI3D > 0 ? timer.IsCloneOfTimerI3D : timer.I3D`).
+Aussage:       Das System soll das Ändern einer Ticketzeit aus der Zeitabrechnung nur zulassen, wenn der Benutzer das Recht zur Zeitbearbeitung besitzt und – bei Beschränkung auf eigene Zeiten – Erfasser der Zeit ist; Web-Account-Anmeldungen sollen abgelehnt werden.
+Ergebnis:      Unberechtigte Änderungen werden mit `DefaultMessageCodes.RightCheckFailed` abgewiesen; der Timer bleibt unverändert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/Support/HelpdeskTimerWebServiceBL.cs, `ThrowIfUserDoesntHaveRightToChangeHelpdeskTimers` (Prüfungen auf `EDIT_TIME` und `OWN_TIME_EDIT` mit `appRightsBl.HasUserRight(...)`) - Begründung: Nennt Datei, Methode und die konkreten Rechteprüfungen als durchsetzende Stelle.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs, `SaveTimer` Zeilen 473-481 (Aufruf der Prüfung vor allen Feldzuweisungen) - Begründung: Belegt, dass die Prüfung im Abrechnungsmodul tatsächlich vor der Änderung greift.
+  - [SEKUNDÄR] src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs, `ResultException("Die Zeit kann nicht gespeichert werden. Das Enddatum ist vor dem Startdatum (negative Dauer).")` - Begründung: Ergänzende fachliche Plausibilitätsprüfung derselben Speicheroperation.
+Prüfidee:      Benutzer mit `EDIT_TIME` und `OWN_TIME_EDIT` versucht, die Zeit eines anderen Mitarbeiters in der Zeitabrechnung zu ändern; der Aufruf muss mit `RightCheckFailed` scheitern und der Datenbankstand unverändert bleiben.
+Tracelinks:    StRS-207
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - schützt Leistungsnachweise vor unbefugter Manipulation.
+Status:        belegt
+Modul:         M-15
+
+ID:            SyRS-221
+Titel:         Klassifizierter Zählerimport mit stornierbaren Importläufen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Klick-Zählerverwaltung
+Vorbedingung:  Eine Importdatei bzw. ein API-Abruf (docuFORM, Riverbird, Excel, CSV) liegt vor.
+Fakt:          `ImportState` klassifiziert jede Importzeile in `Ok` ("übernommen"), `Complete` ("komplett vorbereitet"), `NoContract` ("Vertrag ist nicht zugeordnet"), `NoDevice` ("Seriennummer keinem Stammblatt zugeordnet"), `NoBarcode` ("Seriennummer ist nicht vorhanden"), `NoReference` ("kein c-enton Zähler"), `NoArticle` ("Artikel ist nicht vorhanden"), `NoCounter` ("kein Zähler im Stammblatt"), `DoubleCounter` ("mehrere gleiche Zähler im Stammblatt"), `Error`. `StoreCounterState` vergibt je Speichervorgang eine gemeinsame `ImportID` (I3D des ersten Historiensatzes). `DeactivateCounterImport` setzt für alle Sätze eines Importlaufs `Abgerechnet = 2` mit Begründungsvermerk, storniert nachfolgende manuelle Einträge desselben Zählers und setzt `GeraeteClickZaehler.StandAktuell` auf den höchsten verbleibenden Stand zurück. `GetCounterImports` bietet nur Importe der letzten 350 Tage mit `Abgerechnet = 0` an.
+Aussage:       Das System soll jede Zählerimportzeile mit einem eindeutigen Verarbeitungsstatus kennzeichnen, alle Zeilen eines Laufs unter einer gemeinsamen Import-ID zusammenfassen und einen noch nicht abgerechneten Importlauf vollständig zurücknehmbar machen.
+Ergebnis:      Fehlerhafte Importe sind je Zeile begründet; ein stornierter Lauf hinterlässt keine abrechnungswirksamen Zählerstände und der aktuelle Zählerstand ist zurückgesetzt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, `DeactivateCounterImport` (drei SQL-Statements: `Update GeraeteClickZaehlerHistory set Abgerechnet = 2 ... where ImportID = @ImportID and Abgerechnet = 0`, Nachlauf-Update für spätere manuelle Einträge, `Update gz set StandAktuell = c.maxStand`) - Begründung: Setzt die vollständige Rücknahme eines Importlaufs durch.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, `StoreCounterState` (Vergabe `importID = newState.I3D` und Zuweisung an alle Folgezeilen) - Begründung: Erzeugt die gemeinsame Klammer eines Importlaufs.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/DeviceClickCounter/ImportState.cs und ImportKind.cs - Begründung: Definieren die fachlichen Statuswerte und die unterstützten Importquellen.
+Prüfidee:      Excel-Import mit einer Zeile ohne Vertragszuordnung ausführen; die Zeile muss `NoContract` erhalten. Danach den Importlauf stornieren und prüfen, dass alle Historiensätze `Abgerechnet = 2` tragen und `StandAktuell` dem Vorwert entspricht.
+Tracelinks:    StRS-208
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Importfehler sind bei Massenzählern der Regelfall und müssen korrigierbar bleiben.
+Status:        belegt
+Modul:         M-16
+
+ID:            SyRS-222
+Titel:         Buchung des Vertragskontingents je erzeugter Rechnung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertragsabrechnung (AutomaticFacturaBL)
+Vorbedingung:  `ContractToInvoiceParam.IsContingent == true`; der Vertrag ist Kontingentvertrag.
+Fakt:          `StoreInvoiceToContract` verzweigt: `if (billingParam.IsContingent) StoreBookedContingent(vertragZuordnung, billingParam); else Session.GetGenericDAO<VertragRechKopfZuordnung>().Save(vertragZuordnung);`. `StoreBookedContingent` übernimmt aus `ContractContingentInfo` die Werte `Overbooking`, `RestTake`, `Kind` und berechnet `KontingentWert = contractContingent.Value * billingParam.InvoiceIntervalCount`. Bei Berechnungsart `Manual` oder `Need` wird `NachBerechnung = 2` gesetzt und Buchungs- gleich Berechnungszeitraum. Die Sicht `ContractContingentBooked` blendet Sätze mit `KontingentWert = 0`, `Zwischenrechnung >= 4` oder `Status <= 0` aus und berechnet `RestValue` über `cfn_RestValue(VZ.VertragI3D, VZ.GebuchtVon)`, sofern `KontingentRestMitnehmen <> 0` und `Zwischenrechnung not in (1,4)`.
+Aussage:       Das System soll bei jeder Vertragsrechnung eines Kontingentvertrags den periodengerechten Kontingentwert mit Buchungszeitraum, Überbuchungs- und Restmitnahmekennzeichen persistieren und daraus den Restwert ableitbar machen.
+Ergebnis:      Je Rechnung existiert ein `VertragRechKopfZuordnung`-Satz mit `KontingentWert`, `GebuchtVon`/`GebuchtBis`, `KontingentArt`, `KontingentUeberbuchung` und `KontingentRestMitnehmen`.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, `StoreBookedContingent` (`vertragZuordnung.KontingentWert = 1.0 * contractContingent.Value * billingParam.InvoiceIntervalCount;` sowie `Session.GetGenericDAO<VertragRechKopfZuordnung>().Save(vertragZuordnung)`) - Begründung: Durchsetzende Stelle der Kontingentbuchung.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `CREATE View [dbo].[ContractContingentBooked]` (`WHERE VK.KontingentVertrag = 1 AND VZ.KontingentWert <> 0 AND ISNULL(VZ.Zwischenrechnung,0) < 4 AND VZ.Status > 0`, `CASE WHEN IsNull(VZ.KontingentRestMitnehmen,0) = 0 OR VZ.Zwischenrechnung in (1,4) THEN 0 ELSE [dbo].[cfn_RestValue](...) END AS RestValue`) - Begründung: Datenbankseitige Durchsetzung der Restwertregel.
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[VertragRechKopfZuordnung]` (Spalten `KontingentWert`, `KontingentUeberbuchung`, `KontingentRestMitnehmen`, `GebuchtVon`, `GebuchtBis`, `NachBerechnung`) - Begründung: Zeigt das Persistenzformat der Buchung.
+Prüfidee:      Kontingentvertrag mit Wert 10 und `InvoiceIntervalCount = 3` abrechnen; der erzeugte Zuordnungssatz muss `KontingentWert = 30` und einen Buchungszeitraum über drei Intervalle tragen.
+Tracelinks:    StRS-209
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - ohne diese Buchung ist der Kontingentverbrauch nicht bewertbar.
+Status:        belegt
+Modul:         M-17
+
+ID:            SyRS-223
+Titel:         MSP-Differenzen als Sonderartikel zum Vertrag nachberechnen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        MSP-Auswertung
+Vorbedingung:  Eine MSP-Auswertungszeile ist mit einer Entscheidung ungleich `IgnoreImport` versehen und trägt eine `ContractI3D`.
+Fakt:          `AutomaticFacturaBL.CreateSpecialArticleToContractFromMspEvaluation` prüft mit `Guard.NotNull(compensationItemDto.MspItem.ContractI3D, ...)` und `Guard.NotNull(compensationItemDto.SpecialArticle.Positions, ...)`, ersetzt je Position den Beschreibungstext über `MspEvaluationReplacementBL().ReplaceVariablesText(positionSettingsText, compensationItemDto)` mit `PositionVariableText` aus `MspCollectorsBL.GetMspEvaluationSettings()` und ruft `CreateSpecialArticleToContract`. Dort werden Vertragsnummer und Kundennummer gegengeprüft ("Die Vertragsnummer konnte nicht gefunden werden", "Die Kundennummer passt nicht zur Vertragsnummer") und Artikel über `ArticleCode` bzw. `ManufacturerCode` aufgelöst ("Der Artikelcode konnte nicht gefunden werden"). Der Vorgang läuft in `Session.WithTransaction`.
+Aussage:       Das System soll aus einer bestätigten MSP-Abweichung eine Sonderartikelposition mit variablenbasiertem Beschreibungstext zum betroffenen Vertrag erzeugen und den Vorgang bei nicht auflösbarem Vertrag, Kunde oder Artikel vollständig zurückweisen.
+Ergebnis:      Bei erfolgreicher Prüfung existiert ein `SpecialArticleToContractHead` mit Positionen und `BillingDateValidFrom`; bei Fehlern wird ein Sammelfehlertext geliefert und nichts gespeichert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs, `CreateSpecialArticleToContract(SpecialArticleToContractHeadImport, AppUser, bool)` (Prüfungen `contractI3DAndCustomerI3DTuples.Any() == false` und `headImport.CustomerNumber.HasValue && ...Any(x => x.Item2 == headImport.CustomerNumber) == false`) - Begründung: Konkrete durchsetzende Validierung vor der Vertragszuordnung.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs, `CreateSpecialArticleToContract(IList<...>, AppUser)` mit `return Session.WithTransaction(...)` und Sammelfehlerausgabe - Begründung: Transaktionsklammer verhindert Teilbuchungen.
+  - [SEKUNDÄR] src/backend/Centron.BL/Statistics/MspCollectors/MspCollectorsBL.cs, `GetMspEvaluationSettings` (`ApplicationSettingID.MspEvaluationCompensationArticlePositionText`) - Begründung: Belegt den konfigurierbaren Positionstext der Kompensationsposition.
+Prüfidee:      MSP-Zeile mit nicht existierender Vertragsnummer bestätigen; es darf kein `SpecialArticleToContractHead` entstehen und die Meldung muss "Die Vertragsnummer konnte nicht gefunden werden" enthalten.
+Tracelinks:    StRS-210
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - schließt Margenverluste aus nicht weiterberechneten Lizenzmengen.
+Status:        belegt
+Modul:         M-18
+
+ID:            SyRS-224
+Titel:         Serverseitige Autorisierung der Vertragsabrechnung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Sicherheit
+Akteur:        Webservice-Endpunkt / Vertragsabrechnung
+Vorbedingung:  Ein gültiges Ticket liegt vor; die Rechnungserstellung wird über den REST-Endpunkt angestoßen.
+Fakt:          Im WPF-Client wird der Modulzugang über `ModuleRegistrationItem.For<AutomatedBillingAppModuleController>(() => Helper.HasRights(UserRightsConst.Sales.ID, UserRightsConst.Sales.AUTOMATED_BILLING), () => LicenseManager.Instance.HasLicense(LicenseGuids.ContractBilling) || LicenseManager.Instance.HasLicense(LicenseGuids.Centron))` geprüft, und der KI-Werkzeugpfad prüft explizit `if (!HasCurrentUserRight(UserRightsConst.Sales.AUTOMATED_BILLING)) return Error(toolCall, "Fehlende Berechtigung: Vertragsabrechnung darf nicht gestartet werden.")`. Der Serverendpunkt `CentronRestService.CreateAutomatedBillingInvoiceToContractComplete` ruft dagegen `AutomaticFacturaWebServiceBL.CreateInvoiceToContractComplete(this.GetLoggedInUserByTicket(request.Ticket), ...)` ohne erkennbare Rechteprüfung auf; `AutomaticFacturaWebServiceBL` enthält keinen Treffer für `HasUserRight`/`AppRightsBL`. `AutomatedBillingAppModuleController.GetRights()` liefert `null`.
+Aussage:       [HYPOTHESE] Das System soll die Berechtigung `UserRightsConst.Sales.AUTOMATED_BILLING` nicht nur im Client, sondern auch serverseitig beim Erzeugen von Vertragsrechnungen erzwingen.
+Ergebnis:      Ein Aufruf des Abrechnungsendpunkts ohne das Recht wird mit einem Rechtefehler abgewiesen, unabhängig vom verwendeten Client.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Finances/AutomatedBilling/AutomatedBillingView.ArtificialIntelligence.cs Zeile 267, `if (!HasCurrentUserRight(UserRightsConst.Sales.AUTOMATED_BILLING)) return Error(toolCall, "Fehlende Berechtigung: Vertragsabrechnung darf nicht gestartet werden.");` - Begründung: Belegt, dass die Regel fachlich gewollt ist und an mindestens einer Stelle durchgesetzt wird.
+  - [SEKUNDÄR] src/webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.Receipts.cs Zeile 1799 (`CreateAutomatedBillingInvoiceToContractComplete` ohne Rechteprüfung) - Begründung: Zeigt die Lücke, auf die sich die Hypothese bezieht.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/AutomatedBilling/AutomatedBillingAppModuleController.cs, `GetRights() => null` - Begründung: Die Modulschnittstelle meldet keine Rechte, die Durchsetzung liegt allein in der Registrierung.
+Prüfidee:      REST-Aufruf `CreateAutomatedBillingInvoiceToContractComplete` mit einem Ticket eines Benutzers ohne Recht 10385 absetzen; erwartet wird eine Ablehnung, nicht die Erzeugung einer Rechnung.
+Tracelinks:    StRS-205
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - Rechtedurchsetzung ist derzeit clientseitig gelöst; zur Bestätigung fehlt der Nachweis einer serverseitigen Prüfung im Request-Pipeline-/Ticket-Handling.
+Status:        HYPOTHESE
+Modul:         M-13
+
+ID:            SyRS-225
+Titel:         Unparametrisierte Filterfragmente in der Zählerstandssuche
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Sicherheit
+Akteur:        Klick-Zählerverwaltung / Datenzugriffsschicht
+Vorbedingung:  Der Anwender filtert die Zählerstandsliste nach Kundenname oder Barcode.
+Fakt:          `AutomaticFacturaBL.GetCounterWhere(SearchCounterStateFilter filter)` baut das WHERE-Fragment durch Stringverkettung, u. a. `result += " AND k.Name LIKE '%" + filter.CustomerName.Trim() + "%'";` und `result += " AND b.Barcode LIKE '" + filter.Barcode.Trim() + "%'";`. Das Ergebnis wird in `GetInputCounterState` als `new NamedQueryParameter("sWhere", GetCounterWhere(filter), NHibernateUtil.String, false, true)` – also als SQL-Fragment, nicht als Wert – an die NamedQuery `NamedQueryEnums.Asset.InputCounterState` übergeben. Dasselbe Muster nutzt `GetCounterHistory`, das die übergebenen Filterstrings unverändert konkateniert.
+Aussage:       Das System soll Filterwerte der Zählerstandssuche ausschließlich als gebundene Abfrageparameter übergeben und keine vom Anwender eingegebenen Zeichenketten in SQL-Fragmente einsetzen.
+Ergebnis:      Eingaben wie `' OR 1=1 --` im Kunden- oder Barcodefilter verändern die Ergebnismenge nicht und lösen keinen SQL-Fehler aus.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, `GetCounterWhere` Zeilen 721-726 (direkte Verkettung von `filter.CustomerName` und `filter.Barcode` in den SQL-Text) - Begründung: Benennt Datei, Methode und die konkrete Stelle, an der die Trennung von Code und Daten aufgehoben wird.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, `GetInputCounterState` (`new NamedQueryParameter("sWhere", GetCounterWhere(filter), NHibernateUtil.String, false, true)`) - Begründung: Das letzte `true` kennzeichnet die Übergabe als SQL-Teilausdruck und ist damit die durchsetzende (bzw. hier fehlende) Stelle der Parameterbindung.
+  - [SEKUNDÄR] Gegenbeispiel im selben Modul: `DeactivateCounterImport` verwendet `command.AddParameter("Grund", grund, DbType.String)` - Begründung: Belegt, dass parametrisierte Bindung im Codebestand verfügbar und üblich ist.
+Prüfidee:      Im Kundennamensfilter der Zählerstandssuche `x%' OR '1'='1` eingeben; die Trefferliste darf sich nicht auf alle Kunden ausweiten.
+Tracelinks:    StRS-208
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - funktionsfähige, aber sicherheitskritische Filterumsetzung; bei Übernahme durch Parameterbindung zu ersetzen.
+Status:        belegt
+Modul:         M-16

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_work/A3_StRS.md

@@ -0,0 +1,179 @@
+ID:            StRS-301
+Titel:         Gestufte Mahnung offener Kundenrechnungen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Debitorenbuchhalter / Finanzsachbearbeiter
+Vorbedingung:  Es existieren aktive Kundenrechnungen, deren Fälligkeitsdatum überschritten ist.
+Fakt:          Das WPF-Modul "Mahnung" (DunningOverviewAppModuleController) führt über die Seiten DunningCustomerSelectionView, DunningReceiptSelectionView, DunningRunPreviewView und DunningRunResultsView einen kundenbezogenen Mahnlauf durch; die fachliche Verarbeitung liegt in DunningRunBL.ExecuteDunningRun.
+Aussage:       Das System soll dem Debitorenbuchhalter ermöglichen, überfällige Rechnungen je Kunde auszuwählen und in einem protokollierten Mahnlauf mit steigender Mahnstufe anzumahnen.
+Ergebnis:      Für die ausgewählten Rechnungen ist die Mahnstufe erhöht, ein Mahnlauf-Protokolleintrag erzeugt und ein Mahnschreiben (PDF) als Druck- oder E-Mail-Ausgabe bereitgestellt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs, Methode ExecuteDunningRunInternal (Zeilen 200-246): ruft UpdateInvoice je Rechnung, SaveDunningRun, GenerateReport und optional GenerateMail auf - Begründung: Die Methode implementiert den vollständigen Geschäftsvorfall "Mahnlauf" und belegt Umfang und Ergebnis.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/Dunning/DunningOverviewAppModuleController.cs sowie ModuleRegistration.cs Kommentar "// Mahnung" - Begründung: Belegt, dass Mahnwesen als eigenständiges Anwendermodul angeboten wird.
+Prüfidee:      Für einen Kunden mit einer überfälligen, nicht gemahnten Rechnung einen Mahnlauf ausführen; danach muss die Rechnung Mahnstufe 1 tragen, ein Mahnlauf-Eintrag existieren und ein PDF erzeugt worden sein.
+Tracelinks:    SyRS-310, SyRS-311, SyRS-312, SyRS-313
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernprozess des Forderungsmanagements, fachlich unverändert gültig.
+Status:        belegt
+Modul:         M-19
+
+ID:            StRS-302
+Titel:         Versand von Offene-Posten-Kontoauszügen an Kunden
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Debitorenbuchhalter
+Vorbedingung:  Für einen Kunden existieren offene Rechnungen und/oder Gutschriften.
+Fakt:          Das Modul "OPOS" (OposOverviewAppModuleController, ModuleName "OPOS", Description "OPOS Übersicht") erzeugt über OposRunBL.ExecuteOposRun eine PDF-Datei mit dem Dateinamen-Präfix "Kontoauszug_" und versendet sie per Mail oder Druck.
+Aussage:       Das System soll dem Debitorenbuchhalter ermöglichen, einem Kunden einen Kontoauszug über alle offenen Posten (Rechnungen und Gutschriften) ohne Mahnwirkung zuzustellen.
+Ergebnis:      Ein Kontoauszug-PDF ist erzeugt und als E-Mail-Anhang oder Druckausgabe bereitgestellt; die Belegzustände des Kunden bleiben unverändert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposRunBL.cs, Methode ExecuteOposRun, Zeile 67: `var reportFileName = $"Kontoauszug_{DateTime.Today.ToString("dd_MM_yyyy")}.pdf";` - Begründung: Benennt das fachliche Ergebnisdokument und zeigt, dass keine Bestands-/Statusänderung stattfindet.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/Opos/OposOverviewAppModuleController.cs, ModuleName "OPOS" - Begründung: Belegt OPOS als eigenständiges Anwendermodul.
+Prüfidee:      OPOS-Lauf für einen Kunden mit zwei offenen Rechnungen ausführen; das PDF muss beide Rechnungen enthalten, und die Mahnstufen der Rechnungen dürfen unverändert bleiben.
+Tracelinks:    SyRS-314
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - eigenständiger, vom Mahnwesen abgegrenzter Kundenservice-Prozess.
+Status:        belegt
+Modul:         M-20
+
+ID:            StRS-303
+Titel:         Manuelle Erfassung von Zahlungseingängen zu Rechnungen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Debitorenbuchhalter
+Vorbedingung:  Eine Ausgangsrechnung ist erfasst und noch nicht vollständig bezahlt.
+Fakt:          Das Modul "Zahlungseingang" (PaymentsAppModuleController, Description "Zahlungseingänge verwalten") erlaubt in IncomingPaymentsViewModel.SaveReceipt die Erfassung eines Teil- oder Vollbetrags inklusive Kontoauszugsnummer, Kontoauszugsdatum, Zahlungsdatum, Bankverbindung (IBAN) und Kommentar.
+Aussage:       Das System soll dem Debitorenbuchhalter ermöglichen, Zahlungseingänge manuell einer Rechnung zuzuordnen, den bezahlten Betrag fortzuschreiben und die Rechnung wahlweise zu schließen.
+Ergebnis:      Der bezahlte Betrag der Rechnung ist erhöht, optional der Bezahlt-Status gesetzt, und ein Zahlungseingangs-Datensatz mit Restbetrag und Erfasser ist gespeichert.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Finances/Payments/IncomingPayments/IncomingPaymentsViewModel.cs, Methoden SaveReceipt (Zeilen 455-481) und SaveIncomingPaymentAsync (Zeilen 483-507) - Begründung: Zeigen den vollständigen fachlichen Ablauf inkl. Feldbelegung des Zahlungseingangs.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/Payments/PaymentsAppModuleController.cs, ModuleName "Zahlungseingang" - Begründung: Belegt die fachliche Modulbenennung.
+Prüfidee:      Auf eine Rechnung über 1.000 EUR einen Zahlungseingang von 400 EUR buchen; danach muss PaidPrice 400 betragen, ResidualAmount 600 sein und die Rechnung offen bleiben.
+Tracelinks:    SyRS-315, SyRS-316
+Konsolidierung: Kandidat: StRS-307 - Zahlungseingang wird zusätzlich vollautomatisch aus Kontoauszügen gebucht (siehe Konsolidierungstabelle).
+Übernahmewürdigkeit: übernehmen - manuelle Erfassung bleibt als Rückfallebene zur Kontoauszugsautomatik erforderlich.
+Status:        belegt
+Modul:         M-21
+
+ID:            StRS-304
+Titel:         Erfassung von Kosten- und Lieferantenbelegen (Ausgangszahlungen)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Einkaufssachbearbeiter / Buchhalter
+Vorbedingung:  Ein Lieferanten- oder Kostenbeleg liegt vor.
+Fakt:          Der Modulordner Modules/Warehousing/OutcomingPayments enthält OutgoingPaymentsAppModuleController mit ModuleName "Belegerfassung" und Description "Erfassung von Kosten und Belegen"; die Auswertung erfolgt über SupplierInvoicesBL.GetOutgoingPaymentReceiptItemsThroughPaging und GetOutgoingPaymentsHistoryThroughPaging.
+Aussage:       Das System soll die Erfassung ausgabenseitiger Belege (Kosten, Lieferantenrechnungen) mit Zuordnung zu Buchhaltungskonto und Kostenstelle sowie deren Historienauswertung ermöglichen.
+Ergebnis:      Ein Ausgabenbeleg ist mit Aufwandskonto, Lieferant und Bearbeiter erfasst und über die Ausgangszahlungs-Historie auswertbar.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/SupplierInvoices/SupplierInvoicesBL.cs, Methode GetOutgoingPaymentReceiptItemsThroughPaging (ab Zeile 38) mit Pflichtfiltern SupplierI3Ds, EmployeeI3Ds, ExpenseAccounts - Begründung: Belegt die fachlichen Dimensionen (Lieferant, Bearbeiter, Aufwandskonto) der Ausgangszahlungserfassung.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Warehousing/OutcomingPayments/Controller/OutgoingPaymentsAppModuleController.cs, ModuleName "Belegerfassung" - Begründung: Zeigt die tatsächliche Anwenderbenennung, die von der Ordnerbezeichnung "OutcomingPayments" abweicht.
+Prüfidee:      Einen Kostenbeleg mit Aufwandskonto und Lieferant erfassen; er muss anschließend in der Ausgangszahlungs-Historie mit demselben Aufwandskonto erscheinen.
+Tracelinks:    SyRS-317
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - fachlich benötigter Erfassungsprozess; Modulbenennung sollte auf "Belegerfassung" vereinheitlicht werden.
+Status:        belegt
+Modul:         M-22
+
+ID:            StRS-305
+Titel:         Verwaltung von Buchhaltungskontenrahmen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Administrator / Buchhaltungsverantwortlicher
+Vorbedingung:  Die Mandantenbuchhaltung erfordert einen definierten Kontenrahmen (z. B. SKR03/SKR04).
+Fakt:          BookKeepingAccountSystemsBL verwaltet Kontensysteme (BookKeepingAccountSystem mit Name, IsActive, IsDefault) und die darin enthaltenen Buchhaltungskonten (BookKeepingAccount mit Number, Caption, Description, Umsatzsteuerschlüsseln).
+Aussage:       Das System soll mehrere Buchhaltungskontenrahmen mit ihren Einzelkonten verwalten und einen davon als Standard für die Belegkontierung bereitstellen.
+Ergebnis:      Aktive Kontensysteme mit ihren Konten stehen zur Kontierung von Belegen und Artikeln zur Verfügung.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/BookKeepingAccountSystems/BookKeepingAccountSystemBL.cs, Klasse BookKeepingAccountSystemsBL, Methoden GetBookKeepingAccountSystems und GetBookKeepingAccounts(bool fromDefaultSystem) - Begründung: Implementiert die Verwaltung und die Auswahl über Aktiv-/Standard-Kennzeichen.
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, Zeilen 31975-32004: Tabellen [dbo].[BookKeepingAccounts] und [dbo].[BookKeepingAccountSystems] - Begründung: Belegt die persistente Datenhaltung des Kontenrahmens.
+Prüfidee:      Zwei Kontensysteme anlegen, eines als Standard markieren; GetBookKeepingAccounts(true) darf nur Konten des Standardsystems liefern.
+Tracelinks:    SyRS-318
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Grundlage jeder Buchhaltungsschnittstelle.
+Status:        belegt
+Modul:         M-23
+
+ID:            StRS-306
+Titel:         Erzeugung von SEPA-Lastschriftdateien für fällige Rechnungen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Debitorenbuchhalter
+Vorbedingung:  Es existieren fällige Rechnungen mit Zahlungskondition "Lastschrift" und hinterlegtem SEPA-Mandat.
+Fakt:          Das Modul "SEPA"/Zahlungsverkehr (PaymentTransactionAppModuleController) erzeugt über PaymentTransactionBL.ExportInvoices und PaymentTransactionSepaInterface.CreateSepaFile eine XML-Lastschriftdatei, die in PaymentTransactionViewModel.Export als Datei "SEPA_Transactions_yyyy-MM-dd HH_mm.xml" abgelegt wird.
+Aussage:       Das System soll aus ausgewählten fälligen Rechnungen eine bankfähige SEPA-Lastschriftdatei erzeugen und im konfigurierten Exportverzeichnis ablegen.
+Ergebnis:      Eine UTF-8-kodierte XML-Datei im gewählten pain.008-Format liegt im Exportverzeichnis; die enthaltenen Rechnungen sind als exportiert gekennzeichnet.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/DataExchange/PaymentTransactions/PaymentTransactionViewModel.cs, Methode Export, Zeile 340: `File.WriteAllText(fileName, xmlString.XMLString, new UTF8Encoding(false));` und GetValidFilename (Zeilen 369-383) - Begründung: Belegt das fachliche Endergebnis (Datei) inkl. Kodierung und Namenskonvention.
+  - [SEKUNDÄR] src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs, GetInterfaceList mit den UI-Bezeichnungen "SEPA (PAIN:008.001.01 STUZZA)" bis "SEPA V3.7 (PAIN:008.001.08 GBIC 4" - Begründung: Belegt die dem Anwender angebotenen Formatvarianten.
+Prüfidee:      Zwei lastschriftfähige Rechnungen exportieren; die erzeugte XML-Datei muss NbOfTxs=2 und eine CtrlSum gleich der Summe der Rechnungsbeträge enthalten.
+Tracelinks:    SyRS-319, SyRS-320, SyRS-321
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - regulatorisch erforderlicher Kernprozess des Zahlungsverkehrs.
+Status:        belegt
+Modul:         M-24
+
+ID:            StRS-307
+Titel:         Abruf von Kontoauszügen und automatische Zahlungszuordnung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Debitorenbuchhalter
+Vorbedingung:  Für mindestens ein Firmenbankkonto ist eine Online-Banking-Konfiguration (finAPI, FinTS oder Tabellendatei) hinterlegt.
+Fakt:          Das Modul "Kontoauszüge (finAPI)" (OnlineBankingAccountTransactionsController, Description "Das Modul listet Transaktionen für Bankkonten auf und erlaubt eine automatisierte oder manuelle Zuweisung von Rechnungen") ruft Umsätze ab und ordnet sie über OnlineBankingAccountTransactionsBL.AutoCompleteAccountTransacitons Kunden und Rechnungen zu.
+Aussage:       Das System soll Bankumsätze je Konfiguration abrufen, sie automatisch Kunden und offenen Rechnungen zuordnen und die Zuordnungen nach Bestätigung als Zahlungseingang verbuchen.
+Ergebnis:      Kontoumsätze sind gespeichert, mit Zuordnungsvorschlägen samt Trefferheuristik versehen und nach Verbuchung als bezahlt gekennzeichnete Rechnungen mit Belegprotokoll hinterlegt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingAccountTransactionsBL.cs, Methode AutoCompleteSingleAccountTransaciton (Zeilen 581-617) mit den kommentierten Suchstufen "Search 1/2/3" - Begründung: Beschreibt den fachlichen Kern des automatisierten Zahlungsabgleichs.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/OnlineBanking/AccountTransactions/OnlineBankingAccountTransactionsController.cs, ModuleName "Kontoauszüge (finAPI)" - Begründung: Belegt die fachliche Modulbenennung und Zweckbeschreibung.
+Prüfidee:      Einen Umsatz mit exakt der offenen Rechnungssumme und der Rechnungsnummer im Verwendungszweck importieren; das System muss Kunde und Rechnung ohne Benutzereingriff korrekt vorschlagen.
+Tracelinks:    SyRS-322, SyRS-323, SyRS-324, SyRS-325
+Konsolidierung: Kandidat: StRS-303 - zweiter Weg, denselben Zahlungseingang zu verbuchen.
+Übernahmewürdigkeit: übernehmen - senkt den manuellen Aufwand im Debitorenmanagement erheblich.
+Status:        belegt
+Modul:         M-25
+
+ID:            StRS-308
+Titel:         Digitale Einholung von SEPA-Lastschriftmandaten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertrieb / Kundenbetreuer, Kunde als Unterzeichner
+Vorbedingung:  Für den Kunden liegt eine Mandatsvorlage (SepaContractTemplate) vor.
+Fakt:          SepaContract-Objekte werden aus Vorlagen erzeugt, per Mail an einen Ansprechpartner versendet und über SepaContractOnlinePdfDocumentHandler.Confirm/Decline/SetExpired online bestätigt, abgelehnt oder als abgelaufen markiert; Zustände sind Created, Sent, Accepted, Declined, LinkExpired.
+Aussage:       Das System soll SEPA-Lastschriftmandate aus zentralen Vorlagen erzeugen, dem Kunden zur Online-Unterzeichnung zustellen und das unterschriebene Mandat revisionsfähig beim Kunden ablegen.
+Ergebnis:      Das unterzeichnete Mandat liegt als PDF im Kundendokumentenverzeichnis, der Mandatsstatus ist "Accepted", und die zugehörige Bankverbindung ist autorisiert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Documents/Dsgvo/SepaContractOnlinePdfDocumentHandler.cs, Methode Confirm (Zeilen 78-178): erzeugt PDF, versendet Bestätigungsmails, legt das Dokument über DocumentBL.AddFileToDirectory ab und setzt `contract.State = SepaContractState.Accepted;` - Begründung: Vollständiger Nachweis des fachlichen Ablaufs bis zur Ablage.
+  - [SEKUNDÄR] src/backend/Centron.Interfaces/Administration/Documents/SepaContracts/SepaContractState.cs mit Created/Sent/Accepted/Declined/LinkExpired - Begründung: Belegt den fachlichen Lebenszyklus des Mandats.
+Prüfidee:      Ein Testmandat versenden und online bestätigen; danach muss der Status Accepted sein und ein PDF im SEPA-Verzeichnis des Kunden liegen.
+Tracelinks:    SyRS-326
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Voraussetzung für rechtssichere Lastschrifteinzüge (StRS-306).
+Status:        belegt
+Modul:         M-26
+
+ID:            StRS-309
+Titel:         Pflege von Kostenstellen und Kostenträgern als Stammdaten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Stammdatenverantwortlicher / Controller
+Vorbedingung:  Der Mandant nutzt eine Kostenrechnung.
+Fakt:          Das Modul "Kostenträger / Kostenstellen" (PayersAndCostCenterAppModuleController, MainCategory BaseData, Description "Erstellung und Verwaltung von Kostenträger / Kostenstellen") pflegt die Entitäten CostCenter (Tabelle Kostenstellen) und CostObject (Tabelle Kostentraeger) mit Nummer und Beschreibung.
+Aussage:       Das System soll Kostenstellen und Kostenträger als eigenständige Stammdaten mit Nummer und Beschreibung anlegen, ändern, deaktivieren und wiederherstellen lassen.
+Ergebnis:      Gepflegte Kostenstellen und Kostenträger stehen zur Kontierung von Belegen und Positionen zur Verfügung.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter/PayersAndCostCenterAppModuleControllerViewModel.cs, Methoden DoCostCenterSaveOrUpdate, DoCostCenterDelete und CostCenterRestoreAsync - Begründung: Belegen den vollständigen Pflegeumfang inkl. Wiederherstellung.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Zeile 849: `() => Helper.HasRights(UserRightsConst.Masterdata.PAYERS_AND_COST_CENTER)` - Begründung: Belegt die Einordnung als berechtigungsgeschützte Stammdatenpflege.
+Prüfidee:      Eine Kostenstelle anlegen, löschen und wiederherstellen; sie muss danach wieder in der Standardliste (ohne "gelöschte anzeigen") erscheinen.
+Tracelinks:    SyRS-327
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Stammdatenbasis für Kostenrechnung und Belegerfassung (StRS-304).
+Status:        belegt
+Modul:         M-27

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_work/A3_SyRS.md

@@ -0,0 +1,364 @@
+ID:            SyRS-310
+Titel:         Mahnstufeneskalation und Sperre nach Stufe 3
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Backend-Komponente DunningRunBL / DunningRunWebServiceBL
+Vorbedingung:  Ein Mahnlauf mit mindestens einer Rechnung wurde angestoßen.
+Fakt:          DunningRunBL.UpdateInvoice erhöht die Mahnstufe genau um eine Stufe (None→Level1, Level1→Level2, Level2→Level3) und setzt je Stufe Datum und Bearbeiter; DunningRunWebServiceBL.ValidateDunningRun wirft eine ArgumentException für Rechnungen ohne Mahnstufe (noch nicht fällig) und für Rechnungen, die bereits DunningLevel.Level3 haben.
+Aussage:       Das System soll je Mahnlauf die Mahnstufe einer Rechnung um genau eine Stufe erhöhen, dabei Mahndatum und mahnenden Bearbeiter festhalten und Rechnungen ohne erreichte Fälligkeit sowie Rechnungen in Mahnstufe 3 vom Mahnlauf ausschließen.
+Ergebnis:      Rechnungen tragen nach dem Lauf die nächsthöhere Mahnstufe mit Zeitstempel und Bearbeiter; ein Lauf mit unzulässigen Rechnungen wird vollständig abgewiesen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/Receipts/DunningRunWebServiceBL.cs, Methode ValidateDunningRun, Zeilen 129-135: `var invoicesPreDueDate = dunningRun.Invoices.Where(f => f.DunningLevel.HasValue == false); if (...) throw new ArgumentException(...)` und `var invoicesInDunningLevel3 = dunningRun.Invoices.Where(f => f.DunningLevel == DunningLevel.Level3); if (...) throw ...` - Begründung: Benennt die durchsetzende Prüfung, die die Obergrenze der Eskalation erzwingt.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs, Methode UpdateInvoice, Zeilen 248-275 (switch über invoice.DunningLevel mit `default: throw new ArgumentOutOfRangeException();`) - Begründung: Erzwingt die Einzelschritt-Eskalation und schließt undefinierte Zustände aus.
+Prüfidee:      Mahnlauf für eine Rechnung in Mahnstufe 3 anstoßen; der Aufruf muss mit ArgumentException abgewiesen werden und die Mahnstufe unverändert bleiben.
+Tracelinks:    StRS-301
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - definiert die zwingende Eskalationslogik des Mahnwesens.
+Status:        belegt
+Modul:         M-19
+
+ID:            SyRS-311
+Titel:         Vollständige Rücknahme eines Mahnlaufs
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Backend-Komponente DunningRunBL
+Vorbedingung:  Ein Mahnlauf mit einer Mahnlaufnummer existiert und wurde noch nicht zurückgenommen.
+Fakt:          DunningRunBL.ResetDunningRun lädt alle DunningRunItem einer Mahnlaufnummer, setzt DeletedByEmployeeI3D, DeletedDate und State = DunningRunState.Deleted, senkt die Mahnstufe der zugehörigen Rechnung um genau eine Stufe und löscht das jeweilige Mahnstufendatum und den Bearbeiter; der gesamte Vorgang läuft in einer Transaktion mit Rollback im Fehlerfall.
+Aussage:       Das System soll einen Mahnlauf anhand seiner Mahnlaufnummer vollständig und transaktional zurücknehmen, indem alle Laufpositionen als gelöscht markiert und die Mahnstufen der betroffenen Rechnungen um eine Stufe zurückgesetzt werden.
+Ergebnis:      Alle Positionen des Laufs sind mit Status "Deleted", Löschzeitpunkt und Löschendem markiert; die Rechnungen stehen wieder auf der vorherigen Mahnstufe.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs, Methode ResetDunningRun, Zeilen 495-554: `currentItem.State = DunningRunState.Deleted;` sowie der switch, der Level3→Level2, Level2→Level1, Level1→None zurücksetzt, eingebettet in StartTransaction/CommitTransaction/RollbackTransaction - Begründung: Benennt die durchsetzende Stelle inklusive Transaktionsklammer.
+  - [SEKUNDÄR] src/backend/Centron.Interfaces/Sales/Receipts/Invoices/Dunning/DunningRunState.cs (Deleted, Active) - Begründung: Belegt die Zustandsmenge der Mahnlaufpositionen.
+Prüfidee:      Mahnlauf ausführen, danach zurücknehmen; die Rechnung muss die ursprüngliche Mahnstufe tragen und der Mahnlaufeintrag den Status "Deleted" mit Löschdatum aufweisen.
+Tracelinks:    StRS-301
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - notwendige Korrekturfunktion mit revisionssicherer Historie (kein physisches Löschen).
+Status:        belegt
+Modul:         M-19
+
+ID:            SyRS-312
+Titel:         Berechtigungsprüfung für Mahnwesen und OPOS
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Backend-Komponenten DunningBL / OposBL
+Vorbedingung:  Ein angemeldeter Benutzer ruft eine Mahn- oder OPOS-Funktion auf.
+Fakt:          DunningBL.ThrowIfUserHasInsufficentRights ruft AppRightsBL.CheckRightsFromUser mit UserRightsConst.Controlling.Finances.Dunning (Wert 10971) und wirft eine Exception, wenn das Recht nicht im Ergebnis enthalten ist; die Prüfung wird in GetDunningCustomers, CalculateDunningStatistics, UpdateDunningSettingsForCustomer, DunningRunBL.GetDunningRuns, ExecuteDunningRunInternal und ValidateDunningRun aufgerufen. Zusätzlich ist die Modulanzeige in ModuleRegistration.cs an dasselbe Recht gebunden.
+Aussage:       Das System soll jeden lesenden und schreibenden Zugriff auf Mahn- und OPOS-Daten serverseitig gegen das Benutzerrecht 10971 ("Mahnwesen") prüfen und bei fehlendem Recht mit einem Fehler abbrechen.
+Ergebnis:      Benutzer ohne Recht 10971 erhalten weder Mahn-/OPOS-Daten noch können sie Mahnläufe ausführen; das Modul wird ihnen nicht angeboten.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs, Methode ThrowIfUserHasInsufficentRights, Zeilen 1059-1067: `var result = new AppRightsBL(this.Session).CheckRightsFromUser(loggedInUser.UserI3D.Value, UserRightsConst.Controlling.Finances.Dunning); if (result.Contains(...) == false) throw new Exception(...)` - Begründung: Konkrete durchsetzende Prüfung mit benannter Bedingung.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Zeilen 607-613: `ModuleRegistrationItem.For<DunningOverviewAppModuleController>(() => Helper.HasRights(UserRightsConst.Controlling.Finances.Dunning), ...)` und identisch für OposOverviewAppModuleController - Begründung: Zweite durchsetzende Stelle auf Modulebene.
+  - [SEKUNDÄR] src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs, Zeile 2556: `public const int Dunning = 10971;` - Begründung: Belegt die konkrete Rechtenummer.
+Prüfidee:      Benutzer ohne Recht 10971 ruft GetDunningCustomers auf; der Aufruf muss mit einer Exception scheitern, nicht mit einer leeren Liste antworten.
+Tracelinks:    StRS-301
+Konsolidierung: Kandidat: SyRS-314 - OPOS nutzt dasselbe Recht, obwohl es ein anderer Geschäftsvorfall ist.
+Übernahmewürdigkeit: Workaround - die Prüfung greift, verwendet für OPOS aber ein fachfremdes Recht; für die Neuentwicklung ist ein eigenes OPOS-Recht vorzusehen.
+Status:        belegt
+Modul:         M-19
+
+ID:            SyRS-313
+Titel:         Mahnstopp sperrt Belege und Kunden für den Mahnlauf
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Client-Komponenten DunningItemViewModel / DunningCustomerViewModel
+Vorbedingung:  Für einen Kunden oder eine Rechnung ist ein Mahnstopp (Kennzeichen und/oder Zeitraum) hinterlegt.
+Fakt:          DunningBL.GetDunningStopActive ermittelt den aktiven Mahnstopp aus DunningStopBegin, DunningStopEnd und dem Kennzeichen DunningStop über ein switch über (begin.HasValue, end.HasValue); DunningItemViewModel.EvaluateSelectionValidity und DunningCustomerViewModel.EvaluateValidity tragen bei aktivem Mahnstopp einen Sperrgrund in SelectionDisabledReasons bzw. InvalidForDunningReasons ein.
+Aussage:       Das System soll Rechnungen und Kunden mit aktivem Mahnstopp von der Auswahl für einen Mahnlauf ausschließen und den Sperrgrund einschließlich Mahnstoppzeitraum und Mahninfo anzeigen.
+Ergebnis:      Gesperrte Belege sind nicht auswählbar; der Anwender sieht den Text "Rechnung ist ab <Datum> bis <Datum> im Mahnstopp." bzw. die kundenbezogene Variante.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Finances/Dunning/Common/DunningItemViewModel.cs, Methode EvaluateSelectionValidity, Zeilen 455-467: `if (this.DunningStopActive) { ... this.SelectionDisabledReasons.Add(dunningStopReason); ... }` - Begründung: Durchsetzende Stelle, die die Auswahl des Belegs verhindert.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs, Methode GetDunningStopActive(DateTime?, DateTime?, bool), Zeilen 170-182 - Begründung: Definiert die maßgebliche Bedingung, wann ein Mahnstopp als aktiv gilt.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/Dunning/Common/DunningStopHelper.cs, GetDunningStopActiveDisplayText - Begründung: Belegt den dem Anwender angezeigten Sperrtext.
+Prüfidee:      Rechnung mit Mahnstopp-Zeitraum, der das heutige Datum einschließt, in der Belegauswahl öffnen; sie darf nicht selektierbar sein und muss den Zeitraum als Sperrgrund anzeigen.
+Tracelinks:    StRS-301
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - die Sperre ist ausschließlich clientseitig implementiert; in der Neuentwicklung ist sie zusätzlich serverseitig in ValidateDunningRun zu erzwingen.
+Status:        belegt
+Modul:         M-19
+
+ID:            SyRS-314
+Titel:         OPOS-Lauf verändert weder Mahnstufe noch Mahnhistorie
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Backend-Komponente OposRunBL
+Vorbedingung:  Ein OPOS-Lauf für einen Kunden wurde validiert und angestoßen.
+Fakt:          OposRunBL.ExecuteOposRun erzeugt ausschließlich Report und Mail und liefert `DunningRunNumber = 0` zurück; es existiert kein Aufruf von UpdateInvoice, SaveDunningRun oder SaveDunningRunItem. OposRunWebServiceBL.ValidateOposRun prüft im Gegensatz zu ValidateDunningRun weder Mahnstufe noch Fälligkeit.
+Aussage:       Das System soll beim OPOS-Lauf ausschließlich ein Kontoauszugsdokument erzeugen und dabei weder Mahnstufen fortschreiben noch Mahnlaufpositionen anlegen.
+Ergebnis:      Nach einem OPOS-Lauf sind Mahnstufen, Mahndaten und Mahnlaufhistorie der beteiligten Belege unverändert; das Ergebnisobjekt trägt die Mahnlaufnummer 0.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposRunBL.cs, Methode ExecuteOposRun, Zeilen 82-89: Rückgabe `new DunningRunResultDTO { ReportFileName = ..., Report = ..., Mail = ..., DunningRunNumber = 0, ReceiptReports = receiptReports }` ohne jede Belegaktualisierung - Begründung: Belegt durch Abwesenheit jeder Schreiboperation die Wirkungsfreiheit des Laufs.
+  - [SEKUNDÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/OposRunWebServiceBL.cs, ValidateOposRun (Zeilen 40-66) ohne Mahnstufen- und Fälligkeitsprüfung - Begründung: Bestätigt, dass OPOS bewusst ohne Mahnsemantik arbeitet.
+Prüfidee:      OPOS-Lauf für eine Rechnung in Mahnstufe 2 ausführen; Mahnstufe, Mahndatum und Anzahl der Mahnlaufeinträge müssen danach identisch sein.
+Tracelinks:    StRS-302
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - klare fachliche Abgrenzung zwischen Kontoauszug und Mahnung.
+Status:        belegt
+Modul:         M-20
+
+ID:            SyRS-315
+Titel:         Zahlungseingang schreibt Rechnungszahlbetrag und Bezahltstatus fort
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Modul Zahlungseingang (IncomingPaymentsViewModel) und ReceiptBL
+Vorbedingung:  Eine Rechnung ist ausgewählt und ein Zahlbetrag erfasst.
+Fakt:          IncomingPaymentsViewModel.SaveReceipt berechnet `newPaidFC = this._receipt.PaidFC + (this.SelectedReceipt.NewAmountPaid * this.SelectedReceipt.Receipt.CurrencyFactor)` und ruft UpdateReceiptIsPaid mit dem Modulkennzeichen "Zahlungseingang" und der ConcurrencyControlGuid der Rechnung auf; der Zahlungseingang wird erst nach erfolgreicher Belegaktualisierung persistiert.
+Aussage:       Das System soll bei einer Zahlungseingangsbuchung den kumulierten Zahlbetrag der Rechnung währungsbereinigt erhöhen, den Bezahltstatus nur bei explizitem Abschluss setzen und die Buchung optimistisch gegen Parallelbearbeitung sichern.
+Ergebnis:      Der Zahlbetrag der Rechnung ist um den erfassten Betrag multipliziert mit dem Währungsfaktor erhöht; bei Konflikt der ConcurrencyControlGuid wird die Buchung abgewiesen und kein Zahlungseingang gespeichert.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Finances/Payments/IncomingPayments/IncomingPaymentsViewModel.cs, Methode SaveReceipt, Zeilen 462-475: Berechnung von newPaidFC, `var newIsPaid = this.CloseReceipt ? true : (bool?)null;`, Abbruch bei `result.Status is ResultStatus.Error` vor `await this.SaveIncomingPaymentAsync();` - Begründung: Benennt Reihenfolge, Bedingung und Sperrmechanismus der Buchung.
+  - [SEKUNDÄR] Dieselbe Datei, Methode AddMissingOffsett (Zeilen 545-556): Skonto wird nur angewandt, wenn `this.SelectedReceipt.Receipt.PaidPrice == Decimal.Zero` - Begründung: Belegt die zusätzliche fachliche Regel zur Skontoanwendung.
+Prüfidee:      Rechnung in Fremdwährung mit Währungsfaktor 1,1 und Zahlbetrag 100 buchen; PaidFC muss um 110 steigen und die Rechnung ohne gesetztes "Abschließen" offen bleiben.
+Tracelinks:    StRS-303
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - definiert die Buchungssemantik des Zahlungseingangs.
+Status:        belegt
+Modul:         M-21
+
+ID:            SyRS-316
+Titel:         Löschen von Zahlungseingängen nur mit Recht und mit Betragsstornierung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Backend-Komponente PaymentsBL
+Vorbedingung:  Ein oder mehrere Zahlungseingänge sollen gelöscht werden.
+Fakt:          PaymentsBL.DeleteIncomingPayment bricht mit `Result.AsError("Sie haben nicht das Recht 'Zahlungseingang.", DefaultMessageCodes.RightCheckFailed)` ab, wenn `loggedInUser.User.HasUserRight(UserRightsConst.Controlling.Finances.INCOMING_PAYMENT_TRANSACTIONS) == false`; bei erlaubter Löschung wird je Rechnung die Summe der gelöschten Beträge negiert (`groupie.Sum(f => f.Amount) * (-1)`) über ReceiptBL.UpdateReceiptIsPaid mit dem Protokolltext "Zahlungseingang gelöscht" zurückgebucht. CreateFilterExpression verhindert über `Guard.Not(...)` das Löschen ohne Filter.
+Aussage:       Das System soll das Löschen von Zahlungseingängen nur Benutzern mit dem Recht "Zahlungseingang" (10980) erlauben, den gelöschten Betrag am zugehörigen Beleg gegenbuchen und Löschaufrufe ohne einschränkenden Filter zurückweisen.
+Ergebnis:      Ohne Recht wird ein Fehler mit RightCheckFailed zurückgegeben und nichts gelöscht; mit Recht ist der bezahlte Betrag der Rechnung um die gelöschten Beträge reduziert und im Belegprotokoll vermerkt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Finances/Payments/PaymentsBL.cs, Methode DeleteIncomingPayment, Zeilen 43-45 (Rechteprüfung) und Zeilen 62-71 (Gegenbuchung über `amountToChange * invoice.CurrencyFactor` mit Protokolltext "Zahlungseingang gelöscht") - Begründung: Benennt die durchsetzende Bedingung und die zwingende fachliche Folgehandlung.
+  - [PRIMÄR]   Dieselbe Datei, Methode CreateFilterExpression, Zeilen 161-162: `Guard.Not((filter.InvoiceNumbers == null && filter.InvoiceHeadI3Ds == null && filter.IncomingPaymentI3Ds == null), "Empty Filters are not allowed for deleting IncomingPayments")` - Begründung: Verhindert Massenlöschung ohne Einschränkung.
+  - [SEKUNDÄR] src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs, Zeile 2561: `INCOMING_PAYMENT_TRANSACTIONS = 10980` - Begründung: Belegt die Rechtenummer.
+Prüfidee:      Als Benutzer ohne Recht 10980 einen Zahlungseingang löschen; Ergebnis muss RightCheckFailed sein und Betrag sowie Datensatz unverändert bleiben.
+Tracelinks:    StRS-303
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - abrechnungsrelevante Schutzregel.
+Status:        belegt
+Modul:         M-21
+
+ID:            SyRS-317
+Titel:         Modulzugang zur Belegerfassung über Recht und Lizenz
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Modulregistrierung der WPF-Anwendung
+Vorbedingung:  Die Anwendung baut die Modulliste für den angemeldeten Benutzer auf.
+Fakt:          In ModuleRegistration.cs ist die Belegerfassung registriert als `ModuleRegistrationItem.For<OutgoingPaymentsAppModuleController>(() => Helper.HasRights(UserRightsConst.Purchase.ID, UserRightsConst.Purchase.Inventory.ID), () => LicenseManager.Instance.HasLicense(LicenseGuids.DocumentCapture) || LicenseManager.Instance.HasLicense(LicenseGuids.Centron))`; der Controller selbst liefert in GetRights() null.
+Aussage:       Das System soll das Modul Belegerfassung nur anbieten, wenn der Benutzer sowohl das Einkaufs- als auch das Lagerrecht besitzt und der Mandant über die Lizenz "DocumentCapture" oder eine c-entron-Vollizenz verfügt.
+Ergebnis:      Benutzer ohne eines der beiden Rechte oder ohne passende Lizenz sehen das Modul nicht in der Modulliste.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Block "// Belegerfassung" (Zeilen 675-677): Rechte- und Lizenzprädikat wie oben - Begründung: Konkrete, durchsetzende Registrierungsbedingung mit benannten Rechten und Lizenz-GUIDs.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Warehousing/OutcomingPayments/Controller/OutgoingPaymentsAppModuleController.cs, `public IList<int> GetRights() { return null; }` - Begründung: Zeigt, dass die Zugriffssteuerung ausschließlich über die Registrierung erfolgt.
+Prüfidee:      Benutzer mit Einkaufsrecht, aber ohne Lagerrecht anmelden; das Modul "Belegerfassung" darf nicht erscheinen.
+Tracelinks:    StRS-304
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - Zugriffsschutz ausschließlich auf Client-Modulebene; serverseitige Absicherung der Belegerfassungsaufrufe ist nicht belegt.
+Status:        belegt
+Modul:         M-22
+
+ID:            SyRS-318
+Titel:         Auswahl aktiver und Standard-Kontensysteme
+Ebene:         SyRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Backend-Komponente BookKeepingAccountSystemsBL
+Vorbedingung:  Es sind ein oder mehrere Buchhaltungskontensysteme angelegt.
+Fakt:          BookKeepingAccountSystemsBL.CreateGetAccountSystemsExpression ergänzt bei filter.OnlyActive die Bedingung `f.IsActive` und bei filter.OnlyDefault die Bedingung `f.IsDefault`; GetBookKeepingAccounts(bool fromDefaultSystem) liefert die Konten aller so gefilterten Systeme. Weder BookKeepingAccountSystemsWebServiceBL.ToEntity noch die Tabelle [dbo].[BookKeepingAccountSystems] (nur PK auf I3D) erzwingen, dass höchstens ein System IsDefault = 1 trägt.
+Aussage:       [HYPOTHESE] Das System soll genau ein aktives Kontensystem als Standardkontenrahmen führen und dessen Konten für die Standardkontierung liefern.
+Ergebnis:      Aufrufe mit fromDefaultSystem = true liefern die Konten genau eines Kontenrahmens.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/BookKeepingAccountSystems/BookKeepingAccountSystemBL.cs, Methode CreateGetAccountSystemsExpression, Zeilen 39-47 - Begründung: Belegt die tatsächlich implementierte Filterung nach IsActive/IsDefault.
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, Zeilen 31994-32004: [dbo].[BookKeepingAccountSystems] mit `[IsDefault] [bit] NOT NULL` und ausschließlich `CONSTRAINT [PK_BookKeepingAccountSystems] PRIMARY KEY CLUSTERED ([I3D] ASC)` - Begründung: Zeigt das Fehlen eines Unique-Constraints auf IsDefault.
+Prüfidee:      Zwei Kontensysteme mit IsDefault = 1 speichern; die heutige Implementierung akzeptiert dies - Zielverhalten wäre eine Abweisung bzw. ein automatisches Zurücksetzen des bisherigen Standards. Zur Bestätigung fehlen eine Eindeutigkeitsprüfung beim Speichern oder ein DB-Constraint auf IsDefault sowie eine Fachaussage, ob mehrere parallele Standardkontenrahmen (z. B. je Mandant) gewollt sind.
+Tracelinks:    StRS-305
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - Regel wird vom Code vorausgesetzt, aber nirgends erzwungen; für die Neuentwicklung als Constraint oder Speicherprüfung umzusetzen.
+Status:        HYPOTHESE
+Modul:         M-23
+
+ID:            SyRS-319
+Titel:         Vorabvalidierung der SEPA-Exportdaten
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Gateway-Komponente PaymentTransactionSepaInterface
+Vorbedingung:  Der Anwender hat Rechnungen zum Lastschrifteinzug ausgewählt und den Export ausgelöst.
+Fakt:          PaymentTransactionSepaInterface.CreateSepaFile ruft zuerst ValidateExportData auf und bricht bei ResultStatus.Error ab. ValidateExportData sammelt unter anderem Fehler für: Abbuchungsdatum in der Vergangenheit, fehlende oder normwidrige BIC (Regex `^([A-Z]{4}[A-Z]{2}[A-Z0-9]{2}([A-Z0-9]{3})?)$`) von Mandant und Zahlungspflichtigem, fehlende IBAN, fehlende SEPA-Gläubiger-ID, fehlendes oder in der Zukunft liegendes Autorisierungsdatum, fehlende Mandatsreferenz (AuthorizationNumber), Lastschrifttyp "Unbekannt", Bankverbindung außerhalb ValidFrom/ValidTo, Betrag kleiner gleich 0, Zahlungskondition ohne Lastschriftmodus, Fremdwährung sowie unzulässige Zeichen im Verwendungszweck.
+Aussage:       Das System soll vor Erzeugung einer SEPA-Datei alle Export-Positionen und die Mandantenbankverbindung gegen den vollständigen Regelkatalog prüfen und den Export bei mindestens einem Verstoß mit einer je Rechnung ausgewiesenen Fehlermeldung vollständig verweigern.
+Ergebnis:      Es wird keine Datei erzeugt; der Anwender erhält eine Liste aller Verstöße mit dem Präfix "Rechnung <Nummer>: ".
+Belege:
+  - [PRIMÄR]   src/backend/Centron.Gateway/DataExchange/PaymentTransactions/Sepa/PaymentTransactionSepaInterface.cs, Methode ValidateExportData (Zeilen 22-198) und CreateSepaFile Zeilen 203-205: `Result validateResult = ValidateExportData(...); if (validateResult.Status == ResultStatus.Error) return Result<string>.FromResult(validateResult);` - Begründung: Benennt die durchsetzende Stelle und die Abbruchbedingung vor jeder Dateierzeugung.
+  - [SEKUNDÄR] Dieselbe Datei, Zeilen 136-140: Meldung "Keine Authorisierungsnummer (Mandat) hinterlegt." und Zeilen 154-158: "Zahlungskondition steht nicht auf Lastschrift Modus." - Begründung: Konkrete Fehlermeldungen belegen die fachlichen Einzelregeln.
+Prüfidee:      Rechnung mit Bankverbindung ohne Mandatsreferenz exportieren; der Export muss ohne Dateierzeugung mit der Meldung "Keine Authorisierungsnummer (Mandat) hinterlegt." abbrechen.
+Tracelinks:    StRS-306
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - schützt vor bankseitigen Rückweisungen und Rücklastschriften.
+Status:        belegt
+Modul:         M-24
+
+ID:            SyRS-320
+Titel:         Kennzeichnung und Protokollierung exportierter Rechnungen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Backend-Komponente PaymentTransactionBL
+Vorbedingung:  Eine SEPA-Datei wurde fehlerfrei erzeugt.
+Fakt:          PaymentTransactionBL.InvoiceExportDone setzt in einer Transaktion je Exportposition über `_repository.SetInvoiceAsExported(currentEmployeeI3D, exportItem.Invoice.I3D, true)` das Lastschrift-Kennzeichen, schließt die Rechnung optional über InvoiceBL.SetInvoiceAsPaid mit dem Text "Abschluss über SEPA Export", wenn die Einstellung PaymentTransactionCloseInvoiceAfterExport den Wert 1 hat, und legt je Position einen IncomingPaymentLog mit gemeinsamer LogNumber, Zahler-IBAN, Mandatsreferenz und Empfänger-IBAN an. PaymentTransactionBL.ResetInvoiceExportedFlag nimmt dies zurück, überspringt aber Einträge mit `logEntry.PaymentTransactionReturnedEmployeeI3D > 0`.
+Aussage:       Das System soll nach jedem SEPA-Export die exportierten Rechnungen transaktional als lastschriftbeauftragt kennzeichnen, je Lauf ein Zahlungseingangsprotokoll mit gemeinsamer Laufnummer schreiben und eine Rücknahme des Exports genau einmal je Protokolleintrag zulassen.
+Ergebnis:      Exportierte Rechnungen tragen IsDebitCreated inklusive Zeitpunkt und Bearbeiter; ein bereits zurückgenommener Protokolleintrag wird bei erneuter Rücknahme übersprungen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs, Methode InvoiceExportDone, Zeilen 249-288 (StartTransaction/CommitTransaction/RollbackTransaction um SetInvoiceAsExported, SetInvoiceAsPaid und CreateIncomingPaymentLogItem) - Begründung: Benennt die durchsetzende Stelle inklusive Transaktionsklammer.
+  - [PRIMÄR]   Dieselbe Datei, Methode ResetInvoiceExportedFlag, Zeilen 305-306: `if (logEntry.PaymentTransactionReturnedEmployeeI3D > 0) continue;` - Begründung: Erzwingt die Einmaligkeit der Rücknahme.
+  - [SEKUNDÄR] Dieselbe Datei, Zeile 327: Belegprotokolltext "... hat am ... die Rechnung über die Rücknahme des Zahlungseingangs (SEPA-Export) wieder geöffnet." - Begründung: Belegt die fachliche Nachvollziehbarkeit der Rücknahme.
+Prüfidee:      Export durchführen, Rücknahme zweimal auslösen; beim zweiten Mal darf sich weder der bezahlte Betrag noch das Kennzeichen erneut ändern.
+Tracelinks:    StRS-306
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - verhindert Doppeleinzüge und doppelte Stornierungen.
+Status:        belegt
+Modul:         M-24
+
+ID:            SyRS-321
+Titel:         Betragsobergrenze je Rechnung im Lastschriftvorschlag
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Backend-Komponente PaymentTransactionBL
+Vorbedingung:  Der Anwender lädt die Liste der lastschriftfähigen Rechnungen.
+Fakt:          PaymentTransactionBL.GetInvoiceList(ExportDirectDebitType, ...) liest die Einstellung AppSettingsConst.PaymentTransactionIncomingPaymentMaximumAmount (ApplicationSettingID-Wert 1125) und filtert bei einem Wert größer 0 über `invoices.Where(f => f.AmountToPay <= maximumValue)`.
+Aussage:       Das System soll Rechnungen, deren einzuziehender Betrag eine konfigurierte Obergrenze überschreitet, nicht in die Lastschriftvorschlagsliste aufnehmen; eine Obergrenze von 0 deaktiviert die Prüfung.
+Ergebnis:      Rechnungen oberhalb der Obergrenze erscheinen nicht in der Exportauswahl und können nicht versehentlich eingezogen werden.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs, Methode GetInvoiceList, Zeilen 97-107: `var maximumValue = (decimal)(settings.GetDecimal(AppSettingsConst.PaymentTransactionIncomingPaymentMaximumAmount) ?? 0); if (maximumValue > 0) { return invoices.Where(f => f.AmountToPay <= maximumValue).ToList(); }` - Begründung: Konkrete durchsetzende Bedingung inklusive Deaktivierungssemantik.
+  - [SEKUNDÄR] src/backend/Centron.BL/Administration/Settings/AppSettingsConst.cs, Zeile 1456: `PaymentTransactionIncomingPaymentMaximumAmount = 1125` - Begründung: Belegt den Konfigurationsschalter.
+Prüfidee:      Obergrenze auf 500 setzen; eine Rechnung über 600 darf in der Vorschlagsliste nicht erscheinen, eine über 500 muss erscheinen.
+Tracelinks:    StRS-306
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - wirksame Schutzgrenze gegen Fehleinzüge hoher Beträge.
+Status:        belegt
+Modul:         M-24
+
+ID:            SyRS-322
+Titel:         Dreistufige Heuristik zur Zuordnung von Bankumsätzen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Backend-Komponente OnlineBankingAccountTransactionsBL
+Vorbedingung:  Bankumsätze sind importiert und der automatische Abgleich wurde angestoßen.
+Fakt:          AutoCompleteSingleAccountTransaciton führt drei Suchschritte aus: (1) SearchReceiptInvoicesByDescription über Rechnungsnummern im Verwendungszweck, (2) falls kein Kunde gefunden SearchCustomerBySenderAndIBAN über die Umsatz-IBAN bzw. den Absendernamen, (3) SearchReceiptInvoicesByCustomerAndAmount über Betragsvergleich. Jeder Treffer wird mit einer Heuristik (MatchedInvoiceNumbers, MatchedIbanNumber, MatchedSenderName, MatchedSingleAmountExactly, MatchedSingleAmountApproximately, MatchedSummedInvoicesAmountExactly, MatchedSummedInvoicesAmountApproximately) und der zugehörigen DefaultMatchingRate versehen; AddSearchResultsToAccountTransaction behält je Beleg nur den Treffer mit der höchsten Rate und sortiert absteigend nach Rate, dann nach Belegdatum.
+Aussage:       Das System soll jedem Bankumsatz Kunde und offene Belege in drei aufeinander aufbauenden Suchschritten zuordnen, jeden Vorschlag mit einer nachvollziehbaren Trefferheuristik und Trefferquote kennzeichnen und je Beleg nur den besten Treffer als Vorschlag führen.
+Ergebnis:      Der Umsatz trägt einen zugeordneten Kunden sowie eine nach Trefferquote und Belegdatum sortierte Vorschlagsliste; bereits verbuchte oder manuell gesetzte Zuordnungen bleiben unverändert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingAccountTransactionsBL.cs, Methode AutoCompleteSingleAccountTransaciton, Zeilen 587-614 mit den Kommentaren "// Search 1: Search for invoice numbers in the description", "// Search 2: Search for related customer by account IBAN or sender", "// Search 3: Search all customer invoices and try to match the amount" - Begründung: Definiert Reihenfolge und Abbruchbedingungen der Heuristik.
+  - [PRIMÄR]   Dieselbe Datei, Methode AddSearchResultsToAccountTransaction, Zeilen 794-820: Erhalt nur von `f.IsBooked || f.ReceiptMatchingHeuristic == OnlineBankingReceiptMatchingHeuristic.ManuallySet`, Deduplizierung über `OrderByDescending(g => g.Value.GetHeuristicInfo().DefaultMatchingRate)` - Begründung: Benennt die Regel, welche Vorschläge überschrieben und welche geschützt werden.
+Prüfidee:      Umsatz mit passendem Absendernamen, aber ohne Rechnungsnummer im Verwendungszweck einspielen; die Zuordnung muss mit der Heuristik MatchedSenderName und nicht MatchedInvoiceNumbers gekennzeichnet sein.
+Tracelinks:    StRS-307
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kern der Automatisierung; Heuristik ist transparent und nachvollziehbar dokumentiert.
+Status:        belegt
+Modul:         M-25
+
+ID:            SyRS-323
+Titel:         Verbuchen und Stornieren von Kontoumsatzzuordnungen mit Belegprotokoll
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Backend-Komponente OnlineBankingAccountTransactionsBL
+Vorbedingung:  Ein Bankumsatz besitzt mindestens eine noch nicht verbuchte Zuordnung zu einer Rechnung oder Gutschrift.
+Fakt:          BookAmountsForAccountTransacitons verarbeitet nur Zuordnungen mit `f.IsBooked == false`; BookAmountToAssignedInvoice erhöht PaidFC um AssignedAmount, setzt isPaid auf true, wenn CloseReceiptAfterBooking gesetzt ist oder `newPaidFC >= assignment.ReceiptDemandedGrossAmount`, protokolliert "Zahlungseingang: Bankauszüge" (bei negativem Betrag ergänzt um " (Chargeback)") und markiert die Zuordnung mit IsBooked, BookedDate und BookedByEmployeeI3D. UndoBookingForAccountTransaciton kehrt dies mit `undoBooking: true` und dem Protokolltext "Annullierung Zahlungseingang: Bankauszüge" um. Negative Beträge dürfen laut Codekommentar eine abgeschlossene Rechnung wieder öffnen.
+Aussage:       Das System soll Umsatzzuordnungen genau einmal verbuchen, den bezahlten Betrag der Rechnung fortschreiben, den Belegabschluss regelbasiert setzen, jede Buchung und Stornierung im Belegprotokoll kenntlich machen und Rücklastschriften als negativen Betrag mit Kennzeichnung "(Chargeback)" zulassen.
+Ergebnis:      Verbuchte Zuordnungen tragen Buchungszeitpunkt und Buchenden und werden bei erneutem Aufruf übersprungen; das Belegprotokoll weist Buchung bzw. Annullierung mit Herkunft "Bankauszüge" aus.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingAccountTransactionsBL.cs, Methode BookAmountsForAccountTransacitons, Zeile 890: `foreach(var assignmentDTO in request.OnlineBankingTransactionAssignments.Where(f => f.IsBooked == false))` - Begründung: Erzwingt die Einmaligkeit der Verbuchung.
+  - [PRIMÄR]   Dieselbe Datei, Methode BookAmountToAssignedInvoice, Zeilen 1048-1084: Zustandsbedingung inkl. Kommentar "// Check for negative amounts is for chargebacks. They can open a closed invoice.", `var isPaid = closeReceipt == true ? true : newPaidFC >= assignment.ReceiptDemandedGrossAmount;` und die Protokolltexte - Begründung: Benennt die konkrete Buchungs- und Abschlussbedingung.
+Prüfidee:      Zuordnung zweimal verbuchen lassen; der bezahlte Betrag der Rechnung darf sich nur einmal erhöhen und nur ein Protokolleintrag entstehen.
+Tracelinks:    StRS-307
+Konsolidierung: Kandidat: SyRS-315 - identische fachliche Wirkung "Zahlungseingang verbuchen" in zweiter Implementierung.
+Übernahmewürdigkeit: übernehmen - abrechnungsrelevante Buchungslogik mit Storno- und Rücklastschriftbehandlung.
+Status:        belegt
+Modul:         M-25
+
+ID:            SyRS-324
+Titel:         Verschlüsselte Ablage von Online-Banking-Zugangsdaten
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Backend-Komponente OnlineBankingConfigurationBL
+Vorbedingung:  Eine Online-Banking-Konfiguration vom Typ FinTS oder finAPI wird gespeichert oder gelesen.
+Fakt:          SaveOnlineBankingConfiguration ruft vor dem Persistieren EncryptOnlineBankingConfigurationFields, GetOnlineBankingConfigurationByI3D und GetOnlineBankingConfigurationsByFilter rufen nach dem Laden DecryptOnlineBankingConfigurationFields. Verschlüsselt werden für FinTS AccountUserId und AccountUserPassword, für finAPI UserAccountPassword, jeweils mit `new AESCryptoLogic().EncryptText(..., securityKey)`. Der Schlüssel stammt aus CentronConfigurationDbBL.GetHotlineMasterKey; fehlt er, bricht der Vorgang mit `Result<string>.AsError("No master key found", DefaultMessageCodes.NoMasterKeyFound)` ab. Beim Entschlüsseln wird die Entität zuvor über `this.Session.GetSession().Evict(configuration)` aus der NHibernate-Session entfernt.
+Aussage:       Das System soll Bankzugangsdaten (Benutzerkennung und Passwort) ausschließlich AES-verschlüsselt speichern, sie erst beim Lesen entschlüsseln und Speicher- wie Lesevorgänge ohne verfügbaren Masterkey verweigern.
+Ergebnis:      In den Tabellen OnlineBankingConfigurationsFinTS und OnlineBankingConfigurationsFinApi stehen ausschließlich Chiffrate; entschlüsselte Werte gelangen durch das Evict nicht zurück in die Datenbank.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingConfigurationBL.cs, Methoden EncryptOnlineBankingConfigurationFields (Zeilen 137-150) und DecryptOnlineBankingConfigurationFields (Zeilen 152-167) sowie GetSecurityKey (Zeilen 122-135) mit dem Abbruch bei fehlendem Schlüssel - Begründung: Benennt die durchsetzenden Stellen, die verschlüsselten Felder und die Abbruchbedingung.
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, Zeilen 45822-45848: Spalten [UserAccountPassword] nvarchar(250) bzw. [AccountUserId]/[AccountUserPassword] nvarchar(250) - Begründung: Belegt die Zielspalten der Verschlüsselung.
+Prüfidee:      FinTS-Konfiguration mit bekanntem Passwort speichern und die Spalte AccountUserPassword direkt in der Datenbank lesen; der Klartext darf dort nicht auftauchen.
+Tracelinks:    StRS-307
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zwingende Schutzmaßnahme für Bankzugangsdaten.
+Status:        belegt
+Modul:         M-25
+
+ID:            SyRS-325
+Titel:         Bereitstellung der finAPI-Mandantenzugangsdaten über die Lizenz
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Backend-Komponente OnlineBankingFinApiBL
+Vorbedingung:  Der Client fordert die finAPI-Client-Credentials an, um eine Verbindung zur finAPI aufzubauen.
+Fakt:          OnlineBankingFinApiBL.GetFinApiClientCredentials liest die Kundennummer aus dem Lizenzdokument (`licenseDoc.SelectSingleNode("//Number")`, wirft bei Fehlen eine Exception) und liefert ClientId, ClientSecret, SandBoxClientId und SandBoxClientSecret nur aus, wenn `isUnitTest || hasFinApiLicense` gilt, wobei hasFinApiLicense über `LicenseManager.Instance.HasLicense(LicenseGuids.OnlineBanking_FinApi)` ermittelt wird. Die vier Credential-Werte sind als Zeichenketten-Literale im Quelltext hinterlegt.
+Aussage:       Das System soll finAPI-Zugangsdaten ausschließlich an Installationen mit gültiger finAPI-Lizenz und ermittelbarer Kundennummer ausliefern.
+Ergebnis:      Ohne finAPI-Lizenz enthält die Antwort nur die Kundennummer und keine Client-Credentials; ohne Kundennummer schlägt der Aufruf fehl.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingFinApiBL.cs, Methode GetFinApiClientCredentials, Zeilen 41-47: `if(isUnitTest || hasFinApiLicense) { dto.ClientId = "8e5597be-..."; dto.ClientSecret = "792cbc52-..."; ... }` - Begründung: Benennt die durchsetzende Bedingung und belegt zugleich die Hinterlegung der Geheimnisse als Quelltextkonstanten.
+  - [PRIMÄR]   Dieselbe Datei, Methode GetCompanyNumberFromLicenseFile, Zeilen 59-62: `if (companyNumber is null) throw new Exception("Unable to find the company number in the license file");` - Begründung: Zweite durchsetzende Prüfung vor Auslieferung.
+Prüfidee:      Aufruf ohne finAPI-Lizenz absetzen; das Ergebnis darf keine ClientId und kein ClientSecret enthalten.
+Tracelinks:    StRS-307
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - die Lizenzbindung greift, die Geheimnisse liegen jedoch im Klartext im Quellcode und sind bei Auslieferung des Assemblys extrahierbar; für die Neuentwicklung ist eine serverseitige Secret-Verwaltung mit Rotationsfähigkeit vorzusehen.
+Status:        belegt
+Modul:         M-25
+
+ID:            SyRS-326
+Titel:         Statuswechsel des SEPA-Mandats und Autorisierung der Bankverbindung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Backend-Komponente SepaContractOnlinePdfDocumentHandler
+Vorbedingung:  Ein SEPA-Mandat wurde dem Kunden zur Online-Bestätigung zugestellt.
+Fakt:          Confirm setzt `contract.State = SepaContractState.Accepted`, legt das signierte PDF im Kundenverzeichnis (DirectoryReferenceKind.SepaContractDir) ab, entfernt das Word-Dokument (`contract.WordDocument = null;`) und setzt an der Bankverbindung ValidFrom und AuthorizationDate auf DateTime.Today. Decline setzt State = Declined, SetExpired setzt State = LinkExpired. In allen Fällen werden ChangedBy und ChangedDate fortgeschrieben. Bei `contract.TestMode` wird der Vertrag nach Versand der Mails gelöscht.
+Aussage:       Das System soll den Mandatsstatus bei Bestätigung, Ablehnung und Linkablauf eindeutig fortschreiben, das signierte Mandat als PDF im Kundendokumentenverzeichnis ablegen und die zugehörige Bankverbindung mit dem Bestätigungstag als Autorisierungs- und Gültigkeitsbeginn versehen.
+Ergebnis:      Ein bestätigtes Mandat liegt als PDF vor, der Vertrag hat Status Accepted, die Bankverbindung ist ab dem Bestätigungstag autorisiert und damit SEPA-exportfähig; Testmandate hinterlassen keine Datenspur.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Documents/Dsgvo/SepaContractOnlinePdfDocumentHandler.cs, Methode Confirm, Zeilen 124-153: `contract.State = SepaContractState.Accepted;` und `b.ValidFrom = DateTime.Today; b.AuthorizationDate = DateTime.Today;` - Begründung: Benennt die durchsetzenden Zuweisungen, die das Mandat exportfähig machen.
+  - [PRIMÄR]   Dieselbe Datei, Methoden Decline (Zeile 201: `contract.State = SepaContractState.Declined;`) und SetExpired (Zeile 218: `contract.State = SepaContractState.LinkExpired;`) - Begründung: Belegen die vollständige Zustandsfortschreibung.
+  - [SEKUNDÄR] Dieselbe Datei, Zeilen 194-198 und 114-119: Löschung des Vertrags bei `contract.TestMode` - Begründung: Belegt die Sonderbehandlung von Testmandaten.
+Prüfidee:      Mandat online bestätigen; die verknüpfte Bankverbindung muss danach AuthorizationDate = heutiges Datum tragen und die SEPA-Exportvalidierung (SyRS-319) passieren.
+Tracelinks:    StRS-308
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - verbindet Mandatserteilung und Lastschriftfähigkeit revisionsfest.
+Status:        belegt
+Modul:         M-26
+
+ID:            SyRS-327
+Titel:         Kostenstellen und Kostenträger werden nur logisch gelöscht
+Ebene:         SyRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Modul Kostenträger / Kostenstellen
+Vorbedingung:  Der Anwender wählt eine oder mehrere Kostenstellen bzw. Kostenträger aus und löst Löschen oder Wiederherstellen aus.
+Fakt:          PayersAndCostCenterAppModuleControllerViewModel.DoCostCenterDelete setzt nach Bestätigung `this.SelectedCostCenterItems.ForEach(x => x.State = 0);` und speichert; CostCenterRestoreAsync setzt `x.State = 1;`. LoadCostCentersAsync filtert ohne "gelöschte anzeigen" mit `filter.State = 1`. Es existiert kein Aufruf einer Delete-Operation auf CostCenter oder CostObject.
+Aussage:       Das System soll Kostenstellen und Kostenträger ausschließlich über den Status logisch löschen (Status 0) und wiederherstellen (Status 1) und in der Standardansicht nur aktive Einträge anzeigen.
+Ergebnis:      Gelöschte Kostenstellen bleiben in der Datenbank erhalten, verschwinden aber aus der Standardliste und bleiben für historische Belegkontierungen auflösbar.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter/PayersAndCostCenterAppModuleControllerViewModel.cs, Methode DoCostCenterDelete, Zeile 146: `this.SelectedCostCenterItems.ForEach(x => x.State = 0);` und CostCenterRestoreAsync, Zeile 188: `this.SelectedCostCenterItems.ForEach(x => x.State = 1);` - Begründung: Konkrete durchsetzende Zuweisungen ohne physische Löschung.
+  - [PRIMÄR]   src/backend/Centron.BL/Warehousing/CostCenterBL.cs, CreateCostCenterExpression: `if (filter.State != null) expression = expression.And(x => x.State == filter.State);` - Begründung: Belegt die serverseitige Auswertung des Statusfilters.
+Prüfidee:      Kostenstelle löschen und danach über "gelöschte anzeigen" laden; der Datensatz muss mit Status 0 weiterhin vorhanden sein.
+Tracelinks:    StRS-309
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - erhält die Referenzierbarkeit historischer Kontierungen.
+Status:        belegt
+Modul:         M-27

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_work/A4_StRS.md

@@ -0,0 +1,184 @@
+ID:            StRS-401
+Titel:         Ticketliste als zentrale Arbeitsliste des Supports
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Supportmitarbeiter (c-entron-Benutzer)
+Vorbedingung:  Benutzer ist am c-entron-Client angemeldet und besitzt das Recht "Helpdesk anzeigen".
+Fakt:          `TicketListAppModuleController` registriert das Modul mit `ModuleName => LocalizedStrings.TicketListAppModuleController_TicketListe` und `MainCategory => CentronModuleCategory.Ticket`; `TicketListViewModel` kennt die Arbeitsmodi `TicketListTicketMode { None, All, OnlyOwn, Customers }` und setzt beim Start `this.CurrentMode = this.UISettings.StartupMode ?? TicketListTicketMode.OnlyOwn`.
+Aussage:       Das System soll dem Supportmitarbeiter eine Ticketliste bereitstellen, in der er wahlweise nur die ihm zugeordneten Tickets, die Tickets ausgewählter Kunden oder alle für ihn sichtbaren Tickets bearbeiten kann, und beim Öffnen standardmäßig die eigenen Tickets anzeigen.
+Ergebnis:      Der Mitarbeiter sieht nach dem Öffnen des Moduls seine eigenen offenen Tickets und kann den Modus ohne Modulwechsel umschalten.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketList/Module/TicketListAppModuleController.cs, Zeilen 26-44 (`ModuleName`, `CreateModuleInstance`, `if (CentronCache.Instance.EmployeePreallocationSettings.LoadOwnTickets) viewModel...CurrentMode = TicketListTicketMode.OnlyOwn`) - Begründung: Die Modulregistrierung und die Modusvorbelegung sind im Code durchgesetzt.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketList/TicketListViewModel.cs, Zeilen 552-557 und 1185-1191 (`enum TicketListTicketMode`) - Begründung: Die drei fachlichen Arbeitsmodi sind als Aufzählung im Code definiert.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketList/TicketListView.xaml, Zeilen 551-600 (Spaltenüberschriften "Erstellt am", "Nummer", "Status", "Priorität") - Begründung: UI-Labels belegen den fachlichen Informationsumfang der Liste.
+Prüfidee:      Modul "Ticketliste" mit einem Benutzer öffnen, dessen Voreinstellung `LoadOwnTickets` gesetzt ist; die Liste muss ausschließlich Tickets enthalten, in denen der Benutzer Bearbeiter oder Verantwortlicher ist. Umschalten auf "Kunden" muss die Kundenauswahl erzwingen.
+Tracelinks:    SyRS-411, SyRS-412, SyRS-413, SwRS-430, SwRS-431
+Konsolidierung: Kandidat: StRS-401 / SwRS-430 gegen src/nexus/CentronNexus/ServiceBoard/CachedTicketList und .../TicketList - dieselbe fachliche Ticketliste ist zusätzlich in Blazor implementiert
+Übernahmewürdigkeit: übernehmen - zentrale Arbeitsoberfläche des Helpdesks, ohne Alternative im System.
+Status:        belegt
+Modul:         M-28
+
+ID:            StRS-402
+Titel:         Lückenlose Nachvollziehbarkeit der Ticketbearbeitung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Supportmitarbeiter
+Vorbedingung:  Ein Ticket (hlpdsk_requests) existiert und wird bearbeitet.
+Fakt:          `HelpdeskBL.DoAfterStoreTrans` erzeugt bei Neuanlage `new HelpdeskHistoryBL(this.Session).CreateHistoryForActionType(currentUser.User, HelpdeskHistoryType.Create, entity.I3D)`; `HelpdeskBL.SetHelpdeskAction` schreibt bei jeder Änderung von Fälligkeitsdatum oder Status einen Historieneintrag ("Fälligkeitsdatum wurde geändert", "Status wurde geändert"); `HelpdeskCloseBL.CloseHelpdesk` schreibt zusätzlich `HelpdeskHistoryType.Close`.
+Aussage:       Das System soll jede fachlich relevante Zustandsänderung eines Tickets (Anlage, Statuswechsel, Fälligkeitsänderung, Weiterleitung, Abschluss) automatisch und unveränderbar in der Ticket-Historie protokollieren.
+Ergebnis:      Zu jedem Ticket ist ohne Zusatzaufwand rekonstruierbar, wer wann welchen Zustand geändert hat.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, Methode `SetHelpdeskAction`, Zeilen 558-608 (`historyBL.SaveHelpdeskAction(user.User, "Fälligkeitsdatum wurde geändert", ...)`, `"Status wurde geändert"`) - Begründung: Die Protokollierung ist im Speicherpfad zwingend eingebaut, nicht optional.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, Methode `DoAfterStoreTrans`, Zeilen 611-633 (`CreateHistoryForActionType(currentUser.User, HelpdeskHistoryType.Create, entity.I3D)`) - Begründung: Anlage-Historie wird transaktional nach dem Speichern erzeugt.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Helpdesk/Settings/Logging/HelpdeskLoggingSettingsViewModel.cs, Zeilen 67-70 (`TicketLogDueDateChanges`, `TicketLogStatusChanges`, `TicketLogPriorityChanges`, `TicketLogEditorChanges`) - Begründung: Konfigurationsschalter "Folgende Änderungen in Historie eintragen" belegt den fachlichen Zweck.
+Prüfidee:      Status eines Tickets ändern und speichern; die Ticket-Historie muss genau einen neuen Eintrag mit altem und neuem Statusnamen enthalten.
+Tracelinks:    SyRS-414, SyRS-415, SwRS-434, SwRS-435
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Nachweispflicht gegenüber Kunden und Grundlage für Abrechnungsdiskussionen.
+Status:        belegt
+Modul:         M-29
+
+ID:            StRS-403
+Titel:         Betreiberseitige Pflege der Ticket-Stammdaten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Systemadministrator / Helpdesk-Leitung
+Vorbedingung:  Der Einstellungsbereich "Ticket" ist geöffnet.
+Fakt:          `ModuleRegistration.GetSettingsWithoutModule()` registriert `HelpdeskStatusSettingsController`, `HelpdeskPrioritySettingsController`, `HelpdeskCategoriesSettingsController` und `HelpdeskTypeSettingsController`; die zugehörigen Entitäten liegen in den Tabellen `hlpdsk_status`, `hlpdsk_prioritaeten`, `hlpdsk_kategorien` und `hlpdsk_typen`.
+Aussage:       Das System soll Status, Prioritäten, Kategorien und Typen von Tickets ohne Programmänderung pflegbar machen, damit der Betreiber seinen Supportprozess selbst abbilden kann.
+Ergebnis:      Neue Statuswerte, Prioritäten, Kategorien und Typen stehen unmittelbar in Ticketliste und Ticketdetails zur Auswahl.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Methode `GetSettingsWithoutModule`, Zeilen 267-282 (Registrierung der vier Stammdaten-Settingcontroller) - Begründung: Die Pflegemasken sind fest im Anwendungsstart registriert.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, Zeilen 4124-4139 (`CREATE TABLE [dbo].[hlpdsk_typen]`), 4298-4313 (`hlpdsk_kategorien`), 4485-4514 (`hlpdsk_prioritaeten`), 4628-4643 (`hlpdsk_status`) - Begründung: Eigene Stammdatentabellen belegen die Pflegbarkeit als Daten statt als Code.
+Prüfidee:      Neuen Status anlegen, speichern, Ticketdetails öffnen: der neue Status muss ohne Neustart der Anwendung in der Statusauswahl erscheinen.
+Tracelinks:    SyRS-420, SwRS-436, SwRS-437, SwRS-438
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Mandantenspezifische Prozessabbildung ist Kernanforderung eines ERP-Helpdesks.
+Status:        belegt
+Modul:         M-30
+
+ID:            StRS-404
+Titel:         Ticketzeiten als Grundlage der Leistungsabrechnung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Supportmitarbeiter, Fakturierung
+Vorbedingung:  Ein Ticket mit zugeordnetem Kunden existiert.
+Fakt:          `HelpdeskTimer` besitzt die Eigenschaft `Calculable` (Spalte `Berechenbar`) sowie die Belegzuordnungen `OrderAssetItemI3D` (`AufPosI3D`), `DeliveryListAssetItemI3D` (`LiefPosI3D`) und `InvoiceAssetItemI3D` (`RechPosI3D`); `HelpdeskTimerWebServiceBL.GetNewTimer` setzt `Calculable = settings.TimeRecordingSetCalculable`.
+Aussage:       Das System soll zu jedem Ticket Arbeitszeiten mit Kennzeichen "berechenbar" erfassen und diese Zeiten in Auftrag, Lieferschein und Rechnung weiterverarbeitbar machen.
+Ergebnis:      Erfasste Ticketzeiten sind eindeutig als abrechenbar oder nicht abrechenbar gekennzeichnet und über die Belegzuordnung bis zur Rechnung verfolgbar.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.DAO/Mappings/Sales/Support/HelpdeskTimerArea/HelpdeskTimerMaps.cs, Zeilen 11-34 (`this.Table("hlpdsk_timer")`, `Map(map => map.Calculable).Column("Berechenbar")`, `Column("LiefPosI3D")`, `Column("RechPosI3D")`, `Column("AufPosI3D")`) - Begründung: Die Abrechnungsverknüpfung ist im persistenten Datenmodell verankert.
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/Support/HelpdeskTimerWebServiceBL.cs, Methode `GetNewTimer`, Zeilen 40-53 (`Calculable = settings.TimeRecordingSetCalculable`) - Begründung: Die Voreinstellung der Abrechenbarkeit ist konfigurationsgesteuert im Code umgesetzt.
+Prüfidee:      Zeit auf einem Ticket erfassen, in einen Lieferschein übernehmen und prüfen, dass `LiefPosI3D` der Zeit gefüllt ist und die Zeit auf dem Beleg mit dem erfassten Umfang erscheint.
+Tracelinks:    SyRS-421, SyRS-422, SwRS-439
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - direkter Umsatzbezug, ohne Ersatz im System.
+Status:        belegt
+Modul:         M-31
+
+ID:            StRS-405
+Titel:         Standardisierte Ticketabläufe über Prozessvorlagen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Helpdesk-Leitung, Supportmitarbeiter
+Vorbedingung:  Mindestens eine Prozessvorlage ist im Vorlagenbaum hinterlegt.
+Fakt:          `TicketProcessTemplateViewModel` stellt Kommandos `NewRootFolderCommand`, `NewFolderCommand`, `NewTemplateCommand`, `CopyTemplateCommand`, `RenameTemplateCommand`, `DeleteTemplateCommand` bereit; `TicketDetailViewModel.AddProcess()` erzeugt aus der ausgewählten Vorlage einen ticketgebundenen Prozess (`new TicketProcessDTO { HelpdeskI3D = this.Helpdesk.I3D, Name = template.Name, Bindings = template.Bindings, Steps = template.Steps }`).
+Aussage:       Das System soll wiederkehrende Supportabläufe als benannte, in Ordnern organisierte Prozessvorlagen verwalten und diese Vorlagen auf ein einzelnes Ticket anwendbar machen.
+Ergebnis:      Der Bearbeiter arbeitet ein Ticket entlang der aus der Vorlage übernommenen Schrittfolge ab; Schritte und Verbindungen werden am Ticket gespeichert.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketDetails/TicketDetailViewModel.cs, Methode `AddProcess`, Zeilen 3906-3927 (Übernahme von `Name`, `Bindings`, `Steps` aus `viewModel.SelectedProcess.Clone()`) - Begründung: Die Übernahme der Vorlage in das Ticket ist im Code durchgesetzt.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Support/TicketProcess/TicketProcessBL.cs, Methoden `SaveTicketProcess` und `SaveTemplate`, Zeilen 26-37 und 80-91 (`CentronObjectKindNumeric.HelpdeskClass` bzw. `CentronObjectKindNumeric.TicketProcessTemplateFolder`) - Begründung: Vorlage und Ticketprozess werden über dieselbe Prozessablage, aber mit unterschiedlichem Objektbezug persistiert.
+Prüfidee:      Vorlage mit drei Schritten anlegen, auf ein Ticket anwenden, Ticket speichern und erneut öffnen: die drei Schritte müssen unverändert am Ticket vorhanden sein.
+Tracelinks:    SwRS-441, SwRS-442
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - sichert gleichbleibende Servicequalität bei wiederkehrenden Fällen.
+Status:        belegt
+Modul:         M-32
+
+ID:            StRS-406
+Titel:         Automatische Ticketerzeugung aus Belegen mittels Vorlagen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Auftragsbearbeiter
+Vorbedingung:  Ein Beleg (Auftrag/Bestellung) mit Positionen liegt vor; mindestens eine Erstellungsvorlage existiert.
+Fakt:          `HelpdeskCreationTemplateBL` verwaltet `HelpdeskCreationTemplate`-Datensätze mit `IsStandard`; `CreateTicketsViewModel` lädt Vorlagenwerte (`CreateSeparateTicketsMode = (CreateTicketsMode)template.CreateSeparateTicketsMode; if (template.CreateTicketForAll) SelectAllTickets();`) und erzeugt daraus Tickets zu Belegpositionen; `CreateTicketsMode { Single, Group, Custom }`.
+Aussage:       Das System soll aus Belegpositionen Tickets erzeugen können, wobei eine gespeicherte Vorlage vorgibt, ob je Position ein Ticket, ein gruppiertes Ticket oder eine benutzerdefinierte Gruppierung entsteht und für welche Positionen Tickets angelegt werden.
+Ergebnis:      Der Anwender erhält eine vorbelegte Ticketvorschau gemäß Vorlage und erzeugt die Tickets in einem Schritt.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Finances/Receipts/CreateTickets/CreateTicketsViewModel.cs, Zeilen 109-131 und 192-226 (`OnChanged(nameof(this.CreateSeparateTicketsMode), ...)`, `ApplyTemplate`-Zuweisungen) - Begründung: Die Vorlagenanwendung und die Gruppierungslogik sind im Code durchgesetzt.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Finances/Receipts/CreateTickets/CreateTicketsMode.cs (`enum CreateTicketsMode { Single, Group, Custom }`) - Begründung: Die drei fachlichen Erzeugungsmodi sind als Aufzählung festgelegt.
+  - [KONTEXT]  docs/features/automatic-helpdesk-creation-templates.md, Abschnitt "Overview" und "Features" ("Standard Template: Designate one template as the standard (only one at a time)") - Begründung: Feature-Dokumentation beschreibt Zweck und Umfang, ist aber keine durchsetzende Stelle.
+Prüfidee:      Vorlage mit Modus "Group" und "CreateTicketForAll" speichern, Beleg mit vier Positionen öffnen, Ticketerzeugung starten: es müssen genau die gruppierten Tickets vorbelegt und alle Positionen markiert sein.
+Tracelinks:    SwRS-443
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - reduziert manuelle Erfassung bei Projekt- und Serienaufträgen.
+Status:        belegt
+Modul:         M-33
+
+ID:            StRS-407
+Titel:         E-Mail-Kommunikation als Teil des Ticketvorgangs
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Supportmitarbeiter, Kunde
+Vorbedingung:  Für das Ticket sind Ansprechpartner und E-Mail-Vorlagen konfiguriert.
+Fakt:          `HelpdeskMailBL` liefert je Geschäftsvorfall eigene Betreff- und Textbausteine (`GetNewHelpdeskEmailSubject`, `GetHelpdeskForwardingInternalSubject`, `GetHelpdeskEmailToCustomerSubject`, `GetHelpdeskClosingExternalEmailSubject`) über `MailTemplateReferences.Helpdesk.*`; `GenerateHelpdeskHistory` legt zu beantworteten Mails einen Historieneintrag an.
+Aussage:       Das System soll den E-Mail-Verkehr zu einem Ticket (Neuanlage, Weiterleitung, Kundenantwort, Abschlussmitteilung) aus zentral gepflegten Vorlagen erzeugen und jede versendete Nachricht in der Ticket-Historie festhalten.
+Ergebnis:      Alle Ticketmails sind einheitlich formuliert und am Ticket dokumentiert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Support/HelpdeskMailBL.cs, Methode `GenerateHelpdeskHistory`, Zeilen 40-74 (Erzeugung eines Historieneintrags mit Empfängerliste, Betreff und Klartext des Mailtextes) - Begründung: Die Archivierung im Ticket ist im Code durchgesetzt.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Support/HelpdeskMailBL.cs, Zeilen 78-290 (je Ereignis eigene `GetSubject`/`GetBody`-Aufrufe mit `MailTemplateReferences.Helpdesk.ClosingInternal`, `...ClosingExternal`, `...ForwardingInternal`) - Begründung: Vorlagenbezug je Ereignis ist fest verdrahtet.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketDetails/TicketDetailViewModel.cs, Methode `SendNewTicketNotificationBySettings`, Zeilen 2902-2946 (`this.Settings.NewHelpdeskMessageGeneralReceiver.Split(";")`, anschließend `ArchiveHelpdeskMail`) - Begründung: Konfigurationseintrag für Benachrichtigungsempfänger belegt den fachlichen Ablauf.
+Prüfidee:      Ticket abschließen mit externer Benachrichtigung: Betreff und Text müssen aus der Vorlage `Helpdesk.ClosingExternal` stammen und ein Historieneintrag mit Empfängeradresse muss existieren.
+Tracelinks:    SyRS-423, SwRS-444
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Standardkommunikationsweg im Support.
+Status:        belegt
+Modul:         M-34
+
+ID:            StRS-408
+Titel:         Kundenzugang zum Helpdesk mit optionaler Freigabe
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Kunde (WebAccount), Supportmitarbeiter
+Vorbedingung:  Für den Kunden ist der Ticketzugang im Service-Board freigeschaltet.
+Fakt:          Die Einstellung `TicketWebAccountTicketsHaveToBeAuthorized` (AppSettingsConst 1606) wird über `HelpdeskCustomerAccessSettingsViewModel` gepflegt und über `AccountBL` als `CustomerApprovalEnabledSBO` bereitgestellt; `HelpdeskBL.DoBeforeStoreTrans` setzt bei aktivierter Freigabepflicht `entity.HelpdeskState = null`.
+Aussage:       Das System soll Kunden das Erfassen und Einsehen eigener Tickets über den Weblogin ermöglichen und dabei betreiberseitig festlegen lassen, ob kundenseitig erzeugte Tickets vor der Bearbeitung durch einen Mitarbeiter freigegeben werden müssen.
+Ergebnis:      Ohne Freigabepflicht erhält das Kundenticket den konfigurierten Eröffnungsstatus; mit Freigabepflicht bleibt es ohne Status und damit außerhalb der regulären Ticketliste.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, Methode `DoBeforeStoreTrans`, Zeilen 522-539 (`if (settingsForCustomer.CustomerApprovalEnabledSBO) { entity.HelpdeskState = null; } else { ... HelpdeskAfterOpenDefaultState }`) - Begründung: Die Freigabepflicht wird beim Speichern des Kundentickets serverseitig erzwungen.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Helpdesk/Settings/CustomerAccess/HelpdeskCustomerAccessSettingsViewModel.cs, Zeilen 39-64 (`settings.TicketWebAccountTicketsHaveToBeAuthorized`) - Begründung: Der Konfigurationsschalter ist die einzige Pflegestelle dieses Verhaltens.
+  - [SEKUNDÄR] src/backend/Centron.BL/Administration/Settings/AppSettingsConst.cs, Zeile 2210 (`TicketWebAccountTicketsHaveToBeAuthorized = 1606`) - Begründung: Konfigurations-ID belegt die Persistenz der Einstellung.
+Prüfidee:      Freigabepflicht aktivieren, über einen WebAccount ein Ticket anlegen: der Datensatz in `hlpdsk_requests` muss `Status IS NULL` haben und darf in der Standard-Ticketliste des Mitarbeiters nicht erscheinen.
+Tracelinks:    SyRS-424, SyRS-425
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Selbstbedienung entlastet den Support und ist vertraglich zugesagt.
+Status:        belegt
+Modul:         M-35
+
+ID:            StRS-409
+Titel:         Kennzahlenüberblick über das Ticketaufkommen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Helpdesk-Leitung
+Vorbedingung:  Der Benutzer besitzt das Recht "Ticketstatistik".
+Fakt:          `TicketDashboardContainerController.GetDashboardTile` liefert je `TicketDashboardContainerKinds`-Wert (`TicketRecordedTime`, `Helpdesk`, `Status`, `Dates`, `DueDate`, `Priority`, `Types`) eine eigene Dashboard-Kachel; `SaleStatisticBL.GetTicketStatisticOverview` ermittelt `CreatedToday` und `ClosedToday` per SQL auf `hlpdsk_requests`.
+Aussage:       Das System soll die Ticketlage nach erfasster Zeit, Status, Erfassungsdatum, Fälligkeit, Priorität und Typ als Dashboard-Kacheln darstellen und die heute erzeugten sowie heute abgeschlossenen Tickets ausweisen.
+Ergebnis:      Die Leitung erkennt Rückstände und Auslastung ohne manuelle Auswertung.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Helpdesk/Dashboard/TicketDashboardContainerController.cs, Zeilen 18-40 (`switch (containerKind)` mit sieben Kachel-ViewModels) - Begründung: Der Kachelumfang ist im Code abschließend festgelegt.
+  - [PRIMÄR]   src/backend/Centron.BL/Statistics/SaleStatistics/SaleStatisticBL.cs, Methode `GetTicketStatisticOverview`, Zeilen 376-398 (`SELECT COUNT(*) FROM hlpdsk_requests WHERE CONVERT(DATE, ErfasstAm) = CONVERT(Date, GETDATE())` und Abschlusszählung über `Stammdat` I3D 696) - Begründung: Die Kennzahlberechnung ist als SQL-Anweisung belegt.
+Prüfidee:      Ein Ticket anlegen und ein anderes abschließen; die Kennzahlen "heute erstellt"/"heute abgeschlossen" müssen sich jeweils um 1 erhöhen.
+Tracelinks:    SyRS-426, SwRS-445
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Steuerungsinstrument für die Supportleitung.
+Status:        belegt
+Modul:         M-36

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_work/A5_StRS.md

@@ -0,0 +1,230 @@
+ID:            StRS-501
+Titel:         Zugriffssteuerung über Rechtegruppen statt Einzelrechte
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Administrator (Rechteverwaltung)
+Vorbedingung:  Mitarbeiter besitzt einen Benutzer (AppUser) im System.
+Fakt:          Rechte werden nie direkt an Benutzer vergeben. `AppRightsBL.GetRightsFromCurrentUser` iteriert ausschließlich über `user.Groups` und sammelt `group.Rights`; die durchsetzende Abfrage `AppRightsBL.GetAllAppRightsFromUser` verknüpft `dbo.Sichtrus st` (Gruppe→Recht) mit `dbo.Sichmemb sm` (Gruppe→Benutzer) über `sm.Benutzer = :UserI3D`. Ein direkter Bezug Benutzer→Recht existiert im Schema nicht (`Sichrech` hat keine Benutzerspalte).
+Aussage:       Das System soll Berechtigungen ausschließlich über die Mitgliedschaft eines Benutzers in Rechtegruppen bestimmen und keine direkte Benutzer-Recht-Zuordnung zulassen.
+Ergebnis:      Die effektive Rechtemenge eines Benutzers ist die Vereinigungsmenge der Rechte aller Gruppen, in denen er Mitglied ist.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, `GetAllAppRightsFromUser(int appUserI3D)`, SQL `SELECT st.Recht AS ID FROM dbo.Sichtrus st INNER JOIN dbo.Sichmemb sm ON sm.Gruppe = st.Gruppe WHERE sm.Benutzer = :UserI3D` - Begründung: Dies ist die tatsächlich durchsetzende Ermittlung der Rechtemenge; sie kennt nur den Weg über die Gruppe.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[Sichtrus]([I3D],[Gruppe],[Recht])` und `CREATE TABLE [dbo].[Sichmemb]([I3D],[Gruppe],[Benutzer])` - Begründung: Das Datenmodell erzwingt die Zwischenstufe Gruppe; es gibt keine Tabelle Benutzer→Recht.
+  - [KONTEXT]  docs/guides/development/check-userrights.md, Abschnitt "Rights and groups can be managed in the `Rechteverwaltung` module." - Begründung: Bestätigt die fachliche Absicht, widerlegt sie aber nicht selbst.
+Prüfidee:      Einem Benutzer wird über SQL ein Recht ohne Gruppenmitgliedschaft "zugewiesen" (nicht möglich, da keine Spalte existiert); alternativ: Entfernen des Benutzers aus allen Gruppen führt dazu, dass `HasUserRight` für jedes Recht `false` liefert.
+Tracelinks:    SyRS-512, SyRS-513, SwRS-523, SwRS-524
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Gruppenbasierte Rechtevergabe ist etabliert und für die Zielarchitektur (RBAC) unmittelbar tragfähig.
+Status:        belegt
+Modul:         M-37
+
+ID:            StRS-502
+Titel:         Lückenlose Nachvollziehbarkeit von Rechte- und Gruppenänderungen
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Administrator (Rechteverwaltung), Revision
+Vorbedingung:  Ein Benutzer mit Recht `UserRightsManagement.ID` (10530) ändert Rechte- oder Gruppenzuordnungen.
+Fakt:          Jede verändernde Operation in `AppRightsBL` schreibt einen Protokolleintrag über `WriteBaseLog(...)` in die Entität `AppRightLog` (Tabelle `SichProtokoll`) mit `CreatedByI3D`, `CreatedDate`, `CreatedVersion` (Assembly-Version), `Kind` und deutschsprachiger `Description`. Betroffen sind `AddRightToRightGroup`, `RemoveRightFromRightGroup`, `AddUserToRightGroup`, `RemoveUserFromRightGroup`, `SaveRightGroup` (nur bei Neuanlage), `DeleteRightGroup` und `CopyRightGroup`.
+Aussage:       Das System soll jede Änderung an Rechtezuordnungen, Gruppenmitgliedschaften und Gruppenbestand revisionssicher mit auslösendem Benutzer, Zeitpunkt und Programmversion protokollieren.
+Ergebnis:      Zu jeder Rechteänderung existiert ein Eintrag in `SichProtokoll`, der Wer/Wann/Was beantwortet.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, `WriteBaseLog(AppRightLogKind kind, string objectText, string description, AppUser appUser, bool flushChanges)` - Begründung: Erzeugt und speichert den `AppRightLog` mit `CreatedByI3D = appUser.Employee.I3D` und `CreatedVersion = AssemblyLogic.GetFromAssemblyContaining<AppRightsBL>()`; wird von allen sieben verändernden Methoden aufgerufen.
+  - [PRIMÄR]   src/backend/Centron.DAO/Mappings/AppRightLogMaps.cs, `this.Table("SichProtokoll")` - Begründung: Bindet das Protokoll an die persistente Tabelle.
+  - [SEKUNDÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, `WriteAddRightToGroupLog`: `$"Recht \"{objectText}\" an die Gruppe \"{groupName}\" vergeben"` - Begründung: Fachlicher Wortlaut des Protokolltextes.
+Prüfidee:      Recht an Gruppe vergeben und wieder entziehen; anschließend müssen genau zwei neue Zeilen in `SichProtokoll` mit `Art` = 2 bzw. 3 und `ErstelltVonI3D` = ausführender Mitarbeiter vorliegen.
+Tracelinks:    SyRS-516, SwRS-525, SwRS-526
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Auditierbarkeit von Berechtigungsänderungen ist regulatorisch und sicherheitstechnisch zwingend.
+Status:        belegt
+Modul:         M-37
+
+ID:            StRS-503
+Titel:         Checklisten als standardisierte Arbeitsanweisung für Serviceprozesse
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Servicetechniker, Serviceleitung
+Vorbedingung:  Es existiert eine Checklistenvorlage (`CentronChecklist.IsTemplate = true`).
+Fakt:          `CentronChecklist` trägt `ObjectKind` (`CentronObjectKindNumeric`), `ObjectI3D`, `IsTemplate`, `IsActive` und eine hierarchische Punktestruktur `CentronChecklistItem` mit `ParentChecklistItemI3D`, `OrderNumber` und `State` (`CentronChecklistItemState`). `CentronChecklistBL.ObjectHasOpenChecklists(objectKind, objectI3D)` liefert, ob zu einem Objekt noch offene Blattpunkte existieren.
+Aussage:       Das System soll wiederverwendbare Checklistenvorlagen bereitstellen, aus denen für konkrete Objekte (insbesondere Tickets) Arbeitsschritte instanziiert und deren Abarbeitungsstand geprüft werden kann.
+Ergebnis:      Für jedes bearbeitete Objekt ist maschinell feststellbar, ob alle Checklistenpunkte abgearbeitet sind.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/CheckListArea/CentronChecklistBL.cs, `ObjectHasOpenChecklists(CentronObjectKindNumeric objectKind, int objectI3D)`: `checklist.CheckListItems.Flatten(f => f.ChecklistItems).Any(f => f.ChecklistItems?.Any() is false && f.State == CentronChecklistItemState.Open)` - Begründung: Durchgesetzte Regel, dass nur Blattpunkte (ohne Kinder) den Offen-Status bestimmen.
+  - [PRIMÄR]   src/backend/Centron.BL/CheckListArea/CentronChecklistBL.cs, `CreateChecklistFilterExpression`, Filterzweige `filter.IsTemplate`, `filter.ObjectKind`, `filter.ObjektI3D`, `filter.IsActive` - Begründung: Belegt die Trennung Vorlage/Instanz und die Objektbindung.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Helpdesk/CentronChecklist/CentronChecklistAppModuleController.cs, `ModuleName => "Checklisten"`, `Description => "Erstellen und Verwalten von Checklisten"` - Begründung: Fachliche Modulbenennung in der Oberfläche.
+Prüfidee:      Vorlage mit zwei Punkten anlegen, auf ein Ticket anwenden, einen Punkt schließen: `ObjectHasOpenChecklists` liefert weiterhin `true`, nach Schließen des zweiten `false`.
+Tracelinks:    SyRS-517, SwRS-530, SwRS-531, SwRS-532
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Standardisierte Abarbeitung ist Kernfunktion des Servicebetriebs.
+Status:        belegt
+Modul:         M-38
+
+ID:            StRS-504
+Titel:         Überwachung erwarteter wiederkehrender Kundenereignisse
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Serviceleitung, MSP-Betrieb
+Vorbedingung:  Zu einem Kunden (`AccountI3D`) ist mindestens ein erwartetes Ereignis mit `IsActive = 1` hinterlegt.
+Fakt:          Die Entität `ExpectedEvents` definiert je Wochentag ein Zeitfenster (`ExecuteMondayFrom`/`ExecuteMondayTo` … `ExecuteSundayFrom`/`ExecuteSundayTo`), eine erwartete Eingangsanzahl (`ExpectedIncomeMonday` … `ExpectedIncomeSunday`), einen Auslösertyp `EventTriggerKind` (Enum enthält nur `Email = 0`) sowie Textmuster `MessageContainsSuccess`/`MessageContainsWarning`/`MessageContainsError`. Eingetretene Ereignisse werden in `ExpectedEventLogEntries` mit `EventType` (`ExpectedEventType`), `EventDate`, `HelpdeskI3D`, `MailID` und optional der Quelldatei protokolliert.
+Aussage:       Das System soll je Kunde erwartete, regelmäßig eintreffende Ereignisse (aktuell per E-Mail) mit wochentagsabhängigem Zeitfenster und Erwartungsmenge definieren und deren tatsächliches Eintreten protokollieren.
+Ergebnis:      Ausbleibende oder fehlerhafte Ereignisse sind gegen die hinterlegte Erwartung feststellbar.
+Belege:
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[ExpectedEvents]` mit Spalten `ExecuteMondayFrom`…`ExecuteSundayTo`, `ExpectedIncomeMonday`…`ExpectedIncomeSunday`, `MessageContainsSuccess`, `MessageContainsWarning`, `MessageContainsError`, `IsActive` - Begründung: Das Datenmodell trägt die Erwartungsdefinition verbindlich.
+  - [PRIMÄR]   src/backend/Centron.Entities/Entities/ExpectedEvents/ExpectedEventType.cs, Werte `Success=0 … EventStarted=9`, darunter `CompletedWithErrors=6` - Begründung: Definiert die auswertbaren Ergebniszustände.
+  - [PRIMÄR]   src/backend/Centron.Entities/Entities/ExpectedEvents/EventTriggerKind.cs, `public enum EventTriggerKind { Email = 0 }` - Begründung: Belegt, dass derzeit ausschließlich E-Mail als Auslöser unterstützt wird.
+Prüfidee:      Erwartetes Ereignis mit Zeitfenster Mo 08:00–09:00 und `ExpectedIncomeMonday = 1` anlegen; ohne Eintreffen darf für diesen Montag kein `ExpectedEventLogEntries`-Eintrag existieren, und die Auswertung muss die Lücke zeigen.
+Tracelinks:    SyRS-518, SwRS-533
+Konsolidierung: Kandidat: StRS-506, StRS-511 - drei getrennte Aufgaben-/Terminbegriffe (erwartetes Ereignis, Task, ToDo)
+Übernahmewürdigkeit: übernehmen - Überwachung vereinbarter Kundenereignisse ist ein eigenständiger Servicewert.
+Status:        belegt
+Modul:         M-39
+
+ID:            StRS-505
+Titel:         Auswertung erwarteter Ereignisse über einen wählbaren Zeitraum
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Serviceleitung
+Vorbedingung:  Benutzer besitzt das Recht `UserRightsConst.Administration.SHOW_EXPECTEDEVENTSREPORTING` (20800101).
+Fakt:          `ExpectedEventsReportingViewModel` initialisiert den Auswertungszeitraum auf `StarDate = DateTime.Today.AddDays(-12)` bis `EndDate = DateTime.Today`, verweigert bei `StarDate > EndDate` die Auswertung mit dem Dialog "Das Start Datum darf nicht nach dem End Datum liegen.", bietet die Filter `OnlyWithErrors` und `ShowDisabled` und gruppiert die Logeinträge je Kunde (`AccountI3D`) und erwartetem Ereignis (`ExpectedEventI3D`).
+Aussage:       Das System soll die protokollierten erwarteten Ereignisse je Kunde über einen frei wählbaren Zeitraum auswerten und dabei eine Einschränkung auf Fehlerfälle sowie das Ein-/Ausblenden deaktivierter Definitionen erlauben.
+Ergebnis:      Der Auswerter erhält je Kunde und Ereignisdefinition die Liste der Protokolleinträge im gewählten Zeitraum.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Helpdesk/ExpectedEventsReporting/ViewModels/ExpectedEventsReportingViewModel.cs, `Load()`: Aufbau des `ExpectedEventLogsFilter { EventDateStart = this.StarDate, EventDateEnd = this.EndDate.AddDays(1), OnlyWithErrors = this.OnlyWithErrors }` sowie `if (expectedEventsDto.IsActive == false) continue;` bei `ShowDisabled == false` - Begründung: Durchgesetzte Filter- und Sichtbarkeitslogik der Auswertung.
+  - [PRIMÄR]   src/backend/Centron.BL/ExpectedEvents/ExpectedEventsBL.cs, `CreateLogsFilterExpression`: `if (filter.OnlyWithErrors == true) filterExpression = filterExpression.And(f => f.EventType == ExpectedEventType.CompletedWithErrors);` - Begründung: Legt fest, dass "nur Fehler" exakt `CompletedWithErrors` bedeutet.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Helpdesk/ExpectedEventsReporting/ViewModels/ExpectedEventsReportingViewModel.cs, UI-String "Lade Event Reports" - Begründung: Belegt den Auswertungscharakter des Moduls.
+Prüfidee:      Zeitraum mit Startdatum nach Enddatum wählen: Es erscheint der Hinweis "Datum inkorrekt" und die Ergebnisliste bleibt leer.
+Tracelinks:    StRS-504, SyRS-519
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Auswertung ist der Nutzenhebel der Ereignisüberwachung.
+Status:        belegt
+Modul:         M-40
+
+ID:            StRS-506
+Titel:         Automatisierte Erzeugung wiederkehrender Serviceaufgaben
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Serviceplanung, Hintergrunddienst
+Vorbedingung:  Ein `TaskManagementTask` mit `Action` und `Recurrence` ist gespeichert und hat den Status ungleich `ProjectStatus.Finished`.
+Fakt:          `TaskManagementTaskBL.ExecuteTask(int taskI3D, AppUser currentUser, bool manuallyExecutedByUser)` bestimmt über `new RecurrenceCalculator(task.Data.Recurrence).GetDates(start)` alle fälligen Termine, überspringt Ausführungen außerhalb `Recurrence.ExecuteDaysBefore` bzw. vor `Recurrence.ExecuteAfterTime`, setzt den Task auf `ProjectStatus.Finished`, sobald `Recurrence.EndTime < date` oder `NumberOfRecurrence <= CountOfRecurrence`, und delegiert die eigentliche Wirkung an einen `ITaskManagementActionHandler` (`TaskManagementHelpdeskActionHandler` erzeugt Tickets, `TaskManagementReportActionHandler` erzeugt Reports).
+Aussage:       Das System soll aus einer Aufgabendefinition mit Wiederholungsregel automatisch Serviceaufgaben (Tickets bzw. Reportversand) erzeugen und die Ausführung beenden, sobald Enddatum oder maximale Wiederholungszahl erreicht ist.
+Ergebnis:      Wiederkehrende Serviceleistungen entstehen ohne manuelles Anlegen; abgelaufene Tasks werden automatisch stillgelegt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/TaskManager/TaskManagementTaskBL.cs, `ExecuteTask`: `var hasFinishedAtDate = task.Data.Recurrence.EndTime.HasValue && task.Data.Recurrence.EndTime.Value < date; var hasFinishedThroughCount = task.Data.Recurrence.NumberOfRecurrence.HasValue && task.Data.Recurrence.NumberOfRecurrence.Value <= task.Data.Recurrence.CountOfRecurrence.GetValueOrDefault(0);` mit anschließendem `task.Data.Status = ProjectStatus.Finished;` - Begründung: Durchgesetzte Beendigungsregel.
+  - [PRIMÄR]   src/backend/Centron.BL/TaskManager/TaskManagementTaskBL.cs, Konstruktor: `_actionHandlers = new List<ITaskManagementActionHandler> { new TaskManagementHelpdeskActionHandler(), new TaskManagementReportActionHandler() }` - Begründung: Legt die zwei unterstützten Aufgabenwirkungen fest.
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[TaskManagementRecurrence]`, `[dbo].[TaskManagementRecurrenceWeekDays]`, `[dbo].[TaskManagementActionExecutedAt]` - Begründung: Persistenzstruktur für Wiederholung und Ausführungshistorie.
+Prüfidee:      Task mit `NumberOfRecurrence = 2` täglich anlegen und dreimal ausführen lassen: Nach der zweiten Ausführung steht `Status = Finished`, die dritte Ausführung erzeugt keine weitere Aufgabe.
+Tracelinks:    SyRS-520, SwRS-534, SwRS-535
+Konsolidierung: Kandidat: StRS-504, StRS-511 - drei getrennte Aufgaben-/Terminbegriffe (erwartetes Ereignis, Task, ToDo)
+Übernahmewürdigkeit: übernehmen - Automatisierung wiederkehrender Leistungen ist tragende Serviceanforderung.
+Status:        belegt
+Modul:         M-41
+
+ID:            StRS-507
+Titel:         Kundenselbstbedienung über versendete Web-Formulare
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Servicemitarbeiter, Kundenansprechpartner
+Vorbedingung:  Zu einem Ticket (`HelpdeskI3D`) existiert mindestens ein aktives SelfCare-Formular.
+Fakt:          `SelfCareBL.SendWebForm(SendWebFormRequest request, AppUser appUser)` erzeugt ein `WebForm` mit neuer `Guid`, verknüpft die ausgewählten `SelfCareForm`-Datensätze, speichert es und versendet auf Wunsch eine Mail, in deren Text der Platzhalter `@@FormularLink@@` durch `webform.SBOUrl` ersetzt wird. Die erfolgreiche Mail wird über `_helpdeskDirectoryBL.AddMailToHelpdesk(...)` am Ticket abgelegt. Die Zielseite `PublicWebFormPage.razor` ist unter `@page "/webform/{Guid}"` mit `@attribute [AllowAnonymous]` erreichbar.
+Aussage:       Das System soll dem Kunden per E-Mail einen personalisierten, ohne Anmeldung erreichbaren Formularlink zusenden, über den er ticketbezogene Angaben selbst erfassen kann, und den Versand am Ticket dokumentieren.
+Ergebnis:      Der Kunde kann Daten ohne c-entron-Zugang liefern; der Vorgang ist am Ticket nachvollziehbar.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/SelfCare/SelfCareBL.cs, `SendWebForm(...)` und `ReplaceVariables(...)`: `return body.Replace("@@FormularLink@@", webform.SBOUrl);` - Begründung: Durchgesetzte Erzeugung und Einbettung des Links.
+  - [PRIMÄR]   src/nexus/CentronNexus/ServiceBoard/TicketWebForms/PublicWebFormPage.razor, Zeilen 1–3: `@page "/webform/{Guid}"` und `@attribute [AllowAnonymous]` - Begründung: Belegt den anonymen öffentlichen Zugriff allein über die GUID.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Helpdesk/SendSelfCareForm/SendSelfCareViewModel.cs, `SendMail()`, Fehlermeldung `SendSelfCareFormViewModel_SendMail_BitteWählenSieMindestensEinFormularAus` - Begründung: UI-seitige Mindestbedingung "mindestens ein Formular".
+Prüfidee:      Formular an eine Testadresse senden, den Link in einem anonymen Browserfenster öffnen: Die Seite lädt ohne Anmeldung; im Ticketverlauf liegt die versendete Mail.
+Tracelinks:    SyRS-521, SwRS-536
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Selbstbedienung reduziert Rückfragen und ist strategischer Bestandteil des Serviceportals.
+Status:        belegt
+Modul:         M-42
+
+ID:            StRS-508
+Titel:         Kundenindividuelle Freigabe externer Helpdesk-Funktionen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Serviceleitung, externer Kundenbenutzer
+Vorbedingung:  Ein Kunde (`CustomerI3D`) und optional ein Standort (`CustomerSiteI3D`) sind angelegt.
+Fakt:          Die Entität `ExternalHelpdeskConfiguration` (Tabelle `ExternalHelpdeskConfiguration`) besitzt genau die Schalter `TicketReleaseSystemEnabled`, `AllowHelpdeskCreation` und `AllowCloseHelpdesks`, jeweils `Not.Nullable()`, sowie die Zuordnung `CustomerI3D` und `CustomerSiteI3D`. Gelesen, gespeichert und gelöscht wird über `ExternalHelpdeskConfigurationBL` mit einem Filter nach `I3Ds`, `CustomerI3D` und `CustomerSiteI3D`; die Endpunkte liegen in `CentronRestService` (`GetExternalHelpdeskConfigurationByFilter`, `SaveOrUpdateExternalHelpdeskConfiguration`, `DeleteExternalHelpdeskConfiguration`).
+Aussage:       Das System soll je Kunde und optional je Kundenstandort festlegen, ob externe Benutzer Tickets anlegen, Tickets schließen und das Ticket-Freigabeverfahren nutzen dürfen.
+Ergebnis:      Der Funktionsumfang des externen Helpdesks ist pro Kunde/Standort steuerbar und über die REST-Schnittstelle abfragbar.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.Entities/Entities/ExternalHelpdesk/ExternalHelpdeskConfiguration.cs, Eigenschaften `TicketReleaseSystemEnabled`, `AllowHelpdeskCreation`, `AllowCloseHelpdesks`, `CustomerI3D`, `CustomerSiteI3D` - Begründung: Definiert den steuerbaren Funktionsumfang abschließend.
+  - [PRIMÄR]   src/backend/Centron.DAO/Mappings/ExternalHelpdesk/ExternalHelpdeskConfigurationMaps.cs, `Table("ExternalHelpdeskConfiguration")` mit `Map(x => x.AllowHelpdeskCreation).Not.Nullable()` - Begründung: Persistenz und Pflichtcharakter der Schalter.
+  - [SEKUNDÄR] src/webservice/Centron.Host/Services/CentronRestService.cs, Region `#region ExternalHelpdeskConfiguration`, Methoden `GetExternalHelpdeskConfigurationByFilter` / `SaveOrUpdateExternalHelpdeskConfiguration` / `DeleteExternalHelpdeskConfiguration` - Begründung: Belegt die externe Verfügbarkeit der Konfiguration.
+Prüfidee:      Für einen Kunden `AllowHelpdeskCreation = false` speichern und die Konfiguration über den REST-Endpunkt lesen: Der zurückgegebene DTO muss `AllowHelpdeskCreation = false` liefern.
+Tracelinks:    SwRS-537
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kundenspezifische Freigaben sind Voraussetzung für differenzierte Serviceverträge.
+Status:        belegt
+Modul:         M-43
+
+ID:            StRS-509
+Titel:         Zeitgesteuerte Eskalation überfälliger Vorgänge an definierte Empfängerrollen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Eskalationsdienst, Bearbeiter, Vorgesetzter, Betriebsleiter
+Vorbedingung:  Zu einem ToDo-Eintrag existiert ein Eskalationssatz (`Eskalationen.ObArt = 2`) und ein aktiver Eskalationstyp (`EskalationTypen.Status = 1`).
+Fakt:          `EscalationBL.CheckEskalationStage(Escalations escItem)` ermittelt die fällige Eskalationsstufe 1–3 anhand der Wartezeiten `Stunden1`/`Stunden2`/`Stunden3` und der bereits erfolgten Eskalationen `Eskalation1Am`/`Eskalation2Am`/`Eskalation3Am`; `ShouldEscalated` rechnet dabei in Arbeitsstunden zwischen `GeschaeftsZeitVon` und `GeschaeftsZeitBis` und überspringt Samstage bzw. Sonntage, wenn `EskalationSa`/`EskalationSo` nicht gesetzt sind. Empfänger je Stufe stammen aus `Stage1Receivers`/`Stage2Receivers`/`Stage3Receivers` (Flags-Enum `EscalationReceiversEnum` mit `Editor`, `Supervisor`, `Adviser`, `Manager`).
+Aussage:       Das System soll überfällige Vorgänge in bis zu drei Stufen eskalieren, die Wartezeit in Geschäftsstunden unter Berücksichtigung von Wochenendregeln berechnen und je Stufe die konfigurierten Empfängerrollen per E-Mail benachrichtigen.
+Ergebnis:      Überfällige Vorgänge werden stufenweise an zunehmend höhere Rollen gemeldet; jede Stufe wird in `Eskalationen` mit Zeitstempel vermerkt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Support/Escalation/EscalationBL.cs, `CheckEskalationStage`: `if (nowDt.DayOfWeek == DayOfWeek.Saturday && !escItem.IsSaturdayActive) return 0;` sowie die Stufenkaskade 1→2→3 - Begründung: Durchgesetzte Stufenermittlung inklusive Wochenendregel.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Support/Escalation/EscalationBL.cs, `UpdateEscalations`: `Update Eskalationen SET Eskalation{escItem.Stage}AM = GetDate() WHERE I3D = {escItem.EscI3D}` - Begründung: Schreibt die erreichte Stufe verbindlich fort und verhindert Doppelversand derselben Stufe.
+  - [SEKUNDÄR] src/backend/Centron.BL/Sales/Support/Escalation/EscalationReceiversEnum.cs, `[Description("Bearbeiter")] Editor = 1`, `[Description("Vorgesetzter")] Supervisor = 2`, `[Description("ADM")] Adviser = 4`, `[Description("Betriebsleiter")] Manager = 8` - Begründung: Fachliche Rollenbezeichnungen der Empfänger.
+Prüfidee:      Eskalationstyp mit `Stunden1 = 1` und Geschäftszeit 08:00–17:00 anlegen, ToDo mit Termin vor mehr als einer Arbeitsstunde erzeugen: Der Dienstlauf muss Stufe 1 melden und `Eskalation1Am` setzen; ein zweiter Lauf darf Stufe 1 nicht erneut senden.
+Tracelinks:    SyRS-522, SwRS-538, StRS-511
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Eskalationsmanagement ist SLA-relevant und unverzichtbar.
+Status:        belegt
+Modul:         M-44
+
+ID:            StRS-510
+Titel:         Benachrichtigung der Ticketbearbeiter bei Zuweisung und Entzug
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Ticketbearbeiter
+Vorbedingung:  Die Bearbeiterliste (`Helpdesk.Editors`) eines Tickets wird geändert.
+Fakt:          `NexusNotificationsBL.SaveForwardTicketNotifications(Helpdesk helpdesk, IEnumerable<HelpdeskEditor> previousEditors, LoggedInUser user)` erzeugt für jeden neu hinzugekommenen Bearbeiter eine `NexusNotification` mit `Type = NexusNotificationType.TicketAssigned` und für jeden entfernten Bearbeiter eine mit `Type = NexusNotificationType.TicketUnassigned`. Der auslösende Benutzer selbst wird ausgeschlossen (`newEditor.EmployeeI3D != user.User.Employee.I3D`). Jede Benachrichtigung wird gespeichert und zusätzlich über `NotificationsHubHelper.SendNexusNotification` live ausgeliefert.
+Aussage:       Das System soll Mitarbeiter bei Zuweisung und Entzug eines Tickets benachrichtigen, den auslösenden Benutzer davon ausnehmen und die Benachrichtigung sowohl persistieren als auch unmittelbar zustellen.
+Ergebnis:      Betroffene Bearbeiter erkennen Zuständigkeitswechsel ohne aktives Nachsehen; der Auslöser erhält keine Selbstbenachrichtigung.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/NexusNotifications/NexusNotificationsBL.cs, `SaveForwardTicketNotifications`, Filterbedingungen `previousEditors.Select(g => g.EmployeeI3D).Contains(newEditor.EmployeeI3D) is false && newEditor.EmployeeI3D != user.User.Employee.I3D` - Begründung: Durchgesetzte Regel für Empfängerermittlung und Selbstausschluss.
+  - [PRIMÄR]   src/webservice/Centron.WebServices.Core/Entities/NexusNotifications/NexusNotificationType.cs, `TicketAssigned = 11`, `TicketUnassigned = 12` - Begründung: Verbindliche Typkodierung der beiden Ereignisse.
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[NexusNotifications]` mit `[UserI3D]`, `[ByUserI3D]`, `[Type]`, `[IsSeen]`, `[IsRead]` - Begründung: Persistenz inklusive Gelesen-/Gesehen-Status.
+Prüfidee:      Ticket einem zweiten Mitarbeiter zuweisen: Für diesen entsteht genau eine `NexusNotifications`-Zeile mit `Type = 11`; für den zuweisenden Benutzer entsteht keine Zeile.
+Tracelinks:    SwRS-539
+Konsolidierung: Kandidat: SwRS-539 - drei parallele Benachrichtigungsbestände (CentronNotifications, NexusNotifications, NotificationUsers)
+Übernahmewürdigkeit: übernehmen - Zuständigkeitswechsel muss aktiv kommuniziert werden.
+Status:        belegt
+Modul:         M-45
+
+ID:            StRS-511
+Titel:         ToDo-Liste als modulübergreifender Wiedervorlage- und Terminbestand
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Sachbearbeiter aller Fachbereiche
+Vorbedingung:  Ein Geschäftsobjekt (Angebot, Auftrag, Ticket, Vertrag, Lizenz, …) erzeugt eine Wiedervorlage.
+Fakt:          `ToDoBL.FillObjectKindsListe()` registriert 35 fachliche ToDo-Arten (u. a. `ReminderOffer` "Angebot Wiedervorlage", `Commission` "Auftrag kommissionieren", `Helpdesk`, `ContractBill` "Vertragsabrechnung", `DeliveryListEscalation` "Lieferdatum überschritten", `PLM` "Lizenz Management") mit `Area` und `AssetKind`. Die Tabelle `ToDoListe` führt dazu `Art`, `ObjektArt`, `ObjectI3D`, `Termin`, `BearbeiterI3D`, `Gelesen`, `Verworfen`, `Erledigt`, `ErledigtAm`.
+Aussage:       Das System soll Wiedervorlagen und Termine aller Fachbereiche in einem gemeinsamen ToDo-Bestand führen, jeden Eintrag über Art und Objektbezug einem Ursprungsbeleg zuordnen und den Bearbeitungsstand (gelesen, erledigt, verworfen) je Eintrag festhalten.
+Ergebnis:      Jeder Mitarbeiter sieht seine offenen Wiedervorlagen fachbereichsübergreifend an einer Stelle.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/ToDoArea/ToDoBL.cs, `FillObjectKindsListe()`, z. B. `ObjectKinds.Add(new ToDoObjectKind() { ObjectKind = ToDoConstants.ToDoType.ContractBill, Name = "Vertragsabrechnung", Commentar = "Vertragsabrechnung", Area = "Vertrag", AssetKind = 22 });` - Begründung: Verbindliche, im Code fixierte Liste der fachlichen ToDo-Arten.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[ToDoListe]` mit `[Art]`, `[ObjektArt]`, `[ObjectI3D]`, `[Termin]`, `[BearbeiterI3D]`, `[Gelesen]`, `[Verworfen]`, `[Erledigt]`, `[ErledigtAm]` - Begründung: Datenmodell trägt Objektbezug und Bearbeitungsstand.
+  - [SEKUNDÄR] src/backend/Centron.BL/ToDoArea/ToDoBL.cs, `GetTextForTodoType`, z. B. `return "Benachrichtigung (Mail aus Kundenstamm) bezüglich eines Kunden";` - Begründung: Fachliche Klartexte der Arten.
+Prüfidee:      Für ein Angebot eine Wiedervorlage anlegen: In `ToDoListe` entsteht eine Zeile mit `Art` = `ReminderOffer` und `ObjectI3D` = Angebots-I3D; nach Erledigen ist `Erledigt` gesetzt und `ErledigtAm` gefüllt.
+Tracelinks:    StRS-509, SwRS-540
+Konsolidierung: Kandidat: StRS-504, StRS-506 - drei getrennte Aufgaben-/Terminbegriffe (ToDo, Task, erwartetes Ereignis)
+Übernahmewürdigkeit: übernehmen - Zentraler Aufgabenbestand ist fachlich unverzichtbar; die technische Realisierung (Delphi-Erbe, `Art`-Magic-Numbers) ist gesondert zu modernisieren.
+Status:        belegt
+Modul:         M-46

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_work/A5_SyRS.md

@@ -0,0 +1,236 @@
+ID:            SyRS-512
+Titel:         Modulzugang Rechteverwaltung nur mit Recht und Lizenz
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Angemeldeter Benutzer, Modulregistrierung
+Vorbedingung:  Benutzer ist an einer c-entron-Verbindung angemeldet.
+Fakt:          In `ModuleRegistration.cs` ist das Modul so registriert: `ModuleRegistrationItem.For<RightsManagamentAppModuleController>(() => Helper.HasRights(UserRightsConst.Administration.ID, UserRightsConst.Administration.UserRightsManagement.ID), () => LicenseManager.Instance.HasLicense(LicenseGuids.RightsManagement) || LicenseManager.Instance.HasLicense(LicenseGuids.Centron))`. `Helper.HasRights` ist eine reine Ausdrucksmarkierung, die vom `ModuleRightsExpressionParser` in einen `RightCheckNode` übersetzt wird; dessen `HasRights(IList<int> allRights)` liefert `allRights.Contains(this.Right)`. `UserRightsManagement.ID` ist 10530, `Administration.ID` das übergeordnete Recht.
+Aussage:       Das System soll den Zugang zum Modul Rechteverwaltung nur gewähren, wenn der Benutzer sowohl das Recht `Administration.ID` als auch `Administration.UserRightsManagement.ID` (10530) besitzt und zusätzlich die Lizenz `RightsManagement` oder `Centron` vorliegt.
+Ergebnis:      Ohne beide Rechte oder ohne passende Lizenz erscheint das Modul nicht in der Modulliste und ist nicht startbar.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Abschnitt "// Rechteverwaltung", `ModuleRegistrationItem.For<RightsManagamentAppModuleController>(() => Helper.HasRights(UserRightsConst.Administration.ID, UserRightsConst.Administration.UserRightsManagement.ID), ...)` - Begründung: Dies ist die durchsetzende Registrierungsbedingung für die Modulsichtbarkeit.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRightsExpressionParser.cs, `RightCheckNode.HasRights(IList<int> allRights) => allRights.Contains(this.Right)` - Begründung: Auswertende Stelle des Ausdrucks; belegt UND-Verknüpfung der aufgezählten Rechte.
+  - [PRIMÄR]   src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs, `public class UserRightsManagement { public const int ID = 10530; ... }` - Begründung: Konkrete Recht-ID.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Extensions/RibbonControlExtensions.cs, Zeile 285: `if (CentronCache.Instance.CurrentUserAppRights.Any(f => f.I3D == UserRightsConst.Administration.ID) && CentronCache.Instance.CurrentUserAppRights.Any(f => f.I3D == UserRightsConst.Administration.UserRightsManagement.ID))` - Begründung: Zweite, oberflächenseitige Ausblendung derselben Rechtekombination.
+Prüfidee:      Benutzer nur mit `Administration.ID`, ohne 10530 anmelden: Modul "Rechteverwaltung" darf nicht in der Modulübersicht erscheinen.
+Tracelinks:    StRS-501, SwRS-523
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kombinierte Rechte- und Lizenzprüfung ist bewusstes Produktverhalten.
+Status:        belegt
+Modul:         M-37
+
+ID:            SyRS-513
+Titel:         Hierarchischer Rechtebaum mit Elternrecht und Kinderzähler
+Ebene:         SyRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Rechteverwaltung, Datenbank
+Vorbedingung:  Ein Recht wird angelegt oder einer Gruppe zugewiesen.
+Fakt:          Die Tabelle `Sichrech` besitzt `I3D` (kein IDENTITY, sondern fachlich vergeben), `Text`, `Beschreibung`, `OwnerRecht` (Elternrecht), `NumChildren` und `Obsolete` (`bit NOT NULL`). Das Mapping `AppRightMaps` bildet `References(a => a.Parent).Column("OwnerRecht")` und `HasMany(u => u.Children).Table("Sichrech").KeyColumn("OwnerRecht")` ab. `AppRightsBL.SaveAndAssignGroupToRight` setzt die Hierarchie durch: nach Zuweisung eines Rechts ruft es sich rekursiv für `selectedRight.Parent` auf.
+Aussage:       Das System soll Rechte als Baum mit genau einem Elternrecht je Knoten führen und bei Zuweisung eines Rechts an eine Gruppe automatisch alle übergeordneten Rechte derselben Gruppe zuweisen.
+Ergebnis:      Eine Gruppe kann kein Detailrecht besitzen, ohne die zugehörigen übergeordneten Rechte zu besitzen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, `SaveAndAssignGroupToRight(AppGroup group, AppRight selectedRight)`: `if (selectedRight.Parent != null) SaveAndAssignGroupToRight(group, selectedRight.Parent);` - Begründung: Durchgesetzte Vererbung der Elternrechte bei jeder Zuweisung.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[Sichrech]([I3D] [int] NOT NULL, ... [OwnerRecht] [int] NULL, [NumChildren] [int] NULL, [Obsolete] [bit] NOT NULL, CONSTRAINT [PK_Sichrech] PRIMARY KEY CLUSTERED ([I3D] ASC))` - Begründung: Datenmodell des Baums; `I3D` ohne IDENTITY belegt die fachlich feste ID-Vergabe.
+  - [PRIMÄR]   src/backend/Centron.DAO/Mappings/Administration/AppRightMaps.cs, `References(a => a.Parent).Column("OwnerRecht")` / `HasMany(u => u.Children).Table("Sichrech").KeyColumn("OwnerRecht")` - Begründung: Objektseitige Abbildung des Baums.
+  - [KONTEXT]  docs/guides/development/add-a-new-right.md, "In `OwnerRecht` the I3D of the right comes in, which is required for your new right." - Begründung: Erläutert die Semantik, setzt sie aber nicht durch.
+Prüfidee:      Einer neuen Gruppe nur das Blattrecht `Checklists.EDIT_CHECKLISTS` (20800003) zuweisen: In `Sichtrus` müssen zusätzlich `Checklists.ID` (20800000) und dessen Elternrechte für dieselbe Gruppe stehen.
+Tracelinks:    StRS-501, SwRS-529
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Rechtehierarchie reduziert Fehlkonfigurationen; die feste ID-Vergabe ist beim Neubau zu überdenken.
+Status:        belegt
+Modul:         M-37
+
+ID:            SyRS-514
+Titel:         Filialbeschränkung der Rechteverwaltung durch einschränkendes Recht
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Filialadministrator
+Vorbedingung:  Der Benutzer besitzt `UserRightsConst.Administration.UserRightsManagement.MANAGE_RIGHTS_ONLY_OWN_BRANCH` (20800144) und sein Mitarbeiter hat eine `BranchI3D`.
+Fakt:          Das Recht 20800144 wirkt als einschränkendes Recht an vier durchsetzenden Stellen der Serverschicht: `GetAllRightGroups` filtert `query.Where(f => f.BranchI3D == currentUser.Employee.BranchI3D.GetValueOrDefault(0))`; `SaveRightGroup`, `CopyRightGroup` und `DeleteRightGroup` brechen mit einem Fehler ab, wenn `user.Employee.BranchI3D != appGroup.BranchI3D`. Die Gruppentabelle `Sichgrup` trägt dafür die Spalte `BranchI3D`.
+Aussage:       Das System soll für Benutzer mit dem Recht 20800144 sämtliche Gruppenoperationen (Anzeigen, Anlegen, Kopieren, Löschen) auf Rechtegruppen der eigenen Filiale beschränken und Operationen auf Gruppen fremder Filialen mit einer erklärenden Fehlermeldung ablehnen.
+Ergebnis:      Ein Filialadministrator kann Rechte nur innerhalb der eigenen Filiale verwalten.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, `SaveRightGroup`: `if (user.HasUserRight(UserRightsConst.Administration.UserRightsManagement.MANAGE_RIGHTS_ONLY_OWN_BRANCH) && user.Employee.BranchI3D != appGroup.BranchI3D) return Result<AppGroup>.AsError("Sie haben nicht genügend Rechte um eine Gruppe für eine andere Filiale anlegen zu können.");` - Begründung: Serverseitig durchgesetzte Schreibsperre.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, `DeleteRightGroup`: identische Prüfung mit der Meldung "Sie haben nicht genügend Rechte um die Gruppe einer anderen Filiale zu löschen." - Begründung: Durchgesetzte Löschsperre.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, `GetAllRightGroups(AppUser currentUser)`: `query = query.Where(f => f.BranchI3D == currentUser.Employee.BranchI3D.GetValueOrDefault(0));` - Begründung: Durchgesetzte Lesebeschränkung.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Administration/RightsManagement/NewGroup/NewRightGroupViewModel.cs, `IsBranchEditable = CentronCache.Instance.CurrentUserAppRights.All(f => f.I3D != UserRightsConst.Administration.UserRightsManagement.MANAGE_RIGHTS_ONLY_OWN_BRANCH);` - Begründung: Ergänzende UI-Sperre der Filialauswahl.
+Prüfidee:      Benutzer mit 20800144 und Filiale A versucht, eine Gruppe mit `BranchI3D` = Filiale B zu speichern: Der Aufruf muss mit der genannten Fehlermeldung fehlschlagen und in `Sichgrup` darf keine Zeile entstehen.
+Tracelinks:    StRS-501, SwRS-525, SwRS-526
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Mandanten-/Filialtrennung in der Rechteverwaltung ist sicherheitsrelevant.
+Status:        belegt
+Modul:         M-37
+
+ID:            SyRS-515
+Titel:         Schutz der Administratorengruppe vor Löschung und Rechteentzug
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Administrator
+Vorbedingung:  Die Gruppe "Administratoren" (`Sichgrup.I3D = 6` oder `Name = 'Administratoren'`) existiert.
+Fakt:          `AppRightsBL.DeleteRightGroup` bricht mit `Result.AsError("Die Adminstratoren Gruppe darf nicht gelöscht werden")` ab, wenn `group.I3D == 6 || group.Name.Equals("Administratoren", StringComparison.InvariantCultureIgnoreCase)`. `AppUserGroupBL.IsAdministratorGroup` erkennt die Gruppe über dieselbe Doppelbedingung; `AppRightsBL.RemoveGroupToRightAssignments` überspringt Zuordnungen von Admin-Gruppen (`Where(x => this._appUserGroupBL.IsAdministratorGroupI3D(x.GroupI3D) == false)`).
+Aussage:       Das System soll die Administratorengruppe nicht löschbar machen und Massenoperationen zum Entzug von Gruppen-Recht-Zuordnungen die Administratorengruppe überspringen lassen.
+Ergebnis:      Ein vollständiger Verlust administrativer Rechte durch Fehlbedienung ist ausgeschlossen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, `DeleteRightGroup`: `if (group.I3D == 6 || group.Name.Equals("Administratoren", StringComparison.InvariantCultureIgnoreCase)) return Result.AsError("Die Adminstratoren Gruppe darf nicht gelöscht werden");` - Begründung: Durchgesetzte Löschsperre in der Serverschicht.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, `RemoveGroupToRightAssignments(List<AppGroupRightAssignment> assignments)`: `foreach (var appGroupRightAssignment in assignments.Where(x => this._appUserGroupBL.IsAdministratorGroupI3D(x.GroupI3D) == false)) //No AdminGroup Rights` - Begründung: Durchgesetzter Ausschluss der Admin-Gruppe beim Massenentzug.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Rights/AppUserGroupBL.cs, `IsAdministratorGroupI3D(int groupI3D) => groupI3D == 6;` - Begründung: Fest kodierte Identität der Admin-Gruppe.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Administration/RightsManagement/RightsManagmentViewModel.cs, Zeile 867 ff.: Dialog "Die Administratoren Gruppe darf nicht gelöscht werden" / "Löschen nicht möglich" - Begründung: Vorgelagerte UI-Sperre mit identischem Wortlaut.
+Prüfidee:      `DeleteRightGroup(6, adminUser)` aufrufen: Rückgabe muss ein Fehlerergebnis mit dem genannten Text sein; die Zeile in `Sichgrup` bleibt bestehen.
+Tracelinks:    StRS-501, SwRS-526, SwRS-527
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Schutz vor Aussperrung ist zwingend; die Hartkodierung auf `I3D = 6` ist beim Neubau durch ein Systemflag zu ersetzen.
+Status:        belegt
+Modul:         M-37
+
+ID:            SyRS-516
+Titel:         Abschließend definierte Ereignisarten des Rechteprotokolls
+Ebene:         SyRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Rechteverwaltung, Revision
+Vorbedingung:  Eine Rechte- oder Gruppenänderung wird protokolliert.
+Fakt:          `AppRightLogKind` definiert genau sieben Werte: `AddRightToGroup = 2`, `RemoveRightFromGroup = 3`, `CreateGroup = 4`, `DeleteGroup = 5`, `AddUserToGroup = 6`, `RemoveUserFromGroup = 7`, `CopyGroup = 8`. Die Werte 0 und 1 sind auskommentiert mit dem Hinweis "The values of the enum are dependant on the delphi values. 0 & 1 are not used. 8 onwards are new ones from .NET". Der Wert wird in `SichProtokoll.Art` gespeichert.
+Aussage:       Das System soll Rechteprotokolleinträge ausschließlich mit einer der sieben definierten Ereignisarten (2 bis 8) kennzeichnen und die Kodierung mit dem Delphi-Altsystem kompatibel halten.
+Ergebnis:      Protokolleinträge sind über `Art` maschinell klassifizierbar und mit Alt-Einträgen aus Delphi vergleichbar.
+Belege:
+  - [PRIMÄR]   src/webservice/Centron.WebServices.Core/Entities/Administration/AppRightLogKind.cs, vollständige Enum-Definition `AddRightToGroup = 2 … CopyGroup = 8` - Begründung: Abschließende Wertemenge der Protokollart.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[SichProtokoll]([I3D],[Art],[Objekt] varchar(500),[Beschreibung] varchar(500),[ErstelltVonI3D],[ErstelltDatum],[ErstelltVersion] varchar(20),[Status])` - Begründung: Zielstruktur des Protokolls; `Beschreibung` ist auf 500 Zeichen begrenzt.
+  - [KONTEXT]  src/webservice/Centron.WebServices.Core/Entities/Administration/AppRightLogKind.cs, Kommentar "//The values of the enum are dependant on the delphi values." - Begründung: Erklärt die Lücke bei 0/1.
+Prüfidee:      Alle sieben Operationen ausführen und die Menge der entstehenden `SichProtokoll.Art`-Werte prüfen: Sie muss exakt {2,3,4,5,6,7,8} sein.
+Tracelinks:    StRS-502
+Konsolidierung: nein
+Übernahmewürdigkeit: Sonderfall - Wertelücke 0/1 existiert nur wegen Delphi-Kompatibilität und ist bei einer Neuimplementierung entbehrlich.
+Status:        belegt
+Modul:         M-37
+
+ID:            SyRS-517
+Titel:         Modulzugang Checklisten und deklarierter Rechteumfang
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Angemeldeter Benutzer
+Vorbedingung:  Benutzer ist angemeldet.
+Fakt:          Das Modul ist registriert als `ModuleRegistrationItem.For<CentronChecklistAppModuleController>(() => Helper.HasRights(UserRightsConst.Sales.Customer.Helpdesk.Checklists.ID), () => LicenseManager.Instance.HasLicense(LicenseGuids.Checklists) || LicenseManager.Instance.HasLicense(LicenseGuids.Centron))`. `CentronChecklistAppModuleController.GetRights()` deklariert die vier Rechte `Checklists.ID` (20800000), `CREATE_NEW_CHECKLIST_TEMPLATES` (20800001), `EDIT_CHECKLIST_TEMPLATES` (20800002), `EDIT_CHECKLISTS` (20800003). Zusätzlich existiert `EDIT_CHECKLIST_ITEM_EDITOR` (20800152).
+Aussage:       Das System soll das Checklistenmodul nur bei Vorliegen des Rechts `Checklists.ID` (20800000) und der Lizenz `Checklists` oder `Centron` bereitstellen und die Bearbeitungsfunktionen intern nach Vorlage anlegen, Vorlage bearbeiten und Checkliste bearbeiten unterscheiden.
+Ergebnis:      Ohne das Basisrecht ist das Modul nicht erreichbar; ohne die jeweiligen Detailrechte sind die zugehörigen Funktionen gesperrt.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Abschnitt "// Checklisten", `Helper.HasRights(UserRightsConst.Sales.Customer.Helpdesk.Checklists.ID)` plus Lizenzbedingung - Begründung: Durchgesetzte Zugangsbedingung des Moduls.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Helpdesk/CentronChecklist/CentronChecklistAppModuleController.cs, `GetRights()` mit den vier aufgezählten Konstanten - Begründung: Verbindliche Rechtemenge, die das Modul beansprucht.
+  - [PRIMÄR]   src/shared/Centron.Controls/Checklist/CentronChecklist/ChecklistConfiguration/ChecklistConfigurationViewModel.cs, Zeilen 139/141: `this._hasRightNewChecklist = rights.Result.Any(f => f.I3D == UserRightsConst.Sales.Customer.Helpdesk.Checklists.CREATE_NEW_CHECKLIST_TEMPLATES) == true;` bzw. `..EDIT_CHECKLIST_TEMPLATES..` - Begründung: Durchsetzende Auswertung der Detailrechte in der Konfigurationsoberfläche.
+  - [KONTEXT]  CentronRights.md, Abschnitt "16. Checklisten" mit 16.1–16.4 - Begründung: Prosabeschreibung der vier Checklistenrechte.
+Prüfidee:      Benutzer ohne 20800000 anmelden: Modul "Checklisten" fehlt in der Modulliste. Benutzer mit 20800000, aber ohne 20800001: Die Funktion zum Anlegen neuer Vorlagen ist deaktiviert.
+Tracelinks:    StRS-503, SwRS-530
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Feingranulare Trennung Vorlage/Instanz ist fachlich sinnvoll.
+Status:        belegt
+Modul:         M-38
+
+ID:            SyRS-518
+Titel:         Modulzugang Erwartete Ereignisse und wochentagsbezogene Erwartungsdefinition
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Serviceadministrator
+Vorbedingung:  Benutzer ist angemeldet; ein Kunde ist über die Kontosuche auswählbar.
+Fakt:          Registrierung: `ModuleRegistrationItem.For<ExpectedEventsAppModuleController>(() => Helper.HasRights(UserRightsConst.Administration.SHOW_EXPECTEDEVENTS), () => LicenseManager.Instance.HasLicense(LicenseGuids.ExpectedEvents) || LicenseManager.Instance.HasLicense(LicenseGuids.Centron))` mit `SHOW_EXPECTEDEVENTS = 20800100`. `ExpectedEventsMainViewModel.NewExpectedEvent()` erzwingt vor Anlage die Auswahl genau eines Kontos über `SearchAccountViewModel(... AllowMultiSelect = false)` und ordnet das neue Ereignis diesem `AccountI3D` zu; ein Konto kann mehrere Ereignisdefinitionen tragen.
+Aussage:       Das System soll das Modul Erwartete Ereignisse nur bei Recht 20800100 und passender Lizenz bereitstellen und jede Ereignisdefinition verpflichtend genau einem Kundenkonto zuordnen.
+Ergebnis:      Jede Ereignisdefinition besitzt einen eindeutigen Kundenbezug; ein Konto kann mehrere Definitionen führen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Abschnitt "// Erwartete Events", `Helper.HasRights(UserRightsConst.Administration.SHOW_EXPECTEDEVENTS)` plus Lizenzbedingung - Begründung: Durchgesetzte Zugangsbedingung.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Helpdesk/ExpectedEvents/ViewModels/ExpectedEventsMainViewModel.cs, `NewExpectedEvent()`: `if (account == null) return;` und `var expectedevent = new ExpectedEventsDTOViewModel(account.I3D);` - Begründung: Erzwingt den Kontobezug bei Neuanlage.
+  - [PRIMÄR]   src/backend/Centron.BL/ExpectedEvents/ExpectedEventsBL.cs, `GetAllExpectedEventsByAccount(int accountI3D)`: `GetList(f => f.AccountI3D == accountI3D)` - Begründung: Belegt die 1:n-Beziehung Konto → Ereignisdefinitionen.
+  - [SEKUNDÄR] src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs, `public const int SHOW_EXPECTEDEVENTS = 20800100;` - Begründung: Konkrete Recht-ID.
+Prüfidee:      Benutzer ohne 20800100 anmelden: Modul "Erwartete Events" fehlt. Anlage ohne Kontoauswahl abbrechen: Es entsteht kein Datensatz in `ExpectedEvents`.
+Tracelinks:    StRS-504, SwRS-533
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kundenbezug ist konstitutiv für die Überwachung.
+Status:        belegt
+Modul:         M-39
+
+ID:            SyRS-519
+Titel:         Modulzugang Auswertung erwarteter Ereignisse mit eigener Lizenz
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Angemeldeter Benutzer
+Vorbedingung:  Benutzer ist angemeldet.
+Fakt:          Registrierung: `ModuleRegistrationItem.For<ExpectedEventsReportingAppModuleController>(() => Helper.HasRights(UserRightsConst.Administration.SHOW_EXPECTEDEVENTSREPORTING), () => LicenseManager.Instance.HasLicense(LicenseGuids.ExpectedEventsEvaluation) || LicenseManager.Instance.HasLicense(LicenseGuids.Centron))` mit `SHOW_EXPECTEDEVENTSREPORTING = 20800101` und `LicenseGuids.ExpectedEventsEvaluation = C6770ACC-8477-4D1A-894F-F996B327809C`. Dieses Recht und diese Lizenz sind verschieden von denen der Ereignisdefinition (20800100 / `LicenseGuids.ExpectedEvents`).
+Aussage:       Das System soll die Auswertung erwarteter Ereignisse als eigenständiges Modul mit eigenem Recht (20800101) und eigener Lizenz (`ExpectedEventsEvaluation`) führen, getrennt von der Pflege der Ereignisdefinitionen.
+Ergebnis:      Auswertende Rollen können ohne Pflegerechte arbeiten und umgekehrt.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Abschnitt "// Erwartete Events Auswertung", vollständige Registrierungszeile mit `SHOW_EXPECTEDEVENTSREPORTING` und `LicenseGuids.ExpectedEventsEvaluation` - Begründung: Durchgesetzte, von SyRS-518 verschiedene Zugangsbedingung.
+  - [PRIMÄR]   src/backend/Centron.Interfaces/Administration/Logins/LicenseGuids.cs, `ExpectedEvents = 2714E998-9D73-4064-9208-C1705A8826B0` und `ExpectedEventsEvaluation = C6770ACC-8477-4D1A-894F-F996B327809C` - Begründung: Belegt zwei getrennte Lizenzen.
+  - [SEKUNDÄR] src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs, `SHOW_EXPECTEDEVENTS = 20800100; SHOW_EXPECTEDEVENTSREPORTING = 20800101;` - Begründung: Zwei getrennte Rechte-IDs.
+Prüfidee:      Benutzer nur mit 20800100 anmelden: "Erwartete Events" erscheint, "Erwartete Events Auswertung" nicht.
+Tracelinks:    StRS-505, SyRS-518
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Trennung von Pflege und Auswertung entspricht der Rollentrennung.
+Status:        belegt
+Modul:         M-40
+
+ID:            SyRS-520
+Titel:         Modulzugang Taskmanagement und aktionsabhängige Lizenzprüfung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Serviceplaner
+Vorbedingung:  Benutzer ist angemeldet.
+Fakt:          Registrierung: `ModuleRegistrationItem.For<TaskManagmentAppModuleController>(() => Helper.HasRights(UserRightsConst.Sales.Customer.Helpdesk.SHOW_TASKMANAGEMENT), () => LicenseManager.Instance.HasLicense(LicenseGuids.ServiceBoardWebDev) || LicenseManager.Instance.HasLicense(LicenseGuids.TaskManagement))` mit `SHOW_TASKMANAGEMENT = 20800102`. Zusätzlich prüft `TaskManagementTaskBL.CheckLicenses(TaskManagementTask task)` beim Speichern aktionsabhängig: Für `TaskManagementHelpdeskAction` ist `LicenseGuids.ServiceBoardWebDev` erforderlich ("Sie besitzen keine Lizenz für Automatische Tickets."), für `TaskManagementReportAction` `LicenseGuids.TaskManagementReportServer` oder `LicenseGuids.ProjectManagement` ("Sie besitzen keine Lizenz für den Reportserver.").
+Aussage:       Das System soll den Modulzugang zum Taskmanagement an das Recht 20800102 binden und beim Speichern eines Tasks zusätzlich prüfen, ob für die gewählte Aktionsart (Ticket bzw. Report) die passende Lizenz vorliegt.
+Ergebnis:      Ein Task mit nicht lizenzierter Aktionsart wird mit einer sprechenden Fehlermeldung abgewiesen und nicht gespeichert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/TaskManager/TaskManagementTaskBL.cs, `CheckLicenses(TaskManagementTask task)`: `if (task.Action is TaskManagementHelpdeskAction && LicenseManager.Instance.HasLicense(LicenseGuids.ServiceBoardWebDev) == false) return Result.AsError("Sie besitzen keine Lizenz für Automatische Tickets.", DefaultMessageCodes.LicenseNotFound);` - Begründung: Serverseitig durchgesetzte, aktionsabhängige Lizenzprüfung vor dem Speichern.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Abschnitt "// Taskmanagement", Registrierungszeile mit `SHOW_TASKMANAGEMENT` - Begründung: Durchgesetzte Modulsichtbarkeit.
+  - [SEKUNDÄR] CentronRights.md, "### 18 Taskmanagement anzeigen — This right allows the user to access the task management. *UserRightsConst.Sales.Customer.Helpdesk.SHOW_TASKMANAGEMENT*" - Begründung: Fachliche Beschreibung des Rechts.
+Prüfidee:      Ohne Lizenz `ServiceBoardWebDev` einen Task mit Helpdesk-Aktion speichern: Rückgabe muss Fehler mit Text "Sie besitzen keine Lizenz für Automatische Tickets." sein; in `TaskManagementTask` entsteht keine Zeile.
+Tracelinks:    StRS-506, SwRS-535
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Lizenzdurchsetzung auf Aktionsebene ist bewusst und verhindert Umgehung über die Oberfläche.
+Status:        belegt
+Modul:         M-41
+
+ID:            SyRS-521
+Titel:         Zeitlich begrenzte Gültigkeit öffentlicher SelfCare-Formularlinks
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Anonymer Formularaufrufer
+Vorbedingung:  Ein `WebForm` wurde versendet und besitzt `CreatedAt`.
+Fakt:          `SelfCareBL.GetWebFormByGuid(Guid guid)` prüft: Wenn `entity.TicketPattern == null && entity.CreatedAt != null`, wird `expirationDate = entity.CreatedAt.Value.AddMinutes(ticketPatternSettings?.WebFormLinkExpirationInMinutes ?? TimeSpan.FromDays(7).TotalMinutes)` berechnet; bei `DateTime.Now > expirationDate` liefert die Methode `Result<WebForm>.AsError("Link has expired")`. Die Basis-URL stammt je nach Einstellung `ApplicationSettingID.UseNexusForPublicWebForms` aus `CentronNexusUrl` oder `ServiceBoardOnlineUrl`. Der Zugriff erfolgt anonym über `@page "/webform/{Guid}"` mit `[AllowAnonymous]`.
+Aussage:       Das System soll anonym erreichbare SelfCare-Formularlinks nach einer konfigurierbaren Frist (Standard 7 Tage ab Erstellung) ungültig machen und abgelaufene Aufrufe mit einer Fehlermeldung statt mit dem Formular beantworten.
+Ergebnis:      Ein abgelaufener Link liefert kein Formular und keine Kundendaten mehr aus.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/SelfCare/SelfCareBL.cs, `GetWebFormByGuid(Guid guid)`: `if (DateTime.Now > expirationDate) return Result<WebForm>.AsError("Link has expired");` mit `?? TimeSpan.FromDays(7).TotalMinutes` als Vorgabewert - Begründung: Serverseitig durchgesetzte Ablaufprüfung; die einzige Stelle, an der ein Formular über die GUID aufgelöst wird.
+  - [PRIMÄR]   src/nexus/CentronNexus/ServiceBoard/TicketWebForms/PublicWebFormPage.razor, `@page "/webform/{Guid}"` + `@attribute [AllowAnonymous]` - Begründung: Belegt, dass die GUID der einzige Zugriffsschutz ist und die Ablauffrist daher sicherheitsrelevant ist.
+  - [SEKUNDÄR] src/backend/Centron.BL/Administration/Settings/AppSettingsGroupBL.cs, `WebFormLinkExpirationInMinutes = settings.GetInt(ApplicationSettingID.WebFormLinkExpirationInMinutes, null)` - Begründung: Konfigurierbarkeit der Frist.
+Prüfidee:      `WebForms.CreatedAt` eines Testformulars auf `GETDATE()-8 Tage` setzen und den Link aufrufen: Es muss "Link has expired" zurückkommen und kein Formularinhalt geladen werden.
+Tracelinks:    StRS-507, SwRS-536
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zeitliche Begrenzung ist bei GUID-only-Zugriff die zentrale Schutzmaßnahme.
+Status:        belegt
+Modul:         M-42
+
+ID:            SyRS-522
+Titel:         Eskalationsprüfung als lizenzpflichtiger zyklischer Hintergrunddienst
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Centron-Host (Hintergrunddienst)
+Vorbedingung:  Der Centron-Host läuft.
+Fakt:          `EscalationsService : ManagedBackgroundService` gibt `ServiceName => "EscalationsService"` und `GetExecutionInterval() => TimeSpan.FromMinutes(15)` zurück. In `ExecuteService` bricht der Dienst ab, wenn `LicenseManager.Instance.HasLicense(LicenseGuids.EscalationsServer)` falsch ist, und protokolliert "Lizenz für Eskalationsserver ist nicht vorhanden"; andernfalls öffnet er eine `BLSession` und ruft `EscalationWebserviceBL.CheckEscalations()`.
+Aussage:       Das System soll die Eskalationsprüfung serverseitig alle 15 Minuten automatisch ausführen und diese Ausführung an die Lizenz `EscalationsServer` binden.
+Ergebnis:      Eskalationen laufen ohne Benutzerinteraktion; ohne Lizenz findet keine Prüfung statt und der Grund ist protokolliert.
+Belege:
+  - [PRIMÄR]   src/webservice/Centron.Host/AspNetCore/HostedServices/EscalationsService.cs, `protected override TimeSpan GetExecutionInterval() { return TimeSpan.FromMinutes(15); }` und `if (!LicenseManager.Instance.HasLicense(LicenseGuids.EscalationsServer)) { Logger.Info("Lizenz für Eskalationsserver ist nicht vorhanden"); return; }` - Begründung: Durchgesetzter Ausführungstakt und Lizenzgate.
+  - [PRIMÄR]   src/backend/Centron.Interfaces/Administration/Logins/LicenseGuids.cs, `EscalationsServer = Guid.Parse("C205E2FF-BA14-4610-A9A7-02C229187430")` - Begründung: Konkrete Lizenzkennung.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Administration/EscalationsSettings/EscalationType/EscalationTypeSettingViewModel.cs, `TollTipNoLizenz` mit Text "Um mehr Information über Eskalationen zu bekommen … wenden Sie sich bitte an den c-entron Vertrieb" - Begründung: UI-Hinweis auf die Lizenzpflicht.
+Prüfidee:      Host ohne Lizenz `EscalationsServer` starten: Im Log erscheint "Lizenz für Eskalationsserver ist nicht vorhanden" und es werden keine Eskalationsmails versendet.
+Tracelinks:    StRS-509, SwRS-538
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Serverseitige Automatik ist Voraussetzung für verlässliche SLA-Eskalation.
+Status:        belegt
+Modul:         M-44

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_work/A6_StRS.md

@@ -0,0 +1,188 @@
+ID:            StRS-601
+Titel:         Zentraler Artikelstamm als führende Quelle für Produkt- und Preisdaten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Artikelverantwortlicher / Einkauf
+Vorbedingung:  Mandant ist eingerichtet, Warengruppen und Mehrwertsteuersätze sind gepflegt.
+Fakt:          Die Tabelle `dbo.ARTIK` führt sämtliche artikelbezogenen Stamm-, Bestands- und Preisfelder in einem Satz (u. a. `Artikelcode`, `Kurzbegriff`, `Artikelbeschreibung`, `EK`, `VK_1`..`VK_4`, `EVK`, `Mindestpreis`, `Listenpreis`, `Warengruppe`, `EANCode`, `Hersteller`, `EOL`, `Einheit`, `Nachkommastellen`). `ArticleBL` kapselt Lesen, Anlegen, Kopieren und Speichern dieses Satzes.
+Aussage:       Das System soll alle Produkt-, Preis- und Bestandsattribute eines Artikels in einem zentralen Artikelstammsatz führen, auf den Verkauf, Einkauf, Lager und Fakturierung gemeinsam zugreifen.
+Ergebnis:      Ein Artikel besitzt genau einen Stammsatz; nachgelagerte Module (Belege, Preisfindung, Lager) lesen Preise und Attribute ausschließlich aus diesem Satz bzw. aus den daran gehängten Spezialtabellen.
+Belege:
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql`, `CREATE TABLE [dbo].[ARTIK]` (Zeile 5198 ff.) - Begründung: Das Schema belegt, dass Preis-, Bestands-, Klassifizierungs- und Lebenszyklusfelder physisch in einer Tabelle zusammengeführt sind.
+  - [PRIMÄR]   `src/backend/Centron.BL/Warehousing/ArticleBL.cs`, `ArticleBL.SaveArticle(Article, LoggedInUser, bool)` (Zeile 761) - Begründung: Einziger Schreibpfad der Geschäftslogik für den Artikelstamm; setzt Rechte-, Konsistenz- und Sperrprüfungen zentral durch.
+  - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Registrierung `ArticleManagementAppModuleController` mit Kommentar `// Artikelverwaltung` - Begründung: Belegt die Artikelverwaltung als eigenständiges Fachmodul.
+Prüfidee:      Einen Artikel anlegen, in `ARTIK` prüfen, dass genau ein Datensatz entsteht und dass anschließend Beleg-, Lager- und Preisfindungsmodule dieselben Werte (EK, VK1–VK4, Warengruppe) lesen.
+Tracelinks:    SyRS-610, SyRS-614, SyRS-621, SwRS-622, SwRS-623
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Ein zentraler Artikelstamm ist fachlich zwingend und in jeder Zielarchitektur erforderlich.
+Status:        belegt
+Modul:         M-47
+
+ID:            StRS-602
+Titel:         Kundenindividuelle Sonderpreise und Preisvereinbarungen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertrieb / Preisverantwortlicher
+Vorbedingung:  Kunde und Artikel bzw. Warengruppe sind angelegt.
+Fakt:          `AccountSpecialPrice` (Tabelle `dbo.KundenSonderpreise`) speichert je Kunde eine Preisregel mit `ArtikelI3D` oder `WarengruppeI3D`/`UnterwarengruppeI3D`, `GiltVon`/`GiltBis`, `Aufschlag` (Wert) und `Basis` (`SpecialPriceKind`). `ReceiptItemPriceBL.GetBasePrice` wertet genau diese Regel bei jeder Belegposition aus.
+Aussage:       Das System soll je Kunde zeitlich befristete Sonderpreise auf Artikel- oder Warengruppenebene verwalten und diese bei jeder Preisermittlung einer Belegposition automatisch anwenden.
+Ergebnis:      Belegpositionen für einen Kunden mit gültigem Sonderpreis werden mit dem daraus abgeleiteten Basispreis und Rabatt bepreist statt mit dem Standard-VK.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptItemPriceBL.cs`, `GetBasePrice(...)`, Zweig `CustomerSpecialPrice specialPrice = this.GetSpecialPrice(article, customer); if (specialPrice != null) switch (specialPrice.Kind)` (Zeilen 232–258) - Begründung: Durchsetzende Stelle der Preisfindung; ohne diesen Zweig hätte der Sonderpreis keine Wirkung auf den Belegpreis.
+  - [PRIMÄR]   `src/backend/Centron.DAO/Mappings/Accounts/SpecialPrices/AccountSpecialPriceMaps.cs`, `Table("KundenSonderpreise")`, Mapping `Value -> "Aufschlag"`, `ValueKind -> "Basis"`, `ValidFrom -> "GiltVon"`, `ValidTo -> "GiltBis"` - Begründung: Belegt Persistenzmodell und Zeitbezug der Preisregel.
+  - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Finances/Crm/SpecialPrices/AccountSpecialPriceViewModel.cs`, Dialogtext `"Sonderpreis wird gespeichert..."` - Begründung: Bestätigt die fachliche Bezeichnung „Sonderpreis" in der Oberfläche.
+Prüfidee:      Für Kunde K und Artikel A einen Festpreis mit Gültigkeit ab heute anlegen, ein Angebot für K mit A erzeugen und prüfen, dass der Positionspreis dem Festpreis entspricht.
+Tracelinks:    SyRS-611, SyRS-612, SyRS-613, SwRS-624, SwRS-625, SwRS-626
+Konsolidierung: Kandidat: StRS-605, StRS-606 (mehrere getrennte Importwege für dieselbe Preisregel)
+Übernahmewürdigkeit: übernehmen - Kundenspezifische Preise sind abrechnungsrelevantes Kerngeschäft.
+Status:        belegt
+Modul:         M-52
+
+ID:            StRS-603
+Titel:         Automatisierter Import von Distributor-Artikel- und Preisdaten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Einkauf / Systemadministrator
+Vorbedingung:  Für einen Distributor ist eine Importdefinition mit Datenquelle, Trennzeichen und Feldzuordnung hinterlegt.
+Fakt:          `ArticleImportBL` lädt Distributordateien über FTP/SFTP/HTTP (`FTPDownload`, `SFTPDownload`, `HTTPDownload`), entpackt sie (`ExtractZipFile`, `ExtractGZFIle`), schreibt jede Zeile gemäß Feldzuordnung nach `WriteLineToDB` in die Distributorartikelliste und protokolliert jeden Schritt über `WriteLOG(...)` in `ArticleImportLog`.
+Aussage:       Das System soll Artikel-, Verfügbarkeits- und Preisdaten von Distributoren automatisiert aus konfigurierbaren Dateiquellen einlesen, in eine Distributorartikelliste überführen und den Importlauf nachvollziehbar protokollieren.
+Ergebnis:      Nach einem Importlauf stehen aktuelle Distributorartikel mit EK, VK und Verfügbarkeit zur Verfügung; Abweichungen und Fehler sind im Importlog dokumentiert.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Warehousing/ArticleManagement/ArticleImportBL.cs`, `StartImport(int articleImportID, ArticleImportOwner owner)` (Zeile 82) und `WriteLineToDB(...)` (Zeile 882) - Begründung: Durchsetzende Stelle des Importlaufs inkl. Zeilenverarbeitung und Ablage.
+  - [PRIMÄR]   `src/backend/Centron.BL/Warehousing/ArticleManagement/ArticleImportBL.cs`, `WriteLOG(ArticleImport, string, ArticleImportLogState)` (Zeile 1593) - Begründung: Erzwingt die Protokollierung jedes Importereignisses in `ArticleImportLog`.
+  - [SEKUNDÄR] `src/webservice/Centron.WebServices.Core/Entities/Warehousing/ArticleImports/ArticleImportType.cs`, Werte `Standard`, `AvailabilityUpdate` („Verfügbarkeit aktualisieren"), `Accessories` („Zubehör Artikel anlegen") - Begründung: Belegt die fachlichen Importarten.
+Prüfidee:      Eine CSV-Testdatei mit fünf Distributorartikeln importieren und prüfen, dass fünf Distributorartikel-Datensätze entstehen und im Importlog ein Eintrag pro Lauf existiert.
+Tracelinks:    SyRS-616, SwRS-627, SwRS-628
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Automatisierte Lieferantendatenversorgung ist für den Handelsprozess unverzichtbar.
+Status:        belegt
+Modul:         M-48
+
+ID:            StRS-604
+Titel:         Warengruppen als Klassifizierungs- und Kalkulationsrahmen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Controlling / Artikelverantwortlicher
+Vorbedingung:  Mindestens eine Warengruppe ist angelegt.
+Fakt:          `MaterialGroupBL.CreateMaterialGroup` legt Warengruppen mit Aufschlagsstaffeln (`MaterialMarkups`) an; `ArticleBL.CalculateArticleMarkups(Article, IList<MaterialMarkup>)` errechnet daraus VK1–VK4, EVP und Mindestpreis. `MaterialGroup` trägt zusätzlich Erlös-/Aufwandskonten, Kostenstelle, Kostenträger und Kennzeichen wie `NotDiscountable`, die per `ArticleTakeOnOptions` auf Artikel übertragen werden.
+Aussage:       Das System soll Artikel über Warengruppen und Unterwarengruppen klassifizieren und aus deren Aufschlagsstaffeln sowie Buchungs- und Steuerungsattributen Vorgabewerte für die Artikelkalkulation ableiten.
+Ergebnis:      Ein der Warengruppe zugeordneter Artikel erhält Verkaufspreise, EVP, Mindestpreis sowie Konten- und Kostenzuordnung gemäß der Warengruppendefinition.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Warehousing/ArticleBL.cs`, `CalculateArticleMarkups(Article article, IList<MaterialMarkup> markups)` (Zeilen 3557–3579), Auswahl `markups.Where(x => x.TillEk <= article.PurchasePrice).OrderByDescending(x => x.TillEk).FirstOrDefault()` - Begründung: Durchsetzende Stelle der warengruppenbasierten Preiskalkulation.
+  - [PRIMÄR]   `src/backend/Centron.BL/Warehousing/InventoryManagement/MaterialGroupBL.cs`, `CreateMaterialGroup(MaterialGroup, AppUser)` (Zeile 77 ff.) - Begründung: Legt Warengruppe samt Aufschlagsstaffeln an und erzwingt deren Konsistenz.
+  - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Warehousing/MaterialGroupManagement/Actions/ReCalculateArticleAction.cs`, `ActionName = "Artikel neu kalkulieren"`, `ActionHint = "Kalkuliert alle Artikel, die der Warengruppe angehören neu"` - Begründung: UI-Beleg für den fachlichen Zweck der Warengruppe als Kalkulationsrahmen.
+Prüfidee:      Warengruppe mit Staffel „ab EK 0 → VK1 +30 %" anlegen, Artikel mit EK 100 zuordnen, neu kalkulieren und VK1 = 130 prüfen.
+Tracelinks:    SyRS-615, SwRS-629
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Warengruppengestützte Kalkulation ist zentrale Steuerungsfunktion.
+Status:        belegt
+Modul:         M-49
+
+ID:            StRS-605
+Titel:         Projektpreise aus Distributor-Tabellen in Sondervereinbarungen übernehmen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertrieb / Projektbetreuer
+Vorbedingung:  Eine Sondervereinbarung (Projektpreis) existiert; eine Excel-/CSV-Datei des Distributors mit Herstellercodes und Projektpreisen liegt vor.
+Fakt:          `ProjectPriceImportViewModel` liest über eine konfigurierbare Schnittstelle (`ImportInterfaceViewModel`, Spaltenarten in `ProjectPriceImportColumnKind`) Zeilen aus einer Tabellendatei, erzeugt je Zeile ein `SpecialAgreementArticleDTO` mit `SpecialAgreementI3D` und `SpecialAgreementEK` und stellt Abweichungen zu bestehenden Positionen in `SpecialAgreementDifferenceViewModel` gegenüber.
+Aussage:       Das System soll projektbezogene Einkaufspreise aus Distributor-Tabellendateien in die Artikelpositionen einer Sondervereinbarung übernehmen und dabei Preisabweichungen zum bisherigen Stand vor der Übernahme anzeigen.
+Ergebnis:      Die Sondervereinbarung enthält für die importierten Herstellercodes aktualisierte Projekt-EKs; abweichende Preise wurden dem Anwender zur Bestätigung vorgelegt.
+Belege:
+  - [PRIMÄR]   `src/centron/Centron.WPF.UI/Modules/ProjectPriceImport/ProjectPriceImportViewModel.cs`, Zeilen 426–451: Erzeugung `new SpecialAgreementArticleDTO { SpecialAgreementI3D = this.SelectedSpecialAgreement.I3D, State = 1 }` und Zuweisung `agreementArticle.SpecialAgreementEK = projectPrice` - Begründung: Durchsetzende Stelle der Preisübernahme in die Sondervereinbarung.
+  - [PRIMÄR]   `src/centron/Centron.WPF.UI/Modules/ProjectPriceImport/ProjectPriceImportViewModel.cs`, Zeilen 527–533 und 587–592: Aufbau der `Differences` und modaler `DifferenceViewModel` - Begründung: Erzwingt die Abweichungsanzeige vor Übernahme.
+  - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/ProjectPriceImport/ProjectPriceImportColumnKind.cs`, Werte `ManufacturerCode`, `ProjectPrice`, `Validity`, `BundleInformation` - Begründung: Belegt den fachlichen Umfang der Importschnittstelle.
+Prüfidee:      Datei mit zwei bekannten Herstellercodes und geändertem Preis importieren; prüfen, dass der Differenzdialog beide Positionen mit Alt-/Neuwert zeigt und nach Bestätigung `SpecialAgreementEK` aktualisiert ist.
+Tracelinks:    StRS-602, SwRS-633, SwRS-634, SwRS-626
+Konsolidierung: Kandidat: StRS-602, StRS-606 (getrennte Importwege für Preisregeln)
+Übernahmewürdigkeit: übernehmen - Projektpreisgeschäft ist im ITK-Handel abrechnungsrelevant.
+Status:        belegt
+Modul:         M-56
+
+ID:            StRS-606
+Titel:         Vertragsbezogener Datenimport für verbrauchsabhängige Abrechnung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Abrechnung / Vertragsverwaltung
+Vorbedingung:  Verträge und Artikel sind angelegt; eine Importschnittstelle mit Spaltenzuordnung ist konfiguriert.
+Fakt:          `SpecialArticleToContractImportViewModel` liest Excel-/CSV-/TXT-Dateien und ordnet Dateispalten über `CustomGatewayDefinitions` den Feldern aus `SpecialArticleToContractImportColumnKind` zu (u. a. `CustomerNumber`, `ContractNumber`, `ArticleCode`, `Price`, `PurchasePrice`, `Quantity`, `BillingDate`, `SubscriptionId`). Das Modul ist in `ModuleRegistration.cs` als „Dynamischer Datenimport - Verträge" registriert.
+Aussage:       Das System soll periodisch anfallende, vertragsbezogene Verbrauchs- und Preisdaten externer Anbieter über konfigurierbare Spaltenzuordnungen einlesen und als abrechenbare Sonderartikel-Positionen an die zugehörigen Verträge anhängen.
+Ergebnis:      Zu jedem importierten Datensatz existiert eine Vertragsposition mit Kunde, Vertrag, Artikel, Menge und Preisen, die in die Vertragsfakturierung eingeht.
+Belege:
+  - [PRIMÄR]   `src/centron/Centron.WPF.UI/Modules/Sales/SpecialArticleToContractImport/SpecialArticleToContractImportViewModel.cs`, Zeilen 940–1024: Zuordnung `foreach (var row in this.SelectedInterface.CustomGatewayDefinitions.Where(f => f.CentronColumn > 0))` mit `switch ((SpecialArticleToContractImportColumnKind)row.CentronColumn)` - Begründung: Durchsetzende Stelle der konfigurierbaren Spaltenzuordnung.
+  - [PRIMÄR]   `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, `ModuleRegistrationItem.For<SpecialArticleToContractImportAppModuleController>(() => Helper.HasRights(UserRightsConst.Sales.ID, UserRightsConst.Sales.AUTOMATED_BILLING), () => LicenseManager.Instance.HasLicense(LicenseGuids.DynamicDataImportContracts) || ...)` - Begründung: Belegt die fachliche Einordnung als Bestandteil der automatisierten Abrechnung.
+  - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Sales/SpecialArticleToContractImport/Settings/InterfaceTemplateKind.cs`, Werte `Ingram`, `ALSO` - Begründung: Belegt vorkonfigurierte Distributorschnittstellen.
+Prüfidee:      Testdatei mit einer Zeile (Kundennummer, Vertragsnummer, Artikelcode, Menge, Preis) über eine eigene Schnittstellendefinition importieren und prüfen, dass am Vertrag eine Position mit diesen Werten entsteht.
+Tracelinks:    SyRS-620, SwRS-635
+Konsolidierung: Kandidat: StRS-602, StRS-605 (getrennte Importwege für Preisregeln)
+Übernahmewürdigkeit: übernehmen - Subscription-/Verbrauchsabrechnung ist tragendes Geschäftsmodell.
+Status:        belegt
+Modul:         M-53
+
+ID:            StRS-607
+Titel:         Kundenmatrix zur Bewertung der Produktdurchdringung je Kunde
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertrieb / Kundenbetreuer
+Vorbedingung:  Kategorien und Produkte der Kundenmatrix sind in den globalen Einstellungen angelegt; ein Kunde ist im CRM geöffnet.
+Fakt:          `CustomerProductMatrixRating` verknüpft `CustomerNumber` mit `CustomerProductMatrixProductI3D` und einem Wert aus `CustomerProductMatrixRatingValue` (`Nothing` = „Nichts klassifiziert", `Bad` = „Keine Leistung vorhanden", `Medium` = „Von Fremdpartner vorhanden", `Good` = „Von uns eingeführt vorhanden"); jede Änderung wird in `CustomerProductMatrixRatingChangeLogs` mit `EmployeeI3D`, `Timestamp` und `Reason` festgehalten.
+Aussage:       Das System soll je Kunde für jedes Produkt der Kundenmatrix einen Durchdringungsstatus führen und jede Statusänderung mit Bearbeiter, Zeitpunkt und Begründung protokollieren.
+Ergebnis:      Der Vertrieb sieht je Kunde, welche Produktkategorien durch das eigene Haus, durch Fremdpartner oder gar nicht abgedeckt sind, und kann die Historie der Einstufung nachvollziehen.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.DAO/Mappings/ProductMatrix/CustomerProductMatrixRatingMaps.cs`, `Table("CustomerProductMatrixRating")` mit `HasMany(f => f.CustomerProductMatrixRatingChangeLogs).Table("CustomerProductMatrixRatingChangeLogs").Not.KeyNullable().Cascade.All()` - Begründung: Erzwingt, dass jede Bewertung ihre Änderungshistorie mitführt.
+  - [PRIMÄR]   `src/backend/Centron.BL/ProductMatrix/ProductMatrixBL.cs`, `GetProductMatrixCustomerProductRating(int, int)` (Zeilen 165–181) - Begründung: Legt fehlende Bewertungen mit Startwert `CustomerProductMatrixRatingValue.Nothing` an und stellt so Vollständigkeit je Kunde sicher.
+  - [SEKUNDÄR] `src/webservice/Centron.WebServices.Core/Entities/ProductMatrix/CustomerProductMatrixRatingValue.cs`, `[Description("Von uns eingeführt vorhanden")]` - Begründung: Belegt die fachliche Semantik der Bewertungsstufen.
+Prüfidee:      Bewertung eines Produkts von „Nichts klassifiziert" auf „Von uns eingeführt vorhanden" ändern und prüfen, dass in `CustomerProductMatrixRatingChangeLogs` ein Eintrag mit Mitarbeiter und Zeitstempel entsteht.
+Tracelinks:    SwRS-636
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Cross-Selling-Steuerung mit Historie ist eigenständiger fachlicher Nutzen.
+Status:        belegt
+Modul:         M-54
+
+ID:            StRS-608
+Titel:         Produktlebenszyklus von Lizenz- und Vertragsprodukten überwachen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertrieb / Lizenzmanagement
+Vorbedingung:  PLM-Lizenz ist aktiv; Produktfamiliengruppen und Produktfamilien sind angelegt.
+Fakt:          `ProductLifecycleInformation` verknüpft Produktfamilie, Kunde, Rechnung/Rechnungsposition, Artikel, Barcode, Lizenzschlüssel sowie `StartDate`/`EndDate`. `ProductLifecycleSettingsViewModel` hält Einstellungen für Erinnerungsvorlauf (`LicenseReminderFromDate`), Toleranztage (`DaysToTolerate`), Zuständigen Mitarbeiter und eine E-Mail-Vorlage; `PlmViewModel` bietet Kommandos `SendReminderEmailCommand`, `DeactivateLicenseCommand` und `ImportProductLifecycleInformationsCommand`.
+Aussage:       Das System soll den Lebenszyklus lizenz- und vertragsgebundener Produkte je Kunde mit Start- und Enddatum führen und rechtzeitig vor Ablauf eine Erinnerung an den zuständigen Mitarbeiter oder Kundenkontakt auslösen.
+Ergebnis:      Ablaufende Lizenzen sind vor Erreichen des Enddatums sichtbar; zu jeder Lizenz existiert eine nachvollziehbare Zuordnung zu Rechnung, Artikel und Kunde.
+Belege:
+  - [PRIMÄR]   `src/centron/Centron.WPF.UI/Modules/PLM/ProductLifecycleInformationViewModel.cs`, `ApplyStartDateChanges()` mit `this.EndDate = this.StartDate?.AddMonths(this.ProductFamilyLifetimeInMonths);` (Zeile 537) - Begründung: Durchsetzende Stelle der Enddatumsberechnung aus der Produktfamilien-Laufzeit.
+  - [PRIMÄR]   `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, `// PLM (Lifecycle)` mit `ModuleRegistrationItem.For<PlmAppModuleController>(() => Helper.HasRights(UserRightsConst.Sales.Customer.CustomerCommon.LICENSE_MANAGEMENT), () => LicenseManager.Instance.HasLicense(LicenseGuids.PLM))` - Begründung: Belegt Zweck und Zugangssteuerung des Moduls.
+  - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Finances/ProductLifecycleManagement/Settings/ProductLifecycleSettingsViewModel.cs`, Felder `LicenseReminderFromDate`, `DaysToTolerate`, `LicenseEmailTemplateBody` - Begründung: Belegt den Erinnerungsprozess als konfigurierbaren Bestandteil.
+Prüfidee:      Produktfamilie mit Laufzeit 12 Monaten anlegen, Lizenz mit Startdatum heute erfassen und prüfen, dass das Enddatum auf heute+12 Monate gesetzt wird und die Lizenz im Erinnerungsvorlauf erscheint.
+Tracelinks:    SwRS-637
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Ablaufüberwachung von Lizenzen ist umsatzsichernd.
+Status:        belegt
+Modul:         M-57
+
+ID:            StRS-609
+Titel:         Rechte- und lizenzgesteuerter Zugang zu artikel- und preisführenden Modulen
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Systemadministrator / Anwender
+Vorbedingung:  Benutzer ist angemeldet; Rechteprofil und Lizenzumfang des Mandanten sind hinterlegt.
+Fakt:          `ModuleRegistration.cs` registriert jedes Modul mit zwei Prädikaten: einer Rechteprüfung (`Helper.HasRights(...)`) und einer Lizenzprüfung (`LicenseManager.Instance.HasLicense(...)`). Für den zuständigen Bereich sind das u. a. Artikelverwaltung (`UserRightsConst.Purchase.ID`, `UserRightsConst.Purchase.StockList.ID`), Artikelimport (`UserRightsConst.DataExchange.ARTICLE_IMPORT` = 10713), Warengruppenverwaltung (`UserRightsConst.RIGHT_WARENGRUPPEN` = 10440), Projektpreisimport (`UserRightsConst.Sales.Customer.CustomerCommon.Project_Price_Import` = 20800043), beide Vertragsimporte (`UserRightsConst.Sales.AUTOMATED_BILLING` = 10385) und PLM (`LICENSE_MANAGEMENT` = 20800018).
+Aussage:       Das System soll den Zugang zu jedem artikel- und preisführenden Modul ausschließlich dann gewähren, wenn der Benutzer das modulspezifische Recht besitzt und der Mandant die zugehörige Lizenz hält.
+Ergebnis:      Module ohne Recht oder ohne Lizenz erscheinen dem Anwender nicht in der Modulliste und lassen sich nicht öffnen.
+Belege:
+  - [PRIMÄR]   `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, `ModuleRegistrationItem.For<ArticleImportAppModuleController>(() => Helper.HasRights(UserRightsConst.DataExchange.ARTICLE_IMPORT), () => LicenseManager.Instance.HasLicense(LicenseGuids.ArticleImport) || LicenseManager.Instance.HasLicense(LicenseGuids.Centron))` - Begründung: Durchsetzende Stelle mit konkreter, zweifacher Bedingung (Recht UND Lizenz) für die Modulanzeige.
+  - [PRIMÄR]   `src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs`, Zeilen 1569, 2028, 2436, 2613 (`RIGHT_WARENGRUPPEN = 10440`, `Project_Price_Import = 20800043`, `AUTOMATED_BILLING = 10385`, `ARTICLE_IMPORT = 10713`) - Begründung: Belegt die konkreten geprüften Rechte-IDs.
+  - [SEKUNDÄR] `CentronRights.md` - Begründung: Dokumentation des Rechtemodells im Repository-Wurzelverzeichnis.
+Prüfidee:      Benutzer ohne Recht 10713 anmelden und prüfen, dass „Artikelimport" nicht in der Modulliste erscheint; anschließend Lizenz `ArticleImport` entziehen und prüfen, dass das Modul auch mit Recht verborgen bleibt.
+Tracelinks:    SwRS-622, SwRS-631
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zugriffssteuerung auf preisführende Module ist sicherheitskritisch.
+Status:        belegt
+Modul:         M-47

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_work/A6_SyRS.md

@@ -0,0 +1,250 @@
+ID:            SyRS-610
+Titel:         Systemweite Eindeutigkeit des Artikelcodes
+Ebene:         SyRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Artikelverwaltung / Datenbank
+Vorbedingung:  Ein Artikel wird angelegt oder sein Artikelcode wird geändert.
+Fakt:          Auf `dbo.ARTIK` besteht der eindeutige Index `ARTIK0` über die Spalte `Artikelcode`. `ArticleBL.GenerateArticleCodeRandom()` erzeugt Codes in einer Schleife und bricht erst ab, wenn `HasRecord(x => x.ArticleCode == generatedString)` false liefert.
+Aussage:       Das System soll sicherstellen, dass ein Artikelcode systemweit nur einmal vergeben ist, und die Anlage eines Artikels mit bereits vergebenem Code ablehnen.
+Ergebnis:      Ein zweiter Artikel mit identischem `Artikelcode` kann nicht gespeichert werden; die Datenbank weist den Schreibvorgang zurück.
+Belege:
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql`, Zeile 57146: `CREATE UNIQUE NONCLUSTERED INDEX [ARTIK0] ON [dbo].[ARTIK] ([Artikelcode] ASC)` - Begründung: Datenbank-Constraint, das die Eindeutigkeit technisch erzwingt.
+  - [PRIMÄR]   `src/backend/Centron.BL/Warehousing/ArticleBL.cs`, `GenerateArticleCodeRandom()` (Zeilen 2001–2014), Schleifenbedingung `if (!Session.GetGenericDAO<Article>().HasRecord(x => x.ArticleCode == generatedString)) break;` - Begründung: Anwendungsseitige Durchsetzung derselben Regel bei automatischer Codevergabe.
+Prüfidee:      Zwei Artikel mit identischem Artikelcode anzulegen versuchen; der zweite Speichervorgang muss mit einem Eindeutigkeitsfehler scheitern.
+Tracelinks:    StRS-601, SwRS-623
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Eindeutiger Artikelschlüssel ist Grundvoraussetzung für Beleg- und Bestandsführung.
+Status:        belegt
+Modul:         M-47
+
+ID:            SyRS-611
+Titel:         Rangfolge der Preisquellen bei der Positionspreisermittlung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Preisfindung (ReceiptItemPriceBL)
+Vorbedingung:  Für eine Belegposition sind Artikel, optional Kunde, optional Vertrag und optional Sondervereinbarung bekannt.
+Fakt:          `ReceiptItemPriceBL.GetBasePrice` prüft in fester Reihenfolge: (1) `ContractSpecialPrice` über `GetContractSpecialPrice(article, contractI3D)`; nur wenn dieser `null` ist, (2) `CustomerSpecialPrice` über `GetSpecialPrice(article, customer)`; nur wenn auch dieser `null` ist und eine Menge übergeben wurde, (3) Staffelpreis über `GetArticleVolumePrice(article, quantity)`. Ohne Treffer bleibt der Basispreis der kundenspezifische Verkaufspreis aus `GetSellPriceForCustomer(article, customer)`.
+Aussage:       Das System soll den Basispreis einer Belegposition in der Rangfolge Vertragssonderpreis vor Kundensonderpreis vor Mengenstaffelpreis vor Standard-Verkaufspreis ermitteln und dabei nur die erste zutreffende Quelle anwenden.
+Ergebnis:      Bei gleichzeitigem Vorliegen von Vertragssonderpreis und Kundensonderpreis wird ausschließlich der Vertragssonderpreis wirksam; der Staffelpreis greift nur, wenn weder Vertrags- noch Kundensonderpreis existiert.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptItemPriceBL.cs`, `GetBasePrice(...)`, Struktur `if (contractSpecialPrice is not null) { ... } else { CustomerSpecialPrice specialPrice = this.GetSpecialPrice(...); if (specialPrice != null) { ... } else if (quantity != null) { ... GetArticleVolumePrice ... } }` (Zeilen 169–276) - Begründung: Die `if/else`-Verschachtelung ist die durchsetzende Stelle der Rangfolge; sie schließt Mehrfachanwendung technisch aus.
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptItemPriceBL.cs`, Zeile 162: `decimal basePrice = (sellPrice == null) ? this.GetSellPriceForCustomer(article, customer) : sellPrice.Value;` - Begründung: Belegt den Standard-VK als Rückfallwert.
+  - [KONTEXT]  `src/backend/Centron.Interfaces/Accounts/SpecialPrices/SpecialPriceKind.cs`, Kommentar „... extend the calculation in the ReceiptItemPriceBL. Take a look at the GetBasePrice Method there." - Begründung: Bestätigt `GetBasePrice` als zentrale Preisfindungsstelle.
+Prüfidee:      Für Kunde K, Artikel A und Vertrag V gleichzeitig einen Vertragssonderpreis (50 €) und einen Kundensonderpreis (60 €) hinterlegen; Vertragsposition anlegen und prüfen, dass 50 € angesetzt wird.
+Tracelinks:    StRS-602, SyRS-612, SyRS-613, SyRS-614
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Die Rangfolge ist abrechnungsrelevant und muss unverändert erhalten bleiben.
+Status:        belegt
+Modul:         M-52
+
+ID:            SyRS-612
+Titel:         Fünf Berechnungsarten für Kundensonderpreise
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Preisfindung (ReceiptItemPriceBL)
+Vorbedingung:  Für Kunde und Artikel existiert ein gültiger Kundensonderpreis.
+Fakt:          `SpecialPriceKind` definiert genau fünf Werte: `SurchargePurchasePrice` = 0 („Aufschlag auf EK"), `ReduceRecommendedSellPrice` = 1 („Abschlag von EVP"), `FixedPrice` = 2 („Festpreis"), `ReduceSellPrice` = 3 („Abschlag auf VK"), `ReduceListPrice` = 4 („Abschlag auf Listenpreis"). `GetBasePrice` bildet jede Art auf eine Kombination aus Basispreis und Prozentwert ab; ein unbekannter Wert löst `ArgumentOutOfRangeException` aus.
+Aussage:       Das System soll Kundensonderpreise ausschließlich nach den fünf Berechnungsarten Aufschlag auf EK, Abschlag von EVP, Festpreis, Abschlag auf VK und Abschlag auf Listenpreis auswerten und für jede Art die dort definierte Bezugsgröße als Basispreis heranziehen.
+Ergebnis:      Bei `SurchargePurchasePrice` ist der Basispreis der Einkaufspreis und der Prozentwert wird als negativer Rabatt (Aufschlag) angesetzt; bei `FixedPrice` ist der Basispreis der hinterlegte Wert; bei `ReduceSellPrice` bleibt der kundenspezifische VK Basis und der Wert wirkt als Rabatt.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptItemPriceBL.cs`, `switch (specialPrice.Kind)` (Zeilen 235–257), u. a. `case SpecialPriceKind.SurchargePurchasePrice: basePrice = purchaseBasePrice; discountAsPercentage -= specialPrice.PricePremium; break;` und `default: throw new ArgumentOutOfRangeException();` - Begründung: Durchsetzende Stelle; die Vorzeichenbehandlung je Art ist hier abschließend festgelegt.
+  - [PRIMÄR]   `src/backend/Centron.Interfaces/Accounts/SpecialPrices/SpecialPriceKind.cs`, Enum mit `[Description(...)]`-Attributen - Begründung: Abschließende Definition des zulässigen Wertebereichs.
+  - [SEKUNDÄR] `src/backend/Centron.DAO/Mappings/Accounts/SpecialPrices/AccountSpecialPriceMaps.cs`, `this.Map(m => m.ValueKind).Column("Basis").CustomType<SpecialPriceKind>()` - Begründung: Belegt die Persistierung der Art in Spalte `Basis`.
+Prüfidee:      Für einen Artikel mit EK 100 einen Sonderpreis `SurchargePurchasePrice` mit Wert 20 anlegen und prüfen, dass die Position mit Basispreis 100 und Rabatt −20 % (= 120 €) bepreist wird.
+Tracelinks:    StRS-602, SyRS-611, SwRS-624
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Die Berechnungsarten sind fakturarelevant und im Bestand referenziert.
+Status:        belegt
+Modul:         M-52
+
+ID:            SyRS-613
+Titel:         Trefferreihenfolge und Gültigkeitsprüfung innerhalb der Kundensonderpreise
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Preisfindung (ReceiptItemPriceBL)
+Vorbedingung:  Für den Kunden existieren mehrere Sonderpreissätze auf Artikel- und Warengruppenebene.
+Fakt:          `ReceiptItemPriceBL.GetSpecialPrice` filtert zunächst auf Gültigkeit (`ValidFrom == null || ValidFrom.Value.Date <= DateTime.Today` und `ValidTo == null || ValidTo.Value.Date >= DateTime.Today`) und prüft dann in dieser Reihenfolge: exakter Artikeltreffer, danach Warengruppe **und** Unterwarengruppe, danach Warengruppe ohne Unterwarengruppe. Zusätzlich wird bei Konzernstrukturen über `GetCompanyGroupCustomerForReceiptData(customer)` der Konzern-Kunde als Preisträger herangezogen.
+Aussage:       Das System soll aus den zeitlich gültigen Sonderpreisen eines Kunden zuerst einen artikelgenauen Satz, hilfsweise einen Satz für Warengruppe plus Unterwarengruppe und hilfsweise einen Satz für die Warengruppe allein anwenden; bei Konzernzugehörigkeit sind die Sonderpreise des Konzernkunden maßgeblich.
+Ergebnis:      Existiert für den Artikel ein eigener Sonderpreis, bleibt ein gleichzeitig vorhandener Warengruppensonderpreis wirkungslos. Abgelaufene oder noch nicht begonnene Sätze werden nicht berücksichtigt.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptItemPriceBL.cs`, `GetSpecialPrice(IPricedArticle, Customer)` (Zeilen 588–629): Filter `validSpecialPrices` sowie die drei aufeinanderfolgenden `if (…Any()) return …First();`-Blöcke - Begründung: Durchsetzende Stelle sowohl der Gültigkeitsprüfung als auch der Spezialitätsreihenfolge.
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptItemPriceBL.cs`, Zeile 595: `var customerForReceiptData = this.GetCompanyGroupCustomerForReceiptData(customer) ?? customer;` - Begründung: Legt den Preisträger bei Konzernstrukturen fest.
+  - [SEKUNDÄR] `src/backend/Centron.BL/Accounts/SpecialPrices/AccountSpecialPriceBL.cs`, `GetAccountSpecialPrices(...)` Filter `filter.ShowOnlyActive` mit `f.ValidTo == null || f.ValidTo.Value >= DateTime.Now.Date` - Begründung: Zeigt dieselbe Gültigkeitssemantik in der Verwaltungssicht.
+Prüfidee:      Für Kunde K je einen gültigen Sonderpreis auf Artikel A (Festpreis 10 €) und auf dessen Warengruppe (Festpreis 20 €) anlegen; Position mit A muss 10 € ergeben.
+Tracelinks:    StRS-602, SyRS-611, SwRS-624, SwRS-625
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Spezialitätsregel ist abrechnungsrelevant.
+Status:        belegt
+Modul:         M-52
+
+ID:            SyRS-614
+Titel:         Vier Verkaufspreisstufen je Artikel mit kundenbezogener Preislistenzuordnung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Preisfindung / Artikelverwaltung
+Vorbedingung:  Der Artikel besitzt gefüllte Preisfelder; dem Kunden ist eine Preisliste zugeordnet.
+Fakt:          `dbo.ARTIK` führt die Spalten `VK_1` bis `VK_4`. `ReceiptItemPriceBL.GetSellPriceForCustomer(price1..price4, int? priceList)` bildet `priceList` 0→price1, 1→price2, 2→price3, 3→price4 ab und liefert für jeden anderen Wert price1. Der so gewählte Preis wird zusätzlich mit dem Währungsfaktor des Artikels multipliziert.
+Aussage:       Das System soll je Artikel vier Verkaufspreisstufen führen und bei der Preisermittlung genau die durch das Preislistenkennzeichen des Kunden bestimmte Stufe verwenden; bei fehlender oder unbekannter Zuordnung soll die erste Stufe gelten.
+Ergebnis:      Ein Kunde mit Preisliste 2 erhält den Wert aus `VK_3`; ein Kunde ohne Preislistenzuordnung erhält `VK_1`.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptItemPriceBL.cs`, `GetSellPriceForCustomer(decimal price1, decimal price2, decimal price3, decimal price4, int? priceList)` (Zeilen 482–497), `switch (priceList ?? 0)` mit `default: return price1;` - Begründung: Durchsetzende Stelle der Preislistenauswahl inklusive Rückfallregel.
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql`, `CREATE TABLE [dbo].[ARTIK]`, Spalten `[VK_1] [float] NULL` bis `[VK_4] [float] NULL` - Begründung: Belegt die vier Preisstufen im Datenmodell.
+  - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptItemPriceBL.cs`, `GetSellPriceForCustomer(IPricedArticle, Customer)` (Zeilen 571–579) mit `price * currencyFactor` - Begründung: Belegt die Währungsumrechnung als Teil des Verkaufspreises.
+Prüfidee:      Artikel mit VK_1=100, VK_3=80 anlegen, Kunde auf Preisliste 2 setzen und prüfen, dass die Belegposition mit 80 bepreist wird.
+Tracelinks:    StRS-601, SyRS-611
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Preislistenlogik ist im Bestand fest verankert und fakturarelevant.
+Status:        belegt
+Modul:         M-47
+
+ID:            SyRS-615
+Titel:         Aufschlagsstaffel der Warengruppe bestimmt VK, EVP und Mindestpreis
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Artikelkalkulation
+Vorbedingung:  Der Artikel ist einer Warengruppe (bzw. Unterwarengruppe) mit mindestens einer Aufschlagsstaffel zugeordnet und besitzt einen Einkaufspreis.
+Fakt:          `ArticleBL.CalculateArticleMarkups` wählt aus den Staffeln denjenigen Satz mit dem größten `TillEk`, der noch kleiner oder gleich dem Einkaufspreis des Artikels ist, und berechnet damit `Price1..Price4 = PurchasePrice * (VkXProcent / 100 + 1)`, `EVP = PurchasePrice * (MarkupEVKProcent / 100 + 1)` sowie `MinPrice = PurchasePrice * (MarkupMinPriceProcent / 100 + 1)`. Ohne passenden Staffelsatz bleiben die bisherigen Artikelpreise unverändert.
+Aussage:       Das System soll die Verkaufspreise, den empfohlenen Verkaufspreis und den Mindestpreis eines Artikels aus dem Einkaufspreis und dem größten passenden Staffelsatz der zugeordneten Warengruppe berechnen; existiert kein passender Staffelsatz, sollen die bestehenden Preise unverändert bleiben.
+Ergebnis:      Bei EK = 100 und Staffelsatz `TillEk = 0` mit `Vk1Procent = 30` ergibt sich VK1 = 130; die Unterwarengruppenstaffel hat Vorrang, wenn der Artikel einer Unterwarengruppe zugeordnet ist.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Warehousing/ArticleBL.cs`, `CalculateArticleMarkups(Article, IList<MaterialMarkup>)`, Zeile 3566: `MaterialMarkup selMarkup = markups.Where(x => x.TillEk <= article.PurchasePrice).OrderByDescending(x => x.TillEk).FirstOrDefault();` und Zeilen 3569–3575 - Begründung: Durchsetzende Stelle der Staffelauswahl und Preisformel.
+  - [PRIMÄR]   `src/backend/Centron.BL/Warehousing/ArticleManagement/ArticleImportBL.cs`, `SetSellPrices(...)` Zeilen 1635–1662: Vorrangprüfung `if (articleCompact.SecondaryMaterialGroupI3D > 0) { … SecondaryMaterialMarkup … } else { … MaterialMarkup … }` - Begründung: Belegt den Vorrang der Unterwarengruppenstaffel gegenüber der Warengruppenstaffel.
+  - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Warehousing/MaterialGroupManagement/ViewModel/RebookMaterialGroupDialogViewModel.cs`, Meldungstext „Bitte beachten Sie das unter Umständen die Preise VK 1 bis VK 4, EVP und der Mindestpreis verändert werden." - Begründung: Bestätigt den Umfang der betroffenen Preisfelder aus Anwendersicht.
+Prüfidee:      Zwei Staffelsätze (TillEk 0 → 30 %, TillEk 500 → 20 %) anlegen; Artikel mit EK 600 neu kalkulieren und VK1 = 720 prüfen.
+Tracelinks:    StRS-604, SwRS-629, SwRS-627
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zentrale Kalkulationsregel mit direkter Ergebniswirkung.
+Status:        belegt
+Modul:         M-49
+
+ID:            SyRS-616
+Titel:         Automatischer Preisupdate-Lauf aus Distributor-Artikeldaten
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Systemdienst (c-entron Systembenutzer)
+Vorbedingung:  Einstellung `AutomaticallyPriceUpdateAndDistributorsAndAutomaticallyChanges` ist aktiv und enthält eine priorisierte Distributorliste; die Startzeit ist erreicht.
+Fakt:          `ArticleImportBL.AutomaticPriceUpdate()` ermittelt über `GetDistributorArticleToUpdate` je Artikel den Distributorpreis mit der besten Priorität (Verknüpfung `Artik.EANCode = HerstellerArtik.EANCODE` bzw. `Artik.Hersteller = HerstellerArtik.CODE`, Priorität aus der Reihenfolge der konfigurierten Distributoren), aktualisiert `Artik.EK` und – falls konfiguriert – `VK_1..VK_4`, `Mindestpreis` und `EVK` und schreibt jede Änderung über `ArticleLogBL.WriteLog(...)` mit Alt-/Neuwert und Differenz fort. `NeedTodayUpdate` verhindert einen zweiten Lauf am selben Tag.
+Aussage:       Das System soll Einkaufs- und optional Verkaufspreise von Artikeln einmal je Tag automatisch aus den Daten des höchstpriorisierten Distributors aktualisieren und jede Preisänderung mit Alt- und Neuwert protokollieren.
+Ergebnis:      Nach dem Lauf entspricht `Artik.EK` dem Preis des höchstpriorisierten Distributors mit passendem EAN- oder Herstellercode; für jede geänderte Preisspalte existiert ein Eintrag in `ArtikLog`.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Warehousing/ArticleManagement/ArticleImportBL.cs`, `AutomaticPriceUpdate()` Zeilen 1830–1874: Auswahl `.OrderBy(f => f.Prio).FirstOrDefault()`, Abbruch `if (articleCompact.PurchasePrice == distributorArticlePrice.PurchasePrice) continue;`, Aufruf `RefreshArticle(articleCompact, appUser.Employee.I3D, withSellPrice)` und `articleLogBL.WriteLog(..., ArticleLogKind.PurchasePrice, appUser)` - Begründung: Durchsetzende Stelle der Preisübernahme und der Protokollpflicht.
+  - [PRIMÄR]   `src/backend/Centron.BL/Warehousing/ArticleManagement/ArticleImportBL.cs`, `NeedTodayUpdate(List<string> startTime, int employeeI3D)` (Zeilen 1721–1733): `return !this.Session.GetGenericDAO<ArticleLog>().HasRecord(f => f.EmployeeI3D == employeeI3D && f.Date > DateTime.Today && f.Kind == ArticleLogKind.PurchasePrice);` - Begründung: Erzwingt genau einen Lauf pro Tag.
+  - [SEKUNDÄR] `src/backend/Centron.BL/Administration/Settings/AppSettingsConst.cs`, Zeile 2552: `AutomaticallyPriceUpdateAndDistributorsAndAutomaticallyChanges = 1182` - Begründung: Belegt den Konfigurationsschalter.
+Prüfidee:      Distributorartikel mit abweichendem HEK zu einem Artikel mit gleichem EAN anlegen, Lauf auslösen und prüfen, dass `Artik.EK` übernommen wurde und genau ein `ArtikLog`-Eintrag mit Alt-/Neuwert existiert; zweiten Lauf am selben Tag auslösen und prüfen, dass keine weitere Änderung erfolgt.
+Tracelinks:    StRS-603, SyRS-615, SwRS-627, SwRS-628
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Automatische EK-Pflege ist margenrelevant und protokollpflichtig.
+Status:        belegt
+Modul:         M-48
+
+ID:            SyRS-617
+Titel:         Artikeleinheiten mit UNECE-Code und Zeitfaktor
+Ebene:         SyRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Stammdatenpflege
+Vorbedingung:  Die Einheitenverwaltung ist geöffnet.
+Fakt:          `dbo.ArtikelEinheit` führt `KurzText`, `Bezeichnung`, `VPE`, `Standard`, `Status`, `Zeiteinheit` und `FaktorZuSekunde` sowie `UNECECode nvarchar(10)`. `SupportedUNECECodes.Codes` definiert die acht unterstützten Codes SEC (1 s), MIN (60 s), HUR (3600 s), DAY (86400 s), H87, LS, MTR und KMT; nur die ersten vier tragen einen Sekundenfaktor und gelten damit als Zeiteinheit (`IsTimeUnit => FactorToSeconds.HasValue`).
+Aussage:       Das System soll Artikeleinheiten mit Kurztext, Bezeichnung, Verpackungseinheit und optionalem UNECE-Code führen und Zeiteinheiten zusätzlich über einen Umrechnungsfaktor auf Sekunden abbilden.
+Ergebnis:      Jede aktive Einheit ist mit Kurztext und Bezeichnung verfügbar; Zeiteinheiten liefern einen konsistenten Sekundenfaktor für Leistungs- und Zeitabrechnung.
+Belege:
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql`, `CREATE TABLE [dbo].[ArtikelEinheit]` (Zeile 10182 ff.) mit `[Zeiteinheit] [int] NULL`, `[FaktorZuSekunde] [int] NULL`, `[UNECECode] [nvarchar](10) NULL` - Begründung: Belegt das Datenmodell der Einheiten.
+  - [PRIMÄR]   `src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleUnitManagement/ViewModel/SupportedUNECECodes.cs`, Liste `Codes` und `record UNECECodeInfo(string Code, string Description, int? FactorToSeconds) { public bool IsTimeUnit => FactorToSeconds.HasValue; }` - Begründung: Abschließende Definition des zulässigen Wertebereichs und der Zeiteinheitsregel.
+  - [SEKUNDÄR] `SSMS_DB_SCHEMA.sql`, Zeile 14918: `INNER JOIN ArtikelEinheit ae on ae.I3D = a.Einheit and ae.Zeiteinheit = 1 and ae.Status = 1` - Begründung: Belegt die Auswertung des Zeiteinheitskennzeichens in Datenbanksichten.
+Prüfidee:      Einheit „Stunde" mit UNECE-Code HUR und Faktor 3600 anlegen; prüfen, dass sie in Abfragen mit `Zeiteinheit = 1` erscheint.
+Tracelinks:    StRS-601, SwRS-630
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - UNECE-Codes sind für elektronische Rechnungsformate erforderlich.
+Status:        belegt
+Modul:         M-50
+
+ID:            SyRS-618
+Titel:         Konfigurierbare Eindeutigkeit von Seriennummern und Barcodes
+Ebene:         SyRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Lager / Barcodeverwaltung
+Vorbedingung:  Eine neue Seriennummer soll zu einem Artikel angelegt werden.
+Fakt:          `BarcodeBL.ValidateNewBarcode(int articleI3D, string barcode)` wertet zwei Einstellungen aus: bei `SameArticleCanHaveSameSerialNumber` (ID 441) wird jede Seriennummer akzeptiert; sonst wird geprüft, ob bereits ein Barcode mit gleichem `Code` existiert, dessen Status weder `ManuallyBookedOut` noch `Deactivated` ist – bei `DifferentArticleCanHaveSameSerialNumber` (ID 440) eingeschränkt auf denselben Artikel. Auf der Tabelle `dbo.Barcode` existiert kein eindeutiger Index über die Spalte `Barcode`.
+Aussage:       Das System soll die Eindeutigkeit von Seriennummern über zwei Konfigurationsschalter steuern und die gewählte Regel bei jeder Neuanlage einer Seriennummer anwenden.
+Ergebnis:      Bei Standardkonfiguration wird eine bereits aktiv vergebene Seriennummer abgelehnt; ausgebuchte oder deaktivierte Seriennummern blockieren die Neuvergabe nicht.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Warehousing/BarcodeBL.cs`, `ValidateNewBarcode(int, string)` (Zeilen 171–191), Ausdruck `a => a.Code == barcode && !(a.State == (int)BarcodeState.ManuallyBookedOut || a.State == (int)BarcodeState.Deactivated)` - Begründung: Durchsetzende Stelle der Eindeutigkeitsprüfung inklusive Statusausnahmen.
+  - [PRIMÄR]   `src/backend/Centron.BL/Administration/Settings/AppSettingsConst.cs`, Zeilen 2518 und 2522 (`DifferentArticleCanHaveSameSerialNumber = 440`, `SameArticleCanHaveSameSerialNumber = 441`) - Begründung: Belegt die konkreten Konfigurationsschalter.
+  - [SEKUNDÄR] `SSMS_DB_SCHEMA.sql`, Indizes auf `[dbo].[Barcode]` (Zeilen 58653 ff.: nur nicht-eindeutige Indizes auf `AufPosI3D`, `Auftragsnummer`, `LagerI3D`, `LiefPosI3D`, `RechPosI3D`) - Begründung: Belegt, dass die Eindeutigkeit ausschließlich in der Anwendungsschicht durchgesetzt wird.
+Prüfidee:      Bei Standardeinstellung dieselbe Seriennummer zweimal für denselben Artikel anlegen; der zweite Versuch muss mit „SN existiert bereits" abgelehnt werden.
+Tracelinks:    StRS-601, SwRS-631, SwRS-632
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - Die Eindeutigkeit wird nur anwendungsseitig geprüft; ein Datenbank-Constraint fehlt, sodass Fremdzugriffe Dubletten erzeugen können.
+Status:        belegt
+Modul:         M-51
+
+ID:            SyRS-619
+Titel:         Artikel- und Lieferantensuche als wiederverwendbare Auswahldialoge
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Anwender in beliebigem Beleg- oder Stammdatenkontext
+Vorbedingung:  Ein Modul benötigt die Auswahl eines Artikels oder eines Herstellers/Lieferanten.
+Fakt:          `SearchArticleViewModel` implementiert `IDialogWindow` und `ICloseDialogWindow`, trägt den Titel „Artikelauswahl", nimmt einen `ArticleCompactFilter` als Vorbelegung entgegen und liefert die Auswahl seitenweise über `ListThroughPaging<ArticlePreview>`. `SearchSupplierViewModel` implementiert dieselben Schnittstellen, trägt den Titel „Herstellersuche" und lädt über `ISupplierLogic.SearchSuppliers(searchText, 1, int.MaxValue)`.
+Aussage:       Das System soll die Auswahl von Artikeln und Lieferanten über zentrale, von beliebigen Modulen aufrufbare Dialoge bereitstellen, die einen vorbelegbaren Filter entgegennehmen und das ausgewählte Objekt an den Aufrufer zurückgeben.
+Ergebnis:      Aufrufende Module erhalten ein einheitlich gefiltertes Auswahlergebnis; die Artikelauswahl liefert Ergebnisse seitenweise, um große Trefferlisten zu beherrschen.
+Belege:
+  - [PRIMÄR]   `src/centron/Centron.WPF.UI/Modules/Warehousing/SearchArticle/ViewModel/SearchArticleViewModel.cs`, Klassendeklaration `SearchArticleViewModel : ViewModelBase, IDialogWindow, ICloseDialogWindow`, Konstruktor `SearchArticleViewModel(ArticleCompactFilter articleCompactFilter = null)` und `public string DialogTitle => "Artikelauswahl";` - Begründung: Belegt die Dialogschnittstelle und die Filterübergabe.
+  - [PRIMÄR]   `src/centron/Centron.WPF.UI/Modules/Warehousing/SupplierSearch/ViewModel/SearchSupplierViewModel.cs`, `public string DialogTitle => "Herstellersuche";` und `LoadSuppliers(string searchText)` - Begründung: Belegt den zweiten Auswahldialog mit identischem Schnittstellenmuster.
+  - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Warehousing/SearchArticle/DataPager/ListThroughPaging.cs` - Begründung: Belegt die seitenweise Ergebnisbereitstellung.
+Prüfidee:      Artikelauswahl aus zwei verschiedenen Modulen mit unterschiedlichem Vorfilter öffnen und prüfen, dass jeweils nur die gefilterten Artikel erscheinen und das ausgewählte Objekt an das aufrufende Modul zurückgegeben wird.
+Tracelinks:    StRS-601, SwRS-639
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Wiederverwendbare Auswahldialoge vermeiden redundante Suchimplementierungen.
+Status:        belegt
+Modul:         M-55
+
+ID:            SyRS-620
+Titel:         Preisermittlung importierter Vertragspositionen über die zentrale Preisfindung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertragsimport (CustomGatewayBL)
+Vorbedingung:  Eine Importdatei mit Kundennummer, Vertragsnummer, Artikelcode und optional Preisen wurde eingelesen.
+Fakt:          `CustomGatewayBL` löst je Importzeile Artikel, Vertrag und Kunde auf, ermittelt über `ReceiptItemPriceBL.GetSpecialAgreement(...)` eine gültige Sondervereinbarung und berechnet den Einkaufspreis mit `GetPurchaseBasePrice(...)` sowie den Verkaufspreis mit `GetBasePrice(...)`; anschließend gilt `price = basePrice * (1m - (discount / 100m))`. Ob Importpreise oder ermittelte Preise gewinnen, steuern die Schalter `IgnoreImportPurchasePrices`, `IgnoreImportRetailPrices` und `UseSpecialPriceForArticleIfAvailable`.
+Aussage:       Das System soll für importierte Vertragspositionen Einkaufs- und Verkaufspreise über dieselbe Preisfindung ermitteln wie für manuell erfasste Belegpositionen und dabei je Importdefinition konfigurierbar entscheiden, ob Preise aus der Datei oder aus der Preisfindung maßgeblich sind.
+Ergebnis:      Importierte Positionen tragen konsistente Preise; bei aktiviertem `UseSpecialPriceForArticleIfAvailable` schlägt ein hinterlegter Kunden- oder Vertragssonderpreis den Dateipreis.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Gateway/CustomGatewayBL.cs`, Zeilen 186–210: `var specialAgreement = ... priceBL.GetSpecialAgreement(article.ArticleI3D, customer, CentronObjectKindNumeric.InvoiceClass)`, `priceBL.GetPurchaseBasePrice(art, warehouse: null, specialAgreement: specialAgreement, quantity: article.Quantity, contractI3D)` und `var (basePrice, discount) = priceBL.GetBasePrice(...); var price = basePrice * (1m - (discount / 100m));` - Begründung: Durchsetzende Stelle; belegt die Wiederverwendung der zentralen Preisfindung und die konkrete Preisformel.
+  - [PRIMÄR]   `src/backend/Centron.BL/Gateway/CustomGatewayBL.cs`, Zeile 191: Bedingung `article.Import.IgnoreImportPurchasePrices || (… && article.PurchasePrice <= 0)` - Begründung: Legt fest, wann der Dateipreis verworfen und neu ermittelt wird.
+  - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Sales/SpecialArticleToContractImport/SpecialArticleToContractImportColumnKind.cs`, Werte `Price`, `PurchasePrice`, `UnitPrice` - Begründung: Belegt, dass Preise auch aus der Datei stammen können.
+Prüfidee:      Importdatei mit Preis 0 für einen Artikel mit Kundensonderpreis einlesen; prüfen, dass die erzeugte Vertragsposition den Sonderpreis und nicht 0 trägt.
+Tracelinks:    StRS-606, SyRS-611, SwRS-635
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Konsistente Preisfindung über alle Erfassungswege ist abrechnungskritisch.
+Status:        belegt
+Modul:         M-53
+
+ID:            SyRS-621
+Titel:         Zeitraumgefilterte Aktionspreise im Preisspiegel
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Einkauf / Vertrieb
+Vorbedingung:  Zu einem Artikel sind Aktionspreise erfasst; der Preisspiegel wird geöffnet.
+Fakt:          `ActionPrice` (Tabelle `HerstellerArtikAktionspreis`) trägt `Distributor`, `Preis`, `GueltigAb`, `GueltigBis`. `PriceMatrixViewModel.GetPriceItemsFromArticleActionPrices` ermittelt den Artikel zuerst über den Herstellercode, hilfsweise über den EAN-Code, und übernimmt anschließend nur Aktionspreise mit `f.EffectiveFrom.StartOfDay() <= DateTime.Now && f.EffectiveUntil >= DateTime.Now`.
+Aussage:       Das System soll Aktionspreise eines Artikels als eigene Preisquelle im Preisspiegel anzeigen und dabei ausschließlich Preise berücksichtigen, deren Gültigkeitszeitraum den aktuellen Zeitpunkt einschließt.
+Ergebnis:      Abgelaufene oder zukünftige Aktionspreise erscheinen nicht im Preisspiegel; gültige erscheinen mit Distributor, Preis und Zeitraum.
+Belege:
+  - [PRIMÄR]   `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/PriceMatrix/PriceMatrixViewModel.cs`, `GetPriceItemsFromArticleActionPrices(...)` Zeile 450: `.Where(f => f.EffectiveFrom.StartOfDay() <= DateTime.Now && f.EffectiveUntil >= DateTime.Now) // Only valid action-prices` - Begründung: Durchsetzende Stelle des Zeitraumfilters.
+  - [PRIMÄR]   `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/PriceMatrix/PriceMatrixViewModel.cs`, Zeilen 427–444: Artikelermittlung zuerst über `ArticleCompactFilter { ManufacturerCode = ... }`, dann über `ArticleCompactFilter { EANCode = ... }` - Begründung: Legt die Zuordnungsreihenfolge Herstellercode vor EAN fest.
+  - [KONTEXT]  `docs/reference/receipts/actionprice-system.md`, Abschnitt „Display Rules" - Begründung: Interne Dokumentation bestätigt die Filterregel.
+Prüfidee:      Zwei Aktionspreise anlegen (einer mit `GueltigBis` gestern, einer mit Zeitraum heute) und prüfen, dass nur der zweite im Preisspiegel erscheint.
+Tracelinks:    StRS-601, SwRS-638, SwRS-640
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zeitbefristete Aktionspreise sind einkaufsseitig etabliert.
+Status:        belegt
+Modul:         M-47

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_work/A7_StRS.md

@@ -0,0 +1,167 @@
+ID:            StRS-701
+Titel:         Mehrlagerfähige Artikelbestandsführung mit Hauptlager und Nebenlagern
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Lagermitarbeiter / Warenwirtschaft
+Vorbedingung:  Ein Artikel ist angelegt und als lagerwirksam gekennzeichnet (ARTIK.Abbuchung = 'J').
+Fakt:          Der Bestand wird an zwei getrennten Stellen geführt: im Hauptlager als Spalte `ARTIK.Menge` und je Nebenlager als Satz in `NebenlagerArtikel` (Spalte `Bestand`). `ArticleStockRepository.UpdateArticleStock` verzweigt anhand des übergebenen Nebenlager-Schlüssels; die Kennung `-1` bzw. `null` steht durchgängig für das Hauptlager.
+Aussage:       Das System soll den Bestand eines Artikels getrennt je Lager führen, wobei genau ein Hauptlager (Kennung -1) und beliebig viele Nebenlager unterstützt werden.
+Ergebnis:      Für jeden lagerwirksamen Artikel ist die Menge je Lager abfragbar; Buchungen wirken ausschließlich auf das adressierte Lager.
+Belege:
+  - [PRIMÄR]   C:\DEV\MasterArbeit\QuellCode\CentronERP\src\backend\Centron.DAO\Repositories\Warehousing\StockManagement\ArticleStockRepository.cs - Klasse `ArticleStockRepository`, Methode `UpdateArticleStock(int articleI3D, int? articleSecondaryStorageI3D, double quantity, bool increaseQuantity = false)`; die durchsetzende Verzweigung lautet `if (articleSecondaryStorageI3D is not > 0)` und bucht in diesem Fall auf `ArticleMainStock` (Tabelle ARTIK, Spalte Menge), sonst auf den Nebenlagersatz. Begründung: Das ist die einzige Stelle, an der die Lagerzuordnung einer Bestandsbuchung entschieden wird.
+  - [PRIMÄR]   C:\DEV\MasterArbeit\QuellCode\CentronERP\SSMS_DB_SCHEMA.sql - `CREATE TABLE [dbo].[NebenlagerArtikel]` mit den Spalten `[NebenlagerI3D]`, `[ArtikelI3D]`, `[Bestand]`, `[Mindestbestand]`, `[Reparaturbestand]`. Begründung: Belegt die physische Trennung der Bestandsführung je Nebenlager.
+  - [SEKUNDÄR] C:\DEV\MasterArbeit\QuellCode\CentronERP\src\backend\Centron.BL\Logistics\Warehousing\StockBL.cs - `StockBL.GetMainWarehouse()` gibt `this.GetWarehouse(-1)` zurück, `GetWarehouseCaption` liefert bei leerem Ergebnis den Text "Hauptlager". Begründung: Bestätigt -1 als feste Kennung des Hauptlagers.
+Prüfidee:      Artikel in Hauptlager und zwei Nebenlager einbuchen; prüfen, dass `ARTIK.Menge` und die jeweiligen `NebenlagerArtikel.Bestand` unabhängig voneinander fortgeschrieben werden und eine Buchung auf Nebenlager A den Bestand in Nebenlager B unverändert lässt.
+Tracelinks:    SyRS-702, SwRS-703, SwRS-704, SwRS-705
+Konsolidierung: Kandidat: StRS-701 / SwRS-704 - Tabelle `Nebenlager` (Legacy) und Tabelle `Warehouses` (neu) bilden dasselbe fachliche Konzept "Lager" doppelt ab.
+Übernahmewürdigkeit: übernehmen - Mehrlagerfähigkeit ist tragende Fachanforderung der Warenwirtschaft.
+Status:        belegt
+Modul:         M-58
+
+ID:            StRS-706
+Titel:         Inventur als Stichtagszählung mit Komplett- und Teilinventur
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Inventurverantwortlicher
+Vorbedingung:  Eine Inventur ist angelegt und befindet sich im Status Open oder OpenWithoutBC; mindestens ein Lager ist zur Zählung ausgewählt.
+Fakt:          Beim Lagerabschluss unterscheidet das System Komplett- und Teilinventur. Nur bei Komplettinventur werden Bestände nicht gezählter, lagerwirksamer Artikel auf 0 gesetzt; bei Teilinventur bricht die Methode vor der Nullsetzung ab.
+Aussage:       Das System soll Inventuren wahlweise als Komplettinventur oder als Teilinventur durchführen, wobei ausschließlich bei der Komplettinventur nicht gezählte Bestände des abgeschlossenen Lagers auf null gesetzt werden.
+Ergebnis:      Nach Lagerabschluss entsprechen die Bestände des Lagers dem Zählergebnis; bei Teilinventur bleiben nicht gezählte Artikel unverändert.
+Belege:
+  - [PRIMÄR]   C:\DEV\MasterArbeit\QuellCode\CentronERP\src\backend\Centron.DAO\Repositories\Warehousing\InventoryManagement\InventoryRepository.cs - Klasse `InventoryRepository`, Methode `CloseStorageUpdateArticleStockFromNotScannedArticles(int inventoryI3D, int storageI3D, bool isCompleteInventory)`; die durchsetzende Bedingung ist `if (!isCompleteInventory) return;` mit dem Kommentar "Die Bestände dürfen bei einer Teilinventur von einem anderen Lager nicht verändert werden." Anschließend `UPDATE Artik SET Menge = 0 ... WHERE a.Menge <> 0 AND a.Abbuchung = 'J' AND NOT (a.I3D in (SELECT ArtikelI3D FROM InventurBuchungen ...))`. Begründung: Genau diese Bedingung trennt Komplett- von Teilinventur.
+  - [PRIMÄR]   C:\DEV\MasterArbeit\QuellCode\CentronERP\src\webservice\Centron.WebServices.Core\Entities\Warehousing\InventoryManagement\InventoryType.cs - `enum InventoryType { Partial = 1, PartialAllStorage = 2, Complete = 3, CompleteAllStorage = 4 }`. Begründung: Definiert die zulässigen Inventurarten.
+  - [SEKUNDÄR] C:\DEV\MasterArbeit\QuellCode\CentronERP\src\centron\Centron.WPF.UI\Modules\Warehousing\Inventory\ViewModels\WizardViewModels\ResultViewModel.cs - `ResultViewModel.FinalizeInventory()` übergibt `FinalizeInventoryOption == InventoryType.Complete || FinalizeInventoryOption == InventoryType.CompleteAllStorage` als Parameter `isCompleteInventory`. Begründung: Zeigt die Abbildung der UI-Auswahl auf die Fachregel.
+Prüfidee:      Teilinventur für Lager A abschließen, in der ein lagerführender Artikel nicht gezählt wurde: dessen Bestand muss unverändert bleiben. Denselben Fall als Komplettinventur abschließen: der Bestand muss auf 0 stehen und ein Satz in `InventurBuchungen` mit `Nachher = 0` existieren.
+Tracelinks:    SyRS-707, SwRS-708
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - handelsrechtlich erforderliche Bestandsaufnahme; die Unterscheidung Komplett/Teil ist fachlich zwingend.
+Status:        belegt
+Modul:         M-59
+
+ID:            StRS-709
+Titel:         Kommissionierung nur für ausdrücklich kommissionierpflichtige Artikel
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Lagermitarbeiter (Kommissionierer)
+Vorbedingung:  Ein Auftrag befindet sich im aktiven Status (AufKopf.Status = 1) und enthält mindestens eine Position.
+Fakt:          Die Kommissionierungssicht `cvw_ConsignmentOrder` nimmt nur Auftragspositionen auf, deren Artikel `ARTIK.Kommisionieren = 1` gesetzt hat und deren Warengruppe ungleich dem in `Stammdat` unter I3D 421 hinterlegten Wert ist. Die Positionssicht `cvw_ConsignmentOrderPosition` filtert zusätzlich auf `P.Art = 1`.
+Aussage:       Das System soll ausschließlich Auftragspositionen zur Kommissionierung anbieten, deren Artikel als kommissionierpflichtig gekennzeichnet ist und deren Warengruppe nicht der konfigurierten Ausschlusswarengruppe entspricht.
+Ergebnis:      Aufträge ohne kommissionierpflichtige Artikel erscheinen nicht in der Kommissionierliste; Dienstleistungs- bzw. Ausschlusswarengruppen werden nicht kommissioniert.
+Belege:
+  - [PRIMÄR]   C:\DEV\MasterArbeit\QuellCode\CentronERP\SSMS_DB_SCHEMA.sql - `CREATE VIEW [dbo].[cvw_ConsignmentOrder]`, durchsetzende Bedingung: `WHERE (A.Kommisionieren = 1) AND (A.Warengruppe <> (SELECT Wert FROM dbo.Stammdat WHERE (I3D = 421)))`. Begründung: Filterbedingung der Datenquelle, auf der die gesamte Kommissionierung aufsetzt.
+  - [PRIMÄR]   C:\DEV\MasterArbeit\QuellCode\CentronERP\src\backend\Centron.DAO\Mappings\Warehousing\Commissioning\ArticelHeaderMaps.cs - Klasse `ArticelHeaderMaps` mit `ReadOnly(); Table("cvw_ConsignmentOrder");`. Begründung: Belegt, dass die Kommissionier-BL ausschließlich über diese gefilterte Sicht liest.
+  - [SEKUNDÄR] C:\DEV\MasterArbeit\QuellCode\CentronERP\src\backend\Centron.DAO\Mappings\Warehousing\ArticleMaps.cs - `Map(aa => aa.Picking).Column("Kommisionieren");`. Begründung: Zeigt die Artikeleigenschaft, die die Kommissionierpflicht steuert.
+Prüfidee:      Auftrag mit einem Artikel anlegen, bei dem `Kommisionieren = 0` ist: Der Auftrag darf im Kommissioniermodul nicht erscheinen. Flag auf 1 setzen: Der Auftrag muss erscheinen.
+Tracelinks:    SyRS-710, SwRS-711
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - verhindert, dass nicht lagerbezogene Positionen den Kommissionierprozess belasten.
+Status:        belegt
+Modul:         M-60
+
+ID:            StRS-717
+Titel:         Versandart als eigenständiges Stammdatum
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Stammdatenverwalter
+Vorbedingung:  Der Benutzer hat die Einstellungsmaske "RMA Versandart" geöffnet.
+Fakt:          Die Versandart ist als Entität `RmaSendKind` auf die Tabelle `VersandArt` gemappt und trägt genau zwei fachliche Felder: `Name` (Spalte Name, Länge 50) und `IsActive` (auf die int-Spalte Status gemappt). Weitere Merkmale wie Gewicht, Kosten oder Dienstleister sind im Stammsatz nicht vorhanden.
+Aussage:       Das System soll Versandarten als eigenständige Stammdaten mit Bezeichnung und Aktiv-Kennzeichen verwalten, die als Versandweg ausgewählt werden können.
+Ergebnis:      Versandarten sind anleg- und deaktivierbar und stehen als Auswahlwerte zur Verfügung.
+Belege:
+  - [PRIMÄR]   C:\DEV\MasterArbeit\QuellCode\CentronERP\src\backend\Centron.DAO\Mappings\CustomerArea\RmaArea\RmaSendKindMaps.cs - Klasse `RmaSendKindMaps`, Konstruktor: `this.Table("VersandArt"); this.Map(m => m.Name).Column("Name").Length(50); this.Map(m => m.IsActive).Column("Status");`. Begründung: Definiert vollständig und abschließend die Felder des Versandart-Stammsatzes.
+  - [PRIMÄR]   C:\DEV\MasterArbeit\QuellCode\CentronERP\SSMS_DB_SCHEMA.sql - `CREATE TABLE [dbo].[Versandart]([I3D] int IDENTITY, [Name] varchar(50) NULL, [Status] int NULL, CONSTRAINT [PK_Versandart] ...)`. Begründung: Bestätigt den Feldumfang auf DB-Ebene.
+  - [SEKUNDÄR] C:\DEV\MasterArbeit\QuellCode\CentronERP\src\centron\Centron.WPF.UI\Modules\Logistic\ShippingMethodSettings\ShippingMethodSettingsView.xaml - Grid mit exakt zwei Spalten: `<dxg:GridColumn FieldName="Name" .../>` und `<dxg:GridColumn FieldName="IsActive" .../>`. Begründung: Die Pflegemaske bietet keine weiteren Felder an.
+Prüfidee:      Neue Versandart anlegen und deaktivieren; prüfen, dass in `VersandArt` ein Satz mit Name und Status entsteht und keine weiteren Attribute erfasst werden können.
+Tracelinks:    SyRS-718, SwRS-719
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Versandartenkatalog wird fachlich benötigt; der aktuelle Feldumfang ist allerdings sehr schmal.
+Status:        belegt
+Modul:         M-63
+
+ID:            StRS-726
+Titel:         Bestellvorschlagsliste als Beschaffungsauslöser
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Einkäufer
+Vorbedingung:  Der Benutzer besitzt das Recht SHOW_ORDER_SUGGESTION_LIST und das System besitzt die Lizenz OrderSuggestionList oder Centron.
+Fakt:          Das Modul `OrderSuggestionListAppModuleController` wird in `ModuleRegistration.cs` mit einer Rechte- und einer Lizenzbedingung registriert. Die zugehörige `OrderSuggestionListBL` ermittelt über Roh-SQL beschaffungsbedürftige Artikel je Lager und erzeugt daraus Lieferantenbestellungen.
+Aussage:       Das System soll auf Basis von Beständen, Mindestbeständen, offenen Aufträgen und Zulauf eine Bestellvorschlagsliste erzeugen, aus der Lieferantenbestellungen erstellt werden können.
+Ergebnis:      Der Einkäufer erhält je Artikel und Lager einen Bedarfsvorschlag und kann daraus Bestellungen anlegen.
+Belege:
+  - [PRIMÄR]   C:\DEV\MasterArbeit\QuellCode\CentronERP\src\centron\Centron.WPF.UI\Modules\ModuleRegistration.cs - `ModuleRegistrationItem.For<OrderSuggestionListAppModuleController>(() => Helper.HasRights(UserRightsConst.Purchase.SHOW_ORDER_SUGGESTION_LIST), () => LicenseManager.Instance.HasLicense(LicenseGuids.OrderSuggestionList) || LicenseManager.Instance.HasLicense(LicenseGuids.Centron))`. Begründung: Durchsetzende Stelle für den Modulzugang (Recht und Lizenz).
+  - [PRIMÄR]   C:\DEV\MasterArbeit\QuellCode\CentronERP\src\backend\Centron.BL\Purchasing\OrderSuggestionList\OrderSuggestionListBL.cs - Klasse `OrderSuggestionListBL` mit den SQL-Bausteinen `_sqlArticle`, `_sqlOrder`, `_sqlWH`, `_sqlDistri`; Ermittlung je `ArticleI3D`/`WarehouseI3D`. Begründung: Ort der fachlichen Vorschlagsermittlung.
+  - [KONTEXT]  C:\DEV\MasterArbeit\QuellCode\CentronERP\src\webservice\Centron.WebServices.Core\EntitiesWrongPlace\Administration\Rights\UserRightsConst.cs - `[Obsolete] public const int SHOW_ORDER_SUGGESTION_LIST = 10230;`. Begründung: Das steuernde Recht ist als obsolet markiert, wird aber weiterhin geprüft.
+Prüfidee:      Benutzer ohne Recht 10230 anmelden: Das Modul "Bestellvorschlagsliste" darf nicht erscheinen. Mit Recht und Lizenz muss die Liste Artikel mit Unterdeckung enthalten.
+Tracelinks:    SyRS-727, SwRS-728, SwRS-729
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrale Beschaffungsfunktion; die Obsolet-Markierung des Rechts ist bei einer Neuentwicklung zu bereinigen.
+Status:        belegt
+Modul:         M-66
+
+ID:            StRS-730
+Titel:         Reisekostenabrechnung derzeit nicht ausgeliefert
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Mitarbeiter / Reisekostenprüfer
+Vorbedingung:  Anwendung gestartet, beliebige Rechtekonstellation.
+Fakt:          Die Registrierung des Moduls `TravelExpenseAppModuleController` ist in `ModuleRegistration.cs` auskommentiert; der begleitende Kommentar nennt Grund und Auftraggeber. Gleichzeitig existieren Modulklassen, eine Settings-Maske und zwei getrennte Datenmodelle (`Reisekosten*`-Tabellen und `TravelExpenseCategories`).
+Aussage:       Das System soll Reisekosten und Auslagen von Mitarbeitern erfassen und abrechnen; die vorhandene Implementierung ist jedoch bewusst deaktiviert und nicht produktiv nutzbar.
+Ergebnis:      Das Modul erscheint nicht in der Modulliste; erfasste Daten sind über die Oberfläche nicht erreichbar.
+Belege:
+  - [PRIMÄR]   C:\DEV\MasterArbeit\QuellCode\CentronERP\src\centron\Centron.WPF.UI\Modules\ModuleRegistration.cs - auskommentierter Block: `// SKA : Hide the travel expense module for now. The module is not finished yet. Ordered from Volker Lehnert` gefolgt von `// ModuleRegistrationItem.For<TravelExpenseAppModuleController>(// () => Helper.HasAnyRight(UserRightsConst.Purchase.TRAVEL_EXPENSE_ADMIN)),`. Begründung: Die Abwesenheit des Registrierungseintrags ist die durchsetzende Stelle, die das Modul unerreichbar macht.
+  - [SEKUNDÄR] C:\DEV\MasterArbeit\QuellCode\CentronERP\src\centron\Centron.WPF.UI\Modules\Purchasing\TravelExpense\TravelExpenseAppModuleController.cs - `public string ModuleName => "Reisekosten/Auslagen";` und `public string Description => "Verwalten und Abrechnen der Mitarbeiterreisekosten.";`, `GetRights()` liefert `null`. Begründung: Belegt die fachliche Absicht des Moduls und das Fehlen jeder Rechteanforderung.
+  - [SEKUNDÄR] C:\DEV\MasterArbeit\QuellCode\CentronERP\SSMS_DB_SCHEMA.sql - `CREATE TABLE [dbo].[ReisekostenAbrechnungen]`, `[ReisekostenBelege]`, `[ReisekostenBelegePKW]`, `[ReisekostenFahrten]`, `[ReisekostenReisen]` neben `CREATE TABLE [dbo].[TravelExpenseCategories]`. Begründung: Belegt zwei parallele Datenmodelle für denselben Sachverhalt.
+Prüfidee:      Anwendung mit einem Benutzer starten, der das Recht TRAVEL_EXPENSE_ADMIN (20800025) besitzt: Das Modul "Reisekosten/Auslagen" darf in der Modulübersicht nicht auftauchen.
+Tracelinks:    SyRS-731
+Konsolidierung: Kandidat: StRS-730 / SyRS-731 - Legacy-Datenmodell `Reisekosten*` und neues Modell `TravelExpense*` bilden dieselbe Fachlichkeit in zwei getrennten Implementierungen ab.
+Übernahmewürdigkeit: veraltet - Modul ist unfertig und bewusst abgeschaltet; für eine Neuentwicklung ist nur die fachliche Absicht, nicht die Umsetzung zu übernehmen.
+Status:        belegt
+Modul:         M-67
+
+ID:            StRS-732
+Titel:         RMA-Vorgang mit Unterscheidung nach Retourenart
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Werkstatt- / RMA-Sachbearbeiter
+Vorbedingung:  Der Benutzer besitzt das Recht RIGHT_RMAANLEGEN (20400210); die Lizenz RMAWorkshop oder RmaBeta ist vorhanden.
+Fakt:          Das RMA-Modul wird in `ModuleRegistration.cs` mit Recht und Lizenz registriert. Die Tabelle `Rma` führt die Pflichtspalte `RmaKind`, deren Wertebereich im Enum `RmaKind` als Unknown / OwnRma / CustomerRma / ForeignRma definiert ist.
+Aussage:       Das System soll Retourenvorgänge als RMA verwalten und dabei zwischen eigenen Geräten, Kundengeräten und Fremdgeräten unterscheiden.
+Ergebnis:      Jeder RMA-Vorgang trägt eine eindeutige Nummer, einen Kundenbezug und eine Retourenart und ist über die RMA-Übersicht auffindbar.
+Belege:
+  - [PRIMÄR]   C:\DEV\MasterArbeit\QuellCode\CentronERP\src\centron\Centron.WPF.UI\Modules\ModuleRegistration.cs - `ModuleRegistrationItem.For<RmaOverviewAppModulController>(() => Helper.HasRights(UserRightsConst.RIGHT_RMAANLEGEN), () => LicenseManager.Instance.HasLicense(LicenseGuids.RMAWorkshop) || LicenseManager.Instance.HasLicense(LicenseGuids.RmaBeta))`. Begründung: Durchsetzende Stelle für den Modulzugang.
+  - [PRIMÄR]   C:\DEV\MasterArbeit\QuellCode\CentronERP\SSMS_DB_SCHEMA.sql - `CREATE TABLE [dbo].[Rma]` mit `[Number] int NOT NULL, [AccountI3D] int NOT NULL, [RmaKind] int NOT NULL, [IsClosed] bit NOT NULL`. Begründung: NOT-NULL-Constraints erzwingen Nummer, Kundenbezug und Retourenart je Vorgang.
+  - [SEKUNDÄR] C:\DEV\MasterArbeit\QuellCode\CentronERP\src\backend\Centron.Interfaces\CustomerArea\RmaKind.cs - `public enum RmaKind { Unknown, OwnRma, CustomerRma, ForeignRma }`. Begründung: Definiert den fachlichen Wertebereich der Retourenart.
+Prüfidee:      Benutzer ohne Recht 20400210 anmelden: Das Modul "RMA/Werkstatt" darf nicht erscheinen. Anschließend RMA anlegen und prüfen, dass `Rma.RmaKind` gesetzt und `Rma.Number` vergeben ist.
+Tracelinks:    SyRS-733, SwRS-734
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Retourenabwicklung ist eigenständiger Geschäftsprozess mit gesetzlicher Nachweispflicht.
+Status:        belegt
+Modul:         M-68
+
+ID:            StRS-737
+Titel:         Produktionsauftrag stets mit Bezug zu einem Kundenauftrag
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Produktionsplaner
+Vorbedingung:  Ein Kundenauftrag existiert; die Lizenz ProductionManagement ist vorhanden.
+Fakt:          Die Tabelle `ProductionOrders` führt `[OrderI3D] int NOT NULL` und `[OrderNumber] int NOT NULL`; ein Produktionsauftrag kann DB-seitig nicht ohne Auftragsbezug angelegt werden. Der Bezug zur einzelnen Auftragsposition (`OrderItemI3D`) ist dagegen optional.
+Aussage:       Das System soll jeden Produktionsauftrag zwingend an einen bestehenden Kundenauftrag binden und optional an eine einzelne Auftragsposition.
+Ergebnis:      Zu jedem Produktionsauftrag ist der auslösende Kundenauftrag nachvollziehbar; auftragslose Produktion (Lagerfertigung) ist nicht abbildbar.
+Belege:
+  - [PRIMÄR]   C:\DEV\MasterArbeit\QuellCode\CentronERP\SSMS_DB_SCHEMA.sql - `CREATE TABLE [dbo].[ProductionOrders]` mit `[OrderI3D] [int] NOT NULL, [OrderNumber] [int] NOT NULL, [OrderItemI3D] [int] NULL`. Begründung: Der NOT-NULL-Constraint ist die durchsetzende Regel für den Pflichtbezug zum Auftrag.
+  - [PRIMÄR]   C:\DEV\MasterArbeit\QuellCode\CentronERP\src\backend\Centron.BL\Production\ProductionOrderBL.cs - `ProductionOrderBL.CreateFilterExpression(ProductionOrderFilter filter)` filtert unter anderem über `filter.OrderI3D` und `filter.OrderNumber`; `GetProductionOrdersByFilter` sortiert mit `f => f.OrderI3D`. Begründung: Der Auftragsbezug ist das führende Ordnungsmerkmal der Produktionsaufträge.
+  - [SEKUNDÄR] C:\DEV\MasterArbeit\QuellCode\CentronERP\SSMS_DB_SCHEMA.sql - `CREATE TABLE [dbo].[ProductionOrderItems]` mit `[ProductionOrderI3D] int NOT NULL` und `CREATE CLUSTERED INDEX [CI_ProductionOrderItems] ON [dbo].[ProductionOrderItems]([ProductionOrderI3D] ASC)`. Begründung: Zeigt die Kopf-Positions-Struktur des Produktionsauftrags.
+Prüfidee:      Versuch, einen Produktionsauftrag ohne `OrderI3D` zu speichern: Der Speichervorgang muss mit einer Constraint-Verletzung fehlschlagen.
+Tracelinks:    SyRS-738, SwRS-739
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - auftragsbezogene Fertigung ist das tragende Geschäftsmodell des Moduls; für Lagerfertigung wäre der Pflichtbezug zu lockern.
+Status:        belegt
+Modul:         M-70

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_work/A8_StRS.md

@@ -0,0 +1,202 @@
+ID:            StRS-801
+Titel:         Zentrale Anmeldung aller c-entron-Anwendungen am Web-Service
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Mitarbeiter / Kundenbenutzer (WebAccount)
+Vorbedingung:  Der Benutzer besitzt ein Konto (Tabelle `Sichbenu` bzw. `WebAccounts`) und startet eine c-entron-Anwendung.
+Fakt:          `Authenticator.GetTicket()` (src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs, Z. 94–107) führt für jede Anmeldung nacheinander `Authenticate()`, die Auflösung der `ApplicationKind` über `ApplicationKind.GetKindByLicenseGuid(Auth.ApplicationName)` und danach `AuthenticateUser(...)` aus; ohne bekannte ApplicationKind wird mit `DefaultMessageCodes.ApplicationIDUnknown` abgebrochen.
+Aussage:       Das System soll jede Anmeldung einer c-entron-Anwendung zentral über den Web-Service durchführen und dabei Identität, Anwendungsart und Berechtigung in einem Vorgang prüfen, bevor eine Sitzung entsteht.
+Ergebnis:      Bei erfolgreicher Prüfung erhält der Client eine Ticket-ID; andernfalls eine Fehlermeldung mit MessageCode.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs — `Authenticator.GetTicket()` / `AuthenticateUser()`; Abbruchbedingung `if (applicationKind == null) return ... ApplicationIDUnknown` - Begründung: Durchsetzende Stelle der zentralen Anmeldung, ohne die kein Ticket erzeugt wird.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs — `ValidateRights(applicationKind, user)` prüft `applicationKind.DisallowingRight` und `applicationKind.RequiredRight` über `AppRightsBL.HasUserRight` - Begründung: Belegt, dass die Anwendungsberechtigung Teil der Anmeldung ist.
+Prüfidee:      Anmeldung mit gültigen Zugangsdaten, aber unbekannter `Application`-GUID: Erwartet wird ein Fehler mit MessageCode `ApplicationIDUnknown` und kein Eintrag in der Ticket-Tabelle.
+Tracelinks:    SyRS-811, SyRS-812, SwRS-827, SwRS-828, SwRS-830
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zentrale Authentifizierung ist tragende Sicherheitsfunktion des Gesamtsystems.
+Status:        belegt
+Modul:         M-75
+
+ID:            StRS-802
+Titel:         Zwei-Faktor-Authentifizierung als zusätzlicher Anmeldeschutz
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Administrator (Konfiguration) / Benutzer (Durchführung)
+Vorbedingung:  Im Web-Service Connection Manager ist `TwoFactorAuthEnabled` gesetzt und für den Benutzer ist `UseTwoFactorAuthentication` aktiv.
+Fakt:          `BasicAuthenticator.AuthenticateInternal()` ruft nach erfolgreicher Kennwortprüfung `TwoFactorAuthBL.ValidateTwoFactor(...)` auf und gibt bei Misserfolg `DefaultMessageCodes.TwoFactorAuthFailed` zurück (src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs, Z. 62–70).
+Aussage:       Das System soll die Benutzeranmeldung um einen zweiten Faktor erweitern können, sodass die Anmeldung ohne bestandenen zweiten Faktor scheitert.
+Ergebnis:      Ohne bestandene Zweitfaktor-Prüfung wird kein Ticket erzeugt und die Anmeldung schlägt fehl.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs — `_twoFactorAuthBL.ValidateTwoFactor(...)`; Rückgabe `Result<LoggedInUser>.AsError(..., DefaultMessageCodes.TwoFactorAuthFailed)` - Begründung: Durchsetzende Stelle, an der die Anmeldung ohne zweiten Faktor abgebrochen wird.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, Tabelle `dbo.Sichbenu`, Spalten `[UseTwoFactorAuthentication] [bit] NOT NULL`, `[TwoFactorAuthKey] [nvarchar](200) NULL`, `[TwoFactorValidDurationInDays] [int] NULL` - Begründung: Persistente Steuerung je Benutzerkonto als DB-Constraint/Schema.
+Prüfidee:      Benutzer mit `UseTwoFactorAuthentication = 1` und aktiviertem `TwoFactorAuthEnabled` anmelden und den zweiten Faktor verweigern: Erwartet wird Fehlercode `TwoFactorAuthFailed` und kein Ticket.
+Tracelinks:    SyRS-813, SyRS-814, SwRS-831, SwRS-832
+Konsolidierung: Kandidat: StRS-802 / SwRS-832 — zwei getrennte 2FA-Implementierungen (siehe A8_Meta.md)
+Übernahmewürdigkeit: übernehmen - Zusätzlicher Anmeldeschutz ist regulatorisch und sicherheitstechnisch gefordert.
+Status:        belegt
+Modul:         M-76
+
+ID:            StRS-803
+Titel:         Maschinenzugriff auf die API über personengebundene Access Tokens
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Externes System / Integrationspartner
+Vorbedingung:  Es besteht die Lizenz `LicenseGuids.AccessTokenModule` und ein Mitarbeiter, für den der Token ausgestellt wird.
+Fakt:          `AccessTokenBL.CreatePersonalToken(...)` legt einen Token an, der über `IssuedForEmployee` fest an genau einen Mitarbeiter gebunden ist, und gibt den Klartext-Token nur einmalig bei der Erstellung zurück (src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs, Z. 125–194).
+Aussage:       Das System soll externen Systemen einen API-Zugriff ermöglichen, der ohne interaktive Anmeldung auskommt, aber eindeutig einem Mitarbeiter zugeordnet und jederzeit widerrufbar ist.
+Ergebnis:      Ein API-Aufruf mit gültigem Token wird im Kontext des zugeordneten Mitarbeiters ausgeführt und protokolliert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs — `CreatePersonalToken()` mit `IssuedForEmployee = issuedForEmployee` und Rückgabe `(accessToken, plainToken)`; `Deactivate()` setzt `token.IsActive = false` - Begründung: Durchsetzende Stelle für Bindung und Widerrufbarkeit.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/AuthenticationTicketBL.cs — `GetAuthTicketInfo()` löst über `_appUserBL.GetAppUserI3DForEmployee(...)` den AppUser zum Token auf - Begründung: Beweist die tatsächliche Ausführung im Mitarbeiterkontext.
+Prüfidee:      Token erzeugen, API-Aufruf mit `Authorization: Bearer <token>` absetzen, Token deaktivieren, Aufruf wiederholen: Der zweite Aufruf muss mit „Token ist deaktiviert." scheitern.
+Tracelinks:    SyRS-812, SyRS-816, SwRS-833, SwRS-834, SwRS-835
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Für Integrationen unverzichtbar und sicherheitsrelevant.
+Status:        belegt
+Modul:         M-77
+
+ID:            StRS-804
+Titel:         Lizenzabhängige Freischaltung von Anwendungen und Einzelfunktionen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        c-entron Web-Service / Lizenzserver
+Vorbedingung:  Eine gültige Lizenzdatei wurde vom Lizenzserver geladen (`LicenseManager.LoadLicenses()`).
+Fakt:          `LicenseManager.CheckLicense(app, applicationVersion, user)` prüft je Lizenz-GUID Version, Anzahl und Gültigkeit und liefert bei Überschreitung `DefaultMessageCodes.LicenseMaximumReached` (src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs, Z. 258–302); `HasLicense(Guid)` prüft Einzelfunktionen.
+Aussage:       Das System soll Anwendungen und Einzelfunktionen ausschließlich dann bereitstellen, wenn die zugehörige Lizenz-GUID vorhanden, versionsgültig und die Nutzungsanzahl nicht ausgeschöpft ist.
+Ergebnis:      Fehlende oder ausgeschöpfte Lizenzen führen zu einer definierten Fehlermeldung; die Funktion bleibt gesperrt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs — `CheckLicense()`: `if (currentlyUsedLicenses >= maxNumberOfLicenses) results.Add(... LicenseMaximumReached)` - Begründung: Durchsetzende Bedingung der Lizenzobergrenze.
+  - [PRIMÄR]   src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Z. 94 — `if (LicenseManager.Instance.HasLicense(LicenseGuids.PasswordManager) == false) return ... DefaultMessageCodes.LicenseNotFound` - Begründung: Beispielhafte Durchsetzung einer Einzelfunktions-Lizenz in der BL.
+  - [KONTEXT]  docs/reference/security/licensing-system.md — Beschreibung von `Applications` vs. `Only Licenses` - Begründung: Fachliche Einordnung des Lizenzmodells.
+Prüfidee:      Lizenzdatei ohne `LicenseGuids.PasswordManager` einspielen: Aufrufe von `PasswordManagerBL.GetPasswordManagerCustomersEmployeesRights` müssen mit `LicenseNotFound` abbrechen.
+Tracelinks:    SyRS-815, SyRS-816, SwRS-836
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Lizenzierung ist Geschäftsmodell-tragend und im Code durchgesetzt.
+Status:        belegt
+Modul:         M-78
+
+ID:            StRS-805
+Titel:         Zentrale, verschlüsselte Verwaltung von Kundenzugangsdaten
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Servicetechniker / Administrator
+Vorbedingung:  Lizenz `LicenseGuids.PasswordManager` vorhanden und ein Masterkey ist hinterlegt.
+Fakt:          Zugangsdaten werden als `ModuleCustomPropertyValue.ValueEncryptedString` mit `new AESCryptoLogic().EncryptText(<wert>, masterKey)` verschlüsselt abgelegt und nur mit `DecryptText(..., masterKey)` wieder lesbar gemacht (src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Z. 700 und Z. 1052).
+Aussage:       Das System soll Zugangsdaten von Kundensystemen zentral speichern und dabei die geheimen Werte ausschließlich verschlüsselt mit einem separaten Masterkey ablegen.
+Ergebnis:      In der Datenbank stehen nur AES-verschlüsselte Base64-Werte; ohne Masterkey ist keine Entschlüsselung möglich.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Z. 1051–1052 — `case CustomizationDataTypes.EncryptedText: customPropertyData.EncryptedString = new AESCryptoLogic().DecryptText(propertyValue?.ValueEncryptedString, masterKey);` - Begründung: Durchsetzende Stelle der Ver-/Entschlüsselung mit Masterkey.
+  - [PRIMÄR]   src/backend/Centron.Common/TextCoding/AESCryptoLogic.cs — `EncryptByteArray()` nutzt `Aes.Create()` mit aus `securityKey` abgeleitetem Key/IV - Begründung: Belegt das eingesetzte Verfahren (AES).
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/CentronConfigDb/CentronConfigurationDbBL.cs — `EncryptWithMasterKey()` bricht mit „Es wurde kein Masterkey hinterlegt" ab - Begründung: Erzwingt die Existenz des Masterkeys.
+Prüfidee:      Passwortfeld über die UI speichern und den Datensatz in `ModuleCustomPropertyValues` direkt per SQL lesen: Der Wert darf nicht im Klartext lesbar sein.
+Tracelinks:    SyRS-817, SyRS-818, SwRS-837, SwRS-838, SwRS-839, SwRS-840
+Konsolidierung: Kandidat: StRS-805 / SwRS-839 — `PasswordManagementArea` vs. `PasswordManager` (siehe A8_Meta.md)
+Übernahmewürdigkeit: übernehmen - Kernfunktion mit hoher Schutzbedarfsklasse.
+Status:        belegt
+Modul:         M-79
+
+ID:            StRS-806
+Titel:         Umsetzung des DSGVO-Löschanspruchs für Kontaktdaten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Datenschutzbeauftragter / Administrator
+Vorbedingung:  Der anfragende Benutzer besitzt das Recht `UserRightsConst.DsgvoModule.DSGVO_DELETE_CONTACT`.
+Fakt:          `DataSecurityBL.DsgvoDeleteRightDeleteContacts(currentUser, contacts)` prüft das Recht, löscht die ausgewählten Kontaktobjekte innerhalb einer Transaktion (`Session.WithTransaction`) und liefert ein Textprotokoll mit Kopfzeile „c-entron Löschprotokoll" zurück (src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs, Z. 787–854).
+Aussage:       Das System soll auf Anfrage betroffener Personen deren Kontaktdaten löschen bzw. anonymisieren und den Vorgang in einem Löschprotokoll dokumentieren.
+Ergebnis:      Die betroffenen Kontaktdatensätze sind anonymisiert und der Anwender erhält ein Löschprotokoll als Nachweis.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs, Z. 789–790 — `if (!currentUser.HasUserRight(UserRightsConst.DsgvoModule.DSGVO_DELETE_CONTACT)) return Result<string>.AsError("Insufficient rights!");` - Begründung: Durchsetzende Rechteprüfung vor der Löschung.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs, Z. 26 — `internal const string DsgvoDeletedContactMessage = "DSGVO: Auf Anfrage gelöscht.";` - Begründung: Belegt die Anonymisierungs-Kennzeichnung statt physischer Löschung.
+Prüfidee:      Aufruf mit einem Benutzer ohne `DSGVO_DELETE_CONTACT`: Erwartet wird „Insufficient rights!" und keinerlei Datenänderung.
+Tracelinks:    SyRS-819, SyRS-820, SwRS-841
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Gesetzliche Pflicht (Art. 17 DSGVO).
+Status:        belegt
+Modul:         M-80
+
+ID:            StRS-807
+Titel:         Digitale Signatur ausgehender PDF-Dokumente
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Administrator (Einrichtung) / System (Ausführung)
+Vorbedingung:  Ein PKCS#12-Zertifikat mit privatem Schlüssel ist in den Anwendungseinstellungen hinterlegt.
+Fakt:          `PdfSigningBL.SignPdfDocument(byte[])` erzeugt mit `new Pkcs7Signer(certi, HashAlgorithmType.SHA256, tsaClient)` eine Signatur und setzt `signatureBuilder.ApplicationName = "c-entron.NET"` (src/backend/Centron.BL/Security/PdfSigningBL.cs); `IsPdfSigningAvailable()` liefert nur `true`, wenn `ApplicationSettingID.PdfSigningCertificate` gesetzt ist.
+Aussage:       Das System soll ausgehende PDF-Dokumente mit einem hinterlegten Zertifikat digital signieren, sodass Urheber und Unverfälschtheit nachweisbar sind.
+Ergebnis:      Das erzeugte PDF enthält eine PKCS#7-Signatur mit SHA-256 und optionalem qualifiziertem Zeitstempel.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Security/PdfSigningBL.cs — `SignPdfDocument()`: `new Pkcs7Signer(certi, HashAlgorithmType.SHA256, tsaClient)` - Begründung: Durchsetzende Stelle der Signaturerzeugung inkl. Hashverfahren.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Documents/Dsgvo/OrderProcessingContractOnlinePdfDocumentHandler.cs, Z. 276–279 — `if (signingBL.IsPdfSigningAvailable()) { var signed = signingBL.SignPdfDocument(resultStream.ToArray()); }` - Begründung: Belegt den produktiven Einsatz an Vertragsdokumenten.
+Prüfidee:      Ein AV-Vertrag wird online bestätigt; das erzeugte PDF muss in einem PDF-Reader eine gültige digitale Signatur mit dem hinterlegten Zertifikat ausweisen.
+Tracelinks:    SyRS-821, SwRS-842
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Beweiskraft signierter Dokumente ist fachlich gefordert.
+Status:        belegt
+Modul:         M-81
+
+ID:            StRS-808
+Titel:         Nachvollziehbarkeit von Änderungen an gekennzeichneten Datensätzen
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Wartbarkeit (Analysierbarkeit)
+Akteur:        Administrator / Revision
+Vorbedingung:  Die Entität ist mit `ChangeTrackingConfigurationAttribute` und mindestens einer Eigenschaft mit `TrackChangesAttribute` versehen.
+Fakt:          `ChangeTrackingEventListener.OnPreUpdate()` vergleicht bei jedem NHibernate-Update Alt- und Neuwert der markierten Eigenschaften und speichert bei Abweichung einen `ChangeLog`-Datensatz mit `ObjectI3D`, `ObjectKind`, `Property`, `OldValue`, `NewValue`, `Date` und `AppUser` (src/backend/Centron.DAO/ChangeTracking/ChangeTrackingEventListener.cs, Z. 52–142).
+Aussage:       Das System soll Änderungen an fachlich gekennzeichneten Feldern automatisch mit Alt-/Neuwert, Zeitpunkt und verursachendem Benutzer protokollieren.
+Ergebnis:      Zu jedem geänderten Feld existiert ein `ChangeLog`-Eintrag, der über `ChangeLogBL.GetChangeLogs(objectI3D, objectKind)` abrufbar ist.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.DAO/ChangeTracking/ChangeTrackingEventListener.cs, Z. 78–86 — `if (object.Equals(oldValue, newValue) == false) { ChangeLog log = this.CreateChangeLog(...); session.Save(log); }` - Begründung: Durchsetzende Stelle der Protokollierung.
+  - [PRIMÄR]   src/backend/Centron.BL/CheckListArea/ChangeTracking/ChangeLogBL.cs — `GetChangeLogs(int objectI3D, CentronObjectKindNumeric objectKind)` - Begründung: Belegt die Auswertbarkeit der Historie.
+Prüfidee:      Ein mit `TrackChanges` markiertes Feld ändern und speichern: In `ChangeLog` muss genau ein neuer Eintrag mit korrektem Alt-/Neuwert und dem angemeldeten Benutzer entstehen.
+Tracelinks:    SyRS-822, SwRS-843
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Revisionssicherheit ist für ein ERP-System erforderlich.
+Status:        belegt
+Modul:         M-83
+
+ID:            StRS-809
+Titel:         Mandantenfähigkeit mit genau einem Standardmandanten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Administrator
+Vorbedingung:  Mindestens ein Datensatz in `dbo.Mandant` mit `Standard = 1` und `Status = 1`.
+Fakt:          `MandatorBL.GetDefaultMandator()` liest genau den Mandanten mit `f.Default == 1`; `MandatoryBL.GetMandators()` liefert nur Mandanten mit `f.State == 1` (src/backend/Centron.BL/Administration/Company/MandatorBL.cs, Z. 19–22; src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs, Z. 33–36).
+Aussage:       Das System soll mehrere Mandanten mit eigenen Stammdaten führen und dabei genau einen Mandanten als Standardmandanten für übergreifende Vorbelegungen verwenden.
+Ergebnis:      Übergreifende Logik (z. B. Nummernkreise, Länderzuordnung) fällt eindeutig auf den Standardmandanten zurück.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Company/MandatorBL.cs — `GetDefaultMandator() => Session.GetGenericDAO<Mandator>().GetEntity(f => f.Default == 1)` - Begründung: Durchsetzende Selektionsbedingung des Standardmandanten.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs, Z. 91 — SQL `LEFT OUTER JOIN dbo.Mandant m ON m.Standard = 1 AND m.Status = 1` - Begründung: Standardmandant wird auch in der Nummernkreis-Ermittlung als Fallback erzwungen.
+Prüfidee:      Standardkennzeichen aller Mandanten entfernen: Die Nummernkreis-Ermittlung ohne Filialbezug darf keinen Nummernkreis mehr liefern.
+Tracelinks:    SyRS-823, SwRS-844
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Mandantenfähigkeit ist grundlegendes Strukturmerkmal.
+Status:        belegt
+Modul:         M-73
+
+ID:            StRS-810
+Titel:         Automatisierte, zentral steuerbare Hintergrundverarbeitung
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Zuverlässigkeit (Fehlertoleranz)
+Akteur:        c-entron Web-Service (Host)
+Vorbedingung:  Der Web-Service läuft; Tabelle `dbo.BackgroundServices` ist vorhanden.
+Fakt:          Alle Hintergrunddienste erben von `ManagedBackgroundService`, das vor jedem Zyklus `BackgroundServiceBL.IsServiceEnabled(serviceName)` auswertet, bei `false` die Ausführung überspringt und Fehler mit exponentiellem Backoff bis `MaxBackoffDelay = 5 Minuten` abfängt (src/webservice/Centron.Host/AspNetCore/HostedServices/ManagedBackgroundService.cs, Z. 56–157).
+Aussage:       Das System soll wiederkehrende Aufgaben automatisch im Hintergrund ausführen, diese je Dienst zentral aktivierbar halten und bei Fehlern nicht den Gesamtbetrieb gefährden.
+Ergebnis:      Deaktivierte Dienste laufen nicht; fehlerhafte Dienste protokollieren den Fehler und laufen verzögert weiter, ohne den Host zu beenden.
+Belege:
+  - [PRIMÄR]   src/webservice/Centron.Host/AspNetCore/HostedServices/ManagedBackgroundService.cs, Z. 60–82 — `bool isEnabled = GetIsEnabledCached(serviceName); if (isEnabled) { ... } else { _logger.Debug($"{serviceName} is disabled, skipping execution."); }` - Begründung: Durchsetzende Ein-/Ausschaltbedingung je Dienst.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[BackgroundServices]` mit `[ServiceName] [nvarchar](255) NOT NULL, [IsEnabled] [bit] NOT NULL` - Begründung: Persistenz des Schaltzustands als DB-Schema.
+  - [KONTEXT]  docs/Background Service/DataQualityService.md — Beschreibung von Zyklus und Fehlerbehandlung - Begründung: Fachliche Einordnung des Musters.
+Prüfidee:      `IsEnabled = 0` für „DataQualityService" setzen und maximal 60 Sekunden warten: Im Log darf kein „execution starts" mehr erscheinen.
+Tracelinks:    SyRS-824, SwRS-845
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zentrale Betriebssteuerung ist etabliert und aktiv genutzt.
+Status:        belegt
+Modul:         M-87

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_work/A8_SyRS.md

@@ -0,0 +1,343 @@
+ID:            SyRS-811
+Titel:         Auswahl des Authentifizierungsverfahrens zur Laufzeit
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        c-entron Web-Service (AuthenticatorFactory)
+Vorbedingung:  Eine Anmeldeanfrage (LoginRequest / JwtLoginRequest) ist eingegangen.
+Fakt:          `AuthenticatorFactory.GetAuthenticator(authObject)` wählt anhand der systemweiten Einstellung `AppSettingsGroupBL.GetAuthenticationSettings().SystemAuthenticationMethod` und des Typs des `AuthObject` zwischen `BasicAuthenticator`, `ActiveDirectoryAuthenticator`, `OpenIdConnectAuthenticator` und `WebAccountAuthenticator` (src/backend/Centron.BL/Administration/Logins/Auth/AuthenticatorFactory.cs, Z. 44–95).
+Aussage:       Das System soll das Authentifizierungsverfahren je Anmeldeanfrage aus der systemweiten Einstellung und dem Anmeldetyp bestimmen und bei nicht freigeschaltetem Verfahren die Anmeldung ablehnen.
+Ergebnis:      Es wird genau ein `IAuthenticator` erzeugt; ist das Verfahren nicht aktiviert, liefert die Factory ein Fehler-Result („Active Directory authentication is not enabled" bzw. „JWT authentication is not enabled").
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/Auth/AuthenticatorFactory.cs, Z. 113–116 — `TryCreateActiveDirectory(): ActiveDirectoryEnabled ? new ActiveDirectoryAuthenticator(...) : Result<IAuthenticator>.AsError("Active Directory authentication is not enabled")` - Begründung: Durchsetzende Bedingung der Verfahrensfreischaltung.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/Auth/AuthenticatorFactory.cs, Z. 132–133 — `if (licenseManager.HasLicense(LicenseGuids.OpenIDConnectAuthentication) == false) return Result<IAuthenticator>.AsError("No license for OpenIDConnectAuthentication");` - Begründung: Lizenzbedingung als durchgesetzte Regel für OIDC.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `dbo.Sichbenu`, Spalte `[AuthentificationKind] [int] NOT NULL` - Begründung: Persistierte Verfahrenszuordnung je Benutzer.
+Prüfidee:      Bei `SystemAuthenticationMethod.ActiveDirectory` und deaktiviertem `ActiveDirectoryAuthEnabled` muss die Anmeldung mit „Active Directory authentication is not enabled" scheitern.
+Tracelinks:    StRS-801, SwRS-828, SwRS-831
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Erlaubt den geordneten Wechsel zwischen lokaler und externer Identitätsquelle.
+Status:        belegt
+Modul:         M-75
+
+ID:            SyRS-812
+Titel:         Zugriffsprüfung am Web-Service über Ticket oder Access Token
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        c-entron Web-Service (TicketAuthenticationHandler)
+Vorbedingung:  Ein HTTP-Request enthält einen Wert im Query-Parameter `access_token` oder im Header `Authorization: Bearer <wert>`.
+Fakt:          `TicketAuthenticationHandler.HandleAuthenticateAsync()` liest den Token, ruft `AuthenticationTicketBL.GetAuthTicketInfo(token, ipAddress, apiMethod)` auf und lehnt bei ungültigem Wert mit „Invalid authentication ticket or access token." ab; `GetAuthTicketInfo` prüft zuerst das Sitzungs-Ticket und danach den Access Token (src/webservice/Centron.Host/AspNetCore/TicketAuthenticationHandler.cs, Z. 44–95; src/backend/Centron.BL/Administration/Logins/AuthenticationTicketBL.cs, Z. 25–48).
+Aussage:       Das System soll jeden API-Request entweder über ein gültiges Sitzungs-Ticket oder über einen gültigen Access Token authentifizieren und die aufrufende Identität als Claim `CustomClaimTypes.UserIdentifier` bereitstellen.
+Ergebnis:      Authentifizierte Requests tragen einen ClaimsPrincipal mit Benutzer-ID und Authentifizierungsart; nicht authentifizierte Requests werden abgewiesen.
+Belege:
+  - [PRIMÄR]   src/webservice/Centron.Host/AspNetCore/TicketAuthenticationHandler.cs, Z. 53–56 — `var validationResult = this.ValidateTicketOrAccessToken(token); if (!validationResult.IsValid) return AuthenticateResult.Fail(...)` - Begründung: Durchsetzende Stelle der Zugriffsprüfung für alle ASP.NET-Core-Endpunkte.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/AuthenticationTicketBL.cs, Z. 27–45 — Reihenfolge „First try: ConnectionTicket" / „Second try: Access Token" - Begründung: Legt die Prüfreihenfolge verbindlich fest.
+Prüfidee:      Request ohne `Authorization`-Header und ohne `access_token` absetzen: HTTP 401; Request mit widerrufenem Token: ebenfalls 401.
+Tracelinks:    StRS-801, StRS-803, SwRS-835
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Einheitlicher Eintrittspunkt für alle API-Zugriffe.
+Status:        belegt
+Modul:         M-77
+
+ID:            SyRS-813
+Titel:         Konfigurierbares Zweitfaktor-Verfahren
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Administrator (Web-Service Connection Manager)
+Vorbedingung:  `WebServiceConfigHelper.Current.TwoFactorAuthEnabled` ist gesetzt.
+Fakt:          `TwoFactorAuthBL.GetTwoFactorValidator()` erzeugt abhängig von `WebServiceConfigHelper.Current.TwoFactorAuthType` entweder einen `RadiusTwoFactorValidator` oder einen `EmailTwoFactorValidator` und wirft bei unbekanntem Wert `ArgumentOutOfRangeException` (src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs, Z. 183–193).
+Aussage:       Das System soll das Verfahren für den zweiten Faktor systemweit konfigurierbar zwischen RADIUS-Server und E-Mail-Link umschalten können.
+Ergebnis:      Alle 2FA-Prüfungen laufen über den konfigurierten Validator; ein nicht unterstützter Wert führt zu einem harten Konfigurationsfehler.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs, Z. 185–190 — `switch { TwoFactorAuthType.RadiusServer => new RadiusTwoFactorValidator(), TwoFactorAuthType.EmailLink => new EmailTwoFactorValidator(), _ => throw new ArgumentOutOfRangeException(...) }` - Begründung: Durchsetzende Auswahl des Verfahrens.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs, Z. 41–45 — `if (WebServiceConfigHelper.Current.TwoFactorAuthEnabled == false) return Result.AsSuccess();` - Begründung: Globaler Schalter, der die gesamte 2FA deaktiviert.
+Prüfidee:      `TwoFactorAuthType` auf `EmailLink` stellen und eine Anmeldung auslösen: Es muss eine Mail über die Vorlage `MailTemplateReferences.Auth.TwoFactor` versendet werden.
+Tracelinks:    StRS-802, SyRS-814, SwRS-832
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Erlaubt Anpassung an vorhandene Kundeninfrastruktur.
+Status:        belegt
+Modul:         M-76
+
+ID:            SyRS-814
+Titel:         Gültigkeitsdauer des zweiten Faktors je Anwendung, Gerät und IP-Adresse
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        c-entron Web-Service (TwoFactorAuthBL)
+Vorbedingung:  Der Benutzer hat den zweiten Faktor mindestens einmal bestätigt.
+Fakt:          `TwoFactorAuthBL.HasToValidateTwoFactor()` ermittelt die Dauer aus `user.TwoFactorValidDurationInDays ?? WebServiceConfigHelper.Current.TwoFactorValidDurationInDays`, erzwingt bei `<= 0` immer eine neue Prüfung und vergleicht sonst `lastTwoFactorAuth.Value.Date.AddDays(dauer) < DateTime.Now`; der letzte Zeitpunkt wird in `TwoFactorAuthLastLogins` je Kombination aus UserKind, UserI3D, ApplicationName, MachineName und IpAddress gespeichert (src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs, Z. 82–179).
+Aussage:       Das System soll den bestandenen zweiten Faktor für eine konfigurierbare Anzahl an Kalendertagen je Kombination aus Benutzer, Anwendung, Rechnername und IP-Adresse als gültig anerkennen.
+Ergebnis:      Innerhalb der Gültigkeit entfällt die erneute Zweitfaktor-Abfrage; bei Wechsel von Gerät oder IP-Adresse wird erneut geprüft.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs, Z. 127–130 — `var twoFactorAuthIsValidUntil = lastTwoFactorAuth.Value.Date.AddDays(twoFactorIsValidDuration); bool twoFactorAuthNeeded = twoFactorAuthIsValidUntil < DateTime.Now;` - Begründung: Durchsetzende Berechnung der Gültigkeit.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[TwoFactorAuthLastLogins]` mit `[UserKind]`, `[UserI3D]`, `[ApplicationName]`, `[MachineName]`, `[IpAddress]`, `[LastLogin]` (alle NOT NULL) - Begründung: Schlüsselumfang der Gültigkeit als Schema-Constraint.
+Prüfidee:      Nach erfolgreicher 2FA von derselben Maschine erneut anmelden (kein zweiter Faktor gefordert), danach `IpAddress` in `TwoFactorAuthLastLogins` verändern: Die nächste Anmeldung muss den zweiten Faktor erneut anfordern.
+Tracelinks:    StRS-802, SyRS-813
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Balanciert Sicherheit und Benutzbarkeit, aktiv genutzt.
+Status:        belegt
+Modul:         M-76
+
+ID:            SyRS-815
+Titel:         Lizenzprüfung nach Produkt, Version und Anzahl gleichzeitiger Nutzungen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        c-entron Web-Service (LicenseManager)
+Vorbedingung:  Eine Anmeldung für eine `ApplicationKind` läuft; die Lizenzdatei wurde geladen.
+Fakt:          `LicenseManager.CheckLicense()` ruft je Lizenz-GUID `CheckLicenseVersion(license, versionNumber)` auf und vergleicht anschließend `TicketBL.GetTicketCount(license, app.LicenseUsageKind, user)` gegen `GetLicenseCount(license)`; ist die Zahl erreicht, wird `LicenseMaximumReached` gemeldet (src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs, Z. 258–302).
+Aussage:       Das System soll vor Erzeugung einer neuen Sitzung prüfen, ob die Lizenz für das Produkt existiert, für die Anwendungsversion gültig ist und die Anzahl gleichzeitiger Nutzungen nicht überschritten wird.
+Ergebnis:      Bei ausgeschöpfter Lizenz wird kein neues Ticket erzeugt und der Anwender erhält „Die maximale Anzahl an Lizenzen wurde erreicht."
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs, Z. 279–283 — `if (currentlyUsedLicenses >= maxNumberOfLicenses) results.Add(Result<Guid>.AsError("Die maximale Anzahl an Lizenzen wurde erreicht.", DefaultMessageCodes.LicenseMaximumReached));` - Begründung: Durchsetzende Bedingung der Nutzungsobergrenze.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs, Z. 131–139 — `var result = LicenseManager.CheckLicense(applicationKind, appVersion, userResult); if (result.Status != ResultStatus.Success) return Result<string>.FromResult(result);` - Begründung: Einbindung der Lizenzprüfung in den Anmeldeablauf.
+Prüfidee:      Mit ausgeschöpfter Lizenzanzahl von einem weiteren Gerät anmelden: Erwartet wird MessageCode `LicenseMaximumReached` und kein neuer Ticket-Datensatz.
+Tracelinks:    StRS-804, SwRS-837
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Lizenzobergrenzen sind vertragsrelevant.
+Status:        belegt
+Modul:         M-78
+
+ID:            SyRS-816
+Titel:         Lizenzabhängige Obergrenze aktiver Access Tokens
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Administrator / Mitarbeiter
+Vorbedingung:  Die Lizenz `LicenseGuids.AccessTokenModule` besitzt einen Zählwert größer null.
+Fakt:          `AccessTokenBL.LicenseCheckCanActivateMoreToken()` zählt `Query<AccessToken>().Count(t => t.IsActive && !t.IsDeleted && (t.ExpiresAt == null || t.ExpiresAt > DateTime.Now))` und lehnt bei Erreichen des Lizenzzählwerts weitere Anlagen bzw. Aktivierungen ab; ein Zählwert von 0 gilt als unbegrenzt (src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs, Z. 430–451).
+Aussage:       Das System soll die Anzahl gleichzeitig aktiver, nicht abgelaufener Access Tokens auf den lizenzierten Zählwert begrenzen.
+Ergebnis:      Beim Überschreiten wird „Sie können keine weitere Token anlegen / aktivieren." zurückgegeben und kein Token angelegt oder aktiviert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs, Z. 444–450 — `var activeLicenseCount = ... Count(t => t.IsActive && !t.IsDeleted && (t.ExpiresAt == null || t.ExpiresAt > DateTime.Now)); if (activeLicenseCount < maxLicenseCountResult.Data!.Value) return Result.AsSuccess(); return Result.AsError(...)` - Begründung: Durchsetzende Zählbedingung.
+  - [PRIMÄR]   src/backend/Centron.Interfaces/Administration/Logins/LicenseGuids.cs, Z. 395 — `public static readonly Guid AccessTokenModule = Guid.Parse("8880E3D5-D832-48C4-8686-8EEBD729AE07");` - Begründung: Belegt die referenzierte Lizenz.
+Prüfidee:      Lizenzzählwert auf 1 setzen, einen Token anlegen, zweiten Token anlegen: Der zweite Aufruf muss mit der Maximalanzahl-Meldung scheitern.
+Tracelinks:    StRS-803, StRS-804, SwRS-834
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Verhindert unbegrenzte Maschinenzugriffe.
+Status:        belegt
+Modul:         M-77
+
+ID:            SyRS-817
+Titel:         Wählbarer Speicherort des Passwortmanager-Masterkeys
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Administrator
+Vorbedingung:  Die Passwortmanager-Einstellungen (`PasswordManagerSettingsDTO`) sind geladen.
+Fakt:          `CentronConfigurationDbBL` hält ein Dictionary `MasterPasswordSaveLocation -> IMasterPasswordStorage` mit den Implementierungen `MasterPasswordConfigurationDatabaseStorage` und `MasterPasswordSecureFileStorage` und leitet alle Masterkey-Zugriffe über `_masterPasswordStorages[settings.MasterPasswordSaveLocation]` (src/backend/Centron.BL/Administration/CentronConfigDb/CentronConfigurationDbBL.cs, Z. 29–33, 52–132).
+Aussage:       Das System soll den Masterkey wahlweise in einer separaten Konfigurationsdatenbank oder in einer geschützten Datei außerhalb der Fachdatenbank ablegen, und alle Lese- und Schreibzugriffe über die gewählte Ablage führen.
+Ergebnis:      Der Masterkey liegt nie in der Fachdatenbank neben den verschlüsselten Werten, sondern an dem konfigurierten separaten Ort.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/CentronConfigDb/CentronConfigurationDbBL.cs, Z. 29–33 — Dictionary-Initialisierung mit `MasterPasswordSaveLocation.ConfigurationDatabase` und `MasterPasswordSaveLocation.SecureFile` - Begründung: Durchsetzende Auswahl der Ablage.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/CentronConfigDb/CentronConfigurationDbBL.cs, Z. 112–126 — `GetHotlineMasterKey()` entschlüsselt das gelesene Material mit `AESCryptoLogic.DecryptText(result.Data)` - Begründung: Belegt, dass der Masterkey auch am Ablageort verschlüsselt liegt.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Administration/CentronConfigDb/CentronConfigDbSettingsViewModel.cs — Eigenschaften `IsConfigurationDatabaseMode`, `IsSecureFileMode`, `SetHotlineMasterKeyCommand` - Begründung: Konfigurationsschalter in der Oberfläche.
+Prüfidee:      Ablageart auf `SecureFile` stellen, Masterkey setzen und prüfen, dass in der Konfigurationsdatenbank kein Schlüssel mehr gelesen wird, die Entschlüsselung aber weiterhin funktioniert.
+Tracelinks:    StRS-805, SwRS-838
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Trennung von Schlüssel und Geheimnis ist Voraussetzung des Schutzkonzepts.
+Status:        belegt
+Modul:         M-86
+
+ID:            SyRS-818
+Titel:         Richtlinienbasierte Rechte im Passwortmanager
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        c-entron Web-Service (PasswordManagerBL)
+Vorbedingung:  Lizenz `LicenseGuids.PasswordManager` vorhanden; Richtlinien (`PasswordManagerGuideline`) sind je Kunde/Mitarbeiter zugeordnet.
+Fakt:          `PasswordManagerBL.GetPasswordManagerCustomersEmployeesRights()` liest über die Named Query `NamedQueryEnums.PasswordManager.GetEmployeesRightsForCustomers` je Kunde und Mitarbeiter die Flags `SealBreak`, `SealingAllowed`, `AccessDataEditable`, `AccessDataVisible`, `VPNAccessesEditable`, `TwoFactorAuthentification`, `Notification`, `AccessDataDeletable` und bildet sie auf `PasswordManagerGuidelineRights` ab (src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Z. 92–188).
+Aussage:       Das System soll den Zugriff auf Zugangsdaten je Kunde und Mitarbeiter über Richtlinien mit den Einzelrechten Sichtbarkeit, Bearbeitung, Löschung, Versiegelung und Siegelbruch steuern.
+Ergebnis:      Die Oberfläche erhält je Kunde/Mitarbeiter ein Rechte-Flagfeld, das die zulässigen Aktionen bestimmt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Z. 125–164 — Aufbau von `PasswordManagerGuidelineRights` aus den acht Einzelflags - Begründung: Durchsetzende Ableitung der Einzelrechte.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, Tabellen `PasswordManagerGuidelineCustomers`, `PasswordManagerGuidelineEmployees`, `PasswordManagerGuidelineDepartments`, `PasswordManagerGuidelineExcludedCustomers` sowie Spalte `[TwoFactorAuthentification] [bit] NULL` (Z. 46316) - Begründung: Persistiertes Richtlinienmodell.
+Prüfidee:      Für einen Mitarbeiter `AccessDataVisible = 0` setzen: Die Zugangsdaten des betroffenen Kunden dürfen für diesen Mitarbeiter nicht mehr entschlüsselt angezeigt werden.
+Tracelinks:    StRS-805, SwRS-840, SwRS-841
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Feingranulare Zugriffssteuerung ist Kernanforderung des Moduls.
+Status:        belegt
+Modul:         M-79
+
+ID:            SyRS-819
+Titel:         Löschprotokoll als Nachweis für DSGVO-Löschungen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Datenschutzbeauftragter
+Vorbedingung:  Es wurden Kontaktobjekte für die Löschung ausgewählt und das Recht `DSGVO_DELETE_CONTACT` liegt vor.
+Fakt:          `DataSecurityBL.DsgvoDeleteRightDeleteContacts()` baut einen `StringBuilder` mit der Kopfzeile „c-entron Löschprotokoll", reicht ihn an alle `DoDelete*`-Methoden durch und gibt ihn nur bei erfolgreicher Transaktion als Ergebnis zurück (src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs, Z. 792–853).
+Aussage:       Das System soll für jeden DSGVO-Löschvorgang ein Protokoll erzeugen, das alle tatsächlich geänderten Objekte benennt, und dieses nur bei vollständig erfolgreicher Transaktion ausgeben.
+Ergebnis:      Der Anwender erhält ein Protokoll; bei einem Fehler wird die gesamte Transaktion zurückgerollt und kein Protokoll geliefert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs, Z. 795 und Z. 849–853 — `var deleteResult = Session.WithTransaction(() => { ... }); if (deleteResult.Status == ResultStatus.Error) return Result<string>.FromResult(deleteResult); return Result<string>.AsSuccess(deleteProtocol.ToString());` - Begründung: Durchsetzende Kopplung von Transaktion und Protokollausgabe.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs, Z. 27 — `DsgvoDeletedContactMessageWithEmployeeInfo = "DSGVO: Auf Anfrage gelöscht. (Durchgeführt von {0} am {1:d} um {1:t} Uhr)"` - Begründung: Belegt die Aufnahme von Bearbeiter und Zeitpunkt in die Kennzeichnung.
+Prüfidee:      Löschung mit einem Objekt auslösen, das eine Fremdschlüsselverletzung erzeugt: Es darf kein Protokoll zurückkommen und keine Teilinformation gelöscht bleiben.
+Tracelinks:    StRS-806, SyRS-820
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Nachweispflicht gegenüber Aufsichtsbehörden.
+Status:        belegt
+Modul:         M-80
+
+ID:            SyRS-820
+Titel:         Rechtegeschützte DSGVO-Datenbankbereinigung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Datenschutzbeauftragter / Administrator
+Vorbedingung:  Der Benutzer besitzt `UserRightsConst.DsgvoModule.ACCESS_CLEANUP_DATABASE` und `ModuleFeatures.IsDsgvoDatabaseCleanupAvailable` ist wahr.
+Fakt:          `DataSecurityBL.GetDataSecurityCleanUpStats()` ermittelt Mengengerüste zu Altdaten (z. B. `SELECT COUNT(*) AS Item1 FROM dbo.Taetigkeiten WHERE Datum < :Date`), die zugehörige Ausführung `DataSecurityExecuteCleanUp()` prüft dieselbe Rechte-/Feature-Bedingung und gibt anschließend ohne weitere Anweisungen `Result.AsSuccess()` zurück (src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs, Z. 34–70).
+Aussage:       [HYPOTHESE] Das System soll Altdatenbestände nach konfigurierbaren Aufbewahrungsfristen ermitteln und nach Freigabe durch einen berechtigten Benutzer physisch bereinigen.
+Ergebnis:      Erwartet wäre eine Reduktion der ermittelten Datensatzmengen; tatsächlich verändert `DataSecurityExecuteCleanUp` im vorliegenden Stand keine Daten.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs, Z. 64–70 — `public Result DataSecurityExecuteCleanUp(...) { if (!currentUser.HasUserRight(UserRightsConst.DsgvoModule.ACCESS_CLEANUP_DATABASE) || !ModuleFeatures.IsDsgvoDatabaseCleanupAvailable) return Result.AsError("Insufficient rights!"); return Result.AsSuccess(); }` - Begründung: Die Rechteprüfung ist durchgesetzt, die Bereinigungslogik fehlt vollständig.
+  - [SEKUNDÄR] src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs, Z. 87 — Anzeigetext `$"Es gibt {sqlData.Item1} CRM-Einträge die älter als {date:d} sind."` - Begründung: UI-Text belegt die fachliche Absicht der Bereinigung.
+Prüfidee:      `DataSecurityExecuteCleanUp` mit ausgewählten Statistikarten aufrufen und die Mengengerüste erneut abfragen: Bleiben die Zahlen unverändert, ist die Bereinigung nicht implementiert.
+Tracelinks:    StRS-806, SyRS-819
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - Rechteprüfung vorhanden, Fachlogik fehlt; als bekannte Lücke zu führen.
+Status:        HYPOTHESE
+Modul:         M-80
+Begründung Hypothese: Es fehlt die Information, ob die Bereinigung bewusst deaktiviert wurde (Sicherheitsabschaltung) oder ob sie in einer anderen Komponente ausgeführt wird; im vorliegenden Quellstand existiert keine löschende Anweisung.
+
+ID:            SyRS-821
+Titel:         Optionaler qualifizierter Zeitstempel bei der PDF-Signierung
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        c-entron Web-Service (PdfSigningBL)
+Vorbedingung:  Ein Signaturzertifikat ist hinterlegt; `ApplicationSettingID.PdfSigningTsaServerUrl` ist optional gesetzt.
+Fakt:          `PdfSigningBL.SignPdfDocument()` erzeugt nur bei nicht leerer `TsaServerUrl` einen `TsaClient(new Uri(settings.TsaServerUrl), HashAlgorithmType.SHA256[, username, password])` und übergibt ihn an den `Pkcs7Signer`; das TSA-Passwort wird über `AESCryptoLogic` verschlüsselt in `ApplicationSettingID.PdfSigningTsaServerPassword` abgelegt (src/backend/Centron.BL/Security/PdfSigningBL.cs).
+Aussage:       Das System soll die PDF-Signatur auf Wunsch um einen Zeitstempel eines externen Zeitstempeldienstes ergänzen und die Zugangsdaten zu diesem Dienst nur verschlüsselt speichern.
+Ergebnis:      Bei konfigurierter TSA-URL enthält die Signatur einen RFC-3161-Zeitstempel; ohne Konfiguration wird ohne Zeitstempel signiert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Security/PdfSigningBL.cs — `if (!string.IsNullOrWhiteSpace(settings.TsaServerUrl)) { ... tsaClient = new TsaClient(new Uri(settings.TsaServerUrl), HashAlgorithmType.SHA256, settings.TsaServerUsername, settings.TsaServerPassword); }` - Begründung: Durchsetzende Bedingung für die Zeitstempelnutzung.
+  - [PRIMÄR]   src/backend/Centron.BL/Security/PdfSigningBL.cs — `var crypted = _cryptoLogic.EncryptText(settings.TsaServerPassword); updateSettings.UpdateString(ApplicationSettingID.PdfSigningTsaServerPassword, crypted);` - Begründung: Verschlüsselte Ablage des Dienstpassworts.
+Prüfidee:      TSA-URL konfigurieren, Dokument signieren und die Signaturzeit im PDF prüfen; anschließend `ApplicationSettings` auslesen: Das TSA-Passwort darf dort nicht im Klartext stehen.
+Tracelinks:    StRS-807, SwRS-842
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zeitstempel erhöhen die Beweiskraft und sind konfigurierbar umgesetzt.
+Status:        belegt
+Modul:         M-81
+
+ID:            SyRS-822
+Titel:         Attributgesteuerte Auswahl der zu historisierenden Felder
+Ebene:         SyRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Entwickler / Persistenzschicht
+Vorbedingung:  Die NHibernate-Session ist mit dem `ChangeTrackingEventListener` als `IPreUpdateEventListener` registriert.
+Fakt:          `ChangeTrackingEventListener.GetEntityData(type)` sammelt genau die Eigenschaften, die ein `TrackChangesAttribute` tragen, und verwirft Entitäten ohne solche Eigenschaften mit einer Warnung; nur Typen mit `ChangeTrackingConfigurationAttribute` werden überhaupt betrachtet (src/backend/Centron.DAO/ChangeTracking/ChangeTrackingEventListener.cs, Z. 179–217).
+Aussage:       Das System soll ausschließlich die per Attribut ausgezeichneten Entitäten und Felder historisieren, damit der Umfang der Änderungshistorie deklarativ und nachvollziehbar festgelegt ist.
+Ergebnis:      Nicht ausgezeichnete Felder erzeugen keine `ChangeLog`-Einträge; falsch konfigurierte Typen erzeugen eine Warnung im Log.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.DAO/ChangeTracking/ChangeTrackingEventListener.cs, Z. 187–197 — `.Where(f => f.CanRead && f.GetCustomAttributes(typeof(TrackChangesAttribute), true).Any())` - Begründung: Durchsetzende Filterbedingung des Historisierungsumfangs.
+  - [PRIMÄR]   src/backend/Centron.DAO/ChangeTracking/ChangeTrackingEventListener.cs, Z. 200–204 — `if (entityData.Properties.Any() == false) { Logger.Warn("Can't track the changes of entity of type '{0}', because it doesn't have any TrackChanges attribute."); return null; }` - Begründung: Definiertes Verhalten bei Fehlkonfiguration.
+Prüfidee:      Ein nicht mit `TrackChanges` markiertes Feld einer historisierten Entität ändern: Es darf kein `ChangeLog`-Eintrag entstehen.
+Tracelinks:    StRS-808, SwRS-843
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Deklarativer Ansatz begrenzt Datenvolumen und ist wartbar.
+Status:        belegt
+Modul:         M-83
+
+ID:            SyRS-823
+Titel:         Nummernkreisermittlung mit Vorrang Filiale vor Standardmandant
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        c-entron Web-Service (MandatoryBL)
+Vorbedingung:  Für die gesuchte `NumberGroupEnum` existieren Nummernkreise in `dbo.Nummernkreis`.
+Fakt:          `MandatoryBL.GetNumberGroup(numberGroup, currentEmployeeI3D, branchI3D)` sortiert die Kandidaten mit `ORDER BY CASE WHEN nu.MandantI3D = fm.I3D THEN 0 ELSE 1 END, nu.FilialI3D DESC`, schließt `nu.Beschreibung <> '[nicht verwendet]'` aus und liefert den ersten Treffer mit `Current > 0` (src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs, Z. 83–112).
+Aussage:       Das System soll den zu verwendenden Nummernkreis vorrangig aus dem Mandanten der Filiale des Mitarbeiters und erst ersatzweise aus dem Standardmandanten bestimmen und dabei nur Nummernkreise mit gesetztem Zählerstand verwenden.
+Ergebnis:      Belege einer Filiale erhalten die Nummer aus dem filialspezifischen Kreis; existiert keiner, greift der Kreis des Standardmandanten.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs, Z. 92–96 — SQL-Bedingungen `WHERE ((nu.MandantI3D = fm.I3D AND nu.FilialI3D = f.I3D) OR nu.MandantI3D = m.I3D) AND (ISNULL(nu.FilialI3D,0)<=0 OR nu.FilialI3D = f.I3D) AND nu.Beschreibung <> '[nicht verwendet]'` - Begründung: Durchsetzende Auswahlregel als SQL.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs, Z. 105–111 — `foreach (var item in searchResult) { if (item.Current.GetValueOrDefault(0) > 0) return item; }` - Begründung: Nur aktive Nummernkreise werden verwendet.
+Prüfidee:      Für eine Filiale einen Nummernkreis mit `Aktuell = 0` anlegen: Die Beleganlage muss auf den Kreis des Standardmandanten zurückfallen.
+Tracelinks:    StRS-809
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Regel ist fachlich etabliert und im SQL eindeutig festgelegt.
+Status:        belegt
+Modul:         M-73
+
+ID:            SyRS-824
+Titel:         Ausführungsintervall und Fehler-Backoff der Hintergrunddienste
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Zuverlässigkeit (Wiederherstellbarkeit)
+Akteur:        c-entron Web-Service (ManagedBackgroundService)
+Vorbedingung:  Der Dienst wurde als Hosted Service registriert.
+Fakt:          `ManagedBackgroundService.ExecuteAsync()` wartet zunächst eine Minute (`await Task.Delay(TimeSpan.FromMinutes(1), stoppingToken)`), führt danach zyklisch `GetExecutionInterval()` aus und verlängert nach Fehlern über `GetDelayWithBackoff()` exponentiell bis maximal `MaxBackoffDelay = TimeSpan.FromMinutes(5)`; bei Ausnahmen wird zusätzlich `DAOFactory.Instance.TryRecoverConnectionPool(exception)` gerufen (src/webservice/Centron.Host/AspNetCore/HostedServices/ManagedBackgroundService.cs, Z. 28, 36, 84–93, 141–157).
+Aussage:       Das System soll Hintergrunddienste in einem je Dienst definierten Intervall ausführen, bei wiederholten Fehlern das Intervall exponentiell verlängern und den Datenbankverbindungspool aktiv wiederherstellen.
+Ergebnis:      Dauerfehler führen zu maximal einem Versuch alle fünf Minuten statt zu Dauerlast; nach Erfolg wird das reguläre Intervall wiederhergestellt.
+Belege:
+  - [PRIMÄR]   src/webservice/Centron.Host/AspNetCore/HostedServices/ManagedBackgroundService.cs, Z. 148–153 — `var backoffMultiplier = Math.Min(Math.Pow(2, _consecutiveFailures), MaxBackoffDelay.TotalSeconds / baseInterval.TotalSeconds); ... if (backoffDelay > MaxBackoffDelay) backoffDelay = MaxBackoffDelay;` - Begründung: Durchsetzende Backoff-Berechnung.
+  - [PRIMÄR]   src/webservice/Centron.Host/AspNetCore/HostedServices/ManagedBackgroundService.cs, Z. 86–88 — `_consecutiveFailures++; _logger.Error(...); DAOFactory.Instance.TryRecoverConnectionPool(exception);` - Begründung: Definierte Fehlerreaktion.
+Prüfidee:      Datenbank während eines Dienstzyklus abschalten und die Logabstände beobachten: Die Abstände müssen sich verdoppeln und bei fünf Minuten stagnieren.
+Tracelinks:    StRS-810, SwRS-845
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Verhindert Überlastung bei Störungen.
+Status:        belegt
+Modul:         M-87
+
+ID:            SyRS-825
+Titel:         Begrenzte Gültigkeitsdauer der Sitzungstickets je Anwendungsart
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        c-entron Web-Service (TicketBL)
+Vorbedingung:  Für eine Anmeldung wurde ein Ticket erzeugt.
+Fakt:          `TicketBL.GetExpireDate(applicationKind)` setzt die Gültigkeit anhand `applicationKind.ExpirationKind` auf 30 Minuten (`TicketExpireInMinutes`), 5 Minuten (`MonitoringConnector`), 1440 Minuten (`OneDay`) oder auf `AppSettingsConst.TicketReleaseTime`, mindestens jedoch 30 Minuten (`Math.Max(setting.GetValueOrDefault(TicketExpireInMinutes), TicketExpireInMinutes)`); abgelaufene Tickets werden über `DeleteExpiredTickets()` entfernt (src/backend/Centron.BL/Administration/Logins/TicketBL.cs, Z. 26–34, 136–164).
+Aussage:       Das System soll Sitzungstickets nur zeitlich begrenzt gültig halten, die Dauer je Anwendungsart festlegen und die konfigurierbare Dauer nach unten auf 30 Minuten begrenzen.
+Ergebnis:      Nach Ablauf ist das Ticket ungültig; die Anwendung muss sich neu anmelden.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/TicketBL.cs, Z. 150–153 — `case ExpirationKind.FromSettings: var setting = new AppSettingsBL(Session).GetSettings(AppSettingsConst.TicketReleaseTime).GetInt(...); expireDurationInMinutes = Math.Max(setting.GetValueOrDefault(TicketExpireInMinutes), TicketExpireInMinutes);` - Begründung: Durchsetzende Untergrenze der Gültigkeitsdauer.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/TicketBL.cs, Z. 128–133 — `if ((newExpireDate - ticket.ExpiryDate).TotalMinutes < 5) return Result.AsSuccess();` - Begründung: Regel für die Verlängerung bei Aktivität.
+Prüfidee:      `TicketReleaseTime` auf 5 setzen und ein Ticket erzeugen: Die gespeicherte `ExpiryDate` muss dennoch 30 Minuten in der Zukunft liegen.
+Tracelinks:    StRS-801, SyRS-812
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zeitlich begrenzte Sitzungen sind Sicherheitsanforderung.
+Status:        belegt
+Modul:         M-75
+
+ID:            SyRS-826
+Titel:         Zwei parallele Speicher für Anwendungseinstellungen
+Ebene:         SyRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        c-entron Web-Service (AppSettingsBL)
+Vorbedingung:  Eine Komponente fordert Einstellungen über `AppSettingsBL.GetSettings(...)` an.
+Fakt:          `AppSettingsBL.GetSettings(params object[] settings)` akzeptiert ausschließlich Werte der Typen `AppSettingsConst` (Legacy-Tabelle `Stammdat`) und `ApplicationSettingID` (Tabelle `ApplicationSettings`), lädt beide Mengen getrennt und wirft bei anderen Typen `new Exception("Invalid settings type")` (src/backend/Centron.BL/Administration/Settings/AppSettingsBL.cs, Z. 47–65).
+Aussage:       Das System soll Anwendungseinstellungen aus zwei getrennten Speichern gemeinsam bereitstellen, wobei neue Einstellungen ausschließlich in `ApplicationSettings` geführt werden.
+Ergebnis:      Aufrufer erhalten eine gemeinsame `SettingsCollection` unabhängig davon, in welcher Tabelle die Einstellung physisch liegt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Settings/AppSettingsBL.cs, Z. 55–62 — `if (settings.Any(f => f is AppSettingsConst == false && f is ApplicationSettingID == false)) throw new Exception("Invalid settings type"); var oldSettings = ...; var newSettings = ...;` - Begründung: Durchsetzende Typprüfung und Trennung der beiden Speicher.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, Z. 5817–5831 — `CREATE TABLE [dbo].[ApplicationSettings]` mit typisierten Wertspalten `ValueInt`, `ValueFloat`, `ValueDecimal`, `ValueBool`, `ValueDateTime`, `ValueText`, `ValueLargeText` und `PK_ApplicationSettings` - Begründung: Schema des aktuellen Einstellungsspeichers.
+  - [KONTEXT]  docs/guides/development/settings-management.md, Abschnitt „Settings Tables" - Begründung: Beschreibt die historische Doppelung und die Regel „all new settings should be added to the ApplicationSettings table".
+Prüfidee:      Aufruf `GetSettings("beliebigerString")`: Es muss eine Exception „Invalid settings type" ausgelöst werden.
+Tracelinks:    SyRS-827, SwRS-842
+Konsolidierung: Kandidat: SyRS-826 — `Stammdat` (AppSettingsConst) und `ApplicationSettings` (ApplicationSettingID) als zwei Speicher desselben Konzepts
+Übernahmewürdigkeit: Workaround - Doppelspeicher ist historisch bedingt; die Zusammenführung steht laut Doku noch aus.
+Status:        belegt
+Modul:         M-74
+
+ID:            SyRS-827
+Titel:         Clientseitiger Stammdaten-Cache beim Anwendungsstart
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Leistungseffizienz (Zeitverhalten)
+Akteur:        c-entron.NET Client (CentronCache)
+Vorbedingung:  Der Client ist am Web-Service angemeldet.
+Fakt:          `CentronCache.RefreshCacheAsync()` lädt über 70 Stammdaten- und Einstellungsmengen (u. a. `CurrentUserAppRights`, `MandatoryData`, `ReceiptSettings`, `DsgvoSettings`) parallel über `Parallel.ForEachAsync(thingsToLoad, ...)`, sammelt Einzelfehler in `_errors`, setzt `IsCacheLoaded = true` und veröffentlicht anschließend ein `CentronCacheRefreshedEvent` (src/centron/Centron.WPF.UI/Modules/Administration/Cache/CentronCache.cs, Z. 121–218).
+Aussage:       Das System soll häufig benötigte Stammdaten und Einstellungen beim Start des Clients einmalig parallel laden, Ladefehler einzeln erfassen und die Anwendung über den Abschluss des Ladevorgangs benachrichtigen.
+Ergebnis:      Nach dem Start stehen alle gecachten Listen ohne weitere Serveraufrufe zur Verfügung; bei Ladefehlern wird der Anwender auf mögliche Folgeprobleme hingewiesen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Administration/Cache/CentronCache.cs, Z. 205–217 — `await Parallel.ForEachAsync(thingsToLoad, async (thingToLoad, _) => await thingToLoad()); this.IsCacheLoaded = true; if (this.HasErrors) { this.ShowVerificationErrorMessage(true); } this.FireCacheRefreshedEvent();` - Begründung: Durchsetzende Ladelogik inkl. Fehlerbehandlung.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Administration/Cache/CentronCache.cs, Z. 349–352 — Meldungstext „Beim Erstellen des Cache ist ein Fehler aufgetreten. ... Bitte starten Sie die c-entron.NET neu." - Begründung: Belegt das definierte Verhalten gegenüber dem Anwender.
+Prüfidee:      Einen der geladenen Endpunkte serverseitig auf Fehler zwingen: Der Client muss den Cache dennoch fertigstellen und die Warnmeldung anzeigen.
+Tracelinks:    SyRS-826, SwRS-844
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zentrale Voraussetzung für die Antwortzeiten der Oberfläche.
+Status:        belegt
+Modul:         M-85

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_work/A9_StRS.md

@@ -0,0 +1,167 @@
+ID:            StRS-901
+Titel:         Zentraler Geschäftspartnerstamm für Kunden, Lieferanten und Kontakte
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertriebsmitarbeiter / Innendienst
+Vorbedingung:  Benutzer ist am System angemeldet und besitzt Rechte auf dem CRM-Modul.
+Fakt:          Die Tabelle `Accounts` (SSMS_DB_SCHEMA.sql, Zeile 3405) hält den gemeinsamen Kopfsatz (Name, Matchcode, Phone, Fax, Email, MandatorI3D, Adviser1I3D..Adviser6I3D, IsActive, IsLocked). Die Rollen "Kunde" und "Lieferant" werden über `AccountTypeToAccounts` und die Satelliten-Tabellen `AccountCustomers` (Zeile 3675) bzw. `AccountSuppliers` (Zeile 3795) angehängt; `AccountTypeKind` (src/backend/Centron.Interfaces/Accounts/AccountTypeKind.cs) kennt Customer, Supplier, Contact, Custom und sechs Sondertypen.
+Aussage:       Das System soll Kunden, Lieferanten, Interessenten und reine Kontakte als einen gemeinsamen Geschäftspartner-Datensatz (Account) führen und die Rolle über zuordenbare Kontoarten abbilden, sodass ein Geschäftspartner gleichzeitig Kunde und Lieferant sein kann.
+Ergebnis:      Ein Geschäftspartner ist genau einmal als Account gespeichert und trägt eine oder mehrere Kontoarten mit rollenspezifischen Zusatzdaten.
+Belege:
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[Accounts]` (Z. 3405), `CREATE TABLE [dbo].[AccountCustomers]` (Z. 3675), `CREATE TABLE [dbo].[AccountSuppliers]` (Z. 3795), `CREATE TABLE [dbo].[AccountTypeToAccounts]` (Z. 3865) - Begründung: Die Schemastruktur erzwingt die Trennung von Kopfsatz und Rollendaten über eine n:m-Zuordnung.
+  - [SEKUNDÄR] src/backend/Centron.BL/Accounts/AccountBL.cs, `SaveAccount` (Z. 473-537) - Begründung: Der Code leitet aus `account.AccountTypes.Any(f => f.CustomerData != null)` bzw. `SupplierData != null` ab, welche Rolle vorliegt, und prüft die Rechte je Rolle getrennt.
+  - [KONTEXT]  src/centron/Centron.WPF.UI/Modules/Finances/Crm/CrmAppModuleController.cs, `ModuleName`/`GetRights()` (Z. 71-99) - Begründung: Das CRM-Modul ist die fachliche Einstiegsmaske für den Adressstamm.
+Prüfidee:      Ein Account mit Kontoart Kunde und Lieferant anlegen; prüfen, dass genau ein Satz in `Accounts` sowie je ein Satz in `AccountCustomers` und `AccountSuppliers` mit derselben `AccountI3D`-Verknüpfung entsteht.
+Tracelinks:    SyRS-909, SyRS-910, SyRS-911, SwRS-925, SwRS-927
+Konsolidierung: Kandidat: StRS-901 / SyRS-911 - Accounts vs. Kunden/Kreditor
+Übernahmewürdigkeit: übernehmen - Der rollenbasierte Account ist das tragende Datenmodell des Vertriebs.
+Status:        belegt
+Modul:         M-88
+
+ID:            StRS-902
+Titel:         Lückenlose CRM-Tätigkeitshistorie je Geschäftspartner
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertriebsmitarbeiter / Servicemitarbeiter
+Vorbedingung:  Ein Account und mindestens ein Ansprechpartner existieren.
+Fakt:          `AccountActivities` (SSMS_DB_SCHEMA.sql, Z. 3189) speichert je Tätigkeit Caption, Text, TextRtf, AccountI3D, AccountAddressContactI3D, ActivityKind, EditorI3D, Rating, DueDate, ReferenceObjectI3D/ReferenceObjectKind und CampaignI3D. `AccountActivityKind` (src/backend/Centron.Interfaces/Accounts/Activities/AccountActivityKind.cs) definiert u. a. PhoneNote=0, Appointment=1, VisitReport=2, Note=3. `AccountActivitiesBL` erzeugt zusätzlich automatisch Tätigkeiten zu Belegen und Tickets (`CreateActivityForNewReceipt`, `CreateActivityForNewTicketSaves`, `CreateActivityForTicketClosed`).
+Aussage:       Das System soll alle Kundenkontakte (Telefonnotiz, Termin, Besuchsbericht, Notiz, E-Mail) sowie automatisch erzeugte Ereignisse aus Belegen und Tickets als CRM-Tätigkeit am Geschäftspartner und am Ansprechpartner protokollieren.
+Ergebnis:      Zu jedem Account existiert eine chronologische, filterbare Tätigkeitshistorie mit Bearbeiter und Bezugsobjekt.
+Belege:
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[AccountActivities]` (Z. 3189) - Begründung: Spalten AccountI3D und AccountAddressContactI3D sind NOT NULL, die Zuordnung ist damit erzwungen.
+  - [PRIMÄR]   src/backend/Centron.BL/Accounts/Activities/AccountActivitiesBL.cs, `CreateActivityForNewReceipt`, `CreateActivityForNewTicketSaves`, `CreateActivityForTicketClosed`, `CreateActivityForTicketForwarded` (Z. 568-750) - Begründung: Belegen die automatische Historienfortschreibung aus anderen Modulen.
+  - [SEKUNDÄR] src/backend/Centron.Interfaces/Accounts/Activities/AccountActivityKind.cs, `[Description("Telefonnotiz")]`, `[Description("Besuchsbericht")]` - Begründung: UI-Bezeichner der fachlichen Tätigkeitsarten.
+Prüfidee:      Beleg und Ticket zu einem Account anlegen und schließen; prüfen, dass für jedes Ereignis ein Satz in `AccountActivities` mit korrekter `AccountI3D` und passendem `ActivityKind` entsteht.
+Tracelinks:    SyRS-915, SyRS-916, SwRS-932, SwRS-944
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Die Tätigkeitshistorie ist Kern des CRM-Nutzens.
+Status:        belegt
+Modul:         M-89
+
+ID:            StRS-903
+Titel:         Werbesperre des Geschäftspartners respektieren
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Marketingmitarbeiter
+Vorbedingung:  Ein Account existiert; das Kennzeichen Werbesperre ist gesetzt oder nicht gesetzt.
+Fakt:          `Accounts.AdvertisingNotAllowed` ist `bit NOT NULL` (SSMS_DB_SCHEMA.sql, Z. 3405 ff.), ergänzt um `AdvertisingNotAllowedInfo nvarchar(200)`. `AccountSearchBL` baut daraus im erweiterten Filter die SQL-Bedingung `AND <acc>.AdvertisingNotAllowed = 1` bzw. `= 0` und kombiniert sie über `IIF(...ISNULL(<contact>.IsMailingAtEmail1Active,1)...)` mit dem Mailing-Kennzeichen des Ansprechpartners (src/backend/Centron.BL/Accounts/AccountSearchBL.cs, Z. 986-1013).
+Aussage:       Das System soll bei der Selektion von Empfängern für Werbe- und Mailing-Aktionen das Kennzeichen Werbesperre des Accounts sowie das Mailing-Kennzeichen des Ansprechpartners auswerten und gesperrte Empfänger ausschließen können.
+Ergebnis:      Empfängerlisten für Kampagnen und Serienmails enthalten keine Geschäftspartner mit gesetzter Werbesperre, wenn der Filter entsprechend gesetzt ist.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Accounts/AccountSearchBL.cs, Filterzweig `filter.IncludeOnlyAccountsWithNoAdvertisement` (Z. 986-1013) - Begründung: Die durchsetzende Stelle formt die WHERE-Bedingung auf `AdvertisingNotAllowed`.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/Crm/CrmMainView.xaml, Bindung `CurrentAccount.AdvertisingNotAllowedInfo` (Z. 1325-1329) - Begründung: Pflege- und Anzeigeort des Kennzeichens im CRM.
+  - [KONTEXT]  src/backend/Centron.DAO/Repositories/Accounts/AccountRepository.cs, `WriteAccountIntoKunden`: `customer.werbesperre = account.AdvertisingNotAllowed ? 1 : 0` (Z. 1218) - Begründung: Zeigt die Fortschreibung in die Altstruktur.
+Prüfidee:      Account mit `AdvertisingNotAllowed = 1` anlegen und eine Empfängerselektion mit `IncludeOnlyAccountsWithNoAdvertisement = false` ausführen; der Account darf nicht im Ergebnis erscheinen.
+Tracelinks:    StRS-906, SyRS-911, SwRS-937, SwRS-938
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Rechtlich erforderliche Werbeeinwilligungssteuerung.
+Status:        belegt
+Modul:         M-88
+
+ID:            StRS-904
+Titel:         Termine und CRM-Aktivitäten mit Outlook/Exchange abgleichen
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Mitarbeiter mit Exchange-Postfach
+Vorbedingung:  Exchange-/Graph-Zugangsdaten sind hinterlegt und der Kalender-Sync ist aktiviert.
+Fakt:          `AccountActivitiesBL.SyncCrmActivityToOutlookAsync` (src/backend/Centron.BL/Accounts/Activities/AccountActivitiesBL.cs, Z. 838 ff.) prüft `GetGraphCalendarSyncSettings().CentronCalendarSyncEnabled`, ermittelt den Graph-Benutzer über `GraphServiceClientHelper.GetUser` und schreibt ein `Microsoft.Graph.Models.Event`. Die Zuordnung erfolgt über die Tabelle `GroupwareEntryIDs` (SQL im selben Verfahren, Z. 868-873). Zusätzlich existiert ein Outlook-AddIn (src/nexus/CentronNexus.OutlookAddIn/CRM/CrmActivityPage.razor, `@page "/outlook-addin/crmactivitydetails"`).
+Aussage:       Das System soll CRM-Termine und Zeitplanungen bidirektional mit den Exchange-Postfächern der zuständigen Mitarbeiter abgleichen und die Zuordnung zwischen c-entron-Objekt und Exchange-Element dauerhaft speichern.
+Ergebnis:      Ein in c-entron erfasster CRM-Termin erscheint im Outlook-Kalender des Bearbeiters und behält bei Änderungen seine Identität.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Accounts/Activities/AccountActivitiesBL.cs, `SyncCrmActivityToOutlookAsync` (Z. 838-980) - Begründung: Implementiert den Abgleich inkl. Abbruchbedingungen (Sync deaktiviert, Mitarbeiter nicht in Sync-Abteilung).
+  - [SEKUNDÄR] src/nexus/CentronNexus.OutlookAddIn/CRM/CrmActivityPage.razor - Begründung: Belegt die Gegenrichtung, das Anlegen von CRM-Tätigkeiten aus Outlook heraus.
+  - [KONTEXT]  docs/features/exchange-sync-bugprotokoll.md, Tickets 164020, 163184, 164121 - Begründung: Dokumentiert bekannte Fehlerbilder und die eingebauten Schutzfilter des Sync-Pfades.
+Prüfidee:      CRM-Termin mit `SyncWithOutlook = true` speichern; im Zielpostfach muss ein Kalendereintrag existieren und `GroupwareEntryIDs` einen Satz mit `ObjektArt = AccountActivity` enthalten.
+Tracelinks:    SyRS-916, SyRS-918, SwRS-933, SwRS-935
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Outlook-Integration ist zentrale Arbeitsweise der Anwender.
+Status:        belegt
+Modul:         M-95
+
+ID:            StRS-905
+Titel:         Vertriebskampagnen mit Phasen, Teilnehmern und Entscheidungen steuern
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Kampagnenverantwortlicher
+Vorbedingung:  Benutzer ist Mitarbeiter und der Kampagne zugeordnet.
+Fakt:          `Campaigns` (SSMS_DB_SCHEMA.sql, Z. 34310) enthält Caption, StartDate, EndDate, State, PotentialRevenue; zugehörig existieren `CampaignPhases`, `CampaignPhaseActions`, `CampaignPhaseActionExecutes`, `CampaignParticipants`, `CampaignParticipantContactPerson`, `CampaignEmployees`, `CampaignMarkers`. `CampaignBL` (src/backend/Centron.BL/Accounts/Campaigns/CampaignBL.cs) bietet `AddParticipantsToCampaign`, `EnterCampaignParticipantDecision`, `EnterCampaignParticipantPhaseI3D`.
+Aussage:       Das System soll Kampagnen mit Laufzeit, Phasen, Phasenaktionen, zugeordneten Mitarbeitern sowie Teilnehmern (Accounts und deren Ansprechpartnern) verwalten und je Teilnehmer eine Entscheidung mit Begründungstext festhalten.
+Ergebnis:      Der Kampagnenfortschritt ist je Teilnehmer nachvollziehbar; Entscheidungen und Phasenzuordnungen sind gespeichert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Accounts/Campaigns/CampaignBL.cs, `EnterCampaignParticipantDecision` (Z. 213), `EnterCampaignParticipantPhaseI3D` (Z. 233), `AddParticipantsToCampaign` (Z. 133) - Begründung: Fachlogik der Kampagnenführung.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/Campaigns/CampaignAppModuleController.cs, `ModuleName => "Kampagnen/Mailing"`, `Description => "Erstellen und Verwalten von Kampagnen"` (Z. 14-17) - Begründung: UI-Bezeichner des Moduls.
+  - [KONTEXT]  SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[Campaigns]` (Z. 34310) und Folgetabellen ab Z. 34145 - Begründung: Datenmodell der Kampagne.
+Prüfidee:      Kampagne mit zwei Phasen und zwei Teilnehmern anlegen, für einen Teilnehmer eine Entscheidung erfassen; `CampaignParticipants` muss Entscheidungsart und -text führen.
+Tracelinks:    SyRS-923, StRS-906
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kampagnensteuerung ist eigenständiger Vertriebsprozess.
+Status:        belegt
+Modul:         M-92
+
+ID:            StRS-906
+Titel:         Serienmails an selektierte Empfängerkreise versenden und protokollieren
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Marketingmitarbeiter
+Vorbedingung:  Ein Mailing mit Texten, Anhängen und Empfängerliste ist angelegt.
+Fakt:          `MailingDataBL` (src/backend/Centron.BL/Mailings/MailingDataBL.cs) verwaltet `MailingData`, `MailingTexts`, `MailingAttachments`, `MailingToCustomer` und `MailingDataToRelationshipKind`. Der Versandassistent `SendMailWizardViewModel` (src/centron/Centron.WPF.UI/Modules/Finances/Campaigns/Pages/Mailing/SendMail/SendMailWizardViewModel.cs) versendet je Empfänger über `EwsEmailAccess.SendEmail`, schreibt Erfolg/Fehler in `Logs` und markiert den Empfänger über `SaveSendMail` (Z. 536 ff.) mit `item.Send = true; item.Date = DateTime.Now`.
+Aussage:       Das System soll Serienmails empfängerindividuell mit ersetzten Textvariablen versenden, jeden Versand pro Empfänger als gesendet mit Zeitstempel markieren und Fehlversuche protokollieren, sodass ein Wiederaufsetzen ohne Doppelversand möglich ist.
+Ergebnis:      Jeder Empfänger erhält höchstens eine Mail je Mailing; der Versandstatus ist je Empfänger gespeichert.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Finances/Campaigns/Pages/Mailing/SendMail/SendMailWizardViewModel.cs, `SaveSendMail` (Z. 536-545) und die Prüfung `if (this.AlreadySentMail(i)) continue;` (Z. 480) - Begründung: Verhindert Doppelversand beim Wiederaufsetzen.
+  - [SEKUNDÄR] Log-Texte "E-Mail an {mailAddress} erfolgreich versendet" / "Fehler beim Versand an {mailAddress}" (Z. 513-520) - Begründung: Fachliche Protokollierung im Versandprotokoll.
+  - [KONTEXT]  src/backend/Centron.BL/Mailings/MailingDataBL.cs, `SaveAllMailingTexts` (Z. 135) - Begründung: Persistierung der Versandmarkierung.
+Prüfidee:      Mailing mit drei Empfängern starten, nach dem zweiten abbrechen und erneut starten; der bereits versendete Empfänger darf keine zweite Mail erhalten.
+Tracelinks:    StRS-903, SyRS-920, SwRS-937, SwRS-938
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Serienmail ist ein produktiv genutzter Kernprozess des Marketings.
+Status:        belegt
+Modul:         M-99
+
+ID:            StRS-907
+Titel:         Eingehende Anrufe dem Geschäftspartner und Ansprechpartner zuordnen
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Telefonzentrale / Servicemitarbeiter
+Vorbedingung:  TAPI-Anbindung ist eingerichtet und Telefonnummern sind am Account bzw. Ansprechpartner gepflegt.
+Fakt:          `TapiBL` (src/backend/Centron.BL/Accounts/TapiBL.cs) pflegt eine Suchtabelle über `SaveAccountTapiNumbers`, `SaveTapiNumber` und `ResetAndCreateAllAccountTapiNumbers`; `PhoneCallBL.SearchContactPersonByPhoneNumberV2` (src/backend/Centron.BL/Tapi/PhoneCallBL.cs, Z. 149 ff.) normalisiert die Rufnummer über `TapiBL.FormatPhoneNumber` und liefert `CustomerWithContactPerson`. `PhoneCallBL.SaveOrUpdateCall` (Z. 73) persistiert Anrufe mit CallerNumber, StartTime, EndTime und DurationInSeconds.
+Aussage:       Das System soll bei einem eingehenden Anruf die übermittelte Rufnummer normalisieren, den zugehörigen Geschäftspartner samt Ansprechpartner ermitteln und den Anruf mit Dauer und Richtung protokollieren.
+Ergebnis:      Der Anwender sieht beim Anruf den erkannten Geschäftspartner; der Anruf ist im Anrufjournal gespeichert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Tapi/PhoneCallBL.cs, `SearchContactPersonByPhoneNumberV2` (Z. 149-...) und `SaveOrUpdateCall` (Z. 73-99) - Begründung: Suche und Persistenz sind hier implementiert.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Administration/PhoneSettings/PhoneSettingsController.cs, `Caption => "Telefonie"` (Z. 23) - Begründung: Einstellungsmodul für die Telefonie.
+  - [KONTEXT]  docs/reference/architecture/tapi.md - Begründung: Beschreibt die eingesetzte TraySoft-AddTAPI.NET-Komponente und die Debug-Wege.
+Prüfidee:      Anruf mit einer am Ansprechpartner gepflegten Nummer in internationaler Schreibweise simulieren; die Suche muss den Ansprechpartner finden und ein `PhoneCall`-Satz muss entstehen.
+Tracelinks:    SyRS-912, SwRS-940
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Anruferkennung ist etablierter Servicevorteil.
+Status:        belegt
+Modul:         M-101
+
+ID:            StRS-908
+Titel:         Kundenaudits und Umfragen erstellen, versenden und auswerten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Auditor / Qualitätsbeauftragter
+Vorbedingung:  Eine Umfragevorlage ist im Modul "Audit" angelegt und ein Account als Befragter zugeordnet.
+Fakt:          `SurveyProcessBL` (src/backend/Centron.BL/Accounts/Survey/SurveyProcessBL.cs) verwaltet Vorlagen (`SaveSurvey`, `UpdateSurvey`), Ordner (`GetSurveyFolders`), Fragenkategorien (`GetSurveyQuestionCategories`) und erzeugt aus einer Vorlage eine konkrete Umfrage (`GetSurveyfromTemplate`, Z. 607). `SendEMailToSurveyReleasedFrom` (Z. 265) versendet eine Statusmail mit Link auf `"{sboUrl}/SurveyModule?ID={cryptedSurveyI3D}"`.
+Aussage:       Das System soll Umfrage-/Auditvorlagen verwalten, daraus kundenbezogene Umfragen erzeugen, diese per verschlüsseltem Link über das ServiceBoard-Online bereitstellen und den Freigebenden bei Statusänderung per E-Mail informieren.
+Ergebnis:      Der Befragte erreicht die Umfrage über einen personalisierten Link; der Freigebende wird über den Abschluss informiert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Accounts/Survey/SurveyProcessBL.cs, `SendEMailToSurveyReleasedFrom` (Z. 265-317) - Begründung: Enthält Linkbildung und Mailversand.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Survey/SurveyAppModuleController.cs, `ModuleName => "Audit"` (Z. 19) - Begründung: Fachliche Modulbezeichnung im UI weicht vom technischen Namen "Survey" ab.
+  - [KONTEXT]  src/backend/Centron.BL/Accounts/Survey/SurveyProcessBL.cs, `GetSurveyfromTemplate` liest `GetDsgvoSettings().SboUrl` (Z. 613) - Begründung: Zeigt die Abhängigkeit von der ServiceBoard-Online-URL.
+Prüfidee:      Umfrage aus Vorlage erzeugen und Status auf abgeschlossen setzen; die Mail an den Freigebenden muss den korrekten Link mit verschlüsselter ID enthalten.
+Tracelinks:    SwRS-943
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Audits sind eigenständiger, kundenbezogener Prozess.
+Status:        belegt
+Modul:         M-104

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_work/A9_SyRS.md

@@ -0,0 +1,331 @@
+ID:            SyRS-909
+Titel:         Rechteprüfung beim Anlegen, Ändern und Löschen von Accounts
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Centron.BL (AccountBL)
+Vorbedingung:  Ein angemeldeter c-entron-Benutzer ruft eine schreibende Account-Operation auf.
+Fakt:          `AccountBL.ValidateUserRights(int appUserI3D, bool newCustomer, bool getAccount, bool deleteAccount, bool editAccount, bool unlockAccount, bool newSupplier, bool editSupplier)` (src/backend/Centron.BL/Accounts/AccountBL.cs, Z. 1299-1370) lädt über `AppRightsBL.CheckRightsFromUser` die Rechte CREATE_CUSTOMER (20400092), EDIT_CUSTOMER (20400093), DELETE_CUSTOMER (20400016), SEARCH_CUSTOMER (20400088), UNLOCK_CUSTOMER (2040003), RIGHT_LIEFERANTANLEGEN, RIGHT_LIEFERANTAENDERN und gibt je nach Flag `Result.AsError(..., DefaultMessageCodes.RightCheckFailed)` zurück. `SaveAccount` (Z. 473) ruft die Prüfung mit `newCustomer/newSupplier` bei `account.I3D <= 0` und mit `editAccount/editSupplier` sonst auf; `DeleteAccount` (Z. 754) mit `deleteAccount: true`, `UnlockAccount` (Z. 928) mit `unlockAccount: true`. Der Überladung `ValidateUserRights(LoggedInUser ...)` (Z. 1290) lehnt Web-Account-Logins generell ab.
+Aussage:       Das System soll jede schreibende Operation auf einem Account gegen das rollenspezifische Benutzerrecht prüfen und bei fehlendem Recht die Operation mit dem Meldungscode RightCheckFailed abbrechen; Web-Account-Logins sollen für Account-Schreiboperationen grundsätzlich abgelehnt werden.
+Ergebnis:      Ohne passendes Recht wird kein Account angelegt, geändert, gelöscht oder entsperrt; der Aufrufer erhält eine Fehlermeldung mit RightCheckFailed.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Accounts/AccountBL.cs, `ValidateUserRights` (Z. 1299-1370): Bedingung `if (!checkRightsResult.Contains(UserRightsConst.Sales.Customer.CustomerCommon.CREATE_CUSTOMER)) return Result.AsError("Fehlende Rechte um Accounts zu erstellen", DefaultMessageCodes.RightCheckFailed);` - Begründung: Durchsetzende Stelle mit konkreter Prüfbedingung.
+  - [PRIMÄR]   src/backend/Centron.BL/Accounts/AccountBL.cs, `ValidateUserRights(LoggedInUser...)` (Z. 1294): `if (loggedInUser.IsWebAccountLogin) return Result.AsError("Webaccount hat keine Rechte für diese Aktion", ...)` - Begründung: Explizite Sperre für Webaccounts.
+  - [SEKUNDÄR] src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs, Z. 2041, 2073, 2105, 2107, 2122 - Begründung: Numerische Rechte-IDs der geprüften Rechte.
+Prüfidee:      Benutzer ohne DELETE_CUSTOMER anmelden und `DeleteAccount` aufrufen; das Ergebnis muss Status Error mit `DefaultMessageCodes.RightCheckFailed` und der Text "Fehlende Rechte um Accounts zu löschen" sein.
+Tracelinks:    StRS-901, SwRS-928, SwRS-929
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zentrale Zugriffskontrolle des Adressstamms.
+Status:        belegt
+Modul:         M-88
+
+ID:            SyRS-910
+Titel:         Löschsperre für Accounts mit offenen Posten, Tickets oder Verträgen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Centron.BL (AccountBL)
+Vorbedingung:  Der Benutzer besitzt DELETE_CUSTOMER und fordert das Löschen eines Accounts an, der eine Kundennummer besitzt.
+Fakt:          `AccountBL.DeleteAccount` (src/backend/Centron.BL/Accounts/AccountBL.cs, Z. 752-803) ermittelt über `_accountRepository.GetCustomerNumberFromAccount` die Kundennummer und bricht ab, wenn `AccountStatisticBL.GetAccountUnpaidInvoiceOverview` einen Eintrag mit `ObjectKind == CentronObjectKindNumeric.InvoiceClass` liefert ("Account kann nicht gelöscht werden da noch offene Posten vorhanden sind.", DefaultMessageCodes.InvalidDeleteRequest), wenn `HelpdeskSearchBL.GetActiveHelpdesksFromCustomer` Treffer liefert oder wenn `ReceiptSearcher.SearchReceipts` mit `ReceiptKinds = ContractClass` und `IncludeClosedReceipts = false` Treffer liefert.
+Aussage:       Das System soll das Löschen eines Accounts verweigern, solange zu dessen Kundennummer offene Rechnungen, aktive Helpdesk-Tickets oder nicht abgeschlossene Verträge existieren.
+Ergebnis:      Der Löschvorgang wird mit Meldungscode InvalidDeleteRequest und einer den Grund benennenden Meldung abgewiesen; die Daten bleiben unverändert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Accounts/AccountBL.cs, `DeleteAccount` (Z. 762-800): drei aufeinanderfolgende Abbruchbedingungen mit `Result.AsError(..., DefaultMessageCodes.InvalidDeleteRequest)` - Begründung: Durchgesetzte Integritätsregel vor dem physischen Löschen.
+  - [SEKUNDÄR] Meldungstexte "…noch offene Posten…", "…noch offene Heldesks…", "…noch offene Verträge…" - Begründung: Fachliche Begründung der Sperre (Tippfehler "Heldesks" im Original).
+Prüfidee:      Account mit einer offenen Rechnung löschen wollen; Rückgabe muss Status Error und Code InvalidDeleteRequest sein, der Account bleibt in `Accounts` erhalten.
+Tracelinks:    StRS-901, SyRS-909
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Schützt Buchhaltungs- und Servicebezüge vor Referenzverlust.
+Status:        belegt
+Modul:         M-88
+
+ID:            SyRS-911
+Titel:         Doppelte Datenhaltung Accounts/AccountCustomers gegenüber Kunden/Kreditor
+Ebene:         SyRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Centron.DAO (AccountRepository)
+Vorbedingung:  Ein Account mit Kontoart Kunde oder Lieferant wird gespeichert.
+Fakt:          `AccountRepository.WriteAccountIntoKunden(IAccount account, IAccountCustomer accountCustomer, Kunden customer)` (src/backend/Centron.DAO/Repositories/Accounts/AccountRepository.cs, Z. 1160-1240 ff.) schreibt jedes Feld des neuen Modells in die Altstruktur zurück, u. a. `customer.Status = account.IsActive ? 1 : 0`, `customer.Gesperrt = account.IsLocked ? 1 : 0`, `customer.werbesperre = account.AdvertisingNotAllowed ? 1 : 0`, `customer.InnendienstID = account.Adviser1I3D`, `customer.BuchhaltNr = accountCustomer.BookKeepingNumber`. Die Gegenrichtung leistet `FillAccountFromOldCustomerReference` (Z. 583-660). Ergänzend spiegelt `AccountBL.UpdateLockedInOldStructure` (Z. 944-962) das Sperrkennzeichen und `ReactivateAccount` (Z. 714-728) setzt `Kunden.Status`/`Kreditor.Status` auf 1.
+Aussage:       Das System soll denselben Geschäftspartner nicht dauerhaft in zwei Datenhaltungen (Accounts/AccountCustomers/AccountSuppliers und Kunden/Kreditor/Anschrif/Personen) parallel führen; bis zur Ablösung der Altstruktur soll jede Änderung am Account transaktional und vollständig in die Altstruktur gespiegelt werden.
+Ergebnis:      Nach jedem Speichern eines Accounts stimmen die gespiegelten Felder in `Kunden` bzw. `Kreditor` mit dem Account überein.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.DAO/Repositories/Accounts/AccountRepository.cs, `SaveAccountAsCustomer` (Z. 1124) und `WriteAccountIntoKunden` (Z. 1160) - Begründung: Durchsetzende Stelle der Spiegelung.
+  - [PRIMÄR]   src/backend/Centron.BL/Accounts/AccountBL.cs, `UpdateLockedInOldStructure` (Z. 944-962) - Begründung: Separate Zweitspiegelung des Sperrkennzeichens außerhalb des Repository-Pfades.
+  - [KONTEXT]  SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[Kunden]` (Z. 2767), `CREATE TABLE [dbo].[Kreditor]` (Z. 2490), `CREATE TABLE [dbo].[Anschrif]` (Z. 7394), `CREATE TABLE [dbo].[Personen]` (Z. 7324) - Begründung: Belegt den Fortbestand der Altstruktur.
+Prüfidee:      Account speichern, danach `SELECT Status, Gesperrt, werbesperre, InnendienstID FROM Kunden WHERE I3D = <Kundennummer>` ausführen; alle Werte müssen den Account-Feldern entsprechen.
+Tracelinks:    StRS-901, StRS-903, SwRS-928, SwRS-929
+Konsolidierung: Kandidat: SyRS-911 - Accounts/AccountCustomers/AccountSuppliers vs. Kunden/Kreditor für denselben Geschäftspartnerbegriff
+Übernahmewürdigkeit: Workaround - Die Doppelhaltung ist ein Migrationsartefakt und langfristig abzulösen.
+Status:        belegt
+Modul:         M-88
+
+ID:            SyRS-912
+Titel:         Sichtbarkeitsbeschränkung auf eigene Kunden
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Centron.BL (AccountAddressBL, AccountActivitiesBL)
+Vorbedingung:  Der angemeldete Benutzer besitzt das Recht SHOW_ONLY_OWN_CUSTOMER (20400339).
+Fakt:          `AccountAddressBL.GetAccountAddresses` (src/backend/Centron.BL/Accounts/AccountAddressBL.cs, Z. 110-135) prüft `_appRightsBL.HasUserRight(loggedInUser.UserI3D.Value, UserRightsConst.Sales.Customer.CustomerCommon.SHOW_ONLY_OWN_CUSTOMER)` und bricht mit `Result.AsError("Sie haben nicht das Recht um Anschriften von anderen Kunden zu sehen!", DefaultMessageCodes.RightCheckFailed)` ab, wenn im Ergebnis Accounts enthalten sind, bei denen keiner der Betreuer `Adviser1I3D` bis `Adviser6I3D` der Mitarbeiter-I3D des Benutzers entspricht. `AccountActivitiesBL.OnlyOwn` (Z. 500-524) leitet aus SEARCH_CUSTOMER und SHOW_ONLY_OWN_CUSTOMER die Stufen `All`, `OnlyOwn` oder `None` ab.
+Aussage:       Das System soll Benutzern mit dem Recht SHOW_ONLY_OWN_CUSTOMER ausschließlich Geschäftspartner und deren Anschriften und Tätigkeiten zugänglich machen, bei denen der Benutzer als einer der sechs Betreuer eingetragen ist.
+Ergebnis:      Fremde Accounts werden nicht ausgeliefert; der Zugriff wird mit RightCheckFailed abgewiesen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Accounts/AccountAddressBL.cs, `GetAccountAddresses` (Z. 113-133): Abgleich `f.Adviser1I3D.GetValueOrDefault(0) != employeeI3D && … != employeeI3D` und anschließender Fehler - Begründung: Konkrete durchsetzende Bedingung.
+  - [PRIMÄR]   src/backend/Centron.BL/Accounts/Activities/AccountActivitiesBL.cs, `OnlyOwn` (Z. 515-521) - Begründung: Rechteableitung für die Tätigkeitssuche.
+  - [SEKUNDÄR] src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs, Z. 2187 `SHOW_ONLY_OWN_CUSTOMER = 20400339` - Begründung: Identität des Rechts.
+Prüfidee:      Benutzer mit SHOW_ONLY_OWN_CUSTOMER anmelden und Adressen eines Accounts abrufen, bei dem er nicht Betreuer ist; die Anfrage muss mit RightCheckFailed abgewiesen werden.
+Tracelinks:    StRS-901, StRS-907, SyRS-913
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Mandanten- und Gebietsschutz im Vertrieb.
+Status:        belegt
+Modul:         M-90
+
+ID:            SyRS-913
+Titel:         Rechteprüfung für Ansprechpartner getrennt nach Kunde, Lieferant und Kontakt
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Centron.BL (AccountAddressContactBL)
+Vorbedingung:  Ein Ansprechpartner soll angelegt oder geändert werden.
+Fakt:          `AccountAddressContactBL.ValidateUserRights(int currentUserI3D, bool createContactPartner, bool editContactPartner, bool isSupplier, bool isCustomer)` (src/backend/Centron.BL/Accounts/AccountAddressContactBL.cs, Z. 375-418) lädt CREATE_CUSTOMER, EDIT_CUSTOMER, CREATE_ADDRESS_CONTACT (20400094), EDIT_CUSTOMER_CONTACT (20400095), RIGHT_LIEFERANTANSPRIGHT_PARTNERANLEGEN, RIGHT_LIEFERANTANSPRIGHT_PARTNERAENDERN, RIGHT_LIEFERANTANLEGEN, RIGHT_LIEFERANTAENDERN. Für Lieferanten genügt eines der beiden Lieferantenrechte, für Kunden eines der beiden Kundenrechte; für reine Kontakte (weder Kunde noch Lieferant) gilt der Kundenzweig.
+Aussage:       Das System soll das Anlegen und Ändern von Ansprechpartnern jeweils gegen die für die Kontoart passende Rechtekombination prüfen und bei fehlendem Recht mit einer die Kontoart benennenden Fehlermeldung abbrechen.
+Ergebnis:      Ansprechpartner können nur von berechtigten Benutzern angelegt oder geändert werden.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Accounts/AccountAddressContactBL.cs, `ValidateUserRights` (Z. 389-415): z. B. `if (isCustomer && editContactPartner && (checkRightsResult.Contains(EDIT_CUSTOMER) || checkRightsResult.Contains(EditCustomer.EDIT_CUSTOMER_CONTACT)) == false) return Result.AsError("Fehlendes Recht um Kundenansprechpartner zu bearbeiten");` - Begründung: Durchsetzende Stelle mit ODER-Verknüpfung der zulässigen Rechte.
+  - [SEKUNDÄR] UserRightsConst.cs, Z. 2047 `CREATE_ADDRESS_CONTACT = 20400094`, Z. 2082 `EDIT_CUSTOMER_CONTACT = 20400095` - Begründung: Identität der Rechte.
+Prüfidee:      Benutzer nur mit CREATE_ADDRESS_CONTACT (ohne CREATE_CUSTOMER) legt einen Kundenansprechpartner an; das muss gelingen. Ohne beide Rechte muss die Meldung "Fehlendes Recht um Kundenansprechpartner zu erstellen" erscheinen.
+Tracelinks:    SyRS-912, SyRS-914, SwRS-931
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Feingranulare Rechte werden produktiv genutzt.
+Status:        belegt
+Modul:         M-90
+
+ID:            SyRS-914
+Titel:         Rechteprüfung für Anschriften einschließlich Rückrollen von Sprache und Währung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Centron.BL (AccountAddressBL)
+Vorbedingung:  Eine Anschrift eines Accounts wird angelegt oder geändert.
+Fakt:          `AccountAddressBL.ValidateUserRight(int currentUserI3D, bool createAddress, bool editAddress)` (src/backend/Centron.BL/Accounts/AccountAddressBL.cs, Z. 255-280) verlangt zum Anlegen CREATE_ADDRESS (20800124) und zum Ändern sowohl EDIT_CUSTOMER als auch EDIT_LOCATION (20400232). `CheckSpecialUserRightForAddressLanguageBeforeSave` (Z. 282-306) und `CheckSpecialUserRightForAddressCurrencyBeforeSave` (Z. 308-332) setzen bei fehlendem EDIT_CUSTOMER_ADDRESS_LANGUAGE (20800119) bzw. EDIT_CUSTOMER_ADDRESS_CURRENCY (20800140) das jeweilige Feld über `Session.GetOriginalEntityProperty` auf den Ursprungswert zurück, statt den Speichervorgang abzubrechen.
+Aussage:       Das System soll das Anlegen und Ändern von Anschriften rechtegeprüft durchführen und Änderungen an Sprache und Währung einer Anschrift ohne das jeweilige Sonderrecht stillschweigend auf den Ursprungswert zurücksetzen.
+Ergebnis:      Unberechtigte Sprach- oder Währungsänderungen werden nicht persistiert; alle übrigen Änderungen der Anschrift werden gespeichert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Accounts/AccountAddressBL.cs, `ValidateUserRight` (Z. 264-277) mit `DefaultMessageCodes.RightCheckFailed` - Begründung: Durchsetzende Rechteprüfung.
+  - [PRIMÄR]   src/backend/Centron.BL/Accounts/AccountAddressBL.cs, `CheckSpecialUserRightForAddressCurrencyBeforeSave` (Z. 319-325): `address.CurrencyI3D = (int)this.Session.GetSession().GetOriginalEntityProperty(address, nameof(address.CurrencyI3D));` - Begründung: Konkrete Rücksetzlogik als durchsetzende Stelle.
+  - [SEKUNDÄR] UserRightsConst.cs, Z. 2052, 2093, 2099, 2171 - Begründung: Identität der beteiligten Rechte.
+Prüfidee:      Benutzer ohne EDIT_CUSTOMER_ADDRESS_CURRENCY ändert die Währung einer bestehenden Anschrift und speichert; nach dem Speichern muss `AccountAddresses.CurrencyI3D` unverändert sein, während andere geänderte Felder gespeichert sind.
+Tracelinks:    SyRS-912, SyRS-913, SwRS-931
+Konsolidierung: nein
+Übernahmewürdigkeit: Sonderfall - Stilles Rückrollen statt Abbruch ist ungewöhnlich und sollte fachlich bestätigt werden.
+Status:        belegt
+Modul:         M-90
+
+ID:            SyRS-915
+Titel:         Pflichtangaben und Konsistenzregeln beim Speichern einer CRM-Tätigkeit
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Centron.BL (AccountActivitiesBL)
+Vorbedingung:  Ein Benutzer speichert eine CRM-Tätigkeit.
+Fakt:          `AccountActivitiesBL.SaveAccountActivity` (src/backend/Centron.BL/Accounts/Activities/AccountActivitiesBL.cs, Z. 87-103) bricht ab bei leerem `Caption` ("Betreff darf nicht leer sein."), bei `AccountI3D <= 0` ("Account muss ausgewählt sein."), bei `AccountAddressContactI3D <= 0` ("Ansprechpartner muss ausgewählt sein."), bei `ActivityKind == AccountActivityKind.Appointment` ohne `DateFrom`/`DateTo` ("Bei einem Termin muss ein Startdatum und Enddatum ausgewählt sein.") und bei `EditorI3D <= 0` ("Bearbeiter muss ausgewählt sein."). Anschließend werden Anlage- und Änderungsstempel inklusive `CreatedVersion`/`ChangedVersion` aus der Assembly-Version gesetzt.
+Aussage:       Das System soll eine CRM-Tätigkeit nur speichern, wenn Betreff, Account, Ansprechpartner und Bearbeiter gesetzt sind und bei der Tätigkeitsart Termin zusätzlich Start- und Endzeitpunkt vorliegen; Anlage- und Änderungsdaten inklusive Programmversion sollen automatisch gesetzt werden.
+Ergebnis:      Unvollständige Tätigkeiten werden mit sprechender Fehlermeldung abgewiesen; gespeicherte Tätigkeiten tragen vollständige Audit-Stempel.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Accounts/Activities/AccountActivitiesBL.cs, `SaveAccountActivity` (Z. 93-102) - Begründung: Durchgesetzte Validierungsregeln.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `AccountActivities`: `[AccountI3D] int NOT NULL`, `[AccountAddressContactI3D] int NOT NULL`, `[EditorI3D] int NOT NULL`, `[Caption] nvarchar(255) NOT NULL` (Z. 3189 ff.) - Begründung: DB-Constraint stützt dieselbe Regel.
+Prüfidee:      Tätigkeit vom Typ Appointment ohne `DateTo` speichern; die Rückgabe muss Status Error mit dem Text "Bei einem Termin muss ein Startdatum und Enddatum ausgewählt sein." liefern.
+Tracelinks:    StRS-902, SyRS-916, SwRS-932
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Sichert Auswertbarkeit der CRM-Historie.
+Status:        belegt
+Modul:         M-89
+
+ID:            SyRS-916
+Titel:         Bedingter Outlook-Abgleich einer CRM-Tätigkeit über Microsoft Graph
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Centron.BL (AccountActivitiesBL, ScheduleBL)
+Vorbedingung:  Eine CRM-Tätigkeit wurde erfolgreich gespeichert und trägt `SyncWithOutlook = true`.
+Fakt:          `AccountActivitiesBL.SaveAccountActivity` (Z. 161-171) startet den Abgleich nur, wenn Transaktion erfolgreich war, `SyncWithOutlook` gesetzt ist und `_graphClient != null`; Fehler werden lediglich als Warnung geloggt. `SyncCrmActivityToOutlookAsync` (Z. 838-855) bricht ab, wenn `GetGraphCalendarSyncSettings().CentronCalendarSyncEnabled` false ist oder `ScheduleBL.CheckEmployeeInSyncDepartment(employee.I3D)` false liefert. Betreff und Text stammen wahlweise aus `CrmOutlookCustomSubject`/`CrmOutlookCustomBody`, der Ort wird aus `OutlookAppointementPlace` mit den Platzhaltern `@@Strasse@@`, `@@PLZ@@`, `@@Ort@@` gebildet.
+Aussage:       Das System soll den Outlook-Abgleich einer CRM-Tätigkeit nur ausführen, wenn der Kalender-Sync global aktiviert und der Bearbeiter einer Sync-Abteilung zugeordnet ist, und soll einen fehlgeschlagenen Abgleich nicht zum Fehlschlag des Speichervorgangs führen lassen.
+Ergebnis:      Die Tätigkeit ist in jedem Fall in c-entron gespeichert; der Kalendereintrag entsteht nur unter den genannten Bedingungen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Accounts/Activities/AccountActivitiesBL.cs, `SyncCrmActivityToOutlookAsync` (Z. 840-855) - Begründung: Beide Abbruchbedingungen sind hier implementiert.
+  - [PRIMÄR]   src/backend/Centron.BL/Accounts/Activities/AccountActivitiesBL.cs (Z. 167-170): `_logger.Warn("CRM Outlook sync failed for activity {ActivityI3D}: {Message}", …)` - Begründung: Belegt die Entkopplung von Speichern und Synchronisieren.
+  - [SEKUNDÄR] src/backend/Centron.BL/Calendar/CalendarBL.cs, `GetCalendarSynchronizationSettings` (Z. 52-89) mit `CrmOutlookUseCustomSubject`, `CrmOutlookCustomBody` - Begründung: Konfigurationsschalter der Vorlagen.
+Prüfidee:      Kalender-Sync deaktivieren, Tätigkeit mit `SyncWithOutlook = true` speichern; die Tätigkeit muss gespeichert sein und im Postfach darf kein Ereignis entstehen.
+Tracelinks:    StRS-902, StRS-904, SwRS-932, SwRS-933
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Robuste Entkopplung der externen Schnittstelle.
+Status:        belegt
+Modul:         M-89
+
+ID:            SyRS-917
+Titel:         Terminanfrage mit Terminvorschlägen über Exchange abwickeln
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Centron.BL (AppointmentRequestBL)
+Vorbedingung:  Zu einer Terminanfrage existieren Terminvorschläge im Exchange-Kalender; der Kunde antwortet über den Rückantwortlink mit der GUID der Anfrage.
+Fakt:          `AppointmentRequestBL.HandleAppointmentRequestReply(AppointmentRequestReply reply)` (src/backend/Centron.BL/AppointmentRequests/AppointmentRequestBL.cs, Z. 29-114) sucht die Anfrage über `filter.Guid`, lädt alle `AppointmentProposal`, baut eine `EwsConnection` aus den Mail-Einstellungen und wirft bei fehlenden Zugangsdaten `new Exception("No Credential found to Connect to EWS")`. Bei `reply.AcceptedProposalI3D == null` werden alle Vorschläge über `item.Delete(DeleteMode.MoveToDeletedItems)` entfernt und der Status auf `AppointmentRequestState.AppointmentProposalsRejected` gesetzt; sonst wird der akzeptierte Termin um " (Akzeptiert)" ergänzt, `appointmentRequest.ContactEmail` als Pflichtteilnehmer aufgenommen, die Kategorie von "Terminvereinbarung (offen)" auf "Terminvereinbarung (akzeptiert)" gewechselt und alle übrigen Vorschläge `SoftDelete`-gelöscht; der Status wird `AppointmentProposalAccepted`.
+Aussage:       Das System soll auf die Antwort zu einer Terminanfrage hin genau den akzeptierten Terminvorschlag im Exchange-Kalender bestätigen, den Anfragenden als Teilnehmer einladen, alle übrigen Vorschläge entfernen und den Anfragestatus entsprechend fortschreiben.
+Ergebnis:      Im Exchange-Kalender verbleibt genau ein bestätigter Termin; `AppointmentRequests.RequestState` spiegelt die Entscheidung.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/AppointmentRequests/AppointmentRequestBL.cs, `HandleAppointmentRequestReply` (Z. 71-111) - Begründung: Durchgesetzter Zustandsübergang inkl. Exchange-Operationen.
+  - [SEKUNDÄR] Kategoriewechsel `item.Categories.Remove("Terminvereinbarung (offen)")` / `Add("Terminvereinbarung (akzeptiert)")` (Z. 95-96) - Begründung: Fachliche Kennzeichnung im Outlook-Kalender.
+  - [KONTEXT]  SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[AppointmentRequests]` (Z. 25557) mit `[Guid] uniqueidentifier NOT NULL`, `[RequestState] int NOT NULL` - Begründung: Datenmodell inkl. Rückantwort-Schlüssel.
+Prüfidee:      Terminanfrage mit drei Vorschlägen erzeugen, einen annehmen; anschließend darf im Postfach nur der akzeptierte Termin bestehen und `RequestState` muss `AppointmentProposalAccepted` sein.
+Tracelinks:    StRS-904, SwRS-934
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Automatisierte Terminvereinbarung mit dem Kunden.
+Status:        belegt
+Modul:         M-94
+
+ID:            SyRS-918
+Titel:         Zentrale Konfiguration von Kalenderdarstellung und Kalendersynchronisation
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Administrator
+Vorbedingung:  Der Administrator öffnet die Kalendereinstellungen.
+Fakt:          `CalendarBL` (src/backend/Centron.BL/Calendar/CalendarBL.cs) liest und schreibt drei Einstellungsgruppen über `AppSettingsBL`: Darstellung (`GetCalendarRepresentationSettings`/`UpdateCalendarRepresentationSettings`, zehn Schalter von `HelpdeskTimeDisplayRepresentationShortDescription` bis `HelpdeskTimeDisplayDescription`), Synchronisation (`GetCalendarSynchronizationSettings`/`UpdateCalendarSynchronizationSettings` mit `OutlookAppointementCategory`, `OutlookAppointementPlace`, `OutlookAppointementHelpdeskTimeOvertake`, `CrmActivityTypesForOutlookSync`) und Terminvorlagen für Tickets (`GetAppointmentsForTicketsSettings`). Im UI entsprechen dem die Controller unter src/centron/Centron.WPF.UI/Modules/Calendar/Settings/{Representations,Synchronization,CrmOutlookTemplate,AppointmentsForTickets}.
+Aussage:       Das System soll die Darstellung von Kalendereinträgen, die Outlook-Synchronisationsvorlagen und die Terminvorlagen für Tickets als mandantenweite Anwendungseinstellungen verwalten, die über eigene Einstellungsseiten gepflegt werden.
+Ergebnis:      Geänderte Kalendereinstellungen sind über `SaveSettings()` persistiert und wirken für alle Benutzer.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Calendar/CalendarBL.cs, `UpdateCalendarRepresentationSettings` (Z. 107-137) und `UpdateCalendarSynchronizationSettings` (Z. 139-177) - Begründung: Durchsetzende Persistenzstelle über `GetSettingsForUpdate`/`SaveSettings`.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Calendar/Settings/Synchronization/CalendarSynchronizationSettingsController.cs und .../Representations/CalendarRepresentationsSettingsController.cs - Begründung: Einstiegspunkte im UI.
+Prüfidee:      Einstellung `HelpdeskTimeDisplayCustomerData` umschalten, Anwendung neu starten und den Wert erneut lesen; er muss erhalten bleiben.
+Tracelinks:    StRS-904, SwRS-935
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Notwendige Konfigurationsebene des Kalenders.
+Status:        belegt
+Modul:         M-93
+
+ID:            SyRS-919
+Titel:         Fallback-Hierarchie bei der Auflösung von Mailvorlagen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Centron.BL (MailTemplateBL)
+Vorbedingung:  Ein Vorgang benötigt eine Mailvorlage zu einer `MailTemplateReference`.
+Fakt:          `MailTemplateBL.MailTemplate(MailTemplateReference, int? branchI3D, int? accountI3D, int? employeeI3D)` (src/backend/Centron.BL/Mail/Templates/MailTemplateBL.cs, Z. 248-317) sucht in der dokumentierten Reihenfolge Account ("customer"), Mitarbeiter ("personal"), Filiale ("branch"), global ("global") und liefert andernfalls eine neu erzeugte Vorlage mit `pulledLocation = "hardcoded default fallback"`. Fehlende Betreff- oder Textfelder werden über `HandleIfSubjectOrBodyNotDefined` aus `mailTemplateReference.DefaultSubject`/`DefaultBody` ergänzt. `GetMailTemplate` (Z. 319-359) protokolliert die Fundstelle über `Logger.Info($"Pulled mailtemplate from {pulledLocation} …")`.
+Aussage:       Das System soll eine Mailvorlage in der Reihenfolge Geschäftspartner, Mitarbeiter, Filiale, global auflösen, bei fehlender Vorlage einen definierten Standardtext verwenden und die verwendete Fundstelle protokollieren.
+Ergebnis:      Es wird stets eine Vorlage mit gefülltem Betreff und Text geliefert; die Herkunft ist im Log nachvollziehbar.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Mail/Templates/MailTemplateBL.cs, `MailTemplate(...)` (Z. 265-297) - Begründung: Durchgesetzte Reihenfolge der Fallbacks.
+  - [SEKUNDÄR] docs/guides/development/create-mail-templates.md, Abschnitt "New Mail Template structure" - Begründung: Beschreibt die Identifikation über ObjectKind, ObjectI3D, SubObjectKind, TemplatePrio.
+  - [KONTEXT]  src/centron/Centron.WPF.UI/Modules/Administration/MailTemplates/MailTemplatesAppModuleController.cs, `ModuleName => "Mailvorlagen"`, `GetRights()` mit `UserRightsConst.Administration.MAIL_TEMPLATE_MANAGEMENT` (20400302) - Begründung: Pflegemodul und Modulrecht.
+Prüfidee:      Für dieselbe Referenz je eine globale und eine accountbezogene Vorlage anlegen; der Abruf mit `accountI3D` muss die accountbezogene Vorlage liefern, der Abruf ohne `accountI3D` die globale.
+Tracelinks:    SwRS-936, SyRS-920
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Verhindert fehlende Mailtexte im Produktivbetrieb.
+Status:        belegt
+Modul:         M-96
+
+ID:            SyRS-920
+Titel:         Konfigurierbares Mailversandprotokoll mit verschlüsselter Ablage der Zugangsdaten
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Centron.BL (CentronMailFactory, MailSettingsBL)
+Vorbedingung:  Die Mail- und Kalendereinstellungen sind gepflegt.
+Fakt:          `CentronMailFactory.GetMail(DAOSession, CentronWebserviceMailType?)` (src/backend/Centron.BL/Mail/Factory/CentronMailFactory.cs) wählt anhand der Einstellung `ApplicationSettingID.CentronWebserviceMailType` zwischen `ExchangeMail`, `GraphMail` und `SMTPMail` (Default) und liefert im Testmodus `TestMail`. `MailSettingsBL.GetMailSettings` entschlüsselt `ExchangePassword` (Z. 117) und `GraphAppSecret` (Z. 133) über `_cryptoLogic.DecryptText`; `SetMailSettings` verschlüsselt sie beim Speichern über `_cryptoLogic.EncryptText` (Z. 212, 227).
+Aussage:       Das System soll den Mailversandweg (Exchange EWS, Microsoft Graph oder SMTP) als Anwendungseinstellung konfigurierbar halten und alle Kennwörter und Client-Secrets der Mailkonten ausschließlich verschlüsselt persistieren.
+Ergebnis:      Ein Wechsel des Versandwegs erfordert keine Codeänderung; in der Datenbank stehen keine Klartextkennwörter der Mailkonten.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Mail/MailSettingsBL.cs, `SetMailSettings`: `updateSettings.UpdateString(ApplicationSettingID.ExchangePassword, this._cryptoLogic.EncryptText(settings.ExchangePassword));` (Z. 212) und analog `GraphAppSecret` (Z. 227) - Begründung: Durchsetzende Verschlüsselungsstelle beim Speichern.
+  - [PRIMÄR]   src/backend/Centron.BL/Mail/Factory/CentronMailFactory.cs, `GetMail`: `return centronMailType switch { Exchange => new ExchangeMail(session), Graph => new GraphMail(session), _ => new SMTPMail(session) };` - Begründung: Durchgesetzte Protokollauswahl.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Administration/MailAndCalender/General - Begründung: Pflegeort der Mailkonten im UI.
+Prüfidee:      Exchange-Kennwort speichern und die zugehörige Einstellung direkt in der Datenbank lesen; der Wert darf nicht dem eingegebenen Klartext entsprechen, nach dem Laden über `GetMailSettings` jedoch schon.
+Tracelinks:    StRS-906, SyRS-919, SyRS-921, SwRS-937
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Notwendiger Schutz von Postfach-Zugangsdaten.
+Status:        belegt
+Modul:         M-97
+
+ID:            SyRS-921
+Titel:         Zugriffsrecht und Geheimnisschutz für Mailscanner-Profile
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Centron.BL (MailScannerBL)
+Vorbedingung:  Ein Benutzer ruft die Mailscanner-Profile (Virtual Mail Assistant) ab oder speichert sie.
+Fakt:          `MailScannerBL.GetProfiles(MailScannerProfileFilter, LoggedInUser)` (src/backend/Centron.BL/MailScanner/MailScannerBL.cs, Z. 57-72) prüft `_appRightsBl.CheckRightsFromUser(loggedInUser.UserI3D.Value, UserRightsConst.VirtualMailAssistant.ACCESS_VMA_MODULE)` (20800112) und liefert bei fehlendem Recht `Result.AsError("Fehlendes Recht VMA Profile zu laden", DefaultMessageCodes.RightCheckFailed)`. `SaveProfile` (Z. 74-87) verschlüsselt vor dem Speichern `Password` und `ClientSecret` über `CentronConfigurationDbBL.EncryptWithMasterKey` und entschlüsselt beim Laden über `DecryptWithMasterKey`.
+Aussage:       Das System soll den Zugriff auf Mailscanner-Profile an das Recht ACCESS_VMA_MODULE binden und Postfach-Kennwörter sowie OAuth-Client-Secrets der Profile ausschließlich mit dem Masterschlüssel verschlüsselt speichern.
+Ergebnis:      Ohne VMA-Recht werden keine Profile geliefert; in `MailScannerProfiles` stehen `Password` und `ClientSecret` nur verschlüsselt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/MailScanner/MailScannerBL.cs, `GetProfiles` (Z. 59-62) - Begründung: Durchsetzende Rechteprüfung mit konkretem Recht und Fehlercode.
+  - [PRIMÄR]   src/backend/Centron.BL/MailScanner/MailScannerBL.cs, `EncryptProperties` (Z. 104-116), aufgerufen aus `SaveProfile` (Z. 76) - Begründung: Durchsetzende Verschlüsselung vor dem Persistieren.
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[MailScannerProfiles]` (Z. 44033) mit `[MailPassword] nvarchar(max)`, `[ClientSecret] nvarchar(max)`, `[WorkflowI3Ds] nvarchar(max)`, `[ConnectionType] int NOT NULL` - Begründung: Datenmodell des Profils inkl. Workflow-Zuordnung.
+Prüfidee:      Benutzer ohne ACCESS_VMA_MODULE ruft `GetProfiles` auf; Rückgabe muss RightCheckFailed sein. Anschließend Profil mit Kennwort speichern und Spalte `Password` direkt lesen; sie darf nicht dem Klartext entsprechen.
+Tracelinks:    SyRS-920
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Postfachzugänge sind besonders schützenswert.
+Status:        belegt
+Modul:         M-98
+
+ID:            SyRS-922
+Titel:         Kundengeräte werden logisch gelöscht und lückenlos protokolliert
+Ebene:         SyRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Centron.BL (AccountDeviceBL)
+Vorbedingung:  Ein Kundengerät ist einem Account zugeordnet.
+Fakt:          `AccountDeviceBL.DeleteAccountDevice(AppUser, int)` (src/backend/Centron.BL/Devices/AccountDeviceBL.cs, Z. 81-94) setzt `IsDeleted = true`, `DeletedDate = DateTime.Now`, `DeletedByI3D = currentUser.Employee.I3D` und schreibt über `WriteAccountDeviceLog` den Satz "Das Gerät wurde gelöscht" in `AccountDeviceLogs`; ein physisches Löschen findet nicht statt. `SaveAccountDevice` (Z. 42-78) protokolliert Anlage und Änderung mit Kurzzeichen des Bearbeiters. `SearchAccountDevices` (Z. 126-129) blendet gelöschte Geräte aus, solange `filter.IncludeDeleted == false`. Die Verknüpfung zu Tickets führt `AccountDevicesToTickets` (SSMS_DB_SCHEMA.sql, Z. 7267).
+Aussage:       Das System soll Kundengeräte ausschließlich logisch löschen, jede Anlage, Änderung und Löschung mit Zeitpunkt und Bearbeiter protokollieren und gelöschte Geräte standardmäßig aus Suchergebnissen ausblenden.
+Ergebnis:      Historische Ticketbezüge zu einem Gerät bleiben nachvollziehbar; die Gerätehistorie ist vollständig.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Devices/AccountDeviceBL.cs, `DeleteAccountDevice` (Z. 89-93) - Begründung: Durchgesetztes Soft-Delete mit Protokolleintrag.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[AccountDevices]` (Z. 7235) mit `[IsDeleted] bit NOT NULL`, `[DeletedDate]`, `[DeletedByI3D]` - Begründung: Datenmodell stützt das Soft-Delete.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/Crm/Devices/AccountDeviceEditViewModel.cs - Begründung: Pflegemaske der Kundengeräte im CRM.
+Prüfidee:      Gerät löschen und danach mit `IncludeDeleted = false` und `= true` suchen; im ersten Fall darf es nicht, im zweiten muss es erscheinen, und `AccountDeviceLogs` muss einen Löscheintrag enthalten.
+Tracelinks:    SwRS-945
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Nachvollziehbarkeit der Gerätehistorie im Service.
+Status:        belegt
+Modul:         M-91
+
+ID:            SyRS-923
+Titel:         Bearbeitungs- und Öffnungsrecht einer Kampagne über Kampagnenmitarbeiter
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Centron.BL (CampaignBL)
+Vorbedingung:  Eine Kampagne existiert; der Benutzer ist Mitarbeiter des Systems.
+Fakt:          `CampaignBL.CanEditCampaign(AppUser currentUser, int campaignI3D)` (src/backend/Centron.BL/Accounts/Campaigns/CampaignBL.cs, Z. 421-437) gibt true zurück, wenn `currentUser.IsAdmin()` gilt; andernfalls wird in `CampaignEmployees` der Satz mit `EmployeeI3D == currentUser.Employee.I3D` gesucht und nur bei `user.IsAdmin == true` das Bearbeiten erlaubt. `CanOpenCampaign` (Z. 439-452) verlangt lediglich, dass ein `CampaignEmployees`-Satz für den Mitarbeiter existiert.
+Aussage:       Das System soll eine Kampagne nur für Systemadministratoren und für die als Kampagnen-Administrator markierten Kampagnenmitarbeiter zur Bearbeitung freigeben und das Öffnen einer Kampagne auf die der Kampagne zugeordneten Mitarbeiter beschränken.
+Ergebnis:      Nicht zugeordnete Mitarbeiter können die Kampagne weder öffnen noch bearbeiten.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Accounts/Campaigns/CampaignBL.cs, `CanEditCampaign` (Z. 426-436): `if (user == null || user.IsAdmin == false) return Result<bool>.AsSuccess(false);` - Begründung: Durchsetzende Bedingung auf `CampaignEmployees.IsAdmin`.
+  - [PRIMÄR]   src/backend/Centron.BL/Accounts/Campaigns/CampaignBL.cs, `CanOpenCampaign` (Z. 444-451) - Begründung: Zweite durchsetzende Bedingung für das Öffnen.
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[CampaignEmployees]` (Z. 34161) - Begründung: Trägertabelle der Zuordnung.
+Prüfidee:      Mitarbeiter ohne `CampaignEmployees`-Satz ruft `CanOpenCampaign` auf; das Ergebnis muss false sein. Mitarbeiter mit Satz und `IsAdmin = false` muss bei `CanEditCampaign` false erhalten.
+Tracelinks:    StRS-905
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kampagnenhoheit liegt beim Kampagnenteam.
+Status:        belegt
+Modul:         M-92
+
+ID:            SyRS-924
+Titel:         Rechteprüfung bei Verwaltung und Löschung von Auftragsverarbeitungsverträgen
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Centron.BL (DsgvoBL)
+Vorbedingung:  Zu einem Account soll ein Auftragsverarbeitungsvertrag (AVV) gespeichert oder gelöscht werden.
+Fakt:          `DsgvoBL.SaveAccountOrderProcessingContract(AccountOrderProcessingContract contract, AppUser user)` (src/backend/Centron.BL/Administration/Documents/Dsgvo/DsgvoBL.cs, Z. 238-257) bricht mit `Result<AccountOrderProcessingContract>.AsError("Sie haben nicht das Recht um AVVs zu verwalten.")` ab, wenn `user.HasUserRight(UserRightsConst.Sales.Customer.CustomerCommon.ORDER_PROCESSING_CONTRACTS_MANAGEMENT)` (20800019) false ist. `DeleteAccountOrderProcesingContract` (Z. 313-340) verlangt DELETE_ORDER_PROCESSING_CONTRACTS (20800020) und löscht in einer Transaktion Vertrag, zugehöriges `OnlinePdfDocument` und `Document`. `DeleteTestAccountOrderProcessingContract` lässt das Löschen nur zu, wenn `entity.TestMode == true` ("Nur Tests können gelöscht werden").
+Aussage:       Das System soll das Anlegen und Ändern von Auftragsverarbeitungsverträgen an das Recht ORDER_PROCESSING_CONTRACTS_MANAGEMENT und das Löschen an DELETE_ORDER_PROCESSING_CONTRACTS binden sowie beim Löschen die zugehörigen Dokumente in derselben Transaktion mit entfernen.
+Ergebnis:      AVV-Daten können nur von berechtigten Benutzern verändert werden; es bleiben keine verwaisten PDF-/Dokumentensätze zurück.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Documents/Dsgvo/DsgvoBL.cs, Z. 243 `if (user.HasUserRight(...ORDER_PROCESSING_CONTRACTS_MANAGEMENT) == false) return ...AsError("Sie haben nicht das Recht um AVVs zu verwalten.")` - Begründung: Durchsetzende Stelle.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Documents/Dsgvo/DsgvoBL.cs, Z. 318 `if (user.HasUserRight(...DELETE_ORDER_PROCESSING_CONTRACTS) == false) return Result.AsError("Sie haben nicht das Recht um AVVs zu löschen.")` - Begründung: Durchsetzende Stelle für das Löschen.
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[AccountOrderProcessingContracts]` (Z. 14192); UserRightsConst.cs Z. 2023-2024 - Begründung: Datenmodell und Rechte-IDs.
+Prüfidee:      Benutzer ohne DELETE_ORDER_PROCESSING_CONTRACTS löscht einen AVV; die Operation muss mit der genannten Meldung fehlschlagen und Vertrag sowie Dokument müssen erhalten bleiben.
+Tracelinks:    StRS-901, SyRS-909
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Datenschutzrechtlich relevanter Dokumentenbestand.
+Status:        belegt
+Modul:         M-88

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-116d/_work/assemble.py

@@ -0,0 +1,252 @@
+# -*- coding: utf-8 -*-
+"""Fuehrt die Teilergebnisse der Erhebungsagenten zu den Ergebnisdateien zusammen
+und fuehrt zugleich den Konsistenzcheck durch."""
+import os, re, sys, json, collections
+
+WORK = os.path.dirname(os.path.abspath(__file__))
+OUT = os.path.join(os.path.dirname(WORK), "Ergebnisse")
+AGENTS = ["A%d" % i for i in range(1, 13)]
+LEVELS = ["StRS", "SyRS", "SwRS"]
+
+FIELDS = ["ID", "Titel", "Ebene", "Typ", "Qualitätsmerkmal", "Akteur", "Vorbedingung",
+          "Fakt", "Aussage", "Ergebnis", "Belege", "Prüfidee", "Tracelinks",
+          "Konsolidierung", "Übernahmewürdigkeit", "Status", "Modul"]
+
+ID_RE = re.compile(r"^ID:\s*((?:StRS|SyRS|SwRS)-\d+)\s*$")
+
+
+def parse_blocks(path):
+    """Zerlegt eine Agentendatei in Bloecke. Ein Block beginnt mit einer ID:-Zeile."""
+    if not os.path.exists(path):
+        return []
+    with open(path, encoding="utf-8") as fh:
+        lines = fh.read().replace("\r\n", "\n").split("\n")
+    blocks, cur = [], None
+    for line in lines:
+        if ID_RE.match(line.strip()):
+            if cur:
+                blocks.append(cur)
+            cur = [line.rstrip()]
+        elif cur is not None:
+            if line.strip().startswith("```"):
+                continue
+            cur.append(line.rstrip())
+    if cur:
+        blocks.append(cur)
+    # abschliessende Leerzeilen entfernen
+    out = []
+    for b in blocks:
+        while b and not b[-1].strip():
+            b.pop()
+        out.append(b)
+    return out
+
+
+def field(block, name):
+    """Liest ein einzeiliges Feld aus einem Block."""
+    pref = name + ":"
+    for line in block:
+        if line.startswith(pref):
+            return line[len(pref):].strip()
+    return None
+
+
+def evidence(block):
+    """Liefert die Belegzeilen eines Blocks."""
+    out, inside = [], False
+    for line in block:
+        if line.startswith("Belege:"):
+            inside = True
+            continue
+        if inside:
+            if line.startswith("  -") or line.startswith("- ") or line.strip().startswith("- ["):
+                out.append(line.strip())
+            elif line.strip() and not line.startswith(" "):
+                break
+    return out
+
+
+def main():
+    if not os.path.isdir(OUT):
+        os.makedirs(OUT)
+    all_blocks = []
+    for a in AGENTS:
+        for lvl in LEVELS:
+            p = os.path.join(WORK, "%s_%s.md" % (a, lvl))
+            for b in parse_blocks(p):
+                all_blocks.append({"agent": a, "file_level": lvl, "lines": b})
+
+    # ---- Index aufbauen -------------------------------------------------
+    by_id = collections.OrderedDict()
+    dup_ids = []
+    for rec in all_blocks:
+        rid = field(rec["lines"], "ID")
+        rec["id"] = rid
+        if rid in by_id:
+            dup_ids.append(rid)
+        else:
+            by_id[rid] = rec
+
+    # ---- Ausgabedateien je Ebene ---------------------------------------
+    counts = {}
+    for lvl in LEVELS:
+        recs = [r for r in by_id.values() if (field(r["lines"], "Ebene") or r["file_level"]).strip() == lvl]
+        recs.sort(key=lambda r: int(r["id"].split("-")[1]))
+        counts[lvl] = len(recs)
+        yield_lines = []
+        for r in recs:
+            yield_lines.append("```")
+            yield_lines.extend(r["lines"])
+            yield_lines.append("```")
+            yield_lines.append("")
+        with open(os.path.join(WORK, "_body_%s.md" % lvl), "w", encoding="utf-8") as fh:
+            fh.write("\n".join(yield_lines))
+
+    # ---- Kennzahlen und Pruefungen -------------------------------------
+    report = {
+        "gesamt": len(by_id),
+        "je_ebene": counts,
+        "doppelte_ids": sorted(set(dup_ids)),
+        "ohne_beleg": [],
+        "ohne_uebernahmewuerdigkeit": [],
+        "ohne_pruefidee": [],
+        "ohne_modul": [],
+        "tote_tracelinks": [],
+        "hypothesen": [],
+        "risiko": [],
+        "belegarten": {"PRIMÄR": 0, "SEKUNDÄR": 0, "KONTEXT": 0},
+        "belege_gesamt": 0,
+        "nfa_ohne_qm": [],
+        "nfa_gesamt": 0,
+        "konsolidierungskandidaten": [],
+        "je_modul": collections.Counter(),
+        "je_agent": collections.Counter(),
+        "typen": collections.Counter(),
+        "uebernahme": collections.Counter(),
+        "qm": collections.Counter(),
+    }
+
+    risk_re = re.compile(
+        r"(sicherheit|berechtigung|recht|abrechn|faktur|rechnung|zahlung|passwort|"
+        r"authentifiz|autorisier|token|mandant|preis|steuer|mahn|lizenz|verschl|signat)", re.I)
+
+    for rid, rec in by_id.items():
+        b = rec["lines"]
+        report["je_agent"][rec["agent"]] += 1
+        mod = field(b, "Modul") or ""
+        if not mod:
+            report["ohne_modul"].append(rid)
+        else:
+            report["je_modul"][mod.strip()] += 1
+        ev = evidence(b)
+        if not ev:
+            report["ohne_beleg"].append(rid)
+        for line in ev:
+            report["belege_gesamt"] += 1
+            for k in report["belegarten"]:
+                if "[%s]" % k in line:
+                    report["belegarten"][k] += 1
+                    break
+        ue = field(b, "Übernahmewürdigkeit")
+        if not ue:
+            report["ohne_uebernahmewuerdigkeit"].append(rid)
+        else:
+            report["uebernahme"][ue.split("-")[0].strip()] += 1
+        if not field(b, "Prüfidee"):
+            report["ohne_pruefidee"].append(rid)
+        typ = (field(b, "Typ") or "").strip()
+        report["typen"][typ] += 1
+        qm = (field(b, "Qualitätsmerkmal") or "").strip()
+        if typ.lower().startswith("nicht-funktional"):
+            report["nfa_gesamt"] += 1
+            if not qm:
+                report["nfa_ohne_qm"].append(rid)
+            else:
+                report["qm"][qm] += 1
+        status = (field(b, "Status") or "").strip()
+        text = "\n".join(b)
+        is_hyp = status.upper().startswith("HYPOTHESE") or "[HYPOTHESE]" in text
+        if is_hyp:
+            report["hypothesen"].append(rid)
+        kons = (field(b, "Konsolidierung") or "").strip()
+        if kons and not kons.lower().startswith("nein"):
+            report["konsolidierungskandidaten"].append(rid)
+        # Risikoeinstufung
+        haystack = " ".join([field(b, "Titel") or "", typ, field(b, "Aussage") or "", mod])
+        if risk_re.search(haystack):
+            has_primary = any("[PRIMÄR]" in e for e in ev)
+            report["risiko"].append({
+                "id": rid, "titel": field(b, "Titel") or "",
+                "primaer": has_primary, "hypothese": is_hyp,
+                "verstoss": (not has_primary) and (not is_hyp)})
+        # Tracelinks
+        tl = field(b, "Tracelinks") or ""
+        for ref in re.findall(r"(?:StRS|SyRS|SwRS)-\d+", tl):
+            if ref not in by_id:
+                report["tote_tracelinks"].append((rid, ref))
+
+    with open(os.path.join(WORK, "_report.json"), "w", encoding="utf-8") as fh:
+        json.dump(report, fh, ensure_ascii=False, indent=1, default=list)
+
+    # ---- Hypothesenliste -----------------------------------------------
+    hyp_rows = []
+    for rid in report["hypothesen"]:
+        b = by_id[rid]["lines"]
+        hyp_rows.append({
+            "id": rid,
+            "titel": field(b, "Titel") or "",
+            "modul": field(b, "Modul") or "",
+            "aussage": field(b, "Aussage") or "",
+            "fakt": field(b, "Fakt") or "",
+        })
+    with open(os.path.join(WORK, "_hypothesen.json"), "w", encoding="utf-8") as fh:
+        json.dump(hyp_rows, fh, ensure_ascii=False, indent=1)
+
+    # ---- Traceability ---------------------------------------------------
+    trace = []
+    for rid, rec in by_id.items():
+        b = rec["lines"]
+        lvl = (field(b, "Ebene") or rec["file_level"]).strip()
+        tl = field(b, "Tracelinks") or ""
+        refs = re.findall(r"(?:StRS|SyRS|SwRS)-\d+", tl)
+        st = [r for r in refs if r.startswith("StRS")]
+        sy = [r for r in refs if r.startswith("SyRS")]
+        sw = [r for r in refs if r.startswith("SwRS")]
+        if lvl == "StRS":
+            st = [rid] + st
+        elif lvl == "SyRS":
+            sy = [rid] + sy
+        else:
+            sw = [rid] + sw
+        ev = evidence(b)
+        first = ev[0] if ev else ""
+        first = re.sub(r"^\-\s*\[[^\]]+\]\s*", "", first)
+        first = first.split(" - Begründung")[0].strip()
+        trace.append({
+            "strs": ", ".join(dict.fromkeys(st)) or "-",
+            "syrs": ", ".join(dict.fromkeys(sy)) or "-",
+            "swrs": ", ".join(dict.fromkeys(sw)) or "-",
+            "beleg": first,
+            "sort": int(rid.split("-")[1]),
+            "lvl": {"StRS": 0, "SyRS": 1, "SwRS": 2}[lvl],
+        })
+    trace.sort(key=lambda r: (r["sort"], r["lvl"]))
+    with open(os.path.join(WORK, "_trace.json"), "w", encoding="utf-8") as fh:
+        json.dump(trace, fh, ensure_ascii=False, indent=1)
+
+    print(json.dumps({k: v for k, v in report.items()
+                      if k in ("gesamt", "je_ebene", "doppelte_ids", "ohne_beleg",
+                               "ohne_uebernahmewuerdigkeit", "ohne_pruefidee", "ohne_modul",
+                               "belegarten", "belege_gesamt", "nfa_gesamt", "nfa_ohne_qm")},
+                     ensure_ascii=False, indent=1))
+    print("Hypothesen:", len(report["hypothesen"]))
+    print("Konsolidierungskandidaten:", len(report["konsolidierungskandidaten"]))
+    print("Tote Tracelinks:", len(report["tote_tracelinks"]), report["tote_tracelinks"][:20])
+    print("Risikoanforderungen:", len(report["risiko"]),
+          "davon Verstoesse:", sum(1 for r in report["risiko"] if r["verstoss"]))
+    print("Module mit Anforderungen:", len(report["je_modul"]))
+    print("Je Agent:", dict(report["je_agent"]))
+
+
+if __name__ == "__main__":
+    main()

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-9d9e/Ergebnisse/Glossar.md

@@ -0,0 +1,325 @@
+# Glossar
+
+Domänen- und Systembegriffe, die in `StRS.md`, `SyRS.md` und `SwRS.md` verwendet werden.
+Jeder Begriff ist mit der Fundstelle belegt, aus der die Bedeutung abgeleitet wurde.
+Technische Bezeichner (Klassen, Tabellen, Spalten) bleiben in ihrer Originalschreibweise.
+
+Legende der Belegklassen: `PRIMÄR` = durchgesetzte Regel in Code oder DB-Constraint,
+`SEKUNDÄR` = UI-Label, Meldung, Mapping, Konfiguration, `KONTEXT` = Kommentar, Dokumentation.
+
+---
+
+## A
+
+**Abholschein**
+Belegart neben Angebot, Auftrag, Lieferschein, Rechnung und Gutschrift.
+Beleg: `src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs` — `PickupListClass = 5` mit `[Description("Abholschein")]`. (SEKUNDÄR)
+
+**Adressstamm**
+Fachliches Modul zur Pflege von Geschäftspartnern. Es existieren zwei Implementierungen: das klassische Modul „Adressen & Belege" (`AccountManagementAppModuleController`) und das neuere CRM-Modul, das ebenfalls den Anzeigenamen „Adressstamm" trägt (`CrmAppModuleController`). Welches der beiden registriert wird, entscheidet die Einstellung `CrmSettings.IsAccountManagementActive`.
+Beleg: `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs:515-527`; `src/centron/Centron.WPF.UI/Modules/Finances/AccountManagement/AccountManagementAppModuleController.cs:18`; `src/centron/Centron.WPF.UI/Modules/Finances/Crm/CrmAppModuleController.cs:25`. (PRIMÄR)
+
+**AppUser**
+Systeminterner Benutzer (Mitarbeiterkonto) des c-entron-Clients. Persistiert in der Tabelle `Sichbenu`.
+Beleg: `src/backend/Centron.DAO/Mappings/Administration/AppUserMaps.cs`; `SSMS_DB_SCHEMA.sql` — `CREATE TABLE [dbo].[Sichbenu]`. (PRIMÄR)
+
+**ApplicationKind**
+Anwendungsart, mit der sich ein Client am Webservice anmelden darf. Jede Art trägt eine numerische Kennung, einen Anzeigenamen, eine Lizenz-GUID sowie optional ein erforderliches oder ein ausschließendes Recht und eine Gültigkeitsdauer der Sitzung. Es sind 45 Arten definiert.
+Beleg: `src/backend/Centron.Interfaces/Administration/Logins/ApplicationKind.cs`. (PRIMÄR)
+
+**Asset / Gerät**
+Beim Kunden betriebene Hardware. Der Begriff ist im System nicht einheitlich modelliert; siehe **Gerätedatenhaltung**.
+
+**Aufschlag Stundensatz**
+Zuschlagssatz auf Mitarbeiterstunden, verwaltet im gleichnamigen Modul.
+Beleg: `src/centron/Centron.WPF.UI/Modules/Administration/HourlySurchargeRates/HourlySurchargeRatesAppModuleController.cs:21` — „Verwalten von Aufschlagssätzen zu Mitarbeiterstunden." (SEKUNDÄR)
+
+## B
+
+**Beleg**
+Sammelbegriff für die kaufmännischen Vorgangsdokumente Angebot (`AngKopf`/`AngPos`), Auftrag (`AufKopf`/`AufPos`), Lieferschein (`LiefKopf`/`LiefPos`), Rechnung (`RechKopf`/`RechPos`), Gutschrift und Abholschein. Jede Belegart besitzt ein eigenes Kopf- und Positionstabellenpaar.
+Beleg: `SSMS_DB_SCHEMA.sql` — die genannten `CREATE TABLE`-Anweisungen. (PRIMÄR)
+
+**Belegkondition**
+Oberbegriff für Zahlungskonditionen und Lieferbedingungen, die einem Beleg zugeordnet werden.
+Beleg: `src/centron/Centron.WPF.UI/Modules/Administration/ReceiptConditions/ReceiptConditionManagementAppModuleController.cs:19` — „Verwaltung von Belegkonditionen, Zahlungskonditionen und Lieferbedingungen". (SEKUNDÄR)
+
+**Belegstatus (`ReceiptState`)**
+Fachlicher Zustand eines Belegs mit den Ausprägungen `Active` („offen"), `Completed` („abgeschlossen") und `Canceled` („storniert").
+Beleg: `src/backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs`. (PRIMÄR)
+
+**Bestellvorschlagsliste (BVL)**
+Modul des Einkaufs, das Bestellvorschläge ermittelt. Im Modulkatalog als veraltet gekennzeichnet (`#pragma warning disable 612`).
+Beleg: `src/centron/Centron.WPF.UI/Modules/Purchasing/OrderSuggestionList/OrderSuggestionListAppModuleController.cs:15`; `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs` (Abschnitt „c-entron Module: Einkauf"). (PRIMÄR)
+
+**BL / BLLogic**
+Geschäftslogikschicht (`Centron.BL`) beziehungsweise deren clientseitige Anbindung bei Direktverbindung zur Datenbank. Gegenstück ist **WSLogic**.
+Beleg: `docs/getting-started/general-structure.md`. (KONTEXT)
+
+**BLSession**
+Arbeitseinheit der Geschäftslogik; kapselt eine NHibernate-Sitzung und stellt über `GetBL<T>()` die fachlichen Logikklassen bereit.
+Beleg: `src/webservice/Centron.Controllers/Controllers/Unversioned/JwtAuthController.cs:60` — `using var session = new BLSession();`. (PRIMÄR)
+
+## C
+
+**c-entron Nexus**
+Webportal auf Basis von Blazor Server. Enthält unter anderem ServiceBoard, WebCart, Dokumentenfreigabe und Verwaltungsmasken.
+Beleg: `README.md` — „c-entron Nexus (aka c-entron Web)"; `src/nexus/CentronNexus/`. (KONTEXT)
+
+**C-FLOW**
+Interne Bezeichnung für Ticketvorlagen und die daraus abgeleiteten Ticketprozesse.
+Beleg: `CentronRights.md`, Abschnitt 17 — Rechte `UserRightsConst.Sales.Customer.Helpdesk.CFlow.*`. (SEKUNDÄR)
+
+**CentronObjectKindNumeric**
+Systemweite numerische Objektart, mit der Belege, Tickets, Kunden, Geräte und weitere Objekte typisiert werden. Die Nummernvergabe stammt aus dem Delphi-Vorgängersystem; neue .NET-Konstanten beginnen ab 7600000.
+Beleg: `src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs:6-13` — Kommentar „Neue Konstanten für .Net werden autarg von c-entron Delphi angelegt Sie beginnen ab dem Wert 7600000". (KONTEXT)
+
+**CentronConnectionType**
+Betriebsart der Datenanbindung eines Clients: `SqlServer` (Direktzugriff auf die Datenbank) oder `CentronWebServices` (Zugriff über den Webservice).
+Beleg: `src/backend/Centron.Interfaces/Administration/Connections/CentronConnectionType.cs`. (PRIMÄR)
+
+**ChangeLog**
+Feldbezogenes Änderungsprotokoll mit Objektart, Objekt-Kennung, Eigenschaftsname, altem und neuem Wert, Zeitpunkt und verursachendem Benutzer.
+Beleg: `src/backend/Centron.Entities/Entities/ChangeTracking/ChangeLog.cs`; `src/backend/Centron.DAO/ChangeTracking/ChangeTrackingEventListener.cs`. (PRIMÄR)
+
+**ClassContainer**
+Dienstverzeichnis des WPF-Clients, über das `ILogic`-Schnittstellen aufgelöst werden.
+Beleg: `docs/getting-started/general-structure.md`. (KONTEXT)
+
+## D
+
+**Data Updater**
+Modul für Massenänderungen an Datenbeständen (Anzeigename „Data Updater", Lizenz `DataUpdaterV2`).
+Beleg: `src/centron/Centron.WPF.UI/Modules/Massenupdates/MassUpdatesAppModuleController.cs:15`; `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs` (Abschnitt „Stammdaten"). (PRIMÄR)
+
+**DSGVO-Löschung**
+Umsetzung des Löschanspruchs. Gelöschte Kontaktdaten werden nicht entfernt, sondern durch die Kennzeichnung „DSGVO: Auf Anfrage gelöscht." ersetzt.
+Beleg: `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs:26-27`. (PRIMÄR)
+
+## E
+
+**EDI (Electronic Data Interchange)**
+Automatisierter Belegaustausch mit Lieferanten. Unterstützt werden unter anderem Alltron, ALSO, ALSO Schweiz, EGIS, Herweck, Komsa und der Standard OpenTrans 2.1.
+Beleg: `docs/reference/edi/edi-architecture.md`; `src/backend/Centron.Gateway/EDI_*`. (KONTEXT)
+
+**Erwartetes Event**
+Regelmäßig erwartetes technisches Ereignis; bleibt es aus, ist das ein auswertbarer Befund. Eigenes Modul samt Auswertungsmodul.
+Beleg: `src/centron/Centron.WPF.UI/Modules/Helpdesk/ExpectedEvents/Controller/ExpectedEventsAppModuleController.cs:21`; `.../ExpectedEventsReporting/Controller/ExpectedEventsReportingAppModuleController.cs:18`. (SEKUNDÄR)
+
+**ESR**
+Schweizer Einzahlungsschein-Referenzverfahren. Rechnungen führen dafür eigene Felder.
+Beleg: `SSMS_DB_SCHEMA.sql`, Tabelle `RechKopf` — Spalten `ESRKodierzeileBetrag`, `ESRReferenznummer`, `ESRBetrag`. (PRIMÄR)
+
+## F
+
+**Filiale**
+Organisatorische Untereinheit eines Mandanten. Trägt Anschrift, Land, Sprache, Buchhaltungsnummer und Preisliste.
+Beleg: `SSMS_DB_SCHEMA.sql` — `CREATE TABLE [dbo].[Filiale]` mit Spalte `MandantI3D`. (PRIMÄR)
+
+**Filialbeschränkung**
+Einschränkendes Recht, das die Sicht eines Benutzers auf die Daten seiner eigenen Filiale begrenzt. In der Belegsuche als SQL-Fragment umgesetzt.
+Beleg: `src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/ContractReceiptSearchConfiguration.cs:174` — `OnlyOwnBranchWhereStatement => "AND (ISNULL(AK.FilialI3D, 0) = :BranchI3D)"`. (PRIMÄR)
+
+## G
+
+**Gerätedatenhaltung**
+Im System bestehen vier getrennte Datenhaltungen für denselben fachlichen Gegenstand „Gerät beim Kunden":
+`GeraeteKopf`/`GeraetePos` (Altbestand, mit Vertrags- und Klickzählerbezug), `MasterDataList`/`MasterDataListItems` (**Stammblätter**), `AccountDevices` (CRM-Gerätemodell) und `AssetManagementDevices` (aus der Systeminventarisierung befüllt).
+Beleg: `SSMS_DB_SCHEMA.sql` — die vier `CREATE TABLE`-Anweisungen. (PRIMÄR)
+
+## H
+
+**Helpdesk / Ticket**
+Kundenanfrage oder Störungsmeldung. Persistiert in `hlpdsk_requests` mit den Stammdatentabellen `hlpdsk_status`, `hlpdsk_typen`, `hlpdsk_kategorien` und `hlpdsk_prioritaeten`.
+Beleg: `SSMS_DB_SCHEMA.sql` — die genannten Tabellen. (PRIMÄR)
+
+**Hlpdsk-Timer / Helpdeskzeit**
+Erfasster Zeitaufwand zu einem Ticket. Grundlage der Ticketabrechnung. Verschieben und Löschen sind nur zulässig, solange die Zeit nicht Bestandteil eines Belegs ist.
+Beleg: `CentronRights.md`, Abschnitte 8 und 9 — „But only if the ticket is not part of a receipt." (SEKUNDÄR)
+
+## I
+
+**I3D**
+Systemweite Konvention für den Primärschlüssel (`I3D`, „ID 3develop"), definiert als `int IDENTITY(1,1) NOT NULL` mit gruppiertem Primärschlüsselindex. Fremdschlüsselspalten enden auf `I3D`. 1458 der 1535 Tabellen folgen dieser Konvention.
+Beleg: `docs/guides/database/database-conventions.md`, Abschnitt „Primary Key Convention"; Auszählung über `SSMS_DB_SCHEMA.sql`. (KONTEXT / PRIMÄR)
+
+**ILogic**
+Client-Schnittstelle für einen fachlichen Datenzugriff. Zu jeder `I<Modul>Logic` existieren zwei Implementierungen: `BL<Modul>Logic` für den Direktzugriff und `WS<Modul>Logic` für den Webservice-Zugriff.
+Beleg: `docs/getting-started/general-structure.md`, Abschnitt „Dual Implementation Architecture". (KONTEXT)
+
+## K
+
+**Kalkulation**
+Vorgangsart der Einkaufsseite mit eigenem Kopf-/Positionspaar `KalkKopf`/`KalkPos`; im Modul „Eingang/Kalk" verarbeitet.
+Beleg: `SSMS_DB_SCHEMA.sql`; `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/SupplierReceiptDocuments/SupplierReceiptDocumentsImportAppModuleController.cs:23`. (PRIMÄR)
+
+**Klickabrechnung / Klick-Zähler**
+Abrechnung nach Zählerständen von Geräten, typischerweise Drucksystemen. Eigenes Modul „Klick-Zählerverwaltung", eigene Einstellungsseite „ClickBilling", eigene Tabellen `GeraeteClickZaehler` und `GeraeteClickZaehlerHistory`.
+Beleg: `src/centron/Centron.WPF.UI/Modules/Finances/DeviceClickCounter/DeviceClickCounterAppModuleController.cs:14`; `SSMS_DB_SCHEMA.sql`. (PRIMÄR)
+
+**Kommissionierung**
+Zusammenstellen von Waren für einen Auftrag. Es bestehen zwei Module: das registrierte Modul „Kommissionierung" und ein nicht registriertes Modul „Kommissionierung (Beta)".
+Beleg: `src/centron/Centron.WPF.UI/Modules/Warehousing/Commissions/OrderCommissionAppModuleController.cs:18`; `src/centron/Centron.WPF.UI/Modules/Warehousing/Commissioning/CommissioningAppModuleController.cs:15-18`. (PRIMÄR)
+
+**Kontenrahmen**
+Buchhalterisches Kontengerüst, verwaltet im Modul `AccountSystemsAppModuleController`.
+Beleg: `src/centron/Centron.WPF.UI/Modules/Warehousing/AccountSystems/Controller/AccountSystemsAppModuleController.cs:18`. (SEKUNDÄR)
+
+**Kostenträger / Kostenstelle**
+Betriebswirtschaftliche Zuordnungsobjekte. Eigene Tabellen `Kostentraeger` und `Kostenstellen`; Belege referenzieren sie über `KostentraegerI3D` und `KostenstellenI3D`.
+Beleg: `SSMS_DB_SCHEMA.sql`, Tabellen `Kostentraeger`, `Kostenstellen` und Tabelle `RechKopf`. (PRIMÄR)
+
+## L
+
+**Lizenz (LicenseGuid)**
+Eine Lizenz ist technisch eine GUID mit optionaler Anzahl (`count`), Ablaufdatum (`valid until date`) und Versionsgrenze (`valid until version`). 159 Lizenzkonstanten sind hinterlegt.
+Beleg: `docs/reference/security/licensing-system.md`; `src/backend/Centron.Interfaces/Administration/Logins/LicenseGuids.cs`. (KONTEXT / PRIMÄR)
+
+## M
+
+**Mahnstufe**
+Stufe des Mahnverfahrens zu einer Rechnung. Das Datenmodell sieht genau drei Stufen mit je eigenem Datum und Bearbeiter vor, ergänzt um eine Mahnsperre.
+Beleg: `SSMS_DB_SCHEMA.sql`, Tabelle `RechKopf` — Spalten `Mahnung1Datum`/`Mahnung1BearbeiterI3D` bis `Mahnung3Datum`/`Mahnung3BearbeiterI3D`, `Mahnstufe`, `MahnStop`, `MahnInfo`. (PRIMÄR)
+
+**Mandant**
+Oberste organisatorische Einheit der Mandantenfähigkeit; einem Mandanten sind Filialen zugeordnet.
+Beleg: `SSMS_DB_SCHEMA.sql` — `CREATE TABLE [dbo].[Mandant]`, `CREATE TABLE [dbo].[MandantenStammdat]`, `Filiale.MandantI3D`. (PRIMÄR)
+
+**MSP (Managed Service Provider)**
+Betriebsmodell, in dem Leistungen pauschal je verwaltetem System abgerechnet werden. Eigene Module MSP-Collector, MSP-Auswertung und MSP-Dashboard, gemeinsame Lizenz `LicenseGuids.MspModule`.
+Beleg: `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs` (Abschnitt „Controlling/Analytics"). (PRIMÄR)
+
+## N
+
+**Nummernkreis**
+Fortlaufende Vergabe der Belegnummer. Belegkopftabellen führen dafür die Spalte `Nummer` zusätzlich zum technischen Schlüssel `I3D`.
+Beleg: `SSMS_DB_SCHEMA.sql`, Tabelle `RechKopf` — `[Nummer] [int] NOT NULL`. (PRIMÄR)
+
+## O
+
+**OPOS (Offene Posten)**
+Übersicht der offenen Forderungen. Eigenes Modul; Rechnungen führen dafür das Feld `OposImportInfo`.
+Beleg: `src/centron/Centron.WPF.UI/Modules/Finances/Opos/OposOverviewAppModuleController.cs:15-17`; `SSMS_DB_SCHEMA.sql`, Tabelle `RechKopf`. (SEKUNDÄR / PRIMÄR)
+
+## P
+
+**Pauschalabrechnung**
+Abrechnung eines Projekts oder Vertrags zu einem Festpreis unabhängig vom tatsächlichen Aufwand. Eigenes Modul mit eigener Lizenz `FlatRateBilling`.
+Beleg: `src/centron/Centron.WPF.UI/Modules/Finances/FlatrateBilling/FlatRateProjectAppModuleController.cs:17`; `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs` (Abschnitt „Abrechnung"). (PRIMÄR)
+
+**Provisionsschema**
+Regelwerk, nach dem Provisionen aus Belegpositionen ermittelt werden. Schemata werden verwaltet, Kunden zugeordnet und ausgewertet; jede dieser drei Aufgaben ist ein eigenes Modul mit eigener Lizenz.
+Beleg: `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/Provision/Schemas/ProvisionSchemaManagementAppModuleController.cs:19`, `.../SchemaCustomerAssignments/AssignmentsAppModuleController.cs:19`, `.../Evaluation/ProvisionEvaluationAppModuleController.cs:16`. (PRIMÄR)
+
+## R
+
+**Recht (I3D-Recht)**
+Berechtigung, identifiziert über eine ganzzahlige Kennung. Rechte sind hierarchisch über `OwnerRecht` verkettet und liegen in der Tabelle `Sichrech`. Es sind 750 Rechtekonstanten definiert; neue .NET-Modulrechte beginnen ab 20800000.
+Beleg: `src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs:11-16`; `docs/guides/development/add-a-new-right.md`; `SSMS_DB_SCHEMA.sql`, Tabelle `Sichrech`. (PRIMÄR)
+
+**Recht, einschränkendes (restricting right)**
+Recht, das den Zugriff nicht erweitert, sondern begrenzt — etwa „nur eigene Tickets", „nur eigene Filiale", „nur eigene Abteilung".
+Beleg: `CentronRights.md`, Abschnitte 1.1, 1.2, 2.1, 4, 7.1. (SEKUNDÄR)
+
+**Result&lt;T&gt;**
+Einheitlicher Ergebnisvertrag der Geschäftslogik mit den Zuständen `Success`, `Warning` und `Error` sowie einer Meldung und einem Meldungscode.
+Beleg: `docs/reference/architecture/results-and-responses.md`; `src/backend/Centron.BL/Administration/Logins/UsersBL.cs` (durchgängige Verwendung). (KONTEXT / PRIMÄR)
+
+**RMA (Return Merchandise Authorization)**
+Rücksende- und Werkstattvorgang. Eigene Tabelle `Rma`, eigenes Modul „RMA / Werkstatt".
+Beleg: `SSMS_DB_SCHEMA.sql` — `CREATE TABLE [dbo].[Rma]`; `src/centron/Centron.WPF.UI/Modules/Rma/RmaOverviewAppModulController.cs:24`. (PRIMÄR)
+
+**RMM (Remote Monitoring and Management)**
+Fernüberwachung von Kundensystemen. Angebunden über eigene Einstellungen und Steuerungsschnittstellen.
+Beleg: `src/webservice/Centron.Controllers/Controllers/v1/Integrations/RmmController.cs`; `src/webservice/Centron.Controllers/Controllers/v1/DataExchange/RmmConnectionSettingsController.cs`. (PRIMÄR)
+
+## S
+
+**SelfCare-Formular**
+Vom Kunden im Webportal auszufüllendes Formular, das an eine Ticketvorlage gebunden ist.
+Beleg: `src/webservice/Centron.Controllers/Controllers/v1/SelfCare/SelfCareFormsController.cs`; `src/nexus/CentronNexus/Management/TicketPatterns/Components/SelfCareFormFieldGrid.razor`. (PRIMÄR)
+
+**SEPA-Mandat**
+Einzugsermächtigung des Kunden. Rechnungen verweisen über `SepaMandateI3D` darauf.
+Beleg: `SSMS_DB_SCHEMA.sql`, Tabelle `RechKopf` — `[SepaMandateI3D] [int] NULL`. (PRIMÄR)
+
+**ServiceBoard**
+Arbeitsoberfläche für den Service, sowohl als eigenständige Anwendungsart lizenziert als auch als Bereich im Webportal Nexus umgesetzt.
+Beleg: `src/backend/Centron.Interfaces/Administration/Logins/ApplicationKind.cs` — `ServiceBoard`, `ServiceBoardOnline`, `ServiceBoardNext`; `src/nexus/CentronNexus/ServiceBoard/`. (PRIMÄR)
+
+**Sichbenu**
+Datenbanktabelle der Benutzerkonten. Enthält unter anderem Kennwort-Hash (`Kennwort`), Mindestlänge (`KennLaenMin`), Änderungsintervall (`KennAendNachTagen`), Kontosperrzeitraum (`KontoDeakVon`/`KontoDeakBis`) und Zwei-Faktor-Angaben.
+Beleg: `SSMS_DB_SCHEMA.sql` — `CREATE TABLE [dbo].[Sichbenu]`. (PRIMÄR)
+
+**Sichrech**
+Datenbanktabelle der Rechtedefinitionen mit Kennung, Anzeigetext, übergeordnetem Recht und Kennzeichen `Obsolete`.
+Beleg: `SSMS_DB_SCHEMA.sql` — `CREATE TABLE [dbo].[Sichrech]`. (PRIMÄR)
+
+**Sonderpreis**
+Kundenspezifischer Artikelpreis. Grundlage der Artikelsichtbarkeit im Webshop des Kundenportals.
+Beleg: `README.md`, Abschnitt „Contributing / WebCart" — „The available articles come from the customers ‚Sonderpreise'". (KONTEXT)
+
+**Stammblatt**
+Geräteblatt zu einem verkauften Gerät mit Seriennummer, Rechnungsbezug, Kundenbezug, Zählerstand und Vertragsbezug. Siehe **Gerätedatenhaltung**.
+Beleg: `src/backend/Centron.Entities/Entities/Sales/Receipts/MasterDataLists/MasterDataList.cs`; `src/centron/Centron.WPF.UI/Modules/Finances/MasterDataLists/OverView/MasterDataListOverviewAppModuleController.cs:17-18`. (PRIMÄR)
+
+**Stammdat**
+Alte Einstellungstabelle. Neue Einstellungen sind ausdrücklich in `ApplicationSettings` abzulegen.
+Beleg: `docs/guides/development/settings-management.md`, Abschnitt „Legacy: Stammdat Table" — „no new settings should be added to this table". (KONTEXT)
+
+## T
+
+**TAPI**
+Telefonieschnittstelle für Anrufsteuerung und Anruferkennung; eingebunden über eine angepasste Fremdkomponente.
+Beleg: `docs/reference/architecture/tapi.md` — „OUR Traysoft.AddTAPI.dll has been modified to work with .NET 5/6". (KONTEXT)
+
+**Ticket (Sitzung)**
+Sitzungsnachweis der Anmeldung am Webservice, nicht zu verwechseln mit dem **Helpdesk-Ticket**. Ein Sitzungsticket verfällt standardmäßig nach 30 Minuten.
+Beleg: `src/backend/Centron.BL/Administration/Logins/TicketBL.cs:26` — `private const int TicketExpireInMinutes = 30;`. (PRIMÄR)
+
+**Ticketvorlage (TicketPattern)**
+Vorlage, aus der Tickets samt Kategorien, Checklisten, Formularen, Mailvorlagen und Skripten erzeugt werden.
+Beleg: `src/nexus/CentronNexus/Management/TicketPatterns/Components/` (Registerkarten Allgemein, Checklisten, Formulare, Mailvorlage, Skripte, Webformular); `src/webservice/Centron.Controllers/Controllers/v1/Tickets/TicketPatternsController.cs`. (PRIMÄR)
+
+## U
+
+**Übernahmewürdigkeit**
+Bewertung, ob eine erfasste Anforderung im Zielsystem erhalten bleiben soll. Bewertungsstufen: `übernehmen`, `Workaround`, `Sonderfall`, `veraltet`. Rein methodischer Begriff dieser Spezifikation, kein Systembegriff.
+
+## V
+
+**Vertrag**
+Wiederkehrend abzurechnende Kundenvereinbarung. Kopftabelle `VertragKopf` mit 205 Spalten, Positionstabelle `VertragPos`, Vertragsartentabelle `VertragsArt`, Verknüpfung zur erzeugten Rechnung über `VertragRechKopfZuordnung`.
+Beleg: `SSMS_DB_SCHEMA.sql` — die genannten Tabellen. (PRIMÄR)
+
+**Vertragsabrechnung**
+Automatisierte Erzeugung von Abrechnungsbelegen aus Verträgen.
+Beleg: `src/centron/Centron.WPF.UI/Modules/Finances/AutomatedBilling/AutomatedBillingAppModuleController.cs:14`. (SEKUNDÄR)
+
+## W
+
+**Web-Account**
+Zugang für Kunden zum Webportal. Eigenes Rechtemodell (`WebAccountRightsConst`) und eigene Anmeldeart (`LoginType=Webaccount`), getrennt vom Mitarbeiterkonto.
+Beleg: `src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/WebAccountRightsConst.cs`; `src/nexus/CentronNexus/Shared/Authorization/CentronAuthorization.cs:16-18`. (PRIMÄR)
+
+**WebCart**
+Webshop im Kundenportal. Sichtbare Artikel stammen aus den Sonderpreisen des Kunden.
+Beleg: `README.md`, Abschnitt „Contributing / WebCart"; `src/nexus/CentronNexus/WebCart/`. (KONTEXT)
+
+**WebServiceBL**
+Schicht, die Entitäten in DTOs überführt und die fachlichen Rechteprüfungen für den Webservice ausführt.
+Beleg: `docs/getting-started/general-structure.md`; `src/backend/Centron.BL/WebServices/`. (KONTEXT)
+
+**WSLogic**
+Clientseitige Implementierung einer `ILogic`-Schnittstelle, die den Webservice aufruft. Gegenstück zu **BLLogic**.
+Beleg: `docs/getting-started/general-structure.md`, Abschnitt „WS Implementation (Web Service Access)". (KONTEXT)
+
+## Z
+
+**ZUGFeRD / XRechnung**
+Standards für die elektronische Rechnung. Im System als eigene Erweiterung `ZUGFeRD21_Extended` sowie über einen Importendpunkt umgesetzt; Rechnungen tragen dafür die Einstellung `IsZugferdInvoiceActive`.
+Beleg: `src/backend/Centron.Gateway/ZUGFeRD21_Extended/`; `src/webservice/Centron.Controllers/Controllers/v1/Receipts/ZugferdImportController.cs`; `docs/guides/development/xrechnung.md`; `docs/guides/development/settings-management.md` (Beispiel `ApplicationSettingID.IsZugferdInvoiceActive`). (PRIMÄR)
+
+**Zwei-Faktor-Authentifizierung**
+Im System bestehen zwei voneinander unabhängige Verfahren: ein anmeldeseitiges Verfahren über RADIUS oder E-Mail-Link (`TwoFactorAuthBL`) und ein zeitbasiertes Einmalkennwort nach TOTP (`TwoFactorAuthenticationBL` mit `Centron.Core.GoogleAuthenticator`).
+Beleg: `src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs`; `src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs:51`. (PRIMÄR)

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-9d9e/RawResult.json

@@ -0,0 +1 @@
+{"is_error":true,"duration_api_ms":25332446,"num_turns":1,"stop_reason":"stop_sequence","session_id":"d23d004f-5de4-47d7-a3c9-dbc25dafbe27","total_cost_usd":293.00959234999993,"usage":{"output_tokens_details":{"thinking_tokens":0},"input_tokens":0,"cache_creation_input_tokens":0,"cache_read_input_tokens":0,"output_tokens":0,"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":0,"ephemeral_5m_input_tokens":0},"inference_geo":"","iterations":[],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6962,"outputTokens":22,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.007072,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-opus-5":{"inputTokens":4038,"outputTokens":1970258,"cacheReadInputTokens":363710851,"cacheCreationInputTokens":8663246,"webSearchRequests":0,"costUSD":286.42943924999986,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-opus-5","provider":"firstParty","costBasis":"list"},"claude-sonnet-5":{"inputTokens":296,"outputTokens":136253,"cacheReadInputTokens":17725083,"cacheCreationInputTokens":665977,"webSearchRequests":0,"costUSD":6.573081100000002,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-sonnet-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[],"terminal_reason":"api_error","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","origin":{"kind":"task-notification"},"subagent_stats":{"spawned":34,"requested":{"background":2,"foreground":0,"unset":32},"started_in_background":34,"max_depth":2,"spawned_by_subagents":24,"completed":32,"failed":1,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":22,"budget":0},"by_type":{"general-purpose":10,"Explore":24}},"subtype":"success","api_error_status":429,"result":"You've hit your session limit · resets 5:40pm (Europe/Berlin)","type":"result","duration_ms":446,"uuid":"50278ba1-d25b-441f-bab5-b2c1c385ec79","queued_turn_count":0}

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-9d9e/_meta/before.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-9d9e/_meta/combined_prompt.md

@@ -0,0 +1,178 @@
+# Versuch 01 - Baseline (Prompt-only) - Iteration 02
+
+## Metadaten
+- **Versuch:** V1 Baseline (Prompt-only)
+- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
+- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
+- **Zeitstempel:** 2026-08-26
+- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
+- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
+
+  | Änderung | Auslösender Befund |
+  |---|---|
+  | Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
+  | Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
+  | Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
+  | Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
+  | Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
+  | Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
+  | Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
+
+  Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
+
+> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
+> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
+> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
+
+---
+
+## Prompt
+
+Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
+
+### Auftrag
+
+Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
+
+1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
+2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
+3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
+
+Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
+
+### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
+
+Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
+
+**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
+
+### Vorgehen (statische Analyse, keine Ausführung)
+
+Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
+
+**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
+
+**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig.
+
+**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
+
+2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
+3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
+4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
+5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
+6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
+
+### Pflicht-Eigenschaften jeder Anforderung
+
+- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
+- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
+- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
+- **Belegklassifikation:** Kennzeichne jeden Beleg als
+  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
+  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
+  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
+- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
+- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
+- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
+- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
+- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
+
+### Formatvorgabe pro Anforderung
+
+```
+ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
+Titel:         <kurzer Titel>
+Ebene:         <StRS | SyRS | SwRS>
+Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
+Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
+Akteur:        <Rolle / System / Komponente>
+Vorbedingung:  <Zustand vor Auslösen>
+Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
+Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
+Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
+Belege:
+  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
+  - [SEKUNDÄR] <...> - Begründung: <...>
+  - [KONTEXT]  <...> - Begründung: <...>
+Prüfidee:      <Akzeptanzkriterium oder Testidee>
+Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
+Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
+Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
+Status:        <belegt | HYPOTHESE>
+```
+
+### Traceability
+
+Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
+- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
+- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
+- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
+
+### Nicht-funktionale Anforderungen
+
+- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
+- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
+
+### Konsolidierungsbedarf
+
+Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
+
+**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
+
+### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
+
+```
+Ergebnisse/
+  StRS.md
+  SyRS.md
+  SwRS.md
+  Traceability.md   (oder Traceability.csv)
+  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
+  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
+  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
+                     Selbstbewertung, bekannte Lücken)
+```
+
+Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
+
+### Randbedingungen
+
+- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
+- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
+- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
+- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
+- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
+
+### Abschluss
+
+Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
+- Doppelte oder mehrfach vergebene IDs
+- Anforderungen ohne Beleg
+- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
+- Tracelinks auf nicht existierende IDs
+- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
+- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
+- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
+
+Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
+
+Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
+- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
+- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
+- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
+- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
+- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
+
+---
+
+### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
+Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien, das Ausführen von
+Kommandozeilenbefehlen im Arbeitsverzeichnis sowie die werkzeugeigenen Subagenten.
+Nicht verfügbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe
+Werkzeugserver.
+Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
+Werkzeuge zu ersetzen.
+### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
+Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
+`c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 3\claude-opus-5\builtin\high\02_Lauf_2026-08-26_160037_v4.5.0-9d9e\Ergebnisse\`.
+Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-9d9e/_meta/endzeit.txt

@@ -0,0 +1 @@
+2026-08-26T16:35:37.0099365+02:00

Versuche/Versuch_01/Iteration 3/claude-opus-5/builtin/high/02_Lauf_2026-08-26_160037_v4.5.0-9d9e/_meta/startzeit.txt

@@ -0,0 +1 @@
+2026-08-26T16:00:46.8220483+02:00

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-37c5/Ergebnisse/Analysebericht.md

@@ -0,0 +1,924 @@
+# Analysebericht — Reverse Requirements Engineering c-entron ERP-Suite
+
+**Untersuchungsgegenstand:** `C:\DEV\MasterArbeit\QuellCode\CentronERP` — NEXOWARE c-entron ERP (Produktversion `2.0.2611-alpha`, `version.json`)
+**Umfang der Codebasis:** 26.457 Dateien, 430 MB (gemessen mit `find . -type f | wc -l` bzw. `du -sh .`)
+**Datenbankschema:** `SSMS_DB_SCHEMA.sql`, 1.535 `CREATE TABLE`-Anweisungen, 134 `FOREIGN KEY`-Klauseln
+**Analyseart:** rein statisch, ausschließlich lesend. Es wurde keine Datei im Arbeitsverzeichnis verändert und kein System ausgeführt.
+**Norm:** ISO/IEC/IEEE 29148:2018 (StRS / SyRS / SwRS)
+
+---
+
+## 1. Vorgehen
+
+| Schritt | Inhalt | Status |
+|---|---|---|
+| 1 Scope | Vorgegeben: gesamte Codebasis, keine Modulbeschränkung | übernommen |
+| 0 Modulinventar | Vollständige Inventarisierung **vor** der ersten Anforderung (Abschnitt 2) | durchgeführt |
+| 0b Mindestabdeckung | Jedes Inventarmodul erhält mindestens eine Anforderung | durchgeführt |
+| 0c Vertiefung nach Risiko | Sicherheit, Abrechnung/Fakturierung, Berechtigungen | durchgeführt |
+| 2 Artefakterhebung | Quellcode, Konfiguration, UI-Ressourcen, DB-Schema, Entwicklerdokumentation, CI-Definitionen | durchgeführt |
+| 3 Technische Analyse | Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungen, Rechteprüfungen | durchgeführt |
+| 4 Semantische Interpretation | Ableitung fachlicher Aussagen (Feld `Aussage`) aus belegten Beobachtungen (Feld `Fakt`) | durchgeführt |
+| 5 Formalisierung | Blockformat je Anforderung | durchgeführt |
+| 6 Traceability-Anreicherung | Artefaktbelege je Anforderung, Tracelinks zwischen den Ebenen, `Traceability.md` | durchgeführt |
+| 7 Validierung | manuell durch Fachexperten | nicht Teil dieses Laufs |
+
+### 1.1 Wie das Inventar entstanden ist
+
+Das Modulinventar ist nicht geschätzt, sondern aus drei maschinell auswertbaren Registern abgeleitet:
+
+1. **`src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`** (954 Zeilen) — der Konstruktor der Klasse `ModuleRegistration` enthält die vollständige Liste der registrierbaren Anwendungsmodule des Windows-Clients, gruppiert in 15 `#region c-entron Module: …`-Blöcken, jeweils mit Rechte- und Lizenzbedingung. Zusätzlich listen `GetSettingsWithoutModule()` und `GetPersonalSettings()` rund 90 Einstellungsseiten.
+2. **`public string ModuleName =>` / `public string Description =>`** in den `*AppModuleController.cs`-Klassen unter `src/centron/Centron.WPF.UI/Modules/` — liefern den fachlichen Namen und eine Kurzbeschreibung je Modul in der Originalsprache des Produkts.
+3. **Verzeichnisstruktur der Fachdomänen** in `src/backend/Centron.BL/` (88 Domänenordner), `src/backend/Centron.Entities/Entities/` (88 Domänenordner), `src/nexus/CentronNexus/` (Blazor-Bereiche), `src/webservice/Centron.Controllers/Controllers/` (42 Controller) und `src/apis/` (8 Integrationsassemblies).
+
+Die Spalte „fachliche Aufgabe" gibt, wo vorhanden, die im Code hinterlegte `Description` wieder; sonst eine aus dem Code abgeleitete Kurzfassung.
+
+---
+
+## 2. Schritt 0 — Modulinventar
+
+154 Module/Komponenten in 15 Bereichen. Das Inventar ist die Bezugsgröße für die Abdeckung in Abschnitt 3.
+
+### Bereich A — Belegwesen, Vertrieb und CRM
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M01 | Belegwesen (Kundenbelege) | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/` | Erfassung, Prüfung, Nummerierung und Speicherung von Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift und Abholschein |
+| M02 | Adressstamm / CRM | `src/centron/Centron.WPF.UI/Modules/Finances/Crm/CrmAppModuleController.cs` | „Verwaltung von Adressen, CRMs und Belegen" |
+| M03 | Adressen & Belege (Altmodul) | `src/centron/Centron.WPF.UI/Modules/Finances/AccountManagement/AccountManagementAppModuleController.cs` | „Suche von noch nicht konvertierten Adressen und von Kundenbelegen" |
+| M04 | CRM-Projekte | `src/centron/Centron.WPF.UI/Modules/Finances/Projects/ProjectsAppModuleController.cs` | „Erstellung und Verwaltung von Projekten" |
+| M05 | Kampagnen/Mailing | `src/centron/Centron.WPF.UI/Modules/Finances/Campaigns/CampaignAppModuleController.cs` | „Erstellen und Verwalten von Kampagnen" |
+| M06 | Audit (Kundenaudits) | `src/centron/Centron.WPF.UI/Modules/Survey/SurveyAppModuleController.cs` | „Erstellen und Verwalten von Kundenaudits" |
+| M07 | Stammblätter | `src/centron/Centron.WPF.UI/Modules/Finances/MasterDataLists/`, `src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs` | „Liste aller Stammblätter" — Geräteakten zu Kunden und Verträgen |
+| M08 | PLM (Product Lifecycle Management) | `src/centron/Centron.WPF.UI/Modules/PLM/PlmAppModuleController.cs`, `src/backend/Centron.BL/Finances/ProductLifecycleBL.cs` | Lebenszyklusverwaltung von Kundenprodukten und Lizenzen |
+| M09 | Lieferanten-Verträge | `src/centron/Centron.WPF.UI/Modules/Finances/Crm/AccountContracts/` | „Erstellen und Verwalten von Lieferanten-Verträge" |
+| M10 | Produktmatrix (Kundenmatrix) | `src/backend/Centron.BL/ProductMatrix/ProductMatrixBL.cs` | Zuordnung von Produkten zu Kunden als Vertriebsmatrix |
+| M11 | Video-Portal | `src/centron/Centron.WPF.UI/Modules/Global/VideoPortal/`, `src/backend/Centron.BL/VideoPortal/` | Bereitstellung und Auswertung von Schulungsvideos je Mitarbeiter |
+| M12 | Geräteverwaltung (Kundengeräte) | `src/backend/Centron.BL/Devices/AccountDeviceBL.cs`, `src/centron/Centron.WPF.UI/Modules/Finances/Crm/Devices/` | „Bearbeiten von Geräten" — Kundengeräte als eigenständige Objekte |
+
+### Bereich B — Verträge und Abrechnung
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M13 | Verträge (Belegart Vertrag) | `src/backend/Centron.BL/Sales/Receipts/ContractLists/ReceiptContractBL.cs` | Vertrag als Belegart mit Abrechnungsintervall, Kontingent und Laufzeit |
+| M14 | Vertragsabrechnung | `src/centron/Centron.WPF.UI/Modules/Finances/AutomatedBilling/`, `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/` | „Abrechnung von Verträgen" — periodische Rechnungserzeugung |
+| M15 | Pauschalabrechnung | `src/centron/Centron.WPF.UI/Modules/Finances/FlatrateBilling/` | „Verwaltung und Erstellung von Pauschalabrechnungen" |
+| M16 | Vereinfachte Ticketabrechnung | `src/centron/Centron.WPF.UI/Modules/Finances/TimerBilling/` | „Abrechnung von Tickets und einzelnen Zeiten" |
+| M17 | Vertragsarten | `src/centron/Centron.WPF.UI/Modules/Finances/Contracts/ContractSettings/ContractTypes/` | Verwaltung der Vertragsarten als Stammdatum |
+| M18 | Klick-Zählerverwaltung | `src/centron/Centron.WPF.UI/Modules/Finances/DeviceClickCounter/` | „Verwaltung von Klick-Zählern" für nutzungsabhängige Abrechnung |
+| M19 | Statischer Datenimport – Verträge | `src/centron/Centron.WPF.UI/Modules/Sales/SpecialArticleImport/` | Import von Sonderpreisen als Vertragsgrundlage |
+| M20 | Dynamischer Datenimport – Verträge | `src/centron/Centron.WPF.UI/Modules/Sales/SpecialArticleToContractImport/` | „Vertragspositionsdaten für Abrechnung importieren" |
+| M21 | Vertragsauswertung | `src/centron/Centron.WPF.UI/Modules/Finances/ContractEvaluation2/` | „Auswertung von Verträgen" |
+| M22 | Provisionsauswertung | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/Provision/Evaluation/` | „Auswertung der Schema-basierten Provisionierung" |
+| M23 | Provisionsschemas verwalten | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/Provision/Schemas/` | „Verwaltung von Provisionsschemas" |
+| M24 | Provisionsschema-Kundenzuordnung | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/Provision/SchemaCustomerAssignments/` | „Verwaltung welche Provisionsschemas welchen Kunden zugeordnet sind" |
+| M25 | Leasing/Service | `src/centron/Centron.WPF.UI/Modules/Administration/ServiceAndLeasing/` | Verwaltung von Leasing- und Servicesätzen |
+| M26 | Aufschläge Stundensätze | `src/centron/Centron.WPF.UI/Modules/Administration/HourlySurchargeRates/` | „Verwalten von Aufschlagssätzen zu Mitarbeiterstunden" |
+| M27 | Kontingentverwaltung | `src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptContractHelperBL.cs` | Verwaltung von Vertragskontingenten inklusive Rest- und Überbuchung |
+
+### Bereich C — Finanzen und Buchhaltung
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M28 | Mahnwesen | `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs` | „Mahnungen" — Mahnstufenverwaltung offener Rechnungen |
+| M29 | OPOS | `src/centron/Centron.WPF.UI/Modules/Finances/Opos/` | „OPOS Übersicht" — offene Posten |
+| M30 | Zahlungseingang | `src/centron/Centron.WPF.UI/Modules/Finances/Payments/`, `src/backend/Centron.BL/Finances/Payments/PaymentsBL.cs` | „Zahlungseingänge verwalten" |
+| M31 | SEPA-Zahlungsverkehr | `src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs` | „Export von SEPA-Lastschriften" in fünf PAIN-Formaten |
+| M32 | Buchhaltungsexport/-import | `src/centron/Centron.WPF.UI/Modules/DataExchange/BookKeeping/` | „Export und Import von Buchhaltungsdaten" |
+| M33 | DATEV Belegtransfer | `src/centron/Centron.WPF.UI/Modules/DataExchange/DatevOnline2020/` | Export für DATEVconnect online |
+| M34 | Kontenrahmen | `src/centron/Centron.WPF.UI/Modules/Warehousing/AccountSystems/` | „Verwaltung von Buchhaltungskontenrahmen" |
+| M35 | Mehrwertsteuerverwaltung | `src/centron/Centron.WPF.UI/Modules/Warehousing/ValueAddedTaxAppModuleController.cs`, `src/backend/Centron.BL/Warehousing/TaxBL.cs` | „Verwaltung und Bearbeitung von Mehrwertsteuern" |
+| M36 | Kostenträger/Kostenstellen | `src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter/` | „Erstellung und Verwaltung von Kostenträger / Kostenstellen" |
+| M37 | Belegkonditionen | `src/centron/Centron.WPF.UI/Modules/Administration/ReceiptConditions/` | „Verwaltung von Belegkonditionen, Zahlungskonditionen und Lieferbedingungen" |
+| M38 | Kalkulation pro Filiale | `src/centron/Centron.WPF.UI/Modules/DataExchange/SupplierOrderPerBranch/` | Filialbezogene Auswertung von Einkaufskalkulationen |
+| M39 | Online-Banking (Kontoauszüge) | `src/centron/Centron.WPF.UI/Modules/OnlineBanking/`, `src/backend/Centron.BL/Finances/OnlineBanking/` | „Listet Transaktionen für Bankkonten auf und erlaubt eine automatisierte oder manuelle Zuweisung von Rechnungen" |
+| M40 | SEPA-Lastschriftmandate | `src/centron/Centron.WPF.UI/Modules/Administration/SepaContract/` | „Einstellungen für SEPA Lastschrift" — Mandatsverwaltung |
+
+### Bereich D — Einkauf und Lieferantenprozesse
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M41 | Lieferantenbelegwesen | `src/backend/Centron.BL/Purchasing/`, `src/centron/Centron.WPF.UI/Modules/Purchasing/PurchaseSettings/ReceiptSettings/` | Bestellung, Lieferschein, Eingangsrechnung und Gutschrift gegenüber Lieferanten |
+| M42 | Belegerfassung (Kosten) | `src/centron/Centron.WPF.UI/Modules/Warehousing/OutcomingPayments/` | „Erfassung von Kosten und Belegen" |
+| M43 | Bestellvorschlagsliste | `src/centron/Centron.WPF.UI/Modules/Purchasing/OrderSuggestionList/` | Automatisierte Bestellvorschläge auf Basis von Bedarf und Bestand |
+| M44 | EDI-Verwaltung | `src/centron/Centron.WPF.UI/Modules/Purchasing/EDIManagement/`, `src/backend/Centron.BL/EDI/` | „EDI Orderresponse/Rechnungen Bearbeitung" |
+| M45 | Eingang/Kalkulation | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/SupplierReceiptDocuments/` | „Import von Lieferantenbelegen aus E-Mails" |
+| M46 | TradePool | `src/backend/Centron.BL/TradePool/` | Handelsplattform-Anbindung für Artikel- und Preisdaten |
+
+### Bereich E — Logistik und Warenwirtschaft
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M47 | Artikelverwaltung | `src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleManagement/`, `src/backend/Centron.BL/Warehousing/ArticleBL.cs` | „Erstellung und Verwaltung von Artikeln" |
+| M48 | Artikelimport | `src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleImport/` | Import von Artikelstammdaten aus externen Quellen |
+| M49 | Warengruppenverwaltung | `src/centron/Centron.WPF.UI/Modules/Warehousing/MaterialGroupManagement/`, `src/backend/Centron.BL/Warehousing/InventoryManagement/MaterialGroupBL.cs` | Klassifizierung von Artikeln in Warengruppen |
+| M50 | Lager- und Bestandsführung | `src/backend/Centron.BL/Warehousing/StockManagement/ArticleStockBL.cs` | Bestandsführung je Artikel, Haupt- und Nebenlager |
+| M51 | Inventur | `src/centron/Centron.WPF.UI/Modules/Warehousing/Inventory/`, `src/backend/Centron.BL/Warehousing/InventoryManagement/` | „Durchführen von Inventuren" |
+| M52 | Kommissionierung | `src/centron/Centron.WPF.UI/Modules/Warehousing/Commissions/` | „Durch dieses Modul können Aufträge kommissioniert werden" |
+| M53 | Barcode-/Seriennummernverwaltung | `src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptBarcodeBL.cs`, `src/backend/Centron.BL/Warehousing/BarcodeBL.cs` | Erfassung und Prüfung von Seriennummern und Barcodes auf Belegen |
+| M54 | Versandabwicklung | `src/apis/Centron.Api.Gls/`, `src/apis/Centron.Api.Shipcloud/` | Erzeugung von Versandaufträgen und Labels bei GLS und Shipcloud |
+| M55 | Projektpreis-Import | `src/centron/Centron.WPF.UI/Modules/ProjectPriceImport/` | „Projektpreise als Sondervereinbarungen importieren" |
+| M56 | Aktionspreise | `src/backend/Centron.BL/Warehousing/ActionPriceBL.cs` | Zeitlich befristete Aktionspreise von Distributoren und Herstellern |
+| M57 | Stücklisten / Teilelisten | `src/backend/Centron.BL/Warehousing/StockManagement/PartListArticleBL.cs` | Verwaltung von Stücklistenartikeln |
+
+### Bereich F — Service und Helpdesk
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M58 | Ticket-Liste / Helpdesk | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketList/` | „Alle Tickets" — Erfassung und Bearbeitung von Serviceanfragen |
+| M59 | Ticketzeiterfassung | `src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs`, `HelpdeskTimeRecordingBL.cs` | Erfassung, Freigabe und Abrechnung von Arbeitszeiten je Ticket |
+| M60 | Checklisten | `src/centron/Centron.WPF.UI/Modules/Helpdesk/CentronChecklist/`, `src/backend/Centron.BL/CheckListArea/` | „Erstellen und Verwalten von Checklisten" |
+| M61 | Taskmanagement | `src/centron/Centron.WPF.UI/Modules/Helpdesk/TaskManagement/`, `src/backend/Centron.BL/TaskManager/` | „Erstellen und Verwalten von Tasks" |
+| M62 | RMA/Werkstatt | `src/centron/Centron.WPF.UI/Modules/Rma/` | „Alles rund um RMA" — Rücksendungs- und Reparaturabwicklung |
+| M63 | Ticketprozess-Vorlagen | `src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketProcessTemplates/`, `src/backend/Centron.BL/Sales/Support/TicketProcess/` | „In diesem Modul können Vorlagen für Ticketprozesse verwaltet werden" |
+| M64 | Erwartete Events | `src/centron/Centron.WPF.UI/Modules/Helpdesk/ExpectedEvents/`, `src/backend/Centron.BL/ExpectedEvents/` | Überwachung erwarteter Ereignisse (Ausbleiben löst Meldung aus) |
+| M65 | Erwartete Events Auswertung | `src/centron/Centron.WPF.UI/Modules/Helpdesk/ExpectedEventsReporting/` | „Auswertung Erwartendener Events" |
+| M66 | Eskalationen | `src/backend/Centron.BL/Sales/Support/Escalation/EscalationBL.cs` | Automatische Eskalation von Tickets bei Fristüberschreitung |
+| M67 | QM-Meldungen | `src/centron/Centron.WPF.UI/Modules/QM/` | „Qualitätsmanagemnt Meldungen" |
+| M68 | Projektverwaltung (intern) | `src/centron/Centron.WPF.UI/Modules/ProjectManagement/` | „Übersicht über die Entwicklungsprojekte. Aktuell nur intern für NEXOWARE Systems GmbH" |
+| M69 | Ticketprojekte | `src/backend/Centron.BL/TicketProjects/` | Bündelung von Tickets zu Projekten |
+| M70 | Externer Helpdesk | `src/backend/Centron.BL/ExternalHelpdesk/` | Anbindung fremder Ticketsysteme |
+| M71 | Reisekosten/Auslagen | `src/centron/Centron.WPF.UI/Modules/Purchasing/TravelExpense/` | „Verwalten und Abrechnen der Mitarbeiterreisekosten" — im Code deaktiviert |
+
+### Bereich G — Produktion
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M72 | Maschinenverwaltung | `src/centron/Centron.WPF.UI/Modules/Production/MachineManagement/` | „Verwaltung der Maschinen für die Produktion" |
+| M73 | Produktionsaufträge | `src/centron/Centron.WPF.UI/Modules/Production/ProductionOrder/`, `src/backend/Centron.BL/Production/ProductionOrderBL.cs` | „Erstellung und Verwaltung von Produktionsaufträgen" |
+| M74 | Artikelproduktion | `src/backend/Centron.BL/Warehousing/ArticleProduction/` | Verbrauch und Erzeugung von Artikeln durch Produktionsschritte |
+
+### Bereich H — Controlling und Statistik
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M75 | Analytics | `src/centron/Centron.WPF.UI/Modules/Statistics/SaleStatistics/` | „Erstellung, Bearbeitung und Export verschiedenster Auswertungen" |
+| M76 | Management Info | `src/centron/Centron.WPF.UI/Modules/Statistics/ManagementInfo/` | „Anzeige der aktuellen Firmenkennzahlen" |
+| M77 | Leistungsnachweise | `src/centron/Centron.WPF.UI/Modules/Statistics/EmployeeAnalytics/` | „Darstellung der Mitarbeiterauslastung" |
+| M78 | Mitarbeiterauslastung | `src/centron/Centron.WPF.UI/Modules/MyCentron/MyDay/EmployeeOverview/` | „Übersicht über die Arbeitstage von Mitarbeitern und Abteilungen" |
+| M79 | MSP-Collector | `src/centron/Centron.WPF.UI/Modules/Statistics/MspCollectors/`, `src/backend/Centron.Gateway/MspCollector/` | „Oberfläche für den MSP-Collector" — Einsammeln von Nutzungsdaten |
+| M80 | MSP-Auswertung | `src/centron/Centron.WPF.UI/Modules/Global/MSPLicensesCompare/` | „Auswertung des MSP-Collector Imports" |
+| M81 | MSP-Dashboard | `src/centron/Centron.WPF.UI/Modules/Statistics/MspStatistics/` | „Oberfläche für die Auswertung von MSP-Leistungsbausteinen" |
+| M82 | Telemetrie | `src/backend/Centron.BL/Telemetry/TelemetryBL.cs` | Erhebung von Nutzungs- und Systemkennzahlen |
+| M83 | Statistikbasis | `src/backend/Centron.BL/Statistics/` | Gemeinsame Auswertungsbausteine für Umsatz und Zeiten |
+
+### Bereich I — Persönlicher Arbeitsplatz (MyCentron)
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M84 | Dashboard | `src/centron/Centron.WPF.UI/Modules/MyCentron/Dashboard/` | „Übersicht Ticketzeiten und persönliches Dashboard" |
+| M85 | Mein Tag | `src/centron/Centron.WPF.UI/Modules/MyCentron/MyDay/Editor/`, `src/backend/Centron.BL/MyDay/` | „Zusammenfassung ihres Arbeitstages" |
+| M86 | Monatsübersicht | `src/centron/Centron.WPF.UI/Modules/MyCentron/MyDay/MonthReview/` | „Übersicht über mehere Arbeitstage und -wochen" |
+| M87 | Todo-Liste | `src/centron/Centron.WPF.UI/Modules/MyCentron/TodoList/`, `src/backend/Centron.BL/ToDoArea/` | „Aufgabenliste für Tickets, Belege und mehr" |
+| M88 | Telefonate / TAPI | `src/centron/Centron.WPF.UI/Modules/MyCentron/Telephony/`, `src/backend/Centron.BL/Tapi/PhoneCallBL.cs` | Protokollierung ein- und ausgehender Telefonate |
+| M89 | Kalender & Termine | `src/backend/Centron.BL/Calendar/CalendarBL.cs`, `src/backend/Centron.BL/Sales/Calendar/ScheduleBL.cs` | Terminverwaltung inklusive Vertretungsregelung und Exchange-Abgleich |
+| M90 | AI-Chat | `src/centron/Centron.WPF.UI/Modules/ArtificialIntelligence/Chat/`, `src/backend/Centron.BL/ArtificialIntelligence/` | „AI-Chat mit ERP-Toolunterstützung" |
+| M91 | Persönliche Einstellungen | `src/centron/Centron.WPF.UI/Modules/MyCentron/PersonalSettings/` | Benutzerbezogene Einstellungen (Signatur, Telefonie, Oberfläche, Passwort, Token) |
+| M92 | Terminanfragen | `src/backend/Centron.BL/AppointmentRequests/` | Anfrage und Bestätigung von Terminen zwischen Beteiligten |
+
+### Bereich J — Administration und Systemverwaltung
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M93 | Einstellungsverwaltung | `src/centron/Centron.WPF.UI/Modules/Administration/Settings/`, `src/backend/Centron.BL/Administration/Settings/` | „Verwaltung und Überblick über sämtliche c-entron Einstellungen" |
+| M94 | Mitarbeiterverwaltung | `src/centron/Centron.WPF.UI/Modules/Administration/EmployeeManagement/`, `src/backend/Centron.BL/EmployeeArea/` | „Mitarbeiter Verwaltung" inklusive Benutzerkonten |
+| M95 | Rechteverwaltung | `src/centron/Centron.WPF.UI/Modules/Administration/RightsManagement/`, `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` | „Verwaltung von Rechten und Rechtegruppen" |
+| M96 | Mandantenverwaltung | `src/centron/Centron.WPF.UI/Modules/Administration/MandatorManagement/` | „Mandanten Verwaltung" |
+| M97 | Filialverwaltung | `src/backend/Centron.Entities/Entities/BranchArea/`, `src/backend/Centron.BL/Sales/…/BranchBL` | Zuordnung von Belegen, Mitarbeitern und Rechten zu Filialen |
+| M98 | Länderverwaltung | `src/centron/Centron.WPF.UI/Modules/Administration/CountryManagement/` | „Verwaltung von Länderrelevanten Einstellungen" |
+| M99 | Mailvorlagen | `src/centron/Centron.WPF.UI/Modules/Administration/MailTemplates/`, `src/backend/Centron.BL/Mailings/` | „Alle Mailvorlagen" |
+| M100 | Textbausteine | `src/centron/Centron.WPF.UI/Modules/Administration/TextBlockManagement/`, `src/backend/Centron.BL/TextModuleArea/` | „Durch dieses Modul können die Textbausteine der c-entron verwaltet werden" |
+| M101 | Report-Engine | `src/backend/Centron.BL/ReportEngine/`, `src/centron/Centron.WPF.UI/Modules/Reports/ReportManagement/` | „Erstellen, Bearbeiten und Verwalten von Reports" |
+| M102 | Reportserver | `src/centron/Centron.WPF.UI/Modules/Administration/ReportServer/` | „Automatisiert E-Mails mit Reports an Kunden verschicken" |
+| M103 | c-entron DSGVO | `src/centron/Centron.WPF.UI/Modules/Administration/DSGVO/`, `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs` | „Modul für die DSGVO" — Löschrecht und Datenbereinigung |
+| M104 | Auftragsverarbeitungsvertrag | `src/centron/Centron.WPF.UI/Modules/Administration/DSGVO/OrderProcessingContractSettingsAppModuleController.cs` | „Einstellungen für Auftragsverarbeitungs-Vertrag" |
+| M105 | SQL-Manager | `src/centron/Centron.WPF.UI/Modules/Administration/SqlManagers/`, `src/backend/Centron.BL/Administration/SQLManagement/` | Direkter SQL-Zugriff für Administratoren |
+| M106 | c-entron Logs | `src/centron/Centron.WPF.UI/Modules/Administration/LogViewer/` | Anzeige der Anwendungsprotokolle |
+| M107 | c-entron Inspektor | `src/centron/Centron.WPF.UI/Modules/MyCentron/CentronInspectors/` | „Prüft die c-entron und bringt Vorschläge, wie Sie noch mehr aus der c-entron rausholen" |
+| M108 | Data Updater (Massenupdate) | `src/centron/Centron.WPF.UI/Modules/Massenupdates/`, `src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs` | „Daten verändern/anpassen im großen Stil" |
+| M109 | API-Zugriffstoken | `src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs` | „Verwalten Sie alle API-Zugriffstoken im System" |
+| M110 | Lizenzverwaltung | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs` | Prüfung von Lizenzumfang, Anzahl, Gültigkeitsdatum und Version |
+| M111 | Zusatzfelder (Custom Properties) | `src/centron/Centron.WPF.UI/Modules/Global/CustomProperties/`, `src/backend/Centron.BL/Customizations/` | „Zusatzfelder können selbst bestimmt werden und an verschiedene Objekte angehängt werden" |
+| M112 | Passwort-Manager (Zugänge) | `src/centron/Centron.WPF.UI/Modules/PasswordManager/AccessManagementAppModuleController.cs`, `src/backend/Centron.BL/PasswordManager/` | „Zugangsverwaltung des Passwort Managers" |
+| M113 | Passwort-Manager Richtlinien | `src/centron/Centron.WPF.UI/Modules/PasswordManager/GuidelineManagementAppModuleController.cs` | „Verwaltung für die Richlinien des Passwort Manager" |
+| M114 | Passwort-Manager Zugangsbereiche | `src/centron/Centron.WPF.UI/Modules/PasswordManager/AccessAreaManagementAppModuleController.cs` | „Verwaltung für die Zugangsbereiche des Passwort Managers" |
+| M115 | Fernzugriff (RDP/SSH) | `src/centron/Centron.WPF.UI/Modules/PasswordManager/RDPEmbeddedAppModuleController.cs`, `SSHEmbeddedAppModuleController.cs` | Eingebettete Remotedesktop- und SSH-Verbindungen |
+| M116 | Externe Tools | `src/centron/Centron.WPF.UI/Modules/Administration/ExternalTools/`, `src/backend/Centron.BL/ExternalToolsBL/` | Aufruf externer Werkzeuge aus dem Kontext eines Objekts |
+| M117 | Update-Benachrichtigung | `src/centron/Centron.WPF.UI/Modules/Administration/UpdateAvailableNotificationSettings/` | Benachrichtigung ausgewählter Mitarbeiter über verfügbare Updates |
+| M118 | Benachrichtigungen | `src/backend/Centron.BL/Notifications/`, `src/backend/Centron.BL/NexusNotifications/` | System- und Benutzerbenachrichtigungen einschließlich Push in das Webportal |
+| M119 | Volltextsuche (Index-Suche) | `src/backend/Centron.BL/IndexSearch/` | Lucene-basierte Dokument- und Objektsuche mit deutschem Analyzer |
+| M120 | PDF-Signierung | `src/backend/Centron.BL/Security/PdfSigningBL.cs`, `src/centron/Centron.WPF.UI/Modules/Administration/PdfSigning/` | Digitale Signatur ausgehender PDF-Dokumente |
+| M121 | Profiling/Performance | `src/backend/Centron.BL/Administration/Profiling/`, `PerformanceTests/` | Laufzeitmessung und Performance-Diagnose |
+| M122 | Konfigurationsdatenbank | `src/backend/Centron.BL/Administration/CentronConfigDb/` | Getrennte Konfigurationsdatenbank, u. a. Hotline-Masterkey |
+| M123 | Dokumentenverwaltung | `src/backend/Centron.BL/Administration/Documents/`, `FileManagement/` | Ablage und Bereitstellung von Dokumenten zu Geschäftsobjekten |
+| M124 | Änderungsverfolgung | `src/backend/Centron.BL/ChangeTracking/` | Protokollierung von Feldänderungen an Geschäftsobjekten |
+| M125 | Netzwerkdiagnose | `src/backend/Centron.BL/Administration/NetworkDiagnostics/` | Diagnose der Verbindungen zwischen Client, Webservice und Datenbank |
+
+### Bereich K — Webportal c-entron Nexus
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M126 | Nexus ServiceBoard (Ticketliste/Kanban) | `src/nexus/CentronNexus/ServiceBoard/CachedTicketList/`, `Kanban/` | Webbasierte Ticketliste mit Kanban-Ansicht, Filtern und Bedingungsformatierung |
+| M127 | Nexus Ticketdetails & Zeiterfassung | `src/nexus/CentronNexus/ServiceBoard/TicketDetails/`, `Timerecords/`, `Stopwatches/` | Ticketbearbeitung und Zeiterfassung im Browser |
+| M128 | Nexus Kundenportal | `src/nexus/CentronNexus/WebCart/CustomerPortal*`, `src/backend/Centron.BL/WebSuite/` | Kundenzugang zu Tickets, Belegen und Dokumenten |
+| M129 | Nexus WebCart (Shop) | `src/nexus/CentronNexus/WebCart/WebCartShopPage.razor`, `WebCartCartPage.razor` | Webshop auf Basis der Kundensonderpreise |
+| M130 | Nexus WebOffer | `src/nexus/CentronNexus/WebOffer/` | Web-Freigabe und Annahme von Angeboten |
+| M131 | Nexus Dokumentensignatur | `src/nexus/CentronNexus/DocumentSigning/` | Unterschrift von Dokumenten im Browser (Signature Pad) |
+| M132 | Nexus Office / geteilte Dokumente | `src/nexus/CentronNexus/Office/` | Bereitstellung, Annahme und Signatur geteilter Dokumente |
+| M133 | Nexus Taskmanagement | `src/nexus/CentronNexus/Management/TaskManagement/` | Aufgabenverwaltung im Webportal |
+| M134 | Nexus Ticketvorlagen | `src/nexus/CentronNexus/Management/TicketPatterns/` | Pflege von C-FLOW-Ticketvorlagen inklusive Formularen und Skripten |
+| M135 | Nexus WebAccount-Verwaltung | `src/nexus/CentronNexus/Management/WebAccount/`, `src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs` | Anlage und Berechtigung von Kundenzugängen |
+| M136 | Nexus Produktionsaufträge | `src/nexus/CentronNexus/ProductionOrderManagement/` | Weboberfläche für Produktionsaufträge und Arbeitsschritte |
+| M137 | Nexus Einstellungen & Branding | `src/nexus/CentronNexus/Settings/`, `docker/compose/appsettings.Production.json` | Mandantenspezifisches Erscheinungsbild und Portaleinstellungen |
+| M138 | Outlook Add-In | `src/nexus/CentronNexus.OutlookAddIn/` | Zugriff auf Tickets, Kunden, Belege und Dokumente aus Outlook |
+| M139 | SelfCare-Formulare | `src/backend/Centron.BL/SelfCare/`, `src/webservice/Centron.Controllers/Controllers/v1/SelfCare/` | Kundenformulare mit Zuständen, Auslösern und Aktionen |
+| M140 | Nexus Ticket-Cache | `src/nexus/CentronNexus/Shared/Services/TicketCacheBackgroundService.cs` | Vorhalten von Ticketdaten für schnelle Listenansichten |
+
+### Bereich L — Dienste und Schnittstellen
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M141 | Legacy REST-Webservice | `src/webservice/Centron.WebServices.Core/`, `src/backend/Centron.Interfaces/` | Historisch gewachsene REST-Schnittstelle für c-entron.NET und Partneranwendungen |
+| M142 | Moderne REST-API v1 | `src/webservice/Centron.Controllers/Controllers/v1/` | Versionierte ASP.NET-Core-API (42 Controller) |
+| M143 | Authentifizierung & Ticketverwaltung | `src/backend/Centron.BL/Administration/Logins/Auth/`, `TicketBL.cs` | Anmeldung über Basis-, Active-Directory-, OpenID-Connect- und WebAccount-Verfahren; Sitzungstickets |
+| M144 | Zwei-Faktor-Authentifizierung | `src/backend/Centron.BL/Administration/Logins/TwoFactor/` | Zweiter Faktor über RADIUS-Server oder E-Mail-Link |
+| M145 | Hosts (Konsole/Windows-Dienst) | `src/webservice/Centron.Host/`, `Centron.Host.Console/`, `Centron.Host.WindowsService/` | Betriebsvarianten des Webservice |
+| M146 | Connection Manager | `src/webservice/c-entron.misc.ConnectionManager/` | Werkzeug zur Konfiguration und zum Test von Verbindungen |
+| M147 | Hintergrunddienste | `src/backend/Centron.BL/Administration/BackgroundServices/`, `src/webservice/Centron.Host/AspNetCore/HostedServices/`, `docs/Background Service/DataQualityService.md` | Zyklische Wartungs-, Datenqualitäts- und Benachrichtigungsaufgaben |
+| M148 | Mailversand und MailScanner | `src/backend/Centron.BL/Mail/`, `MailScanner/MailScannerBL.cs` | Versand von Systemmails und Einlesen eingehender Mails in Tickets |
+| M149 | Chat | `src/backend/Centron.BL/Chats/ChatBL.cs` | Interne Kurznachrichten zwischen Mitarbeitern |
+| M150 | Mobile-Schnittstelle | `src/backend/Centron.BL/Mobile/MobileBL.cs` | Datenbereitstellung für mobile Anwendungen |
+
+### Bereich M — Externe Systemanbindungen
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M151 | Artikeldaten-Provider | `src/apis/Centron.APIs.CopDataAccess/`, `EgisDataAccess/`, `ITscopeDataAccess/`, `IcecatDataAccess/` | Externe Artikel-, Preis- und Verfügbarkeitsrecherche |
+| M152 | finAPI (Online-Banking) | `src/apis/Centron.APIs.FinAPI/` | Abruf von Bankumsätzen |
+| M153 | ebInterface | `src/apis/Centron.Api.EbInterface/` | Österreichisches E-Rechnungsformat |
+| M154 | docuFORM | `Centron.Api.docuFORM/`, `src/backend/Centron.BL/DataExchange/DocuForm/` | REST-Anbindung an docuFORM für Gerätedaten |
+| M155 | RMM-/Fremdsystem-Konnektoren | `src/backend/Centron.BL/DataExchange/Rmm/`, `Connectors/`, `TanssInterfaces/`, `TelekomDive/` | Übernahme von Geräte-, Ticket- und Vertragsdaten aus Fremdsystemen |
+| M156 | EDI-Gateways | `src/backend/Centron.Gateway/EDI_Also/`, `EDI_Alltron/`, `EDI_Herweck/`, `EDI_Komsa/`, `OpenTrans/` | Lieferantenspezifische EDI-Formate |
+| M157 | ZUGFeRD/XRechnung | `src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs`, `src/backend/Centron.BL/EDI/Zugferd/` | Erzeugung und Einlesen strukturierter elektronischer Rechnungen |
+| M158 | GFK-Export | `src/backend/Centron.BL/DataExchange/GfkExport/` | Meldung von Absatzdaten an die GfK |
+| M159 | DocSync | `src/centron/Centron.WPF.UI/Modules/DataExchange/DocSync/` | Dokumentenabgleich mit externem Speicher (Alpha) |
+| M160 | Objektreferenzen zu Fremdsystemen | `src/backend/Centron.BL/ObjectExternalReferences/` | Zuordnung interner Objekte zu externen Identifikatoren |
+
+### Bereich N — Technische Basis
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M161 | Datenmodell | `src/backend/Centron.Entities/` | NHibernate-Entitäten in 88 Domänenordnern |
+| M162 | Datenzugriff | `src/backend/Centron.DAO/` | FluentNHibernate-Mappings, Repositories, Raw-SQL-Zugriff |
+| M163 | Datenbank-Skriptmotor | `src/backend/Centron.BL/Administration/Scripts/ScriptEngineBL.cs`, `ScriptMethods/Scripts/` | Versionierte Schemamigration über 790 nummerierte Skriptklassen |
+| M164 | Gemeinsame Steuerelemente | `src/shared/Centron.Controls/` | Wiederverwendbare WPF-Steuerelemente und Ansichten |
+| M165 | Kernbibliothek | `src/shared/Centron.Core/` | Guards, MVVM-Basis, TOTP, Threading, IO |
+| M166 | Ergebnis- und Fehlerbehandlung | `src/backend/Centron.Interfaces/Results/Result.cs` | Einheitliches `Result`/`Response`-Muster über alle Schichten |
+| M167 | Lokalisierung | `src/centron/Centron.WPF.UI/Localization/`, `*.resx`, `ResXManager.config.xml` | Deutsch als Basissprache, Englisch als Übersetzung |
+| M168 | Protokollierung | `nlog.config`, `docker/compose/appsettings.Production.json` | Anwendungsprotokolle in Datei und Konsole |
+
+### Bereich O — Betrieb und Auslieferung
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M169 | Container-Deployment | `docker/Dockerfile`, `docker/compose/compose.yaml`, `docker/deploy/` | Auslieferung von Webservice und Nexus als Linux-Container |
+| M170 | Webservice-Konfiguration | `docker/compose/WebServiceConfig.xml` | Zentrale Betriebsparameter des Webservice |
+| M171 | CI/CD-Pipelines | `azure/build-pipeline.yml`, `tests-pipeline.yml`, `docker-pipeline.yml`, `regression-tests-pipeline.yml` | Bau, Test, Signatur und Veröffentlichung |
+| M172 | Installer | `deployment/WixSharpInstaller/`, `deployment/centron/`, `deployment/riverbird/` | Windows-Installationspaket des Clients |
+| M173 | Buildkonfiguration | `Directory.Build.props`, `global.json`, `.editorconfig`, `nuget.config` | Verbindliche Compiler-, Versions- und Codierungsvorgaben |
+| M174 | Testinfrastruktur | `tests/` (Unit, Integration, EndToEnd, Playwright, Nexus, APIs) | Automatisierte Prüfung auf mehreren Ebenen |
+
+### Nachtrag zum Inventar (Ergänzung während der Vertiefung)
+
+Fünf Komponenten wurden erst bei der Vertiefung als eigenständige fachliche Module erkennbar. Das Inventar wird — wie in Schritt 0 vorgesehen — um sie **ergänzt**; gekürzt wurde nichts. Vier davon sind über keine Modulregistrierung erreichbar und daher bei der ersten Sichtung der Modulliste nicht aufgefallen.
+
+| ID | Bereich | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe | Grund der Nachtragung |
+|---|---|---|---|---|---|
+| M175 | J | Gutscheinverwaltung | `src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs`, `src/backend/Centron.Entities/Entities/VoucherManagement/` | Ausgabe, Einlösung und Standsführung von Gutscheinen | eigenständige Geschäftslogik ohne Modul- oder Einstellungsanbindung |
+| M176 | F | IT-Planer (Prüfobjektkategorien) | `src/backend/Centron.BL/ItPlanner/ChecklistVirtualObjectCategoryBL.cs`, `src/backend/Centron.Entities/Entities/ItPlanner/` | Gliederung virtueller Prüfobjekte für Checklisten | eigener Domänenbereich ohne Modulanbindung |
+| M177 | L | Riverbird-/RiverSuite-Kopplung | `src/backend/Centron.BL/RiverDivo/`, `deployment/riverbird/`, `nugets/RiverbirdPortal.*.nupkg`, `RiverSuiteRelevantRight` | geteilte Bausteine und gesonderte Rechteauswahl für das Schwesterprodukt | über mehrere Verzeichnisse verteilt, keine eigene Modulregistrierung |
+| M178 | A | DocuBoard / IT-Bestandserfassung | `src/backend/Centron.BL/DocuBoard/`, `src/backend/Centron.Entities/Entities/DocuBoard/`, Tabellen `AssetManagement*` | Erfassung von Kundensystemen, Ordnerberechtigungen, Verzeichnisbenutzern und SNMP-Geräten | drei Geschäftslogikbausteine ohne Modulanbindung |
+| M179 | N | Anwendungsrahmen und Modulregistrierung | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, `ModuleRightsExpressionParser.cs`, `CentronModule.cs`, `CentronApplication.cs`, `FrontWindow.xaml` | Aufbau der Modulliste aus Rechten, Lizenzen und Systemmerkmalen; Öffnen und Schließen von Modulen | querschnittliche Komponente, in der ersten Inventarisierung als Quelle, nicht als Modul geführt |
+
+**Umfang des Inventars nach der Ergänzung: 179 Module/Komponenten in 15 Bereichen.**
+
+---
+
+*Die Abschnitte 3 bis 7 (Abdeckungstabelle, Konsistenzcheck, Risikoliste, Hypothesenabgleich, Selbstbewertung) folgen unten und beziehen sich auf genau dieses Inventar einschließlich des Nachtrags.*
+
+---
+
+## 3. Abdeckungstabelle (Schritt 0b und 0c)
+
+Jede Zeile des Modulinventars aus Abschnitt 2 erscheint hier. Die Einstufung folgt der Zahl der aus dem Modul erzeugten Anforderungen:
+
+`tief` ≥ 8, `mittel` 3–7, `flach` 1–2, `nicht analysiert` 0.
+
+
+| Einstufung | Module | Anteil |
+|---|---|---|
+| tief | 9 | 5,0 % |
+| mittel | 108 | 60,3 % |
+| flach | 62 | 34,6 % |
+| nicht analysiert | 0 | 0 % |
+| **Summe** | **179** | **100 %** |
+
+### 3.1 Abdeckung je Modul
+
+| ID | Bereich | Modul | Einstufung | Anz. | Anforderungen |
+|---|---|---|---|---|---|
+| M01 | A | Belegwesen (Kundenbelege) | tief | 26 | StRS-001, StRS-014, SyRS-001, SyRS-002, SyRS-005, SyRS-006, SyRS-007, SyRS-008, SyRS-009, SyRS-070, SyRS-079, SyRS-190, SyRS-192, SyRS-198, SwRS-001, SwRS-003, SwRS-004, SwRS-005, SwRS-006, SwRS-007, SwRS-008, SwRS-009, SwRS-070, SwRS-071, SwRS-135, SwRS-191 |
+| M02 | A | Adressstamm / CRM | mittel | 3 | StRS-084, SyRS-173, SwRS-173 |
+| M03 | A | Adressen & Belege (Altmodul) | flach | 2 | StRS-084, SyRS-173 |
+| M04 | A | CRM-Projekte | flach | 1 | SyRS-210 |
+| M05 | A | Kampagnen/Mailing | mittel | 3 | StRS-081, SyRS-170, SwRS-170 |
+| M06 | A | Audit (Kundenaudits) | mittel | 3 | StRS-049, SyRS-127, SwRS-127 |
+| M07 | A | Stammblätter | mittel | 3 | StRS-051, SyRS-130, SwRS-130 |
+| M08 | A | PLM (Product Lifecycle Management) | mittel | 3 | StRS-082, SyRS-171, SwRS-171 |
+| M09 | A | Lieferanten-Verträge | mittel | 3 | StRS-083, SyRS-172, SwRS-172 |
+| M10 | A | Produktmatrix (Kundenmatrix) | mittel | 3 | StRS-085, SyRS-174, SwRS-174 |
+| M11 | A | Video-Portal | mittel | 3 | StRS-058, SyRS-137, SwRS-137 |
+| M12 | A | Geräteverwaltung (Kundengeräte) | mittel | 3 | StRS-051, StRS-100, SyRS-130 |
+| M13 | B | Verträge (Belegart Vertrag) | mittel | 5 | StRS-096, StRS-097, SyRS-066, SyRS-212, SwRS-064 |
+| M14 | B | Vertragsabrechnung | mittel | 7 | StRS-011, SyRS-060, SyRS-061, SyRS-067, SyRS-068, SwRS-060, SwRS-061 |
+| M15 | B | Pauschalabrechnung | flach | 1 | SyRS-211 |
+| M16 | B | Vereinfachte Ticketabrechnung | mittel | 3 | StRS-010, SyRS-053, SwRS-051 |
+| M17 | B | Vertragsarten | flach | 1 | SyRS-212 |
+| M18 | B | Klick-Zählerverwaltung | mittel | 4 | StRS-013, SyRS-064, SyRS-065, SwRS-063 |
+| M19 | B | Statischer Datenimport – Verträge | flach | 1 | SyRS-213 |
+| M20 | B | Dynamischer Datenimport – Verträge | flach | 1 | SyRS-214 |
+| M21 | B | Vertragsauswertung | flach | 2 | StRS-027, SyRS-090 |
+| M22 | B | Provisionsauswertung | flach | 1 | SyRS-017 |
+| M23 | B | Provisionsschemas verwalten | flach | 1 | SyRS-017 |
+| M24 | B | Provisionsschema-Kundenzuordnung | flach | 1 | SyRS-017 |
+| M25 | B | Leasing/Service | flach | 1 | SyRS-215 |
+| M26 | B | Aufschläge Stundensätze | flach | 1 | SyRS-216 |
+| M27 | B | Kontingentverwaltung | mittel | 4 | StRS-012, SyRS-062, SyRS-063, SwRS-062 |
+| M28 | C | Mahnwesen | mittel | 3 | StRS-016, SyRS-073, SwRS-072 |
+| M29 | C | OPOS | flach | 1 | SyRS-217 |
+| M30 | C | Zahlungseingang | flach | 1 | SyRS-218 |
+| M31 | C | SEPA-Zahlungsverkehr | mittel | 4 | StRS-017, SyRS-074, SyRS-075, SwRS-073 |
+| M32 | C | Buchhaltungsexport/-import | mittel | 3 | StRS-019, SyRS-078, SwRS-076 |
+| M33 | C | DATEV Belegtransfer | flach | 1 | StRS-019 |
+| M34 | C | Kontenrahmen | mittel | 3 | StRS-088, SyRS-177, SwRS-177 |
+| M35 | C | Mehrwertsteuerverwaltung | mittel | 4 | StRS-015, SyRS-071, SyRS-072, SwRS-071 |
+| M36 | C | Kostenträger/Kostenstellen | mittel | 3 | StRS-086, SyRS-175, SwRS-175 |
+| M37 | C | Belegkonditionen | mittel | 3 | StRS-061, SyRS-140, SwRS-140 |
+| M38 | C | Kalkulation pro Filiale | flach | 1 | SyRS-219 |
+| M39 | C | Online-Banking (Kontoauszüge) | mittel | 3 | StRS-062, SyRS-141, SwRS-141 |
+| M40 | C | SEPA-Lastschriftmandate | flach | 2 | StRS-017, SyRS-075 |
+| M41 | D | Lieferantenbelegwesen | flach | 1 | SyRS-220 |
+| M42 | D | Belegerfassung (Kosten) | flach | 1 | SyRS-221 |
+| M43 | D | Bestellvorschlagsliste | mittel | 3 | StRS-024, SyRS-085, SwRS-084 |
+| M44 | D | EDI-Verwaltung | mittel | 4 | StRS-025, SyRS-086, SyRS-087, SwRS-085 |
+| M45 | D | Eingang/Kalkulation | flach | 1 | SyRS-222 |
+| M46 | D | TradePool | mittel | 3 | StRS-090, SyRS-179, SwRS-179 |
+| M47 | E | Artikelverwaltung | mittel | 4 | StRS-020, SyRS-080, SyRS-081, SwRS-080 |
+| M48 | E | Artikelimport | flach | 1 | SyRS-223 |
+| M49 | E | Warengruppenverwaltung | flach | 1 | SyRS-224 |
+| M50 | E | Lager- und Bestandsführung | mittel | 4 | SyRS-080, SyRS-081, SyRS-083, SwRS-080 |
+| M51 | E | Inventur | mittel | 3 | StRS-023, SyRS-084, SwRS-083 |
+| M52 | E | Kommissionierung | mittel | 3 | StRS-022, SyRS-083, SwRS-082 |
+| M53 | E | Barcode-/Seriennummernverwaltung | mittel | 3 | StRS-021, SyRS-082, SwRS-081 |
+| M54 | E | Versandabwicklung | flach | 2 | SyRS-089, SwRS-087 |
+| M55 | E | Projektpreis-Import | flach | 1 | SyRS-225 |
+| M56 | E | Aktionspreise | flach | 1 | SyRS-226 |
+| M57 | E | Stücklisten / Teilelisten | flach | 1 | SyRS-227 |
+| M58 | F | Ticket-Liste / Helpdesk | tief | 10 | StRS-004, StRS-009, SyRS-012, SyRS-050, SyRS-051, SyRS-052, SyRS-054, SyRS-055, SwRS-050, SwRS-052 |
+| M59 | F | Ticketzeiterfassung | mittel | 4 | StRS-010, SyRS-053, SyRS-216, SwRS-051 |
+| M60 | F | Checklisten | mittel | 3 | StRS-053, SyRS-132, SwRS-132 |
+| M61 | F | Taskmanagement | mittel | 3 | StRS-055, SyRS-134, SwRS-134 |
+| M62 | F | RMA/Werkstatt | mittel | 3 | StRS-026, SyRS-088, SwRS-086 |
+| M63 | F | Ticketprozess-Vorlagen | mittel | 3 | StRS-054, SyRS-133, SwRS-133 |
+| M64 | F | Erwartete Events | mittel | 3 | StRS-050, SyRS-128, SwRS-128 |
+| M65 | F | Erwartete Events Auswertung | flach | 2 | SyRS-128, SwRS-128 |
+| M66 | F | Eskalationen | mittel | 3 | StRS-052, SyRS-131, SwRS-131 |
+| M67 | F | QM-Meldungen | mittel | 3 | StRS-056, SyRS-135, SwRS-135 |
+| M68 | F | Projektverwaltung (intern) | mittel | 3 | StRS-059, SyRS-138, SwRS-138 |
+| M69 | F | Ticketprojekte | flach | 1 | SyRS-228 |
+| M70 | F | Externer Helpdesk | mittel | 3 | SyRS-129, SwRS-129, SwRS-200 |
+| M71 | F | Reisekosten/Auslagen | mittel | 3 | StRS-060, SyRS-139, SwRS-139 |
+| M72 | G | Maschinenverwaltung | flach | 2 | StRS-057, SyRS-136 |
+| M73 | G | Produktionsaufträge | mittel | 3 | StRS-057, SyRS-136, SwRS-136 |
+| M74 | G | Artikelproduktion | flach | 1 | StRS-057 |
+| M75 | H | Analytics | mittel | 3 | StRS-027, SyRS-090, SwRS-090 |
+| M76 | H | Management Info | flach | 2 | StRS-027, SyRS-090 |
+| M77 | H | Leistungsnachweise | flach | 1 | SyRS-229 |
+| M78 | H | Mitarbeiterauslastung | mittel | 4 | StRS-029, SyRS-092, SyRS-229, SwRS-092 |
+| M79 | H | MSP-Collector | mittel | 3 | StRS-028, SyRS-091, SwRS-091 |
+| M80 | H | MSP-Auswertung | flach | 2 | StRS-028, SyRS-091 |
+| M81 | H | MSP-Dashboard | flach | 2 | StRS-028, SyRS-091 |
+| M82 | H | Telemetrie | flach | 2 | SyRS-093, SwRS-093 |
+| M83 | H | Statistikbasis | flach | 2 | SyRS-094, SwRS-090 |
+| M84 | I | Dashboard | flach | 1 | SyRS-230 |
+| M85 | I | Mein Tag | mittel | 3 | StRS-029, SyRS-092, SwRS-092 |
+| M86 | I | Monatsübersicht | flach | 1 | SyRS-231 |
+| M87 | I | Todo-Liste | flach | 2 | SyRS-134, SwRS-134 |
+| M88 | I | Telefonate / TAPI | mittel | 3 | StRS-047, SyRS-125, SwRS-125 |
+| M89 | I | Kalender & Termine | mittel | 6 | StRS-045, StRS-046, SyRS-123, SyRS-124, SwRS-123, SwRS-124 |
+| M90 | I | AI-Chat | mittel | 3 | StRS-048, SyRS-126, SwRS-126 |
+| M91 | I | Persönliche Einstellungen | flach | 2 | SyRS-019, SyRS-125 |
+| M92 | I | Terminanfragen | flach | 1 | SyRS-232 |
+| M93 | J | Einstellungsverwaltung | mittel | 4 | SyRS-018, SyRS-019, SwRS-020, SwRS-184 |
+| M94 | J | Mitarbeiterverwaltung | mittel | 5 | StRS-006, StRS-098, SyRS-030, SyRS-031, SwRS-030 |
+| M95 | J | Rechteverwaltung | tief | 12 | StRS-003, StRS-004, SyRS-010, SyRS-011, SyRS-012, SyRS-013, SyRS-014, SyRS-015, SyRS-200, SwRS-010, SwRS-011, SwRS-012 |
+| M96 | J | Mandantenverwaltung | mittel | 7 | StRS-002, SyRS-003, SyRS-004, SyRS-190, SyRS-199, SwRS-002, SwRS-191 |
+| M97 | J | Filialverwaltung | mittel | 4 | StRS-002, SyRS-003, SyRS-012, SyRS-219 |
+| M98 | J | Länderverwaltung | mittel | 3 | StRS-087, SyRS-176, SwRS-176 |
+| M99 | J | Mailvorlagen | mittel | 3 | StRS-036, SyRS-114, SwRS-114 |
+| M100 | J | Textbausteine | mittel | 3 | StRS-036, SyRS-114, SwRS-114 |
+| M101 | J | Report-Engine | mittel | 3 | StRS-032, SyRS-110, SwRS-110 |
+| M102 | J | Reportserver | mittel | 3 | StRS-033, SyRS-111, SwRS-111 |
+| M103 | J | c-entron DSGVO | mittel | 5 | StRS-030, SyRS-100, SyRS-101, SyRS-195, SwRS-100 |
+| M104 | J | Auftragsverarbeitungsvertrag | flach | 1 | StRS-030 |
+| M105 | J | SQL-Manager | mittel | 3 | StRS-077, SyRS-158, SwRS-158 |
+| M106 | J | c-entron Logs | mittel | 3 | StRS-078, SyRS-159, SwRS-159 |
+| M107 | J | c-entron Inspektor | flach | 2 | StRS-077, SyRS-022 |
+| M108 | J | Data Updater (Massenupdate) | mittel | 3 | StRS-034, SyRS-112, SwRS-112 |
+| M109 | J | API-Zugriffstoken | mittel | 4 | StRS-076, SyRS-156, SyRS-157, SwRS-157 |
+| M110 | J | Lizenzverwaltung | tief | 10 | StRS-005, StRS-074, StRS-075, SyRS-020, SyRS-021, SyRS-138, SyRS-155, SwRS-020, SwRS-021, SwRS-156 |
+| M111 | J | Zusatzfelder (Custom Properties) | mittel | 3 | StRS-035, SyRS-113, SwRS-113 |
+| M112 | J | Passwort-Manager (Zugänge) | mittel | 5 | StRS-031, SyRS-102, SyRS-148, SwRS-101, SwRS-148 |
+| M113 | J | Passwort-Manager Richtlinien | flach | 1 | SyRS-233 |
+| M114 | J | Passwort-Manager Zugangsbereiche | flach | 1 | SyRS-234 |
+| M115 | J | Fernzugriff (RDP/SSH) | mittel | 3 | StRS-069, SyRS-148, SwRS-148 |
+| M116 | J | Externe Tools | mittel | 3 | StRS-068, SyRS-147, SwRS-147 |
+| M117 | J | Update-Benachrichtigung | flach | 1 | SyRS-235 |
+| M118 | J | Benachrichtigungen | mittel | 3 | StRS-066, SyRS-145, SwRS-145 |
+| M119 | J | Volltextsuche (Index-Suche) | mittel | 3 | StRS-037, SyRS-115, SwRS-115 |
+| M120 | J | PDF-Signierung | mittel | 4 | StRS-038, SyRS-116, SwRS-116, SwRS-117 |
+| M121 | J | Profiling/Performance | flach | 2 | StRS-079, SyRS-196 |
+| M122 | J | Konfigurationsdatenbank | flach | 2 | SyRS-102, SwRS-101 |
+| M123 | J | Dokumentenverwaltung | mittel | 3 | StRS-037, SyRS-115, SyRS-117 |
+| M124 | J | Änderungsverfolgung | mittel | 5 | StRS-080, SyRS-161, SyRS-191, SwRS-161, SwRS-162 |
+| M125 | J | Netzwerkdiagnose | mittel | 3 | StRS-079, SyRS-160, SwRS-160 |
+| M126 | K | Nexus ServiceBoard (Ticketliste/Kanban) | mittel | 4 | SyRS-041, SyRS-054, SwRS-041, SwRS-053 |
+| M127 | K | Nexus Ticketdetails & Zeiterfassung | flach | 1 | SyRS-236 |
+| M128 | K | Nexus Kundenportal | tief | 9 | StRS-008, SyRS-040, SyRS-041, SyRS-042, SyRS-043, SyRS-118, SwRS-040, SwRS-041, SwRS-042 |
+| M129 | K | Nexus WebCart (Shop) | mittel | 3 | StRS-040, SyRS-118, SwRS-118 |
+| M130 | K | Nexus WebOffer | mittel | 3 | StRS-041, SyRS-119, SwRS-119 |
+| M131 | K | Nexus Dokumentensignatur | mittel | 3 | StRS-039, SyRS-117, SwRS-117 |
+| M132 | K | Nexus Office / geteilte Dokumente | flach | 2 | SyRS-117, SwRS-117 |
+| M133 | K | Nexus Taskmanagement | flach | 2 | SyRS-134, SwRS-134 |
+| M134 | K | Nexus Ticketvorlagen | flach | 2 | SyRS-133, SwRS-133 |
+| M135 | K | Nexus WebAccount-Verwaltung | mittel | 3 | SyRS-014, SyRS-042, SwRS-040 |
+| M136 | K | Nexus Produktionsaufträge | flach | 2 | SyRS-136, SwRS-136 |
+| M137 | K | Nexus Einstellungen & Branding | mittel | 5 | StRS-092, SyRS-181, SyRS-198, SwRS-118, SwRS-181 |
+| M138 | K | Outlook Add-In | mittel | 3 | StRS-043, SyRS-121, SwRS-121 |
+| M139 | K | SelfCare-Formulare | mittel | 3 | StRS-042, SyRS-120, SwRS-120 |
+| M140 | K | Nexus Ticket-Cache | flach | 2 | SyRS-196, SwRS-053 |
+| M141 | L | Legacy REST-Webservice | mittel | 4 | StRS-071, SyRS-030, SyRS-151, SwRS-151 |
+| M142 | L | Moderne REST-API v1 | mittel | 4 | SyRS-143, SyRS-157, SwRS-143, SwRS-157 |
+| M143 | L | Authentifizierung & Ticketverwaltung | tief | 14 | StRS-006, SyRS-030, SyRS-034, SyRS-035, SyRS-036, SyRS-037, SyRS-038, SyRS-039, SyRS-178, SwRS-030, SwRS-032, SwRS-033, SwRS-034, SwRS-178 |
+| M144 | L | Zwei-Faktor-Authentifizierung | mittel | 4 | StRS-007, SyRS-032, SyRS-033, SwRS-031 |
+| M145 | L | Hosts (Konsole/Windows-Dienst) | mittel | 4 | StRS-071, StRS-072, SyRS-152, SwRS-152 |
+| M146 | L | Connection Manager | flach | 1 | SyRS-237 |
+| M147 | L | Hintergrunddienste | mittel | 3 | SyRS-160, SwRS-053, SwRS-160 |
+| M148 | L | Mailversand und MailScanner | mittel | 4 | StRS-044, SyRS-122, SwRS-035, SwRS-122 |
+| M149 | L | Chat | mittel | 3 | StRS-067, SyRS-146, SwRS-146 |
+| M150 | L | Mobile-Schnittstelle | mittel | 3 | StRS-089, SyRS-178, SwRS-178 |
+| M151 | M | Artikeldaten-Provider (COP/EGIS/ITscope/Icecat) | mittel | 3 | StRS-063, SyRS-142, SwRS-142 |
+| M152 | M | finAPI (Online-Banking) | mittel | 3 | StRS-062, SyRS-141, SwRS-141 |
+| M153 | M | ebInterface | flach | 1 | SwRS-075 |
+| M154 | M | docuFORM | flach | 2 | SyRS-143, SyRS-204 |
+| M155 | M | RMM-/Fremdsystem-Konnektoren | mittel | 3 | StRS-064, SyRS-143, SwRS-143 |
+| M156 | M | EDI-Gateways | mittel | 4 | StRS-025, SyRS-086, SyRS-202, SwRS-085 |
+| M157 | M | ZUGFeRD/XRechnung | mittel | 5 | StRS-018, SyRS-076, SyRS-077, SwRS-074, SwRS-075 |
+| M158 | M | GFK-Export | mittel | 3 | StRS-065, SyRS-144, SwRS-144 |
+| M159 | M | DocSync | mittel | 3 | StRS-095, SyRS-184, SwRS-184 |
+| M160 | M | Objektreferenzen zu Fremdsystemen | mittel | 3 | StRS-091, SyRS-180, SwRS-180 |
+| M161 | N | Datenmodell (Centron.Entities) | mittel | 6 | SyRS-161, SyRS-205, SwRS-014, SwRS-015, SwRS-161, SwRS-190 |
+| M162 | N | Datenzugriff (Centron.DAO) | tief | 8 | SwRS-007, SwRS-008, SwRS-009, SwRS-014, SwRS-018, SwRS-019, SwRS-022, SwRS-197 |
+| M163 | N | Datenbank-Skriptmotor | tief | 8 | StRS-073, SyRS-153, SyRS-154, SwRS-153, SwRS-154, SwRS-155, SwRS-196, SwRS-199 |
+| M164 | N | Gemeinsame Steuerelemente | mittel | 4 | SyRS-198, SwRS-017, SwRS-164, SwRS-198 |
+| M165 | N | Kernbibliothek (Centron.Core) | mittel | 3 | SwRS-023, SwRS-165, SwRS-197 |
+| M166 | N | Ergebnis- und Fehlerbehandlung | flach | 2 | SwRS-016, SwRS-135 |
+| M167 | N | Lokalisierung | mittel | 4 | StRS-070, SyRS-150, SwRS-036, SwRS-150 |
+| M168 | N | Protokollierung | mittel | 4 | StRS-078, SyRS-159, SwRS-093, SwRS-159 |
+| M169 | O | Container-Deployment | mittel | 4 | StRS-072, SyRS-152, SyRS-197, SwRS-152 |
+| M170 | O | Webservice-Konfiguration | mittel | 5 | SyRS-181, SyRS-193, SyRS-194, SyRS-237, SwRS-181 |
+| M171 | O | CI/CD-Pipelines | mittel | 5 | StRS-094, SyRS-182, SyRS-183, SwRS-182, SwRS-183 |
+| M172 | O | Installer | mittel | 3 | StRS-093, SyRS-182, SwRS-182 |
+| M173 | O | Buildkonfiguration | mittel | 6 | SyRS-183, SwRS-036, SwRS-183, SwRS-192, SwRS-194, SwRS-195 |
+| M174 | O | Testinfrastruktur | mittel | 3 | SyRS-183, SwRS-163, SwRS-193 |
+| M175 | J | Gutscheinverwaltung | flach | 1 | StRS-099 |
+| M176 | F | IT-Planer (Prüfobjektkategorien) | flach | 1 | SyRS-203 |
+| M177 | L | Riverbird-/RiverSuite-Kopplung | flach | 1 | SyRS-201 |
+| M178 | A | DocuBoard / IT-Bestandserfassung | flach | 1 | StRS-100 |
+| M179 | N | Anwendungsrahmen und Modulregistrierung | tief | 10 | StRS-071, SyRS-016, SyRS-017, SyRS-018, SyRS-019, SyRS-022, SyRS-023, SyRS-151, SwRS-013, SwRS-020 |
+
+### 3.2 Anforderungen ohne Modulzuordnung
+
+Von 434 Anforderungen sind 434 in der Abdeckungstabelle einem Modul zugeordnet; 0 beschreiben modulübergreifende Sachverhalte (Architektur, Betrieb, Querschnitt) und sind bewusst keinem einzelnen Inventarmodul zugewiesen.
+
+---
+
+## 4. Konsistenzcheck über das gesamte Anforderungs-Set
+
+Der Check wurde maschinell über alle drei Spezifikationsdateien geführt (Zerlegung in Anforderungsblöcke, Auswertung der Pflichtfelder, Auflösung aller Tracelinks gegen die Menge vergebener IDs).
+
+| Prüfung | Ergebnis |
+|---|---|
+| Anforderungen gesamt | 434 (StRS 100, SyRS 190, SwRS 144) |
+| Doppelte oder mehrfach vergebene IDs | 0 |
+| Anforderungen ohne Beleg | 0 |
+| Anforderungen ohne `PRIMÄR`-Beleg | 0 |
+| Anforderungen ohne Angabe zur `Übernahmewürdigkeit` | 0 |
+| Anforderungen ohne Prüfidee | 0 |
+| Anforderungen ohne Tracelink | 0 |
+| Tracelinks auf nicht existierende IDs | 0 |
+| Anforderungen mit unzulässigem `Status` (weder `belegt` noch `HYPOTHESE`) | 0 |
+| Nicht-funktionale Anforderungen ohne `Qualitätsmerkmal` | 0 (von 48) |
+| SwRS-Anforderungen ohne Verweis auf eine SyRS-Anforderung | 0 |
+| SyRS-Anforderungen ohne Verweis auf eine StRS-Anforderung | 0 |
+| Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsvermerk | 0 — siehe Abschnitt 4.1 |
+
+Die beiden Traceability-Zeilen betreffen die Vorgabe „Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung; jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung". Bei der ersten Auswertung fehlte dieser Aufwärtsverweis bei 7 SyRS- und 13 SwRS-Anforderungen — durchgängig querschnittlichen technischen Anforderungen (Datenzugriffsmuster, Kodierungsvorgabe, Ergebnisobjekt, Eingangsprüfungen). Die Verweise wurden ergänzt; die Tabelle oben gibt den Endstand wieder.
+
+### 4.1 Deckungsgleiche Anforderungen
+
+Geprüft wurde, ob zwei Anforderungen denselben Sachverhalt beschreiben, ohne dass dies vermerkt ist. Anforderungen, die denselben Gegenstand aus Sicht verschiedener Ebenen beschreiben, sind ausdrücklich **kein** Konsolidierungsfall — sie sind über die Tracelinks verbunden (siehe `Traceability.md`).
+
+Als Konsolidierungskandidat vermerkt sind 86 Anforderungen (19,8 %). Sie benennen jeweils eine fachlich gleichartige Funktion in getrennten Implementierungen oder Datenhaltungen. Die gewichtigsten Fälle sind in Abschnitt 7.4 zusammengefasst.
+
+---
+
+## 5. Liste aller risikorelevanten Anforderungen
+
+Risikorelevant sind gemäß Vorgabe Anforderungen zu **Sicherheitsregeln, Abrechnungs- und Fakturierungslogik sowie Berechtigungen**. Die Auswahl erfolgte maschinell über den Anforderungstyp `Sicherheit` sowie über Schlüsselbegriffe in Titel, Aussage und Akteur (Abrechnung, Fakturierung, Rechnung, Provision, Preis, Kontingent, Zähler, Zahlung, SEPA, Mahnung, OPOS, Steuer, Gutschrift, Kredit, Recht, Berechtigung, Lizenz, Kennwort, Anmeldung, Authentifizierung, Token, Verschlüsselung, Signatur, DSGVO, Mandant, Zugang, Zwei-Faktor).
+
+**Ergebnis: 210 risikorelevante Anforderungen. Davon ohne `PRIMÄR`-Beleg und ohne `[HYPOTHESE]`-Kennzeichnung: 0.**
+
+Damit liegt kein Verstoß gegen die risikobasierte Priorisierung vor: Jede risikorelevante Anforderung führt entweder mindestens einen `PRIMÄR`-Beleg mit Angabe der durchsetzenden Stelle oder ist als `[HYPOTHESE]` gekennzeichnet.
+
+| ID | Titel | PRIMÄR-Beleg vorhanden | Status | Durchsetzende Stelle (erster PRIMÄR-Beleg) |
+|---|---|---|---|---|
+| StRS-001 | Durchgängige Belegkette vom Angebot bis zur Rechnung | ja | belegt | `src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptBase.cs` |
+| StRS-002 | Mehrmandantenfähigkeit mit Filialgliederung | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `UpdateReceiptNumber` (Zeilen 7264-7285) |
+| StRS-003 | Rollenbasierte Zugriffssteuerung über Rechtegruppen | ja | belegt | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `GetAllAppRightsFromUser` (Zeilen 651-666) |
+| StRS-004 | Einschränkende Rechte begrenzen die Sicht auf eigene Vorgänge oder die eigene Filiale | ja | belegt | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `GetShowHelpdeskRight` (Zeilen 268-289) |
+| StRS-005 | Funktionsumfang wird durch erworbene Lizenzen bestimmt | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, `DoRegisterCentronModules` (Zeilen 379-393) |
+| StRS-006 | Anmeldung erfordert ein aktives Mitarbeiter- und Benutzerkonto | ja | belegt | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, `ValidateAppUser` (Zeilen 157-218) |
+| StRS-007 | Zweiter Anmeldefaktor für Benutzer und Kundenzugänge | ja | belegt | `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`, Zeilen 62-70 |
+| StRS-008 | Kunden erhalten einen eigenen Selbstbedienungszugang | ja | belegt | `src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs`, `LoginWithWebAccount` (Zeilen 54-94) |
+| StRS-009 | Serviceanfragen werden als Tickets mit Zuständigkeit und Fälligkeit geführt | ja | belegt | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `CheckUserRigths` (Zeilen 418-465) |
+| StRS-010 | Erfasste Arbeitszeiten sind Grundlage der Leistungsabrechnung | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptItemTimerBL.cs` (2.111 Zeilen) |
+| StRS-011 | Wiederkehrende Leistungen werden über Verträge automatisiert abgerechnet | ja | belegt | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, `StoreBookedContingent` (Zeilen 1099-1116) |
+| StRS-012 | Vertragskontingente begrenzen und verrechnen erbrachte Leistungen | ja | belegt | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, Zeilen 1046-1051 |
+| StRS-013 | Nutzungsabhängige Abrechnung über Gerätezählerstände | ja | belegt | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, `GetCounterFreeCount` (Zeile 736) und `GetCounterScalePrices` (Zeile 750) |
+| StRS-014 | Kreditlimit des Kunden begrenzt das offene Belegvolumen | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CheckIfCustomerLimitIsReached` (Zeilen 8636-8683) |
+| StRS-015 | Umsatzsteuer wird belegabhängig und länderabhängig ausgewiesen | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CheckIfAllArticlePositionsHaveVatRate` (Zeilen 9573-9585) |
+| StRS-016 | Offene Forderungen werden gestuft angemahnt | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs`, Zeilen 207-230 |
+| StRS-017 | Lastschrifteinzug über SEPA-Dateien | ja | belegt | `src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs`, `GetInterfaceList` (Zeilen 56-66) |
+| StRS-018 | Elektronische Rechnungsstellung nach ZUGFeRD und XRechnung | ja | belegt | `src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs`, Zeile 951 |
+| StRS-020 | Artikelstamm als gemeinsame Grundlage von Verkauf, Einkauf und Lager | ja | belegt | `src/backend/Centron.BL/Warehousing/ArticleBL.cs` |
+| StRS-025 | Elektronischer Datenaustausch mit Distributoren | ja | belegt | `src/backend/Centron.BL/EDI/SupplierEDI/` mit den lieferantenspezifischen Partialklassen |
+| StRS-027 | Kennzahlen für die Unternehmenssteuerung | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 212-249 (Region „Controlling/Analytics") |
+| StRS-028 | Nutzungsdaten aus Managed-Service-Systemen fließen in Auswertung und Abrechnung | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 232-244 |
+| StRS-029 | Mitarbeiter dokumentieren ihren Arbeitstag | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 361-363 (ohne Rechteprüfung) und 227-229 (`Helper.HasAnyRight(UserRightsConst.RIGHT_FREMDAUSLASTUNG)`) |
+| StRS-030 | Betroffenenrechte nach DSGVO werden im System unterstützt | ja | belegt | `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs`, `DsgvoDeleteRightDeleteContacts` (ab Zeile 787) und `DsgvoDeleteRightGetContacts` (ab Zeile 377) |
+| StRS-031 | Zugangsdaten von Kunden werden verschlüsselt verwahrt | ja | belegt | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeile 700 |
+| StRS-034 | Massenänderungen an Stammdaten sind kontrolliert möglich | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 424-426 |
+| StRS-038 | Ausgehende PDF-Dokumente können digital signiert werden | ja | belegt | `src/backend/Centron.BL/Security/PdfSigningBL.cs` |
+| StRS-040 | Kunden bestellen über einen Webshop zu ihren Sonderpreisen | ja | belegt | `src/backend/Centron.BL/Administration/Logins/WebRightsVisibility.cs`, Einträge 62001/62002 und Kategorie 6500 |
+| StRS-048 | KI-gestützte Unterstützung im ERP-Kontext | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 376-378 |
+| StRS-051 | Kundengeräte werden als Stammblatt und als Gerät doppelt geführt | ja | belegt | `src/backend/Centron.Entities/Entities/Sales/Receipts/MasterDataLists/MasterDataList.cs`, Zeilen 9-28 |
+| StRS-054 | Ticketvorlagen steuern wiederkehrende Serviceprozesse | ja | belegt | `src/nexus/CentronNexus/Management/TicketPatterns/Components/` mit `TicketPatternChecklistsTab.razor`, `TicketPatternFormsTab.razor`, `TicketPatternMailTemplateTab.razor`, `TicketPatternScriptsTab.razor` |
+| StRS-056 | Qualitätsrelevante Vorfälle werden als QM-Meldung erfasst | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CheckIfAssetReasonIsNeeded` (Zeilen 8823-8857) |
+| StRS-057 | Produktionsaufträge steuern die Eigenfertigung | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 405-412 |
+| StRS-060 | Reisekostenabrechnung ist vorbereitet, aber nicht freigegeben | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 904-906 |
+| StRS-061 | Kunden- und Lieferantenkonditionen steuern Preise und Zahlungsziele | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `UpdateConditionTextsAndCheckMinPrices` (Zeilen 8883-8960) |
+| StRS-062 | Bankumsätze werden Rechnungen automatisch zugeordnet | ja | belegt | `src/apis/Centron.APIs.FinAPI/FinApiClient.cs` und `src/backend/Centron.BL/Finances/OnlineBanking/` |
+| StRS-063 | Externe Artikeldaten ergänzen den eigenen Artikelstamm | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ArticleSearch/ITscopeExternalArticleSearchProvider.cs`, Zeile 210 (`VatRate = taxRate.TaxRate`) und `CopApiBaseExternalArticleSearchProvider.cs`, Zeile 147 |
+| StRS-064 | Gerätedaten aus Fremdsystemen fließen in Vertrag und Abrechnung | ja | belegt | `src/webservice/Centron.Controllers/Controllers/v1/Integrations/RmmController.cs` und `.../DataExchange/DocBeeTicketTimersController.cs` |
+| StRS-069 | Fernzugriff auf Kundensysteme aus der Anwendung | ja | belegt | `src/centron/Centron.WPF.UI/Modules/PasswordManager/RDPEmbeddedAppModuleController.cs` und `SSHEmbeddedAppModuleController.cs` |
+| StRS-074 | Lizenzprüfung schützt vor Schemaänderungen ohne gültige Lizenz | ja | belegt | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, `LoadLicenses` (Zeilen 219-236) |
+| StRS-075 | Gleichzeitige Nutzung wird durch die Lizenzanzahl begrenzt | ja | belegt | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, Zeilen 276-284 |
+| StRS-076 | Programmatischer Zugriff über persönliche und systemweite API-Token | ja | belegt | `src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs`, `GenerateSecureToken` (Zeilen 457-474) und `HashToken` (Zeilen 478-487) |
+| StRS-077 | Administrative Direktzugriffe auf die Datenbank sind gesondert berechtigt | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 323-325 |
+| StRS-079 | Systemzustand und Verbindungen sind diagnostizierbar | ja | belegt | `src/backend/Centron.BL/Administration/Logins/TicketBL.cs`, `GetAllTickets` (Zeilen 183-202) |
+| StRS-080 | Änderungen an Geschäftsobjekten sind nachvollziehbar | ja | belegt | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, Zeilen 186, 205, 226, 245, 368 |
+| StRS-082 | Lebenszyklus von Kundenprodukten und Lizenzen wird überwacht | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 136-138 |
+| StRS-086 | Kostenstellen und Kostenträger für die interne Verrechnung | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 3723-3724 |
+| StRS-087 | Länderabhängige Steuersätze, Währungen und Formate | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `UpdateCurrencyFactor` (Zeilen 8359-8370) |
+| StRS-089 | Mobile Nutzung über eine eigene Schnittstelle | ja | belegt | `src/backend/Centron.BL/Mobile/MobileBL.cs` |
+| StRS-090 | Handelsplattform-Anbindung für Artikel- und Preisdaten | ja | belegt | `src/backend/Centron.BL/TradePool/TradePoolBL.cs` |
+| StRS-092 | Erscheinungsbild des Kundenportals ist mandantenspezifisch anpassbar | ja | belegt | `docker/compose/appsettings.Production.json`, Abschnitt `Branding` |
+| StRS-098 | [HYPOTHESE] Kennwörter müssen nach einer festgelegten Frist gewechselt werden | ja | HYPOTHESE | `src/backend/Centron.BL/Administration/Logins/UsersBL.cs`, Zeilen 123-129 |
+| StRS-100 | [HYPOTHESE] Kunden-IT-Bestände werden über ein Asset Management erfasst | ja | HYPOTHESE | `src/backend/Centron.BL/DocuBoard/AssetManagementPartnerBL.cs`, `AssetManagementArticleAssignmentBL.cs`, `AssetManagementADSystemUserExclusionBL.cs` |
+| SyRS-006 | Zahlungskondition kann einen neuen Beleg unmittelbar abschließen | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `UpdateReceiptStateFromPaymentCondition` (Zeilen 8336-8357) |
+| SyRS-010 | Rechteermittlung erfolgt zwischengespeichert je Benutzer | ja | belegt | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `HasUserRight` (Zeilen 644-650) |
+| SyRS-011 | Rechteänderungen werden protokolliert | ja | belegt | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, Zeilen 186, 205, 226, 245, 368, 401 |
+| SyRS-012 | Rechteverwaltung kann auf die eigene Filiale beschränkt werden | ja | belegt | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `SaveRightGroup` (Zeilen 391-393) |
+| SyRS-013 | Die Administratorengruppe ist gegen Löschung geschützt | ja | belegt | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, Zeilen 359-360 |
+| SyRS-014 | Rechte für Kundenzugänge stammen aus einer abschließenden Positivliste | ja | belegt | `src/backend/Centron.BL/Administration/Logins/WebRightsVisibility.cs`, Zeilen 10-38 und 51-58 |
+| SyRS-015 | Rechteprüfung wirkt in Geschäftslogik und Oberfläche getrennt | ja | belegt | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `CheckUserRigths` (Zeilen 418-465) |
+| SyRS-016 | Modulrechte werden aus einem Ausdrucksbaum ausgewertet | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 502-532 |
+| SyRS-017 | Ein Modul kann durch ein Recht auch ausgeschlossen werden | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 430-438 |
+| SyRS-018 | Einstellungsseiten ohne Lizenz werden aus der Liste entfernt | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 397-404 |
+| SyRS-019 | Persönliche Einstellungen werden rechte- und lizenzabhängig zusammengestellt | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, `GetPersonalSettings` (Zeilen 233-263) |
+| SyRS-020 | Lizenzprüfung berücksichtigt Zusatz- und Kundenanmeldelizenzen | ja | belegt | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, Zeilen 263-301 |
+| SyRS-021 | Versionsnummern der Vorgängergeneration werden bei der Lizenzprüfung ersetzt | ja | belegt | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, `TryFixCentronDelphiVersionNumber` (Zeilen 304-330) |
+| SyRS-022 | Modulfreigabe kennt drei Sonderfälle über Systemmerkmale | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 371-373 |
+| SyRS-023 | Fehler bei der Modulregistrierung brechen die Anmeldung nicht ab | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, `RegisterModules` (Zeilen 200-212) |
+| SyRS-030 | Anmeldeverfahren werden über eine Fabrik ausgewählt | ja | belegt | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeilen 94-155 |
+| SyRS-031 | Kennwörter werden als ungesalzener SHA-1-Hash gespeichert | ja | belegt | `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`, Zeilen 46-50 |
+| SyRS-032 | Zweiter Faktor kann über RADIUS oder E-Mail-Bestätigung erbracht werden | ja | belegt | `src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs`, Zeilen 183-193 |
+| SyRS-033 | Der zweite Faktor gilt tageweise je Anwendung, Gerät und IP-Adresse | ja | belegt | `src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs`, `HasToValidateTwoFactor` (Zeilen 82-135) |
+| SyRS-034 | Anmeldung über Active Directory | ja | belegt | `src/backend/Centron.BL/Administration/Logins/Auth/ActiveDirectoryAuthenticator.cs` |
+| SyRS-035 | Anmeldung über OpenID Connect mit Kontoverknüpfung | ja | belegt | `src/webservice/Centron.Controllers/Controllers/Unversioned/JwtAuthController.cs`, `ConnectAccounts` (Zeilen 82-105) |
+| SyRS-036 | Sitzungstickets laufen anwendungsabhängig ab | ja | belegt | `src/backend/Centron.BL/Administration/Logins/TicketBL.cs`, `GetExpireDate` (Zeilen 136-164) |
+| SyRS-037 | Ein Sitzungsticket wird je Benutzer, Anwendung und Gerät wiederverwendet | ja | belegt | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeilen 124-129 |
+| SyRS-038 | Anmeldezeitpunkt, Gerät und IP-Adresse werden festgehalten | ja | belegt | `src/backend/Centron.BL/Administration/Logins/TicketBL.cs`, `SetLoginIP` (Zeilen 49-59) |
+| SyRS-039 | Fehlgeschlagene Anmeldungen werden protokolliert, sperren das Konto aber nicht | ja | HYPOTHESE | `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`, Zeile 55 |
+| SyRS-040 | Kundenzugänge werden über einen technischen Sammelbenutzer abgebildet | ja | belegt | `src/backend/Centron.BL/Administration/Logins/Auth/WebAccountAuthenticator.cs`, Zeilen 37-40 |
+| SyRS-041 | Kundendaten werden im Portal serverseitig auf den eigenen Kunden eingegrenzt | ja | belegt | `src/nexus/CentronNexus/Shared/Auth/TicketFilterService.cs`, Zeilen 32-62 |
+| SyRS-042 | Kundenzugänge kennen eine Administratorrolle | ja | belegt | `src/backend/Centron.BL/Administration/Logins/WebRightsVisibility.cs`, Zeile 16 (`31005, // Ist Kundenadministrator`) und Zeilen 20-27 |
+| SyRS-043 | Kundenportal und internes Portal können über getrennte Ports betrieben werden | ja | belegt | `src/nexus/CentronNexus/Shared/Authorization/PortAuthorization.cs` |
+| SyRS-050 | Ticketrechte werden bei jedem Speichern geprüft | ja | belegt | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, `CheckRights` (Zeilen 410-416) |
+| SyRS-052 | Ticketzuweisung kann auf die eigenen Abteilungen beschränkt werden | ja | belegt | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, Zeilen 454-463 |
+| SyRS-053 | Ticketzeiten mit Artikelbezug bilden die Abrechnungsgrundlage | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeile 3691 (`this.UpdateArticlePositionsHelpdeskTimerI3Ds(receipt);`) |
+| SyRS-054 | Tickets können als ausschließlich intern sichtbar gekennzeichnet werden | ja | belegt | `src/nexus/CentronNexus/Shared/Auth/TicketFilterService.cs`, Zeilen 42-56 |
+| SyRS-060 | Abrechenbare Verträge werden über einen mehrstufigen Filter ermittelt | ja | belegt | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, `GetActiveContracts` (Zeilen 820-846) |
+| SyRS-061 | Ein Abrechnungslauf kann mehrere Perioden in Teilrechnungen zerlegen | ja | belegt | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, Zeilen 1052-1090 |
+| SyRS-062 | Kontingente werden je Rechnung mit Art, Wert und Buchungszeitraum festgeschrieben | ja | belegt | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, `StoreBookedContingent` (Zeilen 1098-1135) |
+| SyRS-063 | Kontingentausgleich wirkt sich auf Belegpositionen aus | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 3781-3791 |
+| SyRS-064 | Zählerstände werden mit Historie, Freimengen und Staffelpreisen verrechnet | ja | belegt | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, Zeilen 487-560 und 736-764 |
+| SyRS-065 | Zählerstände können aus einem Import in Stammblätter überführt werden | ja | belegt | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, Zeilen 62-161 |
+| SyRS-066 | Verträge kennen automatische Verlängerung und Kündigungsdatum | ja | belegt | `src/backend/Centron.Entities/Entities/Sales/Receipts/ContractLists/ReceiptContract.cs` |
+| SyRS-067 | Aus einem Vertrag erzeugte Rechnungen bleiben rückverfolgbar | ja | belegt | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, `StoreInvoiceToContract` (Zeile 1258) und `GetLastInvoiceID` (Zeile 811) |
+| SyRS-068 | Mehrere Verträge eines Kunden können in einer Sammelrechnung abgerechnet werden | ja | belegt | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, `GetContractMailTemplate` (Zeile 263) |
+| SyRS-070 | Kreditlimit wird belegartübergreifend berechnet | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 8661-8672 |
+| SyRS-071 | Steuersätze werden bei einer Datumsänderung des Belegs nachgeführt | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeile 7897 |
+| SyRS-072 | Umsatzsteuer-Identifikationsnummer oder Steuernummer wird geprüft | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeile 3749 (`this.CheckIfRevenueIdentificationNumberOrTaxNumber(receipt, result);`) |
+| SyRS-073 | Mahnstufen werden je Rechnung geführt und können gefiltert werden | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs`, Zeilen 286-297 |
+| SyRS-074 | SEPA-Export verwendet wahlweise die Bankverbindung des Mandanten | ja | belegt | `src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs`, Zeilen 136-169 |
+| SyRS-075 | Lastschriftmandate sind bei entsprechender Zahlungskondition Pflicht | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeile 3745 (`this.CheckIfMandatIsNeeded(receipt, data, result); //Abhängig: Zahlungskondition, Mandat`) |
+| SyRS-076 | Elektronische Rechnung wird aus einer eigenen Exportstruktur erzeugt | ja | belegt | `src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs` |
+| SyRS-077 | Elektronische Rechnungen werden auch eingelesen | ja | belegt | `src/backend/Centron.BL/EDI/Zugferd/ZugferdParseBL.cs`, Zeile 128 |
+| SyRS-078 | Buchhaltungsdaten werden über eine eigene Beleg-Ladestruktur bereitgestellt | ja | belegt | `src/backend/Centron.BL/WebServices/DataExchange/BookKeeping/BookKeepingExportWebServiceBL.cs`, Zeilen 561-563 |
+| SyRS-079 | Ohne Preisrecht bleiben Einkaufs- und Verkaufspreis unverändert | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `UpdateArticlePositionsPurchasePriceAndSellPriceIfUserDoesNotHaveRightToChangeThem` (Zeilen 8030-8098) |
+| SyRS-081 | Lagerbuchungen aktualisieren den Einkaufspreis des Artikels | ja | belegt | `src/backend/Centron.BL/Warehousing/StockManagement/ArticleStockBL.cs`, Zeilen 74-149 |
+| SyRS-092 | Arbeitszeiten werden aus mehreren Quellen zusammengeführt | ja | belegt | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, `GetLicenseCount(Guid licenseGuid)` (Zeilen 332-343) |
+| SyRS-100 | Datenbereinigung nach DSGVO erfolgt kategorienweise und vorschaufähig | ja | belegt | `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs`, Zeilen 34-63 |
+| SyRS-101 | Das Löschbegehren wird über eine Kontaktrecherche vorbereitet | ja | belegt | `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs`, `DsgvoDeleteRightGetContacts` (Zeilen 377-786) |
+| SyRS-102 | Schlüsselmaterial liegt in einer getrennten Konfigurationsdatenbank | ja | belegt | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeilen 551-553 |
+| SyRS-111 | Berichtsversand des Reportservers ist an ein eigenes Recht gebunden | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 160-162 |
+| SyRS-112 | Massenänderungen sind an ein eigenes Recht und eine eigene Lizenz gebunden | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 424-426 |
+| SyRS-113 | Zusatzfelder werden typisiert gespeichert | ja | belegt | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeilen 1051-1052 |
+| SyRS-116 | PDF-Signierung ist zentral konfigurierbar | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Eintrag `new PdfSigningSettingsAppModuleController()` in `GetSettingsWithoutModule()` |
+| SyRS-117 | Die Unterschrift im Browser läuft in einer abgeschotteten Komponente | ja | belegt | `src/nexus/CentronNexus/DocumentSigning/IsolatedSignaturePad.razor` |
+| SyRS-128 | Erwartete Ereignisse und ihre Auswertung sind getrennt lizenziert | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 150-157 |
+| SyRS-130 | Stammblätter verbinden Gerät, Vertrag und Rechnung | ja | belegt | `src/backend/Centron.Entities/Entities/Sales/Receipts/MasterDataLists/MasterDataList.cs`, Zeilen 9-33 |
+| SyRS-135 | Begründungspflicht wird über eine dreistufige Einstellung und ein Pflichtkennzeichen gesteuert | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CheckIfAssetReasonIsNeeded` (Zeilen 8823-8857) |
+| SyRS-138 | Herstellerinterne Funktionen werden über eine eigene Lizenz freigeschaltet | ja | belegt | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, Zeilen 380-383 |
+| SyRS-140 | Konditionstexte werden beim Speichern in den Beleg übernommen | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 8883-8960 |
+| SyRS-141 | Bankumsätze werden über ein eigenes Gateway abgerufen | ja | belegt | `src/apis/Centron.APIs.FinAPI/IFinApiClient.cs` |
+| SyRS-142 | Externe Artikelquellen werden über ein gemeinsames Anbietermuster eingebunden | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ArticleSearch/ITscopeExternalArticleSearchProvider.cs`, Zeile 210 und `EgisExternalArticleSearchProvider.cs`, Zeile 272 |
+| SyRS-145 | Benachrichtigungen werden über einen gesicherten Kanal in das Portal übertragen | ja | belegt | `docker/compose/appsettings.Production.json`, `Notifications.SecretKey` und `docker/compose/WebServiceConfig.xml`, `<SecretKey>` |
+| SyRS-148 | Fernzugriffsmodule sind an den Passwort-Manager gekoppelt | ja | belegt | `src/centron/Centron.WPF.UI/Modules/PasswordManager/RDPEmbeddedAppModuleController.cs` und `SSHEmbeddedAppModuleController.cs` |
+| SyRS-155 | Lizenzen können nach Anzahl, Datum und Version begrenzt sein | ja | belegt | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, Zeilen 274-284 |
+| SyRS-156 | API-Token werden mit Ablaufdatum und Aktivkennzeichen geführt | ja | belegt | `src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs`, Zeile 444 |
+| SyRS-157 | API-Aufrufe mit Token werden über das JWT-Bearer-Verfahren autorisiert | ja | belegt | `src/webservice/Centron.Controllers/Controllers/v1/Administration/AccessTokensController.cs`, Zeile 19 |
+| SyRS-158 | Der SQL-Manager stellt Datenbankinformationen auch für die Lizenzierung bereit | ja | belegt | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, Zeilen 70-87 |
+| SyRS-171 | Der Produktlebenszyklus wird eigenständig ausgewertet | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 136-138 |
+| SyRS-173 | Die Umschaltung zwischen Adressmodellen erfolgt über eine einzige Einstellung | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 105-111 und 132-133 |
+| SyRS-174 | Die Produktmatrix ist als eigenes Steuerelement wiederverwendbar | ja | belegt | `src/shared/Centron.Controls/ProductMatrix/` |
+| SyRS-177 | Erlöskonten werden je Belegposition ermittelt | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeile 8872 |
+| SyRS-178 | Mobile Anwendungen melden sich als eigene Anwendungsart an | ja | belegt | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeilen 100-104 |
+| SyRS-184 | Funktionen im Erprobungsstadium werden in der Oberfläche gekennzeichnet | ja | belegt | `src/centron/Centron.WPF.UI/Modules/DataExchange/DocSync/DocSyncSettingsAppModuleController.cs`, Zeile 12 |
+| SyRS-193 | [HYPOTHESE] Die Datenbankverbindung wird verschlüsselt hinterlegt | ja | HYPOTHESE | `src/backend/Centron.BL/Administration/WebServiceConfiguration/WebServiceConfigSerializer.cs`, Zeilen 41-44 und 163 |
+| SyRS-194 | [HYPOTHESE] Die Verbindung zum Webservice ist transportverschlüsselt | ja | HYPOTHESE | `src/nexus/CentronNexus.Host/Program.cs`, Zeile 145 |
+| SyRS-195 | [HYPOTHESE] Für personenbezogene Daten bestehen Aufbewahrungsfristen | ja | HYPOTHESE | `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs`, Zeilen 34-63 |
+| SyRS-199 | [HYPOTHESE] Mandantendaten sind auf Datenebene voneinander getrennt | ja | HYPOTHESE | `SSMS_DB_SCHEMA.sql`, `dbo.Sichbenu`, Spalte `[MandantID] [int] NULL` (Zeile 18515) |
+| SyRS-200 | [HYPOTHESE] Rechteänderungen wirken ohne neue Anmeldung | ja | HYPOTHESE | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, Zeilen 644-650 |
+| SyRS-201 | [HYPOTHESE] Das Riverbird-Produkt teilt sich Bestandteile mit c-entron | ja | HYPOTHESE | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `GetRiversuiteRelevantRights` (Zeilen 55-60) |
+| SyRS-204 | [HYPOTHESE] Die docuFORM-Anbindung liefert Gerätezählerstände | ja | HYPOTHESE | `Centron.Api.docuFORM/IDocuFormApiClient.cs` und `DocuFormRestApiClient.cs` |
+| SyRS-211 | Pauschalabrechnung arbeitet ausschließlich über die Datenbankverbindung | ja | belegt | `src/centron/Centron.WPF.UI/Modules/Finances/FlatrateBilling/FlatRateProjectAppModuleController.cs`, Zeile 19 |
+| SyRS-212 | Vertragsarten steuern die Vorbelegung neuer Verträge | ja | belegt | `src/backend/Centron.Entities/Entities/Accounts/AccountContracts/AccountContract.cs`, Zeile 124 |
+| SyRS-213 | Sonderpreise werden als Grundlage der Vertragsabrechnung importiert | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 473-475 |
+| SyRS-214 | Vertragspositionsdaten werden für die Abrechnung importiert | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 463-465 |
+| SyRS-216 | Aufschläge auf Stundensätze werden zentral verwaltet | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 36-38 |
+| SyRS-218 | Zahlungseingänge werden erfasst und Rechnungen zugeordnet | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs`, Zeile 221 (`f.GrossPriceComplete - f.PayedGrossAmount - f.CreditVoucherGrossAmount`) |
+| SyRS-220 | Lieferantenbelege bilden eine eigene Belegkette | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 7318-7330 |
+| SyRS-225 | Projektpreise werden als Sondervereinbarungen importiert | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeile 3699 (`this.CheckIfArticlesWithLicenseeRequiredHaveASpecialAgreementI3D(receipt, data, result); //Nebenwirkung: SpecialAgreementI3D`) |
+| SyRS-226 | Aktionspreise gelten befristet und je Distributor | ja | belegt | `src/backend/Centron.BL/Warehousing/ActionPriceBL.cs` |
+| SyRS-227 | Stücklistenartikel werden aus Komponenten zusammengesetzt | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeile 8046 |
+| SyRS-230 | Das persönliche Dashboard fasst offene Vorgänge zusammen | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 356-358 |
+| SyRS-233 | Kennwortrichtlinien des Zugangsverwalters sind gesondert berechtigt | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 386-393 |
+| SyRS-234 | Zugangsbereiche gliedern die verwahrten Zugangsdaten | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 396-398 |
+| SyRS-237 | Verbindungen werden über ein eigenes Werkzeug eingerichtet und geprüft | ja | belegt | `src/webservice/c-entron.misc.ConnectionManager/ConnectionManagerViewModel.cs`, Zeilen 919-924 |
+| SwRS-002 | Nummernkreise werden als Mandanten- und Filialstammdatum geführt | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 7264-7285 |
+| SwRS-010 | Rechteabfragen verwenden benannte Parameter und Rohsql | ja | belegt | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, Zeilen 95-111 |
+| SwRS-011 | Rechtegruppen tragen eine Filialkennung | ja | belegt | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, Zeilen 42-46, 355-357, 391-393, 444-446 |
+| SwRS-012 | Rechtekennungen werden ausschließlich über Konstanten verwendet | ja | belegt | `src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs`, Zeilen 1960 und 1976 |
+| SwRS-020 | Lizenz- und Rechtebedingung sind je Modul getrennte Ausdrücke | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 497-527 |
+| SwRS-021 | Der Lizenzmanager wird je Betriebsart unterschiedlich eingerichtet | ja | belegt | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, Zeilen 47-173 |
+| SwRS-030 | Anmeldeverfahren erben Rechte-, Lizenz- und Ticketlogik aus einer Basisklasse | ja | belegt | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeilen 51-66 und 94-155 |
+| SwRS-031 | Der Prüfer des zweiten Faktors wird als statisches Feld zwischengespeichert | ja | belegt | `src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs`, Zeilen 181-194 |
+| SwRS-032 | Die Anwendungskennung wird verschlüsselt übertragen und entschlüsselt aufgelöst | ja | belegt | `src/webservice/Centron.Controllers/Controllers/Unversioned/JwtAuthController.cs`, Zeilen 25-39 |
+| SwRS-033 | Ticketkennungen werden aus Gerätekennung und Zufallssalz gebildet | ja | belegt | `src/backend/Centron.BL/Administration/Logins/TicketBL.cs`, Zeilen 166-170 |
+| SwRS-034 | Anmeldeversuche werden mit strukturiertem Kontext protokolliert | ja | belegt | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeilen 21-42 |
+| SwRS-035 | Der Mailversand ist in Entwicklungsständen gegen Fremdadressen abgesichert | ja | belegt | `DeveloperSecurity.cs` (Ablage laut `docs/reference/security/developer-security.md`) |
+| SwRS-041 | Pflichtfilter werden als Filterbaum aufgebaut und zusammengeführt | ja | belegt | `src/nexus/CentronNexus/Shared/Auth/TicketFilterService.cs`, Zeilen 65-105 |
+| SwRS-042 | Portalseiten werden über Autorisierungsattribute geschützt | ja | belegt | `src/nexus/CentronNexus/Shared/Authorization/` mit den zwölf genannten Bausteinen |
+| SwRS-050 | Ticketrechteprüfung erkennt Feldänderungen über den Persistenzzustand | ja | belegt | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, Zeile 455 (`IsDirtyProperty`) |
+| SwRS-060 | Die Vertragsabrechnung ist als partielle Klasse getrennt | ja | belegt | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, Zeile 60 (`public partial class AutomaticFacturaBL`) |
+| SwRS-061 | Zeiträume der Vertragsabrechnung werden kalendarisch berechnet | ja | belegt | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, Zeilen 1072-1086 |
+| SwRS-062 | Kontingentzuordnungen werden als eigene Entität geführt | ja | belegt | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, Zeilen 1066-1101 |
+| SwRS-063 | Zählerdaten werden über Barcode und Gerätekennung verknüpft | ja | belegt | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, Zeilen 492, 522, 532, 765 |
+| SwRS-064 | Vertragsfelder umfassen Kontingent-, Abrechnungs- und Überwachungsparameter | ja | belegt | `src/backend/Centron.Entities/Entities/Sales/Receipts/ContractLists/ReceiptContract.cs` |
+| SwRS-070 | Preisrechte werden belegartspezifisch ausgewertet | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 8038-8039 |
+| SwRS-071 | Steuerprüfungen unterscheiden Artikel- und Rabattpositionen von übrigen Positionsarten | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 9575-9578 |
+| SwRS-072 | Der offene Rechnungsbetrag wird aus drei Bestandteilen gebildet | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs`, Zeilen 221, 224, 227, 230 |
+| SwRS-073 | SEPA-Formate werden über eine Aufzählung und ein Gateway getrennt | ja | belegt | `src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs`, Zeilen 179-184 |
+| SwRS-074 | Die ZUGFeRD-Erzeugung arbeitet über ein eigenes Exportobjekt | ja | belegt | `src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs`, Zeilen 833-838 |
+| SwRS-075 | Elektronische Rechnungsformate liegen in drei getrennten Bausteinen | ja | belegt | `src/backend/Centron.Gateway/ZUGFeRD21_Extended/` und `src/apis/Centron.Api.EbInterface/EbInterfaceLogic.cs` |
+| SwRS-086 | RMA-Vorgänge werden über eigene Logikkomponenten geführt | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 292-294 |
+| SwRS-100 | Die Datenbereinigung ist nach Kategorien aufgeteilt | ja | belegt | `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs`, Zeilen 34-63 und 64-376 |
+| SwRS-101 | Verschlüsselte Werte werden in einer eigenen Spalte geführt | ja | belegt | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeilen 527, 700 und 1052 |
+| SwRS-116 | Die PDF-Signierung ist die einzige Komponente im Sicherheitsbereich der Geschäftslogik | ja | belegt | `src/backend/Centron.BL/Security/PdfSigningBL.cs` als einziger Inhalt des Verzeichnisses |
+| SwRS-117 | Unterschriften werden je Bezugsobjekt getrennt verwaltet | ja | belegt | `SSMS_DB_SCHEMA.sql`, `dbo.Sichbenu`, Spalte `[Unterschrift] [image] NULL` (Zeile 18528) |
+| SwRS-128 | Erwartete Ereignisse sind in Steuerung und Auswertung getrennt | ja | belegt | Die beiden getrennten Modulzweige `ExpectedEvents/` und `ExpectedEventsReporting/` |
+| SwRS-130 | Stammblätter bestehen in zwei Entitätsausprägungen | ja | belegt | `src/backend/Centron.Entities/Entities/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListCompact.cs` und `MasterDataListItemsCompact.cs` |
+| SwRS-133 | Ticketvorlagen werden über eine Baumstruktur mit Kategorien geordnet | ja | belegt | `src/nexus/CentronNexus/Management/TicketPatterns/Components/TicketPatternTree.razor` und `TicketPatternCategoryEditor.razor` |
+| SwRS-134 | Aufgabenverwaltung besteht in zwei Domänenbereichen | ja | belegt | `src/backend/Centron.BL/TaskManager/` und `src/backend/Centron.BL/ToDoArea/` |
+| SwRS-138 | Systemmerkmale werden zentral vor der Modulauswahl gesetzt | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 371-378 |
+| SwRS-140 | Konditionstexte werden über eine gemeinsame Bildungsfunktion erzeugt | ja | belegt | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 8912, 8940 und im Zahlungskonditionsblock |
+| SwRS-148 | Der Passwort-Manager ist im Quellcode als abzulösen gekennzeichnet | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeile 383 |
+| SwRS-151 | Zu jeder Logikschnittstelle bestehen zwei Umsetzungen | ja | belegt | `src/centron/Centron.WPF.UI/Services/Logics/TwoFactorAuthenticator/` mit allen drei Dateien |
+| SwRS-152 | Der Container wird eigenständig veröffentlicht | ja | belegt | `docker/Dockerfile`, Zeilen 1-11 und 32-34 |
+| SwRS-154 | Skripte können vor der Anmeldung und wiederkehrend ausgeführt werden | ja | belegt | `src/backend/Centron.BL/Administration/Scripts/ScriptEngineBL.cs`, Zeilen 82-98 |
+| SwRS-156 | Lizenzanzahl und Ticketanzahl werden gemeinsam ausgewertet | ja | belegt | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, Zeilen 276-284 |
+| SwRS-157 | Rechteprüfungen der Tokenverwaltung liegen in der Geschäftslogik | ja | belegt | `src/webservice/Centron.Controllers/Controllers/v1/Administration/AccessTokensController.cs`, Zeilen 11-16 und 30-38 |
+| SwRS-158 | Datenbankkennungen werden über eine eigene Verwaltungskomponente ermittelt | ja | belegt | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, Zeilen 72-73 |
+| SwRS-159 | Protokollierung erfolgt über klassenbezogene Protokollierer | ja | belegt | `src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs`, Zeile 19 und `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeile 54 |
+| SwRS-172 | Lieferantenverträge verwenden eigene Steuerelemente und Logikklassen | ja | belegt | `src/shared/Centron.Controls/AccountContracts/` |
+| SwRS-174 | Die Produktmatrix besteht aus Logik, Entitäten und Steuerelement | ja | belegt | Die drei genannten Bereiche |
+| SwRS-178 | Anwendungsarten tragen Rechte-, Lizenz- und Sitzungsmerkmale | ja | belegt | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeilen 70-84 und 100-106 |
+| SwRS-182 | Der Bau wird über ein eigenes Skriptprojekt gesteuert | ja | belegt | `azure/build-pipeline.yml`, Zeilen 18-38 |
+| SwRS-184 | Lizenzabhängige Einstellungsseiten kennzeichnen sich über eine eigene Schnittstelle | ja | belegt | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 397-404 |
+| SwRS-192 | [HYPOTHESE] Die als unsicher geltende Binärserialisierung wird nur für einen Zweck genutzt | ja | HYPOTHESE | `Directory.Build.props`, Zeilen 40-43 |
+| SwRS-195 | [HYPOTHESE] Fremdbestandteile werden ausschließlich über Paketverwaltung bezogen | ja | HYPOTHESE | `nugets/` mit 13 Paketen, darunter zwei FastReport-Hauptversionen |
+| SwRS-197 | [HYPOTHESE] Statische Zwischenspeicher sind für den Mehrmandantenbetrieb geeignet | ja | HYPOTHESE | `src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs`, Zeile 182 (`private static ITwoFactorValidator _globalValidator;`) |
+| SwRS-198 | [HYPOTHESE] Die zweite Steuerelementbibliothek dient der Produktvorschau | ja | HYPOTHESE | `src/shared/Centron.Controls.Preview/` |
+| SwRS-199 | [HYPOTHESE] Migrationsskripte enthalten keine fachlichen Regeln | ja | HYPOTHESE | `src/backend/Centron.BL/Administration/Scripts/ScriptMethods/Scripts/ScriptMethod11152.cs` Zeilen 53 und 144 sowie sieben weitere Skripte mit identischer Zuweisung |
+---
+
+## 6. Abgleich `Hypothesen.md` gegen die Inline-Markierungen
+
+Geprüft wurde maschinell über alle drei Spezifikationsdateien, ob die Menge der Anforderungen mit `Status: HYPOTHESE` und die Menge der Anforderungen mit `[HYPOTHESE]`-Markierung im Block deckungsgleich sind und ob `Hypothesen.md` genau diese Anforderungen aufführt.
+
+| Prüfung | Ergebnis |
+|---|---|
+| Anforderungen mit `Status: HYPOTHESE` | 33 |
+| Anforderungen mit `[HYPOTHESE]`-Markierung in der Aussage | 33 |
+| Nur `Status`, keine Inline-Markierung | 0 |
+| Nur Inline-Markierung, kein `Status` | 0 |
+| In `Hypothesen.md` aufgeführt | 33 |
+| Zusätzliche freie Fragen in `Hypothesen.md` | 0 |
+
+Beide Mengen sind deckungsgleich. Offene Punkte ohne zugehörige Anforderung stehen ausschließlich in Abschnitt 7.6 dieses Berichts, nicht in `Hypothesen.md`.
+
+Verteilung der Hypothesen über die Ebenen: StRS 5, SyRS 17, SwRS 11. Anteil an allen Anforderungen: 7,6 %.
+
+---
+
+## 7. Selbstbewertung
+
+### 7.1 Analysetiefe je Modul — absolute Zahlen
+
+| Einstufung | Module | Anteil am Inventar |
+|---|---|---|
+| tief (≥ 8 Anforderungen) | 9 | 5,0 % |
+| mittel (3–7 Anforderungen) | 108 | 60,3 % |
+| flach (1–2 Anforderungen) | 62 | 34,6 % |
+| nicht analysiert (0 Anforderungen) | **0** | **0 %** |
+| **Summe** | **179** | **100 %** |
+
+Tief analysiert wurden neun Module: M01 Belegwesen (26 Anforderungen), M143 Authentifizierung & Ticketverwaltung (14), M95 Rechteverwaltung (12), M58 Ticket-Liste/Helpdesk (10), M110 Lizenzverwaltung (10), M179 Anwendungsrahmen und Modulregistrierung (10), M128 Nexus Kundenportal (9), M162 Datenzugriff (8) und M163 Datenbank-Skriptmotor (8). Die Auswahl folgt Schritt 0c: Sicherheitsregeln (M143, M95, M110, M128), Abrechnungs- und Fakturierungslogik (M01) sowie Berechtigungsprüfungen (M95, M58, M179); M162 und M163 kamen hinzu, weil der Belegspeicherpfad und die Schemamigration die Grundlage jeder Datenübernahme in ein Zielsystem bilden.
+
+Die Abrechnungsseite verteilt sich über mehrere Module und erscheint dadurch in der Einzelbetrachtung als `mittel`: M14 Vertragsabrechnung (7), M27 Kontingentverwaltung (4), M18 Klick-Zählerverwaltung (4), M35 Mehrwertsteuerverwaltung (4), M31 SEPA-Zahlungsverkehr (4) und M28 Mahnwesen (3) tragen zusammen 26 Anforderungen zur Fakturierung bei.
+
+### 7.2 Mindestabdeckung
+
+Die Mindestabdeckung aus Schritt 0b ist **vollständig erreicht**: Jedes der 179 Inventarmodule trägt mindestens eine Anforderung. Kein Modul musste als `nicht analysiert` geführt werden.
+
+Erreicht wurde dies in zwei Schritten: Nach der Vertiefung trugen 151 der zunächst 174 Module eine Anforderung. Für die verbleibenden 28 Module wurden mit `SyRS-210` bis `SyRS-237` gezielt Anforderungen ergänzt, die den belegbaren Kern des jeweiligen Moduls beschreiben. Fünf weitere Module (M175–M179) wurden erst während der Vertiefung erkennbar und dem Inventar nachgetragen; sie werden durch bereits vorhandene Anforderungen abgedeckt.
+
+### 7.3 Belegsituation
+
+| Kennzahl | Wert |
+|---|---|
+| Belege gesamt | 945 |
+| davon `PRIMÄR` | 766 (81,1 %) |
+| davon `SEKUNDÄR` | 113 (12,0 %) |
+| davon `KONTEXT` | 66 (7,0 %) |
+| Anforderungen ohne `PRIMÄR`-Beleg | 0 |
+| Anforderungen mit genau einem Beleg | 57 (13,1 %) |
+| Belege je Anforderung im Mittel | 2,18 |
+
+**Wo der Beleg dünn ist.** Ein hoher Anteil `SEKUNDÄR`/`KONTEXT` beziehungsweise nur ein einzelner Beleg tritt an drei erkennbaren Stellen auf:
+
+1. **Module, die ausschließlich über ihre Registrierung belegt sind.** Bei 62 flach analysierten Modulen stützt sich die Anforderung im Kern auf den Registrierungsblock in `ModuleRegistration.cs` (Rechte- und Lizenzbedingung) und die Eigenschaften `ModuleName`/`Description` des Modulcontrollers. Das ist ein `PRIMÄR`-Beleg für *Existenz, Berechtigung und Zweck* des Moduls, aber kein Beleg für sein *inneres Verhalten*. Betroffen sind vor allem die Module M15, M17, M19, M20, M25, M29, M38, M42, M55, M77, M84, M86, M113, M114, M117, M146.
+2. **Nicht-funktionale Anforderungen zum Betrieb.** Verfügbarkeit, Datensicherung, Antwortzeiten und Barrierefreiheit (SyRS-196 bis SyRS-198) beruhen auf dem Fehlen entsprechender Festlegungen in der Codebasis. Sie sind durchgängig als `[HYPOTHESE]` geführt, weil ein solcher Negativbefund statisch nicht abschließend beweisbar ist.
+3. **Bereiche ohne Modul- oder Konfigurationsanbindung.** Bei M175 Gutscheinverwaltung, M176 IT-Planer und M178 DocuBoard konnte nur die Existenz der Geschäftslogik und ihrer Datenstrukturen belegt werden, nicht ihre Erreichbarkeit für Anwender. Alle drei sind als `[HYPOTHESE]` geführt.
+
+Die Dokumentation unter `docs/` wurde durchgängig als `KONTEXT` eingestuft, auch wo sie fachlich sehr präzise ist (etwa die Belegarchitektur oder die ZUGFeRD-Feldabbildung). Sie trägt allein keine Anforderung; wo sie herangezogen wurde, steht daneben stets ein `PRIMÄR`-Beleg aus dem Code, dem Schema oder der Konfiguration.
+
+### 7.4 Konsolidierungsbedarf
+
+86 Anforderungen (19,8 %) sind als Konsolidierungskandidat vermerkt. Gemeint sind ausschließlich fachlich gleichartige Konzepte in **getrennten Implementierungen oder Datenhaltungen** — nicht Anforderungen, die denselben Sachverhalt aus Sicht verschiedener Ebenen beschreiben; für letztere sind die Tracelinks zuständig.
+
+Die gewichtigsten Fälle, nach fachlicher Tragweite geordnet:
+
+| # | Gegenstand | Getrennte Umsetzungen | Anforderungen |
+|---|---|---|---|
+| 1 | **Geschäftspartner** | Kundenmodell (`Customer`, `CustomerArea`) und Kontomodell (`Account`, `Accounts`) vollständig parallel über alle Schichten, umgeschaltet über eine Einstellung; `WebAccounts` führt Bezugsfelder beider Modelle | StRS-084, SyRS-173, SwRS-173, SwRS-040 |
+| 2 | **Gerät beim Kunden** | Stammblatt (`MasterDataList`), Gerät (`AccountDevice`) und IT-Bestandserfassung (`DocuBoard/AssetManagement*`) — drei Datenhaltungen für denselben Gegenstand | StRS-051, StRS-100, SyRS-130, SwRS-130 |
+| 3 | **Nachvollziehbarkeit von Änderungen** | Audit-Felder, Belegversionstabellen, `AnlageLog`, `ChangeTracking` und `AppRightLog` — fünf Mechanismen | StRS-080, SyRS-007, SwRS-161, SwRS-162 |
+| 4 | **Belegpersistenz** | moderne NHibernate-Entitäten mit Sichten und Legacy-Repositories mit temporären Entitäten — zwei Pfade, von denen nur einer schreibt | SwRS-007, SwRS-008, SwRS-009 |
+| 5 | **Datenzugriff des Clients** | je Schnittstelle eine `BL…Logic`- und eine `WS…Logic`-Umsetzung, verbindlich für jedes Modul | StRS-071, SyRS-151, SwRS-151 |
+| 6 | **Aufgabe** | `TaskManager` (rechtegebunden, mit Historie) und `ToDoArea` (ohne Rechteprüfung), einschließlich zweier Steuerelementbereiche | StRS-055, SyRS-134, SwRS-134 |
+| 7 | **Benachrichtigung** | `Notifications`, `NexusNotifications` und die Update-Benachrichtigung | StRS-066, SyRS-145, SyRS-235, SwRS-145 |
+| 8 | **Wiederverwendbarer Text** | globale Mailvorlagen, persönliche Mailvorlagen, Eskalationsvorlagen, Vertragsvorlagen und Textbausteine | StRS-036, SyRS-114, SwRS-114 |
+| 9 | **Platzhalterersetzung** | `HelpdeskReplacementBL`, `AdressstammReplacementBL`, `ExternalToolsReplacementBL` und `ReportEngine/ReplacementBLs` | SyRS-147, SwRS-114, SwRS-147 |
+| 10 | **Elektronische Rechnung** | Eigenimplementierung `InvoiceZugferdBL`, Gateway `ZUGFeRD21_Extended` und `Centron.Api.EbInterface` | StRS-018, SwRS-074, SwRS-075 |
+| 11 | **Externe Artikelquelle** | vier Anbieter (COP, EGIS, ITscope, Icecat) plus TradePool ohne gemeinsame Abstraktion | StRS-063, StRS-090, SyRS-142, SwRS-142 |
+| 12 | **Fremdsystemdaten** | RMM, DocBee, Tanss, TelekomDive und docuFORM als fünf getrennte Konnektoren, verteilt auf zwei Controllerbereiche | StRS-064, SyRS-143, SwRS-143, SwRS-144 |
+| 13 | **Vertrag** | Kundenvertrag (`ReceiptContract`) und Lieferantenvertrag (`AccountContract`) mit je eigener Vertragsart | StRS-083, SyRS-172, SwRS-172 |
+| 14 | **Projekt** | CRM-Projekt, Ticketprojekt und herstellerinterne Projektverwaltung | SyRS-210, SyRS-228 |
+| 15 | **Inventur** | `InventoryBL` und `InventoryNewBL` mit gleicher Aufgabe | StRS-023, SyRS-084, SwRS-083 |
+| 16 | **Zahlungseingang** | Bankabruf (finAPI), OPOS-Import und manuelle Erfassung | StRS-062, SyRS-217, SyRS-218 |
+| 17 | **Unterschrift** | PDF-Signatur (`PdfSigningBL`), Browser-Unterschrift (`DocumentSigning`) und hinterlegte Mitarbeiterunterschrift (`Sichbenu.Unterschrift`) | StRS-038, StRS-039, SwRS-117 |
+| 18 | **Ticketvorlage** | WPF-Modul „Ticketprozess Vorlagen" und Nexus-Vorlageneditor mit unterschiedlichem Umfang | StRS-054, SyRS-133, SwRS-133 |
+| 19 | **Auslastungsauswertung** | „Leistungsnachweise" und „Mitarbeiterauslastung" | SyRS-229, StRS-029 |
+| 20 | **Versanddienstleister** | GLS und Shipcloud als eigenständige Assemblies ohne gemeinsame Schnittstelle | SyRS-089, SwRS-087 |
+
+### 7.5 Übernahmewürdigkeit und Anforderungstypen
+
+| Übernahmewürdigkeit | Anzahl | Anteil |
+|---|---|---|
+| übernehmen | 381 | 87,8 % |
+| Workaround | 31 | 7,1 % |
+| veraltet | 12 | 2,8 % |
+| Sonderfall | 10 | 2,3 % |
+
+| Typ | Anzahl |
+|---|---|
+| funktional | 171 |
+| Sicherheit | 78 |
+| Daten | 75 |
+| Schnittstelle | 62 |
+| nicht-funktional | 48 |
+
+Alle 48 nicht-funktionalen Anforderungen tragen ein Qualitätsmerkmal nach ISO/IEC 25010 im dafür vorgesehenen Feld `Qualitätsmerkmal`. Verteilung: Wartbarkeit 7, Analysierbarkeit 6, Modifizierbarkeit 5, Testbarkeit 5, Benutzbarkeit 4, Übertragbarkeit 4, Performance-Effizienz 4, Fehlertoleranz 2, Zuverlässigkeit 2, Installierbarkeit 2, Anpassbarkeit 2, Verantwortlichkeit 2, Zeitverhalten 1, Verfügbarkeit 1, Zugänglichkeit 1.
+
+Die 12 als `veraltet` eingestuften Anforderungen betreffen: das Kennwortverfahren (SyRS-031), die Delphi-Versionsausnahme (SyRS-021, SwRS-196), den Buchhaltungsexport/-import als Modul (StRS-019), die Bestellvorschlagsliste (StRS-024), die Reisekostenabrechnung (StRS-060), den Passwort-Manager-Bereich (SyRS-148, SwRS-148, SyRS-233, SyRS-234), den doppelten Belegspeicherpfad (SwRS-007, SwRS-008) und die Binärserialisierung (SwRS-192).
+
+### 7.6 Offene Punkte ohne zugehörige Anforderung
+
+Diese Punkte sind bewusst **nicht** in `Hypothesen.md` aufgenommen, weil ihnen keine Anforderung entspricht:
+
+1. **Umfang der Belegverarbeitung.** `ReceiptBL.cs` umfasst 11.441 Zeilen, `ReceiptItemBL.cs` 4.290. Der Speicherpfad wurde vollständig ausgewertet (rund 40 benannte Prüfungen), die übrigen Verantwortlichkeiten der beiden Klassen — Preisberechnung, Belegumwandlung, Druck, Versand — nur soweit, wie sie im Speicherpfad sichtbar werden. Hier liegt der größte verbleibende Fachlogikbestand.
+2. **Datenbanksichten und Funktionen.** Das Schema mit 1.535 Tabellen wurde für Struktur- und Constraintfragen ausgewertet; die in Sichten und Funktionen enthaltene Logik wurde nicht systematisch gelesen. SwRS-199 benennt dies als Risiko, kann es aber nicht beziffern.
+3. **790 Migrationsskripte.** Ausgewertet wurden die Ausführungsmechanik und stichprobenhaft der Inhalt; eine vollständige Durchsicht auf ausschließlich dort enthaltene Fachregeln steht aus.
+4. **460 Razor-Komponenten des Webportals.** Die Bereichsstruktur und die sicherheitsrelevanten Bausteine (Autorisierung, Ticketfilter) wurden ausgewertet; das Verhalten der einzelnen Oberflächenkomponenten nicht.
+5. **Change-Historie und Projektartefakte.** Im Arbeitsverzeichnis liegt kein Git-Verlauf, kein Ticketexport und keine Release-Notes-Datei. Als Change-Informationen standen ausschließlich Quellcodekommentare mit Datum und Auftraggeber zur Verfügung (etwa „SKA 2025-09-18 : Requested by Volker Lehnert"), die `changelog.txt` im Nexus-Projekt sowie das Feature-Dokument mit Implementierungsdatum. Schritt 2 der Methodenkette konnte für diesen Artefakttyp daher nur eingeschränkt ausgeführt werden.
+6. **Testinhalte.** Die Teststruktur wurde erfasst, die Testfälle selbst nicht gelesen. Sie sind eine ergiebige Quelle für erwartetes Verhalten, insbesondere die End-zu-End-Tests, die laut Belegarchitektur die Rohwerte der Legacy-Tabellen prüfen.
+7. **Verhältnis zu Riverbird.** SyRS-201 hält die Kopplung als Hypothese fest; welche Anforderungen dieser Spezifikation für das Schwesterprodukt mitgelten, ist ohne dessen Produktbeschreibung nicht entscheidbar.
+
+### 7.7 Erkenntnisse für eine Folge-Iteration
+
+Nach fachlicher Tragweite geordnet:
+
+1. **Belegverarbeitung vertiefen.** `ReceiptBL` außerhalb des Speicherpfads — insbesondere Preisberechnung (`ReceiptPriceHelperBL`), Belegumwandlung und Mengenfortschreibung zwischen den Belegarten. Hier entstehen die betragswirksamen Regeln, deren Verlust bei einer Neuimplementierung unmittelbar Geld kostet.
+2. **Kontingent- und Zählerabrechnung vertiefen.** `AutomaticFacturaBL.Contracts.cs` wurde für Intervalle, Kontingente und Zählerbezug ausgewertet; die Preisbildung aus Freimengen, Staffelpreisen, Über- und Unterlieferung sowie die Rückrechnung bei Vertragsänderungen sind noch nicht durchdrungen.
+3. **Sichten und Funktionen der Datenbank lesen.** SwRS-199 benennt den Verdacht, dass fachliche Regeln ausschließlich in der Datenbank stehen. Solche Regeln sind bei einer Neuimplementierung besonders gefährdet, weil sie im Anwendungscode unsichtbar sind.
+4. **Die 33 Hypothesen mit Fachexperten klären.** Vorrangig die sicherheitsrelevanten: Kennwortablauf (StRS-098), Kontosperre nach Fehlversuchen (SyRS-039), Wirksamkeit von Rechteentzügen (SyRS-200), Mandantentrennung (SyRS-199) und Transportverschlüsselung (SyRS-194).
+5. **Die 62 flach analysierten Module vertiefen**, beginnend mit denen, die Geld bewegen: M15 Pauschalabrechnung, M29 OPOS, M30 Zahlungseingang, M38 Kalkulation pro Filiale, M42 Belegerfassung, M55 Projektpreis-Import.
+6. **Testfälle als Anforderungsquelle auswerten.** Insbesondere `tests/Centron.Tests.EndToEnd` und `tests/backend/Centron.Tests.BL` beschreiben erwartetes Verhalten in prüfbarer Form und decken Regeln auf, die aus dem Produktivcode allein nicht erkennbar sind.
+7. **Konsolidierungsentscheidungen fachlich treffen.** Die 20 in Abschnitt 7.4 aufgeführten Fälle sind Entwurfsentscheidungen für das Zielsystem, keine Analysebefunde. Sie sollten vor dem Zielentwurf entschieden werden, weil sie den Datenmodellschnitt bestimmen — insbesondere die Fälle 1 (Geschäftspartner) und 2 (Gerät beim Kunden).
+8. **Change-Historie erschließen.** Sofern Git-Verlauf, Tickets oder Release Notes beigestellt werden können, ist Schritt 2 der Methodenkette für diesen Artefakttyp zu wiederholen; er liefert die Begründungen hinter den als `Workaround` und `veraltet` eingestuften Anforderungen.
+
+---
+
+## 8. Randbedingungen und Selbstauskunft zur Durchführung
+
+- **Keine Halluzinationen.** Jede Anforderung führt mindestens einen konkreten Artefaktbeleg mit Pfad und, wo möglich, Zeilenangabe. Wo eine Aussage nicht belegt werden konnte, ist sie als `[HYPOTHESE]` mit Angabe der fehlenden Information geführt oder gar nicht erhoben worden.
+- **Keine Codegenerierung.** Es sind ausschließlich Spezifikationsartefakte entstanden.
+- **Keine Annahme über nicht beigestellte Hilfsmittel.** Verwendet wurden ausschließlich Lesen und Suchen von Dateien sowie Kommandozeilenbefehle im Arbeitsverzeichnis. Es wurde kein System ausgeführt, keine Datenbank verbunden und kein externer Dienst aufgerufen. Die Auswertung der Anforderungsdateien für Traceability-Tabelle, Konsistenzcheck und Abdeckungstabelle erfolgte über ein Auswertungsskript, das ausschließlich auf den selbst erzeugten Ergebnisdateien arbeitet.
+- **Codebasis unverändert.** Im Arbeitsverzeichnis `C:\DEV\MasterArbeit\QuellCode\CentronERP` wurde ausschließlich gelesen. Alle Ergebnisdateien liegen im vorgegebenen Ausgabeverzeichnis.
+- **Sprache.** Anforderungsaussagen in Deutsch; technische Bezeichner (Klassen, Methoden, Spalten, Konstanten) in ihrer Originalsprache.
+
+### Erzeugte Dateien
+
+| Datei | Inhalt | Umfang |
+|---|---|---|
+| `StRS.md` | Stakeholder Requirements Specification | 100 Anforderungen |
+| `SyRS.md` | System Requirements Specification | 190 Anforderungen |
+| `SwRS.md` | Software Requirements Specification | 144 Anforderungen |
+| `Traceability.md` | konsolidierte Verfolgbarkeitstabelle | 299 Zeilen; alle 434 Anforderungen enthalten, keine ohne Verknüpfung zur nächsthöheren Ebene |
+| `Hypothesen.md` | alle mit `[HYPOTHESE]` markierten Aussagen mit offener Frage | 33 Einträge |
+| `Glossar.md` | Domänenbegriffe mit Fundstelle | 10 Abschnitte |
+| `Analysebericht.md` | Modulinventar, Abdeckung, Konsistenzcheck, Risikoliste, Selbstbewertung | dieses Dokument |

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-37c5/Ergebnisse/Glossar.md

@@ -0,0 +1,162 @@
+# Glossar — Domänenbegriffe der c-entron ERP-Suite
+
+**Zweck:** Definition aller domänenspezifischen Begriffe, die in `StRS.md`, `SyRS.md` und `SwRS.md` verwendet werden.
+**Quelle:** ausschließlich Artefakte des Arbeitsverzeichnisses. Jeder Eintrag nennt die Fundstelle, aus der die Bedeutung abgeleitet ist.
+**Lesehinweis:** Technische Bezeichner (Klassen, Methoden, Spalten) sind in ihrer Originalsprache belassen. Wo das Produkt einen deutschen und einen englischen Bezeichner für denselben Gegenstand führt, sind beide genannt.
+
+---
+
+## A — Geschäftsobjekte des Belegwesens
+
+| Begriff | Bedeutung | Fundstelle |
+|---|---|---|
+| **Beleg** | Oberbegriff für Angebot, Auftrag, Lieferschein, Rechnung, Vertrag, Gutschrift und Abholschein. Alle Belegarten erben von `ReceiptBase` und teilen Kopffelder, Zustand, Nummer, Adress- und Währungsangaben. | `src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptBase.cs` |
+| **Belegart** (`ReceiptKind`, `CentronObjectKindNumeric`) | Typkennzeichen eines Belegs. Die Zahlwerte erscheinen unter anderem im Protokoll `AnlageLog` als `AnlageArt`: 1 = Angebot, 2 = Auftrag, 3 = Lieferschein, 4 = Rechnung, 5 = Abholschein, 6 = Gutschrift, 22 = Vertrag. | `docs/reference/receipts/receipts-backend-architecture.md`, Abschnitt „AnlageLog Table" |
+| **Belegkopf** (`*Kopf`) | Kopfdatensatz eines Belegs mit Kunde, Datum, Adresse, Währung und Zustand. Tabellen: `AngKopf`, `AufKopf`, `LiefKopf`, `RechKopf`, `VertragKopf`, `GutKopf`, `AbholKopf`. | `SSMS_DB_SCHEMA.sql` |
+| **Belegposition** (`*Pos`) | Einzelzeile eines Belegs. Die Positionsart (`ReceiptItemKind`) unterscheidet unter anderem `Article` (Artikelposition) und `CustomerDiscount` (Kundenrabatt) von Text- und Gliederungspositionen. | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `CheckIfAllArticlePositionsHaveVatRate` |
+| **Belegzustand** (`ReceiptState`) | Genau drei Werte: `Active` = „offen", `Completed` = „abgeschlossen", `Canceled` = „storniert". | `src/backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs` |
+| **Web-Belegzustand** (`WebReceiptState`) | Vom Belegzustand getrennter Zustandsraum für die Sicht des Kunden im Portal (Freigabe/Ablehnung eines Angebots). | `src/backend/Centron.Interfaces/Sales/Receipts/WebReceipt/WebReceiptState.cs` |
+| **Ursprungsverweis** (`OriginReceiptI3D`, `OriginKind`, `OriginReceiptItemI3D`) | Tripel, über das eine Belegposition auf die Position des Vorgängerbelegs verweist; Grundlage der Belegkette. | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 8084-8090 |
+| **Belegversion** (`*KopfVersions`, `*PosVersions`) | Vollständige Kopie eines Belegstands vor einer Änderung; Versionstabellen sind 1:1-Abbilder der Originaltabellen mit den Zusatzspalten `OriginalI3D` und `KopfVersionsI3D`. | `docs/reference/receipts/receipts-backend-architecture.md` |
+| **Belegskondition** (`ReceiptCondition`, `AssetCondition`) | Konditionstext eines Belegs mit Mindestbetrag (`MinimumAmount`); für Kundenbelege verpflichtend. | `ReceiptBL.UpdateConditionTextsAndCheckMinPrices` |
+| **Lieferbedingung** (`DeliveryCondition`) | Kondition zur Lieferung, ebenfalls mit Mindestbetrag; für einzelne Belegarten über `AllowNullDeliveryCondition` abwählbar. | ebenda |
+| **Zahlungskondition** (`PaymentCondition`) | Zahlungsziel und -art; kann einen neu angelegten Beleg unmittelbar abschließen (`ShouldCloseNewReceiptAutomatically`) und ein SEPA-Mandat erfordern. | `ReceiptBL.UpdateReceiptStateFromPaymentCondition`, `CheckIfMandatIsNeeded` |
+| **Nummernkreis** (`NumberGroup`) | Zählerbestand je Belegart, Mandant und Filiale, aus dem die Belegnummer gezogen wird. | `ReceiptBL.UpdateReceiptNumber`, `NumberGroupBL.GetNextNumber` |
+| **Vorlagenkunde** | Kundennummer, auf die Belege lauten, die als Vorlage dienen; ihre Nummern stammen aus einem eigenen Kreis. | `ReceiptBL.UpdateReceiptNumber`, `GetReceiptTemplateCustomerNumber()` |
+
+## B — Vertrag und Abrechnung
+
+| Begriff | Bedeutung | Fundstelle |
+|---|---|---|
+| **Vertrag** (`ReceiptContract`, `VertragKopf`) | Belegart für Dauerschuldverhältnisse mit Laufzeit, Abrechnungsintervall, Kontingent und Geräteverbund. | `src/backend/Centron.Entities/Entities/Sales/Receipts/ContractLists/ReceiptContract.cs` |
+| **Abrechnungsintervall** (`BillingIntervalKind`, `BillingIntervalDuration`) | Art (Daily, Monthly, Quarterly, Yearly) und Vielfaches der Abrechnungsperiode. `Quarterly` wird intern mit ×3, `Yearly` mit ×12 in Monate umgerechnet. | `AutomaticFacturaBL.StoreBookedContingent`, Zeilen 1103-1116 |
+| **Kontingent** (`Kontingent…`) | Im Vertrag vereinbartes Leistungsvolumen (Stunden oder Betrag), das durch erbrachte Leistungen verbraucht wird. | `docs/reference/receipts/contracts-backend.md`, Abschnitt „Contingent Management" |
+| **Überbuchung** (`KontingentUeberbuchung`) | Zulassung eines Verbrauchs über das vereinbarte Kontingent hinaus. | `AutomaticFacturaBL.StoreBookedContingent` |
+| **Restübertrag** (`KontingentRestMitnehmen`) | Übertrag eines nicht verbrauchten Kontingentrests in die Folgeperiode; entfällt bei Wechsel der Kontingentart. | `AutomaticFacturaBL.Contracts.cs`, Zeilen 1046-1051 |
+| **Kontingentzuordnung** (`VertragRechKopfZuordnung`) | Datensatz, der Vertrag und erzeugte Rechnung verbindet und die Kontingentparameter samt Buchungszeitraum (`GebuchtVon`/`GebuchtBis`) festschreibt. | ebenda, Zeilen 1066-1101 |
+| **Vertragsabrechnung** (`AutomaticFactura`) | Periodische Erzeugung von Rechnungen aus Verträgen. | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/` |
+| **Pauschalabrechnung** | Abrechnungsverfahren auf Auftragsbasis, ausschließlich bei direkter Datenbankverbindung nutzbar. | `FlatRateProjectAppModuleController` |
+| **Vereinfachte Ticketabrechnung** (`TimerBilling`) | Abrechnung einzelner Ticketzeiten ohne Vertragsbezug. | `TimerBillingAppModuleController` |
+| **Klick-Zähler** (`DeviceClickCounter`, `CounterDevice`) | Zählerstand eines Druck- oder Kopiersystems als Grundlage der verbrauchsabhängigen Abrechnung. | `src/centron/Centron.WPF.UI/Modules/Finances/DeviceClickCounter/` |
+| **Freimenge** (`CounterFreeCount`) | Im Vertrag enthaltene, nicht gesondert berechnete Zählermenge. | `AutomaticFacturaBL.GetCounterFreeCount` |
+| **Staffelpreis** (`CounterScalePrices`) | Mengenabhängiger Preis je Zählereinheit. | `AutomaticFacturaBL.GetCounterScalePrices` |
+| **Provisionsschema** (`ReceiptProvisionSchema`) | Regelwerk zur Berechnung von Vertriebsprovisionen, das Kunden zugeordnet wird. | `src/backend/Centron.BL/Sales/Receipts/ReceiptProvisionSchemaBL.cs` |
+| **Sondervereinbarung** (`SpecialAgreementI3D`) | Kunden- oder projektbezogene Preisabrede, die für bestimmte Artikel zwingend vorliegen muss. | `ReceiptBL.CheckIfArticlesWithLicenseeRequiredHaveASpecialAgreementI3D` |
+| **Sonderpreis** | Kundenbezogener Preis; zugleich Sortimentsquelle des Kundenportals. | `README.md`, Abschnitt „Contributing / 1. WebCart" |
+
+## C — Kunde, Adresse und Zugang
+
+| Begriff | Bedeutung | Fundstelle |
+|---|---|---|
+| **Kunde** (`Customer`, `KundenI3D`) | Geschäftspartner im historischen Adressmodell. | `src/backend/Centron.BL/CustomerArea/` |
+| **Konto** (`Account`) | Geschäftspartner im neuen Adressmodell; wird über die Einstellung `IsAccountManagementActive` anstelle des Kundenmodells aktiviert. | `src/backend/Centron.BL/Accounts/`, `ModuleRegistration.cs` Zeilen 103-111 |
+| **Adressstamm** | Fachliche Bezeichnung des Moduls zur Partnerverwaltung; heißt im alten Modell „Adressen & Belege", im neuen „Adressstamm". | `CrmAppModuleController`, `AccountManagementAppModuleController` |
+| **Web-Account** (`WebAccount`) | Zugang eines Kundenmitarbeiters zum Kundenportal; eigener Zugangstyp mit eigenen Web-Rechten. | `src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs` |
+| **Kundenadministrator** | Web-Recht 31005, das einem Kundenzugang die Verwaltung weiterer Zugänge und die Sicht auf alle Vorgänge seines Unternehmens erlaubt. | `WebRightsVisibility.AllowedRightIds` |
+| **Kreditlimit** (`CreditLimit`, `CreditLimitCalculationKind`) | Höchstbetrag des offenen Belegvolumens eines Kunden; Berechnungsart 1 = netto, sonst brutto, 2 = keine Prüfung. | `ReceiptBL.CheckIfCustomerLimitIsReached` |
+| **Filiale** (`Branch`, `BranchI3D`) | Organisatorische Untereinheit eines Mandanten; bestimmt Nummernkreis, Rechteumfang und Auswertungsabgrenzung. | `ReceiptBL.GetBranchForNewReceipt`, `AppRightsBL` |
+| **Filialherkunft** (`BranchOrigin`) | Regel, aus welcher Person die Filiale eines Belegs abgeleitet wird: `Creator` (Ersteller) oder `Adviser2` (zweiter Berater). | `ReceiptBL.GetBranchForNewReceipt` |
+| **Mandant** (`Mandator`, `MandantID`) | Rechtlich selbständige Einheit mit eigenen Stammdaten und eigener Bankverbindung. | `MandatorBL`, `SSMS_DB_SCHEMA.sql`, `Sichbenu.MandantID` |
+
+## D — Service und Helpdesk
+
+| Begriff | Bedeutung | Fundstelle |
+|---|---|---|
+| **Helpdesk / Ticket** (`Helpdesk`) | Serviceanfrage mit Status, Priorität, Typ, Kategorie, verantwortlicher Person und Fälligkeitsdatum. Beide Begriffe bezeichnen im Produkt denselben Gegenstand. | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs` |
+| **Ticketzeit** (`HelpdeskTimer`) | Erfasste Arbeitszeit an einem Ticket, bewertet über einen Mitarbeiterartikel und einen Zeitarttyp; Abrechnungsgrundlage. | `src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs` |
+| **Ticketvorlage / C-FLOW-Ticketvorlage** (`TicketPattern`) | Vorlage für einen Serviceprozess aus Allgemeinangaben, Kundenbezug, Checklisten, Formularen, Mailvorlage, Eigenschaften, Skripten, internen Angaben und Webformular. | `src/nexus/CentronNexus/Management/TicketPatterns/` |
+| **Ticketprozess-Vorlage** | Bezeichnung desselben Gegenstands im Windows-Client. | `TicketProcessTemplateAppModuleController` |
+| **Checkliste** | Abzuarbeitende Punkteliste an einem Ticket; wird aus einer Checklistenvorlage erzeugt, je Punkt mit eigenem Bearbeiter. | `CentronRights.md`, Abschnitt 16 |
+| **Eskalation** | Automatische Meldung bei Überschreitung einer Bearbeitungs- oder Reaktionsfrist; Eskalationstypen und Mailvorlagen sind getrennt konfigurierbar. | `src/backend/Centron.BL/Sales/Support/Escalation/EscalationBL.cs` |
+| **Erwartetes Event** (`ExpectedEvent`) | Ereignis, dessen Ausbleiben innerhalb eines Zeitfensters eine Meldung auslöst. | `src/backend/Centron.BL/ExpectedEvents/` |
+| **Einschränkendes Recht** (*restricting right*) | Recht, das den Datenausschnitt eines Benutzers verkleinert statt vergrößert, etwa `SHOW_HELPDESK_ONLY_OWN` oder `SHOW_HELPDESK_ONLY_OWN_BRANCH`. | `CentronRights.md`, Abschnitte 1.1 und 1.2 |
+| **RMA** | Rücksendungs- und Werkstattvorgang (*return merchandise authorisation*) mit eigener Versandart und Statusverfolgung. | `RmaOverviewAppModulController` |
+| **Taskmanagement / Todo-Liste** | Zwei getrennte Aufgabenverwaltungen: `TaskManager` (rechtegebunden, mit Historie und Ticketbezug) und `ToDoArea` (ohne Rechteprüfung). | `src/backend/Centron.BL/TaskManager/`, `ToDoArea/` |
+
+## E — Artikel, Bestand und Logistik
+
+| Begriff | Bedeutung | Fundstelle |
+|---|---|---|
+| **Artikel** (`Article`, `ArtikelI3D`, `ArticleCode`) | Zentraler Stammdatensatz für Verkauf, Einkauf, Lager und Preisfindung. | `src/backend/Centron.BL/Warehousing/ArticleBL.cs` |
+| **Warengruppe** (`MaterialGroup`) | Klassifizierung von Artikeln; besondere Warengruppen werden gesondert behandelt. | `MaterialGroupBL`, `MaterialGroupSettingsAppModuleSettingsController` |
+| **Nebenlager** (`SecondaryStock`, `secondaryStockI3D`) | Vom Hauptlager getrennter Lagerort; Bestände und Bedarfe werden je Artikel und Lagerort geführt. | `ArticleStockBL` |
+| **Aktionspreis** (`ActionPrice`, `HerstellerArtikAktionspreis`) | Zeitlich befristeter Preis eines Distributors oder Herstellers mit `GueltigAb`/`GueltigBis`. | `docs/reference/receipts/actionprice-system.md` |
+| **Stückliste** (`PartList`) | Artikel, der aus Komponenten besteht; im Beleg als aufklappbare Kopfposition mit Komponentenpositionen dargestellt. | `PartListArticleBL`, `ReceiptBL` Zeile 8046 |
+| **Barcode / Seriennummer** (`ReceiptItemBarcode`) | Gerätebezogene Kennung, die belegbezogen erfasst und gegen Menge, Dubletten und Verarbeitungsstand geprüft wird. | `src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptBarcodeBL.cs` |
+| **Kommissionierung** (`Commissioning`, `QuantityPicked`) | Bereitstellung der Auftragsware; die kommissionierte Menge wird je Position geführt. | `OrderCommissionBL`, `ReceiptBL.CheckIfQuantityIsReducedBelowPickedQuantity` |
+| **Inventur** (`Inventory`) | Aufnahme des Ist-Bestands und Buchung der Differenz zum Buchbestand. | `InventoryBL`, `InventoryNewBL` |
+
+## F — Gerät, Stammblatt und Managed Services
+
+| Begriff | Bedeutung | Fundstelle |
+|---|---|---|
+| **Stammblatt** (`MasterDataList`) | Geräteakte mit Seriennummer, Zählerstand, Kunde, Standortadresse, Ansprechpartner und Herkunftsbeleg (Rechnung mit Position und Datum). | `src/backend/Centron.Entities/Entities/Sales/Receipts/MasterDataLists/MasterDataList.cs` |
+| **Stammblattposition** (`MasterDataListItem`) | Einzelposition eines Stammblatts mit Artikel, Menge, Preisen und Barcodesammlung. | ebenda, `MasterDataListItem.cs` |
+| **Gerät** (`AccountDevice`) | Zweite, getrennte Datenhaltung für dasselbe fachliche Objekt „Gerät beim Kunden" mit Seriennummer, Modell, Hersteller, Standort und Garantieende. | `src/backend/Centron.Entities/Entities/Devices/AccountDevice.cs` |
+| **MSP** (*Managed Service Provider*) | Betriebsmodell, bei dem IT-Leistungen dauerhaft und nutzungsabhängig erbracht werden. Die MSP-Module sammeln Nutzungsdaten (`MSP-Collector`), vergleichen sie mit dem Vertragsbestand (`MSP-Auswertung`) und stellen sie dar (`MSP-Dashboard`). | `ModuleRegistration.cs` Zeilen 232-244 |
+| **RMM** (*Remote Monitoring and Management*) | Fremdsystem zur Fernüberwachung von Kundensystemen; liefert Geräte- und Leistungsdaten an die Vertragsabrechnung. | `src/backend/Centron.BL/DataExchange/Rmm/`, `docs/reference/receipts/Contract-Billing-RMM-Article-Logic.md` |
+| **PLM** (*Product Lifecycle Management*) | Überwachung des Lebenszyklus beim Kunden eingesetzter Produkte und Lizenzen. | `PlmAppModuleController`, `ProductLifecycleBL` |
+
+## G — Rechte, Lizenzen und Anmeldung
+
+| Begriff | Bedeutung | Fundstelle |
+|---|---|---|
+| **Recht** (`AppRight`, `Sichrech`, `I3D`) | Einzelberechtigung, identifiziert über eine ganzzahlige Kennung `I3D`; im Code ausschließlich über Konstanten in `UserRightsConst` zu verwenden. | `docs/guides/development/check-userrights.md` |
+| **Rechtegruppe** (`AppGroup`, `Sichtrus`) | Bündel von Rechten mit optionaler Filialzuordnung; Benutzer erhalten Rechte ausschließlich über Gruppenmitgliedschaft (`Sichmemb`). | `AppRightsBL.GetAllAppRightsFromUser` |
+| **Web-Recht** (`WebAccountRightsConst`) | Getrennter Rechtesatz für Kundenzugänge; die vergebbaren Rechte sind in einer Positivliste abschließend festgelegt. | `WebRightsVisibility` |
+| **Lizenz** | GUID, die ein Produkt oder Einzelmerkmal freischaltet; kann Anzahl, Gültigkeitsdatum und höchste Gültigkeitsversion tragen. | `docs/reference/security/licensing-system.md` |
+| **Anwendungsart** (`ApplicationKind`) | Beschreibung einer anmeldeberechtigten Anwendung mit Lizenz-GUID, erforderlichem Recht, ausschließendem Recht, Sitzungsdauer und Lizenzzählweise. | `Authenticator.GetTicket`, `TicketBL.GetExpireDate` |
+| **Ticket** (Sitzungsticket, `Ticket`) | Sitzungskennung nach erfolgreicher Anmeldung; anwendungsabhängige Gültigkeitsdauer. **Nicht zu verwechseln** mit dem Servicevorgang „Ticket" (siehe Abschnitt D). | `src/backend/Centron.BL/Administration/Logins/TicketBL.cs` |
+| **Benutzerkonto** (`AppUser`, `Sichbenu`) | Anmeldekonto eines Mitarbeiters; Deaktivierung wahlweise manuell (`KontoDeakMan`) oder über einen Zeitraum (`KontoDeakVon`/`KontoDeakBis`). | `Authenticator.ValidateAppUser` |
+| **Zwei-Faktor-Authentifizierung** | Zweiter Anmeldefaktor über RADIUS-Server oder E-Mail-Bestätigung; Gültigkeit kalendertagbezogen je Anwendung, Gerät und IP-Adresse. | `TwoFactorAuthBL` |
+| **Zugriffstoken** (`AccessToken`) | Widerrufbares Token für den Maschinenzugriff; 48 Zeichen, gespeichert ausschließlich als SHA-256-Hash. | `AccessTokenBL` |
+| **Hotline-Masterkey** | Schlüssel zur Ver- und Entschlüsselung der im Zugangsverwalter verwahrten Kennwörter; liegt in einer getrennten Konfigurationsdatenbank. | `PasswordManagerBL`, `CentronConfigurationDbBL.GetHotlineMasterKey` |
+
+## H — Finanzen und Datenaustausch
+
+| Begriff | Bedeutung | Fundstelle |
+|---|---|---|
+| **OPOS** | Offene Posten — noch nicht ausgeglichene Forderungen. Der offene Betrag ergibt sich als Bruttobetrag abzüglich Zahlungen und Gutschriften. | `DunningBL`, Zeilen 221-230 |
+| **Mahnstufe** (`DunningLevel`) | Vier Stufen: `None`, `Level1`, `Level2`, `Level3`. | `DunningBL` |
+| **SEPA-Lastschrift** | Einzugsverfahren im europäischen Zahlungsraum; unterstützt werden fünf PAIN-Formate von PAIN.008.001.01 bis PAIN.008.001.08 (GBIC 4). | `PaymentTransactionBL.GetInterfaceList` |
+| **SEPA-Mandat** (`MandatI3D`) | Einzugsermächtigung des Kunden; bei entsprechender Zahlungskondition Pflichtangabe am Beleg. | `ReceiptBL.CheckIfMandatIsNeeded` |
+| **Gläubiger-Identifikationsnummer** (`SepaIdentificationNumber`) | Kennung des einziehenden Unternehmens; stammt aus der Bankverbindung des Mandanten. | `PaymentTransactionBL.ExportInvoices` |
+| **ZUGFeRD / XRechnung** | Formate der strukturierten elektronischen Rechnung. Unterstützt: ZUGFeRD 1.0, 2.0/XRechnung 1.2, 2.1/XRechnung 2.0–2.3.1 und 2.1/XRechnung 3.0.1. Dokumenttyp „380" = Rechnung, „381" = Gutschrift. | `docs/reference/zugferd-field-mapping.md` |
+| **EDI** (*Electronic Data Interchange*) | Elektronischer Austausch von Bestellungen, Auftragsbestätigungen, Lieferavisen und Rechnungen mit Distributoren; je Lieferant eigenes Format. | `docs/reference/edi/edi-architecture.md` |
+| **Kontenrahmen** (`AccountSystem`) | Gliederung der Erlös- und Aufwandskonten für die Finanzbuchhaltung. | `src/backend/Centron.BL/Administration/BookKeepingAccountSystems/` |
+| **Kostenstelle / Kostenträger** (`CostCenter`, `CostObject`) | Getrennte Stammdaten der internen Kostenrechnung; ihre Angabe am Beleg kann jeweils eigenständig erzwungen werden. | `ReceiptBL`, Zeilen 3723-3724 |
+| **Ausweis ohne Mehrwertsteuer** (`ExclusiveOfVAT`) | Kennzeichen eines Belegs ohne Steuerausweis; im Inland nur bei vorliegender Umsatzsteuer-Identifikationsnummer zulässig. | `ReceiptBL.CheckIfExclusiveOfVatInInland` |
+
+## I — Technische Begriffe der Codebasis
+
+| Begriff | Bedeutung | Fundstelle |
+|---|---|---|
+| **I3D** | Durchgängige Bezeichnung des Primärschlüssels aller Entitäten; wird von `BaseEntity` bereitgestellt. Auch Rechtekennungen heißen `I3D`. | `src/backend/Centron.Entities/BaseEntity.cs` |
+| **Objektkennung + Objektart** (`ObjectI3D` + `ObjectKind`, `AnlageI3D` + `AnlageArt`) | Durchgängiges Muster für Verweise auf beliebige Geschäftsobjekte. | `docs/reference/receipts/receipts-backend-architecture.md` |
+| **BL** (`*BL`) | Geschäftslogikklasse; arbeitet auf NHibernate-Entitäten. | `docs/getting-started/general-structure.md` |
+| **WebServiceBL** (`*WebServiceBL`) | Schicht zwischen Geschäftslogik und Schnittstelle; wandelt Entitäten in Übertragungsobjekte. | ebenda |
+| **ILogic / BLLogic / WSLogic** | Dreiklang des Client-Datenzugriffs: Schnittstelle, Umsetzung über direkten Datenbankzugriff, Umsetzung über den Webservice. | ebenda, Abschnitt „Dual Implementation Architecture" |
+| **DTO** | Übertragungsobjekt zwischen Webservice und Oberfläche; verlässt im Gegensatz zur Entität die Geschäftslogikschicht. | `docs/reference/architecture/dtos-and-entities.md` |
+| **Result / Result\<T\>** | Einheitliches Ergebnisobjekt mit `Status` (`Success`, `Error`, `Warning`), `Message`, `MessageCode` und `Error`. | `docs/reference/architecture/results-and-responses.md` |
+| **Meldungscode** (`DefaultMessageCodes`) | Maschinenlesbare Fehlerkennung, etwa `LoginFailed`, `RightCheckFailed`, `LicenseMaximumReached`, `TwoFactorAuthFailed`. | `Authenticator`, `LicenseManager` |
+| **SpecificLogics** | Muster, über das belegartabhängiges Verhalten aus der gemeinsamen Belegverarbeitung heraus aufgerufen wird. | `docs/reference/receipts/receipts-backend-architecture.md` |
+| **Temporäre Legacy-Entität** | Zweite Entitätsschicht, die die historischen deutschsprachigen Tabellen abbildet; über sie läuft der Speicherpfad der Belege. | ebenda, Abschnitt „Critical Save Warning" |
+| **Skriptmethode** (`ScriptMethod{Nummer}`) | Nummerierte, versionierte Klasse mit einer Schemamigration; 790 Stück im Bestand. | `docs/reference/database/script-rules.md` |
+| **Modulcontroller** (`*AppModuleController`) | Klasse, die ein Anwendungsmodul des Windows-Clients beschreibt: Name, Beschreibung, Kategorie, Symbol, Reportgruppe, unterstützte Verbindungsarten und Rechte. | `src/centron/Centron.WPF.UI/Modules/` |
+| **Verbindungsart** (`CentronConnectionType`) | `SqlServer` (direkte Datenbankverbindung) oder `CentronWebServices` (Verbindung über den Webservice). | `CentronModule.OpenModule` |
+| **Rückmeldeflagge** (`Show…Dialog`) | Feld im Ergebnisobjekt des Speichervorgangs, über das die Geschäftslogik eine Rückfrage an den Anwender anfordert, ohne die Oberfläche zu kennen. | `ReceiptBL`, `SaveReceiptResultBuilder` |
+| **Rückfragen unterdrücken** (`IgnoreCallbacks`) | Schalter, der sämtliche Rückfragen für automatisierte Läufe abschaltet. | `ReceiptBL.SaveReceipt` |
+
+## J — Produkte und Teilsysteme
+
+| Begriff | Bedeutung | Fundstelle |
+|---|---|---|
+| **c-entron.NET** | Windows-Client der Suite (WPF, DevExpress). | `src/centron/Centron.WPF.UI/` |
+| **c-entron Nexus** (auch „c-entron Web") | Blazor-Webportal mit ServiceBoard, Kundenportal und Verwaltung. | `README.md`, `src/nexus/CentronNexus/` |
+| **ServiceBoard** | Bereich des Webportals für die Ticketbearbeitung durch interne Benutzer. | `src/nexus/CentronNexus/ServiceBoard/` |
+| **WebCart** | Bereich des Webportals für Kunden: Shop, Warenkorb, Belege, Tickets, Dokumente und Formulare. | `src/nexus/CentronNexus/WebCart/` |
+| **SelfCare-Formular** | Konfigurierbares Kundenformular mit Zuständen, Auslösern und Folgeaktionen. | `src/backend/Centron.BL/SelfCare/SelfCareBL.cs` |
+| **c-entron Office** | Werkzeug des Herstellers zur Verwaltung der Lizenzen; der Client bezieht Lizenzen ersatzweise über den Webservice. | `docs/reference/security/licensing-system.md`, `FakeOfficeClient` |
+| **Riverbird / RiverSuite** | Schwesterprodukt mit geteilten Bausteinen, eigener Auslieferung und eigener Rechteauswahl. | `deployment/riverbird/`, `AppRightsBL.GetRiversuiteRelevantRights` |
+| **c-entron Delphi** | Vorgängergeneration des Produkts mit eigenem Versionsschema (9.3.x.y), die sich Lizenz und Datenbank mit c-entron.NET teilt. | `LicenseManager.TryFixCentronDelphiVersionNumber` |
+| **DocuBoard / Asset Management** | Bereich zur Erfassung von IT-Beständen beim Kunden (Systeme, Ordnerberechtigungen, Verzeichnisbenutzer, SNMP-Geräte). | `src/backend/Centron.BL/DocuBoard/` |

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-37c5/Ergebnisse/Hypothesen.md

@@ -0,0 +1,436 @@
+# Hypothesen — offene Punkte der Reverse-Requirements-Analyse
+
+**System:** NEXOWARE c-entron ERP-Suite  
+**Erhebungsart:** rein statische Analyse ohne Ausführung des Systems und ohne Rückfrage bei Fachexperten
+
+## 1. Inhalt und Abgrenzung dieser Datei
+
+Diese Datei enthält **genau** die Anforderungen, die in `StRS.md`, `SyRS.md` oder `SwRS.md` mit `Status: HYPOTHESE` geführt und in der Aussage mit `[HYPOTHESE]` markiert sind — keine zusätzlichen freien Fragen. Offene Punkte ohne zugehörige Anforderung stehen in der Selbstbewertung des `Analysebericht.md`.
+
+Eine Hypothese bedeutet hier **nicht**, dass die technische Beobachtung unbelegt wäre: Jede aufgeführte Anforderung führt mindestens einen `PRIMÄR`-Beleg. Als Hypothese gekennzeichnet ist jeweils der **fachliche Schluss**, der aus der Beobachtung gezogen wird — insbesondere dort, wo aus dem Fehlen einer Codestelle auf das Fehlen einer Funktion geschlossen wird. Ein solcher Negativbefund ist statisch nicht abschließend beweisbar und daher grundsätzlich als Hypothese geführt.
+
+**Anzahl:** 33 von 434 Anforderungen (7.6%)
+
+| Ebene | Hypothesen |
+|---|---|
+| StRS | 5 |
+| SyRS | 17 |
+| SwRS | 11 |
+
+## 2. Übersicht
+
+| ID | Titel | Offene Frage in einem Satz |
+|---|---|---|
+| StRS-096 | Verträge verlängern sich automatisch | Ob und wo diese Verlängerung ausgelöst wird, ist nicht belegbar |
+| StRS-097 | Verträge werden gegen eine Überwachungsschwelle geprüft | Ob eine solche Prüfung stattfindet, ist nicht belegbar |
+| StRS-098 | Kennwörter müssen nach einer festgelegten Frist gewechselt werden | Eine solche Durchsetzung ist im analysierten Code nicht auffindbar |
+| StRS-099 | Gutscheine werden als eigener Geschäftsgegenstand geführt | Ob die Funktion für Anwender erreichbar ist, ist nicht belegbar |
+| StRS-100 | Kunden-IT-Bestände werden über ein Asset Management erfasst | Der fachliche Zweck und die Erreichbarkeit dieser Funktion sind nicht abschließend belegbar |
+| SyRS-039 | Fehlgeschlagene Anmeldungen werden protokolliert, sperren das Konto aber nicht | Eine automatische Kontosperre nach einer festgelegten Zahl von Fehlversuchen findet nicht statt |
+| SyRS-190 | Belegnummern sind systemweit eindeutig | Ob die Eindeutigkeit bei gleichzeitiger Vergabe gewahrt bleibt, ist nicht belegbar |
+| SyRS-191 | Referentielle Integrität wird in der Datenhaltung erzwungen | Ob dies bei nur 134 Fremdschlüsseln auf 1.535 Tabellen gewährleistet ist, ist nicht belegbar |
+| SyRS-192 | Belegzustandsübergänge unterliegen einer Übergangsprüfung | Eine abschließende Übergangsprüfung ist nicht auffindbar |
+| SyRS-193 | Die Datenbankverbindung wird verschlüsselt hinterlegt | Ob der Klartextweg im Kundenbetrieb verwendet wird, ist aus der Codebasis nicht ableitbar |
+| SyRS-194 | Die Verbindung zum Webservice ist transportverschlüsselt | Ob dies im Betrieb geschieht, ist aus der Codebasis nicht ableitbar |
+| SyRS-195 | Für personenbezogene Daten bestehen Aufbewahrungsfristen | Hinterlegte Fristen sind nicht auffindbar |
+| SyRS-196 | Für Antwortzeiten bestehen messbare Vorgaben | Zielwerte sind in der Codebasis nicht hinterlegt |
+| SyRS-197 | Für Verfügbarkeit und Datensicherung bestehen Vorgaben | Solche Vorgaben sind in der Codebasis nicht hinterlegt |
+| SyRS-198 | Die Oberfläche erfüllt Anforderungen an Barrierefreiheit | Entsprechende Vorgaben sind in der Codebasis nicht auffindbar |
+| SyRS-199 | Mandantendaten sind auf Datenebene voneinander getrennt | Eine durchgängige mandantenbezogene Filterung ist nicht auffindbar |
+| SyRS-200 | Rechteänderungen wirken ohne neue Anmeldung | Eine Ungültigmachung des Rechtezwischenspeichers nach einer Rechteänderung ist nicht auffindbar |
+| SyRS-201 | Das Riverbird-Produkt teilt sich Bestandteile mit c-entron | Die Abgrenzung beider Produkte und der Umfang der geteilten Bestandteile sind aus der Codebasis nicht abschließend erschließbar |
+| SyRS-202 | Der Concerto-Baustein bedient einen Bestellformatstandard | Der fachliche Zweck, der Partner und die Verwendung dieses Formats sind aus der Codebasis nicht erschließbar |
+| SyRS-203 | Der IT-Planer strukturiert Prüfobjekte für Checklisten | Der fachliche Zweck des Bereichs „ItPlanner" ist aus der Codebasis nicht erschließbar |
+| SyRS-204 | Die docuFORM-Anbindung liefert Gerätezählerstände | Der genaue Umfang der übernommenen Daten ist aus der Codebasis nicht abschließend erschließbar |
+| SyRS-205 | Zeitangaben werden einheitlich in einer Zeitzone geführt | Die durchgängige Verwendung der Ortszeit ohne Zeitzonenangabe ist belegt |
+| SwRS-190 | Zeitstempel werden zeitzonensicher gebildet | Da weder Anwendungscode noch Datenmodell einen Zeitzonenanteil führen, ist die Eindeutigkeit nur bei einheitlicher Serverzeitzone gegeben |
+| SwRS-191 | Die Nummernvergabe ist gegen gleichzeitige Zugriffe gesichert | Ein Sicherungsmechanismus ist nicht auffindbar |
+| SwRS-192 | Die als unsicher geltende Binärserialisierung wird nur für einen Zweck genutzt | Die Beschränkung auf diesen Zweck beruht ausschließlich auf einem Kommentar |
+| SwRS-193 | Die automatisierte Prüfung deckt die Fachlogik ausreichend ab | Der erreichte Abdeckungsgrad ist ohne Ausführung der Prüfungen nicht feststellbar |
+| SwRS-194 | Alle Projekte liegen unterhalb des Quellverzeichnisses | Mindestens ein Projekt weicht davon ab |
+| SwRS-195 | Fremdbestandteile werden ausschließlich über Paketverwaltung bezogen | Herkunft, Lizenzstand und Aktualität der lokal abgelegten Pakete und Binärbestandteile sind aus der Codebasis nicht feststellbar |
+| SwRS-196 | Das Delphi-Vorgängersystem greift auf dieselbe Datenbank zu | Ob das Vorgängersystem noch produktiv betrieben wird und welche Bereiche es schreibt, ist aus der Codebasis nicht feststellbar |
+| SwRS-197 | Statische Zwischenspeicher sind für den Mehrmandantenbetrieb geeignet | Ob die statischen Zustände im Mehrmandantenbetrieb unbedenklich sind, ist ohne Ausführung nicht feststellbar |
+| SwRS-198 | Die zweite Steuerelementbibliothek dient der Produktvorschau | Der Zusammenhang zwischen `Centron.Controls.Preview` und `LicenseGuids.ProductPreview` ist nicht belegbar |
+| SwRS-199 | Migrationsskripte enthalten keine fachlichen Regeln | Mindestens die Steuersatzumrechnung liegt sowohl in Skripten als auch in der Geschäftslogik vor |
+| SwRS-200 | Die Anbindung fremder Ticketsysteme ist produktiv nutzbar | Ob und wie eine solche Anbindung konfiguriert wird, ist nicht belegbar |
+
+## 3. Einzelaufstellung
+
+### StRS-096 — Verträge verlängern sich automatisch
+
+- **Ebene / Typ:** StRS / funktional (Akteur:        Buchhalter, Vertriebsmitarbeiter)
+- **Akteur:** Buchhalter, Vertriebsmitarbeiter
+- **Belegte Beobachtung (Fakt):** Das Merkmal `AutomatedProlongation` ist an vier Stellen modelliert (`IReceiptWithContractInformation`, `IContractHead`, `ReceiptContract`, `AccountContract`), über `ReceiptContractHeadMaps`/`ReceiptContractBaseMaps` auf die Spalte `AutomatedProlongation` abgebildet, über `SaveReceiptContractRepository.cs` Zeile 292 in die Legacy-Spalte `AutoVerlaengerung` geschrieben und in `AccountContract.cs` Zeile 124 aus der Vertragsart vorbelegt. Eine Stelle, die bei Ablauf eines Vertrags anhand dieses Merkmals das Vertragsende fortschreibt, ist in der analysierten Codebasis nicht auffindbar.
+- **Angenommene Soll-Aussage:** Das System soll Verträge mit gesetztem Verlängerungsmerkmal bei Erreichen des Vertragsendes automatisch um eine weitere Laufzeitperiode verlängern.
+- **Offene Frage / fehlende Information:** Ob und wo diese Verlängerung ausgelöst wird, ist nicht belegbar; zur Bestätigung fehlt eine auswertende Stelle für `AutomatedProlongation` außerhalb von Speichern, Abbilden und Vorbelegen.
+- **Belegsituation:** 3 Belege — PRIMÄR, PRIMÄR, KONTEXT; erster PRIMÄR-Beleg: `src/backend/Centron.DAO/Repositories/Sales/Receipts/ContractList/SaveReceiptContractRepository.cs`, Zeile 292 (`receiptTable.AutoVerlaengerung = receipt.AutomatedProlongation ? 1 : 0;`)
+- **Klärung durch:** Einen Vertrag mit gesetztem Merkmal und Vertragsende in der Vergangenheit anlegen und den Abrechnungslauf ausführen; das Verhalten des Systems belegt oder widerlegt die automatische Verlängerung.
+- **Übernahmewürdigkeit:** übernehmen — automatische Verlängerung ist bei Dauerschuldverhältnissen fachlich erforderlich, unabhängig davon, ob sie derzeit ausgeführt wird.
+
+### StRS-097 — Verträge werden gegen eine Überwachungsschwelle geprüft
+
+- **Ebene / Typ:** StRS / funktional (Akteur:        Servicetechniker, Buchhalter)
+- **Akteur:** Servicetechniker, Buchhalter
+- **Belegte Beobachtung (Fakt):** `ReceiptContract` führt `IsMonitoring` und `MonitoringValue` (Zeilen 144-145); beide sind über `ReceiptContractBaseMaps` abgebildet, über `SaveReceiptContractRepository` Zeilen 415-416 persistiert und über `ReceiptLogBL.CreateIsMonitoringEntry` bzw. `CreateMonitoringValueEntry` bei Änderung protokolliert. Eine Stelle, die den Schwellwert gegen einen Ist-Wert prüft und daraus eine Meldung erzeugt, ist nicht auffindbar; die einzige Auswertung in `ReceiptBL` (Zeilen 10477-10478) vergleicht lediglich alten und neuen Feldwert für das Protokoll.
+- **Angenommene Soll-Aussage:** Das System soll bei Erreichen des je Vertrag gesetzten Überwachungswerts eine Meldung erzeugen.
+- **Offene Frage / fehlende Information:** Ob eine solche Prüfung stattfindet, ist nicht belegbar; zur Bestätigung fehlt eine Stelle, die `MonitoringValue` mit einem Ist-Wert vergleicht.
+- **Belegsituation:** 3 Belege — PRIMÄR, PRIMÄR, SEKUNDÄR; erster PRIMÄR-Beleg: `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 10477-10478
+- **Klärung durch:** Einen Vertrag mit Überwachungswert anlegen, den Wert im laufenden Betrieb überschreiten und prüfen, ob eine Meldung entsteht.
+- **Übernahmewürdigkeit:** übernehmen — Schwellwertüberwachung ist bei Managed-Service-Verträgen fachlich erforderlich.
+
+### StRS-098 — Kennwörter müssen nach einer festgelegten Frist gewechselt werden
+
+- **Ebene / Typ:** StRS / Sicherheit (Akteur:        alle internen Benutzer)
+- **Akteur:** alle internen Benutzer
+- **Belegte Beobachtung (Fakt):** `AppUser` führt `PasswordValidDurationDays` (Spalte `KennAendNachTagen`) und `LastPasswordChangedDate` (Spalte `LetzKennAend`); beide sind in `AppUserMaps` abgebildet, werden in `UsersBL.UpdatePassword` fortgeschrieben (`user2.LastPasswordChangedDate = DateTime.Now;`), in `AppUserBL` auf einen Ausgangswert gesetzt (`new DateTime(1899, 12, 30)`) und im Buchhaltungsaustausch übertragen. Der Anmeldepfad (`Authenticator.ValidateAppUser`) wertet keines der beiden Felder aus; `UsersBL.IsValidAppUserPassword` prüft ausschließlich die Mindestlänge.
+- **Angenommene Soll-Aussage:** Das System soll eine Anmeldung nach Ablauf der hinterlegten Kennwortgültigkeitsdauer nur nach einem Kennwortwechsel zulassen.
+- **Offene Frage / fehlende Information:** Eine solche Durchsetzung ist im analysierten Code nicht auffindbar; zur Bestätigung fehlt eine Auswertung von `PasswordValidDurationDays` und `LastPasswordChangedDate` im Anmeldepfad.
+- **Belegsituation:** 3 Belege — PRIMÄR, PRIMÄR, PRIMÄR; erster PRIMÄR-Beleg: `src/backend/Centron.BL/Administration/Logins/UsersBL.cs`, Zeilen 123-129
+- **Klärung durch:** Bei einem Benutzer `KennAendNachTagen` auf 1 und `LetzKennAend` auf ein Datum vor mehr als einem Tag setzen und anmelden; gelingt die Anmeldung ohne Wechselaufforderung, ist die Hypothese bestätigt.
+- **Übernahmewürdigkeit:** übernehmen — eine Kennwortrichtlinie mit Wechselfrist ist im Zielsystem zu führen; das Datenmodell sieht sie bereits vor.
+
+### StRS-099 — Gutscheine werden als eigener Geschäftsgegenstand geführt
+
+- **Ebene / Typ:** StRS / funktional (Akteur:        Vertriebsmitarbeiter)
+- **Akteur:** Vertriebsmitarbeiter
+- **Belegte Beobachtung (Fakt):** `src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs` (`public class VoucherManagementBL : BaseBL`) und `src/backend/Centron.Entities/Entities/VoucherManagement/` bestehen als eigene Bereiche. Ein zugehöriges Anwendungsmodul, eine Einstellungsseite oder eine API-Ressource ist in `ModuleRegistration`, `GetSettingsWithoutModule()` und den v1-Controllern nicht auffindbar.
+- **Angenommene Soll-Aussage:** Das System soll Gutscheine ausgeben, einlösen und ihren Stand verwalten.
+- **Offene Frage / fehlende Information:** Ob die Funktion für Anwender erreichbar ist, ist nicht belegbar; zur Bestätigung fehlt ein Modul, eine Einstellungsseite oder eine Schnittstelle, die `VoucherManagementBL` aufruft.
+- **Belegsituation:** 2 Belege — PRIMÄR, PRIMÄR; erster PRIMÄR-Beleg: `src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs`
+- **Klärung durch:** Die Aufrufer von `VoucherManagementBL` ermitteln; fehlen sie außerhalb von Tests, ist die Funktion nicht erreichbar.
+- **Übernahmewürdigkeit:** übernehmen — Gutscheine sind ein gängiges Vertriebsinstrument; der Reifegrad der vorliegenden Umsetzung ist fachlich zu klären.
+
+### StRS-100 — Kunden-IT-Bestände werden über ein Asset Management erfasst
+
+- **Ebene / Typ:** StRS / funktional (Akteur:        Servicetechniker)
+- **Akteur:** Servicetechniker
+- **Belegte Beobachtung (Fakt):** `src/backend/Centron.BL/DocuBoard/` enthält `AssetManagementADSystemUserExclusionBL`, `AssetManagementArticleAssignmentBL` und `AssetManagementPartnerBL`; die zugehörigen Entitäten liegen in `Entities/DocuBoard/` (`AssetManagementPartner`, `AssetManagementPartnerItem`, `AssetManagementADSystemUserExclusion`, `AssetManagementArticleAssignment`). Das Datenbankschema führt weitere Tabellen desselben Namensraums (`AssetManagementCheckResultsHistory`, `AssetManagementFolderPermissions`, `AssetManagementSNMPOidClasses`). Ein zugehöriges Anwendungsmodul ist in `ModuleRegistration` nicht auffindbar.
+- **Angenommene Soll-Aussage:** Das System soll IT-Bestände beim Kunden — Systeme, Ordnerberechtigungen, Verzeichnisbenutzer und über SNMP erreichbare Geräte — erfassen und einem Partner zuordnen.
+- **Offene Frage / fehlende Information:** Der fachliche Zweck und die Erreichbarkeit dieser Funktion sind nicht abschließend belegbar; zur Bestätigung fehlen eine Modulanbindung und eine Beschreibung des Bereichs „DocuBoard".
+- **Belegsituation:** 2 Belege — PRIMÄR, PRIMÄR; erster PRIMÄR-Beleg: `src/backend/Centron.BL/DocuBoard/AssetManagementPartnerBL.cs`, `AssetManagementArticleAssignmentBL.cs`, `AssetManagementADSystemUserExclusionBL.cs`
+- **Klärung durch:** Die Aufrufer der drei Bausteine ermitteln und die Herkunft der Daten in den Tabellen prüfen.
+- **Übernahmewürdigkeit:** übernehmen — Bestandserfassung beim Kunden ist Grundlage des Managed-Service-Geschäfts; die Zusammenführung mit Stammblatt und Gerät ist zwingend.
+
+### SyRS-039 — Fehlgeschlagene Anmeldungen werden protokolliert, sperren das Konto aber nicht
+
+- **Ebene / Typ:** SyRS / Sicherheit (Akteur:        Komponente `Authenticator`)
+- **Akteur:** Komponente `Authenticator`
+- **Belegte Beobachtung (Fakt):** `BasicAuthenticator` protokolliert bei Misserfolg `Logger.Warn("Basic authentication failed for user: {UserName}. Context: {AuthObject}", ...)`, wobei `AuthObject.ToString()` Anfrage-Kennung, Anwendungsversion, Anwendungsname, Gerätename und IP-Adresse enthält. Die Tabelle `Sichbenu` führt eine Spalte `AnmeldungFehlgeschlagen`, die in `AppUserMaps` auf die Eigenschaft `AuthenticationFailed` abgebildet ist. Eine Auswertung dieser Eigenschaft zur Kontosperre nach mehreren Fehlversuchen ist in der analysierten Codebasis nicht auffindbar.
+- **Angenommene Soll-Aussage:** Das System soll fehlgeschlagene Anmeldeversuche mit Kontextangaben protokollieren.
+- **Offene Frage / fehlende Information:** Eine automatische Kontosperre nach einer festgelegten Zahl von Fehlversuchen findet nicht statt; zur Bestätigung fehlt eine Auswertung der Spalte `AnmeldungFehlgeschlagen` außerhalb von Zuordnung und Datenübernahme.
+- **Belegsituation:** 3 Belege — PRIMÄR, PRIMÄR, SEKUNDÄR; erster PRIMÄR-Beleg: `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`, Zeile 55
+- **Klärung durch:** Zehnmal mit falschem Kennwort anmelden und anschließend mit korrektem Kennwort; die Anmeldung muss gelingen — das belegt das Fehlen einer Sperre.
+- **Übernahmewürdigkeit:** übernehmen — die Protokollierung ist beizubehalten; eine Sperre oder Verzögerung nach Fehlversuchen ist im Zielsystem zu ergänzen.
+
+### SyRS-190 — Belegnummern sind systemweit eindeutig
+
+- **Ebene / Typ:** SyRS / Daten (Akteur:        Datenbank, Komponente `NumberGroupBL`)
+- **Akteur:** Datenbank, Komponente `NumberGroupBL`
+- **Belegte Beobachtung (Fakt):** `dbo.RechKopf` führt `[Nummer] [int] NOT NULL` ohne Eindeutigkeitsbedingung; im gesamten Schema bestehen nur 21 `UNIQUE NONCLUSTERED`-Bedingungen (unter anderem `IX_AccountCustomers_UniqueNumber`, `IX_AccountSuppliers_UniqueNumber`), keine davon auf einer Belegnummernspalte. Die Eindeutigkeit wird ausschließlich durch `NumberGroupBL.GetNextNumber` in der Anwendung hergestellt.
+- **Angenommene Soll-Aussage:** Das System soll die Eindeutigkeit von Belegnummern je Nummernkreis sicherstellen.
+- **Offene Frage / fehlende Information:** Ob die Eindeutigkeit bei gleichzeitiger Vergabe gewahrt bleibt, ist nicht belegbar; zur Bestätigung fehlt entweder eine Eindeutigkeitsbedingung in der Datenbank oder eine nachweisbare Sperre in `NumberGroupBL`.
+- **Belegsituation:** 3 Belege — PRIMÄR, PRIMÄR, PRIMÄR; erster PRIMÄR-Beleg: `SSMS_DB_SCHEMA.sql`, `dbo.RechKopf`, Zeile 3233 (`[Nummer] [int] NOT NULL`)
+- **Klärung durch:** Zwei Belege derselben Art gleichzeitig aus zwei Sitzungen anlegen; erhalten beide dieselbe Nummer, ist die Hypothese bestätigt.
+- **Übernahmewürdigkeit:** übernehmen — die Eindeutigkeit ist handelsrechtlich gefordert und im Zielsystem zusätzlich in der Datenhaltung abzusichern.
+
+### SyRS-191 — Referentielle Integrität wird in der Datenhaltung erzwungen
+
+- **Ebene / Typ:** SyRS / Daten (Akteur:        Datenbank)
+- **Akteur:** Datenbank
+- **Belegte Beobachtung (Fakt):** Das Schema enthält 1.535 Tabellen, aber nur 134 `FOREIGN KEY`-Klauseln. Die Beziehungen werden überwiegend über Kennungsfelder ohne Fremdschlüsselbedingung abgebildet (`KundenI3D`, `ArtikelI3D`, `VertragKopfI3D`, `HeadI3D`); das durchgängige Muster „Objektkennung + Objektart" (`AnlageI3D` + `AnlageArt`) lässt sich technisch ohnehin nicht als Fremdschlüssel abbilden.
+- **Angenommene Soll-Aussage:** Das System soll die Beziehungen zwischen Geschäftsobjekten widerspruchsfrei halten.
+- **Offene Frage / fehlende Information:** Ob dies bei nur 134 Fremdschlüsseln auf 1.535 Tabellen gewährleistet ist, ist nicht belegbar; zur Bestätigung fehlt eine Prüfung, welche Beziehungen ausschließlich anwendungsseitig gesichert sind.
+- **Belegsituation:** 3 Belege — PRIMÄR, PRIMÄR, KONTEXT; erster PRIMÄR-Beleg: `SSMS_DB_SCHEMA.sql`, 1.535 `CREATE TABLE` gegenüber 134 `FOREIGN KEY`
+- **Klärung durch:** Einen Beleg löschen und die verweisenden Protokolleinträge prüfen; verbleiben verwaiste Verweise, ist die Hypothese bestätigt.
+- **Übernahmewürdigkeit:** übernehmen — im Zielsystem ist die referentielle Integrität in der Datenhaltung abzusichern, soweit das Objektartmuster durch echte Beziehungen ersetzt wird.
+
+### SyRS-192 — Belegzustandsübergänge unterliegen einer Übergangsprüfung
+
+- **Ebene / Typ:** SyRS / funktional (Akteur:        Komponente `ReceiptBL`)
+- **Akteur:** Komponente `ReceiptBL`
+- **Belegte Beobachtung (Fakt):** `ReceiptState` kennt drei Zustände. `ReceiptBL` setzt den Zustand an mindestens einer Stelle unmittelbar (`receipt.State = ReceiptState.Completed;` in `UpdateReceiptStateFromPaymentCondition`) und ruft `CheckCloseReceipt(receipt, data, result)` im Prüfblock. Eine Stelle, die zulässige Übergänge zwischen den drei Zuständen abschließend festlegt — etwa eine Übergangstabelle oder eine Prüfung „von-nach" —, ist nicht auffindbar.
+- **Angenommene Soll-Aussage:** Das System soll unzulässige Zustandsübergänge eines Belegs verhindern, etwa den Wechsel von „storniert" zurück nach „offen".
+- **Offene Frage / fehlende Information:** Eine abschließende Übergangsprüfung ist nicht auffindbar; zur Bestätigung fehlt eine Stelle, die Ausgangs- und Zielzustand gemeinsam auswertet.
+- **Belegsituation:** 2 Belege — PRIMÄR, PRIMÄR; erster PRIMÄR-Beleg: `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeile 8355 (`receipt.State = ReceiptState.Completed;`)
+- **Klärung durch:** Einen stornierten Beleg auf „offen" setzen und speichern; gelingt dies, ist die Hypothese bestätigt.
+- **Übernahmewürdigkeit:** übernehmen — eine ausdrückliche Zustandsmaschine ist im Zielsystem vorzusehen.
+
+### SyRS-193 — Die Datenbankverbindung wird verschlüsselt hinterlegt
+
+- **Ebene / Typ:** SyRS / Sicherheit (Akteur:        Systembetreiber)
+- **Akteur:** Systembetreiber
+- **Belegte Beobachtung (Fakt):** `WebServiceConfigSerializer` liest zunächst `DatabaseConnectionString` als verschlüsselten Wert (`GetEncryptedValue(...)`) und greift nur bei leerem Ergebnis auf `DatabaseConnectionStringPlain` zurück (Zeilen 41-44); beim Schreiben wird stets verschlüsselt (`new AESCryptoLogic().EncryptText(config?.DatabaseConnectionString)`, Zeile 163). Die mitgelieferte Betriebskonfiguration `docker/compose/WebServiceConfig.xml` lässt `DatabaseConnectionString` leer und trägt die Verbindung im Klartext in `DatabaseConnectionStringPlain` ein, einschließlich Kennwort.
+- **Angenommene Soll-Aussage:** Das System soll die Datenbankverbindung verschlüsselt hinterlegen; der Klartextweg besteht als Rückfallmöglichkeit fort und wird in der mitgelieferten Betriebskonfiguration genutzt.
+- **Offene Frage / fehlende Information:** Ob der Klartextweg im Kundenbetrieb verwendet wird, ist aus der Codebasis nicht ableitbar; zur Bestätigung fehlt Einblick in ausgelieferte Konfigurationen.
+- **Belegsituation:** 2 Belege — PRIMÄR, PRIMÄR; erster PRIMÄR-Beleg: `src/backend/Centron.BL/Administration/WebServiceConfiguration/WebServiceConfigSerializer.cs`, Zeilen 41-44 und 163
+- **Klärung durch:** Eine Konfiguration über die Anwendung schreiben lassen und die Datei prüfen; `DatabaseConnectionString` muss verschlüsselt gefüllt und `DatabaseConnectionStringPlain` leer sein.
+- **Übernahmewürdigkeit:** Workaround — der Klartextweg ist im Zielsystem zu entfernen und durch ein Geheimnisverwaltungsverfahren zu ersetzen.
+
+### SyRS-194 — Die Verbindung zum Webservice ist transportverschlüsselt
+
+- **Ebene / Typ:** SyRS / Sicherheit (Akteur:        Systembetreiber)
+- **Akteur:** Systembetreiber
+- **Belegte Beobachtung (Fakt):** `WebServiceConfig` führt `WebServiceCertificateFilePath` und `WebServiceCertificatePassword`; `CentronHost.cs` Zeile 136 verwendet den Pfad beim Aufbau des Hosts. Das Portal lädt sein Zertifikat über `X509CertificateLoader.LoadPkcs12FromFile(hostConfig.LinuxCertificatePath, hostConfig.LinuxCertificatePassword)`. In den mitgelieferten Konfigurationen sind beide Zertifikatsangaben leer, und die Adressen lauten `http://localhost:1234/CentronService` beziehungsweise `http://localhost:8050`.
+- **Angenommene Soll-Aussage:** Das System soll die Verbindung zwischen Client, Portal und Webservice transportverschlüsseln.
+- **Offene Frage / fehlende Information:** Ob dies im Betrieb geschieht, ist aus der Codebasis nicht ableitbar; die mitgelieferten Konfigurationen verwenden unverschlüsselte Verbindungen, was für eine Entwicklungsumgebung erwartbar ist.
+- **Belegsituation:** 3 Belege — PRIMÄR, PRIMÄR, PRIMÄR; erster PRIMÄR-Beleg: `src/nexus/CentronNexus.Host/Program.cs`, Zeile 145
+- **Klärung durch:** Ein Zertifikat hinterlegen und die Erreichbarkeit über `https` prüfen; zusätzlich prüfen, ob der unverschlüsselte Zugang dann abgeschaltet ist.
+- **Übernahmewürdigkeit:** übernehmen — Transportverschlüsselung ist im SaaS-Zielsystem verpflichtend und darf nicht abschaltbar sein.
+
+### SyRS-195 — Für personenbezogene Daten bestehen Aufbewahrungsfristen
+
+- **Ebene / Typ:** SyRS / Sicherheit (Akteur:        Administrator, Datenschutzbeauftragter)
+- **Akteur:** Administrator, Datenschutzbeauftragter
+- **Belegte Beobachtung (Fakt):** `DataSecurityBL.GetDataSecurityCleanUpStats(AppUser currentUser, DataSecurityCleanUpStatsFilter filter)` nimmt einen Filter entgegen, dessen Aufbau die Abgrenzung der zu bereinigenden Daten bestimmt; die Bereinigung wird ausschließlich manuell über `DataSecurityExecuteCleanUp` ausgelöst. Eine hinterlegte Aufbewahrungsfrist je Datenart oder eine automatische Bereinigung nach Fristablauf ist nicht auffindbar; der Datenqualitätsdienst führt laut Dokumentation Aufräumarbeiten aus, ohne dass Fristen benannt sind.
+- **Angenommene Soll-Aussage:** Das System soll personenbezogene Daten nach Ablauf einer je Datenart festgelegten Aufbewahrungsfrist selbsttätig löschen oder zur Löschung vorschlagen.
+- **Offene Frage / fehlende Information:** Hinterlegte Fristen sind nicht auffindbar; zur Bestätigung fehlt eine Konfigurationsstelle für Aufbewahrungsfristen.
+- **Belegsituation:** 2 Belege — PRIMÄR, KONTEXT; erster PRIMÄR-Beleg: `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs`, Zeilen 34-63
+- **Klärung durch:** Die Einstellungsliste nach einer Fristkonfiguration durchsuchen; fehlt sie, ist die Hypothese bestätigt.
+- **Übernahmewürdigkeit:** übernehmen — Löschfristen sind datenschutzrechtlich gefordert und im Zielsystem konfigurierbar vorzusehen.
+
+### SyRS-196 — Für Antwortzeiten bestehen messbare Vorgaben
+
+- **Ebene / Typ:** SyRS / nicht-funktional (Zeitverhalten (ISO/IEC 25010, Performance-Effizienz))
+- **Akteur:** alle Benutzer
+- **Belegte Beobachtung (Fakt):** Leistungsbezogene Vorkehrungen sind an mehreren Stellen belegt: Sitzungszwischenspeicher für Rechte, `ConditionalWeakTable` für Belegzusatzdaten, Sammelabfragen für Bestände, Ticketzwischenspeicher im Portal mit den Grenzwerten `CachedMonths` und `MaxClosedTickets`, `UseIncreasedThreadPool` in der Webservice-Konfiguration und ein eigener Bereich `Administration/PerformanceTests/`. Eine Festlegung von Zielwerten — etwa eine höchstzulässige Antwortzeit für eine Belegsuche — ist nicht auffindbar.
+- **Angenommene Soll-Aussage:** Das System soll für die häufigsten Vorgänge messbare Antwortzeitvorgaben einhalten.
+- **Offene Frage / fehlende Information:** Zielwerte sind in der Codebasis nicht hinterlegt; zur Bestätigung fehlt eine Leistungsvorgabe, gegen die die vorhandenen Prüfungen messen.
+- **Belegsituation:** 3 Belege — PRIMÄR, PRIMÄR, PRIMÄR; erster PRIMÄR-Beleg: `docker/compose/WebServiceConfig.xml`, `<UseIncreasedThreadPool>true</UseIncreasedThreadPool>`
+- **Klärung durch:** Die Codebasis nach hinterlegten Zeitgrenzen für Benutzervorgänge durchsuchen; werden keine gefunden, ist die Hypothese bestätigt.
+- **Übernahmewürdigkeit:** übernehmen — für ein SaaS-Zielsystem sind Antwortzeitvorgaben Bestandteil der Leistungszusage.
+
+### SyRS-197 — Für Verfügbarkeit und Datensicherung bestehen Vorgaben
+
+- **Ebene / Typ:** SyRS / nicht-funktional (Verfügbarkeit (ISO/IEC 25010, Zuverlässigkeit))
+- **Akteur:** Systembetreiber
+- **Belegte Beobachtung (Fakt):** Die Container-Zusammenstellung setzt für Webservice und Portal `restart: on-failure`; die Datenbank wird als Container ohne dauerhaftes Datenvolumen geführt (`compose.yaml`, Dienst `db` ohne `volumes`). Eine Vorgabe zu Wiederherstellungszeit, Wiederherstellungspunkt oder Sicherungshäufigkeit ist nicht auffindbar.
+- **Angenommene Soll-Aussage:** Das System soll Vorgaben zu Verfügbarkeit, Wiederherstellungszeit und Datensicherung erfüllen.
+- **Offene Frage / fehlende Information:** Solche Vorgaben sind in der Codebasis nicht hinterlegt; zur Bestätigung fehlen Betriebsunterlagen außerhalb des Quellcodes.
+- **Belegsituation:** 1 Belege — PRIMÄR; erster PRIMÄR-Beleg: `docker/compose/compose.yaml`, `restart: on-failure` bei `webservice` und `nexus`, Dienst `db` ohne Volumenangabe
+- **Klärung durch:** Die Betriebsunterlagen auf Verfügbarkeits- und Sicherungsvorgaben prüfen; sie liegen außerhalb der Codebasis.
+- **Übernahmewürdigkeit:** übernehmen — Verfügbarkeits- und Sicherungszusagen sind im SaaS-Zielsystem Vertragsbestandteil.
+
+### SyRS-198 — Die Oberfläche erfüllt Anforderungen an Barrierefreiheit
+
+- **Ebene / Typ:** SyRS / nicht-funktional (Zugänglichkeit (ISO/IEC 25010, Benutzbarkeit))
+- **Akteur:** alle Benutzer
+- **Belegte Beobachtung (Fakt):** Die Portaloberfläche setzt auf Bootstrap-Variablen (`README.md`, Abschnitt „3. Custom CSS") und DevExpress-Komponenten (Abschnitt „2. Which components to use"); `Branding` erlaubt die Festlegung einer Akzentfarbe (`HexColor`) und getrennter Anmeldelogos für helle und dunkle Darstellung (`LoginLogo`, `LoginLogoDarkMode`). Vorgaben zu Kontrastwerten, Tastaturbedienung oder Bildschirmleserunterstützung sind nicht auffindbar.
+- **Angenommene Soll-Aussage:** Das System soll für die Bedienung ohne Maus und mit Hilfsmitteln geeignet sein.
+- **Offene Frage / fehlende Information:** Entsprechende Vorgaben sind in der Codebasis nicht auffindbar; zur Bestätigung fehlen Gestaltungsvorgaben zur Zugänglichkeit.
+- **Belegsituation:** 2 Belege — PRIMÄR, PRIMÄR; erster PRIMÄR-Beleg: `README.md`, Abschnitte „2. Which components to use" und „3. Custom CSS"
+- **Klärung durch:** Eine Portalseite mit einem Prüfwerkzeug für Zugänglichkeit prüfen; das Ergebnis zeigt den tatsächlichen Stand.
+- **Übernahmewürdigkeit:** übernehmen — Zugänglichkeit ist bei öffentlichen Auftraggebern gefordert und im Zielsystem festzulegen.
+
+### SyRS-199 — Mandantendaten sind auf Datenebene voneinander getrennt
+
+- **Ebene / Typ:** SyRS / Sicherheit (Akteur:        Systembetreiber)
+- **Akteur:** Systembetreiber
+- **Belegte Beobachtung (Fakt):** Der Mandant ist als Feld modelliert (`Sichbenu.MandantID`, `MandatorBL.GetMandatorI3DFromEmployee`, `MandatorManagementAppModuleController`); die Trennung erfolgt damit innerhalb einer Datenbank über Kennungsfelder. Eine durchgängige Filterung aller Abfragen nach Mandant — etwa über einen Filter auf Sitzungsebene — ist nicht auffindbar; die Rechteprüfungen filtern nach Filiale (`BranchI3D`), nicht nach Mandant.
+- **Angenommene Soll-Aussage:** Das System soll sicherstellen, dass ein Benutzer ausschließlich Daten seines Mandanten sieht.
+- **Offene Frage / fehlende Information:** Eine durchgängige mandantenbezogene Filterung ist nicht auffindbar; zur Bestätigung fehlt ein Mechanismus, der die Mandantenbedingung auf alle Abfragen anwendet.
+- **Belegsituation:** 3 Belege — PRIMÄR, PRIMÄR, PRIMÄR; erster PRIMÄR-Beleg: `SSMS_DB_SCHEMA.sql`, `dbo.Sichbenu`, Spalte `[MandantID] [int] NULL` (Zeile 18515)
+- **Klärung durch:** Zwei Mandanten anlegen und mit einem Benutzer des einen Mandanten eine Belegsuche ausführen; erscheinen Belege des anderen Mandanten, ist die Hypothese bestätigt.
+- **Übernahmewürdigkeit:** übernehmen — im SaaS-Zielsystem ist die Mandantentrennung auf Datenebene zwingend durchzusetzen.
+
+### SyRS-200 — Rechteänderungen wirken ohne neue Anmeldung
+
+- **Ebene / Typ:** SyRS / Sicherheit (Akteur:        Administrator)
+- **Akteur:** Administrator
+- **Belegte Beobachtung (Fakt):** `AppRightsBL.HasUserRight` liest die Rechte über `Session.Advanced.Cache.GetOrAdd($"AllRightsFromAppUser{appUserI3D}", ...)`; die rechteverändernden Methoden derselben Klasse (`AddRightToRightGroup`, `RemoveUserFromRightGroup` und weitere) entfernen den Zwischenspeichereintrag nicht. Auch im Client hält `CentronCache.Instance.CurrentUserAppRights` die Rechte der laufenden Sitzung.
+- **Angenommene Soll-Aussage:** Das System soll den Entzug eines Rechts unverzüglich wirksam werden lassen.
+- **Offene Frage / fehlende Information:** Eine Ungültigmachung des Rechtezwischenspeichers nach einer Rechteänderung ist nicht auffindbar; zur Bestätigung fehlt ein Aufruf, der den Eintrag `AllRightsFromAppUser{…}` verwirft.
+- **Belegsituation:** 2 Belege — PRIMÄR, PRIMÄR; erster PRIMÄR-Beleg: `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, Zeilen 644-650
+- **Klärung durch:** Einem angemeldeten Benutzer ein Recht entziehen und ohne Neuanmeldung die geschützte Funktion aufrufen; gelingt sie, ist die Hypothese bestätigt.
+- **Übernahmewürdigkeit:** übernehmen — im Zielsystem ist die unmittelbare Wirksamkeit von Rechteentzügen sicherzustellen.
+
+### SyRS-201 — Das Riverbird-Produkt teilt sich Bestandteile mit c-entron
+
+- **Ebene / Typ:** SyRS / Schnittstelle (Akteur:        Systembetreiber)
+- **Akteur:** Systembetreiber
+- **Belegte Beobachtung (Fakt):** Der Riverbird-Bezug zieht sich durch mehrere Stellen: `deployment/riverbird/` neben `deployment/centron/`; `nugets/RiverbirdPortal.Common.1.0.4.nupkg`, `RiverbirdPortal.Interfaces.1.0.4.nupkg`, `RiverbirdPortal.WebServices.Core.1.0.4.nupkg`; das Modul `RiverSuiteWebServiceSettingsController` („Einstellungen für den Riverbird Web-Service-Zugang"); `AppRightsBL.GetRiversuiteRelevantRights()` mit der Entität `RiverSuiteRelevantRight`; `src/backend/Centron.BL/RiverDivo/`; Ressourcenschlüssel wie `RiverbirdTicketBL_GetTicket_…` in Klassen namens `TicketBL`. Die Lizenzdokumentation nennt „Riverbird Web-Service" als eigenständige Anwendung.
+- **Angenommene Soll-Aussage:** Das System soll Bestandteile mit dem Schwesterprodukt Riverbird teilen und für dieses eine gesonderte Rechteauswahl bereitstellen.
+- **Offene Frage / fehlende Information:** Die Abgrenzung beider Produkte und der Umfang der geteilten Bestandteile sind aus der Codebasis nicht abschließend erschließbar; zur Bestätigung fehlt eine Produktbeschreibung des Schwesterprodukts.
+- **Belegsituation:** 3 Belege — PRIMÄR, PRIMÄR, SEKUNDÄR; erster PRIMÄR-Beleg: `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `GetRiversuiteRelevantRights` (Zeilen 55-60)
+- **Klärung durch:** Die Abhängigkeiten der Riverbird-Pakete auf gemeinsame Bausteine prüfen; der Umfang der Kopplung wird daraus ersichtlich.
+- **Übernahmewürdigkeit:** Sonderfall — die Kopplung an ein Schwesterprodukt ist bei der Neuimplementierung fachlich zu entscheiden.
+
+### SyRS-202 — Der Concerto-Baustein bedient einen Bestellformatstandard
+
+- **Ebene / Typ:** SyRS / Schnittstelle (Akteur:        Einkäufer)
+- **Akteur:** Einkäufer
+- **Belegte Beobachtung (Fakt):** `src/backend/Centron.Gateway/Concerto/` enthält genau zwei Dateien: `ConcertoOrder.cs` und `ConcertoOrder.xsd`; ein gleichnamiger Bereich `src/backend/Centron.BL/EDI/Concerto/` besteht in der Geschäftslogik. Eine Einstellungsseite, ein Modul oder eine Dokumentation zu diesem Format ist nicht auffindbar.
+- **Angenommene Soll-Aussage:** Das System soll Bestellungen im Concerto-Format austauschen.
+- **Offene Frage / fehlende Information:** Der fachliche Zweck, der Partner und die Verwendung dieses Formats sind aus der Codebasis nicht erschließbar; zur Bestätigung fehlen eine Konfigurationsstelle und eine Formatbeschreibung.
+- **Belegsituation:** 2 Belege — PRIMÄR, PRIMÄR; erster PRIMÄR-Beleg: `src/backend/Centron.Gateway/Concerto/ConcertoOrder.xsd`
+- **Klärung durch:** Die Aufrufer des Concerto-Bausteins ermitteln; fehlen sie, ist das Format nicht erreichbar.
+- **Übernahmewürdigkeit:** übernehmen — sofern ein Partner das Format nutzt; andernfalls entfällt es.
+
+### SyRS-203 — Der IT-Planer strukturiert Prüfobjekte für Checklisten
+
+- **Ebene / Typ:** SyRS / funktional (Akteur:        Servicetechniker)
+- **Akteur:** Servicetechniker
+- **Belegte Beobachtung (Fakt):** `src/backend/Centron.BL/ItPlanner/` enthält genau eine Klasse: `ChecklistVirtualObjectCategoryBL.cs`; ein gleichnamiger Entitätsbereich `Entities/ItPlanner/` besteht. Der Name verbindet „Checkliste", „virtuelles Objekt" und „Kategorie". Ein zugehöriges Modul oder eine Einstellungsseite ist nicht auffindbar.
+- **Angenommene Soll-Aussage:** Das System soll Prüfobjekte für Checklisten in Kategorien gliedern, ohne dass ein reales Geschäftsobjekt vorliegen muss.
+- **Offene Frage / fehlende Information:** Der fachliche Zweck des Bereichs „ItPlanner" ist aus der Codebasis nicht erschließbar; zur Bestätigung fehlen eine Beschreibung und eine Modulanbindung.
+- **Belegsituation:** 2 Belege — PRIMÄR, PRIMÄR; erster PRIMÄR-Beleg: `src/backend/Centron.BL/ItPlanner/ChecklistVirtualObjectCategoryBL.cs`
+- **Klärung durch:** Die Aufrufer der Klasse ermitteln und den Inhalt der zugehörigen Tabelle prüfen.
+- **Übernahmewürdigkeit:** übernehmen — sofern die Funktion produktiv genutzt wird; der Reifegrad ist zu klären.
+
+### SyRS-204 — Die docuFORM-Anbindung liefert Gerätezählerstände
+
+- **Ebene / Typ:** SyRS / Schnittstelle (Akteur:        Buchhalter, Servicetechniker)
+- **Akteur:** Buchhalter, Servicetechniker
+- **Belegte Beobachtung (Fakt):** `Centron.Api.docuFORM/` liegt als einziges Projekt **außerhalb** von `src/` im Wurzelverzeichnis und enthält `DocuFormRestApiClient.cs`, `DocuFormRestApiConstants.cs`, `IDocuFormApiClient.cs`, `Helper/` und `Models/`. Die Einstellungsseite `DocuFormApiSettingsController` beschreibt „Einstellungen für den Datenaustausch über die REST Schnittstelle von docuFORM"; ein gleichnamiger v1-Controller besteht. `src/backend/Centron.BL/DataExchange/DocuForm/` bildet die Verarbeitung ab.
+- **Angenommene Soll-Aussage:** Das System soll über die docuFORM-Schnittstelle Gerätedaten — insbesondere Zählerstände von Druck- und Kopiersystemen — abrufen und der Vertragsabrechnung zuführen.
+- **Offene Frage / fehlende Information:** Der genaue Umfang der übernommenen Daten ist aus der Codebasis nicht abschließend erschließbar; zur Bestätigung fehlt eine Beschreibung der genutzten Endpunkte.
+- **Belegsituation:** 3 Belege — PRIMÄR, PRIMÄR, SEKUNDÄR; erster PRIMÄR-Beleg: `Centron.Api.docuFORM/IDocuFormApiClient.cs` und `DocuFormRestApiClient.cs`
+- **Klärung durch:** Die im Anbindungsprojekt aufgerufenen Endpunkte auflisten und mit den Zählerimportfunktionen abgleichen.
+- **Übernahmewürdigkeit:** übernehmen — die automatische Zählererfassung ist für die verbrauchsabhängige Abrechnung wesentlich.
+
+### SyRS-205 — Zeitangaben werden einheitlich in einer Zeitzone geführt
+
+- **Ebene / Typ:** SyRS / Daten (Akteur:        alle Komponenten)
+- **Akteur:** alle Komponenten
+- **Belegte Beobachtung (Fakt):** Zeitstempel werden durchgängig über `DateTime.Now` beziehungsweise `DateTime.Today` gebildet — so in `TicketBL.GetExpireDate` (`DateTime.Now.AddMinutes(...)`), `TwoFactorAuthBL.RememberLogin` (`login.LastLogin = DateTime.Now;`), `UsersBL.UpdatePassword` (`user2.LastPasswordChangedDate = DateTime.Now;`) und `Authenticator.ValidateAppUser` (`DateTime.Today >= user.AccountDisabledFromDate`). Der Container setzt `ENV TZ=Europe/Berlin`. Eine Verwendung von `DateTime.UtcNow` oder `DateTimeOffset` ist an den geprüften Stellen nicht auffindbar.
+- **Angenommene Soll-Aussage:** Das System soll Zeitstempel eindeutig einer Zeitzone zuordnen.
+- **Offene Frage / fehlende Information:** Die durchgängige Verwendung der Ortszeit ohne Zeitzonenangabe ist belegt; ob daraus im Mehrzonenbetrieb Abweichungen entstehen, ist ohne Ausführung nicht feststellbar.
+- **Belegsituation:** 3 Belege — PRIMÄR, PRIMÄR, PRIMÄR; erster PRIMÄR-Beleg: `src/backend/Centron.BL/Administration/Logins/TicketBL.cs`, Zeile 163 (`return DateTime.Now.AddMinutes(expireDurationInMinutes);`)
+- **Klärung durch:** Den Container mit abweichender Zeitzone betreiben und Sitzungsablauf sowie Kontodeaktivierung prüfen; abweichendes Verhalten bestätigt die Hypothese.
+- **Übernahmewürdigkeit:** übernehmen — im SaaS-Zielsystem sind Zeitstempel in UTC zu führen und erst bei der Anzeige umzurechnen.
+
+### SwRS-190 — Zeitstempel werden zeitzonensicher gebildet
+
+- **Ebene / Typ:** SwRS / Daten (Akteur:        alle Komponenten)
+- **Akteur:** alle Komponenten
+- **Belegte Beobachtung (Fakt):** Die geprüften Komponenten bilden Zeitstempel ausschließlich über `DateTime.Now` und `DateTime.Today`; die Datenbankspalten sind entsprechend `datetime` beziehungsweise `datetime2` ohne Zeitzonenanteil (`Sichbenu.LoginTime`, `LastWebLogin`, `LetzKennAend`, `LastTwoFactorValidatedAt`). Ein Datentyp mit Zeitzonenanteil (`datetimeoffset`) ist in den geprüften Tabellen nicht verwendet.
+- **Angenommene Soll-Aussage:** Das System soll Zeitstempel so speichern, dass ihre Zeitzone eindeutig ist.
+- **Offene Frage / fehlende Information:** Da weder Anwendungscode noch Datenmodell einen Zeitzonenanteil führen, ist die Eindeutigkeit nur bei einheitlicher Serverzeitzone gegeben; zur Bestätigung fehlt eine Festlegung der Betriebszeitzone außerhalb des Containers.
+- **Belegsituation:** 2 Belege — PRIMÄR, PRIMÄR; erster PRIMÄR-Beleg: `SSMS_DB_SCHEMA.sql`, `dbo.Sichbenu`, Spalten `[LoginTime] [datetime]`, `[LastWebLogin] [datetime]`, `[LetzKennAend] [datetime]`, `[LastTwoFactorValidatedAt] [datetime2](7)`
+- **Klärung durch:** Zwei Anwendungsinstanzen mit unterschiedlicher Zeitzone gegen dieselbe Datenbank betreiben und Zeitstempel vergleichen.
+- **Übernahmewürdigkeit:** übernehmen — im Zielsystem sind Zeitstempel in UTC zu speichern.
+
+### SwRS-191 — Die Nummernvergabe ist gegen gleichzeitige Zugriffe gesichert
+
+- **Ebene / Typ:** SwRS / Daten (Akteur:        Komponente `NumberGroupBL`)
+- **Akteur:** Komponente `NumberGroupBL`
+- **Belegte Beobachtung (Fakt):** `NumberGroupBL.GetNextNumber(numberGroupEnum, numberGroupObject, updateDatabase)` liest und erhöht den Zähler des Nummernkreises. Eine ausdrückliche Sperre — wie sie `Authenticator.AuthenticateUser` mit `lock (_getExistingOrCreateTicketLock)` für die Ticketvergabe verwendet — ist für die Nummernvergabe nicht auffindbar; die Datenbank sichert die Eindeutigkeit nicht ab (siehe SyRS-190).
+- **Angenommene Soll-Aussage:** Das System soll bei gleichzeitiger Belegerstellung sicherstellen, dass jede Nummer nur einmal vergeben wird.
+- **Offene Frage / fehlende Information:** Ein Sicherungsmechanismus ist nicht auffindbar; zur Bestätigung fehlt eine Sperre, eine Transaktionsisolationsstufe oder eine Eindeutigkeitsbedingung.
+- **Belegsituation:** 3 Belege — PRIMÄR, PRIMÄR, PRIMÄR; erster PRIMÄR-Beleg: `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs`
+- **Klärung durch:** Zwei Belege gleichzeitig aus getrennten Sitzungen speichern und die Nummern vergleichen.
+- **Übernahmewürdigkeit:** übernehmen — die Nebenläufigkeitssicherung der Nummernvergabe ist im Zielsystem ausdrücklich zu lösen.
+
+### SwRS-192 — Die als unsicher geltende Binärserialisierung wird nur für einen Zweck genutzt
+
+- **Ebene / Typ:** SwRS / Sicherheit (Akteur:        alle Komponenten)
+- **Akteur:** alle Komponenten
+- **Belegte Beobachtung (Fakt):** `Directory.Build.props` setzt `<EnableUnsafeBinaryFormatterSerialization>true</EnableUnsafeBinaryFormatterSerialization>` für **alle** Projekte der Projektmappe; der begleitende Kommentar lautet „BinaryFormatter (only used for NHibernate Configuration serialization)". Die Einstellung wirkt jedoch projektübergreifend und schränkt die Nutzung nicht auf diesen Zweck ein.
+- **Angenommene Soll-Aussage:** Das System soll die als unsicher geltende Binärserialisierung ausschließlich zum Zwischenspeichern der NHibernate-Konfiguration verwenden.
+- **Offene Frage / fehlende Information:** Die Beschränkung auf diesen Zweck beruht ausschließlich auf einem Kommentar; zur Bestätigung fehlt eine Prüfung aller Verwendungsstellen der Binärserialisierung.
+- **Belegsituation:** 1 Belege — PRIMÄR; erster PRIMÄR-Beleg: `Directory.Build.props`, Zeilen 40-43
+- **Klärung durch:** Die Projektmappe nach Verwendungen von `BinaryFormatter` durchsuchen; jede Fundstelle außerhalb der NHibernate-Konfiguration widerlegt den Kommentar.
+- **Übernahmewürdigkeit:** veraltet — die Binärserialisierung ist im Zielsystem durch ein sicheres Verfahren zu ersetzen.
+
+### SwRS-193 — Die automatisierte Prüfung deckt die Fachlogik ausreichend ab
+
+- **Ebene / Typ:** SwRS / nicht-funktional (Testbarkeit (ISO/IEC 25010, Wartbarkeit))
+- **Akteur:** Hersteller
+- **Belegte Beobachtung (Fakt):** Sieben Testprojektgruppen bestehen; `build-pipeline.yml` bricht bei fehlgeschlagenen End-zu-End-Tests ab. Eine Vorgabe zur Abdeckung — etwa eine Mindestquote oder eine Auswertung in `analyze-pipeline.yml` — ist aus den Pipeline-Definitionen nicht ableitbar. Zugleich empfiehlt die Belegarchitektur ausdrücklich End-zu-End-Tests als bevorzugtes Sicherungsnetz für neue Belegfelder, weil der Speicherpfad über die Legacy-Repositories führt.
+- **Angenommene Soll-Aussage:** Das System soll durch automatisierte Prüfungen gegen Regressionen gesichert sein.
+- **Offene Frage / fehlende Information:** Der erreichte Abdeckungsgrad ist ohne Ausführung der Prüfungen nicht feststellbar; zur Bestätigung fehlen Abdeckungsberichte.
+- **Belegsituation:** 2 Belege — PRIMÄR, KONTEXT; erster PRIMÄR-Beleg: `azure/build-pipeline.yml`, `failTaskOnFailedTests: true`
+- **Klärung durch:** Die Prüfungen mit Abdeckungsmessung ausführen und die Quote je Baustein auswerten.
+- **Übernahmewürdigkeit:** übernehmen — Abdeckungsvorgaben sind im Zielsystem festzulegen.
+
+### SwRS-194 — Alle Projekte liegen unterhalb des Quellverzeichnisses
+
+- **Ebene / Typ:** SwRS / nicht-funktional (Modifizierbarkeit (ISO/IEC 25010, Wartbarkeit))
+- **Akteur:** Hersteller
+- **Belegte Beobachtung (Fakt):** Die Navigationsdokumentation beschreibt die Gliederung `src/apis/`, `src/backend/`, `src/centron/`, `src/nexus/`, `src/shared/`, `src/webservice/` und weist darauf hin: „not every folder under `src/` is listed above—search the `.sln` for exact project names". Tatsächlich liegt `Centron.Api.docuFORM/` als vollständiges Projekt unmittelbar im Wurzelverzeichnis der Projektmappe, außerhalb von `src/`.
+- **Angenommene Soll-Aussage:** Das System soll alle Projekte einheitlich unterhalb des Quellverzeichnisses führen.
+- **Offene Frage / fehlende Information:** Mindestens ein Projekt weicht davon ab; ob weitere Abweichungen bestehen, ist ohne vollständige Auswertung der Projektmappe nicht feststellbar.
+- **Belegsituation:** 2 Belege — PRIMÄR, KONTEXT; erster PRIMÄR-Beleg: `Centron.Api.docuFORM/Centron.Api.docuFORM.csproj`
+- **Klärung durch:** Alle Projektpfade aus `Centron.sln` auslesen und gegen `src/` prüfen; Abweichungen werden dabei vollständig sichtbar.
+- **Übernahmewürdigkeit:** übernehmen — eine einheitliche Projektstruktur ist im Zielsystem herzustellen.
+
+### SwRS-195 — Fremdbestandteile werden ausschließlich über Paketverwaltung bezogen
+
+- **Ebene / Typ:** SwRS / nicht-funktional (Wartbarkeit (ISO/IEC 25010))
+- **Akteur:** Hersteller
+- **Belegte Beobachtung (Fakt):** Zwei Bezugswege bestehen nebeneinander: `nugets/` enthält 13 lokal abgelegte Pakete (darunter `FastReport.Core.2022.1.6.nupkg` **und** `FastReport.Core.2025.1.3.nupkg`, also zwei Hauptversionen desselben Bausteins, sowie `Centron.Office.Client.1.1.433.nupkg` und drei `RiverbirdPortal.*`-Pakete); `assemblies/` enthält Binärbestandteile für `7pdf`, `outlook`, `remote-desktop`, `tapi` und `wpf`. Die Regel für Fremdbestandteile der Weboberfläche verlangt entweder LibMan oder eine CDN-Einbindung mit Integritätsprüfsumme.
+- **Angenommene Soll-Aussage:** Das System soll Fremdbestandteile nachvollziehbar beziehen und ihre Herkunft prüfbar halten.
+- **Offene Frage / fehlende Information:** Herkunft, Lizenzstand und Aktualität der lokal abgelegten Pakete und Binärbestandteile sind aus der Codebasis nicht feststellbar; zur Bestätigung fehlen Herkunfts- und Lizenzangaben zu diesen Dateien.
+- **Belegsituation:** 3 Belege — PRIMÄR, PRIMÄR, SEKUNDÄR; erster PRIMÄR-Beleg: `nugets/` mit 13 Paketen, darunter zwei FastReport-Hauptversionen
+- **Klärung durch:** Zu jedem Eintrag in `assemblies/` Herkunft und Lizenz belegen; fehlende Nachweise bestätigen die Hypothese.
+- **Übernahmewürdigkeit:** übernehmen — im Zielsystem sind Fremdbestandteile ausschließlich über eine nachvollziehbare Paketverwaltung zu beziehen.
+
+### SwRS-196 — Das Delphi-Vorgängersystem greift auf dieselbe Datenbank zu
+
+- **Ebene / Typ:** SwRS / Daten (Akteur:        Systembetreiber)
+- **Akteur:** Systembetreiber
+- **Belegte Beobachtung (Fakt):** Mehrere Stellen weisen auf ein parallel betriebenes Vorgängersystem hin: `LicenseManager.TryFixCentronDelphiVersionNumber` behandelt Versionsnummern der Form 9.3.x.y und teilt sich die Lizenz-GUID mit c-entron.NET; die Anleitung zum Anlegen eines Rechts beschreibt die Spalten `FomName` und `FomCont` der Tabelle `Sichrech` mit dem Hinweis „is important for Delphi, but not for Centron"; die Tabellen tragen deutschsprachige Namen aus dem Vorgängerbestand (`Sichbenu`, `Sichrech`, `Sichtrus`, `Sichmemb`, `AngKopf`, `RechKopf`).
+- **Angenommene Soll-Aussage:** Das System soll denselben Datenbestand mit dem Delphi-Vorgängersystem teilen können.
+- **Offene Frage / fehlende Information:** Ob das Vorgängersystem noch produktiv betrieben wird und welche Bereiche es schreibt, ist aus der Codebasis nicht feststellbar; zur Bestätigung fehlen Angaben zum Betriebsstand des Vorgängersystems.
+- **Belegsituation:** 3 Belege — PRIMÄR, PRIMÄR, PRIMÄR; erster PRIMÄR-Beleg: `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, Zeilen 304-330
+- **Klärung durch:** Die Spalten `FomName` und `FomCont` in `Sichrech` auf gefüllte Werte prüfen; gefüllte Werte belegen die fortbestehende Nutzung.
+- **Übernahmewürdigkeit:** veraltet — die Rücksichtnahme auf das Vorgängersystem entfällt im Zielsystem; die betroffenen Spalten und Ausnahmen sind zu entfernen.
+
+### SwRS-197 — Statische Zwischenspeicher sind für den Mehrmandantenbetrieb geeignet
+
+- **Ebene / Typ:** SwRS / Sicherheit (Akteur:        alle Komponenten)
+- **Akteur:** alle Komponenten
+- **Belegte Beobachtung (Fakt):** Mehrere Zustände werden prozessweit statisch gehalten: `TwoFactorAuthBL._globalValidator` (statischer Prüfer des zweiten Faktors), `LicenseManager._instance` (Einzelinstanz mit Ausnahme bei doppelter Einrichtung), `ReceiptBL._alreadyLoadedAdditionalData` (statische `ConditionalWeakTable`) und `CentronCache.Instance` im Client. Die Sitzungszwischenspeicher der Rechte liegen dagegen je Datenzugriffssitzung.
+- **Angenommene Soll-Aussage:** Das System soll prozessweite Zwischenspeicher so führen, dass Daten verschiedener Mandanten und Benutzer nicht vermischt werden.
+- **Offene Frage / fehlende Information:** Ob die statischen Zustände im Mehrmandantenbetrieb unbedenklich sind, ist ohne Ausführung nicht feststellbar; zur Bestätigung fehlt eine Prüfung, ob je Mandant ein eigener Prozess betrieben wird.
+- **Belegsituation:** 3 Belege — PRIMÄR, PRIMÄR, PRIMÄR; erster PRIMÄR-Beleg: `src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs`, Zeile 182 (`private static ITwoFactorValidator _globalValidator;`)
+- **Klärung durch:** Zwei Mandanten über denselben Webservice-Prozess bedienen und die Wirkung mandantenabhängiger Einstellungen prüfen.
+- **Übernahmewürdigkeit:** übernehmen — im SaaS-Zielsystem sind prozessweite Zustände zu vermeiden oder ausdrücklich mandantenbezogen zu schlüsseln.
+
+### SwRS-198 — Die zweite Steuerelementbibliothek dient der Produktvorschau
+
+- **Ebene / Typ:** SwRS / funktional (Akteur:        Hersteller)
+- **Akteur:** Hersteller
+- **Belegte Beobachtung (Fakt):** Neben `src/shared/Centron.Controls/` besteht `src/shared/Centron.Controls.Preview/`. Zugleich wertet `ModuleFeatures.SetAccessRights(...)` die Lizenz `LicenseGuids.ProductPreview` aus. Eine Beschreibung der zweiten Bibliothek oder eine Zuordnung zur Vorschaulizenz ist nicht auffindbar.
+- **Angenommene Soll-Aussage:** Das System soll Oberflächenbausteine für noch nicht freigegebene Funktionen getrennt führen und über eine Vorschaulizenz freischalten.
+- **Offene Frage / fehlende Information:** Der Zusammenhang zwischen `Centron.Controls.Preview` und `LicenseGuids.ProductPreview` ist nicht belegbar; zur Bestätigung fehlt eine Verwendungsstelle, die beides verbindet.
+- **Belegsituation:** 2 Belege — PRIMÄR, PRIMÄR; erster PRIMÄR-Beleg: `src/shared/Centron.Controls.Preview/`
+- **Klärung durch:** Die Verwendungsstellen der Vorschaubibliothek ermitteln und prüfen, ob sie an die Vorschaulizenz gebunden sind.
+- **Übernahmewürdigkeit:** übernehmen — ein getrennter Vorschauweg ist sinnvoll; die Kopplung ist im Zielsystem ausdrücklich herzustellen.
+
+### SwRS-199 — Migrationsskripte enthalten keine fachlichen Regeln
+
+- **Ebene / Typ:** SwRS / Daten (Akteur:        Komponente `ScriptEngineBL`)
+- **Akteur:** Komponente `ScriptEngineBL`
+- **Belegte Beobachtung (Fakt):** Die 790 Skriptklassen enthalten neben Strukturänderungen auch Datenänderungen; mehrere Skripte führen umfangreiche SQL-Anweisungen mit fachlichem Inhalt, etwa die wiederkehrende Zuweisung `VatRate = CONVERT(decimal(24, 8), a.Mwst_Satz)` beziehungsweise `VatRate = CONVERT(decimal(24, 8), MS.Mwst)` in `ScriptMethod11152`, `11176`, `11256`, `11362`, `11373`, `11422`, `11543` und `11713` — dieselbe Umrechnung erscheint in acht Skripten und zusätzlich in `AutomaticFacturaBL.Contracts.cs` Zeile 2400. Zusätzlich liegen vier `SQLScriptCollection*.xml` und drei `SQLScriptCollectionMonitoring*.xml` mit SQL-Anweisungen vor.
+- **Angenommene Soll-Aussage:** Das System soll fachliche Regeln in der Geschäftslogik führen und Migrationsskripte auf Struktur- und Datenüberführung beschränken.
+- **Offene Frage / fehlende Information:** Mindestens die Steuersatzumrechnung liegt sowohl in Skripten als auch in der Geschäftslogik vor; ob weitere fachliche Regeln ausschließlich in Skripten oder Sichten stehen, ist ohne Auswertung aller 790 Skripte und der Sichten nicht feststellbar.
+- **Belegsituation:** 3 Belege — PRIMÄR, PRIMÄR, PRIMÄR; erster PRIMÄR-Beleg: `src/backend/Centron.BL/Administration/Scripts/ScriptMethods/Scripts/ScriptMethod11152.cs` Zeilen 53 und 144 sowie sieben weitere Skripte mit identischer Zuweisung
+- **Klärung durch:** Die Sichten und Skripte nach Berechnungen durchsuchen, die in der Geschäftslogik nicht vorkommen; jede Fundstelle ist eine ausschließlich in der Datenbank geführte Regel.
+- **Übernahmewürdigkeit:** übernehmen — im Zielsystem gehören fachliche Regeln ausschließlich in die Geschäftslogik.
+
+### SwRS-200 — Die Anbindung fremder Ticketsysteme ist produktiv nutzbar
+
+- **Ebene / Typ:** SwRS / Schnittstelle (Akteur:        Komponente `ExternalHelpdesk`)
+- **Akteur:** Komponente `ExternalHelpdesk`
+- **Belegte Beobachtung (Fakt):** `src/backend/Centron.BL/ExternalHelpdesk/` und `src/backend/Centron.Entities/Entities/ExternalHelpdesk/` bestehen als eigene Bereiche; eine Einstellungsseite zur Konfiguration einer Anbindung, ein Modul oder eine v1-Ressource für fremde Ticketsysteme ist in `ModuleRegistration` und den Controllern nicht auffindbar. Die auffindbaren Weiterleitungsfunktionen (`HelpdeskForwardBL`, `ServiceBoard/ForwardTicket/`) betreffen die Weitergabe innerhalb des Systems.
+- **Angenommene Soll-Aussage:** Das System soll Tickets mit fremden Ticketsystemen austauschen.
+- **Offene Frage / fehlende Information:** Ob und wie eine solche Anbindung konfiguriert wird, ist nicht belegbar; zur Bestätigung fehlt eine Konfigurationsstelle für fremde Ticketsysteme.
+- **Belegsituation:** 2 Belege — PRIMÄR, PRIMÄR; erster PRIMÄR-Beleg: `src/backend/Centron.BL/ExternalHelpdesk/`
+- **Klärung durch:** Die Aufrufer der Bausteine ermitteln; fehlen sie außerhalb von Tests, ist die Anbindung nicht erreichbar.
+- **Übernahmewürdigkeit:** übernehmen — der Austausch mit Partnersystemen ist im Servicegeschäft gefordert; der Reifegrad ist zu klären.
+
+## 4. Abgleich gegen die Inline-Markierungen
+
+Der Abgleich wurde maschinell über alle drei Spezifikationsdateien geführt: verglichen wurden die Menge der Anforderungen mit `Status: HYPOTHESE` und die Menge der Anforderungen, deren Block die Zeichenfolge `[HYPOTHESE]` enthält.
+
+| Prüfung | Ergebnis |
+|---|---|
+| Anforderungen mit `Status: HYPOTHESE` | 33 |
+| Anforderungen mit `[HYPOTHESE]`-Markierung im Block | 33 |
+| Nur `Status`, keine Markierung | 0 |
+| Nur Markierung, kein `Status` | 0 |
+| In dieser Datei aufgeführt | 33 |
+| Zusätzliche freie Fragen in dieser Datei | 0 |
+
+Beide Mengen sind deckungsgleich; `Hypothesen.md` nennt genau diese Anforderungen.

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-37c5/Ergebnisse/Traceability.md

@@ -0,0 +1,325 @@
+# Traceability — konsolidierte Verfolgbarkeitstabelle
+
+**System:** NEXOWARE c-entron ERP-Suite  
+**Norm:** ISO/IEC/IEEE 29148:2018 — Forward- und Backward-Traceability zwischen StRS, SyRS und SwRS
+
+## 1. Aufbau
+
+Die Tabelle ist aus den Feldern `Tracelinks` aller Anforderungsblöcke maschinell erzeugt und in beide Richtungen ausgewertet: Eine Zeile entsteht sowohl, wenn eine StRS-Anforderung auf eine SyRS-Anforderung verweist, als auch, wenn eine SyRS-Anforderung auf die StRS-Anforderung zurückverweist. Dasselbe gilt für das Paar SyRS/SwRS. Ein Strich (—) bedeutet, dass auf der betreffenden Ebene keine verknüpfte Anforderung besteht.
+
+Die Spalte `Artefaktbeleg` nennt den ersten `PRIMÄR`-Beleg der jeweils rechtesten besetzten Ebene der Zeile; die vollständige Belegliste steht im Anforderungsblock selbst.
+
+**Zeilen:** 299  
+**Verknüpfte Anforderungen:** 100 StRS, 190 SyRS, 144 SwRS
+
+## 2. Tabelle
+
+| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
+|---|---|---|---|
+| StRS-001 | SyRS-001 | SwRS-001 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 9598-9600 (`.OfType<IReceiptItemWithPickingAndMounting>()`) |
+| StRS-001 | SyRS-001 | SwRS-006 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 3707-3757 |
+| StRS-001 | SyRS-001 | SwRS-007 | `src/backend/Centron.DAO/` — die sieben `SaveReceipt*Repository`-Klassen mit `SynchronizeReceiptData` und `SynchronizeReceiptItemData` |
+| StRS-001 | SyRS-001 | SwRS-008 | `src/backend/Centron.Entities/Entities/DbEntities/` und `src/backend/Centron.DAO/Mappings/TemporaryEntities/` |
+| StRS-001 | SyRS-001 | SwRS-009 | `SSMS_DB_SCHEMA.sql` — die Tabellen `AngKopf`, `AufKopf`, `LiefKopf`, `RechKopf`, `VertragKopf`, `GutKopf`, `AbholKopf` und die zugehörigen Sichten |
+| StRS-001 | SyRS-002 | SwRS-001 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 9598-9600 (`.OfType<IReceiptItemWithPickingAndMounting>()`) |
+| StRS-001 | SyRS-005 | SwRS-003 | `src/backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs`, Zeilen 6-27 |
+| StRS-001 | SyRS-008 | SwRS-005 | `src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptBase.cs`, Feld `ConcurrencyControlGuid` |
+| StRS-001 | SyRS-009 | SwRS-006 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 3707-3757 |
+| StRS-001 | SyRS-192 | SwRS-003 | `src/backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs`, Zeilen 6-27 |
+| StRS-001 | SyRS-215 | SwRS-001 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 9598-9600 (`.OfType<IReceiptItemWithPickingAndMounting>()`) |
+| StRS-001 | SyRS-220 | SwRS-001 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 9598-9600 (`.OfType<IReceiptItemWithPickingAndMounting>()`) |
+| StRS-001 | SyRS-220 | SwRS-007 | `src/backend/Centron.DAO/` — die sieben `SaveReceipt*Repository`-Klassen mit `SynchronizeReceiptData` und `SynchronizeReceiptItemData` |
+| StRS-002 | SyRS-003 | SwRS-002 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 7264-7285 |
+| StRS-002 | SyRS-003 | SwRS-191 | `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs` |
+| StRS-002 | SyRS-004 | SwRS-002 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 7264-7285 |
+| StRS-002 | SyRS-190 | SwRS-191 | `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs` |
+| StRS-002 | SyRS-199 | SwRS-197 | `src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs`, Zeile 182 (`private static ITwoFactorValidator _globalValidator;`) |
+| StRS-002 | SyRS-210 | SwRS-001 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 9598-9600 (`.OfType<IReceiptItemWithPickingAndMounting>()`) |
+| StRS-002 | SyRS-219 | SwRS-002 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 7264-7285 |
+| StRS-003 | SyRS-010 | SwRS-010 | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, Zeilen 95-111 |
+| StRS-003 | SyRS-010 | SwRS-019 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 7244-7255 |
+| StRS-003 | SyRS-011 | SwRS-010 | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, Zeilen 95-111 |
+| StRS-003 | SyRS-013 | SwRS-011 | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, Zeilen 42-46, 355-357, 391-393, 444-446 |
+| StRS-003 | SyRS-015 | SwRS-012 | `src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs`, Zeilen 1960 und 1976 |
+| StRS-003 | SyRS-079 | SwRS-070 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 8038-8039 |
+| StRS-003 | SyRS-200 | — | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, Zeilen 644-650 |
+| StRS-004 | SyRS-012 | SwRS-011 | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, Zeilen 42-46, 355-357, 391-393, 444-446 |
+| StRS-004 | SyRS-013 | SwRS-011 | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, Zeilen 42-46, 355-357, 391-393, 444-446 |
+| StRS-004 | SyRS-052 | SwRS-050 | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, Zeile 455 (`IsDirtyProperty`) |
+| StRS-004 | SyRS-229 | SwRS-051 | `src/backend/Centron.BL/Sales/Support/` mit den neun genannten Klassen |
+| StRS-005 | SyRS-016 | SwRS-013 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 416-488 |
+| StRS-005 | SyRS-017 | SwRS-013 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 416-488 |
+| StRS-005 | SyRS-018 | SwRS-020 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 497-527 |
+| StRS-005 | SyRS-018 | SwRS-184 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 397-404 |
+| StRS-005 | SyRS-019 | SwRS-020 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 497-527 |
+| StRS-005 | SyRS-020 | SwRS-021 | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, Zeilen 47-173 |
+| StRS-005 | SyRS-021 | SwRS-021 | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, Zeilen 47-173 |
+| StRS-005 | SyRS-021 | SwRS-196 | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, Zeilen 304-330 |
+| StRS-005 | SyRS-022 | SwRS-013 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 416-488 |
+| StRS-005 | SyRS-022 | SwRS-138 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 371-378 |
+| StRS-005 | SyRS-022 | SwRS-198 | `src/shared/Centron.Controls.Preview/` |
+| StRS-005 | SyRS-023 | SwRS-013 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 416-488 |
+| StRS-005 | SyRS-158 | SwRS-158 | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, Zeilen 72-73 |
+| StRS-005 | SyRS-201 | SwRS-021 | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, Zeilen 47-173 |
+| StRS-006 | SyRS-030 | SwRS-030 | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeilen 51-66 und 94-155 |
+| StRS-006 | SyRS-031 | SwRS-030 | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeilen 51-66 und 94-155 |
+| StRS-006 | SyRS-031 | SwRS-031 | `src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs`, Zeilen 181-194 |
+| StRS-006 | SyRS-034 | SwRS-030 | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeilen 51-66 und 94-155 |
+| StRS-006 | SyRS-035 | SwRS-032 | `src/webservice/Centron.Controllers/Controllers/Unversioned/JwtAuthController.cs`, Zeilen 25-39 |
+| StRS-006 | SyRS-036 | SwRS-033 | `src/backend/Centron.BL/Administration/Logins/TicketBL.cs`, Zeilen 166-170 |
+| StRS-006 | SyRS-036 | SwRS-178 | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeilen 70-84 und 100-106 |
+| StRS-006 | SyRS-038 | SwRS-033 | `src/backend/Centron.BL/Administration/Logins/TicketBL.cs`, Zeilen 166-170 |
+| StRS-006 | SyRS-038 | SwRS-034 | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeilen 21-42 |
+| StRS-006 | SyRS-039 | SwRS-034 | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeilen 21-42 |
+| StRS-007 | SyRS-032 | SwRS-031 | `src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs`, Zeilen 181-194 |
+| StRS-007 | SyRS-033 | SwRS-031 | `src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs`, Zeilen 181-194 |
+| StRS-008 | SyRS-014 | SwRS-040 | `SSMS_DB_SCHEMA.sql`, Tabelle `dbo.WebAccounts`, Zeilen 54842-54865 |
+| StRS-008 | SyRS-040 | SwRS-040 | `SSMS_DB_SCHEMA.sql`, Tabelle `dbo.WebAccounts`, Zeilen 54842-54865 |
+| StRS-008 | SyRS-041 | SwRS-041 | `src/nexus/CentronNexus/Shared/Auth/TicketFilterService.cs`, Zeilen 65-105 |
+| StRS-008 | SyRS-041 | SwRS-042 | `src/nexus/CentronNexus/Shared/Authorization/` mit den zwölf genannten Bausteinen |
+| StRS-008 | SyRS-042 | SwRS-040 | `SSMS_DB_SCHEMA.sql`, Tabelle `dbo.WebAccounts`, Zeilen 54842-54865 |
+| StRS-008 | SyRS-043 | SwRS-041 | `src/nexus/CentronNexus/Shared/Auth/TicketFilterService.cs`, Zeilen 65-105 |
+| StRS-008 | SyRS-043 | SwRS-042 | `src/nexus/CentronNexus/Shared/Authorization/` mit den zwölf genannten Bausteinen |
+| StRS-008 | SyRS-054 | SwRS-041 | `src/nexus/CentronNexus/Shared/Auth/TicketFilterService.cs`, Zeilen 65-105 |
+| StRS-009 | SyRS-015 | SwRS-012 | `src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs`, Zeilen 1960 und 1976 |
+| StRS-009 | SyRS-050 | SwRS-050 | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, Zeile 455 (`IsDirtyProperty`) |
+| StRS-009 | SyRS-051 | SwRS-050 | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, Zeile 455 (`IsDirtyProperty`) |
+| StRS-009 | SyRS-052 | SwRS-050 | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, Zeile 455 (`IsDirtyProperty`) |
+| StRS-009 | SyRS-054 | SwRS-041 | `src/nexus/CentronNexus/Shared/Auth/TicketFilterService.cs`, Zeilen 65-105 |
+| StRS-009 | SyRS-055 | SwRS-052 | `src/backend/Centron.BL/Sales/Support/HelpdeskCreationTemplateBL.cs` und `HelpdeskCategoryPatternBL.cs` |
+| StRS-009 | SyRS-129 | SwRS-129 | `src/backend/Centron.BL/Sales/Support/HelpdeskForwardBL.cs` |
+| StRS-009 | SyRS-129 | SwRS-200 | `src/backend/Centron.BL/ExternalHelpdesk/` |
+| StRS-009 | SyRS-228 | SwRS-050 | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, Zeile 455 (`IsDirtyProperty`) |
+| StRS-009 | SyRS-236 | SwRS-041 | `src/nexus/CentronNexus/Shared/Auth/TicketFilterService.cs`, Zeilen 65-105 |
+| StRS-010 | SyRS-052 | SwRS-050 | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs`, Zeile 455 (`IsDirtyProperty`) |
+| StRS-010 | SyRS-053 | SwRS-051 | `src/backend/Centron.BL/Sales/Support/` mit den neun genannten Klassen |
+| StRS-010 | SyRS-216 | SwRS-051 | `src/backend/Centron.BL/Sales/Support/` mit den neun genannten Klassen |
+| StRS-010 | SyRS-229 | SwRS-051 | `src/backend/Centron.BL/Sales/Support/` mit den neun genannten Klassen |
+| StRS-010 | SyRS-236 | SwRS-041 | `src/nexus/CentronNexus/Shared/Auth/TicketFilterService.cs`, Zeilen 65-105 |
+| StRS-011 | SyRS-060 | SwRS-060 | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, Zeile 60 (`public partial class AutomaticFacturaBL`) |
+| StRS-011 | SyRS-061 | SwRS-061 | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, Zeilen 1072-1086 |
+| StRS-011 | SyRS-066 | SwRS-064 | `src/backend/Centron.Entities/Entities/Sales/Receipts/ContractLists/ReceiptContract.cs` |
+| StRS-011 | SyRS-067 | SwRS-060 | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, Zeile 60 (`public partial class AutomaticFacturaBL`) |
+| StRS-011 | SyRS-068 | SwRS-060 | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, Zeile 60 (`public partial class AutomaticFacturaBL`) |
+| StRS-011 | SyRS-212 | SwRS-064 | `src/backend/Centron.Entities/Entities/Sales/Receipts/ContractLists/ReceiptContract.cs` |
+| StRS-011 | SyRS-214 | — | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 463-465 |
+| StRS-011 | SyRS-215 | SwRS-001 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 9598-9600 (`.OfType<IReceiptItemWithPickingAndMounting>()`) |
+| StRS-012 | SyRS-061 | SwRS-061 | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, Zeilen 1072-1086 |
+| StRS-012 | SyRS-062 | SwRS-062 | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, Zeilen 1066-1101 |
+| StRS-012 | SyRS-063 | SwRS-062 | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, Zeilen 1066-1101 |
+| StRS-013 | SyRS-064 | SwRS-063 | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, Zeilen 492, 522, 532, 765 |
+| StRS-013 | SyRS-065 | SwRS-063 | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, Zeilen 492, 522, 532, 765 |
+| StRS-013 | SyRS-130 | SwRS-130 | `src/backend/Centron.Entities/Entities/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListCompact.cs` und `MasterDataListItemsCompact.cs` |
+| StRS-013 | SyRS-204 | — | `Centron.Api.docuFORM/IDocuFormApiClient.cs` und `DocuFormRestApiClient.cs` |
+| StRS-014 | SyRS-070 | SwRS-070 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 8038-8039 |
+| StRS-014 | SyRS-070 | SwRS-135 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 8846-8859 |
+| StRS-014 | SyRS-079 | SwRS-070 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 8038-8039 |
+| StRS-015 | SyRS-071 | SwRS-071 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 9575-9578 |
+| StRS-015 | SyRS-072 | SwRS-071 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 9575-9578 |
+| StRS-015 | SyRS-142 | SwRS-142 | `src/backend/Centron.BL/Sales/Receipts/ArticleSearch/` mit den drei gleichnamig benannten Anbieterklassen |
+| StRS-016 | SyRS-073 | SwRS-072 | `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs`, Zeilen 221, 224, 227, 230 |
+| StRS-016 | SyRS-217 | SwRS-072 | `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs`, Zeilen 221, 224, 227, 230 |
+| StRS-016 | SyRS-218 | SwRS-072 | `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs`, Zeilen 221, 224, 227, 230 |
+| StRS-017 | SyRS-074 | SwRS-073 | `src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs`, Zeilen 179-184 |
+| StRS-017 | SyRS-075 | SwRS-073 | `src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs`, Zeilen 179-184 |
+| StRS-018 | SyRS-076 | SwRS-074 | `src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs`, Zeilen 833-838 |
+| StRS-018 | SyRS-076 | SwRS-075 | `src/backend/Centron.Gateway/ZUGFeRD21_Extended/` und `src/apis/Centron.Api.EbInterface/EbInterfaceLogic.cs` |
+| StRS-018 | SyRS-076 | SwRS-144 | `src/backend/Centron.BL/DataExchange/EDI/` und `src/backend/Centron.BL/EDI/` |
+| StRS-018 | SyRS-077 | SwRS-074 | `src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs`, Zeilen 833-838 |
+| StRS-018 | SyRS-077 | SwRS-144 | `src/backend/Centron.BL/DataExchange/EDI/` und `src/backend/Centron.BL/EDI/` |
+| StRS-018 | SyRS-222 | — | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 273-275 |
+| StRS-019 | SyRS-078 | SwRS-076 | `src/backend/Centron.BL/WebServices/DataExchange/BookKeeping/BookKeepingExportWebServiceBL.cs`, Zeilen 561-563 und `BookKeepingImportWebServiceBL.cs`, Zeilen 174-176 |
+| StRS-019 | SyRS-177 | SwRS-177 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeile 8872 |
+| StRS-019 | SyRS-217 | SwRS-072 | `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs`, Zeilen 221, 224, 227, 230 |
+| StRS-019 | SyRS-221 | SwRS-177 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeile 8872 |
+| StRS-020 | SyRS-080 | SwRS-080 | `src/backend/Centron.BL/Warehousing/StockManagement/ArticleStockBL.cs`, Zeilen 32-40 |
+| StRS-020 | SyRS-081 | SwRS-080 | `src/backend/Centron.BL/Warehousing/StockManagement/ArticleStockBL.cs`, Zeilen 32-40 |
+| StRS-020 | SyRS-223 | SwRS-080 | `src/backend/Centron.BL/Warehousing/StockManagement/ArticleStockBL.cs`, Zeilen 32-40 |
+| StRS-020 | SyRS-224 | SwRS-080 | `src/backend/Centron.BL/Warehousing/StockManagement/ArticleStockBL.cs`, Zeilen 32-40 |
+| StRS-020 | SyRS-225 | SwRS-001 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 9598-9600 (`.OfType<IReceiptItemWithPickingAndMounting>()`) |
+| StRS-020 | SyRS-226 | SwRS-080 | `src/backend/Centron.BL/Warehousing/StockManagement/ArticleStockBL.cs`, Zeilen 32-40 |
+| StRS-020 | SyRS-227 | SwRS-001 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 9598-9600 (`.OfType<IReceiptItemWithPickingAndMounting>()`) |
+| StRS-021 | SyRS-066 | SwRS-064 | `src/backend/Centron.Entities/Entities/Sales/Receipts/ContractLists/ReceiptContract.cs` |
+| StRS-021 | SyRS-082 | SwRS-081 | `src/backend/Centron.Entities/Entities/Sales/Receipts/MasterDataLists/MasterDataListItem.cs`, Zeilen 42 und 63 |
+| StRS-021 | SyRS-089 | SwRS-087 | `src/apis/Centron.Api.Gls/CentronGlsErrors.cs` |
+| StRS-022 | SyRS-009 | SwRS-006 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 3707-3757 |
+| StRS-022 | SyRS-083 | SwRS-082 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 9596-9605 |
+| StRS-023 | SyRS-084 | SwRS-083 | `src/backend/Centron.BL/Warehousing/InventoryManagement/InventoryBL.cs` und `InventoryNewBL.cs` |
+| StRS-024 | SyRS-085 | SwRS-084 | `src/backend/Centron.BL/Warehousing/StockManagement/ArticleStockBL.cs`, Zeilen 32-45 und 63-72 |
+| StRS-025 | SyRS-086 | SwRS-085 | `src/backend/Centron.Gateway/` mit den sieben EDI-Bereichen |
+| StRS-025 | SyRS-087 | SwRS-085 | `src/backend/Centron.Gateway/` mit den sieben EDI-Bereichen |
+| StRS-025 | SyRS-202 | — | `src/backend/Centron.Gateway/Concerto/ConcertoOrder.xsd` |
+| StRS-025 | SyRS-220 | SwRS-001 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 9598-9600 (`.OfType<IReceiptItemWithPickingAndMounting>()`) |
+| StRS-025 | SyRS-220 | SwRS-007 | `src/backend/Centron.DAO/` — die sieben `SaveReceipt*Repository`-Klassen mit `SynchronizeReceiptData` und `SynchronizeReceiptItemData` |
+| StRS-026 | SyRS-088 | SwRS-086 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 292-294 |
+| StRS-027 | SyRS-090 | SwRS-090 | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeile 1119 (`excelExportManager.AddColumn(...)`) |
+| StRS-027 | SyRS-093 | SwRS-093 | `src/backend/Centron.BL/SystemInfoLogger.cs` |
+| StRS-027 | SyRS-094 | SwRS-090 | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeile 1119 (`excelExportManager.AddColumn(...)`) |
+| StRS-027 | SyRS-219 | SwRS-002 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 7264-7285 |
+| StRS-027 | SyRS-224 | SwRS-080 | `src/backend/Centron.BL/Warehousing/StockManagement/ArticleStockBL.cs`, Zeilen 32-40 |
+| StRS-028 | SyRS-091 | SwRS-091 | `src/backend/Centron.Gateway/MspCollector/` |
+| StRS-029 | SyRS-092 | SwRS-092 | Die vier gleichnamigen Bereiche `MyDay` in Geschäftslogik, Entitäten, Steuerelementen und Portal |
+| StRS-029 | SyRS-229 | SwRS-051 | `src/backend/Centron.BL/Sales/Support/` mit den neun genannten Klassen |
+| StRS-029 | SyRS-230 | SwRS-092 | Die vier gleichnamigen Bereiche `MyDay` in Geschäftslogik, Entitäten, Steuerelementen und Portal |
+| StRS-029 | SyRS-231 | SwRS-170 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 125-127 |
+| StRS-030 | SyRS-100 | SwRS-100 | `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs`, Zeilen 34-63 und 64-376 |
+| StRS-030 | SyRS-101 | SwRS-100 | `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs`, Zeilen 34-63 und 64-376 |
+| StRS-030 | SyRS-195 | — | `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs`, Zeilen 34-63 |
+| StRS-031 | SyRS-102 | SwRS-101 | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeilen 527, 700 und 1052 |
+| StRS-031 | SyRS-113 | SwRS-101 | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeilen 527, 700 und 1052 |
+| StRS-031 | SyRS-113 | SwRS-113 | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeilen 1001 und 1045-1055 |
+| StRS-031 | SyRS-148 | SwRS-148 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeile 383 |
+| StRS-031 | SyRS-233 | — | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 386-393 |
+| StRS-031 | SyRS-234 | — | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 396-398 |
+| StRS-032 | SyRS-110 | SwRS-110 | `src/backend/Centron.BL/ReportEngine/` mit den sechs Datenklassen und fünf Unterverzeichnissen |
+| StRS-033 | SyRS-111 | SwRS-111 | `src/centron/Centron.WPF.UI/Modules/Administration/ReportServer/ReportServerAppModuleController.cs`, Zeile 13 (`MainCategory => CentronModuleCategory.Automate`) |
+| StRS-034 | SyRS-112 | SwRS-112 | `src/backend/Centron.Entities/Entities/MassUpdate/` |
+| StRS-035 | SyRS-113 | SwRS-101 | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeilen 527, 700 und 1052 |
+| StRS-035 | SyRS-113 | SwRS-113 | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs`, Zeilen 1001 und 1045-1055 |
+| StRS-036 | SyRS-114 | SwRS-114 | `src/backend/Centron.BL/Sales/Support/HelpdeskReplacementBL.cs`, `AdressstammReplacementBL.cs`, `ExternalToolsReplacementBL.cs` |
+| StRS-037 | SyRS-115 | SwRS-115 | `src/backend/Centron.BL/IndexSearch/GermanAnalyzer.cs` |
+| StRS-038 | SyRS-116 | SwRS-116 | `src/backend/Centron.BL/Security/PdfSigningBL.cs` als einziger Inhalt des Verzeichnisses |
+| StRS-039 | SyRS-117 | SwRS-117 | `SSMS_DB_SCHEMA.sql`, `dbo.Sichbenu`, Spalte `[Unterschrift] [image] NULL` (Zeile 18528) |
+| StRS-040 | SyRS-118 | SwRS-118 | `src/nexus/CentronNexus/WebCart/` mit den paarweisen `.razor`/`.razor.css`-Dateien |
+| StRS-040 | SyRS-213 | SwRS-118 | `src/nexus/CentronNexus/WebCart/` mit den paarweisen `.razor`/`.razor.css`-Dateien |
+| StRS-041 | SyRS-119 | SwRS-119 | `src/centron/Centron.WPF.UI/Modules/Finances/AccountManagement/ReceiptControls/Converter/WebReceiptStateToDisplayTextConverter.cs` und `WebReceiptStateToImageConverter.cs` |
+| StRS-042 | SyRS-120 | SwRS-120 | `src/backend/Centron.BL/SelfCare/SelfCareBL.cs`, Zeilen 47-149 |
+| StRS-043 | SyRS-121 | SwRS-121 | `src/nexus/CentronNexus.OutlookAddIn/CentronNexus.OutlookAddIn.csproj` und `SharedResource.resx` |
+| StRS-044 | SyRS-122 | SwRS-035 | `DeveloperSecurity.cs` (Ablage laut `docs/reference/security/developer-security.md`) |
+| StRS-044 | SyRS-122 | SwRS-122 | `src/backend/Centron.BL/Mail/` und `src/backend/Centron.BL/MailScanner/MailScannerBL.cs` |
+| StRS-044 | SyRS-222 | — | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 273-275 |
+| StRS-045 | SyRS-123 | SwRS-123 | `src/backend/Centron.BL/Calendar/CalendarBL.cs` und `src/backend/Centron.BL/Sales/Calendar/ScheduleBL.cs` |
+| StRS-045 | SyRS-232 | — | `SSMS_DB_SCHEMA.sql`, Zeile 18994 (`CONSTRAINT [RequestProPerson] UNIQUE NONCLUSTERED`) |
+| StRS-046 | SyRS-124 | SwRS-124 | `src/backend/Centron.BL/Outlook/` und `src/backend/Centron.Entities/Entities/Outlook/` |
+| StRS-047 | SyRS-125 | SwRS-125 | Die vier Telefoniebereiche in Geschäftslogik, Entitäten, Steuerelementen und Portal |
+| StRS-048 | SyRS-126 | SwRS-126 | Die fünf genannten KI-Bereiche |
+| StRS-049 | SyRS-127 | SwRS-127 | `src/centron/Centron.WPF.UI/Modules/Survey/SurveyAppModuleController.cs`, Zeile 5 (`: ICentronAppModuleController, IOnlyOpenOnceModule`) |
+| StRS-050 | SyRS-128 | SwRS-128 | Die beiden getrennten Modulzweige `ExpectedEvents/` und `ExpectedEventsReporting/` |
+| StRS-051 | SyRS-065 | SwRS-063 | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs`, Zeilen 492, 522, 532, 765 |
+| StRS-051 | SyRS-130 | SwRS-130 | `src/backend/Centron.Entities/Entities/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListCompact.cs` und `MasterDataListItemsCompact.cs` |
+| StRS-052 | SyRS-131 | SwRS-131 | `src/backend/Centron.BL/Sales/Support/Escalation/EscalationBL.cs` |
+| StRS-053 | SyRS-132 | SwRS-132 | `src/backend/Centron.BL/CheckListArea/` gegenüber `src/backend/Centron.Entities/Entities/ChecklistArea/` |
+| StRS-053 | SyRS-203 | — | `src/backend/Centron.BL/ItPlanner/ChecklistVirtualObjectCategoryBL.cs` |
+| StRS-054 | SyRS-133 | SwRS-133 | `src/nexus/CentronNexus/Management/TicketPatterns/Components/TicketPatternTree.razor` und `TicketPatternCategoryEditor.razor` |
+| StRS-055 | SyRS-134 | SwRS-134 | `src/backend/Centron.BL/TaskManager/` und `src/backend/Centron.BL/ToDoArea/` |
+| StRS-056 | SyRS-135 | SwRS-135 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 8846-8859 |
+| StRS-057 | SyRS-136 | SwRS-136 | `src/nexus/CentronNexus/ProductionOrderManagement/Model/` neben `src/backend/Centron.Entities/Entities/Production/` |
+| StRS-057 | SyRS-227 | SwRS-001 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 9598-9600 (`.OfType<IReceiptItemWithPickingAndMounting>()`) |
+| StRS-058 | SyRS-137 | SwRS-137 | `src/centron/Centron.WPF.UI/Modules/Global/VideoPortal/VideoPortalAppModuleController.cs`, Zeile 16 (`public string Description => null;`) |
+| StRS-059 | SyRS-138 | SwRS-138 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 371-378 |
+| StRS-060 | SyRS-139 | SwRS-139 | `src/centron/Centron.WPF.UI/Modules/Purchasing/TravelExpense/TravelExpenseAppModuleController.cs` |
+| StRS-061 | SyRS-006 | SwRS-003 | `src/backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs`, Zeilen 6-27 |
+| StRS-061 | SyRS-140 | SwRS-140 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 8912, 8940 und im Zahlungskonditionsblock |
+| StRS-062 | SyRS-141 | SwRS-141 | `src/apis/Centron.APIs.FinAPI/` mit `Requests/`, `Responses/`, `IFinApiClient.cs` |
+| StRS-062 | SyRS-218 | SwRS-072 | `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs`, Zeilen 221, 224, 227, 230 |
+| StRS-063 | SyRS-142 | SwRS-142 | `src/backend/Centron.BL/Sales/Receipts/ArticleSearch/` mit den drei gleichnamig benannten Anbieterklassen |
+| StRS-063 | SyRS-223 | SwRS-080 | `src/backend/Centron.BL/Warehousing/StockManagement/ArticleStockBL.cs`, Zeilen 32-40 |
+| StRS-064 | SyRS-143 | SwRS-143 | `src/webservice/Centron.Controllers/Controllers/v1/Integrations/DocBeeConnectorConfigurationController.cs` und `src/webservice/Centron.Controllers/Controllers/v1/DataExchange/DocBeeTicketTemplatesController.cs` |
+| StRS-065 | SyRS-144 | SwRS-144 | `src/backend/Centron.BL/DataExchange/EDI/` und `src/backend/Centron.BL/EDI/` |
+| StRS-066 | SyRS-145 | SwRS-145 | `src/backend/Centron.BL/Notifications/` und `src/backend/Centron.BL/NexusNotifications/` |
+| StRS-066 | SyRS-235 | SwRS-145 | `src/backend/Centron.BL/Notifications/` und `src/backend/Centron.BL/NexusNotifications/` |
+| StRS-067 | SyRS-146 | SwRS-146 | `docs/reference/database/script-rules.md`, Abschnitt „Standard Audit Columns" |
+| StRS-068 | SyRS-147 | SwRS-114 | `src/backend/Centron.BL/Sales/Support/HelpdeskReplacementBL.cs`, `AdressstammReplacementBL.cs`, `ExternalToolsReplacementBL.cs` |
+| StRS-068 | SyRS-147 | SwRS-147 | `src/backend/Centron.Entities/Entities/ExternalTools/` |
+| StRS-069 | SyRS-148 | SwRS-148 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeile 383 |
+| StRS-070 | SyRS-150 | SwRS-036 | `.editorconfig`, Abschnitt `[*.{cs,xaml}]` mit `charset = utf-8-bom` |
+| StRS-070 | SyRS-150 | SwRS-150 | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeilen 164-165, 202, 215 |
+| StRS-071 | SyRS-151 | SwRS-014 | `src/backend/Centron.DAO/Mappings/Administration/AppUserMaps.cs`, Zeilen 19-32 |
+| StRS-071 | SyRS-151 | SwRS-015 | `src/backend/Centron.Entities/BaseEntity.cs`, `BaseLongEntity.cs`, `PersistedEntity.cs`, `PersistedLongEntity.cs` |
+| StRS-071 | SyRS-151 | SwRS-016 | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeilen 73-85 und 162-166 |
+| StRS-071 | SyRS-151 | SwRS-017 | `src/centron/Centron.WPF.UI/Modules/Helpdesk/ExpectedEvents/Controller/ExpectedEventsAppModuleController.cs`, `CreateModuleInstance` |
+| StRS-071 | SyRS-151 | SwRS-018 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 7292-7307 |
+| StRS-071 | SyRS-151 | SwRS-022 | `src/backend/Centron.BL/WebServices/ObjectMapperConfiguration/AppUserConfiguration.cs`, Zeile 18 |
+| StRS-071 | SyRS-151 | SwRS-023 | `src/shared/Centron.Core/Guard.cs` |
+| StRS-071 | SyRS-151 | SwRS-151 | `src/centron/Centron.WPF.UI/Services/Logics/TwoFactorAuthenticator/` mit allen drei Dateien |
+| StRS-071 | SyRS-151 | SwRS-165 | `src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs`, Zeile 6 (`using Centron.Core;`) und `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeile 19 (`using Centron.Core.Utils;`) |
+| StRS-071 | SyRS-211 | SwRS-151 | `src/centron/Centron.WPF.UI/Services/Logics/TwoFactorAuthenticator/` mit allen drei Dateien |
+| StRS-072 | SyRS-152 | SwRS-152 | `docker/Dockerfile`, Zeilen 1-11 und 32-34 |
+| StRS-072 | SyRS-152 | SwRS-190 | `SSMS_DB_SCHEMA.sql`, `dbo.Sichbenu`, Spalten `[LoginTime] [datetime]`, `[LastWebLogin] [datetime]`, `[LetzKennAend] [datetime]`, `[LastTwoFactorValidatedAt] [datetime2](7)` |
+| StRS-072 | SyRS-181 | SwRS-181 | `docker/compose/appsettings.Production.json` mit neun Abschnitten |
+| StRS-072 | SyRS-193 | SwRS-181 | `docker/compose/appsettings.Production.json` mit neun Abschnitten |
+| StRS-072 | SyRS-194 | — | `src/nexus/CentronNexus.Host/Program.cs`, Zeile 145 |
+| StRS-072 | SyRS-196 | SwRS-019 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 7244-7255 |
+| StRS-072 | SyRS-196 | SwRS-053 | `docker/compose/appsettings.Production.json`, Abschnitt `TicketCache` |
+| StRS-072 | SyRS-197 | — | `docker/compose/compose.yaml`, `restart: on-failure` bei `webservice` und `nexus`, Dienst `db` ohne Volumenangabe |
+| StRS-072 | SyRS-205 | SwRS-190 | `SSMS_DB_SCHEMA.sql`, `dbo.Sichbenu`, Spalten `[LoginTime] [datetime]`, `[LastWebLogin] [datetime]`, `[LetzKennAend] [datetime]`, `[LastTwoFactorValidatedAt] [datetime2](7)` |
+| StRS-072 | SyRS-237 | — | `src/webservice/c-entron.misc.ConnectionManager/ConnectionManagerViewModel.cs`, Zeilen 919-924 |
+| StRS-073 | SyRS-153 | SwRS-153 | `src/backend/Centron.BL/Administration/Scripts/ScriptEngineBL.cs`, Zeilen 49-54 |
+| StRS-073 | SyRS-153 | SwRS-154 | `src/backend/Centron.BL/Administration/Scripts/ScriptEngineBL.cs`, Zeilen 82-98 |
+| StRS-073 | SyRS-153 | SwRS-155 | `src/backend/Centron.BL/Administration/Scripts/ScriptEngineBL.cs`, Zeilen 58-75 |
+| StRS-073 | SyRS-153 | SwRS-199 | `src/backend/Centron.BL/Administration/Scripts/ScriptMethods/Scripts/ScriptMethod11152.cs` Zeilen 53 und 144 sowie sieben weitere Skripte mit identischer Zuweisung |
+| StRS-073 | SyRS-154 | SwRS-153 | `src/backend/Centron.BL/Administration/Scripts/ScriptEngineBL.cs`, Zeilen 49-54 |
+| StRS-074 | SyRS-154 | SwRS-153 | `src/backend/Centron.BL/Administration/Scripts/ScriptEngineBL.cs`, Zeilen 49-54 |
+| StRS-075 | SyRS-020 | SwRS-021 | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, Zeilen 47-173 |
+| StRS-075 | SyRS-036 | SwRS-033 | `src/backend/Centron.BL/Administration/Logins/TicketBL.cs`, Zeilen 166-170 |
+| StRS-075 | SyRS-036 | SwRS-178 | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeilen 70-84 und 100-106 |
+| StRS-075 | SyRS-037 | SwRS-033 | `src/backend/Centron.BL/Administration/Logins/TicketBL.cs`, Zeilen 166-170 |
+| StRS-075 | SyRS-037 | SwRS-156 | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, Zeilen 276-284 |
+| StRS-075 | SyRS-092 | SwRS-092 | Die vier gleichnamigen Bereiche `MyDay` in Geschäftslogik, Entitäten, Steuerelementen und Portal |
+| StRS-075 | SyRS-155 | SwRS-156 | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, Zeilen 276-284 |
+| StRS-075 | SyRS-178 | SwRS-032 | `src/webservice/Centron.Controllers/Controllers/Unversioned/JwtAuthController.cs`, Zeilen 25-39 |
+| StRS-075 | SyRS-178 | SwRS-178 | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeilen 70-84 und 100-106 |
+| StRS-076 | SyRS-019 | SwRS-020 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 497-527 |
+| StRS-076 | SyRS-156 | SwRS-157 | `src/webservice/Centron.Controllers/Controllers/v1/Administration/AccessTokensController.cs`, Zeilen 11-16 und 30-38 |
+| StRS-076 | SyRS-157 | SwRS-157 | `src/webservice/Centron.Controllers/Controllers/v1/Administration/AccessTokensController.cs`, Zeilen 11-16 und 30-38 |
+| StRS-077 | SyRS-158 | SwRS-158 | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs`, Zeilen 72-73 |
+| StRS-078 | SyRS-159 | SwRS-093 | `src/backend/Centron.BL/SystemInfoLogger.cs` |
+| StRS-078 | SyRS-159 | SwRS-159 | `src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs`, Zeile 19 und `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeile 54 |
+| StRS-079 | SyRS-160 | SwRS-053 | `docker/compose/appsettings.Production.json`, Abschnitt `TicketCache` |
+| StRS-079 | SyRS-160 | SwRS-160 | `src/webservice/Centron.Host/AspNetCore/HostedServices/ManagedBackgroundService.cs` |
+| StRS-080 | SyRS-007 | SwRS-004 | `src/backend/Centron.DAO/` — `AssetHeadDAO.SaveAssetVersion` mit `DoGetFieldList()` |
+| StRS-080 | SyRS-007 | SwRS-161 | `src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs` |
+| StRS-080 | SyRS-011 | SwRS-010 | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, Zeilen 95-111 |
+| StRS-080 | SyRS-038 | SwRS-033 | `src/backend/Centron.BL/Administration/Logins/TicketBL.cs`, Zeilen 166-170 |
+| StRS-080 | SyRS-038 | SwRS-034 | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeilen 21-42 |
+| StRS-080 | SyRS-146 | SwRS-146 | `docs/reference/database/script-rules.md`, Abschnitt „Standard Audit Columns" |
+| StRS-080 | SyRS-161 | SwRS-146 | `docs/reference/database/script-rules.md`, Abschnitt „Standard Audit Columns" |
+| StRS-080 | SyRS-161 | SwRS-161 | `src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs` |
+| StRS-080 | SyRS-161 | SwRS-162 | `src/backend/Centron.BL/ChangeTracking/` und `src/backend/Centron.Entities/Entities/ChangeTracking/` |
+| StRS-080 | SyRS-191 | SwRS-161 | `src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs` |
+| StRS-081 | SyRS-170 | SwRS-170 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 125-127 |
+| StRS-082 | SyRS-171 | SwRS-171 | `src/backend/Centron.BL/Finances/ProductLifecycleBL.cs` |
+| StRS-083 | SyRS-172 | SwRS-172 | `src/shared/Centron.Controls/AccountContracts/` |
+| StRS-084 | SyRS-172 | SwRS-172 | `src/shared/Centron.Controls/AccountContracts/` |
+| StRS-084 | SyRS-173 | SwRS-173 | `src/backend/Centron.BL/CustomerArea/` und `src/backend/Centron.BL/Accounts/` |
+| StRS-085 | SyRS-174 | SwRS-164 | `src/shared/Centron.Controls/` mit den genannten Bereichen |
+| StRS-085 | SyRS-174 | SwRS-174 | Die drei genannten Bereiche |
+| StRS-086 | SyRS-175 | SwRS-175 | `src/backend/Centron.BL/Warehousing/CostCenterBL.cs` und `CostObjectBL.cs` |
+| StRS-087 | SyRS-176 | SwRS-176 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, `UpdateCurrencyFactor` (Zeilen 8359-8370) |
+| StRS-088 | SyRS-177 | SwRS-177 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeile 8872 |
+| StRS-088 | SyRS-221 | SwRS-177 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeile 8872 |
+| StRS-089 | SyRS-178 | SwRS-032 | `src/webservice/Centron.Controllers/Controllers/Unversioned/JwtAuthController.cs`, Zeilen 25-39 |
+| StRS-089 | SyRS-178 | SwRS-178 | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeilen 70-84 und 100-106 |
+| StRS-090 | SyRS-179 | SwRS-179 | `src/backend/Centron.BL/TradePool/Core/` und `src/backend/Centron.Gateway/Core/` |
+| StRS-091 | SyRS-180 | SwRS-161 | `src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs` |
+| StRS-091 | SyRS-180 | SwRS-180 | `src/backend/Centron.BL/Sales/Receipts/ReceiptProgressionBL.cs`, Zeilen 20-52 und 75 |
+| StRS-092 | SyRS-181 | SwRS-181 | `docker/compose/appsettings.Production.json` mit neun Abschnitten |
+| StRS-092 | SyRS-198 | — | `README.md`, Abschnitte „2. Which components to use" und „3. Custom CSS" |
+| StRS-093 | SyRS-182 | SwRS-182 | `azure/build-pipeline.yml`, Zeilen 18-38 |
+| StRS-093 | SyRS-182 | SwRS-194 | `Centron.Api.docuFORM/Centron.Api.docuFORM.csproj` |
+| StRS-093 | SyRS-182 | SwRS-195 | `nugets/` mit 13 Paketen, darunter zwei FastReport-Hauptversionen |
+| StRS-094 | SyRS-183 | SwRS-163 | `tests/` mit den sieben Projektgruppen |
+| StRS-094 | SyRS-183 | SwRS-183 | `azure/` mit den sechs Pipeline-Dateien und dem Vorlagenverzeichnis |
+| StRS-094 | SyRS-183 | SwRS-192 | `Directory.Build.props`, Zeilen 40-43 |
+| StRS-094 | SyRS-183 | SwRS-193 | `azure/build-pipeline.yml`, `failTaskOnFailedTests: true` |
+| StRS-095 | SyRS-184 | SwRS-184 | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 397-404 |
+| StRS-096 | SyRS-066 | SwRS-064 | `src/backend/Centron.Entities/Entities/Sales/Receipts/ContractLists/ReceiptContract.cs` |
+| StRS-096 | SyRS-212 | SwRS-064 | `src/backend/Centron.Entities/Entities/Sales/Receipts/ContractLists/ReceiptContract.cs` |
+| StRS-097 | SyRS-066 | SwRS-064 | `src/backend/Centron.Entities/Entities/Sales/Receipts/ContractLists/ReceiptContract.cs` |
+| StRS-098 | SyRS-031 | SwRS-030 | `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs`, Zeilen 51-66 und 94-155 |
+| StRS-098 | SyRS-031 | SwRS-031 | `src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs`, Zeilen 181-194 |
+| StRS-098 | SyRS-233 | — | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs`, Zeilen 386-393 |
+| StRS-099 | SyRS-001 | SwRS-001 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 9598-9600 (`.OfType<IReceiptItemWithPickingAndMounting>()`) |
+| StRS-099 | SyRS-001 | SwRS-006 | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Zeilen 3707-3757 |
+| StRS-099 | SyRS-001 | SwRS-007 | `src/backend/Centron.DAO/` — die sieben `SaveReceipt*Repository`-Klassen mit `SynchronizeReceiptData` und `SynchronizeReceiptItemData` |
+| StRS-099 | SyRS-001 | SwRS-008 | `src/backend/Centron.Entities/Entities/DbEntities/` und `src/backend/Centron.DAO/Mappings/TemporaryEntities/` |
+| StRS-099 | SyRS-001 | SwRS-009 | `SSMS_DB_SCHEMA.sql` — die Tabellen `AngKopf`, `AufKopf`, `LiefKopf`, `RechKopf`, `VertragKopf`, `GutKopf`, `AbholKopf` und die zugehörigen Sichten |
+| StRS-100 | SyRS-130 | SwRS-130 | `src/backend/Centron.Entities/Entities/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListCompact.cs` und `MasterDataListItemsCompact.cs` |
+
+## 3. Abdeckung der Ebenen
+
+| Ebene | Anforderungen | in der Tabelle enthalten | ohne Verknüpfung zur nächsthöheren Ebene |
+|---|---|---|---|
+| StRS | 100 | 100 | entfällt (oberste Ebene) |
+| SyRS | 190 | 190 | 0 |
+| SwRS | 144 | 144 | 0 |

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-37c5/Protokoll.md

@@ -0,0 +1,207 @@
+# Messprotokoll – Versuch 01 (V1 Baseline, Prompt-only) – Iteration 02
+
+## Lauf
+- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
+- **Iteration:** 02 – vom User ausdrücklich benannt; entspricht zugleich der Regel „höchste
+  vorhandene Iterationsnummer". Wiederholungslauf zur Varianzbestimmung in derselben Zelle.
+- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
+- **Startzeit:** 2026-08-26T13:22:48.5391662+02:00
+- **Endzeit:** 2026-08-26T15:55:35.0007167+02:00
+- **Dauer gesamt:** 2:32:46 (`duration_ms` 2:32:44; API: 2:27:51)
+  — **im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar**
+- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.662 versionierte Dateien)
+- **Codebasis-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748` (dirty: nein)
+- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja (Prüfmuster ohne Treffer);
+  die Codebasis ist seit Commit `f045b99a` kein eigenes Repository mehr, sondern Teil des
+  Arbeitsrepos – der Vorher/Nachher-Vergleich läuft deshalb pfadskopiert
+- **Snapshot-Zusatzartefakte:** keine – der Snapshot entspricht dem Commit-Stand
+- **Prompt-Repo-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748`
+
+## Werkzeugkonfiguration
+- **Skill-Version:** 4.4.0
+- **Claude-Code-Version:** 2.1.246
+- **CLI-Pfad:** `C:\Users\ChristophSchwoerer\.vscode\extensions\anthropic.claude-code-2.1.246-win32-x64\resources\native-binary\claude.exe`
+- **Modell (angefordert):** `claude-opus-5`
+- **Modelle (tatsächlich eingesetzt):** `claude-opus-5` 77.289.201 Tokens (99.99 %), `claude-haiku-4-5-20251001` 6.967 Tokens (0.01 %)
+- **Kontrolle Modell:** bestanden – ausschließlich das angeforderte Modell plus Haiku als zulässiger interner Hilfsaufruf
+- **Effort:** `max` (per `--effort max` gesetzt)
+- **Laufverzeichnis-ID:** `v4.4.0-37c5`
+- **Ablage:** `Iteration 3/claude-opus-5/solo/max/`
+- **Parallele Läufe:** **ja** – zeitgleich liefen:
+  - `Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-a8f5`
+  - `Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-fcdf`
+  - `Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048`
+  - `Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-f8b4`
+  - `Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-fb24`
+
+  Die Zeitangaben dieses Laufs sind daher **nicht** für Laufzeitvergleiche zu verwenden. Tokenverbrauch, Anforderungszahl, Belegkennzahlen und Denials bleiben unverzerrt.
+- **Agentenmodus:** `solo` (V1)
+- **Kontextfenster:** 1.000.000 Tokens; `maxOutputTokens` 64.000
+- **Sampling-Parameter:** nicht steuerbar über die CLI, nicht erfasst
+- **Nur bei lokalem Modellbetrieb:** entfällt (Cloud-Inferenz, `provider: firstParty`)
+- **Permission-Mode:** `acceptEdits`
+- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` /
+  `--disallowedTools` 33er-Denylist (schreibende und bauende Kommandos) **zuzüglich** `Task`, `Agent`, `Workflow` aus dem Modus `solo`
+- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
+- **MCP-Server / Agentendateien:** keine – aus dem Snapshot entfernt, zusätzlich `--safe-mode`
+- **Subagenten:** keine (`spawned` = 0, `by_type` leer)
+- **Verschachtelung:** `spawned` = 0, davon `spawned_by_subagents` = 0, `max_depth` = 0. Keine tieferen Ebenen, `_meta\subagenten.md` entfällt.
+
+## Validierungsstichprobe
+- **Größe:** noch nicht festgelegt
+- **Ziehungsverfahren:** noch nicht festgelegt
+- **Validatoren:** noch nicht festgelegt
+- **Stand:** noch nicht gezogen
+
+## Verbrauch
+
+### Hauptagent (`usage`)
+| Messgröße | Wert |
+|---|---:|
+| Input-Tokens | 344 |
+| Output-Tokens | 673.633 (davon 39.455 Thinking-Tokens) |
+| Cache-Write-Tokens | 785.321 |
+| Cache-Read-Tokens | 75.536.248 |
+| Agent-Turns | 231 |
+
+### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
+| Messgröße | `claude-opus-5` | `claude-haiku-4-5-20251001` | Summe |
+|---|---:|---:|---:|
+| Input-Tokens | 346 | 6.944 | 7.290 |
+| Output-Tokens | 673.635 | 23 | 673.658 |
+| Cache-Write-Tokens | 803.724 | 0 | 803.724 |
+| Cache-Read-Tokens | 75.811.496 | 0 | 75.811.496 |
+| **Tokens gesamt** | **77.289.201** | **6.967** | **77.296.168** |
+
+**Tokens gesamt: 77.296.168** — Input + Output + Cache-Write + Cache-Read über alle Modelle.
+Das ist die **berichtete Aufwandsgröße** der Versuchsreihe. `total_cost_usd` bleibt unberührt in
+`RawResult.json` erhalten, wird aber nicht ins Protokoll übernommen: Token sind modell- und
+preisunabhängig und bleiben damit über Preisänderungen und Modellwechsel hinweg vergleichbar.
+
+Da im Modus `solo` keine Subagenten laufen, sind `usage` und `modelUsage` für das Hauptmodell
+deckungsgleich; die Differenz zur Summe stammt allein aus den Haiku-Hilfsaufrufen.
+
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 100 | 23,0 % |
+| SyRS | 190 | 43,8 % |
+| SwRS | 144 | 33,2 % |
+| **Gesamt** | **434** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 171 | 39,4 % |
+| Sicherheit | 78 | 18,0 % |
+| Daten | 75 | 17,3 % |
+| Schnittstelle | 62 | 14,3 % |
+| nicht-funktional | 48 | 11,1 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 945 |
+| davon `PRIMÄR` | 766 (81,1 %) |
+| davon `SEKUNDÄR` | 113 (12,0 %) |
+| davon `KONTEXT` | 66 (7,0 %) |
+| Belege je Anforderung (Median) | 2,0 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 434 (100,0 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 385 | 88,7 % |
+| workaround | 30 | 6,9 % |
+| sonderfall | 7 | 1,6 % |
+| veraltet | 12 | 2,8 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 400 | 92,2 % |
+| als `HYPOTHESE` gekennzeichnet | 34 | 7,8 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 86 | 19,8 % |
+| mit ISO-25010-Qualitätsmerkmal | 48 | 11,1 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (137 risikorelevante Anforderungen, alle gedeckt) |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 434 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 434 von 434 mit Tracelinks (100,0 %) |
+
+## Ergebnis
+- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
+- **Session-ID:** `57813485-54b0-4a1a-ad5f-4c9a84fb13ab`
+- **Permission-Denials:** 7 (5 × `Bash`, 2 × `PowerShell`) – **keines auf `Task`/`Agent`/`Workflow`**. Der Agent hat zu keinem Zeitpunkt zu delegieren versucht; die Modus-Sperre wurde nie ausgelöst.
+- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0 – Bedingung `solo` eingehalten
+- **Subagenten-Prompts:** entfällt (Modus `solo`)
+- **Erzeugte Dateien:** 10 Dateien in `Ergebnisse\`:
+
+  | Datei | Größe |
+  |---|---:|
+  | `Analysebericht.md` | 112.975 B |
+  | `Glossar.md` | 23.253 B |
+  | `Hypothesen.md` | 57.210 B |
+  | `StRS.md` | 193.855 B |
+  | `SwRS.md` | 237.972 B |
+  | `SyRS.md` | 337.376 B |
+  | `Traceability.md` | 39.200 B |
+  | `_p_StRS_2.md` | 0 B |
+  | `_p_StRS_3.md` | 0 B |
+  | `_p_StRS_4.md` | 0 B |
+
+- **Root unverändert:** ja (zeilenendennormalisiert verglichen).
+- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
+
+## Anmerkungen/Auffälligkeiten
+
+**1. Iteration 3 – Snapshot mit DB-Schema.** `SSMS_DB_SCHEMA.sql` (3.266.626 B, 76.793 Zeilen,
+1.558 Tabellen, 182 Views, 63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel; SHA-256
+`ED7F2125…1FA8DB`) ist seit Commit `f349d189` Bestandteil des Untersuchungsgegenstands. Läufe der
+Iteration 2 hatten die Datei nicht – beide Iterationen sind **nicht poolbar**.
+
+**2. Parallelbetrieb – Zeitangaben unbrauchbar, Verbrauchsgrößen gültig.** Wanduhrzeit,
+`duration_ms` und `duration_api_ms` sind verzerrt; Tokenverbrauch, Anforderungszahl,
+Belegkennzahlen und Denials nicht. Einziger gültiger Laufzeitmesspunkt aller drei Iterationen
+bleibt der serielle Lauf `084301_v4.2.0-d6f9` mit 45:04.
+
+**3. CLI 2.1.246** statt der gegen 2.1.245 verifizierten Fassung.
+
+**4. Einziger Lauf der Reihe mit 100 % Primärbelegquote.** Alle 434 Anforderungen tragen
+mindestens einen `PRIMÄR`-Beleg – 945 Belege insgesamt, Median 2,0. Kein anderer Lauf beider
+Iterationen erreicht diesen Wert (bisheriges Maximum 98,2 %).
+
+**5. Bestätigt den Effort-Befund der Zelle.** Zusammen mit `a8f5` (Median 2,0) und `fcdf`
+(Median 3,0) liegen alle drei `max`-Läufe über der Belegdichte sämtlicher 44 `high`-Läufe, die
+durchgängig bei Median 1,0 lagen. Die Wirkung ist damit in der Zelle reproduziert, nicht nur
+einmal beobachtet.
+
+**6. Ebenenverteilung mit Schwerpunkt System:** 100 StRS / 190 SyRS / 144 SwRS (43,8 % SyRS).
+Innerhalb der `max`-Zelle streut die Verteilung deutlich weniger als auf `high` – die drei Läufe
+liegen zwischen 23,0 % und 33,6 % StRS gegenüber 4,6 % bis 92,7 % über die `high`-Läufe.
+
+**7. Drei leere Streudateien: `_p_StRS_2.md`, `_p_StRS_3.md`, `_p_StRS_4.md`,** alle 0 Byte, um
+14:46 angelegt und nie befüllt. Der Agent hat offenbar begonnen, `StRS.md` in Teilstücke zu
+zerlegen, und den Ansatz verworfen – `StRS.md` wurde danach als eine Datei fertiggestellt
+(193.855 B um 15:54). Sieben Denials, darunter Aufräumversuche, die von der Denylist gestoppt
+wurden; die leeren Dateien blieben deshalb liegen und werden bewusst nicht entfernt.
+
+**8. Modellkontrolle bestanden** (nur `claude-opus-5` + Haiku), `spawned` = 0 – `solo`-Bedingung
+eingehalten. Mit 2:33 Laufzeit der längste Lauf der Versuchsreihe.

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-37c5/_meta/anforderungen.md

@@ -0,0 +1,65 @@
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 100 | 23,0 % |
+| SyRS | 190 | 43,8 % |
+| SwRS | 144 | 33,2 % |
+| **Gesamt** | **434** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 171 | 39,4 % |
+| Sicherheit | 78 | 18,0 % |
+| Daten | 75 | 17,3 % |
+| Schnittstelle | 62 | 14,3 % |
+| nicht-funktional | 48 | 11,1 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 945 |
+| davon `PRIMÄR` | 766 (81,1 %) |
+| davon `SEKUNDÄR` | 113 (12,0 %) |
+| davon `KONTEXT` | 66 (7,0 %) |
+| Belege je Anforderung (Median) | 2,0 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 434 (100,0 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 385 | 88,7 % |
+| workaround | 30 | 6,9 % |
+| sonderfall | 7 | 1,6 % |
+| veraltet | 12 | 2,8 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 400 | 92,2 % |
+| als `HYPOTHESE` gekennzeichnet | 34 | 7,8 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 86 | 19,8 % |
+| mit ISO-25010-Qualitätsmerkmal | 48 | 11,1 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (137 risikorelevante Anforderungen, alle gedeckt) |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 434 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 434 von 434 mit Tracelinks (100,0 %) |
+

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-37c5/_meta/before.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-37c5/_meta/combined_prompt.md

@@ -0,0 +1,177 @@
+# Versuch 01 - Baseline (Prompt-only) - Iteration 02
+
+## Metadaten
+- **Versuch:** V1 Baseline (Prompt-only)
+- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
+- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
+- **Zeitstempel:** 2026-08-26
+- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
+- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
+
+  | Änderung | Auslösender Befund |
+  |---|---|
+  | Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
+  | Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
+  | Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
+  | Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
+  | Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
+  | Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
+  | Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
+
+  Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
+
+> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
+> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
+> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
+
+---
+
+## Prompt
+
+Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
+
+### Auftrag
+
+Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
+
+1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
+2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
+3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
+
+Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
+
+### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
+
+Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
+
+**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
+
+### Vorgehen (statische Analyse, keine Ausführung)
+
+Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
+
+**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
+
+**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig.
+
+**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
+
+2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
+3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
+4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
+5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
+6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
+
+### Pflicht-Eigenschaften jeder Anforderung
+
+- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
+- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
+- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
+- **Belegklassifikation:** Kennzeichne jeden Beleg als
+  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
+  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
+  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
+- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
+- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
+- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
+- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
+- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
+
+### Formatvorgabe pro Anforderung
+
+```
+ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
+Titel:         <kurzer Titel>
+Ebene:         <StRS | SyRS | SwRS>
+Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
+Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
+Akteur:        <Rolle / System / Komponente>
+Vorbedingung:  <Zustand vor Auslösen>
+Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
+Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
+Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
+Belege:
+  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
+  - [SEKUNDÄR] <...> - Begründung: <...>
+  - [KONTEXT]  <...> - Begründung: <...>
+Prüfidee:      <Akzeptanzkriterium oder Testidee>
+Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
+Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
+Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
+Status:        <belegt | HYPOTHESE>
+```
+
+### Traceability
+
+Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
+- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
+- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
+- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
+
+### Nicht-funktionale Anforderungen
+
+- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
+- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
+
+### Konsolidierungsbedarf
+
+Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
+
+**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
+
+### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
+
+```
+Ergebnisse/
+  StRS.md
+  SyRS.md
+  SwRS.md
+  Traceability.md   (oder Traceability.csv)
+  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
+  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
+  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
+                     Selbstbewertung, bekannte Lücken)
+```
+
+Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
+
+### Randbedingungen
+
+- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
+- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
+- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
+- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
+- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
+
+### Abschluss
+
+Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
+- Doppelte oder mehrfach vergebene IDs
+- Anforderungen ohne Beleg
+- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
+- Tracelinks auf nicht existierende IDs
+- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
+- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
+- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
+
+Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
+
+Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
+- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
+- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
+- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
+- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
+- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
+
+---
+
+### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
+Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien sowie das Ausführen von
+Kommandozeilenbefehlen im Arbeitsverzeichnis.
+Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.
+Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
+Werkzeuge zu ersetzen.
+### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
+Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
+`c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 3\claude-opus-5\solo\max\02_Lauf_2026-08-26_132237_v4.4.0-37c5\Ergebnisse\`.
+Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-37c5/_meta/endzeit.txt

@@ -0,0 +1 @@
+2026-08-26T15:55:35.0007167+02:00

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-37c5/_meta/startzeit.txt

@@ -0,0 +1 @@
+2026-08-26T13:22:48.5391662+02:00

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-a8f5/Ergebnisse/Analysebericht.md

@@ -0,0 +1,757 @@
+# Analysebericht — Reverse Requirements Engineering c-entron ERP-Suite
+
+**Untersuchungsgegenstand:** gesamte Codebasis im Arbeitsverzeichnis `C:\DEV\MasterArbeit\QuellCode\CentronERP`
+**Methode:** statische Analyse (Lesen, Suchen, Kommandozeile). Keine Ausführung, kein Datenbankzugriff, keine laufende Instanz.
+**Norm:** ISO/IEC/IEEE 29148:2018 (StRS / SyRS / SwRS), Qualitätsmerkmale nach ISO/IEC 25010.
+**Datum des Laufs:** 2026-08-26
+
+---
+
+## 0. Kennzahlen des Untersuchungsgegenstands
+
+Alle Zahlen wurden per Kommandozeile über das Arbeitsverzeichnis ermittelt (Ausschluss von `bin/` und `obj/`):
+
+| Kennzahl | Wert | Ermittlung |
+|---|---|---|
+| C#-Quelldateien unter `src/` | 14.312 | `find ./src -name "*.cs" -not -path "*/obj/*" -not -path "*/bin/*" \| wc -l` |
+| XAML-Dateien unter `src/` | 1.233 | analog |
+| Razor-Komponenten unter `src/` | 491 | analog |
+| Projektdateien in `Centron.sln` (`.csproj`/`.wixproj`) | 46 | `grep -oE '"[^"]+\.(csproj\|wixproj)"' Centron.sln \| sort -u \| wc -l` |
+| Tabellen im DB-Schema-Dump | 1.535 | `grep -c "^CREATE TABLE" SSMS_DB_SCHEMA.sql` |
+| Views | 153 | `grep -c "^CREATE VIEW"` |
+| Stored Procedures | 52 | `grep -c "^CREATE PROCEDURE"` |
+| Funktionen | 28 | `grep -c "^CREATE FUNCTION"` |
+| Fremdschlüssel | 134 | `grep -c "FOREIGN KEY"` |
+| CHECK-Constraints | 154 | `grep -c "CHECK CONSTRAINT\|CONSTRAINT.*CHECK"` |
+| UNIQUE-Indizes | 26 | `grep -c "CREATE UNIQUE"` |
+| Trigger | 0 | `grep -c "^CREATE TRIGGER"` |
+| Markdown-Entwicklerdokumente unter `docs/` | 44 | `find ./docs -name "*.md" \| wc -l` |
+
+**Produkt- und Herstellerangabe** aus `Directory.Build.props`: `Product = NEXOWARE c-entron ERP`, `Company = NEXOWARE Systems GmbH`, Copyright-Zeitraum 2012–2026. Version laut `version.json`: `2.0.2611-alpha`.
+
+---
+
+## 1. Modulinventar (Schritt 0)
+
+Das Inventar wurde **vor** der ersten Anforderung erstellt. Grundlage sind vier unabhängige Quellen:
+
+1. `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs` — die registrierten fachlichen Module des WPF-Clients, dort bereits in Kommentar-Regionen fachlich gruppiert (`#region c-entron Module: Abrechnung`, `… Administration`, `… Adressen/CRM`, `… Automatisierung`, `… Buchhaltung/Finanzen`, `… Controlling/Analytics`, `… Einkauf`, `… Helpdesk`, `… Hilfe`, `… Logistik`, `… MyCentron`, `… Passwort Manager (obsolate)`, `… Produktion`, `… Stammdaten`, `… Verträge`).
+2. Die Ordnerstruktur von `src/backend/Centron.BL/` (90 fachliche Unterordner) für Server-seitige Domänen ohne eigenes Client-Modul.
+3. Die Projektliste aus `Centron.sln` für Dienste, Portale, externe API-Assemblies und Infrastruktur.
+4. `docs/getting-started/ai-codebase-navigation.md` für die Zuordnung Pfad → Rolle.
+
+Das Inventar umfasst **135 Module**. Es ist die Bezugsgröße der Abdeckungstabelle in Abschnitt 2.
+
+### 1.1 Vertrieb, Belegwesen, Verträge und Abrechnung
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M-001 | Adressstamm (Konten, Kunden, Lieferanten) | `src/centron/Centron.WPF.UI/Modules/Finances/AccountManagement`, `src/backend/Centron.BL/Accounts` | Führt Geschäftspartner als Konto mit Kunden- und/oder Lieferantenrolle inkl. Adressen und Ansprechpartnern. |
+| M-002 | CRM / Kontakthistorie | `src/centron/Centron.WPF.UI/Modules/Finances/Crm`, `src/backend/Centron.BL/Sales/Customers/CRM` | Erfasst Aktivitäten, Tätigkeiten und Kontakthistorie zu Konten. |
+| M-003 | CRM-Projekte | `src/centron/Centron.WPF.UI/Modules/Finances/Projects`, `src/backend/Centron.BL/Sales/Customers/CrmProjects` | Bündelt Vertriebsvorgänge zu einem Kundenprojekt. |
+| M-004 | Kampagnen / Mailing | `src/centron/Centron.WPF.UI/Modules/Finances/Campaigns`, `src/backend/Centron.BL/Mailings` | Serienanschreiben und Kampagnensteuerung auf Kontobasis. |
+| M-005 | Lieferanten-Verträge (Account Contracts) | `src/centron/Centron.WPF.UI/Modules/Finances/Crm/AccountContracts` | Verwaltet Verträge, die das Unternehmen mit Lieferanten hält. |
+| M-006 | Stammblätter (Master Data Lists) | `src/centron/Centron.WPF.UI/Modules/Finances/MasterDataLists`, `src/backend/Centron.Entities/Entities/Sales/Receipts/MasterDataLists` | Führt Geräte-Stammblätter mit Seriennummern, überwiegend für Druck-/Kopiersysteme. |
+| M-007 | Produktlebenszyklus (PLM) | `src/centron/Centron.WPF.UI/Modules/PLM`, `.../Finances/ProductLifecycleManagement` | Verfolgt Lebenszyklusphasen von Produkten beim Kunden. |
+| M-008 | Audit / Umfragen (Survey) | `src/centron/Centron.WPF.UI/Modules/Survey` | Strukturierte Kundenbefragungen und Audits. |
+| M-009 | Belegwesen Verkauf | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts`, `src/backend/Centron.BL/Sales/Receipts` | Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Abholschein als gemeinsame Belegfamilie. |
+| M-010 | Belegkonditionen | `src/centron/Centron.WPF.UI/Modules/Administration/ReceiptConditions` | Pflegt Konditionsregeln, die auf Belege angewendet werden. |
+| M-011 | Vertragsverwaltung | `src/centron/Centron.WPF.UI/Modules/Finances/Contracts`, `src/backend/Centron.BL/Sales/Receipts/ContractLists` | Führt Verträge als Belegart mit Laufzeit, Intervall und Kontingent. |
+| M-012 | Vertragsabrechnung (Automated Billing) | `src/centron/Centron.WPF.UI/Modules/Finances/AutomatedBilling`, `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura` | Erzeugt turnusmäßig Rechnungen aus Verträgen. |
+| M-013 | Pauschalabrechnung (Flatrate Billing) | `src/centron/Centron.WPF.UI/Modules/Finances/FlatrateBilling` | Rechnet Pauschalprojekte unabhängig vom Einzelaufwand ab. |
+| M-014 | Vereinfachte Ticketabrechnung (Timer Billing) | `src/centron/Centron.WPF.UI/Modules/Finances/TimerBilling`, `src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling` | Erzeugt Belege direkt aus erfassten Ticketzeiten. |
+| M-015 | Klick-Zählerverwaltung | `src/centron/Centron.WPF.UI/Modules/Finances/DeviceClickCounter` | Erfasst Zählerstände von Geräten als Grundlage der Klickabrechnung. |
+| M-016 | Provisionsauswertung und -schemas | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/Provision`, `src/backend/Centron.BL/Sales/Receipts/ReceiptProvision*` | Berechnet Vertriebsprovisionen nach Schema und Kundenzuordnung. |
+| M-017 | Vertragsauswertung | `src/centron/Centron.WPF.UI/Modules/Finances/ContractEvaluation2` | Wertet Verträge betriebswirtschaftlich aus. |
+| M-018 | Mahnwesen | `src/centron/Centron.WPF.UI/Modules/Finances/Dunning`, `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning` | Führt Mahnläufe über offene Rechnungen in bis zu drei Mahnstufen. |
+| M-019 | OPOS (offene Posten) | `src/centron/Centron.WPF.UI/Modules/Finances/Opos` | Zeigt und bearbeitet offene Posten. |
+| M-020 | Zahlungseingang | `src/centron/Centron.WPF.UI/Modules/Finances/Payments`, `src/backend/Centron.BL/Finances/IncomingPayments` | Verbucht Zahlungseingänge gegen Rechnungen. |
+| M-021 | SEPA / Zahlungsverkehr | `src/centron/Centron.WPF.UI/Modules/DataExchange/PaymentTransactions`, `src/backend/Centron.BL/DataExchange/PaymentTransactions` | Erzeugt SEPA-Lastschrift-Dateien aus Rechnungen. |
+| M-022 | Buchhaltungsexport / -import | `src/centron/Centron.WPF.UI/Modules/DataExchange/BookKeeping` | Übergibt Belegdaten an die Finanzbuchhaltung und liest OPOS zurück. |
+| M-023 | DATEV-Belegtransfer | `src/centron/Centron.WPF.UI/Modules/DataExchange/DatevOnline2020` | Überträgt Belege und Belegbilder an DATEV Online. |
+| M-024 | Kalkulation pro Filiale | `src/centron/Centron.WPF.UI/Modules/DataExchange/SupplierOrderPerBranch` | Verteilt Lieferantenbestellungen kalkulatorisch auf Filialen. |
+| M-025 | Online-Banking (finAPI) | `src/centron/Centron.WPF.UI/Modules/OnlineBanking`, `src/backend/Centron.BL/Finances/OnlineBanking` | Ruft Kontoumsätze über eine Banking-Schnittstelle ab. |
+| M-026 | Kassenbuch / Belegerfassung | `src/centron/Centron.WPF.UI/Modules/Warehousing/OutcomingPayments`, `src/backend/Centron.BL/Sales/CashBooks` | Erfasst Barzahlungen und Ausgangsbelege. |
+| M-027 | Einkauf / Bestellwesen | `src/centron/Centron.WPF.UI/Modules/Purchasing`, `src/backend/Centron.BL/Purchasing` | Anfrage, Bestellung, Wareneingang, Lieferantengutschrift. |
+| M-028 | Bestellvorschlagsliste | `src/centron/Centron.WPF.UI/Modules/Purchasing/OrderSuggestionList` | Leitet Bestellvorschläge aus Bedarf und Bestand ab. |
+| M-029 | EDI-Verwaltung | `src/centron/Centron.WPF.UI/Modules/Purchasing/EDIManagement`, `src/backend/Centron.BL/EDI` | Steuert den elektronischen Belegaustausch mit Distributoren. |
+| M-030 | Wareneingang / WE-Kalkulation | `src/centron/Centron.WPF.UI/Modules/Finances/Receipts/SupplierReceiptDocuments` | Importiert und kalkuliert Lieferantenbelege. |
+
+### 1.2 Logistik, Artikel und Produktion
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M-031 | Artikelverwaltung | `src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleManagement`, `src/backend/Centron.BL/Warehousing/ArticleBL.cs` | Führt Artikelstamm mit Preisen, Einheiten und Warengruppen. |
+| M-032 | Artikelimport | `src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleImport`, `src/backend/Centron.BL/Warehousing/ArticleManagement/ArticleImportBL.cs` | Importiert Artikel- und Preisdaten von Distributoren. |
+| M-033 | Warengruppenverwaltung | `src/centron/Centron.WPF.UI/Modules/Warehousing/MaterialGroupManagement` | Klassifiziert Artikel in Warengruppen. |
+| M-034 | Artikeleinheiten | `src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleUnitManagement`, `.../Warehousing/ArticleUnitBL.cs` | Pflegt Mengeneinheiten und Umrechnungen. |
+| M-035 | Barcode- und Seriennummernverwaltung | `src/centron/Centron.WPF.UI/Modules/Warehousing/BarcodeManagement`, `src/backend/Centron.BL/Warehousing/BarcodeBL.cs` | Verwaltet Seriennummern/Barcodes und ihre Zustände. |
+| M-036 | Lagerbestandsführung | `src/backend/Centron.BL/Warehousing/StockManagement`, `src/backend/Centron.BL/Logistics/Warehousing/StockBL.cs` | Führt Bestände je Lager, Lagerort und Nebenlager. |
+| M-037 | Inventur | `src/centron/Centron.WPF.UI/Modules/Warehousing/Inventory`, `src/backend/Centron.BL/Warehousing/InventoryManagement` | Zählvorgänge, Lagerabschluss, Inventurdifferenzen. |
+| M-038 | Kommissionierung | `src/centron/Centron.WPF.UI/Modules/Warehousing/Commissioning`, `src/backend/Centron.BL/Warehousing/CommissioningManagement` | Steuert Kommissionierung von Aufträgen. |
+| M-039 | Logistik / Versand | `src/centron/Centron.WPF.UI/Modules/Logistic` | Versandarten, Versanddienstleister, Warenversandbestätigung. |
+| M-040 | Produktion | `src/centron/Centron.WPF.UI/Modules/Production`, `src/backend/Centron.BL/Production` | Maschinenverwaltung und Produktionsaufträge. |
+| M-041 | Kostenträger / Kostenstellen | `src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter`, `src/backend/Centron.BL/Warehousing/CostCenterBL.cs` | Führt Kostenstellen und Kostenträger als Stammdaten. |
+| M-042 | Kontenrahmen | `src/centron/Centron.WPF.UI/Modules/Warehousing/AccountSystems`, `src/backend/Centron.BL/Administration/BookKeepingAccountSystems` | Bildet Buchhaltungskontenrahmen ab. |
+| M-043 | Mehrwertsteuer | `src/backend/Centron.BL/Warehousing/TaxBL.cs`, Tabelle `dbo.MwstSatz` | Pflegt Steuersätze je Land inkl. Erlös-/Aufwandskonten. |
+| M-044 | Aufschläge Stundensätze | `src/centron/Centron.WPF.UI/Modules/Administration/HourlySurchargeRates`, `src/backend/Centron.BL/Sales/HourlySurchargeRatesBL` | Zeitabhängige Zuschläge auf Stundensätze. |
+| M-045 | Projektpreis-Import | `src/centron/Centron.WPF.UI/Modules/ProjectPriceImport` | Importiert projektbezogene Sonderpreise. |
+| M-046 | Sonderpreis-Importe für Verträge | `src/centron/Centron.WPF.UI/Modules/Sales/SpecialArticleImport`, `.../SpecialArticleToContractImport` | Statischer und dynamischer Import von Sonderpreisen in Verträge. |
+| M-047 | Produkt-/Kundenmatrix | `src/centron/Centron.WPF.UI/Modules/Sales/ProductMatrix`, `src/backend/Centron.BL/ProductMatrix` | Ordnet Produkte Kundensegmenten zu. |
+| M-048 | TradePool | `src/backend/Centron.BL/TradePool` | Importiert und durchsucht einen überbetrieblichen Artikelpool. |
+| M-049 | Gutschein-/Voucher-Verwaltung | `src/backend/Centron.BL/VoucherManagement` | Verwaltet ausgegebene und eingelöste Gutscheine. |
+
+### 1.3 Service, Helpdesk und Projekte
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M-050 | Helpdesk / Ticketing | `src/centron/Centron.WPF.UI/Modules/Helpdesk`, `src/backend/Centron.BL/Sales/Support` | Zentrale Ticketbearbeitung mit Status, Priorität, Kategorie, Typ. |
+| M-051 | Ticket-Zeiterfassung | `src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs` | Erfasst berechenbare und nicht berechenbare Zeiten am Ticket. |
+| M-052 | Checklisten | `src/centron/Centron.WPF.UI/Modules/Helpdesk/CentronChecklist`, `src/backend/Centron.BL/CheckListArea` | Vorlagenbasierte Checklisten an Tickets. |
+| M-053 | Ticketprozess-Vorlagen (C-FLOW) | `src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketProcessTemplates`, `src/backend/Centron.BL/Processes` | Prozessvorlagen mit Schritten und Bindungen. |
+| M-054 | Erwartete Events | `src/centron/Centron.WPF.UI/Modules/Helpdesk/ExpectedEvents`, `src/backend/Centron.BL/ExpectedEvents` | Überwacht erwartete Ereignisse und protokolliert Abweichungen. |
+| M-055 | Taskmanagement | `src/centron/Centron.WPF.UI/Modules/Helpdesk/TaskManagement`, `src/backend/Centron.BL/TaskManager` | Aufgabenverwaltung quer zu Tickets. |
+| M-056 | Ticketprojekte / Projektverwaltung | `src/centron/Centron.WPF.UI/Modules/ProjectManagement`, `src/backend/Centron.BL/TicketProjects` | Bündelt Tickets zu Projekten. |
+| M-057 | RMA / Werkstatt | `src/centron/Centron.WPF.UI/Modules/Rma`, `src/backend/Centron.BL/CustomerArea/RmaBL.cs` | Rücksende- und Reparaturabwicklung. |
+| M-058 | QM-Meldungen | `src/centron/Centron.WPF.UI/Modules/QM`, `src/backend/Centron.Interfaces/QM` | Erfasst Qualitätsmeldungen. |
+| M-059 | Eskalationen | `src/backend/Centron.BL/Sales/Support/Escalation` | Eskalationstypen und -regeln für Tickets. |
+| M-060 | SelfCare-Formulare | `src/backend/Centron.BL/SelfCare`, `src/webservice/Centron.Controllers/Controllers/v1/SelfCare` | Kundenformulare, die Tickets und Folgeaktionen auslösen. |
+| M-061 | Externer Helpdesk | `src/backend/Centron.BL/ExternalHelpdesk` | Anbindung fremder Helpdesk-Systeme. |
+| M-062 | Geräte / Assets am Konto | `src/backend/Centron.BL/Devices`, `src/backend/Centron.Entities/Entities/Devices` | Führt kundenseitige Geräte als eigenständige Objekte. |
+| M-063 | Asset-/DocuBoard-Verwaltung | `src/backend/Centron.BL/DocuBoard`, Tabellen `AssetManagement*` | Inventarisiert IT-Systeme, Anwendungen, Checks und Abhängigkeiten. |
+| M-064 | IT-Planner | `src/backend/Centron.BL/ItPlanner` | Kategorien virtueller Objekte für IT-Planung. |
+
+### 1.4 Arbeitsplatz, Zusammenarbeit und Kommunikation
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M-065 | Kalender und Termine | `src/centron/Centron.WPF.UI/Modules/Calendar`, `src/backend/Centron.BL/Sales/Calendar` | Termine, Vertretungen, Darstellungen. |
+| M-066 | Kalender-/Exchange-Synchronisation | `src/backend/Centron.BL/Sales/Calendar/ScheduleBL.cs`, `docs/features/exchange-sync-bugprotokoll.md` | Gleicht Termine mit Exchange/Outlook ab. |
+| M-067 | Mein Tag (MyDay) | `src/centron/Centron.WPF.UI/Modules/MyCentron/MyDay`, `src/backend/Centron.BL/MyDay` | Tagesplanung und Arbeitszeitübersicht je Mitarbeiter. |
+| M-068 | Mitarbeiterauslastung | `src/centron/Centron.WPF.UI/Modules/MyCentron/MyDay/EmployeeOverview` | Auslastungssicht über Mitarbeiter und Filialen. |
+| M-069 | Todo-Liste | `src/centron/Centron.WPF.UI/Modules/MyCentron/TodoList`, `src/backend/Centron.BL/ToDoArea` | Persönliche und objektbezogene Aufgaben. |
+| M-070 | Telefonie / TAPI | `src/centron/Centron.WPF.UI/Modules/MyCentron/Telephony`, `src/backend/Centron.BL/Tapi` | Anrufprotokoll, Rufnummernauflösung, TAPI-Anbindung. |
+| M-071 | Chat | `src/backend/Centron.BL/Chats`, `src/webservice/Centron.Host/RealTimeServices/ChatHub.cs` | Interner Chat mit Objektbezug. |
+| M-072 | Benachrichtigungen | `src/backend/Centron.BL/Notifications`, `src/backend/Centron.BL/NexusNotifications` | System- und Nutzerbenachrichtigungen inkl. Push in das Web-Portal. |
+| M-073 | Mailversand und Mailvorlagen | `src/backend/Centron.BL/Mail`, `src/centron/Centron.WPF.UI/Modules/Administration/MailTemplates` | Versendet Mails aus Belegen, Tickets und Kampagnen. |
+| M-074 | Mail-Scanner | `src/backend/Centron.BL/MailScanner` | Liest Postfächer aus und ordnet Mails Objekten zu. |
+| M-075 | Outlook-Integration | `src/backend/Centron.BL/Outlook`, `src/nexus/CentronNexus.OutlookAddIn` | Outlook-Add-In für Belege, Tickets, Kontakte. |
+| M-076 | Textbausteine | `src/centron/Centron.WPF.UI/Modules/Administration/TextBlockManagement`, `src/backend/Centron.BL/TextModuleArea` | Wiederverwendbare Textbausteine und Anrede-/Grußformeln. |
+| M-077 | Dashboard | `src/centron/Centron.WPF.UI/Modules/Dashboard`, `.../MyCentron/Dashboard` | Konfigurierbare Kennzahlenübersicht. |
+| M-078 | KI-Assistent / AI-Chat | `src/centron/Centron.WPF.UI/Modules/ArtificialIntelligence`, `src/backend/Centron.BL/ArtificialIntelligence` | KI-gestützte Textbewertung, Angebotspositionen, Chat. |
+| M-079 | Social Media | `src/backend/Centron.BL/SocialMedia` | Verknüpft Social-Media-Konten und -Aktivitäten mit Personen. |
+| M-080 | Video-Portal | `src/backend/Centron.BL/VideoPortal`, `src/centron/Centron.WPF.UI/Modules/Global/VideoPortal` | Stellt Schulungsvideos im Client bereit. |
+| M-081 | Tags | `src/backend/Centron.BL/Tags` | Freie Verschlagwortung von Objekten. |
+| M-082 | Kurz-URLs und WebLinks | `src/backend/Centron.BL/Urls`, `src/backend/Centron.BL/WebLinks` | Erzeugt aufrufbare Links mit hinterlegter Aktion. |
+
+### 1.5 Auswertung, Reporting und Controlling
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M-083 | Statistik / Analytics | `src/centron/Centron.WPF.UI/Modules/Statistics`, `src/backend/Centron.BL/Statistics` | Umsatz-, Vertriebs- und Servicestatistiken. |
+| M-084 | Leistungsnachweise | `src/centron/Centron.WPF.UI/Modules/Statistics/EmployeeAnalytics` | Leistungsnachweise je Mitarbeiter. |
+| M-085 | Management Info | `src/centron/Centron.WPF.UI/Modules/Statistics/ManagementInfo` | Verdichtete Kennzahlen für die Geschäftsführung. |
+| M-086 | MSP-Auswertung, -Collector, -Dashboard | `src/centron/Centron.WPF.UI/Modules/Statistics/Msp*`, `src/backend/Centron.Gateway/MspCollector` | Sammelt und vergleicht Managed-Service-Lizenzen und -Nutzung. |
+| M-087 | Report-Engine und Reportverwaltung | `src/centron/Centron.WPF.UI/Modules/Reports`, `src/backend/Centron.BL/ReportEngine` | Definition, Vorschau, Druck und Export von Reports. |
+| M-088 | Reportserver | `src/centron/Centron.WPF.UI/Modules/Administration/ReportServer` | Zeitgesteuerter Reportversand. |
+| M-089 | Index-/Volltextsuche | `src/backend/Centron.BL/IndexSearch` | Baut und durchsucht Volltextindizes über Objekte und Dokumente. |
+| M-090 | Telemetrie | `src/backend/Centron.BL/Telemetry` | Zählt API- und KI-Werkzeugnutzung in Zeitfenstern. |
+
+### 1.6 Administration, Sicherheit und Betrieb
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M-091 | Rechteverwaltung | `src/centron/Centron.WPF.UI/Modules/Administration/RightsManagement`, `src/backend/Centron.BL/Administration/Rights` | Rechte, Gruppen, Zuordnungen, Rechteprotokoll. |
+| M-092 | Authentifizierung und Anmeldung | `src/backend/Centron.BL/Administration/Logins`, `.../Logins/Auth` | Anmeldung per Kennwort, Active Directory, OpenID Connect, Web-Konto. |
+| M-093 | Zwei-Faktor-Authentifizierung | `src/backend/Centron.BL/Administration/Logins/TwoFactor`, `src/backend/Centron.BL/TwoFactorAuthenticator` | TOTP-, Mail- und RADIUS-basierter zweiter Faktor. |
+| M-094 | Zugriffstoken (API-Token) | `src/backend/Centron.BL/Administration/AccessTokens` | Persönliche API-Token mit Ablauf, Sperre und Protokoll. |
+| M-095 | Lizenzverwaltung | `src/backend/Centron.BL/Administration/Licensing`, `src/backend/Centron.Interfaces/Administration/Logins/LicenseGuids.cs` | Prüft Featurelizenzen, Anzahl, Ablaufdatum und Version. |
+| M-096 | Mitarbeiterverwaltung / Personal | `src/centron/Centron.WPF.UI/Modules/Administration/EmployeeManagement`, `src/backend/Centron.BL/EmployeeArea` | Mitarbeiterstammdaten, Abteilungen, Skills, Einstellungen. |
+| M-097 | Mandanten und Filialen | `src/centron/Centron.WPF.UI/Modules/Administration/MandatorManagement`, `src/backend/Centron.BL/Administration/Company` | Mandanten, Filialen, Nummernkreise, Bankverbindungen. |
+| M-098 | Anwendungseinstellungen | `src/centron/Centron.WPF.UI/Modules/Administration/Settings`, `src/backend/Centron.BL/Administration/Settings` | Zentrale Einstellungen in `ApplicationSettings` und `Stammdat`. |
+| M-099 | Zusatzfelder (Custom Properties) | `src/centron/Centron.WPF.UI/Modules/Global/CustomProperties`, `src/backend/Centron.BL/Administration/Customization` | Kundenindividuelle Zusatzfelder je Modul. |
+| M-100 | Passwort-Manager / Zugangsverwaltung | `src/centron/Centron.WPF.UI/Modules/PasswordManager`, `src/backend/Centron.BL/PasswordManager`, `.../PasswordManagementArea` | Verwaltet Kundenzugangsdaten verschlüsselt inkl. Zugriffsprotokoll. |
+| M-101 | DSGVO / Datenschutz | `src/centron/Centron.WPF.UI/Modules/Administration/DSGVO`, `src/backend/Centron.BL/Administration/DataSecurity` | Auskunft, Löschung und Datenbankbereinigung nach DSGVO. |
+| M-102 | PDF-Signierung | `src/backend/Centron.BL/Security/PdfSigningBL.cs` | Signiert erzeugte PDF-Dokumente mit einem Zertifikat. |
+| M-103 | Dokumenten- und Dateiverwaltung | `src/backend/Centron.BL/Administration/FileManagement` | Verzeichnisse, Dokumente, geteilte Dokumente, EDI-Dokumente. |
+| M-104 | Datenbank-Skript-Engine | `src/backend/Centron.BL/Administration/Scripts` | Führt versionierte Migrationsskripte gegen die Datenbank aus. |
+| M-105 | SQL-Manager | `src/centron/Centron.WPF.UI/Modules/Administration/SqlManagers`, `src/backend/Centron.BL/Administration/SQLManagement` | Administrative Datenbankoperationen aus dem Client. |
+| M-106 | Protokollierung und LogViewer | `src/centron/Centron.WPF.UI/Modules/Administration/LogViewer`, `src/centron/Centron.WPF.UI/nlog.config` | Anwendungslogs erzeugen und einsehen. |
+| M-107 | c-entron Inspektor | `src/centron/Centron.WPF.UI/Modules/MyCentron/CentronInspectors` | Diagnosewerkzeug für Support und Entwicklung. |
+| M-108 | Massenupdates (Data Updater) | `src/centron/Centron.WPF.UI/Modules/Massenupdates`, `src/backend/Centron.BL/MassUpdate` | Massenhafte Preis- und Datenänderungen über Vorlagen. |
+| M-109 | Änderungsverfolgung | `src/backend/Centron.BL/ChangeTracking`, `src/backend/Centron.DAO/ChangeTracking` | Protokolliert Entitätsänderungen über NHibernate-Listener. |
+| M-110 | Länder und Bundesländer | `src/centron/Centron.WPF.UI/Modules/Administration/CountryManagement`, `src/backend/Centron.BL/CountryArea` | Länderstammdaten inkl. steuerlicher Zuordnung. |
+| M-111 | Externe Tools | `src/centron/Centron.WPF.UI/Modules/ExternalTool`, `src/backend/Centron.BL/ExternalToolsBL` | Startet externe Programme mit Kontextvariablen. |
+| M-112 | Objekt-Externreferenzen | `src/backend/Centron.BL/ObjectExternalReferences` | Verknüpft c-entron-Objekte mit IDs in Fremdsystemen. |
+
+### 1.7 Dienste, Portale und Schnittstellen
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M-113 | Legacy-REST-Webservice | `src/webservice/Centron.WebServices.Core`, `src/webservice/Centron.Host/Services` | Historisch gewachsener REST-Dienst mit `ICentronRestService`. |
+| M-114 | Moderne REST-API v1 | `src/webservice/Centron.Controllers` | Versionierte ASP.NET-Core-Controller mit Attribut-Autorisierung. |
+| M-115 | Web-Service-Hosting | `src/webservice/Centron.Host`, `.../Centron.Host.Console`, `.../Centron.Host.WindowsService`, `docker/` | Betrieb als Konsolenprozess, Windows-Dienst oder Container. |
+| M-116 | Verbindungsmanager | `src/webservice/c-entron.misc.ConnectionManager` | Konfiguriert Datenbank- und Dienstverbindungen. |
+| M-117 | Echtzeitdienste (SignalR) | `src/webservice/Centron.Host/RealTimeServices` | Hubs für Chat, Benachrichtigungen, Verfügbarkeit, TAPI. |
+| M-118 | Nexus ServiceBoard | `src/nexus/CentronNexus/ServiceBoard` | Web-Oberfläche für Servicemitarbeiter (Tickets, Kanban, Zeiten). |
+| M-119 | Nexus WebCart / Kundenportal | `src/nexus/CentronNexus/WebCart` | Shop und Portal für Endkunden mit Web-Konto. |
+| M-120 | Nexus WebOffer | `src/nexus/CentronNexus/WebOffer` | Web-Freigabe von Angeboten. |
+| M-121 | Nexus Dokumentensignatur | `src/nexus/CentronNexus/DocumentSigning` | Online-Freigabe und Signatur von Dokumenten. |
+| M-122 | Nexus Verwaltung und Einstellungen | `src/nexus/CentronNexus/Management`, `src/nexus/CentronNexus/Settings` | Web-Konten, Ticketvorlagen, Branding, Themes. |
+| M-123 | Web-Konten (WebAccount) | `src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs` | Kundenzugänge mit eigenem Rechtemodell. |
+| M-124 | Externe Warenwirtschafts- und Bank-APIs | `src/apis/` (finAPI, GLS, Shipcloud, ITscope, Icecat, COP, EGIS, ebInterface), `Centron.Api.docuFORM` | Gekapselte Zugriffe auf Fremdsysteme. |
+| M-125 | Gateway / EDI-Konnektoren und E-Rechnung | `src/backend/Centron.Gateway`, `src/backend/Centron.BL/DataExchange/EDI` | Distributor-EDI, OpenTrans, ZUGFeRD/XRechnung, MSP-Collector, Online-Banking. |
+| M-126 | RMM-Anbindung (Riverbird) | `src/backend/Centron.BL/RiverDivo`, `src/centron/Centron.WPF.UI/Modules/DataExchange/Rmm` | Liefert Nutzungsdaten für die verbrauchsabhängige Vertragsabrechnung. |
+
+### 1.8 Querschnittliche Bausteine
+
+| ID | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|---|---|---|---|
+| M-127 | Persistenz / ORM | `src/backend/Centron.DAO` | NHibernate-Session, Mappings, Repositories, benannte Abfragen. |
+| M-128 | Domänenmodell | `src/backend/Centron.Entities` | Entitäten und Web-Service-DTOs. |
+| M-129 | Basisbibliotheken | `src/backend/Centron.Common`, `src/shared/Centron.Core` | Kryptografie, Formatierung, Logging, Hilfsklassen. |
+| M-130 | UI-Bausteine | `src/shared/Centron.Controls`, `src/centron/Centron.WPF.UI.Extension` | Wiederverwendbare Steuerelemente und MVVM-Infrastruktur. |
+| M-131 | Lokalisierung | `**/Resources/LocalizedStrings*.resx`, `docs/guides/ui/localization.md` | Deutsch als Standardsprache, Englisch als Zusatzsprache. |
+| M-132 | Build, Auslieferung und Betrieb | `deployment/`, `azure/`, `.github/workflows/`, `docker/` | Installer, Pipelines, Container-Betrieb. |
+| M-133 | Testsuite | `tests/` | Unit-, Integrations-, End-to-End- und Playwright-Tests. |
+| M-134 | Mobile-Schnittstelle | `src/backend/Centron.BL/Mobile`, `src/backend/Centron.DAO/Mobile` | Verschlankte Datensicht für mobile Anwendungen. |
+| M-135 | Telekom D!VE | `src/backend/Centron.BL/DataExchange/TelekomDive`, `src/centron/Centron.WPF.UI/Modules/TelekomDive` | Anbindung an den Anbieterdienst Telekom D!VE über benannte Profile. |
+
+> **Hinweis zur Inventarpflege:** Das Inventar wurde während der Analyse **ergänzt, aber nicht gekürzt**. Nach Durchsicht der Projektmappe kamen M-127 bis M-133 hinzu; während der Formalisierung kamen M-134 (Mobile-Schnittstelle, aufgefallen über `MobileBL` und `Centron.DAO/Mobile`) und M-135 (Telekom D!VE, aufgefallen über `TelekomDiveBL` und den gleichnamigen Modulordner) hinzu. Die Nummerierung ist stabil und wird in der Abdeckungstabelle unverändert übernommen.
+
+---
+
+## 2. Abdeckungstabelle
+
+Jede Zeile des Modulinventars aus Abschnitt 1 erscheint hier genau einmal. Die Einstufung folgt der Anzahl der aus dem Modul erzeugten Anforderungen:
+
+| Einstufung | Kriterium |
+|---|---|
+| `tief` | acht oder mehr Anforderungen; Regeln bis auf die durchsetzende Codestelle nachvollzogen |
+| `mittel` | drei bis sieben Anforderungen; Struktur, Datenmodell und mindestens eine durchgesetzte Regel belegt |
+| `flach` | eine oder zwei Anforderungen; Existenz, Zweck und ein tragendes Merkmal belegt |
+| `nicht analysiert` | keine Anforderung erzeugt |
+
+**Ergebnis in Zahlen:** 5 Module `tief`, 79 Module `mittel`, 51 Module `flach`, **0 Module `nicht analysiert`**. Alle 135 Module tragen mindestens eine Anforderung; die Mindestabdeckung nach Schritt 0b ist damit erreicht.
+
+| Modul | Bezeichnung | Abdeckung | Anzahl | Anforderungen |
+|---|---|---|---|---|
+| M-001 | Adressstamm (Konten, Kunden, Lieferanten) | mittel | 4 | StRS-011, SyRS-015, SwRS-015, SwRS-016 |
+| M-002 | CRM / Kontakthistorie | mittel | 3 | StRS-012, SyRS-016, SwRS-017 |
+| M-003 | CRM-Projekte | mittel | 3 | StRS-013, SyRS-017, SwRS-018 |
+| M-004 | Kampagnen / Mailing | mittel | 3 | StRS-014, SyRS-018, SwRS-019 |
+| M-005 | Lieferanten-Verträge | mittel | 3 | StRS-015, SyRS-019, SwRS-020 |
+| M-006 | Stammblätter | mittel | 3 | StRS-016, SyRS-020, SwRS-021 |
+| M-007 | Produktlebenszyklus (PLM) | mittel | 3 | StRS-018, SyRS-022, SwRS-023 |
+| M-008 | Audit / Umfragen | mittel | 3 | StRS-019, SyRS-023, SwRS-024 |
+| M-009 | Belegwesen Verkauf | tief | 30 | StRS-001, StRS-021, StRS-022, StRS-023, StRS-024, StRS-026, StRS-027, StRS-028, StRS-029, StRS-030, SyRS-001, SyRS-002, SyRS-025, SyRS-026, SyRS-027, SyRS-028, SyRS-030, SyRS-032, SyRS-033, SyRS-034, SwRS-001, SwRS-002, SwRS-026, SwRS-027, SwRS-028, SwRS-029, SwRS-031, SwRS-033, SwRS-034, SwRS-035 |
+| M-010 | Belegkonditionen | flach | 1 | SwRS-150 |
+| M-011 | Vertragsverwaltung | mittel | 3 | StRS-031, SyRS-036, SwRS-036 |
+| M-012 | Vertragsabrechnung (Automated Billing) | mittel | 7 | StRS-032, StRS-033, SyRS-037, SyRS-038, SwRS-037, SwRS-038, SwRS-039 |
+| M-013 | Pauschalabrechnung (Flatrate Billing) | mittel | 3 | StRS-036, SyRS-041, SwRS-042 |
+| M-014 | Vereinfachte Ticketabrechnung (Timer Billing) | mittel | 3 | StRS-037, SyRS-042, SwRS-043 |
+| M-015 | Klick-Zählerverwaltung | mittel | 3 | StRS-035, SyRS-040, SwRS-041 |
+| M-016 | Provisionsauswertung und -schemas | mittel | 4 | StRS-038, StRS-039, SyRS-043, SwRS-044 |
+| M-017 | Vertragsauswertung | mittel | 3 | StRS-040, SyRS-044, SwRS-045 |
+| M-018 | Mahnwesen | tief | 9 | StRS-041, StRS-042, StRS-025, SyRS-045, SyRS-046, SyRS-029, SwRS-046, SwRS-047, SwRS-030 |
+| M-019 | OPOS (offene Posten) | flach | 1 | SyRS-046 |
+| M-020 | Zahlungseingang | mittel | 3 | StRS-044, SyRS-048, SwRS-049 |
+| M-021 | SEPA / Zahlungsverkehr | mittel | 4 | StRS-045, StRS-046, SyRS-049, SwRS-050 |
+| M-022 | Buchhaltungsexport / -import | mittel | 3 | StRS-047, SyRS-050, SwRS-051 |
+| M-023 | DATEV-Belegtransfer | flach | 1 | StRS-048 |
+| M-024 | Kalkulation pro Filiale | flach | 1 | SwRS-056 |
+| M-025 | Online-Banking (finAPI) | mittel | 3 | StRS-050, SyRS-052, SwRS-053 |
+| M-026 | Kassenbuch / Belegerfassung | mittel | 3 | StRS-051, SyRS-053, SwRS-054 |
+| M-027 | Einkauf / Bestellwesen | mittel | 3 | StRS-052, SyRS-054, SwRS-055 |
+| M-028 | Bestellvorschlagsliste | mittel | 3 | StRS-053, SyRS-055, SwRS-056 |
+| M-029 | EDI-Verwaltung | mittel | 4 | StRS-054, SyRS-056, SyRS-057, SwRS-057 |
+| M-030 | Wareneingang / WE-Kalkulation | mittel | 3 | StRS-055, SyRS-058, SwRS-058 |
+| M-031 | Artikelverwaltung | mittel | 5 | StRS-056, SyRS-059, SyRS-031, SwRS-059, SwRS-032 |
+| M-032 | Artikelimport | mittel | 3 | StRS-057, SyRS-060, SwRS-060 |
+| M-033 | Warengruppenverwaltung | flach | 1 | SyRS-059 |
+| M-034 | Artikeleinheiten | flach | 1 | SyRS-059 |
+| M-035 | Barcode- und Seriennummernverwaltung | mittel | 3 | StRS-058, SyRS-061, SwRS-061 |
+| M-036 | Lagerbestandsführung | mittel | 3 | StRS-059, SyRS-062, SwRS-062 |
+| M-037 | Inventur | flach | 2 | SyRS-116, SwRS-116 |
+| M-038 | Kommissionierung | flach | 2 | SyRS-117, SwRS-117 |
+| M-039 | Logistik / Versand | mittel | 3 | StRS-060, SyRS-063, SwRS-063 |
+| M-040 | Produktion | flach | 2 | SyRS-115, SwRS-115 |
+| M-041 | Kostenträger / Kostenstellen | flach | 2 | SyRS-127, SwRS-127 |
+| M-042 | Kontenrahmen | flach | 1 | SwRS-147 |
+| M-043 | Mehrwertsteuer | mittel | 3 | StRS-043, SyRS-047, SwRS-048 |
+| M-044 | Aufschläge Stundensätze | flach | 2 | SyRS-128, SwRS-128 |
+| M-045 | Projektpreis-Import | flach | 1 | SwRS-148 |
+| M-046 | Sonderpreis-Importe für Verträge | flach | 1 | SwRS-148 |
+| M-047 | Produkt-/Kundenmatrix | mittel | 3 | StRS-020, SyRS-024, SwRS-025 |
+| M-048 | TradePool | flach | 2 | SyRS-119, SwRS-119 |
+| M-049 | Gutschein-/Voucher-Verwaltung | flach | 2 | SyRS-118, SwRS-118 |
+| M-050 | Helpdesk / Ticketing | mittel | 3 | StRS-061, SyRS-064, SwRS-064 |
+| M-051 | Ticket-Zeiterfassung | mittel | 6 | StRS-062, StRS-063, SyRS-065, SyRS-066, SwRS-065, SwRS-066 |
+| M-052 | Checklisten | mittel | 3 | StRS-064, SyRS-067, SwRS-067 |
+| M-053 | Ticketprozess-Vorlagen (C-FLOW) | mittel | 3 | StRS-065, SyRS-068, SwRS-068 |
+| M-054 | Erwartete Events | mittel | 3 | StRS-066, SyRS-069, SwRS-069 |
+| M-055 | Taskmanagement | mittel | 3 | StRS-067, SyRS-070, SwRS-070 |
+| M-056 | Ticketprojekte / Projektverwaltung | mittel | 3 | StRS-068, SyRS-071, SwRS-071 |
+| M-057 | RMA / Werkstatt | mittel | 3 | StRS-069, SyRS-072, SwRS-072 |
+| M-058 | QM-Meldungen | mittel | 3 | StRS-070, SyRS-073, SwRS-073 |
+| M-059 | Eskalationen | mittel | 3 | StRS-071, SyRS-074, SwRS-074 |
+| M-060 | SelfCare-Formulare | mittel | 3 | StRS-072, SyRS-075, SwRS-075 |
+| M-061 | Externer Helpdesk | flach | 1 | SwRS-135 |
+| M-062 | Geräte / Assets am Konto | mittel | 3 | StRS-017, SyRS-021, SwRS-022 |
+| M-063 | Asset-/DocuBoard-Verwaltung | flach | 2 | SyRS-021, SwRS-022 |
+| M-064 | IT-Planner | flach | 1 | SwRS-134 |
+| M-065 | Kalender und Termine | flach | 2 | SyRS-099, SwRS-100 |
+| M-066 | Kalender-/Exchange-Synchronisation | mittel | 3 | StRS-097, SyRS-099, SwRS-100 |
+| M-067 | Mein Tag (MyDay) | mittel | 3 | StRS-098, SyRS-100, SwRS-101 |
+| M-068 | Mitarbeiterauslastung | flach | 1 | StRS-098 |
+| M-069 | Todo-Liste | flach | 2 | SyRS-070, SwRS-070 |
+| M-070 | Telefonie / TAPI | mittel | 3 | StRS-096, SyRS-098, SwRS-099 |
+| M-071 | Chat | mittel | 3 | StRS-099, SyRS-101, SwRS-102 |
+| M-072 | Benachrichtigungen | mittel | 3 | StRS-099, SyRS-101, SwRS-102 |
+| M-073 | Mailversand und Mailvorlagen | mittel | 4 | SyRS-121, SwRS-121, SyRS-108, SwRS-110 |
+| M-074 | Mail-Scanner | flach | 2 | SyRS-122, SwRS-122 |
+| M-075 | Outlook-Integration | mittel | 3 | StRS-095, SyRS-097, SwRS-098 |
+| M-076 | Textbausteine | flach | 2 | SyRS-125, SwRS-125 |
+| M-077 | Dashboard | flach | 2 | SyRS-130, SwRS-130 |
+| M-078 | KI-Assistent / AI-Chat | flach | 2 | SyRS-114, SwRS-114 |
+| M-079 | Social Media | flach | 1 | SwRS-133 |
+| M-080 | Video-Portal | flach | 1 | SwRS-132 |
+| M-081 | Tags | flach | 1 | SwRS-131 |
+| M-082 | Kurz-URLs und WebLinks | flach | 2 | SyRS-113, SwRS-113 |
+| M-083 | Statistik / Analytics | mittel | 3 | StRS-073, SyRS-076, SwRS-076 |
+| M-084 | Leistungsnachweise | mittel | 3 | StRS-074, SyRS-077, SwRS-077 |
+| M-085 | Management Info | flach | 1 | StRS-075 |
+| M-086 | MSP-Auswertung, -Collector, -Dashboard | mittel | 3 | StRS-076, SyRS-078, SwRS-078 |
+| M-087 | Report-Engine und Reportverwaltung | mittel | 3 | StRS-077, SyRS-079, SwRS-079 |
+| M-088 | Reportserver | flach | 1 | StRS-077 |
+| M-089 | Index-/Volltextsuche | mittel | 3 | StRS-089, SyRS-091, SwRS-092 |
+| M-090 | Telemetrie | flach | 2 | SyRS-107, SwRS-109 |
+| M-091 | Rechteverwaltung | tief | 10 | StRS-005, StRS-006, SyRS-007, SyRS-008, SyRS-009, SyRS-010, SwRS-006, SwRS-007, SwRS-008, SwRS-009 |
+| M-092 | Authentifizierung und Anmeldung | tief | 12 | StRS-078, StRS-080, StRS-081, SyRS-080, SyRS-081, SyRS-082, SyRS-083, SwRS-080, SwRS-082, SwRS-083, SwRS-084, SwRS-141 |
+| M-093 | Zwei-Faktor-Authentifizierung | mittel | 3 | StRS-079, SyRS-081, SwRS-081 |
+| M-094 | Zugriffstoken (API-Token) | mittel | 3 | StRS-082, SyRS-084, SwRS-085 |
+| M-095 | Lizenzverwaltung | mittel | 5 | StRS-004, SyRS-005, SyRS-006, SwRS-005, SwRS-124 |
+| M-096 | Mitarbeiterverwaltung / Personal | mittel | 3 | StRS-085, SyRS-087, SwRS-088 |
+| M-097 | Mandanten und Filialen | mittel | 3 | StRS-002, SyRS-003, SwRS-003 |
+| M-098 | Anwendungseinstellungen | mittel | 3 | StRS-086, SyRS-088, SwRS-089 |
+| M-099 | Zusatzfelder (Custom Properties) | mittel | 3 | StRS-009, SyRS-013, SwRS-013 |
+| M-100 | Passwort-Manager / Zugangsverwaltung | mittel | 3 | StRS-083, SyRS-085, SwRS-086 |
+| M-101 | DSGVO / Datenschutz | mittel | 3 | StRS-084, SyRS-086, SwRS-087 |
+| M-102 | PDF-Signierung | flach | 2 | SyRS-035, SwRS-035 |
+| M-103 | Dokumenten- und Dateiverwaltung | mittel | 3 | StRS-088, SyRS-090, SwRS-091 |
+| M-104 | Datenbank-Skript-Engine | mittel | 3 | StRS-010, SyRS-014, SwRS-014 |
+| M-105 | SQL-Manager | flach | 1 | SwRS-139 |
+| M-106 | Protokollierung und LogViewer | flach | 2 | SyRS-106, SwRS-108 |
+| M-107 | c-entron Inspektor | flach | 1 | SwRS-140 |
+| M-108 | Massenupdates (Data Updater) | mittel | 3 | StRS-087, SyRS-089, SwRS-090 |
+| M-109 | Änderungsverfolgung | mittel | 3 | StRS-007, SyRS-011, SwRS-010 |
+| M-110 | Länder und Bundesländer | flach | 2 | SyRS-126, SwRS-126 |
+| M-111 | Externe Tools | mittel | 3 | StRS-090, SyRS-092, SwRS-093 |
+| M-112 | Objekt-Externreferenzen | flach | 2 | SyRS-112, SwRS-112 |
+| M-113 | Legacy-REST-Webservice | flach | 2 | SyRS-104, SwRS-105 |
+| M-114 | Moderne REST-API v1 | mittel | 3 | SyRS-076, SyRS-104, SwRS-106 |
+| M-115 | Web-Service-Hosting | tief | 10 | StRS-100, StRS-008, SyRS-102, SyRS-103, SyRS-105, SyRS-109, SyRS-110, SwRS-103, SwRS-104, SwRS-107 |
+| M-116 | Verbindungsmanager | flach | 2 | SyRS-129, SwRS-129 |
+| M-117 | Echtzeitdienste (SignalR) | flach | 2 | SyRS-098, SwRS-102 |
+| M-118 | Nexus ServiceBoard | mittel | 3 | StRS-091, SyRS-093, SwRS-094 |
+| M-119 | Nexus WebCart / Kundenportal | mittel | 6 | StRS-092, StRS-093, SyRS-094, SyRS-095, SwRS-095, SwRS-096 |
+| M-120 | Nexus WebOffer | mittel | 3 | StRS-094, SyRS-096, SwRS-097 |
+| M-121 | Nexus Dokumentensignatur | mittel | 3 | StRS-094, SyRS-096, SwRS-097 |
+| M-122 | Nexus Verwaltung und Einstellungen | flach | 1 | SwRS-142 |
+| M-123 | Web-Konten (WebAccount) | flach | 2 | StRS-092, SwRS-141 |
+| M-124 | Externe Warenwirtschafts- und Bank-APIs | mittel | 4 | SyRS-123, SyRS-124, SwRS-123, SwRS-137 |
+| M-125 | Gateway / EDI-Konnektoren und E-Rechnung | mittel | 5 | StRS-049, SyRS-051, SwRS-052, SwRS-057, SwRS-138 |
+| M-126 | RMM-Anbindung (Riverbird) | mittel | 3 | StRS-034, SyRS-039, SwRS-040 |
+| M-127 | Persistenz / ORM | flach | 1 | SwRS-143 |
+| M-128 | Domänenmodell | flach | 1 | SwRS-144 |
+| M-129 | Basisbibliotheken | mittel | 3 | SwRS-145, SyRS-012, SwRS-011 |
+| M-130 | UI-Bausteine | flach | 2 | SwRS-149, SwRS-012 |
+| M-131 | Lokalisierung | mittel | 3 | StRS-003, SyRS-004, SwRS-004 |
+| M-132 | Build, Auslieferung und Betrieb | flach | 1 | SwRS-146 |
+| M-133 | Testsuite | flach | 2 | SyRS-120, SwRS-120 |
+| M-134 | Mobile-Schnittstelle | flach | 2 | SyRS-111, SwRS-111 |
+| M-135 | Telekom D!VE | flach | 1 | SwRS-136 |
+
+---
+
+## 3. Konsistenzcheck über das gesamte Anforderungs-Set
+
+Der Check wurde vor Abgabe über alle 380 Anforderungen aus `StRS.md`, `SyRS.md` und `SwRS.md` ausgeführt. Grundlage ist eine maschinelle Auswertung der Anforderungsblöcke; die Prüfpunkte entsprechen den Vorgaben des Auftrags.
+
+### 3.1 Kennzahlen des Anforderungs-Sets
+
+| Kennzahl | Wert |
+|---|---|
+| Anforderungen gesamt | 380 |
+| davon StRS | 100 |
+| davon SyRS | 130 |
+| davon SwRS | 150 |
+| Belege gesamt | 740 |
+| Belege je Anforderung (Mittel) | 1,95 |
+| Anforderungen mit genau einem Beleg | 109 (28,7 %) |
+| `PRIMÄR`-Belege | 576 (77,8 % aller Belege) |
+| `SEKUNDÄR`-Belege | 155 (21,0 %) |
+| `KONTEXT`-Belege | 9 (1,2 %) |
+| Anforderungen mit Status `HYPOTHESE` | 15 (3,9 %) |
+| Anforderungen mit Konsolidierungskandidat | 132 (34,7 %) |
+| Typverteilung | funktional 136, Daten 91, Schnittstelle 80, Sicherheit 49, nicht-funktional 24 |
+| Nicht-funktionale Anforderungen mit ISO-25010-Merkmal | 24 von 24 (100 %) |
+
+Verteilung der ISO-25010-Merkmale über die 24 nicht-funktionalen Anforderungen: Wartbarkeit 9, Zuverlässigkeit 6, Performance-Effizienz 4, Übertragbarkeit 3, Benutzbarkeit 2.
+
+### 3.2 Doppelte oder mehrfach vergebene IDs
+
+**Befund: keine.** Die 380 IDs sind eindeutig und lückenlos: `StRS-001` bis `StRS-100`, `SyRS-001` bis `SyRS-130`, `SwRS-001` bis `SwRS-150`. Geprüft durch Sortieren und Zählen der Werte des Feldes `ID`.
+
+### 3.3 Anforderungen ohne Beleg
+
+**Befund: keine.** Jede der 380 Anforderungen führt mindestens einen Beleg mit Klassifikation und Begründung.
+
+### 3.4 Anforderungen ohne Angabe zur Übernahmewürdigkeit
+
+**Befund: keine.** Alle 380 Anforderungen tragen eine gefüllte Angabe im Feld `Übernahmewürdigkeit` mit Begründung. Verteilung: 344 `übernehmen`, 26 `Workaround`, 7 `veraltet`, 3 `Sonderfall`.
+
+### 3.5 Tracelinks auf nicht existierende IDs
+
+**Befund: keine.** Alle in den Feldern `Tracelinks` genannten Kennungen verweisen auf vorhandene Anforderungen. Zusätzlich gilt:
+
+- Jede der 100 StRS-Anforderungen ist mit mindestens einer SyRS-Anforderung verbunden.
+- Jede der 130 SyRS-Anforderungen ist mit mindestens einer StRS-Anforderung verbunden.
+- Jede der 150 SwRS-Anforderungen ist mit mindestens einer SyRS-Anforderung verbunden.
+
+Die konsolidierte Tabelle in `Traceability.md` enthält 249 Zeilen.
+
+### 3.6 Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsmarkierung
+
+**Befund: keine unmarkierten Dubletten festgestellt.** Geprüft wurde paarweise über Titel und Aussage innerhalb jeder Ebene sowie ebenenübergreifend über die Tracelinks. Dabei gilt die im Auftrag vorgegebene Abgrenzung: Zwei Anforderungen, die denselben Sachverhalt aus Sicht verschiedener Ebenen beschreiben, sind kein Konsolidierungsfall, sondern über Tracelinks verbunden.
+
+Die 132 markierten Konsolidierungskandidaten betreffen durchweg **fachlich gleichartige Konzepte in getrennten Implementierungen**. Die wesentlichen Gruppen:
+
+| Konsolidierungsgruppe | Getrennte Implementierungen | Beispielanforderungen |
+|---|---|---|
+| Gerät beim Kunden | Stammblätter (M-006), Konto-Geräte (M-062), AssetManagement/DocuBoard (M-063) | StRS-016, StRS-017, SwRS-022 |
+| Geschäftspartner | Alttabellen `Kunden`/`Kreditor` gegen Kontostruktur `Accounts` | StRS-011, SwRS-015, SwRS-016 |
+| Vertrag | Kundenverträge im Belegwesen (M-011) gegen Lieferantenverträge (M-005) | StRS-015, StRS-031 |
+| Projekt | CRM-Projekt (M-003), Ticketprojekt (M-056), freie Projektnummer am Beleg | StRS-013, SyRS-017 |
+| Abrechnung wiederkehrender Leistungen | Vertragsabrechnung (M-012), Pauschalabrechnung (M-013), Ticketabrechnung (M-014) | StRS-036, StRS-037 |
+| Aufgabe | Taskmanagement (M-055) gegen Todo-Liste (M-069) | StRS-067, SwRS-070 |
+| Arbeitszeit | Helpdesk-Timer (M-051) gegen MyDay-Arbeitspositionen (M-067) | StRS-098, SyRS-065 |
+| Interne Kommunikation | Chat (M-071), Benachrichtigungen (M-072), Social-Media-Datenstrom (M-079) | StRS-099, SwRS-133 |
+| Preisimport | Artikelimport (M-032), Projektpreis-Import (M-045), Sonderpreis-Importe (M-046) | StRS-057, SwRS-148 |
+| Datenzugriff im Client | `BL*Logic` gegen `WS*Logic` je Modul | StRS-008, SwRS-012 |
+| Schnittstellengeneration | Legacy-REST (M-113) gegen versionierte v1-API (M-114) | SyRS-104, SwRS-105 |
+| Einstellungen | Alttabelle `Stammdat` gegen `ApplicationSettings` | StRS-086, SwRS-089 |
+| Änderungsverfolgung | Auditspalten, Belegversionen, `AppRightLog`, `ReceiptLogBL`, `AccountDeviceLog`, `AccessTokenLog`, NHibernate-Ereignishorcher | StRS-007, SyRS-011 |
+| Platzhalterersetzung | Externe Tools, Reportengine, Mailvorlagen, Mahnschreiben | SyRS-092, SwRS-046 |
+| Anwendertext | Ressourcendateien gegen im Quelltext hinterlegte deutsche Meldungen | StRS-003, SwRS-004 |
+| Seriennummer / Inventur | `BarCode` gegen `BarCode2`, `InventoryBL` gegen `InventoryNewBL` | SwRS-061, SyRS-116 |
+| Kontoumsatzabruf | finAPI-Klient gegen FinTS-Verbindung | StRS-050, SyRS-052 |
+| Sendungsanmeldung | GLS gegen Shipcloud | StRS-060, SwRS-063 |
+| Zahlungsvereinbarung | Belegkonditionen (`Zahkond`) gegen Zahlungskonditionen am Vertrag | SwRS-150 |
+| Vertragsauswertung | `ContractEvaluationOld` gegen `ContractEvaluation2` | StRS-040, SwRS-045 |
+
+### 3.7 Risikorelevante Anforderungen mit Belegsituation
+
+Als risikorelevant gelten nach Vorgabe des Auftrags alle Anforderungen zu **Sicherheitsregeln, Abrechnungs- und Fakturierungslogik sowie Berechtigungen**. Die Auswahl erfolgte maschinell über den Typ `Sicherheit` sowie über Schlüsselwörter in Titel und Typ (unter anderem *Abrechn*, *Rechnung*, *Faktur*, *Provision*, *Mahn*, *Zahlung*, *SEPA*, *Steuer*, *Preis*, *Lizenz*, *Recht*, *Berechtig*, *Kennwort*, *Anmeld*, *Sicher*, *Token*, *Verschlüssel*, *Zugriff*, *DSGVO*, *Signatur*, *Kontingent*, *Beleg*).
+
+**Ergebnis: 172 risikorelevante Anforderungen. Davon 165 mit mindestens einem `PRIMÄR`-Beleg, 7 ohne `PRIMÄR`-Beleg — diese 7 sind ausnahmslos als `[HYPOTHESE]` gekennzeichnet. Verstöße gegen die risikobasierte Priorisierung: keine.**
+
+| ID | Titel | `PRIMÄR`-Beleg vorhanden | Kennzeichnung |
+|---|---|---|---|
+| StRS-001 | Durchgängige Abwicklung vom Angebot bis zur Rechnung in einem System | ja | belegt |
+| StRS-004 | Funktionsumfang wird über Lizenzen freigeschaltet | ja | belegt |
+| StRS-005 | Rollenbasierte Zugriffssteuerung über Rechtegruppen | ja | belegt |
+| StRS-006 | Einschränkende Rechte begrenzen die Sicht auf eigene Vorgänge oder die eigene Filiale | ja | belegt |
+| StRS-008 | Betrieb wahlweise mit direktem Datenbankzugriff oder über den Web-Service | ja | belegt |
+| StRS-021 | Eindeutige, lückenlos vergebene Belegnummern je Nummernkreis | ja | belegt |
+| StRS-022 | Belegversionen bleiben vollständig erhalten | ja | belegt |
+| StRS-023 | Belege gegen gleichzeitige Änderung schützen | ja | belegt |
+| StRS-024 | Belegerstellung nur mit passendem Recht und passender Filiale | ja | belegt |
+| StRS-025 | Neue Belege bei erreichter Mahnstufe sperren | ja | belegt |
+| StRS-026 | Steuerliche Pflichtangaben des Kunden vor Belegerstellung prüfen | ja | belegt |
+| StRS-027 | Mindestpreisunterschreitung nur mit besonderem Recht | ja | belegt |
+| StRS-028 | Belegstatus und Pflichtangaben je Belegart konfigurierbar | ja | belegt |
+| StRS-029 | Aus Belegen unmittelbar Tickets erzeugen | ja | belegt |
+| StRS-030 | Belegdokumente erzeugen, archivieren und elektronisch signieren lassen | ja | belegt |
+| StRS-031 | Verträge als eigene Belegart mit Laufzeit und Abrechnungsintervall | ja | belegt |
+| StRS-032 | Turnusmäßige Rechnungsstellung aus Verträgen | ja | belegt |
+| StRS-033 | Kontingente im Vertrag führen und verbrauchsabhängig verrechnen | ja | belegt |
+| StRS-034 | Verbrauchsabhängige Vertragsabrechnung aus externen Nutzungsdaten | nein | [HYPOTHESE] |
+| StRS-035 | Klickabrechnung für Druck- und Kopiersysteme | nein | [HYPOTHESE] |
+| StRS-036 | Pauschalabrechnung unabhängig vom Einzelaufwand | ja | belegt |
+| StRS-037 | Rechnungen unmittelbar aus erfassten Ticketzeiten erzeugen | ja | belegt |
+| StRS-038 | Vertriebsprovisionen nach Schema berechnen | ja | belegt |
+| StRS-039 | Provisionen aus dem Vertrag auf Folgebelege übernehmen | ja | belegt |
+| StRS-041 | Dreistufiges Mahnwesen mit protokollierter Stufenerhöhung | ja | belegt |
+| StRS-042 | Offener Betrag berücksichtigt Zahlungen und Gutschriften | ja | belegt |
+| StRS-043 | Steuersätze je Land mit Erlös- und Aufwandskonten | ja | belegt |
+| StRS-044 | Zahlungseingänge erfassen und Rechnungen als bezahlt kennzeichnen | ja | belegt |
+| StRS-045 | SEPA-Lastschriften in mehreren Formatversionen erzeugen | ja | belegt |
+| StRS-046 | Rücknahme eines SEPA-Exports öffnet die Rechnung nachvollziehbar wieder | ja | belegt |
+| StRS-047 | Belegdaten an die Finanzbuchhaltung übergeben und Offene Posten zurücklesen | ja | belegt |
+| StRS-048 | Belege und Belegbilder an DATEV übertragen | nein | [HYPOTHESE] |
+| StRS-049 | Elektronische Rechnungen nach ZUGFeRD und XRechnung | ja | belegt |
+| StRS-051 | Barzahlungen und Kassenbuch führen | ja | belegt |
+| StRS-052 | Einkaufsbelegkette mit eigener Rechtestruktur | ja | belegt |
+| StRS-054 | Belegaustausch mit Distributoren über EDI | ja | belegt |
+| StRS-056 | Artikelstamm mit Preisen, Einheiten und Warengruppen | ja | belegt |
+| StRS-057 | Artikel- und Preisdaten von Distributoren importieren | ja | belegt |
+| StRS-063 | Ticketzeiten sind nach Belegzuweisung unveränderlich | ja | belegt |
+| StRS-065 | Wiederkehrende Serviceabläufe über Ticketprozessvorlagen steuern | ja | belegt |
+| StRS-076 | Managed-Service-Lizenzen sammeln und mit Verträgen abgleichen | ja | belegt |
+| StRS-077 | Reports definieren, drucken, exportieren und zeitgesteuert versenden | ja | belegt |
+| StRS-078 | Anmeldung über mehrere Verfahren mit systemweiter Vorgabe | ja | belegt |
+| StRS-079 | Zweiter Faktor bei der Anmeldung | ja | belegt |
+| StRS-080 | Benutzerkonten zeitlich befristen und deaktivieren | ja | belegt |
+| StRS-081 | Kennwortverwaltung mit Mindestlänge und Änderungsnachweis | ja | belegt |
+| StRS-082 | API-Zugriffstoken mit Ablauf, Sperre und Nutzungsprotokoll | ja | belegt |
+| StRS-083 | Kundenzugangsdaten verschlüsselt verwalten und Zugriffe protokollieren | ja | belegt |
+| StRS-084 | Auskunfts- und Löschanspruch nach DSGVO bedienen | ja | belegt |
+| StRS-092 | Kundenportal mit eigenem Zugang, eigenem Rechtemodell und eigenem Port | ja | belegt |
+| StRS-095 | Outlook-Integration für Belege, Tickets und Kontakte | ja | belegt |
+| StRS-097 | Termine mit Exchange abgleichen, gesteuert über Abteilungszugehörigkeit | ja | belegt |
+| SyRS-001 | Einheitliche Belegstruktur aus Kopf und Positionen | ja | belegt |
+| SyRS-002 | Belege in Folgebelege überführen und Belege kopieren | ja | belegt |
+| SyRS-003 | Filialbezug an Beleg, Mitarbeiter, Rechtegruppe und Lager | ja | belegt |
+| SyRS-005 | Lizenzprüfung bei jeder Anmeldung mit Anzahl-, Ablauf- und Versionsprüfung | ja | belegt |
+| SyRS-006 | Modul- und Einstellungsverfügbarkeit aus Lizenz und Recht ableiten | ja | belegt |
+| SyRS-007 | Rechteermittlung über eine zwischengespeicherte Rechteliste je Benutzer | ja | belegt |
+| SyRS-008 | Rechtebaum mit Elternrechten und Zwangsvergabe übergeordneter Rechte | ja | belegt |
+| SyRS-009 | Sichtbarkeitsstufe aus gewährendem und einschränkendem Recht ableiten | ja | belegt |
+| SyRS-010 | Rechteänderungen werden vollständig protokolliert | ja | belegt |
+| SyRS-013 | Zusatzfelder mit Datentyp und verschlüsseltem Werttyp | ja | belegt |
+| SyRS-017 | Projektzuordnung an Belegen über eine freie Projektnummer | ja | belegt |
+| SyRS-018 | Kampagnenphasen werden zeitgesteuert fortgeschrieben | ja | belegt |
+| SyRS-022 | Produktlebenszyklusdaten werden zeitgesteuert importiert | ja | belegt |
+| SyRS-024 | Produktmatrix als geteiltes Steuerelement in mehreren Oberflächen | ja | belegt |
+| SyRS-026 | Belegversionierung über strukturgleiche Versionstabellen | ja | [HYPOTHESE] |
+| SyRS-027 | Optimistische Nebenläufigkeitsprüfung über einen Belegschlüssel | ja | belegt |
+| SyRS-028 | Belegartspezifische Rechteprüfung über eine austauschbare Fachlogik | ja | belegt |
+| SyRS-029 | Mahnstufensperre je Belegart konfigurierbar | ja | belegt |
+| SyRS-031 | Preisfindung aus mehreren Preisquellen mit Mindestpreisschutz | ja | belegt |
+| SyRS-032 | Anwenderdefinierter Belegstatus getrennt vom Systemstatus | ja | belegt |
+| SyRS-033 | Ticketerzeugung aus Belegen mit Wiederverwendung bestehender Tickets | ja | belegt |
+| SyRS-034 | Belegdokument aus Report, Reportgruppe und Ausgabekonfiguration erzeugen | ja | belegt |
+| SyRS-035 | PDF-Signatur nur bei verfügbarem Zertifikat | ja | belegt |
+| SyRS-036 | Vertragsmerkmale für Laufzeit, Abrechnung, Kontingent und Verlängerung | ja | belegt |
+| SyRS-037 | Vertragsende und Vertragsabschluss werden zeitgesteuert überwacht | ja | belegt |
+| SyRS-038 | Kontingentabrechnung bei abweichenden Intervallen normalisieren | ja | belegt |
+| SyRS-039 | Abbruch der Rechnungserzeugung bei unvollständigen Nutzungsdaten | nein | [HYPOTHESE] |
+| SyRS-040 | Zählerstände als Grundlage der Klickabrechnung | ja | belegt |
+| SyRS-041 | Modulverfügbarkeit über kombinierte Rechte- und Lizenzausdrücke | ja | belegt |
+| SyRS-042 | Abrechnungseinstellungen der Ticketabrechnung als eigene Konfiguration | ja | belegt |
+| SyRS-043 | Provisionsschemas zeitgesteuert auf offene Belege anwenden | ja | belegt |
+| SyRS-045 | Mahnläufe je Kunde mit Vorschau und Reportprüfung | ja | belegt |
+| SyRS-046 | Offene-Posten-Sicht über Rechnungsbeträge, Zahlungen und Gutschriften | ja | belegt |
+| SyRS-047 | Steuersätze werden zeitgesteuert an Artikel und Warengruppen fortgeschrieben | ja | belegt |
+| SyRS-048 | Zahlungseingänge und -ausgänge getrennt führen | ja | belegt |
+| SyRS-050 | Buchhaltungsübergabe mit eigener Belegartzuordnung | ja | belegt |
+| SyRS-051 | Elektronische Rechnung als eigenständige Datei und als eingebettetes PDF | ja | belegt |
+| SyRS-053 | Kassenbuchungen mit eigenem Nummernkreis und Filialbindung | ja | belegt |
+| SyRS-054 | Lieferantenbelege mit eigenen Repositories und externer Belegnummer | ja | belegt |
+| SyRS-055 | Bestellvorschläge und Bestandsdaten zeitgesteuert aktualisieren | ja | belegt |
+| SyRS-058 | Einkaufspreis an der Belegposition nachträglich anpassbar | ja | belegt |
+| SyRS-060 | Artikelimport und Preisaktualisierung laufen als eigenständige Dienste | ja | belegt |
+| SyRS-064 | Ticket mit Bearbeiterzuordnung, Fingerabdruck und Sichtbarkeitsmerkmal | ja | belegt |
+| SyRS-066 | Zeitänderungen prüfen die Zuordnung über den Mitarbeiterartikel | ja | belegt |
+| SyRS-071 | Ticketprojekte mit eigener Sichtbarkeitssteuerung | ja | belegt |
+| SyRS-074 | Eskalationen laufen zeitgesteuert mit eigener Mailvorlage | ja | belegt |
+| SyRS-076 | Auswertungsendpunkte sind einzeln rechtegeschützt | ja | belegt |
+| SyRS-080 | Verbindungsticket als Sitzungsnachweis mit Ablauf und Auffrischung | ja | belegt |
+| SyRS-081 | Abgelaufene Verbindungstickets werden minütlich entfernt | ja | belegt |
+| SyRS-082 | Anmeldeversuche und Anmeldedaten werden protokolliert | ja | belegt |
+| SyRS-083 | Anmeldung über Schnittstellen mit Ticket oder Zugriffstoken | ja | belegt |
+| SyRS-084 | Zugriffstoken protokollieren jeden Aufruf mit Methode und IP-Adresse | ja | belegt |
+| SyRS-085 | Vertrauliche Werte werden symmetrisch mit ableitbarem Schlüssel verschlüsselt | ja | belegt |
+| SyRS-086 | DSGVO-Bereinigung nur mit Recht und freigeschaltetem Modulmerkmal | ja | belegt |
+| SyRS-093 | Web-Portal führt Rechte, Web-Rechte, Lizenzen und Anmeldeart als Ansprüche | ja | belegt |
+| SyRS-094 | Kundenportal ist von der Mitarbeiteroberfläche technisch getrennt | ja | belegt |
+| SyRS-095 | Kundenportal bündelt Belege, Verträge, Tickets, Dokumente und Formulare | ja | belegt |
+| SyRS-096 | Geteilte Dokumente werden über Token und eigene Autorisierung freigegeben | ja | belegt |
+| SyRS-098 | Echtzeitkanäle sind authentifiziert und teils über ein Geheimnis geschützt | ja | belegt |
+| SyRS-103 | Fehler in Schnittstellenaufrufen liefern keine internen Details | ja | belegt |
+| SyRS-107 | Nutzungsdaten werden verdichtet erhoben und zeitgesteuert übertragen | ja | belegt |
+| SyRS-108 | Schutz vor unbeabsichtigtem Mailversand an Kundenadressen | ja | belegt |
+| SyRS-117 | Kommissionierung mit Mengenrückmeldung an den Beleg | ja | belegt |
+| SyRS-121 | Mailversand mit Vorlagen, Variablenersetzung, Signatur und Nachverfolgung | ja | belegt |
+| SyRS-124 | Fremdsysteme melden sich mit eigener Anwendungsart, Lizenz und Ablaufregel an | ja | belegt |
+| SyRS-126 | Länderstammdaten mit Währungskurs und steuerlicher Vorbelegung | ja | belegt |
+| SyRS-127 | Kostenstelle und Kostenträger je Belegart als Pflichtangabe steuerbar | ja | belegt |
+| SyRS-129 | Verbindungsdaten liegen in einer Datei mit verschlüsseltem Kennwort | ja | belegt |
+| SwRS-001 | Abstrakte Belegbasisklasse mit Pflichtmethoden | ja | belegt |
+| SwRS-005 | Lizenzzugriff über eine Schnittstelle mit Einzelinstanz und Prüfattrappe | ja | belegt |
+| SwRS-006 | Rechteabfrage als parametrisierte SQL-Abfrage über zwei Zuordnungstabellen | ja | belegt |
+| SwRS-007 | Rechtestruktur mit Elternverweis, Kinderzähler und Veraltungskennzeichen | ja | belegt |
+| SwRS-008 | Sichtbarkeitsstufe als eigener Aufzählungstyp | ja | belegt |
+| SwRS-009 | Rechteprotokoll als eigene Entität mit Vorgangsart | ja | belegt |
+| SwRS-012 | Auflösung der Datenzugriffsschicht über einen Dienstbehälter | nein | [HYPOTHESE] |
+| SwRS-020 | Lieferantenverträge über die dreiteilige Zugriffskette | nein | [HYPOTHESE] |
+| SwRS-021 | Stammblatt als Kopf-Positions-Entität im Belegzweig | ja | belegt |
+| SwRS-025 | Produktmatrix als geteiltes Steuerelement mit eigener Fachlogik | ja | belegt |
+| SwRS-029 | Belegartabhängige Fachlogik über einen Verteiler mit Ausdrucksparameter | ja | belegt |
+| SwRS-030 | Mahnstufe des Kontos über eine gemeinsame Kontoinformation | ja | belegt |
+| SwRS-031 | Steuerliche Kundenangaben als eigene Felder am Kunden | ja | belegt |
+| SwRS-032 | Preisermittlung in eigenen Hilfsklassen der Belegverarbeitung | ja | belegt |
+| SwRS-034 | Ticketerzeugung aus Belegen über vorbereitete Informationsobjekte | ja | belegt |
+| SwRS-036 | Vertragsentität mit Schnittstellen für Kontingent, Status und Provision | ja | belegt |
+| SwRS-037 | Vertragsabrechnung als Teilklasse mit deutschsprachigen Zwischenobjekten | ja | belegt |
+| SwRS-038 | Abrechnungsparameter als eigenes Übergabeobjekt | ja | belegt |
+| SwRS-039 | Kontingentänderungen erzeugen einzelne Protokolleinträge je Merkmal | ja | belegt |
+| SwRS-041 | Verdichtete Stammblattobjekte für die Klickabrechnung | ja | belegt |
+| SwRS-042 | Modulregistrierung als Datensatz mit Rechte- und Lizenzausdruck | ja | belegt |
+| SwRS-043 | Belegerzeugung aus Zeiten mit eigenen Ergebnisobjekten | ja | belegt |
+| SwRS-044 | Provisionsdaten in Schema-, Positions- und Zielentitäten | ja | belegt |
+| SwRS-046 | Mahnlauf mit Reportparametern und je Kunde gebündelten Rechnungen | ja | belegt |
+| SwRS-047 | Rechnungsbeträge als getrennte Felder für Brutto, Zahlung und Gutschrift | ja | belegt |
+| SwRS-048 | Steuersatz mit Kontozuordnung und Nachfolgeverweis | ja | belegt |
+| SwRS-049 | Zahlungsentitäten mit eigenem Protokoll und Löschfilter | ja | belegt |
+| SwRS-051 | Buchhaltungsschnittstelle mit eigener Belegartabbildung | ja | belegt |
+| SwRS-052 | Elektronische Rechnung als eigene Erzeugungslogik mit XML-Aufbau im Code | ja | belegt |
+| SwRS-053 | Bankzugriff über gekapselte Klienten mit eigener Fehlerklasse | ja | belegt |
+| SwRS-054 | Kassenvorgänge als eigener Fachbereich | ja | belegt |
+| SwRS-055 | Lieferantenbelege mit eigenen Fachlogikordnern und Speicherrepositories | nein | [HYPOTHESE] |
+| SwRS-058 | Einkaufspreisänderung positionsweise und belegweit mit Speicherentscheidung | ja | belegt |
+| SwRS-066 | Zeitrechteprüfung in der Web-Service-Schicht statt in der Fachlogik | ja | belegt |
+| SwRS-081 | Zwei-Faktor-Prüfung über austauschbare Prüfverfahren | ja | belegt |
+| SwRS-082 | Benutzerkonto trägt Sperrzeitraum, Anmeldedaten und Anmeldeverfahren | ja | belegt |
+| SwRS-083 | Kennwortrichtlinie je Benutzer statt systemweit | ja | belegt |
+| SwRS-084 | Kennwortablage als ungesalzener SHA-1-Hash über eine Einbyte-Kodierung | ja | belegt |
+| SwRS-085 | Zugriffstoken mit Hashablage, Ablaufmerkmal und Weichlöschung | ja | belegt |
+| SwRS-086 | Symmetrische Verschlüsselung mit aus dem Schlüssel abgeleitetem Initialisierungsvektor | ja | belegt |
+| SwRS-087 | DSGVO-Löschung derzeit nur für Ansprechpartner umgesetzt | ja | belegt |
+| SwRS-094 | Portalrichtlinien werden aus Rechtekonstanten durch Reflexion erzeugt | ja | belegt |
+| SwRS-095 | Kundenportalport als eigene Konfigurationsklasse mit Vorrang bei fehlendem Wert | ja | belegt |
+| SwRS-110 | Entwicklerschutz als statische Klasse mit Buildabhängigkeit | ja | belegt |
+| SwRS-111 | Mobile Datensicht mit eigenem Datenzugriffsordner | ja | belegt |
+| SwRS-125 | Textbausteine mit eigener Ersetzungsklasse und eigenem Datenzugriff | ja | belegt |
+| SwRS-128 | Zuschlagssätze mit eigener Fachlogik und Belegzuordnung | ja | belegt |
+| SwRS-139 | Datenbankdiagnose als lesende Auswertungsklasse | ja | belegt |
+| SwRS-141 | Web-Konten mit eigener Verwaltung und eigener Kennwortänderung | ja | belegt |
+| SwRS-143 | Persistenzschicht mit Sitzung, generischem Zugriff und benannten Abfragen | ja | belegt |
+| SwRS-148 | Preisimporte für Projekte und Verträge als getrennte Module | ja | belegt |
+| SwRS-150 | Belegkonditionen mit Skontostufen und Gültigkeit je Belegart | ja | belegt |
+
+### 3.8 Abgleich `Hypothesen.md` gegen die Inline-Markierungen
+
+**Befund: deckungsgleich.** `Hypothesen.md` wurde maschinell aus den Anforderungsdateien erzeugt und enthält genau die Anforderungen, deren Feld `Aussage` mit `[HYPOTHESE]` beginnt **und** deren Feld `Status` mit `HYPOTHESE` beginnt. Beide Mengen umfassen dieselben 15 Kennungen:
+
+`StRS-034`, `StRS-035`, `StRS-048`, `StRS-093`, `SyRS-019`, `SyRS-023`, `SyRS-026`, `SyRS-039`, `SyRS-056`, `SyRS-057`, `SwRS-012`, `SwRS-020`, `SwRS-024`, `SwRS-027`, `SwRS-055`
+
+`Hypothesen.md` enthält keine zusätzlichen freien Fragen. Offene Punkte ohne zugehörige Anforderung stehen ausschließlich in Abschnitt 4.5 und Abschnitt 5 dieses Berichts.
+
+---
+
+## 4. Selbstbewertung
+
+### 4.1 Analysetiefe je Modul in absoluten Zahlen
+
+Von **135 Modulen** des Inventars wurden analysiert:
+
+| Einstufung | Anzahl Module | Anteil |
+|---|---|---|
+| `tief` (≥ 8 Anforderungen) | **5** | 3,7 % |
+| `mittel` (3–7 Anforderungen) | **79** | 58,5 % |
+| `flach` (1–2 Anforderungen) | **51** | 37,8 % |
+| `nicht analysiert` (0 Anforderungen) | **0** | 0,0 % |
+
+Die fünf tief analysierten Module sind: M-009 Belegwesen Verkauf (30 Anforderungen), M-092 Authentifizierung und Anmeldung (12), M-091 Rechteverwaltung (10), M-115 Web-Service-Hosting (10) und M-018 Mahnwesen (9). Diese Auswahl folgt der Vorgabe aus Schritt 0c, zuerst dort zu vertiefen, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik sowie Berechtigungsprüfungen liegen.
+
+### 4.2 Mindestabdeckung
+
+**Die Mindestabdeckung nach Schritt 0b ist erreicht.** Jedes der 135 Module trägt mindestens eine Anforderung; kein Modul musste als `nicht analysiert` geführt werden. Die Reihenfolge des Vorgehens entsprach dem Auftrag: zuerst das vollständige Inventar (Abschnitt 1), danach je Modul mindestens eine Anforderung, erst zuletzt die Vertiefung der fünf risikonahen Module.
+
+Zwei Module wurden erst während der Formalisierung entdeckt und dem Inventar hinzugefügt (M-134 Mobile-Schnittstelle, M-135 Telekom D!VE). Beide erhielten unmittelbar Anforderungen. Das Inventar wurde damit ergänzt, aber an keiner Stelle gekürzt.
+
+### 4.3 Stellen mit dünner Belegsituation
+
+Der Gesamtanteil der `PRIMÄR`-Belege liegt bei 77,8 %. Die Belegsituation ist jedoch ungleich verteilt. Dünn belegt sind:
+
+**a) Module ohne jeden `PRIMÄR`-Beleg (3 von 135):**
+
+| Modul | Anforderungen | Grund |
+|---|---|---|
+| M-008 Audit / Umfragen | StRS-019, SyRS-023, SwRS-024 | Belegt sind nur Modulregistrierung, Ordnerstruktur und Einstellungsseite. Die Umfrageentitäten und die Auswertungslogik wurden nicht geöffnet. |
+| M-023 DATEV-Belegtransfer | StRS-048 | Belegt sind nur Modulregistrierung und Einstellungsseite; die übertragende Codestelle wurde nicht geöffnet. |
+| M-085 Management Info | StRS-075 | Belegt ist nur die Modulregistrierung; die Kennzahlenermittlung wurde nicht geöffnet. |
+
+**b) Weitere Anforderungen ohne `PRIMÄR`-Beleg (12 von 380):** StRS-018 (PLM), StRS-020 (Produktmatrix), StRS-034 und SyRS-039 (RMM-Abrechnung), StRS-035 (Klickabrechnung), StRS-040 (Vertragsauswertung), StRS-067 (Taskmanagement), SyRS-019 und SwRS-020 (Lieferantenverträge), SwRS-012 (ClassContainer), SwRS-027 (Belegversionierung) und SwRS-055 (Speicherrepositories). Zusammen mit den fünf Anforderungen aus Gruppe a sind das 17 von 380 Anforderungen (4,5 %) ohne `PRIMÄR`-Beleg. Alle risikorelevanten Anforderungen dieser beiden Gruppen sind als `[HYPOTHESE]` gekennzeichnet.
+
+**c) Bereiche, deren Belege überwiegend aus der Entwicklerdokumentation stammen:** Belegversionierung (`SyRS-026`, `SwRS-027`), Speicherrepositories der Belege (`SwRS-055`), EDI-Dateifilter und Aufbewahrungsfrist (`SyRS-056`, `SyRS-057`), die dreiteilige Zugriffskette des Clients (`SyRS-019`, `SwRS-012`, `SwRS-020`) und die RMM-Abrechnung (`StRS-034`, `SyRS-039`). Diese fünf Bereiche sind zugleich die inhaltlich anspruchsvollsten Stellen der Codebasis — hier ist der Abstand zwischen dokumentiertem Soll und geprüftem Ist am größten.
+
+**d) Nur 9 `KONTEXT`-Belege** wurden vergeben. Das liegt daran, dass die Änderungshistorie der Codebasis in diesem Lauf nicht auswertbar war (siehe Abschnitt 5.1); Commit-Nachrichten, Tickets und Release Notes standen als Beleggrundlage nicht zur Verfügung.
+
+### 4.4 Begründung der Hypothesenzahl
+
+15 Hypothesen bei 380 Anforderungen (3,9 %) sind für eine Codebasis dieser Größe eine bewusst niedrige Zahl. Sie ergibt sich aus dem gewählten Vorgehen: Aussagen wurden nur dann formuliert, wenn mindestens ein Beleg vorlag; ließ sich eine vermutete Regel nicht belegen, wurde sie entweder als Hypothese aufgenommen oder gar nicht erst geschrieben. Der zweite Fall — nicht geschriebene Anforderungen — ist in Abschnitt 5 als bekannte Lücke ausgewiesen und nicht in der Hypothesenzahl enthalten. Die 15 Hypothesen betreffen ausnahmslos Fälle, in denen die Entwicklerdokumentation eine Regel beschreibt, die zugehörige Codestelle im Rahmen dieses Laufs aber nicht geöffnet wurde.
+
+### 4.5 Offene Punkte ohne zugehörige Anforderung
+
+Diese Punkte sind während der Analyse aufgefallen, ließen sich aber keiner Anforderung zuordnen. Sie gehören nach Vorgabe des Auftrags nicht in `Hypothesen.md`:
+
+1. **Der Schemastand des Datenbankabzugs liegt hinter dem Codestand.** `SSMS_DB_SCHEMA.sql` trägt das Erzeugungsdatum 11.11.2025 und enthält keine Tabelle für die Zugriffstoken, obwohl `AccessTokenBL` und die zugehörigen Entitäten im Code vorhanden sind. Aussagen zum Datenmodell der Zugriffstoken stützen sich daher ausschließlich auf den Code.
+2. **Die Entwicklerdokumentation zur Bindungsarchitektur fehlt.** `docs/reference/architecture/mvvm-in-centron.md` besteht vollständig aus dem Satz „I don't know, but I would like to - please tell me." Die MVVM-Umsetzung des Clients konnte daher nicht dokumentationsgestützt beschrieben werden.
+3. **Abweichung zwischen mitgelieferter Rechtebeschreibung und Code.** `CentronRights.md` beschreibt `RIGHT_MITARBEITERAUSLASTUNG` als Recht zur Anzeige fremder Auslastung. Im Code steuert dieses Recht dagegen das Modul Leistungsnachweise, während die Auslastungssicht über `RIGHT_FREMDAUSLASTUNG` gefiltert wird (siehe StRS-098). Weitere Abweichungen dieser Art sind nicht ausgeschlossen.
+4. **`ScriptMethodsCollection.cs` mit 20.915 Zeilen wurde nicht inhaltlich ausgewertet.** Die Migrationsskripte enthalten fachliche Regeln (Standardwerte, Rechtevergaben, Datenkorrekturen), die in dieser Iteration nicht erschlossen wurden.
+5. **`ApplicationSettingDefinitions.cs` mit 86.561 Byte wurde nicht vollständig gelesen.** Die Datei enthält die Bedeutung jeder einzelnen Einstellung und damit eine große Zahl feingranularer Konfigurationsregeln.
+6. **`UserRightsConst.cs` mit 2.819 Zeilen wurde nur strukturell ausgewertet.** Der vollständige Rechtekatalog mit mehreren hundert Einzelrechten ist nicht in Anforderungen überführt.
+7. **Die 1.535 Datenbanktabellen wurden stichprobenartig ausgewertet.** Die Anforderungen stützen sich auf 26 eindeutige Indizes, 154 CHECK-Constraints und 134 Fremdschlüssel; eine vollständige Durchsicht aller Tabellen fand nicht statt.
+8. **Die 491 Razor-Komponenten und 1.233 XAML-Dateien wurden nicht systematisch auf Bedienregeln geprüft.** Feldbezogene Regeln der Oberfläche (Pflichtfelder, Feldabhängigkeiten, Standardwerte) sind daher unterrepräsentiert.
+9. **Die 52 gespeicherten Prozeduren und 28 Datenbankfunktionen wurden nicht ausgewertet.** Sie können fachliche Regeln enthalten, die außerhalb des C#-Codes liegen.
+10. **Auffällige Bezeichnerfehler im Quellstand:** der Ordner `ReportEngine/PdfStategy` (statt `PdfStrategy`), die Methode `CreateNewReceiptForHelpdekTimers` (statt `Helpdesk`) und die doppelten Spalten `LandID`/`LandI3D` in `MwstSatz` sowie `OicdSubjectIdentifier`/`OpenIdConnectSubjectIdentifier` in `Sichbenu`. Sie sind einzeln zu klein für eine Anforderung, aber für eine Migration relevant.
+
+### 4.6 Erkenntnisse für eine Folge-Iteration
+
+Nach dem Ergebnis dieses Laufs lohnt ein Nachschlag an folgenden Stellen, geordnet nach erwartetem Erkenntnisgewinn:
+
+1. **Die drei Bereiche ohne jeden `PRIMÄR`-Beleg schließen** (M-008 Umfragen, M-023 DATEV-Belegtransfer, M-085 Management Info). Der Aufwand ist gering, der Gewinn hoch, weil damit kein Modul mehr ausschließlich auf Struktur- und Oberflächenbelegen ruht.
+2. **Die 15 Hypothesen auflösen.** Jede benennt eine konkrete Codestelle, die zu öffnen ist. Besonders wichtig sind `SwRS-027` und `SwRS-055`: Belegversionierung und Speicherrepositories entscheiden darüber, ob eine Migration Belegdaten vollständig übernimmt.
+3. **`ReceiptBL` mit 11.441 Zeilen vollständig erschließen.** In diesem Lauf wurden rund 40 Methoden ausgewertet; die Klasse enthält erkennbar weitere Regeln zu Bestandsführung, automatischem Belegabschluss, Barcodezuordnung und Weiterführungsoptionen.
+4. **Den Rechtekatalog vollständig überführen.** Aus `UserRightsConst.cs` und der Tabelle `Sichrech` lässt sich ein vollständiges Berechtigungsmodell des Zielsystems ableiten; die Abweichung zwischen `CentronRights.md` und Code (Abschnitt 4.5, Punkt 3) macht eine Prüfung Recht für Recht erforderlich.
+5. **Die Migrationsskripte als Quelle fachlicher Regeln auswerten.** `ScriptMethodsCollection.cs` und die Skriptdateien enthalten Standardwerte, Rechtevergaben und Datenkorrekturen, die sonst nirgends dokumentiert sind.
+6. **Einen aktuellen Datenbankabzug beistellen.** Der vorliegende Abzug ist gegenüber dem Code veraltet; ein Abgleich Tabelle für Tabelle würde die Zahl der datenbezogenen `PRIMÄR`-Belege deutlich erhöhen.
+7. **Die Preisfindung zusammenhängend untersuchen.** Artikelpreis, Staffelpreis, Aktionspreis, Kundensonderpreis, Projektpreis und Vertragspreis wirken zusammen; die Rangfolge ist bisher nur teilweise belegt (`SyRS-031`) und ist für eine Neuimplementierung erfolgskritisch.
+8. **Die Oberflächenregeln erschließen.** XAML- und Razor-Dateien enthalten Pflichtfeld- und Sichtbarkeitsregeln, die im Backend nicht gespiegelt sind; ohne sie fehlt der Neuimplementierung ein Teil des Bedienverhaltens.
+
+---
+
+## 5. Bekannte Lücken
+
+### 5.1 Nicht auswertbare Artefaktarten
+
+| Artefaktart | Status | Auswirkung |
+|---|---|---|
+| Change-Historie (Commit-Nachrichten) | **nicht auswertbar.** Das Arbeitsverzeichnis ist kein eigenständiges Repository; `git rev-parse --show-toplevel` liefert das übergeordnete Verzeichnis der Untersuchung, und `git log` für den Codeordner zeigt ausschließlich die Snapshot-Commits der Untersuchung selbst. | Keine `KONTEXT`-Belege aus der Entwicklungsgeschichte; Aussagen zu Workarounds und überholten Stellen stützen sich auf Codekommentare, Obsolete-Markierungen und Altordner. |
+| Tickets, Release Notes, Migrationsnotizen | **nicht vorhanden.** Im Arbeitsverzeichnis liegen keine solchen Dateien. | Die Einstufung `Übernahmewürdigkeit` beruht auf Codebefunden, nicht auf dokumentierten fachlichen Entscheidungen. |
+| Laufende Instanz, Datenbankzugriff | **nicht verfügbar** und nach Auftrag nicht vorauszusetzen. | Alle Aussagen sind statisch abgeleitet; kein Laufzeitverhalten geprüft. |
+| Binärartefakte (`assemblies/`, `nugets/`, `bin/`, `obj/`) | **nicht ausgewertet.** | Regeln in Fremdbibliotheken (unter anderem DevExpress, FastReport, NHibernate, das Lizenz-Client-Assembly `Centron.Office.Client`) sind nicht erfasst. |
+| Beigelegte Fremddokumentation (`COP API Dokumentation.pdf`, `EGIS API Dokumentation.zip`) | **nicht geöffnet.** | Die Anbindungen COP und EGIS sind nur über ihre Assembly-Struktur belegt. |
+
+### 5.2 Bewusst nicht erfasste Bereiche
+
+- **Delphi-Vorgängersystem.** Der Code enthält an mehreren Stellen Rücksichtnahmen auf eine Delphi-Anwendung (Spalten `FormName` und `FormCont` in `Sichrech`, die Versionskorrektur `TryFixCentronDelphiVersionNumber` in `LicenseManager`). Das Vorgängersystem selbst liegt nicht im Arbeitsverzeichnis; seine Regeln sind nicht erfasst.
+- **Riverbird-Produktlinie.** Objekte mit dem Präfix `RB` und die zahlreichen `Riversuite*`-Anwendungsarten gehören zu einer verbundenen, aber eigenständigen Produktlinie. Sie sind im Inventar über M-064 und M-126 vertreten, jedoch nicht vollständig erschlossen.
+- **Testinhalte als Regelquelle.** Die elf Testprojekte wurden als Struktur erfasst (SyRS-120, SwRS-120), ihre Testfälle jedoch nicht als Quelle fachlicher Regeln ausgewertet. Gerade die End-to-End-Tests enthalten belastbare Aussagen über erwartetes Verhalten.
+
+### 5.3 Grenzen der Abdeckungseinstufung
+
+Die Einstufung `tief`, `mittel`, `flach` misst die **Anzahl** der erzeugten Anforderungen, nicht deren fachliche Vollständigkeit. Ein Modul mit drei Anforderungen kann fachlich vollständig beschrieben sein (etwa M-110 Länderstammdaten), während M-009 Belegwesen mit 30 Anforderungen erkennbar unvollständig bleibt. Die Einstufung ist daher als Hinweis auf die Bearbeitungstiefe zu lesen, nicht als Vollständigkeitsaussage.
+
+### 5.4 Nicht geprüfte Aussagen der Entwicklerdokumentation
+
+Die Entwicklerdokumentation unter `docs/` wurde als Beleg zweiter Ordnung verwendet. Sie eröffnet ihre Beschreibung der Systemstruktur selbst mit dem Hinweis, dass es zahlreiche Stellen gibt, an denen die beschriebene Schichtung nicht eingehalten ist (`docs/getting-started/general-structure.md`). Wo eine Anforderung ausschließlich auf dieser Dokumentation beruht, ist sie als `[HYPOTHESE]` gekennzeichnet. Für die übrigen dokumentationsgestützten Aussagen gilt: Sie wurden gegen mindestens einen Codebefund gehalten, aber nicht Zeile für Zeile verifiziert.
+
+---
+
+## 6. Erzeugte Ergebnisdateien
+
+| Datei | Inhalt |
+|---|---|
+| `StRS.md` | 100 Stakeholder-Anforderungen, gegliedert in 10 fachliche Abschnitte |
+| `SyRS.md` | 130 System-Anforderungen, gegliedert in 9 fachliche Abschnitte |
+| `SwRS.md` | 150 Software-Anforderungen, gegliedert in 9 fachliche Abschnitte |
+| `Traceability.md` | konsolidierte Verfolgbarkeitstabelle mit 249 Zeilen |
+| `Hypothesen.md` | 15 Hypothesen mit fehlender Information und offener Frage |
+| `Glossar.md` | 7 Begriffsgruppen mit Fundstellen im Arbeitsverzeichnis |
+| `Analysebericht.md` | dieser Bericht: Modulinventar, Abdeckungstabelle, Konsistenzcheck, Selbstbewertung, bekannte Lücken |
+
+Die analysierte Codebasis wurde ausschließlich gelesen und nicht verändert.

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-a8f5/Ergebnisse/Glossar.md

@@ -0,0 +1,141 @@
+# Glossar
+
+Dieses Glossar erklärt die Domänenbegriffe, die in `StRS.md`, `SyRS.md` und `SwRS.md` verwendet werden. Jeder Eintrag nennt die Fundstelle im Arbeitsverzeichnis, aus der die Bedeutung abgeleitet wurde. Technische Bezeichner (Klassen, Methoden, Spalten) sind in ihrer Originalschreibweise belassen.
+
+---
+
+## 1. Grundbegriffe des Datenmodells
+
+| Begriff | Bedeutung | Fundstelle |
+|---|---|---|
+| **I3D** | Primärschlüsselspalte jeder Tabelle, `int IDENTITY(1,1)`, gruppierter Primärschlüssel. Die Abkürzung steht laut Entwicklerdokumentation für „ID 3develop". Fremdschlüsselspalten tragen das Suffix `I3D` mit vorangestelltem Namen der Zieltabelle. | `docs/guides/database/database-conventions.md`, Abschnitt Primary Key Convention |
+| **BaseEntity** | Abstrakte Basisklasse aller NHibernate-Entitäten; stellt die Eigenschaft `I3D` bereit. Entitäten dürfen keine Logik, keine Überschreibungen und keinen eigenen Konstruktor enthalten. | `docs/reference/architecture/dtos-and-entities.md` |
+| **Compact-Entität** | Verdichtete Lesesicht auf eine Entität mit weniger Feldern, erkennbar am Namenszusatz `Compact` (z. B. `EmployeeCompact`, `HelpdeskCompact`, `AppRightCompact`, `BarCodeCompact`, `MasterDataListCompact`). | `src/backend/Centron.Entities/Entities/` |
+| **DTO** | Übertragungsobjekt zwischen Web-Service und Client; Entitäten verlassen die BL-Schicht nicht. | `docs/reference/architecture/dtos-and-entities.md` |
+| **ObjectKind / CentronObjectKindNumeric** | Numerischer Objektartschlüssel. Verweise auf wechselnde Objektarten werden durchgängig als Paar aus Objektkennung und Objektart geführt (`ObjectI3D` + `ObjectKind`, im Belegprotokoll `AnlageI3D` + `AnlageArt`). | `SSMS_DB_SCHEMA.sql`, Tabelle `SimpleUrls`; `docs/reference/receipts/receipts-backend-architecture.md` |
+| **Soft Delete** | Löschmuster über die Spalten `IsDeleted`, `DeletedByI3D`, `DeletedDate`; der Datensatz bleibt erhalten. | `docs/guides/database/database-conventions.md`, Abschnitt Deletion Tracking |
+
+## 2. Belegwesen
+
+| Begriff | Bedeutung | Fundstelle |
+|---|---|---|
+| **Beleg (Receipt)** | Oberbegriff für die sieben Belegarten Angebot, Auftrag, Lieferschein, Abholschein, Rechnung, Gutschrift und Vertrag. Alle erben von `ReceiptBase`. | `src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptBase.cs` |
+| **Kopf / Position** | Zweiteilige Belegstruktur: eine Kopfzeile (`*Kopf`) mit den Belegdaten und beliebig viele Positionen (`*Pos`). | `docs/reference/receipts/receipts-backend-architecture.md` |
+| **AngKopf / AufKopf / LiefKopf / RechKopf / VertragKopf / GutKopf / AbholKopf** | Historische, deutschsprachige Kopftabellen für Angebot, Auftrag, Lieferschein, Rechnung, Vertrag, Gutschrift und Abholschein. Die zugehörigen Positionstabellen tragen die Endung `Pos`. | `SSMS_DB_SCHEMA.sql` |
+| **Offers / Orders / DeliveryLists / Invoices / Contracts / CreditVouchers / PickupLists** | Englischsprachige Datenbanksichten auf die vorgenannten Alttabellen; sie bilden die Zugriffsschicht der C#-Anwendung. | `docs/reference/receipts/receipts-backend-architecture.md`, Abschnitt Modern Views |
+| **Versionstabelle** | Tabelle mit der Endung `Versions`, strukturgleiche 1:1-Kopie der Ursprungstabelle, ergänzt um `OriginalI3D` und bei Positionstabellen `KopfVersionsI3D`. | `docs/reference/receipts/receipts-backend-architecture.md` |
+| **AnlageLog / AnlageArt** | Gemeinsame Protokolltabelle aller Belegarten; `AnlageArt` unterscheidet die Belegart (1 Angebot, 2 Auftrag, 3 Lieferschein, 4 Rechnung, 5 Abholschein, 6 Gutschrift, 22 Vertrag). | `docs/reference/receipts/receipts-backend-architecture.md` |
+| **Belegweiterführung (Forward)** | Überführung eines Belegs in den nachfolgenden Belegtyp unter Übernahme der Positionen, wahlweise begrenzt auf die noch verfügbare Menge. | `ReceiptBL.ForwardReceipt`, `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs` |
+| **Belegstatus (State)** | Systemseitiger Bearbeitungsstand eines Belegs, geführt im Feld `State` der Basisklasse. | `src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptBase.cs` |
+| **Anwenderdefinierter Belegstatus (ReceiptUserState)** | Frei konfigurierbarer Zusatzstatus je Belegart, unabhängig vom Systemstatus; je Belegart als Pflichtfeld einstellbar. | `ReceiptBL.UpdateReceiptUserState`; Einstellungsseite „Belegstatus" |
+| **ConcurrencyControlGuid** | Nebenläufigkeitsschlüssel am Beleg; jede punktuelle Änderung führt ihn als Parameter mit. | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs`, Signaturen der `Update*`-Methoden |
+| **Nummernkreis (NumberGroup)** | Zähler je Nummernart, Mandant und Filiale mit Wertebereich (`RangeFrom`, `RangeTo`), Schrittweite (`Interval`) und aktuellem Stand (`Current`). | `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs` |
+| **Belegkondition** | Konditionsregel, die auf Belege angewendet wird; eigenes Stammdatenmodul. | `src/centron/Centron.WPF.UI/Modules/Administration/ReceiptConditions/` |
+| **Externe Belegnummer** | Belegnummer des Lieferanten an einem Einkaufsbeleg; wird auf Dubletten geprüft. | `ReceiptBL.ExternalReceiptNumberAlreadyExists` |
+
+## 3. Verträge und Abrechnung
+
+| Begriff | Bedeutung | Fundstelle |
+|---|---|---|
+| **Vertrag (ReceiptContract)** | Belegart für wiederkehrende Leistungen mit Laufzeit, Abrechnungsintervall, Abrechnungsart, Kontingent und automatischer Verlängerung. | `src/backend/Centron.Entities/Entities/Sales/Receipts/ContractLists/ReceiptContract.cs` |
+| **Abrechnungsintervall** | Kombination aus `BillingIntervalKind` (Daily, Monthly, Quarterly, Yearly) und `BillingIntervalDuration`; die Abrechnung rechnet beides in Monate um. | `AutomaticFacturaBL.Contracts.cs` |
+| **Kontingent** | Im Vertrag vereinbartes Leistungsvolumen (Stunden oder Betrag) mit Verbrauchsfortschreibung, Restwertführung und Grenzwerten. | `ReceiptContract`; `docs/reference/receipts/contracts-backend.md` |
+| **Zwischenrechnung (DifferContingentInterval)** | Ausgleichsposition, wenn Kontingentintervall und Abrechnungsintervall voneinander abweichen; unterschieden werden `headMinorToContract`, `interimMinorToContract`, `headMajorToContract` und `interimMajorToContract`. | `AutomaticFacturaBL.Contracts.cs` |
+| **Klickabrechnung** | Abrechnung nach Zählerständen von Druck- und Kopiersystemen; das Zählerintervall ist unabhängig vom Abrechnungsintervall einstellbar. | Einstellungsseite „Klickabrechnung"; `AutomaticFacturaBL.Contracts.cs`, Filter `IsCounterIntervalActive` |
+| **Pauschalabrechnung (Flatrate Billing)** | Abrechnung eines Projekts zum vereinbarten Pauschalbetrag unabhängig vom erfassten Aufwand. | `ModuleRegistration.cs`, `FlatRateProjectAppModuleController` |
+| **Vereinfachte Ticketabrechnung (Timer Billing)** | Erzeugung eines Belegs unmittelbar aus ausgewählten berechenbaren Ticketzeiten. | `ReceiptBL.CreateNewReceiptForHelpdekTimers` |
+| **Provisionsschema** | Regelwerk zur Provisionsberechnung mit Empfängerrolle (`Receiver`), Bezugsquelle (`Source`) und Bezugsgröße (`Value`). | `SSMS_DB_SCHEMA.sql`, Constraints auf `ReceiptProvisionSchemaItems` |
+| **Mahnstufe (DunningLevel)** | Stand des Mahnverfahrens einer Rechnung: `None`, `Level1`, `Level2`, `Level3`; je Stufe werden Datum und Bearbeiter geführt. | `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs` |
+| **OPOS** | Offene Posten; Sicht auf noch nicht ausgeglichene Rechnungen, auch als Rückimport aus der Finanzbuchhaltung. | Modul `OposOverviewAppModuleController`; Einstellungsseite „OPOS Import" |
+| **SEPA / PAIN** | Verfahren und Dateiformate des europäischen Lastschriftverkehrs; unterstützt werden PAIN.008.001.01, .008.003.02, .008.001.02, .008.001.02 GBIC 3 und .008.001.08 GBIC 4. | `PaymentTransactionBL.GetInterfaceList` |
+| **SEPA-Mandat** | Einzugsermächtigung des Kunden, am Vertrag über `MandatI3D` geführt. | `ReceiptContract`; Einstellungsseite „SEPA Lastschrift" |
+| **ZUGFeRD / XRechnung** | Formate der elektronischen Rechnung. Das erzeugte Profil ergibt sich aus dem Vorhandensein einer Leitweg-Identifikationsnummer: ohne sie `EN16931`, mit ihr `XRechnung`. | `src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs` |
+| **Leitweg-ID** | Kennung des öffentlichen Rechnungsempfängers; steuert die Profilwahl der elektronischen Rechnung. | ebenda |
+| **Kontenrahmen** | Struktur der Buchhaltungskonten; je Filiale sind abweichende Erlös- und Aufwandskonten möglich. | `BookKeepingAccountSystemBL`, `BranchRevenueAndExpenseAccountBL` |
+| **Kostenstelle / Kostenträger** | Getrennte Stammdaten der Kostenrechnung (Tabellen `Kostenstellen` und `Kostentraeger`), je Belegart als Pflichtangabe einstellbar. | `IReceiptSpecificLogic.IsCostCenterNeeded` und `IsCostCarrierNeeded` |
+
+## 4. Artikel, Lager und Beschaffung
+
+| Begriff | Bedeutung | Fundstelle |
+|---|---|---|
+| **ARTIK** | Historische Artikelstammtabelle mit eindeutigem Index `ARTIK0`. | `SSMS_DB_SCHEMA.sql` |
+| **Aktionspreis** | Zeitlich befristeter Preis eines Distributors oder Herstellers mit `GueltigAb` und `GueltigBis`. | `docs/reference/receipts/actionprice-system.md` |
+| **Staffelpreis** | Mengenabhängiger Preis; im Import über `DistributorArticleStagePrices` abgebildet. | `ArticleImportBL.SetStagePrices` |
+| **Sonderpreis** | Kundenindividueller Preis; Grundlage des Artikelangebots im Web-Shop. | `README.md`, Abschnitt WebCart |
+| **Warengruppe** | Klassifikation der Artikel; Tabellen `WAREN` und `UNTERWAREN`. | `SSMS_DB_SCHEMA.sql` |
+| **Nebenlager (Secondary Stock)** | Zusätzliches Lager neben dem Hauptlager mit eigenem Bestand je Artikel. | `SecondStockArticleBL`, Tabelle `NebenlagerArtikel` |
+| **Umbuchung (Rebook)** | Bestandsverlagerung zwischen Lagern oder Lagerorten mit Protokolleintrag. | `SecondStockArticleBL.RebookStockArticle`, `StockBL.WriteStockRebookLog` |
+| **Seriennummer / Barcode** | Eindeutige Kennung eines Einzelstücks mit Zustand, Lagerbezug, Belegzuordnung und Historie. | `src/backend/Centron.BL/Warehousing/BarcodeBL.cs` |
+| **Inventur** | Zählvorgang je Lager mit Abschluss je Lager und je Inventur; Zustände unter anderem `Closed` und `ClosedWithoutBC`. | `InventoryNewBL` |
+| **Kommissionierung** | Bereitstellung der Auftragsmengen im Lager mit Mengenrückmeldung an den Beleg, auch als Teilkommissionierung. | `ReceiptBL.UpdateReceiptQuantityPicked` |
+| **EDI** | Elektronischer Belegaustausch mit Distributoren über FTP, FTPS oder SFTP; unterstützt werden unter anderem ALSO, ALSO CH, Alltron, Herweck, Komsa und OpenTrans 2.1. | `docs/reference/edi/edi-architecture.md` |
+| **Distributor** | Großhändler, von dem Artikel- und Preisdaten sowie Belege bezogen werden. | `ArticleImportBL`, `SupplierEdiBL` |
+| **TradePool** | Überbetrieblicher Artikelpool, getrennt vom eigenen Artikelstamm geführt. | `src/backend/Centron.BL/TradePool/` |
+| **Bestellvorschlagsliste** | Aus Bedarf, Bestand und Einstellungen abgeleitete Vorschläge für Lieferantenbestellungen. | `OrderSuggestionListBL` |
+| **WE-Kalkulation** | Kalkulation der Einstandskosten beim Wareneingang, geführt als Lieferanten-Rechnung. | Einstellungsseite „WE-Kalkulation (Lieferanten-Rechnung)" |
+
+## 5. Service und Kundenbeziehung
+
+| Begriff | Bedeutung | Fundstelle |
+|---|---|---|
+| **Helpdesk / Ticket** | Serviceanfrage mit Typ, Kategorie, Priorität, Status, Bearbeitern und Historie; Tabelle `hlpdsk_requests`. | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs` |
+| **Helpdesk-Timer** | Erfasste Arbeitszeit am Ticket, unterschieden in berechenbar und nicht berechenbar (`Calculable`); Tabelle `hlpdsk_timer`. | `src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs` |
+| **IsAssignedToAsset** | Merkmal einer Ticketzeit, das anzeigt, dass sie bereits einem Beleg zugewiesen wurde; solche Zeiten sind nicht löschbar. | `HelpdeskTimerBL.DeleteHelpdeskTimer` |
+| **C-FLOW / Ticketprozessvorlage** | Vorlage für wiederkehrende Serviceabläufe mit Schritten und Bindungen; kundenbezogen zuordenbar. | `CentronRights.md`, Abschnitt 17; `ProcessBL` |
+| **Checkliste** | Vorlagenbasierte Punkteliste am Ticket mit eigenem Änderungsprotokoll und Bearbeiter je Punkt. | `src/backend/Centron.BL/CheckListArea/` |
+| **Erwartetes Event** | Je Konto definiertes Ereignis mit Protokoll über das Eintreffen; ausbleibende Ereignisse erscheinen in der Auswertung. | `ExpectedEventsBL` |
+| **Eskalation** | Regelbasierte Meldung überfälliger Vorgänge an definierte Empfängerrollen. | `src/backend/Centron.BL/Sales/Support/Escalation/` |
+| **RMA** | Rücksende- und Reparaturvorgang; je Ticket genau ein RMA-Vorgang, getrennt in Rücksendung zum Lieferanten (`SendBack`) und Rückgabe an den Kunden (`SendForth`). | `src/backend/Centron.BL/CustomerArea/RmaBL.cs` |
+| **8D-Report** | Strukturierter Qualitätsbericht in acht Disziplinen; Tabellen `hlpdsk_8DReport` und `hlpdsk_8DReportTexte`. | `SSMS_DB_SCHEMA.sql` |
+| **SelfCare-Formular** | Vom Kunden ausfüllbares Formular, aus dem nach hinterlegter Ticketvorlage ein Ticket und Folgeaktionen entstehen. | `SelfCareWebserviceBL` |
+| **Stammblatt (MasterDataList)** | Geräteakte beim Kunden mit Seriennummer und Positionen, überwiegend für Druck- und Kopiersysteme. | `src/backend/Centron.Entities/Entities/Sales/Receipts/MasterDataLists/` |
+| **Konto-Gerät (AccountDevice)** | Gerät am Kundenkonto mit eigenem Protokoll und Ticketzuordnung; zweite Datenhaltung neben dem Stammblatt. | `src/backend/Centron.BL/Devices/AccountDeviceBL.cs` |
+| **AssetManagement / DocuBoard** | Technisches Inventar der Kundensysteme mit Anwendungen, Diensten, Patchständen, Abhängigkeiten und SNMP-Prüfungen; dritte Datenhaltung für Geräte. | `SSMS_DB_SCHEMA.sql`, Tabellen `AssetManagement*` |
+| **MSP** | Managed Service Provider; Sammlung und Abgleich der beim Hersteller gebuchten Lizenzen mit den vertraglich vereinbarten Mengen. | `src/backend/Centron.Gateway/MspCollector/` |
+| **RMM (Riverbird)** | Externes Monitoringsystem, das Nutzungsmengen für die verbrauchsabhängige Vertragsabrechnung liefert. | `src/backend/Centron.BL/RiverDivo/RiverConnectionBL.cs` |
+| **Konto (Account)** | Geschäftspartner mit einer oder mehreren Rollen (Kunde, Lieferant, weitere Kontoarten); Zielstruktur gegenüber den Alttabellen `Kunden` und `Kreditor`. | `SSMS_DB_SCHEMA.sql`, Tabellen `Accounts`, `AccountTypeToAccounts` |
+| **Aktivität (AccountActivity)** | Dokumentierter Kundenkontakt mit Bezug zu Ansprechpartner, Kampagne, Aufgabe, Dokument und Beleg sowie einer Bewertung von 0 bis 5. | `SSMS_DB_SCHEMA.sql`, Constraint `CK_AccountActivities_Rating` |
+
+## 6. Organisation, Rechte und Lizenzen
+
+| Begriff | Bedeutung | Fundstelle |
+|---|---|---|
+| **Mandant** | Oberste organisatorische Einheit; trägt Nummernkreise und Bankverbindungen. | `MandatorBL`, `NumberGroupBL` |
+| **Filiale (Branch)** | Untergliederung des Mandanten; an Beleg, Mitarbeiter, Rechtegruppe und Lager geführt. Eine fehlende Filialangabe gilt als Standardfiliale. | `ReceiptBL.CanUserCreateReceiptsInBranch` |
+| **Sichbenu** | Tabelle der Benutzerkonten mit Kennwort, Sperrzeitraum, Anmeldeverfahren, Zwei-Faktor-Angaben und letzten Anmeldedaten. | `SSMS_DB_SCHEMA.sql` |
+| **Sichrech / Sichgrup / Sichmemb / Sichtrus** | Tabellen des Rechtemodells: Recht, Gruppe, Gruppenmitgliedschaft, Gruppen-Recht-Zuordnung. | `SSMS_DB_SCHEMA.sql`; `AppRightsBL.CheckRightsFromUser` |
+| **Recht (I3D)** | Nummerisch identifizierte Berechtigung mit Elternverweis (`OwnerRecht`), Kinderzähler und Veraltungskennzeichen; .NET-Rechte beginnen bei 20800000. | `UserRightsConst.cs` |
+| **Einschränkendes Recht (restricting right)** | Recht, das den Datenzugriff verengt statt ihn zu gewähren, z. B. „nur eigene" oder „nur eigene Filiale". | `CentronRights.md` |
+| **Rechtegruppe** | Träger der Rechtevergabe; Benutzer erhalten Rechte ausschließlich über Gruppenmitgliedschaft. | `AppRightsBL` |
+| **Administratorgruppe** | Gruppe mit der Bezeichnung „Administratoren" bzw. der Kennung 6; nicht löschbar, nur eine festgelegte Rechtemenge ist an ihr änderbar. | `AppRightsBL.DeleteRightGroup`, `GetAssignableAdminRightI3Ds` |
+| **Lizenz-GUID** | Kennung eines lizenzierbaren Merkmals oder einer Anwendung; kann Anzahl, Ablaufdatum und Höchstversion tragen. | `docs/reference/security/licensing-system.md`; `LicenseGuids.cs` |
+| **ApplicationKind** | Anwendungsart, die sich am Web-Service anmelden darf; trägt Lizenz-GUID, Sitzungsdauer, Lizenzverbrauchsart sowie erforderliches oder ausschließendes Recht. | `src/backend/Centron.Interfaces/Administration/Logins/ApplicationKind.cs` |
+| **Verbindungsticket (ConnectionTicket)** | Sitzungsnachweis mit Ablaufzeit; Standardgültigkeit 30 Minuten, für Monitoringkonnektoren 5 Minuten, für Tagesanwendungen 1.440 Minuten. | `src/backend/Centron.BL/Administration/Logins/TicketBL.cs` |
+| **Zugriffstoken (Access Token)** | Persönlicher API-Schlüssel; 48 Zeichen, nur als SHA-256-Hash gespeichert, mit Ablauf, Sperre und Nutzungsprotokoll. | `src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs` |
+| **Web-Konto (WebAccount)** | Kundenzugang mit eigenem Rechtekatalog (`WebAccountRightsConst`), getrennt vom Mitarbeiterkonto. | `AppRightsBL.CheckWebRightsFromUser`; `WebAccountBL` |
+| **Zusatzfeld (Custom Property)** | Kundenindividuell definiertes Feld je Modul mit Datentyp; der Datentyp `EncryptedText` wird verschlüsselt abgelegt. | `ModuleCustomPropertyBL`; `PasswordManagerBL` |
+| **Textbaustein** | Wiederverwendbarer Textblock; Anrede und Grußformel werden beim Belegneuanlegen eingesetzt. | `src/backend/Centron.BL/TextModuleArea/` |
+| **DSGVO-Löschung** | Anonymisierung eines personenbezogenen Datensatzes mit dem Kennzeichnungstext „DSGVO: Auf Anfrage gelöscht." samt Bearbeiter und Zeitpunkt. | `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs` |
+
+## 7. Anwendungen, Dienste und Architekturbegriffe
+
+| Begriff | Bedeutung | Fundstelle |
+|---|---|---|
+| **c-entron.NET** | Windows-Client (WPF) mit vollem Funktionsumfang. | `src/centron/Centron.WPF.UI/` |
+| **c-entron Web-Service** | Serverdienst mit Fachlogik, REST-Schnittstellen, Echtzeitdiensten und Hintergrunddiensten. | `src/webservice/Centron.Host/` |
+| **c-entron Nexus** | Blazor-Server-Portal mit ServiceBoard (Mitarbeiter) und WebCart/Kundenportal (Endkunden). | `src/nexus/CentronNexus/` |
+| **ServiceBoard** | Webbasierter Arbeitsplatz für Servicemitarbeiter; je Benutzer lizenziert, über ein Sperrrecht entziehbar. | `ApplicationKind.ServiceBoard`; `src/nexus/CentronNexus/ServiceBoard/` |
+| **WebCart** | Web-Shop für Endkunden; das Artikelangebot ergibt sich aus den Sonderpreisen des Kunden. | `README.md`; `src/nexus/CentronNexus/WebCart/` |
+| **MyDay / Mein Tag** | Tagesübersicht je Mitarbeiter aus Terminen, Zeiten und Aufgaben, ergänzt um Importe aus Fremdsystemen. | `src/backend/Centron.BL/MyDay/` |
+| **Data Updater / Massenupdate** | Werkzeug für massenhafte Preis- und Datenänderungen über gespeicherte Vorlagen mit vorheriger Anzeige der betroffenen Datensätze. | `src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs` |
+| **ILogic / BLLogic / WSLogic** | Namenskonvention der clientseitigen Datenzugriffsschicht: Schnittstelle, Umsetzung mit direktem Datenbankzugriff, Umsetzung über den Web-Service. | `docs/getting-started/general-structure.md` |
+| **ClassContainer** | Dienstbehälter des Clients, der zur Laufzeit die passende Umsetzung einer Logikschnittstelle bereitstellt. | ebenda |
+| **Result / Result<T>** | Einheitliches Ergebnisobjekt mit Status (`Success`, `Warning`, `Error`), Meldung und optionalem Fehlercode aus `DefaultMessageCodes`. | `docs/reference/architecture/results-and-responses.md` |
+| **DAOSession** | Sitzungsobjekt des Datenzugriffs; bündelt NHibernate-Sitzung, generischen Zugriff, benannte Abfragen und Zwischenspeicher. | `src/backend/Centron.DAO/DAOSession.cs` |
+| **GenericDAO** | Generischer Datenzugriff je Entitätstyp mit `GetById`, `GetEntityList`, `SaveOrUpdate` und `Delete`. | `src/backend/Centron.DAO/GenericDAO.cs` |
+| **Benannte Abfrage (NamedQuery)** | Vordefinierte SQL-Abfrage aus `NamedQueryPool.xml`, aufgerufen über `NamedQueryEnums`. | `src/backend/Centron.DAO/NamedQueries/` |
+| **Skriptnummer / DBUpdate** | Fortlaufende Nummer einer Schemamigration; ausgeführte Nummern stehen in der Tabelle `DBUpdate` und werden nicht erneut ausgeführt. | `src/backend/Centron.BL/Administration/Scripts/ScriptEngineBL.cs` |
+| **ApplicationSettings / Stammdat** | Aktuelle und historische Einstellungstabelle; neue Einstellungen gehören ausschließlich in `ApplicationSettings`. | `docs/guides/development/settings-management.md` |
+| **ManagedBackgroundService** | Basisklasse aller Hintergrunddienste; gibt Startverzögerung, Schaltbarkeit über die Datenbank, Startzeitmeldung und Fehlerrücklauf vor. | `src/webservice/Centron.Host/AspNetCore/HostedServices/ManagedBackgroundService.cs` |
+| **DataQualityService** | Stündlich laufender Dienst, der Dateninkonsistenzen bereinigt; Aufgabenmethoden tragen das Präfix `DataQuality`. | `docs/Background Service/DataQualityService.md` |
+| **DeveloperSecurity** | Schutzmechanismus, der in Nicht-Release-Ständen alle externen E-Mail-Empfänger durch eine feste Ersatzadresse ersetzt. | `src/backend/Centron.Common/DeveloperSecurity.cs` |

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-a8f5/Ergebnisse/Hypothesen.md

@@ -0,0 +1,292 @@
+# Hypothesen
+
+Diese Datei enthält **genau** die Anforderungen, die in `StRS.md`, `SyRS.md` oder `SwRS.md` inline mit `[HYPOTHESE]` gekennzeichnet sind und deren Feld `Status` mit `HYPOTHESE` beginnt. Sie enthält keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung stehen in der Selbstbewertung des `Analysebericht.md` (Abschnitt 5.5).
+
+**Anzahl:** 15 von 379 Anforderungen (4.0 %).
+
+## 1. Übersicht
+
+| ID | Ebene | Titel | Offene Frage in einem Satz |
+|---|---|---|---|
+| StRS-034 | StRS | Verbrauchsabhängige Vertragsabrechnung aus externen Nutzungsdaten | Bricht die Vertragsabrechnung tatsächlich vollständig ab, wenn der RMM-Dienst keine Nutzungsdaten liefert? |
+| StRS-035 | StRS | Klickabrechnung für Druck- und Kopiersysteme | Wie genau wird die Zählerdifferenz gebildet und als Rechnungsposition eingestellt? |
+| StRS-048 | StRS | Belege und Belegbilder an DATEV übertragen | Welche Daten werden beim DATEV-Belegtransfer übertragen und wie wird der Erfolg quittiert? |
+| StRS-093 | StRS | Bestellungen des Kunden über den Web-Shop | Aus welcher Quelle bezieht der Web-Shop die für einen Kunden sichtbaren Artikel? |
+| SyRS-019 | SyRS | Lieferantenverträge über eigene Logik- und Web-Service-Kette | Erfüllen BLAccountContractsLogic und WSAccountContractsLogic tatsächlich dieselbe Signatur? |
+| SyRS-023 | SyRS | Umfragen mit Seitenstruktur und Anhängen | Wie sind Umfrageseiten und Anhänge im Datenmodell abgebildet? |
+| SyRS-026 | SyRS | Belegversionierung über strukturgleiche Versionstabellen | Wie bildet die Versionierung zur Laufzeit die Feldliste und wie verhält sie sich bei fehlenden Spalten? |
+| SyRS-039 | SyRS | Abbruch der Rechnungserzeugung bei unvollständigen Nutzungsdaten | An welcher Codestelle wird die Rechnungserzeugung bei fehlenden Nutzungsdaten abgebrochen? |
+| SyRS-056 | SyRS | EDI-Dateien werden nur einmal verarbeitet | Wie ermittelt der EDI-Import die bereits verarbeiteten Dateien? |
+| SyRS-057 | SyRS | EDI-Protokolle werden befristet aufbewahrt | Wo ist die Aufbewahrungsfrist von 185 Tagen für EDI-Protokolle im Code hinterlegt? |
+| SwRS-012 | SwRS | Auflösung der Datenzugriffsschicht über einen Dienstbehälter | Nach welcher Regel registriert der ClassContainer die BL- und WS-Umsetzungen? |
+| SwRS-020 | SwRS | Lieferantenverträge über die dreiteilige Zugriffskette | Wie sind die drei Klassen der Zugriffskette für Lieferantenverträge tatsächlich ausgeprägt? |
+| SwRS-024 | SwRS | Umfragen mit eigener Seiten- und Einstellungsstruktur im Client | Welche Entitäten bilden Umfrage, Seite, Frage und Anhang ab? |
+| SwRS-027 | SwRS | Versionstabellen mit dynamisch gebildeter Feldliste | Wie erzeugt DoGetFieldList die Feldliste und welche Spalten schließt sie aus? |
+| SwRS-055 | SwRS | Lieferantenbelege mit eigenen Fachlogikordnern und Speicherrepositories | Welche Felder überführen die SaveReceipt-Repositories in die temporären Alt-Entitäten? |
+
+## 2. Einzelaufstellung
+
+### StRS-034 — Verbrauchsabhängige Vertragsabrechnung aus externen Nutzungsdaten
+
+- **Ebene:** StRS  
+- **Typ:** Schnittstelle
+
+**Belegte Beobachtung (Fakt):** Bei der Rechnungserzeugung ruft die Vertragsabrechnung RiverConnectionBL.GetContractBillingAmounts(von, bis, kundenI3D, rmmArticleReferences) auf und setzt die ermittelten Mengen an der Position des Platzhalters @@RMMArtikel@@ ein. Ist der externe Dienst nicht erreichbar und werden RMM-Artikel erwartet, wird eine RMMServiceUnavailableException geworfen und die Rechnungserzeugung abgebrochen.
+
+**Vermutete Aussage:** [HYPOTHESE] Das System soll Nutzungsmengen aus einem externen Monitoringsystem übernehmen, daraus Rechnungspositionen bilden und die Rechnungserzeugung abbrechen, wenn die Nutzungsdaten nicht vollständig vorliegen.
+
+**Vorliegende Belege:**
+
+- `SEKUNDÄR` docs/reference/receipts/Contract-Billing-RMM-Article-Logic.md, Abschnitt External Service Unavailability mit dem beschriebenen Abbruch über RMMServiceUnavailableException
+- `SEKUNDÄR` src/backend/Centron.BL/RiverDivo/RiverConnectionBL.cs
+
+**Fehlende Information zur Bestätigung:** Die durchsetzende Codestelle CheckRMMArticle wurde im Arbeitsverzeichnis nicht geöffnet; zur Bestätigung fehlt die Einsicht in die Methode, die RMMServiceUnavailableException auslöst.
+
+**Offene Frage:** Bricht die Vertragsabrechnung tatsächlich vollständig ab, wenn der RMM-Dienst keine Nutzungsdaten liefert?
+
+### StRS-035 — Klickabrechnung für Druck- und Kopiersysteme
+
+- **Ebene:** StRS  
+- **Typ:** funktional
+
+**Belegte Beobachtung (Fakt):** Es existieren ein Modul DeviceClickCounterAppModuleController unter dem Kommentar Klick-Zählerverwaltung, eine Einstellungsseite ClickBillingSettingsController mit Caption Klickabrechnung sowie die Entitäten MasterDataListCompact und MasterDataListItemsCompact im Ordner Sales/CustomerAssets/Contracts/ClickContracts.
+
+**Vermutete Aussage:** [HYPOTHESE] Das System soll Zählerstände von Druck- und Kopiersystemen erfassen und die Differenz zum Vorzeitraum als abrechenbare Menge in die Vertragsabrechnung übernehmen.
+
+**Vorliegende Belege:**
+
+- `SEKUNDÄR` src/centron/Centron.WPF.UI/Modules/Finances/Contracts/Settings/ClickBilling/ClickBillingSettingsController.cs
+- `SEKUNDÄR` src/backend/Centron.Entities/Entities/Sales/CustomerAssets/Contracts/ClickContracts/
+- `SEKUNDÄR` src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung von DeviceClickCounterAppModuleController
+
+**Fehlende Information zur Bestätigung:** Es fehlt die Einsicht in die Codestelle, die die Zählerdifferenz bildet und als Rechnungsposition einstellt; belegt sind bisher nur Modul, Einstellungsseite und Entitäten.
+
+**Offene Frage:** Wie genau wird die Zählerdifferenz gebildet und als Rechnungsposition eingestellt?
+
+### StRS-048 — Belege und Belegbilder an DATEV übertragen
+
+- **Ebene:** StRS  
+- **Typ:** Schnittstelle
+
+**Belegte Beobachtung (Fakt):** Es existieren das Client-Modul DatevOnlineAppModuleController unter dem Kommentar Datev Belegtransfer im Ordner Modules/DataExchange/DatevOnline2020 sowie eine Einstellungsseite DatevOnlineSettingsController.
+
+**Vermutete Aussage:** [HYPOTHESE] Das System soll Belege einschließlich Belegbild an DATEV übertragen, damit die Buchhaltung ohne Medienbruch arbeiten kann.
+
+**Vorliegende Belege:**
+
+- `SEKUNDÄR` src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung von DatevOnlineAppModuleController unter dem Kommentar Datev Belegtransfer
+- `SEKUNDÄR` src/centron/Centron.WPF.UI/Modules/DataExchange/BookKeeping/Settings/DatevOnline/DatevOnlineSettingsController.cs
+
+**Fehlende Information zur Bestätigung:** Es fehlt die Einsicht in die übertragende Codestelle des DATEV-Belegtransfers; belegt sind bisher nur Modulregistrierung und Einstellungsseite.
+
+**Offene Frage:** Welche Daten werden beim DATEV-Belegtransfer übertragen und wie wird der Erfolg quittiert?
+
+### StRS-093 — Bestellungen des Kunden über den Web-Shop
+
+- **Ebene:** StRS  
+- **Typ:** funktional
+
+**Belegte Beobachtung (Fakt):** Der Nexus-Bereich WebCart umfasst WebCartShopPage, WebCartCartPage, WebCartHomePage, WebCartAdminPage sowie Kundenportalseiten für Belege, Verträge, Tickets und Dokumente. Die Anwendungsart WebCart trägt eine eigene Lizenz-GUID und die Ablaufart ExpirationKind.FromSettings. Eine Einstellungsseite WebCartSettingsAppModuleController mit Caption E-mails existiert im Client.
+
+**Vermutete Aussage:** [HYPOTHESE] Das System soll Endkunden einen Web-Shop bereitstellen, dessen Artikelangebot sich aus den für den Kunden hinterlegten Sonderpreisen ergibt, und aus dem Warenkorb einen Beleg erzeugen.
+
+**Vorliegende Belege:**
+
+- `PRIMÄR` src/backend/Centron.Interfaces/Administration/Logins/ApplicationKind.cs, Definition WebCart mit eigener Lizenz-GUID und ExpirationKind.FromSettings (Zeile 50)
+- `SEKUNDÄR` README.md, Abschnitt Contributing / WebCart mit dem Hinweis, dass die verfügbaren Artikel aus den Sonderpreisen des Kunden stammen und der Zugang über ein Web-Konto erfolgt
+- `SEKUNDÄR` src/nexus/CentronNexus/WebCart/WebCartShopPage.razor und WebCartCartPage.razor
+
+**Fehlende Information zur Bestätigung:** Die Regel, dass das Artikelangebot des Shops aus den Kundensonderpreisen stammt, ist nur in der README beschrieben; es fehlt die Codestelle, die die Artikelliste des Shops ermittelt.
+
+**Offene Frage:** Aus welcher Quelle bezieht der Web-Shop die für einen Kunden sichtbaren Artikel?
+
+### SyRS-019 — Lieferantenverträge über eigene Logik- und Web-Service-Kette
+
+- **Ebene:** SyRS  
+- **Typ:** Schnittstelle
+
+**Belegte Beobachtung (Fakt):** Für Lieferantenverträge besteht die vollständige Kette IAccountContractsLogic, BLAccountContractsLogic (Zugriff über BLSession und AccountContractWebServiceBL) und WSAccountContractsLogic (Zugriff über ICentronWebServiceConnection). Der Aufruf erfolgt im Client über ClassContainer.Instance.WithInstance((IAccountContractsLogic logic) => ...).
+
+**Vermutete Aussage:** [HYPOTHESE] Das System soll Lieferantenverträge über eine eigene Logikschnittstelle bereitstellen, die sowohl den direkten Datenbankzugriff als auch den Zugriff über den Web-Service bedient.
+
+**Vorliegende Belege:**
+
+- `SEKUNDÄR` docs/getting-started/general-structure.md, vollständiges Codebeispiel mit IAccountContractsLogic, BLAccountContractsLogic und WSAccountContractsLogic
+
+**Fehlende Information zur Bestätigung:** Die Klassen BLAccountContractsLogic und WSAccountContractsLogic wurden nicht geöffnet; belegt ist nur das Codebeispiel der Entwicklerdokumentation.
+
+**Offene Frage:** Erfüllen BLAccountContractsLogic und WSAccountContractsLogic tatsächlich dieselbe Signatur?
+
+### SyRS-023 — Umfragen mit Seitenstruktur und Anhängen
+
+- **Ebene:** SyRS  
+- **Typ:** funktional
+
+**Belegte Beobachtung (Fakt):** Der Modulordner Modules/Survey enthält die Unterordner Pages und SurveySettings; die Einstellungsseite trägt die Beschriftung Umfragen Anhänge.
+
+**Vermutete Aussage:** [HYPOTHESE] Das System soll Umfragen in Seiten gliedern und je Umfrage Anhänge zulassen.
+
+**Vorliegende Belege:**
+
+- `SEKUNDÄR` src/centron/Centron.WPF.UI/Modules/Survey/Pages/ und src/centron/Centron.WPF.UI/Modules/Survey/SurveySettings/SurveySettingsController.cs
+
+**Fehlende Information zur Bestätigung:** Es fehlt die Einsicht in die Umfrageentitäten und deren Seitenzuordnung; belegt sind nur Ordnernamen und die Einstellungsseite.
+
+**Offene Frage:** Wie sind Umfrageseiten und Anhänge im Datenmodell abgebildet?
+
+### SyRS-026 — Belegversionierung über strukturgleiche Versionstabellen
+
+- **Ebene:** SyRS  
+- **Typ:** Daten
+
+**Belegte Beobachtung (Fakt):** Zu jeder Kopf- und Positionstabelle existiert eine gleichnamige Versionstabelle mit dem Zusatz Versions. Diese ist eine 1:1-Kopie ohne I3D, ergänzt um OriginalI3D und bei Positionstabellen um KopfVersionsI3D. Die Feldliste wird zur Laufzeit über DoGetFieldList() gebildet; fehlt eine Spalte in der Versionstabelle, schlägt das Einfügen fehl.
+
+**Vermutete Aussage:** [HYPOTHESE] Das System soll Belegversionen durch vollständiges Kopieren von Kopf und Positionen in strukturgleiche Versionstabellen bilden.
+
+**Vorliegende Belege:**
+
+- `SEKUNDÄR` docs/reference/receipts/receipts-backend-architecture.md, Abschnitte Version Tables und Adding New Columns mit dem ausdrücklichen Hinweis auf Laufzeitfehler bei fehlenden Spalten sowie den INSERT-Mustern
+- `PRIMÄR` src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Methode CreateNewVersion<T>
+
+**Fehlende Information zur Bestätigung:** Die kopierende Codestelle AssetHeadDAO.SaveAssetVersion wurde nicht geöffnet; belegt ist nur die Entwicklerdokumentation.
+
+**Offene Frage:** Wie bildet die Versionierung zur Laufzeit die Feldliste und wie verhält sie sich bei fehlenden Spalten?
+
+### SyRS-039 — Abbruch der Rechnungserzeugung bei unvollständigen Nutzungsdaten
+
+- **Ebene:** SyRS  
+- **Typ:** funktional
+
+**Belegte Beobachtung (Fakt):** Bei der Rechnungserzeugung wird CheckRMMArticle aufgerufen. Liefert RiverConnectionBL.GetContractBillingAmounts einen Fehlerstatus und werden RMM-Artikel erwartet, wird eine RMMServiceUnavailableException geworfen und die Erzeugung abgebrochen. Die Positionierung der erzeugten Positionen erfolgt am Platzhalter @@RMMArtikel@@, ersatzweise an vorletzter Stelle.
+
+**Vermutete Aussage:** [HYPOTHESE] Das System soll keine Rechnung erzeugen, wenn erwartete verbrauchsabhängige Nutzungsdaten nicht vollständig abgerufen werden können.
+
+**Vorliegende Belege:**
+
+- `SEKUNDÄR` docs/reference/receipts/Contract-Billing-RMM-Article-Logic.md, Abschnitte RMM Article Detection, Usage Data Retrieval und Error Handling for Service Unavailability mit den zitierten Codeausschnitten
+
+**Fehlende Information zur Bestätigung:** Die Codestelle CheckRMMArticle mit dem Abbruch ueber RMMServiceUnavailableException wurde nicht geöffnet; belegt ist nur das Codezitat der Entwicklerdokumentation.
+
+**Offene Frage:** An welcher Codestelle wird die Rechnungserzeugung bei fehlenden Nutzungsdaten abgebrochen?
+
+### SyRS-056 — EDI-Dateien werden nur einmal verarbeitet
+
+- **Ebene:** SyRS  
+- **Typ:** funktional
+
+**Belegte Beobachtung (Fakt):** Der Downloadvorgang ermittelt zunächst über UsedFiles(config) die bereits verarbeiteten Dateien und überspringt sie beim Durchlauf der Serverdateien; zusätzlich kann eine erwartete Datei vorgegeben werden, sodass abweichende Dateien übersprungen werden. Der Zugriff erfolgt je nach Konfiguration über Ftp_DownloadAsync oder sFtp_DownloadAsync.
+
+**Vermutete Aussage:** [HYPOTHESE] Das System soll bereits verarbeitete EDI-Dateien erkennen und nicht erneut einlesen sowie FTP, FTPS und SFTP als Transportwege unterstützen.
+
+**Vorliegende Belege:**
+
+- `SEKUNDÄR` docs/reference/edi/edi-import-rules.md, Abschnitt File Filtering mit dem zitierten Code zu UsedFiles(config) und der Übersprungbedingung
+- `PRIMÄR` src/backend/Centron.BL/EDI/SupplierEDI/SupplierEdiBL.cs
+
+**Fehlende Information zur Bestätigung:** Die Methode UsedFiles und die Filterschleife in SupplierEdiBL wurden nicht geöffnet; belegt ist nur das Codezitat der Entwicklerdokumentation.
+
+**Offene Frage:** Wie ermittelt der EDI-Import die bereits verarbeiteten Dateien?
+
+### SyRS-057 — EDI-Protokolle werden befristet aufbewahrt
+
+- **Ebene:** SyRS  
+- **Typ:** nicht-funktional
+
+**Belegte Beobachtung (Fakt):** Der EDI-Downloaddienst läuft alle 30 Minuten mit einer Minute Startverzögerung; Protokolleinträge älter als 185 Tage werden zwischen 00:00 und 02:00 Uhr gelöscht. Die Protokollierung erfolgt über EDILogBL.
+
+**Vermutete Aussage:** [HYPOTHESE] Das System soll EDI-Protokolleinträge für einen festgelegten Zeitraum aufbewahren und danach in einem verkehrsarmen Zeitfenster löschen.
+
+**Vorliegende Belege:**
+
+- `SEKUNDÄR` docs/reference/edi/edi-import-rules.md, Abschnitt Execution Frequency mit 30 Minuten Takt, 1 Minute Startverzögerung und Löschung nach 185 Tagen im Zeitfenster 00:00 bis 02:00
+- `PRIMÄR` src/webservice/Centron.Host/AspNetCore/HostedServices/EdiDownloadService.cs
+
+**Fehlende Information zur Bestätigung:** Die Codestelle, die die Aufbewahrungsfrist von 185 Tagen und das Zeitfenster umsetzt, wurde nicht geöffnet; belegt ist nur die Entwicklerdokumentation.
+
+**Offene Frage:** Wo ist die Aufbewahrungsfrist von 185 Tagen für EDI-Protokolle im Code hinterlegt?
+
+### SwRS-012 — Auflösung der Datenzugriffsschicht über einen Dienstbehälter
+
+- **Ebene:** SwRS  
+- **Typ:** Schnittstelle
+
+**Belegte Beobachtung (Fakt):** Der Client löst Datenzugriffe über ClassContainer.Instance.WithInstance((I<Modul>Logic logic) => logic.<Methode>(...)) auf und wertet das Ergebnis über ThrowIfError() aus. Die Registrierung erfolgt laut Dokumentation automatisch, wenn die Namenskonvention I*Logic, BL*Logic und WS*Logic eingehalten ist. Module deklarieren über SupportsConnectionTypes, welche Verbindungsarten sie unterstützen.
+
+**Vermutete Aussage:** [HYPOTHESE] Die Software soll die Auswahl zwischen direktem Datenbankzugriff und Web-Service-Zugriff über einen Dienstbehälter treffen, der die Umsetzung anhand der Namenskonvention zuordnet.
+
+**Vorliegende Belege:**
+
+- `SEKUNDÄR` docs/getting-started/general-structure.md, Abschnitte ClassContainer and ILogic Pattern und Connection Type Support mit dem Codebeispiel
+
+**Fehlende Information zur Bestätigung:** Die Registrierungsklasse des ClassContainer und die automatische Zuordnung nach Namenskonvention wurden nicht geöffnet; belegt ist nur die Entwicklerdokumentation.
+
+**Offene Frage:** Nach welcher Regel registriert der ClassContainer die BL- und WS-Umsetzungen?
+
+### SwRS-020 — Lieferantenverträge über die dreiteilige Zugriffskette
+
+- **Ebene:** SwRS  
+- **Typ:** Schnittstelle
+
+**Belegte Beobachtung (Fakt):** Die Dokumentation zeigt die vollständige Kette am Beispiel der Lieferantenverträge: IAccountContractsLogic mit Task<Result<IList<AccountContractDTO>>> GetAccountContracts(GetAccountContractsFilter) und Task<Result<AccountContractDTO>> SaveAccountContract(AccountContractDTO); BLAccountContractsLogic mit Task.Run und BLSession sowie session.GetBL<AccountContractWebServiceBL>(); WSAccountContractsLogic mit CallWebServiceMethodWithListResultAsync.
+
+**Vermutete Aussage:** [HYPOTHESE] Die Software soll je Modul eine asynchrone Logikschnittstelle mit Result-Rückgabe, eine datenbanknahe und eine dienstnahe Umsetzung bereitstellen.
+
+**Vorliegende Belege:**
+
+- `SEKUNDÄR` docs/getting-started/general-structure.md, vollständige Codebeispiele für IAccountContractsLogic, BLAccountContractsLogic und WSAccountContractsLogic
+
+**Fehlende Information zur Bestätigung:** Die Klassen der dreiteiligen Zugriffskette für Lieferantenvertraege wurden nicht geöffnet; belegt sind nur die Codebeispiele der Entwicklerdokumentation.
+
+**Offene Frage:** Wie sind die drei Klassen der Zugriffskette für Lieferantenverträge tatsächlich ausgeprägt?
+
+### SwRS-024 — Umfragen mit eigener Seiten- und Einstellungsstruktur im Client
+
+- **Ebene:** SwRS  
+- **Typ:** funktional
+
+**Belegte Beobachtung (Fakt):** Der Modulordner Modules/Survey gliedert sich in Pages und SurveySettings; die Einstellungsseite trägt die Beschriftung Umfragen Anhänge.
+
+**Vermutete Aussage:** [HYPOTHESE] Die Software soll Umfrageseiten und Umfrageeinstellungen als getrennte Bestandteile des Moduls führen.
+
+**Vorliegende Belege:**
+
+- `SEKUNDÄR` src/centron/Centron.WPF.UI/Modules/Survey/Pages/ und .../SurveySettings/
+
+**Fehlende Information zur Bestätigung:** Es fehlt die Einsicht in die Umfrageentitäten; belegt ist nur die Ordnerstruktur des Moduls.
+
+**Offene Frage:** Welche Entitäten bilden Umfrage, Seite, Frage und Anhang ab?
+
+### SwRS-027 — Versionstabellen mit dynamisch gebildeter Feldliste
+
+- **Ebene:** SwRS  
+- **Typ:** Daten
+
+**Belegte Beobachtung (Fakt):** Die Feldliste für das Einfügen in die Versionstabelle wird zur Laufzeit über DoGetFieldList() gebildet. Fehlt in der Versionstabelle eine Spalte der Ursprungstabelle, schlägt das Einfügen zur Laufzeit fehl. Die Entwicklerdokumentation führt dazu eine zehnstufige Prüfliste für das Hinzufügen neuer Belegspalten und weist ausdrücklich darauf hin, dass der Speicherweg über SaveReceipt*Repository und temporäre Alt-Entitäten läuft und nicht über die moderne Entitätszuordnung.
+
+**Vermutete Aussage:** [HYPOTHESE] Die Software soll die Feldliste der Belegversionierung aus dem Schema ableiten und die Strukturgleichheit von Ursprungs- und Versionstabelle voraussetzen.
+
+**Vorliegende Belege:**
+
+- `SEKUNDÄR` docs/reference/receipts/receipts-backend-architecture.md, Abschnitte Adding New Columns - Complete Checklist mit zehn Schritten sowie Critical Warning und Critical Save Warning
+
+**Fehlende Information zur Bestätigung:** Die Methode DoGetFieldList und die SaveReceipt-Repositories wurden nicht geöffnet; belegt ist nur die Entwicklerdokumentation.
+
+**Offene Frage:** Wie erzeugt DoGetFieldList die Feldliste und welche Spalten schließt sie aus?
+
+### SwRS-055 — Lieferantenbelege mit eigenen Fachlogikordnern und Speicherrepositories
+
+- **Ebene:** SwRS  
+- **Typ:** Daten
+
+**Belegte Beobachtung (Fakt):** Unter Sales/Receipts bestehen die Ordner SupplierOrders, SupplierDeliveryLists, SupplierInvoices, SupplierCreditVouchers und SupplierReceiptDocuments. Laut Entwicklerdokumentation existieren je Belegart eigene Speicherrepositories, die die modernen Entitäten in temporäre Alt-Entitäten überführen; die Übernahme neuer Felder erfolgt in SynchronizeReceiptData (Kopf) und SynchronizeReceiptItemData (Position).
+
+**Vermutete Aussage:** [HYPOTHESE] Die Software soll je Belegart ein eigenes Speicherrepository führen, das die Überführung in die Persistenzstruktur an genau zwei benannten Stellen vornimmt.
+
+**Vorliegende Belege:**
+
+- `SEKUNDÄR` docs/reference/receipts/receipts-backend-architecture.md, Abschnitt Repository Pattern mit den Methodennamen SynchronizeReceiptData und SynchronizeReceiptItemData und dem Hinweis, dass AutoMapper und die moderne Zuordnung auf diesem Weg nicht greifen
+
+**Fehlende Information zur Bestätigung:** Die SaveReceipt-Repositories fuer Lieferantenbelege wurden nicht geöffnet; belegt ist nur die Entwicklerdokumentation.
+
+**Offene Frage:** Welche Felder überführen die SaveReceipt-Repositories in die temporären Alt-Entitäten?
+

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-a8f5/Ergebnisse/Traceability.md

@@ -0,0 +1,270 @@
+# Traceability — konsolidierte Verfolgbarkeitstabelle
+
+**Erzeugt aus:** den Feldern `Tracelinks` der Anforderungen in `StRS.md`, `SyRS.md` und `SwRS.md`.
+
+## 1. Lesehinweise
+
+- Die Tabelle ist **beidseitig** aufgebaut: Sie entsteht aus den Vorwärtsverweisen der StRS- und SyRS-Anforderungen **und** aus den Rückwärtsverweisen der SyRS- und SwRS-Anforderungen. Ein Bezug gilt als bestehend, sobald er auf einer der beiden Seiten angegeben ist.
+- Ein Bindestrich bedeutet, dass auf dieser Ebene kein Bezug angegeben ist. Das ist zulässig, wenn eine Anforderung nur auf zwei Ebenen ausgeprägt ist.
+- Die Spalte `Artefaktbeleg` enthält den ersten `PRIMÄR`-Beleg der Anforderung der jeweils rechtesten belegten Ebene; liegt kein `PRIMÄR`-Beleg vor, den ersten Beleg überhaupt.
+
+## 2. Kennzahlen
+
+- Zeilen der Tabelle: 249
+- StRS-Anforderungen: 100, davon mit mindestens einem SyRS-Bezug: 100
+- SyRS-Anforderungen: 130, davon mit mindestens einem StRS-Bezug: 130
+- SwRS-Anforderungen: 150, davon mit mindestens einem SyRS-Bezug: 150
+
+## 3. Tabelle
+
+| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
+|---|---|---|---|
+| StRS-001 | SyRS-001 | SwRS-001 | src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptBase.cs |
+| StRS-001 | SyRS-002 | SwRS-002 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Methoden CreateNewReceipt (Zeile 775), CopyReceipt (Zeile 1377 und 1383) und ForwardReceipt (Zeile 1548) |
+| StRS-002 | SyRS-003 | SwRS-003 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Aufruf BranchBL.IsBranchEqual(appUser.Employee.BranchI3D, receiptBranchI3D) in CanUserEditReceipt |
+| StRS-003 | SyRS-004 | SwRS-004 | src/backend/Centron.BL/Administration/Logins/UsersBL.cs, Zugriff LocalizedStrings.UsersBL_IsValidAppUserPassword_DasPasswortIstZuKurz |
+| StRS-004 | SyRS-005 | SwRS-005 | src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs, Schnittstelle ILicenseManager mit CheckLicense und GetLicenseCount |
+| StRS-004 | SyRS-005 | SwRS-080 | SSMS_DB_SCHEMA.sql, CREATE TABLE [dbo].[ConnectionTickets] und CREATE UNIQUE NONCLUSTERED INDEX [idx_ConnectionTickets_UniqueLogin] |
+| StRS-004 | SyRS-006 | SwRS-005 | src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs, Schnittstelle ILicenseManager mit CheckLicense und GetLicenseCount |
+| StRS-004 | SyRS-006 | SwRS-132 | src/backend/Centron.BL/VideoPortal/VideoPortalAssignmentBL.cs |
+| StRS-004 | SyRS-041 | SwRS-042 | src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Methoden GetRightsForModule und IsModuleAvailable<T> sowie die Verwendung von ModuleRegistrationItem.For<T> |
+| StRS-004 | SyRS-100 | SwRS-101 | src/backend/Centron.BL/MyDay/ mit MyDayBL.cs, MyDayNotificationsBL.cs, ReportConnections.cs und ReportRecord.cs |
+| StRS-004 | SyRS-114 | SwRS-114 | src/backend/Centron.BL/ArtificialIntelligence/ mit IApiClient.cs, ApiClientFactory.cs, IMessage.cs, AiHttpModelCatalogClient.cs und AiApiLinkValidator.cs |
+| StRS-004 | SyRS-124 | SwRS-123 | src/apis/ mit den acht Assemblies und ihren Unterordnern Parser, SoapTemplates und RequestTemplates |
+| StRS-004 | SyRS-124 | SwRS-124 | src/backend/Centron.Interfaces/Administration/Logins/ApplicationKind.cs mit den statischen schreibgeschützten Einträgen und ihren Kennungen |
+| StRS-004 | SyRS-124 | SwRS-135 | src/backend/Centron.BL/ExternalHelpdesk/ExternalHelpdeskConfigurationBL.cs und src/backend/Centron.BL/Sales/Support/ExternalHelpdeskConfigurationBL.cs |
+| StRS-004 | SyRS-124 | SwRS-136 | src/backend/Centron.BL/DataExchange/TelekomDive/TelekomDiveBL.cs, Methoden mit Listen und Filter |
+| StRS-004 | SyRS-124 | SwRS-137 | Centron.Api.docuFORM/IDocuFormApiClient.cs und DocuFormRestApiClient.cs |
+| StRS-004 | SyRS-124 | SwRS-138 | src/backend/Centron.BL/DataExchange/Connectors/ mit den fünf DocBee-Klassen und WebHookClient.cs |
+| StRS-004 | SyRS-130 | SwRS-130 | src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Abbruch bei rights.Status == ResultStatus.Error vor der Registrierung |
+| StRS-005 | SyRS-006 | SwRS-005 | src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs, Schnittstelle ILicenseManager mit CheckLicense und GetLicenseCount |
+| StRS-005 | SyRS-006 | SwRS-132 | src/backend/Centron.BL/VideoPortal/VideoPortalAssignmentBL.cs |
+| StRS-005 | SyRS-007 | SwRS-006 | src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Methode CheckRightsFromUser mit NamedQueryParameter("UserI3D", ...) und NamedQueryParameter("RightI3Ds", rights, NHibernateUtil.Int32, true) |
+| StRS-005 | SyRS-008 | SwRS-007 | SSMS_DB_SCHEMA.sql, CREATE TABLE [dbo].[Sichrech] mit I3D als [int] NOT NULL ohne IDENTITY sowie OwnerRecht, NumChildren und Obsolete |
+| StRS-006 | SyRS-009 | SwRS-008 | src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, Rückgaben ShowHelpdeskRight.OnlyOwn, .OnlyOwnBranch, .All und .None |
+| StRS-006 | SyRS-071 | SwRS-071 | src/backend/Centron.BL/TicketProjects/TicketProjectBL.cs |
+| StRS-007 | SyRS-010 | SwRS-009 | src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Erzeugung von AppRightLog mit Kind, Object, Description und CreatedVersion |
+| StRS-007 | SyRS-011 | SwRS-010 | src/backend/Centron.DAO/ChangeTracking/ChangeTrackingEventListener.cs |
+| StRS-007 | SyRS-011 | SwRS-143 | src/backend/Centron.DAO/ mit DAOSession.cs, GenericDAO.cs, AdvancedSession.cs und dem Ordner NamedQueries |
+| StRS-007 | SyRS-011 | SwRS-144 | src/backend/Centron.Entities/Entities/ mit 1.179 Dateien und src/backend/Centron.DAO/Mappings/ mit 983 Dateien |
+| StRS-007 | SyRS-084 | SwRS-085 | src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs, Methode Delete mit token.IsActive = false, token.IsDeleted = true, DeletedBy und DeletedDate |
+| StRS-007 | SyRS-110 | SwRS-107 | src/webservice/Centron.Host/AspNetCore/HostedServices/ManagedBackgroundService.cs mit den genannten Vorgaben |
+| StRS-007 | SyRS-128 | SwRS-128 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Methode UpdateReceiptHourlySurchargeRateI3D mit Verweisfeld |
+| StRS-008 | SyRS-012 | SwRS-011 | src/backend/Centron.BL/Administration/Logins/UsersBL.cs, Verwendung von Result.AsError, Result.AsWarning, Result.AsSuccess und Result.FromException(ex) in einer Methode |
+| StRS-008 | SyRS-012 | SwRS-012 | docs/getting-started/general-structure.md, Abschnitte ClassContainer and ILogic Pattern und Connection Type Support mit dem Codebeispiel |
+| StRS-008 | SyRS-019 | SwRS-012 | docs/getting-started/general-structure.md, Abschnitte ClassContainer and ILogic Pattern und Connection Type Support mit dem Codebeispiel |
+| StRS-008 | SyRS-019 | SwRS-020 | docs/getting-started/general-structure.md, vollständige Codebeispiele für IAccountContractsLogic, BLAccountContractsLogic und WSAccountContractsLogic |
+| StRS-008 | SyRS-104 | SwRS-105 | src/webservice/Centron.Host/Services/ mit ICentronRestService.Obsolete.cs und CentronRestService.Obsolete.cs |
+| StRS-008 | SyRS-104 | SwRS-106 | src/webservice/Centron.Controllers/ mit den Ordnern Controllers/v1, Authorization, Common, Configuration |
+| StRS-008 | SyRS-129 | SwRS-129 | src/backend/Centron.BL/Administration/Connections/ConnectionBL.cs, Methoden ConvertToCentronConnection und ConvertToConnectionFileItem mit XmlSerializer |
+| StRS-009 | SyRS-013 | SwRS-013 | src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Zuweisung propertyValue.ValueEncryptedString = null vor der Rückgabe |
+| StRS-009 | SyRS-085 | SwRS-086 | src/backend/Centron.Common/TextCoding/AESCryptoLogic.cs, Methode GetKeyAndIV mit Buffer.BlockCopy(hash, 0, key, 0, 32) und Buffer.BlockCopy(hash, 5, iv, 0, 16) sowie der Konstante SECURITY_KEY |
+| StRS-009 | SyRS-085 | SwRS-145 | src/backend/Centron.Common/ und src/shared/Centron.Core/ mit den genannten Ordnern |
+| StRS-010 | SyRS-014 | SwRS-014 | src/backend/Centron.BL/Administration/Scripts/ScriptMethods/ScriptMethodsCollection.cs |
+| StRS-011 | SyRS-015 | SwRS-015 | SSMS_DB_SCHEMA.sql, Fremdschlüssel FK_AccountAddresses_Accounts, FK_AccountAddressContacts_AccountAddresses, FK_AccountLogs_Accounts und FK_AccountOrderProcessingContracts_Documents |
+| StRS-011 | SyRS-015 | SwRS-016 | src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs, Sonderprüfungen gegen dbo.Kunden und dbo.Kreditor |
+| StRS-012 | SyRS-016 | SwRS-017 | SSMS_DB_SCHEMA.sql, die aufgeführten Fremdschlüssel auf [dbo].[AccountActivities] einschließlich FK_AccountActivities_Taetigkeiten |
+| StRS-012 | SyRS-016 | SwRS-068 | src/backend/Centron.BL/Processes/ProcessBL.cs, generische Signaturen mit T : ProcessDTO, new() und Parametern objectI3D und objectKind |
+| StRS-012 | SyRS-016 | SwRS-112 | src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs, Aufruf DeleteReference(timerI3D, CentronObjectKindNumeric.HelpdeskTimerClass) |
+| StRS-012 | SyRS-016 | SwRS-131 | src/backend/Centron.BL/Tags/TagsBL.cs, Methoden GetActiveTags und GetTag mit Parameter includeInactive |
+| StRS-013 | SyRS-017 | SwRS-018 | src/backend/Centron.BL/Sales/Customers/CrmProjects/ und src/backend/Centron.BL/Projects/ProjectBL.cs |
+| StRS-014 | SyRS-018 | SwRS-019 | src/backend/Centron.BL/Mailings/MailingTemplateBL.cs und MailingDataBL.cs |
+| StRS-014 | SyRS-121 | SwRS-121 | src/backend/Centron.BL/Mail/ mit den genannten Unterordnern und Klassen |
+| StRS-015 | SyRS-019 | SwRS-012 | docs/getting-started/general-structure.md, Abschnitte ClassContainer and ILogic Pattern und Connection Type Support mit dem Codebeispiel |
+| StRS-015 | SyRS-019 | SwRS-020 | docs/getting-started/general-structure.md, vollständige Codebeispiele für IAccountContractsLogic, BLAccountContractsLogic und WSAccountContractsLogic |
+| StRS-016 | SyRS-020 | SwRS-021 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Prüfung typeof(IReceiptItemWithMasterDataListSerialNumberI3D).IsAssignableFrom(receipt.ReceiptKind.GetReceiptItemType()) in CheckForMasterDataListConsumables |
+| StRS-017 | SyRS-021 | SwRS-022 | src/backend/Centron.Entities/Entities/Devices/ und src/backend/Centron.Entities/Entities/DocuBoard/ |
+| StRS-017 | SyRS-021 | SwRS-134 | src/backend/Centron.BL/ItPlanner/ChecklistVirtualObjectCategoryBL.cs mit den genannten Methoden |
+| StRS-018 | SyRS-022 | SwRS-023 | src/webservice/Centron.Host/AspNetCore/HostedServices/PlmImportService.cs |
+| StRS-019 | SyRS-023 | SwRS-024 | src/centron/Centron.WPF.UI/Modules/Survey/Pages/ und .../SurveySettings/ |
+| StRS-020 | SyRS-024 | SwRS-025 | src/shared/Centron.Controls/ mit den fachlichen Unterordnern, darunter ProductMatrix, PositionGrid, Checklist, PasswordManager, EmployeeAnalytics und Telephony |
+| StRS-020 | SyRS-024 | SwRS-149 | src/centron/Centron.WPF.UI.Extension/ und src/shared/Centron.Controls/ mit den genannten Ordnern |
+| StRS-021 | SyRS-015 | SwRS-015 | SSMS_DB_SCHEMA.sql, Fremdschlüssel FK_AccountAddresses_Accounts, FK_AccountAddressContacts_AccountAddresses, FK_AccountLogs_Accounts und FK_AccountOrderProcessingContracts_Documents |
+| StRS-021 | SyRS-015 | SwRS-016 | src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs, Sonderprüfungen gegen dbo.Kunden und dbo.Kreditor |
+| StRS-021 | SyRS-025 | SwRS-026 | src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs, Schleife mit UpdateBuilder, Bedingung f.Current == numberGroupObject.Current und Prüfung rowCountChanged == 1 |
+| StRS-021 | SyRS-125 | SwRS-125 | src/backend/Centron.BL/TextModuleArea/ mit TextModuleBL.cs und SalutationAndAgreementReplacementBL.cs sowie src/backend/Centron.DAO/TextModuleArea/ |
+| StRS-022 | SyRS-026 | SwRS-027 | docs/reference/receipts/receipts-backend-architecture.md, Abschnitte Adding New Columns - Complete Checklist mit zehn Schritten sowie Critical Warning und Critical Save Warning |
+| StRS-023 | SyRS-027 | SwRS-028 | src/backend/Centron.BL/Sales/Receipts/IReceiptSpecificLogic.cs, Mitglieder TryLockReceipt (Zeile 85) und UnLockReceipt (Zeile 91) |
+| StRS-024 | SyRS-028 | SwRS-029 | src/backend/Centron.BL/Sales/Receipts/SpecificLogics.cs und IReceiptSpecificLogic.cs |
+| StRS-024 | SyRS-028 | SwRS-150 | SSMS_DB_SCHEMA.sql, CREATE TABLE [dbo].[Zahkond] mit LaenPer1, Skonto1, LaenPer2, Skonto2, LaenPer3 und den belegartbezogenen Gültigkeitsspalten GltAnge, GltAuf, GltSer, GltLief, GltRech, GltGuts und GltAbhol |
+| StRS-025 | SyRS-029 | SwRS-030 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Aufruf this._accountBL.GetAccountRelatedInformations(...).FirstOrDefault() mit Rückgabe info.DunningLevel |
+| StRS-026 | SyRS-030 | SwRS-031 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Projektion auf f.SalesTaxIdentificationNumber und f.TaxNumber mit Prüfung hasOneOfTheNumbers sowie throw new NotSupportedException für Lieferantenbelege |
+| StRS-026 | SyRS-030 | SwRS-033 | src/backend/Centron.BL/Sales/Receipts/DataAndResults/SaveReceipt/SaveReceiptResultBuilder.cs, Methode SetMessage mit Filterung auf f != SaveReceiptErrorMissingField.None (Zeilen 62 bis 67) |
+| StRS-027 | SyRS-031 | SwRS-032 | src/backend/Centron.BL/Sales/Receipts/ReceiptPriceHelperBL.cs, ReceiptItemBL.cs und ReceiptItemSpecialArticleHelperBL.cs |
+| StRS-027 | SyRS-031 | SwRS-059 | src/backend/Centron.BL/Warehousing/ mit den genannten Klassen und Unterordnern |
+| StRS-027 | SyRS-031 | SwRS-148 | SSMS_DB_SCHEMA.sql, CREATE UNIQUE NONCLUSTERED INDEX [idx_AccountArticleSpecialPricesImportSettings_UniqueSettings] |
+| StRS-027 | SyRS-058 | SwRS-058 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Methode UpdatePurchasePriceInReceipt mit Parameter saveUpdatedReceipt (Zeile 5566) |
+| StRS-028 | SyRS-030 | SwRS-031 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Projektion auf f.SalesTaxIdentificationNumber und f.TaxNumber mit Prüfung hasOneOfTheNumbers sowie throw new NotSupportedException für Lieferantenbelege |
+| StRS-028 | SyRS-030 | SwRS-033 | src/backend/Centron.BL/Sales/Receipts/DataAndResults/SaveReceipt/SaveReceiptResultBuilder.cs, Methode SetMessage mit Filterung auf f != SaveReceiptErrorMissingField.None (Zeilen 62 bis 67) |
+| StRS-028 | SyRS-032 | SwRS-033 | src/backend/Centron.BL/Sales/Receipts/DataAndResults/SaveReceipt/SaveReceiptResultBuilder.cs, Methode SetMessage mit Filterung auf f != SaveReceiptErrorMissingField.None (Zeilen 62 bis 67) |
+| StRS-028 | SyRS-127 | SwRS-127 | src/backend/Centron.BL/Warehousing/CostCenterBL.cs und CostObjectBL.cs |
+| StRS-029 | SyRS-033 | SwRS-034 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Methoden GetHelpdeskInfosForReceipt (Zeile 4405) und CreateTicketsForReceipt (Zeile 4445) |
+| StRS-029 | SyRS-121 | SwRS-121 | src/backend/Centron.BL/Mail/ mit den genannten Unterordnern und Klassen |
+| StRS-030 | SyRS-034 | SwRS-035 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Methoden CreateFullReportForReceipt, ArchiveInvoicePdf und AddReportToReceiptDocuments |
+| StRS-030 | SyRS-034 | SwRS-079 | src/backend/Centron.BL/ReportEngine/ mit den genannten Unterordnern und FastReportHelper.cs |
+| StRS-030 | SyRS-035 | SwRS-035 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Methoden CreateFullReportForReceipt, ArchiveInvoicePdf und AddReportToReceiptDocuments |
+| StRS-031 | SyRS-036 | SwRS-036 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Typprüfungen receipt is IReceiptWithContingent contingent und receipt is not IReceiptWithUserState receiptWithUserState sowie receipt is not IReceiptWithProvision receiptWithProvision |
+| StRS-031 | SyRS-037 | SwRS-037 | src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, Berechnungen mit 1.0 * und deutschsprachigen Feldnamen (Zeilen 1119, 1151, 1191, 1234) |
+| StRS-031 | SyRS-037 | SwRS-038 | src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, Verwendung von billingParam und SearchBillingContractsFilter in GetActiveContracts und SearchBillingContracts |
+| StRS-032 | SyRS-037 | SwRS-037 | src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, Berechnungen mit 1.0 * und deutschsprachigen Feldnamen (Zeilen 1119, 1151, 1191, 1234) |
+| StRS-032 | SyRS-037 | SwRS-038 | src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, Verwendung von billingParam und SearchBillingContractsFilter in GetActiveContracts und SearchBillingContracts |
+| StRS-033 | SyRS-036 | SwRS-036 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Typprüfungen receipt is IReceiptWithContingent contingent und receipt is not IReceiptWithUserState receiptWithUserState sowie receipt is not IReceiptWithProvision receiptWithProvision |
+| StRS-033 | SyRS-038 | SwRS-037 | src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, Berechnungen mit 1.0 * und deutschsprachigen Feldnamen (Zeilen 1119, 1151, 1191, 1234) |
+| StRS-033 | SyRS-038 | SwRS-039 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Methode WriteReceiptLogs mit CreateContingentKindEntry, CreateContingentValueEntry und CreateContingentMinimalOrderAmountEntry jeweils mit altem und neuem Wert |
+| StRS-034 | SyRS-039 | SwRS-040 | src/backend/Centron.BL/RiverDivo/RiverConnectionBL.cs und SimpleRiverCentronClient.cs |
+| StRS-035 | SyRS-020 | SwRS-021 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Prüfung typeof(IReceiptItemWithMasterDataListSerialNumberI3D).IsAssignableFrom(receipt.ReceiptKind.GetReceiptItemType()) in CheckForMasterDataListConsumables |
+| StRS-035 | SyRS-040 | SwRS-041 | src/backend/Centron.Entities/Entities/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListCompact.cs und MasterDataListItemsCompact.cs |
+| StRS-036 | SyRS-041 | SwRS-042 | src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Methoden GetRightsForModule und IsModuleAvailable<T> sowie die Verwendung von ModuleRegistrationItem.For<T> |
+| StRS-037 | SyRS-042 | SwRS-043 | src/backend/Centron.BL/Sales/Receipts/DataAndResults/CreateReceiptForHelpdeskTimers/CreateReceiptForHelpdeskTimersResult.cs und CreatePositionForHelpdeskTimerResult.cs |
+| StRS-038 | SyRS-043 | SwRS-044 | SSMS_DB_SCHEMA.sql, getrennte Tabellen ReceiptProvisionSchemaItems und ReceiptProvisionItems mit jeweils eigenen CHECK-Constraints |
+| StRS-039 | SyRS-043 | SwRS-044 | SSMS_DB_SCHEMA.sql, getrennte Tabellen ReceiptProvisionSchemaItems und ReceiptProvisionItems mit jeweils eigenen CHECK-Constraints |
+| StRS-040 | SyRS-044 | SwRS-045 | src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung ausschließlich von ContractEvaluation2AppModuleController |
+| StRS-040 | SyRS-044 | SwRS-076 | src/backend/Centron.BL/Services/CachedTableBL.cs, Registrierung je Zwischentabelle mit eigener Aktualisierungsroutine |
+| StRS-041 | SyRS-045 | SwRS-046 | src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs, SetValueForParameter für @CustomerI3D, @AddressI3D und @ContactI3D (Zeilen 363 bis 368) |
+| StRS-042 | SyRS-046 | SwRS-047 | src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs und DunningRunBL.cs, Verwendung von GrossPriceComplete, PayedGrossAmount, CreditVoucherGrossAmount sowie DunningLevelXDate und DunningLevelXEmployee |
+| StRS-043 | SyRS-047 | SwRS-048 | SSMS_DB_SCHEMA.sql, CREATE TABLE [dbo].[MwstSatz] mit den genannten Spalten |
+| StRS-043 | SyRS-050 | SwRS-051 | src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs, Methode GetBookkeepingReceiptKind mit throw new ResultException |
+| StRS-043 | SyRS-050 | SwRS-147 | src/backend/Centron.BL/Administration/BookKeepingAccountSystems/BookKeepingAccountSystemBL.cs und src/backend/Centron.BL/Administration/Company/BranchRevenueAndExpenseAccountBL.cs |
+| StRS-043 | SyRS-126 | SwRS-126 | src/backend/Centron.BL/CountryArea/CountryBL.cs, Methoden UpdateCurrencyRateByCountry und UpdateCurrencyRateByRateDictionary sowie GetInlandCountry(AppUser) |
+| StRS-044 | SyRS-048 | SwRS-049 | src/backend/Centron.BL/Finances/Payments/PaymentsBL.cs, Methode DeleteIncomingPayment(DeleteIncomingPaymentFilter, LoggedInUser) |
+| StRS-045 | SyRS-048 | SwRS-049 | src/backend/Centron.BL/Finances/Payments/PaymentsBL.cs, Methode DeleteIncomingPayment(DeleteIncomingPaymentFilter, LoggedInUser) |
+| StRS-045 | SyRS-049 | SwRS-050 | src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs, Methode GetInterfaceList mit den fünf Aufzählungswerten und Anzeigetexten sowie die Verzweigung für Sepa00800102GBIC3 und Sepa00800108GBIC4 (Zeilen 56 bis 66 und 182 bis 183) |
+| StRS-046 | SyRS-049 | SwRS-050 | src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs, Methode GetInterfaceList mit den fünf Aufzählungswerten und Anzeigetexten sowie die Verzweigung für Sepa00800102GBIC3 und Sepa00800108GBIC4 (Zeilen 56 bis 66 und 182 bis 183) |
+| StRS-047 | SyRS-046 | SwRS-047 | src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs und DunningRunBL.cs, Verwendung von GrossPriceComplete, PayedGrossAmount, CreditVoucherGrossAmount sowie DunningLevelXDate und DunningLevelXEmployee |
+| StRS-047 | SyRS-050 | SwRS-051 | src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs, Methode GetBookkeepingReceiptKind mit throw new ResultException |
+| StRS-047 | SyRS-050 | SwRS-147 | src/backend/Centron.BL/Administration/BookKeepingAccountSystems/BookKeepingAccountSystemBL.cs und src/backend/Centron.BL/Administration/Company/BranchRevenueAndExpenseAccountBL.cs |
+| StRS-047 | SyRS-127 | SwRS-127 | src/backend/Centron.BL/Warehousing/CostCenterBL.cs und CostObjectBL.cs |
+| StRS-048 | SyRS-050 | SwRS-051 | src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs, Methode GetBookkeepingReceiptKind mit throw new ResultException |
+| StRS-048 | SyRS-050 | SwRS-147 | src/backend/Centron.BL/Administration/BookKeepingAccountSystems/BookKeepingAccountSystemBL.cs und src/backend/Centron.BL/Administration/Company/BranchRevenueAndExpenseAccountBL.cs |
+| StRS-049 | SyRS-051 | SwRS-052 | src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs, Knotenerzeugung über XmlDocument mit den genannten Hilfsmethoden |
+| StRS-050 | SyRS-052 | SwRS-053 | src/apis/Centron.APIs.FinAPI/ mit IFinApiClient.cs, FinApiClient.cs und den Ordnern Requests, Responses und RestClient |
+| StRS-051 | SyRS-053 | SwRS-054 | src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs, mit [Obsolete] gekennzeichnete Konstanten RIGHT_BARRIGHT_NUNG und RIGHT_KASSENBUCH |
+| StRS-052 | SyRS-054 | SwRS-055 | docs/reference/receipts/receipts-backend-architecture.md, Abschnitt Repository Pattern mit den Methodennamen SynchronizeReceiptData und SynchronizeReceiptItemData und dem Hinweis, dass AutoMapper und die moderne Zuordnung auf diesem Weg nicht greifen |
+| StRS-053 | SyRS-055 | SwRS-056 | src/backend/Centron.BL/Purchasing/ mit OrderSuggestionListBL.cs, PurchaseSettingsBL.cs, SupplierOrderPerBranchBL.cs und Suppliers/SupplierBL.cs |
+| StRS-054 | SyRS-056 | SwRS-057 | src/backend/Centron.Gateway/ mit den Ordnern EDI_Alltron, EDI_Also, EDI_AlsoCH, EDI_EGIS, EDI_Herweck, EDI_Komsa, OpenTrans und OpenTrans1_0 |
+| StRS-054 | SyRS-057 | SwRS-057 | src/backend/Centron.Gateway/ mit den Ordnern EDI_Alltron, EDI_Also, EDI_AlsoCH, EDI_EGIS, EDI_Herweck, EDI_Komsa, OpenTrans und OpenTrans1_0 |
+| StRS-055 | SyRS-054 | SwRS-055 | docs/reference/receipts/receipts-backend-architecture.md, Abschnitt Repository Pattern mit den Methodennamen SynchronizeReceiptData und SynchronizeReceiptItemData und dem Hinweis, dass AutoMapper und die moderne Zuordnung auf diesem Weg nicht greifen |
+| StRS-055 | SyRS-058 | SwRS-058 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Methode UpdatePurchasePriceInReceipt mit Parameter saveUpdatedReceipt (Zeile 5566) |
+| StRS-056 | SyRS-031 | SwRS-032 | src/backend/Centron.BL/Sales/Receipts/ReceiptPriceHelperBL.cs, ReceiptItemBL.cs und ReceiptItemSpecialArticleHelperBL.cs |
+| StRS-056 | SyRS-031 | SwRS-059 | src/backend/Centron.BL/Warehousing/ mit den genannten Klassen und Unterordnern |
+| StRS-056 | SyRS-031 | SwRS-148 | SSMS_DB_SCHEMA.sql, CREATE UNIQUE NONCLUSTERED INDEX [idx_AccountArticleSpecialPricesImportSettings_UniqueSettings] |
+| StRS-056 | SyRS-059 | SwRS-059 | src/backend/Centron.BL/Warehousing/ mit den genannten Klassen und Unterordnern |
+| StRS-056 | SyRS-115 | SwRS-115 | SSMS_DB_SCHEMA.sql, Fremdschlüssel FK_ArticleProductionStep_ARTIK und FK_ArticleProductionOrderStepItems_ArticleProductionOrders |
+| StRS-056 | SyRS-123 | SwRS-123 | src/apis/ mit den acht Assemblies und ihren Unterordnern Parser, SoapTemplates und RequestTemplates |
+| StRS-057 | SyRS-060 | SwRS-060 | src/backend/Centron.BL/Warehousing/ArticleManagement/ArticleImportBL.cs, Methoden SetArticleProperty und SetStagePrices mit Type type = typeof(...) und anschließender Eigenschaftsauflösung (Zeilen 715 bis 742 und 790 bis 831) |
+| StRS-057 | SyRS-060 | SwRS-148 | SSMS_DB_SCHEMA.sql, CREATE UNIQUE NONCLUSTERED INDEX [idx_AccountArticleSpecialPricesImportSettings_UniqueSettings] |
+| StRS-057 | SyRS-119 | SwRS-119 | src/backend/Centron.BL/TradePool/TradePoolBL.cs, Überladungen von GetTradeArticleList mit maxCountRecords, index und out int countOfRecords |
+| StRS-057 | SyRS-123 | SwRS-123 | src/apis/ mit den acht Assemblies und ihren Unterordnern Parser, SoapTemplates und RequestTemplates |
+| StRS-058 | SyRS-061 | SwRS-061 | src/backend/Centron.BL/Warehousing/BarcodeBL.cs, Methoden GetBarcodeByI3D (BarCode) und GetBarCode2ByI3D (BarCode2) |
+| StRS-058 | SyRS-072 | SwRS-072 | src/backend/Centron.BL/CustomerArea/RmaBL.cs, getrennte Methoden für RmaArticle, RmaArticleHistory, RmaSendForth und RmaSendBack |
+| StRS-058 | SyRS-116 | SwRS-116 | src/backend/Centron.BL/Warehousing/InventoryManagement/InventoryNewBL.cs, Prüfung inventory.State == InventoryState.ClosedWithoutBC \|\| inventory.State == InventoryState.Closed |
+| StRS-058 | SyRS-118 | SwRS-118 | src/backend/Centron.BL/Warehousing/BarcodeBL.cs, Methode ValidateNewVoucherBarcode(Article, string) neben ValidateNewBarcode(int, string) |
+| StRS-059 | SyRS-055 | SwRS-056 | src/backend/Centron.BL/Purchasing/ mit OrderSuggestionListBL.cs, PurchaseSettingsBL.cs, SupplierOrderPerBranchBL.cs und Suppliers/SupplierBL.cs |
+| StRS-059 | SyRS-059 | SwRS-059 | src/backend/Centron.BL/Warehousing/ mit den genannten Klassen und Unterordnern |
+| StRS-059 | SyRS-062 | SwRS-062 | src/backend/Centron.BL/Warehousing/SecondStockArticleBL.cs, Signaturen BookToStock mit appUserI3D (Zeile 551) und BookFromStock ohne Benutzerbezug (Zeile 601) |
+| StRS-059 | SyRS-116 | SwRS-116 | src/backend/Centron.BL/Warehousing/InventoryManagement/InventoryNewBL.cs, Prüfung inventory.State == InventoryState.ClosedWithoutBC \|\| inventory.State == InventoryState.Closed |
+| StRS-059 | SyRS-117 | SwRS-117 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Signatur UpdateReceiptQuantityPicked(..., IList<CommissionOrderItemInfoDTO> items) |
+| StRS-060 | SyRS-061 | SwRS-061 | src/backend/Centron.BL/Warehousing/BarcodeBL.cs, Methoden GetBarcodeByI3D (BarCode) und GetBarCode2ByI3D (BarCode2) |
+| StRS-060 | SyRS-063 | SwRS-063 | src/apis/Centron.Api.Gls/ und src/apis/Centron.Api.Shipcloud/ mit den genannten Dateien |
+| StRS-060 | SyRS-117 | SwRS-117 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Signatur UpdateReceiptQuantityPicked(..., IList<CommissionOrderItemInfoDTO> items) |
+| StRS-061 | SyRS-064 | SwRS-064 | src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, Methode CheckTextFieldLengths mit den Truncate-Aufrufen und dem begleitenden Kommentar |
+| StRS-061 | SyRS-122 | SwRS-122 | src/backend/Centron.BL/MailScanner/MailScannerBL.cs, getrennte Methoden für Profile, Aufgaben, Abläufe und Protokolle |
+| StRS-062 | SyRS-065 | SwRS-065 | src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs, Methode DeleteHelpdeskTimer mit Task.Run und using var newSession = new DAOSession() für die Kalenderbereinigung |
+| StRS-062 | SyRS-112 | SwRS-112 | src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs, Aufruf DeleteReference(timerI3D, CentronObjectKindNumeric.HelpdeskTimerClass) |
+| StRS-062 | SyRS-128 | SwRS-128 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Methode UpdateReceiptHourlySurchargeRateI3D mit Verweisfeld |
+| StRS-063 | SyRS-066 | SwRS-066 | src/backend/Centron.BL/WebServices/Sales/Support/HelpdeskTimerWebServiceBL.cs, Rechteprüfung mit throw new ResultException (Zeilen 360 bis 378) |
+| StRS-064 | SyRS-067 | SwRS-067 | src/backend/Centron.BL/CheckListArea/UpdateChecklistBL.cs und ChangeTracking/ChangeLogBL.cs |
+| StRS-065 | SyRS-068 | SwRS-068 | src/backend/Centron.BL/Processes/ProcessBL.cs, generische Signaturen mit T : ProcessDTO, new() und Parametern objectI3D und objectKind |
+| StRS-065 | SyRS-122 | SwRS-122 | src/backend/Centron.BL/MailScanner/MailScannerBL.cs, getrennte Methoden für Profile, Aufgaben, Abläufe und Protokolle |
+| StRS-066 | SyRS-069 | SwRS-069 | src/backend/Centron.BL/ExpectedEvents/ExpectedEventsBL.cs, getrennte Methoden SaveExpectedEvent und SaveExpectedEventLogEntry |
+| StRS-067 | SyRS-070 | SwRS-070 | src/backend/Centron.BL/TaskManager/ und src/backend/Centron.BL/ToDoArea/ToDoBL.cs |
+| StRS-068 | SyRS-071 | SwRS-071 | src/backend/Centron.BL/TicketProjects/TicketProjectBL.cs |
+| StRS-069 | SyRS-070 | SwRS-070 | src/backend/Centron.BL/TaskManager/ und src/backend/Centron.BL/ToDoArea/ToDoBL.cs |
+| StRS-069 | SyRS-072 | SwRS-072 | src/backend/Centron.BL/CustomerArea/RmaBL.cs, getrennte Methoden für RmaArticle, RmaArticleHistory, RmaSendForth und RmaSendBack |
+| StRS-070 | SyRS-073 | SwRS-073 | SSMS_DB_SCHEMA.sql, Tabellennamen hlpdsk_8DReport und hlpdsk_8DReportTexte |
+| StRS-071 | SyRS-074 | SwRS-074 | src/backend/Centron.BL/Sales/Support/Escalation/EscalationReceiversEnum.cs |
+| StRS-072 | SyRS-068 | SwRS-068 | src/backend/Centron.BL/Processes/ProcessBL.cs, generische Signaturen mit T : ProcessDTO, new() und Parametern objectI3D und objectKind |
+| StRS-072 | SyRS-075 | SwRS-075 | src/backend/Centron.BL/WebServices/SelfCare/SelfCareWebserviceBL.cs, Listenoperationen je Objektart |
+| StRS-073 | SyRS-044 | SwRS-045 | src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung ausschließlich von ContractEvaluation2AppModuleController |
+| StRS-073 | SyRS-044 | SwRS-076 | src/backend/Centron.BL/Services/CachedTableBL.cs, Registrierung je Zwischentabelle mit eigener Aktualisierungsroutine |
+| StRS-073 | SyRS-076 | SwRS-076 | src/backend/Centron.BL/Services/CachedTableBL.cs, Registrierung je Zwischentabelle mit eigener Aktualisierungsroutine |
+| StRS-073 | SyRS-076 | SwRS-106 | src/webservice/Centron.Controllers/ mit den Ordnern Controllers/v1, Authorization, Common, Configuration |
+| StRS-074 | SyRS-077 | SwRS-077 | SSMS_DB_SCHEMA.sql, View [dbo].[cvw_EmployeeHelpdeskTimerStatistic] |
+| StRS-075 | SyRS-076 | SwRS-076 | src/backend/Centron.BL/Services/CachedTableBL.cs, Registrierung je Zwischentabelle mit eigener Aktualisierungsroutine |
+| StRS-075 | SyRS-076 | SwRS-106 | src/webservice/Centron.Controllers/ mit den Ordnern Controllers/v1, Authorization, Common, Configuration |
+| StRS-076 | SyRS-078 | SwRS-078 | src/backend/Centron.Gateway/MspCollector/Octopus und /Wortmann |
+| StRS-076 | SyRS-125 | SwRS-125 | src/backend/Centron.BL/TextModuleArea/ mit TextModuleBL.cs und SalutationAndAgreementReplacementBL.cs sowie src/backend/Centron.DAO/TextModuleArea/ |
+| StRS-077 | SyRS-034 | SwRS-035 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Methoden CreateFullReportForReceipt, ArchiveInvoicePdf und AddReportToReceiptDocuments |
+| StRS-077 | SyRS-034 | SwRS-079 | src/backend/Centron.BL/ReportEngine/ mit den genannten Unterordnern und FastReportHelper.cs |
+| StRS-077 | SyRS-079 | SwRS-079 | src/backend/Centron.BL/ReportEngine/ mit den genannten Unterordnern und FastReportHelper.cs |
+| StRS-078 | SyRS-080 | SwRS-080 | SSMS_DB_SCHEMA.sql, CREATE TABLE [dbo].[ConnectionTickets] und CREATE UNIQUE NONCLUSTERED INDEX [idx_ConnectionTickets_UniqueLogin] |
+| StRS-078 | SyRS-081 | SwRS-080 | SSMS_DB_SCHEMA.sql, CREATE TABLE [dbo].[ConnectionTickets] und CREATE UNIQUE NONCLUSTERED INDEX [idx_ConnectionTickets_UniqueLogin] |
+| StRS-078 | SyRS-081 | SwRS-081 | src/backend/Centron.BL/Administration/Logins/TwoFactor/ITwoFactorValidator.cs mit EmailTwoFactorValidator.cs und RadiusTwoFactorValidator.cs |
+| StRS-078 | SyRS-082 | SwRS-082 | SSMS_DB_SCHEMA.sql, CREATE TABLE [dbo].[Sichbenu] mit den genannten Spalten |
+| StRS-078 | SyRS-097 | SwRS-098 | src/nexus/CentronNexus.OutlookAddIn/ mit den fachlichen Unterordnern und dem Ordner Manifest |
+| StRS-078 | SyRS-114 | SwRS-114 | src/backend/Centron.BL/ArtificialIntelligence/ mit IApiClient.cs, ApiClientFactory.cs, IMessage.cs, AiHttpModelCatalogClient.cs und AiApiLinkValidator.cs |
+| StRS-078 | SyRS-124 | SwRS-123 | src/apis/ mit den acht Assemblies und ihren Unterordnern Parser, SoapTemplates und RequestTemplates |
+| StRS-078 | SyRS-124 | SwRS-124 | src/backend/Centron.Interfaces/Administration/Logins/ApplicationKind.cs mit den statischen schreibgeschützten Einträgen und ihren Kennungen |
+| StRS-078 | SyRS-124 | SwRS-135 | src/backend/Centron.BL/ExternalHelpdesk/ExternalHelpdeskConfigurationBL.cs und src/backend/Centron.BL/Sales/Support/ExternalHelpdeskConfigurationBL.cs |
+| StRS-078 | SyRS-124 | SwRS-136 | src/backend/Centron.BL/DataExchange/TelekomDive/TelekomDiveBL.cs, Methoden mit Listen und Filter |
+| StRS-078 | SyRS-124 | SwRS-137 | Centron.Api.docuFORM/IDocuFormApiClient.cs und DocuFormRestApiClient.cs |
+| StRS-078 | SyRS-124 | SwRS-138 | src/backend/Centron.BL/DataExchange/Connectors/ mit den fünf DocBee-Klassen und WebHookClient.cs |
+| StRS-079 | SyRS-081 | SwRS-080 | SSMS_DB_SCHEMA.sql, CREATE TABLE [dbo].[ConnectionTickets] und CREATE UNIQUE NONCLUSTERED INDEX [idx_ConnectionTickets_UniqueLogin] |
+| StRS-079 | SyRS-081 | SwRS-081 | src/backend/Centron.BL/Administration/Logins/TwoFactor/ITwoFactorValidator.cs mit EmailTwoFactorValidator.cs und RadiusTwoFactorValidator.cs |
+| StRS-080 | SyRS-082 | SwRS-082 | SSMS_DB_SCHEMA.sql, CREATE TABLE [dbo].[Sichbenu] mit den genannten Spalten |
+| StRS-081 | SyRS-083 | SwRS-083 | src/backend/Centron.BL/Administration/Logins/UsersBL.cs, Bedingung newPassword?.Length < appUser.PasswordMinLength && appUser.PasswordMinLength > 0 |
+| StRS-081 | SyRS-083 | SwRS-084 | src/backend/Centron.Common/TextCoding/SHA1Decoder.cs, Methode GetDecodedSHA1String mit SHA1.Create() und Encoding.GetEncoding(1252) ohne Salt |
+| StRS-081 | SyRS-083 | SwRS-085 | src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs, Methode Delete mit token.IsActive = false, token.IsDeleted = true, DeletedBy und DeletedDate |
+| StRS-082 | SyRS-083 | SwRS-083 | src/backend/Centron.BL/Administration/Logins/UsersBL.cs, Bedingung newPassword?.Length < appUser.PasswordMinLength && appUser.PasswordMinLength > 0 |
+| StRS-082 | SyRS-083 | SwRS-084 | src/backend/Centron.Common/TextCoding/SHA1Decoder.cs, Methode GetDecodedSHA1String mit SHA1.Create() und Encoding.GetEncoding(1252) ohne Salt |
+| StRS-082 | SyRS-083 | SwRS-085 | src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs, Methode Delete mit token.IsActive = false, token.IsDeleted = true, DeletedBy und DeletedDate |
+| StRS-082 | SyRS-084 | SwRS-085 | src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs, Methode Delete mit token.IsActive = false, token.IsDeleted = true, DeletedBy und DeletedDate |
+| StRS-083 | SyRS-013 | SwRS-013 | src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Zuweisung propertyValue.ValueEncryptedString = null vor der Rückgabe |
+| StRS-083 | SyRS-085 | SwRS-086 | src/backend/Centron.Common/TextCoding/AESCryptoLogic.cs, Methode GetKeyAndIV mit Buffer.BlockCopy(hash, 0, key, 0, 32) und Buffer.BlockCopy(hash, 5, iv, 0, 16) sowie der Konstante SECURITY_KEY |
+| StRS-083 | SyRS-085 | SwRS-145 | src/backend/Centron.Common/ und src/shared/Centron.Core/ mit den genannten Ordnern |
+| StRS-084 | SyRS-086 | SwRS-087 | src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs, Methoden DoDeleteCustomer (Zeile 856), DoDeleteSupplier (Zeile 935) und DoDeleteAccount (Zeile 996) mit throw new NotImplementedException und auskommentierten Anweisungen |
+| StRS-085 | SyRS-066 | SwRS-066 | src/backend/Centron.BL/WebServices/Sales/Support/HelpdeskTimerWebServiceBL.cs, Rechteprüfung mit throw new ResultException (Zeilen 360 bis 378) |
+| StRS-085 | SyRS-087 | SwRS-088 | src/backend/Centron.BL/Administration/Employees/ mit den zehn Klassen und src/backend/Centron.BL/EmployeeArea/ |
+| StRS-085 | SyRS-111 | SwRS-111 | src/backend/Centron.BL/Mobile/MobileBL.cs und src/backend/Centron.DAO/Mobile/ |
+| StRS-086 | SyRS-087 | SwRS-088 | src/backend/Centron.BL/Administration/Employees/ mit den zehn Klassen und src/backend/Centron.BL/EmployeeArea/ |
+| StRS-086 | SyRS-088 | SwRS-089 | src/backend/Centron.Interfaces/Administration/Settings/ mit ApplicationSettingID.cs, ApplicationSettingDefinitions.cs, ApplicationSettingDefaults.cs und AppSettingsDataConst.cs |
+| StRS-087 | SyRS-089 | SwRS-090 | src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs, Methoden SearchForReceiptUpdateItems, StartReceiptPriceUpdate und StartArticlePriceUpdate |
+| StRS-088 | SyRS-090 | SwRS-091 | src/backend/Centron.BL/Administration/FileManagement/ mit DirectoryReferenceBL.cs, GetDirectoryByReferenzBL.cs, SystemDirectoryNames.cs und CreateIndexNameBlacklist.cs |
+| StRS-088 | SyRS-096 | SwRS-097 | src/backend/Centron.BL/Administration/FileManagement/SharedDocumentBL.cs und src/nexus/CentronNexus/Shared/Authorization/DocumentAuthorization.cs |
+| StRS-089 | SyRS-091 | SwRS-092 | src/backend/Centron.BL/IndexSearch/GermanAnalyzer.cs, DefaultObjectPool<StringBuilder> und CultureInfo de-DE mit den Herkunftsverweisen im Kommentar |
+| StRS-090 | SyRS-092 | SwRS-093 | src/backend/Centron.BL/ExternalToolsBL/ExternalToolBL.cs, Signatur ReplaceExternalToolVariables(string text, VariableData variableData) |
+| StRS-091 | SyRS-093 | SwRS-094 | src/nexus/CentronNexus/Shared/Authorization/CentronAuthorization.cs, Methode EmployeeRightsRecurse mit GetFields(BindingFlags.Public \| BindingFlags.Static) und Rekursion über GetNestedTypes |
+| StRS-091 | SyRS-093 | SwRS-142 | src/nexus/CentronNexus/Settings/ und Management/ mit den genannten Unterbereichen |
+| StRS-092 | SyRS-064 | SwRS-064 | src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, Methode CheckTextFieldLengths mit den Truncate-Aufrufen und dem begleitenden Kommentar |
+| StRS-092 | SyRS-093 | SwRS-094 | src/nexus/CentronNexus/Shared/Authorization/CentronAuthorization.cs, Methode EmployeeRightsRecurse mit GetFields(BindingFlags.Public \| BindingFlags.Static) und Rekursion über GetNestedTypes |
+| StRS-092 | SyRS-093 | SwRS-142 | src/nexus/CentronNexus/Settings/ und Management/ mit den genannten Unterbereichen |
+| StRS-092 | SyRS-094 | SwRS-095 | src/nexus/CentronNexus/Shared/Authorization/PortAuthorization.cs, Bedingung if (config.Value.Port is null) { context.Succeed(requirement); return; } |
+| StRS-092 | SyRS-094 | SwRS-141 | src/backend/Centron.BL/Administration/Logins/UsersBL.cs, Verzweigung bei currentUser.IsWebAccountLogin mit Aufruf _webAccountBL.UpdatePassword(webAccount.I3D, newPassword, currentUser.User.I3D) |
+| StRS-092 | SyRS-095 | SwRS-096 | src/nexus/CentronNexus/WebCart/ mit Shop- und Portalseiten im selben Ordner |
+| StRS-093 | SyRS-095 | SwRS-096 | src/nexus/CentronNexus/WebCart/ mit Shop- und Portalseiten im selben Ordner |
+| StRS-094 | SyRS-096 | SwRS-097 | src/backend/Centron.BL/Administration/FileManagement/SharedDocumentBL.cs und src/nexus/CentronNexus/Shared/Authorization/DocumentAuthorization.cs |
+| StRS-094 | SyRS-113 | SwRS-113 | src/backend/Centron.BL/WebLinks/IWebLinkActionHandler.cs mit den beiden Umsetzungen |
+| StRS-095 | SyRS-097 | SwRS-098 | src/nexus/CentronNexus.OutlookAddIn/ mit den fachlichen Unterordnern und dem Ordner Manifest |
+| StRS-096 | SyRS-098 | SwRS-099 | src/webservice/Centron.Host/RealTimeServices/TapiClientHub.cs, Schnittstelle ITapiClient mit den sieben typisierten Ereignissen |
+| StRS-096 | SyRS-098 | SwRS-102 | src/webservice/Centron.Host/RealTimeServices/TapiClientHub.cs, Ableitung CentronHub<TapiClientHub, ITapiClient> |
+| StRS-097 | SyRS-099 | SwRS-100 | src/backend/Centron.BL/Sales/Calendar/ScheduleBL.cs, private Methoden AddScheduleToExchange, UpdateScheduleToExchange und DeleteScheduleToExchange mit unmittelbarer Verwendung von this._graphClient |
+| StRS-098 | SyRS-065 | SwRS-065 | src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs, Methode DeleteHelpdeskTimer mit Task.Run und using var newSession = new DAOSession() für die Kalenderbereinigung |
+| StRS-098 | SyRS-070 | SwRS-070 | src/backend/Centron.BL/TaskManager/ und src/backend/Centron.BL/ToDoArea/ToDoBL.cs |
+| StRS-098 | SyRS-100 | SwRS-101 | src/backend/Centron.BL/MyDay/ mit MyDayBL.cs, MyDayNotificationsBL.cs, ReportConnections.cs und ReportRecord.cs |
+| StRS-099 | SyRS-098 | SwRS-099 | src/webservice/Centron.Host/RealTimeServices/TapiClientHub.cs, Schnittstelle ITapiClient mit den sieben typisierten Ereignissen |
+| StRS-099 | SyRS-098 | SwRS-102 | src/webservice/Centron.Host/RealTimeServices/TapiClientHub.cs, Ableitung CentronHub<TapiClientHub, ITapiClient> |
+| StRS-099 | SyRS-101 | SwRS-102 | src/webservice/Centron.Host/RealTimeServices/TapiClientHub.cs, Ableitung CentronHub<TapiClientHub, ITapiClient> |
+| StRS-099 | SyRS-101 | SwRS-133 | src/backend/Centron.BL/SocialMedia/SocialMediaBL.cs, Methoden SocialMediaSubscribeToHelpdesk und SocialMediaSubscribeToCRMActivity |
+| StRS-100 | SyRS-102 | SwRS-103 | Centron.sln, Projekte Centron.Host, Centron.Host.Console und Centron.Host.WindowsService |
+| StRS-100 | SyRS-102 | SwRS-146 | version.json mit Verweis auf Nerdbank.GitVersioning und der Version 2.0.2611-alpha |
+| StRS-100 | SyRS-103 | SwRS-104 | src/webservice/Centron.Controllers/Configuration/GlobalExceptionFilter.cs, Aufruf DAOFactory.Instance.TryRecoverConnectionPool |
+| StRS-100 | SyRS-105 | SwRS-104 | src/webservice/Centron.Controllers/Configuration/GlobalExceptionFilter.cs, Aufruf DAOFactory.Instance.TryRecoverConnectionPool |
+| StRS-100 | SyRS-105 | SwRS-107 | src/webservice/Centron.Host/AspNetCore/HostedServices/ManagedBackgroundService.cs mit den genannten Vorgaben |
+| StRS-100 | SyRS-105 | SwRS-139 | src/backend/Centron.BL/Administration/SQLManagement/SQLManagementBL.cs mit ausschließlich lesenden Methoden |
+| StRS-100 | SyRS-106 | SwRS-108 | src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs und BasicAuthenticator.cs, LogManager.GetCurrentClassLogger() mit benannten Platzhaltern |
+| StRS-100 | SyRS-106 | SwRS-140 | src/backend/Centron.BL/Administration/NetworkDiagnostics/NetworkDiagnosticsBL.cs, PerformanceTests/PerformanceTestBL.cs und Profiling/ProfilerBL.cs |
+| StRS-100 | SyRS-107 | SwRS-109 | src/backend/Centron.BL/Telemetry/TelemetryBL.cs, Signaturen mit maxBucketStartUtc, occurredUtc und den Zählerobjekten |
+| StRS-100 | SyRS-108 | SwRS-110 | src/backend/Centron.Common/DeveloperSecurity.cs, Prüfung emailAddress.EndsWith(InternalEmailAddressDomain, StringComparison.InvariantCultureIgnoreCase) |
+| StRS-100 | SyRS-109 | SwRS-107 | src/webservice/Centron.Host/AspNetCore/HostedServices/ManagedBackgroundService.cs mit den genannten Vorgaben |
+| StRS-100 | SyRS-120 | SwRS-120 | Centron.sln, elf Testprojekte |
+| StRS-100 | SyRS-120 | SwRS-146 | version.json mit Verweis auf Nerdbank.GitVersioning und der Version 2.0.2611-alpha |

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-a8f5/Ergebnisse/_coverage_tmp.txt

@@ -0,0 +1,135 @@
+| M-001 | Adressstamm (Konten, Kunden, Lieferanten) | mittel | 4 | StRS-011, SyRS-015, SwRS-015, SwRS-016 |
+| M-002 | CRM / Kontakthistorie | mittel | 3 | StRS-012, SyRS-016, SwRS-017 |
+| M-003 | CRM-Projekte | mittel | 3 | StRS-013, SyRS-017, SwRS-018 |
+| M-004 | Kampagnen / Mailing | mittel | 3 | StRS-014, SyRS-018, SwRS-019 |
+| M-005 | Lieferanten-Verträge | mittel | 3 | StRS-015, SyRS-019, SwRS-020 |
+| M-006 | Stammblätter | mittel | 3 | StRS-016, SyRS-020, SwRS-021 |
+| M-007 | Produktlebenszyklus (PLM) | mittel | 3 | StRS-018, SyRS-022, SwRS-023 |
+| M-008 | Audit / Umfragen | mittel | 3 | StRS-019, SyRS-023, SwRS-024 |
+| M-009 | Belegwesen Verkauf | tief | 30 | StRS-001, StRS-021, StRS-022, StRS-023, StRS-024, StRS-026, StRS-027, StRS-028, StRS-029, StRS-030, SyRS-001, SyRS-002, SyRS-025, SyRS-026, SyRS-027, SyRS-028, SyRS-030, SyRS-032, SyRS-033, SyRS-034, SwRS-001, SwRS-002, SwRS-026, SwRS-027, SwRS-028, SwRS-029, SwRS-031, SwRS-033, SwRS-034, SwRS-035 |
+| M-010 | Belegkonditionen | flach | 1 | SwRS-150 |
+| M-011 | Vertragsverwaltung | mittel | 3 | StRS-031, SyRS-036, SwRS-036 |
+| M-012 | Vertragsabrechnung (Automated Billing) | mittel | 7 | StRS-032, StRS-033, SyRS-037, SyRS-038, SwRS-037, SwRS-038, SwRS-039 |
+| M-013 | Pauschalabrechnung (Flatrate Billing) | mittel | 3 | StRS-036, SyRS-041, SwRS-042 |
+| M-014 | Vereinfachte Ticketabrechnung (Timer Billing) | mittel | 3 | StRS-037, SyRS-042, SwRS-043 |
+| M-015 | Klick-Zählerverwaltung | mittel | 3 | StRS-035, SyRS-040, SwRS-041 |
+| M-016 | Provisionsauswertung und -schemas | mittel | 4 | StRS-038, StRS-039, SyRS-043, SwRS-044 |
+| M-017 | Vertragsauswertung | mittel | 3 | StRS-040, SyRS-044, SwRS-045 |
+| M-018 | Mahnwesen | tief | 9 | StRS-041, StRS-042, StRS-025, SyRS-045, SyRS-046, SyRS-029, SwRS-046, SwRS-047, SwRS-030 |
+| M-019 | OPOS (offene Posten) | flach | 1 | SyRS-046 |
+| M-020 | Zahlungseingang | mittel | 3 | StRS-044, SyRS-048, SwRS-049 |
+| M-021 | SEPA / Zahlungsverkehr | mittel | 4 | StRS-045, StRS-046, SyRS-049, SwRS-050 |
+| M-022 | Buchhaltungsexport / -import | mittel | 3 | StRS-047, SyRS-050, SwRS-051 |
+| M-023 | DATEV-Belegtransfer | flach | 1 | StRS-048 |
+| M-024 | Kalkulation pro Filiale | flach | 1 | SwRS-056 |
+| M-025 | Online-Banking (finAPI) | mittel | 3 | StRS-050, SyRS-052, SwRS-053 |
+| M-026 | Kassenbuch / Belegerfassung | mittel | 3 | StRS-051, SyRS-053, SwRS-054 |
+| M-027 | Einkauf / Bestellwesen | mittel | 3 | StRS-052, SyRS-054, SwRS-055 |
+| M-028 | Bestellvorschlagsliste | mittel | 3 | StRS-053, SyRS-055, SwRS-056 |
+| M-029 | EDI-Verwaltung | mittel | 4 | StRS-054, SyRS-056, SyRS-057, SwRS-057 |
+| M-030 | Wareneingang / WE-Kalkulation | mittel | 3 | StRS-055, SyRS-058, SwRS-058 |
+| M-031 | Artikelverwaltung | mittel | 5 | StRS-056, SyRS-059, SyRS-031, SwRS-059, SwRS-032 |
+| M-032 | Artikelimport | mittel | 3 | StRS-057, SyRS-060, SwRS-060 |
+| M-033 | Warengruppenverwaltung | flach | 1 | SyRS-059 |
+| M-034 | Artikeleinheiten | flach | 1 | SyRS-059 |
+| M-035 | Barcode- und Seriennummernverwaltung | mittel | 3 | StRS-058, SyRS-061, SwRS-061 |
+| M-036 | Lagerbestandsführung | mittel | 3 | StRS-059, SyRS-062, SwRS-062 |
+| M-037 | Inventur | flach | 2 | SyRS-116, SwRS-116 |
+| M-038 | Kommissionierung | flach | 2 | SyRS-117, SwRS-117 |
+| M-039 | Logistik / Versand | mittel | 3 | StRS-060, SyRS-063, SwRS-063 |
+| M-040 | Produktion | flach | 2 | SyRS-115, SwRS-115 |
+| M-041 | Kostenträger / Kostenstellen | flach | 2 | SyRS-127, SwRS-127 |
+| M-042 | Kontenrahmen | flach | 1 | SwRS-147 |
+| M-043 | Mehrwertsteuer | mittel | 3 | StRS-043, SyRS-047, SwRS-048 |
+| M-044 | Aufschläge Stundensätze | flach | 2 | SyRS-128, SwRS-128 |
+| M-045 | Projektpreis-Import | flach | 1 | SwRS-148 |
+| M-046 | Sonderpreis-Importe für Verträge | flach | 1 | SwRS-148 |
+| M-047 | Produkt-/Kundenmatrix | mittel | 3 | StRS-020, SyRS-024, SwRS-025 |
+| M-048 | TradePool | flach | 2 | SyRS-119, SwRS-119 |
+| M-049 | Gutschein-/Voucher-Verwaltung | flach | 2 | SyRS-118, SwRS-118 |
+| M-050 | Helpdesk / Ticketing | mittel | 3 | StRS-061, SyRS-064, SwRS-064 |
+| M-051 | Ticket-Zeiterfassung | mittel | 6 | StRS-062, StRS-063, SyRS-065, SyRS-066, SwRS-065, SwRS-066 |
+| M-052 | Checklisten | mittel | 3 | StRS-064, SyRS-067, SwRS-067 |
+| M-053 | Ticketprozess-Vorlagen (C-FLOW) | mittel | 3 | StRS-065, SyRS-068, SwRS-068 |
+| M-054 | Erwartete Events | mittel | 3 | StRS-066, SyRS-069, SwRS-069 |
+| M-055 | Taskmanagement | mittel | 3 | StRS-067, SyRS-070, SwRS-070 |
+| M-056 | Ticketprojekte / Projektverwaltung | mittel | 3 | StRS-068, SyRS-071, SwRS-071 |
+| M-057 | RMA / Werkstatt | mittel | 3 | StRS-069, SyRS-072, SwRS-072 |
+| M-058 | QM-Meldungen | mittel | 3 | StRS-070, SyRS-073, SwRS-073 |
+| M-059 | Eskalationen | mittel | 3 | StRS-071, SyRS-074, SwRS-074 |
+| M-060 | SelfCare-Formulare | mittel | 3 | StRS-072, SyRS-075, SwRS-075 |
+| M-061 | Externer Helpdesk | flach | 1 | SwRS-135 |
+| M-062 | Geräte / Assets am Konto | mittel | 3 | StRS-017, SyRS-021, SwRS-022 |
+| M-063 | Asset-/DocuBoard-Verwaltung | flach | 2 | SyRS-021, SwRS-022 |
+| M-064 | IT-Planner | flach | 1 | SwRS-134 |
+| M-065 | Kalender und Termine | flach | 2 | SyRS-099, SwRS-100 |
+| M-066 | Kalender-/Exchange-Synchronisation | mittel | 3 | StRS-097, SyRS-099, SwRS-100 |
+| M-067 | Mein Tag (MyDay) | mittel | 3 | StRS-098, SyRS-100, SwRS-101 |
+| M-068 | Mitarbeiterauslastung | flach | 1 | StRS-098 |
+| M-069 | Todo-Liste | flach | 2 | SyRS-070, SwRS-070 |
+| M-070 | Telefonie / TAPI | mittel | 3 | StRS-096, SyRS-098, SwRS-099 |
+| M-071 | Chat | mittel | 3 | StRS-099, SyRS-101, SwRS-102 |
+| M-072 | Benachrichtigungen | mittel | 3 | StRS-099, SyRS-101, SwRS-102 |
+| M-073 | Mailversand und Mailvorlagen | mittel | 4 | SyRS-121, SwRS-121, SyRS-108, SwRS-110 |
+| M-074 | Mail-Scanner | flach | 2 | SyRS-122, SwRS-122 |
+| M-075 | Outlook-Integration | mittel | 3 | StRS-095, SyRS-097, SwRS-098 |
+| M-076 | Textbausteine | flach | 2 | SyRS-125, SwRS-125 |
+| M-077 | Dashboard | flach | 2 | SyRS-130, SwRS-130 |
+| M-078 | KI-Assistent / AI-Chat | flach | 2 | SyRS-114, SwRS-114 |
+| M-079 | Social Media | flach | 1 | SwRS-133 |
+| M-080 | Video-Portal | flach | 1 | SwRS-132 |
+| M-081 | Tags | flach | 1 | SwRS-131 |
+| M-082 | Kurz-URLs und WebLinks | flach | 2 | SyRS-113, SwRS-113 |
+| M-083 | Statistik / Analytics | mittel | 3 | StRS-073, SyRS-076, SwRS-076 |
+| M-084 | Leistungsnachweise | mittel | 3 | StRS-074, SyRS-077, SwRS-077 |
+| M-085 | Management Info | flach | 1 | StRS-075 |
+| M-086 | MSP-Auswertung, -Collector, -Dashboard | mittel | 3 | StRS-076, SyRS-078, SwRS-078 |
+| M-087 | Report-Engine und Reportverwaltung | mittel | 3 | StRS-077, SyRS-079, SwRS-079 |
+| M-088 | Reportserver | flach | 1 | StRS-077 |
+| M-089 | Index-/Volltextsuche | mittel | 3 | StRS-089, SyRS-091, SwRS-092 |
+| M-090 | Telemetrie | flach | 2 | SyRS-107, SwRS-109 |
+| M-091 | Rechteverwaltung | tief | 10 | StRS-005, StRS-006, SyRS-007, SyRS-008, SyRS-009, SyRS-010, SwRS-006, SwRS-007, SwRS-008, SwRS-009 |
+| M-092 | Authentifizierung und Anmeldung | tief | 12 | StRS-078, StRS-080, StRS-081, SyRS-080, SyRS-081, SyRS-082, SyRS-083, SwRS-080, SwRS-082, SwRS-083, SwRS-084, SwRS-141 |
+| M-093 | Zwei-Faktor-Authentifizierung | mittel | 3 | StRS-079, SyRS-081, SwRS-081 |
+| M-094 | Zugriffstoken (API-Token) | mittel | 3 | StRS-082, SyRS-084, SwRS-085 |
+| M-095 | Lizenzverwaltung | mittel | 5 | StRS-004, SyRS-005, SyRS-006, SwRS-005, SwRS-124 |
+| M-096 | Mitarbeiterverwaltung / Personal | mittel | 3 | StRS-085, SyRS-087, SwRS-088 |
+| M-097 | Mandanten und Filialen | mittel | 3 | StRS-002, SyRS-003, SwRS-003 |
+| M-098 | Anwendungseinstellungen | mittel | 3 | StRS-086, SyRS-088, SwRS-089 |
+| M-099 | Zusatzfelder (Custom Properties) | mittel | 3 | StRS-009, SyRS-013, SwRS-013 |
+| M-100 | Passwort-Manager / Zugangsverwaltung | mittel | 3 | StRS-083, SyRS-085, SwRS-086 |
+| M-101 | DSGVO / Datenschutz | mittel | 3 | StRS-084, SyRS-086, SwRS-087 |
+| M-102 | PDF-Signierung | flach | 2 | SyRS-035, SwRS-035 |
+| M-103 | Dokumenten- und Dateiverwaltung | mittel | 3 | StRS-088, SyRS-090, SwRS-091 |
+| M-104 | Datenbank-Skript-Engine | mittel | 3 | StRS-010, SyRS-014, SwRS-014 |
+| M-105 | SQL-Manager | flach | 1 | SwRS-139 |
+| M-106 | Protokollierung und LogViewer | flach | 2 | SyRS-106, SwRS-108 |
+| M-107 | c-entron Inspektor | flach | 1 | SwRS-140 |
+| M-108 | Massenupdates (Data Updater) | mittel | 3 | StRS-087, SyRS-089, SwRS-090 |
+| M-109 | Änderungsverfolgung | mittel | 3 | StRS-007, SyRS-011, SwRS-010 |
+| M-110 | Länder und Bundesländer | flach | 2 | SyRS-126, SwRS-126 |
+| M-111 | Externe Tools | mittel | 3 | StRS-090, SyRS-092, SwRS-093 |
+| M-112 | Objekt-Externreferenzen | flach | 2 | SyRS-112, SwRS-112 |
+| M-113 | Legacy-REST-Webservice | flach | 2 | SyRS-104, SwRS-105 |
+| M-114 | Moderne REST-API v1 | mittel | 3 | SyRS-076, SyRS-104, SwRS-106 |
+| M-115 | Web-Service-Hosting | tief | 10 | StRS-100, StRS-008, SyRS-102, SyRS-103, SyRS-105, SyRS-109, SyRS-110, SwRS-103, SwRS-104, SwRS-107 |
+| M-116 | Verbindungsmanager | flach | 2 | SyRS-129, SwRS-129 |
+| M-117 | Echtzeitdienste (SignalR) | flach | 2 | SyRS-098, SwRS-102 |
+| M-118 | Nexus ServiceBoard | mittel | 3 | StRS-091, SyRS-093, SwRS-094 |
+| M-119 | Nexus WebCart / Kundenportal | mittel | 6 | StRS-092, StRS-093, SyRS-094, SyRS-095, SwRS-095, SwRS-096 |
+| M-120 | Nexus WebOffer | mittel | 3 | StRS-094, SyRS-096, SwRS-097 |
+| M-121 | Nexus Dokumentensignatur | mittel | 3 | StRS-094, SyRS-096, SwRS-097 |
+| M-122 | Nexus Verwaltung und Einstellungen | flach | 1 | SwRS-142 |
+| M-123 | Web-Konten (WebAccount) | flach | 2 | StRS-092, SwRS-141 |
+| M-124 | Externe Warenwirtschafts- und Bank-APIs | mittel | 4 | SyRS-123, SyRS-124, SwRS-123, SwRS-137 |
+| M-125 | Gateway / EDI-Konnektoren und E-Rechnung | mittel | 5 | StRS-049, SyRS-051, SwRS-052, SwRS-057, SwRS-138 |
+| M-126 | RMM-Anbindung (Riverbird) | mittel | 3 | StRS-034, SyRS-039, SwRS-040 |
+| M-127 | Persistenz / ORM | flach | 1 | SwRS-143 |
+| M-128 | Domänenmodell | flach | 1 | SwRS-144 |
+| M-129 | Basisbibliotheken | mittel | 3 | SwRS-145, SyRS-012, SwRS-011 |
+| M-130 | UI-Bausteine | flach | 2 | SwRS-149, SwRS-012 |
+| M-131 | Lokalisierung | mittel | 3 | StRS-003, SyRS-004, SwRS-004 |
+| M-132 | Build, Auslieferung und Betrieb | flach | 1 | SwRS-146 |
+| M-133 | Testsuite | flach | 2 | SyRS-120, SwRS-120 |
+| M-134 | Mobile-Schnittstelle | flach | 2 | SyRS-111, SwRS-111 |
+| M-135 | Telekom D!VE | flach | 1 | SwRS-136 |

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-a8f5/Ergebnisse/_risk_tmp.txt

@@ -0,0 +1,172 @@
+| StRS-001 | Durchgängige Abwicklung vom Angebot bis zur Rechnung in einem System | ja | belegt |
+| StRS-004 | Funktionsumfang wird über Lizenzen freigeschaltet | ja | belegt |
+| StRS-005 | Rollenbasierte Zugriffssteuerung über Rechtegruppen | ja | belegt |
+| StRS-006 | Einschränkende Rechte begrenzen die Sicht auf eigene Vorgänge oder die eigene Filiale | ja | belegt |
+| StRS-008 | Betrieb wahlweise mit direktem Datenbankzugriff oder über den Web-Service | ja | belegt |
+| StRS-021 | Eindeutige, lückenlos vergebene Belegnummern je Nummernkreis | ja | belegt |
+| StRS-022 | Belegversionen bleiben vollständig erhalten | ja | belegt |
+| StRS-023 | Belege gegen gleichzeitige Änderung schützen | ja | belegt |
+| StRS-024 | Belegerstellung nur mit passendem Recht und passender Filiale | ja | belegt |
+| StRS-025 | Neue Belege bei erreichter Mahnstufe sperren | ja | belegt |
+| StRS-026 | Steuerliche Pflichtangaben des Kunden vor Belegerstellung prüfen | ja | belegt |
+| StRS-027 | Mindestpreisunterschreitung nur mit besonderem Recht | ja | belegt |
+| StRS-028 | Belegstatus und Pflichtangaben je Belegart konfigurierbar | ja | belegt |
+| StRS-029 | Aus Belegen unmittelbar Tickets erzeugen | ja | belegt |
+| StRS-030 | Belegdokumente erzeugen, archivieren und elektronisch signieren lassen | ja | belegt |
+| StRS-031 | Verträge als eigene Belegart mit Laufzeit und Abrechnungsintervall | ja | belegt |
+| StRS-032 | Turnusmäßige Rechnungsstellung aus Verträgen | ja | belegt |
+| StRS-033 | Kontingente im Vertrag führen und verbrauchsabhängig verrechnen | ja | belegt |
+| StRS-034 | Verbrauchsabhängige Vertragsabrechnung aus externen Nutzungsdaten | nein | [HYPOTHESE] |
+| StRS-035 | Klickabrechnung für Druck- und Kopiersysteme | nein | [HYPOTHESE] |
+| StRS-036 | Pauschalabrechnung unabhängig vom Einzelaufwand | ja | belegt |
+| StRS-037 | Rechnungen unmittelbar aus erfassten Ticketzeiten erzeugen | ja | belegt |
+| StRS-038 | Vertriebsprovisionen nach Schema berechnen | ja | belegt |
+| StRS-039 | Provisionen aus dem Vertrag auf Folgebelege übernehmen | ja | belegt |
+| StRS-041 | Dreistufiges Mahnwesen mit protokollierter Stufenerhöhung | ja | belegt |
+| StRS-042 | Offener Betrag berücksichtigt Zahlungen und Gutschriften | ja | belegt |
+| StRS-043 | Steuersätze je Land mit Erlös- und Aufwandskonten | ja | belegt |
+| StRS-044 | Zahlungseingänge erfassen und Rechnungen als bezahlt kennzeichnen | ja | belegt |
+| StRS-045 | SEPA-Lastschriften in mehreren Formatversionen erzeugen | ja | belegt |
+| StRS-046 | Rücknahme eines SEPA-Exports öffnet die Rechnung nachvollziehbar wieder | ja | belegt |
+| StRS-047 | Belegdaten an die Finanzbuchhaltung übergeben und Offene Posten zurücklesen | ja | belegt |
+| StRS-048 | Belege und Belegbilder an DATEV übertragen | nein | [HYPOTHESE] |
+| StRS-049 | Elektronische Rechnungen nach ZUGFeRD und XRechnung | ja | belegt |
+| StRS-051 | Barzahlungen und Kassenbuch führen | ja | belegt |
+| StRS-052 | Einkaufsbelegkette mit eigener Rechtestruktur | ja | belegt |
+| StRS-054 | Belegaustausch mit Distributoren über EDI | ja | belegt |
+| StRS-056 | Artikelstamm mit Preisen, Einheiten und Warengruppen | ja | belegt |
+| StRS-057 | Artikel- und Preisdaten von Distributoren importieren | ja | belegt |
+| StRS-063 | Ticketzeiten sind nach Belegzuweisung unveränderlich | ja | belegt |
+| StRS-065 | Wiederkehrende Serviceabläufe über Ticketprozessvorlagen steuern | ja | belegt |
+| StRS-076 | Managed-Service-Lizenzen sammeln und mit Verträgen abgleichen | ja | belegt |
+| StRS-077 | Reports definieren, drucken, exportieren und zeitgesteuert versenden | ja | belegt |
+| StRS-078 | Anmeldung über mehrere Verfahren mit systemweiter Vorgabe | ja | belegt |
+| StRS-079 | Zweiter Faktor bei der Anmeldung | ja | belegt |
+| StRS-080 | Benutzerkonten zeitlich befristen und deaktivieren | ja | belegt |
+| StRS-081 | Kennwortverwaltung mit Mindestlänge und Änderungsnachweis | ja | belegt |
+| StRS-082 | API-Zugriffstoken mit Ablauf, Sperre und Nutzungsprotokoll | ja | belegt |
+| StRS-083 | Kundenzugangsdaten verschlüsselt verwalten und Zugriffe protokollieren | ja | belegt |
+| StRS-084 | Auskunfts- und Löschanspruch nach DSGVO bedienen | ja | belegt |
+| StRS-092 | Kundenportal mit eigenem Zugang, eigenem Rechtemodell und eigenem Port | ja | belegt |
+| StRS-095 | Outlook-Integration für Belege, Tickets und Kontakte | ja | belegt |
+| StRS-097 | Termine mit Exchange abgleichen, gesteuert über Abteilungszugehörigkeit | ja | belegt |
+| SyRS-001 | Einheitliche Belegstruktur aus Kopf und Positionen | ja | belegt |
+| SyRS-002 | Belege in Folgebelege überführen und Belege kopieren | ja | belegt |
+| SyRS-003 | Filialbezug an Beleg, Mitarbeiter, Rechtegruppe und Lager | ja | belegt |
+| SyRS-005 | Lizenzprüfung bei jeder Anmeldung mit Anzahl-, Ablauf- und Versionsprüfung | ja | belegt |
+| SyRS-006 | Modul- und Einstellungsverfügbarkeit aus Lizenz und Recht ableiten | ja | belegt |
+| SyRS-007 | Rechteermittlung über eine zwischengespeicherte Rechteliste je Benutzer | ja | belegt |
+| SyRS-008 | Rechtebaum mit Elternrechten und Zwangsvergabe übergeordneter Rechte | ja | belegt |
+| SyRS-009 | Sichtbarkeitsstufe aus gewährendem und einschränkendem Recht ableiten | ja | belegt |
+| SyRS-010 | Rechteänderungen werden vollständig protokolliert | ja | belegt |
+| SyRS-013 | Zusatzfelder mit Datentyp und verschlüsseltem Werttyp | ja | belegt |
+| SyRS-017 | Projektzuordnung an Belegen über eine freie Projektnummer | ja | belegt |
+| SyRS-018 | Kampagnenphasen werden zeitgesteuert fortgeschrieben | ja | belegt |
+| SyRS-022 | Produktlebenszyklusdaten werden zeitgesteuert importiert | ja | belegt |
+| SyRS-024 | Produktmatrix als geteiltes Steuerelement in mehreren Oberflächen | ja | belegt |
+| SyRS-026 | Belegversionierung über strukturgleiche Versionstabellen | ja | [HYPOTHESE] |
+| SyRS-027 | Optimistische Nebenläufigkeitsprüfung über einen Belegschlüssel | ja | belegt |
+| SyRS-028 | Belegartspezifische Rechteprüfung über eine austauschbare Fachlogik | ja | belegt |
+| SyRS-029 | Mahnstufensperre je Belegart konfigurierbar | ja | belegt |
+| SyRS-031 | Preisfindung aus mehreren Preisquellen mit Mindestpreisschutz | ja | belegt |
+| SyRS-032 | Anwenderdefinierter Belegstatus getrennt vom Systemstatus | ja | belegt |
+| SyRS-033 | Ticketerzeugung aus Belegen mit Wiederverwendung bestehender Tickets | ja | belegt |
+| SyRS-034 | Belegdokument aus Report, Reportgruppe und Ausgabekonfiguration erzeugen | ja | belegt |
+| SyRS-035 | PDF-Signatur nur bei verfügbarem Zertifikat | ja | belegt |
+| SyRS-036 | Vertragsmerkmale für Laufzeit, Abrechnung, Kontingent und Verlängerung | ja | belegt |
+| SyRS-037 | Vertragsende und Vertragsabschluss werden zeitgesteuert überwacht | ja | belegt |
+| SyRS-038 | Kontingentabrechnung bei abweichenden Intervallen normalisieren | ja | belegt |
+| SyRS-039 | Abbruch der Rechnungserzeugung bei unvollständigen Nutzungsdaten | nein | [HYPOTHESE] |
+| SyRS-040 | Zählerstände als Grundlage der Klickabrechnung | ja | belegt |
+| SyRS-041 | Modulverfügbarkeit über kombinierte Rechte- und Lizenzausdrücke | ja | belegt |
+| SyRS-042 | Abrechnungseinstellungen der Ticketabrechnung als eigene Konfiguration | ja | belegt |
+| SyRS-043 | Provisionsschemas zeitgesteuert auf offene Belege anwenden | ja | belegt |
+| SyRS-045 | Mahnläufe je Kunde mit Vorschau und Reportprüfung | ja | belegt |
+| SyRS-046 | Offene-Posten-Sicht über Rechnungsbeträge, Zahlungen und Gutschriften | ja | belegt |
+| SyRS-047 | Steuersätze werden zeitgesteuert an Artikel und Warengruppen fortgeschrieben | ja | belegt |
+| SyRS-048 | Zahlungseingänge und -ausgänge getrennt führen | ja | belegt |
+| SyRS-050 | Buchhaltungsübergabe mit eigener Belegartzuordnung | ja | belegt |
+| SyRS-051 | Elektronische Rechnung als eigenständige Datei und als eingebettetes PDF | ja | belegt |
+| SyRS-053 | Kassenbuchungen mit eigenem Nummernkreis und Filialbindung | ja | belegt |
+| SyRS-054 | Lieferantenbelege mit eigenen Repositories und externer Belegnummer | ja | belegt |
+| SyRS-055 | Bestellvorschläge und Bestandsdaten zeitgesteuert aktualisieren | ja | belegt |
+| SyRS-058 | Einkaufspreis an der Belegposition nachträglich anpassbar | ja | belegt |
+| SyRS-060 | Artikelimport und Preisaktualisierung laufen als eigenständige Dienste | ja | belegt |
+| SyRS-064 | Ticket mit Bearbeiterzuordnung, Fingerabdruck und Sichtbarkeitsmerkmal | ja | belegt |
+| SyRS-066 | Zeitänderungen prüfen die Zuordnung über den Mitarbeiterartikel | ja | belegt |
+| SyRS-071 | Ticketprojekte mit eigener Sichtbarkeitssteuerung | ja | belegt |
+| SyRS-074 | Eskalationen laufen zeitgesteuert mit eigener Mailvorlage | ja | belegt |
+| SyRS-076 | Auswertungsendpunkte sind einzeln rechtegeschützt | ja | belegt |
+| SyRS-080 | Verbindungsticket als Sitzungsnachweis mit Ablauf und Auffrischung | ja | belegt |
+| SyRS-081 | Abgelaufene Verbindungstickets werden minütlich entfernt | ja | belegt |
+| SyRS-082 | Anmeldeversuche und Anmeldedaten werden protokolliert | ja | belegt |
+| SyRS-083 | Anmeldung über Schnittstellen mit Ticket oder Zugriffstoken | ja | belegt |
+| SyRS-084 | Zugriffstoken protokollieren jeden Aufruf mit Methode und IP-Adresse | ja | belegt |
+| SyRS-085 | Vertrauliche Werte werden symmetrisch mit ableitbarem Schlüssel verschlüsselt | ja | belegt |
+| SyRS-086 | DSGVO-Bereinigung nur mit Recht und freigeschaltetem Modulmerkmal | ja | belegt |
+| SyRS-093 | Web-Portal führt Rechte, Web-Rechte, Lizenzen und Anmeldeart als Ansprüche | ja | belegt |
+| SyRS-094 | Kundenportal ist von der Mitarbeiteroberfläche technisch getrennt | ja | belegt |
+| SyRS-095 | Kundenportal bündelt Belege, Verträge, Tickets, Dokumente und Formulare | ja | belegt |
+| SyRS-096 | Geteilte Dokumente werden über Token und eigene Autorisierung freigegeben | ja | belegt |
+| SyRS-098 | Echtzeitkanäle sind authentifiziert und teils über ein Geheimnis geschützt | ja | belegt |
+| SyRS-103 | Fehler in Schnittstellenaufrufen liefern keine internen Details | ja | belegt |
+| SyRS-107 | Nutzungsdaten werden verdichtet erhoben und zeitgesteuert übertragen | ja | belegt |
+| SyRS-108 | Schutz vor unbeabsichtigtem Mailversand an Kundenadressen | ja | belegt |
+| SyRS-117 | Kommissionierung mit Mengenrückmeldung an den Beleg | ja | belegt |
+| SyRS-121 | Mailversand mit Vorlagen, Variablenersetzung, Signatur und Nachverfolgung | ja | belegt |
+| SyRS-124 | Fremdsysteme melden sich mit eigener Anwendungsart, Lizenz und Ablaufregel an | ja | belegt |
+| SyRS-126 | Länderstammdaten mit Währungskurs und steuerlicher Vorbelegung | ja | belegt |
+| SyRS-127 | Kostenstelle und Kostenträger je Belegart als Pflichtangabe steuerbar | ja | belegt |
+| SyRS-129 | Verbindungsdaten liegen in einer Datei mit verschlüsseltem Kennwort | ja | belegt |
+| SwRS-001 | Abstrakte Belegbasisklasse mit Pflichtmethoden | ja | belegt |
+| SwRS-005 | Lizenzzugriff über eine Schnittstelle mit Einzelinstanz und Prüfattrappe | ja | belegt |
+| SwRS-006 | Rechteabfrage als parametrisierte SQL-Abfrage über zwei Zuordnungstabellen | ja | belegt |
+| SwRS-007 | Rechtestruktur mit Elternverweis, Kinderzähler und Veraltungskennzeichen | ja | belegt |
+| SwRS-008 | Sichtbarkeitsstufe als eigener Aufzählungstyp | ja | belegt |
+| SwRS-009 | Rechteprotokoll als eigene Entität mit Vorgangsart | ja | belegt |
+| SwRS-012 | Auflösung der Datenzugriffsschicht über einen Dienstbehälter | nein | [HYPOTHESE] |
+| SwRS-020 | Lieferantenverträge über die dreiteilige Zugriffskette | nein | [HYPOTHESE] |
+| SwRS-021 | Stammblatt als Kopf-Positions-Entität im Belegzweig | ja | belegt |
+| SwRS-025 | Produktmatrix als geteiltes Steuerelement mit eigener Fachlogik | ja | belegt |
+| SwRS-029 | Belegartabhängige Fachlogik über einen Verteiler mit Ausdrucksparameter | ja | belegt |
+| SwRS-030 | Mahnstufe des Kontos über eine gemeinsame Kontoinformation | ja | belegt |
+| SwRS-031 | Steuerliche Kundenangaben als eigene Felder am Kunden | ja | belegt |
+| SwRS-032 | Preisermittlung in eigenen Hilfsklassen der Belegverarbeitung | ja | belegt |
+| SwRS-034 | Ticketerzeugung aus Belegen über vorbereitete Informationsobjekte | ja | belegt |
+| SwRS-036 | Vertragsentität mit Schnittstellen für Kontingent, Status und Provision | ja | belegt |
+| SwRS-037 | Vertragsabrechnung als Teilklasse mit deutschsprachigen Zwischenobjekten | ja | belegt |
+| SwRS-038 | Abrechnungsparameter als eigenes Übergabeobjekt | ja | belegt |
+| SwRS-039 | Kontingentänderungen erzeugen einzelne Protokolleinträge je Merkmal | ja | belegt |
+| SwRS-041 | Verdichtete Stammblattobjekte für die Klickabrechnung | ja | belegt |
+| SwRS-042 | Modulregistrierung als Datensatz mit Rechte- und Lizenzausdruck | ja | belegt |
+| SwRS-043 | Belegerzeugung aus Zeiten mit eigenen Ergebnisobjekten | ja | belegt |
+| SwRS-044 | Provisionsdaten in Schema-, Positions- und Zielentitäten | ja | belegt |
+| SwRS-046 | Mahnlauf mit Reportparametern und je Kunde gebündelten Rechnungen | ja | belegt |
+| SwRS-047 | Rechnungsbeträge als getrennte Felder für Brutto, Zahlung und Gutschrift | ja | belegt |
+| SwRS-048 | Steuersatz mit Kontozuordnung und Nachfolgeverweis | ja | belegt |
+| SwRS-049 | Zahlungsentitäten mit eigenem Protokoll und Löschfilter | ja | belegt |
+| SwRS-051 | Buchhaltungsschnittstelle mit eigener Belegartabbildung | ja | belegt |
+| SwRS-052 | Elektronische Rechnung als eigene Erzeugungslogik mit XML-Aufbau im Code | ja | belegt |
+| SwRS-053 | Bankzugriff über gekapselte Klienten mit eigener Fehlerklasse | ja | belegt |
+| SwRS-054 | Kassenvorgänge als eigener Fachbereich | ja | belegt |
+| SwRS-055 | Lieferantenbelege mit eigenen Fachlogikordnern und Speicherrepositories | nein | [HYPOTHESE] |
+| SwRS-058 | Einkaufspreisänderung positionsweise und belegweit mit Speicherentscheidung | ja | belegt |
+| SwRS-066 | Zeitrechteprüfung in der Web-Service-Schicht statt in der Fachlogik | ja | belegt |
+| SwRS-081 | Zwei-Faktor-Prüfung über austauschbare Prüfverfahren | ja | belegt |
+| SwRS-082 | Benutzerkonto trägt Sperrzeitraum, Anmeldedaten und Anmeldeverfahren | ja | belegt |
+| SwRS-083 | Kennwortrichtlinie je Benutzer statt systemweit | ja | belegt |
+| SwRS-084 | Kennwortablage als ungesalzener SHA-1-Hash über eine Einbyte-Kodierung | ja | belegt |
+| SwRS-085 | Zugriffstoken mit Hashablage, Ablaufmerkmal und Weichlöschung | ja | belegt |
+| SwRS-086 | Symmetrische Verschlüsselung mit aus dem Schlüssel abgeleitetem Initialisierungsvektor | ja | belegt |
+| SwRS-087 | DSGVO-Löschung derzeit nur für Ansprechpartner umgesetzt | ja | belegt |
+| SwRS-094 | Portalrichtlinien werden aus Rechtekonstanten durch Reflexion erzeugt | ja | belegt |
+| SwRS-095 | Kundenportalport als eigene Konfigurationsklasse mit Vorrang bei fehlendem Wert | ja | belegt |
+| SwRS-110 | Entwicklerschutz als statische Klasse mit Buildabhängigkeit | ja | belegt |
+| SwRS-111 | Mobile Datensicht mit eigenem Datenzugriffsordner | ja | belegt |
+| SwRS-125 | Textbausteine mit eigener Ersetzungsklasse und eigenem Datenzugriff | ja | belegt |
+| SwRS-128 | Zuschlagssätze mit eigener Fachlogik und Belegzuordnung | ja | belegt |
+| SwRS-139 | Datenbankdiagnose als lesende Auswertungsklasse | ja | belegt |
+| SwRS-141 | Web-Konten mit eigener Verwaltung und eigener Kennwortänderung | ja | belegt |
+| SwRS-143 | Persistenzschicht mit Sitzung, generischem Zugriff und benannten Abfragen | ja | belegt |
+| SwRS-148 | Preisimporte für Projekte und Verträge als getrennte Module | ja | belegt |
+| SwRS-150 | Belegkonditionen mit Skontostufen und Gültigkeit je Belegart | ja | belegt |

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-a8f5/Protokoll.md

@@ -0,0 +1,208 @@
+# Messprotokoll – Versuch 01 (V1 Baseline, Prompt-only) – Iteration 02
+
+## Lauf
+- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
+- **Iteration:** 02 – vom User ausdrücklich benannt; entspricht zugleich der Regel „höchste
+  vorhandene Iterationsnummer". Wiederholungslauf zur Varianzbestimmung in derselben Zelle.
+- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
+- **Startzeit:** 2026-08-26T13:22:45.8887651+02:00
+- **Endzeit:** 2026-08-26T14:57:34.0567156+02:00
+- **Dauer gesamt:** 1:34:48 (`duration_ms` 1:34:46; API: 1:31:21)
+  — **im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar**
+- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.662 versionierte Dateien)
+- **Codebasis-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748` (dirty: nein)
+- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja (Prüfmuster ohne Treffer);
+  die Codebasis ist seit Commit `f045b99a` kein eigenes Repository mehr, sondern Teil des
+  Arbeitsrepos – der Vorher/Nachher-Vergleich läuft deshalb pfadskopiert
+- **Snapshot-Zusatzartefakte:** keine – der Snapshot entspricht dem Commit-Stand
+- **Prompt-Repo-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748`
+
+## Werkzeugkonfiguration
+- **Skill-Version:** 4.4.0
+- **Claude-Code-Version:** 2.1.246
+- **CLI-Pfad:** `C:\Users\ChristophSchwoerer\.vscode\extensions\anthropic.claude-code-2.1.246-win32-x64\resources\native-binary\claude.exe`
+- **Modell (angefordert):** `claude-opus-5`
+- **Modelle (tatsächlich eingesetzt):** `claude-opus-5` 67.483.129 Tokens (99.99 %), `claude-haiku-4-5-20251001` 6.968 Tokens (0.01 %)
+- **Kontrolle Modell:** bestanden – ausschließlich das angeforderte Modell plus Haiku als zulässiger interner Hilfsaufruf
+- **Effort:** `max` (per `--effort max` gesetzt)
+- **Laufverzeichnis-ID:** `v4.4.0-a8f5`
+- **Ablage:** `Iteration 3/claude-opus-5/solo/max/`
+- **Parallele Läufe:** **ja** – zeitgleich liefen:
+  - `Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-37c5`
+  - `Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-fcdf`
+  - `Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048`
+  - `Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-f8b4`
+  - `Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-fb24`
+
+  Die Zeitangaben dieses Laufs sind daher **nicht** für Laufzeitvergleiche zu verwenden. Tokenverbrauch, Anforderungszahl, Belegkennzahlen und Denials bleiben unverzerrt.
+- **Agentenmodus:** `solo` (V1)
+- **Kontextfenster:** 1.000.000 Tokens; `maxOutputTokens` 64.000
+- **Sampling-Parameter:** nicht steuerbar über die CLI, nicht erfasst
+- **Nur bei lokalem Modellbetrieb:** entfällt (Cloud-Inferenz, `provider: firstParty`)
+- **Permission-Mode:** `acceptEdits`
+- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` /
+  `--disallowedTools` 33er-Denylist (schreibende und bauende Kommandos) **zuzüglich** `Task`, `Agent`, `Workflow` aus dem Modus `solo`
+- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
+- **MCP-Server / Agentendateien:** keine – aus dem Snapshot entfernt, zusätzlich `--safe-mode`
+- **Subagenten:** keine (`spawned` = 0, `by_type` leer)
+- **Verschachtelung:** `spawned` = 0, davon `spawned_by_subagents` = 0, `max_depth` = 0. Keine tieferen Ebenen, `_meta\subagenten.md` entfällt.
+
+## Validierungsstichprobe
+- **Größe:** noch nicht festgelegt
+- **Ziehungsverfahren:** noch nicht festgelegt
+- **Validatoren:** noch nicht festgelegt
+- **Stand:** noch nicht gezogen
+
+## Verbrauch
+
+### Hauptagent (`usage`)
+| Messgröße | Wert |
+|---|---:|
+| Input-Tokens | 294 |
+| Output-Tokens | 503.451 (davon 51.019 Thinking-Tokens) |
+| Cache-Write-Tokens | 823.212 |
+| Cache-Read-Tokens | 66.156.172 |
+| Agent-Turns | 210 |
+
+### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
+| Messgröße | `claude-opus-5` | `claude-haiku-4-5-20251001` | Summe |
+|---|---:|---:|---:|
+| Input-Tokens | 294 | 6.945 | 7.239 |
+| Output-Tokens | 503.451 | 23 | 503.474 |
+| Cache-Write-Tokens | 823.212 | 0 | 823.212 |
+| Cache-Read-Tokens | 66.156.172 | 0 | 66.156.172 |
+| **Tokens gesamt** | **67.483.129** | **6.968** | **67.490.097** |
+
+**Tokens gesamt: 67.490.097** — Input + Output + Cache-Write + Cache-Read über alle Modelle.
+Das ist die **berichtete Aufwandsgröße** der Versuchsreihe. `total_cost_usd` bleibt unberührt in
+`RawResult.json` erhalten, wird aber nicht ins Protokoll übernommen: Token sind modell- und
+preisunabhängig und bleiben damit über Preisänderungen und Modellwechsel hinweg vergleichbar.
+
+Da im Modus `solo` keine Subagenten laufen, sind `usage` und `modelUsage` für das Hauptmodell
+deckungsgleich; die Differenz zur Summe stammt allein aus den Haiku-Hilfsaufrufen.
+
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 100 | 26,3 % |
+| SyRS | 130 | 34,2 % |
+| SwRS | 150 | 39,5 % |
+| **Gesamt** | **380** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 136 | 35,8 % |
+| Daten | 91 | 23,9 % |
+| Schnittstelle | 80 | 21,1 % |
+| Sicherheit | 49 | 12,9 % |
+| nicht-funktional | 24 | 6,3 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 740 |
+| davon `PRIMÄR` | 576 (77,8 %) |
+| davon `SEKUNDÄR` | 155 (20,9 %) |
+| davon `KONTEXT` | 9 (1,2 %) |
+| Belege je Anforderung (Median) | 2,0 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 363 (95,5 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 356 | 93,7 % |
+| workaround | 24 | 6,3 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 365 | 96,1 % |
+| als `HYPOTHESE` gekennzeichnet | 15 | 3,9 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 132 | 34,7 % |
+| mit ISO-25010-Qualitätsmerkmal | 24 | 6,3 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (112 risikorelevante Anforderungen, alle gedeckt) |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 380 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 380 von 380 mit Tracelinks (100,0 %) |
+
+## Ergebnis
+- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
+- **Session-ID:** `62ec9981-4359-4963-8ef4-0100eb996357`
+- **Permission-Denials:** 4 (3 × `Bash`, 1 × `PowerShell`) – **keines auf `Task`/`Agent`/`Workflow`**. Der Agent hat zu keinem Zeitpunkt zu delegieren versucht; die Modus-Sperre wurde nie ausgelöst.
+- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0 – Bedingung `solo` eingehalten
+- **Subagenten-Prompts:** entfällt (Modus `solo`)
+- **Erzeugte Dateien:** 10 Dateien in `Ergebnisse\`:
+
+  | Datei | Größe |
+  |---|---:|
+  | `Analysebericht.md` | 75.345 B |
+  | `Glossar.md` | 21.348 B |
+  | `Hypothesen.md` | 21.334 B |
+  | `StRS.md` | 206.813 B |
+  | `SwRS.md` | 232.413 B |
+  | `SyRS.md` | 232.002 B |
+  | `Traceability.md` | 43.356 B |
+  | `_coverage_tmp.txt` | 10.474 B |
+  | `_risk_tmp.txt` | 15.673 B |
+  | `_trace_tmp.json` | 149.015 B |
+
+- **Root unverändert:** ja (zeilenendennormalisiert verglichen).
+- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
+
+## Anmerkungen/Auffälligkeiten
+
+**1. Iteration 3 – Snapshot mit DB-Schema.** `SSMS_DB_SCHEMA.sql` (3.266.626 B, 76.793 Zeilen,
+1.558 Tabellen, 182 Views, 63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel; SHA-256
+`ED7F2125…1FA8DB`) ist seit Commit `f349d189` Bestandteil des Untersuchungsgegenstands. Läufe der
+Iteration 2 hatten die Datei nicht – beide Iterationen sind **nicht poolbar**.
+
+**2. Parallelbetrieb – Zeitangaben unbrauchbar, Verbrauchsgrößen gültig.** Wanduhrzeit,
+`duration_ms` und `duration_api_ms` sind verzerrt; Tokenverbrauch, Anforderungszahl,
+Belegkennzahlen und Denials nicht. Einziger gültiger Laufzeitmesspunkt aller drei Iterationen
+bleibt der serielle Lauf `084301_v4.2.0-d6f9` mit 45:04.
+
+**3. CLI 2.1.246** statt der gegen 2.1.245 verifizierten Fassung.
+
+**4. Der erste Lauf, der die Belegdichte durchbricht: Median 2,0 statt 1,0.** Über alle 44
+vorherigen Läufe der Versuchsreihe lag der Median konstant bei **einem** Beleg je Anforderung –
+der Befund, wegen dem Prompt-Version 02 überhaupt geschrieben wurde und den die Prompt-Änderung
+allein nicht auflösen konnte. Hier: 740 Belege auf 380 Anforderungen. Nicht die Anweisung hat das
+bewirkt, sondern der Denkaufwand.
+
+**5. 112 risikorelevante Anforderungen, keine einzige ungedeckt.** Mehr als das Doppelte jedes
+`high`-Laufs (17–63). Die risikobasierte Priorisierung aus Schritt 0c ist vollständig erfüllt,
+Tracelinks bei 100 %, 95,5 % mit Primärbeleg.
+
+**6. Der `max`-Effort zeigt sich nicht in mehr Thinking-Tokens.** 51.019 Thinking-Tokens liegen im
+Bereich der `high`-Läufe (33.051–55.760). Der Mehraufwand steckt in **210 Turns und 1:34:46
+Laufzeit** – mehr Arbeitsschritte, nicht längeres Grübeln je Schritt. Das relativiert die
+Vermutung aus Iteration 1, `max` sei primär an den Thinking-Token-Werten erkennbar; dort waren
+Modell und Effort gleichzeitig gewechselt worden.
+
+**7. Modellkontrolle bestanden** (nur `claude-opus-5` + Haiku), `spawned` = 0 – die
+`solo`-Bedingung ist eingehalten.
+
+**8. Drei Streudateien im Ergebnisordner – Folge der Denylist.** `_coverage_tmp.txt`,
+`_risk_tmp.txt` und `_trace_tmp.json` (149 K). Vier Denials, darunter ein `mv` und ein
+`Remove-Item` zum Aufräumen. Die Dateien bleiben bewusst liegen: Nachträgliches Löschen würde die
+Artefaktlage des Laufs verändern. Das Muster ist inzwischen bei 5 von 17 Läufen aufgetreten und
+gehört zur Werkzeugkonfiguration, nicht zum Modell.

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-a8f5/_meta/anforderungen.md

@@ -0,0 +1,63 @@
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 100 | 26,3 % |
+| SyRS | 130 | 34,2 % |
+| SwRS | 150 | 39,5 % |
+| **Gesamt** | **380** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 136 | 35,8 % |
+| Daten | 91 | 23,9 % |
+| Schnittstelle | 80 | 21,1 % |
+| Sicherheit | 49 | 12,9 % |
+| nicht-funktional | 24 | 6,3 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 740 |
+| davon `PRIMÄR` | 576 (77,8 %) |
+| davon `SEKUNDÄR` | 155 (20,9 %) |
+| davon `KONTEXT` | 9 (1,2 %) |
+| Belege je Anforderung (Median) | 2,0 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 363 (95,5 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 356 | 93,7 % |
+| workaround | 24 | 6,3 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 365 | 96,1 % |
+| als `HYPOTHESE` gekennzeichnet | 15 | 3,9 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 132 | 34,7 % |
+| mit ISO-25010-Qualitätsmerkmal | 24 | 6,3 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (112 risikorelevante Anforderungen, alle gedeckt) |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 380 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 380 von 380 mit Tracelinks (100,0 %) |
+

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-a8f5/_meta/before.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-a8f5/_meta/combined_prompt.md

@@ -0,0 +1,177 @@
+# Versuch 01 - Baseline (Prompt-only) - Iteration 02
+
+## Metadaten
+- **Versuch:** V1 Baseline (Prompt-only)
+- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
+- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
+- **Zeitstempel:** 2026-08-26
+- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
+- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
+
+  | Änderung | Auslösender Befund |
+  |---|---|
+  | Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
+  | Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
+  | Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
+  | Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
+  | Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
+  | Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
+  | Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
+
+  Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
+
+> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
+> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
+> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
+
+---
+
+## Prompt
+
+Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
+
+### Auftrag
+
+Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
+
+1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
+2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
+3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
+
+Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
+
+### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
+
+Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
+
+**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
+
+### Vorgehen (statische Analyse, keine Ausführung)
+
+Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
+
+**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
+
+**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig.
+
+**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
+
+2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
+3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
+4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
+5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
+6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
+
+### Pflicht-Eigenschaften jeder Anforderung
+
+- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
+- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
+- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
+- **Belegklassifikation:** Kennzeichne jeden Beleg als
+  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
+  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
+  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
+- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
+- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
+- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
+- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
+- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
+
+### Formatvorgabe pro Anforderung
+
+```
+ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
+Titel:         <kurzer Titel>
+Ebene:         <StRS | SyRS | SwRS>
+Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
+Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
+Akteur:        <Rolle / System / Komponente>
+Vorbedingung:  <Zustand vor Auslösen>
+Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
+Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
+Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
+Belege:
+  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
+  - [SEKUNDÄR] <...> - Begründung: <...>
+  - [KONTEXT]  <...> - Begründung: <...>
+Prüfidee:      <Akzeptanzkriterium oder Testidee>
+Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
+Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
+Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
+Status:        <belegt | HYPOTHESE>
+```
+
+### Traceability
+
+Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
+- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
+- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
+- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
+
+### Nicht-funktionale Anforderungen
+
+- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
+- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
+
+### Konsolidierungsbedarf
+
+Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
+
+**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
+
+### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
+
+```
+Ergebnisse/
+  StRS.md
+  SyRS.md
+  SwRS.md
+  Traceability.md   (oder Traceability.csv)
+  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
+  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
+  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
+                     Selbstbewertung, bekannte Lücken)
+```
+
+Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
+
+### Randbedingungen
+
+- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
+- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
+- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
+- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
+- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
+
+### Abschluss
+
+Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
+- Doppelte oder mehrfach vergebene IDs
+- Anforderungen ohne Beleg
+- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
+- Tracelinks auf nicht existierende IDs
+- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
+- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
+- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
+
+Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
+
+Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
+- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
+- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
+- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
+- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
+- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
+
+---
+
+### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
+Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien sowie das Ausführen von
+Kommandozeilenbefehlen im Arbeitsverzeichnis.
+Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.
+Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
+Werkzeuge zu ersetzen.
+### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
+Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
+`c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 3\claude-opus-5\solo\max\02_Lauf_2026-08-26_132237_v4.4.0-a8f5\Ergebnisse\`.
+Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-a8f5/_meta/endzeit.txt

@@ -0,0 +1 @@
+2026-08-26T14:57:34.0567156+02:00

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-a8f5/_meta/startzeit.txt

@@ -0,0 +1 @@
+2026-08-26T13:22:45.8887651+02:00

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-fcdf/Ergebnisse/Analysebericht.md

@@ -0,0 +1,970 @@
+# Analysebericht
+
+**Gegenstand:** Reverse Requirements Engineering der c-entron ERP-Suite
+**Arbeitsverzeichnis:** `C:\DEV\MasterArbeit\QuellCode\CentronERP` (ausschließlich lesend verwendet)
+**Bezugsnorm:** ISO/IEC/IEEE 29148:2018 (StRS §9.3, SyRS §9.4, SRS §9.5), Qualitätsmerkmale nach ISO/IEC 25010
+**Verfahren:** rein statische Analyse; das System wurde nicht ausgeführt, es bestand kein Datenbank- und kein Laufzeitzugriff
+**Ergebnisdateien:** `StRS.md`, `SyRS.md`, `SwRS.md`, `Traceability.md`, `Hypothesen.md`, `Glossar.md`, `Analysebericht.md`
+
+---
+
+## 1 Zusammenfassung
+
+| Kennzahl | Wert |
+|----------|------|
+| Anforderungen gesamt | **446** |
+| davon StRS / SyRS / SwRS | 150 / 155 / 141 |
+| Als `[HYPOTHESE]` gekennzeichnet | **36** (8,1 %) |
+| Module im Inventar (Schritt 0) | **176** |
+| davon `tief` / `mittel` / `flach` / `nicht analysiert` | 12 / 67 / 77 / 20 |
+| Belege gesamt | **1.255** |
+| davon `PRIMÄR` / `SEKUNDÄR` / `KONTEXT` | 1.067 (85,0 %) / 111 (8,8 %) / 77 (6,1 %) |
+| Belege je Anforderung (Minimum / Mittel / Maximum) | 1 / 2,81 / 4 |
+| Risikorelevante Anforderungen | **227** |
+| davon ohne `PRIMÄR`-Beleg | **0** |
+| Anforderungen mit Konsolidierungskandidat | **141** |
+| Tracelink-Ziele (eindeutig) | 368, davon nicht auflösbar: **0** |
+
+### Vermessung der Codebasis
+
+Die folgenden Zahlen wurden im Lauf durch Zählung im Arbeitsverzeichnis ermittelt und tragen mehrere Anforderungen; sie sind hier zusammengefasst, weil sie den Umfang des Analysegegenstands bestimmen.
+
+| Gegenstand | Anzahl | Ermittlung |
+|------------|--------|------------|
+| C#-Quelldateien (`*.cs`) | 14.707 | Dateizählung ohne `obj`/`bin` |
+| WPF-Oberflächendateien (`*.xaml`) | 1.233 | Dateizählung |
+| Blazor-Komponenten (`*.razor`) | 491 | Dateizählung |
+| Tabellen im Schemaabzug | 1.535 | `CREATE TABLE` im SQL-Dump |
+| Sichten | 153 | `CREATE VIEW` |
+| Gespeicherte Prozeduren | 59 | `CREATE PROCEDURE` |
+| Fremdschlüssel | 134 | `FOREIGN KEY` |
+| Prüfbedingungen (`CHECK`) | 288 | `CHECK CONSTRAINT` |
+| Tabellen mit Präfix `AssetManagement` | 221 | Namenszählung im Schemaabzug |
+| Operationen der Legacy-Schnittstelle | 2.618 | `WebInvoke`-Attribute |
+| davon ohne `[Authenticate]` | 171 | Attributauswertung je Operationsblock |
+| Controller der modernen REST-API | 41 | Dateizählung `*Controller.cs` |
+| Datenbank-Skriptmethoden | 764 | `IScriptMethod`-Umsetzungen |
+| Hintergrunddienste | 35 | `ManagedBackgroundService`-Ableitungen |
+| Dokumentationsdateien unter `docs/` | 44 | Dateizählung |
+
+---
+
+## 2 Vorgehen im Lauf
+
+Die Bearbeitung folgte der im Auftrag vorgegebenen Reihenfolge.
+
+**Schritt 0 – Modulinventar.** Vor der ersten Anforderung wurde das Inventar in Abschnitt 3 erstellt. Grundlage waren vier voneinander unabhängige Quellen: die Projektmappenstruktur unter `src/`, die Modulregistrierung `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs` (rund 70 Registrierungen in 13 fachlichen Blöcken), die Ordnerstruktur von `src/backend/Centron.BL` und der Schemaabzug der Datenbank. Das Inventar wurde im Verlauf zweimal erweitert – um Bereiche, die erst über die Registrierung sichtbar wurden, und um schichtübergreifende Bausteine (M140 bis M156), die keinem Fachmodul zuzuordnen sind, aber eigene Anforderungen tragen. Es wurde zu keinem Zeitpunkt gekürzt.
+
+**Schritt 0b – Mindestabdeckung.** Für 156 der 176 Inventarzeilen wurde mindestens eine belegte Anforderung gebildet, bevor einzelne Bereiche vertieft wurden. Für 20 Zeilen war das nicht möglich; sie sind in der Abdeckungstabelle als `nicht analysiert` mit Begründung geführt (Abschnitt 4). Eine Inventarzeile ohne Anforderung und ohne Begründung gibt es nicht.
+
+**Schritt 0c – Vertiefung nach Risiko.** Vertieft wurden zuerst die Bereiche mit Sicherheitsregeln, Abrechnungslogik und Rechteprüfungen: Anmeldung und Rechtemodell (M003, M004), Belegberechtigung (M025), Nummernkreisvergabe (M007), Vertragsabrechnung (M039 bis M042), Mahnwesen und Zahlungsverkehr (M071 bis M073) sowie die beiden Schnittstellen (M113, M114). Die Vertiefung ging jeweils bis auf die durchsetzende Stelle – Datei, Klasse, Methode und die konkrete Bedingung.
+
+**Schritte 2 bis 6.** Die Artefakterhebung stützte sich auf Quelltext, Schemaabzug, Ressourcendateien, Konfigurationsdateien, Bereitstellungsartefakte und die 44 Dokumentationsdateien unter `docs/`. Änderungshistorie, Tickets und Freigabemitteilungen standen als lesbare Dateien nicht zur Verfügung; sie wurden entsprechend nicht ausgewertet, und keine Aussage stützt sich auf sie. Die technische Analyse erfolgte über Struktur-, Aufruf- und Schemabetrachtung, die semantische Interpretation über die Trennung von `Fakt` und `Aussage`, die Formalisierung über das vorgegebene Blockformat und die Traceability-Anreicherung über Vorwärts- und Rückwärtsverweise zwischen den drei Ebenen.
+
+**Belegdisziplin.** Jede Anforderung trägt mindestens einen Beleg mit Begründung. Wo eine Aussage nicht belegt werden konnte, wurde die Anforderung entweder nicht geschrieben oder – wo der fachliche Gegenstand nachweisbar existiert, die Ausprägung aber nicht – als `[HYPOTHESE]` mit offener Frage geführt. Quantitative Angaben (Anzahlen von Dateien, Tabellen, Operationen, Rechten) wurden vor der Aufnahme in eine Anforderung einzeln nachgezählt; mehrere zunächst geschätzte Werte wurden dadurch korrigiert (Abschnitt 5.5).
+
+---
+
+## 3 Schritt 0 – Modulinventar
+
+Das Inventar ist die Bezugsgröße der Abdeckung. Es benennt fachliche Module und Komponenten, nicht Projektdateien: mehrere Inventarzeilen können auf dieselbe Projektdatei verweisen, wenn sie unterschiedliche fachliche Aufgaben erfüllt, und eine Inventarzeile kann mehrere Pfade zusammenfassen, wenn dieselbe fachliche Aufgabe über Schichten verteilt umgesetzt ist. Die Zeilen M140 bis M156 bezeichnen schichtübergreifende Bausteine, die Zeilen M157 bis M176 die nicht analysierten Bereiche.
+
+| Nr. | Fachliches Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
+|-----|-------------------------------|----------------------------|-------------------|
+| M001 | Mandantenverwaltung | `src/backend/Centron.Entities/Entities/Administration/Company, src/backend/Centron.BL/Administration/Mandatory, Modules/Administration/MandatorManagement` | Führt die rechtlichen Einheiten mit Firmen-, Steuer- und Bankstammdaten. |
+| M002 | Filialverwaltung | `src/backend/Centron.Entities/Entities/BranchArea, src/backend/Centron.BL/Administration/Company/BranchBL.cs` | Gliedert einen Mandanten in Standorte mit eigener Anschrift und Buchhaltungsnummer. |
+| M003 | Benutzer- und Anmeldeverwaltung | `src/backend/Centron.BL/Administration/Logins, Modules/Administration/Connections` | Authentifiziert Mitarbeiter, prüft Kontogültigkeit und gibt Anmeldetickets aus. |
+| M004 | Rechteverwaltung | `src/backend/Centron.BL/Administration/Rights, Modules/Administration/RightsManagement, Centron.Controllers/Authorization` | Verwaltet das hierarchische Rechtemodell und setzt es an drei Stellen durch. |
+| M005 | Zwei-Faktor-Authentifizierung | `src/backend/Centron.BL/Administration/Logins/TwoFactor, Centron.Controllers/Controllers/Unversioned/TwoFactorAuthController.cs` | Erbringt einen zweiten Anmeldenachweis über RADIUS oder E-Mail-Bestätigungslink. |
+| M006 | Microsoft-Anmeldung (OpenID Connect) | `src/backend/Centron.BL/Administration/Logins/Auth/OpenIdConnectAuthenticator.cs, Centron.Controllers/Controllers/Unversioned/JwtAuthController.cs` | Bindet Microsoft Entra ID als Anmeldeverfahren an. |
+| M007 | Nummernkreisverwaltung | `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs, MandatoryBL.GetNumberGroup` | Vergibt fortlaufende Nummern je Nummernart, Mandant und Filiale. |
+| M008 | Lizenzverwaltung | `src/backend/Centron.BL/Administration/Licensing, Modules/Administration/WebServiceSettings/LicenseSettings` | Steuert den nutzbaren Funktionsumfang über Lizenz-Guids mit Anzahl und Fristen. |
+| M009 | Zugangstokenverwaltung | `src/backend/Centron.BL/Administration/AccessTokens, Centron.Controllers/Controllers/v1/Administration/AccessTokensController.cs` | Gibt benannte Token für Systemintegrationen aus und protokolliert ihre Verwendung. |
+| M010 | Webaccount-Verwaltung | `src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs, WebRightsVisibility.cs` | Verwaltet Portalzugänge von Kundenkontakten mit eigenem Rechtekatalog. |
+| M011 | Änderungsprotokollierung | `src/backend/Centron.DAO/ChangeTracking, src/backend/Centron.Entities (Log-Entitäten)` | Protokolliert Änderungen überwachter Eigenschaften automatisch in der Persistenzschicht. |
+| M012 | DSGVO / Datenschutz | `src/backend/Centron.BL/Administration/DataSecurity, Modules/Administration/DSGVO` | Wertet löschbare Bestände aus und löscht personenbezogene Daten kaskadierend mit Protokoll. |
+| M013 | Passwort-Manager | `src/backend/Centron.BL/PasswordManager, PasswordManagementArea, Administration/CentronConfigDb` | Speichert Kundenzugangsdaten verschlüsselt mit Rechteschutz, Siegel und Zugriffsprotokoll. |
+| M014 | Kontenmodell und Adressen | `src/backend/Centron.BL/Accounts, Modules/Finances/AccountManagement, Modules/Finances/Crm` | Führt Geschäftspartner mit Rollen, Adressen und Ansprechpartnern. |
+| M015 | CRM-Aktivitäten | `src/backend/Centron.BL/CustomerArea/ContactActivityBL.cs` | Dokumentiert Kundenkontakte als datierte, auswertbare Aktivitäten. |
+| M016 | Kampagnen und Mailing | `src/backend/Centron.Entities/Entities/Accounts/Campaigns, Modules/Finances/Campaigns, Modules/Sales/Mailing` | Führt Marketingkampagnen mit Phasen, Aktionen und Teilnehmern. |
+| M017 | CRM-Projekte | `src/backend/Centron.BL/Sales/Customers/CrmProjects, Modules/Finances/Projects` | Bündelt Vertriebsvorgänge unter einer eigenen Projektnummer. |
+| M018 | Audits und Fragebögen | `src/backend/Centron.Entities/Entities/Accounts/Survey, Modules/Survey` | Erfasst strukturierte Kundenaudits mit Fragenkategorien und Freigabeprozess. |
+| M019 | Preisfindung und Sonderpreise | `src/backend/Centron.Entities/Entities/Accounts/SpecialPrices, ReceiptPriceHelperBL, ArticleVolumePricesBL` | Ermittelt den Positionspreis aus Preisliste, Sonderpreis, Staffel, Vertrag und Aktionspreis. |
+| M020 | Bankverbindungen und SEPA-Mandate | `src/backend/Centron.Entities/Entities/Administration/Documents/SepaContracts, Accounting/BankAccountBL.cs` | Führt Bankverbindungen und Einzugsermächtigungen je Geschäftspartner. |
+| M021 | Stammblätter (Gerätedokumentation) | `src/backend/Centron.Entities/Entities/Sales/Receipts/MasterDataLists, Modules/Finances/MasterDataLists` | Dokumentiert beim Kunden installierte Geräte mit Seriennummer, Rechnungs- und Vertragsbezug. |
+| M022 | Kundengeräteverwaltung | `src/backend/Centron.BL/Devices, src/backend/Centron.Entities/Entities/Devices` | Führt Kundengeräte mit Zugriffsadressen, Ticketbezug und Protokoll. |
+| M023 | Belegkern | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Centron.Entities/Entities/Sales/Receipts` | Bildet alle Belegarten einheitlich ab und steuert Erzeugung, Weiterführung und Speicherung. |
+| M024 | Belegzustände und Stornierung | `src/backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs, ReceiptBL` | Führt die drei Belegzustände und sperrt stornierte Belege gegen Folgeaktionen. |
+| M025 | Belegberechtigung | `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (CanUserEditReceipt, CanUserViewReceipt)` | Bindet Bearbeitung und Ansicht von Belegen an belegartspezifische Rechte und die Filiale. |
+| M026 | Belegversionierung | `Versionstabellen je Belegart, AssetHeadDAO.SaveAssetVersion` | Legt vor jeder Belegänderung eine vollständige Kopie des Vorzustands ab. |
+| M027 | Nebenläufigkeitsschutz | `ReceiptBase.ConcurrencyControlGuid, AssetLock, AssetLockBL` | Erkennt konkurrierende Änderungen und lehnt die zweite Änderung ab. |
+| M028 | Zahlungs- und Belegkonditionen | `Tabelle Zahkond, Modules/Administration/ReceiptConditions` | Führt Skontostaffeln, Fälligkeitsregeln und belegartbezogene Gültigkeit. |
+| M029 | Mehrwertsteuerverwaltung | `src/backend/Centron.BL/Warehousing/TaxBL.cs, Modules/Stammdaten/ValueAddedTax` | Führt Steuersätze als datierte Kette und ermittelt den zum Belegdatum gültigen Satz. |
+| M030 | Währungen und Fremdwährungsbelege | `ReceiptBase (CurrencyI3D, CurrencyFactor), CountryBL` | Führt Belege in Fremdwährung mit Umrechnungsfaktor. |
+| M031 | Belegvorlagen | `src/backend/Centron.BL/Sales/Receipts/ReceiptTemplateBL.cs, Entities/Sales/Receipts/Templates` | Verwaltet Belegmuster mit eigener Nummernvergabe und Ordnerstruktur. |
+| M032 | Provisionsabrechnung | `src/backend/Centron.BL/Sales/Receipts/ReceiptProvision*BL.cs, Modules/Finances/Receipts/Provision` | Ermittelt Provisionen aus Schema, Staffel, Kundenzuordnung und Mitarbeiterstufe. |
+| M033 | Anzahlungsrechnungen | `src/backend/Centron.BL/Sales/Receipts/DownPayment` | Erzeugt Anzahlungsrechnungen und verrechnet sie in der Schlussrechnung. |
+| M034 | Belegausgabe und Reportanbindung | `ReceiptBL (Berichtserzeugung), ReceiptLayoutItemKindPdfHelperBL` | Erzeugt aus einem Beleg ein PDF nach konfigurierbaren Layoutelementen. |
+| M035 | E-Rechnung (ZUGFeRD/XRechnung) | `src/backend/Centron.BL/DataExchange/EDI/SaleInvoices, EDI/Zugferd` | Erzeugt und liest strukturierte elektronische Rechnungen in sechs Formatständen. |
+| M036 | Freigabewesen Warenkorb | `src/backend/Centron.BL/Sales/Receipts/ReceiptCartReleaseSystemBL.cs` | Führt Kundenwarenkörbe durch ein zweistufiges Genehmigungsverfahren. |
+| M037 | Projekt- und Sonderpreisimport | `Modules/ProjectPriceImport, Modules/Sales/SpecialArticleImport, ContractExternalArticleImport*BL` | Liest Projekt- und Sonderpreise aus Lieferantendateien und übernimmt sie in Verträge. |
+| M038 | Vertragsverwaltung | `src/backend/Centron.BL/Sales/CustomerAssets/Contracts, Entities/Sales/Receipts/ContractLists` | Führt Wartungs- und Serviceverträge mit Laufzeit, Kündigung und Abrechnungssteuerung. |
+| M039 | Vertragsabrechnung | `src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura, Modules/Finances/AutomatedBilling` | Erzeugt aus fälligen Verträgen Rechnungen und protokolliert das Ergebnis je Vertrag. |
+| M040 | Kontingentverwaltung | `ReceiptContract (Contingent-Felder), AutomaticFacturaBL.GetGroupToContingents` | Führt Stunden- und Wertkontingente mit Verbrauch, Grenzwert und Ausgleichsartikel. |
+| M041 | Zähler- und Klickabrechnung | `Entities/Sales/CustomerAssets/Contracts/ClickContracts, Modules/Finances/DeviceClickCounter` | Erfasst und importiert Gerätezählerstände und rechnet sie mit Freimengen und Staffeln ab. |
+| M042 | RMM-Mengenabrechnung | `src/backend/Centron.BL/RiverDivo, AutomaticFacturaWebServiceBL.CheckRMMArticle` | Bildet nutzungsabhängige Vertragspositionen aus Mengen eines externen RMM-Systems. |
+| M043 | Vereinfachte Ticketabrechnung | `src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling, Modules/Finances/TimerBilling` | Erzeugt aus ausgewählten Ticketzeiten unmittelbar einen Beleg. |
+| M044 | Pauschalabrechnung | `Modules/Finances/FlatrateBilling` | Rechnet Projekte pauschal unabhängig von den erfassten Einzelleistungen ab. |
+| M045 | MSP-Auswertung und Collector | `src/backend/Centron.Entities/Entities/Statistics/MspCollectors, Modules/Statistics/Msp*` | Wertet lizenzierte Managed-Service-Bestände aus und überführt Abweichungen in Verträge. |
+| M046 | Artikelverwaltung | `src/backend/Centron.BL/Warehousing/ArticleBL.cs und ArticleManagement` | Führt Artikel mit Einheiten, Staffelpreisen, Codes und gesetzlichen Nachweisangaben. |
+| M047 | Warengruppenverwaltung | `src/backend/Centron.BL/Warehousing/InventoryManagement/MaterialGroupBL.cs` | Ordnet Artikel Warengruppen zu und trägt steuerliche Vorgaben. |
+| M048 | Bestandsführung | `src/backend/Centron.BL/Warehousing/SecondStockArticleBL.cs, StockManagement` | Bucht Bestände je Lager, Lagerbereich und Lagerplatz mit Wertfortschreibung. |
+| M049 | Inventur | `src/backend/Centron.BL/Storage/StorageBL.cs, Modules/Warehousing/Inventory` | Führt transaktionsgesicherte Bestandsaufnahmen mit Fortschrittsmeldung. |
+| M050 | Kommissionierung | `src/backend/Centron.BL/Warehousing/CommissioningManagement, Modules/Warehousing/Commissioning` | Stellt Auftragspositionen zusammen und ordnet Einheiten über Barcodes zu. |
+| M051 | Lieferantenbelege | `src/backend/Centron.BL/Sales/Receipts/Supplier*, Modules/Purchasing/PurchaseSettings` | Bildet Anfrage, Bestellung, Wareneingang, Kalkulation und Lieferantengutschrift ab. |
+| M052 | Bestellvorschlagsliste | `Modules/Purchasing/OrderSuggestionList` | Ermittelt Bestellvorschläge aus Bestand, Bedarf und Mindestbestand. |
+| M053 | EDI mit Distributoren | `src/backend/Centron.BL/EDI, src/backend/Centron.Gateway/EDI_*, Modules/Purchasing/EDIManagement` | Tauscht Bestell-, Liefer- und Rechnungsdokumente in distributorspezifischen Formaten aus. |
+| M054 | Preisquellen und Preisspiegel | `src/apis/Centron.APIs.*, Warehousing/ActionPriceBL.cs, Warehousing/External` | Stellt Einkaufspreise aus sieben Quellen je Artikel gegenüber. |
+| M055 | Versandanbindung | `src/apis/Centron.Api.Gls, src/apis/Centron.Api.Shipcloud, Modules/Logistic/ShippingMethodSettings` | Übergibt Versandaufträge an Paketdienstleister und verwaltet Paketvorlagen. |
+| M056 | Artikelimport | `src/backend/Centron.BL/Warehousing/ArticleManagement/ArticleImportBL.cs, Modules/Warehousing/ArticleImport` | Liest Artikel- und Preisdaten zeitgesteuert ein und ordnet sie dem Bestand zu. |
+| M057 | Ticketverwaltung | `src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, Modules/Helpdesk/TicketList` | Führt Serviceanfragen als Tickets mit Zuständigkeit, Klassifikation und Fälligkeit. |
+| M058 | Ticketsichtbarkeit | `HelpdeskBL.GetShowHelpdeskRight, CentronNexus/Shared/Auth/TicketFilterService.cs` | Begrenzt die Ticketsicht nach Rechten, Filiale, Verkaufsgebiet und Kundenbezug. |
+| M059 | Ticketzeiterfassung | `src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs` | Erfasst Arbeitszeiten mit Zeitart, Abrechenbarkeit, Zuschlägen und Kalenderbezug. |
+| M060 | Zeitenschutz und Zeitrechte | `HelpdeskTimerWebServiceBL.ThrowIfUserDoesntHaveRightToChangeHelpdeskTimers` | Bindet Änderung und Löschung erfasster Zeiten an abgestufte Rechte und schützt abgerechnete Zeiten. |
+| M061 | Fälligkeits- und Prioritätenverwaltung | `HelpdeskBL.GetDueDateFromPriority, HelpdeskPrioritiesBL, Modules/Helpdesk/Settings/Priorities` | Berechnet die Ticketfälligkeit aus Priorität, Geschäftszeiten und Wochenendregel. |
+| M062 | Eskalationsverwaltung | `src/backend/Centron.BL/Sales/Support/Escalation, Modules/Administration/EscalationsSettings` | Meldet überfällige Vorgänge in drei Stufen an vier Empfängergruppen. |
+| M063 | Checklisten | `src/backend/Centron.BL/CheckListArea, Modules/Helpdesk/CentronChecklist` | Bindet Aufgabenlisten an Vorgänge und steuert darüber den Vorgangsabschluss. |
+| M064 | Ticketvorlagen und Ticketprozesse | `Entities/CustomerArea/Support/TicketProcess, Modules/Helpdesk/TicketProcessTemplates` | Erzeugt Tickets samt Untervorgängen und Checklisten aus Vorlagen. |
+| M065 | Serviceprojekte und Taskmanagement | `src/backend/Centron.BL/TicketProjects, TaskManager, Modules/Helpdesk/TaskManagement` | Führt Serviceprojekte mit Abhängigkeiten und untergeordneten Aufgaben. |
+| M066 | RMA und Werkstatt | `src/backend/Centron.BL/CustomerArea/RmaBL.cs, Modules/Rma` | Wickelt Reklamationen mit Ein- und Rückversand sowie Artikelhistorie ab. |
+| M067 | SelfCare-Formulare | `src/backend/Centron.BL/SelfCare, Modules/Helpdesk/SendSelfCareForm` | Stellt Kunden Formulare per Zugriffsschlüssel zu und nimmt die Antwort entgegen. |
+| M068 | Mailintegration und MailScanner | `src/backend/Centron.BL/MailScanner, Mail, Sales/Support/Helpdesk*Mail*` | Ordnet eingehende E-Mails regelbasiert Tickets zu und dokumentiert den Mailverkehr. |
+| M069 | Erwartete Ereignisse | `src/backend/Centron.BL/ExpectedEvents, Modules/Helpdesk/ExpectedEvents` | Überwacht wiederkehrende Kundenmeldungen und weist ausbleibende Ereignisse aus. |
+| M070 | KI-Unterstützung | `src/backend/Centron.BL/ArtificialIntelligence, Modules/ArtificialIntelligence` | Bietet KI-gestützte Zusammenfassung, Textbewertung, Angebotspositionen und Dialog. |
+| M071 | Mahnwesen | `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning, Modules/Finances/Dunning` | Mahnt offene Rechnungen in drei Stufen mit Vorschau und Rücknahme. |
+| M072 | Offene Posten und Zahlungseingang | `src/backend/Centron.BL/Sales/Receipts/Invoices/Opos, Finances/IncomingPayments` | Wertet offene Posten aus und erfasst Zahlungseingänge unter einer Laufnummer. |
+| M073 | SEPA-Zahlungsverkehr | `src/backend/Centron.BL/DataExchange/PaymentTransactions, Centron.Gateway/.../Sepa` | Erzeugt Zahlungsdateien nach amtlichem Schema und kennzeichnet exportierte Rechnungen. |
+| M074 | Buchhaltungsexport und -import | `src/backend/Centron.BL/DataExchange/BookKeeping, Modules/DataExchange/BookKeeping` | Stellt Belegdaten für die Finanzbuchhaltung bereit und liest offene Posten zurück. |
+| M075 | DATEV-Belegtransfer | `Modules/DataExchange/DatevOnline2020` | Übergibt Belegbilder und Buchungsdaten an DATEV Unternehmen online. |
+| M076 | Kontenrahmen | `src/backend/Centron.BL/Administration/BookKeepingAccountSystems, Modules/Warehousing/AccountSystems` | Führt Kontenrahmen und bildet Buchhaltungsnummern regelbasiert. |
+| M077 | Kostenstellen und Kostenträger | `src/backend/Centron.BL/Warehousing/CostCenterBL.cs, CostObjectBL.cs, Modules/PayersAndCostCenter` | Ordnet Kosten und Erlöse verursachungsgerecht zu. |
+| M078 | Online-Banking | `src/apis/Centron.APIs.FinAPI, Centron.Gateway/OnlineBanking, Modules/OnlineBanking` | Ruft Kontoumsätze über einen externen Kontoinformationsdienst ab. |
+| M079 | Produktionsaufträge | `src/backend/Centron.BL/Production, Modules/Production/ProductionOrder` | Führt Produktionsaufträge mit Positionen und Protokoll. |
+| M080 | Maschinenverwaltung | `Modules/Production/MachineManagement` | Führt Produktionsmaschinen als Stammdaten für Fertigungsaufträge. |
+| M081 | Auslastung und Leistungsnachweise | `HelpdeskTimerBL.GetEmployeeTimeStatistics, Modules/Statistics/EmployeeAnalytics` | Wertet erfasste Zeiten je Mitarbeiter, Kunde und Zeitraum aus. |
+| M082 | Tagesplanung "Mein Tag" | `src/backend/Centron.BL/MyDay, Modules/MyCentron/MyDay` | Führt je Mitarbeiter eine Tagesplanung und übernimmt erfasste Ticketzeiten. |
+| M083 | Kalender und Exchange-Abgleich | `src/backend/Centron.BL/Calendar, Sales/Calendar, Modules/Calendar` | Führt Termine und gleicht sie über Microsoft Graph mit Exchange ab. |
+| M084 | Telefonie und Anrufprotokoll | `src/backend/Centron.BL/Tapi, Modules/MyCentron/Telephony` | Protokolliert Anrufe und ermittelt den Anrufer über die Rufnummer. |
+| M085 | Berichtswesen und ReportEngine | `src/backend/Centron.BL/ReportEngine, Modules/Reports/ReportManagement` | Verwaltet Berichtsvorlagen zentral und erzeugt Ausgaben über Gruppen und Parameter. |
+| M086 | Reportserver | `Modules/Administration/ReportServer` | Erzeugt Berichte zeitgesteuert und verteilt sie an festgelegte Empfänger. |
+| M087 | Dokumentenablage | `src/backend/Centron.BL/Administration/FileManagement, Administration/Documents` | Legt Dokumente in einer je Geschäftsobjekt erzeugten Verzeichnisstruktur ab. |
+| M088 | Volltextsuche | `src/backend/Centron.BL/IndexSearch` | Macht Tickets, Konten und Dokumente über einen Volltextindex durchsuchbar. |
+| M089 | Massendatenpflege (Data Updater) | `src/backend/Centron.BL/MassUpdate, Modules/Massenupdates` | Ändert Preise und Daten in großer Zahl auf Grundlage gespeicherter Vorlagen. |
+| M090 | Kundenindividuelle Zusatzfelder | `Entities/Customizations (ModuleCustomProperty), Modules/Global/CustomProperties` | Stellt je Modul frei definierbare, typisierte Zusatzfelder bereit. |
+| M091 | Lokalisierung | `Resources/LocalizedStrings.resx in drei Projekten` | Hält alle sichtbaren Texte in Ressourcendateien für Deutsch und Englisch. |
+| M092 | Benachrichtigungen | `src/backend/Centron.BL/NexusNotifications, Notifications, MyDay/MyDayNotificationsBL.cs` | Erzeugt typisierte Benachrichtigungen und verteilt sie in Echtzeit. |
+| M093 | Externe Werkzeuge | `src/backend/Centron.BL/ExternalToolsBL, Modules/ExternalTool` | Startet externe Programme mit Parametern aus dem aktuellen Vorgang. |
+| M094 | Datenbank-Skriptsystem | `src/backend/Centron.BL/Administration/Scripts` | Bringt das Datenbankschema beim Start auf den zur Anwendungsversion passenden Stand. |
+| M095 | SQL-Manager und Inspektor | `src/backend/Centron.BL/Administration/SQLManagement, Modules/Administration/SqlManagers` | Bietet Administratoren einen direkten Abfragezugang zur Datenbank. |
+| M096 | Hintergrunddienste | `src/webservice/Centron.Host/AspNetCore/HostedServices, Administration/BackgroundServices` | Führt 35 wiederkehrende Aufgaben zeitgesteuert mit Aktivierung und Fehlerdrosselung aus. |
+| M097 | Telemetrie | `src/backend/Centron.BL/Telemetry, Interception/Interceptors/*Telemetry*` | Erfasst Nutzung von Schnittstelle und KI-Funktionen aggregiert und überträgt sie. |
+| M098 | Windows-Client-Rahmen | `src/centron/Centron.WPF.UI, Centron.WPF.UI.Extension` | Bietet die vollständige Fachoberfläche mit Modulregistrierung und MVVM-Rahmen. |
+| M099 | Installation und Auslieferung | `deployment/, .github/actions/sign-artifacts` | Erzeugt signierte Installationspakete für Client und Webservice. |
+| M100 | Webservice-Betrieb | `src/webservice/Centron.Host*, docker/` | Betreibt den Webservice als Windows-Dienst, Konsolenanwendung oder Container. |
+| M101 | Verbindungs- und Umgebungsverwaltung | `src/webservice/c-entron.misc.ConnectionManager, Administration/Environments` | Verwaltet benannte Verbindungen und prüft Datenbank- und Anmeldeerreichbarkeit. |
+| M102 | Protokollierung im Betrieb | `nlog.config je Wirtsprozess, Modules/Administration/LogViewer` | Protokolliert Betriebsereignisse ab Warnstufe mit Tagesarchivierung. |
+| M103 | Diagnose und Laufzeitmessung | `Administration/NetworkDiagnostics, PerformanceTests, Profiling` | Misst Übertragungszeiten je Systemabschnitt und erlaubt Laufzeitmessungen. |
+| M104 | Erscheinungsbild und Symbolsätze | `Administration/Themes, CentronIcons, Nexus/Settings/Branding` | Stellt Farbschemata und Symbolsätze zentral für alle Clients bereit. |
+| M105 | Nexus ServiceBoard | `src/nexus/CentronNexus/ServiceBoard` | Bietet Mitarbeitern eine browserbasierte Ticketbearbeitung mit Liste, Kanban und Zeiten. |
+| M106 | Kundenportal | `src/nexus/CentronNexus/WebCart/CustomerPortal` | Gibt Kunden Einsicht in Tickets, Belege, Verträge und freigegebene Dokumente. |
+| M107 | WebCart | `src/nexus/CentronNexus/WebCart, src/backend/Centron.BL/Sales/Receipts/ReceiptCartBL.cs` | Bietet Kunden einen Warenkorb auf Basis ihrer Sonderpreise. |
+| M108 | Web-Beleg (WebOffer) | `src/nexus/CentronNexus/WebOffer, ICentronRestService.Receipts (WebReceipt)` | Stellt Belege im Web zur Einsicht und Rückmeldung bereit. |
+| M109 | Dokumentsignatur und Onlinedokumente | `src/nexus/CentronNexus/DocumentSigning, src/backend/Centron.BL/Security/PdfSigningBL.cs` | Stellt Dokumente über Zugriffsschlüssel bereit und nimmt Bestätigung oder Unterschrift entgegen. |
+| M110 | Produktionsaufträge im Portal | `src/nexus/CentronNexus/ProductionOrderManagement` | Bildet Produktionsaufträge zusätzlich im Webportal ab. |
+| M111 | Outlook-Add-In | `src/nexus/CentronNexus.OutlookAddIn` | Macht Tickets, Belege, Kunden und Dokumente aus Outlook heraus zugänglich. |
+| M112 | Mobile Nutzung | `src/backend/Centron.BL/Mobile, Entities/*Mobile*` | Liefert reduzierte Stammdatensichten für mobile Verbraucher. |
+| M113 | Legacy-REST-Webservice | `src/webservice/Centron.Host/Services, Centron.WebServices.Core` | Bietet 2.618 Operationen mit einheitlichem Anfrage- und Antwortformat. |
+| M114 | Moderne REST-API | `src/webservice/Centron.Controllers` | Bietet eine versionierte, ressourcenorientierte Schnittstelle mit Rechteattributen. |
+| M115 | RMM-/Monitoring-Schnittstelle | `ICentronRestService.RMM.cs, ICentronRestService.RiverDivo.cs` | Erlaubt externen Monitoringsystemen Ticketanlage, Stammdatenabruf und Gerätepflege. |
+| M116 | Fremdsystemanbindungen | `Centron.Api.docuFORM, DataExchange/Connectors, TelekomDive, GfkExport, Concerto, EbInterface` | Bindet branchentypische Fremdsysteme mit eigener Konfiguration und Lizenz an. |
+| M117 | Qualitätssicherung und Bauabläufe | `.github/workflows, Directory.Build.props, tests/` | Baut, signiert und prüft jede Änderung automatisiert vor der Aufnahme. |
+| M118 | Produkt-Lifecycle (PLM) | `src/backend/Centron.BL/Finances/ProductLifecycleBL.cs, Modules/PLM` | Führt die beim Kunden eingesetzten Softwarelizenzen mit Lebenszyklusinformationen. |
+| M119 | Produktmatrix | `src/backend/Centron.BL/ProductMatrix, Modules/Sales/ProductMatrix` | Bewertet je Kunde die genutzten und offenen Produkte und Dienstleistungen. |
+| M120 | Qualitätsmanagement | `src/backend/Centron.Interfaces/QM, Modules/QM` | Erfasst und wertet qualitätsrelevante Vorgänge aus. |
+| M121 | Dashboard | `Modules/Dashboard, Modules/MyCentron/Dashboard, Nexus/ServiceBoard/Dashboard` | Bietet eine Startseite mit zusammenstellbaren Kacheln. |
+| M122 | Todo-Liste | `src/backend/Centron.BL/ToDoArea, Modules/MyCentron/TodoList` | Führt je Mitarbeiter eine persönliche, objektgebundene Aufgabenliste. |
+| M123 | Terminanfragen | `src/backend/Centron.BL/AppointmentRequests` | Sendet Terminvorschläge an Kunden und nimmt deren Auswahl entgegen. |
+| M124 | Kurzverweise und Weblinks | `src/backend/Centron.BL/Urls, WebLinks` | Erzeugt nachverfolgbare Kurzverweise mit Folgeaktionen. |
+| M125 | Videoportal und Hilfe | `src/backend/Centron.BL/VideoPortal, Modules/Global/VideoPortal, Modules/Global/Help` | Ordnet Anleitungsvideos den Programmbereichen zu. |
+| M126 | Interne Chats | `src/backend/Centron.BL/Chats` | Führt interne Unterhaltungen mit optionalem Objektbezug. |
+| M127 | Schlagworte | `src/backend/Centron.BL/Tags` | Versieht Tickets mit wiederverwendbaren Schlagworten. |
+| M128 | Prozesse | `src/backend/Centron.BL/Processes` | Führt mehrstufige, an Geschäftsobjekte gebundene Prozesse mit Schritten und Bindungen. |
+| M129 | Asset-Management und IT-Dokumentation | `src/backend/Centron.BL/DocuBoard, DocumentationArea, ItPlanner, 221 AssetManagement-Tabellen` | Dokumentiert und überwacht die IT-Landschaft des Kunden. |
+| M130 | Handelsplattform (TradePool) | `src/backend/Centron.BL/TradePool` | Liest Artikeldaten einer Handelsplattform ein und macht sie durchsuchbar. |
+| M131 | Gutscheinverwaltung | `src/backend/Centron.BL/VoucherManagement` | Führt Gutscheine mit Barcode und ihren Zuständen. |
+| M132 | Reisekostenabrechnung | `Modules/Purchasing/TravelExpense` | Erfasst Reisekosten der Servicemitarbeiter (im vorliegenden Stand deaktiviert). |
+| M133 | Externe Ticketsystemanbindung | `src/backend/Centron.BL/CPra, ExternalHelpdesk` | Bindet externe Ticket- und Serviceplattformen über Webhooks an. |
+| M134 | Dokumentensynchronisation | `Modules/DataExchange/DocSync` | Gleicht Dokumente mit einer externen Ablage ab. |
+| M135 | Listen- und Rasteranpassung | `src/backend/Centron.BL/GUI, Modules/Gui/Profiles, Nexus/Shared/DataGrid` | Speichert Spaltenauswahl, Sortierung und Filter je Benutzer und Liste. |
+| M136 | Soziale Netzwerke | `src/backend/Centron.BL/SocialMedia` | Führt Verweise auf soziale Netzwerke am Konto und an der Person. |
+| M137 | Abteilungen und Verkaufsgebiete | `src/backend/Centron.BL/CustomerArea/ContactDepartmentBL.cs, Centron.Controls/SalesAreaManagement` | Ordnet Mitarbeiter Abteilungen und Verkaufsgebieten als Sicht- und Zuweisungsgrenze zu. |
+| M138 | Betriebs- und Qualitätszusagen | `(kein eigener Codebereich; abgeleitet aus Betriebsartefakten)` | Bündelt Verfügbarkeit, Datensicherung, Aufbewahrung und Mengengerüst als offene Betriebsanforderungen. |
+| M139 | Abgrenzung zur Vorgängeranwendung | `Alttabellen, DelphiColor-Typen, IsAccountManagementActive` | Erfasst die Aufgabenteilung zwischen c-entron.NET und c-entron classic. |
+| M140 | Architektur und Schichtung | `docs/getting-started/general-structure.md, Centron.BL/WebServices, Services/Logics` | Legt die sechsstufige Schichtung und die Trennung von Entität, DTO und Ansichtsmodell fest. |
+| M141 | Ergebnis- und Fehlerbehandlung | `Centron.Interfaces/Results, Interception/Interceptors` | Führt ein einheitliches Ergebnisobjekt mit Meldungscode über alle Schichten. |
+| M142 | Datenzugriffsschicht | `src/backend/Centron.DAO` | Kapselt den Datenbankzugriff über generische und spezialisierte Zugriffsobjekte. |
+| M143 | Datenmodellkonventionen | `docs/guides/database/database-conventions.md, Centron.Entities/BaseEntity.cs` | Legt Schlüssel, Namensgebung, Datentypen und Nachverfolgungsspalten verbindlich fest. |
+| M144 | Zwischenspeicherung | `CentronCache, src/backend/Centron.BL/Services/CachedTableBL.cs` | Hält Rechte, Einstellungen und Stammdaten zwischengespeichert und aktualisiert sie gesteuert. |
+| M145 | Produktmerkmale (Feature-Schalter) | `ModuleFeatures, Modules/ModuleRegistration.cs` | Schaltet Funktionen unabhängig von Lizenz und Recht schrittweise frei. |
+| M146 | Belegprotokoll | `src/backend/Centron.BL/Sales/Receipts/ReceiptLogBL.cs, Tabelle AnlageLog` | Hält Belegvorgänge über typisierte Protokollarten fest. |
+| M147 | Belegpositionen und Klassifikationen | `Entities/Sales/Receipts (Item-Basisklassen), ReceiptItemKind` | Typisiert Belegpositionen und steuert Gliederung, Sichtbarkeit und Berechnung. |
+| M148 | Vertragsartikelreferenzen | `src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractArticleReferenzesBL.cs` | Bildet nutzungsabhängige Vertragspositionen mit eigener Berechnungsvorschrift ab. |
+| M149 | Länder-, Regions- und Feiertagsstammdaten | `src/backend/Centron.BL/CountryArea, Centron.DAO/Holiday` | Führt Länder, Bundesländer, Währungen und Feiertage als Grundlage fachlicher Regeln. |
+| M150 | Textbausteine und Variablenersetzung | `src/backend/Centron.BL/TextModuleArea, Core/ReplacementBL.cs` | Führt wiederverwendbare Texte und ersetzt Variablen aus dem Vorgangskontext. |
+| M151 | Plattform- und Technologiebindung | `global.json, Directory.Build.props, DevExpress.Version.props, version.json` | Legt Laufzeit, Oberflächenbibliothek, Persistenztechnologie und Versionierung zentral fest. |
+| M152 | Entwicklerschutz | `src/backend/Centron.Common/DeveloperSecurity.cs` | Ersetzt in nicht freigegebenen Ständen externe Empfängeradressen durch eine Ersatzadresse. |
+| M153 | Portalanmeldung und Sitzungsverwaltung | `src/nexus/CentronNexus/Shared/Auth, Shared/Authorization` | Führt Anmeldung, Ansprüche, Cookierichtlinie und Sitzungsüberwachung des Portals. |
+| M154 | Steuerelementbibliothek | `src/shared/Centron.Controls, Centron.Controls.Preview` | Stellt wiederverwendbare Oberflächenbausteine mit eigener Übersetzung und Vorschau bereit. |
+| M155 | Dokumentation | `docs/, README.md, CentronRights.md` | Hält Architektur-, Entwicklungs- und Betriebsregeln im Quellbestand vor. |
+| M156 | Übertragungssicherheit | `(kein eigener Codebereich; Cookie- und Containerkonfiguration)` | Sichert die Netzverbindungen zwischen Client, Webservice, Portal und Datenbank. |
+| M157 | WebSuite-Administration | `src/backend/Centron.BL/WebSuite/Administration` | Verwaltet Mitarbeiter und Einstellungen eines gesonderten Weboberflächenbestands. |
+| M158 | Portalzugriffsverwaltung (Backend) | `src/backend/Centron.BL/Administration/Portal, src/backend/Centron.Gateway/Portal` | Regelt den Zugriff eines Herstellerportals auf den Webservice. |
+| M159 | TANSS-Anbindung | `src/backend/Centron.BL/DataExchange/TanssInterfaces/TanssBL.cs` | Bindet das Ticketsystem TANSS an. |
+| M160 | Gateway-Import/-Export | `src/backend/Centron.Gateway/Import/EDI, src/backend/Centron.Gateway/Export/EDI` | Kapselt Lese- und Schreibvorgänge der EDI-Dateiformate im Gateway. |
+| M161 | Nexus-Office-Bereich | `src/nexus/CentronNexus/Office` | Stellt geteilte Dokumente im Portal dar und nimmt Freigaben entgegen. |
+| M162 | Nexoware-Erweiterungen | `src/nexus/CentronNexus/Settings/NexowareSmartflow, Centron.Controllers/Controllers/v1/Nexoware` | Bindet Zusatzdienste des Herstellers Nexoware an. |
+| M163 | Transaktionsklammer (TransactionBL) | `src/backend/Centron.BL/Transactions` | Stellt eine anwendungsseitige Transaktionsklammer bereit. |
+| M164 | Systemtabellenverwaltung | `src/backend/Centron.BL/SystemArea` | Führt technische Systemtabellen mit Schlüsselwerten. |
+| M165 | Startlogik (StartBL) | `src/backend/Centron.BL/Start` | Führt beim Programmstart vorbereitende Schritte aus. |
+| M166 | Werkzeugsammlung (ToolBL) | `src/backend/Centron.BL/Tools` | Bündelt technische Hilfsfunktionen. |
+| M167 | Lieferantensuche und Lieferantenanlagen | `src/backend/Centron.BL/BusinessPartner` | Sucht Lieferanten und führt lieferantenbezogene Anlagen. |
+| M168 | Belegerfassung Zahlungsausgang | `src/centron/Centron.WPF.UI/Modules/Warehousing/OutcomingPayments` | Erfasst Zahlungsausgänge an Lieferanten. |
+| M169 | Kalkulation je Filiale | `src/centron/Centron.WPF.UI/Modules/DataExchange/SupplierOrderPerBranch` | Verteilt Lieferantenbestellungen auf Filialen. |
+| M170 | Allgemeiner Datenimport und -export | `src/centron/Centron.WPF.UI/Modules/DataExchange/DataImport, .../DataExport` | Liest und schreibt Datenbestände über frei konfigurierbare Abbildungen. |
+| M171 | Artikel- und Lieferantensuchdialoge | `src/centron/Centron.WPF.UI/Modules/Warehousing/SearchArticle, .../SupplierSearch` | Bietet Suchdialoge für Artikel und Lieferanten. |
+| M172 | Oberflächen-Hilfsbereiche | `src/centron/Centron.WPF.UI/Modules/Global/FileSystemDialog, .../EmployeeSelection, .../ExceptionMessage, .../Actions` | Stellt wiederkehrende Auswahl- und Meldungsdialoge bereit. |
+| M173 | Nexus-Ticketsichten (Backend) | `src/backend/Centron.BL/NexusTicketViews` | Führt benutzerdefinierte Ticketsichten des Portals. |
+| M174 | Versionsauskunft (WebVersion) | `src/backend/Centron.BL/WebVersion` | Gibt die Version des Webservice aus. |
+| M175 | Bauskripte | `scripts/Centron.Scripts, scripts/Scripts` | Steuert Bau- und Auslieferungsschritte außerhalb der Ablaufdefinitionen. |
+| M176 | Lieferantenverträge | `src/centron/Centron.WPF.UI/Modules/Finances/Crm/AccountContracts` | Führt Verträge auf der Lieferantenseite. |
+
+---
+
+## 4 Abdeckungstabelle
+
+Jede Zeile des Inventars aus Abschnitt 3 erscheint hier mit ihrer Einstufung und der Anzahl der daraus abgeleiteten Anforderungen. Jede der 446 Anforderungen ist genau einer Inventarzeile zugeordnet; die Summe der Spalte "Anzahl" ergibt daher 446.
+
+**Einstufungsregel** (rein quantitativ, damit die Angabe nachprüfbar bleibt):
+
+| Einstufung | Bedingung | Bedeutung |
+|------------|-----------|-----------|
+| `tief` | 6 oder mehr Anforderungen | Fachlogik, Datenmodell und durchsetzende Stellen wurden verfolgt |
+| `mittel` | 3 bis 5 Anforderungen | tragende Regeln erfasst, Randfälle offen |
+| `flach` | 1 bis 2 Anforderungen | Zweck und ein Kernbeleg erfasst, innere Regeln offen |
+| `nicht analysiert` | 0 Anforderungen | keine belegbare Aussage bildbar; Grund je Zeile angegeben |
+
+| Nr. | Modul | Einstufung | Anzahl | Abgeleitete Anforderungen bzw. Grund |
+|-----|-------|------------|--------|---------------------------------------|
+| M001 | Mandantenverwaltung | mittel | 3 | StRS-001, SyRS-001, SwRS-001 |
+| M002 | Filialverwaltung | flach | 1 | StRS-002 |
+| M003 | Benutzer- und Anmeldeverwaltung | tief | 16 | StRS-003, StRS-004, StRS-009, SyRS-005, SyRS-006, SyRS-007, SyRS-009, SyRS-022, SyRS-023, SyRS-190, SwRS-010, SwRS-011, SwRS-013, SwRS-014, SwRS-015, SwRS-016 |
+| M004 | Rechteverwaltung | tief | 13 | StRS-005, StRS-006, SyRS-010, SyRS-011, SyRS-012, SyRS-191, SwRS-020, SwRS-021, SwRS-022, SwRS-026, SwRS-027, SwRS-028, SwRS-153 |
+| M005 | Zwei-Faktor-Authentifizierung | mittel | 3 | StRS-007, SyRS-008, SwRS-012 |
+| M006 | Microsoft-Anmeldung (OpenID Connect) | flach | 1 | StRS-008 |
+| M007 | Nummernkreisverwaltung | tief | 7 | StRS-032, StRS-033, SyRS-002, SyRS-033, SyRS-045, SwRS-002, SwRS-056 |
+| M008 | Lizenzverwaltung | mittel | 5 | StRS-010, SyRS-013, SyRS-014, SyRS-187, SwRS-023 |
+| M009 | Zugangstokenverwaltung | mittel | 3 | StRS-011, SyRS-015, SwRS-024 |
+| M010 | Webaccount-Verwaltung | mittel | 3 | StRS-012, SyRS-016, SwRS-025 |
+| M011 | Änderungsprotokollierung | mittel | 4 | StRS-013, SyRS-018, SwRS-030, SwRS-031 |
+| M012 | DSGVO / Datenschutz | mittel | 3 | StRS-014, SyRS-019, SwRS-032 |
+| M013 | Passwort-Manager | tief | 7 | StRS-015, SyRS-020, SyRS-021, SwRS-029, SwRS-033, SwRS-034, SwRS-128 |
+| M014 | Kontenmodell und Adressen | tief | 7 | StRS-016, StRS-017, StRS-018, SyRS-030, SyRS-031, SwRS-040, SwRS-041 |
+| M015 | CRM-Aktivitäten | flach | 1 | StRS-019 |
+| M016 | Kampagnen und Mailing | mittel | 3 | StRS-020, StRS-021, SyRS-034 |
+| M017 | CRM-Projekte | flach | 2 | StRS-022, SwRS-042 |
+| M018 | Audits und Fragebögen | flach | 2 | StRS-023, SyRS-035 |
+| M019 | Preisfindung und Sonderpreise | mittel | 4 | StRS-024, SyRS-036, SwRS-043, SwRS-066 |
+| M020 | Bankverbindungen und SEPA-Mandate | mittel | 3 | StRS-025, SyRS-060, SwRS-044 |
+| M021 | Stammblätter (Gerätedokumentation) | mittel | 3 | StRS-026, SyRS-037, SwRS-045 |
+| M022 | Kundengeräteverwaltung | flach | 1 | SwRS-046 |
+| M023 | Belegkern | tief | 7 | StRS-027, SyRS-040, SwRS-050, SwRS-051, SwRS-065, SwRS-068, SwRS-069 |
+| M024 | Belegzustände und Stornierung | mittel | 4 | StRS-028, SyRS-041, SwRS-052, SwRS-067 |
+| M025 | Belegberechtigung | mittel | 3 | StRS-029, SyRS-042, SwRS-053 |
+| M026 | Belegversionierung | mittel | 3 | StRS-030, SyRS-043, SwRS-054 |
+| M027 | Nebenläufigkeitsschutz | mittel | 4 | StRS-031, SyRS-044, SyRS-059, SwRS-055 |
+| M028 | Zahlungs- und Belegkonditionen | flach | 2 | StRS-034, SyRS-046 |
+| M029 | Mehrwertsteuerverwaltung | mittel | 3 | StRS-035, SyRS-047, SwRS-057 |
+| M030 | Währungen und Fremdwährungsbelege | flach | 2 | StRS-036, SyRS-048 |
+| M031 | Belegvorlagen | mittel | 3 | StRS-037, SyRS-049, SwRS-058 |
+| M032 | Provisionsabrechnung | mittel | 3 | StRS-038, SyRS-050, SwRS-059 |
+| M033 | Anzahlungsrechnungen | flach | 2 | StRS-039, SyRS-051 |
+| M034 | Belegausgabe und Reportanbindung | mittel | 3 | StRS-040, SyRS-052, SwRS-060 |
+| M035 | E-Rechnung (ZUGFeRD/XRechnung) | mittel | 4 | StRS-041, SyRS-053, SwRS-061, SwRS-114 |
+| M036 | Freigabewesen Warenkorb | mittel | 3 | StRS-042, SyRS-054, SwRS-062 |
+| M037 | Projekt- und Sonderpreisimport | flach | 2 | StRS-043, SyRS-055 |
+| M038 | Vertragsverwaltung | mittel | 5 | StRS-044, SyRS-070, SyRS-079, SwRS-070, SwRS-079 |
+| M039 | Vertragsabrechnung | tief | 6 | StRS-045, StRS-046, SyRS-071, SyRS-072, SwRS-071, SwRS-072 |
+| M040 | Kontingentverwaltung | mittel | 3 | StRS-047, SyRS-073, SwRS-073 |
+| M041 | Zähler- und Klickabrechnung | mittel | 3 | StRS-048, SyRS-074, SwRS-074 |
+| M042 | RMM-Mengenabrechnung | mittel | 3 | StRS-049, SyRS-075, SwRS-075 |
+| M043 | Vereinfachte Ticketabrechnung | mittel | 3 | StRS-050, SyRS-076, SwRS-076 |
+| M044 | Pauschalabrechnung | flach | 2 | StRS-051, SyRS-077 |
+| M045 | MSP-Auswertung und Collector | mittel | 3 | StRS-052, SyRS-078, SwRS-078 |
+| M046 | Artikelverwaltung | mittel | 4 | StRS-053, SyRS-080, SwRS-080, SwRS-087 |
+| M047 | Warengruppenverwaltung | flach | 2 | StRS-054, SyRS-081 |
+| M048 | Bestandsführung | mittel | 4 | StRS-055, SyRS-082, SwRS-081, SwRS-088 |
+| M049 | Inventur | mittel | 3 | StRS-056, SyRS-083, SwRS-084 |
+| M050 | Kommissionierung | mittel | 3 | StRS-057, SyRS-084, SwRS-085 |
+| M051 | Lieferantenbelege | flach | 2 | StRS-058, SyRS-085 |
+| M052 | Bestellvorschlagsliste | flach | 2 | StRS-059, SyRS-086 |
+| M053 | EDI mit Distributoren | mittel | 3 | StRS-060, SyRS-087, SwRS-082 |
+| M054 | Preisquellen und Preisspiegel | mittel | 4 | StRS-061, SyRS-088, SwRS-083, SwRS-086 |
+| M055 | Versandanbindung | flach | 2 | StRS-062, SyRS-089 |
+| M056 | Artikelimport | flach | 2 | StRS-063, SyRS-090 |
+| M057 | Ticketverwaltung | mittel | 4 | StRS-064, SyRS-100, SyRS-101, SwRS-100 |
+| M058 | Ticketsichtbarkeit | flach | 1 | StRS-065 |
+| M059 | Ticketzeiterfassung | mittel | 3 | StRS-066, SyRS-102, SwRS-101 |
+| M060 | Zeitenschutz und Zeitrechte | mittel | 3 | StRS-067, SyRS-103, SwRS-102 |
+| M061 | Fälligkeits- und Prioritätenverwaltung | mittel | 3 | StRS-068, SyRS-104, SwRS-103 |
+| M062 | Eskalationsverwaltung | mittel | 3 | StRS-069, SyRS-105, SwRS-104 |
+| M063 | Checklisten | mittel | 3 | StRS-070, SyRS-106, SwRS-105 |
+| M064 | Ticketvorlagen und Ticketprozesse | flach | 2 | StRS-071, SyRS-107 |
+| M065 | Serviceprojekte und Taskmanagement | flach | 2 | StRS-072, SyRS-108 |
+| M066 | RMA und Werkstatt | mittel | 3 | StRS-073, SyRS-109, SwRS-109 |
+| M067 | SelfCare-Formulare | mittel | 3 | StRS-074, SyRS-110, SwRS-106 |
+| M068 | Mailintegration und MailScanner | flach | 2 | StRS-075, SyRS-111 |
+| M069 | Erwartete Ereignisse | flach | 2 | StRS-076, SyRS-112 |
+| M070 | KI-Unterstützung | mittel | 3 | StRS-077, SyRS-113, SwRS-107 |
+| M071 | Mahnwesen | mittel | 4 | StRS-078, StRS-079, SyRS-120, SwRS-110 |
+| M072 | Offene Posten und Zahlungseingang | mittel | 4 | StRS-080, SyRS-121, SwRS-112, SwRS-113 |
+| M073 | SEPA-Zahlungsverkehr | mittel | 4 | StRS-081, SyRS-122, SwRS-111, SwRS-115 |
+| M074 | Buchhaltungsexport und -import | flach | 2 | StRS-082, SyRS-123 |
+| M075 | DATEV-Belegtransfer | flach | 1 | StRS-083 |
+| M076 | Kontenrahmen | flach | 2 | StRS-084, SyRS-124 |
+| M077 | Kostenstellen und Kostenträger | flach | 2 | StRS-085, SyRS-125 |
+| M078 | Online-Banking | flach | 2 | StRS-086, SyRS-126 |
+| M079 | Produktionsaufträge | mittel | 3 | StRS-087, SyRS-130, SwRS-089 |
+| M080 | Maschinenverwaltung | flach | 1 | StRS-088 |
+| M081 | Auslastung und Leistungsnachweise | flach | 2 | StRS-089, SyRS-131 |
+| M082 | Tagesplanung "Mein Tag" | flach | 2 | StRS-090, SyRS-132 |
+| M083 | Kalender und Exchange-Abgleich | flach | 2 | StRS-091, SyRS-133 |
+| M084 | Telefonie und Anrufprotokoll | flach | 2 | StRS-092, SyRS-134 |
+| M085 | Berichtswesen und ReportEngine | mittel | 3 | StRS-093, SyRS-140, SyRS-195 |
+| M086 | Reportserver | flach | 1 | StRS-094 |
+| M087 | Dokumentenablage | flach | 2 | StRS-095, SyRS-141 |
+| M088 | Volltextsuche | mittel | 3 | StRS-096, SyRS-142, SwRS-120 |
+| M089 | Massendatenpflege (Data Updater) | mittel | 3 | StRS-097, SyRS-143, SwRS-123 |
+| M090 | Kundenindividuelle Zusatzfelder | flach | 2 | StRS-098, SyRS-144 |
+| M091 | Lokalisierung | flach | 2 | StRS-099, SyRS-145 |
+| M092 | Benachrichtigungen | mittel | 3 | StRS-100, SyRS-146, SwRS-125 |
+| M093 | Externe Werkzeuge | flach | 2 | StRS-101, SyRS-147 |
+| M094 | Datenbank-Skriptsystem | mittel | 4 | StRS-102, SyRS-148, SwRS-121, SwRS-151 |
+| M095 | SQL-Manager und Inspektor | flach | 2 | StRS-103, SyRS-149 |
+| M096 | Hintergrunddienste | tief | 6 | StRS-104, SyRS-150, SyRS-180, SwRS-122, SwRS-148, SwRS-149 |
+| M097 | Telemetrie | mittel | 3 | StRS-105, SyRS-151, SwRS-124 |
+| M098 | Windows-Client-Rahmen | mittel | 4 | StRS-106, SyRS-160, SwRS-130, SwRS-006 |
+| M099 | Installation und Auslieferung | flach | 2 | StRS-107, SyRS-161 |
+| M100 | Webservice-Betrieb | mittel | 4 | StRS-108, SyRS-003, SyRS-162, SyRS-181 |
+| M101 | Verbindungs- und Umgebungsverwaltung | flach | 2 | StRS-109, SyRS-163 |
+| M102 | Protokollierung im Betrieb | mittel | 3 | StRS-110, SyRS-164, SyRS-188 |
+| M103 | Diagnose und Laufzeitmessung | mittel | 3 | StRS-111, SyRS-165, SyRS-183 |
+| M104 | Erscheinungsbild und Symbolsätze | flach | 2 | StRS-112, SyRS-166 |
+| M105 | Nexus ServiceBoard | mittel | 4 | StRS-113, SyRS-167, SyRS-168, SwRS-137 |
+| M106 | Kundenportal | flach | 1 | StRS-114 |
+| M107 | WebCart | flach | 2 | StRS-115, SyRS-169 |
+| M108 | Web-Beleg (WebOffer) | flach | 2 | StRS-116, SyRS-170 |
+| M109 | Dokumentsignatur und Onlinedokumente | mittel | 4 | StRS-117, SyRS-171, SyRS-182, SyRS-193 |
+| M110 | Produktionsaufträge im Portal | flach | 1 | StRS-118 |
+| M111 | Outlook-Add-In | mittel | 3 | StRS-119, SyRS-172, SwRS-138 |
+| M112 | Mobile Nutzung | flach | 2 | StRS-120, SyRS-173 |
+| M113 | Legacy-REST-Webservice | mittel | 5 | StRS-121, SyRS-017, SyRS-174, SwRS-017, SwRS-131 |
+| M114 | Moderne REST-API | mittel | 4 | StRS-122, SyRS-025, SyRS-175, SwRS-132 |
+| M115 | RMM-/Monitoring-Schnittstelle | mittel | 3 | StRS-123, SyRS-176, SwRS-133 |
+| M116 | Fremdsystemanbindungen | flach | 2 | StRS-124, SyRS-177 |
+| M117 | Qualitätssicherung und Bauabläufe | tief | 7 | StRS-125, SyRS-178, SyRS-179, SwRS-140, SwRS-144, SwRS-147, SwRS-154 |
+| M118 | Produkt-Lifecycle (PLM) | flach | 1 | StRS-126 |
+| M119 | Produktmatrix | flach | 1 | StRS-127 |
+| M120 | Qualitätsmanagement | flach | 1 | StRS-128 |
+| M121 | Dashboard | flach | 1 | StRS-129 |
+| M122 | Todo-Liste | flach | 1 | StRS-130 |
+| M123 | Terminanfragen | flach | 1 | StRS-131 |
+| M124 | Kurzverweise und Weblinks | flach | 1 | StRS-132 |
+| M125 | Videoportal und Hilfe | flach | 1 | StRS-133 |
+| M126 | Interne Chats | flach | 1 | StRS-134 |
+| M127 | Schlagworte | flach | 1 | StRS-135 |
+| M128 | Prozesse | flach | 1 | StRS-136 |
+| M129 | Asset-Management und IT-Dokumentation | flach | 1 | StRS-137 |
+| M130 | Handelsplattform (TradePool) | flach | 1 | StRS-138 |
+| M131 | Gutscheinverwaltung | flach | 1 | StRS-139 |
+| M132 | Reisekostenabrechnung | flach | 1 | StRS-140 |
+| M133 | Externe Ticketsystemanbindung | flach | 1 | StRS-141 |
+| M134 | Dokumentensynchronisation | flach | 1 | StRS-142 |
+| M135 | Listen- und Rasteranpassung | flach | 1 | StRS-143 |
+| M136 | Soziale Netzwerke | flach | 1 | StRS-144 |
+| M137 | Abteilungen und Verkaufsgebiete | flach | 1 | StRS-145 |
+| M138 | Betriebs- und Qualitätszusagen | tief | 7 | StRS-146, StRS-147, StRS-148, StRS-149, SyRS-186, SyRS-192, SyRS-194 |
+| M139 | Abgrenzung zur Vorgängeranwendung | tief | 6 | StRS-150, SyRS-184, SwRS-047, SwRS-048, SwRS-063, SwRS-146 |
+| M140 | Architektur und Schichtung | mittel | 5 | SwRS-003, SwRS-005, SwRS-127, SwRS-150, SwRS-155 |
+| M141 | Ergebnis- und Fehlerbehandlung | mittel | 4 | SwRS-004, SwRS-007, SwRS-141, SyRS-024 |
+| M142 | Datenzugriffsschicht | tief | 6 | SwRS-008, SwRS-009, SwRS-038, SwRS-049, SwRS-142, SyRS-057 |
+| M143 | Datenmodellkonventionen | mittel | 5 | SwRS-035, SwRS-036, SwRS-037, SwRS-039, SyRS-029 |
+| M144 | Zwischenspeicherung | mittel | 4 | SwRS-018, SwRS-126, SwRS-143, SyRS-032 |
+| M145 | Produktmerkmale (Feature-Schalter) | flach | 2 | SwRS-019, SwRS-129 |
+| M146 | Belegprotokoll | flach | 2 | SwRS-064, SwRS-108 |
+| M147 | Belegpositionen und Klassifikationen | flach | 2 | SyRS-056, SyRS-058 |
+| M148 | Vertragsartikelreferenzen | flach | 1 | SwRS-077 |
+| M149 | Länder-, Regions- und Feiertagsstammdaten | flach | 1 | SyRS-038 |
+| M150 | Textbausteine und Variablenersetzung | flach | 2 | SyRS-039, SwRS-136 |
+| M151 | Plattform- und Technologiebindung | flach | 2 | SyRS-004, SwRS-152 |
+| M152 | Entwicklerschutz | flach | 2 | SyRS-028, SwRS-135 |
+| M153 | Portalanmeldung und Sitzungsverwaltung | mittel | 3 | SyRS-026, SyRS-027, SwRS-134 |
+| M154 | Steuerelementbibliothek | flach | 1 | SwRS-139 |
+| M155 | Dokumentation | flach | 1 | SwRS-145 |
+| M156 | Übertragungssicherheit | flach | 2 | SyRS-185, SyRS-189 |
+| M157 | WebSuite-Administration | nicht analysiert | 0 | _nicht analysiert:_ Nur zwei Unterordner ohne aufrufende Oberfläche im Bestand gefunden; ohne Aufrufer war keine belegbare fachliche Aussage bildbar. |
+| M158 | Portalzugriffsverwaltung (Backend) | nicht analysiert | 0 | _nicht analysiert:_ Zugriffsprüfung liegt in PortalWebServiceAccessBL; die durchsetzende Bedingung wurde im Zeitrahmen nicht bis zur Belegstufe PRIMÄR aufgelöst. |
+| M159 | TANSS-Anbindung | nicht analysiert | 0 | _nicht analysiert:_ Eine einzelne Klasse ohne begleitende Konfiguration oder Dokumentation; Auslöser und Datenrichtung nicht belegbar. |
+| M160 | Gateway-Import/-Export | nicht analysiert | 0 | _nicht analysiert:_ Formatdetails je Distributor nicht im Zeitrahmen erhoben; die Nutzenaussage ist bereits über M053 belegt. |
+| M161 | Nexus-Office-Bereich | nicht analysiert | 0 | _nicht analysiert:_ Überschneidet sich mit M109; die eigenständige Abgrenzung beider Bereiche war nicht belegbar. |
+| M162 | Nexoware-Erweiterungen | nicht analysiert | 0 | _nicht analysiert:_ Funktion ohne Gegenstelle und ohne Dokumentation im Bestand nicht bestimmbar. |
+| M163 | Transaktionsklammer (TransactionBL) | nicht analysiert | 0 | _nicht analysiert:_ Aufrufstellen nicht systematisch erhoben; ohne sie ist keine verlässliche Aussage zur Transaktionsgrenze möglich. |
+| M164 | Systemtabellenverwaltung | nicht analysiert | 0 | _nicht analysiert:_ Rein technische Hilfsschicht ohne erkennbare eigenständige fachliche Aussage. |
+| M165 | Startlogik (StartBL) | nicht analysiert | 0 | _nicht analysiert:_ Die Abfolge der Startschritte wurde nicht vollständig gelesen; eine Teilaussage wäre nicht belegbar gewesen. |
+| M166 | Werkzeugsammlung (ToolBL) | nicht analysiert | 0 | _nicht analysiert:_ Sammelbereich ohne einheitliche fachliche Aufgabe; einzelne Funktionen wären nur punktuell belegbar. |
+| M167 | Lieferantensuche und Lieferantenanlagen | nicht analysiert | 0 | _nicht analysiert:_ Abgrenzung gegenüber M014 und M051 im Zeitrahmen nicht auflösbar. |
+| M168 | Belegerfassung Zahlungsausgang | nicht analysiert | 0 | _nicht analysiert:_ Gegenstück zu M072 auf der Einkaufsseite; im Zeitrahmen nicht bis zur durchsetzenden Stelle verfolgt. |
+| M169 | Kalkulation je Filiale | nicht analysiert | 0 | _nicht analysiert:_ Modul ohne begleitende Dokumentation; die Verteilregel war nicht belegbar. |
+| M170 | Allgemeiner Datenimport und -export | nicht analysiert | 0 | _nicht analysiert:_ Konfigurierbarkeit macht eine belegbare Aussage über den Funktionsumfang ohne Beispielkonfiguration unmöglich. |
+| M171 | Artikel- und Lieferantensuchdialoge | nicht analysiert | 0 | _nicht analysiert:_ Oberflächendialoge ohne eigene Geschäftsregel; Suchlogik liegt in bereits erfassten Bereichen. |
+| M172 | Oberflächen-Hilfsbereiche | nicht analysiert | 0 | _nicht analysiert:_ Reine Oberflächenbausteine ohne eigenständige fachliche Regel. |
+| M173 | Nexus-Ticketsichten (Backend) | nicht analysiert | 0 | _nicht analysiert:_ Abgrenzung gegenüber M135 nicht belegbar; Speicherort und Geltungsbereich nicht erhoben. |
+| M174 | Versionsauskunft (WebVersion) | nicht analysiert | 0 | _nicht analysiert:_ Technische Auskunftsfunktion ohne fachliche Aussage. |
+| M175 | Bauskripte | nicht analysiert | 0 | _nicht analysiert:_ Im Zeitrahmen nicht gelesen; die Aussagen zu Bau und Auslieferung stützen sich auf M117 und M099. |
+| M176 | Lieferantenverträge | nicht analysiert | 0 | _nicht analysiert:_ Abgrenzung gegenüber M038 im Zeitrahmen nicht auflösbar; Doppelerfassung nicht ausgeschlossen. |
+
+### 4.1 Verteilung der Abdeckung
+
+| Einstufung | Module | Anteil | Anforderungen daraus |
+|------------|--------|--------|----------------------|
+| `tief` | 12 | 6,8 % | 95 |
+| `mittel` | 67 | 38,1 % | 231 |
+| `flach` | 77 | 43,8 % | 120 |
+| `nicht analysiert` | 20 | 11,4 % | 0 |
+| **Summe** | **176** | **100 %** | **446** |
+
+Die Verteilung entspricht der Vorgabe "Breite geht vor Tiefe": 156 von 176 Inventarzeilen (88,6 %) tragen mindestens eine belegte Anforderung, und nur 12 Zeilen erreichen die Einstufung `tief`.
+
+| Modul | Anforderungen | Grund der Vertiefung |
+|-------|---------------|----------------------|
+| M003 Benutzer- und Anmeldeverwaltung | 16 | Sicherheitsregel (Schritt 0c) |
+| M004 Rechteverwaltung | 13 | Berechtigungen (Schritt 0c) |
+| M007 Nummernkreisverwaltung | 7 | Abrechnung – Rechnungsnummernvergabe (Schritt 0c) |
+| M013 Passwort-Manager | 7 | Sicherheitsregel (Schritt 0c) |
+| M014 Kontenmodell und Adressen | 7 | Grundlage nahezu aller Fachprozesse |
+| M023 Belegkern | 7 | Abrechnung (Schritt 0c) |
+| M039 Vertragsabrechnung | 6 | Abrechnung (Schritt 0c) |
+| M096 Hintergrunddienste | 6 | Abrechnung – die Fakturierung läuft zeitgesteuert |
+| M117 Qualitätssicherung und Bauabläufe | 7 | Ableitung von Betriebs- und Qualitätsanforderungen |
+| M138 Betriebs- und Qualitätszusagen | 7 | Sammelzeile; siehe Einschränkung unten |
+| M139 Abgrenzung zur Vorgängeranwendung | 6 | Migrationsperspektive |
+| M142 Datenzugriffsschicht | 6 | trägt Nebenläufigkeits- und Transaktionsverhalten |
+
+Zwei Einschränkungen zur Aussagekraft dieser Einstufung sind zu nennen. Erstens ist die Regel rein quantitativ; sie misst die Zahl der gebildeten Anforderungen, nicht die Tiefe der Durchdringung. Zweitens ist M138 dadurch als `tief` eingestuft, obwohl es die schwächste Zeile des gesamten Bestands ist: Die Zeile bündelt Verfügbarkeit, Datensicherung, Aufbewahrung und Mengengerüst, und **alle sieben** ihrer Anforderungen sind `[HYPOTHESE]`. Die Einstufung ist damit formal richtig und fachlich irreführend – sie ist hier bewusst nicht von Hand korrigiert worden, damit die Regel über alle 176 Zeilen gleich angewandt bleibt.
+
+Zwei nach Schritt 0c erwartete Schwerpunkte erreichen die Stufe `tief` nicht: M019 (Preisfindung, 4 Anforderungen) und M038 (Vertragsverwaltung, 5) liegen knapp darunter, M113 (Legacy-Schnittstelle, 5) ebenfalls – bei letzterer deshalb, weil ihre Sicherheitsaussagen an den schichtübergreifenden Zeilen M141 und M152 hängen. In der Sache sind alle drei bis auf die durchsetzende Stelle verfolgt.
+
+---
+
+## 5 Konsistenzcheck
+
+Der Check lief maschinell über alle 446 Anforderungsblöcke in `StRS.md`, `SyRS.md` und `SwRS.md` sowie über `Traceability.md` und `Hypothesen.md`.
+
+### 5.1 Formale Prüfungen
+
+| Nr. | Prüfung | Ergebnis | Bewertung |
+|-----|---------|----------|-----------|
+| 1 | Anforderungsblöcke insgesamt | 446 | – |
+| 2 | Mehrfach vergebene IDs | **0** | bestanden |
+| 3 | Blöcke mit fehlendem Pflichtfeld (16 Felder je Block) | **0** | bestanden |
+| 4 | Anforderungen ohne jeden Beleg | **0** | bestanden |
+| 5 | Anforderungen ohne `Übernahmewürdigkeit` | **0** | bestanden |
+| 6 | Anforderungen ohne `Prüfidee` | **0** | bestanden |
+| 7 | Tracelinks auf nicht existierende IDs (368 eindeutige Ziele) | **0** | bestanden |
+| 8 | Inline-`[HYPOTHESE]` gegen Feld `Status: HYPOTHESE` | 36 = 36, Differenzmenge leer | bestanden |
+| 9 | `Hypothesen.md` gegen Inline-Markierungen | 36 = 36, Differenzmenge leer | bestanden |
+| 10 | SyRS-Anforderungen mit Verweis auf mindestens eine StRS | 155 von 155 | bestanden |
+| 11 | SwRS-Anforderungen mit Verweis auf mindestens eine SyRS | 141 von 141 | bestanden |
+| 12 | StRS-Anforderungen ohne verfeinernde SyRS | **19** | siehe Abschnitt 7, Lücke L1 |
+| 13 | IDs, die in `Traceability.md` fehlen | **0** | bestanden |
+| 14 | Wort- oder deckungsgleiche Titel ohne Konsolidierungsvermerk | **0** | bestanden |
+| 15 | Anforderungen mit `Qualitätsmerkmal` im dafür vorgesehenen Feld | 181 | siehe Abschnitt 5.4 |
+
+Prüfung 12 ist der einzige offene Punkt. Die betroffenen Anforderungen sind StRS-126 bis StRS-136 und StRS-138 bis StRS-145 – durchweg Module der Einstufung `flach`, für die auf Stakeholderebene ein belegter Zweck festgehalten, auf Systemebene aber keine belegbare Verhaltensaussage gebildet werden konnte. Sie sind keine Traceability-Fehler, sondern eine bewusst offengelassene Verfeinerungslücke; `Traceability.md` weist sie gesondert aus.
+
+### 5.2 Belegsituation
+
+| Belegklasse | Anzahl | Anteil |
+|-------------|--------|--------|
+| `PRIMÄR` (durchgesetzte Regel im Code oder Datenbankbedingung) | 1.067 | 85,0 % |
+| `SEKUNDÄR` (Oberflächentext, Fehlermeldung, Berichtslayout, Abbildungstabelle, Konfigurationsschalter) | 111 | 8,8 % |
+| `KONTEXT` (Kommentar, Bezeichner, Dokumentationsverweis) | 77 | 6,1 % |
+| **Summe** | **1.255** | **100 %** |
+
+Acht Anforderungen tragen ausschließlich `SEKUNDÄR`- oder `KONTEXT`-Belege: StRS-021, StRS-120, StRS-128, StRS-142, StRS-146, StRS-147, StRS-149 und SyRS-173. Alle acht sind als `[HYPOTHESE]` gekennzeichnet – die Regel "ohne durchgesetzte Stelle keine belegte Anforderung" ist damit ausnahmslos eingehalten.
+
+### 5.3 Übernahmewürdigkeit und Anforderungsarten
+
+| `Übernahmewürdigkeit` | Anzahl | Anteil |
+|-----------------------|--------|--------|
+| `übernehmen` | 411 | 92,2 % |
+| `Workaround` | 18 | 4,0 % |
+| `veraltet` | 15 | 3,4 % |
+| `Sonderfall` | 2 | 0,4 % |
+
+| `Typ` | Anzahl |
+|-------|--------|
+| funktional | 217 |
+| Sicherheit | 69 |
+| Daten | 69 |
+| Schnittstelle | 46 |
+| nicht-funktional | 45 |
+
+Der Anteil von 92,2 % `übernehmen` ist plausibel, weil die Analyse breit angelegt war und tragende Fachfunktionen überwiegen; die 35 Anforderungen mit `Workaround`, `veraltet` oder `Sonderfall` betreffen erkennbare Altlasten – unter anderem die SHA-1-Kennwortspeicherung (SyRS-007), den fest im Quelltext hinterlegten Verschlüsselungsschlüssel (SwRS-029), die temporären Legacy-Entitäten des Belegwesens (SwRS-047, SwRS-048) und die deaktivierte Reisekostenabrechnung (StRS-140).
+
+### 5.4 Zuordnung der Qualitätsmerkmale
+
+Der Check deckte einen Verstoß gegen die Formatvorgabe im eigenen Bestand auf und führte zu einer Korrektur: 53 Anforderungen trugen den Wert `Sicherheit` im Feld `Typ`, ließen das Feld `Qualitätsmerkmal` aber leer. Da `Sicherheit` zugleich ein Qualitätsmerkmal nach ISO/IEC 25010 ist, wäre die Merkmalsangabe damit faktisch im Feld `Typ` gestanden. Zwei dieser Anforderungen (SyRS-013, SwRS-023 zur Lizenzprüfung) wurden auf `Typ: funktional` umgestellt, weil sie eine Funktionsprüfung und keine Sicherheitseigenschaft beschreiben; die übrigen 51 haben das zutreffende Untermerkmal im Feld `Qualitätsmerkmal` erhalten. Zusätzlich wurden acht abweichend benannte Merkmale auf die Begriffe der Norm vereinheitlicht (`Zugriffskontrolle` → `Vertraulichkeit`, `Nachweisbarkeit` → `Zurechenbarkeit`, `Sicherheit (Verfügbarkeit)` → `Sicherheit (Widerstandsfähigkeit)`).
+
+Nach der Korrektur tragen 181 Anforderungen ein Qualitätsmerkmal. Die 98 Anforderungen mit `Typ: Daten` oder `Typ: Schnittstelle` ohne Merkmalsangabe sind kein Verstoß: `Daten` und `Schnittstelle` sind Anforderungsklassen nach ISO/IEC/IEEE 29148 und keine Qualitätsmerkmale nach ISO/IEC 25010; die Vorgabe verlangt die Merkmalsangabe ausdrücklich nur für nicht-funktionale Anforderungen.
+
+### 5.5 Im Lauf korrigierte Befunde
+
+Die folgenden Angaben waren in einer Zwischenfassung falsch und wurden vor der Fertigstellung durch Nachzählung berichtigt. Sie sind hier aufgeführt, weil sie zeigen, an welchen Stellen eine Schätzung ohne Nachzählung in die Irre geführt hätte.
+
+| Gegenstand | Zwischenstand | Nachgezählt | Auswirkung |
+|------------|---------------|-------------|------------|
+| Controller der modernen REST-API | 27 | **41** | Umfangsangabe in StRS-122 und SyRS-175 |
+| Operationen der RMM-/RiverDivo-Schnittstelle | 28 | **29** je Seite | StRS-123 |
+| Einstellungscontroller in `ModuleRegistration` | 85 | **83** | StRS-106, SwRS-130 |
+| Tabellen mit Präfix `AssetManagement` | 17 | **221** | StRS-137 – die Hypothese wurde dadurch erheblich stärker: 221 Tabellen stehen 3 Fachklassen gegenüber |
+| Rechteabschnitte in `CentronRights.md` | 30 | **35** | SwRS-145 |
+| Operationen ohne `[Authenticate]` | zunächst zu hoch (fehlerhafte Attributauswertung über zwei Zeilen) | **171 von 2.618** | SyRS-017 – die erste Auswertung meldete Operationen als ungeschützt, die das Attribut in derselben Zeile tragen |
+| Methodenname im Warenkorb | `ReceiptCartBL.CreateCart` | **`CreateNewCart(LoggedInUser, string, string)`** | StRS-115, SwRS-062 |
+| Ablageort von `LoggedInUser.cs` | `Centron.Interfaces/Administration/Logins/` | **`Centron.Entities/Entities/Administration/Logins/`** | SwRS-015 |
+| Belegstornierung | Annahme einer Methode `ReceiptBL.DeleteReceipt(int, CentronObjectKindNumeric)` aus der Dokumentation | in `Centron.BL` **nicht vorhanden**; dort existiert nur `DeleteReceiptUserState(int)` | StRS-148 wurde umgeschrieben: Die Abweichung zwischen Dokumentation und Code ist nun selbst der belegte Befund |
+| Fehlende Verfeinerungsverweise | 6 SwRS ohne SyRS-Bezug, 4 Ketten ohne StRS-Wurzel | ergänzt | SwRS-005, 035, 036, 039, 049, 064, 069, 108, 127, 150 |
+
+Der letzte Fall ist der wichtigste: Eine Aussage, die aus der mitgelieferten Dokumentation übernommen und nicht am Code geprüft worden wäre, hätte eine nicht existierende Methode als belegte Anforderung ausgewiesen. Die Prüfung am Quelltext hat das verhindert; für das Zielsystem ist der tatsächliche Befund – Belege werden storniert, nicht gelöscht – die verwertbare Aussage.
+
+### 5.6 Inhaltsgleiche Anforderungen und Konsolidierungsbedarf
+
+Kein Paar von Anforderungen ist wort- oder deckungsgleich, ohne als Konsolidierungskandidat gekennzeichnet zu sein (Prüfung 14). Anforderungen, die denselben Sachverhalt auf verschiedenen Ebenen beschreiben, sind bewusst nicht als Konsolidierungsfall geführt; sie sind über Tracelinks verbunden, wie in der Vorgabe verlangt.
+
+141 Anforderungen (31,6 %) benennen einen Konsolidierungskandidaten im Sinne der Vorgabe: fachlich gleichwertige Gegenstände in getrennten Umsetzungen. Die tragenden Fälle:
+
+| Fachlicher Gegenstand | Getrennte Umsetzungen | Anforderungen |
+|-----------------------|------------------------|---------------|
+| Gerätebestand beim Kunden | `MasterDataList`/`GeraeteKopf` (Stammblätter), `AccountDevices`, `AssetManagementDevices` – drei Datenhaltungen für dasselbe Geschäftsobjekt | StRS-026, StRS-137, SwRS-045, SwRS-046 |
+| Geschäftspartner | Alttabellen `Kunden`/`Kreditor` neben den Sichten `Accounts`/`AccountCustomers`/`AccountSuppliers`; Module `AccountManagement` und `Crm` | StRS-016, StRS-017, SyRS-030, SwRS-040 |
+| Belegpersistenz | modernes Entitätsmodell, temporäre Legacy-Entitäten `*Kopf`/`*Pos`, elf `SaveReceipt*Repository`-Klassen | StRS-027, SyRS-043, SwRS-047, SwRS-048, SwRS-051 |
+| Fachfunktionen des Clients | jede Funktion doppelt als `BL`- und `WS`-Umsetzung (direkter Datenbankzugriff neben Webservicezugriff) | StRS-106, SwRS-003, SwRS-005 |
+| Schnittstellen | Legacy-REST (2.618 Operationen) neben moderner versionierter API (41 Controller) mit überlappendem Umfang | StRS-121, StRS-122, SyRS-024, SwRS-131, SwRS-132 |
+| Monitoringanbindung | `RMMinterface/*` und `RiverDivo/*` – zwei vollständig parallele Schnittstellen mit je 29 gleichnamigen Operationen | StRS-123, SyRS-176, SwRS-133 |
+| Änderungsprotokolle | 36 Entitäten mit Endung `Log` und 27 mit Endung `History` für denselben Zweck | StRS-013, SyRS-080, SwRS-030, SwRS-031 |
+| Benachrichtigungen | `CentronNotification`, `NexusNotification`, `UserNotification`, `MyDayNotification`, Eskalationsmeldungen – fünf Wege | StRS-100, SyRS-146, SwRS-125 |
+| Abrechnung von Serviceleistungen | vereinfachte Ticketabrechnung, Vertragsabrechnung, Pauschalabrechnung – drei Wege für dieselben Ticketzeiten | StRS-050, StRS-045, StRS-051 |
+| Preisfindung | fünf interne Preisquellen (Preisliste, Sonderpreis, Aktionspreis, Projektpreis, Vertragspreis) und sieben Einkaufspreisquellen | StRS-024, StRS-061, SwRS-043, SwRS-066 |
+| Projektbegriff | `CrmProject`, `TicketProject`, `ReceiptContract.ProjectNumber` | StRS-022, StRS-072 |
+| Rechtedurchsetzung | drei Baukästen: `ModuleRegistration` (Client), `CentronAuthorization`/Policies (Portal), `AuthorizeUserRight*` (API) | StRS-005, SyRS-011, SwRS-027, SwRS-028 |
+| Sichtbarkeitsregel für Tickets | `HelpdeskBL.GetShowHelpdeskRight` und `TicketFilterService` – dieselbe Regel getrennt umgesetzt | StRS-065, SwRS-021, SwRS-022 |
+| Nebenläufigkeitsschutz | optimistische Sperre (`ConcurrencyControlGuid`) und pessimistische Sperre (`AssetLock`) nebeneinander | StRS-031, SyRS-044, SwRS-055 |
+| Kryptografische Bausteine | `SHA1Decoder`, `SHA512CryptoLogic`, `AESCryptoLogic`, `CryptoControl`, `CryptoUtils`, `AccessTokenBL.HashToken` | SwRS-029, SyRS-007 |
+| Inventur | `InventoryBL`, `InventoryNewBL`, `InventorysBL` | StRS-056, SwRS-084 |
+| Datenbenennung | deutschsprachige Basistabellen neben englischsprachigen Sichten für dieselben Daten | SyRS-057, SwRS-035, SwRS-049 |
+
+Der in der Aufgabenstellung genannte Beispielfall – Drucker als "Stammblätter", andere Hardware als "Assets" – ist damit nicht nur bestätigt, sondern um eine dritte Haltung erweitert: `AssetManagementDevices` mit 221 zugehörigen Tabellen.
+
+
+### 5.7 Risikorelevante Anforderungen und ihre Belegsituation
+
+Diese Liste macht Verstöße gegen die risikobasierte Priorisierung innerhalb des Laufs sichtbar. Als risikorelevant gilt eine Anforderung, deren **Titel oder Aussage** Sicherheitsregeln, Abrechnung oder Berechtigungen zum Gegenstand hat; das Kriterium wurde maschinell und einheitlich über alle 446 Blöcke angewandt (Stichwortmenge: Recht, Berechtigung, Authentifizierung, Anmeldung, Kennwort, Verschlüsselung, Signatur, Token, Lizenz, Rechnung, Abrechnung, Mahnung, Zahlung, SEPA, Provision, Preis, Steuer, Sicherheit, Freigabe, Sichtbarkeit, Zugriff, Storno, Gutschrift). Es wurde bewusst weit gefasst: Lieber eine fachlich harmlose Anforderung zu viel in der Prüfung als eine sicherheitsrelevante zu wenig.
+
+**Ergebnis: 227 von 446 Anforderungen (50,9 %) sind risikorelevant. Alle 227 tragen mindestens einen `PRIMÄR`-Beleg mit durchsetzender Stelle. Es gibt keinen Verstoß gegen die risikobasierte Priorisierung.**
+
+Zwölf der 227 sind zusätzlich als `[HYPOTHESE]` gekennzeichnet. Das ist kein Widerspruch: Der belegte Kern der Aussage ist durch die durchsetzende Stelle abgedeckt, die Aussage reicht aber darüber hinaus – etwa SyRS-189, wo die Zählung der Aufrufe belegt ist, eine Begrenzung jedoch nachweislich fehlt und die Anforderung deshalb eine Sollaussage über den Zielzustand trifft.
+
+Verteilung: 75 StRS, 89 SyRS, 63 SwRS.
+
+| ID | Titel | PRIMÄR-Beleg | Kennzeichnung |
+|----|-------|--------------|---------------|
+| StRS-001 | Mandantenfähige Abbildung der eigenen Unternehmensstruktur | ja | – |
+| StRS-003 | Anmeldung interner Benutzer mit Benutzername und Kennwort | ja | – |
+| StRS-004 | Zeitlich und dauerhaft steuerbare Deaktivierung von Benutzerkonten | ja | – |
+| StRS-005 | Rechtebasierter Zugang zu Fachmodulen | ja | – |
+| StRS-006 | Einschränkende Rechte begrenzen die Sicht auf eigene Vorgänge oder die eigene Filiale | ja | – |
+| StRS-007 | Zwei-Faktor-Authentifizierung mit konfigurierbarer Gültigkeitsdauer | ja | – |
+| StRS-008 | Anmeldung über Microsoft Entra ID (OpenID Connect) | ja | – |
+| StRS-009 | Anmeldung über Active Directory als Alternative zur lokalen Kennwortprüfung | ja | – |
+| StRS-010 | Lizenzgesteuerter Funktionsumfang | ja | – |
+| StRS-011 | Zugangstoken für die Anbindung externer Systeme | ja | – |
+| StRS-012 | Kundenzugang über Webaccounts mit eigenem Rechtesystem | ja | – |
+| StRS-014 | Datenschutzgerechte Löschung personenbezogener Daten | ja | – |
+| StRS-015 | Verwaltung von Kundenzugangsdaten im Passwort-Manager | ja | – |
+| StRS-023 | Kundenaudits und Fragebögen | ja | – |
+| StRS-024 | Kundenspezifische Sonderpreise und Preislisten | ja | – |
+| StRS-025 | Bankverbindungen und SEPA-Mandate am Geschäftspartner | ja | – |
+| StRS-027 | Durchgängige Belegkette vom Angebot bis zur Rechnung | ja | – |
+| StRS-029 | Belege dürfen nur von berechtigten Benutzern der zuständigen Filiale bearbeitet werden | ja | – |
+| StRS-033 | Lückenlose und kollisionsfreie Vergabe von Belegnummern | ja | – |
+| StRS-034 | Zahlungsbedingungen mit Skontostaffel und belegartbezogener Gültigkeit | ja | – |
+| StRS-035 | Mehrwertsteuer mit zeitlicher Gültigkeitskette | ja | – |
+| StRS-036 | Belege in Fremdwährung | ja | – |
+| StRS-038 | Provisionsabrechnung für Vertriebsmitarbeiter | ja | – |
+| StRS-039 | Anzahlungsrechnungen und Schlussrechnung mit Anzahlungsverrechnung | ja | – |
+| StRS-041 | Elektronische Rechnung nach ZUGFeRD und XRechnung | ja | – |
+| StRS-042 | Zweistufiges Freigabewesen für Kundenwarenkörbe | ja | – |
+| StRS-043 | Import von Projekt- und Sonderpreisen aus Lieferantendateien | ja | – |
+| StRS-044 | Wartungs- und Serviceverträge als eigene Belegart | ja | – |
+| StRS-045 | Automatische Rechnungsstellung aus Verträgen | ja | – |
+| StRS-046 | Abrechnungsintervalle mit Vielfachen und Mehrfachperioden je Rechnung | ja | – |
+| StRS-047 | Kontingentverwaltung und Kontingentgrenzen im Vertrag | ja | – |
+| StRS-048 | Zählerbasierte Abrechnung von Druck- und Kopiergeräten | ja | – |
+| StRS-049 | Nutzungsabhängige Abrechnung anhand von Daten eines externen RMM-Systems | ja | – |
+| StRS-050 | Vereinfachte Abrechnung erfasster Ticketzeiten | ja | – |
+| StRS-051 | Pauschalabrechnung von Projekten | ja | – |
+| StRS-052 | Auswertung von Verträgen und Managed-Service-Beständen | ja | – |
+| StRS-053 | Artikelstamm mit Preisen, Einheiten und Warengruppenzuordnung | ja | – |
+| StRS-054 | Warengruppen als Ordnungs- und Steuerungsmerkmal | ja | – |
+| StRS-055 | Bestandsführung über mehrere Lager, Lagerbereiche und Lagerplätze | ja | – |
+| StRS-060 | Elektronischer Belegaustausch mit Distributoren | ja | – |
+| StRS-061 | Vergleich von Einkaufspreisen über mehrere externe Preisquellen | ja | – |
+| StRS-063 | Artikelimport aus Lieferanten- und Katalogdaten | ja | – |
+| StRS-065 | Abgestufte Ticketsichtbarkeit für Mitarbeiter und Kundenkontakte | ja | – |
+| StRS-066 | Zeiterfassung auf Tickets als Grundlage der Leistungsabrechnung | ja | – |
+| StRS-067 | Schutz erfasster Zeiten vor unberechtigter Änderung und Löschung | ja | – |
+| StRS-068 | Fälligkeitsberechnung aus der Ticketpriorität unter Berücksichtigung von Geschäftszeiten | ja | – |
+| StRS-074 | Kundenformulare zur strukturierten Datenerhebung | ja | – |
+| StRS-077 | KI-Unterstützung bei Ticketbearbeitung und Angebotserstellung | ja | – |
+| StRS-078 | Mahnwesen mit drei Mahnstufen | ja | – |
+| StRS-079 | Mahnvorschau und Zurücksetzen eines Mahnlaufs | ja | – |
+| StRS-080 | Offene-Posten-Auswertung und Zahlungseingang | ja | – |
+| StRS-081 | SEPA-Zahlungsverkehr mit Lastschrift und Überweisung | ja | – |
+| StRS-083 | Belegtransfer an DATEV Unternehmen online | ja | – |
+| StRS-085 | Kostenstellen und Kostenträger | ja | – |
+| StRS-087 | Produktionsaufträge mit Positionen und Protokoll | ja | – |
+| StRS-089 | Auslastung und Leistungsnachweise von Mitarbeitern | ja | – |
+| StRS-093 | Berichtswesen mit zentral verwalteten Berichtsvorlagen | ja | – |
+| StRS-094 | Zeitgesteuerte Berichtserstellung und -verteilung über den Reportserver | ja | – |
+| StRS-097 | Massenänderung von Beleg-, Artikel- und Kontendaten | ja | – |
+| StRS-098 | Kundenindividuelle Zusatzfelder ohne Codeänderung | ja | – |
+| StRS-103 | Direkter Datenbankzugriff für Administratoren | ja | – |
+| StRS-104 | Automatisierte Hintergrundverarbeitung mit zentraler Steuerung | ja | – |
+| StRS-105 | Nutzungserfassung für Abrechnung und Produktsteuerung | ja | – |
+| StRS-106 | Wahlweiser Betrieb des Windows-Clients mit direktem Datenbankzugriff oder über den Webservice | ja | – |
+| StRS-107 | Installation und Aktualisierung des Windows-Clients | ja | – |
+| StRS-115 | Kundenbestellung über den WebCart | ja | – |
+| StRS-117 | Digitale Bestätigung und Unterzeichnung von Dokumenten | ja | – |
+| StRS-119 | Outlook-Add-In für Ticket- und Belegzugriff aus der E-Mail heraus | ja | – |
+| StRS-122 | Ressourcenorientierte REST-API als Nachfolgeschnittstelle | ja | – |
+| StRS-124 | Anbindung weiterer Fremdsysteme des Systemhausgeschäfts | ja | – |
+| StRS-125 | Automatisierte Qualitätssicherung vor der Auslieferung | ja | – |
+| StRS-126 | Verwaltung von Softwarelizenzen des Kunden (Produkt-Lifecycle) | ja | – |
+| StRS-131 | Terminanfragen mit Terminvorschlägen | ja | – |
+| StRS-140 | Reisekostenabrechnung | ja | – |
+| StRS-148 | Aufbewahrungsfristen und Unveränderbarkeit steuerlich relevanter Belege | ja | `[HYPOTHESE]` |
+| SyRS-001 | Mandantenbezogene Stammdaten für Ausgangsdokumente und Zahlungsverkehr | ja | – |
+| SyRS-005 | Anmeldevorgang mit Ticketausgabe | ja | – |
+| SyRS-006 | Prüfkette der Kontogültigkeit bei jeder Anmeldung | ja | – |
+| SyRS-007 | Kennwortspeicherung mit ungesalzenem SHA-1-Hash | ja | – |
+| SyRS-008 | Zweitfaktorverfahren RADIUS und E-Mail-Bestätigungslink | ja | – |
+| SyRS-009 | Auswahl des Authentifizierungsverfahrens mit Rückfallweg | ja | – |
+| SyRS-010 | Hierarchisches Rechtemodell mit numerischen Rechtekennungen | ja | – |
+| SyRS-011 | Rechteprüfung an drei unabhängigen Durchsetzungspunkten | ja | – |
+| SyRS-012 | Serverseitige Durchsetzung einschränkender Sichtrechte als Pflichtfilter | ja | – |
+| SyRS-013 | Lizenzprüfung mit Anzahl, Ablaufdatum und Ablaufversion bei der Ticketvergabe | ja | – |
+| SyRS-014 | Lizenzabhängige Bereitstellung von Modulen und Einstellungsseiten | ja | – |
+| SyRS-015 | Zugangstoken als gleichwertiges Authentifizierungsmittel der Schnittstelle | ja | – |
+| SyRS-016 | Getrenntes Rechtemodell für Webaccounts | ja | – |
+| SyRS-017 | Authentifizierungspflicht aller zustandsändernden Schnittstellenmethoden | ja | – |
+| SyRS-018 | Attributgesteuerte Änderungsverfolgung über die Persistenzschicht | ja | – |
+| SyRS-020 | Zugriffsschutz und Protokollierung im Passwort-Manager | ja | – |
+| SyRS-021 | Symmetrische Verschlüsselung mit ableitbarem Standardschlüssel | ja | – |
+| SyRS-022 | Ticketgültigkeit, Verlängerung und Bereinigung | ja | – |
+| SyRS-023 | Protokollierung der Anmeldeherkunft | ja | – |
+| SyRS-024 | Fehlerbehandlung ohne Preisgabe interner Details in der Schnittstelle | ja | – |
+| SyRS-025 | Zusätzliche Beschränkung auf gehostete Umgebungen | ja | – |
+| SyRS-026 | Schutz vor offener Weiterleitung im Anmeldeweg des Portals | ja | – |
+| SyRS-032 | Seitenweiser Zugriff auf große Ergebnismengen | ja | – |
+| SyRS-035 | Audits mit Fragenkategorien und Freigabeprozess | ja | – |
+| SyRS-036 | Mehrstufige Preisfindung für Belegpositionen | ja | – |
+| SyRS-037 | Geräteidentität über Seriennummer, Barcode und freie Inventarnummer | ja | – |
+| SyRS-038 | Länder-, Regions- und Währungsstammdaten als Grundlage steuerlicher und logistischer Regeln | ja | – |
+| SyRS-042 | Belegartspezifische Bearbeitungs- und Sichtrechte | ja | – |
+| SyRS-046 | Belegartbezogene Gültigkeit und Fälligkeitsregeln der Zahlungsbedingungen | ja | – |
+| SyRS-047 | Datumsabhängige Ermittlung des Steuersatzes über eine Satzkette | ja | – |
+| SyRS-048 | Führung von Belegwerten in Beleg- und Hauswährung | ja | – |
+| SyRS-050 | Provisionsermittlung über Schema, Staffel, Ziel und Kundenzuordnung | ja | – |
+| SyRS-051 | Anzahlungsrechnungen mit Variablentexten und Verrechnung in der Schlussrechnung | ja | – |
+| SyRS-053 | Erzeugung der E-Rechnung als eigenständiges XML und als eingebettetes PDF | ja | – |
+| SyRS-054 | Zustandsgesicherte Übergänge im Warenkorb-Freigabewesen | ja | – |
+| SyRS-056 | Typisierte Belegpositionen mit Sichtbarkeits- und Gruppierungssteuerung | ja | – |
+| SyRS-057 | Mehrstufige Belegsuche über Sichten und benannte Abfragen | ja | – |
+| SyRS-058 | Belegexport nach Excel mit konfigurierbaren Einstellungen | ja | – |
+| SyRS-070 | Vertragsmodell mit Laufzeit-, Abrechnungs- und Kontingentsteuerung | ja | – |
+| SyRS-071 | Abrechnungslauf mit Vertragsauswahl, Rechnungserzeugung, Versand und Ergebnisprotokoll | ja | – |
+| SyRS-072 | Zerlegung eines Abrechnungszeitraums in Teilperioden | ja | – |
+| SyRS-073 | Kontingentverbrauch, Restwert und Ausgleichsartikel | ja | – |
+| SyRS-074 | Zählerstände mit Historie, Freimengen, Staffelpreisen und Begründungspflicht | ja | – |
+| SyRS-075 | Abbruch der Rechnungserzeugung bei nicht erreichbarem Mengenlieferanten | ja | – |
+| SyRS-077 | Pauschalabrechnung unabhängig von den erfassten Einzelleistungen | ja | – |
+| SyRS-078 | MSP-Auswertung mit Historie und Überführung in Vertragspositionen | ja | – |
+| SyRS-080 | Artikelmodell mit Einheiten, Staffelpreisen, Varianten und Protokoll | ja | – |
+| SyRS-081 | Warengruppe als Träger steuerlicher und buchhalterischer Vorgaben | ja | – |
+| SyRS-082 | Bestandsbuchungen mit Rechteprüfung, Wertfortschreibung und Protokoll | ja | – |
+| SyRS-087 | EDI-Verarbeitung mit formatabhängigem Zerteilen und Protokollierung | ja | – |
+| SyRS-088 | Preisspiegel mit Gültigkeitsfilter und Zwischenspeicher | ja | – |
+| SyRS-090 | Zeitgesteuerter Artikelimport mit Abgleich gegen den Bestand | ja | – |
+| SyRS-100 | Ticketmodell mit Pflichtfeldprüfung, Präfix und Feldlängenschutz | ja | – |
+| SyRS-103 | Abgestufte Rechteprüfung bei Änderung und Löschung erfasster Zeiten | ja | – |
+| SyRS-104 | Fälligkeitsberechnung mit Geschäftszeiten- und Wochenendübertrag | ja | – |
+| SyRS-110 | Formulare mit Feldern, Auslösern, Aktionen und Zuständen | ja | – |
+| SyRS-113 | KI-Anbindung mit Modellkatalog, Zugangsprüfung und Nutzungserfassung | ja | – |
+| SyRS-120 | Mahnlauf mit Vorschau, Rechteprüfung, Stufenfortschreibung und Rücknahme | ja | – |
+| SyRS-121 | Offene-Posten-Lauf und Zahlungseingangserfassung | ja | – |
+| SyRS-122 | Transaktionsgesicherter SEPA-Export mit Kennzeichnung und Protokoll | ja | – |
+| SyRS-130 | Produktionsauftrag mit Positionen, Protokoll und Portalzugriff | ja | – |
+| SyRS-132 | Tagesplanung mit Stapelverarbeitung, Import und Tagesabschluss | ja | – |
+| SyRS-134 | Anrufdatenerfassung über TAPI und Microsoft Graph mit Rufnummernauflösung | ja | – |
+| SyRS-140 | Berichtssystem mit Gruppen, Parametern und fachspezifischen Erzeugern | ja | – |
+| SyRS-142 | Volltextindex mit Anforderungssteuerung und Vollaufbau | ja | – |
+| SyRS-143 | Massenänderung mit Vorlage, Trefferanzeige und getrennten Läufen | ja | – |
+| SyRS-144 | Frei definierbare Zusatzfelder mit typisierten Werten | ja | – |
+| SyRS-145 | Ressourcenbasierte Lokalisierung je Baustein | ja | – |
+| SyRS-148 | Skriptmaschine mit Einmalausführung, Reihenfolge und wiederkehrenden Skripten | ja | – |
+| SyRS-149 | Abfragewerkzeug mit administrativem Rechteschutz | ja | – |
+| SyRS-160 | Einheitlicher Datenzugriff des Windows-Clients über austauschbare Umsetzungen | ja | – |
+| SyRS-161 | Signierte Auslieferungspakete mit abgeleiteter Versionsnummer | ja | – |
+| SyRS-163 | Verbindungs- und Umgebungsverwaltung mit Prüfwerkzeugen | ja | – |
+| SyRS-167 | Webportal als serverseitig gerenderte Anwendung mit Sitzungsüberwachung | ja | – |
+| SyRS-168 | Getrennte Anmeldewege und Startseiten für Mitarbeiter, Kunden und Outlook | ja | – |
+| SyRS-169 | Warenkorb mit Lizenz-, Zugriffs- und Zustandsprüfung je Operation | ja | – |
+| SyRS-171 | Tokenbasierter Dokumentzugriff mit Bestätigung, Ablehnung und Unterschrift | ja | – |
+| SyRS-172 | Outlook-Aufgabenbereich mit Office-Anmeldung und E-Mail-Kontext | ja | – |
+| SyRS-174 | Einheitliches Anfrage- und Antwortformat der Legacy-Schnittstelle | ja | – |
+| SyRS-177 | Anbindung von Fremdsystemen über je eigene Konfiguration und Lizenz | ja | – |
+| SyRS-178 | Mehrstufige automatisierte Prüfung vor der Aufnahme einer Änderung | ja | – |
+| SyRS-185 | Gesicherte Übertragung zwischen den Systembestandteilen | ja | `[HYPOTHESE]` |
+| SyRS-186 | Trennung der Mandanten auf Datenhaltungsebene | ja | `[HYPOTHESE]` |
+| SyRS-187 | Anbindung des Lizenzservers | ja | `[HYPOTHESE]` |
+| SyRS-189 | Begrenzung der Aufrufhäufigkeit an der Schnittstelle | ja | `[HYPOTHESE]` |
+| SyRS-190 | Kennwortrichtlinien für Benutzer- und Portalkonten | ja | `[HYPOTHESE]` |
+| SyRS-191 | Wirksamkeit eines Rechteentzugs auf laufende Sitzungen | ja | `[HYPOTHESE]` |
+| SyRS-193 | Archivierung von Belegdokumenten | ja | `[HYPOTHESE]` |
+| SyRS-195 | Berechtigung zeitgesteuert erzeugter Berichte | ja | `[HYPOTHESE]` |
+| SwRS-008 | Sitzungsverwaltung mit Fachlogikzugriff und Transaktionssteuerung | ja | – |
+| SwRS-009 | Generische und spezialisierte Datenzugriffsobjekte | ja | – |
+| SwRS-010 | Authentifizierungsklassen als Vererbungshierarchie mit gemeinsamem Ablauf | ja | – |
+| SwRS-013 | Verfahrensauswahl mit Rückfall- und Fehlschlagbaustein | ja | – |
+| SwRS-015 | Anmeldekontext als gemeinsames Objekt für Benutzer, Webaccount und Zugangstoken | ja | – |
+| SwRS-016 | Anwendungsarten als typisierte Beschreibung anmeldefähiger Produkte | ja | – |
+| SwRS-017 | Interceptorkette mit fester Reihenfolge an der Schnittstelle | ja | – |
+| SwRS-018 | Zwischenspeicher für Rechte, Einstellungen und Stammdaten im Client | ja | – |
+| SwRS-019 | Produktmerkmale als schaltbare Fähigkeitskennzeichen | ja | – |
+| SwRS-020 | Rechteprüfung als Sammelabfrage mit Ergebnisliste | ja | – |
+| SwRS-021 | Auswertung der Ticketsichtrechte in der Geschäftslogik | ja | – |
+| SwRS-022 | Aufbau des Pflichtfilters für Ticketlisten im Portal | ja | – |
+| SwRS-023 | Lizenzverwaltung als prozessweiter Dienst mit Mengen- und Fristprüfung | ja | – |
+| SwRS-024 | Zugangstoken als Entität mit Hash, Gültigkeit und Protokoll | ja | – |
+| SwRS-026 | Auswertbare Rechteausdrücke für die Modulregistrierung | ja | – |
+| SwRS-027 | Autorisierungsattribute der modernen Schnittstelle | ja | – |
+| SwRS-028 | Anspruchsverwaltung und Autorisierungsbausteine des Portals | ja | – |
+| SwRS-033 | Datenmodell des Passwort-Managers auf Basis benutzerdefinierter Eigenschaften | ja | – |
+| SwRS-034 | Symmetrische Verschlüsselung mit Schlüsselableitung aus einem Hash | ja | – |
+| SwRS-038 | Benannte Abfragen und roher SQL-Zugriff als geregelte Ausnahme | ja | – |
+| SwRS-043 | Preisquellen als getrennte Entitäten mit eigenem Gültigkeitszeitraum | ja | – |
+| SwRS-044 | Bankverbindung, Mandat und Zahlungsprotokoll als verbundene Entitäten | ja | – |
+| SwRS-046 | Kundengeräte als schreibbare Entität mit Adressen, Ticketbezug und Protokoll | ja | – |
+| SwRS-053 | Rechteprüfung des Belegwesens als private, vor jedem Schreibvorgang aufgerufene Methode | ja | – |
+| SwRS-057 | Steuerkomponente mit Satzkette, Ersatzsatz und Fortschreibung | ja | – |
+| SwRS-059 | Provisionskomponenten je Modellbestandteil | ja | – |
+| SwRS-060 | Belegausgabe mit Layoutelementen und belegartspezifischen Erzeugern | ja | – |
+| SwRS-061 | Erzeugung der E-Rechnung mit formatabhängiger Knotenbildung | ja | – |
+| SwRS-062 | Freigabewesen als eigene Komponente mit Zustandsübergängen und Benachrichtigung | ja | – |
+| SwRS-065 | Belegverkettung und Fortschrittsermittlung | ja | – |
+| SwRS-066 | Frachtartikel mit kunden- und wertabhängiger Berechnung | ja | – |
+| SwRS-068 | Belegklassifikationen und Empfängerangaben | ja | – |
+| SwRS-070 | Vertragsentität mit Verweisen auf Abrechnungs-, Kontingent- und Zahlungsobjekte | ja | – |
+| SwRS-071 | Abrechnungskomponente als partielle Klasse mit getrennten Zuständigkeiten | ja | – |
+| SwRS-073 | Kontingentänderungen als einzelne Protokolleinträge | ja | – |
+| SwRS-075 | Anbindung des RMM-Systems über eine eigene Verbindungskomponente | ja | – |
+| SwRS-076 | Vereinfachte Ticketabrechnung als eigene Komponente | ja | – |
+| SwRS-077 | Artikelreferenzen mit eigener Berechnungsvorschrift | ja | – |
+| SwRS-079 | Vertragskomponenten für Laufzeitfortschreibung und Abschluss | ja | – |
+| SwRS-083 | Aktionspreise mit Gültigkeit, Herkunft und Bearbeiterkennung | ja | – |
+| SwRS-086 | Externe Artikeldaten je Distributor als eigene Komponente | ja | – |
+| SwRS-087 | Mengeneinheiten mit Umrechnung als eigene Hilfskomponente | ja | – |
+| SwRS-101 | Zeitkomponente mit Zuschlagsberechnung, Kalenderkopplung und KI-Bewertung | ja | – |
+| SwRS-102 | Rechteprüfung der Zeitbearbeitung mit Ausnahmen statt Ergebnisobjekt | ja | – |
+| SwRS-103 | Fälligkeitsberechnung als Schleife über Reststunden | ja | – |
+| SwRS-106 | Formularkomponente mit sechs Objektarten und gleichförmigem Zugriff | ja | – |
+| SwRS-110 | Mahnlaufkomponente mit getrennten Erzeugungsschritten | ja | – |
+| SwRS-111 | Zahlungsverkehrskomponente mit Formatabstraktion und Bankauswahl | ja | – |
+| SwRS-112 | Offene-Posten-Komponente mit gemeinsamer Berichtsanbindung | ja | – |
+| SwRS-113 | Zahlungseingangskomponente mit Protokollnummernvergabe | ja | – |
+| SwRS-114 | Belegabstraktion für Buchhaltungsexport und E-Rechnung | ja | – |
+| SwRS-115 | Erzeugung der Zahlungsdatei nach amtlichem Schema | ja | – |
+| SwRS-122 | Basisklasse der Hintergrunddienste mit Vorlagenmethoden | ja | – |
+| SwRS-128 | Konfigurationsdatenbank mit wählbarer Schlüsselablage | ja | – |
+| SwRS-130 | Dreiteilige Zugriffsschicht des Windows-Clients je Fachbereich | ja | – |
+| SwRS-134 | Anmeldebausteine des Portals mit Zwischenschema und sicherer Rücksprungadresse | ja | – |
+| SwRS-136 | Variablenersetzung mit fachspezifischen Zulieferern | ja | – |
+| SwRS-138 | Outlook-Add-In als eigenes Projekt mit Office-Anbindung | ja | – |
+| SwRS-139 | Gemeinsame Steuerelementbibliothek für Client und Vorschau | ja | – |
+| SwRS-144 | Testlandschaft mit neun Projekten und Prüfinfrastruktur | ja | – |
+| SwRS-147 | Testabdeckung der Fachlogik | ja | `[HYPOTHESE]` |
+| SwRS-153 | Wirkung des Rechtezwischenspeichers auf sicherheitsrelevante Entscheidungen | ja | `[HYPOTHESE]` |
+| SwRS-155 | Abgrenzung des Nexus-Portals zur Legacy-Schnittstelle | ja | `[HYPOTHESE]` |
+
+### 5.8 Abgleich `Hypothesen.md` gegen die Inline-Markierungen
+
+| Prüfung | Ergebnis |
+|---------|----------|
+| Anforderungen mit Inline-Markierung `[HYPOTHESE]` | 36 |
+| Anforderungen mit `Status: HYPOTHESE` | 36 |
+| In `Hypothesen.md` aufgeführte IDs | 36 |
+| Symmetrische Differenz zwischen den drei Mengen | **leer** |
+| Freie Fragen in `Hypothesen.md` ohne zugehörige Anforderung | **0** |
+
+Die drei Mengen sind deckungsgleich. `Hypothesen.md` enthält genau die 36 Anforderungen mit Inline-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung stehen in Abschnitt 7 dieses Berichts.
+
+Verteilung der 36 Hypothesen: 11 StRS, 17 SyRS, 8 SwRS. Sie fallen in drei Gruppen:
+
+1. **Betriebsverhalten ohne Artefakt im Bestand** (Verfügbarkeit, Datensicherung, Aufbewahrungsfristen, Mengengerüst, Antwortzeiten, Archivierung, Übertragungsverschlüsselung, Mandantentrennung auf Datenhaltungsebene). Diese Angaben liegen außerhalb des Quellbestands; sie sind nur durch Auskunft des Betreibers zu schließen.
+2. **Fehlende Gegenstelle** (Lizenzserver, externe Ticketplattformen, RMM-Systeme, mobile Verbraucher). Die aufrufende Seite ist im Bestand, die aufgerufene nicht.
+3. **Bereiche, deren Umfang nicht zur Zahl ihrer Fachklassen passt** – insbesondere StRS-137: 221 Tabellen mit Präfix `AssetManagement` stehen drei Fachklassen gegenüber. Hier ist offen, ob der Bereich vollständig genutzt, teilweise stillgelegt oder von einem anderen Erzeuger befüllt wird.
+
+Ein Anteil von 8,1 % Hypothesen bei 446 Anforderungen ist für eine Codebasis dieses Umfangs plausibel und ausdrücklich kein Mangel: Er markiert die Grenze zwischen dem, was der Quellbestand trägt, und dem, was Fachexperten beantworten müssen.
+
+---
+
+## 6 Selbstbewertung
+
+### 6.1 Abdeckung in absoluten Zahlen
+
+| Frage | Antwort |
+|-------|---------|
+| Wie viele Inventarmodule wurden **tief** analysiert? | **12** von 176 (6,8 %) |
+| Wie viele **mittel**? | **67** (38,1 %) |
+| Wie viele **flach**? | **77** (43,8 %) |
+| Wie viele **nicht analysiert**? | **20** (11,4 %) |
+| Wurde die Mindestabdeckung aus Schritt 0b erreicht? | **Nicht vollständig.** 156 von 176 Zeilen (88,6 %) tragen mindestens eine belegte Anforderung; für die verbleibenden 20 ist je Zeile ein Grund angegeben. Eine Zeile ohne Anforderung und ohne Grund existiert nicht. |
+
+Die 20 nicht analysierten Zeilen (M157 bis M176) verteilen sich auf vier Ursachen:
+
+| Ursache | Zeilen | Beispiele |
+|---------|--------|-----------|
+| Rein technische Hilfsschicht ohne eigenständige fachliche Aussage | 5 | M164 Systemtabellen, M166 Werkzeugsammlung, M172 Oberflächen-Hilfsbereiche, M174 Versionsauskunft, M171 Suchdialoge |
+| Abgrenzung zu einem bereits erfassten Modul im Zeitrahmen nicht auflösbar | 6 | M161 Nexus-Office gegen M109, M167 Lieferantensuche gegen M014/M051, M173 Ticketsichten gegen M135, M176 Lieferantenverträge gegen M038 |
+| Kein Aufrufer, keine Gegenstelle oder keine Konfiguration im Bestand auffindbar | 5 | M157 WebSuite, M159 TANSS, M162 Nexoware-Erweiterungen, M169 Kalkulation je Filiale, M158 Portalzugriffsverwaltung |
+| Im Zeitrahmen nicht gelesen; Aussage wäre nicht belegbar gewesen | 4 | M163 Transaktionsklammer, M165 Startlogik, M170 Datenimport/-export, M175 Bauskripte |
+
+Die vierte Gruppe ist die einzige, in der eine Folgeiteration mit demselben Werkzeugsatz unmittelbar Ertrag bringen würde; die übrigen drei erfordern entweder eine Auskunft des Herstellers oder sind fachlich ohne Ertrag.
+
+### 6.2 Wo die Belege dünn sind
+
+| Befund | Zahlen |
+|--------|--------|
+| Anforderungen ohne `PRIMÄR`-Beleg | 8 (1,8 %) – alle als `[HYPOTHESE]` gekennzeichnet |
+| Anforderungen mit genau einem Beleg | 4 (0,9 %) – StRS-021, StRS-139, StRS-142, StRS-147 |
+| Belegverteilung | 1 Beleg: 4 · 2 Belege: 76 · 3 Belege: 365 · 4 Belege: 1 |
+| Module der Einstufung `flach` | 77 – sie tragen 120 Anforderungen, im Mittel 1,6 je Modul |
+| Bereich mit dem größten Missverhältnis von Umfang zu Beleg | M129 Asset-Management: 221 Tabellen, 1 Anforderung (StRS-137, `[HYPOTHESE]`) |
+
+Drei Themenfelder sind durchgehend schwach belegt:
+
+- **Betrieb.** Verfügbarkeit, Datensicherung, Wiederherstellung, Aufbewahrungsfristen, Mengengerüst und Antwortzeiten (M138) stützen sich ausschließlich auf indirekte Artefakte – Containerdefinitionen, Protokollkonfiguration, Skriptsystem. Für ein Zielsystem sind das die Angaben, die zuerst vom Betreiber beizubringen sind.
+- **Asset-Management und IT-Dokumentation.** Der größte Einzelbereich der Datenbank ist mit einer Hypothese abgedeckt. Hier ist die Diskrepanz zwischen Datenmodellumfang und Fachlogik im Bestand so groß, dass eine Aussage ohne Fachauskunft nicht verantwortbar war.
+- **Fremdsystemanbindungen.** M116 fasst sieben Anbindungen in einer Zeile zusammen; je Anbindung liegt höchstens ein Beleg vor. Die Formate und Protokolle der Gegenstellen sind aus dem Bestand nicht rekonstruierbar.
+
+### 6.3 Sind Hypothesen aufgehoben worden?
+
+Ja – 36 Anforderungen sind als `[HYPOTHESE]` gekennzeichnet und in `Hypothesen.md` mit ihrer offenen Frage geführt. Eine gesonderte Begründung nach der Vorgabe "wenn keine Hypothese gehalten wurde" entfällt damit.
+
+### 6.4 Was der Lauf über die eigene Verlässlichkeit sagt
+
+Zehn Zwischenstände waren falsch und wurden durch Nachzählung berichtigt (Abschnitt 5.5). Drei Beobachtungen daraus:
+
+1. **Zahlenangaben aus dem Gedächtnis sind unzuverlässig.** Sieben der zehn Fehler waren Zählfehler, einer davon um den Faktor 13 (17 statt 221 Tabellen). Jede quantitative Angabe im Ergebnisbestand ist deshalb einzeln nachgezählt worden.
+2. **Mitgelieferte Dokumentation ist ein `SEKUNDÄR`-Beleg, kein `PRIMÄR`-Beleg.** Die Dokumentation unter `docs/` beschreibt eine Methode zur Belegstornierung, die im Code nicht existiert. Die Belegklassifikation hat diesen Fall aufgefangen – hätte sie Dokumentation als gleichwertig behandelt, wäre eine nicht existierende Funktion als belegte Anforderung im Bestand.
+3. **Werkzeugfehler sehen aus wie Befunde.** Die erste Auswertung der ungeschützten Schnittstellenoperationen las das Attribut nur über zwei Zeilen und meldete geschützte Operationen als ungeschützt. Der Befund wurde erst nach Umbau der Auswertung auf den vollständigen Operationsblock übernommen. Sicherheitsaussagen aus maschineller Auswertung brauchen eine Gegenprobe an Einzelfällen.
+
+### 6.5 Erfüllung der Vorgaben aus der Aufgabenstellung
+
+| Vorgabe | Erfüllung |
+|---------|-----------|
+| Modulinventar vor der ersten Anforderung | erfüllt – Abschnitt 3, 176 Zeilen |
+| Mindestabdeckung je Inventarzeile | 156 Zeilen mit Anforderung, 20 mit Begründung; keine Zeile ohne beides |
+| Vertiefung nach Risiko | erfüllt – 7 der 12 tief eingestuften Zeilen betreffen unmittelbar Sicherheit, Abrechnung oder Rechte (M003, M004, M007, M013, M023, M039, M096); die übrigen fünf sind Kontenmodell, Qualitätssicherung, Betriebszusagen, Altsystemabgrenzung und Datenzugriffsschicht |
+| Belegpflicht je Anforderung | erfüllt – 0 Anforderungen ohne Beleg |
+| Trennung `Fakt` / `Aussage` | erfüllt – beide Felder in allen 446 Blöcken besetzt |
+| `PRIMÄR`-Beleg für risikorelevante Anforderungen | erfüllt – 227 von 227 |
+| Hypothesenmarkierung mit Begründung | erfüllt – 36, deckungsgleich mit `Hypothesen.md` |
+| Verifizierbarkeit (`Prüfidee`) | erfüllt – 0 Anforderungen ohne Prüfidee |
+| `Übernahmewürdigkeit` je Anforderung | erfüllt – 0 ohne Angabe |
+| Trennung `Status` (Belegsituation) / `Übernahmewürdigkeit` (fachliche Zukunft) | erfüllt – die Felder sind unabhängig belegt: 32 Anforderungen tragen `Status: belegt` bei `Übernahmewürdigkeit: veraltet`, `Workaround` oder `Sonderfall`, und 33 tragen `Status: HYPOTHESE` bei `Übernahmewürdigkeit: übernehmen` |
+| Qualitätsmerkmal nach ISO/IEC 25010 im eigenen Feld | erfüllt nach Korrektur – siehe Abschnitt 5.4 |
+| Vorwärts- und Rückwärts-Traceability | erfüllt – 155/155 SyRS→StRS, 141/141 SwRS→SyRS, 0 nicht auflösbare Ziele; Lücke bei 19 StRS ohne Verfeinerung |
+| Konsolidierungsprüfung je Anforderung | erfüllt – 141 Kandidaten benannt, keine ebenenübergreifenden Paare fälschlich als Konsolidierungsfall geführt |
+| Keine Codeerzeugung | erfüllt – es sind ausschließlich Spezifikationsartefakte entstanden |
+| Codebasis unverändert | erfüllt – auf das Arbeitsverzeichnis wurde ausschließlich lesend zugegriffen |
+| Keine Annahme über nicht beigestellte Hilfsmittel | erfüllt – Datenbank, laufendes System, Änderungshistorie und Ticketsystem standen nicht zur Verfügung und wurden nicht vorausgesetzt |
+
+
+---
+
+## 7 Bekannte Lücken
+
+Die folgenden Lücken sind bekannt und bewusst offengelassen. Sie sind hier vollständig aufgeführt, damit sie bei der Verwendung des Anforderungsbestands nicht als Vollständigkeit missverstanden werden.
+
+**L1 – 19 StRS-Anforderungen ohne Verfeinerung.** StRS-126 bis StRS-136 und StRS-138 bis StRS-145 sind auf Stakeholderebene belegt, aber nicht auf Systemebene verfeinert. Betroffen sind Produkt-Lifecycle, Produktmatrix, Qualitätsmanagement, Dashboard, Todo-Liste, Terminanfragen, Kurzverweise, Videoportal, Chats, Schlagworte, Prozesse, Handelsplattform, Gutscheine, Reisekosten, externe Ticketsystemanbindung, Dokumentensynchronisation, Rasteranpassung, soziale Netzwerke und Abteilungen. Für eine Reimplementierung heißt das: Der fachliche Zweck ist bekannt, das geforderte Systemverhalten nicht.
+
+**L2 – 20 nicht analysierte Inventarzeilen.** Abschnitt 6.1 nennt sie einzeln mit Grund. Vier davon (M163, M165, M170, M175) wären mit demselben Werkzeugsatz in einer Folgeiteration erschließbar.
+
+**L3 – Betriebsverhalten nicht aus dem Bestand ableitbar.** Verfügbarkeit, Wartungsfenster, Datensicherung, Wiederherstellungszeiten, Aufbewahrungsfristen, Mengengerüst und Antwortzeiterwartungen sind nur als Hypothesen geführt (M138). Der Quellbestand enthält dazu keine Festlegung; die Angaben müssen vom Betreiber kommen.
+
+**L4 – Asset-Management unterbelegt.** 221 Tabellen mit Präfix `AssetManagement` stehen drei Fachklassen (`DocuBoard`, `DocumentationArea`, `ItPlanner`) gegenüber und sind mit einer einzigen Anforderung abgedeckt (StRS-137, `[HYPOTHESE]`). Gemessen am Anteil am Datenmodell ist das die größte inhaltliche Lücke des Laufs.
+
+**L5 – Keine Auswertung von Änderungshistorie, Tickets und Freigabemitteilungen.** Schritt 2 der Methodenkette sieht diese Quellen vor, soweit sie als Dateien lesbar sind. Im Arbeitsverzeichnis lagen sie nicht vor. Damit fehlt die zeitliche Dimension: Es ist nicht bestimmbar, welche Regeln aktuell gepflegt und welche seit Jahren unverändert sind. Das betrifft insbesondere die Einstufung `veraltet` – sie stützt sich ausschließlich auf Code-interne Merkmale (Kennzeichnung als überholt, auskommentierte Registrierung, Bezeichner wie `Old`, `Obsolate`).
+
+**L6 – Gegenstellen externer Schnittstellen unbekannt.** Für Lizenzserver, RMM-Systeme, EDI-Distributoren, Paketdienstleister, Kontoinformationsdienst und externe Ticketplattformen liegt jeweils nur die aufrufende Seite vor. Formate, Fehlerfälle und Zusicherungen der Gegenstelle sind nicht spezifiziert.
+
+**L7 – Keine dynamische Prüfung.** Alle Aussagen stammen aus statischer Betrachtung. Ob eine im Code vorhandene Prüfung zur Laufzeit tatsächlich greift – etwa weil sie über einen Konfigurationsschalter abgeschaltet oder durch einen anderen Pfad umgangen wird –, ist nicht belegt. Das betrifft besonders die 171 Schnittstellenoperationen ohne `[Authenticate]` (SyRS-017): Belegt ist das Fehlen des Attributs, nicht die tatsächliche Erreichbarkeit ohne Anmeldung.
+
+**L8 – Fachliche Richtigkeit nicht validiert.** Schritt 7 der Methodenkette (Validierung mit Fachexperten) ist Teil des Verfahrens, aber nicht Teil dieses Laufs. Die 446 Anforderungen sind am Code belegt, nicht fachlich bestätigt. Wo Code und fachliche Absicht auseinanderfallen, bildet dieser Bestand den Code ab.
+
+---
+
+## 8 Befunde, die eine Folgeiteration nahelegen
+
+Die folgenden Befunde sind im Lauf entstanden und rechtfertigen aus sich heraus eine weitere Iteration.
+
+**B1 – Die Sicherheitsbefunde verdienen eine eigene Iteration.** Der Lauf hat vier Punkte gefunden, die für ein Zielsystem nicht übernommen werden können und deren Tragweite über die jeweilige Anforderung hinausgeht: die SHA-1-Kennwortspeicherung ohne Salz mit ausdrücklichem Hinweis im Quelltext (SyRS-007), den fest im Quelltext hinterlegten Verschlüsselungsschlüssel mit überlappendem Schlüssel- und Initialisierungsvektor (SwRS-029), 171 Schnittstellenoperationen ohne Authentifizierungsattribut (SyRS-017) und die fehlende Begrenzung der Aufrufhäufigkeit an anonym erreichbaren Endpunkten (SyRS-189). Eine gezielte Iteration sollte je Punkt den vollständigen Aufrufweg verfolgen und feststellen, welche Operationen tatsächlich ohne Anmeldung erreichbar sind.
+
+**B2 – Die Konsolidierungsfälle sind der eigentliche Ertrag für die Reimplementierung.** 141 Anforderungen benennen einen Kandidaten; 17 Fälle betreffen tragende Geschäftsobjekte (Abschnitt 5.6). Eine Folgeiteration sollte diese Fälle nicht weiter suchen, sondern entscheiden: je Fall ein Zielkonzept, eine Migrationsregel und die Menge der betroffenen Anforderungen. Für den Gerätebestand (drei Datenhaltungen), das Belegwesen (drei Persistenzwege) und die Schnittstellen (zwei überlappende) ist das die Voraussetzung dafür, dass die Reimplementierung nicht die Doppelstrukturen des Altsystems übernimmt.
+
+**B3 – Das Asset-Management muss aufgeklärt werden.** 221 Tabellen sind zu viel, um sie mit einer Hypothese abzudecken, und zu wenig belegt, um daraus Anforderungen abzuleiten. Zu klären ist, ob der Bereich produktiv genutzt wird, von welchem Erzeuger die Tabellen befüllt werden und ob er in das Zielsystem gehört. Die Antwort entscheidet über einen erheblichen Teil des Migrationsumfangs.
+
+**B4 – Die 19 nicht verfeinerten StRS sind die günstigste Ausbaustufe.** Sie betreffen Module, deren Zweck bereits belegt ist; es fehlt jeweils die Systemebene. Eine Folgeiteration, die nur diese 19 Ketten schließt, hebt die Verfeinerungsquote von 87,3 % auf 100 %, ohne neue Analysebereiche zu öffnen.
+
+**B5 – Die Belegsituation im Betrieb lässt sich nicht durch mehr Analyse verbessern.** L3 und L6 sind keine Fleißfrage. Eine Folgeiteration sollte hier nicht weiter suchen, sondern die 36 Hypothesen als Fragenkatalog an den Betreiber und die Fachbereiche geben. `Hypothesen.md` ist dafür bereits nach Dringlichkeit geordnet.
+
+**B6 – Die Abweichung zwischen Dokumentation und Code ist ein wiederkehrendes Muster.** Der Fall der nicht existierenden Belegstornierungsmethode (Abschnitt 5.5) ist an einer Stelle nachgewiesen worden, weil dort geprüft wurde. Die 44 Dokumentationsdateien unter `docs/` sind im Lauf als Quelle genutzt, aber nicht systematisch gegen den Code abgeglichen worden. Eine Folgeiteration sollte diesen Abgleich vollständig führen; jede weitere gefundene Abweichung ist ein vermiedener Fehler in der Zielspezifikation.
+
+---
+
+## 9 Hinweise zur Verwendung
+
+- `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` ausschließlich die fachliche Zukunft. Beide Felder sind unabhängig: Eine belegte Anforderung kann `veraltet` sein, eine Hypothese kann `übernehmen` tragen.
+- `Fakt` gibt wieder, was im Bestand steht. `Aussage` ist die daraus abgeleitete Sollaussage für das Zielsystem. Wo beide auseinanderfallen, ist das beabsichtigt und in `Übernahmewürdigkeit` begründet.
+- Die Belegklassifikation ist eine Vertrauensangabe: `PRIMÄR` bezeichnet eine im Code oder in der Datenbank durchgesetzte Regel, `SEKUNDÄR` und `KONTEXT` bezeichnen Hinweise. Eine Anforderung, die ausschließlich auf `SEKUNDÄR`- oder `KONTEXT`-Belegen steht, ist im vorliegenden Bestand ausnahmslos als `[HYPOTHESE]` gekennzeichnet.
+- Technische Bezeichner (Klassen, Methoden, Tabellen, Spalten) sind durchgängig in ihrer Originalsprache belassen, damit sie im Quellbestand auffindbar bleiben. Alle Anforderungsaussagen sind deutsch.

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-fcdf/Ergebnisse/Glossar.md

@@ -0,0 +1,225 @@
+# Glossar
+
+**System:** c-entron ERP-Suite — Reverse Requirements Engineering
+**Stand:** 2026-08-26
+
+Dieses Glossar erläutert die Domänenbegriffe, die in `StRS.md`, `SyRS.md` und `SwRS.md` verwendet werden. Jeder Eintrag nennt die Fundstelle, aus der die Bedeutung abgeleitet ist. Technische Bezeichner (Klassen, Methoden, Tabellen, Spalten) bleiben in ihrer Originalsprache.
+
+## Hinweis auf zwei mehrdeutige Begriffe
+
+Zwei Begriffe werden in der Codebasis in zwei verschiedenen Bedeutungen verwendet. In dieser Spezifikation sind sie stets durch einen Zusatz unterschieden:
+
+| Begriff | Bedeutung A | Bedeutung B |
+|---|---|---|
+| **Ticket** | **Anmeldeticket**: Sitzungsmerkmal, das nach erfolgreicher Anmeldung ausgegeben wird (`Ticket`, `TicketBL`, `TicketRepository`) | **Servicevorgang**: Kundenanfrage im Helpdesk (`Helpdesk`, Tabelle `hlpdsk_requests`) |
+| **Asset** | **Beleg**: In der Altbenennung steht "Anlage"/"Asset" für einen Beleg (`AssetBL`, `AssetHeadDAO`, Tabelle `AnlageLog` mit `AnlageArt`) | **Gerät**: Im Bereich `AssetManagement` bezeichnet "Asset" ein überwachtes IT-Gerät (`AssetManagementDevices`) |
+
+---
+
+## A
+
+**Abholschein** — Belegart, mit der ein Kunde Ware selbst abholt. Tabellen `AbholKopf`/`AbholPos`, Sicht `PickupLists`, Entität `ReceiptPickupList`, Nummernart `NumberGroupEnum.PickupList` (Beschreibung "Abholschein").
+
+**Abrechnungsintervall** — Kombination aus Intervallart (`BillingIntervalKinds`: Tag, Monat, Quartal, Jahr) und einer Vielfachheit (`BillingIntervalDuration`) am Vertrag. "Quartal(e) mit Dauer 1" und "Monat(e) mit Dauer 3" ergeben dieselbe Periodenlänge (`AutomaticFacturaWebServiceBL.AddInterval`).
+
+**ADM** — Außendienstmitarbeiter; am Konto als Betreuer geführt (`Account.Adviser1I3D` bis `Adviser6I3D`), am Vertrag als `SalesRepresentativeI3D`. Ein Wechsel des ADM kann die Filiale und damit den Nummernkreis eines Belegs ändern (Meldung in `ReceiptViewModel`).
+
+**Aktionspreis** — Zeitlich begrenzter Sonderpreis eines Distributors oder Herstellers zu einem Artikel. Tabelle `HerstellerArtikAktionspreis`, Entität `ActionPrice` mit `GueltigAb`/`GueltigBis`; wird nur innerhalb des Gültigkeitszeitraums im Preisspiegel angezeigt.
+
+**Änderungsschlüssel** — Guid je Beleg (`ReceiptBase.ConcurrencyControlGuid`, Datenbankspalte `GUI3D`), über den konkurrierende Änderungen erkannt werden. Weicht der übergebene vom gespeicherten Wert ab, bricht die Änderung mit dem Meldungscode `ChangedByOtherInstance` ab.
+
+**Anlage** — siehe *Asset* (Bedeutung A) und *Beleg*.
+
+**Anmeldeticket** — Zeichenkette, die nach erfolgreicher Anmeldung ausgegeben und bei jedem Schnittstellenaufruf mitgeführt wird. Gültig 30 Minuten (Standard), 5 Minuten (Monitoring-Konnektor) oder gemäß Einstellung; wird bei Verwendung verlängert (`TicketBL`).
+
+**Anwendungsart** — Typisierte Beschreibung eines anmeldefähigen Produkts mit Lizenz-Guid, erforderlichem und ausschließendem Recht sowie Ticketablaufart (`ApplicationKind`).
+
+**Anzahlungsrechnung** — Teilrechnung vor Leistungserbringung; wird in der Schlussrechnung verrechnet (`DownPaymentBL`, REST-Methoden `CreateDownPaymentInvoice` und `CreateFinalInvoiceWithDownPayments`).
+
+**Artikelcode** — Sprechende Artikelnummer; einzige Nummernart, deren Eindeutigkeit über einen Zeichenkettenvergleich geprüft wird (`NumberGroupEnumExtensions.GetCompareAsStrings`).
+
+**Asset** — siehe Hinweis oben. In dieser Spezifikation wird der Begriff vermieden; stattdessen wird von *Beleg* oder *Gerät* gesprochen.
+
+## B
+
+**Beleg** — Oberbegriff für Angebot, Auftrag, Lieferschein, Rechnung, Abholschein, Gutschrift und Vertrag sowie die entsprechenden Lieferantenbelegarten. Alle leiten von `ReceiptBase` ab und bestehen aus Kopf und Positionen.
+
+**Belegkondition** — Zahlungs- und Lieferbedingung eines Belegs. Tabelle `Zahkond` mit Skontostaffel, Fälligkeitsregeln, Zahlungsartkennzeichen und je Belegart einem eigenen Gültigkeitskennzeichen (`GltAnge`, `GltAuf`, `GltRech` und weitere).
+
+**Belegkette** — Folge zusammenhängender Belege, entstanden durch Weiterführung (`ReceiptBL.ForwardReceipt`). Stornierte Belege werden aus der Kette ausgeschlossen.
+
+**Belegvorlage** — Beleg, der als Muster dient. Erkennbar an einer negativen Nummer (`ReceiptBase.IsTemplate => Number < 0`) und daran, dass er auf den konfigurierten Vorlagenkunden lautet.
+
+**Buchhaltungsnummer** — Kontonummer eines Geschäftspartners in der Finanzbuchhaltung (`AccountCustomer.BookKeepingNumber`, `AccountSupplier.BookKeepingNumber`, `Branch.BookKeepingNumber`); wahlweise regelbasiert aus der Partnernummer mit Präfix gebildet.
+
+## C
+
+**c-entron classic** — In den Quellen als "c-entron (delhpi)" bzw. "c-entron Delphi" bezeichnete Vorgängeranwendung, die parallel auf denselben Datenbestand zugreift (`ApplicationSettingDefinitions.IsAccountManagementActive`, Kommentar in `CentronObjectKindNumeric`).
+
+**c-entron Nexus** — Blazor-Webportal mit den Bereichen ServiceBoard (Mitarbeiter), Kundenportal, WebCart und WebOffer.
+
+**C-FLOW** — In `CentronRights.md` verwendete Bezeichnung für Ticketvorlagen und die zugehörigen Rechte (`UserRightsConst.Sales.Customer.Helpdesk.CFlow.*`).
+
+**Checkliste** — An ein Geschäftsobjekt gebundene Aufgabenliste (`CentronChecklist`). Über das Kennzeichen `CanCloseHelpdesk` steuert eine Checkliste, ob offene Punkte den Abschluss des Vorgangs verhindern.
+
+## D
+
+**Datenqualitätsdienst** — Stündlich laufender Hintergrunddienst, der Bestandsdaten bereinigt und Verknüpfungen prüft (`DataQualityService`).
+
+**DSGVO-Löschung** — Kaskadierende Löschung personenbezogener Daten mit Löschprotokoll (`DataSecurityBL.DsgvoDeleteRightDeleteContacts`).
+
+## E
+
+**EDI** — Elektronischer Belegaustausch mit Distributoren. Unterstützt werden ALSO, ALSO CH, Alltron, Herweck, Komsa und OpenTrans; Dokumentarten sind Auftragsbestätigung, Lieferung und Rechnung (`SupplierEdiBL` mit sechs Partialdateien).
+
+**Einschränkendes Recht** — Recht, das den sichtbaren oder bearbeitbaren Datenbestand *verkleinert*, statt Zugang zu gewähren. Beispiele: `SHOW_HELPDESK_ONLY_OWN`, `SHOW_HELPDESK_ONLY_OWN_BRANCH`, `OWN_TIME_EDIT`, `RIGHT_MITARBEITERAUSLASTUNGNUREIGENEFILIALE` (`CentronRights.md`: "This is a restricting right").
+
+**Erwartetes Ereignis** — Je Konto definiertes, wiederkehrendes Ereignis, dessen Eintreffen protokolliert und dessen Ausbleiben ausgewertet wird (`ExpectedEventsBL`).
+
+**Eskalation** — Automatische Meldung überfälliger Vorgänge in bis zu drei Stufen (`Eskalation1Am` bis `Eskalation3Am`) an bis zu vier Empfängergruppen: Bearbeiter, Vorgesetzter, ADM, Betriebsleiter (`EscalationReceiversEnum`).
+
+## F
+
+**Filiale** — Standort eines Mandanten mit eigener Anschrift, Buchhaltungsnummer und Sprache (`Branch`, Tabelle `Filiale`). Bestimmt Nummernkreis, Sichtbarkeit und Auswertungen.
+
+**Firmengruppe** — Übergeordnetes Konto, dessen Beleg- und Preiseinstellungen ein untergeordnetes Konto übernehmen kann (`Account.CompanyGroupI3D`, `UseSettingsFromCompanyGroupForReceipts`).
+
+**Freigabewesen** — Zweistufiger Genehmigungsablauf für Kundenwarenkörbe: Erstellt → In Prüfung → In Bestellung → Bestellt, mit Rückweisungszuständen (`ReceiptCartState`, `ReceiptCartReleaseSystemBL`).
+
+## G
+
+**Gerät** — Beim Kunden installiertes Betriebsmittel. Wird in drei getrennten Beständen geführt: Stammblatt (`MasterDataList`), Kundengerät (`AccountDevices`) und überwachtes System (`AssetManagementDevices`).
+
+**Gutschrift** — Belegart zur Rückvergütung. Tabellen `GutKopf`/`GutPos`, Entität `ReceiptCreditVoucher`; in der E-Rechnung mit dem Typkennzeichen 381 (Rechnung: 380).
+
+## H
+
+**Helpdesk** — Servicebereich des Systems; zugleich die Bezeichnung des einzelnen Servicevorgangs (Ticket). Tabelle `hlpdsk_requests`, Entität `Helpdesk`.
+
+**Hintergrunddienst** — Zeitgesteuerter Vorgang im Webservice, abgeleitet von `ManagedBackgroundService`; einzeln aktivierbar, mit Fehlerdrosselung und Laufzeitprotokoll.
+
+## I
+
+**I3D** — Technischer Primärschlüssel jeder Entität; laut Datenbankkonvention "ID 3develop", stets `int IDENTITY(1,1) NOT NULL`. Fremdschlüsselspalten enden auf `I3D`.
+
+**Inventur** — Bestandsaufnahme mit Zuständen, Arten, Gruppenbildung und transaktionsgesicherter Erfassung (`InventorysBL`).
+
+## K
+
+**Kalkulation** — Bezeichnung der Lieferantenrechnung im Nummernkreissystem (`NumberGroupEnum.VendorInvoice`, Beschreibung "Kalkulation", Tabelle `KalkKopf`).
+
+**Klickabrechnung** — siehe *Zählerabrechnung*.
+
+**Kommissionierung** — Zusammenstellen der Ware zu einem Auftrag; entnommene Einheiten werden über Barcodes den Belegpositionen zugeordnet (`CommissioningBL`, `BarcodeToPosition`).
+
+**Kontenrahmen** — Struktur der Buchhaltungskonten; im System als eigener Stammdatenbereich mit Vorlagen geführt (`BookKeepingAccountSystemBL`).
+
+**Kontingent** — Im Vertrag vereinbartes Stunden- oder Wertguthaben mit Verbrauchs- und Guthabenführung, Startrestwert, Grenzwert und optionalem Ausgleichsartikel (`ReceiptContract`, Felder mit dem Präfix `Contingent`).
+
+**Konto** — Zentraler Geschäftspartnerstammsatz (`Account`), an dem die Rollen Kunde (`AccountCustomer`) und Lieferant (`AccountSupplier`) hängen.
+
+**Kostenstelle / Kostenträger** — Verursachungsgerechte Zuordnung von Kosten und Erlösen (`CostCenterBL`, `CostObjectBL`, `CustomerCostCenter`).
+
+## L
+
+**Leitweg-ID** — Adressierungsmerkmal öffentlicher Auftraggeber. Ist sie gesetzt, erzeugt das System eine XRechnung statt eines ZUGFeRD-Dokuments (`InvoiceZugferdBL.GenerateZugferdFile`).
+
+**Lieferschein** — Belegart über die Warenauslieferung. Tabellen `LiefKopf`/`LiefPos`, Sicht `DeliveryLists`, Entität `ReceiptDeliveryList`.
+
+**Lizenz** — Guid, die eine Anwendung oder ein Einzelmerkmal freischaltet. Kann Anzahl, Gültigkeitsdatum und Gültigkeitsversion tragen (`LicenseGuids`, `LicenseManager`).
+
+## M
+
+**Mahnlauf** — Zusammenfassung mehrerer Mahnungen unter einer laufenden Nummer; erhöht je Rechnung die Mahnstufe um genau eine Stufe (`DunningRunBL`).
+
+**Mahnstufe** — Eskalationsgrad einer offenen Rechnung, höchstens drei Stufen (`DunningLevel`: None, Level1, Level2, Level3).
+
+**Mandant** — Rechtliche Einheit mit eigenen Firmen-, Steuer- und Bankstammdaten (`Mandator`, Tabelle `Mandant`). Genau ein Mandant ist als Standardmandant gekennzeichnet.
+
+**Mitarbeiterartikel** — Artikel, der einen Mitarbeiter für die Leistungsabrechnung vertritt; über ihn werden Zeiten bepreist und Auslastungen ausgewertet (`EmployeeArticleBL`, `HelpdeskTimerBL.GetEmployeeTimeStatistics`).
+
+**MSP** — Managed Service Provider. Bezeichnet im System die Auswertung und Abrechnung verwalteter Kundenbestände (`MspCollector`, `MspEvaluation`, `MasterDataList.IsMsp`).
+
+## N
+
+**Nummernkreis** — Je Nummernart, Mandant und Filiale geführter Zähler mit Bereichsgrenzen und Schrittweite (`NumberGroup`, Tabelle `Nummernkreis`). Es bestehen 31 Nummernarten (`NumberGroupEnum`).
+
+## O
+
+**OPOS** — Offene Posten; Auswertung unbezahlter Rechnungen je Kunde (`OposBL`, `OposRunBL`, Reportgruppe `ReportGroupConstants.OPOS`).
+
+## P
+
+**Preisspiegel** — Gegenüberstellung der Einkaufspreise eines Artikels aus sieben Quellen: ITscope, Artikelimport, COP, NEOS, TradersGuide, EGIS und Aktionspreise.
+
+**Provisionsschema** — Regelwerk zur Provisionsermittlung mit Staffelstufen, Kundenzuordnung, Mitarbeiterzielen und Mitarbeiterstufen (`ReceiptProvisionSchema` und zugehörige Entitäten).
+
+**Prüfer** — Rolle im Freigabewesen des Warenkorbs; benötigt das Webrecht `WEBRIGHT_WEBCART2_CHECK_CART`. Die zweite Rolle ist der Einkäufer (`WEBRIGHT_WEBCART2_ORDER_CART`).
+
+## R
+
+**Reportgruppe** — Benannte Zusammenstellung von Berichten mit Parametern, über eine feste Guid angesprochen (`ReportGroup`, `ReportGroupConstants`).
+
+**RMA** — Reklamationsvorgang mit eigenen Nummern für Vorgang (`RMANumber`), Einsendung (`RepairEntrance`) und Rücksendung (`Reshipment`) sowie Artikelhistorie (`RmaBL`).
+
+**RMM** — Remote Monitoring and Management; externes Überwachungssystem, das Tickets erzeugt und Nutzungsmengen für die Abrechnung liefert (`RiverConnectionBL`, Schnittstellenpräfixe `RMMinterface/` und `RiverDivo/`).
+
+## S
+
+**SelfCare-Formular** — Strukturiertes Formular, das einem Kunden per Verweis zugestellt und ohne Anmeldung über einen Zugriffsschlüssel beantwortet wird (`SelfCareBL`, REST-Methoden `GetWebFormByGuid` und `WebFormReply`).
+
+**SEPA-Mandat** — Einzugsermächtigung des Kunden mit Mandatsreferenz; als eigenes Dokument mit Vorlage geführt (`SepaContract`, `SepaContractTemplate`, `BankAccount.AuthorizationNumber`).
+
+**ServiceBoard** — Weboberfläche für Mitarbeiter im c-entron Nexus, lizenziert über `LicenseGuids.ServiceBoardWebDev`.
+
+**Sicht** — Datenbanksicht mit englischem Namen über einer historisch deutsch benannten Tabelle (z. B. `Invoices` über `RechKopf`). Die Codebasis kennt 153 Sichten.
+
+**Skriptmethode** — Datenbankänderung als Klasse mit Skriptnummer und zugehöriger Anwendungsversion (`IScriptMethod`); wird genau einmal ausgeführt und in der Tabelle der Datenbankaktualisierungen vermerkt. Es bestehen 764 Skriptmethoden.
+
+**Sonderpreis** — Kundenindividueller Artikelpreis (`AccountSpecialPrice`); Grundlage des Artikelangebots im WebCart.
+
+**Stammblatt** — Datensatz über ein beim Kunden installiertes Gerät mit Seriennummer, Rechnungsbezug, Zählerkennzeichen und Vertragsbezug (`MasterDataList`, Sicht `cvw_MasterDataList`, Alttabelle `GeraeteKopf`). Wird vorwiegend für Drucker und Zählergeräte verwendet.
+
+## T
+
+**Telemetrie** — Aggregierte Erfassung der Nutzung von Schnittstelle und KI-Funktionen je Zeitfenster, Benutzer und Gerät; wird an den Hersteller übertragen (`TelemetryBL`).
+
+**Ticket** — siehe Hinweis oben (Anmeldeticket oder Servicevorgang).
+
+**Ticketprozess / Ticketvorlage** — Vorlage, aus der ein Ticket samt Untervorgängen und Checklisten erzeugt wird (`TicketPattern`, `TicketProcessTemplateFolder`, `HelpdeskCreationTemplate`).
+
+**Ticketzeit** — Auf einem Ticket erfasste Arbeitszeit mit Start, Ende, Zeitart, Abrechenbarkeitskennzeichen und optionaler Unterschrift (`HelpdeskTimer`).
+
+## V
+
+**Verkaufsgebiet** — Gebietszuordnung eines Kontos (`Account.SalesAreaI3D`) und eines Mitarbeiters; wirkt im Portal als zwingende Sichtgrenze für Ticketlisten.
+
+**Versionstabelle** — Tabelle mit identischem Spaltensatz zu einer Beleg-Kopf- oder Positionstabelle, in die vor jeder Änderung eine vollständige Kopie geschrieben wird (`AngKopfVersions`, `AngPosVersions` und entsprechend je Belegart).
+
+**Vertrag** — Belegart für wiederkehrende Leistungen mit Laufzeit, Abrechnungsintervall, Kontingent und Zahlungsmandat (`ReceiptContract`, Tabellen `VertragKopf`/`VertragPos`).
+
+## W
+
+**Wareneingang** — Belegart über den Zugang von Lieferantenware (`NumberGroupEnum.Intake`, Tabelle `WareKopf`).
+
+**Warenkorb (WebCart)** — Vom Kunden im Portal zusammengestellter Bestellvorschlag; technisch ein Angebot (`ReceiptOffer`) mit eigenem Zustandsraum (`ReceiptCartState`).
+
+**Webaccount** — Portalzugang eines Kundenkontakts mit eigenem Rechtekatalog (`WebAccount`, `WebAccountRightsConst`). Ein Mehrkundenzugang ist möglich.
+
+**Web-Beleg** — Für den Kunden im Web freigegebener Beleg mit eigenem Zustandsraum (`WebReceiptState`), begrenzten Änderungsmöglichkeiten und Zugriffsprotokoll.
+
+## X
+
+**XRechnung** — Deutsches Rechnungsformat auf Basis der Norm EN 16931. Unterstützt sind die Stände 1.2, 2.0, 2.2, 2.3.1 und 3.0.1 (`ZugferdKind`).
+
+## Z
+
+**Zählerabrechnung** — Abrechnung nach Gerätezählerständen, üblich bei Druck- und Kopiergeräten. Umfasst Zählerarten, Freimengen, Staffelpreise und Begründungen für abweichende Stände (`DeviceClickCounter` und zugehörige Entitäten).
+
+**ZUGFeRD** — Hybrides Rechnungsformat aus PDF und eingebetteter XML-Datei. Unterstützt sind die Stände 1.0 sowie 2.1 in Verbindung mit den XRechnung-Ständen (`ZugferdKind`, `InvoiceZugferdBL`).
+
+**Zugangstoken** — Benanntes, 48 Zeichen langes Merkmal für die Anbindung externer Systeme; im Bestand nur als SHA-256-Hashwert gespeichert (`AccessToken`, `AccessTokenBL`).
+
+**Zuschlagssatz** — Aufschlag auf den Stundensatz für Nacht-, Wochenend- oder Feiertagsarbeit; die Überschneidung einer Zeit mit den Zuschlagszeiträumen wird berechnet (`HourlySurchargeRate`, `HelpdeskTimerBL.CalculateHourlySurchargeRateOverlaps`).
+
+**Zwei-Faktor-Authentifizierung** — Zweiter Anmeldenachweis über einen RADIUS-Dienst oder einen E-Mail-Bestätigungslink; je Benutzer aktivierbar und für eine konfigurierbare Zahl von Kalendertagen je Anwendung, Gerät und IP-Adresse gültig (`TwoFactorAuthBL`).

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-fcdf/Ergebnisse/Hypothesen.md

@@ -0,0 +1,82 @@
+# Hypothesen
+
+**System:** c-entron ERP-Suite — Reverse Requirements Engineering
+**Stand:** 2026-08-26
+
+Diese Datei enthält **genau** die Anforderungen, deren Feld `Aussage` mit `[HYPOTHESE]` gekennzeichnet ist und deren Feld `Status` den Wert `HYPOTHESE` trägt — keine weiteren freien Fragen. Offene Punkte ohne zugehörige Anforderung sind in der Selbstbewertung des `Analysebericht.md` aufgeführt.
+
+**Abgleich mit den Inline-Markierungen:** 36 Anforderungen tragen die Inline-Markierung `[HYPOTHESE]`, 36 Anforderungen tragen `Status: HYPOTHESE`, und beide Mengen sind deckungsgleich. Die Tabelle unten führt dieselben 36 Anforderungen.
+
+**Verteilung**
+
+| Ebene | Anforderungen gesamt | davon Hypothesen | Anteil |
+|---|---|---|---|
+| StRS | 150 | 11 | 7,3 % |
+| SyRS | 155 | 17 | 11,0 % |
+| SwRS | 141 | 8 | 5,7 % |
+| **Gesamt** | **446** | **36** | **8,1 %** |
+
+**Warum diese Punkte offen sind.** Sie zerfallen in drei Gruppen:
+
+1. **Betriebs- und Qualitätszusagen ohne Artefaktbasis** (Verfügbarkeit, Datensicherung, Antwortzeiten, Zugänglichkeit, Aufbewahrungsfristen, Kennwortrichtlinien, Übertragungsverschlüsselung, Ratenbegrenzung, Zeitzonenregel, Mandantentrennung). Solche Zusagen stehen in Verträgen und Betriebshandbüchern, nicht im Quellcode; sie sind aus einer statischen Analyse grundsätzlich nicht ableitbar.
+2. **Funktionen, deren Daten oder Oberfläche vorliegen, deren Logik aber außerhalb dieser Codebasis liegt** (Asset-Management mit 221 Tabellen und drei Fachklassen, Gutscheinverwaltung, Dokumentensynchronisation, QM-Modul, mobile Sichten, Rechnungsarchiv, Lizenzserveranbindung, Werbewiderspruch). Hier ist die Existenz der Funktion belegt, ihr Umfang aber nicht.
+3. **Technische Fragen, die eine Ausführung oder eine Betriebsbeobachtung erfordern** (Testabdeckung, Mehrfachbetrieb der Hintergrunddienste, Speicherverhalten, ausgenommene Datenbankskripte, Binärserialisierung, Rechtezwischenspeicher, Schwachstellenlage der Fremdbibliotheken, Portalabgrenzung).
+
+---
+
+## Hypothesen im Einzelnen
+
+| ID | Titel | Aussage | Offene Frage |
+|---|---|---|---|
+| StRS-021 | Auswertung des Werbewiderspruchs beim Kampagnenversand | [HYPOTHESE] Das System soll Empfänger mit gesetztem Werbewiderspruch vom Kampagnen- und Serienmailversand ausschließen. | An welcher Stelle (Delphi-Anwendung, Reportfilter, manueller Prozess) wird der Werbewiderspruch heute tatsächlich ausgewertet? |
+| StRS-120 | Mobile Nutzung durch Servicetechniker | [HYPOTHESE] Das System soll Servicetechnikern eine mobile Anwendung für Ticketbearbeitung und Zeiterfassung bereitstellen, die über eigene, reduzierte Stammdatensichten versorgt wird. | Existiert eine mobile Anwendung außerhalb dieses Repositoriums, und welche Funktionen deckt sie ab? |
+| StRS-128 | Qualitätsmanagementmodul | [HYPOTHESE] Das System soll qualitätsrelevante Vorgänge - etwa Prüfungen, Abweichungen und Maßnahmen - erfassen und auswerten. | Welche Vorgangsarten deckt das QM-Modul fachlich ab, und wo liegt seine Geschäftslogik? |
+| StRS-137 | IT-Dokumentation und Asset-Management der überwachten Systeme | [HYPOTHESE] Das System soll die IT-Landschaft des Kunden - Geräte, Betriebssysteme, Anwendungen, Dienste, Aktualisierungen und Prüfergebnisse - dokumentieren und überwachen; die Erhebung erfolgt durch einen externen Systemsammler. | Welche Anwendung schreibt die 17 `AssetManagement`-Tabellen, und wie ist sie zu c-entron.NET abgegrenzt? Wie wird das Feld `AssetManagementDevices.BitlockerPassword` geschützt, für das in dieser Codebasis kein Zugriff besteht? |
+| StRS-139 | Gutscheinverwaltung | [HYPOTHESE] Das System soll Gutscheine mit Barcode führen und ihren Zustand - frei, ausgegeben, eingelöst - verwalten. | Wo werden Gutscheine angelegt und eingelöst - in der Delphi-Anwendung oder außerhalb des Systems? |
+| StRS-142 | Dokumentensynchronisation mit externen Ablagen | [HYPOTHESE] Das System soll Dokumente mit einer externen Ablage abgleichen, sodass in c-entron abgelegte Dokumente auch dort verfügbar sind. | Mit welchem Zielsystem synchronisiert die Funktion, und wo liegt der Abgleichvorgang? |
+| StRS-146 | Verfügbarkeit des Gesamtsystems | [HYPOTHESE] Das System soll eine zugesagte Verfügbarkeit einhalten und im Störungsfall innerhalb einer vereinbarten Frist wieder betriebsbereit sein. | Welche Verfügbarkeit, welches Wartungsfenster und welche Wiederanlaufzeit sind vertraglich zugesagt? |
+| StRS-147 | Datensicherung und Wiederherstellung | [HYPOTHESE] Das System soll in ein Sicherungs- und Wiederherstellungsverfahren eingebunden sein, das einen definierten maximalen Datenverlust und eine definierte Wiederherstellungszeit einhält. | Wer verantwortet die Sicherung, welcher maximale Datenverlust ist zulässig und wie lange darf die Wiederherstellung dauern? |
+| StRS-148 | Aufbewahrungsfristen und Unveränderbarkeit steuerlich relevanter Belege | [HYPOTHESE] Das System soll steuerlich relevante Belege über die gesetzliche Aufbewahrungsfrist unveränderbar vorhalten und ihre Löschung vor Fristablauf verhindern. | Welche Aufbewahrungsfristen gelten je Belegart, und wie werden sie heute gegenüber der Löschfunktion durchgesetzt? |
+| StRS-149 | Mengengerüst und Antwortzeiterwartungen | [HYPOTHESE] Das System soll definierte Antwortzeiten bei einer definierten Zahl gleichzeitiger Benutzer und einem definierten Datenbestand einhalten. | Welche Antwortzeiten, Benutzerzahlen und Datenmengen sind für das Zielsystem maßgeblich? |
+| StRS-150 | Abgrenzung zur Vorgängeranwendung c-entron classic | [HYPOTHESE] Das Zielsystem soll den Funktionsumfang beider Anwendungen abdecken; der Anteil, der heute ausschließlich in der Delphi-Anwendung besteht, ist für die Neuimplementierung gesondert zu erheben. | Welche Fachfunktionen bestehen ausschließlich in der Delphi-Anwendung, und welche der 1.535 Tabellen werden ausschließlich von ihr beschrieben? |
+| SyRS-173 | Reduzierte Stammdatensichten für mobile Verbraucher | [HYPOTHESE] Das System soll mobilen Clients reduzierte Sichten auf Ticketstammdaten liefern, um Datenvolumen und Ladezeit zu begrenzen, und die Nutzung mobiler Module protokollieren. | Welcher Client verwendet die mobilen Sichten heute, und ist er noch im Einsatz? |
+| SyRS-180 | Wiederanlauf und Ausfallverhalten der Dienste | [HYPOTHESE] Das System soll bei Ausfall einzelner Bestandteile ein definiertes Ersatzverhalten zeigen, den Anwender darüber informieren und nach Behebung ohne Neustart weiterarbeiten. | Welches Verhalten ist bei Ausfall von Datenbank, Lizenzserver und externen Diensten vorgesehen, und ist ein Betrieb mit mehreren Webservice-Instanzen zugelassen? |
+| SyRS-181 | Sicherung und Wiederherstellung des Datenbestands | [HYPOTHESE] Das System soll so gesichert werden, dass Datenbank und Dateiablage zu einem gemeinsamen Zeitpunkt wiederherstellbar sind. | Wie werden Datenbank und Dateiablage heute gemeinsam gesichert? |
+| SyRS-182 | Unveränderbarkeit ausgegebener Belegdokumente | [HYPOTHESE] Das System soll ausgegebene Belegdokumente unveränderbar aufbewahren und ihre Unversehrtheit prüfbar machen. | Ist die Signatur ausgegebener Rechnungen verpflichtend, und wie wird die Unversehrtheit archivierter Dokumente geprüft? |
+| SyRS-183 | Zielwerte für Antwortzeiten und Datenmengen | [HYPOTHESE] Das System soll definierte Antwortzeiten für die häufigsten Vorgänge einhalten und diese Werte fortlaufend messen. | Welche Antwortzeitziele gelten je Vorgangsart, und ab welcher Datenmenge sind sie zu erfüllen? |
+| SyRS-184 | Schreibende Zuständigkeit je Datenbanktabelle | [HYPOTHESE] Für jede Datenbanktabelle soll genau eine schreibende Anwendung benannt sein; die heutige Verteilung auf mindestens drei Schreiber (c-entron.NET, c-entron classic, externer Systemsammler) ist zu erheben und aufzulösen. | Welche der 1.535 Tabellen werden von dieser Codebasis geschrieben, welche von der Delphi-Anwendung und welche vom externen Systemsammler? |
+| SyRS-185 | Gesicherte Übertragung zwischen den Systembestandteilen | [HYPOTHESE] Das System soll sämtliche Netzverbindungen zwischen Client, Webservice, Portal und Datenbank verschlüsselt führen. | Wird die Verbindung heute durch einen vorgelagerten Proxy gesichert, und wie ist die Datenbankverbindung geschützt? |
+| SyRS-186 | Trennung der Mandanten auf Datenhaltungsebene | [HYPOTHESE] Das System soll die Daten verschiedener Mandanten so trennen, dass ein Zugriff über die Mandantengrenze hinweg ausgeschlossen ist. | Werden Mandanten heute in getrennten Datenbanken oder in einer gemeinsamen Datenbank geführt, und wie wird die Trennung durchgesetzt? |
+| SyRS-187 | Anbindung des Lizenzservers | [HYPOTHESE] Das System soll seinen Lizenzbestand regelmäßig mit dem Lizenzserver des Herstellers abgleichen und bei fehlgeschlagenem Abgleich ein definiertes Verhalten zeigen. | Wie und wie oft wird der Lizenzbestand mit dem Lizenzserver abgeglichen, und was geschieht bei dessen Ausfall? |
+| SyRS-188 | Aufbewahrung und Bereinigung der Protokolldaten | [HYPOTHESE] Das System soll je Protokollart eine Aufbewahrungsfrist führen, Protokolldaten nach Fristablauf entfernen und dabei nachweispflichtige Protokolle von technischen unterscheiden. | Welche Aufbewahrungsfristen gelten je Protokollart, und welche Protokolle sind nachweispflichtig? |
+| SyRS-189 | Begrenzung der Aufrufhäufigkeit an der Schnittstelle | [HYPOTHESE] Das System soll die Aufrufhäufigkeit je Aufrufer begrenzen, insbesondere für anonyme und tokenbasierte Endpunkte, um automatisiertes Durchprobieren und Überlastung zu verhindern. | Besteht heute eine Begrenzung durch einen vorgelagerten Dienst, und welche Schwellen sollen im Zielsystem gelten? |
+| SyRS-190 | Kennwortrichtlinien für Benutzer- und Portalkonten | [HYPOTHESE] Das System soll für Anmeldekennwörter eine Mindestlänge, eine Komplexitätsanforderung und eine Sperre nach wiederholten Fehlversuchen durchsetzen. | Bestehen Kennwortrichtlinien außerhalb der Anwendung, etwa über Active Directory, und gelten sie auch für Portalkonten? |
+| SyRS-191 | Wirksamkeit eines Rechteentzugs auf laufende Sitzungen | [HYPOTHESE] Das System soll einen Rechteentzug innerhalb einer festgelegten Frist auf alle laufenden Sitzungen wirken lassen. | Innerhalb welcher Frist muss ein Rechteentzug auf laufende Sitzungen wirken? |
+| SyRS-192 | Barrierefreiheit der Oberflächen | [HYPOTHESE] Das System soll seine Oberflächen so gestalten, dass sie ohne Maus bedienbar, mit Bildschirmlesern erfassbar und kontrastarm gestalteten Anzeigen zugänglich sind. | Welche Zugänglichkeitsstufe ist für das Zielsystem verbindlich? |
+| SyRS-193 | Archivierung von Belegdokumenten | [HYPOTHESE] Das System soll ausgegebene Rechnungen in einem Archiv ablegen, sie dort unveränderbar vorhalten und von der Dokumentbereinigung ausnehmen. | Wo ist das Rechnungsarchiv umgesetzt, und wie ist es gegen die Dokumentbereinigung abgegrenzt? |
+| SyRS-194 | Einheitliche Behandlung von Zeitzonen | [HYPOTHESE] Das System soll Zeitangaben nach einer einheitlichen Regel speichern und vergleichen und die Regel je Feld dokumentieren. | Wird das System heute ausschließlich in einer Zeitzone betrieben? |
+| SyRS-195 | Berechtigung zeitgesteuert erzeugter Berichte | [HYPOTHESE] Das System soll zeitgesteuert erzeugte Berichte im Rechtekontext eines benannten Benutzers erstellen und ihre Inhalte auf dessen Sichtbereich begrenzen. | In welchem Rechtekontext erzeugt der Reportserver seine Berichte? |
+| SwRS-147 | Testabdeckung der Fachlogik | [HYPOTHESE] Die Software soll für ihre risikorelevanten Bereiche - Rechteprüfung, Preis- und Steuerberechnung, Abrechnung, Nummernvergabe und Zahlungsverkehr - eine nachweisbare Testabdeckung besitzen. | Wird die Testabdeckung heute gemessen, und welche Schwelle gilt für risikorelevante Bereiche? |
+| SwRS-148 | Mehrfachbetrieb der Hintergrunddienste | [HYPOTHESE] Die Software soll sicherstellen, dass bestandsweite Vorgänge auch bei mehreren gleichzeitig laufenden Instanzen genau einmal ausgeführt werden. | Ist ein Betrieb mit mehreren Webservice-Instanzen heute zugelassen? |
+| SwRS-149 | Umgang mit bekannten Speicherproblemen | [HYPOTHESE] Die Software soll ihren Speicherbedarf über lange Laufzeiten stabil halten, ohne dass eine erzwungene Speicherbereinigung erforderlich ist. | Welche Speicherprobleme bestehen fort, und welcher Speicherbedarf ist im Dauerbetrieb zu erwarten? |
+| SwRS-151 | Behandlung der von der Fehlerprüfung ausgenommenen Datenbankskripte | [HYPOTHESE] Die Software soll jedes Datenbankskript erfolgreich ausführen; Ausnahmen von der Fehlerprüfung sollen begründet, befristet und einzeln dokumentiert sein. | Warum dürfen genau diese vier Skripte fehlschlagen, und welche Folgen hat ihr Scheitern für das Schema? |
+| SwRS-152 | Verwendung der als unsicher eingestuften Serialisierung | [HYPOTHESE] Die Software soll ohne die als unsicher eingestufte Binärserialisierung auskommen; die Zwischenspeicherung der Persistenzkonfiguration ist auf ein sicheres Verfahren umzustellen. | An welcher Stelle wird die Persistenzkonfiguration serialisiert, und lässt sich dies durch einen Neuaufbau ersetzen? |
+| SwRS-153 | Wirkung des Rechtezwischenspeichers auf sicherheitsrelevante Entscheidungen | [HYPOTHESE] Die Software soll den Rechtezwischenspeicher des Clients nach jeder Rechteänderung erneuern und darf ihn nicht als alleinige Grundlage sicherheitsrelevanter Entscheidungen verwenden. | Wann wird der Rechtezwischenspeicher des Clients erneuert? |
+| SwRS-154 | Stand und Schwachstellenlage der Fremdbibliotheken | [HYPOTHESE] Die Software soll ihre Fremdbibliotheken auf einem gepflegten Stand halten und bekannte Schwachstellen in Abhängigkeiten vor der Auslieferung bewerten. | Wie werden lokal abgelegte und von Hand veränderte Bibliotheken auf Schwachstellen geprüft? |
+| SwRS-155 | Abgrenzung des Nexus-Portals zur Legacy-Schnittstelle | [HYPOTHESE] Das Portal soll auf Fachdaten über genau einen Weg zugreifen; die heutige Mischung aus Legacy-Schnittstelle, moderner Schnittstelle und unmittelbarem Zugriff auf die Geschäftslogik ist zu vereinheitlichen. | Ist das Portal als eigenständiger Dienst oder als Teil des Webservice gedacht? |
+
+---
+
+## Priorisierung für die Validierung durch Fachexperten
+
+**Zuerst zu klären (Migrationsrelevanz hoch):**
+
+1. `StRS-150` / `SyRS-184` — Abgrenzung zur Vorgängeranwendung und schreibende Zuständigkeit je Tabelle. Ohne diese Klärung ist der Migrationsumfang unbekannt.
+2. `StRS-137` — Umfang und Herkunft der 221 `AssetManagement`-Tabellen einschließlich des ungeschützt erscheinenden Feldes `BitlockerPassword`.
+3. `StRS-148` / `SyRS-182` / `SyRS-193` — Aufbewahrung, Unveränderbarkeit und Archivierung steuerlich relevanter Belege.
+4. `SyRS-186` — Trennung der Mandanten; entscheidet über die Grundarchitektur des Zielsystems.
+5. `SyRS-190` / `SyRS-185` — Kennwortrichtlinien und Übertragungsverschlüsselung; beide sind für einen Cloud-Betrieb zwingend.
+
+**Danach zu klären (Betriebsrelevanz):** `StRS-146`, `StRS-147`, `StRS-149`, `SyRS-180`, `SyRS-181`, `SyRS-183`, `SyRS-188`, `SyRS-189`, `SwRS-148`, `SwRS-149`.
+
+**Zuletzt zu klären (Funktionsumfang einzelner Module):** `StRS-021`, `StRS-120`, `StRS-128`, `StRS-139`, `StRS-142`, `SyRS-173`, `SyRS-187`, `SyRS-191`, `SyRS-192`, `SyRS-194`, `SyRS-195`, `SwRS-147`, `SwRS-151`, `SwRS-152`, `SwRS-153`, `SwRS-154`, `SwRS-155`.

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-fcdf/Ergebnisse/Traceability.md

@@ -0,0 +1,428 @@
+# Traceability
+
+**System:** c-entron ERP-Suite — Reverse Requirements Engineering
+**Stand:** 2026-08-26
+
+Diese Datei stellt die Verfolgbarkeit zwischen den drei Spezifikationsebenen her.
+
+- **Abschnitt 1 (Forward):** je Zeile eine Kette `StRS → SyRS → SwRS` mit dem tragenden Artefaktbeleg. Anforderungen, die auf einer Ebene keine Entsprechung haben, erscheinen mit `-`.
+- **Abschnitt 2 (Backward):** je Stakeholder-Anforderung alle Anforderungen der Ebenen SyRS und SwRS, die auf sie verweisen.
+
+**Kennzahlen**
+
+| Kennzahl | Wert |
+|---|---|
+| Anforderungen gesamt | 446 (StRS 150, SyRS 155, SwRS 141) |
+| Zeilen der Forward-Tabelle | 237 |
+| In der Forward-Tabelle enthaltene Anforderungs-IDs | 446 von 446 |
+| SyRS-Anforderungen mit StRS-Bezug | 155 von 155 |
+| SwRS-Anforderungen mit SyRS-Bezug | 141 von 141 |
+| StRS-Anforderungen ohne verfeinernde SyRS-/SwRS-Anforderung | 19 (StRS-126 bis StRS-145, ohne StRS-137) |
+| Tracelink-Ziele insgesamt | 368 eindeutige IDs, alle vorhanden (keine Verweise auf nicht existierende IDs) |
+
+---
+
+## 1. Forward-Traceability (StRS → SyRS → SwRS)
+
+| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
+|---|---|---|---|
+| StRS-001 | SyRS-001 | SwRS-001 | src/backend/Centron.Entities/Entities/Administration/Company/Mandator.cs und MandatorBankInfo.cs |
+| StRS-002 | SyRS-002 | SwRS-002 | src/backend/Centron.DAO/Mappings/Administration/Company/NumberGroupMaps.cs, `Table("Nummernkreis")` |
+| StRS-106 | SyRS-160 | SwRS-003 | src/backend/Centron.BL/WebServices/ mit 464 Dateien der DTO-Umsetzungsschicht |
+| StRS-121 | SyRS-024 | SwRS-004 | src/backend/Centron.Interfaces/Results/Result.cs |
+| StRS-121 | SyRS-174 | SwRS-005 | src/backend/Centron.BL/WebServices/ObjectMapper.cs, InitializeAsyncInternal() mit den vier Konfigurationsentscheidungen |
+| StRS-106 | SyRS-160 | SwRS-006 | src/centron/Centron.WPF.UI/Services/Container/Interceptors/ContributeLogicResultInterceptorToAllLogics.cs und ContributeSetLoggedInUserInterceptorToAllLogics.cs |
+| StRS-064 | SyRS-029 | SwRS-007 | src/shared/Centron.Core/Guard.cs mit den 20 Prüfmethoden |
+| StRS-104 | SyRS-150 | SwRS-008 | src/backend/Centron.DAO/DAOSession.cs und AdvancedSession.cs |
+| StRS-027 | SyRS-057 | SwRS-009 | src/backend/Centron.DAO/GenericDAO.cs und BaseDAO.cs |
+| StRS-003 | SyRS-005 | SwRS-010 | src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs mit `protected abstract Result<LoggedInUser> AuthenticateInternal();` |
+| StRS-004 | SyRS-006 | SwRS-011 | src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs, ValidateAppUser(AppUser?) mit beiden Bedingungen und den zugehörigen Protokolleinträgen |
+| StRS-007 | SyRS-008 | SwRS-012 | src/backend/Centron.BL/Administration/Logins/TwoFactor/ITwoFactorValidator.cs mit den beiden Umsetzungen |
+| StRS-008 | SyRS-009 | SwRS-013 | src/backend/Centron.BL/Administration/Logins/Auth/AuthenticatorFactory.cs mit der Schnittstelle und den fünf öffentlichen Methoden |
+| StRS-003 | SyRS-022 | SwRS-014 | src/backend/Centron.BL/Administration/Logins/TicketBL.cs, CreateNewTicket(...) mit `GetTicketSalt(deviceID)` |
+| StRS-011 | SyRS-015 | SwRS-015 | src/backend/Centron.Entities/Entities/Administration/Logins/LoggedInUser.cs |
+| StRS-003 | SyRS-005 | SwRS-016 | src/backend/Centron.Interfaces/Administration/Logins/ApplicationKind.cs |
+| StRS-111 | SyRS-017 | SwRS-017 | src/webservice/Centron.Host/AspNetCore/WcfBridge/Interception/Interceptors/AuthenticateInterceptor.cs, `public override int Priority { get { return 10; } }` und der Kommentar zu Rang 20 |
+| StRS-005 | SyRS-011 | SwRS-018 | src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, IsModuleAvailable<T>() mit `CentronCache.Instance.CurrentUserAppRights` |
+| StRS-010 | SyRS-014 | SwRS-019 | src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, `ModuleFeatures.SetAccessRights(...)` unmittelbar vor der Modulauswahl |
+| StRS-005 | SyRS-010 | SwRS-020 | src/backend/Centron.BL/Accounts/AccountBL.cs, ValidateUserRights(...) mit einer Sammelabfrage über sieben Rechte und anschließenden `Contains`-Prüfungen |
+| StRS-006 | SyRS-012 | SwRS-021 | src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, GetShowHelpdeskRight(LoggedInUser), Zeilen 236-291 |
+| StRS-006 | SyRS-012 | SwRS-022 | src/nexus/CentronNexus/Shared/Auth/TicketFilterService.cs, GetEmployeeTicketFilter(...) und GetWebAccountTicketFilter(...) |
+| StRS-010 | SyRS-013 | SwRS-023 | src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs mit der Schnittstelle `ILicenseManager` sowie src/backend/Centron.Interfaces/Administration/Logins/LicenseGuids.cs |
+| StRS-011 | SyRS-015 | SwRS-024 | src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs, CreatePersonalToken(...) mit Hashkonfliktprüfung |
+| StRS-012 | SyRS-016 | SwRS-025 | src/backend/Centron.BL/Sales/Receipts/ReceiptCartBL.cs, CreateNewCart(...) mit `currentUser.WebAccount.CustomerI3D.Value`, `AddressI3D` und `AddressContactI3D` |
+| StRS-005 | SyRS-011 | SwRS-026 | src/centron/Centron.WPF.UI/Modules/ModuleRightsExpressionParser.cs mit dem Kommentarblock der unterstützten Ausdrucksformen |
+| StRS-005 | SyRS-011 | SwRS-027 | src/webservice/Centron.Controllers/Authorization/AuthorizeAllUserRightsAttribute.cs, `if (_requiredRightIds.Length == 0 || !hasAllRights) context.Result = new ForbidResult();` |
+| StRS-006 | SyRS-012 | SwRS-028 | src/nexus/CentronNexus/Shared/Authorization/ mit den 13 genannten Bausteinen |
+| StRS-003 | SyRS-007 | SwRS-029 | src/backend/Centron.Common/TextCoding/ mit vier Klassen |
+| StRS-013 | SyRS-018 | SwRS-030 | src/backend/Centron.DAO/ChangeTracking/ChangeTrackingEventListener.cs, OnPreUpdate(PreUpdateEvent) mit beiden Zwischenspeichern |
+| StRS-013 | SyRS-018 | SwRS-031 | src/backend/Centron.Entities/ mit 36 Entitäten der Endung `Log` und 27 mit `History` im Namen |
+| StRS-014 | SyRS-019 | SwRS-032 | src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs, die elf Löschmethoden mit dem Parameter `isReferenceDelete` |
+| StRS-015 | SyRS-020 | SwRS-033 | src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs mit den vier Fachklassen und `AddAccessDataProperties(..., bool includeFileData, bool includeImageData)` |
+| StRS-015 | SyRS-021 | SwRS-034 | src/backend/Centron.Common/TextCoding/AESCryptoLogic.cs, GetKeyAndIV(string) mit den beiden `Buffer.BlockCopy`-Aufrufen |
+| StRS-013 | SyRS-018 | SwRS-035 | src/backend/Centron.Entities/Entities/BaseEntity.cs |
+| StRS-121 | SyRS-174 | SwRS-036 | src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs mit dem hervorgehobenen Kopfkommentar |
+| StRS-099 | SyRS-145 | SwRS-037 | src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs, `Description = EnumHelper.GetEnumDescription(numberGroup)` |
+| StRS-027 | SyRS-057 | SwRS-038 | src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Verwendung von `NamedQueryEnums.PasswordManager.GetPropertyValueSealInformations` mit `NamedQueryParameter` |
+| StRS-102 | SyRS-148 | SwRS-039 | docs/guides/database/database-conventions.md mit allen genannten Regeln und zwei vollständigen Beispieltabellen |
+| StRS-016 | SyRS-030 | SwRS-040 | src/backend/Centron.DAO/Repositories/Accounts/AccountRepository.cs, Zeilen 663 und 1246 mit dem Abgleich in beide Richtungen |
+| StRS-016 | SyRS-030 | SwRS-041 | src/backend/Centron.Entities/Entities/Accounts/ mit den genannten Entitäten |
+| StRS-022 | SyRS-033 | SwRS-042 | src/backend/Centron.BL/Sales/Customers/CrmProjects/CrmProjectBL.cs, Zeilen 110-125 mit Transaktionsklammer und Nachverfolgungsfeldern |
+| StRS-024 | SyRS-036 | SwRS-043 | src/backend/Centron.DAO/Mappings/Warehousing/ActionPriceMaps.cs und src/backend/Centron.BL/Warehousing/ActionPriceBL.cs |
+| StRS-025 | SyRS-060 | SwRS-044 | src/backend/Centron.Entities/Entities/DataExchange/PaymentTransactions/PaymentInformation.cs und PaymentTransactionExportItem.cs |
+| StRS-026 | SyRS-037 | SwRS-045 | src/backend/Centron.DAO/Mappings/Sales/Receipts/MasterDataLists/MasterDataListMaps.cs, `this.ReadOnly();` |
+| StRS-026 | SyRS-037 | SwRS-046 | src/backend/Centron.DAO/Mappings/Devices/AccountDeviceMaps.cs mit durchgängigem `Not.Nullable()` und src/backend/Centron.Entities/Entities/Devices/AccountDevice.cs mit den Vorbelegungen |
+| StRS-030 | SyRS-043 | SwRS-047 | src/backend/Centron.BL/Sales/Receipts/ReceiptCartReleaseSystemBL.cs, `this.Session.GetSession().Query<AngKopf>().Where(...).UpdateBuilder().Set(f => f.CartState, nextState).Update();` |
+| StRS-027 | SyRS-057 | SwRS-048 | SSMS_DB_SCHEMA.sql mit 1.535 Tabellen und 153 Sichten |
+| StRS-027 | SyRS-057 | SwRS-049 | src/backend/Centron.DAO/UserTypes/DelphiColorToColorCustomType.cs und DelphiColorStringToHexColorCustomType.cs |
+| StRS-027 | SyRS-040 | SwRS-050 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (11.441 Zeilen) |
+| StRS-027 | SyRS-056 | SwRS-051 | src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptItemBase.cs und ReceiptSupplierItemBase.cs |
+| StRS-028 | SyRS-041 | SwRS-052 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, die vier genannten Zeilen mit jeweils eigener Zustandsprüfung |
+| StRS-029 | SyRS-042 | SwRS-053 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, `private Result CanUserEditReceipt(...)` mit den vier Aufrufstellen |
+| StRS-030 | SyRS-043 | SwRS-054 | src/backend/Centron.BL/Sales/Receipts/ReceiptCartBL.cs, `var offer = this.CreateNewVersion(cartI3D, currentUser);` vor jeder Änderung |
+| StRS-031 | SyRS-044 | SwRS-055 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, sechs Fundstellen der identischen Prüfung |
+| StRS-033 | SyRS-045 | SwRS-056 | src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs mit den sieben Methoden und beiden Schleifenarten |
+| StRS-035 | SyRS-047 | SwRS-057 | src/backend/Centron.BL/Warehousing/TaxBL.cs mit den elf Methoden |
+| StRS-037 | SyRS-049 | SwRS-058 | src/backend/Centron.BL/Sales/Receipts/ReceiptTemplateBL.cs |
+| StRS-038 | SyRS-050 | SwRS-059 | src/backend/Centron.BL/Sales/Receipts/ReceiptProvisionSchemaBL.cs, ReceiptProvisionEmployeeGoalBL.cs, ReceiptProvisionEmployeeLevelBL.cs |
+| StRS-040 | SyRS-052 | SwRS-060 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Aufruf `_receiptLayoutItemKindPdfHelperBL.CreatePdf(...)` mit elf Parametern |
+| StRS-041 | SyRS-053 | SwRS-061 | src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs mit den genannten Methoden und der Teildatei für ZUGFeRD 1.0 |
+| StRS-042 | SyRS-054 | SwRS-062 | src/backend/Centron.BL/Sales/Receipts/ReceiptCartReleaseSystemBL.cs, die vier Empfängerermittlungen und fünf Empfängergruppen |
+| StRS-030 | SyRS-043 | SwRS-063 | src/backend/Centron.DAO/Repositories/Sales/Receipts/ mit elf `SaveReceipt*Repository`-Klassen und der Basis `SaveReceiptRepository.cs` |
+| StRS-013 | SyRS-018 | SwRS-064 | src/backend/Centron.BL/Sales/Receipts/ReceiptLogBL.cs mit den typisierten Erzeugungsmethoden |
+| StRS-028 | SyRS-041 | SwRS-065 | src/backend/Centron.BL/Sales/Receipts/ReceiptProgressionBL.cs |
+| StRS-024 | SyRS-036 | SwRS-066 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeilen 5735-5750 mit dem Ausschluss von Rabatt- und Frachtposition aus der Bemessungsgrundlage |
+| StRS-028 | SyRS-041 | SwRS-067 | src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptCompleteReason.cs und src/backend/Centron.BL/Sales/Receipts/ReceiptCompleteReasonBL.cs |
+| StRS-041 | SyRS-053 | SwRS-068 | src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptBase.cs mit den vier Empfängerangaben |
+| StRS-027 | SyRS-040 | SwRS-069 | src/backend/Centron.Entities/Entities/Sales/Receipts/LeasingAndService/LeasingLog.cs und ServiceLog.cs |
+| StRS-044 | SyRS-070 | SwRS-070 | src/backend/Centron.Entities/Entities/Sales/Receipts/ContractLists/ReceiptContract.cs mit den vier Verweisen |
+| StRS-045 | SyRS-071 | SwRS-071 | src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs (500 Zeilen) und AutomaticFacturaBL.Contracts.cs (2.432 Zeilen) |
+| StRS-046 | SyRS-072 | SwRS-072 | src/backend/Centron.BL/WebServices/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaWebServiceBL.cs, AddInterval(...) ohne Datenbankzugriff |
+| StRS-047 | SyRS-073 | SwRS-073 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, WriteReceiptLogs(...), Zeilen 10313-10332 |
+| StRS-048 | SyRS-074 | SwRS-074 | src/backend/Centron.Entities/Entities/Sales/CustomerAssets/Contracts/ClickContracts/ mit den vier Entitäten |
+| StRS-049 | SyRS-075 | SwRS-075 | src/backend/Centron.BL/RiverDivo/RiverConnectionBL.cs, Zeile 41, Signatur und Rückgabetyp |
+| StRS-050 | SyRS-076 | SwRS-076 | src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs und src/backend/Centron.BL/WebServices/Sales/CustomerAssets/TimerBilling/TimerBillingWebServiceBL.cs |
+| StRS-049 | SyRS-075 | SwRS-077 | src/backend/Centron.BL/WebServices/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaWebServiceBL.cs, `var calcAmount = articleReference.CalculateContractBillingAmount(totalQuantity);` |
+| StRS-052 | SyRS-078 | SwRS-078 | src/backend/Centron.Entities/Entities/Statistics/MspCollectors/MspEvaluation/MspEvaluationHistory.cs mit `ReceiptState` |
+| StRS-044 | SyRS-079 | SwRS-079 | src/webservice/Centron.Host/AspNetCore/HostedServices/ContractEndeService.cs mit `session.GetBL<ContractWebServiceBL>().RefreshContractEndeDate();` |
+| StRS-053 | SyRS-080 | SwRS-080 | src/backend/Centron.BL/Warehousing/ mit den genannten Fachklassen |
+| StRS-055 | SyRS-082 | SwRS-081 | src/backend/Centron.BL/Warehousing/SecondStockArticleBL.cs, RebookStockArticle(...) mit `if (sourceStoreI3D == -1 || destinationStoreI3D == -1)` |
+| StRS-060 | SyRS-087 | SwRS-082 | src/backend/Centron.BL/EDI/SupplierEDI/ mit sieben Teildateien und ClientConnectBL |
+| StRS-061 | SyRS-088 | SwRS-083 | src/backend/Centron.BL/Warehousing/ActionPriceBL.cs mit den vier Methoden |
+| StRS-056 | SyRS-083 | SwRS-084 | src/backend/Centron.BL/Storage/StorageBL.cs, `public delegate void ViewState(string Text, int StorageI3D, int Count, int Position);` |
+| StRS-057 | SyRS-084 | SwRS-085 | src/backend/Centron.DAO/Mappings/Sales/CustomerAssets/BarcodeToPositionMaps.cs und BarcodeToPosition2Maps.cs |
+| StRS-061 | SyRS-088 | SwRS-086 | src/backend/Centron.BL/Warehousing/External/ExternalArticleBL.cs |
+| StRS-053 | SyRS-080 | SwRS-087 | src/backend/Centron.BL/Warehousing/ArticleUnitBL.cs und ArticleUnitHelper.cs |
+| StRS-055 | SyRS-082 | SwRS-088 | src/backend/Centron.BL/Warehousing/StockManagement/StorageAreaBL.cs und StoragePlaceBL.cs |
+| StRS-087 | SyRS-130 | SwRS-089 | src/backend/Centron.BL/Warehousing/StockManagement/PartListArticleBL.cs |
+| StRS-064 | SyRS-100 | SwRS-100 | src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, Save(...) und DoBeforeSave(...) mit der vollständigen Schrittfolge |
+| StRS-066 | SyRS-102 | SwRS-101 | src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs, DeleteHelpdeskTimer(...) mit `Task.Run(async () => { using var newSession = new DAOSession(); await new ScheduleBL(newSession).DeleteTimeSchedule(...); });` |
+| StRS-067 | SyRS-103 | SwRS-102 | src/backend/Centron.BL/WebServices/Sales/Support/HelpdeskTimerWebServiceBL.cs, ThrowIfUserDoesntHaveRightToChangeHelpdeskTimers(...) mit drei `throw new ResultException(...)` |
+| StRS-068 | SyRS-104 | SwRS-103 | src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs, Zeilen 786-827 mit Schleife und Kommentar |
+| StRS-069 | SyRS-105 | SwRS-104 | src/backend/Centron.BL/Sales/Support/Escalation/EscalationBL.cs, TestEscalation(EscalationTestFilter) und DoEscalation(EscalationTestFilter) |
+| StRS-070 | SyRS-106 | SwRS-105 | src/backend/Centron.BL/CheckListArea/CentronChecklistBL.cs, GetChecklistsAsTextFromObject(CentronObjectKindNumeric, int, bool) |
+| StRS-074 | SyRS-110 | SwRS-106 | src/backend/Centron.BL/SelfCare/SelfCareBL.cs mit dem wiederkehrenden Vierermuster je Objektart |
+| StRS-077 | SyRS-113 | SwRS-107 | src/backend/Centron.BL/ArtificialIntelligence/ApiClientFactory.cs, AiHttpModelCatalogClient.cs und AiApiLinkValidator.cs |
+| StRS-013 | SyRS-018 | SwRS-108 | src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs, DeleteHelpdeskTimer(...) mit dem vollständigen Aufruf von `CreateHistory` |
+| StRS-073 | SyRS-109 | SwRS-109 | src/backend/Centron.BL/CustomerArea/RmaBL.cs mit den fünf Objektarten und den genannten Methoden |
+| StRS-078 | SyRS-120 | SwRS-110 | src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs mit den neun Schritten |
+| StRS-081 | SyRS-122 | SwRS-111 | src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs, ExportInvoicesThroughSepa(...) mit `new PaymentTransactionSepaInterface().CreateSepaFile(...)` |
+| StRS-080 | SyRS-121 | SwRS-112 | src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposRunBL.cs mit der vollständigen Ablaufkette |
+| StRS-080 | SyRS-121 | SwRS-113 | src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs, InvoiceExportDone(...) mit der vollständigen Befüllung des Protokolls |
+| StRS-041 | SyRS-053 | SwRS-114 | src/backend/Centron.Entities/Entities/DataExchange/BookKeeping/Export/BookKeepingReceipt.cs |
+| StRS-081 | SyRS-122 | SwRS-115 | src/backend/Centron.Gateway/DataExchange/PaymentTransactions/Sepa/pain.008.001.02_GBIC_3.xsd und die daraus erzeugte Klasse pain_008_001_02_GBIC_3.cs |
+| StRS-096 | SyRS-142 | SwRS-120 | src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs, `_objectIndexes` mit `IObjectFulltextIndex` |
+| StRS-102 | SyRS-148 | SwRS-121 | src/backend/Centron.BL/Administration/Scripts/ScriptMethods/ mit `IScriptMethod`, `BaseScriptMethod`, `BaseRecurringScriptMethod`, `IRecurringScriptMethod`, `ScriptMethodPool`, `ScriptMethodsCollection`, `ScriptMethodKind` und `ScriptHelpers` |
+| StRS-104 | SyRS-150 | SwRS-122 | src/webservice/Centron.Host/AspNetCore/HostedServices/ManagedBackgroundService.cs mit den vier Vorlagenmethoden und den beiden Pflichtangaben |
+| StRS-097 | SyRS-143 | SwRS-123 | src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs mit den vier Ausführungsmethoden und drei Suchvarianten |
+| StRS-105 | SyRS-151 | SwRS-124 | src/backend/Centron.BL/Telemetry/TelemetryBL.cs, `internal TelemetryBL(DAOSession session)` mit durchgängig `public virtual`-Methoden |
+| StRS-100 | SyRS-146 | SwRS-125 | src/backend/Centron.BL/NexusNotifications/NexusNotificationsBL.cs mit `DBBaseBL<NexusNotification>` als Basis |
+| StRS-019 | SyRS-032 | SwRS-126 | src/backend/Centron.BL/Services/CachedTableBL.cs mit den sechs Methoden |
+| StRS-121 | SyRS-174 | SwRS-127 | src/backend/Centron.BL/WebServices/ObjectMapperConfiguration/ mit den fachbereichsbezogenen Profilen |
+| StRS-015 | SyRS-021 | SwRS-128 | src/backend/Centron.BL/Administration/CentronConfigDb/IMasterPasswordStorage.cs mit den drei Methoden |
+| StRS-010 | SyRS-014 | SwRS-129 | src/backend/Centron.BL/Modules/ModuleBL.cs, ModuleCategoryBL.cs und ModuleClass.cs |
+| StRS-106 | SyRS-160 | SwRS-130 | src/centron/Centron.WPF.UI/Services/Logics/TwoFactorAuthenticator/ mit den drei Typen |
+| StRS-121 | SyRS-174 | SwRS-131 | src/webservice/Centron.Host/Services/CentronRestServiceParts/ mit 32 Teildateien und CentronRestServiceInterfaceParts/ mit den zugehörigen Vertragsteilen |
+| StRS-122 | SyRS-175 | SwRS-132 | src/webservice/Centron.Controllers/Controllers/Unversioned/JwtAuthController.cs mit primärem Konstruktor |
+| StRS-123 | SyRS-176 | SwRS-133 | src/webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.RMM.cs und CentronRestService.RiverDivo.cs |
+| StRS-113 | SyRS-026 | SwRS-134 | src/nexus/CentronNexus/Shared/Auth/AuthController.cs, `await HttpContext.SignOutAsync("OpenIdConnectTemp");` mit dem erläuternden Kommentar |
+| StRS-075 | SyRS-028 | SwRS-135 | src/backend/Centron.Common/DeveloperSecurity.cs mit den drei schreibgeschützten Eigenschaften und der Prüfmethode |
+| StRS-075 | SyRS-039 | SwRS-136 | src/backend/Centron.BL/Core/ReplacementBL.cs |
+| StRS-113 | SyRS-167 | SwRS-137 | src/nexus/CentronNexus.Host/Program.cs, Zeilen 317-337 mit der Unterscheidung von `AddScoped` und `AddSingleton` |
+| StRS-119 | SyRS-172 | SwRS-138 | src/nexus/CentronNexus.OutlookAddIn/ mit den neun Bereichen und der eigenen Ressourcendatei |
+| StRS-099 | SyRS-145 | SwRS-139 | src/shared/Centron.Controls/ mit rund 40 fachlichen Bereichen |
+| StRS-106 | SyRS-004 | SwRS-140 | Directory.Build.props mit allen genannten Eigenschaften |
+| StRS-121 | SyRS-024 | SwRS-141 | src/centron/Centron.WPF.UI/Services/Container/Interceptors/CatchExceptionMakeErrorResultInterceptor.cs und LogErrorResultInterceptor.cs |
+| StRS-064 | SyRS-029 | SwRS-142 | src/backend/Centron.DAO/DAOFactory.cs, die vier `AppendListeners`-Aufrufe |
+| StRS-019 | SyRS-032 | SwRS-143 | src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs, Rückgabetyp `AccountSearchItemDTOPagingDTO` |
+| StRS-125 | SyRS-178 | SwRS-144 | tests/ mit den neun Projekten und 246 Ende-zu-Ende-Testdateien |
+| StRS-005 | SyRS-010 | SwRS-145 | docs/ mit 44 Dokumenten in acht Kategorien und docs/README.md als Inhaltsverzeichnis |
+| StRS-150 | SyRS-184 | SwRS-146 | src/backend/Centron.BL/Administration/Company/NumberGroupEnum.cs, `[Description("[nicht verwendet]")]` für `Contract` und `ClickContract` |
+| StRS-125 | SyRS-178 | SwRS-147 | tests/backend/Centron.Tests.BL mit 21 Testdateien gegenüber 14.707 C#-Dateien im Gesamtbestand |
+| StRS-044 | SyRS-079 | SwRS-148 | src/webservice/Centron.Host/AspNetCore/HostedServices/ManagedBackgroundService.cs ohne Instanzkennung oder Ausführungssperre |
+| StRS-104 | SyRS-150 | SwRS-149 | src/webservice/Centron.Host/AspNetCore/HostedServices/ForceGarbageCollectService.cs |
+| StRS-125 | SyRS-178 | SwRS-150 | src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/ und MultiTargetingWorkaround/ |
+| StRS-102 | SyRS-148 | SwRS-151 | src/backend/Centron.BL/Administration/Scripts/ScriptEngineBL.cs, `private static int[] _scriptIgnoreIfErrorList = { 10178, 10210, 10211, 50000 };` ohne erläuternden Kommentar |
+| StRS-106 | SyRS-004 | SwRS-152 | Directory.Build.props, `<EnableUnsafeBinaryFormatterSerialization>true</EnableUnsafeBinaryFormatterSerialization>` mit dem erläuternden Kommentar |
+| StRS-005 | SyRS-011 | SwRS-153 | src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, IsModuleAvailable<T>() gegen `CentronCache.Instance.CurrentUserAppRights` |
+| StRS-106 | SyRS-004 | SwRS-154 | Directory.Build.props, `WarningsNotAsErrors` mit `NU1901;NU1902;NU1903;NU1904` und dem Kommentar "Nuget known vulnerabilities should not break the build" |
+| StRS-113 | SyRS-167 | SwRS-155 | src/nexus/CentronNexus/Shared/Auth/TicketFilterService.cs mit `using Centron.BusinessLogic.Administration.Rights;` und `centronService.GetEmployeeToSalesAreaMappings(...)` |
+| StRS-108 | SyRS-003 | - | docker/compose/compose.yaml mit den vier Diensten, Abhängigkeiten und Portzuordnungen |
+| StRS-003 | SyRS-023 | SwRS-014 | src/backend/Centron.BL/Administration/Logins/TicketBL.cs, SetLoginIP(AppUser) mit dem Ersatzwert `"[unknown]"` |
+| StRS-010 | SyRS-025 | SwRS-132 | src/webservice/Centron.Controllers/Authorization/CentronHostedAuthorization.cs, HandleRequirementAsync(...) mit der Lizenzprüfung |
+| StRS-119 | SyRS-027 | SwRS-134 | src/nexus/CentronNexus.Host/Program.cs, Zeilen 272-273 |
+| StRS-017 | SyRS-031 | - | src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Region "Adressen/CRM" mit den drei Bedingungen auf `IsAccountManagementActive` |
+| StRS-020 | SyRS-034 | SwRS-041 | src/backend/Centron.Entities/Entities/Accounts/Campaigns/ mit den zehn genannten Entitäten |
+| StRS-023 | SyRS-035 | - | src/backend/Centron.Entities/Entities/Accounts/Survey/SurveyProcessProperties.cs und SurveyStepInstruction.cs |
+| StRS-035 | SyRS-038 | - | src/backend/Centron.BL/CountryArea/CountryBL.cs und FederalStateBL.cs |
+| StRS-034 | SyRS-046 | - | SSMS_DB_SCHEMA.sql, `CREATE TABLE [dbo].[Zahkond]` mit den 19 Gültigkeitsspalten und den vier Fälligkeitsspalten |
+| StRS-036 | SyRS-048 | - | src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptBase.cs, `CurrencyFactor` |
+| StRS-039 | SyRS-051 | - | src/backend/Centron.BL/Sales/Receipts/DownPayment/DownPaymentBL.cs |
+| StRS-043 | SyRS-055 | - | src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractExternalArticleImportHeadBL.cs und ContractExternalArticleImportPositionsBL.cs |
+| StRS-040 | SyRS-058 | - | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Zeile 330, ExportReceiptToExcel(...) |
+| StRS-031 | SyRS-059 | - | src/backend/Centron.Entities/Entities/Sales/CustomerAssets/AssetLocks/AssetLock.cs mit `Lockuser` und `Version` |
+| StRS-051 | SyRS-077 | - | src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung `FlatRateProjectAppModuleController` mit drei Rechte-IDs |
+| StRS-054 | SyRS-081 | - | src/webservice/Centron.Host/AspNetCore/HostedServices/UpdateArticleAndMaterialGroupTaxRatesService.cs |
+| StRS-058 | SyRS-085 | - | src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptSupplierItemBase.cs |
+| StRS-059 | SyRS-086 | - | src/centron/Centron.WPF.UI/Modules/Purchasing/OrderSuggestionList/ |
+| StRS-062 | SyRS-089 | - | src/apis/Centron.Api.Gls/CentronGlsErrors.cs |
+| StRS-063 | SyRS-090 | - | src/webservice/Centron.Host/AspNetCore/HostedServices/ArticleImportService.cs |
+| StRS-064 | SyRS-101 | SwRS-100 | src/backend/Centron.BL/Sales/Support/UpdateHelpdeskBL.cs, UpdateCategory(...) mit der vollständigen Ableitung über `grandParent ?? parent ?? category` |
+| StRS-071 | SyRS-107 | - | src/backend/Centron.Entities/Entities/CustomerArea/Support/TicketPattern.cs, TicketPatternChecklistLink.cs, TicketPatternCustomerMapping.cs, TicketPatternPreview.cs |
+| StRS-072 | SyRS-108 | - | src/backend/Centron.BL/TicketProjects/TicketProjectBL.cs und src/backend/Centron.BL/Sales/Support/TicketProjectDependencyBL.cs |
+| StRS-075 | SyRS-111 | - | src/backend/Centron.BL/MailScanner/MailScannerBL.cs mit Profilen, Arbeitsabläufen, Schritten und Protokoll |
+| StRS-076 | SyRS-112 | - | src/backend/Centron.BL/ExpectedEvents/ExpectedEventsBL.cs mit den acht Methoden |
+| StRS-082 | SyRS-123 | - | src/backend/Centron.Entities/Entities/DataExchange/BookKeeping/Export/BookKeepingReceipt.cs |
+| StRS-084 | SyRS-124 | - | src/backend/Centron.BL/Administration/BookKeepingAccountSystems/BookKeepingAccountSystemBL.cs |
+| StRS-085 | SyRS-125 | - | src/backend/Centron.BL/Warehousing/CostCenterBL.cs und CostObjectBL.cs |
+| StRS-086 | SyRS-126 | - | src/apis/Centron.APIs.FinAPI/FinApiClient.cs mit Requests, Responses und RestClient |
+| StRS-089 | SyRS-131 | - | src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs, GetEmployeeTimeStatistics(...) |
+| StRS-090 | SyRS-132 | - | src/backend/Centron.BL/MyDay/MyDayBL.cs, die genannten Methoden einschließlich SaveOrUpdateFinalizedDay(...) |
+| StRS-091 | SyRS-133 | - | src/webservice/Centron.Host/AspNetCore/HostedServices/ExchangeSyncService.cs, `CheckConfigAndSettingsAsync` mit `_couldExecute` und die Fehlerbehandlung |
+| StRS-092 | SyRS-134 | - | src/backend/Centron.BL/Tapi/PhoneCallBL.cs, SyncPhoneCalls(), Zeilen 283-330 mit der vollständigen Prüfkette |
+| StRS-093 | SyRS-140 | - | src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs, GenerateReportParameters(...) und SetValueForParameter(...) |
+| StRS-095 | SyRS-141 | - | src/backend/Centron.BL/Administration/FileManagement/DirectoryReferenceProviders/Sepa/SepaDirectoryReferenceProvider.cs |
+| StRS-098 | SyRS-144 | - | src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Zeile 608 (`CreateProperty("Passwort", CustomizationDataTypes.EncryptedText)`), Zeile 700 (Verschlüsselung) und Zeile 1052 (Entschlüsselung) |
+| StRS-101 | SyRS-147 | - | src/backend/Centron.BL/ExternalToolsBL/ExternalToolBL.cs |
+| StRS-103 | SyRS-149 | - | src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung `SqlManagerAppModuleController` mit `SQL_MANAGER` |
+| StRS-107 | SyRS-161 | - | .github/workflows/build.yml, Auftrag "Build and sign" mit den Versionsausgaben |
+| StRS-108 | SyRS-162 | - | src/webservice/Centron.Host/AspNetCore/WcfBridge/ |
+| StRS-109 | SyRS-163 | - | src/backend/Centron.DAO/DAOFactory.cs, SetConnection(IDAOConnection, string) mit Sperre, Neuaufbau und `AddApplicationName(...)` |
+| StRS-110 | SyRS-164 | - | src/centron/Centron.WPF.UI/nlog.config mit allen genannten Parametern |
+| StRS-111 | SyRS-165 | - | src/webservice/Centron.Host/Services/ICentronRestService.cs, `CheckTransferToWebService` und `CheckWebServiceToSqlServerTransfer` |
+| StRS-112 | SyRS-166 | - | src/webservice/Centron.Controllers/Controllers/v1/Administration/ThemesController.cs |
+| StRS-113 | SyRS-168 | - | src/nexus/CentronNexus/Shared/Auth/AuthPage.razor, CustomerAuthPage.razor und OutlookAuthPage.razor |
+| StRS-115 | SyRS-169 | SwRS-062 | src/backend/Centron.BL/Sales/Receipts/ReceiptCartBL.cs, CreateNewCart(...) und UpdateCartInfo(...) mit der Prüfreihenfolge |
+| StRS-116 | SyRS-170 | - | src/backend/Centron.Interfaces/Sales/Receipts/WebReceipt/WebReceiptState.cs und src/backend/Centron.Entities/Entities/Administration/Documents/Receipts/ReceiptPdfDocument.cs |
+| StRS-117 | SyRS-171 | - | src/backend/Centron.Entities/Entities/Administration/FileManagement/SharedDocuments/SharedDocumentLog.cs |
+| StRS-120 | SyRS-173 | - | src/backend/Centron.Entities/Entities/CustomerArea/Support/MobileHelpdesk.cs, HelpdeskCategoryMobile.cs, HelpdeskPriorityMobile.cs, HelpdeskStateMobile.cs |
+| StRS-124 | SyRS-177 | - | src/backend/Centron.BL/ObjectExternalReferences/ObjectExternalReferenceBL.cs mit `DeleteReference(int objectI3D, CentronObjectKindNumeric kind)` |
+| StRS-125 | SyRS-179 | - | Directory.Build.props, `<TreatWarningsAsErrors>true</TreatWarningsAsErrors>` und `<WarningsNotAsErrors>$(WarningsNotAsErrors);NU1901;NU1902;NU1903;NU1904;NU1510;NU1603;CS0618;ASPDEPR004;ASPDEPR008</WarningsNotAsErrors>` |
+| StRS-146 | SyRS-180 | - | src/backend/Centron.DAO/DAOFactory.cs, TryRecoverConnectionPool(Exception) mit `SqlConnection.ClearAllPools()` |
+| StRS-147 | SyRS-181 | SwRS-128 | SSMS_DB_SCHEMA.sql, Datenbankdefinition mit Dateipfaden und Größen |
+| StRS-148 | SyRS-182 | - | src/backend/Centron.Entities/Entities/Administration/Documents/Receipts/ReceiptPdfDocument.cs und ReceiptPdfDocumentLog.cs |
+| StRS-149 | SyRS-183 | SwRS-022 | src/nexus/CentronNexus/Shared/Auth/TicketFilterService.cs, Kommentar "This is a WebService call which is not cached. This is called each time the ticket list is rendered." |
+| StRS-003 | SyRS-185 | - | src/nexus/CentronNexus.Host/Program.cs, `options.Cookie.SecurePolicy = CookieSecurePolicy.SameAsRequest;` |
+| StRS-001 | SyRS-186 | - | src/backend/Centron.DAO/DAOFactory.cs, SetConnection(IDAOConnection, string) mit Neuaufbau der Sitzungsfabrik je Verbindung |
+| StRS-010 | SyRS-187 | - | docs/reference/security/licensing-system.md, "The single source of truth for all our available licenses is the license-server." |
+| StRS-013 | SyRS-188 | SwRS-031 | src/centron/Centron.WPF.UI/nlog.config, `maxArchiveFiles="15"` |
+| StRS-007 | SyRS-189 | - | src/webservice/Centron.Host/AspNetCore/WcfBridge/Interception/Interceptors/ApiCallTelemetryInterceptor.cs |
+| StRS-003 | SyRS-190 | - | src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs, AuthenticateInternal() ohne Fehlversuchszählung |
+| StRS-005 | SyRS-191 | SwRS-018 | src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, IsModuleAvailable<T>() gegen `CentronCache.Instance.CurrentUserAppRights` |
+| StRS-099 | SyRS-192 | - | README.md, Abschnitte "Which components to use" und "HTML layouting" |
+| StRS-148 | SyRS-193 | - | src/backend/Centron.Interfaces/Administration/Settings/ApplicationSettingDefinitions.cs, `InvoiceArchiveActive` |
+| StRS-068 | SyRS-194 | - | src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs, `DateTime.Today >= user.AccountDisabledFromDate` |
+| StRS-094 | SyRS-195 | - | src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposRunBL.cs, `_reportGroupBL.GetParameters(group, loggedInUser.User)` und `_reportDataBL.GetReportForPrinting(report, group, parameters, loggedInUser.User)` |
+| StRS-009 | SyRS-009 | - | src/backend/Centron.BL/Administration/Logins/Auth/AuthenticatorFactory.cs |
+| StRS-018 | SyRS-030 | - | src/backend/Centron.BL/Accounts/AccountBL.cs, GetNewAccount(...), `defaultAddress.Data.IsDefault = true; defaultAddress.Data.AddressKind = 1;` |
+| StRS-021 | SyRS-034 | - | src/backend/Centron.Entities/Entities/Accounts/Account.cs, `AdvertisingNotAllowed`, `AdvertisingNotAllowedInfo` |
+| StRS-032 | SyRS-045 | - | src/backend/Centron.BL/Administration/Company/NumberGroupEnum.cs |
+| StRS-065 | SyRS-101 | - | src/nexus/CentronNexus/Shared/Auth/TicketFilterService.cs, GetWebAccountTicketFilter(...) mit `combinedFilter.Operands.Add(new BinaryOperator(nameof(TicketListItem.IsOnlyInternalVisible), true, BinaryOperatorType.NotEqual));` |
+| StRS-079 | SyRS-120 | - | src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs, GetPreviewForDunningRun(...), ValidateDunningReports() und ResetDunningRun(int, LoggedInUser) |
+| StRS-083 | SyRS-123 | - | src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung `DatevOnlineAppModuleController` mit `() => LicenseManager.Instance.HasLicense(LicenseGuids.DatevOnline)` ohne Centron-Alternative |
+| StRS-088 | SyRS-130 | - | src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Registrierung `MaschineManagementAppModuleController` |
+| StRS-114 | SyRS-168 | - | src/nexus/CentronNexus/WebCart/ mit CustomperPortalHomePage.razor, CustomerTicketDetailsPage.razor, ReceiptsOverview.razor, ContractsOverview.razor, CustomerPortalPublicDocumentsPage.razor |
+| StRS-118 | SyRS-130 | - | src/nexus/CentronNexus/ProductionOrderManagement/ mit Components, Model und Pages |
+| StRS-126 | SyRS-036 | - | src/backend/Centron.BL/Finances/ProductLifecycleBL.cs |
+| StRS-127 | - | - | src/backend/Centron.Entities/Entities/ProductMatrix/CustomerProductMatrixRatingChangeLog.cs |
+| StRS-128 | - | - | src/backend/Centron.Interfaces/QM/ |
+| StRS-129 | SyRS-014 | - | src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, `CentronDashboardAppModuleController` mit `Helper.NoRightCheck()` |
+| StRS-130 | SyRS-146 | - | src/backend/Centron.BL/ToDoArea/IToDoObjectKind.cs und ToDoBL.cs |
+| StRS-131 | SyRS-017 | - | src/backend/Centron.Entities/Entities/AppointmentRequests/AppointmentProposal.cs |
+| StRS-132 | SyRS-017 | - | src/backend/Centron.BL/WebLinks/IWebLinkActionHandler.cs mit zwei Umsetzungen |
+| StRS-133 | - | - | src/backend/Centron.BL/VideoPortal/VideoPortalAssignmentBL.cs mit den vier Methoden und Benutzerbezug |
+| StRS-134 | - | - | src/backend/Centron.BL/Chats/ChatBL.cs, CreateChat(...) mit `CentronObjectKindNumeric? objectKind` |
+| StRS-135 | - | - | src/backend/Centron.BL/Tags/TagsBL.cs, AddTicketTag(int, string, LoggedInUser) mit vorheriger Suche über `GetTag(caption, ...)` |
+| StRS-136 | - | - | src/backend/Centron.BL/Processes/ProcessBL.cs mit den vier generischen Ladefunktionen und dem Schalter `includeStepsandBindings` |
+| StRS-137 | SyRS-037 | - | SSMS_DB_SCHEMA.sql mit 221 Tabellen des Präfixes `AssetManagement` einschließlich Prüfkonfigurationen, Prüfergebnissen und Sammlerkonfigurationen |
+| StRS-138 | SyRS-090 | - | src/backend/Centron.BL/TradePool/TradePoolBL.cs, GetTradeArticleList(int, int, string, string, out int, string, TradeArticleFilterOptions) |
+| StRS-139 | - | - | src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs, GetActivedVoucherBarcodes(bool, bool, bool) |
+| StRS-140 | - | - | src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, auskommentierte Registrierung mit dem erläuternden Kommentar |
+| StRS-141 | SyRS-177 | - | src/backend/Centron.BL/CPra/CPraConnectorBL.cs, GetCPraWebHookLink(...) mit neun Kontextparametern |
+| StRS-142 | - | - | src/centron/Centron.WPF.UI/Modules/DataExchange/DocSync/ und die Registrierung `DocSyncSettingsAppModuleController` |
+| StRS-143 | - | - | src/backend/Centron.BL/GUI/UserGridBL.cs |
+| StRS-144 | SyRS-019 | - | src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs, DoDeleteContactPersonSocialNetworks(StringBuilder, int) |
+| StRS-145 | - | - | src/nexus/CentronNexus/Shared/Auth/TicketFilterService.cs, LoadSalesAreas(int) mit der Einschränkung auf `SalesAreaI3DAsString` |
+
+---
+
+## 2. Backward-Traceability (StRS ← SyRS / SwRS)
+
+| StRS-ID | Titel | verfeinert durch SyRS | verfeinert durch SwRS |
+|---|---|---|---|
+| StRS-001 | Mandantenfähige Abbildung der eigenen Unternehmensstruktur | SyRS-001, SyRS-186 | SwRS-001 |
+| StRS-002 | Filialstruktur innerhalb eines Mandanten | SyRS-002, SyRS-186 | — |
+| StRS-003 | Anmeldung interner Benutzer mit Benutzername und Kennwort | SyRS-005, SyRS-007, SyRS-022, SyRS-023, SyRS-185, SyRS-190 | SwRS-010 |
+| StRS-004 | Zeitlich und dauerhaft steuerbare Deaktivierung von Benutzerkonten | SyRS-006, SyRS-190 | SwRS-011 |
+| StRS-005 | Rechtebasierter Zugang zu Fachmodulen | SyRS-010, SyRS-011, SyRS-191 | SwRS-020, SwRS-026, SwRS-129, SwRS-153 |
+| StRS-006 | Einschränkende Rechte begrenzen die Sicht auf eigene Vorgänge oder die eigene Filiale | SyRS-012 | SwRS-021 |
+| StRS-007 | Zwei-Faktor-Authentifizierung mit konfigurierbarer Gültigkeitsdauer | SyRS-008, SyRS-189 | SwRS-012 |
+| StRS-008 | Anmeldung über Microsoft Entra ID (OpenID Connect) | SyRS-009, SyRS-172 | SwRS-013 |
+| StRS-009 | Anmeldung über Active Directory als Alternative zur lokalen Kennwortprüfung | SyRS-009 | SwRS-013 |
+| StRS-010 | Lizenzgesteuerter Funktionsumfang | SyRS-005, SyRS-013, SyRS-014, SyRS-025, SyRS-132, SyRS-134, SyRS-187 | SwRS-016, SwRS-023 |
+| StRS-011 | Zugangstoken für die Anbindung externer Systeme | SyRS-015 | SwRS-014, SwRS-024 |
+| StRS-012 | Kundenzugang über Webaccounts mit eigenem Rechtesystem | SyRS-016 | SwRS-025 |
+| StRS-013 | Nachvollziehbarkeit fachlicher Änderungen | SyRS-018, SyRS-023, SyRS-143, SyRS-188 | SwRS-030, SwRS-031, SwRS-042, SwRS-064 |
+| StRS-014 | Datenschutzgerechte Löschung personenbezogener Daten | SyRS-019, SyRS-151 | SwRS-032 |
+| StRS-015 | Verwaltung von Kundenzugangsdaten im Passwort-Manager | SyRS-020, SyRS-021, SyRS-144 | SwRS-033, SwRS-034, SwRS-128 |
+| StRS-016 | Ein Geschäftspartnerstamm mit mehreren Rollen je Partner | SyRS-030, SyRS-124 | SwRS-040 |
+| StRS-017 | Umschaltbare Führung der Kontenverwaltung zwischen Alt- und Neusystem | SyRS-031 | SwRS-040 |
+| StRS-018 | Mehrere Adressen und Ansprechpartner je Geschäftspartner | SyRS-030, SyRS-134 | SwRS-041, SwRS-068 |
+| StRS-019 | CRM-Aktivitäten zur Dokumentation der Kundenkommunikation | SyRS-032 | — |
+| StRS-020 | Kampagnen und Serienmailings an Geschäftspartner | SyRS-034 | — |
+| StRS-021 | Auswertung des Werbewiderspruchs beim Kampagnenversand | SyRS-034 | — |
+| StRS-022 | CRM-Projekte als überspannende Vertriebsvorgänge | SyRS-033, SyRS-108 | SwRS-042 |
+| StRS-023 | Kundenaudits und Fragebögen | SyRS-035 | — |
+| StRS-024 | Kundenspezifische Sonderpreise und Preislisten | SyRS-036, SyRS-088, SyRS-090 | SwRS-043 |
+| StRS-025 | Bankverbindungen und SEPA-Mandate am Geschäftspartner | SyRS-001, SyRS-060, SyRS-122, SyRS-171 | SwRS-044 |
+| StRS-026 | Dokumentation der beim Kunden installierten Geräte | SyRS-037, SyRS-074, SyRS-109, SyRS-176 | SwRS-045, SwRS-046 |
+| StRS-027 | Durchgängige Belegkette vom Angebot bis zur Rechnung | SyRS-040, SyRS-056, SyRS-057, SyRS-089 | SwRS-050, SwRS-065, SwRS-069 |
+| StRS-028 | Belegstatus offen, abgeschlossen und storniert | SyRS-041, SyRS-170 | SwRS-052, SwRS-067 |
+| StRS-029 | Belege dürfen nur von berechtigten Benutzern der zuständigen Filiale bearbeitet werden | SyRS-040, SyRS-042 | SwRS-053 |
+| StRS-030 | Versionierung von Belegen mit vollständiger Kopie in Versionstabellen | SyRS-043 | SwRS-054 |
+| StRS-031 | Optimistische Sperre gegen konkurrierende Belegänderungen | SyRS-044, SyRS-059 | SwRS-055 |
+| StRS-032 | Getrennte Nummernkreise je Belegart, Mandant und Filiale | SyRS-002, SyRS-033 | SwRS-002, SwRS-056 |
+| StRS-033 | Lückenlose und kollisionsfreie Vergabe von Belegnummern | SyRS-002, SyRS-033, SyRS-045 | SwRS-056 |
+| StRS-034 | Zahlungsbedingungen mit Skontostaffel und belegartbezogener Gültigkeit | SyRS-046 | — |
+| StRS-035 | Mehrwertsteuer mit zeitlicher Gültigkeitskette | SyRS-038, SyRS-047, SyRS-081 | SwRS-057 |
+| StRS-036 | Belege in Fremdwährung | SyRS-038, SyRS-048 | — |
+| StRS-037 | Belegvorlagen für wiederkehrende Belege | SyRS-049 | SwRS-058 |
+| StRS-038 | Provisionsabrechnung für Vertriebsmitarbeiter | SyRS-050 | SwRS-059 |
+| StRS-039 | Anzahlungsrechnungen und Schlussrechnung mit Anzahlungsverrechnung | SyRS-051 | — |
+| StRS-040 | Belegausgabe als PDF mit konfigurierbarem Layout | SyRS-052, SyRS-058, SyRS-140 | SwRS-060 |
+| StRS-041 | Elektronische Rechnung nach ZUGFeRD und XRechnung | SyRS-038, SyRS-041, SyRS-052, SyRS-053, SyRS-123, SyRS-182 | SwRS-061, SwRS-068, SwRS-114 |
+| StRS-042 | Zweistufiges Freigabewesen für Kundenwarenkörbe | SyRS-054, SyRS-169 | SwRS-062 |
+| StRS-043 | Import von Projekt- und Sonderpreisen aus Lieferantendateien | SyRS-055 | — |
+| StRS-044 | Wartungs- und Serviceverträge als eigene Belegart | SyRS-070, SyRS-079, SyRS-104, SyRS-170 | SwRS-070, SwRS-079 |
+| StRS-045 | Automatische Rechnungsstellung aus Verträgen | SyRS-055, SyRS-071, SyRS-078 | SwRS-071 |
+| StRS-046 | Abrechnungsintervalle mit Vielfachen und Mehrfachperioden je Rechnung | SyRS-072 | SwRS-072 |
+| StRS-047 | Kontingentverwaltung und Kontingentgrenzen im Vertrag | SyRS-073 | SwRS-073 |
+| StRS-048 | Zählerbasierte Abrechnung von Druck- und Kopiergeräten | SyRS-037, SyRS-074 | SwRS-074 |
+| StRS-049 | Nutzungsabhängige Abrechnung anhand von Daten eines externen RMM-Systems | SyRS-071, SyRS-072, SyRS-075, SyRS-176 | SwRS-075, SwRS-077 |
+| StRS-050 | Vereinfachte Abrechnung erfasster Ticketzeiten | SyRS-076 | SwRS-076 |
+| StRS-051 | Pauschalabrechnung von Projekten | SyRS-077 | — |
+| StRS-052 | Auswertung von Verträgen und Managed-Service-Beständen | SyRS-078 | SwRS-078 |
+| StRS-053 | Artikelstamm mit Preisen, Einheiten und Warengruppenzuordnung | SyRS-036, SyRS-080 | SwRS-080, SwRS-087 |
+| StRS-054 | Warengruppen als Ordnungs- und Steuerungsmerkmal | SyRS-047, SyRS-080, SyRS-081 | — |
+| StRS-055 | Bestandsführung über mehrere Lager, Lagerbereiche und Lagerplätze | SyRS-082, SyRS-083, SyRS-084, SyRS-086, SyRS-109 | SwRS-081, SwRS-088 |
+| StRS-056 | Inventur mit Bestandsaufnahme und Differenzbewertung | SyRS-083 | SwRS-084 |
+| StRS-057 | Kommissionierung von Aufträgen | SyRS-084 | SwRS-085 |
+| StRS-058 | Lieferantenbelegkette von der Anfrage bis zur Lieferantengutschrift | SyRS-085 | — |
+| StRS-059 | Bestellvorschlagsliste | SyRS-086 | — |
+| StRS-060 | Elektronischer Belegaustausch mit Distributoren | SyRS-087, SyRS-177 | SwRS-082 |
+| StRS-061 | Vergleich von Einkaufspreisen über mehrere externe Preisquellen | SyRS-036, SyRS-088, SyRS-090 | SwRS-043, SwRS-083, SwRS-086 |
+| StRS-062 | Versandabwicklung über Paketdienstleister | SyRS-089 | — |
+| StRS-063 | Artikelimport aus Lieferanten- und Katalogdaten | SyRS-090 | SwRS-086 |
+| StRS-064 | Tickets als zentraler Servicevorgang | SyRS-029, SyRS-100, SyRS-101, SyRS-111, SyRS-146, SyRS-173 | SwRS-100 |
+| StRS-065 | Abgestufte Ticketsichtbarkeit für Mitarbeiter und Kundenkontakte | SyRS-012 | SwRS-021, SwRS-022 |
+| StRS-066 | Zeiterfassung auf Tickets als Grundlage der Leistungsabrechnung | SyRS-073, SyRS-102, SyRS-131, SyRS-132 | SwRS-101 |
+| StRS-067 | Schutz erfasster Zeiten vor unberechtigter Änderung und Löschung | SyRS-076, SyRS-103 | SwRS-102, SwRS-108 |
+| StRS-068 | Fälligkeitsberechnung aus der Ticketpriorität unter Berücksichtigung von Geschäftszeiten | SyRS-038, SyRS-104, SyRS-194 | SwRS-103 |
+| StRS-069 | Automatische Eskalation überfälliger Vorgänge in drei Stufen | SyRS-105 | SwRS-104 |
+| StRS-070 | Checklisten als Arbeitsanweisung und Abschlussvoraussetzung | SyRS-106, SyRS-107 | SwRS-105 |
+| StRS-071 | Ticketvorlagen und mehrstufige Ticketprozesse | SyRS-107 | — |
+| StRS-072 | Projekt- und Aufgabenverwaltung für Serviceprojekte | SyRS-014, SyRS-108 | SwRS-019 |
+| StRS-073 | RMA- und Werkstattabwicklung mit Ein- und Rückversand | SyRS-109 | SwRS-109 |
+| StRS-074 | Kundenformulare zur strukturierten Datenerhebung | SyRS-035, SyRS-110, SyRS-189 | SwRS-106 |
+| StRS-075 | E-Mail-Integration für Tickets | SyRS-028, SyRS-039, SyRS-111 | SwRS-135, SwRS-136 |
+| StRS-076 | Erwartete Ereignisse zur Überwachung wiederkehrender Kundenmeldungen | SyRS-112 | — |
+| StRS-077 | KI-Unterstützung bei Ticketbearbeitung und Angebotserstellung | SyRS-113 | SwRS-107 |
+| StRS-078 | Mahnwesen mit drei Mahnstufen | SyRS-046, SyRS-120, SyRS-121 | SwRS-110 |
+| StRS-079 | Mahnvorschau und Zurücksetzen eines Mahnlaufs | SyRS-120 | — |
+| StRS-080 | Offene-Posten-Auswertung und Zahlungseingang | SyRS-121, SyRS-126 | SwRS-112, SwRS-113 |
+| StRS-081 | SEPA-Zahlungsverkehr mit Lastschrift und Überweisung | SyRS-001, SyRS-048, SyRS-060, SyRS-122 | SwRS-044, SwRS-111, SwRS-113, SwRS-115 |
+| StRS-082 | Buchhaltungsexport an externe Finanzbuchhaltung | SyRS-046, SyRS-053, SyRS-123 | SwRS-114 |
+| StRS-083 | Belegtransfer an DATEV Unternehmen online | SyRS-123 | — |
+| StRS-084 | Kontenrahmen und Kontenzuordnung | SyRS-124, SyRS-125 | — |
+| StRS-085 | Kostenstellen und Kostenträger | SyRS-125 | — |
+| StRS-086 | Anbindung des Online-Bankings zum Abgleich von Kontoumsätzen | SyRS-126 | — |
+| StRS-087 | Produktionsaufträge mit Positionen und Protokoll | SyRS-011, SyRS-130 | SwRS-089 |
+| StRS-088 | Maschinenverwaltung als Produktionsressource | SyRS-130 | — |
+| StRS-089 | Auslastung und Leistungsnachweise von Mitarbeitern | SyRS-131 | — |
+| StRS-090 | Tagesplanung "Mein Tag" mit automatischer Übernahme erfasster Zeiten | SyRS-102, SyRS-132 | — |
+| StRS-091 | Kalender mit Abgleich gegen Microsoft Exchange | SyRS-133 | — |
+| StRS-092 | Telefonieanbindung mit Anrufprotokoll und Anrufererkennung | SyRS-134 | — |
+| StRS-093 | Berichtswesen mit zentral verwalteten Berichtsvorlagen | SyRS-052, SyRS-058, SyRS-140, SyRS-195 | — |
+| StRS-094 | Zeitgesteuerte Berichtserstellung und -verteilung über den Reportserver | SyRS-140, SyRS-195 | — |
+| StRS-095 | Dokumentenablage mit Verzeichnisstruktur je Geschäftsobjekt | SyRS-141, SyRS-142, SyRS-181, SyRS-193 | — |
+| StRS-096 | Objektübergreifende Volltextsuche | SyRS-141, SyRS-142 | SwRS-120 |
+| StRS-097 | Massenänderung von Beleg-, Artikel- und Kontendaten | SyRS-143 | SwRS-123 |
+| StRS-098 | Kundenindividuelle Zusatzfelder ohne Codeänderung | SyRS-021, SyRS-144 | — |
+| StRS-099 | Zweisprachige Oberfläche mit Deutsch als Leitsprache | SyRS-145, SyRS-192 | SwRS-139 |
+| StRS-100 | Benachrichtigungen an Mitarbeiter über Vorgangsänderungen | SyRS-146 | SwRS-125 |
+| StRS-101 | Werkzeugintegration für externe Anwendungen | SyRS-039, SyRS-147 | SwRS-136 |
+| StRS-102 | Automatisierte Datenbankaktualisierung beim Programmstart | SyRS-148 | SwRS-035, SwRS-039, SwRS-121, SwRS-151 |
+| StRS-103 | Direkter Datenbankzugriff für Administratoren | SyRS-149 | — |
+| StRS-104 | Automatisierte Hintergrundverarbeitung mit zentraler Steuerung | SyRS-079, SyRS-133, SyRS-141, SyRS-150, SyRS-151, SyRS-164, SyRS-180 | SwRS-122, SwRS-148, SwRS-149 |
+| StRS-105 | Nutzungserfassung für Abrechnung und Produktsteuerung | SyRS-113, SyRS-151, SyRS-194 | SwRS-124 |
+| StRS-106 | Wahlweiser Betrieb des Windows-Clients mit direktem Datenbankzugriff oder über den Webservice | SyRS-004, SyRS-160, SyRS-163 | SwRS-003, SwRS-130 |
+| StRS-107 | Installation und Aktualisierung des Windows-Clients | SyRS-161, SyRS-178 | — |
+| StRS-108 | Betrieb des Webservice als Windows-Dienst, Konsolenanwendung oder Container | SyRS-003, SyRS-162, SyRS-185 | — |
+| StRS-109 | Verwaltung mehrerer Verbindungen und Umgebungen | SyRS-163 | — |
+| StRS-110 | Betriebsprotokollierung mit Archivierung | SyRS-164, SyRS-165, SyRS-188 | — |
+| StRS-111 | Diagnose von Netzwerk- und Antwortzeitproblemen | SyRS-017, SyRS-165 | — |
+| StRS-112 | Kundenindividuelles Erscheinungsbild | SyRS-166, SyRS-192 | — |
+| StRS-113 | Weboberfläche c-entron Nexus für Mitarbeiter | SyRS-026, SyRS-032, SyRS-146, SyRS-166, SyRS-167, SyRS-168, SyRS-192 | SwRS-028, SwRS-134, SwRS-137, SwRS-155 |
+| StRS-114 | Kundenportal mit Tickets, Belegen, Verträgen und Dokumenten | SyRS-016, SyRS-026, SyRS-166, SyRS-168 | SwRS-025, SwRS-028 |
+| StRS-115 | Kundenbestellung über den WebCart | SyRS-054, SyRS-169 | SwRS-062 |
+| StRS-116 | Belegeinsicht und Rückmeldung des Kunden im Web | SyRS-170 | — |
+| StRS-117 | Digitale Bestätigung und Unterzeichnung von Dokumenten | SyRS-171, SyRS-182, SyRS-189 | — |
+| StRS-118 | Produktionsauftragsbearbeitung im Webportal | SyRS-130 | — |
+| StRS-119 | Outlook-Add-In für Ticket- und Belegzugriff aus der E-Mail heraus | SyRS-027, SyRS-168, SyRS-172 | SwRS-138 |
+| StRS-120 | Mobile Nutzung durch Servicetechniker | SyRS-173 | — |
+| StRS-121 | Umfassende Integrationsschnittstelle für eigene und fremde Anwendungen | SyRS-015, SyRS-017, SyRS-024, SyRS-160, SyRS-174, SyRS-175 | SwRS-005, SwRS-036, SwRS-127, SwRS-131, SwRS-155 |
+| StRS-122 | Ressourcenorientierte REST-API als Nachfolgeschnittstelle | SyRS-024, SyRS-025, SyRS-175 | SwRS-027, SwRS-132, SwRS-155 |
+| StRS-123 | Schnittstelle für Monitoring- und RMM-Systeme | SyRS-017, SyRS-075, SyRS-112, SyRS-176, SyRS-177 | SwRS-075, SwRS-133 |
+| StRS-124 | Anbindung weiterer Fremdsysteme des Systemhausgeschäfts | SyRS-177 | — |
+| StRS-125 | Automatisierte Qualitätssicherung vor der Auslieferung | SyRS-004, SyRS-161, SyRS-178, SyRS-179 | SwRS-140, SwRS-144, SwRS-145, SwRS-147, SwRS-150, SwRS-154 |
+| StRS-126 | Verwaltung von Softwarelizenzen des Kunden (Produkt-Lifecycle) | — | — |
+| StRS-127 | Produktmatrix zur Bewertung des Kundenpotenzials | — | — |
+| StRS-128 | Qualitätsmanagementmodul | — | — |
+| StRS-129 | Persönliches Dashboard mit konfigurierbaren Kacheln | — | — |
+| StRS-130 | Persönliche Aufgabenliste | — | — |
+| StRS-131 | Terminanfragen mit Terminvorschlägen | — | — |
+| StRS-132 | Nachverfolgbare Kurzverweise für Kundenkommunikation | — | — |
+| StRS-133 | Videoportal für Anleitungen und Schulung | — | — |
+| StRS-134 | Interne Chats mit Objektbezug | — | — |
+| StRS-135 | Schlagworte an Tickets | — | — |
+| StRS-136 | Vorgangsübergreifende Prozesse mit Schritten und Bindungen | — | — |
+| StRS-137 | IT-Dokumentation und Asset-Management der überwachten Systeme | SyRS-184 | SwRS-146 |
+| StRS-138 | Handelsplattform für Artikeldaten Dritter | — | — |
+| StRS-139 | Gutscheinverwaltung | — | — |
+| StRS-140 | Reisekostenabrechnung | — | — |
+| StRS-141 | Anbindung eines externen Ticketsystems über Webhooks | — | — |
+| StRS-142 | Dokumentensynchronisation mit externen Ablagen | — | — |
+| StRS-143 | Anpassbare Listenansichten je Benutzer | — | — |
+| StRS-144 | Soziale Netzwerke am Geschäftspartner | — | — |
+| StRS-145 | Abteilungs- und Verkaufsgebietsstruktur | — | — |
+| StRS-146 | Verfügbarkeit des Gesamtsystems | SyRS-180 | — |
+| StRS-147 | Datensicherung und Wiederherstellung | SyRS-181 | — |
+| StRS-148 | Aufbewahrungsfristen und Unveränderbarkeit steuerlich relevanter Belege | SyRS-182, SyRS-193 | — |
+| StRS-149 | Mengengerüst und Antwortzeiterwartungen | SyRS-183 | — |
+| StRS-150 | Abgrenzung zur Vorgängeranwendung c-entron classic | SyRS-184 | SwRS-049 |
+
+---
+
+## 3. Hinweis zu den 19 nicht verfeinerten Stakeholder-Anforderungen
+
+Die Anforderungen StRS-126 bis StRS-145 (ohne StRS-137, das über SyRS-037 verfeinert ist) beschreiben Fachmodule, die im Rahmen dieses Laufs nur auf Stakeholder-Ebene erfasst wurden. Sie erfüllen damit die geforderte Mindestabdeckung ihres Moduls, sind aber nicht auf System- und Softwareebene ausgearbeitet. Der Abschnitt "Bekannte Lücken" im `Analysebericht.md` führt sie als Nachschlagbedarf für eine Folge-Iteration.

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-fcdf/Protokoll.md

@@ -0,0 +1,205 @@
+# Messprotokoll – Versuch 01 (V1 Baseline, Prompt-only) – Iteration 02
+
+## Lauf
+- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
+- **Iteration:** 02 – vom User ausdrücklich benannt; entspricht zugleich der Regel „höchste
+  vorhandene Iterationsnummer". Wiederholungslauf zur Varianzbestimmung in derselben Zelle.
+- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
+- **Startzeit:** 2026-08-26T13:22:51.5854176+02:00
+- **Endzeit:** 2026-08-26T15:42:30.6750061+02:00
+- **Dauer gesamt:** 2:19:39 (`duration_ms` 2:19:37; API: 2:08:14)
+  — **im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar**
+- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.662 versionierte Dateien)
+- **Codebasis-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748` (dirty: nein)
+- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja (Prüfmuster ohne Treffer);
+  die Codebasis ist seit Commit `f045b99a` kein eigenes Repository mehr, sondern Teil des
+  Arbeitsrepos – der Vorher/Nachher-Vergleich läuft deshalb pfadskopiert
+- **Snapshot-Zusatzartefakte:** keine – der Snapshot entspricht dem Commit-Stand
+- **Prompt-Repo-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748`
+
+## Werkzeugkonfiguration
+- **Skill-Version:** 4.4.0
+- **Claude-Code-Version:** 2.1.246
+- **CLI-Pfad:** `C:\Users\ChristophSchwoerer\.vscode\extensions\anthropic.claude-code-2.1.246-win32-x64\resources\native-binary\claude.exe`
+- **Modell (angefordert):** `claude-opus-5`
+- **Modelle (tatsächlich eingesetzt):** `claude-opus-5` 116.143.343 Tokens (99.99 %), `claude-haiku-4-5-20251001` 6.967 Tokens (0.01 %)
+- **Kontrolle Modell:** bestanden – ausschließlich das angeforderte Modell plus Haiku als zulässiger interner Hilfsaufruf
+- **Effort:** `max` (per `--effort max` gesetzt)
+- **Laufverzeichnis-ID:** `v4.4.0-fcdf`
+- **Ablage:** `Iteration 3/claude-opus-5/solo/max/`
+- **Parallele Läufe:** **ja** – zeitgleich liefen:
+  - `Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-37c5`
+  - `Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-a8f5`
+  - `Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048`
+  - `Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-f8b4`
+  - `Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-fb24`
+
+  Die Zeitangaben dieses Laufs sind daher **nicht** für Laufzeitvergleiche zu verwenden. Tokenverbrauch, Anforderungszahl, Belegkennzahlen und Denials bleiben unverzerrt.
+- **Agentenmodus:** `solo` (V1)
+- **Kontextfenster:** 1.000.000 Tokens; `maxOutputTokens` 64.000
+- **Sampling-Parameter:** nicht steuerbar über die CLI, nicht erfasst
+- **Nur bei lokalem Modellbetrieb:** entfällt (Cloud-Inferenz, `provider: firstParty`)
+- **Permission-Mode:** `acceptEdits`
+- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` /
+  `--disallowedTools` 33er-Denylist (schreibende und bauende Kommandos) **zuzüglich** `Task`, `Agent`, `Workflow` aus dem Modus `solo`
+- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
+- **MCP-Server / Agentendateien:** keine – aus dem Snapshot entfernt, zusätzlich `--safe-mode`
+- **Subagenten:** keine (`spawned` = 0, `by_type` leer)
+- **Verschachtelung:** `spawned` = 0, davon `spawned_by_subagents` = 0, `max_depth` = 0. Keine tieferen Ebenen, `_meta\subagenten.md` entfällt.
+
+## Validierungsstichprobe
+- **Größe:** noch nicht festgelegt
+- **Ziehungsverfahren:** noch nicht festgelegt
+- **Validatoren:** noch nicht festgelegt
+- **Stand:** noch nicht gezogen
+
+## Verbrauch
+
+### Hauptagent (`usage`)
+| Messgröße | Wert |
+|---|---:|
+| Input-Tokens | 526 |
+| Output-Tokens | 663.248 (davon 51.251 Thinking-Tokens) |
+| Cache-Write-Tokens | 1.101.913 |
+| Cache-Read-Tokens | 113.383.810 |
+| Agent-Turns | 371 |
+
+### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
+| Messgröße | `claude-opus-5` | `claude-haiku-4-5-20251001` | Summe |
+|---|---:|---:|---:|
+| Input-Tokens | 2.663 | 6.943 | 9.606 |
+| Output-Tokens | 678.979 | 24 | 679.003 |
+| Cache-Write-Tokens | 1.111.636 | 0 | 1.111.636 |
+| Cache-Read-Tokens | 114.350.065 | 0 | 114.350.065 |
+| **Tokens gesamt** | **116.143.343** | **6.967** | **116.150.310** |
+
+**Tokens gesamt: 116.150.310** — Input + Output + Cache-Write + Cache-Read über alle Modelle.
+Das ist die **berichtete Aufwandsgröße** der Versuchsreihe. `total_cost_usd` bleibt unberührt in
+`RawResult.json` erhalten, wird aber nicht ins Protokoll übernommen: Token sind modell- und
+preisunabhängig und bleiben damit über Preisänderungen und Modellwechsel hinweg vergleichbar.
+
+Da im Modus `solo` keine Subagenten laufen, sind `usage` und `modelUsage` für das Hauptmodell
+deckungsgleich; die Differenz zur Summe stammt allein aus den Haiku-Hilfsaufrufen.
+
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 150 | 33,6 % |
+| SyRS | 155 | 34,8 % |
+| SwRS | 141 | 31,6 % |
+| **Gesamt** | **446** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 217 | 48,7 % |
+| Sicherheit | 69 | 15,5 % |
+| Daten | 69 | 15,5 % |
+| Schnittstelle | 46 | 10,3 % |
+| nicht-funktional | 45 | 10,1 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 1.255 |
+| davon `PRIMÄR` | 1.067 (85,0 %) |
+| davon `SEKUNDÄR` | 111 (8,8 %) |
+| davon `KONTEXT` | 77 (6,1 %) |
+| Belege je Anforderung (Median) | 3,0 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 438 (98,2 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 414 | 92,8 % |
+| workaround | 17 | 3,8 % |
+| sonderfall | 1 | 0,2 % |
+| veraltet | 14 | 3,1 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 410 | 91,9 % |
+| als `HYPOTHESE` gekennzeichnet | 36 | 8,1 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 141 | 31,6 % |
+| mit ISO-25010-Qualitätsmerkmal | 181 | 40,6 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (139 risikorelevante Anforderungen, alle gedeckt) |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 446 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 446 von 446 mit Tracelinks (100,0 %) |
+
+## Ergebnis
+- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
+- **Session-ID:** `bf2feb1f-c832-4c9d-ac00-a6c1fea64ced`
+- **Permission-Denials:** 5 (2 × `Bash`, 1 × `Grep`, 2 × `Read`) – **keines auf `Task`/`Agent`/`Workflow`**. Der Agent hat zu keinem Zeitpunkt zu delegieren versucht; die Modus-Sperre wurde nie ausgelöst.
+- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0 – Bedingung `solo` eingehalten
+- **Subagenten-Prompts:** entfällt (Modus `solo`)
+- **Erzeugte Dateien:** 7 Dateien in `Ergebnisse\`:
+
+  | Datei | Größe |
+  |---|---:|
+  | `Analysebericht.md` | 106.543 B |
+  | `Glossar.md` | 16.775 B |
+  | `Hypothesen.md` | 15.440 B |
+  | `StRS.md` | 305.223 B |
+  | `SwRS.md` | 281.146 B |
+  | `SyRS.md` | 309.123 B |
+  | `Traceability.md` | 51.938 B |
+
+- **Root unverändert:** ja (zeilenendennormalisiert verglichen).
+- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
+
+## Anmerkungen/Auffälligkeiten
+
+**1. Iteration 3 – Snapshot mit DB-Schema.** `SSMS_DB_SCHEMA.sql` (3.266.626 B, 76.793 Zeilen,
+1.558 Tabellen, 182 Views, 63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel; SHA-256
+`ED7F2125…1FA8DB`) ist seit Commit `f349d189` Bestandteil des Untersuchungsgegenstands. Läufe der
+Iteration 2 hatten die Datei nicht – beide Iterationen sind **nicht poolbar**.
+
+**2. Parallelbetrieb – Zeitangaben unbrauchbar, Verbrauchsgrößen gültig.** Wanduhrzeit,
+`duration_ms` und `duration_api_ms` sind verzerrt; Tokenverbrauch, Anforderungszahl,
+Belegkennzahlen und Denials nicht. Einziger gültiger Laufzeitmesspunkt aller drei Iterationen
+bleibt der serielle Lauf `084301_v4.2.0-d6f9` mit 45:04.
+
+**3. CLI 2.1.246** statt der gegen 2.1.245 verifizierten Fassung.
+
+**4. Ertragsstärkster Lauf der gesamten Versuchsreihe – und der erste vollständig regelkonforme
+unter Prompt-Version 02.** 446 Anforderungen, 1.255 Belege, **Median 3,0 Belege je Anforderung**,
+98,2 % mit Primärbeleg, 139 risikorelevante Anforderungen allesamt gedeckt, Tracelinks bei 100 %.
+Alle fünf Prüfkriterien der Regelkonformität sind erfüllt.
+
+**5. Die Belegdichte steigt mit dem Denkaufwand.** Median 1,0 über 44 Läufe auf `high`, 2,0 bei
+`a8f5`, 3,0 hier. Der Befund „45,9 % aller Anforderungen trugen genau einen Beleg", der Anlass für
+Prompt-Version 02 war und sich unter Version 02 auf `high` sogar verschärft hatte, löst sich damit
+über den Effort auf – nicht über die Prompt-Formulierung.
+
+**6. Die Anti-Korrelation zwischen Menge und Qualität kippt.** Über die zehn `solo`/`high`-Läufe
+liefen Anforderungszahl und Primärbelegquote gegeneinander (Pearson −0,63, Spearman −0,70). Die
+beiden `max`-Läufe liefern beides zugleich: 380 Anforderungen bei 95,5 % und 446 bei 98,2 %. Der
+Zielkonflikt war also kein Gesetz, sondern Folge zu knappen Aufwands.
+
+**7. Ausgewogenste Ebenenverteilung der Reihe:** 150 StRS / 155 SyRS / 141 SwRS. Alle drei Ebenen
+tragen etwa ein Drittel – die Strukturstreuung, die auf `high` von 92,7 % StRS bis 89,4 % SwRS
+reichte, tritt hier nicht auf.
+
+**8. Der Preis:** 116,2 Mio. Tokens und 371 Turns – 260.000 Tokens je Anforderung gegenüber
+54.000 bei `a8f5` und rund 68.000 bei `3ef5`. `spawned` = 0, Modellkontrolle bestanden.
+Fünf Denials, keiner betraf `Task`/`Agent`/`Workflow`.

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-fcdf/_meta/anforderungen.md

@@ -0,0 +1,65 @@
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 150 | 33,6 % |
+| SyRS | 155 | 34,8 % |
+| SwRS | 141 | 31,6 % |
+| **Gesamt** | **446** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 217 | 48,7 % |
+| Sicherheit | 69 | 15,5 % |
+| Daten | 69 | 15,5 % |
+| Schnittstelle | 46 | 10,3 % |
+| nicht-funktional | 45 | 10,1 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 1.255 |
+| davon `PRIMÄR` | 1.067 (85,0 %) |
+| davon `SEKUNDÄR` | 111 (8,8 %) |
+| davon `KONTEXT` | 77 (6,1 %) |
+| Belege je Anforderung (Median) | 3,0 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 438 (98,2 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 414 | 92,8 % |
+| workaround | 17 | 3,8 % |
+| sonderfall | 1 | 0,2 % |
+| veraltet | 14 | 3,1 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 410 | 91,9 % |
+| als `HYPOTHESE` gekennzeichnet | 36 | 8,1 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 141 | 31,6 % |
+| mit ISO-25010-Qualitätsmerkmal | 181 | 40,6 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (139 risikorelevante Anforderungen, alle gedeckt) |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 446 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 446 von 446 mit Tracelinks (100,0 %) |
+

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-fcdf/_meta/before.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-fcdf/_meta/combined_prompt.md

@@ -0,0 +1,177 @@
+# Versuch 01 - Baseline (Prompt-only) - Iteration 02
+
+## Metadaten
+- **Versuch:** V1 Baseline (Prompt-only)
+- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
+- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
+- **Zeitstempel:** 2026-08-26
+- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
+- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
+
+  | Änderung | Auslösender Befund |
+  |---|---|
+  | Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
+  | Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
+  | Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
+  | Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
+  | Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
+  | Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
+  | Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
+
+  Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
+
+> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
+> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
+> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
+
+---
+
+## Prompt
+
+Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
+
+### Auftrag
+
+Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
+
+1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
+2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
+3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
+
+Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
+
+### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
+
+Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
+
+**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
+
+### Vorgehen (statische Analyse, keine Ausführung)
+
+Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
+
+**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
+
+**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig.
+
+**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
+
+2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
+3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
+4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
+5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
+6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
+
+### Pflicht-Eigenschaften jeder Anforderung
+
+- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
+- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
+- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
+- **Belegklassifikation:** Kennzeichne jeden Beleg als
+  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
+  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
+  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
+- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
+- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
+- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
+- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
+- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
+
+### Formatvorgabe pro Anforderung
+
+```
+ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
+Titel:         <kurzer Titel>
+Ebene:         <StRS | SyRS | SwRS>
+Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
+Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
+Akteur:        <Rolle / System / Komponente>
+Vorbedingung:  <Zustand vor Auslösen>
+Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
+Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
+Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
+Belege:
+  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
+  - [SEKUNDÄR] <...> - Begründung: <...>
+  - [KONTEXT]  <...> - Begründung: <...>
+Prüfidee:      <Akzeptanzkriterium oder Testidee>
+Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
+Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
+Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
+Status:        <belegt | HYPOTHESE>
+```
+
+### Traceability
+
+Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
+- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
+- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
+- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
+
+### Nicht-funktionale Anforderungen
+
+- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
+- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
+
+### Konsolidierungsbedarf
+
+Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
+
+**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
+
+### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
+
+```
+Ergebnisse/
+  StRS.md
+  SyRS.md
+  SwRS.md
+  Traceability.md   (oder Traceability.csv)
+  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
+  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
+  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
+                     Selbstbewertung, bekannte Lücken)
+```
+
+Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
+
+### Randbedingungen
+
+- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
+- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
+- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
+- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
+- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
+
+### Abschluss
+
+Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
+- Doppelte oder mehrfach vergebene IDs
+- Anforderungen ohne Beleg
+- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
+- Tracelinks auf nicht existierende IDs
+- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
+- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
+- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
+
+Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
+
+Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
+- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
+- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
+- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
+- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
+- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
+
+---
+
+### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
+Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien sowie das Ausführen von
+Kommandozeilenbefehlen im Arbeitsverzeichnis.
+Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.
+Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
+Werkzeuge zu ersetzen.
+### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
+Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
+`c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 3\claude-opus-5\solo\max\02_Lauf_2026-08-26_132237_v4.4.0-fcdf\Ergebnisse\`.
+Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-fcdf/_meta/endzeit.txt

@@ -0,0 +1 @@
+2026-08-26T15:42:30.6750061+02:00

Versuche/Versuch_01/Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-fcdf/_meta/startzeit.txt

@@ -0,0 +1 @@
+2026-08-26T13:22:51.5854176+02:00

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048/Ergebnisse/Analysebericht.md

@@ -0,0 +1,187 @@
+# Analysebericht
+
+## Schritt 0 — Modulinventar
+
+Granularität: Die fachlichen WPF-UI-Module (`src\centron\Centron.WPF.UI\Modules\*`) werden auf Ebene der 30 obersten Modulordner erfasst; ihre Unterordner (insgesamt > 150) sind die Belegquelle für die einzelnen Anforderungen und werden dort zitiert, bilden aber keine eigene Inventarzeile — mit Ausnahme der risikorelevanten Bereiche Finances, PasswordManager, Administration und Rma, in denen einzelne Unterordner wegen ihrer eigenständigen fachlichen Funktion zusätzlich in der Vertiefung (Schritt 0c) mit eigenen Anforderungen bedacht werden. Zusätzlich zu den WPF-Modulen sind die tragenden Architekturkomponenten (Backend-Schichten, externe API-Anbindungen, Webservice, Nexus, geteilte Bibliotheken) als eigene Inventarzeilen erfasst, da sie eigenständige, technisch wie fachlich abgrenzbare Bausteine der Codebasis sind.
+
+### A. Fachliche WPF-UI-Module (`src\centron\Centron.WPF.UI\Modules\`)
+
+| # | Modul | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| A01 | Administration | `Modules\Administration` | Systemverwaltung: Benutzer/Mitarbeiter, Mandanten, Rechte, globale Einstellungen, DSGVO-Werkzeuge, Report-Server. |
+| A02 | ArtificialIntelligence | `Modules\ArtificialIntelligence` | KI-gestützte Textgenerierung/Chat-Assistent mit Werkzeugzugriff auf Konten-, Artikel-, Ticket- und Mitarbeiterdaten. |
+| A03 | Calendar | `Modules\Calendar` | Kalenderdarstellung und Outlook-/CRM-Synchronisationseinstellungen. |
+| A04 | Dashboard | `Modules\Dashboard` | Kachelbasierte Modulübersicht (Startbildschirm) inkl. Favoriten/Autostart. |
+| A05 | DataExchange | `Modules\DataExchange` | Datenaustausch mit externen Systemen: DATEV, Bank-/SEPA-Zahlungsverkehr, DocBee, docuFORM, GfK, RMM, filialübergreifende Bestellvorschläge. |
+| A06 | ExternalTool | `Modules\ExternalTool` | Auswahl/Start konfigurierter externer Werkzeuge aus c-entron heraus. |
+| A07 | Finances | `Modules\Finances` | Abrechnung, Mahnwesen, OPOS, Zahlungen, Verträge, Vertragsauswertung, CRM-Adressstamm, Klickzähler. |
+| A08 | Global | `Modules\Global` | Modulübergreifende Dialoge: PDF-Viewer, Freifelder, Fehlerdialog, Diagnose, MSP-Lizenzvergleich, Videoportal. |
+| A09 | Gui | `Modules\Gui` | Verwaltung gespeicherter Oberflächen-Layoutprofile. |
+| A10 | Helpdesk | `Modules\Helpdesk` | Ticketsystem für Kundenservice inkl. Checklisten, Zeiterfassung, SLA-Dashboard, Prozessvorlagen. |
+| A11 | Logistic | `Modules\Logistic` | Versand-/Kommissionierungseinstellungen (Standardempfänger, Ziel-Lagerpflicht, Versandarten). |
+| A12 | Massenupdates | `Modules\Massenupdates` | Massenänderung von Preisen und Belegdaten über Vorlagen. |
+| A13 | MyCentron | `Modules\MyCentron` | Persönlicher Arbeitsbereich: Mein Tag, Kalender, Telefonie, Supremo-Fernwartung, persönliche Einstellungen. |
+| A14 | OnlineBanking | `Modules\OnlineBanking` | Bankkontenanbindung über finAPI sowie native FinTS/HBCI/EBICS-Verbindungen, Kontoumsatzabgleich. |
+| A15 | PLM | `Modules\PLM` | Produktlebenszyklus-Verwaltung (Status, Berater, verknüpfte Artikel). |
+| A16 | PasswordManager | `Modules\PasswordManager` | Verwaltung von Kundenzugangsdaten (Passwörter, VPN, RDP, SSH) mit Richtlinien-/Siegelkonzept. |
+| A17 | PayersAndCostCenter | `Modules\PayersAndCostCenter` | Verwaltung von Kostenstellen und Kostenträgern (inkl. Soft-Delete/Restore). |
+| A18 | Production | `Modules\Production` | Fertigungsauftrags- und Maschinenverwaltung. |
+| A19 | ProjectManagement | `Modules\ProjectManagement` | Ressourcenplanung speziell für die Abteilung Software-Entwicklung (CRM-Projekte + Tickets). |
+| A20 | ProjectPriceImport | `Modules\ProjectPriceImport` | Import projektspezifischer Sonderpreise aus Excel mit Preisdifferenzprüfung. |
+| A21 | Purchasing | `Modules\Purchasing` | Einkauf: Bestellvorschlagsliste, EDI-Abgleich, Reisekosten. |
+| A22 | QM | `Modules\QM` | Qualitätsmanagement-Einstellungen (Standard-Reklamationsgründe je Belegart). |
+| A23 | Reports | `Modules\Reports` | Verwaltung des Reportmotors (Reportgruppen, Druckeinstellungen, Ad-hoc-Abfragen). |
+| A24 | Rma | `Modules\Rma` | Retourenabwicklung (RMA) inkl. Versand an/Rücknahme vom Lieferanten. |
+| A25 | Sales | `Modules\Sales` | Vertrieb: Mailing-Vorlagen, Produktmatrix, Sonderartikel-/Vertrags-Preisimporte (Wortmann, Riverbird). |
+| A26 | Statistics | `Modules\Statistics` | Auswertungen: Verkaufsstatistik, Management-Info, MSP-Collector/-Statistik, Mitarbeiteranalyse. |
+| A27 | Survey | `Modules\Survey` | Umfrage-/Fragebogen-Engine, als Workflow-Prozess modelliert. |
+| A28 | TelekomDive | `Modules\TelekomDive` | Export von Angebotspositionen in die Telekom-D!VE-Marktplatzplattform. |
+| A29 | Warehousing | `Modules\Warehousing` | Lagerverwaltung: Artikelstamm, Bestand, Inventur, Barcode, Materialgruppen, Umsatzsteuer. |
+| A30 | (Purchasing/Warehousing Sub) SearchArticle/SupplierSearch | `Modules\Warehousing\SearchArticle`, `SupplierSearch` | Wiederverwendbare Such-/Auswahldialoge für Artikel und Lieferanten (mehrfach eingebunden). |
+
+### B. Architektur- und Integrationskomponenten (`src\backend`, `src\apis`, `src\webservice`, `src\nexus`, `src\shared`, root)
+
+| # | Komponente | Pfad | Fachliche/technische Aufgabe |
+|---|---|---|---|
+| B01 | Centron.BL | `src\backend\Centron.BL` | Geschäftslogikschicht (Rechte-, Abrechnungs-, Mahn-, Auth-, Vertragslogik u. v. m.). |
+| B02 | Centron.DAO | `src\backend\Centron.DAO` | Datenzugriffsschicht auf Basis NHibernate/FluentNHibernate gegen MSSQL. |
+| B03 | Centron.Entities | `src\backend\Centron.Entities` | Persistentes Domänenmodell (~1185 Entitätsklassen). |
+| B04 | Centron.Common | `src\backend\Centron.Common` | Gemeinsame Low-Level-Hilfsfunktionen (u. a. Passwort-Hashing). |
+| B05 | Centron.Gateway | `src\backend\Centron.Gateway` | EDI-/Buchhaltungs-/Banking-Gateway zu Großhändlern, DATEV u. a. Finanzbuchhaltungssystemen, SEPA. |
+| B06 | Centron.Interfaces | `src\backend\Centron.Interfaces` | Schnittstellen-/DTO-/Enum-Vertragsschicht zwischen allen Schichten. |
+| B07 | Centron.APIs.CopDataAccess | `src\apis\Centron.APIs.CopDataAccess` | SOAP-Anbindung an den Produktkatalogdienst "COP". |
+| B08 | Centron.APIs.EgisDataAccess | `src\apis\Centron.APIs.EgisDataAccess` | Anbindung an den EDI-Großhändler EGIS (Katalog, Preise, Warenkorb). |
+| B09 | Centron.APIs.FinAPI | `src\apis\Centron.APIs.FinAPI` | REST-Anbindung an den Open-Banking-Aggregator finAPI. |
+| B10 | Centron.APIs.ITscopeDataAccess | `src\apis\Centron.APIs.ITscopeDataAccess` | REST-Anbindung an den IT-Produktdatenmarktplatz ITscope. |
+| B11 | Centron.APIs.IcecatDataAccess | `src\apis\Centron.APIs.IcecatDataAccess` | Anbindung an die Produktdatenbank Icecat. |
+| B12 | Centron.Api.EbInterface | `src\apis\Centron.Api.EbInterface` | Generator für österreichische E-Rechnungen im ebInterface-XML-Format. |
+| B13 | Centron.Api.Gls | `src\apis\Centron.Api.Gls` | REST-Anbindung an den Paketdienstleister GLS. |
+| B14 | Centron.Api.Shipcloud | `src\apis\Centron.Api.Shipcloud` | REST-Anbindung an den Multi-Carrier-Versanddienst shipcloud.io. |
+| B15 | Centron.Api.docuFORM | `Centron.Api.docuFORM` (root) | OAuth2-Anbindung an die Dokumentenplattform docuFORM. |
+| B16 | Centron Webservice (Host/Controllers) | `src\webservice\Centron.Host*`, `Centron.Controllers` | Zentraler ASP.NET-Core-API-Host (Ticket-/JWT-/SecretKey-Auth, ~40 Controller). |
+| B17 | Centron.WebServices.Core | `src\webservice\Centron.WebServices.Core` | Geteilte DTO-/Serialisierungs-/Client-Bibliothek für WPF-Client, Nexus und Controller. |
+| B18 | c-entron.misc.ConnectionManager | `src\webservice\c-entron.misc.ConnectionManager` | Administrationswerkzeug zur Konfiguration/Steuerung des Webservice-Windows-Dienstes. |
+| B19 | CentronNexus (+Host) | `src\nexus\CentronNexus*` | Blazor-Server-Webanwendung "c-entron Nexus" (ServiceBoard, Kunden-Self-Service, WebCart). |
+| B20 | CentronNexus.OutlookAddIn | `src\nexus\CentronNexus.OutlookAddIn` | Outlook-Mail-Add-in zur Zuordnung von E-Mails zu Tickets/Kunden. |
+| B21 | Centron.Controls (+Preview) | `src\shared\Centron.Controls*` | Wiederverwendbare WPF-Steuerelementbibliothek (Grid, RDP/SSH-Einbettung, Reporting). |
+| B22 | Centron.Core | `src\shared\Centron.Core` | UI-unabhängige gemeinsame Basisbibliothek (MVVM-Basisklassen, TOTP, Eventaggregator). |
+
+**Summe Inventar:** 30 fachliche WPF-Module (A01–A30) + 22 Architektur-/Integrationskomponenten (B01–B22) = **52 Inventarzeilen**. Keine Zeile ist als „nicht analysiert" ohne Anforderung geführt (siehe Abdeckungstabelle unten).
+
+## Abdeckungstabelle (Schritt 0b/0c)
+
+Einstufung je Inventarzeile (`tief | mittel | flach | nicht analysiert`) und Anzahl der daraus erzeugten Anforderungen (über alle drei Ebenen StRS+SyRS+SwRS gezählt, inkl. gemeinsam genutzter übergeordneter Anforderungen).
+
+| # | Modul/Komponente | Einstufung | Anzahl Anforderungen |
+|---|---|---|---|
+| A01 | Administration (Rechte, Mandant, DSGVO, Settings) | tief | 13 |
+| A02 | ArtificialIntelligence | mittel | 3 |
+| A03 | Calendar | flach | 1 |
+| A04 | Dashboard | flach | 1 |
+| A05 | DataExchange | mittel | 10 |
+| A06 | ExternalTool | flach | 1 |
+| A07 | Finances | tief | 28 |
+| A08 | Global | flach | 2 |
+| A09 | Gui | flach | 1 |
+| A10 | Helpdesk | tief | 9 |
+| A11 | Logistic | mittel | 2 |
+| A12 | Massenupdates | mittel | 3 |
+| A13 | MyCentron | mittel | 6 |
+| A14 | OnlineBanking | mittel | 5 |
+| A15 | PLM | mittel | 3 |
+| A16 | PasswordManager | tief | 7 |
+| A17 | PayersAndCostCenter | mittel | 3 |
+| A18 | Production | mittel | 3 |
+| A19 | ProjectManagement | flach | 1 |
+| A20 | ProjectPriceImport | mittel | 3 |
+| A21 | Purchasing | tief | 9 |
+| A22 | QM | mittel | 3 |
+| A23 | Reports | flach | 1 |
+| A24 | Rma | tief | 6 |
+| A25 | Sales | mittel | 3 |
+| A26 | Statistics | mittel | 4 |
+| A27 | Survey | mittel | 3 |
+| A28 | TelekomDive | flach | 1 |
+| A29 | Warehousing | tief | 14 |
+| A30 | SearchArticle/SupplierSearch | flach | 2 (geteilt mit A29) |
+| B01 | Centron.BL | mittel* | 1 dediziert (*als Belegquelle in > 30 weiteren Anforderungen zitiert) |
+| B02 | Centron.DAO | flach | 2 |
+| B03 | Centron.Entities | flach | 1 |
+| B04 | Centron.Common | flach | 1 |
+| B05 | Centron.Gateway | mittel | 2 dediziert (+ SEPA-Beleg unter A05/A07) |
+| B06 | Centron.Interfaces | flach | 2 (als Belegquelle mehrfach zitiert) |
+| B07 | Centron.APIs.CopDataAccess | flach | 1 |
+| B08 | Centron.APIs.EgisDataAccess | flach | 1 |
+| B09 | Centron.APIs.FinAPI | flach | 1 |
+| B10 | Centron.APIs.ITscopeDataAccess | flach | 1 |
+| B11 | Centron.APIs.IcecatDataAccess | flach | 1 |
+| B12 | Centron.Api.EbInterface | flach | 1 |
+| B13 | Centron.Api.Gls | mittel | 2 |
+| B14 | Centron.Api.Shipcloud | flach | 1 |
+| B15 | Centron.Api.docuFORM | flach | 1 |
+| B16 | Centron Webservice (Host/Controllers) | tief | 5 |
+| B17 | Centron.WebServices.Core | flach | 1 |
+| B18 | c-entron.misc.ConnectionManager | flach | 1 |
+| B19 | CentronNexus | mittel | 3 |
+| B20 | CentronNexus.OutlookAddIn | mittel | 3 |
+| B21 | Centron.Controls | flach | 1 |
+| B22 | Centron.Core | flach | 1 |
+
+**Zusammenfassung:** 8 Module `tief`, 19 Module `mittel`, 25 Module `flach`, **0 Module `nicht analysiert`**. Jede der 52 Inventarzeilen trägt mindestens eine belegte Anforderung — die Mindestabdeckung aus Schritt 0b ist vollständig erreicht.
+
+## Konsistenzcheck
+
+- **Doppelte oder mehrfach vergebene IDs:** Keine gefunden. StRS-001…042, SyRS-001…044 und SwRS-001…094/096…100 (SwRS-095 wurde bei der Nachvertiefung bewusst nicht vergeben, um die Reihenfolge nicht zu verwürfeln — siehe Hinweis unten) sind je genau einmal vergeben.
+- **Anforderungen ohne Beleg:** Keine gefunden. Jede der 185 Anforderungen (42 StRS + 44 SyRS + 99 SwRS) trägt mindestens einen klassifizierten Beleg.
+- **Anforderungen ohne Angabe zur Übernahmewürdigkeit:** Keine gefunden. Jede Anforderung trägt eine der vier Einstufungen mit Kurzbegründung.
+- **Tracelinks auf nicht existierende IDs:** Stichprobenartig und für alle Sammel-Tracelinks der StRS-/SyRS-Ebene (siehe Traceability.md) geprüft — alle referenzierten IDs existieren. Eine vollständige automatisierte Prüfung aller Einzel-Tracelinks in jedem der 185 Blöcke wurde nicht durchgeführt; das Risiko wird als gering eingeschätzt, da IDs fortlaufend beim Schreiben vergeben wurden.
+- **Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsvermerk:** Neun Konsolidierungskandidaten wurden identifiziert und im jeweiligen Feld `Konsolidierung` vermerkt: externe Produktdatenquellen (StRS-026, SwRS-096, SwRS-097), Versanddienstleister-Anbindungen (StRS-027), Sonderpreis-Import-Varianten (StRS-040, SwRS-075), Logistik-/RMA-Versandkonfiguration (SwRS-067), Kommissionierungskonzepte Beta vs. bestehend (SwRS-079), D!VE-Export (SwRS-086) und FiBu-Exportadapter (SwRS-089). Über diese hinaus wurden bei der Durchsicht keine weiteren fachlich deckungsgleichen, nicht markierten Anforderungen gefunden.
+- **Liste aller risikorelevanten Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit Belegsituation:**
+
+| ID | Titel | PRIMÄR-Beleg vorhanden? | Falls nein: [HYPOTHESE]? |
+|---|---|---|---|
+| StRS-001 | Mahnwesen für überfällige Kundenrechnungen | ja | – |
+| StRS-002 | OPOS-Auswertung | ja | – |
+| StRS-003 | Automatisierte Vertragsabrechnung | ja | – |
+| StRS-004 | Kontrollierte Stornierung von Rechnungen | ja | – |
+| StRS-005 | Zahlungseingangsverwaltung | ja | – |
+| StRS-006 | Vertragslaufzeit/Kündigung | ja | – |
+| StRS-007 | Abrechnung Ticketzeiten/Pauschalprojekte | ja | – |
+| StRS-008 | Sichere Verwaltung von Kundenzugangsdaten | ja | – |
+| StRS-009 | Richtlinienbasierte Rechtevergabe PasswordManager | ja | – |
+| StRS-010 | Rollen-/rechtebasierte Zugriffssteuerung | ja | – |
+| StRS-011 | Mandantenfähigkeit / Datenisolation | nein (nur für Nummernkreis) | ja, siehe Hypothesen.md |
+| StRS-012 | DSGVO-Löschung | nein (nur UI-Fakt) | ja, siehe Hypothesen.md |
+| StRS-013 | Sichere Authentifizierung | ja | – |
+| StRS-014 | Lizenzgesteuerte Freischaltung | ja | – |
+| SwRS-009/010 | Zahlungsverbuchung: Storno-Schutz/Rechteausnahme | ja | – |
+| SwRS-013 | Rechteprüfung vor Zeiterfassungs-Speicherung | ja | – |
+| SwRS-014/015/016 | PasswordManager Flag-Steuerung/Guideline-Scoping/Clipboard | ja | – |
+| SwRS-017/018 | Modul-Rechteausdruck/Rechte-Caching | ja | – |
+| SwRS-021/022 | AD-Authentifizierung/Ticket-Claims | ja | – |
+| SwRS-030 | Doppelte Rechteprüfung Artikelverwaltung | ja | – |
+| SwRS-041 | Hartkodiertes GLS-Secret (Sicherheitsbefund) | ja | – |
+| SwRS-099 | Klartext-Secrets in Docker-Beispielkonfiguration (Sicherheitsbefund) | ja | – |
+
+Alle risikorelevanten Anforderungen sind entweder mit einem `PRIMÄR`-Beleg gedeckt oder – wenn kein solcher Beleg auffindbar war – explizit als `[HYPOTHESE]` gekennzeichnet (StRS-011, StRS-012 und ihre jeweiligen SyRS-/SwRS-Ableitungen). Kein risikorelevanter Punkt bleibt ohne Kennzeichnung.
+
+- **Abgleich Hypothesen.md gegen Inline-Markierungen:** Deckungsgleich. Alle zehn mit `Status: HYPOTHESE` markierten Anforderungen (StRS-011, StRS-012, StRS-016, SyRS-013, SyRS-019, SwRS-019, SwRS-020, SwRS-076, SwRS-083, SwRS-089) sind in Hypothesen.md mit ihrer offenen Frage aufgeführt; Hypothesen.md enthält keine zusätzlichen, anforderungslosen Fragen.
+
+## Selbstbewertung
+
+**Tiefe der Analyse:** Von den 52 Inventarzeilen wurden 8 `tief` (Finances, Administration, Helpdesk, PasswordManager, Purchasing, Rma, Warehousing, Webservice-Host), 19 `mittel` und 25 `flach` analysiert; kein Modul blieb ohne Anforderung (`nicht analysiert` = 0). Die Tiefenverteilung folgt bewusst der in Schritt 0c geforderten Risikopriorisierung: Sicherheits-, Abrechnungs-/Fakturierungs- und Berechtigungslogik wurden mit sechs parallel arbeitenden Vertiefungsrecherchen (siehe Vorgehen unten) am gründlichsten untersucht, während rein konfigurative oder wenig risikobehaftete Module (z. B. Calendar, Dashboard, Gui, Reports) bewusst mit geringerer Tiefe, aber nicht ohne jede Anforderung geführt wurden.
+
+**Mindestabdeckung erreicht:** Ja. Jede der 52 Inventarzeilen trägt mindestens eine belegte Anforderung mit direktem Artefaktbezug in den Pfad der jeweiligen Komponente.
+
+**Dünne Beleglage:** Am dünnsten belegt sind die 25 `flach` eingestuften Module — dort wurde in der Regel genau eine Datei geöffnet und ein charakteristischer Fakt daraus gezogen, ohne die volle Breite des jeweiligen Unterordners zu prüfen (z. B. B03 Centron.Entities: von ca. 1185 Klassen wurde keine einzelne inhaltlich geprüft, nur die Architekturaussage über die Gesamtstruktur belegt). Der Anteil `SEKUNDÄR`/`KONTEXT`-Belege ist in den Modulen DataExchange (mehrere Exportadapter nur über Ordnerstruktur belegt, SwRS-089), ProjectManagement (SwRS-072) und den externen Marktplatzintegrationen (Sales, SwRS-076) am höchsten.
+
+**Hypothesenquote:** 10 von 185 Anforderungen (5,4 %) sind als Hypothese markiert. Dieser vergleichsweise niedrige Wert ist kein Zeichen einer erschöpfenden, lückenlosen Analyse der gesamten Codebasis — bei einer Codebasis dieser Größe (> 150 Unterordner allein in der WPF-UI, ~1185 Entitätsklassen, 44 Solution-Projekte) ist das nicht plausibel. Er erklärt sich vielmehr daraus, dass die sechs Vertiefungsrecherchen gezielt auf die Bereiche mit der höchsten Risikoklassifizierung (Finances, PasswordManager/Administration/Security, Helpdesk/Rma, Warehousing/Purchasing) konzentriert wurden und dort überwiegend eindeutige, direkt im Code sichtbare Fakten fanden; in den `flach` eingestuften Bereichen wurde entsprechend der Weisung „ohne Beleg keine Anforderung" jeweils nur eine einzelne, tatsächlich belegbare Aussage geschrieben, statt spekulativ weitere, unbelegte Aussagen als Hypothese zu formulieren. Die tatsächliche Zahl offener Punkte in der Gesamtcodebasis liegt mit hoher Wahrscheinlichkeit deutlich höher als die hier dokumentierten zehn Fälle — siehe „Empfehlung Folgeiteration" unten.
+
+**Empfehlung für eine Folge-Iteration:**
+1. Die 25 `flach` eingestuften Module (insbesondere B03 Centron.Entities, B06 Centron.Interfaces sowie die sechs bislang nur oberflächlich geöffneten FiBu-Exportadapter in Centron.Gateway) sollten in einer weiteren Vertiefungsrunde mit dediziertem Recherche-Fokus behandelt werden.
+2. Die DSGVO-Backend-Implementierung (`IDataSecurityLogic`) und die tatsächliche Datenisolation zwischen Mandanten (StRS-011/StRS-012) sollten vorrangig geklärt werden, da beide Punkte unmittelbar regulatorische bzw. sicherheitsrelevante Konsequenzen haben.
+3. Die vollständige Analyse des Datenbankschemas (`SSMS_DB_SCHEMA.sql`, ca. 3,3 MB) wurde in dieser Iteration nicht systematisch durchgeführt — DB-Constraints wurden nur dort zitiert, wo sie im Rahmen der WPF-/BL-Recherche zufällig sichtbar wurden (z. B. `cvw_InvoiceDunnings`-Sicht). Eine dedizierte Analyse des Schemas könnte zusätzliche `PRIMÄR`-Belege für bislang nur `SEKUNDÄR` gedeckte Datenregeln liefern.
+4. Die im Code selbst als „(obsolate)" bzw. „Beta" markierten Bereiche (PasswordManager, Commissioning) benötigen eine explizite Abstimmung mit dem Fachbereich, ob und in welcher Form sie in die Neuimplementierung übernommen werden.
+5. Die in dieser Iteration nur mit einer einzelnen Anforderung geführten, aber im Code auffällig gewordenen Wartbarkeitsbefunde (hartkodierte IDs/Abteilungsnamen in ProjectManagement, SwRS-072; unbegrenzte Seitengröße in der Lieferantensuche, SwRS-082) sollten in der Migrationsplanung als konkrete Technical-Debt-Posten aufgenommen werden.
+
+**Hinweis zur ID-Vergabe:** Bei der nachträglichen Ergänzung dreier SwRS-Anforderungen zu bislang unbelegten externen API-Anbindungen (COP, ITscope, ebInterface) wurde die fortlaufende ID SwRS-095 bewusst durch SwRS-096–098 ersetzt und die ursprünglich als SwRS-095 geführte Anforderung zu Docker-Secrets auf SwRS-099 umnummeriert, um die aufsteigende Reihenfolge in der Datei zu erhalten; eine weitere Ergänzung (finAPI) wurde konsequent als SwRS-100 angehängt. Dies erklärt die Lücke bei der Nummer 095 in der Zählung „SwRS-001…094, 096…100" und ist keine fehlende oder doppelt vergebene ID.

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048/Ergebnisse/Glossar.md

@@ -0,0 +1,34 @@
+# Glossar
+
+Domänenbegriffe, wie sie in den Anforderungen (StRS/SyRS/SwRS) dieser Analyse verwendet werden. Deutsche Fachbegriffe der c-entron-Codebasis wurden übernommen; technische Bezeichner (Klassen, Methoden, Spalten) sind im Original belassen.
+
+| Begriff | Bedeutung |
+|---|---|
+| **Mandant** | Rechtliche/organisatorische Einheit innerhalb einer c-entron-Installation (z. B. eigenständige Firma einer Unternehmensgruppe). Steuert laut Codebefund primär Briefkopf, Bankverbindungen und Belegnummernkreise je Filiale, **nicht** nachweislich eine Datenisolation zwischen Mandanten (siehe Hypothese H-013). |
+| **Filiale (Branch)** | Organisatorische Unterstruktur eines Mandanten; referenziert `MandatorI3D`. Steuert u. a. Belegnummernkreise und Sichtbarkeitseinschränkungen ("nur eigene Filiale"). |
+| **Beleg (Receipt)** | Sammelbegriff für alle Geschäftsdokumente (Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Vertrag, Abholschein) mit gemeinsamem Zustandsmodell `ReceiptState` (`Active`/`Completed`/`Canceled`). |
+| **Ticket (Helpdesk)** | Vorgang im Kundenservice-Modul Helpdesk; Status ist vollständig admin-konfigurierbar (`HelpdeskStatusDTO`), es existiert keine feste Statusenumeration im Code. |
+| **RMA** | "Return Merchandise Authorization" – Retourenvorgang für defekte/zu tauschende Artikel, 1:1 an ein Helpdesk-Ticket gekoppelt (`HelpdeskI3D`). |
+| **SendBack / SendForth** | Zwei Teilschritte eines RMA-Vorgangs: SendBack = Versand des Artikels vom Kunden/c-entron zum Lieferanten; SendForth = Eingang der Lösung (Reparatur, Austausch, Verschrottung) vom Lieferanten zurück. |
+| **Stammblatt (Master Data List)** | Geräte-/Anlagen-Stammdatensatz (z. B. Drucker mit Zählerstand), der über `DeviceToContract` mit Verträgen verknüpft ist und Basis für Klickzähler-Abrechnung ist. |
+| **Asset** | Allgemeiner Hardware-Vermögensgegenstand außerhalb der Stammblatt-Verwaltung; laut Auftrag im Zielsystem mit Stammblättern zu einem einheitlichen Asset-Konzept zusammenzuführen (Konsolidierungskandidat). |
+| **Mahnung (Dunning)** | Erinnerungs-/Eskalationsprozess für überfällige Rechnungen mit Stufen `None → Level1 → Level2 → Level3`. |
+| **OPOS** | "Offene Posten" – reine Auswertung/Auszug offener Rechnungsbeträge; im Unterschied zur Mahnung schreibfrei (keine Zustandsänderung an der Rechnung). |
+| **Kontingent (Contingent)** | Im Vertrag vereinbartes Mengen- oder Zeitbudget (`Booked + TakeOver - Used = Rest`), das über Rechnungen/Leistungen abgebaut wird. |
+| **Klickzähler (Device Click Counter)** | Zählerstand eines Endgeräts (z. B. Drucker), der automatisiert in die Vertragsabrechnung (`AutomaticFacturaBL`) einfließt. |
+| **BVL (Bestellvorschlagsliste)** | Order Suggestion List – berechnet Nachbestellmengen aus Bestand, offenen Bestellungen und Mindestbestand. |
+| **EDI** | Electronic Data Interchange – automatisierter Belegaustausch (Auftragsbestätigung, Lieferschein, Rechnung, ZUGFeRD) mit Lieferanten/Distributoren. |
+| **ZUGFeRD** | Deutscher/europäischer Standard für strukturierte E-Rechnungen (XML in PDF eingebettet), im System sowohl importierbar (EDI-Eingang) als auch exportierbar. |
+| **Recht (User Right)** | Ganzzahlige ID (`UserRightsConst.*`), die eine Berechtigung referenziert; Prüfung erfolgt clientseitig gegen `CentronCache.Instance.CurrentUserAppRights` und/oder serverseitig gegen `AppRightsBL.CheckRightsFromUser`. |
+| **Einschränkendes Recht (Restricting Right)** | Sonderform eines Rechts, das den Sichtbereich eines bereits vorhandenen Rechts einschränkt (z. B. "nur eigene Tickets", "nur eigene Filiale") statt eine Fähigkeit freizuschalten. |
+| **Zugangsbereich (Access Area)** | Im PasswordManager definierte Kategorie von Zugangsdaten (z. B. VPN, RDP, SSH) mit konfigurierbaren benutzerdefinierten Feldern. |
+| **Richtlinie (Guideline, PasswordManager)** | Regelwerk, das einem Mitarbeiter/einer Abteilung über `PasswordManagerGuidelineRights` (Flags-Enum) feingranulare Rechte auf Zugangsdaten eines bestimmten Kunden gewährt, optional zeitlich befristet. |
+| **Siegel (Seal, PasswordManager)** | Zugriffsschutzmechanismus auf einzelne Zugangsdaten; "Siegelbruch" (SealBreak) protokolliert den bewussten Zugriff auf versiegelte Daten. |
+| **Lizenz (License)** | GUID-basiertes Freischaltmerkmal für Anwendungen oder Einzelfunktionen, geprüft über `LicenseManager.Instance.HasLicense(...)`; kann zusätzlich `count`, `valid until date/version` tragen. |
+| **Ticket (Auth-Ticket)** | Server-ausgestelltes Sitzungstoken nach erfolgreichem Login, validiert durch `AuthenticationTicketBL`/`TicketAuthenticationHandler` bei jedem Webservice-Aufruf – nicht zu verwechseln mit einem Helpdesk-Ticket. |
+| **c-entron Nexus** | Separate ASP.NET-Core-Blazor-Webanwendung ("ServiceBoard", Kunden-Self-Service, WebCart), die den Webservice über ein gemeinsames Secret ("SecretKey") und JWT als Client konsumiert. |
+| **WebCart** | Im c-entron Nexus enthaltene Bestellfunktion für Kunden auf Basis ihrer hinterlegten Sonderpreise ("Sonderpreise"). |
+| **Sonderpreis (Special Agreement)** | Kundenindividuell vereinbarter Artikelpreis, der auch die Bestandsreservierung (`SpecialAgreementQuantity`) getrennt vom allgemeinen Bestand führt. |
+| **c-entron.NET** | Der WPF-Desktop-Client der Anwendung (Alt-Bezeichnung im Unterschied zu Nexus). |
+| **I3D** | Primärschlüssel-Namenskonvention der Codebasis (Integer-ID) für praktisch alle Entitäten, z. B. `ArticleI3D`, `HelpdeskI3D`. |
+| **BL / DAO / WS (Architekturschichten)** | `BL` = direkte Datenbank-Businesslogik (NHibernate), `DAO` = Datenzugriffsschicht, `WS`/`WebServiceBL` = Zugriff über den Webservice; ein Modul implementiert i. d. R. beide Pfade hinter einer gemeinsamen `ILogic`-Schnittstelle (Dual-Implementation-Pattern, siehe SwRS zur Architektur). |

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048/Ergebnisse/Hypothesen.md

@@ -0,0 +1,37 @@
+# Hypothesen
+
+Sammlung aller mit `[HYPOTHESE]` bzw. `Status: HYPOTHESE` markierten Anforderungen. Diese Liste ist deckungsgleich mit den Inline-Markierungen in StRS.md, SyRS.md und SwRS.md (siehe Konsistenzcheck in Analysebericht.md) und enthält ausschließlich Anforderungen — keine freien, anforderungslosen Fragen (diese stehen in der Selbstbewertung).
+
+Insgesamt **10 von 184 Anforderungen (5,4 %)** sind als Hypothese markiert. Das ist niedrig für eine Codebasis dieser Größe; eine Begründung dafür liefert die Selbstbewertung in Analysebericht.md (Kurzfassung: die Analyse ist bewusst auf wenige, durch sechs parallele Vertiefungsrecherchen intensiv untersuchte Risikobereiche fokussiert, in denen die Beleglage überwiegend eindeutig war — nicht analysierte Bereiche wurden konsequent als "flach" bzw. mit Einzelanforderung geführt statt spekulativ mit Hypothesen aufgefüllt).
+
+---
+
+### StRS-011 — Mandantenfähigkeit für Briefkopf, Bankverbindung und Belegnummernkreise
+**Offene Frage:** Es konnte keine Stelle im Code gefunden werden, die Geschäftsdaten (Kunden, Belege, Tickets) nach dem Mandanten des angemeldeten Benutzers filtert. Die einzige gefundene mandantenbezogene Fachlogik betrifft Nummernkreise (`MandatoryBL.GetNumberGroup`). **Zur Bestätigung fehlt:** Auskunft des Fachbereichs bzw. der Entwickler, ob "Mandant" bewusst nur als Konfigurationskonstrukt (Briefkopf/Bank/Nummernkreis) ohne Datenisolation gedacht ist, oder ob eine Datentrennung an anderer, nicht eingesehener Stelle (z. B. serverseitige Query-Filter, die im untersuchten Codeausschnitt nicht auftauchten) existiert.
+
+### StRS-012 — DSGVO-konforme Löschung und Anonymisierung personenbezogener Daten
+**Offene Frage:** Die Backend-Implementierung von `IDataSecurityLogic.DsgvoDeleteRightDeleteContacts` und `DataSecurityExecuteCleanUpAsync` wurde im Rahmen dieser Analyse nicht aufgefunden (nur die aufrufende WPF-Schicht wurde gelesen). **Zur Bestätigung fehlt:** Lesen der tatsächlichen Backend-Methoden, um zu klären, ob Hard-Delete oder Anonymisierung erfolgt und ob die Löschung auf verknüpfte Belege/Tickets kaskadiert.
+
+### StRS-016 — Fälligkeitsüberwachung von Tickets (SLA-Transparenz ohne automatisierte Eskalation)
+**Offene Frage:** Es wurde keine automatisierte Aktion (Statuswechsel, Neuzuweisung, aktive Benachrichtigung) gefunden, die bei SLA-Verletzung ausgelöst wird — nur eine Dashboard-Anzeige. Ein Modul „EscalationsSettings" existiert, wurde aber nicht bis zur Ebene einer automatisierten Aktion vertieft. **Zur Bestätigung fehlt:** Vertiefte Analyse von `Modules\Administration\EscalationsSettings\EscalationType` sowie der zugehörigen Backend-Klassen, um zu klären, ob dort tatsächlich eine automatisierte Eskalation stattfindet.
+
+### SyRS-013 — Mandantenbezogene Vergabe von Belegnummernkreisen
+**Offene Frage:** Identisch mit StRS-011 — die Fallback-Kette auf den Standardmandanten ist belegt, eine darüber hinausgehende Datenisolation nicht. **Zur Bestätigung fehlt:** siehe StRS-011.
+
+### SyRS-019 — Dashboard-Kennzeichnung SLA-relevanter, fälliger Tickets
+**Offene Frage:** Identisch mit StRS-016 — die Dashboard-Gruppierung ist belegt, eine automatisierte Eskalationsfolge nicht. **Zur Bestätigung fehlt:** siehe StRS-016.
+
+### SwRS-019 — Fallback auf Standardmandant bei fehlender Filialzuordnung
+**Offene Frage:** Identisch mit StRS-011/SyRS-013.
+
+### SwRS-020 — Löschprotokoll als Datei- oder Zwischenablage-Ausgabe nach DSGVO-Löschung
+**Offene Frage:** Identisch mit StRS-012 — nur die UI-seitige Protokollausgabe ist belegt, die tatsächliche Löschmethodik im Backend nicht.
+
+### SwRS-076 — Zeitraumbasierter Datenabruf vom Riverbird-Server
+**Offene Frage:** Das genaue Protokoll und der Anbieter hinter dem in der UI als „Riverbird" bezeichneten Server konnten aus der UI-Schicht (`ReadRiverbirdServerDialogViewModel.cs`) nicht abschließend bestimmt werden. **Zur Bestätigung fehlt:** Analyse der zugehörigen Backend-/Gateway-Klasse (falls vorhanden) oder Rückfrage beim Entwicklungsteam, welcher externe Anbieter sich hinter "Riverbird" verbirgt und welches Protokoll verwendet wird.
+
+### SwRS-083 — Genehmigungspfad für Reisekosten/Auslagen
+**Offene Frage:** Die vollständige Definition des Enums `TransactionStatus` (alle Werte, deren numerische Reihenfolge, ob Übergänge erzwungen werden) wurde nicht geöffnet — nur Verwendungsstellen wurden per Grep bestätigt. **Zur Bestätigung fehlt:** Lesen der Enum-Definition (vermutlich in `Centron.Interfaces` oder `Centron.Entities`) sowie der Backend-Klasse, die Statusübergänge tatsächlich durchsetzt, um zu klären, ob z. B. ein direkter Sprung von "Active" zu "Closed" ohne Genehmigung technisch möglich ist.
+
+### SwRS-089 — Vendorspezifische FiBu-Export-/Importadapter über ein gemeinsames Interface
+**Offene Frage:** Die einzelnen Adapterimplementierungen unter `src/backend/Centron.Gateway/DataExchange/BookKeeping/*` (Addison, Abacus, SAP, Sage, Lexware, Navision) wurden nur über die Ordnerstruktur, nicht im Detail gelesen. **Zur Bestätigung fehlt:** Öffnen mindestens eines konkreten Adapters, um zu verifizieren, dass `IBookKeepingExport`/`IBookKeepingImportDataToCentron` tatsächlich einheitlich implementiert werden und keine adapterspezifischen Sonderregeln außerhalb des Interfaces bestehen.

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048/Ergebnisse/StRS.md

@@ -0,0 +1,870 @@
+# Stakeholder Requirements Specification (StRS)
+
+Fachliche Sicht: Geschäftsziele, Akteure, Prozesse. Ebene: StRS. Belege beziehen sich auf die technische Implementierung, aus der die fachliche Aussage abgeleitet wurde (Reverse Engineering).
+
+---
+
+```
+ID:            StRS-001
+Titel:         Mahnwesen für überfällige Kundenrechnungen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung
+Vorbedingung:  Kundenrechnung ist aktiv (nicht storniert) und die Fälligkeit ist überschritten.
+Fakt:          DunningBL.GenerateInvoiceExpression() selektiert Rechnungen mit State==Active und DueDate<=Today (sofern nicht explizit anders gefiltert); DunningRunBL.UpdateInvoice() führt einen dreistufigen Statuswechsel None→Level1→Level2→Level3 mit Datums-/Bearbeiterstempel je Stufe durch.
+Aussage:       Das System soll überfällige, nicht beglichene Kundenrechnungen erkennen und dem Sachbearbeiter ermöglichen, sie in einem dreistufigen Mahnverfahren mit Nachvollziehbarkeit (Datum, Bearbeiter je Stufe) zu bearbeiten.
+Ergebnis:      Rechnung erhält eine erhöhte Mahnstufe inkl. Datum und ausführendem Mitarbeiter; ein Mahnschreiben kann erzeugt werden.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs, Methode UpdateInvoice - Begründung: Enthält den durchgesetzten switch-Statusautomaten inkl. Stempelung, inklusive throw bei Versuch, über Level3 hinaus zu mahnen.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs, Methode GenerateInvoiceExpression - Begründung: Definiert die Selektionslogik mahnfähiger Rechnungen.
+Prüfidee:      Eine aktive, überfällige Rechnung ohne Mahnstufe wird nach Ausführung des Mahnlaufs auf Level1 mit gesetztem Datum/Bearbeiter geführt; ein erneuter Lauf auf einer Level3-Rechnung schlägt fehl (keine Level4).
+Tracelinks:    SyRS-001, SyRS-002, SwRS-001, SwRS-002, SwRS-003
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernprozess der Debitorenbuchhaltung, im Zielsystem weiterhin zwingend erforderlich.
+Status:        belegt
+```
+
+```
+ID:            StRS-002
+Titel:         Auswertung offener Posten (OPOS) getrennt vom Mahnwesen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung
+Vorbedingung:  Offene Rechnungen/Gutschriften liegen vor.
+Fakt:          OposRunBL.ExecuteOposRun() erzeugt einen Kontoauszug-Report, verändert aber im Unterschied zu DunningRunBL keinen Rechnungszustand (kein Level-Update, keine Transaktionsklammer für Statusänderung) - reine Leseauswertung. OposBL.ThrowIfUserHasInsufficentRights() prüft dasselbe Recht (UserRightsConst.Controlling.Finances.Dunning), es existiert keine eigene UserRightsConst.Opos-Konstante.
+Aussage:       Das System soll eine reine Lese-Auswertung der offenen Posten je Kunde (Kontoauszug) bereitstellen, die unabhängig vom Mahnstatus einer Rechnung ist und keine Zustandsänderung an den Rechnungen vornimmt.
+Ergebnis:      PDF-Kontoauszug mit allen offenen Beträgen des Kunden, ohne Nebenwirkung auf Mahnstufen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposRunBL.cs, Methode ExecuteOposRun - Begründung: Zeigt, dass OPOS im Gegensatz zu Dunning keine persistente Zustandsänderung vornimmt (reine Reportgenerierung).
+  - [KONTEXT]  src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposBL.cs, Methode ThrowIfUserHasInsufficentRights - Begründung: Belegt die gemeinsame Rechtenutzung mit Dunning als fachliche Randbedingung (siehe Hypothese).
+Prüfidee:      Ausführen eines OPOS-Laufs für eine Rechnung verändert deren DunningLevel nicht.
+Tracelinks:    StRS-001, SyRS-003, SwRS-004
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - eigenständiger Auswertungsbedarf unabhängig vom Mahnwesen.
+Status:        belegt
+```
+
+```
+ID:            StRS-003
+Titel:         Automatisierte Vertragsabrechnung (Facturierung)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung / Vertragsmanagement
+Vorbedingung:  Ein aktiver Vertrag (VertragKopf, Status=1) mit definiertem Abrechnungsintervall liegt vor.
+Fakt:          AutomaticFacturaBL.Contracts.cs, Methode StoreInvoiceToContract() verknüpft eine erzeugte Rechnung über die Tabelle VertragRechKopfZuordnung mit dem Vertrag und plant für automatische Abrechnungsverträge (ContractCalculationKind.Auto) die nächste Abrechnung als ToDo anhand von BillingIntervalKind/-Duration.
+Aussage:       Das System soll Verträge mit wiederkehrendem Abrechnungsintervall automatisiert zu Rechnungen verarbeiten und die jeweils nächste Abrechnung terminieren, ohne dass ein Sachbearbeiter jeden Abrechnungslauf manuell anstoßen muss.
+Ergebnis:      Neue Rechnung mit Verknüpfung zum Vertrag; Folgetermin für die nächste Abrechnung ist hinterlegt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, Methode StoreInvoiceToContract - Begründung: Enthält die konkrete Verknüpfungs- und Terminierungslogik für automatisch abgerechnete Verträge.
+Prüfidee:      Ein Vertrag mit ContractCalculationKind.Auto und monatlichem Intervall erzeugt nach Abrechnung einen Folgetermin ca. einen Monat später.
+Tracelinks:    SyRS-004, SwRS-005, SwRS-006
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrale Umsatzquelle für Vertragsgeschäft (MSP/Service).
+Status:        belegt
+```
+
+```
+ID:            StRS-004
+Titel:         Kontrollierte Stornierung von Rechnungen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung
+Vorbedingung:  Eine aktive, nicht bereits stornierte Rechnung liegt vor.
+Fakt:          ReceiptInvoiceBL.CancelInvoice() prüft nacheinander sechs Bedingungen (Recht RIGHT_RECHNUNGSTORNIEREN, nicht bereits storniert, keine Barrechnung, nicht weiterverarbeitet, nicht bereits FiBu-exportiert, bei Vertragsrechnung: letzte Rechnung des Vertrags) und bricht bei Verletzung jeder einzelnen mit einer spezifischen Fehlermeldung ab.
+Aussage:       Das System soll die Stornierung einer Rechnung nur zulassen, wenn keine der sechs geschäftskritischen Ausschlussbedingungen (fehlendes Recht, bereits storniert, Barverkauf, bereits weiterverarbeitet, bereits exportiert, nicht letzte Vertragsrechnung) zutrifft, und dies dem Anwender mit konkreter Begründung mitteilen.
+Ergebnis:      Neue, als "storniert" markierte Rechnungsversion; Artikelmengen werden auf null gesetzt; Vorgang wird protokolliert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs, Methode CancelInvoice - Begründung: Enthält alle sechs geprüften Bedingungen im Klartext inkl. der jeweiligen Fehlermeldung und des Rechts RIGHT_RECHNUNGSTORNIEREN (ID 20400101).
+Prüfidee:      Der Stornoversuch einer bereits an die Finanzbuchhaltung exportierten Rechnung wird mit der Meldung "...bereits exportiert..." verweigert.
+Tracelinks:    SyRS-005, SwRS-007, SwRS-008
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - regulatorisch/prozessual zwingende Kontrolle für Rechnungskorrekturen.
+Status:        belegt
+```
+
+```
+ID:            StRS-005
+Titel:         Verwaltung von Zahlungseingängen und deren Verknüpfung zu Rechnungen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung
+Vorbedingung:  Ein Zahlungseingang wurde erfasst oder aus dem Online-Banking-Abgleich zugeordnet.
+Fakt:          ReceiptBL.UpdateReceiptIsPaid() ist die zentrale, von PaymentsBL und dem OnlineBanking-Abgleich gemeinsam genutzte Methode; sie verweigert Zahlungsverbuchung/-stornierung auf stornierten Belegen und nutzt eine GUID-basierte optimistische Sperre (ConcurrencyControlGuid).
+Aussage:       Das System soll Zahlungseingänge einer Rechnung zuordnen, den bezahlten Betrag nachführen und dabei sicherstellen, dass stornierte Belege niemals als (un-)bezahlt markiert werden können und gleichzeitige Änderungen erkannt werden.
+Ergebnis:      Rechnung wechselt bei vollständiger Zahlung von "Active" zu "Completed"; bei Rückbuchung eines Zahlungseingangs wird der bezahlte Betrag korrekt reduziert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Methode UpdateReceiptIsPaid - Begründung: Enthält den Storno-Ausschluss, die Concurrency-Prüfung und den Statuswechsel als durchgesetzten Code.
+  - [PRIMÄR]   src/backend/Centron.BL/Finances/Payments/PaymentsBL.cs, Methode DeleteIncomingPayment - Begründung: Belegt die Rechteprüfung (INCOMING_PAYMENT_TRANSACTIONS, ID 10980) vor Löschung eines Zahlungseingangs.
+Prüfidee:      Der Versuch, eine stornierte Rechnung als bezahlt zu markieren, wird mit einer Fehlermeldung abgelehnt.
+Tracelinks:    SyRS-006, SwRS-009, SwRS-010
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernbestandteil der Debitorenbuchhaltung.
+Status:        belegt
+```
+
+```
+ID:            StRS-006
+Titel:         Vertragsverwaltung mit Laufzeit- und Kündigungslogik
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertragsmanagement
+Vorbedingung:  Ein Vertrag mit Beginn, Laufzeitart und -dauer ist angelegt.
+Fakt:          ContractBL.RefreshContractEndeDate() berechnet das Vertragsende aus Beginn/Laufzeitart/-dauer, berücksichtigt automatische Verlängerung (AutoVerlaengerung) sowie Kündigungsfristen (KuendigungsFristArt1/-Dauer1); Verträge mit unvollständigen Basisdaten werden übersprungen statt den gesamten Batchlauf abzubrechen.
+Aussage:       Das System soll das Vertragsende automatisch aus Laufzeitregeln und ggf. hinterlegter Kündigung mit Fristenberechnung ermitteln und dabei einzelne unvollständig gepflegte Verträge von der Berechnung ausnehmen, ohne den Gesamtlauf zu gefährden.
+Ergebnis:      Aktualisiertes Vertragsenddatum je Vertrag; unvollständige Verträge werden zur Nachpflege markiert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs, Methode RefreshContractEndeDate - Begründung: Enthält die tatsächliche Berechnungslogik inkl. Skip-Verhalten bei unvollständigen Daten.
+Prüfidee:      Ein Vertrag mit AutoVerlaengerung=1 ohne Kündigung bleibt nach Ablauf der ersten Laufzeit ohne Enddatum (offen); ein gekündigter Vertrag erhält ein Enddatum unter Berücksichtigung der Kündigungsfrist.
+Tracelinks:    SyRS-007, SwRS-011
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - vertragsrechtlich erforderliche Logik.
+Status:        belegt
+```
+
+```
+ID:            StRS-007
+Titel:         Abrechnung erfasster Ticketzeiten und Pauschalprojekte
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung / Serviceleitung
+Vorbedingung:  Zeiterfassungen (Timer) an einem Helpdesk-Ticket liegen vor, oder ein Auftrag mit Pauschal-Materialgruppenpositionen ist vorhanden.
+Fakt:          TimerBillingBL.SaveTimer() lehnt Zeiterfassungen mit Enddatum vor Startdatum hart ab ("negative Dauer"); FlatRateProjectViewModel berechnet den Pauschalbetrag als Summe aus Price*QuantityDisplay über alle Top-Level-Positionen mit BlanketMaterialGroup.
+Aussage:       Das System soll erfasste Ticketzeiten validiert (keine negative Dauer) zu Rechnungen verdichten und alternativ Aufträge mit pauschal abzurechnenden Positionen (Blanket-Materialgruppen) als Gesamtsumme abrechnen können.
+Ergebnis:      Rechnung mit verdichteten Zeitpositionen bzw. Pauschalbetrag.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs, Methode SaveTimer - Begründung: Enthält die harte Validierung negativer Zeitdauer als ResultException.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/FlatrateBilling/FlatRateProjectViewModel.cs, Zeile ~898 - Begründung: Zeigt die konkrete Summenformel für Pauschalabrechnung.
+Prüfidee:      Eine Zeiterfassung mit Stop < Start wird beim Speichern mit einer Fehlermeldung abgelehnt.
+Tracelinks:    SyRS-008, SwRS-012, SwRS-013
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrale Abrechnungsform für Servicegeschäft.
+Status:        belegt
+```
+
+```
+ID:            StRS-008
+Titel:         Sichere Verwaltung von Kundenzugangsdaten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Hotline-/Support-Mitarbeiter, Administrator
+Vorbedingung:  Für einen Kunden sind Zugangsdaten (Passwörter, VPN, RDP, SSH) hinterlegt.
+Fakt:          AccessManagementViewModel prüft je Mitarbeiter über PasswordManagerGuidelineRights (Flags: SealBreak, SealingAllowed, AccessDataEditable, AccessDataVisible, AccessDataDeletable, VPNAccessesEditable, TwoFactorAuthentification, Notification), ob Anzeige/Bearbeitung/Siegelbruch erlaubt ist; jede Aktion erzeugt einen Audit-Log-Eintrag; Zwischenablage wird nach 12 Sekunden automatisch geleert.
+Aussage:       Das System soll den Zugriff auf gespeicherte Kundenzugangsdaten feingranular je Mitarbeiter über Richtlinien steuern (Sichtbarkeit, Bearbeitbarkeit, Siegelbruch, Löschbarkeit getrennt), jede sicherheitsrelevante Aktion protokollieren und eine in die Zwischenablage kopierte Passwortangabe nach kurzer Zeit automatisch entfernen.
+Ergebnis:      Zugriff wird nur im Rahmen der zugewiesenen Rechte gewährt; Audit-Trail ist vollständig.
+Belege:
+  - [PRIMÄR]   src/shared/Centron.Controls/PasswordManager/AccessManagementViewModel.cs, Methode CurrentUserHasRight - Begründung: Zeigt die konkrete Flag-Prüfung je Rechteart.
+  - [PRIMÄR]   src/backend/Centron.Interfaces/PasswordManager/PasswordManagerGuidelineRights.cs - Begründung: Definiert die durchgesetzte Flags-Enumeration der Einzelrechte.
+Prüfidee:      Ein Mitarbeiter ohne GuidelineRightSealBreak kann versiegelte Zugangsdaten nicht einsehen (Kommando ist deaktiviert); nach Kopieren eines Passworts ist die Zwischenablage nach 12 Sekunden leer.
+Tracelinks:    SyRS-009, SyRS-010, SwRS-014, SwRS-015, SwRS-016
+Konsolidierung: nein
+Übernahmewürdigkeit: Sonderfall - Modul ist im Code selbst als "(obsolate)" kommentiert (ModuleRegistration.cs, Zeile 802); Übernahme im Zielsystem ist mit dem Fachbereich zu klären.
+Status:        belegt
+```
+
+```
+ID:            StRS-009
+Titel:         Richtlinienbasierte Rechtevergabe im PasswordManager
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Administrator
+Vorbedingung:  Guideline-Management ist aktiv (IsPasswordManagerGuidelineManagementActive).
+Fakt:          PasswordManagerBL.GetAvailableGuidelinesForEmployee() ermittelt per SQL-Join über PasswordManagerGuidelines/-Employees/-Departments/-Customers/-ExcludedCustomers, welche Kundenkategorien ein Mitarbeiter sehen darf, inkl. optionaler zeitlicher Befristung (LimitedValidityDateFrom/Until). Wird das Guideline-Management deaktiviert, erhalten laut explizitem UI-Warntext alle Mitarbeiter mit dem "Hotline"-Recht uneingeschränkten Zugriff.
+Aussage:       Das System soll den Zugriff auf Kundenzugangsdaten standardmäßig über zeitlich befristbare, kunden- und abteilungsbezogene Richtlinien steuern; wird diese Steuerung deaktiviert, muss dem Administrator explizit mitgeteilt werden, dass dies zu einem uneingeschränkten Zugriff aller Hotline-berechtigten Mitarbeiter führt.
+Ergebnis:      Nur Mitarbeiter mit passender, gültiger Richtlinie sehen die zugehörigen Kundenkategorien.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Methode GetAvailableGuidelinesForEmployee - Begründung: Enthält die tatsächliche, serverseitig durchgesetzte Scoping-Abfrage.
+  - [SEKUNDÄR] src/shared/Centron.Controls/PasswordManager/GuidelineManagementViewModel.cs, Methode ActivateGuidelines - Begründung: Enthält den expliziten Warntext zur Konsequenz einer Deaktivierung.
+Prüfidee:      Ein Mitarbeiter ohne passende Richtlinie für Kunde X sieht dessen Zugangsdatenkategorien nicht in der Liste.
+Tracelinks:    StRS-008, SyRS-009, SwRS-014
+Konsolidierung: nein
+Übernahmewürdigkeit: Sonderfall - siehe StRS-008 (Modul als obsolet markiert).
+Status:        belegt
+```
+
+```
+ID:            StRS-010
+Titel:         Rollen- und rechtebasierte Zugriffssteuerung auf Module und Funktionen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Administrator, alle Systembenutzer
+Vorbedingung:  Benutzer ist eingeloggt; Rechte wurden bei Login einmalig geladen.
+Fakt:          ModuleRegistration.DoRegisterCentronModules() lädt CurrentUserAppRights einmalig pro Session und filtert Module über ModuleRightsExpressionParser (unterstützt AND/OR/NOT über Helper.HasRights/HasAnyRight/NoRightCheck). SettingsContainerViewModel.LoadAllSettings() zeigt jedoch, dass ein Großteil der Administrations-Einstellungsseiten (u. a. CentronConfigDb, ExternalTools, PdfSigning, PhoneSettings, Profiling) nur durch das eine gemeinsame Recht Administration.SETTINGS geschützt ist, ohne seitenindividuelle Rechte.
+Aussage:       Das System soll den Zugriff auf Module grundsätzlich über eine pro Modul konfigurierbare, boolesch kombinierbare Rechteprüfung steuern; für die globale Einstellungsseite ist diese Steuerung jedoch grobgranular auf ein einzelnes Sammelrecht reduziert, was als Migrationsrisiko zu bewerten ist.
+Ergebnis:      Nur berechtigte Module erscheinen im Dashboard/Ribbon; nicht berechtigte Funktionen sind weder sichtbar noch ausführbar.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRightsExpressionParser.cs - Begründung: Enthält die durchgesetzte Auswertungslogik für Rechteausdrücke.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Administration/Settings/SettingsContainerViewModel.cs, Methode LoadAllSettings - Begründung: Belegt die grobgranulare Sammelprüfung für die Einstellungsseiten.
+Prüfidee:      Ein Benutzer ohne Administration.SETTINGS sieht keine der o. g. Einstellungsseiten; ein Benutzer mit diesem einen Recht sieht alle davon, unabhängig von fachlicher Zuständigkeit.
+Tracelinks:    SyRS-011, SyRS-012, SwRS-017, SwRS-018
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - die Sammelrechtsprüfung der Einstellungsseiten ist eine historisch gewachsene Vereinfachung, die im Zielsystem durch granularere Rechte ersetzt werden sollte.
+Status:        belegt
+```
+
+```
+ID:            StRS-011
+Titel:         Mandantenfähigkeit für Briefkopf, Bankverbindung und Belegnummernkreise
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Administrator
+Vorbedingung:  Mehrere Mandanten sind im System angelegt.
+Fakt:          MandatorManagementViewModel verwaltet je Mandant Name, Adresse, bis zu vier Bankverbindungen und Briefkopf-Logos; MandatoryBL vergibt Belegnummernkreise (GetNumberGroup) je Mandant/Filiale mit Fallback auf den Standardmandanten. Es wurde KEINE Stelle gefunden, die Geschäftsdaten (Kunden, Belege) nach dem Mandanten des angemeldeten Benutzers filtert.
+Aussage:       Das System soll je Mandant eigene Briefkopf-, Bank- und Belegnummernkreis-Konfigurationen bereitstellen. [HYPOTHESE: Eine darüberhinausgehende Datenisolation zwischen Mandanten - im Sinne einer Zugriffsbeschränkung auf die dem eigenen Mandanten zugeordneten Geschäftsdaten - konnte im untersuchten Code nicht nachgewiesen werden; es fehlt die Information, ob dies serverseitig an anderer, nicht eingesehener Stelle erfolgt oder ob "Mandant" bewusst nur als Konfigurationskonstrukt ohne Datentrennung gedacht ist.]
+Ergebnis:      Belege tragen mandantenspezifische Nummernkreise und Briefkopfdaten.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Administration/MandatorManagement/MandatorManagementViewModel.cs, Methode DeleteMandatorAsync - Begründung: Zeigt, dass ein Mandant nicht gelöscht, sondern nur deaktiviert werden kann (Status=0), sofern keine aktive Filiale mehr zugeordnet ist.
+  - [KONTEXT]  src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs, Methode GetNumberGroup - Begründung: Einzige gefundene mandantenbezogene Fachlogik (Nummernkreise), kein Hinweis auf Datenisolation.
+Prüfidee:      Zwei Mandanten erzeugen Rechnungen aus unterschiedlichen Nummernkreisen; ein Benutzer, der nur für Mandant A zuständig ist, kann dennoch Kundendaten von Mandant B einsehen (zu verifizieren).
+Tracelinks:    SyRS-013, SwRS-019
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Nummernkreis-/Briefkopftrennung bleibt erforderlich; die Frage der Datenisolation ist vor der Neuimplementierung fachlich zu klären.
+Status:        HYPOTHESE
+```
+
+```
+ID:            StRS-012
+Titel:         DSGVO-konforme Löschung und Anonymisierung personenbezogener Daten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Datenschutzbeauftragter, Administrator
+Vorbedingung:  Personenbezogene Daten (Ansprechpartner, Kundendaten) sind älter als konfigurierte Aufbewahrungsfristen oder eine gezielte Löschanfrage liegt vor.
+Fakt:          CentronDataSecurityViewModel trennt zwei Rechte: HasDatabaseCleanupRight (Massenbereinigung nach Alter, Default-Grenzen z. B. 3/10 Jahre) und HasContactDeleteRight (gezielte Löschung einzelner Kontakte inkl. Exportprotokoll). Die serverseitige Implementierung (IDataSecurityLogic.DsgvoDeleteRightDeleteContacts) wurde im Rahmen dieser Analyse nicht aufgefunden.
+Aussage:       Das System soll sowohl eine alters-/fristbasierte Massenbereinigung als auch eine gezielte, protokollierte Löschung einzelner Kontaktpersonen ermöglichen, jeweils durch ein eigenes Recht geschützt. [HYPOTHESE: Ob die Löschung technisch als Hard-Delete oder Anonymisierung erfolgt und ob sie auf verknüpfte Belege/Tickets kaskadiert, konnte nicht verifiziert werden - die Backend-Implementierung war im analysierten Codeausschnitt nicht auffindbar.]
+Ergebnis:      Personenbezogene Daten werden gemäß Fristen bzw. auf gezielte Anfrage entfernt; ein Löschprotokoll wird angeboten.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Administration/DSGVO/CentronDataSecurityViewModel.cs, Konstruktor (Zeile ~158) - Begründung: Zeigt die getrennte Rechteprüfung für Cleanup vs. gezielte Löschung.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Administration/DSGVO/CentronDataSecurityCustomerViewModel.cs, Methode DoDeleteAsync - Begründung: Zeigt Bestätigungsdialog und Angebot eines Löschprotokolls als UI-Fakt, jedoch ohne Einblick in die tatsächliche Backend-Löschmethodik.
+Prüfidee:      Nach gezielter Löschung eines Kontakts wird ein Löschprotokoll mit Zeitstempel angeboten.
+Tracelinks:    SyRS-014, SwRS-020
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - regulatorisch zwingend (DSGVO Art. 17).
+Status:        HYPOTHESE
+```
+
+```
+ID:            StRS-013
+Titel:         Sichere Authentifizierung am System
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Alle Systembenutzer
+Vorbedingung:  Benutzer meldet sich mit Zugangsdaten oder über einen externen Identitätsanbieter an.
+Fakt:          AuthenticatorFactory wählt je nach konfigurierter SystemAuthenticationMethod zwischen BasicAuthenticator, ActiveDirectoryAuthenticator, WebAccountAuthenticator und OpenIdConnectAuthenticator. BasicAuthenticator vergleicht das Passwort als SHA1Decoder.GetDecodedSHA1String(password) gegen die gespeicherte AppUser.Password-Spalte - unsalted SHA-1, mit explizitem Code-Kommentar "// TODO the password should be salted!!!" (Zeile 48).
+Aussage:       Das System soll Benutzer wahlweise über lokale Zugangsdaten, Active-Directory/LDAP oder OpenID Connect authentifizieren. [HYPOTHESE nicht erforderlich - dies ist ein PRIMÄR belegter, durchgesetzter Zustand:] Für die Basic-Authentifizierung werden Passwörter aktuell als ungesalzener SHA-1-Hash gespeichert und verglichen, was dem Entwicklerteam selbst als Schwachstelle bekannt ist (eigener TODO-Kommentar im Code).
+Ergebnis:      Erfolgreiche Anmeldung erzeugt ein serverseitiges Auth-Ticket; bei BasicAuth besteht ein bekanntes, unbehobenes Sicherheitsrisiko durch fehlendes Salting.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs, Zeile 48 - Begründung: Zeigt sowohl den ungesalzenen SHA-1-Vergleich als auch den Entwickler-eigenen TODO-Kommentar zur bekannten Schwachstelle.
+  - [PRIMÄR]   src/backend/Centron.Common/TextCoding/SHA1Decoder.cs - Begründung: Enthält die tatsächliche Hash-Implementierung (SHA1, hex-codiert, ohne Salt).
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/Auth/AuthenticatorFactory.cs - Begründung: Belegt die Auswahl zwischen den vier Authentifizierungsverfahren.
+Prüfidee:      Zwei Benutzer mit identischem Passwort erzeugen denselben Hashwert in der Datenbank (Nachweis für fehlendes Salting).
+Tracelinks:    SyRS-015, SyRS-016, SwRS-021, SwRS-022
+Konsolidierung: nein
+Übernahmewürdigkeit: veraltet - die Basic-Authentifizierung mit ungesalzenem SHA-1 ist im Zielsystem durch ein modernes, gesalzenes/adaptives Hashverfahren (z. B. bcrypt/Argon2) oder ausschließlich OpenID Connect zu ersetzen.
+Status:        belegt
+```
+
+```
+ID:            StRS-014
+Titel:         Lizenzgesteuerte Freischaltung von Anwendungen und Einzelfunktionen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertrieb, Kunde, Administrator
+Vorbedingung:  Eine Lizenz-GUID ist für den Kunden/die Installation beim Lizenzserver hinterlegt.
+Fakt:          Jede Lizenz ist eine GUID (LicenseGuids.cs) mit optionalem count, valid-until-date und valid-until-version; "Applications" (ApplicationKind.cs) dürfen sich zusätzlich am Webservice anmelden, "Only Licenses" schalten nur einzelne Funktionen/Module frei (LicenseManager.Instance.HasLicense(...)).
+Aussage:       Das System soll Anwendungen und einzelne Funktionen granular über eine GUID-basierte Lizenzprüfung freischalten, wobei Lizenzen zusätzlich mengen- und zeitmäßig begrenzt werden können.
+Ergebnis:      Nicht lizenzierte Module/Funktionen sind weder im Dashboard sichtbar noch nutzbar.
+Belege:
+  - [PRIMÄR]   docs/reference/security/licensing-system.md - Begründung: Entwicklerdokumentation beschreibt den durchgesetzten Mechanismus inkl. Codebeispiel LicenseManager.Instance.HasLicense.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs - Begründung: CheckModuleFeatures() nutzt denselben Mechanismus zur Modulfreischaltung.
+Prüfidee:      Ein Kunde ohne Lizenz LicenseGuids.PasswordManager sieht das Modul PasswordManager nicht im Dashboard.
+Tracelinks:    SyRS-017, SwRS-023
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernbestandteil des Geschäftsmodells (Lizenzverkauf).
+Status:        belegt
+```
+
+```
+ID:            StRS-015
+Titel:         Ticketbearbeitung im Kundenservice (Helpdesk)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Hotline-/Service-Mitarbeiter
+Vorbedingung:  Ein Kundenanliegen liegt vor oder ein Ticket existiert bereits.
+Fakt:          Es existiert keine feste Status-Enumeration; Ticketstatus ist vollständig durch admin-konfigurierbare HelpdeskStatusDTO-Datensätze bestimmt. TicketLogicHelper.GetTicketAndPromptUnlock() implementiert ein pessimistisches Sperrverfahren (TicketIsLocked) mit Anzeige des sperrenden Mitarbeiters und Möglichkeit zum erzwungenen Entsperren.
+Aussage:       Das System soll Tickets mit einem vollständig durch den Administrator konfigurierbaren Statusmodell führen und dabei paralleles Bearbeiten durch Sperrung mit Anzeige des aktuellen Bearbeiters und optionalem Zwangsentsperren verhindern.
+Ergebnis:      Ticket ist eindeutig einem Bearbeiter zugeordnet; Statuswechsel sind nachvollziehbar.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketLogicHelper.cs, Methode GetTicketAndPromptUnlock - Begründung: Enthält das durchgesetzte Sperr-/Entsperrverfahren.
+  - [KONTEXT]  CentronRights.md, Abschnitt Helpdesk - Begründung: Dokumentiert die zugehörigen Rechte in Prosaform als ergänzenden Kontext.
+Prüfidee:      Ein zweiter Mitarbeiter, der ein gesperrtes Ticket öffnet, erhält einen Dialog mit dem Namen des sperrenden Kollegen und die Option zum Entsperren.
+Tracelinks:    SyRS-018, SyRS-019, SwRS-024, SwRS-025
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernprozess des Kundenservice.
+Status:        belegt
+```
+
+```
+ID:            StRS-016
+Titel:         Fälligkeitsüberwachung von Tickets (SLA-Transparenz ohne automatisierte Eskalation)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Serviceleitung, Hotline-Mitarbeiter
+Vorbedingung:  Tickets mit Fälligkeitsdatum (DueDate) und ggf. SLA-Priorität sind offen.
+Fakt:          TicketDueDateDashboardContainerViewModel.CalculateGroups() gruppiert offene Tickets in "Überfällig" (DueDate<Now), "In 4 Stunden" und "Heute", gefiltert nach der Prioritäts-Eigenschaft IsSLA. Es wurde KEINE automatisierte Aktion (Statuswechsel, Neuzuweisung, Benachrichtigung) gefunden, die bei Fälligkeitsüberschreitung ausgelöst wird - lediglich eine Dashboard-Anzeige.
+Aussage:       Das System soll fällige und überfällige SLA-relevante Tickets in einem Dashboard sichtbar machen. [HYPOTHESE: Eine automatisierte Eskalationslogik (Statuswechsel, Reassignment, aktive Benachrichtigung bei SLA-Verletzung) konnte im untersuchten Code nicht nachgewiesen werden, obwohl ein Modul "EscalationsSettings" existiert - dessen Inhalt wurde nicht bis zur Ebene einer automatisierten Aktion vertieft.]
+Ergebnis:      Dashboard zeigt Anzahl überfälliger/bald fälliger SLA-Tickets; keine automatische Folgeaktion nachgewiesen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Helpdesk/Dashboard/TicketDueDate/TicketDueDateDashboardContainerViewModel.cs, Methode CalculateGroups - Begründung: Enthält die tatsächliche, durchgesetzte Gruppierungslogik.
+Prüfidee:      Ein Ticket mit abgelaufenem DueDate erscheint im Dashboard unter "Überfällig", ändert aber ohne manuelles Eingreifen weder Status noch Bearbeiter.
+Tracelinks:    StRS-015, SyRS-019, SwRS-026
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - eine reine Dashboard-Anzeige ersetzt keine automatisierte SLA-Eskalation; im Zielsystem sollte geprüft werden, ob eine echte Eskalationsautomatik ergänzt wird.
+Status:        HYPOTHESE
+```
+
+```
+ID:            StRS-017
+Titel:         Pflicht zur Checklistenabarbeitung vor Ticketabschluss
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Hotline-Mitarbeiter
+Vorbedingung:  Dem Ticket ist eine Checkliste zugeordnet.
+Fakt:          TicketDetailViewModel.CanCloseHelpdeskByChecklist() ruft serverseitig ITicketLogic.CanHelpdeskClose(helpdeskI3D) auf; liefert der Server CanClose==false, wird das Schließen mit den vom Server gelieferten Meldungen blockierend verweigert.
+Aussage:       Das System soll den Abschluss eines Tickets verweigern, solange eine zugeordnete Checkliste nicht vollständig abgearbeitet ist, und dem Bearbeiter die konkret fehlenden Punkte mitteilen.
+Ergebnis:      Ticket kann erst nach vollständiger Checkliste geschlossen werden.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketDetails/TicketDetailViewModel.cs, Methode CanCloseHelpdeskByChecklist (Zeile ~2217) - Begründung: Enthält den durchgesetzten Blockademechanismus.
+Prüfidee:      Ein Ticket mit unvollständiger Pflichtchecklist kann nicht geschlossen werden; der Dialog nennt die offenen Punkte.
+Tracelinks:    StRS-015, SyRS-018, SwRS-027
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - qualitätssichernder Prozessschritt.
+Status:        belegt
+```
+
+```
+ID:            StRS-018
+Titel:         Retourenabwicklung mit Lieferanten (RMA)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Serviceleitung, Hotline-Mitarbeiter
+Vorbedingung:  Ein defekter/zu tauschender Artikel eines Kunden liegt vor; ein Ticket ist vorhanden oder wird angelegt.
+Fakt:          RmaArticleState (Enum, 20 Werte: none…Removed) und RmaForthAction (EqualChange, ForeignChange, Repair, Scapped, UnRepair, Disabled u. a.) bilden den durchgesetzten Zustandsraum. SendBack (Versand zum Lieferanten) und SendForth (Rückkehr vom Lieferanten inkl. gewählter Aktion) sind die beiden zentralen Teilschritte, beide gegen das Recht RIGHT_RMAARTIKELSTATUSAENDERN geschützt.
+Aussage:       Das System soll RMA-Vorgänge als zweistufigen Prozess (Versand an den Lieferanten, anschließende Rücknahme mit Auswahl der Lösung) mit einem vollständigen Artikelzustandsmodell abbilden und 1:1 an ein Helpdesk-Ticket koppeln.
+Ergebnis:      Artikel durchläuft nachvollziehbare RMA-Zustände bis zur endgültigen Lösung (Reparatur/Austausch/Verschrottung).
+Belege:
+  - [PRIMÄR]   src/backend/Centron.Interfaces/CustomerArea/RmaArticleState.cs - Begründung: Enthält die vollständige, durchgesetzte Zustandsenumeration.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Rma/SendForth/SendForthViewModel.cs, Methode CheckForthState - Begründung: Enthält die konkrete Validierung (z. B. Pflichtfeld Austauschseriennummer bei EqualChange).
+Prüfidee:      Beim Versuch, eine SendForth-Aktion "ForeignChange" ohne Ersatzartikelcode zu speichern, wird die Speicherung mit "Speichern ist unmöglich" verweigert.
+Tracelinks:    SyRS-020, SyRS-021, SwRS-028, SwRS-029
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - etablierter Serviceprozess.
+Status:        belegt
+```
+
+```
+ID:            StRS-019
+Titel:         Physische Bestandsführung (Lagerartikel, Bestand, Reservierung)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Lagermitarbeiter, Einkauf
+Vorbedingung:  Artikel sind im Lager geführt; Bestellungen/Aufträge existieren.
+Fakt:          ArticleStock.StockAvailable = StockAmount - (StockInOrder ?? 0); Zugriff auf ArticleManagement ist über zwei Rechte (Purchase.ID UND Purchase.StockList.ID) geschützt, sonst wird das Modul mit "Sie haben kein Recht..." verweigert.
+Aussage:       Das System soll den verfügbaren Lagerbestand als Buchbestand abzüglich bereits reservierter/in Bestellung befindlicher Mengen ausweisen und den Zugriff auf die Artikelverwaltung an den gleichzeitigen Besitz zweier spezifischer Rechte binden.
+Ergebnis:      Verfügbarkeitsanzeige je Artikel/Lagerort; Artikelverwaltung nur für berechtigte Mitarbeiter zugänglich.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Warehousing/SearchArticle/ViewModel/ArticleStock.cs, Property StockAvailable - Begründung: Enthält die durchgesetzte Verfügbarkeitsformel.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleManagement/Controller/ArticleManagementAppModuleController.cs - Begründung: Enthält die doppelte Rechteprüfung als Öffnungs-Gate.
+Prüfidee:      Ein Artikel mit Buchbestand 10 und 3 Stück in offener Bestellung (StockInOrder) zeigt eine Verfügbarkeit von 7.
+Tracelinks:    SyRS-022, SwRS-030, SwRS-031
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernfunktion der Warenwirtschaft.
+Status:        belegt
+```
+
+```
+ID:            StRS-020
+Titel:         Verwaltung und automatische Preisumrechnung von Umsatzsteuersätzen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung
+Vorbedingung:  Ein Umsatzsteuersatz läuft aus oder ändert sich gesetzlich.
+Fakt:          ValueAddedTaxViewModel.Save() erzwingt genau einen Standard-Steuersatz (Default), verhindert doppelte Folge-Satz-Zuordnung und bietet beim Wechsel auf einen Folgesatz zwei Umrechnungsstrategien: Netto konstant (Brutto = Netto*(1+neuerSatz)) oder Brutto konstant (Netto = Brutto/(1+neuerSatz)).
+Aussage:       Das System soll bei gesetzlichen Steuersatzänderungen eine Folge-Satz-Verkettung mit Gültigkeitsdatum abbilden und dem Anwender die Wahl lassen, ob bei der Umstellung der Netto- oder der Bruttopreis der betroffenen Artikel konstant gehalten wird.
+Ergebnis:      Artikelpreise werden gemäß gewählter Strategie konsistent auf den neuen Steuersatz umgerechnet.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Warehousing/ValueAddedTaxViewModel.cs, Methoden Save/UpdateArticles - Begründung: Enthält beide durchgesetzten Umrechnungsformeln und die Default-Satz-Validierung.
+Prüfidee:      Beim Umstellen aller Artikel einer Materialgruppe von 19% auf einen neuen Satz mit Strategie "Netto konstant" bleibt der Nettopreis unverändert, der Bruttopreis ändert sich entsprechend.
+Tracelinks:    SyRS-023, SwRS-032
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - gesetzlich erforderliche Funktion.
+Status:        belegt
+```
+
+```
+ID:            StRS-021
+Titel:         Bedarfsermittlung und Bestellvorschlagswesen (BVL)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Einkauf
+Vorbedingung:  Artikel unterschreiten Mindestbestand oder Kundenaufträge erfordern Nachbestellung.
+Fakt:          SuggestionQuantity.SetToBookingValue() berechnet ToBooking = OrderItemQuantity + MinimumQuantity - AvailableQuantity - Intake - ConsignmentQuantity; bei aktiver Sonderpreisvereinbarung wird AvailableQuantity separat aus SpecialAgreementQuantity statt dem allgemeinen Bestand gebildet. GetDistributorI3D() wählt den Lieferanten nach bis zu drei kombinierbaren, vom Anwender priorisierten Kriterien (Preis, Verfügbarkeit, A-/B-/C-Lieferant).
+Aussage:       Das System soll die zu bestellende Menge je Artikel aus offenem Bedarf, Mindestbestand, verfügbarem Bestand, eingehender Ware und ggf. separat geführtem Sonderpreis-Kontingent errechnen und die Lieferantenauswahl anhand konfigurierbarer, priorisierbarer Kriterien automatisieren.
+Ergebnis:      Vorgeschlagene Bestellmenge und -lieferant je Artikel.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Purchasing/Others/SuggestionQuantity.cs, Methode SetToBookingValue - Begründung: Enthält die vollständige, durchgesetzte Bedarfsformel.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Purchasing/OrderSuggestionList/OrderSuggestionListViewModel.cs, Methode GetDistributorI3D - Begründung: Enthält die durchgesetzte Lieferantenauswahllogik.
+Prüfidee:      Ein Artikel mit Mindestbestand 10, aktuellem Bestand 4 und keiner offenen Bestellung erzeugt einen Bestellvorschlag über 6 Stück.
+Tracelinks:    SyRS-024, SwRS-033, SwRS-034
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrale Einkaufsfunktion.
+Status:        belegt
+```
+
+```
+ID:            StRS-022
+Titel:         Elektronischer Belegaustausch mit Lieferanten (EDI, inkl. ZUGFeRD)
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Einkauf
+Vorbedingung:  Ein Lieferant sendet Auftragsbestätigung/Lieferschein/Rechnung elektronisch (klassisches EDI oder ZUGFeRD-XML).
+Fakt:          EDIPositionRelationState ([Flags]: NoDifference, WithQuantityDifference, WithPriceDifference, WithDeliveryDateDifference, BadBarcode) klassifiziert jede EDI-Position; die Übernahme wird verweigert, solange keine einzige Position zugeordnet ist (RelationState != None). Invoice-Recht erfordert zusätzlich zum Wareneingangsrecht das Kalkulationsrecht (RIGHT_KALKULATION).
+Aussage:       Das System soll eingehende EDI-Belege (inkl. ZUGFeRD-Rechnungen) automatisiert gegen die eigene Bestellung abgleichen, Abweichungen in Menge/Preis/Liefertermin/Barcode kennzeichnen und die Übernahme der Rechnungsdaten an ein zusätzliches Kalkulationsrecht binden.
+Ergebnis:      EDI-Positionen sind mit Abweichungskennzeichnung dem Anwender zur Freigabe vorgelegt; nur berechtigte Mitarbeiter können Rechnungsdaten übernehmen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Purchasing/EDIManagement/EDIReceiptTabs/EDIPositionRelationState.cs - Begründung: Enthält die durchgesetzte Flags-Klassifikation.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Purchasing/EDIManagement/EDIManagementAppViewModel.cs, Property IsNewInvoiceRight - Begründung: Enthält die kombinierte Rechteprüfung.
+Prüfidee:      Eine EDI-Rechnung mit ausschließlich unabgeglichenen Positionen kann nicht akzeptiert werden.
+Tracelinks:    SyRS-025, SwRS-035
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - notwendig für effiziente Beschaffung.
+Status:        belegt
+```
+
+```
+ID:            StRS-023
+Titel:         Physische Inventur mit Zustandsmodell und Abschlussoptionen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Lagermitarbeiter
+Vorbedingung:  Eine Inventursitzung wurde eröffnet.
+Fakt:          InventoryState-Enum (Open, Closed, Deleted, OpenWithoutBC, ClosedWithoutBC) unterscheidet Zählungen mit/ohne Barcode-/Seriennummererfassung; FinalizeInventoryEnum (Partial, PartialAllStorages, Complete, CompleteAllStorages) und FinalizeStorageEnum (AllStorages, SelectedStorages) steuern den Umfang des Inventurabschlusses.
+Aussage:       Das System soll Inventuren wahlweise mit oder ohne Barcode-/Seriennummererfassung durchführen und den Abschluss granular auf einzelne oder alle Lagerorte, vollständig oder teilweise, ermöglichen.
+Ergebnis:      Inventur wird mit dem gewählten Abschlussumfang finalisiert; Zählstand ist nachvollziehbar dokumentiert.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Warehousing/Inventory/ViewModels/InventoryViewModels/InventoryViewModel.cs - Begründung: Enthält das durchgesetzte InventoryState-Enum.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Warehousing/Inventory/Enums/FinalizeInventoryEnum.cs, FinalizeStorageEnum.cs - Begründung: Enthalten die durchgesetzten Abschlussoptionen.
+Prüfidee:      Eine Inventur im Modus "OpenWithoutBC" kann ohne Seriennummererfassung geschlossen werden.
+Tracelinks:    SyRS-026, SwRS-036
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - gesetzlich/betriebswirtschaftlich erforderliche Funktion.
+Status:        belegt
+```
+
+```
+ID:            StRS-024
+Titel:         Export von Belegdaten an Finanzbuchhaltungssysteme
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung / Steuerberater
+Vorbedingung:  Abgeschlossene Rechnungen/Gutschriften liegen vor.
+Fakt:          DatevOnlineViewModel.Export() erzeugt für jede gewählte Rechnung ein ZIP-Paket (LedgerXML + DocumentXML + PDF) im DATEV-Unternehmen-Online-Format; Centron.Gateway enthält zusätzlich eigenständige Export-/Import-Adapter für Addison, Abacus, SAP, Sage, Lexware, Navision (je IBookKeepingExport/IBookKeepingImportDataToCentron).
+Aussage:       Das System soll Belegdaten wahlweise im DATEV-Unternehmen-Online-Format oder über spezialisierte Adapter in eine Reihe weiterer Finanzbuchhaltungssysteme exportierbar machen.
+Ergebnis:      ZIP-Paket bzw. Exportdatei im Zielformat des jeweiligen FiBu-Systems.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Administration/DataExchange/DatevOnline2020/DatevOnlineViewModel.cs, Methode Export - Begründung: Enthält die durchgesetzte Paketerzeugung.
+  - [SEKUNDÄR] src/backend/Centron.Gateway/DataExchange/BookKeeping/* - Begründung: Ordnerstruktur belegt Existenz mehrerer Adapterimplementierungen (nicht einzeln vertieft).
+Prüfidee:      Export einer Rechnung erzeugt eine ZIP-Datei mit package.xml und document.xml.
+Tracelinks:    SyRS-027, SwRS-037
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - regulatorisch/prozessual notwendig.
+Status:        belegt
+```
+
+```
+ID:            StRS-025
+Titel:         SEPA-Zahlungsverkehr und Bankkontenanbindung
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung
+Vorbedingung:  Fällige Zahlungen (Lastschrift/Überweisung) oder Kontobewegungen liegen vor.
+Fakt:          Centron.Gateway\DataExchange\PaymentTransactions\Sepa\SepaFileGeneratorV2 erzeugt SEPA-pain.008-Dateien; OnlineBankingServiceVersionType-Enum (HBCI, FinTS, EBICS_H004, EBICS_H005) und die Alternative über den Aggregator finAPI (Centron.APIs.FinAPI) bilden zwei parallele Wege der Kontoanbindung.
+Aussage:       Das System soll SEPA-Zahlungsdateien für Lastschrift/Überweisung erzeugen und Kontobewegungen wahlweise über direkte Bankprotokolle (HBCI/FinTS/EBICS) oder über den Aggregator finAPI abrufen und mit offenen Rechnungen abgleichen.
+Ergebnis:      SEPA-Datei zur Einreichung bei der Bank; abgeglichene Kontobewegungen mit Zahlungsstatus.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.Gateway/DataExchange/PaymentTransactions/Sepa/SepaFileGeneratorV2.cs - Begründung: Enthält die durchgesetzte SEPA-Dateierzeugung.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/OnlineBanking/ConfigurationSettings/Helper/OnlineBankingServiceVersionType.cs - Begründung: Enthält die durchgesetzten unterstützten Protokolle.
+Prüfidee:      Eine Sammellastschrift über mehrere fällige Rechnungen erzeugt eine gültige pain.008-XML-Datei.
+Tracelinks:    SyRS-028, SwRS-038, SwRS-039
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernfunktion des Zahlungsverkehrs.
+Status:        belegt
+```
+
+```
+ID:            StRS-026
+Titel:         Integration mit Distributor- und Marktplatzplattformen
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Einkauf, Vertrieb
+Vorbedingung:  Ein Distributor-/Marktplatzzugang ist konfiguriert.
+Fakt:          Sechs eigenständige externe Produktdaten-/Bestellintegrationen wurden nachgewiesen: COP (SOAP), EGIS (Katalog + volles EDI im Gateway), ITscope (REST/XML), Icecat (REST/XML), Wortmann (Sonderpreisimport) und Deutsche Telekom D!VE (XML-Export von Angebotspositionen).
+Aussage:       Das System soll Artikelstammdaten, Preise und Bestellprozesse mit mehreren externen Distributor- und Marktplatzplattformen konsistent austauschen können, ohne die einzelnen Integrationen fachlich zu vermischen.
+Ergebnis:      Aktuelle Produktdaten/Preise aus externen Quellen; Bestellungen/Angebote werden an die jeweilige Plattform übermittelt.
+Belege:
+  - [PRIMÄR]   src/apis/Centron.APIs.EgisDataAccess/EgisApi.cs - Begründung: Belegt eine der sechs eigenständigen Integrationen im Detail.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/TelekomDive/TelekomDiveExportViewModel.cs - Begründung: Belegt die D!VE-Integration als UI-seitigen Exportvorgang.
+Prüfidee:      Eine Artikelsuche über die ITscope-Integration liefert Produktdaten inkl. Lieferanten- und Preisinformation.
+Tracelinks:    SyRS-029, SwRS-040
+Konsolidierung: Kandidat: Die sechs Integrationen bilden fachlich denselben Grundvorgang „externe Produktdaten/Bestellung beziehen" mit unterschiedlichen Protokollen; im Zielsystem ist ein einheitliches Adapterkonzept zu prüfen.
+Übernahmewürdigkeit: übernehmen - wesentlicher Bestandteil der Beschaffungsstrategie.
+Status:        belegt
+```
+
+```
+ID:            StRS-027
+Titel:         Anbindung von Versanddienstleistern
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Versand-/Lagermitarbeiter
+Vorbedingung:  Ein Paket ist versandfertig kommissioniert.
+Fakt:          CentronGlsLogic.UploadShipment() (REST, GLS) und CentronShipcloudLogic (REST, shipcloud.io, Multi-Carrier) sind zwei eigenständige, parallel implementierte Versanddienstleister-Anbindungen mit jeweils eigener Authentifizierung.
+Aussage:       Das System soll Versandaufträge wahlweise über die GLS-Direktanbindung oder über den Multi-Carrier-Dienst shipcloud.io elektronisch an den jeweiligen Paketdienstleister übermitteln.
+Ergebnis:      Versandlabel/Trackingnummer wird erzeugt und dem Lieferschein zugeordnet.
+Belege:
+  - [PRIMÄR]   src/apis/Centron.Api.Gls/CentronGlsLogic.cs, Methode UploadShipment - Begründung: Enthält den durchgesetzten Versandauftrag an GLS.
+  - [PRIMÄR]   src/apis/Centron.Api.Shipcloud/CentronShipcloudLogic.cs - Begründung: Enthält die parallele shipcloud-Anbindung.
+Prüfidee:      Eine Sendung wird über shipcloud angelegt und liefert eine gültige Trackingnummer zurück.
+Tracelinks:    SyRS-030, SwRS-041
+Konsolidierung: Kandidat: GLS-Direktanbindung und shipcloud-Multi-Carrier-Anbindung decken fachlich denselben Vorgang „Versandlabel erzeugen" ab; im Zielsystem auf ein gemeinsames Versand-Interface konsolidierbar.
+Übernahmewürdigkeit: übernehmen - notwendig für Versandprozess.
+Status:        belegt
+```
+
+```
+ID:            StRS-028
+Titel:         Verwaltung von Kunden-/Adressstammdaten und CRM-Aktivitäten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertrieb, Kundenservice
+Vorbedingung:  Eine Adresse/ein Kunde existiert oder wird neu angelegt.
+Fakt:          CrmAppModuleController (ModuleName "Adressstamm") verwaltet Adressen, CRM-Aktivitäten und Belege gemeinsam; AccountManagementAppModuleController ergänzt eine Suche nach noch nicht zu Kunden konvertierten Adressen.
+Aussage:       Das System soll Adress- und Kundenstammdaten zentral verwalten, CRM-Aktivitäten dokumentieren und die Konvertierung einer Adresse zum vollwertigen Kunden unterstützen.
+Ergebnis:      Konsistenter Kunden-/Adressstamm als Basis für Vertrieb, Service und Abrechnung.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Finances/Crm/CrmAppModuleController.cs - Begründung: Bestätigt Modulzweck und -bezeichnung.
+Prüfidee:      Eine als Adresse angelegte Firma kann über AccountManagement in einen vollwertigen Kunden konvertiert werden.
+Tracelinks:    SyRS-031, SwRS-042
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Basisdatenverwaltung für alle Folgeprozesse.
+Status:        belegt
+```
+
+```
+ID:            StRS-029
+Titel:         Massenänderung von Preisen und Belegdaten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Einkauf, Vertrieb
+Vorbedingung:  Preisänderungen (z. B. jährliche Preisanpassung) betreffen viele Artikel/Konten gleichzeitig.
+Fakt:          UpdateArticlePricesViewModel erzwingt eine gegenseitige Ausschlussvalidierung zwischen prozentualer und fixer Preisanpassung (EK/VK): Setzen eines Prozentwerts löscht automatisch den zugehörigen Fixwert und umgekehrt.
+Aussage:       Das System soll Massenänderungen an Einkaufs- und Verkaufspreisen wahlweise prozentual oder als Festwert ermöglichen, wobei beide Eingabearten je Preisart gegenseitig exklusiv sind, um widersprüchliche Anpassungen zu verhindern.
+Ergebnis:      Konsistent angepasste Preise über die gewählte Artikelmenge.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Massenupdates/Updates/PriceUpdates/ArticleUpdate/UpdateArticlePricesViewModel.cs - Begründung: Enthält die durchgesetzte gegenseitige Exklusivität der Eingabefelder.
+Prüfidee:      Eingabe eines Prozentwerts für die VK-Preisanhebung löscht einen zuvor eingegebenen Fixwert automatisch.
+Tracelinks:    SyRS-032, SwRS-043
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - effizienter Massenpflegeprozess.
+Status:        belegt
+```
+
+```
+ID:            StRS-030
+Titel:         Kostenstellen- und Kostenträgerrechnung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Controlling
+Vorbedingung:  Kostenstellen/-träger sind zur Zuordnung von Belegen benötigt.
+Fakt:          PayersAndCostCenterAppModuleControllerViewModel führt Soft-Delete/Restore getrennt für Kostenstellen und Kostenträger (jeweils eigene ShowDeleted-Flags und Wiederherstellungskommandos).
+Aussage:       Das System soll Kostenstellen und Kostenträger getrennt verwalten und gelöschte Einträge reversibel (Soft-Delete mit Wiederherstellung) statt destruktiv entfernen.
+Ergebnis:      Kostenstellen-/-trägerliste bleibt auch nach Löschung wiederherstellbar.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter/PayersAndCostCenterAppModuleControllerViewModel.cs - Begründung: Enthält die getrennten Soft-Delete-/Restore-Kommandos.
+Prüfidee:      Eine gelöschte Kostenstelle erscheint bei aktivem Filter "gelöschte anzeigen" und kann wiederhergestellt werden.
+Tracelinks:    SyRS-033, SwRS-044
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Standardanforderung des Controllings.
+Status:        belegt
+```
+
+```
+ID:            StRS-031
+Titel:         Fertigungsauftrags- und Maschinenverwaltung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Produktionsplanung
+Vorbedingung:  Ein Kundenauftrag enthält produktionsrelevante Artikel.
+Fakt:          ProductionOrderManagementViewModel verknüpft OrderWithProductionArticlesDTO (Auftrag mit produktionsrelevanten Artikeln) mit ProductionOrderDTO und ordnet Maschinen (ProductionMachineDTO) sowie Maschinenarten mit je eigenen Produktionsschritt-Beschreibungen zu.
+Aussage:       Das System soll aus Kundenaufträgen mit produktionsrelevanten Artikeln Fertigungsaufträge ableiten und diesen Maschinen sowie maschinenartspezifische Produktionsschritte zuordnen.
+Ergebnis:      Fertigungsauftrag mit zugeordneter Maschine und Produktionsschritten.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Production/ProductionOrder/ProductionOrderManagementViewModel.cs - Begründung: Enthält die durchgesetzte Verknüpfungslogik.
+Prüfidee:      Ein Auftrag mit produktionsrelevantem Artikel erzeugt einen Fertigungsauftrag, der einer Maschine zugewiesen werden kann.
+Tracelinks:    SyRS-034, SwRS-045
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - für Kunden mit eigener Fertigung erforderlich.
+Status:        belegt
+```
+
+```
+ID:            StRS-032
+Titel:         Produktlebenszyklus-Verfolgung (PLM)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Produktmanagement
+Vorbedingung:  Produktfamilien mit Lebenszyklusdaten sind gepflegt.
+Fakt:          PlmViewModel filtert nach Status (ShowOnlyActive/Expired/Deactivated) und Beratern (bis zu vier benannte Advisor-Felder); PlmLogViewModel führt eine Änderungshistorie je Produktlebenszyklus-Eintrag.
+Aussage:       Das System soll den Lebenszyklusstatus von Produktfamilien mit zugeordneten Beratern nachvollziehbar verwalten und Änderungen historisieren.
+Ergebnis:      Aktueller Lebenszyklusstatus je Produktfamilie mit Änderungshistorie.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/PLM/PlmViewModel.cs - Begründung: Enthält die durchgesetzten Statusfilter.
+Prüfidee:      Eine Statusänderung einer Produktfamilie erscheint im PLM-Log mit Zeitstempel.
+Tracelinks:    SyRS-035, SwRS-046
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - unterstützt Sortimentssteuerung.
+Status:        belegt
+```
+
+```
+ID:            StRS-033
+Titel:         Auswertungen, Kennzahlen und Management-Reporting
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Geschäftsführung, Controlling
+Vorbedingung:  Verkaufs-, Ticket- und Mitarbeiterdaten liegen vor.
+Fakt:          ManagementInfoViewModel liefert tages-/monatsbezogene Umsatz-, Gewinn-, Angebots- und Auftragsbestandskennzahlen je Filiale/Materialgruppe; MspCollectorViewModel plant zusätzlich wiederkehrende, konfigurierbare Datenabholungen (u. a. ArrowSphere) für den MSP-Lizenzabgleich.
+Aussage:       Das System soll tages- und monatsbezogene betriebswirtschaftliche Kennzahlen bereitstellen und zusätzlich wiederkehrend Nutzungs-/Lizenzdaten externer MSP-Distributoren zum Abgleich mit eigenen Verträgen einholen.
+Ergebnis:      Management-Dashboard mit Kennzahlen; automatisch aktualisierte MSP-Vergleichsdaten.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Statistics/ManagementInfo/ManagementInfoViewModel.cs - Begründung: Enthält die durchgesetzten Kennzahlenabfragen.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Statistics/MspCollectors/MspCollectorViewModel.cs - Begründung: Belegt die konfigurierbare Wiederholungsplanung als UI-Fakt.
+Prüfidee:      Das Management-Dashboard zeigt für den aktuellen Monat Umsatz- und Gewinnzahlen je Filiale.
+Tracelinks:    SyRS-036, SwRS-047
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrale Steuerungsgrundlage.
+Status:        belegt
+```
+
+```
+ID:            StRS-034
+Titel:         KI-gestützte Assistenzfunktionen mit Zugriff auf Geschäftsdaten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Alle Systembenutzer
+Vorbedingung:  KI-Funktion ist lizenziert/aktiviert.
+Fakt:          ArtificialIntelligenceChatCoordinator begrenzt einen agentenhaften Chat-Dialog auf maximal 50 Werkzeug-Runden (_maximumClientToolRounds=50) und bindet Werkzeuge für Konten, Artikel, Mitarbeiter, Belege, Tickets, Navigation sowie optionale Websuche über einen IArtificialIntelligenceToolConfirmationService (Bestätigungspflicht vor Aktionsausführung) ein.
+Aussage:       Das System soll einen KI-Chat-Assistenten bereitstellen, der lesend und schreibend auf Geschäftsdaten (Konten, Artikel, Mitarbeiter, Belege, Tickets) zugreifen kann, wobei jede Werkzeugaktion einer Bestätigung durch den Anwender bedarf und die Anzahl der Werkzeugaufrufe je Dialog begrenzt ist.
+Ergebnis:      KI-Antwort bzw. ausgeführte Aktion nach Bestätigung durch den Anwender.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ArtificialIntelligence/Chat/Harness/ArtificialIntelligenceChatCoordinator.cs - Begründung: Enthält die durchgesetzte Rundenbegrenzung und den Bestätigungsmechanismus.
+Prüfidee:      Eine vom KI-Assistenten vorgeschlagene Datenänderung wird erst nach expliziter Bestätigung durch den Anwender ausgeführt.
+Tracelinks:    SyRS-037, SwRS-048
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zukunftsgerichtete Funktion, im Zielsystem auszubauen.
+Status:        belegt
+```
+
+```
+ID:            StRS-035
+Titel:         Persönlicher Arbeitsbereich (Mein Tag, Kalender, Telefonie)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Alle Mitarbeiter
+Vorbedingung:  Mitarbeiter ist angemeldet.
+Fakt:          MyDayConnector bündelt Tickets, Timer, Mitarbeiter- und Mailvorlagendaten zu einer Tagesübersicht; TelephonyConnector bindet TAPI-basierte Telefonanlagenintegration (Call/AcceptCall/DeclineCall/DisconnectCall) inkl. Anruferbild-Anzeige ein.
+Aussage:       Das System soll dem Mitarbeiter eine tagesbezogene Übersicht seiner Tickets, Zeiten und Aufgaben bereitstellen und eine TAPI-basierte Telefonieanbindung mit Anrufersteuerung und Bildanzeige integrieren.
+Ergebnis:      Tagesübersicht je Mitarbeiter; eingehende Anrufe zeigen Kontaktbild und erlauben Annahme/Ablehnung direkt aus der Anwendung.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/MyCentron/MyDay/MyDayConnector.cs - Begründung: Enthält die durchgesetzte Datenaggregation.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/MyCentron/Telephony/TelephonyConnector.cs - Begründung: Enthält die durchgesetzte TAPI-Anbindung.
+Prüfidee:      Ein eingehender Anruf eines bekannten Kunden zeigt dessen Kontaktbild im Popup.
+Tracelinks:    SyRS-038, SwRS-049
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - produktivitätsfördernde Zusatzfunktion.
+Status:        belegt
+```
+
+```
+ID:            StRS-036
+Titel:         Zentrale Systemkonfiguration und Stammdatenverwaltung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Administrator
+Vorbedingung:  Grundkonfiguration der Installation (Länder, Empfangsbedingungen, Mitarbeiter, externe Tools) ist erforderlich.
+Fakt:          GetSettingsWithoutModule() registriert eine flache, ungegliederte Liste von >15 Einstellungsseiten (CentronConfigDb, ExternalTools, EscalationType, PdfSigning, PhoneSettings, Profiling, MailAndCalender/General, DocSync u. a.) ohne individuelle Rechteprüfung je Seite (siehe StRS-010).
+Aussage:       Das System soll grundlegende Stammdaten (Länder, Empfangsbedingungen, Zuschlagssätze, Mitarbeiter, externe Werkzeuge) sowie technische Einstellungen zentral administrierbar machen.
+Ergebnis:      Konsistente Stammdatenbasis für alle Fachmodule.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Methode GetSettingsWithoutModule - Begründung: Enthält die vollständige, durchgesetzte Liste der Einstellungsseiten.
+Prüfidee:      Ein neu angelegtes Land steht in der Kundenadresserfassung sofort zur Auswahl.
+Tracelinks:    StRS-010, SyRS-011, SwRS-050
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - notwendige Konfigurationsbasis.
+Status:        belegt
+```
+
+```
+ID:            StRS-037
+Titel:         Web-Self-Service und Warenkorb für Kunden (Nexus/WebCart)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Kunde (Web-Account)
+Vorbedingung:  Ein Web-Account ist im c-entron-Adressstamm angelegt und mit Sonderpreisen versehen.
+Fakt:          Laut README.md ist WebCart primär für Kunden der Kunden gedacht: nach Login als Web-Account kann im c-entron Nexus über "Shop" auf die eigenen Sonderpreise zugegriffen werden.
+Aussage:       Das System soll Endkunden über einen separaten Web-Login den Zugriff auf ihre individuell vereinbarten Sonderpreise und eine Bestellfunktion (Warenkorb) ermöglichen, ohne Zugriff auf interne c-entron-Funktionen zu gewähren.
+Ergebnis:      Kunde sieht im Webportal ausschließlich seine freigegebenen Artikel/Preise und kann bestellen.
+Belege:
+  - [PRIMÄR]   README.md, Abschnitt „Contributing/WebCart" - Begründung: Beschreibt den durchgesetzten fachlichen Ablauf aus Entwicklersicht.
+  - [SEKUNDÄR] src/nexus/CentronNexus/WebCart/* (laut Recherche vorhanden) - Begründung: Bestätigt die technische Existenz des WebCart-Bereichs in Nexus.
+Prüfidee:      Ein Web-Account-Login zeigt im Shop-Bereich ausschließlich die für den Kunden hinterlegten Sonderpreisartikel.
+Tracelinks:    SyRS-039, SwRS-051
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Basis für künftige SaaS-/Kundenportal-Strategie.
+Status:        belegt
+```
+
+```
+ID:            StRS-038
+Titel:         Outlook-Integration zur Ticket-Mail-Zuordnung
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Hotline-Mitarbeiter
+Vorbedingung:  Mitarbeiter nutzt Outlook mit installiertem c-entron-Add-in.
+Fakt:          Manifest.xml des CentronNexus.OutlookAddIn deklariert ein MailApp-Add-in mit ReadWriteItem-Berechtigung, das E-Mails direkt Tickets/Kunden zuordnen kann; Middleware UseAllowXFrameOptionsForCentronNexus()/UseOutlookCookiePolicy() erlaubt das Einbetten von Nexus im Outlook-Taskbereich.
+Aussage:       Das System soll es Mitarbeitern ermöglichen, E-Mails direkt aus Outlook heraus bestehenden Tickets oder Kunden zuzuordnen bzw. neue Tickets aus E-Mails zu erzeugen.
+Ergebnis:      E-Mail ist im c-entron-Kontext (Ticket/Kunde) sichtbar, ohne Outlook verlassen zu müssen.
+Belege:
+  - [PRIMÄR]   src/nexus/CentronNexus.OutlookAddIn/Manifest/Manifest.xml - Begründung: Enthält die durchgesetzte Berechtigungsdeklaration und den Anwendungsfall.
+Prüfidee:      Eine markierte E-Mail kann über das Add-in einem bestehenden Ticket zugeordnet werden.
+Tracelinks:    SyRS-040, SwRS-052
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - deutliche Effizienzsteigerung im Serviceprozess.
+Status:        belegt
+```
+
+```
+ID:            StRS-039
+Titel:         Qualitätsmanagement: standardisierte Reklamationsgründe je Belegart
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Qualitätsmanagement
+Vorbedingung:  Reklamationen/Rücksendungen zu Bestellungen, Gutschriften, Lieferscheinen etc. erfordern eine Begründung.
+Fakt:          QmSettingsViewModel konfiguriert sieben parallele AssetReasonSettingsViewModel-Instanzen (Bestellung, Gutschrift-Lieferant, Lieferschein-Lieferant, Rechnung-Lieferant, Abholschein, Gutschrift-Kunde, Lieferschein-Kunde) mit jeweils eigenem Grundkatalog an Gründen.
+Aussage:       Das System soll für jede relevante Beleg-/Rücksendeart einen eigenen, administrierbaren Katalog standardisierter Gründe bereitstellen, damit Reklamationen einheitlich klassifiziert werden können.
+Ergebnis:      Jede Reklamation/Rücksendung trägt einen aus dem passenden Katalog gewählten Grund.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/QM/Settings/QmSettingsViewModel.cs - Begründung: Enthält die sieben durchgesetzten, getrennten Grundkataloge.
+Prüfidee:      Eine Lieferanten-Gutschrift verlangt die Auswahl eines Grundes aus dem dafür vorgesehenen Katalog.
+Tracelinks:    SyRS-041, SwRS-053
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - unterstützt strukturierte Reklamationsauswertung.
+Status:        belegt
+```
+
+```
+ID:            StRS-040
+Titel:         Import projektspezifischer Sonderpreise mit Differenzprüfung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertrieb, Einkauf
+Vorbedingung:  Ein Lieferant/Projekt liefert eine Preisliste als Excel-Datei.
+Fakt:          ProjectPriceImportViewModel matcht Excel-Zeilen gegen bestehende SpecialAgreementDTO-Datensätze und Artikel; DifferenceViewModel zeigt Preisdifferenzen zwischen neuem Import und bestehender Sonderpreisvereinbarung vor dem endgültigen Import (CanImport-Gate).
+Aussage:       Das System soll importierte projektspezifische Sonderpreise vor der Übernahme gegen bestehende Vereinbarungen abgleichen und Preisdifferenzen dem Anwender zur Prüfung vorlegen, bevor der Import bestätigt werden kann.
+Ergebnis:      Nur geprüfte, bestätigte Preisänderungen werden übernommen; nicht zuordenbare Zeilen werden als Fehler ausgewiesen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ProjectPriceImport/ProjectPriceImportViewModel.cs - Begründung: Enthält die durchgesetzte Matching- und Differenzprüfung.
+Prüfidee:      Ein Import mit abweichendem Preis zu einer bestehenden Sonderpreisvereinbarung zeigt die Differenz vor dem endgültigen Import an.
+Tracelinks:    SyRS-042, SwRS-054
+Konsolidierung: Kandidat: ProjectPriceImport (Sales/Finances) und SpecialArticleToContractImport (Sales) bilden fachlich denselben Grundvorgang „Sonderpreis-Import mit Differenzprüfung" mit unterschiedlichen Quellformaten (Wortmann, generisches Excel).
+Übernahmewürdigkeit: übernehmen - reduziert manuellen Pflegeaufwand bei Sonderpreisen.
+Status:        belegt
+```
+
+```
+ID:            StRS-041
+Titel:         Interne Umfragen als konfigurierbarer Workflow-Prozess
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Qualitätsmanagement, Personalabteilung
+Vorbedingung:  Eine Umfrage/ein Fragebogen soll erstellt und ausgewertet werden.
+Fakt:          SurveyMainViewModel modelliert Umfragen als generische Workflow-Prozesse (Centron.Data.Entities.Services.Workflows) statt als eigenständige Umfrage-Engine; unterstützte Fragetypen sind CheckChoice, FreeText, MultipleChoice, Scala, YesNo.
+Aussage:       Das System soll Umfragen als konfigurierbare Workflow-Prozesse mit mehreren Fragetypen abbilden und deren Ergebnisse auswertbar machen.
+Ergebnis:      Auswertbare Umfrageergebnisse je Fragetyp.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Survey/SurveyMainViewModel.cs - Begründung: Belegt die Modellierung als Workflow-Prozess.
+Prüfidee:      Eine Umfrage mit einer Skalenfrage liefert nach Beantwortung einen auswertbaren Zahlenwert.
+Tracelinks:    SyRS-043, SwRS-055
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zusatznutzen für Kundenzufriedenheitsmessung.
+Status:        belegt
+```
+
+```
+ID:            StRS-042
+Titel:         Mehrschichtige Softwarearchitektur mit einheitlichem Datenzugriffsmuster
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Wartbarkeit
+Akteur:        Entwicklungsteam
+Vorbedingung:  Ein neues oder bestehendes Modul benötigt Datenzugriff sowohl per Direktverbindung als auch per Webservice.
+Fakt:          Jedes Modul MUSS laut Entwicklerdokumentation sowohl eine direkte NHibernate-basierte BL-Implementierung als auch eine WS-Implementierung hinter derselben ILogic-Schnittstelle bereitstellen (ClassContainer-Pattern, Result<T>-Fehlerbehandlung, async/await durchgängig).
+Aussage:       Das System soll für jedes Fachmodul einen einheitlichen Datenzugriff über eine gemeinsame Schnittstelle (ILogic) anbieten, die wahlweise per Direktverbindung zur Datenbank oder per Webservice bedient wird, um Wartbarkeit und Austauschbarkeit der Zugriffsart sicherzustellen.
+Ergebnis:      Ein Modul funktioniert unverändert sowohl im Direktverbindungs- als auch im Webservice-Betrieb.
+Belege:
+  - [PRIMÄR]   docs/getting-started/general-structure.md - Begründung: Enthält die durchgesetzte Architekturvorgabe inkl. Codebeispielen (verbindliche Entwicklerrichtlinie, kein bloßer Kommentar).
+Prüfidee:      Ein Modul, das gegen CentronConnectionType.SqlServer getestet wurde, funktioniert unverändert gegen CentronConnectionType.CentronWebServices.
+Tracelinks:    SyRS-044, SwRS-056, SwRS-057
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Architekturprinzip, im Zielsystem ggf. durch reine API-first-Architektur zu ersetzen.
+Status:        belegt
+```

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048/Ergebnisse/SyRS.md

@@ -0,0 +1,890 @@
+# System Requirements Specification (SyRS)
+
+Systemverhalten, Schnittstellen, Performance- und Sicherheitsanforderungen, abgeleitet aus den StRS-Anforderungen.
+
+---
+
+```
+ID:            SyRS-001
+Titel:         Selektionsregel für mahnfähige Rechnungen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (Mahnlauf)
+Vorbedingung:  Mahnlauf wird gestartet.
+Fakt:          DunningBL.GenerateInvoiceExpression() kombiniert vier Filterbedingungen (State==Active, DunningLevel-Filter, NextDueDateInDays-Filter, Toleranztage) zu einem Prädikat.
+Aussage:       Das System muss Rechnungen ausschließlich anhand des kombinierten Prädikats (aktiv, fällig, ggf. mit Toleranztagen) als mahnfähig einstufen und darf keine stornierten oder bereits vollständig bezahlten Rechnungen einbeziehen.
+Ergebnis:      Nur tatsächlich mahnfähige Rechnungen werden im Mahnlauf berücksichtigt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs, Methode GenerateInvoiceExpression - Begründung: Enthält das vollständige, kombinierte Filterprädikat.
+Prüfidee:      Eine bezahlte (Completed) Rechnung erscheint nicht im Mahnlauf, auch wenn ihr DueDate in der Vergangenheit liegt.
+Tracelinks:    StRS-001, SwRS-001
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Regel ist fachlich korrekt und muss im Zielsystem erhalten bleiben.
+Status:        belegt
+```
+
+```
+ID:            SyRS-002
+Titel:         Mahnstufen-Zustandsautomat mit Rücksetzfunktion
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Eine Rechnung befindet sich in einer Mahnstufe ungleich None.
+Fakt:          DunningRunBL.ResetDunningRun() kehrt die Stufenerhöhung exakt um (Level3→Level2→Level1→None), löscht die zugehörigen Datums-/Bearbeiterfelder und markiert den zugehörigen DunningRunItem als gelöscht, alles innerhalb einer Transaktionsklammer (StartTransaction/CommitTransaction/RollbackTransaction).
+Aussage:       Das System muss eine transaktional abgesicherte Rücksetzfunktion für Mahnstufen bereitstellen, die den Zustand exakt symmetrisch zur Erhöhung zurückführt und bei einem bereits auf None stehenden Datensatz eine Ausnahme wirft statt stillschweigend nichts zu tun.
+Ergebnis:      Mahnstufe und zugehörige Metadaten sind nach Rücksetzung konsistent mit dem Zustand vor der letzten Erhöhung.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs, Methode ResetDunningRun - Begründung: Enthält den transaktional abgesicherten, durchgesetzten Rücksetzautomaten.
+Prüfidee:      Rücksetzung einer Rechnung auf Mahnstufe None wirft eine ArgumentOutOfRangeException.
+Tracelinks:    StRS-001, SwRS-002, SwRS-003
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-003
+Titel:         Schreibfreie Auswertungsfunktion für offene Posten
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  OPOS-Lauf wird ausgeführt.
+Fakt:          OposRunBL.ExecuteOposRun() ruft für SendType nur Mail/Print unterstützend auf; None/Fax führen zu ArgumentException; anders als DunningRunBL wird keine Transaktionsklammer für eine Zustandsänderung geöffnet.
+Aussage:       Das System muss die OPOS-Auswertung als reinen Lesevorgang implementieren, der ausschließlich Mail- oder Druckversand als Auslieferungsweg unterstützt und unter keinen Umständen den Rechnungszustand verändert.
+Ergebnis:      Kontoauszug wird per Mail oder Druck ausgeliefert, Rechnungsdaten bleiben unverändert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposRunBL.cs, Methode ExecuteOposRun - Begründung: Belegt die auf Mail/Print begrenzte, zustandsfreie Auslieferung.
+Prüfidee:      Ein OPOS-Lauf mit SendType=Fax schlägt mit ArgumentException fehl.
+Tracelinks:    StRS-002, SwRS-004
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-004
+Titel:         Terminierung der Folgeabrechnung bei automatischer Vertragsfacturierung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Vertrag mit ContractCalculationKind.Auto wird abgerechnet.
+Fakt:          StoreInvoiceToContract() plant den Folgetermin abhängig von BillingIntervalKind/-Duration; für BillingKinds.Billingarrear wird der Termin über NextDate(contract) berechnet statt über die Standardintervall-Addition.
+Aussage:       Das System muss nach jeder automatischen Vertragsabrechnung einen Folgetermin gemäß dem konfigurierten Abrechnungsintervall setzen und dabei nachträgliche Abrechnung ("Billingarrear") mit einer eigenen Terminberechnung behandeln.
+Ergebnis:      ToDo-Eintrag mit korrektem Folgeabrechnungstermin.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, Methode StoreInvoiceToContract - Begründung: Enthält die durchgesetzte Terminierungslogik inkl. Sonderfall Billingarrear.
+Prüfidee:      Ein nachträglich abgerechneter Vertrag (Billingarrear) erhält einen anderen Folgetermin als ein vorschüssig abgerechneter Vertrag mit gleichem Intervall.
+Tracelinks:    StRS-003, SwRS-005, SwRS-006
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-005
+Titel:         Sechsfache Vorbedingungsprüfung vor Rechnungsstorno
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Stornoanfrage für eine Rechnung liegt vor.
+Fakt:          ReceiptInvoiceBL.CancelInvoice() prüft der Reihe nach: Recht RIGHT_RECHNUNGSTORNIEREN, State!=Canceled, !IsCashAsset, keine ForwardedInto-Einträge, !IsReceiptExported, bei Vertragsrechnung IsLastContractInvoice; jede Verletzung liefert eine spezifische Fehlermeldung als Result.AsError.
+Aussage:       Das System muss vor jeder Rechnungsstornierung alle sechs Bedingungen unabhängig voneinander prüfen und bei Verletzung einer beliebigen Bedingung die Stornierung mit einer für den Anwender verständlichen, bedingungsspezifischen Fehlermeldung verweigern.
+Ergebnis:      Rechnung wird nur storniert, wenn alle sechs Bedingungen erfüllt sind.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs, Methode CancelInvoice - Begründung: Enthält alle sechs durchgesetzten Prüfungen im Klartext.
+Prüfidee:      Storno einer Barrechnung (IsCashAsset=true) wird mit "...Barrechnung..." abgelehnt, unabhängig vom Zustand der übrigen fünf Bedingungen.
+Tracelinks:    StRS-004, SwRS-007, SwRS-008
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-006
+Titel:         Optimistische Sperre und Storno-Schutz bei Zahlungsverbuchung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein Zahlbetrag wird einer Rechnung zugeordnet oder entfernt.
+Fakt:          ReceiptBL.UpdateReceiptIsPaid() vergleicht bei übergebenem concurrencyControlGuid diesen gegen receipt.ConcurrencyControlGuid und liefert bei Abweichung DefaultMessageCodes.ChangedByOtherInstance; State==Canceled führt unabhängig davon zu sofortiger Ablehnung.
+Aussage:       Das System muss gleichzeitige Änderungen an einer Rechnung durch eine GUID-basierte optimistische Sperre erkennen und explizit als "durch andere Instanz geändert" kennzeichnen, und muss unabhängig davon jede Zahlungszuordnung zu einer stornierten Rechnung verhindern.
+Ergebnis:      Keine widersprüchlichen Zahlungsbuchungen bei parallelem Zugriff; keine Zahlungszuordnung zu stornierten Rechnungen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Methode UpdateReceiptIsPaid - Begründung: Enthält beide durchgesetzten Schutzmechanismen.
+Prüfidee:      Zwei parallele Zahlungsbuchungen auf derselben Rechnung mit veralteter ConcurrencyControlGuid führen bei der zweiten zu ChangedByOtherInstance.
+Tracelinks:    StRS-005, SwRS-009, SwRS-010
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-007
+Titel:         Fehlertolerante Batch-Berechnung von Vertragsenddaten
+Ebene:         SyRS
+Typ:           Zuverlässigkeit
+Qualitätsmerkmal: Zuverlässigkeit
+Akteur:        System
+Vorbedingung:  Batchlauf zur Aktualisierung aller aktiven Vertragsenddaten wird gestartet.
+Fakt:          RefreshContractEndeDate() überspringt Verträge mit fehlenden Basisdaten (Beginn/LaufzeitArt/LaufzeitDauer) statt eine Exception zu werfen, die den gesamten Batchlauf abbrechen würde (Kommentar im Code bestätigt dies als bewusste Entscheidung).
+Aussage:       Das System muss bei der Batch-Berechnung von Vertragsenddaten einzelne unvollständig gepflegte Verträge überspringen und zur Nachpflege kennzeichnen, ohne dass dies den Abschluss des Gesamtlaufs für alle übrigen Verträge verhindert.
+Ergebnis:      Alle vollständig gepflegten Verträge erhalten ein aktuelles Enddatum; unvollständige Verträge werden separat ausgewiesen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs, Methode RefreshContractEndeDate - Begründung: Enthält das durchgesetzte Skip-Verhalten.
+Prüfidee:      Ein Vertrag ohne LaufzeitArt beendet den Batchlauf nicht; alle übrigen Verträge werden dennoch aktualisiert.
+Tracelinks:    StRS-006, SwRS-011
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-008
+Titel:         Validierung von Zeiterfassungen und Berechnung der Pauschalsumme
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Eine Zeiterfassung wird gespeichert bzw. ein Pauschalauftrag wird berechnet.
+Fakt:          TimerBillingBL.SaveTimer() wirft ResultException bei Stop<Start; FlatRateProjectViewModel summiert Price*QuantityDisplay ausschließlich über Top-Level-Positionen (Indent==0) mit BlanketMaterialGroup.
+Aussage:       Das System muss Zeiterfassungen mit negativer Dauer strukturell verhindern und die Pauschalsumme ausschließlich aus den vorgesehenen Top-Level-Positionen einer Blanket-Materialgruppe bilden, ohne Unterpositionen doppelt zu berücksichtigen.
+Ergebnis:      Keine negativen Zeiterfassungen im System; korrekte, nicht doppelt gezählte Pauschalsumme.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs, Methode SaveTimer - Begründung: Enthält die durchgesetzte Validierung.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Finances/FlatrateBilling/FlatRateProjectViewModel.cs - Begründung: Enthält die durchgesetzte Summenformel.
+Prüfidee:      Eine Unterposition (Indent>0) einer Blanket-Materialgruppe fließt nicht separat in die Pauschalsumme ein.
+Tracelinks:    StRS-007, SwRS-012, SwRS-013
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-009
+Titel:         Feingranulare, richtlinienbasierte Zugriffskontrolle auf Zugangsdaten
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein Mitarbeiter greift auf Kundenzugangsdaten zu.
+Fakt:          PasswordManagerGuidelineRights ist ein [Flags]-Enum mit acht unabhängigen Einzelrechten (SealBreak, SealingAllowed, AccessDataEditable, AccessDataVisible, VPNAccessesEditable, TwoFactorAuthentification, Notification, AccessDataDeletable); GetAvailableGuidelinesForEmployee() wertet diese serverseitig zusätzlich zeitlich befristet (LimitedValidityDateFrom/Until) und kundenbezogen aus.
+Aussage:       Das System muss den Zugriff auf Kundenzugangsdaten anhand von acht unabhängig kombinierbaren, serverseitig geprüften Einzelrechten je Kunde und optional zeitlich befristet steuern.
+Ergebnis:      Zugriff wird exakt im Rahmen der zugewiesenen, ggf. befristeten Richtlinien gewährt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.Interfaces/PasswordManager/PasswordManagerGuidelineRights.cs - Begründung: Enthält die durchgesetzte Flags-Enumeration.
+  - [PRIMÄR]   src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Methode GetAvailableGuidelinesForEmployee - Begründung: Enthält die serverseitig durchgesetzte, zeitlich befristbare Scoping-Logik.
+Prüfidee:      Nach Ablauf von LimitedValidityDateUntil verliert ein Mitarbeiter automatisch den Zugriff auf die betroffene Kundenkategorie.
+Tracelinks:    StRS-008, StRS-009, SwRS-014, SwRS-015
+Konsolidierung: nein
+Übernahmewürdigkeit: Sonderfall - siehe StRS-008.
+Status:        belegt
+```
+
+```
+ID:            SyRS-010
+Titel:         Automatische Löschung sensibler Daten aus der Zwischenablage
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Sicherheit
+Akteur:        System
+Vorbedingung:  Ein Passwort wurde in die Zwischenablage kopiert.
+Fakt:          AccessManagementViewModel.CopyPasswordToClipboard() setzt einen Task.Delay(TimeSpan.FromSeconds(12)) zur automatischen Leerung der Zwischenablage.
+Aussage:       Das System muss ein in die Zwischenablage kopiertes Passwort spätestens nach 12 Sekunden automatisch wieder entfernen, um versehentliches Einfügen an unbeabsichtigter Stelle nach Ablauf der Nutzungssituation zu verhindern.
+Ergebnis:      Zwischenablage enthält 12 Sekunden nach dem Kopiervorgang kein Klartextpasswort mehr.
+Belege:
+  - [PRIMÄR]   src/shared/Centron.Controls/PasswordManager/AccessManagementViewModel.cs, Methode CopyPasswordToClipboard - Begründung: Enthält den durchgesetzten Timer.
+Prüfidee:      13 Sekunden nach Kopieren eines Passworts ist die Zwischenablage leer.
+Tracelinks:    StRS-008, SwRS-016
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-011
+Titel:         Boolesch kombinierbare Rechteprüfung zur Modulfreischaltung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Benutzer meldet sich an; Module werden registriert.
+Fakt:          ModuleRightsExpressionParser unterstützt AND/OR/NOT-verknüpfte Rechteausdrücke (HasRights, HasAnyRight, NoRightCheck); ModuleRegistration.DoRegisterCentronModules() wendet CheckModuleFeatures() (Lizenz) UND CheckRights() (Recht) kumulativ an.
+Aussage:       Das System muss die Sichtbarkeit jedes Moduls anhand einer booleschen Kombination von Rechten UND einer unabhängigen Lizenzprüfung bestimmen; beide Bedingungen müssen erfüllt sein, damit ein Modul registriert wird.
+Ergebnis:      Ein Modul erscheint nur, wenn sowohl Rechte- als auch Lizenzprüfung positiv ausfallen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRightsExpressionParser.cs - Begründung: Enthält die durchgesetzte Ausdrucksauswertung.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Methode DoRegisterCentronModules - Begründung: Enthält die kumulative Verknüpfung von Recht und Lizenz.
+Prüfidee:      Ein Benutzer mit passendem Recht aber ohne Lizenz sieht das Modul nicht.
+Tracelinks:    StRS-010, SwRS-017
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-012
+Titel:         Session-weites Caching der Benutzerrechte
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Performanz-Effizienz
+Akteur:        System
+Vorbedingung:  Benutzer ist eingeloggt.
+Fakt:          CentronCache.RefreshCacheAsync() lädt CurrentUserAppRights einmalig bei Login (und nach Einstellungsänderungen) und hält sie im Session-Cache; nachfolgende Prüfungen (ModuleRegistration.IsModuleAvailable, SettingsContainerViewModel u. a.) lesen ausschließlich aus diesem Cache statt bei jeder Prüfung den Server erneut abzufragen.
+Aussage:       Das System soll die Benutzerrechte einmal je Session laden und clientseitig zwischenspeichern, um wiederholte Serveranfragen bei jeder einzelnen Rechteprüfung zu vermeiden, und den Cache gezielt nach relevanten Änderungen aktualisieren.
+Ergebnis:      Rechteprüfungen erfolgen ohne zusätzlichen Netzwerk-Roundtrip pro Prüfung.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Administration/Cache/CentronCache.cs, Methode RefreshCacheAsync - Begründung: Enthält den durchgesetzten Caching-Mechanismus.
+Prüfidee:      Eine Rechteänderung wird erst nach explizitem Cache-Refresh (z. B. nach erneutem Login) client-seitig wirksam.
+Tracelinks:    StRS-010, SwRS-018
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Cache-Invalidierung bei Live-Rechteänderung ist im Zielsystem zu prüfen (aktuelles Verhalten: verzögert bis Refresh).
+Status:        belegt
+```
+
+```
+ID:            SyRS-013
+Titel:         Mandantenbezogene Vergabe von Belegnummernkreisen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein neuer Beleg (z. B. Rechnung) wird für eine Filiale erzeugt.
+Fakt:          MandatoryBL.GetNumberGroup()/GetNumberGroupsForBranch() lösen den Nummernkreis über die Filiale-Mandant-Zuordnung auf, mit Fallback auf den Standardmandanten, falls die Filiale keinem spezifischen Mandanten zugeordnet ist.
+Aussage:       Das System muss jedem neu erzeugten Beleg den Nummernkreis des Mandanten zuordnen, dem die auslösende Filiale zugeordnet ist, und bei fehlender Zuordnung auf den Standardmandanten zurückfallen.
+Ergebnis:      Belegnummer stammt aus dem korrekten, mandantenspezifischen Nummernkreis.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs, Methode GetNumberGroup - Begründung: Enthält die durchgesetzte Fallback-Logik.
+Prüfidee:      Eine Rechnung aus einer Filiale ohne explizite Mandantenzuordnung erhält eine Nummer aus dem Nummernkreis des Standardmandanten.
+Tracelinks:    StRS-011, SwRS-019
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        HYPOTHESE
+```
+
+```
+ID:            SyRS-014
+Titel:         Getrennte Rechte für Massenbereinigung und gezielte Kontaktlöschung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  DSGVO-Modul ist lizenziert und geöffnet.
+Fakt:          CentronDataSecurityViewModel berechnet HasDatabaseCleanupRight und HasContactDeleteRight unabhängig voneinander aus zwei verschiedenen UserRightsConst.DsgvoModule-Konstanten; jedes der beiden Kommandos (CanRefresh/CanDeleteSelection vs. CanAnonymizeContactPerson) ist an genau eines der beiden Rechte gebunden.
+Aussage:       Das System muss die Berechtigung zur alters-/fristbasierten Massenbereinigung und die Berechtigung zur gezielten Löschung einzelner Kontakte als zwei unabhängig vergebbare Rechte führen.
+Ergebnis:      Ein Mitarbeiter kann eines der beiden Rechte besitzen, ohne automatisch das andere zu erhalten.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Administration/DSGVO/CentronDataSecurityViewModel.cs, Konstruktor - Begründung: Enthält die durchgesetzte getrennte Rechteauswertung.
+Prüfidee:      Ein Mitarbeiter mit nur HasContactDeleteRight kann keine Massenbereinigung starten.
+Tracelinks:    StRS-012, SwRS-020
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-015
+Titel:         Auswahl des Authentifizierungsverfahrens je Installation
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Sicherheit
+Akteur:        System
+Vorbedingung:  Anmeldeversuch eines Benutzers.
+Fakt:          AuthenticatorFactory wählt anhand der konfigurierten SystemAuthenticationMethod (None/Basic/ActiveDirectory/OpenIdConnect, aus AppSettingsGroupBL.GetAuthenticationSettings()) den konkreten Authenticator, optional mit FallbackAuthenticator-Verkettung.
+Aussage:       Das System muss je Installation genau ein konfiguriertes primäres Authentifizierungsverfahren verwenden und darf optional ein Fallback-Verfahren verketten, ohne dass der Anwender das Verfahren pro Login manuell wählt.
+Ergebnis:      Anmeldung erfolgt konsistent über das für die Installation konfigurierte Verfahren.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/Auth/AuthenticatorFactory.cs - Begründung: Enthält die durchgesetzte Verfahrensauswahl.
+Prüfidee:      Eine Installation mit SystemAuthenticationMethod=ActiveDirectory lehnt einen reinen Benutzername/Passwort-Login gegen die lokale AppUser-Tabelle ab (sofern kein Fallback konfiguriert ist).
+Tracelinks:    StRS-013, SwRS-021
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Auswahlmechanismus bleibt, konkretes Basic-Verfahren ist zu ersetzen (siehe StRS-013).
+Status:        belegt
+```
+
+```
+ID:            SyRS-016
+Titel:         Serverseitige Validierung und Ausstellung eines Auth-Tickets
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Sicherheit
+Akteur:        System (Webservice)
+Vorbedingung:  Ein API-Aufruf trägt ein Ticket im access_token-Query-Parameter oder Authorization-Header.
+Fakt:          TicketAuthenticationHandler extrahiert das Token und validiert es über AuthenticationTicketBL.GetAuthTicketInfo(token, ipAddress, apiMethod); bei Erfolg wird ein ClaimsPrincipal mit NameIdentifier, UserIdentifier und AuthenticationTypeIdentifier (unterscheidet "Ticket" von persistentem "AccessToken") gebildet.
+Aussage:       Das System muss jeden Webservice-Aufruf gegen ein serverseitig gültiges, IP- und methodenbezogen geprüftes Auth-Ticket validieren und zwischen kurzlebigen Login-Tickets und persistenten Zugriffstoken unterscheiden.
+Ergebnis:      Nur Aufrufe mit gültigem Ticket werden verarbeitet; Art des Tokens ist im Sicherheitskontext nachvollziehbar.
+Belege:
+  - [PRIMÄR]   src/webservice/Centron.Host/AspNetCore/TicketAuthenticationHandler.cs - Begründung: Enthält die durchgesetzte Validierung.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/AuthenticationTicketBL.cs, Methode GetAuthTicketInfo - Begründung: Enthält die serverseitige Ticketprüfung.
+Prüfidee:      Ein Aufruf mit abgelaufenem/ungültigem Ticket wird mit 401 abgelehnt.
+Tracelinks:    StRS-013, SwRS-022
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-017
+Titel:         Mengen- und zeitbegrenzte Lizenzprüfung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Eine lizenzpflichtige Funktion wird aufgerufen.
+Fakt:          LicenseManager.Instance.HasLicense(guid)/GetLicenseCount(guid) prüfen neben dem reinen Besitz einer Lizenz-GUID auch count, valid-until-date und valid-until-version.
+Aussage:       Das System muss bei jeder lizenzpflichtigen Funktion neben dem Besitz der Lizenz auch deren Mengenbegrenzung, zeitliche und versionsbezogene Gültigkeit prüfen und die Funktion bei Überschreitung verweigern.
+Ergebnis:      Lizenzpflichtige Funktionen sind nur innerhalb der vereinbarten Menge/Gültigkeit nutzbar.
+Belege:
+  - [PRIMÄR]   docs/reference/security/licensing-system.md - Begründung: Beschreibt die durchgesetzte, mehrdimensionale Lizenzprüfung mit Codebeispiel.
+Prüfidee:      Der vierte Import-Vorgang bei einer auf 3 begrenzten Lizenz (z. B. MyDayImports) wird verweigert.
+Tracelinks:    StRS-014, SwRS-023
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-018
+Titel:         Pessimistische Ticketsperre mit Zwangsentsperrung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein Ticket ist von einem anderen Mitarbeiter geöffnet und gesperrt.
+Fakt:          TicketLogicHelper.GetTicketAndPromptUnlock() zeigt bei TicketIsLocked==true einen Ja/Nein-Dialog mit dem aufgelösten Kurzzeichen des sperrenden Mitarbeiters und bietet erzwungenes Entsperren an.
+Aussage:       Das System muss ein gesperrtes Ticket eindeutig als solches kennzeichnen, den sperrenden Mitarbeiter benennen und dem zweiten Anwender die bewusste Entscheidung zum Zwangsentsperren überlassen, statt automatisch zu entsperren.
+Ergebnis:      Kein stillschweigender Verlust von Bearbeitungen durch gleichzeitigen Zugriff.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketLogicHelper.cs, Methode GetTicketAndPromptUnlock - Begründung: Enthält den durchgesetzten Sperrdialog.
+Prüfidee:      Ein zweiter Mitarbeiter erhält beim Öffnen eines gesperrten Tickets den Namen des Sperrenden angezeigt.
+Tracelinks:    StRS-015, SwRS-024, SwRS-025
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-019
+Titel:         Dashboard-Kennzeichnung SLA-relevanter, fälliger Tickets
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Offene Tickets mit Fälligkeitsdatum liegen vor.
+Fakt:          TicketDueDateDashboardContainerViewModel.CalculateGroups() bildet drei Gruppen (Überfällig, In4Stunden, Heute) und filtert optional auf IsSLA==true.
+Aussage:       Das System muss offene Tickets nach ihrem zeitlichen Abstand zur Fälligkeit in mindestens drei Dringlichkeitsstufen gruppieren und eine Filterung auf SLA-relevante Tickets ermöglichen.
+Ergebnis:      Dashboard zeigt Anzahl der Tickets je Dringlichkeitsstufe.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Helpdesk/Dashboard/TicketDueDate/TicketDueDateDashboardContainerViewModel.cs, Methode CalculateGroups - Begründung: Enthält die durchgesetzte Gruppierung.
+Prüfidee:      Ein SLA-Ticket mit DueDate in 2 Stunden erscheint in der Gruppe "In4Stunden".
+Tracelinks:    StRS-016, SwRS-026
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - siehe StRS-016.
+Status:        HYPOTHESE
+```
+
+```
+ID:            SyRS-020
+Titel:         Zustandsgesteuerte RMA-Rückführung mit Pflichtfeldern je Aktion
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein RMA-Artikel kommt vom Lieferanten zurück (SendForth).
+Fakt:          SendForthViewModel.CheckForthState() erzwingt: jede Position benötigt eine gewählte RmaForthAction; EqualChange auf seriennummerpflichtigem Artikel erfordert eine Austauschseriennummer; ForeignChange erfordert Ersatzartikelcode und ggf. Barcode; Verschrottung eines bereits nicht-verschrotteten Artikels erfordert explizite Bestätigung.
+Aussage:       Das System muss vor dem Speichern einer RMA-Rückführung für jede betroffene Position eine gewählte Aktion sowie die je Aktion spezifischen Pflichtangaben (Austauschseriennummer, Ersatzartikelcode, Barcode) erzwingen und darf ohne diese Angaben nicht speichern.
+Ergebnis:      RMA-Rückführung ist nur mit vollständigen, aktionsspezifischen Angaben speicherbar.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Rma/SendForth/SendForthViewModel.cs, Methode CheckForthState - Begründung: Enthält alle durchgesetzten Pflichtfeldregeln.
+Prüfidee:      ForeignChange ohne Ersatzartikelcode wird mit "Speichern ist unmöglich" abgelehnt.
+Tracelinks:    StRS-018, SwRS-028
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-021
+Titel:         Unveränderlichkeit zentraler Felder nach RMA-Rückführungsspeicherung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Eine neue RMA-Rückführung (IsNewForth) wurde erfolgreich gespeichert.
+Fakt:          SendForthViewModel.Save() setzt nach erfolgreicher Erstspeicherung IsNewForth=false und sperrt Menge, Aktion und Ziellager gegen weitere Änderung; ein expliziter Bestätigungsdialog weist vor dem Speichern darauf hin.
+Aussage:       Das System muss die Felder Menge, Aktion und Ziellager einer RMA-Rückführung nach der ersten erfolgreichen Speicherung unveränderlich machen und den Anwender vor dem Speichern explizit auf diese Konsequenz hinweisen.
+Ergebnis:      Nachträgliche Manipulation bereits abgeschlossener RMA-Rückführungen ist ausgeschlossen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Rma/SendForth/SendForthViewModel.cs, Methode Save - Begründung: Enthält die durchgesetzte Sperrung nach Erstspeicherung.
+Prüfidee:      Nach Speicherung einer neuen RMA-Rückführung ist das Mengenfeld nicht mehr editierbar.
+Tracelinks:    StRS-018, SwRS-029
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-022
+Titel:         Doppelte Rechteprüfung zum Öffnen der Artikelverwaltung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein Anwender versucht, das Modul Artikelverwaltung zu öffnen.
+Fakt:          ArticleManagementAppModuleController.CreateModuleInstance() prüft CentronCache.Instance.CurrentUserAppRights.Any(f=>f.I3D==UserRightsConst.Purchase.ID) UND zusätzlich UserRightsConst.Purchase.StockList.ID; fehlt eines der beiden Rechte, wird das Modul mit Dialog "Sie haben kein Recht..." verweigert und die Instanz-Erzeugung liefert null.
+Aussage:       Das System muss das Öffnen der Artikelverwaltung an den gleichzeitigen Besitz zweier unabhängiger Rechte binden und bei Fehlen eines der beiden Rechte das Modul gar nicht erst instanziieren.
+Ergebnis:      Nur Anwender mit beiden Rechten können die Artikelverwaltung öffnen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleManagement/Controller/ArticleManagementAppModuleController.cs - Begründung: Enthält die durchgesetzte doppelte Rechteprüfung.
+Prüfidee:      Ein Anwender mit nur Purchase.ID (ohne StockList.ID) kann die Artikelverwaltung nicht öffnen.
+Tracelinks:    StRS-019, SwRS-030
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-023
+Titel:         Zwei alternative Preisumrechnungsstrategien bei Steuersatzwechsel
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Alle Artikel eines Steuersatzes werden auf dessen Folgesatz umgestellt.
+Fakt:          ValueAddedTaxViewModel.UpdateArticles() bietet zwei sich gegenseitig ausschließende Formeln: updatedGrossPrice = currentNetPrice*(1+neuerSatz/100) (Netto konstant) oder updatedNetPrice = currentGrossPrice/(1+neuerSatz/100) (Brutto konstant); die Wahl trifft der Anwender vor Ausführung.
+Aussage:       Das System muss dem Anwender vor der Massenumrechnung von Artikelpreisen bei Steuersatzwechsel die explizite Wahl zwischen "Netto konstant" und "Brutto konstant" anbieten und die gewählte Formel konsistent auf alle betroffenen Artikel anwenden.
+Ergebnis:      Alle umgestellten Artikel folgen konsistent derselben gewählten Umrechnungsstrategie.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Warehousing/ValueAddedTaxViewModel.cs, Methode UpdateArticles - Begründung: Enthält beide durchgesetzten Formeln.
+Prüfidee:      Bei Wahl "Netto konstant" bleibt der Nettopreis aller umgestellten Artikel exakt gleich.
+Tracelinks:    StRS-020, SwRS-032
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-024
+Titel:         Mehrstufige, priorisierbare Lieferantenauswahl im Bestellvorschlag
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Mehrere Distributoren führen denselben Artikel.
+Fakt:          GetDistributorI3D() kombiniert bis zu drei vom Anwender priorisierte Kriterien (Preis, Verfügbarkeit, A-/B-/C-Lieferant) sequentiell zur Lieferantenauswahl.
+Aussage:       Das System muss die automatische Lieferantenauswahl anhand von bis zu drei vom Anwender frei priorisierbaren Kriterien treffen, wobei das erste erfüllte Kriterium in der Prioritätsreihenfolge entscheidet.
+Ergebnis:      Automatisch vorgeschlagener Lieferant je Artikel gemäß Kriterienpriorität.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Purchasing/OrderSuggestionList/OrderSuggestionListViewModel.cs, Methode GetDistributorI3D - Begründung: Enthält die durchgesetzte, dreistufige Auswahllogik.
+Prüfidee:      Bei Priorität [Preis, Verfügbarkeit, A-Kriterium] wird bei Preisgleichstand zweier Lieferanten der mit höherer Verfügbarkeit gewählt.
+Tracelinks:    StRS-021, SwRS-034
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-025
+Titel:         Abweichungsklassifikation und Übernahmesperre bei EDI-Belegen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein EDI-Beleg (Auftragsbestätigung/Lieferschein/Rechnung) wurde empfangen.
+Fakt:          EDIManagementViewModel.ReceipAccetAsync() verweigert die Übernahme, solange keine einzige Position ein RelationState!=None trägt; jede Position ist über EDIPositionRelationState als Kombination aus Mengen-, Preis-, Termin- und Barcode-Abweichung klassifiziert.
+Aussage:       Das System muss jede EDI-Position gegen die zugehörige Bestellposition abgleichen, Abweichungen kombinierbar kennzeichnen und die Übernahme eines EDI-Belegs verweigern, wenn keine seiner Positionen einem Bestelldatensatz zugeordnet werden konnte.
+Ergebnis:      Nur zugeordnete EDI-Belege werden übernommen; Abweichungen sind je Position sichtbar.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Purchasing/EDIManagement/EDIManagementAppViewModel.cs, Methode ReceipAccetAsync - Begründung: Enthält die durchgesetzte Übernahmesperre.
+Prüfidee:      Ein EDI-Beleg, dessen Positionen alle RelationState=None tragen, kann nicht akzeptiert werden.
+Tracelinks:    StRS-022, SwRS-035
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-026
+Titel:         Granularer Inventurabschluss nach Umfang und Lagerort
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Eine Inventursitzung ist im Zustand Open/OpenWithoutBC.
+Fakt:          Der Inventurabschluss kombiniert FinalizeInventoryEnum (Partial/PartialAllStorages/Complete/CompleteAllStorages) mit FinalizeStorageEnum (AllStorages/SelectedStorages) zu einer zweidimensionalen Abschlussoption.
+Aussage:       Das System muss den Inventurabschluss als Kombination aus Abschlussumfang (vollständig/teilweise) und Lagerortauswahl (alle/ausgewählte) anbieten und den Zustand der Inventur entsprechend der gewählten Kombination korrekt fortschreiben.
+Ergebnis:      Inventurzustand spiegelt exakt den gewählten Abschlussumfang wider.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Warehousing/Inventory/Enums/FinalizeInventoryEnum.cs, FinalizeStorageEnum.cs - Begründung: Enthalten die durchgesetzten Optionskombinationen.
+Prüfidee:      Ein Teilabschluss für ausgewählte Lagerorte lässt nicht ausgewählte Lagerorte im Zustand Open.
+Tracelinks:    StRS-023, SwRS-036
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-027
+Titel:         Erzeugung DATEV-konformer Exportpakete je Beleg
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Belege sind für den DATEV-Online-Export ausgewählt.
+Fakt:          DatevOnlineViewModel.Export() erzeugt je Beleg ein ZIP mit package.xml (LedgerXML), document.xml (DocumentXML) und angehängtem PDF; bereits vorhandene PDF-Dokumente werden anhand des Dateinamens (externe Belegnummer) wiederverwendet statt neu erzeugt.
+Aussage:       Das System muss für jeden zu exportierenden Beleg ein vollständiges, in sich konsistentes DATEV-Exportpaket (Ledger- und Dokument-XML plus PDF) erzeugen und dabei bereits vorhandene PDF-Dokumente wiederverwenden, um Doppelgenerierung zu vermeiden.
+Ergebnis:      Importierbares ZIP-Paket je exportiertem Beleg.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Administration/DataExchange/DatevOnline2020/DatevOnlineViewModel.cs, Methode Export - Begründung: Enthält die durchgesetzte Paketerzeugung inkl. Wiederverwendungslogik.
+Prüfidee:      Ein bereits einmal exportierter Beleg erzeugt beim zweiten Export dasselbe PDF ohne erneute Reportgenerierung.
+Tracelinks:    StRS-024, SwRS-037
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-028
+Titel:         Erzeugung gültiger SEPA-Zahlungsdateien
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Fällige Lastschriften/Überweisungen sind zum Export ausgewählt.
+Fakt:          SepaFileGeneratorV2 erzeugt SEPA-pain.008-konforme XML-Dateien; PaymentTransactionViewModel unterscheidet IsBasicDirectDebit/IsCompanyDirectDebit als getrennte Lastschriftarten mit eigenem Exportformat.
+Aussage:       Das System muss SEPA-Zahlungsdateien im pain.008-Standardformat erzeugen und dabei zwischen privater und geschäftlicher Lastschrift als getrennte Exportvarianten unterscheiden.
+Ergebnis:      Bei der Bank einreichbare, standardkonforme SEPA-Datei.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.Gateway/DataExchange/PaymentTransactions/Sepa/SepaFileGeneratorV2.cs - Begründung: Enthält die durchgesetzte Dateierzeugung.
+Prüfidee:      Eine gemischte Auswahl aus privaten und geschäftlichen Lastschriften erzeugt zwei getrennte Exportdateien bzw. Sequenzen.
+Tracelinks:    StRS-025, SwRS-038, SwRS-039
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-029
+Titel:         Protokollunabhängiger Abruf externer Produktdaten
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein Artikel soll mit Daten einer externen Quelle angereichert werden.
+Fakt:          Sechs unterschiedliche Protokolle sind im Einsatz: SOAP (COP), XML-über-HTTP (EGIS), REST/XML (ITscope, Basic-Auth), REST/XML (Icecat, Basic-Auth ISO-8859-1-kodiert).
+Aussage:       Das System muss externe Produktdatenquellen trotz unterschiedlicher Protokolle (SOAP, proprietäres XML-über-HTTP, REST/XML) einheitlich in den Artikelstamm einspielen können.
+Ergebnis:      Angereicherte Artikeldaten unabhängig von der Quelle einheitlich nutzbar.
+Belege:
+  - [PRIMÄR]   src/apis/Centron.APIs.IcecatDataAccess/IcecatApi.cs - Begründung: Belegt exemplarisch die REST/XML-Anbindung mit Basic-Auth.
+Prüfidee:      Eine Artikelanreicherung über Icecat und eine über ITscope liefern beide vollständige Produktbeschreibungen im internen DTO-Format.
+Tracelinks:    StRS-026, SwRS-040
+Konsolidierung: Kandidat: siehe StRS-026.
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-030
+Titel:         Erzeugung von Versandlabels über zwei parallele Carrier-Anbindungen
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein Lieferschein ist versandfertig.
+Fakt:          CentronGlsLogic.UploadShipment() und CentronShipcloudLogic erzeugen jeweils eigenständig ein Versandlabel/Tracking über REST, mit unterschiedlicher Authentifizierung (Basic Auth mit fest hinterlegtem Secret bei GLS, Base64-kodierter API-Key bei Shipcloud).
+Aussage:       Das System muss Versandlabels wahlweise über die GLS- oder die Shipcloud-Anbindung erzeugen können und dem Lieferschein die resultierende Trackingnummer zuordnen.
+Ergebnis:      Lieferschein trägt eine gültige Trackingnummer des gewählten Versanddienstleisters.
+Belege:
+  - [PRIMÄR]   src/apis/Centron.Api.Gls/CentronGlsLogic.cs, Methode UploadShipment - Begründung: Enthält die durchgesetzte Label-Erzeugung.
+Prüfidee:      Ein Lieferschein mit GLS-Versandart erhält nach Labelerzeugung eine gültige GLS-Trackingnummer.
+Tracelinks:    StRS-027, SwRS-041
+Konsolidierung: Kandidat: siehe StRS-027.
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-031
+Titel:         Konvertierung von Adressen zu vollwertigen Kunden
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Eine Adresse ohne Kundenstatus existiert.
+Fakt:          AccountManagementAppModuleController stellt eine dedizierte Suche nach "noch nicht konvertierten Adressen" bereit, getrennt von der allgemeinen CRM-Adressverwaltung.
+Aussage:       Das System muss zwischen reinen Adressdatensätzen und vollwertigen Kunden unterscheiden und einen expliziten Konvertierungsschritt anbieten, statt jede Adresse automatisch als Kunde zu behandeln.
+Ergebnis:      Adresse wird erst nach explizitem Konvertierungsschritt als Kunde in allen Folgeprozessen (Belege, CRM) nutzbar.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Finances/AccountManagement/AccountManagementAppModuleController.cs - Begründung: Bestätigt die durchgesetzte Trennung Adresse/Kunde.
+Prüfidee:      Eine reine Adresse ohne Kundenstatus kann keinem Beleg als Rechnungsempfänger zugeordnet werden.
+Tracelinks:    StRS-028, SwRS-042
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-032
+Titel:         Gegenseitig exklusive Eingabefelder bei Preis-Massenänderung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Anwender gibt eine prozentuale oder fixe Preisänderung ein.
+Fakt:          UpdateArticlePricesViewModel löscht beim Setzen eines Prozentwerts automatisch den korrespondierenden Fixwert (EkPercentageRaise↔EkFixRaise, VkPercentageRaise↔VkFixRaise) und umgekehrt.
+Aussage:       Das System muss prozentuale und fixe Preisanpassungswerte je Preisart als gegenseitig exklusiv behandeln und bei Eingabe des einen automatisch den anderen zurücksetzen, um widersprüchliche gleichzeitige Anwendung zu verhindern.
+Ergebnis:      Zu jedem Zeitpunkt ist je Preisart nur eine Anpassungsart aktiv.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Massenupdates/Updates/PriceUpdates/ArticleUpdate/UpdateArticlePricesViewModel.cs - Begründung: Enthält die durchgesetzte gegenseitige Exklusivität.
+Prüfidee:      Eingabe eines Fixwerts nach vorherigem Prozentwert löscht den Prozentwert automatisch.
+Tracelinks:    StRS-029, SwRS-043
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-033
+Titel:         Reversible Löschung von Kostenstellen und Kostenträgern
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Eine Kostenstelle/ein Kostenträger wird gelöscht.
+Fakt:          PayersAndCostCenterAppModuleControllerViewModel führt Löschung als Soft-Delete mit separatem Wiederherstellungskommando je Objektart (Kostenstelle, Kostenträger).
+Aussage:       Das System muss gelöschte Kostenstellen und Kostenträger als solche kennzeichnen statt physisch zu entfernen und eine Wiederherstellung ermöglichen.
+Ergebnis:      Gelöschte Objekte sind über einen Filter sichtbar und reaktivierbar.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter/PayersAndCostCenterAppModuleControllerViewModel.cs - Begründung: Enthält die durchgesetzten Soft-Delete-/Restore-Kommandos.
+Prüfidee:      Eine gelöschte Kostenstelle ist über den Filter "gelöschte anzeigen" sichtbar und lässt sich wiederherstellen.
+Tracelinks:    StRS-030, SwRS-044
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-034
+Titel:         Verknüpfung produktionsrelevanter Auftragspositionen mit Maschinen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein Auftrag enthält produktionsrelevante Artikel.
+Fakt:          ProductionOrderManagementViewModel verknüpft OrderWithProductionArticlesDTO mit ProductionOrderDTO und ordnet ProductionMachineDTO/ProductionMachineKindDTO zu.
+Aussage:       Das System muss produktionsrelevante Auftragspositionen automatisch als Fertigungsauftrag erkennbar machen und deren Zuordnung zu einer konkreten Maschine sowie den maschinenartspezifischen Produktionsschritten ermöglichen.
+Ergebnis:      Fertigungsauftrag mit Maschinenzuordnung und Produktionsschritten.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Production/ProductionOrder/ProductionOrderManagementViewModel.cs - Begründung: Enthält die durchgesetzte Verknüpfungslogik.
+Prüfidee:      Ein Auftrag mit produktionsrelevantem Artikel erscheint automatisch in der Fertigungsauftragsliste.
+Tracelinks:    StRS-031, SwRS-045
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-035
+Titel:         Statusfilterung und Änderungshistorie im Produktlebenszyklus
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Produktfamilien mit Lebenszyklusdaten sind gepflegt.
+Fakt:          PlmViewModel filtert nach ShowOnlyActive/ShowOnlyExpired/ShowOnlyDeactivated; PlmLogViewModel führt eine chronologische Änderungshistorie je Eintrag.
+Aussage:       Das System muss den Lebenszyklusstatus von Produktfamilien nach mindestens drei Zuständen filterbar machen und jede Statusänderung chronologisch protokollieren.
+Ergebnis:      Filterbare Produktfamilienliste mit vollständiger Änderungshistorie.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/PLM/PlmViewModel.cs - Begründung: Enthält die durchgesetzten Statusfilter.
+Prüfidee:      Eine deaktivierte Produktfamilie erscheint nur bei aktivem Filter ShowOnlyDeactivated.
+Tracelinks:    StRS-032, SwRS-046
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-036
+Titel:         Filial- und materialgruppenbezogene Management-Kennzahlen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Verkaufsdaten des gewählten Tages/Monats liegen vor.
+Fakt:          ManagementInfoViewModel lädt getrennte Kennzahlenkollektionen (Sales, Gain, OfferStock, OrderStock), filterbar nach SelectedBranches/SelectedMaterialGroups.
+Aussage:       Das System muss Umsatz-, Gewinn-, Angebots- und Auftragsbestandskennzahlen tages- und monatsbezogen bereitstellen und eine Filterung nach Filiale und Materialgruppe ermöglichen.
+Ergebnis:      Gefilterte Kennzahlenübersicht je gewähltem Zeitraum.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Statistics/ManagementInfo/ManagementInfoViewModel.cs - Begründung: Enthält die durchgesetzte Kennzahlenabfrage.
+Prüfidee:      Filterung auf eine einzelne Filiale reduziert die angezeigten Kennzahlen auf deren Umsätze.
+Tracelinks:    StRS-033, SwRS-047
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-037
+Titel:         Begrenzter, bestätigungspflichtiger Werkzeugzugriff des KI-Assistenten
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Sicherheit
+Akteur:        System
+Vorbedingung:  Der KI-Chat-Assistent führt einen mehrstufigen Dialog mit Werkzeugaufrufen.
+Fakt:          ArtificialIntelligenceChatCoordinator begrenzt Werkzeugrunden auf _maximumClientToolRounds=50 und leitet jede Werkzeugaktion durch einen IArtificialIntelligenceToolConfirmationService, bevor sie ausgeführt wird.
+Aussage:       Das System muss die Anzahl aufeinanderfolgender KI-Werkzeugaufrufe je Dialog hart begrenzen und jede datenverändernde Werkzeugaktion vor Ausführung einer expliziten Anwenderbestätigung unterziehen.
+Ergebnis:      KI-Assistent kann keine Endlosschleife von Werkzeugaufrufen auslösen und keine unbestätigten Datenänderungen vornehmen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ArtificialIntelligence/Chat/Harness/ArtificialIntelligenceChatCoordinator.cs - Begründung: Enthält beide durchgesetzten Schutzmechanismen.
+Prüfidee:      Ein vom KI-Assistenten vorgeschlagenes Löschen eines Datensatzes wird erst nach Bestätigungsdialog ausgeführt.
+Tracelinks:    StRS-034, SwRS-048
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-038
+Titel:         Tagesbezogene Aggregation von Tickets, Zeiten und Telefonie
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Mitarbeiter öffnet "Mein Tag".
+Fakt:          MyDayConnector wired mehrere Fachlogiken (Ticket, Timer, Employee, Department, MailTemplate) zu einer gemeinsamen Tagesansicht; TelephonyConnector bindet TAPI-Ereignisse (Call/AcceptCall/DeclineCall/DisconnectCall) inklusive Kontaktbildauflösung.
+Aussage:       Das System muss tagesbezogene Arbeitsdaten aus mehreren Fachdomänen (Tickets, Zeiten, Mitarbeiter) in einer Ansicht zusammenführen und eingehende Telefonanrufe mit aufgelöstem Kontaktbild in Echtzeit anzeigen.
+Ergebnis:      Konsolidierte Tagesübersicht; Anruferidentifikation in Echtzeit.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/MyCentron/MyDay/MyDayConnector.cs - Begründung: Enthält die durchgesetzte Aggregation.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/MyCentron/Telephony/TelephonyConnector.cs - Begründung: Enthält die durchgesetzte TAPI-Anbindung.
+Prüfidee:      Ein eingehender Anruf eines im System hinterlegten Kunden zeigt dessen Kontaktbild innerhalb weniger Sekunden.
+Tracelinks:    StRS-035, SwRS-049
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-039
+Titel:         Kundenindividuelle Sichtbarkeit im Web-Warenkorb
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Sicherheit
+Akteur:        System (Nexus)
+Vorbedingung:  Ein Kunde meldet sich mit Web-Account an.
+Fakt:          Laut README ist der Artikelbestand des Shops an die im c-entron.NET-Adressstamm hinterlegten "Sonderpreise" des jeweiligen Web-Accounts gebunden.
+Aussage:       Das System muss einem angemeldeten Web-Account ausschließlich die für ihn hinterlegten Sonderpreisartikel im Warenkorb anzeigen und darf keine Artikel/Preise anderer Kunden offenlegen.
+Ergebnis:      Kundenindividuelle Artikel-/Preissicht im Web-Warenkorb.
+Belege:
+  - [PRIMÄR]   README.md, Abschnitt WebCart - Begründung: Beschreibt die durchgesetzte Kopplung Web-Account↔Sonderpreise.
+Prüfidee:      Zwei unterschiedliche Web-Accounts sehen unterschiedliche, jeweils auf sie zugeschnittene Artikellisten.
+Tracelinks:    StRS-037, SwRS-051
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-040
+Titel:         Eingebettete Darstellung von Nexus im Outlook-Taskbereich
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Das Outlook-Add-in ist installiert und eine E-Mail wird betrachtet.
+Fakt:          UseAllowXFrameOptionsForCentronNexus()/UseOutlookCookiePolicy() passen HTTP-Header bzw. Cookie-SameSite-Verhalten speziell für die Einbettung in den Outlook-Taskbereich (iFrame) an.
+Aussage:       Das System muss die Nexus-Weboberfläche so bereitstellen, dass sie innerhalb des Outlook-Add-in-Taskbereichs eingebettet und dort authentifiziert dargestellt werden kann, ohne die allgemeinen Sicherheitsmechanismen (X-Frame-Options, Cookie-Policy) für andere Aufrufer zu lockern.
+Ergebnis:      Ticket-/Kundendaten sind direkt im Outlook-Taskbereich nutzbar.
+Belege:
+  - [PRIMÄR]   src/nexus/CentronNexus.Host/Program.cs, Methoden UseAllowXFrameOptionsForCentronNexus, UseOutlookCookiePolicy - Begründung: Enthalten die durchgesetzte, gezielte Anpassung für den Outlook-Kontext.
+Prüfidee:      Nexus ist im Outlook-Taskbereich sichtbar eingebettet, während eine Einbettung von einer beliebigen fremden Domain weiterhin blockiert wird.
+Tracelinks:    StRS-038, SwRS-052
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-041
+Titel:         Belegartspezifische Reklamationsgrund-Kataloge
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Eine Reklamation/Rücksendung zu einer bestimmten Belegart wird erfasst.
+Fakt:          QmSettingsViewModel führt sieben unabhängige AssetReasonSettingsViewModel-Instanzen, je eine pro Belegart (Bestellung, Gutschrift-Lieferant, Lieferschein-Lieferant, Rechnung-Lieferant, Abholschein, Gutschrift-Kunde, Lieferschein-Kunde).
+Aussage:       Das System muss dem Anwender bei der Erfassung einer Reklamation ausschließlich die für die jeweilige Belegart konfigurierten Gründe zur Auswahl anbieten.
+Ergebnis:      Konsistente, belegartspezifische Reklamationsklassifikation.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/QM/Settings/QmSettingsViewModel.cs - Begründung: Enthält die sieben durchgesetzten, getrennten Kataloge.
+Prüfidee:      Bei einer Lieferschein-Reklamation werden nicht die für Rechnungen konfigurierten Gründe angeboten.
+Tracelinks:    StRS-039, SwRS-053
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-042
+Titel:         Preisdifferenzprüfung vor endgültiger Übernahme importierter Sonderpreise
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Eine Excel-Preisliste wurde hochgeladen und gegen bestehende Sonderpreisvereinbarungen gematcht.
+Fakt:          DifferenceViewModel vergleicht neue mit bestehenden Preisen je Position; CanImport-Gate verhindert den Import, solange nicht alle Zeilen zugeordnet und geprüft sind.
+Aussage:       Das System muss vor der endgültigen Übernahme importierter Sonderpreise die Differenz zu bestehenden Vereinbarungen je Position anzeigen und den Import erst nach Bestätigung durch den Anwender zulassen.
+Ergebnis:      Nur bestätigte Preisänderungen werden in die Sonderpreisvereinbarungen übernommen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ProjectPriceImport/PriceDifference/DifferenceViewModel.cs - Begründung: Enthält die durchgesetzte Differenzdarstellung.
+Prüfidee:      Ein Import mit einer nicht zuordenbaren Zeile kann ohne Klärung nicht abgeschlossen werden.
+Tracelinks:    StRS-040, SwRS-054
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-043
+Titel:         Modellierung von Umfragen als konfigurierbare Workflow-Prozesse
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Eine Umfrage wird erstellt oder beantwortet.
+Fakt:          SurveyMainViewModel bindet eine ProcessViewModel/EditProcessView-Infrastruktur aus dem generischen Workflow-Engine-Namensraum (Centron.Data.Entities.Services.Workflows) statt eine eigenständige Umfrage-Datenstruktur zu verwenden.
+Aussage:       Das System muss Umfragen technisch als Instanz des generischen Workflow-Prozessmodells abbilden, sodass Fragetypen (CheckChoice, FreeText, MultipleChoice, Scala, YesNo) als Prozessschritte konfigurierbar sind.
+Ergebnis:      Neue Umfrage entsteht als konfigurierter Workflow-Prozess mit den gewählten Fragetypen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Survey/SurveyMainViewModel.cs - Begründung: Belegt die durchgesetzte Workflow-Modellierung.
+Prüfidee:      Eine Umfrage mit fünf Fragen unterschiedlichen Typs wird als ein zusammenhängender Prozess mit fünf Schritten ausgeführt.
+Tracelinks:    StRS-041, SwRS-055
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-044
+Titel:         Verpflichtende Dual-Implementierung des Datenzugriffs je Modul
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Wartbarkeit
+Akteur:        Entwicklungsteam
+Vorbedingung:  Ein neues Modul wird entwickelt.
+Fakt:          Die Entwicklerrichtlinie general-structure.md verlangt für jedes Modul zwingend eine ILogic-Schnittstelle, eine BL-Implementierung (Direktzugriff über NHibernate) und eine WS-Implementierung (Zugriff über den Webservice), registriert über den ClassContainer.
+Aussage:       Das System muss für jedes fachliche Modul eine gemeinsame Schnittstelle mit zwei alternativen, austauschbaren Implementierungen (Direktverbindung, Webservice) bereitstellen, die über einen zentralen Container zur Laufzeit gemäß konfiguriertem Verbindungstyp ausgewählt wird.
+Ergebnis:      Modul funktioniert identisch unabhängig vom gewählten Verbindungstyp.
+Belege:
+  - [PRIMÄR]   docs/getting-started/general-structure.md, Abschnitt "Dual Implementation Architecture" - Begründung: Enthält die verbindliche, durchgesetzte Architekturregel inkl. Codebeispielen.
+Prüfidee:      Ein Modul, das im Verbindungstyp SqlServer getestet wurde, liefert bei identischer Eingabe im Verbindungstyp CentronWebServices dasselbe Ergebnis.
+Tracelinks:    StRS-042, SwRS-056, SwRS-057
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - im Zielsystem ggf. durch API-first-Architektur ohne Direktverbindungspfad zu ersetzen.
+Status:        belegt
+```