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 new file mode 100644 index 00000000..451ed6a7 --- /dev/null +++ b/docs/03_Domain/01_Core_Model/Entities/Event_Structure_Diagram.md @@ -0,0 +1,89 @@ +# Turnier- & Bewerbsstruktur Diagramm + +Dieses Diagramm zeigt die strukturelle Hierarchie und die Beziehungen zwischen Event, Turnier und Bewerb basierend auf +dem ÖTO-Regelwerk und den Anforderungen der OEPS-Schnittstelle. + +```mermaid +erDiagram +%% Entities + EVENT { + string id PK "UUID" + string name "z.B. Apropos Pferd 2026" + date start_date + date end_date + string location + string organizer_id FK "Veranstalter (Akteur)" + string status "PLANNING, ACTIVE, ARCHIVED" + } + + TOURNAMENT { + 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 ruleset "OETO oder FEI" + } + + COMPETITION { + string id PK "UUID" + string tournament_id FK + string code_internal "2-stellig (B-Satz Pos. 2)" + 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)" + int start_fee "in Cent" + string status "OPEN, RUNNING, FINISHED" + } + + OFFICIALS { + string id PK "UUID" + string tournament_id FK "oder competition_id" + string actor_id FK "Richter / Parcoursbauer" + string role "Hauptrichter, Richter, TD" + } + +%% Relationships + EVENT ||--o{ TOURNAMENT: "beinhaltet" + TOURNAMENT ||--o{ COMPETITION: "besteht aus (B-Satz)" + TOURNAMENT ||--o{ OFFICIALS: "hat Funktionäre (C-Satz)" + COMPETITION ||--o{ OFFICIALS: "wird gerichtet von" +``` + +## Erläuterung zum Modell (Option B) + +### 1. `EVENT` (Veranstaltung) + +Das **Event** ist der übergeordnete organisatorische Rahmen (z.B. "Pferdefestival 2026"). Es hat ein Datum, einen Ort +und einen Veranstalter. Es existiert unabhängig von den strikten OEPS-Regularien und ist primär für die administrative +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. + +### 3. `COMPETITION` (Bewerb / Prüfung) + +Die kleinste sportliche Einheit und das Herzstück der Ausschreibung. +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) + datentechnisch fast wie ein eigener Bewerb behandelt. In unserer Datenbank repräsentieren wir jede Abteilung als + eigene Zeile in der Tabelle `competition` (oder verknüpfen sie intelligent), da jede Abteilung ihre eigene + Ergebnisliste und ihr eigenes Preisgeld hat. +* **Nummerierung:** Intern 2-stellig (`code_internal`), für Turniere ab 100 Bewerben offiziell 3-stellig ( + `code_official` an Stelle 61). +* **Richtverfahren:** Entscheidet darüber, wie Fehler und Zeit (Springen) oder Wertnoten (Dressur) in ein Ranking + übersetzt werden. + +### 4. `OFFICIALS` (Funktionäre) + +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. 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 new file mode 100644 index 00000000..6a7eef84 --- /dev/null +++ b/docs/03_Domain/03_Analysis/Domain_Workshop_Results_2026-03-17.md @@ -0,0 +1,72 @@ +--- +type: Reference +status: ACTIVE +owner: Lead Architect +date: 2026-03-17 +--- + +# Ergebnisse: Domain Workshop vom 17.03.2026 + +**Teilnehmer:** Owner (Fachexperte), 🏗️ [Lead Architect], 📜 [ÖTO/FEI Rulebook Expert], 👷 [Backend Developer], +🎨 [Frontend Expert], 🖌️ [UI/UX Designer] + +## 🎯 Fokus des Workshops + +* 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). + +--- + +## 💡 Erkenntnisse der Agents + +### 📜 [ÖTO/FEI Rulebook Expert] + +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. + +### 👷 [Backend Developer] + +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. + +### 🎨 [Frontend Expert] & 🖌️ [UI/UX Designer] + +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. + +--- +*Nächste Schritte: Detaillierung des ZNS-Imports (Stammdaten & Akteure).*