Datenlandschaft SCK — Systeme, Synchronisierung, Redundanzen

Erstellt: 2026-03-21 | Quelle: API-Abfragen aller 4 Systeme Systeme: Dynamics 365 CS, Business Central, Brevo, FundraisingBox

1. Systemübersicht

Die 4 Kernsysteme

System	Zweck	Kontakte	Besonderheit
Dynamics 365 Customer Service	Service-Center, Teilnehmerverwaltung	≥ 5.000	66.000+ Cases, Vivenu-Integration, 568 Marketing-Listen
Brevo	E-Mail-Marketing, Newsletter	111.508	165 Listen, 475 Kampagnen, Double-Opt-In
FundraisingBox	Spendenverwaltung	3.597	15.190 Spenden, SEPA-Mandate, Zuwendungsbescheinigungen
Business Central	Buchhaltung, ERP	144.820 (Kontakte) / 5.410 (Debitoren)	Debitoren, Kreditoren, Artikel, Rechnungen

Datenvolumen im Vergleich

Datenkategorie	D365 CS	Brevo	FRB	BC
Kontakte/Personen	≥ 5.000	111.508	3.597	144.820
Listen/Segmente	568	165	—	—
E-Mail-Templates	557	30	—	—
Kampagnen	0	475	—	—
Spenden	—	—	15.190	—
Cases/Tickets	66.000+	—	—	—
Debitoren	—	—	—	5.410
Kreditoren	—	—	—	3.340

2. Datensynchronisierung — Ist-Zustand

2.1 Verknüpfungs-IDs (am Beispiel Andreas Knorr)

System	ID-Feld	Wert
D365 CS	contactid	c30fdb38-e433-ed11-9db1-0022489ca32b
D365 CS	cnsc_kontaktnummer	106369
D365 CS	cnsc_bcckmid	3e13cd8d-5706-ef11-a2c4-f266b2857ae6
D365 CS	cnsc_bcsckid	1f73d38e-5706-ef11-a2c4-f266b2857ae6
D365 CS	cnscvv_vivenucontactid	665201bc3023714421ff04f2
Brevo	Kontakt-ID	4518
Brevo	KONTAKTNUMMER_CRM	106369
FRB	fb_person_id	24624583
FRB	external_person_id	106369
BC	Kundennummer	106369
BC	Kontaktnummer	106369
Vivenu	Customer-ID	665201bc3023714421ff04f2

2.2 Synchronisierungsmatrix

                D365 CS ←→ BC
                  ↕           ↕
               Brevo       FRB
                  ↕
               Vivenu → D365 CS

Sync-Richtung	Mechanismus	Verknüpfung	Status
D365 CS → BC	cnsc_bcckmid / cnsc_bcsckid	BC-GUID am D365-Kontakt	Teilweise (nicht alle Kontakte)
BC → D365 CS	Kontaktnummer = Kundennummer	Gleiche Nummer 106369	Manuell/Import
D365 CS → Brevo	KONTAKTNUMMER_CRM	106369 in Brevo	Teilweise (nur 1 von 5 AK-Kontakten in Brevo)
FRB → BC	external_person_id	= BC/D365-Kontaktnummer	Teilweise
Vivenu → D365 CS	cnscvv_vivenucontactid	Vivenu-Kunden-ID	Automatisch (aber fehlerhaft bei Drittbuchungen!)
FRB → Brevo	Kein direkter Link	—	Keine Sync
BC → Brevo	Kein direkter Link	—	Keine Sync
BC → FRB	Kein direkter Link	—	Keine Sync

2.3 Was wird wo synchronisiert?

Datentyp	Quelle	Ziel	Wie
Kontaktstammdaten	D365 CS	BC	BC-IDs am D365-Kontakt (cnsc_bcckmid/bcsckid)
Kontaktnummer	D365 CS	Brevo + FRB	Als external_person_id / KONTAKTNUMMER_CRM
Vivenu-Tickets	Vivenu	D365 CS	Automatischer Import (cnscvv_*-Entities)
Rabattcode	D365 CS (Vivenu)	Brevo	TICKET_RABATTCODE (manuell?)
Marketing-Listen	D365 CS + Brevo	Parallel	Keine Sync — doppelte Pflege!
Spenderdaten	FRB	BC	external_person_id = Debitorennummer
E-Mail-Versand	Brevo	D365 CS	Cases durch Bounce-Mails

3. Redundanzen

3.1 Kontaktdaten — 4-fach gespeichert

Am Beispiel Andreas Knorr:

Feld	D365 CS	Brevo	FRB	BC
Name	Andreas Knorr	Andreas Knorr	Andreas Knorr	Andreas Knorr
E-Mail	anknorr@me.com	anknorr@me.com	anknorr@me.com	anknorr@me.com
Adresse	Vödestr. 75, 58455 Witten	—	Vödestr. 75, 58455 Witten	Vödestr. 75, 58455 Witten
Telefon	+49 2302 24320	—	0230224320	—
Mobil	+49 173 6167044	491736167044	+49 173 6167044	—
Geb.datum	20.12.1961	—	20.12.1961	—

Problem: Keine zentrale Stelle für Adressänderungen. Wenn AK umzieht, muss die Adresse in mindestens 3 Systemen geändert werden (D365, FRB, BC). Brevo hat gar keine Adresse.

3.2 Marketing-Listen — doppelt gepflegt

Listen existieren sowohl in D365 CS (568 Listen) als auch in Brevo (165 Listen). Viele sind thematisch identisch:

Thema	D365 CS	Brevo
Judith ZS Dortmund	✓	✓ (ID 308)
BET Teilnehmer diverse Städte	✓	✓
7WK Teilnehmer diverse Städte	✓	✓
Chorleitende regional	✓	✓ (CL-Listen)
Ehrenamtliche	✓	✓ (ID 193)
Gemeinderundmail	✓	✓ (ID 198)
Spendenmailing	✓	✓ (ID 257/258)
EPA-Teilnehmer	✓	✓ (ID 243)
GKT/EGF	✓	✓
Marketingmaterial NICHT senden	✓ (WillKeineBriefe/NoPost)	✓ (ID 105)

Problem: Welches System ist führend? Wenn jemand sich abmeldet, muss das in beiden Systemen passieren. Risiko: inkonsistente Opt-Outs, DSGVO-Verstoß.

3.3 E-Mail-Templates — doppelt gepflegt

D365 CS: 557 Templates (Service-Center, Stornierungen, Proben, DSGVO)
Brevo: 30 transaktionale Templates (Double-Opt-In, Bestätigungen)

Teilweise überlappend bei Bestätigungsmails (Anmeldungen, Proben).

3.4 Sperrlisten / Opt-Outs — 4-fach

System	Mechanismus
D365 CS	Liste "WillKeineBriefe" / "NoPost" / "Marketingmaterial NICHT senden"
Brevo	emailBlacklisted, Liste "Marketingmaterial NICHT senden" (ID 105)
FRB	wants_no_email, wants_no_post, wants_no_call (pro Person)
BC	Keine explizite Marketingsperre

Problem: Kein zentraler Opt-Out. Wenn jemand per Mail widerspricht, wird das im D365-Case bearbeitet, aber FRB und Brevo müssen manuell aktualisiert werden.

4. Identifizierte Probleme

4.1 Kein Master Data Management

Es gibt kein führendes System für Kontaktstammdaten. Die Kontaktnummer (z.B. 106369) dient als informelle Verknüpfung über alle Systeme, aber: - Nicht alle Kontakte haben eine übergreifende Nummer - Brevo hat 111.508 Kontakte, D365 nur ≥5.000 — die Mehrheit ist nicht verknüpft - BC hat 144.820 Kontakte — davon sind jedoch 99% (143.412) ohne Business Relation (siehe 4.9)

4.9 BC-Kontakte: 144.820 Einträge — 99% sind CRM-Ballast

Detailanalyse (21.03.2026): Die 144.820 BC-Kontakte sind kein Zeichen einer großen Kundenbasis, sondern ein historisch gewachsener, nie bereinigter Adresspool.

Typ-Verteilung

Typ	Anzahl	Anteil
Person	127.926	88,3%
Company	16.894	11,7%

Business Relation — das Kernproblem

Relation	Anzahl	Anteil
Keine (undefiniert)	143.412	99,0%
Customer (Debitor)	613	0,4%
Vendor (Kreditor)	379	0,3%
None	348	0,2%
Multiple	68	0,05%

Nummernkreise zeigen 3 große Imports

Nummernkreis	Anzahl	Vermutete Herkunft
200000–299999	93.399 (64,5%)	Massen-Import (altes CRM/FRB/Newsletter?)
100000–199999	31.751	Älterer Bestand, viele "gelöscht"-Markierungen
700000–799999	18.690	Newsletter-/Veranstaltungsteilnehmer (98% mit E-Mail)
300000–399999	595	Kreditoren-Kontakte
800000–899999	382	Companies (Kreditoren/Lieferanten)

Datenqualität

Kriterium	Vorhanden	Fehlend
Name	144.441 (99,7%)	379 komplett leer (nur Leerzeichen)
E-Mail	110.290 (76%)	34.530
Adresse/Stadt	131.043 (90%)	13.777
"gelöscht" im Namen	2.913	—

Vergleich mit ERP-Kern

Entity	Anzahl	Bemerkung
BC-Kontakte	144.820	99% ohne ERP-Verknüpfung
Debitoren	5.410	Nur 613 davon mit Kontakt verknüpft
Kreditoren	3.340	Nur 379 davon mit Kontakt verknüpft
Verkaufsrechnungen	27.286	—
Sachposten	568.152	—

Fazit: Operativ relevant sind nur ~1.000–1.400 Kontakte (mit Business Relation). Die restlichen ~143.400 sind importierte Adressdaten ohne jede ERP-Verknüpfung. Dies relativiert die Empfehlung "BC als Stammdaten-Master": Der echte Stammdaten-Kern liegt bei unter 9.000 Datensätzen (5.410 Debitoren + 3.340 Kreditoren).

4.2 Vivenu-Import erzeugt fehlerhafte Kontakte

Dokumentiert am Beispiel Veronika Grewe-Knorr / Barbara Grewe: - Drittbuchungen legen Kontakte unter dem Namen des Buchenden statt des Teilnehmers an - Diese werden dann fälschlich als Duplikate erkannt und gemerged - D365-Merge ist irreversibel → Datenverlust

4.3 Massive Duplikate in allen Systemen

System	Beispiel
D365 CS	5 Kontakte für Andreas Knorr (3 aktiv, 2 gemerged)
Brevo	Doppelte Listen (z.B. PNL WDS Dortmund: ID 240 + 300)
Brevo	3 Attribute für Singstimme (SING_STIMME, CHORSTIMME, SINGSTIMME)
FRB	Sauberer (nur 1 AK-Kontakt), aber externe IDs nicht immer gesetzt
BC	144.820 Kontakte, viele leer — vermutlich Import-Artefakte

4.4 Telefonnummern-Format inkonsistent

System	Format für AKs Mobil
D365 CS	+49 173 6167044
Brevo	491736167044
FRB	+49 173 6167044 UND 01736167044
BC	— (nicht gespeichert)

4.5 E-Mail-Zuordnung unklar

Andreas Knorr hat verschiedene E-Mails in verschiedenen Systemen:

E-Mail	D365 CS	Brevo	FRB	BC
anknorr@me.com	✓ (Master)	✓	✓	✓
anknorr@gmail.com	✓ (Duplikat)	—	—	—
andreas.knorr@ev-pop.de	✓ (separater Kontakt)	—	—	—
andreas.knorr@creative-kirche.de	✓ (SystemUser)	—	—	—

4.6 Brevo-Sender Tippfehler

Sender ID 2: ev-pop-insitut.de statt ev-pop-institut.de (deaktiviert, aber unsauber).

4.7 BC: Negative Artikelbestände

Einige Artikel haben negativen Bestand (z.B. "7WK CHP" mit -90) — Buchungsfehler oder fehlende Wareneingänge.

4.8 FRB: Bankverbindungen im Klartext via API

Die FRB-API liefert vollständige IBANs, BICs und Kontoinhabernamen. Das ist ein Datenschutzrisiko, falls der API-Key kompromittiert wird.

5. Feature-Überschneidungen: Was macht D365 CS, was besser in BC oder Brevo laufen könnte?

5.1 Features in D365 CS, die besser in Brevo gehören

Feature	Aktuell in D365 CS	Besser in Brevo	Begründung
Marketing-Listen	568 Listen, manuell gepflegt	✓	Brevo hat Segmentierung, Automatisierung, DOI-Flows, Bounce-Management. Listen in D365 sind tote Daten ohne Versandfunktion.
E-Mail-Templates (Marketing)	557 Templates	✓	Brevo hat Drag&Drop-Editor, A/B-Tests, Personalisierung. D365-Templates sind nur für 1:1-Mails aus Cases.
Newsletter-Versand	Nicht in D365, aber Listen dort gepflegt	✓	Brevo ist das Versandsystem — Listen dort pflegen, wo sie genutzt werden.
Opt-Out-Management	WillKeineBriefe/NoPost-Listen	✓	Brevo hat automatisches Blacklisting, Abmeldelinks, DSGVO-Compliance built-in.

5.2 Features in D365 CS, die besser in BC gehören

Feature	Aktuell in D365 CS	Besser in BC	Begründung
Kontaktstammdaten (Adresse, Tel)	Auf D365-Kontakten	✓	BC ist das ERP — Debitoren/Kontakte sind dort buchhalterisch relevant. BC sollte Master für Stammdaten sein.
Sperrlisten (NoPost)	In D365 als Marketing-Listen	✓ (Marketingsperre am Debitor)	Zentraler Ort für Sperren, die auch den Postversand (FRB-Spendenbriefe) betreffen.

5.3 Features, die in D365 CS bleiben sollten

Feature	Begründung
Cases / Service-Center	Kernfunktion von D365 CS — E-Mail-basierte Fallbearbeitung
Queues / Warteschlangen	Zuweisung an Teams, Routing
*Chorverwaltung (cnsc_chor)**	Custom Entities, tief integriert
*Vivenu-Integration (cnscvv_)**	Ticketing-Anbindung, Kernprozess
1:1 E-Mail-Kommunikation	Individuelle Korrespondenz aus Cases
Service-Templates (Storno, DSGVO)	Case-bezogene Textbausteine

5.4 Features in FRB, die mit BC synchronisiert werden sollten

Feature	FRB	BC	Status
Spendeneingänge	15.190 Spenden	Debitoren-Buchungen	Teilweise (external_person_id = Debitorennummer)
SEPA-Mandate	In FRB gespeichert	Lastschrift-Verwaltung	Nicht synchronisiert
Zuwendungsbescheinigungen	FRB generiert	BC bucht	Manueller Abgleich
Projekte/Kostenstellen	60 Projekte in FRB	Dimensionen in BC	Mapping über Buchungsvermerk (Custom Field 14245)

6. Empfehlungen zur Harmonisierung

6.1 Master Data Management einführen

Empfehlung: BC als führendes System für Stammdaten (Name, Adresse, E-Mail, Telefon) definieren.

Begründung: - BC hat bereits 144.820 Kontakte (größte Datenbasis) - Debitorennummer (z.B. 106369) wird bereits systemübergreifend als ID verwendet - Buchhaltungsrelevante Daten (Adresse für Rechnungen, Spendenbescheinigungen) müssen in BC korrekt sein

Sync-Richtung:

BC (Master) → D365 CS (cnsc_kontaktnummer)
BC (Master) → Brevo (KONTAKTNUMMER_CRM)
BC (Master) → FRB (external_person_id)

6.2 Marketing-Listen konsolidieren

Empfehlung: Listen nur noch in Brevo pflegen. D365 CS behält nur Case-relevante Zuordnungen.

Umsetzung: 1. Alle aktiven D365-Marketing-Listen nach Brevo migrieren (einmalig) 2. Neue Listen nur noch in Brevo anlegen 3. D365-Listen auf Archiv-Status setzen 4. Segmentierung in Brevo über Attribute statt statische Listen

6.3 Zentrales Opt-Out

Empfehlung: Opt-Out zentral in Brevo verwalten (emailBlacklisted) und nach D365 CS und FRB synchronisieren.

Umsetzung: 1. Brevo-Webhook bei Abmeldung → D365 CS aktualisieren 2. FRB-Flag wants_no_email mit Brevo-Blacklist abgleichen (täglich/Batch) 3. D365-Case-Template "DSGVO Löschungsbegehren" triggert Brevo-Blacklist + FRB-Sperre

6.4 Vivenu-Import reparieren

Empfehlung: Vivenu-Import so anpassen, dass bei Drittbuchungen der Teilnehmername verwendet wird, nicht der Buchende.

Falls technisch nicht möglich: - Kontakte aus Vivenu-Import nicht automatisch in D365-Duplikatserkennung einbeziehen - Manuellen Review-Schritt vor Merge einführen - Geburtsdatum als Merge-Kriterium verwenden (unterschiedliche Geb.daten = kein Merge!)

6.5 Nummernformat vereinheitlichen

Empfehlung: Telefonnummern im E.164-Format speichern (+491736167044).

Umsetzung: - Brevo: Attribut SMS bereits in diesem Format (nur + fehlt) - FRB: Beim Import normalisieren - D365: Workflow/Plugin bei Kontaktänderung

6.6 BC aufräumen

Empfehlung: 1. Leere Kontakte (ohne Name, ohne E-Mail) identifizieren und deaktivieren 2. Automatisch aus E-Mail-Adressen generierte Einträge prüfen 3. Negative Artikelbestände korrigieren

6.7 FRB ↔ BC Spenden-Sync verbessern

Empfehlung: 1. FRB-Custom-Field Buchungsvermerk (14245) als BC-Buchungstext verwenden 2. FRB-Projekte auf BC-Dimensionen mappen 3. Täglicher Batch-Import FRB → BC (statt manuell)

6.8 Brevo aufräumen

Empfehlung: 1. Doppelte Listen zusammenführen (z.B. PNL WDS Dortmund: ID 240 + 300) 2. Drei Singstimme-Attribute auf eins reduzieren (CHORSTIMME behalten, Rest migrieren) 3. Deaktivierten Sender mit Tippfehler (ID 2) löschen

7. Zielarchitektur

┌─────────────────────────────────────────────────────────┐
│                    Business Central                      │
│              MASTER: Stammdaten (Kontakte,               │
│              Debitoren, Kreditoren, Artikel)              │
└───────┬──────────────────┬──────────────────┬────────────┘
        │ Sync             │ Sync             │ Sync
        ▼                  ▼                  ▼
┌───────────────┐  ┌──────────────┐  ┌────────────────┐
│   D365 CS     │  │    Brevo     │  │ FundraisingBox │
│               │  │              │  │                │
│ • Cases       │  │ • Newsletter │  │ • Spenden      │
│ • Queues      │  │ • Kampagnen  │  │ • SEPA         │
│ • Vivenu-     │  │ • Opt-In/Out │  │ • Zuw.besch.   │
│   Tickets     │  │ • DOI-Flows  │  │ • Projekte     │
│ • Chor-       │  │ • Listen     │  │                │
│   verwaltung  │  │ • Bounce-    │  │                │
│ • 1:1 E-Mail  │  │   Mgmt      │  │                │
└───────┬───────┘  └──────────────┘  └────────────────┘
        │ Import
        ▼
┌───────────────┐
│    Vivenu     │
│ • Ticketing   │
│ • Events      │
│ • Checkout    │
└───────────────┘

Systemverantwortung klar trennen

Aufgabe	Führendes System
Stammdaten (Name, Adresse, Tel)	BC
Buchhaltung, Rechnungen	BC
Service-Center, Cases	D365 CS
Ticketing, Events	Vivenu → D365 CS
Chorverwaltung	D365 CS
Newsletter, Massen-E-Mail	Brevo
Marketing-Listen, Segmentierung	Brevo
Opt-In/Opt-Out	Brevo (→ Sync zu anderen)
Spendenverwaltung	FRB
SEPA-Lastschriften	FRB
Zuwendungsbescheinigungen	FRB (→ Buchung in BC)

8. Quick Wins (sofort umsetzbar)

#	Maßnahme	Aufwand	Wirkung
1	Brevo: Doppelte Listen zusammenführen	Gering	Saubere Datenbasis
2	Brevo: Singstimme-Attribute konsolidieren	Gering	Weniger Verwirrung
3	D365: Merge-Sperre bei unterschiedlichen Geburtsdaten	Mittel	Verhindert falsche Merges
4	Alle Systeme: Telefonnummern auf E.164 normalisieren	Mittel	Konsistenz
5	FRB → BC: Automatischer Spenden-Import (Script)	Mittel	Weniger manuelle Arbeit
6	D365 Marketing-Listen: Archivieren, nur noch Brevo nutzen	Hoch	Eliminiert doppelte Pflege
7	BC: Leere Kontakte bereinigen	Hoch	Datenqualität

Anhang: Datenquellen dieser Analyse

System	API	Auth
D365 CS	`creativekirche.crm4.dynamics.com/api/data/v9.2/`	Client Credentials OAuth2
Brevo	`api.brevo.com/v3/`	API-Key Header
FundraisingBox	`api.fundraisingbox.com/v1/`	HTTP Basic Auth
Business Central	`api.businesscentral.dynamics.com/v2.0/.../api/v2.0`	MSAL Device Flow