RQ bis Z77

Kapitel/02_theoretischer_hintergrund/02_01_requirements_engineering.typ

@@ -11,7 +11,7 @@ Im Kern adressiert das Requirments Engineering zwei Themen:
 
 Ein etablierter Ansatz zur Strukturierung von diversen Sichtweisen ist das Viewpoint-Konzept @kotonya1996viewpoints, bei dem Anforderungen aus unterschiedlichen Perspektiven modelliert und anschließend konsolidiert werden .
 
-Für diese Arbeit ist die Perspektivenorientierung relevant, weil implementierter Code typischerweise keine expliziten Stakeholder-Sichten enthält. Für eine Migration auf Basis eines Reverse Engeneering Ansatzes sind diese aber relevant für die implementierung und architekturlle Entscheidungen (z. B. Nutzerrollen, kundenspezifische Varianten, regulatorische Vorgaben).
+_Für diese Arbeit ist die Perspektivenorientierung relevant, weil implementierter Code typischerweise keine expliziten Stakeholder-Sichten enthält. Für eine Migration auf Basis eines Reverse Engeneering Ansatzes sind diese aber relevant für die implementierung und architekturlle Entscheidungen (z. B. Nutzerrollen, kundenspezifische Varianten, regulatorische Vorgaben)._
 
 #heading(level: 3)[Arten von Requirements und Qualitätskriterien]
 
@@ -21,59 +21,60 @@ Für die Qualität einzelner Requirements gibt es etablierte Standards. @iso2914
 
 Für die Bewertung von KI-extrahierten Requirements sind drei Kriterien maßgeblich relevant:
 
-- **Verifizierbarkeit:** Ein Requirement ist so formuliert, dass ein Test oder eine Prüfmethode ableitbar ist (z. B. Messkriterium, Akzeptanzbedingung).
+- *Verifizierbarkeit:* Ein Requirement ist so formuliert, dass ein Test oder eine Prüfmethode ableitbar ist (z. B. Messkriterium, Akzeptanzbedingung).
-- **Eindeutigkeit:** Formulierungen vermeiden Mehrdeutigkeiten und definieren Begriffe, die in der Domäne unterschiedlich interpretiert werden können \ (z.B. „Das System soll Aufträge schnell verarbeiten" vs. „Das System soll einen Auftrag innerhalb von 2 Sekunden validieren und bestätigen")
+- *Eindeutigkeit:* Formulierungen vermeiden Mehrdeutigkeiten und definieren Begriffe, die in der Domäne unterschiedlich interpretiert werden können \ (z.B. „Das System soll Aufträge schnell verarbeiten" vs. „Das System soll einen Auftrag innerhalb von 2 Sekunden validieren und bestätigen")
-- **Nachvollziehbarkeit (Traceability):** Es ist erkennbar, aus welchem Requirement das Artefakt (Code, Konfiguration, Datenbank, Ticket, Interview) abgeleitet wurde.
+- *Nachvollziehbarkeit (Traceability):* Es ist erkennbar, aus welchem Requirement das Artefakt (Code, Konfiguration, Datenbank, Ticket, Interview) abgeleitet wurde.
 
-Qualitätsanforderungen verdienen im Modernisierungskontext eine gesonderte Betrachtung, weil sie über die reine Funktionsgleichheit hinaus die Zielarchitektur motivieren. #cite(<glinz2008quality>, form: "prose") argumentiert, dass Qualitätsanforderungen risikobasiert und wertorientiert priorisiert werden sollten. Für Legacy-Migrationen ist dies plausibel: Ein „vollständiges" Requirements-Set ist praktisch schwer erreichbar, gleichzeitig sind bestimmte Quality Requirements (z. B. Datenschutz, Verfügbarkeit, Rollout-Fähigkeit) hochkritisch, weil sie Architekturentscheidungen dominieren.
+Nicht funktionale Anforderungen (z.B. Qualitätsanforderungen) bedürfen einer besonderen Betrachtung, weil sie über die reine Funktionsgleichheit hinaus die Zielarchitektur bestimmen. #cite(<glinz2008quality>, form: "prose") argumentiert, dass Qualitätsanforderungen risikobasiert und wertorientiert priorisiert werden sollten. Für Legacy-Migrationen ist dies nachvollziehbar: Ein „vollständiges" Requirements-Set ist praktisch schwer erreichbar, gleichzeitig sind bestimmte Non-Functional Requirements (z. B. Datenschutz, Verfügbarkeit, Rollout-Fähigkeit) hochkritisch, weil sie Architekturentscheidungen dominieren. 
 
 Für die inhaltliche Strukturierung von Qualitätsanforderungen ist das Qualitätsmodell ISO/IEC 25010:2011 verbreitet, das Qualitätsmerkmale wie Performance-Effizienz, Zuverlässigkeit, Sicherheit oder Wartbarkeit systematisch ordnet. Für Reverse Requirements Engineering ist dies hilfreich, weil aus Code häufig nur Teilaspekte sichtbar werden (z. B. Caching-Mechanismen als Hinweis auf Performance-Annahmen), während andere Qualitätsziele (z. B. „Maintainability") eher indirekt über Architekturentscheidungen und Entwicklungspraktiken wirksam werden @iso25010_2011.
 
-Die Relevanz sauberer Requirements-Qualität zeigt sich auch in der Risikoperspektive. #cite(<lawrence2001toprisk>, form: "prose") beschreiben Requirements Engineering als primäre Risikozone, wenn Anforderungen unklar, instabil oder unvollständig sind. Für diese Arbeit folgt daraus, dass KI-gestützte Requirements-Extraktion nicht nur „mehr Text" erzeugen darf, sondern gezielt die Risiken der Unklarheit und der Fehlinterpretation reduzieren muss.
+Die Relevanz saubere formulierter Requirements zeigt sich auch in der Risikoperspektive. #cite(<lawrence2001toprisk>, form: "prose") beschreiben Requirements Engineering als primäres Risiko, wenn Anforderungen unklar, instabil oder unvollständig sind. 
+\ \
+_Für diese Arbeit folgt daraus, dass KI-gestütztes Reverse-Requirements-Engineering nicht nur „mehr Text" erzeugen darf, sondern gezielt die Risiken der Unklarheit und der Fehlinterpretation reduzieren muss._
 
 #heading(level: 3)[Spezifikationsformen und Grad der Formalisierung]
 
-Requirements werden in der Praxis in unterschiedlichen Repräsentationsformen dokumentiert. Standards wie IEEE 830-1998 und ISO/IEC/IEEE 29148:2018 fokussieren auf strukturierte Spezifikationen (z. B. SRS) und definieren typische Kapitel (Zweck, Systemkontext, funktionale Anforderungen, Schnittstellen, Qualitätsanforderungen, Annahmen). Daneben existieren weniger formale Formen wie User Stories, Use-Case-Beschreibungen oder Backlog-Einträge, die vor allem in agilen Settings verbreitet sind @ieee830_1998 @iso29148_2018.
+Requirements werden in unterschiedlichen Repräsentationsformen dokumentiert. Standards wie IEEE 830-1998 und ISO/IEC/IEEE 29148:2018 fokussieren auf strukturierte Spezifikationen (z. B. SRS) und definieren typische Kapitel (Zweck, Systemkontext, funktionale Anforderungen, Schnittstellen, Qualitätsanforderungen, Annahmen). Zudem existieren weniger formale Formen wie User Stories, Use-Case-Beschreibungen oder Backlog-Einträge, die in agilen Settings verwendung finden. @ieee830_1998 @iso29148_2018.
 
 Für Reverse Requirements Engineering sind zwei Punkte entscheidend:
 
-- **Form beeinflusst Interpretierbarkeit:** Eine knappe User Story („Als Nutzer möchte ich …") ist leicht verständlich, transportiert aber selten Randbedingungen, Datenregeln oder Fehlerfälle. Eine SRS-Formulierung kann präziser sein, erfordert aber mehr Kontext und Definitionen.
+- *Form* beeinflusst Interpretierbarkeit: Eine kurze User Story („Als Nutzer möchte ich …") ist leicht verständlich, transportiert aber weniger Randbedingungen, Datenregeln oder Fehlerfälle. Eine SRS-Formulierung kann präziser sein, erfordert aber mehr Kontext und Definitionen.
-- **Grad der Formalisierung beeinflusst Prüfbarkeit:** Je stärker Requirements mit Akzeptanzkriterien, Beispielen oder Messgrößen verknüpft sind, desto einfacher sind Reviews und Tests. #cite(<pohl2010re>, form: "prose") betont Anforderungen-Validierung als eigene Disziplin, die ohne prüfbare Formulierungen methodisch kaum belastbar ist.
+- *Grad* der Formalisierung beeinflusst Prüfbarkeit: Je stärker Requirements mit Akzeptanzkriterien, Beispielen oder Messgrößen verknüpft sind, desto einfacher sind Reviews und Tests. #cite(<pohl2010re>, form: "prose") betont Anforderungen-Validierung als eigene Disziplin.
 
-Im Kontext dieser Arbeit bietet sich daher ein hybrider Stil an: Requirements werden als kurze, klare Soll-Aussagen formuliert und jeweils um Kontext (Akteur/Prozess), Randbedingungen (Vorbedingungen, Datenobjekte) und mindestens eine Prüfidee ergänzt. LLMs können die sprachliche Konsistenz unterstützen, die notwendige Präzisierung muss jedoch durch Belege und Validierung abgesichert werden.
+_Für diese Arbeit wir daher ein hybrider Stil gewählt: Requirements werden als kurze, klare Soll-Aussagen formuliert und jeweils um Kontext (Akteur/Prozess), Randbedingungen (Vorbedingungen, Datenobjekte) und mindestens eine Prüfidee ergänzt._
 
 #heading(level: 3)[Traceability als Verbindung zwischen Code und Requirement]
 
-Traceability bezeichnet die Möglichkeit, Beziehungen zwischen Requirements und anderen Artefakten herzustellen und über den Lebenszyklus zu pflegen. #cite(<gotel1994traceability>, form: "prose") analysieren Traceability als wiederkehrendes Problem, insbesondere dort, wo Artefakte heterogen sind und die Disziplin zur Pflege fehlt. #cite(<ramesh2001traceability>, form: "prose") schlagen Referenzmodelle vor, die Traceability-Typen und -Ziele strukturieren, etwa die Rückverfolgbarkeit zur Begründung (Rationale), zu Designentscheidungen oder zur Evolution eines Requirements.
+Traceability bezeichnet die Verknüpfung von Requirements und Artefakten, wie z.B. Code oder Test. #cite(<gotel1994traceability>, form: "prose") bezeichnen Traceability als wiederkehrendes Problem, vor allem bei unterschiedlichen Arten von Artefakten. 
 
-Für Reverse Requirements Engineering ist Traceability nicht nur ein „Nice-to-have", sondern eine Sicherheitsmaßnahme:
+Beim Reverse Requirements Engineering ist Traceability nicht nur ein „Nice-to-have", sondern eine Grundvoraussetzung.\
+Ein Requirement lässt sich gegen konkrete Codeausschnitte oder Laufzeitbeobachtungen prüfen da da Requirement ja aus dem Code selbst entsteht.
 
-- **Plausibilisierung:** Ein Requirement lässt sich gegen konkrete Codeausschnitte oder Laufzeitbeobachtungen prüfen.
+In Legacy-Systemen ist die Ursprüngliche Traceability typischerweise unvollständig, falls überhaupt vorhanden: Hinweise finden sich in Commit-Messages, Branch-Namen, Datenbankskripten, Konfigurationsdateien, UI-Texten oder in impliziten Konventionen. Der Anspruch dieser Arbeit besteht daher nicht darin, „perfekte" Traceability wiederherzustellen, sondern eine minimal belastbare, reproduzierbare Verknüpfung zwischen extrahierten Requirements und Artefakten zu etablieren.
-- **Abgrenzung:** Es wird klar, ob eine Aussage wirklich aus der Codebasis folgt oder aus Interpretationen und Ergänzungen entsteht.
-- **Änderungsmanagement:** Bei Codeänderungen lässt sich ermitteln, welche Requirements betroffen sein könnten.
 
-In Legacy-Systemen ist Traceability typischerweise fragmentiert: Hinweise finden sich in Commit-Messages, Branch-Namen, Datenbankskripten, Konfigurationsdateien, UI-Texten oder in impliziten Konventionen. Der methodische Anspruch dieser Arbeit besteht daher nicht darin, „perfekte" Traceability wiederherzustellen, sondern eine minimal belastbare, reproduzierbare Verknüpfung zwischen extrahierten Requirements und Belegen zu etablieren.
+#heading(level: 3)[Abgrenzung von Reverse Engineering zu Reverse Requirements Engineering]
 
-#heading(level: 3)[Reverse Engineering und Reverse Requirements Engineering]
+Reverse Engineering wird klassisch als Analyseprozess verstanden, der aus einem bestehenden System Wissen über Struktur, Verhalten und Designentscheidungen rekonstruiert. #cite(<chikofsky1990taxonomy>, form: "prose") prägen hierfür die Bennung und grenzen Reverse Engineering von Reengineering sowie Design Recovery ab. Für Requirements-nahe Fragestellungen ist hier relevant, dass Reverse Engineering nicht automatisch auch Requirements liefert, sondern erstmal nur technische Fakten (z. B. Abhängigkeiten, Datenflüsse, Zustandsautomaten).
 
-Reverse Engineering wird klassisch als Analyseprozess verstanden, der aus einem bestehenden System Wissen über Struktur, Verhalten und Designentscheidungen rekonstruiert. #cite(<chikofsky1990taxonomy>, form: "prose") prägen hierfür eine Taxonomie und grenzen Reverse Engineering von Reengineering sowie Design Recovery ab. Für Requirements-nahe Fragestellungen ist hier relevant, dass Reverse Engineering nicht automatisch „Anforderungen" liefert, sondern zunächst technische Fakten (z. B. Abhängigkeiten, Datenflüsse, Zustandsautomaten).
+Reverse Requirements Engineering (RRE) fokussiert sich dagegen auf die rückwärtsgerichtete Gewinnung von Requirements aus bestehenden Artefakten. Dabei kann das Ziel unterschiedlich interpretiert werden:
 
-Reverse Requirements Engineering (RRE) fokussiert auf die rückwärtsgerichtete Gewinnung von Anforderungen aus bestehenden Artefakten. Dabei kann das Ziel unterschiedlich interpretiert werden:
+- *Rekonstruktion eines Soll-Zustands:* Welche fachlichen Anforderungen werden durch die aktuelle Implementierung implizit erfüllt? Was war das ursprüngliche Ziel der Imepementierung?
+- *Rekonstruktion eines Ist-Zustands:* Welche Funktionen und Regeln sind dagegen tatsächlich implementiert?
 
-- **Rekonstruktion eines Soll-Zustands:** Welche fachlichen Anforderungen werden durch die aktuelle Implementierung implizit erfüllt?
+Gerade im Legacy Umfeld ist diese Unterscheidung entscheidend. Die Codebasis enthält oft historisch entstandene Workarounds oder kundenspezifische Anpassungen. Ohne zusätzliche Validierung besteht das Risiko, dass RRE den Ist-Zustand als Soll-Zustand fehlinterpretiert.
-- **Rekonstruktion eines Ist-Zustands:** Welche Funktionen und Regeln sind tatsächlich implementiert, unabhängig davon, ob sie intendiert waren?
 
-Gerade im Migrationskontext ist diese Unterscheidung entscheidend. Die Codebasis enthält oft historisch entstandene Workarounds oder kundenspezifische Anpassungen. Diese können fachlich gewollt, technisch opportunistisch oder schlicht „mitgewachsen" sein. Ohne zusätzliche Validierung besteht das Risiko, dass RRE den Ist-Zustand als Soll-Zustand fehlinterpretiert.
+Frühe Ansätze zur Brücke zwischen Reverse Engineering und Requirements liefern beispielsweise #cite(<yu2005retr>, form: "prose") mit „RETR: Reverse Engineering to Requirements". Der Beitrag betont, dass Requirements-Rückgewinnung eine methodische Kette aus Artefaktsichtung, Strukturierung und Validierung benötigt. 
-
-Frühe Ansätze zur Brücke zwischen Reverse Engineering und Requirements liefern beispielsweise #cite(<yu2005retr>, form: "prose") mit „RETR: Reverse Engineering to Requirements". Der Beitrag betont, dass Requirements-Rückgewinnung eine methodische Kette aus Artefaktsichtung, Strukturierung und Validierung benötigt. In ähnlicher Richtung beschreibt ein requirementsgetriebenes Reengineering-Framework, wie Requirements als Leitplanken für Reengineering-Entscheidungen genutzt werden können @tahvildari2001reengineering.
 
 Methodisch lassen sich dabei grob zwei Analysestränge unterscheiden:
 
-- **Statische Analyse:** Ableitung von Struktur- und Datenflussinformationen aus Code und Artefakten ohne Ausführung (z. B. Abhängigkeiten, SQL-Statements, Aufrufketten). Statische Analyse ist skaliert gut, erkennt aber nicht zuverlässig Laufzeitbedingungen (z. B. Feature Flags, Konfigurationsvarianten).
+- *Statische Analyse:* Ableitung von Struktur- und Datenflussinformationen aus Code und Artefakten ohne Ausführung (z. B. Abhängigkeiten, SQL-Statements, Aufrufketten). Statische Analyse ist skaliert gut, erkennt aber nicht zuverlässig Laufzeitbedingungen (z. B. Feature Flags, Konfigurationsvarianten).
-- **Dynamische Analyse:** Beobachtung von Laufzeitverhalten durch Logging, Tracing oder instrumentierte Tests (z. B. welche Regeln bei bestimmten Eingaben greifen). Dynamische Analyse ist näher am realen Verhalten, benötigt aber reproduzierbare Szenarien und Testdaten.
+- *Dynamische Analyse:* Beobachtung von Laufzeitverhalten durch Logging, Tracing oder instrumentierte Tests (z. B. welche Regeln bei bestimmten Eingaben greifen). Dynamische Analyse ist näher am realen Verhalten, benötigt aber reproduzierbare Szenarien und Testdaten.
 
 Reverse Requirements Engineering in einem Migrationsprojekt profitiert typischerweise von einer Kombination beider Stränge. Ohne dynamische Belege steigt das Risiko, dass nicht offensichtliche Bedingungen (z. B. kundenspezifische Schalter) übersehen werden; ohne statische Analyse bleibt die Abdeckung häufig zu gering.
 
+_Da eine Dynamische Analyse durch ein LLM mit den gegebenen technischen Möglichkeiten derzeit unpraktikabel ist, fokussiert sich diese Arbeit auf die statische Analyse von Artefakten, ergänzt manuell erstellte Artefakte zur Laufzeit (z.B. Screenshots)._
+
 #heading(level: 3)[Typische Methodenkette für Requirements-Rückgewinnung aus Code]
 
 Aus Sicht dieser Arbeit lässt sich Reverse Requirements Engineering in einer Legacy-Codebasis als wiederholbarer Ablauf strukturieren. Die konkrete Ausgestaltung hängt vom System und den verfügbaren Artefakten ab, die grundlegenden Schritte sind jedoch weitgehend stabil:

Versuche/Versuch 04/Prompts

@@ -0,0 +1,46 @@
+Prompt 1:
+
+1. Lies alle Dateien in \Versuche.
+2. Schau dir die Datei @ERP_WEB/UseCases_Short.md genau an. Gibt es Usecases in den anderen Dateien die hier nicht erwähnt sind? Ignoiere alle Usecases zu Produktionsplanung und TicketManagement
+
+-----
+Return1.md
+
+----- 
+Prompt 2
+
+1, 2 , 3, sind ok der Rest nur leidlich. Erstelle die Liste nochmal neu. Ignoriere dabei alles zu RMM anbindung (Asset Management generell ist ok), Validierungsregeln und REST API. Es geht hierbei darum die Anwendungs Funktion der Software abzubilden. API Endpunkte oder Valididerung sind konkrete implementierungen....
+
+-----
+Return2.md
+
+-----
+Prompt 3
+Dann kopiere UseCases_short.md zu UseCases_short_V2.md und füge die neuen Usecases an passender Stelle ein
+
+----
+Return3.md
+
+----
+UseCases_Short_V2.md
+
+-----
+Prompt 4
+Erstelle jetzt eine neue Datei UseCases_long.md und schreibe eine Ausführliche Beschreibung der UseCases in @ERP_WEB/UseCases_Short_V2.md . Konzentriere dich auf die Funktionalen Bestandteile. In der Beschreibung soll kein Code oder technische implementierung vorkommen. 
+
+----
+Prompt5
+Kannst du das Pro Usecase auch so aufsplitten und nicht als prosa schreiben? Bitte auch alle Usecases hierfür nochmal mit der vollen Doku in \Versuche inhaltlich abgleichen. 
+
+Jeder Use Case beschreibt aus Anwendersicht:
+Was der Benutzer tut
+Warum er es tut (Geschäftszweck)
+Was das erwartete Ergebnis ist
+
+
+-----
+Prompt6
+Erstelle noch ein Inhaltsverzeichnis
+
+------
+Usecases_Long.md

Versuche/Versuch 04/Return1.md

@@ -0,0 +1,97 @@
+# Use-Case-Vergleich: UseCases_Short.md vs. andere Dateien
+
+## Referenz-Datei: ERP_WEB/UseCases_Short.md
+- **748 Use Cases** in 17 Modulen (1-17)
+- Deckt ab: Abrechnung, Administration, Adressen/CRM, Automatisierung, Buchhaltung, Controlling, Einkauf, Verkauf, Helpdesk, MyCentron, Logistik, Stammdaten, Vertraege, CentronNexus, Asset Management, Terminverwaltung, State Machines & Wizards
+
+> **Hinweis**: Use Cases zu **Produktionsplanung** und **TicketManagement** wurden wie gewuenscht ignoriert.
+
+---
+
+## Fehlende Use Cases (in anderen Dateien vorhanden, NICHT in UseCases_Short.md)
+
+### 1. Aus `ERP_WEB/FOLGEMEETING_VORBEREITUNG.md`
+
+| UC-ID | Titel | Bemerkung |
+|-------|-------|-----------|
+| **UC-021** | **Warenausgang (Goods Issue/Outbound)** | Kein eigener Use Case in UseCases_Short - nur Kommissionierung (11.4) und Versand sind abgedeckt, aber nicht explizit "Warenausgang" als eigenstaendiger Prozess |
+| **UC-022** | **Bestandsverwaltung (Inventory Management)** | Inventur (11.3) ist vorhanden, aber allgemeine Bestandsverwaltung (Umbuchungen, Bestandskorrekturen, Mindestbestandswarnungen) fehlt als eigene Kategorie |
+| **UC-031** | **Aktivitaeten (CRM Activities)** | Aktivitaets-Tracking (Anrufe, Besuche, Emails, Notizen) als CRM-Funktion fehlt komplett in UseCases_Short |
+| **UC-032** | **Anfragen/Leads (Inquiries/Leads)** | Lead-Management, Lead-Qualifizierung, Lead-Konvertierung zu Angebot/Kunde fehlt komplett |
+| **UC-041** | **Automatische Abrechnung (Automatic Billing)** | Zwar ist Vertragsabrechnung (1.1) vorhanden, aber ein uebergreifender Use Case fuer automatisierte/zeitgesteuerte Abrechnung ohne manuellen Eingriff fehlt |
+| **UC-042** | **Workflow-Engine (allgemein)** | Eine generische Workflow-Engine als eigener Use Case (nicht nur Ticket-Prozesse oder Freigaben) fehlt |
+| **UC-052** | **OPOS-Import (Bestandsabgleich)** | OPOS (5.5) deckt offene Posten ab, aber ein spezifischer Import/Sync-Use-Case fuer Bestandsabgleich mit externen Systemen fehlt |
+| **UC-060** | **Umsatzreporting** | Analytics (6.1) hat Verkaufsstatistik, aber ein dedizierter Umsatzreport (nach Perioden, Filialen, Produktgruppen, Vergleich) fehlt als eigenstaendiger UC |
+| **UC-061** | **Lagerwert-Report** | Lagerbestandsentwicklung (6.1.8) ist erwaehnt, aber ein spezifischer Lagerwert-Report (Bewertung, Abschreibung, Slow-Mover) fehlt |
+| **UC-062** | **Aufwand/Kosten-Analyse** | Kostentraeger/Kostenstellen (12.3) existiert, aber eine uebergreifende Aufwand/Kosten-Analyse fehlt |
+| **UC-070** | **Kundenbereich Read-Only (Kundenportal)** | Ein Self-Service-Kundenportal (Rechnungen einsehen, Tickets erstellen, Vertraege sehen) fehlt komplett in UseCases_Short |
+
+### 2. Aus `Versuch 03/ERP_DOCUMENTATION/USE_CASES_STATE_MACHINES.md`
+
+| UC-ID | Titel | Bemerkung |
+|-------|-------|-----------|
+| **UC-018** | **Item Lost During Inventory Count** | Artikel-Verlust waehrend Inventur - nicht in UseCases_Short (17.3 hat nur Retoure, Verschrottung, Umbuchung, Ersatz) |
+| **UC-021** | **Batched Item Processing - Intake to Stock** | Batch-Wareneingang (mehrere Artikel gleichzeitig einlagern) - fehlt als eigener Workflow |
+| **UC-022** | **Item Condition Change & Metadata Update** | Zustandsaenderung eines Artikels (z.B. von "Neu" auf "Gebraucht") - fehlt |
+| **UC-023** | **Serial Number Discrepancy Resolution** | Seriennummer-Abweichung klaeren - fehlt |
+| **UC-024** | **Deactivation of Demo Unit** | Demo-Geraet deaktivieren/ausmustern - fehlt |
+| **UC-030** | **CRM Project Lifecycle - Successful Close** | CRM-Projekte (3.3) haben CRUD, aber der vollstaendige Lifecycle als State Machine (Opportunity -> Proposal -> Negotiation -> Won/Lost) fehlt |
+
+### 3. Aus `ERP_DOCUMENTATION/USE_CASES_WIZARD_WORKFLOWS.md`
+
+| Bereich | Fehlende Use Cases | Bemerkung |
+|---------|-------------------|-----------|
+| **Fehlerbehandlung Abrechnung** | Billing mit fehlenden Mengen erkennen und korrigieren; Barcode-Varianz-Override; E-Mail-Versandfehler mit Retry; Druckerverbindungsfehler mit PDF-Fallback; Teilweise erfolgreiche Abrechnung mit Error-Logging; Kontingent-Erschoepfungswarnung und Billing-Pause | UseCases_Short hat keine Error-Recovery-Szenarien fuer die Abrechnung |
+| **Reporting Abrechnung** | Abrechnungsvorschau-Verifizierung vor Versand; Post-Billing Abstimmungsbericht | Fehlt als eigenstaendiger Workflow |
+| **Kontingent-Details** | Monatliches Geld-Kontingent mit Overbooking; Stunden-Kontingent fuer Dienstleister; Quartals-Kontingent mit Warengruppen-Zuordnung; Kontingent-Uebertrag in naechste Periode; Gratis-Perioden-Zuweisung (Promotion); Kontingent-Umverteilung waehrend Vertragslaufzeit | UseCases_Short (17.6) hat nur 4 generische Kontingent-UCs, die Wizard-Datei hat 7 spezifische Szenarien |
+| **Preise & Rabatte** | Stufen-Volumenrabatt; Warengruppen-Mengenpreise; Artikelspezifische Preis-Ueberschreibung; Stundenzuschlaege (Arbeitsstufen); Kombinations-Preisregeln; Erweiterte bedingte Preisgestaltung | UseCases_Short (17.8.7) hat nur "Preis- und Rabattstrukturen" als einen einzigen UC |
+| **SLA-Details** | Quartalmaessige praeventive Wartung; 24/7 Notfallsupport (2h Reaktionszeit); Geschaeftszeiten-Support (4h Response); Bedarfs-Wartung; Multi-Tier SLA (Gold/Silber/Bronze) | UseCases_Short (17.8.8) hat nur einen generischen SLA-UC |
+
+### 4. Aus `ERP_DOCUMENTATION/USE_CASES_ASSET_MANAGEMENT.md`
+
+| Bereich | Fehlende Use Cases | Bemerkung |
+|---------|-------------------|-----------|
+| **AD-Benutzerausschluss-Details** | Ausschluss nach SamAccountName; Ausschluss nach ObjectSID; Ausschlusstyp aendern; Benutzer wieder einschliessen; Bestehenden Ausschluss bearbeiten | UseCases_Short (15.4) hat 5 generische UCs, die Detaildatei beschreibt spezifischere Szenarien |
+| **RMM-Artikeltyp-Details** | 20+ spezifische Check-Types (CPU, Memory, Disk, Backup, Antivirus, Patch Status, etc.) | UseCases_Short (15.3) hat nur 5 generische UCs |
+
+### 5. Aus `Versuch 03/ERP_DOCUMENTATION/UNDOCUMENTED_USE_CASES_SUMMARY.md`
+
+Diese Meta-Analyse identifiziert **1.211 undokumentierte Use Cases** (71% Luecke). Die wichtigsten fehlenden Bereiche (ohne Produktionsplanung und TicketManagement):
+
+| Bereich | Geschaetzte fehlende UCs | Status in UseCases_Short |
+|---------|--------------------------|--------------------------|
+| **Quality/Compliance** | ~25 Use Cases | KOMPLETT FEHLEND - Qualitaetskontrolle, Zertifizierungen, Sicherheitschecklisten |
+| **Social Media & Marketing** | ~10 Use Cases | KOMPLETT FEHLEND - Social Feeds, Accounts, Posts, Engagement |
+| **Data Exchange/EDI (erweitert)** | ~50 Use Cases | Nur minimal dokumentiert (7.3 hat 6 UCs, aber 40+ DB-Tabellen existieren) |
+| **Validierungsregeln** | ~381 Regeln | 431 Regeln im Code, nur 50 dokumentiert |
+| **REST API Endpunkte** | ~254 Endpunkte | 284 Endpunkte existieren, nur ~30 durch UCs abgedeckt |
+
+---
+
+## Zusammenfassung: Komplett fehlende Themen in UseCases_Short.md
+
+### Kategorie A: Ganz neue Module/Bereiche (nicht erwaehnt)
+1. **Kundenportal / Self-Service** (UC-070) - Kunden koennen Rechnungen, Tickets, Vertraege einsehen
+2. **CRM Aktivitaeten-Tracking** (UC-031) - Anrufe, Besuche, E-Mails, Notizen als CRM-Aktivitaeten
+3. **Lead-Management** (UC-032) - Anfragen, Leads, Qualifizierung, Konvertierung
+4. **Quality & Compliance** - Sicherheitschecklisten, Materialpruefung, Umweltanforderungen, Audits
+5. **Social Media Management** - Social Feeds, Accounts, Posts, Kommentare, Engagement
+
+### Kategorie B: Existierende Module mit fehlender Tiefe
+6. **Warenausgang** (UC-021) - als eigenstaendiger Prozess neben Kommissionierung
+7. **Allgemeine Bestandsverwaltung** (UC-022) - Umbuchungen, Korrekturen, Mindestbestaende
+8. **Workflow-Engine** (UC-042) - generische Workflow-Automatisierung
+9. **Lagerwert-Reporting** (UC-061) - Bewertung, Slow-Mover, Abschreibung
+10. **Aufwand/Kosten-Analyse** (UC-062) - uebergreifende Analyse
+11. **Abrechnungs-Fehlerbehandlung** - 6 Recovery-Szenarien aus Wizard-Workflows
+12. **Kontingent-Szenarien** - 7 spezifische Szenarien vs. 4 generische in UseCases_Short
+13. **Preis-/Rabattstrukturen** - 6 spezifische Szenarien vs. 1 generischer UC
+14. **SLA-Szenarien** - 5 spezifische Szenarien vs. 1 generischer UC
+15. **Artikel-Lifecycle-Erweiterungen** - Verlust, Batch-Eingang, Zustandsaenderung, SN-Abweichung, Demo-Deaktivierung
+16. **CRM-Projekt-Lifecycle** - als vollstaendige State Machine
+17. **Automatische Abrechnung** (UC-041) - zeitgesteuert ohne manuellen Eingriff
+
+### Anzahl fehlender Use Cases (geschaetzt)
+- **Kategorie A (neue Bereiche)**: ~50-70 Use Cases
+- **Kategorie B (fehlende Tiefe)**: ~40-50 Use Cases
+- **Gesamt**: ~90-120 Use Cases fehlen in UseCases_Short.md

Versuche/Versuch 04/Return2.md

@@ -0,0 +1,232 @@
+# Use-Case-Vergleich: UseCases_Short.md vs. andere Dateien
+
+## Referenz-Datei: ERP_WEB/UseCases_Short.md
+- **748 Use Cases** in 17 Modulen (1-17)
+- Deckt ab: Abrechnung, Administration, Adressen/CRM, Automatisierung, Buchhaltung, Controlling, Einkauf, Verkauf, Helpdesk, MyCentron, Logistik, Stammdaten, Vertraege, CentronNexus, Asset Management, Terminverwaltung, State Machines & Wizards
+
+> **Ignoriert**: Produktionsplanung, TicketManagement, RMM-Anbindung, REST API Endpunkte, Validierungsregeln
+
+---
+
+## Fehlende Anwendungsfunktionen (in anderen Dateien, NICHT in UseCases_Short.md)
+
+### A. Komplett fehlende Funktionsbereiche
+
+#### A1. Kundenportal / Self-Service (UC-070)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Was fehlt**: Ein kundengerichtetes Portal, in dem Kunden (nicht Mitarbeiter!) ihre Daten einsehen koennen:
+- Beleg-Uebersicht (Rechnungen, Lieferscheine, Angebote)
+- Zahlungshistorie
+- Kontaktinformationen
+- Optional: Tickets erstellen/einsehen
+
+**Abgrenzung**: CentronNexus (Modul 14) ist das **interne** Web-Portal fuer Mitarbeiter. Das Kundenportal ist eine voellig andere Zielgruppe.
+
+---
+
+#### A2. CRM-Aktivitaeten (UC-031)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Was fehlt**: Erstellen und Verwalten von CRM-Aktivitaeten als eigene Entitaet:
+- Anrufe protokollieren
+- Kundenbesuche dokumentieren
+- E-Mail-Korrespondenz verknuepfen
+- Notizen/Vermerke erstellen
+- Wiedervorlagen/Follow-ups planen
+- Aktivitaeten einem Kunden zuordnen
+
+**Abgrenzung**: UC 3.1.4 "Adresse mit Aktivitaetshistorie anzeigen" zeigt nur die Historie an - es gibt keinen Use Case fuer das ERSTELLEN und VERWALTEN von Aktivitaeten.
+
+---
+
+#### A3. Lead-Management / Anfragen (UC-032)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Was fehlt**: Der gesamte Prozess von der Anfrage bis zum Angebot:
+- Anfrage/Lead erfassen (Webformular, Telefon, Messe)
+- Lead qualifizieren (Interessensprofil, Budget, Dringlichkeit)
+- Lead-Status tracken (Neu, Kontaktiert, Qualifiziert, Verloren)
+- Lead zu Angebot/Kunde konvertieren
+
+**Abgrenzung**: CRM-Projekte (3.3) beginnen erst bei einem konkreten Projekt. Der fruehe Vertriebstrichter (Lead -> Opportunity) fehlt.
+
+---
+
+#### A4. Arbeitssicherheit / Qualitaets-Compliance
+**Quelle**: UNDOCUMENTED_USE_CASES_DATABASE_MODELS.md
+**DB-Tabellen vorhanden**: AGArbeitssicherheit, AGMaterial, AGUmweltschutz, AGPrufvorschrift, ArtikelAGArbeitssicherheit, ArtikelAGMaterial, Arbeitssicherheit
+**Was fehlt**: Ein ganzes Modul fuer Arbeits-/Qualitaetssicherheit:
+- Sicherheitschecklisten pro Arbeitsplatz/Taetigkeit verwalten
+- Materialsicherheit dokumentieren (Gefahrstoffe, Umgang)
+- Umweltschutzanforderungen erfassen und pruefen
+- Pruefvorschriften fuer Artikel/Materialien definieren
+- Arbeitssicherheits-Audits durchfuehren und dokumentieren
+- Compliance-Berichte fuer ISO-Zertifizierungen generieren
+
+**Hinweis**: Nicht zu verwechseln mit den Compliance-Erwaenungen in UseCases_Short (DSGVO 2.2, Report-Compliance 12.7.5 etc.) - dort geht es um Daten-Compliance. Hier geht es um **physische Arbeitssicherheit und Materialqualitaet**.
+
+---
+
+#### A5. Social-Media-Management
+**Quelle**: UNDOCUMENTED_USE_CASES_DATABASE_MODELS.md
+**DB-Tabellen vorhanden**: SocialMediaStream, SocialMediaStreamAccount, SocialMediaAction, SocialMediaComment, SocialMediaLike
+**Was fehlt**:
+- Social-Media-Accounts verknuepfen (Facebook, Twitter, LinkedIn)
+- Social-Media-Feeds ueberwachen
+- Posts planen und veroeffentlichen
+- Kommentare und Interaktionen verwalten
+- Engagement-Metriken analysieren
+- Leads aus Social Media generieren
+
+---
+
+### B. Fehlende Funktionen in bestehenden Modulen
+
+#### B1. Warenausgang (UC-021)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Logistik (11)
+**Was fehlt**: Der Warenausgang als eigenstaendiger Prozess:
+- Lagerausbuchung bei Lieferschein-Erstellung
+- FIFO-/Seriennummern-Auswahl beim Ausbuchen
+- Bestandsaktualisierung nach Warenausgang
+- Warenausgangs-Protokoll/Beleg
+
+**Abgrenzung**: Kommissionierung (11.4) ist das Zusammenstellen der Ware. Warenausgang ist die tatsaechliche Bestandsreduzierung und Buchung.
+
+---
+
+#### B2. Allgemeine Bestandsfuehrung (UC-022)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Logistik (11)
+**Was fehlt**: Laufende Bestandsverwaltung zwischen Inventuren:
+- Lagerbestandsabfrage (Menge, Reserviert, Verfuegbar)
+- Lagerumbuchung zwischen Lagerorten
+- Manuelle Bestandskorrektur mit Begruendung
+- Mindestbestandswarnungen
+- Bestandsabstimmung (Soll/Ist-Vergleich)
+
+**Abgrenzung**: Inventur (11.3) ist die periodische Zaehlung. Bestandsfuehrung ist der taegliche Umgang mit Bestaenden.
+
+---
+
+#### B3. Lagerwert-Report (UC-061)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Controlling (6)
+**Was fehlt**: Ein dedizierter Lagerwert-Bericht:
+- Bestaende x Einstandspreis = Lagerwert
+- FIFO- vs. Durchschnittsbewertung
+- Slow-Mover-Identifikation
+- Abweichungsanalyse (Bewertungsdifferenzen)
+- Lagerwert-Entwicklung ueber Zeit
+
+**Abgrenzung**: UC 6.1.8 "Lagerbestands-Entwicklung und Umschlag" erwaehnt Mengen, aber nicht die wertmaessige Betrachtung (Lagerbewertung, Slow-Mover, FIFO).
+
+---
+
+#### B4. Aufwand/Kosten-Analyse (UC-062)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Controlling (6)
+**Was fehlt**: Uebergreifende Aufwands- und Kostenanalyse:
+- Zeitaufwand pro Kunde/Projekt aggregieren
+- Kostenvergleich: geplant vs. tatsaechlich
+- Gewinnmarge pro Projekt/Kunde berechnen
+- Aufwand/Kosten-Report exportieren
+
+**Abgrenzung**: Kostentraeger/Kostenstellen (12.3) ist Stammdaten-Verwaltung. Hier geht es um die analytische Auswertung.
+
+---
+
+#### B5. Automatische Abrechnung (UC-041)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Abrechnung (1) / Automatisierung (4)
+**Was fehlt**: Zeitgesteuerte Abrechnung ohne Benutzereingriff:
+- Regelmaessige Abrechnungsjobs konfigurieren (taeglich, woechentlich, monatlich)
+- MSP-Gebuehren automatisch fakturieren
+- Vertragsgebundene Abrechnungen nach Intervall ausfuehren
+- Ergebnis-Benachrichtigung an Sachbearbeiter
+
+**Abgrenzung**: Modul 1.1 (Vertragsabrechnung) ist ein Wizard, den ein Benutzer manuell durchlaeuft. UC-041 beschreibt die vollautomatische Abrechnung im Hintergrund.
+
+---
+
+#### B6. Abteilungstaetigkeiten
+**Quelle**: UNDOCUMENTED_USE_CASES_DATABASE_MODELS.md
+**DB-Tabellen**: AbtTaetigkeiten, AbtTaetigkeitenZuordnung
+**Modul**: Administration (2.14)
+**Was fehlt**: Verwaltung von Taetigkeiten pro Abteilung:
+- Taetigkeitsprofile definieren (z.B. "Vertrieb Innendienst", "Service Aussendienst")
+- Mitarbeiter Taetigkeiten zuordnen
+- Taetigkeiten fuer Kapazitaetsplanung nutzen
+
+**Abgrenzung**: Abteilungsverwaltung (2.14) hat nur "Abteilung erstellen" und "Abteilung zuordnen". Die Taetigkeitsebene fehlt.
+
+---
+
+#### B7. Artikel-Lifecycle-Sonderfaelle
+**Quelle**: USE_CASES_STATE_MACHINES.md
+**Modul**: State Machines (17.3)
+**Was fehlt in 17.3** (dort nur: Retoure, Verschrottung, Umbuchung, Ersatz):
+- **Artikel verloren bei Inventur** - Buchung und Dokumentation wenn ein Artikel bei der Inventur nicht auffindbar ist
+- **Seriennummer-Abweichung** - Workflow wenn gescannte SN nicht mit erwarteter SN uebereinstimmt
+- **Demo-Geraet deaktivieren** - Spezial-Lifecycle fuer Demo-/Leihgeraete (Aktiv -> Rueckruf -> Aufbereitung -> Wiederverwendung/Entsorgung)
+- **Artikel-Zustandsaenderung** - Aenderung des Zustands (Neu -> Gebraucht, Repariert -> Einsatzbereit)
+- **Batch-Wareneingang** - Einlagerung mehrerer Artikel gleichzeitig (z.B. nach Paletten-Lieferung)
+
+---
+
+#### B8. CRM-Projekt als vollstaendiger Lifecycle
+**Quelle**: USE_CASES_STATE_MACHINES.md (UC-030)
+**Modul**: CRM-Projekte (3.3)
+**Was fehlt**: Die State Machine des CRM-Projekts:
+- Status-Uebergaenge: Opportunity -> Proposal -> Negotiation -> Won/Lost
+- Automatische Eskalation bei Inaktivitaet
+- Win/Loss-Analyse nach Abschluss
+- Pipeline-Ansicht aller Projekte nach Status
+
+**Abgrenzung**: Modul 3.3 hat CRUD-Operationen und "als verloren markieren" (3.3.7), aber den vollstaendigen Sales-Pipeline-Lifecycle mit Statusuebergaengen und Analyse nicht.
+
+---
+
+#### B9. Kontingent-Szenarien (Vertiefung)
+**Quelle**: USE_CASES_WIZARD_WORKFLOWS.md
+**Modul**: Kontingent-State-Machine (17.6)
+**Was fehlt** (17.6 hat nur 4 generische UCs):
+- Geld-Kontingent mit Overbooking-Regelung
+- Stunden-Kontingent fuer Dienstleister
+- Quartals-Kontingent mit Warengruppen-Zuordnung
+- Kontingent-Uebertrag in Folgeperiode
+- Gratis-Perioden (Promotions)
+- Kontingent-Umverteilung waehrend Vertragslaufzeit
+
+---
+
+#### B10. Workflow-Engine / Automatisierungsregeln (UC-042)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Automatisierung (4)
+**Was fehlt**: Eine generische Workflow-Engine:
+- Trigger definieren: Beleg-Status, Datumsregeln, Betragschwellen
+- Aktionen konfigurieren: E-Mail senden, Report generieren, Daten aendern, Aufgabe erstellen
+- Bedingungslogik (Wenn-Dann-Sonst)
+- Workflow-Ketten (Aktion A loest Aktion B aus)
+
+**Abgrenzung**: "Erwartete Events" (4.1/4.2) deckt Event-basierte Triggers ab. Die generische Workflow-Engine geht darueber hinaus - sie verkettet Aktionen und hat Bedingungslogik.
+
+---
+
+## Zusammenfassung
+
+| # | Fehlende Funktion | Typ | Quelle |
+|---|-------------------|-----|--------|
+| **A1** | Kundenportal / Self-Service | Neues Modul | FOLGEMEETING |
+| **A2** | CRM-Aktivitaeten | Neues Modul | FOLGEMEETING |
+| **A3** | Lead-Management | Neues Modul | FOLGEMEETING |
+| **A4** | Arbeitssicherheit / Qualitaets-Compliance | Neues Modul | DB-Schema |
+| **A5** | Social-Media-Management | Neues Modul | DB-Schema |
+| **B1** | Warenausgang | Fehlender Prozess in Logistik | FOLGEMEETING |
+| **B2** | Allgemeine Bestandsfuehrung | Fehlender Prozess in Logistik | FOLGEMEETING |
+| **B3** | Lagerwert-Report | Fehlender Report in Controlling | FOLGEMEETING |
+| **B4** | Aufwand/Kosten-Analyse | Fehlender Report in Controlling | FOLGEMEETING |
+| **B5** | Automatische Abrechnung | Fehlender Prozess in Abrechnung | FOLGEMEETING |
+| **B6** | Abteilungstaetigkeiten | Fehlend in Administration | DB-Schema |
+| **B7** | Artikel-Lifecycle-Sonderfaelle (5 Stueck) | Fehlend in State Machines | State Machines |
+| **B8** | CRM-Projekt Sales Pipeline | Fehlend in CRM-Projekte | State Machines |
+| **B9** | Kontingent-Szenarien (6 Stueck) | Fehlende Tiefe in Vertraege | Wizard Workflows |
+| **B10** | Workflow-Engine / Automatisierungsregeln | Fehlend in Automatisierung | FOLGEMEETING |

Versuche/Versuch 04/Return3.md

@@ -0,0 +1,241 @@
+# Use-Case-Vergleich: UseCases_Short.md vs. andere Dateien
+
+## Referenz-Datei: ERP_WEB/UseCases_Short.md
+- **748 Use Cases** in 17 Modulen (1-17)
+- Deckt ab: Abrechnung, Administration, Adressen/CRM, Automatisierung, Buchhaltung, Controlling, Einkauf, Verkauf, Helpdesk, MyCentron, Logistik, Stammdaten, Vertraege, CentronNexus, Asset Management, Terminverwaltung, State Machines & Wizards
+
+> **Ignoriert**: Produktionsplanung, TicketManagement, RMM-Anbindung, REST API Endpunkte, Validierungsregeln
+
+---
+
+## Fehlende Anwendungsfunktionen (in anderen Dateien, NICHT in UseCases_Short.md)
+
+### A. Komplett fehlende Funktionsbereiche
+
+#### A1. Kundenportal / Self-Service (UC-070)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Was fehlt**: Ein kundengerichtetes Portal, in dem Kunden (nicht Mitarbeiter!) ihre Daten einsehen koennen:
+- Beleg-Uebersicht (Rechnungen, Lieferscheine, Angebote)
+- Zahlungshistorie
+- Kontaktinformationen
+- Optional: Tickets erstellen/einsehen
+
+**Abgrenzung**: CentronNexus (Modul 14) ist das **interne** Web-Portal fuer Mitarbeiter. Das Kundenportal ist eine voellig andere Zielgruppe.
+
+---
+
+#### A2. CRM-Aktivitaeten (UC-031)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Was fehlt**: Erstellen und Verwalten von CRM-Aktivitaeten als eigene Entitaet:
+- Anrufe protokollieren
+- Kundenbesuche dokumentieren
+- E-Mail-Korrespondenz verknuepfen
+- Notizen/Vermerke erstellen
+- Wiedervorlagen/Follow-ups planen
+- Aktivitaeten einem Kunden zuordnen
+
+**Abgrenzung**: UC 3.1.4 "Adresse mit Aktivitaetshistorie anzeigen" zeigt nur die Historie an - es gibt keinen Use Case fuer das ERSTELLEN und VERWALTEN von Aktivitaeten.
+
+---
+
+#### A3. Lead-Management / Anfragen (UC-032)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Was fehlt**: Der gesamte Prozess von der Anfrage bis zum Angebot:
+- Anfrage/Lead erfassen (Webformular, Telefon, Messe)
+- Lead qualifizieren (Interessensprofil, Budget, Dringlichkeit)
+- Lead-Status tracken (Neu, Kontaktiert, Qualifiziert, Verloren)
+- Lead zu Angebot/Kunde konvertieren
+
+**Abgrenzung**: CRM-Projekte (3.3) beginnen erst bei einem konkreten Projekt. Der fruehe Vertriebstrichter (Lead -> Opportunity) fehlt.
+
+---
+
+#### A4. Arbeitssicherheit / Qualitaets-Compliance
+**Quelle**: UNDOCUMENTED_USE_CASES_DATABASE_MODELS.md
+**DB-Tabellen vorhanden**: AGArbeitssicherheit, AGMaterial, AGUmweltschutz, AGPrufvorschrift, ArtikelAGArbeitssicherheit, ArtikelAGMaterial, Arbeitssicherheit
+**Was fehlt**: Ein ganzes Modul fuer Arbeits-/Qualitaetssicherheit:
+- Sicherheitschecklisten pro Arbeitsplatz/Taetigkeit verwalten
+- Materialsicherheit dokumentieren (Gefahrstoffe, Umgang)
+- Umweltschutzanforderungen erfassen und pruefen
+- Pruefvorschriften fuer Artikel/Materialien definieren
+- Arbeitssicherheits-Audits durchfuehren und dokumentieren
+- Compliance-Berichte fuer ISO-Zertifizierungen generieren
+
+**Hinweis**: Nicht zu verwechseln mit den Compliance-Erwaenungen in UseCases_Short (DSGVO 2.2, Report-Compliance 12.7.5 etc.) - dort geht es um Daten-Compliance. Hier geht es um **physische Arbeitssicherheit und Materialqualitaet**.
+
+---
+
+#### A5. Social-Media-Management
+**Quelle**: UNDOCUMENTED_USE_CASES_DATABASE_MODELS.md
+**DB-Tabellen vorhanden**: SocialMediaStream, SocialMediaStreamAccount, SocialMediaAction, SocialMediaComment, SocialMediaLike
+**Was fehlt**:
+- Social-Media-Accounts verknuepfen (Facebook, Twitter, LinkedIn)
+- Social-Media-Feeds ueberwachen
+- Posts planen und veroeffentlichen
+- Kommentare und Interaktionen verwalten
+- Engagement-Metriken analysieren
+- Leads aus Social Media generieren
+
+---
+
+### B. Fehlende Funktionen in bestehenden Modulen
+
+#### B1. Warenausgang (UC-021)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Logistik (11)
+**Was fehlt**: Der Warenausgang als eigenstaendiger Prozess:
+- Lagerausbuchung bei Lieferschein-Erstellung
+- FIFO-/Seriennummern-Auswahl beim Ausbuchen
+- Bestandsaktualisierung nach Warenausgang
+- Warenausgangs-Protokoll/Beleg
+
+**Abgrenzung**: Kommissionierung (11.4) ist das Zusammenstellen der Ware. Warenausgang ist die tatsaechliche Bestandsreduzierung und Buchung.
+
+---
+
+#### B2. Allgemeine Bestandsfuehrung (UC-022)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Logistik (11)
+**Was fehlt**: Laufende Bestandsverwaltung zwischen Inventuren:
+- Lagerbestandsabfrage (Menge, Reserviert, Verfuegbar)
+- Lagerumbuchung zwischen Lagerorten
+- Manuelle Bestandskorrektur mit Begruendung
+- Mindestbestandswarnungen
+- Bestandsabstimmung (Soll/Ist-Vergleich)
+
+**Abgrenzung**: Inventur (11.3) ist die periodische Zaehlung. Bestandsfuehrung ist der taegliche Umgang mit Bestaenden.
+
+---
+
+#### B3. Lagerwert-Report (UC-061)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Controlling (6)
+**Was fehlt**: Ein dedizierter Lagerwert-Bericht:
+- Bestaende x Einstandspreis = Lagerwert
+- FIFO- vs. Durchschnittsbewertung
+- Slow-Mover-Identifikation
+- Abweichungsanalyse (Bewertungsdifferenzen)
+- Lagerwert-Entwicklung ueber Zeit
+
+**Abgrenzung**: UC 6.1.8 "Lagerbestands-Entwicklung und Umschlag" erwaehnt Mengen, aber nicht die wertmaessige Betrachtung (Lagerbewertung, Slow-Mover, FIFO).
+
+---
+
+#### B4. Aufwand/Kosten-Analyse (UC-062)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Controlling (6)
+**Was fehlt**: Uebergreifende Aufwands- und Kostenanalyse:
+- Zeitaufwand pro Kunde/Projekt aggregieren
+- Kostenvergleich: geplant vs. tatsaechlich
+- Gewinnmarge pro Projekt/Kunde berechnen
+- Aufwand/Kosten-Report exportieren
+
+**Abgrenzung**: Kostentraeger/Kostenstellen (12.3) ist Stammdaten-Verwaltung. Hier geht es um die analytische Auswertung.
+
+---
+
+#### B5. Automatische Abrechnung (UC-041)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Abrechnung (1) / Automatisierung (4)
+**Was fehlt**: Zeitgesteuerte Abrechnung ohne Benutzereingriff:
+- Regelmaessige Abrechnungsjobs konfigurieren (taeglich, woechentlich, monatlich)
+- MSP-Gebuehren automatisch fakturieren
+- Vertragsgebundene Abrechnungen nach Intervall ausfuehren
+- Ergebnis-Benachrichtigung an Sachbearbeiter
+
+**Abgrenzung**: Modul 1.1 (Vertragsabrechnung) ist ein Wizard, den ein Benutzer manuell durchlaeuft. UC-041 beschreibt die vollautomatische Abrechnung im Hintergrund.
+
+---
+
+#### B6. Abteilungstaetigkeiten
+**Quelle**: UNDOCUMENTED_USE_CASES_DATABASE_MODELS.md
+**DB-Tabellen**: AbtTaetigkeiten, AbtTaetigkeitenZuordnung
+**Modul**: Administration (2.14)
+**Was fehlt**: Verwaltung von Taetigkeiten pro Abteilung:
+- Taetigkeitsprofile definieren (z.B. "Vertrieb Innendienst", "Service Aussendienst")
+- Mitarbeiter Taetigkeiten zuordnen
+- Taetigkeiten fuer Kapazitaetsplanung nutzen
+
+**Abgrenzung**: Abteilungsverwaltung (2.14) hat nur "Abteilung erstellen" und "Abteilung zuordnen". Die Taetigkeitsebene fehlt.
+
+---
+
+#### B7. Artikel-Lifecycle-Sonderfaelle
+**Quelle**: USE_CASES_STATE_MACHINES.md
+**Modul**: State Machines (17.3)
+**Was fehlt in 17.3** (dort nur: Retoure, Verschrottung, Umbuchung, Ersatz):
+- **Artikel verloren bei Inventur** - Buchung und Dokumentation wenn ein Artikel bei der Inventur nicht auffindbar ist
+- **Seriennummer-Abweichung** - Workflow wenn gescannte SN nicht mit erwarteter SN uebereinstimmt
+- **Demo-Geraet deaktivieren** - Spezial-Lifecycle fuer Demo-/Leihgeraete (Aktiv -> Rueckruf -> Aufbereitung -> Wiederverwendung/Entsorgung)
+- **Artikel-Zustandsaenderung** - Aenderung des Zustands (Neu -> Gebraucht, Repariert -> Einsatzbereit)
+- **Batch-Wareneingang** - Einlagerung mehrerer Artikel gleichzeitig (z.B. nach Paletten-Lieferung)
+
+---
+
+#### B8. CRM-Projekt als vollstaendiger Lifecycle
+**Quelle**: USE_CASES_STATE_MACHINES.md (UC-030)
+**Modul**: CRM-Projekte (3.3)
+**Was fehlt**: Die State Machine des CRM-Projekts:
+- Status-Uebergaenge: Opportunity -> Proposal -> Negotiation -> Won/Lost
+- Automatische Eskalation bei Inaktivitaet
+- Win/Loss-Analyse nach Abschluss
+- Pipeline-Ansicht aller Projekte nach Status
+
+**Abgrenzung**: Modul 3.3 hat CRUD-Operationen und "als verloren markieren" (3.3.7), aber den vollstaendigen Sales-Pipeline-Lifecycle mit Statusuebergaengen und Analyse nicht.
+
+---
+
+#### B9. Kontingent-Szenarien (Vertiefung)
+**Quelle**: USE_CASES_WIZARD_WORKFLOWS.md
+**Modul**: Kontingent-State-Machine (17.6)
+**Was fehlt** (17.6 hat nur 4 generische UCs):
+- Geld-Kontingent mit Overbooking-Regelung
+- Stunden-Kontingent fuer Dienstleister
+- Quartals-Kontingent mit Warengruppen-Zuordnung
+- Kontingent-Uebertrag in Folgeperiode
+- Gratis-Perioden (Promotions)
+- Kontingent-Umverteilung waehrend Vertragslaufzeit
+
+---
+
+#### B10. Workflow-Engine / Automatisierungsregeln (UC-042)
+**Quelle**: FOLGEMEETING_VORBEREITUNG.md
+**Modul**: Automatisierung (4)
+**Was fehlt**: Eine generische Workflow-Engine:
+- Trigger definieren: Beleg-Status, Datumsregeln, Betragschwellen
+- Aktionen konfigurieren: E-Mail senden, Report generieren, Daten aendern, Aufgabe erstellen
+- Bedingungslogik (Wenn-Dann-Sonst)
+- Workflow-Ketten (Aktion A loest Aktion B aus)
+
+**Abgrenzung**: "Erwartete Events" (4.1/4.2) deckt Event-basierte Triggers ab. Die generische Workflow-Engine geht darueber hinaus - sie verkettet Aktionen und hat Bedingungslogik.
+
+---
+
+## Implementierung
+
+### Schritt 1: Datei kopieren
+- Kopiere `ERP_WEB/UseCases_Short.md` nach `ERP_WEB/UseCases_Short_V2.md`
+
+### Schritt 2: Fehlende Use Cases einfuegen (an passender Stelle im Dokument)
+
+**Einfuegestellen und neue UCs:**
+
+| Position in Datei | Was einfuegen |
+|---|---|
+| Nach 1.1 (Vertragsabrechnung) | **1.x Automatische Abrechnung** (B5) - zeitgesteuerte Abrechnung |
+| Nach 3.1 (Adressstamm) | **3.x CRM-Aktivitaeten** (A2) - Anrufe, Besuche, Mails, Notizen |
+| Nach 3.3 (CRM-Projekte) | CRM-Projekt-Lifecycle als State Machine ergaenzen (B8) |
+| Nach 3.4 (Kampagnen) | **3.x Lead-Management** (A3) - Anfragen, Leads, Qualifizierung |
+| Nach 3.4 (Kampagnen) | **3.x Social-Media-Management** (A5) |
+| Nach 4.2 (Erwartete Events) | **4.x Workflow-Engine** (B10) |
+| Nach 6.1 (Analytics) | **6.x Lagerwert-Report** (B3) und **6.x Aufwand/Kosten-Analyse** (B4) |
+| Nach 11.3 (Inventur) | **11.x Warenausgang** (B1) und **11.x Bestandsfuehrung** (B2) |
+| Nach 2.14 (Abteilungsverwaltung) | **2.x Abteilungstaetigkeiten** (B6) |
+| Neues Modul 18 | **Arbeitssicherheit / Qualitaets-Compliance** (A4) |
+| Neues Modul 19 | **Kundenportal / Self-Service** (A1) |
+| In 17.3 (Artikel-Lifecycle) | 5 Sonderfaelle ergaenzen (B7) |
+| In 17.6 (Kontingent) | 6 spezifische Szenarien ergaenzen (B9) |
+
+### Schritt 3: Nummerierung konsistent halten
+- Neue Unterkategorien erhalten die naechste freie Nummer im jeweiligen Modul
+- Stil und Format beibehalten (#### fuer UC-Titel, Beschreibungstext darunter)