SAP Dynamics 365 Schnittstelle

Was eine SAP-Dynamics-365-Anbindung wirklich leistet

In SAP liegen Geld und Logistik: der Geschäftspartner-Stamm, der Materialstamm, die Konditionen, die Kreditlimits, die Kundenaufträge, die Lieferung und Faktura auslösen. In Dynamics 365 lebt der Vertrieb: Konten, Kontakte, Verkaufschancen, Angebote und die tägliche Pipeline im Dataverse. Ohne Verbindung beschreiben beide dieselben Kunden und Produkte in zwei verschiedenen Sprachen - und jemand tippt den Unterschied von Hand nach.

Eine SAP-Dynamics-365-Anbindung schließt diese Lücke in beide Richtungen. Stammdaten fließen aus SAP heraus, damit der Vertrieb immer gegen echte Kunden, echte Materialien und aktuelle Preise kalkuliert. Angebote und Aufträge fließen nach SAP zurück, damit das Front Office nicht zum parallelen Datenbestand wird, den die Buchhaltung später abgleichen muss. SAP bleibt führendes System, Dynamics bleibt das System für die Kundenbeziehung, und die Pipeline hält beide ehrlich.

Welche Daten fließen

SAP-Objekt / Ereignis	Wird in Dynamics 365 zu	Hinweis
Geschäftspartner / Kundenstamm (DEBMAS, API_BUSINESS_PARTNER)	Konto + Kontakte	SAP-Nummer in einen alternativen Dataverse-Schlüssel geschrieben
Materialstamm (MATMAS, API_PRODUCT_SRV)	Produkt	Basismengeneinheit auf Dataverse-Einheitengruppe abgebildet
Konditionen / Preisliste	Preisliste + Preislistenpositionen	Je Währung und Vertriebsbereich; Konditionsarten zum Nettopreis aufgelöst
Kreditlimit / Sperrstatus	Feld / Statuskennzeichen am Konto	Vertrieb sieht einen gesperrten Kunden vor dem Angebot
In Dynamics erfasstes Angebot / Auftrag	Kundenauftrag (ORDERS, API_SALES_ORDER_SRV)	Auf korrekte Verkaufsorganisation, Vertriebsweg, Sparte gemappt
Faktura / Rechnung (VBRK)	Rechnung + Status	Zahlungs- und Ausgleichsstatus zur Einsicht zurückgegeben
Lieferung / Verfügbarkeitsprüfung	Auftragspositionsstatus	Bestätigte Menge und Termin an den Dynamics-Auftrag zurückgemeldet

Objektumfang, Richtung und Feldzuordnung stimmen wir einmalig ab und hinterlegen sie in der Pipeline. Danach ordnet niemand mehr eine Kundennummer von Hand einer GUID zu.

Die Details, an denen einfache Syncs scheitern

Ein Punkt-zu-Punkt-Skript oder eine generische Konnektor-Vorlage deckt den Gutfall ab und lässt die teuren Ränder offen:

• Identität und das Geschäftspartner-Modell. S/4HANA hat Kunde und Lieferant im Geschäftspartner vereint, das klassische ECC nicht. Eine SAP-Kundennummer per Namen einem Dynamics-Konto zuzuordnen, ist der sichere Weg zu Duplikaten. Der Geschäftsschlüssel muss der Anker sein, gespeichert als alternativer Dataverse-Schlüssel, mit einer klaren Regel für Datensätze, die auf einer der beiden Seiten entstehen.
• Die SAP-Organisationsstruktur hat kein Dynamics-Pendant. Verkaufsorganisation, Vertriebsweg, Sparte und Buchungskreis entscheiden, wie ein Auftrag in SAP verarbeitet wird. Dynamics kennt keines davon. Ein im CRM erfasster Auftrag ohne die richtige Organisationszuordnung wird direkt abgewiesen.
• Währungen und Mengeneinheiten. SAP speichert Beträge zu einer Währung mit eigener Dezimalbehandlung und Mengeneinheiten als interne Codes, die nicht den ISO-Codes entsprechen, die Dataverse erwartet. Preise gelten je Vertriebsbereich und Währung. Eine falsche Einheit oder ein falscher Dezimalversatz, und Mengen und Summen stimmen unbemerkt nicht.
• Delta statt Vollabzug. Den kompletten Materialstamm jede Nacht neu zu schieben, ist langsam und riskant. SAP-Änderungszeiger oder OData-Delta-Tokens sagen, was sich geändert hat; die Änderungsverfolgung von Dynamics tut dasselbe auf dem Rückweg. Ohne Delta bewegt man entweder alles oder verpasst Aktualisierungen.
• Dataverse-Service-Protection-Limits. Dynamics 365 drosselt nach Anzahl der Anfragen und Ausführungszeit je Benutzer. Eine naive Schleife mit einem Aufruf pro Datensatz läuft ins Limit und bleibt mitten im Import stehen. Schreibvorgänge müssen über die Web-API gebündelt und korrekt gedrosselt werden.
• Teilfehler und Reihenfolge. Ein Auftrag verweist auf einen Kunden und Materialien, die in Dynamics bereits existieren müssen. Ein fehlerhafter Datensatz im Batch darf den Rest nicht scheitern lassen, und ein erneuter Versuch darf die bereits erfolgreichen nicht doppelt buchen.

Wie wir sie bauen und betreiben

Wir behandeln das als Pipeline, nicht als Migration. SAP-Objekte werden als Delta abgeholt oder empfangen - OData mit Delta-Tokens, IDoc-Verteilung oder BAPI-Aufrufe je nach Objekt und Landschaft -, gegen ein Schema validiert, in das abgestimmte Dataverse-Modell überführt und über die Dynamics-365-Web-API in passend dimensionierten Batches geschrieben. Aufträge und Angebote laufen in die Gegenrichtung nach SAP, unter der richtigen Organisationszuordnung.

Die Pipeline ist idempotent: Jeder Datensatz trägt einen stabilen Geschäftsschlüssel, sodass ein erneuter Lauf, ein Replay oder zwei überlappende Läufe nie ein Duplikat erzeugen oder einen neueren Wert mit einem veralteten überschreiben. Sie läuft auf cloud-nativer, vollständig EU-gehosteter Infrastruktur, sodass Geschäftspartner- und Auftragsdaten die EU nicht verlassen - das hält AVV und DSGVO sauber.

Und dann halten wir sie am Laufen. Monitoring, Alerting, Incident Response und - entscheidend - das Beobachten von SAP-API-Freigaben und Microsofts Änderungen an den Dataverse-Limits liegen vertraglich bei uns. Sie bekommen einen festen Ansprechpartner und ein SLA, kein Skript, das jemand babysitten muss.

Wann sich diese Anbindung lohnt

Wenn nur eine Handvoll Konten zwischen den Systemen wandert und jemand den einen oder anderen Auftrag nachtippt, ist ein manueller Ablauf völlig in Ordnung - und wir sagen Ihnen das auch. Die Anbindung lohnt sich, wenn das Stammdatenvolumen das Nachtippen fehleranfällig macht, wenn der Vertrieb vor dem Angebot aktuelle Preise und Kreditstatus braucht, wenn in Dynamics erfasste Aufträge unter strengen Organisationsregeln in SAP landen müssen, oder wenn die Buchhaltung jeden Abschluss damit verbringt, zwei Datenbestände abzugleichen, die von Anfang an einer hätten sein sollen.