83 lines
3.8 KiB
Markdown
83 lines
3.8 KiB
Markdown
---
|
||
type: Guide
|
||
status: ACTIVE
|
||
owner: 🧹 Curator & 🏗️ Lead Architect
|
||
last_update: 2026-04-02
|
||
sources:
|
||
- docs/03_Domain/01_Glossary/Ubiquitous_Language.md
|
||
- Domain Workshop 2026-03-17
|
||
---
|
||
|
||
# Event‑First‑Workflow (MVP)
|
||
|
||
Ziel: Ein neuer Veranstaltungs‑Durchlauf wird konsequent „Event‑First“ aufgebaut. Dabei folgt der Bedienfluss strikt der Domänen‑Hierarchie:
|
||
|
||
Veranstaltung → Turnier → Bewerbe → Abteilungen → Startliste
|
||
|
||
---
|
||
|
||
## 1. Vorbedingungen
|
||
|
||
- Verein (→ Begriff: Veranstalter) ist im System vorhanden.
|
||
- Grundlegende Stammdaten synchron (Reiter, Pferde, Vereine) – optional für die Planung, erforderlich für Startlisten.
|
||
|
||
Querverweis: → Ubiquitous Language, Abschnitt „Hierarchie der Veranstaltungs‑Struktur“ und Begriffe „Veranstaltung“, „Turnier“, „Bewerb“, „Abteilung“, „Startliste“.
|
||
|
||
---
|
||
|
||
## 2. Schritt‑für‑Schritt
|
||
|
||
1) Veranstaltung anlegen
|
||
- Eingaben: Titel, Datum(e), Ort, Typ (Turnier, Reitertreffen, …), Veranstalter (Vereinsnummer), interne Event‑ID (System vergibt).
|
||
- Output: Veranstaltung existiert, → Veranstaltungs‑Kassa und → TeilnehmerKonto‑Container werden vorbereitet.
|
||
|
||
2) Turnier anlegen (innerhalb der Veranstaltung; mehrfach möglich)
|
||
- Eingaben: Turniernummer (offiziell, wenn vorhanden), Sparte(n) (z. B. CDN, CSN), Kategorie (C‑NEU, C, …), geplanter Zeitraum.
|
||
- Output: Turnier angelegt, → Turnierkassa eröffnet; Ausschreibungs‑Metadaten vorbereiten.
|
||
|
||
3) Bewerbe anlegen (pro Turnier)
|
||
- Eingaben: fortlaufende Bewerbsnummer, Bezeichnung, Klasse/Höhe, Richtverfahren, Startberechtigungen.
|
||
- Output: Bewerbe als Container für Abteilungen vorhanden.
|
||
|
||
4) Abteilungen planen/anlegen (pro Bewerb, mindestens eine)
|
||
- Eingaben: Abteilungsnummer (fortlaufend), Abteilungs‑Typ: `SEPARATE_SIEGEREHRUNG` oder `ORGANISATORISCH`, optional Teilnehmerkreis‑Filter (Lizenz, Altersklasse …).
|
||
- Systemhinweis: Bei Überschreiten von ÖTO‑Schwellenwerten zeigt das System WARNUNG + Option „Override“ (→ TBA hat letztes Wort).
|
||
- Output: Abteilungen stehen für Nennungen/Startlisten bereit.
|
||
|
||
5) Startliste erzeugen (pro Abteilung)
|
||
- Eingaben: Nennungen (Paar Reiter+Pferd), Reihenfolgen‑Logik (z. B. Zufall, Startwunsch), Kollisionen prüfen.
|
||
- Output: Fixierte Startliste je Abteilung; Grundlage für Ergebniserfassung und Abrechnung (Sportförderbeitrag, Tierwohl‑Euro pro Start).
|
||
|
||
---
|
||
|
||
## 3. Rollen & Verantwortungen
|
||
|
||
- Meldestelle: Erfassung/Prüfung der Daten, Startlistenpflege, Kassenabwicklung.
|
||
- TBA (Turnierbeauftragter): Genehmigung von Abteilungs‑Overrides und Regel‑Abweichungen (Override‑Event wird protokolliert).
|
||
- Veranstalter: Finanzielle Verantwortung, Kassen‑Schluss, Freigabe der Ausschreibung.
|
||
|
||
---
|
||
|
||
## 4. Artefakte & Systemobjekte
|
||
|
||
- Veranstaltung (Root) → Veranstaltungs‑Kassa, TeilnehmerKonto‑Container, Multi‑Turnier‑Verrechnung.
|
||
- Turnier → Turnierkassa, Ausschreibung.
|
||
- Bewerb → Liste von Abteilungen.
|
||
- Abteilung → kleinste ausführbare Einheit (Nennungen, Startliste, Ergebnis, Siegerehrung nach Typ).
|
||
|
||
---
|
||
|
||
## 5. Akzeptanzkriterien (MVP)
|
||
|
||
- Erstellung in exakt der Reihenfolge möglich; Zwischenspeichern und spätere Fortsetzung unterstützt.
|
||
- Abteilungen mindestens 1 pro Bewerb; Typ wählbar; Warnungen bei ÖTO‑Schwellenwert‑Überschreitung.
|
||
- Startliste pro Abteilung generierbar; Kollisionen und Startwünsche werden berücksichtigt.
|
||
- Abrechnung: Gebühren pro Start (Sportförderbeitrag, Tierwohl‑Euro) werden korrekt ausgewiesen; Zahlvorgänge können turnierübergreifend auf TeilnehmerKonto verbucht werden (Event‑Ebene).
|
||
|
||
---
|
||
|
||
## 6. Querverweise
|
||
|
||
- Domänenbegriffe: `docs/03_Domain/01_Glossary/Ubiquitous_Language.md`
|
||
- ÖTO‑Schwellenwerte: `docs/03_Domain/02_Reference/OETO_Regelwerk/Abteilungs-Trennungs-Schwellenwerte.md`
|