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

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.
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.
Bewerbe anlegen (pro Turnier)
- Eingaben: fortlaufende Bewerbsnummer, Bezeichnung, Klasse/Höhe, Richtverfahren, Startberechtigungen.
- Output: Bewerbe als Container für Abteilungen vorhanden.
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.
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

3.8 KiB Raw Blame History Unescape Escape