Zum Inhalt

FundraisingBox-Integration: Technische Analyse und Automatisierungsoptionen

Erstellt: 2026-03-05 Systeme: FundraisingBox (FRB), Business Central (BC), Dynamics 365 Customer Service (CRM) Mandant: Stiftung Creative Kirche

Inhaltsverzeichnis

  1. Systemlandschaft und Datenfluss
  2. Analyse: Business Central und FundraisingBox
  3. Analyse: CRM und FundraisingBox
  4. Vorschläge zur Automatisierung BC - FundraisingBox
  5. Optionen zur Synchronisierung FundraisingBox - CRM

1. Systemlandschaft und Datenfluss

1.1 Beteiligte Systeme

System Rolle Zugang
FundraisingBox (FRB) Führendes System für Spendenverwaltung secure.fundraisingbox.com
Business Central (BC) Finanzbuchhaltung, Hauptbuch api.businesscentral.dynamics.com
Dynamics 365 CRM Zentrale Kontaktverwaltung creativekirche.crm4.dynamics.com

1.2 Aktueller Datenfluss (Ist-Zustand)

FundraisingBox (FRB)                    Business Central (BC)
+------------------------+              +------------------------+
| Einzelspenden          |    manuell   | Konsolidierte          |
| 15.148 Spenden         | -----------> | Sammelbuchungen        |
| 2.853 Spender          |   monatlich  | ~20-50 Buchungen/Monat |
| 16 Projekte            |              | auf Spendenkonten      |
| Spendenbescheinigungen |              | (58 Konten)            |
+------------------------+              +------------------------+
         |                                        |
         |                                        | cnsc_bcsckid
         |  kein direkter Link                    | (Cenesco-Feld)
         |                                        v
         |                              +------------------------+
         +------ kein Datenfluss -----> | Dynamics 365 CRM       |
                                        | 178.328 Kontakte       |
                                        | 664 mit BC-ID          |
                                        | 587 BC-Sync aktiv      |
                                        +------------------------+

Kernbefund: Alle Datenflüsse sind unidirektional und die FRB-BC-Verbindung ist vollständig manuell. Zwischen FRB und CRM existiert kein Datenfluss.

1.3 Datenhoheit

Datenkategorie Führendes System
Einzelspenden, Spenderprojekte FundraisingBox
Spendenbescheinigungen FundraisingBox
Dankesschreiben, Aktionen FundraisingBox
Konsolidierte Finanzbuchungen Business Central
Kontaktdaten (Adresse, E-Mail, Telefon) Dynamics 365 CRM
Debitorenstammdaten Business Central

2. Analyse: Business Central und FundraisingBox

2.1 BC-Instanz: Überblick

Kennzahl Stiftung CK CK Medien GmbH Popakademie
Sachkonten 577 624 354
Debitoren 5.386 109.397 179
Kreditoren 3.334 964 500
Buchungsblätter 17 16 9
Dimensionen 5 6 3
  • Tenant: 6745ed26-c599-4098-a610-c8825a6e077f
  • Environment: Production (3 Companies)
  • API: v2.0 (OData REST)
  • Extensions: Keine benutzerdefinierten Extensions installiert
  • Job Queue: Keine automatisierten Jobs konfiguriert
  • BC-CRM-Kopplung: Über Cenesco-Felder (cnsc_bcsckid) im CRM

2.2 Spendenrelevante Konten in BC (Stiftung CK)

Die Stiftung verwendet 58 spendenrelevante Sachkonten, davon die wichtigsten:

Konto Bezeichnung Verwendung
3220 Spenden Ideell Hauptkonto IDE-Spenden
322001 IDE Erste Spende Erstspender ideell
322003 IDE Weitere Spende Folgespenden ideell
322007 IDE Einzug Spende Lastschriftspenden
322009 IDE Dauerauftrag Spende Daueraufträge
3224 Spenden Zweckbetrieb Zweckgebundene Spenden
3226 MIG Spenden Spenden Missionarisch
3251 Gezahlte Spenden/Zuwendungen Weitergabe
3253 Gezahlte Spenden Projekte Projektspenden-Weitergabe
0658 Paypal Spenden Paypal-Durchlaufkonto

2.3 Dimensionen (Kostenrechnung)

Dimension Werte Relevanz für Spenden
KOSTENSTELLE 155 Organisationseinheit (z.B. Gemeinde, Verwaltung)
KOSTENTRÄGER 562 Veranstaltung/Projekt (z.B. GKT, MLK, WZG)
KT3D 45 Projekttyp (Chorprojekt, Workshop, Live-Show)
KT4D 67 Projektmanagement-Zuordnung
SPHÄRE 5 Steuerliche Sphäre (Ideell, Zweckbetrieb, wirtsch. GB)

Die Dimension SPHÄRE ist für die korrekte steuerliche Zuordnung von Spenden entscheidend und muss bei jeder Buchung mitgegeben werden.

2.4 Buchungsblätter (Journals)

Spendenrelevante Buchungsblätter:

Code Bezeichnung Funktion
SPENDE Spende Hauptjournal für Spendenbuchungen
PORT Portal Lastschrift FRB-Lastschrifteinzüge
PP Paypal Zahlung PayPal-Spendeneingänge
STANDARD Standard ohne Nr. Diverse Buchungen

2.5 Buchungsmuster: Wie FRB-Daten heute in BC ankommen

Die Analyse der 1.164 Spendenbuchungen zeigt folgende Konsolidierungsmuster:

Belegnummern-Systematik

Prefix Anzahl Beispiel Bedeutung
S 516 S251169 "Fundbox 01/26" FRB-Monatssumme (häufigster Typ)
ES 158 ES231414VS Einzelspende mit Vermerk
UB 109 UB240307 Umbuchung/Saldierung
PP 59 PP250095 "Spende Heiko Patzner" PayPal-Einzelbuchung
VCM 59 VCM240307 Verrechnungskonto CKM
J 42 J24099 "GKT Spenden" Jahresabschluss-Buchung
KS 41 KS0161+ "GKT Spenden + Kollekten" Kassenbuchung
PAYPAL 20 PAYPAL 01/26 "Paypal 01/26" PayPal-Monatskonsolidierung
STRIPE 8 STRIPE 12/25 "FundBox Zahlungen 12/25" Stripe/FRB-Monatskonsolidierung
082-085 36 082-021 "Konsolidierung 30.04.25" Konsolidierungsbuchungen

Monatliche Buchungsfrequenz

Monat Buchungen Bemerkung
2025-04 30
2025-05 50 Höhere Aktivität
2025-06 25
2025-07 19
2025-12 46 Jahresende-Buchungen
2026-01 17
2026-02 11

Ergebnis: Die FRB-Daten werden monatlich konsolidiert als Sammelbuchungen in BC erfasst. Die typische Belegnummer S251169 mit Beschreibung "Fundbox 01/26" zeigt eine manuelle monatliche Zusammenfassung aller FRB-Spenden. PayPal- und Stripe-Zahlungen werden teils separat konsolidiert (PAYPAL 11/25, STRIPE 12/25).

2.6 Manueller Prozess (rekonstruiert)

1. Monatlich: FRB-Spenden des Vormonats sichten
2. Summen pro Zahlungsweg bilden (Lastschrift, PayPal, Stripe, Bank)
3. Summen pro Sphäre/Kostenstelle aufschlüsseln
4. Im BC-Buchungsblatt "SPENDE" erfassen:
   - Belegnummer: S + fortlaufend (z.B. S251169)
   - Beschreibung: "Fundbox MM/YY" oder "Paypal MM/YY"
   - Kontierung auf Spendenkonten (3220, 322001, etc.)
   - Dimensionen: KOSTENSTELLE, KOSTENTRÄGER, SPHÄRE
5. Buchungsblatt prüfen und buchen

2.7 FRB-Datenbestand

Kennzahl Wert
Spenden gesamt 15.148
Eindeutige Spender 2.853
Gesamtvolumen 795.173 EUR
Zeitraum 2021 - 2026

Verteilung nach Projekt (Top 10, nur 2025)

Projekt Spenden Anteil
Creative Kirche allgemein 762 17,6%
Gemeinde Creative Kirche 696 16,1%
Freundeskreis 678 15,7%
Wohnzimmergottesdienst 568 13,1%
Worship Cafe 518 12,0%
Kinderfonds 399 9,2%
Kauf Pop-Akademie 295 6,8%
Brot für die Welt: Kenia 112 2,6%
SoulTeens 51 1,2%
Brot für die Welt: YMCA 47 1,1%

Verteilung nach Zahlungsweise (nur 2025)

Zahlungsweise Spenden Anteil
(keine Angabe / Bank) 2.396 55,5%
Wikando Lastschrift 1.172 27,1%
PayPal 471 10,9%
KD-Bank Portal 201 4,7%
Stripe (Apple/Google Pay, Kreditkarte) 64 1,5%
via Medien GmbH 16 0,4%

Jährliche Entwicklung

Jahr Spenden
2021 701
2022 3.038
2023 2.998
2024 3.322
2025 4.320
2026 (bis März) 769

3. Analyse: CRM und FundraisingBox

3.1 CRM-Datenbestand

Kennzahl Wert
CRM-Kontakte gesamt 178.328
Kontakte mit E-Mail 147.113 (82,5%)
Kontakte mit BC-ID (cnsc_bcsckid) 664 (0,4%)
Kontakte mit BC-Sync aktiv (cnsc_bcsynchronisation) 587 (0,3%)

3.2 BC-CRM-Kopplung (Cenesco)

Die BC-CRM-Integration läuft über Cenesco-Felder im CRM-Kontakt:

CRM-Feld Funktion Befüllt
cnsc_bcsckid BC-Debitor-ID (Stiftung CK) 664 Kontakte
cnsc_bcckmid BC-Debitor-ID (CK Medien) vereinzelt
cnsc_bcpopid BC-Debitor-ID (Popakademie) vereinzelt
cnsc_bcsynchronisation BC-Sync aktiv (true/false) 587 Kontakte
cnsc_kontaktnummer Interne CRM-Kontaktnummer fast alle
cnsc_ctskundennummer CTS-Kundennummer vereinzelt

Befund: Nur 664 von 178.328 CRM-Kontakten (0,4%) haben eine BC-Debitor-ID. Das bedeutet, die allermeisten CRM-Kontakte sind nicht mit BC-Debitoren verkoppelt.

3.3 FRB-CRM Abgleich: Ergebnisse

Der Abgleich der 2.853 FRB-Spendernamen gegen die 178.328 CRM-Kontakte ergibt:

Kategorie Anzahl Volumen Anteil
In CRM gefunden 2.498 (87,6%) 671.636 EUR 84,5%
Nicht in CRM 355 (12,4%) 123.537 EUR 15,5%

Detailanalyse der CRM-Matches

Unterkategorie Anzahl Bedeutung
Im CRM, mit BC-ID 244 Spender ist CRM-Kontakt UND BC-Debitor
Im CRM, mit BC-Sync aktiv 100 Aktive Synchronisation CRM-BC
Im CRM, ohne BC-ID 2.254 Spender ist CRM-Kontakt, aber KEIN BC-Debitor

Lücken im aktuellen Zustand

  1. 87,6% der FRB-Spender existieren im CRM — aber das CRM weiss nichts von deren Spenden
  2. Nur 244 von 2.498 gematchten Spendern haben eine BC-Debitor-ID
  3. Die größten Spender (bis 21.590 EUR Gesamtvolumen) haben teilweise keine BC-Verknüpfung
  4. 355 FRB-Spender (12,4%) sind gar nicht im CRM erfasst — darunter Firmenspender und Sammelposten
  5. Im CRM gibt es keine Spendeninformationen — ein Servicemitarbeiter kann keine Spendenfragen beantworten

3.4 Aktuelle Situation: Was fehlt im CRM

Ein Servicemitarbeiter, der einen Anruf eines Spenders entgegennimmt, sieht im CRM: - Name, Adresse, E-Mail, Telefon - Ggf. BC-Debitor-ID - Ggf. Vivenu-Kontakt-Link

Nicht sichtbar: - Ob und wann Spenden eingegangen sind - Welche Projekte unterstützt werden - Ob eine Spendenbescheinigung ausgestellt wurde - Höhe und Häufigkeit der Spenden - Zahlungsweise (Lastschrift, PayPal, Überweisung)

4. Vorschläge zur Automatisierung BC - FundraisingBox

4.1 Zielszenario

Die FundraisingBox bleibt führendes System für: - Einzelspenden und Spenderhistorie - Spendenprojekte und Aktionen - Spendenbescheinigungen und Dankesschreiben - Zahlungsabwicklung (Lastschrift, PayPal, Stripe)

Business Central erhält konsolidierte Monatsbuchungen — wie bisher, aber automatisiert.

4.2 FRB-API: Technische Voraussetzungen

Die FundraisingBox bietet eine REST-API (API Package ist aktiviert): - Basis-URL: https://api.fundraisingbox.com/ - Authentifizierung: API-Key (muss bei FRB angefragt/freigeschaltet werden) - Dokumentation: https://fundraisingbox.com/api-docs/

Aktueller Stand: Das API-Package ist in der FRB-Instanz aktiv, aber der API-Key ist nicht im Web-UI sichtbar. Dieser muss beim FRB-Support angefragt werden.

Alternativ (aktuell genutzter Workaround): Web-Scraping der FRB-Oberfläche über Session-Cookie-Authentifizierung. Dies ist nicht für eine Produktivautomatisierung geeignet.

4.3 Option A: Automatisierte konsolidierte Buchungen (empfohlen)

Ansatz: Monatlicher automatisierter Prozess, der FRB-Spenden ausliest, konsolidiert und als BC-Buchungsblattzeilen erfasst.

FRB-API                    Middleware                    BC-API
+-----------+              +------------------+          +-----------+
| GET       |   JSON       | Konsolidierung:  |  POST    | journals/ |
| /donations| -----------> | - Summe/Projekt  | -------> | journal   |
| ?month=   |              | - Summe/Zahlweg  |          | Lines     |
|  2026-01  |              | - Sphäre-Zuordn |          |           |
+-----------+              | - Dimensionen    |          +-----------+
                           +------------------+

Konsolidierungslogik

Zusammenfassung pro Monat nach:

Gruppierung BC-Feld Beispiel
FRB-Projekt Sachkonto + KOSTENTRÄGER Freundeskreis -> Kto 3220, KT "FK"
Zahlungsweg Belegnummer-Prefix Lastschrift -> S..., PayPal -> PP...
Steuerliche Sphäre Dimension SPHÄRE Ideell -> 1, Zweckbetrieb -> 3

Mapping-Tabelle: FRB-Projekt -> BC-Kontierung

Diese Tabelle muss einmalig definiert und gepflegt werden:

FRB-Projekt BC-Sachkonto BC-Kostenstelle BC-Kostenträger Sphäre
Freundeskreis 3220 (zu definieren) FK 1 (Ideell)
Creative Kirche allgemein 3220 (zu definieren) CK-ALLG 1 (Ideell)
Wohnzimmergottesdienst 3224 (zu definieren) WZG 3 (Zweckbetrieb)
Kinderfonds 3220 (zu definieren) KF 1 (Ideell)
Gemeinde Creative Kirche 1802 90 (zu definieren) GEM 1 (Ideell)
Worship Cafe 3224 (zu definieren) WC 3 (Zweckbetrieb)
... ... ... ... ...

Implementierung

Technologie: Python-Script auf raspip5, ausführbar als systemd-Timer oder manuell.

BC-API-Endpunkte:

POST /companies({id})/journals({spende-id})/journalLines
{
  "accountNumber": "3220",
  "postingDate": "2026-01-31",
  "documentNumber": "FRB-2601",
  "amount": 12345.67,
  "description": "FundBox Spenden 01/26 - Freundeskreis",
  "dimensions": [
    {"code": "KOSTENSTELLE", "valueCode": "..."},
    {"code": "KOSTENTRÄGER", "valueCode": "FK"},
    {"code": "SPHÄRE", "valueCode": "1"}
  ]
}

Ablauf: 1. FRB-API: Spenden des Vormonats abrufen (GET /donations?from=2026-01-01&to=2026-01-31) 2. Gruppierung nach Projekt + Zahlungsweg + Sphäre 3. Mapping auf BC-Konten und Dimensionen gemäß Mapping-Tabelle 4. BC-API: Buchungsblattzeilen im Journal "SPENDE" anlegen 5. Optional: Automatisches Buchen oder manuelle Freigabe im BC

Vorteile: - Kein manueller Aufwand mehr für monatliche Konsolidierung - Konsistente Kontierung durch feste Mapping-Tabelle - Prüfschritt vor dem Buchen möglich (Buchungsblatt prüfen) - FRB bleibt führendes System — BC erhält nur Zusammenfassungen

Aufwand: Mittel (2-3 Tage Entwicklung + Mapping-Tabelle definieren)

4.4 Option B: Einzelspenden in BC buchen

Ansatz: Jede FRB-Spende wird einzeln als BC-Buchung erfasst.

Vorteile: - Volle Transparenz aller Einzelspenden in BC - Abstimmbarkeit auf Einzelbelegebene

Nachteile: - ~4.000 zusätzliche BC-Buchungen pro Jahr - Erhöhte BC-Lizenzkosten möglich (bei volumenabhängiger Lizenzierung) - Doppelte Datenhaltung (FRB + BC kennen beide alle Einzelspenden) - Keine echte Notwendigkeit, wenn FRB als führendes System fungiert - Widerspricht dem bisherigen Konsolidierungsprinzip

Empfehlung: Nicht empfohlen. Die FRB ist das Detailsystem für Spenden. Eine Duplizierung aller Einzelspenden in BC schafft keinen Mehrwert, sondern nur Redundanz und Komplexität.

4.5 Option C: FRB-Export + manueller Import

Ansatz: Automatisierter CSV/Excel-Export aus FRB, manueller Import in BC.

Dies ist ein Mittelweg: Die Datenaufbereitung wird automatisiert, aber der Import bleibt manuell (für Kontrollzwecke).

Implementierung: 1. Monatlicher Export-Report aus FRB (konsolidiert, im BC-Import-Format) 2. Per E-Mail an Buchhaltung oder auf Netzlaufwerk 3. Manuelle Prüfung und Import in BC

Aufwand: Gering (1 Tag), aber kein vollständiger Automatisierungsgewinn.

4.6 Empfehlung

Option A (automatisierte konsolidierte Buchungen) wird empfohlen:

  1. FRB-API-Key beim FRB-Support anfordern
  2. Mapping-Tabelle FRB-Projekt -> BC-Kontierung definieren (mit Buchhaltung abstimmen)
  3. Automatisierungs-Script entwickeln und testen
  4. Erster Monat parallel laufen lassen (automatisch + manuell vergleichen)
  5. Nach Validierung: Umstellung auf automatisierten Prozess

5. Optionen zur Synchronisierung FundraisingBox - CRM

5.1 Ziel

Der CRM-Kontakt soll als 360-Grad-Sicht auf den Kunden/Spender dienen. Ohne FRB-Zugriff muss ein Servicemitarbeiter folgende Fragen beantworten können:

  • "Habe ich eine Spende erhalten?" -> Ja, am 15.01.2026, 50 EUR für Freundeskreis
  • "Wann kommt meine Spendenbescheinigung?" -> Wurde am 01.02.2026 verschickt
  • "Welches Projekt unterstütze ich?" -> Freundeskreis (Dauerspender seit 2022)
  • "Können Sie meine Bankverbindung ändern?" -> Weiterleitung an FRB-Team (Änderung nur in FRB)

5.2 Zu synchronisierende Daten

Datenfeld Richtung Frequenz Priorität
Spender-Status (aktiv/inaktiv) FRB -> CRM täglich hoch
Letzte Spende (Datum, Betrag, Projekt) FRB -> CRM täglich hoch
Gesamtvolumen Spenden FRB -> CRM täglich hoch
Anzahl Spenden (gesamt + lfd. Jahr) FRB -> CRM täglich mittel
Unterstützte Projekte FRB -> CRM täglich mittel
Spendenbescheinigung (Status, Datum) FRB -> CRM täglich hoch
Zahlungsweise FRB -> CRM täglich niedrig
Spendenhistorie (letzte 12 Monate) FRB -> CRM täglich mittel

Richtung: Ausschliesslich FRB -> CRM (unidirektional). Das CRM ändert keine FRB-Daten.

5.3 Option 1: Custom Entity im CRM (empfohlen)

Ansatz: Neue Custom Entity frb_spende (oder cnsc_spende) im CRM, die FRB-Spenden als verknüpfte Datensätze zum Kontakt speichert.

Schema:

Contact (1) ----< (n) frb_spende
                        - frb_spende_id (PK)
                        - frb_donation_id (FRB-ID, z.B. FB-28693)
                        - frb_datum
                        - frb_betrag
                        - frb_projekt
                        - frb_zahlungsweise
                        - frb_bescheinigung_status
                        - frb_bescheinigung_datum

Zusätzlich: Rollup-Felder am Kontakt:

Feld Typ Berechnung
frb_spender_status OptionSet aktiv/inaktiv
frb_letzte_spende_datum DateTime MAX(frb_datum)
frb_letzte_spende_betrag Currency letzter Betrag
frb_gesamtvolumen Currency SUM(frb_betrag)
frb_anzahl_spenden Integer COUNT(*)
frb_projekte Text Komma-separierte Liste

Vorteile: - Volle Spendenhistorie im CRM sichtbar - Servicemitarbeiter sehen alle relevanten Daten auf einen Blick - Rollup-Felder auf Kontakt-Ebene für schnelle Übersicht - Filterbar (z.B. "alle Spender mit Volumen > 1.000 EUR") - Nutzbar in CRM-Dashboards und Reports

Nachteile: - Custom Entity erfordert CRM-Customizing (Power Platform / Dynamics Admin) - ~15.000 Datensätze initial + ~4.000/Jahr fortlaufend - Matching FRB-Spender -> CRM-Kontakt muss definiert werden (Name? E-Mail?)

Aufwand: Mittel-hoch (3-5 Tage: Entity-Definition, Sync-Script, Matching-Logik)

5.4 Option 2: Zusammenfassungsfelder am Kontakt (einfacher)

Ansatz: Keine eigene Entity, sondern nur Zusammenfassungsfelder direkt am CRM-Kontakt.

Neue Felder am Kontakt:

Feld Typ Inhalt
frb_spender Boolean Ist FRB-Spender (ja/nein)
frb_letzte_spende Text "15.01.2026 - 50,00 EUR - Freundeskreis"
frb_gesamtvolumen Currency Summe aller Spenden
frb_anzahl_spenden Integer Gesamtanzahl
frb_projekte Text "Freundeskreis, Wohnzimmergottesdienst"
frb_bescheinigung Text "2025: verschickt am 01.02.2026"
frb_seit DateTime Erste Spende
frb_letzte_aktualisierung DateTime Letzter Sync

Vorteile: - Einfach zu implementieren (nur neue Felder, keine Entity) - Sofort auf dem Kontaktformular sichtbar - Geringer CRM-Customizing-Aufwand

Nachteile: - Keine Einzelspendenhistorie im CRM - Textfelder sind nicht filterbar/sortierbar - Bei vielen Projekten wird das Feld unübersichtlich

Aufwand: Gering (1-2 Tage)

5.5 Option 3: Hybridlösung (empfohlen)

Ansatz: Kombination aus Custom Entity (Option 1) für die letzten 12-24 Monate und Zusammenfassungsfeldern (Option 2) für die Schnellübersicht.

Der Servicemitarbeiter sieht: 1. Oben im Kontaktformular: Zusammenfassungsfelder (Spender? Letztes Spende? Gesamtvolumen?) 2. Tab "Spenden": Liste der letzten 12-24 Monate Einzelspenden als Sub-Grid

Empfohlen, weil: - Schnellübersicht + Detail-Drill-Down - Begrenzte Datenmenge im CRM (nur rollierendes Fenster) - Servicemitarbeiter bekommt 90% der Fragen ohne FRB-Zugriff beantwortet

5.6 Matching-Strategie: FRB-Spender -> CRM-Kontakt

Das Matching ist die größte Herausforderung. Aktueller Stand: - FRB hat: Name, E-Mail, Adresse (nicht über API geprüft) - CRM hat: Name, E-Mail, Kontaktnummer

Empfohlene Matching-Reihenfolge: 1. E-Mail-Adresse (eindeutigstes Merkmal) 2. Nachname + Vorname (bei Namensdubletten: zusätzlich PLZ/Ort) 3. Manuelles Matching für nicht-zuordenbare Fälle

Ergebnis des Testlaufs (nur Name-Matching): - 87,6% Match-Rate (2.498 von 2.853) - Mit E-Mail-Matching dürfte die Rate auf 90-95% steigen

5.7 Technische Implementierung

Datenfluss:

FRB-API              Sync-Service              CRM Dataverse API
+-----------+        +------------------+       +-----------------+
| GET       |  JSON  | 1. FRB-Spenden   | POST  | contacts/       |
| /donations| -----> |    laden         | ----> | (Update Felder) |
|           |        | 2. Matching      |       |                 |
|           |        |    FRB->CRM      | POST  | frb_spenden/    |
|           |        | 3. Sync          | ----> | (Custom Entity) |
+-----------+        +------------------+       +-----------------+

Frequenz: Täglich (z.B. 06:00 Uhr morgens)

APIs: - FRB: REST API mit API-Key (muss angefordert werden) - CRM: Dataverse Web API v9.2 mit MSAL OAuth2 Device Flow oder Client Credentials

Hosting: Python-Script auf raspip5, ausführbar als systemd-Timer.

5.8 Zusammenfassung: Priorisierte Schritte

Schritt Beschreibung Aufwand Abhängigkeit
1 FRB-API-Key beim Support anfordern 0 -
2 Mapping-Tabelle FRB-Projekt -> BC-Kontierung definieren 1 Tag Buchhaltung
3 BC-Automatisierung (Option A) implementieren 2-3 Tage Schritt 1+2
4 CRM Custom Entity frb_spende definieren 1 Tag CRM-Admin
5 CRM-Zusammenfassungsfelder am Kontakt anlegen 0,5 Tag CRM-Admin
6 FRB-CRM Sync-Service implementieren 3-4 Tage Schritt 1+4+5
7 Parallelbetrieb und Validierung 2 Wochen Schritt 3+6
8 Go-Live - Schritt 7

Gesamtaufwand Entwicklung: ca. 8-10 Tage Kritischer Pfad: FRB-API-Key (Schritt 1) blockiert alles Weitere

Anhang

A. Datenquellen dieser Analyse

Datei Inhalt
bc_output/Production_full_analysis.json BC-Gesamtanalyse
bc_output/Production_accounts.json 577 Sachkonten
bc_output/Production_dimensions.json 5 Dimensionen mit Werten
bc_output/Production_customers.json 5.386 Debitoren
bc_output/Production_journals.json 17 Buchungsblätter
bc_output/spenden_buchungen_Stiftung_Creative_Kirche.json 1.164 Spendenbuchungen
bc_output/frb_donations.csv 15.148 FRB-Einzelspenden
bc_output/frb_crm_abgleich.json FRB-CRM Matching-Ergebnis

B. API-Zugänge

System Endpunkt Auth
BC API api.businesscentral.dynamics.com/v2.0/{tenant}/Production/api/v2.0 MSAL Device Flow
CRM API creativekirche.crm4.dynamics.com/api/data/v9.2 MSAL Device Flow
FRB API api.fundraisingbox.com (zu aktivieren) API-Key

Azure App Registration: 18592d44-7e56-4c5d-af17-788e354d0424 ("Business Central Integration") - Berechtigungen: BC (Financials.ReadWrite.All), CRM (user_impersonation) - FRB: Keine Azure-Integration (eigenständige API)

C. Analyse-Scripts

Script Funktion
bc_explore.py BC-API Explorer (erste Verbindungstests)
bc_analyze.py BC-Instanz Vollanalyse
bc_spenden_analyse.py BC-Spendenbuchungen Tiefenanalyse
frb_crm_match.py FRB-Spender vs. CRM-Kontakte Abgleich