---
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`