Schlüssel und Rechte
Datenwörterbuch und Berechtigungen werden für die unterstützte Version geprüft. Ein fremder Mandant bleibt auch bei bekannter Referenz ausgeschlossen.
Das Modell muss mit der tatsächlich verwendeten API-Semantik übereinstimmen.
Datenmodell und Ledger
Ein Datenmodell für Teilnehmer, Regeln und Buchungen
Erkennen Sie, wo Daten entstehen, welches System sie führt und wie aus einem Ereignis eine überprüfbare Buchung wird.
Dieselben Objekte für Architektur und FinanceEin Mitglied ist kein Konto.
Ein Mitglied ist kein Konto.
Ein Ereignis ist noch keine Buchung.
Wer die Objekte und ihre Zuständigkeit sauber trennt, kann normale Vorgänge ebenso erklären wie Retouren, Dubletten und spätere Korrekturen.
Organisation
Mandant → Programm → Markt
Marke, Region und Partner setzen den fachlichen Rahmen. Rollen bestimmen den zulässigen Datenbereich.
Teilnahme
Mitglied → Konto → Berechtigung
Profil, Firmen- oder Haushaltsbezug und Consent verbinden Identität mit erlaubter Nutzung.
Geschäftsvorfall
Ereignis → Entscheidung → Ledger
Eine stabile Referenz verbindet Herkunft, gültige Regel und konkrete Wertbewegung.
Artikel und Katalog · Anspruch · Gutschein · Bestellung · Auszahlung
Je Objekt: führendes System, Schlüssel, Zustand und Aufbewahrung
Je Objekt: führendes System, Schlüssel, Zustand und Aufbewahrung
Für jedes Objekt eine klare QuelleWissen, welches System
Wissen, welches System
welchen Stand führt.
| Objekt | Hoheit und Schlüssel | Abgleichfrage |
|---|---|---|
| Mitglied / Profil | Führende Identität und externe Referenz beispielsweise aus CRM oder einem vereinbarten Teilnehmerprozess. | Wie werden Änderungen und mögliche Dubletten kontrolliert übernommen? |
| Artikel / Katalog | Bestätigter Produktstamm und Zuordnungen aus dem zuständigen ERP- oder Katalogprozess. | Welche Version gilt bei der Qualifikation eines historischen Kaufs? |
| Kauf / Ereignis | Stabile fachliche Event-ID und Herkunft aus POS, Shop, ERP oder geprüftem Beleg. | Ist die Meldung neu, verspätet oder erneut zugestellt? |
| Regel / Entscheidung | Gültige Regelversion mit Ergebnis, Begründung und wirksamem Zeitpunkt. | Warum wurde gerade dieser Vorteil gewährt oder abgelehnt? |
| Ledger / Einlösung | Buchungsreferenz, Zustand und Programmwährung im führenden Wertprozess. | Welche Reservierung oder Gegenbuchung gehört zum Vorgang? |
| Bestellung / Auszahlung | Auftrag und bestätigter externer Status beim verantwortlichen Partner. | Wurde die Wirkung bereits ausgeführt oder nur angefordert? |
Wie werden Replikation und Aufbewahrung festgelegt?
Jede Kopie bekommt einen Zweck und einen Aktualitätsanspruch. Ein DWH kann analytische Daten vorhalten, während das Ledger den verbindlichen Wertstand führt. Aufbewahrung, Löschung und Zugriff richten sich nach dem jeweiligen Objekt und dem abgestimmten Konzept. Das Datenwörterbuch dokumentiert diese Zuordnung versionsgebunden.
Vom Nachweis zur WertbewegungDrei Datensätze.
Drei Datensätze.
Eine erklärbare Herkunft.
Das Ereignis beschreibt, was gemeldet wurde. Die Entscheidung erklärt, welche Regel angewendet wurde. Der Ledger-Eintrag hält die konkrete Wertbewegung fest.
Diese Trennung macht Fehler untersuchbar. Eine technisch angenommene Meldung kann fachlich abgelehnt werden. Eine positive Entscheidung kann noch auf Freigabe warten. Der Kontostand darf diese unterschiedlichen Zustände nicht verbergen.
Was gehört in die Buchungsreferenz?
Stabile Ereignis-ID, Regelbezug, Programmwährung und Zeitstempel verbinden die Wirkung mit ihrer Quelle. Eine Korrektur erhält einen eigenen Bezug zum Ursprung. Interne technische IDs und externe fachliche Referenzen werden nicht ungeprüft gleichgesetzt.
Herkunft verfolgenSynthetisches Beispiel
Geschäftsvorfall Event-ID: K-001 Quelle: POS-DEMO Mitglied: M-001 Typ: qualifizierter Kauf Noch keine Aussage über den gebuchten Vorteil.
Werte niemals still überschreibenKauf +100. Einlösung −30.
Kauf +100. Einlösung −30.
Teilretoure −20. Verfügbar 50.
Kontoverlauf M-001Beispiel · Punkte
Kauf freigegebenK-001 / V-01
+100100Prämie bestätigtE-001 / Reservierung RES-01
−3070TeilretoureR-001 / Bezug K-001
−2050Erneute KaufmeldungK-001 / bereits verarbeitet
050Bestand nach den Beispielvorgängen50 Punkte
Reservierung gegen Doppelnutzung
Bei parallelen Einlösungen muss die maßgebliche Grenze atomar geprüft und verändert werden. Zwei gleichzeitige Anfragen dürfen nicht beide denselben verfügbaren Wert verbrauchen. Eine bloße Anzeige im Frontend genügt dafür nicht.
Verspätung und Replay
Eine verspätete Meldung braucht eine definierte zeitliche Einordnung. Ein Replay darf bereits wirksame Ereignisse nicht nochmals vergüten. Die ursprüngliche Gültigkeit einer Regel und der tatsächliche Verarbeitungszeitpunkt bleiben unterscheidbar.
Identität verändern, Herkunft erhaltenZusammenführen, trennen,
Zusammenführen, trennen,
exportieren und beenden.
Ein Profil kann sich ändern. Die Geschichte eines wertrelevanten Vorgangs darf dadurch nicht unerklärbar werden.
Dublettenprüfung und Identitätsabgleich legen fest, wann zwei Datensätze tatsächlich dieselbe Teilnahme betreffen. Ein Merge oder Split erhält Freigabe, betroffenen Umfang und einen nachvollziehbaren Umgang mit Konten, offenen Reservierungen und historischen Referenzen.
Wie passen Löschung und Geschäftsvorfall zusammen?
Personenbezogene Profildaten und begründet weiter aufzubewahrende Geschäftsbelege benötigen unterschiedliche Lebenszyklen. Löschung oder Pseudonymisierung wird mit dem abgestimmten Zweck- und Aufbewahrungskonzept verbunden. Es wird nicht pauschal jede Buchung gelöscht oder jede Person dauerhaft im Audit vervielfältigt.
Was braucht ein portables Exportpaket?
Objekte, Felder, Schlüsselbeziehungen, Zustände und Datenstand gehören in das Paket. Kontostände benötigen eine Beziehung zu Herkunft und offenen Vorgängen. Ein Datenwörterbuch und eine Mengen- beziehungsweise Saldenabstimmung machen den Export für ein Zielsystem tatsächlich nutzbar.
Ein Datenmodell an einem echten Fall erklärenErst verfolgen.
Erst verfolgen.
Dann gemeinsam freigeben.
Korrektur und Abstimmung
Kauf, Einlösung und Teilretoure werden bis zur Gegenbuchung und zum ERP-Abgleich durchlaufen. Offene Reservierungen werden separat betrachtet.
Saldo, Einzelbewegung und externer Status müssen zusammen erklärbar sein.
Migration und Exit
Herkunft, Verfall, Status und offene Vorgänge werden bereits vor der Übernahme inventarisiert. Ein Rückfallplan schützt den Übergang.
Eine importierte Gesamtsumme ersetzt keine nachvollziehbare Bestandshistorie.
Passende Bausteine
Hier geht Ihr Thema weiter.
Lassen Sie uns konkret werden
Ihr Vorhaben. Unser gemeinsamer nächster Schritt.
Besprechen wir Ihre Zielgruppe, Ihre Datenquellen und den Ablauf, den Sie verbessern möchten. Daraus entsteht eine Demo, die zu Ihrem Programm passt.
Ihre Demo beginnt mit Ihrem Alltag.
Ein normaler Vorgang. Ein Sonderfall. Die beteiligten Systeme. Wir zeigen, wie Regeln, Kanäle und Kontrolle zusammenspielen.