diff --git a/docs/03_Domain/01_Core_Model/Entities/Event_Structure_Diagram.md b/docs/03_Domain/01_Core_Model/Entities/Event_Structure_Diagram.md index 451ed6a7..e5de59f8 100644 --- a/docs/03_Domain/01_Core_Model/Entities/Event_Structure_Diagram.md +++ b/docs/03_Domain/01_Core_Model/Entities/Event_Structure_Diagram.md @@ -20,7 +20,7 @@ erDiagram string id PK "UUID" string event_id FK string oeps_number "z.B. 21001 (A-Satz)" - string category "z.B. CSN-A, CDN-B" + string category "z.B. CSN-A, CDN-B, CDN-C-NEU" string ruleset "OETO oder FEI" } @@ -31,18 +31,76 @@ erDiagram string code_official "3-stellig (B-Satz Pos. 61)" int division_id "Abteilung (0=keine, 1=Abt. 1...)" string title "z.B. Standardspringprüfung" - string category "Klasse z.B. L, M, S*" string discipline "S (Springen), D (Dressur), C" - string scoring_method "Richtverfahren (z.B. A0, A2)" + string category "Klasse z.B. A, L, M, S*, lizenzfrei" + string scoring_method "Richtverfahren (z.B. A0, A2, AM5, Stil)" int start_fee "in Cent" string status "OPEN, RUNNING, FINISHED" + int planned_duration_per_starter_seconds "Kalkulierte Reitzeit pro Starter" } OFFICIALS { string id PK "UUID" string tournament_id FK "oder competition_id" string actor_id FK "Richter / Parcoursbauer" - string role "Hauptrichter, Richter, TD" + string role "Hauptrichter, Richter, TD, Parcoursbauer" + } + + ACTOR { + string id PK "UUID" + string oeps_id "z.B. 123456" + string type "PERSON, ORGANIZATION" + string name "Vollständiger Name" + string license_code "z.B. R1" + } + + QUALIFICATION { + string id PK "UUID" + string actor_id FK + string discipline "S, D, V" + string level "z.B. L, M, S" + string role "RICHTER, PARCOURSBAUER" + } + + ENTRY { + string id PK "UUID" + string competition_id FK + string horse_id FK + string rider_id FK + string status "ACTIVE, WITHDRAWN" + string preferred_start_position "Optional: vorne, hinten, zu" + } + + START_LIST_ENTRY { + string id PK "UUID" + string entry_id FK + int start_order "Nummer in der Startreihenfolge" + string status "READY, IN_PROGRESS, FINISHED, DNS" + } + + RESULT { + string id PK "UUID" + string start_list_entry_id FK + int rank "Platzierung (kann manuell überschrieben werden)" + string status "OK, EL, RET, DNS" + float points "Fehlerpunkte / Wertnote" + float time_seconds "Benötigte Zeit" + int prize_money "Ausbezahltes Geld in Cent" + } + + BILLING_ACCOUNT { + string id PK "UUID" + string event_id FK + string payer_id FK "Akteur (Zahler)" + int current_balance "in Cent" + } + + TRANSACTION { + string id PK "UUID" + string account_id FK + string entry_id FK "Optionaler Bezug zur Nennung" + string type "NENNGELD, STARTGELD, TAUSCHGEBÜHR, NACHNENNUNG" + int amount "in Cent" } %% Relationships @@ -50,9 +108,16 @@ erDiagram TOURNAMENT ||--o{ COMPETITION: "besteht aus (B-Satz)" TOURNAMENT ||--o{ OFFICIALS: "hat Funktionäre (C-Satz)" COMPETITION ||--o{ OFFICIALS: "wird gerichtet von" + OFFICIALS }o--|| ACTOR: "ist ein" + ACTOR ||--o{ QUALIFICATION: "hat Berechtigungen" + COMPETITION ||--o{ ENTRY: "hat Nennungen" + ENTRY ||--o| START_LIST_ENTRY: "wird zu Starter" + START_LIST_ENTRY ||--o| RESULT: "hat Ergebnis" + EVENT ||--o{ BILLING_ACCOUNT: "verwaltet Kassa für" + BILLING_ACCOUNT ||--o{ TRANSACTION: "verbucht" ``` -## Erläuterung zum Modell (Option B) +## Erläuterung zum Modell ### 1. `EVENT` (Veranstaltung) @@ -61,17 +126,17 @@ und einen Veranstalter. Es existiert unabhängig von den strikten OEPS-Regularie Verwaltung (Rechnungsstellung, Anlagenplanung) wichtig. ### 2. `TOURNAMENT` (Turnier) - Ein Event kann mehrere **Turniere** beinhalten (z.B. ein nationales CSN-B und gleichzeitig ein internationales CSI2*). Das Turnier ist die Instanz, die strikt an das Regelwerk gebunden ist: - * Es korrespondiert 1:1 mit dem **A-Satz** des OEPS-Pflichtenhefts. * Es hat eine eindeutige 5-stellige `oeps_number`. -* Es legt fest, nach welchem Regelwerk (ÖTO vs. FEI) geritten und ausgewertet wird. +* Es legt fest, nach welchem Regelwerk (ÖTO vs. FEI) geritten und ausgewertet wird. In der ersten Phase konzentrieren + wir uns auf **C-NEU** und **C**. ### 3. `COMPETITION` (Bewerb / Prüfung) -Die kleinste sportliche Einheit und das Herzstück der Ausschreibung. +Die kleinste sportliche Einheit und das Herzstück der Ausschreibung. Wir fokussieren uns initial auf **Dressur (D)** und +**Springen (S)**. Hier finden wir die direkte Verbindung zum **B-Satz** der Legacy-Spezifikation: * **Abteilungen (`division_id`):** Laut OEPS-Schnittstelle wird jede Abteilung (z.B. R1-Reiter getrennt von R2-Reitern) @@ -82,8 +147,31 @@ Hier finden wir die direkte Verbindung zum **B-Satz** der Legacy-Spezifikation: `code_official` an Stelle 61). * **Richtverfahren:** Entscheidet darüber, wie Fehler und Zeit (Springen) oder Wertnoten (Dressur) in ein Ranking übersetzt werden. +* **Zeitplanung:** `planned_duration_per_starter_seconds` ist für die Kalkulation der Startzeiten elementar. -### 4. `OFFICIALS` (Funktionäre) +### 4. `OFFICIALS` & `QUALIFICATION` (Der C-Satz & ZNS-Import) Dies entspricht dem **C-Satz**. Richter und Parcoursbauer müssen einem Turnier oder spezifisch einem Bewerb zugewiesen -werden. Deren 6-stellige OEPS-Nummer (Satznummer) wird für den Ergebnis-Export benötigt. +werden. + +* Neu: Die Entität `QUALIFICATION` bildet die importierten Lizenzstufen aus der ZNS-Datei `RICHT01.DAT` ab. Das Backend + gleicht diese Berechtigungen bei der Zuweisung gegen die Kategorie der `COMPETITION` ab. + +### 5. `ENTRY`, `START_LIST_ENTRY` & `RESULT` (Nennung bis Ergebnis) + +* **`ENTRY` (Nennung):** Die Nennung verknüpft ein Pferd und einen Reiter mit einem bestimmten Bewerb. Hier werden auch + **Startwünsche** (vorne/hinten) erfasst, die für den Telefon-Workflow kritisch sind. +* **`START_LIST_ENTRY` (Startliste):** Generiert aus den aktiven Nennungen. Definiert die exakte Startreihenfolge. +* **`RESULT` (Ergebnis):** Hält die im "Richterturm-Workflow" erfassten Rohdaten (Punkte/Zeit) und die errechnete + Platzierung. Die Platzierung kann bei Bedarf manuell vom Veranstalter überschrieben werden (z.B. wenn mehr Platziert + werden sollen, als die ÖTO vorschlägt). + +### 6. Billing Context (`BILLING_ACCOUNT` & `TRANSACTION`) + +Die Abrechnung (Kassa) wird als separater Bereich an das `EVENT` gehängt. + +* Es wird ein `BILLING_ACCOUNT` pro "Zahler" (meist ein `ACTOR`) geführt. +* Jede Gebühr (Nenngeld, Startgeld, Nachnenngebühr) wird als atomare `TRANSACTION` verbucht. +* Wenn ein **Nennungstausch** stattfindet, bleibt das Nenngeld als positive Transaktion auf dem Account erhalten, + während für die neue Nennung lediglich eine neue Startgeld- oder Tauschgebühr-Transaktion erzeugt wird. Das ermöglicht + maximale Flexibilität. diff --git a/docs/03_Domain/01_Core_Model/Processes/ZNS_Import_Process.md b/docs/03_Domain/01_Core_Model/Processes/ZNS_Import_Process.md new file mode 100644 index 00000000..615bd086 --- /dev/null +++ b/docs/03_Domain/01_Core_Model/Processes/ZNS_Import_Process.md @@ -0,0 +1,101 @@ +# Prozess: ZNS-Import (Master Data Sync) + +**Status:** Draft / Konzept +**Datum:** 17.03.2026 + +## 1. Ausgangslage & Herausforderungen + +Das OEPS stellt die Stammdaten als ZIP-Datei (`zns.zip`) bereit, die in Form von textbasierten ASCII-Dateien (Codepage +850) vorliegen. Die Struktur ist starr, nicht relational und erfahrungsgemäß oft fehlerbehaftet oder unsauber +formatiert (Legacy-Spezifikation V2.4). + +Zusätzlich ändern sich Lizenzstände, Sperrlisten oder Registrierungen laufend. Weiters ist die Meldestelle oft +gezwungen, vor Ort manuelle Korrekturen vorzunehmen oder Daten aus anderen Quellen (z.B. Zuchtverbände wie AWÖ) zu +integrieren. + +## 2. Architektonische Entscheidung: Event Sourcing & CQRS + +Um den Anforderungen (vollständige Historie, turnierspezifischer Datenstand, fehlertoleranter Import, **manuelle +Overrides**) gerecht zu werden, wird der ZNS-Import nach Prinzipien von **Event Sourcing** und **CQRS (Command Query +Responsibility Segregation)** konzipiert. + +* Wir überschreiben keine Daten einfach (`UPDATE`), sondern hängen Änderungen als Ereignisse (`EVENTS`) an. +* Dies ermöglicht es uns, den Stand einer Person oder eines Pferdes für die Ewigkeit exakt zu rekonstruieren, selbst + wenn sich die Stammdaten ändern. + +### 2.1 Der Import-Ablauf (Die "Command" Seite) + +1. **Ingestion:** Der User (Meldestelle) lädt die `zns.zip` hoch oder triggert einen Import aus einer anderen Quelle ( + Zuchtverband). +2. **Parsing & Cleansing:** Ein dedizierter Importer-Service entpackt die ZIP, liest die Dateien zeilenweise (Codepage + 850!) und konvertiert die starren ASCII-Strings in nutzbare DTOs (Data Transfer Objects). Hier greifen erste + Reinigungs-Routinen. +3. **Event Generation:** Der Service vergleicht die geparsten Daten mit dem aktuellen Stand (der "Read Model" + Datenbank). + * Findet er einen neuen Akteur (Satznummer bisher unbekannt), erzeugt er ein `ActorCreatedEvent`. + * Findet er Änderungen (z.B. Lizenz wurde von R1 auf R2 erhöht, oder Sperre wurde gesetzt), erzeugt er ein + `ActorUpdatedEvent` (bzw. spezifischer `LicenseUpgradedEvent`, `ActorLockedEvent`). +4. **Manuelle Korrekturen (Overrides):** Wenn die Meldestelle vor Ort Daten korrigiert (weil die OEPS-Daten falsch + waren), erzeugt das System ein spezielles Event, z.B. `ManualActorCorrectionEvent`. Dieses Event hat eine **höhere + Priorität** als zukünftige `ActorUpdatedEvents` aus dem ZNS-Import, solange der OEPS die Daten in seinem System nicht + korrigiert hat (Lösung z.B. über einen "Ignorier-Zeitstempel" oder Prioritäts-Flags in der Projektion). +5. **Event Log:** Diese Events werden in einem zentralen Event Log (dem "Event Store") persistiert. Dies ist die + absolute Single Source of Truth. + +### 2.2 Die Datenbereitstellung (Die "Query" Seite) + +1. **Projection (Projektion):** Kleine "Listener" hören auf das Event Log und bauen daraus die relationale + Lesedatenbank (SQLite / PostgreSQL) auf. Hierbei wird die Logik angewandt, dass manuelle Korrekturen der Meldestelle + Vorrang vor veralteten Verbandsdaten haben. +2. **Turnier-Snapshot:** Wenn ein Turnier konfiguriert wird oder am Vortag aktualisiert wird, zieht sich das System + einen "Snapshot" (Schnappschuss) der aktuellen Stammdaten und verknüpft diese mit der Turnier-ID. +3. **Zuchtverbands-Daten (Fremdformate):** Die Architektur erlaubt es uns leicht, neue Parser (z.B. für AWÖ-Daten) zu + schreiben. Diese lesen die fremden Formate ein und generieren die gleichen Standard-Events (`HorseCreatedEvent`, aber + evtl. mit Lebensnummer statt OEPS-Satznummer), die dann problemlos in die bestehende Projektion einfließen. + +## 3. Datenhaltung (Konzeptuelles Modell) + +```mermaid +sequenceDiagram + participant User + participant ImporterService as ZNS / AWÖ Importer + participant EventStore as Event Log (Append Only) + participant Projections as DB (Read Models) + User ->> ImporterService: Upload zns.zip (Freitag vor Turnier) + ImporterService ->> ImporterService: Parse & Clean + + rect rgb(200, 220, 240) + Note right of ImporterService: Generierung von Import-Events + ImporterService ->> EventStore: Append: ActorUpdatedEvent(Satznummer: 123456, License: R2) + end + + User ->> EventStore: Manuelle Korrektur am Turniertag + rect rgb(240, 200, 200) + Note right of User: Generierung von Override-Events + User ->> EventStore: Append: ManualActorCorrectionEvent(Satznummer: 123456, Name: "Neuer Name") + end + + EventStore -->> Projections: Update Relational DB (z.B. aktueller Stand) + Note over Projections: Turniersystem liest nur
aus Read Models. Manuelle Korrekturen
gewinnen gegen Import-Daten. +``` + +## 4. Vorteile dieser Architektur + +* **Audit-Sicherheit:** Wir wissen exakt, *wann* sich *was* geändert hat. Nichts geht verloren. +* **Archivierung:** Ein Turnier-Archiv muss nicht mehr mühsam als riesiger PDF/Daten-Dump gesichert werden. Wir können + das Turnier einfach anhand des Timestamps gegen den Event Store abfragen. +* **Fehlertoleranz:** Wenn ein Parsing-Fehler auftritt oder der OEPS kaputte Daten liefert, machen wir einfach ein + Rollback der fehlerhaften Events und projizieren die Datenbank neu. Wir zerschießen nicht die operativen Tabellen. +* **Erweiterbarkeit (Vision):** Wenn später ein "Ergebnis-Analyse-Service" oder ein "Züchter-Portal" angebunden wird, + können diese einfach die historischen Events abonnieren (Kafka/Message Queue). +* **Integration von Drittsystemen (Zuchtverbände):** Fremddaten können durch eigene Parser in unsere Standard-Events + übersetzt und nahtlos integriert werden. + +## 5. Zu klärende Details für die Implementierung + +* **Sync-Mechanismus:** Wie kommen die Events vom Master-Server auf den Offline-Laptop im Plumpsklo? (Vermutlich eine + robuste Sync-Queue, Kafka könnte für den Offline-Einsatz zu schwergewichtig sein, Alternativen evaluieren). +* **Event-Payload:** Definition der JSON-Struktur für die wichtigsten Events (`zns.actor.updated`, + `zns.horse.registered`). +* **Merge-Logik:** Wie lange bleibt ein `ManualActorCorrectionEvent` gültig, bevor ein zukünftiges Update vom ZNS diesen + Wert wieder überschreiben darf? diff --git a/docs/03_Domain/03_Analysis/Domain_Workshop_Results_2026-03-17.md b/docs/03_Domain/03_Analysis/Domain_Workshop_Results_2026-03-17.md index 6a7eef84..e02664c2 100644 --- a/docs/03_Domain/03_Analysis/Domain_Workshop_Results_2026-03-17.md +++ b/docs/03_Domain/03_Analysis/Domain_Workshop_Results_2026-03-17.md @@ -1,72 +1,102 @@ ---- -type: Reference -status: ACTIVE -owner: Lead Architect -date: 2026-03-17 ---- +# Ergebnisse Domain Workshop (17.03.2026) -# Ergebnisse: Domain Workshop vom 17.03.2026 +**Teilnehmer:** Owner, 🏗️ [Lead Architect], 📜 [ÖTO/FEI Rulebook Expert], 👷 [Backend Developer], 🎨 [Frontend Expert], +🖌️ [UI/UX Designer] -**Teilnehmer:** Owner (Fachexperte), 🏗️ [Lead Architect], 📜 [ÖTO/FEI Rulebook Expert], 👷 [Backend Developer], -🎨 [Frontend Expert], 🖌️ [UI/UX Designer] +## 📜 [ÖTO/FEI Rulebook Expert] - Erkenntnisse -## 🎯 Fokus des Workshops +1. **Autorität des Turnierbeauftragten (TBA):** + Die Analyse der ÖTO (§ 24, § 25) bestätigt die Aussage des Owners: Der TBA ist die höchste Instanz vor Ort und kann + in Absprache mit dem Veranstalter von der Ausschreibung abweichende, für alle verbindliche Entscheidungen treffen. + Das System muss daher bei Regelkonflikten immer einen manuellen "Override" durch die Meldestelle ermöglichen. -* Klärung der Kompetenzen vor Ort (Turnierbeauftragter vs. Regelwerk). -* Analyse der Kassenführung und komplexer Gebühren-Szenarien. -* Management von Funktionären und deren Qualifikationen. -* Erster Entwurf für den Workflow der Turnieranlage (UI/UX). +2. **Gebührenlogik & Abrechnung (Das "Hansi"-Szenario):** + Die Komplexität der Gebührenstruktur wurde stark verdeutlicht. Es muss klar unterschieden werden zwischen: + * **Nenngeld** (Grundgebühr, oft im Voraus via ZNS bezahlt) + * **Startgeld** (pro Bewerb) + * **Nachnenngebühren** (Aufschlag bei später Nennung, oft verhandelbar) + * **Nebengebühren** (Sportförderbeitrag, Tierwohl-Euro - pro Start fällig) + Die Möglichkeit für den Veranstalter, auf Gebührenanteile (z.B. Nachnenngebühr) zu verzichten, muss im + Abrechnungssystem einfach abbildbar sein. ---- +3. **Qualifikation von Funktionären:** + Die Qualifikationen für Richter und Parcoursbauer sind in der Datei `RICHT01.DAT` der ZNS-Daten enthalten. Diese + Qualifikationen müssen gegen die Anforderungen des jeweiligen Bewerbs (Klasse, Sparte) validiert werden. -## 💡 Erkenntnisse der Agents +## 👷 [Backend Developer] - Erkenntnisse -### 📜 [ÖTO/FEI Rulebook Expert] +1. **Bounded Context "Billing & Accounting":** + Die Kassenführung ist zu komplex und hat zu viele eigene Regeln, um sie eng mit dem sportlichen Kern ( + Nennung/Ergebnis) zu koppeln. Wir werden dies als separaten Bounded Context mit eigenen Services und einem + dedizierten Datenmodell für Konten, Transaktionen und Gebühren umsetzen. Die Abrechnung muss kontobasiert pro Zahler + erfolgen (nicht nur pro Reiter). -1. **Autorität des Turnierbeauftragten (TBA):** Die Analyse der ÖTO (§ 24, § 25) bestätigt die Praxis-Erfahrung: Der TBA - ist die höchste Instanz vor Ort und kann in Absprache mit dem Veranstalter von der Ausschreibung abweichende, für - alle verbindliche Entscheidungen treffen. **Das System muss daher bei Regelkonflikten immer einen manuellen " - Override" durch die Meldestelle ermöglichen.** -2. **Gebührenlogik & Abrechnung:** Das "Hansi"-Szenario (Klassenüberschreitung, Reiterwechsel, Nachnennung) hat die - enorme Komplexität der Gebührenstruktur verdeutlicht. Es muss zwingend unterschieden werden zwischen: - * **Nenngeld:** Grundgebühr, oft im Voraus via ZNS bezahlt. - * **Startgeld:** Gebühr pro einzelnem Bewerb. - * **Nachnenngebühren:** Strafaufschlag bei später Meldung. - * **Nebengebühren:** Sportförderbeitrag, Tierwohl-Euro (pro Start). - Die Möglichkeit für den Veranstalter, auf Gebührenanteile (z.B. Nachnenngebühr) zu verzichten, muss zwingend - abgebildet werden. -3. **Qualifikation von Funktionären:** Die Qualifikationen für Richter und Parcoursbauer sind in der Datei - `RICHT01.DAT` (ZNS-Daten) enthalten. Diese müssen beim Import ausgelesen und im System gegen die Anforderungen des - jeweiligen Bewerbs (Klasse, Sparte) validiert werden. +2. **Implementierung "Nennungstausch":** + Der Tausch einer Nennung (Reiter/Pferd) wird nicht als reines Storno + Neu-Buchung implementiert, sondern als * + *Transfer-Operation**. Bereits bezahlte Nenngelder werden als Guthaben auf dem Konto des ursprünglichen Zahlers (oder + des Pferdes) geführt und können auf die neue Nennung angerechnet werden. Das System berechnet und verbucht + automatisch die anfallenden Differenzen und Tauschgebühren. -### 👷 [Backend Developer] +3. **Validierungs-Service für Funktionäre:** + Es wird eine Backend-Funktion implementiert, die bei der Zuweisung eines Richters/Parcoursbauers zu einem Bewerb + dessen Qualifikationen (aus den importierten ZNS-Daten) gegen die Anforderungen des Bewerbs prüft. Die API wird bei + einem Mismatch eine `WARNUNG` zurückgeben, aber keinen harten `FEHLER`, um den vom Rulebook Expert bestätigten " + Override" durch die Meldestelle zu ermöglichen. -1. **Neuer Bounded Context "Billing & Accounting":** Die Kassenführung ist zu komplex und eigenständig, um sie mit dem - sportlichen Kern (Nennung/Ergebnis) zu vermischen. Wir etablieren einen separaten Bounded Context mit dediziertem - Datenmodell für **Konten (pro "Zahler"), Transaktionen und Gebühren**. -2. **Architektur "Nennungstausch":** Der Tausch einer Nennung (Reiter oder Pferd) wird *nicht* als einfaches Löschen und - Neuanlegen implementiert. Es wird als **Transfer-Operation** abgebildet. Bereits bezahlte Nenngelder verbleiben als - Guthaben auf dem Konto des ursprünglichen Zahlers (oder sind an das Pferd gebunden) und können auf die neue Nennung - angerechnet werden. Nur Differenzen und Tauschgebühren werden neu verbucht. -3. **Validierungs-Service für Funktionäre:** Es wird ein Service implementiert, das bei der Zuweisung eines - Richters/Parcoursbauers zu einem Bewerb dessen Qualifikationen (aus den ZNS-Daten) prüft. Wichtig: Die API liefert - bei Mismatches nur eine `WARNUNG`, keinen blockierenden `FEHLER`, um den "Override" durch die Meldestelle (siehe - Rulebook Expert) zu garantieren. +4. **ZNS-Import, Fremddaten (Zuchtverbände) & Event Sourcing:** + Die unsauberen und oft wechselnden ZNS-Daten des OEPS werden nicht destruktiv in Datenbanktabellen überschrieben. + Stattdessen wird eine **Event Sourcing** Architektur gewählt. + * Das Hochladen der `zns.zip` triggert einen Parser, der Änderungen (Updates bei Lizenzen, neue Akteure) als + zeitgestempelte Events (z.B. `ActorUpdatedEvent`) in einem "Event Log" ablegt. + * Fremddaten (z.B. von Zuchtverbänden wie dem AWÖ) können über dedizierte Parser eingelesen und in dieselben + Standard-Events übersetzt werden. + * **Manuelle Korrekturen durch die Meldestelle** (wegen fehlerhafter OEPS-Daten) erzeugen "Override-Events", die + Vorrang vor veralteten Import-Daten haben. + * Für die schnelle Anzeige und Offline-Synchronisation werden aus diesen Events saubere Projektionen ("Read Models") + und turnierspezifische Snapshots gebaut. -### 🎨 [Frontend Expert] & 🖌️ [UI/UX Designer] +## 🎨 [Frontend Expert] & 🖌️ [UI/UX Designer] - Erkenntnisse -1. **Workflow-Übernahme (Don't reinvent the wheel):** Die vom Owner bereitgestellten Screenshots des Altsystems ( - `Turnier-Transfer.PNG`, `Turnier-Richter.PNG` etc.) definieren einen praxiserprobten Workflow. Dieser wird als - Blaupause für das neue UI verwendet. -2. **Modernes UI-Konzept (Wizard-Ansatz):** Anstelle vieler separater Fenster (wie im Altsystem) wird die Turnieranlage - in einem **geführten, schrittweisen Prozess** (Wizard oder übersichtliche Tab-Struktur) abgebildet. - * *Schritt 1:* Stammdaten & ZNS-Import - * *Schritt 2:* Konfiguration (Austragungsplätze, Preisliste) - * *Schritt 3:* Team (Zuweisung von Richtern, Parcoursbauern) - * *Schritt 4:* Bewerbsanlage -3. **Smart UI:** Die Oberfläche wird den vertrauten Workflow bieten, aber durch **Echtzeit-Validierung** (z.B. visuelle - Warnung bei Zuweisung eines Richters ohne passende Lizenz) und **intelligente Suchfelder** (Auto-Complete) die - Dateneingabe erheblich beschleunigen und absichern. +1. **Workflow-Übernahme als Grundlage:** + Die vom Owner bereitgestellten Screenshots des Altsystems (`BilderSuDo/`) definieren einen praxiserprobten, schnellen + und vom User extrem gut akzeptierten Workflow. Diese Screens dienen als absolute Blaupause für das neue UI/UX-Design. ---- -*Nächste Schritte: Detaillierung des ZNS-Imports (Stammdaten & Akteure).* +2. **Der "Bewerbe anlegen"-Workflow (`Bewerbe.PNG` etc.):** + * Zweigeteilte Ansicht (Master-Detail): Links Liste/Filter aller Bewerbe, Rechts Detail-Tabs. + * Detail-Tabs gliedern sich in: *Bewertung* (Richtverfahren), *Geldpreis* (Dotierung nach Platzierung), *Ort/Zeit* ( + Ablaufplanung mit Zeit-pro-Starter-Logik). + * *Design-Vorgabe:* Diese Informationsarchitektur wird in moderne Compose-Layouts (z.B. List-Detail-Pane) überführt, + die Logik bleibt identisch. + +3. **Die zentrale "Nennungs-Maske" (`Nennungen.PNG`):** + * Dies ist das **Herzstück der Meldestelle** ("Das Telefon läutet..."). + * Extrem schnelle Suche via Kopfnummer oder Name (mit sofortiger Auto-Completion). + * Anzeige der Meta-Daten (z.B. Besitzer) für sofortige Identifikation. + * Direkte Zuweisung zu Bewerben via Klick aus einer Liste unten. + * Berücksichtigung von Startwünschen ("vorne", "hinten"). + * *Design-Vorgabe:* Diese Maske muss auf **absolute Tastatur- & Schnellbedienbarkeit** optimiert werden (Hotkeys, + Tab-Flow). Sie fungiert als Dashboard (Absprung zu Startliste, Kassa). + * **Self-Service Äquivalenz:** Das Webformular für den Reiter nutzt im Hintergrund dieselbe Logik, um die Meldestelle + maximal zu entlasten. + +4. **Startlisten-Erstellung (`Startlisten.PNG`):** + * Schneller Wechsel zwischen Bewerben über Nummern-Leiste oben (Tab-Ersatz). + * Berücksichtigung der beim Nennen erfassten Wünsche ("vorne", "hinten"). + +5. **Ergebnis-Erfassung am Richterturm (`Ergebnisliste.PNG`):** + * Schnelleingabe-Maske optimiert für den fließenden Ablauf. + * Oben: Gesamtergebnis / Unten: Startliste als Warteschlange / Mitte: Aktueller Reiter in Eingabe. + * Absoluter Fokus auf **"Enter & Tabulator"-Workflow**. Ein Mausklick darf für den Standard-Ablauf nicht nötig sein. + * Spontane Abweichungen von der Startfolge (nächster Reiter kommt früher) müssen durch simplen Doppelklick auf die + Warteschlange lösbar sein. + * Entscheidung über Anzahl der Platzierten bleibt flexibel und ist durch die Meldestelle überschreibbar (ÖTO als + Richtlinie, Veranstalter hat letztes Wort). + +## 🏗️ [Lead Architect] - Strategischer Fokus (MVP Phase 1) + +Um zügig einen echten Mehrwert zu generieren, wird der Scope für die erste Ausbaustufe (MVP) hart eingegrenzt: + +* **Turnier-Kategorien:** Fokus auf **C-NEU** und **C**. +* **Sparten:** Fokus ausschließlich auf **Dressur (D)** und **Springen (S)**. +* *Begründung:* Diese Eingrenzung reduziert die initial benötigte Komplexität der Regelwerks-Implementierung enorm, + deckt aber gleichzeitig das absolute "Brot-und-Butter"-Geschäft für kleine bis mittlere Veranstalter ab.