ERP-Integration für die Automatisierung der Sales-Order-Erfassung: SAP, Dynamics & mehr – turian

ERP-Integration für die Automatisierung
der Sales-Order-Erfassung: SAP, Dynamics & mehr

Wenn ein KI-gestützter Order-Intake-Agent einen eingehenden Kundenauftrag verarbeitet, ist die ERP-Integration der Punkt, an dem die eigentliche Arbeit stattfindet. Das Lesen des Dokuments ist nur Schritt eins. Was das System anschließend mit den Daten macht — welche Felder es schreibt, welche Datensätze es zur Validierung aus dem ERP liest und wie es Konflikte zwischen dem eingehenden Dokument und dem aktuellen Zustand im ERP behandelt — entscheidet darüber, ob Sie den Order-Intake-Prozess automatisiert haben oder nur das Dokumentenlesen.

Dieser Leitfaden zeigt, was ERP-Integration für Sales-Order-Automatisierung in der Praxis tatsächlich bedeutet — mit SAP und Microsoft Dynamics als zentrale Beispiele. Er richtet sich an IT-Leads und Operations-Verantwortliche, die die Datenebene verstehen müssen, bevor sie sich für eine Implementierung entscheiden.

Die Integrationsanforderung

Was die Integration leisten muss —
in beide Richtungen

Automatisierung im Order Intake braucht eine bidirektionale ERP-Verbindung. Viele Anbieter sprechen allgemein von „ERP-Konnektivität“, ohne Richtung oder Tiefe der Integration zu benennen. Genau diese Unterscheidung ist entscheidend.

↑

Richtung

Outbound — die Automatisierung schreibt ins ERP

Das System muss bestätigte Auftragsdaten ins ERP schreiben — also den Auftragskopf anlegen, Positionen befüllen und den nächsten Schritt im Fulfillment-Workflow auslösen.

Typische Schwachstelle

Wenn dieser Schreibschritt einen manuellen Import erfordert oder ein Mensch die Daten prüfen und bestätigen muss, bevor sie ins ERP gelangen, haben Sie die Auftragserfassung nicht automatisiert. Sie haben nur das Lesen des Dokuments automatisiert und einen strukturierten Übergabepunkt geschaffen, der weiterhin menschliches Handeln braucht.
↓

Richtung

Inbound — die Automatisierung liest aus dem ERP

Das System muss Daten aus dem ERP lesen, um den eingehenden Auftrag zu validieren. Dazu gehören Kundendaten, Produktstamm und Preisdatensätze — also etwa, ob die Produktreferenz des Kunden zu einer aktiven SKU gehört, welcher Preis vereinbart ist oder ob aktuell ein Kreditlimitproblem vorliegt.

Ohne diesen Inbound-Read gleicht die Automatisierung Auftragsdaten nur mit einer statischen Referenzdatei ab, die in dem Moment veraltet ist, in dem sich Ihr ERP ändert. Mit ihm läuft jede Validierung gegen den Live-Zustand Ihres ERP.

Die entscheidende Unterscheidung

Die meisten Anbieter sagen „ERP-Konnektivität“. Die eigentliche Frage lautet: in welche Richtung — und wie tief? Eine Write-only-Integration automatisiert die Übergabe. Eine bidirektionale Integration automatisiert den Workflow.

Die Datenebene

Was bei einem bestätigten Auftrag
ins ERP geschrieben wird

Für einen Standardauftrag, der durch einen Intake-Agenten Ende-zu-Ende verarbeitet wird, lassen sich die geschriebenen ERP-Daten in drei Ebenen gliedern — plus eine klare Grenze für alles, was nicht automatisch geschrieben wird.

01

Ebene

Auftragskopf

Kundennummer

Wird aus dem eingehenden Dokument aufgelöst — ein Lookup, kein bloßes Kopieren

Auftragsdatum und gewünschtes Lieferdatum

Bestellreferenz des Kunden

Lieferadresse

Wird gegen den Kundenstamm validiert und bei Abweichung markiert

Zahlungsbedingungen

Werden aus dem Kundenstamm gelesen

Auftragskanal oder Source-Tag für Reporting

02

Ebene

Positionen

Interne SKU

Wird aus der Produktreferenz des Kunden aufgelöst — hier steckt der Großteil der Matching-Logik

Bestellte Menge und Mengeneinheit

Vereinbarter Preis

Wird gegen aktuelle Preislisten oder kundenspezifische Preisdatensätze validiert

Gewünschtes Lieferdatum pro Position

Sofern auf Positionsebene angegeben

Alle positionsbezogenen Hinweise aus dem Kundendokument

03

Ebene

Status- und Workflow-Trigger

Auftragsstatus

Entwurf, bestätigt oder ausstehend wegen offener Ausnahme

Zuweisung an den verantwortlichen Inside-Sales-Mitarbeiter oder Team-Queue

Trigger für nachgelagerte Fulfillment-Schritte, wo relevant

—

Nicht automatisch geschrieben

Alles, was eine menschliche Entscheidung erfordert

Aufträge mit ungelösten Ausnahmen — etwa eine Position, die nicht gematcht werden konnte, eine Preisabweichung oberhalb des konfigurierten Schwellenwerts oder ein Kreditlimit-Flag — werden als Entwurfsdatensätze mit einem Status geschrieben, der verhindert, dass sie weiterlaufen, bevor die Ausnahme gelöst wurde. Keine bestätigten Daten gelangen ins ERP, bevor ein Mensch die Ausnahme geprüft und freigegeben hat.
ERP-Integration für Sales-Order-Automatisierung: SAP & Dynamics – turian

SAP-Integration

SAP-Integration:
Wie sie in der Praxis aussieht

SAP ist im europäischen Mid-Market für Manufacturing und Distribution das am häufigsten eingesetzte ERP. Der Integrationsansatz unterscheidet sich je nachdem, welche SAP-Variante verwendet wird.

SAP

SAP-Variante

SAP S/4HANA

OData REST APIs

S/4HANA stellt eine Reihe standardisierter OData-APIs bereit, die die meisten für den Order Intake relevanten Datenobjekte abdecken: Sales-Order-Erstellung (A_SalesOrder und A_SalesOrderItem), Customer-Master-Abfragen (A_BusinessPartner), Material-Master-Abfragen (A_Product) sowie Pricing-Condition-Abfragen (A_SlsPrcgCndnRecdValidity).

Ein gut gebauter Intake-Agent nutzt diese APIs direkt sowohl für Lese- als auch für Schreibzugriffe. Der Order-Creation-Call schreibt Header und Line Items in einer einzigen Transaktion. Wenn der Schreibvorgang fehlschlägt — etwa wegen eines fehlenden Pflichtfelds, eines Konflikts bei der Verfügbarkeit oder eines Credit Blocks — liefert die API einen strukturierten Fehler zurück. Der Agent kann diesen entweder automatisch behandeln (wenn der Fehlertyp entsprechend konfiguriert ist) oder in die Exception Queue routen und den Fehlerkontext direkt sichtbar machen.

Drei Punkte, die in der Integrationsspezifikation sauber geklärt sein müssen

  • Berechtigungsumfang Das Servicekonto für die Integration benötigt Lesezugriff auf Customer Master, Material Master und Pricing Conditions sowie Schreibzugriff für die Sales-Order-Erstellung. Das ist ein klar definierter, begrenzter Scope — kein breiter ERP-Zugriff. Er sollte präzise festgelegt und vor Start der Implementierung von der IT freigegeben werden.
  • Pricing Procedure SAP-Pricing-Procedures können komplex sein, mit mehreren Condition Types, kundenspezifischen Vereinbarungen und manuellen Preis-Overrides. Der Intake-Agent muss wissen, welche Pricing Condition zur Validierung gelesen werden soll und ab welchem Schwellenwert eine Preisabweichung als Ausnahme markiert statt akzeptiert wird. Das wird pro Implementierung konfiguriert.
  • Output Types Wenn die Auftragsbestätigung in SAP erzeugt wird: Löst das automatisch einen Output aus — etwa eine gedruckte Bestätigung, eine EDI-Nachricht oder eine E-Mail? Falls ja, muss dieser Output unterdrückt oder mit dem Outbound-Kommunikationsschritt des Agents abgestimmt werden, damit keine doppelten Bestätigungen beim Kunden ankommen.
SAP

SAP-Variante

SAP Business One

Service Layer API / DI API

SAP Business One verwendet eine andere Integrationsarchitektur — primär die Service Layer API (eine REST-Schnittstelle) und in manchen Setups die DI API (eine COM-basierte Schnittstelle, die On-Premise-Integrationsmiddleware voraussetzt).

Der Service Layer deckt die zentralen Objekte für den Order Intake ab: Sales Orders (Orders-Endpoint), Business Partners (BusinessPartners) und Items (Items). Für standardisierte Auftragserstellung und Master-Data-Reads ist das in der Regel ausreichend.

Die DI API ist älter und deutlich komplexer in der Nutzung, wird aber teils noch für spezielle Customizations oder für On-Premise-Business-One-Deployments benötigt, in denen der Service Layer nicht aktiviert ist. Deshalb sollte jede Business-One-Integration damit beginnen, sauber zu klären, welche API-Oberfläche in der konkreten Kundenumgebung überhaupt verfügbar und unterstützt ist.

Unterschied im Pricing-Modell

Business One hat ein weniger komplexes Pricing-Condition-Modell als S/4HANA. Kundenspezifische Preise werden eher über spezielle Preislisten und Zahlungskonditionen als über Condition Records abgebildet. Die Preisvalidierungslogik des Intake-Agents muss deshalb so konfiguriert sein, dass für jeden Kunden die richtige Preisliste gelesen wird.
SAP

SAP-Variante — Legacy

SAP ECC

RFC/BAPI · IDocs · Middleware

SAP ECC läuft noch immer bei einem erheblichen Teil der europäischen Mid-Market-Unternehmen, die bislang nicht auf S/4HANA migriert haben. ECC stellt von Haus aus keine modernen REST-APIs bereit. Die Integration erfolgt typischerweise über RFC/BAPI-Aufrufe (SAPs Remote-Function-Call-Layer), IDocs (SAPs Dokumentenaustauschformat, vor allem für EDI-ähnliche Batch-Prozesse) oder über eine Middleware-Schicht, die zwischen dem Integrationsagenten und SAPs internen Schnittstellen übersetzt.

BAPI_SALESORDER_CREATEFROMDAT2 ist die Standard-BAPI zur Sales-Order-Erstellung in ECC. Sie funktioniert, verlangt aber eine sehr sorgfältige Behandlung der Input-Struktur — das Field Mapping ist starr und die Fehlerbehandlung ist weniger sauber als bei den OData-APIs in S/4HANA.

Migrationsrisiko

Wenn der Kunde auf ECC läuft, sollten die Migrationspläne vor dem Design der Integration geklärt werden. Ein System, das für ECC-BAPI-Calls ausgelegt ist, muss für eine spätere S/4HANA-OData-Migration erneut angepasst werden.

Microsoft Dynamics 365

Microsoft Dynamics 365
Integration

Dynamics 365 — insbesondere Business Central und die CRM-orientierte Sales-Variante — ist bei europäischen Mid-Market-Distributoren weit verbreitet und stellt seine Daten über Microsofts OData-v4-API-Schicht bereit.

D365

Dynamics-365-Variante

Business Central

OData v4 APIs

Für Business Central decken die relevanten APIs Sales Orders (salesOrders und salesOrderLines), Customers (customers) und Items (items) ab. Das Integrationsmodell ähnelt SAP S/4HANA: Kundendaten und Item Master werden zur Validierung gelesen, bestätigte Auftragsdaten werden als Sales-Order-Record geschrieben, und Fehler werden über die API-Response behandelt.

Im Vergleich zu SAP ECC

Business Central bietet eine sauberere und konsistentere API-Oberfläche als SAP ECC. Für Mid-Market-Unternehmen auf Business Central ist die Integrationsschicht deshalb meist schneller aufgebaut und stabiler im Betrieb.

Drei Dynamics-spezifische Punkte für die Spezifikation

  • Environments Dynamics 365 arbeitet mit Sandbox- und Produktionsumgebungen. Die Integration sollte zuerst in der Sandbox gebaut und getestet werden, bevor Produktionszugänge freigegeben werden. Das muss in die Implementierungszeit eingeplant werden.
  • API-Throttling Die Dynamics-APIs von Microsoft unterliegen Service-Protection-Limits, die Anfragen oberhalb definierter Schwellenwerte drosseln. Bei hohem Auftragsvolumen muss die Integration diese Limits berücksichtigen, etwa durch Request-Batching oder Rate-Limiting-Logik.
  • Custom Fields Viele Dynamics-Implementierungen enthalten kundenspezifische Felder auf Order Records. Die Integrationsspezifikation muss klar unterscheiden, welche Custom Fields für die Auftragserstellung zwingend erforderlich sind und welche erst nachgelagert von anderen Prozessen befüllt werden.
D365

Dynamics-365-Variante

Dynamics 365 Sales

OData v4 · CRM data model

Dynamics 365 Sales (die CRM-orientierte Variante) ist seltener das primäre Order-Management-System für B2B-Distributoren, kommt aber in einigen Unternehmen dennoch dafür zum Einsatz. In diesen Fällen werden Auftragsdatensätze als Opportunity- oder Order-Entities innerhalb des Dynamics-Datenmodells angelegt.

Die Integration muss dabei berücksichtigen, wie Contact-/Account-Records mit dem Auftrag verknüpft sind — das funktioniert anders als in einem ERP-nativen Modell. Durch die Datenobjekt-Hierarchie aus Account, Contact, Opportunity und Order muss die Integrationsschicht zuerst den richtigen Account auflösen, bevor der Order Record geschrieben werden kann.

CRM- vs. ERP-Datenmodell

Im Gegensatz zu Business Central wurde Dynamics 365 Sales nicht als Order-Management-System entwickelt. Wenn ein Unternehmen es dennoch dafür nutzt, sollte vor Beginn der Integrationsspezifikation geprüft werden, ob alle erforderlichen Order-Management-Felder und Workflows sauber konfiguriert sind.
ERP-Integration für Sales-Order-Automatisierung: Ausnahmen & Datenmapping – turian

Ausnahmelogik

Wie Ausnahmen mit dem ERP
interagieren

Exception Handling in der Order-Intake-Automatisierung hat eine ERP-Dimension, die im Integrationsdesign oft zu wenig präzise definiert wird. Wenn ein Auftrag auf eine Ausnahme trifft — etwa eine Position, die nicht gematcht werden kann, eine Preisabweichung oder einen Kreditblock — muss das System entscheiden, was ins ERP geschrieben wird und in welchem Status. Drei Ansätze sind üblich.

01

Ansatz

Nichts schreiben, in Queue halten

Der Auftrag bleibt in der Automatisierungsschicht liegen, bis die Ausnahme gelöst ist, und wird erst danach als bestätigter Auftrag ins ERP geschrieben. Aus ERP-Datensicht sauber, aber der Auftrag existiert bis zur Klärung nicht im ERP. Bei zeitkritischen Aufträgen entsteht dadurch Verzögerung.
Einfachster ERP-Footprint
02

Ansatz

Als Entwurf schreiben

Der Auftrag wird sofort als Entwurf oder gesperrter Datensatz ins ERP geschrieben, mit einem Status, der verhindert, dass er in die Erfüllung weiterläuft. Die Ausnahme wird dem Team zusammen mit einem Link zum ERP-Datensatz angezeigt. Nach der Klärung wird der Datensatz aktualisiert und freigegeben. Dafür muss das ERP einen Draft-/Blocked-State unterstützen, und der Fulfillment-Prozess muss diesen respektieren.
Häufigster Ansatz
03

Ansatz

Bestätigte Positionen schreiben, Ausnahmepositionen halten

Bei Aufträgen mit einer Mischung aus sauberen und problematischen Positionen werden die bestätigten Positionen sofort geschrieben, während die Ausnahmepositionen in der Queue bleiben. Operativ oft der nützlichste Ansatz, wenn Kunden eine Teilbestätigung erwarten, aber auch der komplexeste in der Integrationslogik.
Am komplexesten in der Umsetzung
Welcher Ansatz richtig ist, hängt vom Datenmodell des ERP und von den operativen Anforderungen ab. Er sollte vor dem Build in der Integrationsspezifikation definiert werden — nicht erst im Testing.

Das Data-Mapping-Gespräch

Vier Fragen, die den Großteil
des Mapping-Aufwands treiben

Jede Implementierung beinhaltet ein Data-Mapping, das fast immer länger dauert als erwartet, wenn es zu Beginn nicht sauber eingegrenzt wird. Diese vier Fragen treiben den Großteil der Arbeit — und die Antworten darauf liegen in Ihrer ERP-Konfiguration und in Ihren kommerziellen Vereinbarungen, nicht in der Intake-Software.

01

Wie löst das System eine eingehende Kundenreferenz auf ein konkretes ERP-Konto auf?

Firmenname, Kunden-PO-Nummer, USt-IdNr. — wie wird jede dieser Referenzen einem Account-Datensatz zugeordnet? Und was passiert, wenn die eingehende Referenz zu mehreren Kundendatensätzen passt oder zu keinem?

02

Wie mappt das System die Produktreferenz des Kunden auf Ihre interne SKU?

Interne Artikelnummer des Kunden, Beschreibung, Hersteller-Code — gibt es dafür bereits eine Cross-Reference-Tabelle im ERP, oder muss das Matching in der Intake-Schicht konfiguriert werden?

03

Welcher Preisdatenbestand gilt pro Kunden-Produkt-Kombination?

Standardpreisliste, kundenspezifische Vereinbarung, Vertragspreis oder eine Kombination daraus? Und ab welcher Toleranz wird eine Abweichung markiert statt akzeptiert?

04

Wo findet die Mengeneinheiten-Umrechnung statt, und welche Rundungslogik gilt?

Wenn Ihr Kunde in einer anderen Mengeneinheit bestellt als der Basis-Einheit Ihres ERP, muss die Umrechnung explizit definiert sein — einschließlich dessen, was an den Rändern passiert.

Wenn die Antworten auf diese vier Fragen vor Projektstart vorliegen, entscheidet das darüber, ob die Mapping-Phase zwei Wochen oder sechs dauert.

Im Stable State

Wie gute Integration
im laufenden Betrieb aussieht

Ein gut integrierter Order-Intake-Agent hat im Stable State keine sichtbare Naht zwischen Automatisierungsschicht und ERP. End-to-End verarbeitete Aufträge erscheinen im ERP als saubere Sales-Order-Datensätze, die sich von manuell erfassten Aufträgen nur durch das Source-Tag unterscheiden. Ausnahmen erscheinen als Entwurfs- oder gesperrte Datensätze mit angehängten Lösungshinweisen. Das Inside-Sales-Team arbeitet weiter im ERP wie bisher — es sieht nur weniger Datensätze, die Aufmerksamkeit erfordern.

Saubere Aufträge

Keine sichtbare Naht

End-to-End verarbeitete Aufträge erscheinen im ERP als saubere Sales-Order-Datensätze, die sich von manuell erfassten Aufträgen nur durch das Source-Tag unterscheiden.

Ausnahmen

Entwurfsdatensätze mit Handlungshinweisen

Ausnahmen erscheinen als Entwurfs- oder gesperrte Datensätze mit angehängten Lösungshinweisen — nicht als fehlende Datensätze oder ungeroutete Queue-Elemente.

Das Team

Gleiches ERP, weniger Vorgänge

Das Inside-Sales-Team arbeitet weiter im ERP wie bisher. Es sieht einfach weniger Vorgänge, die manuelle Aufmerksamkeit brauchen.

Die Integration wird außerdem gepflegt, nicht nur ausgerollt. Wenn sich der Produktstamm ändert, die Pricing-Logik angepasst wird oder ein neuer Kunde mit ungewöhnlichem Bestellverhalten hinzukommt, wird die Konfiguration des Intake-Agents entsprechend aktualisiert. Diese Wartungslast ist niedrig, wenn die Integration gut designt und dokumentiert ist — und hoch, wenn sie es nicht ist.

Wartungsverantwortung vor Go-live definieren

Wer aktualisiert die Konfiguration, wenn sich ERP-Daten ändern?

Produktstamm-Updates, neue Preisvereinbarungen, ausgelaufene SKUs — wer verantwortet auf Intake-Seite jede dieser Änderungen?

Wie werden Änderungen zwischen ERP-Verantwortlichen und Intake-Agent-Verantwortlichen kommuniziert?

Ein definierter Prozess für Change Notifications verhindert, dass Konfigurationsdrift still zwischen den Review-Zyklen anwächst.

Wie wird eine Konfigurationsänderung getestet, bevor sie live geht?

Auch kleine Konfigurationsänderungen sollten anhand einer Stichprobe aktueller Aufträge validiert werden, bevor sie in Produktion gehen.

Technisches Review anfordern

Mappen Sie Ihr ERP-Setup auf das
richtige Integrationsdesign

Wenn Sie eine ERP-Integration für die Order-Intake-Automatisierung planen und vor der Festlegung auf einen Ansatz ein technisches Review Ihres konkreten Setups möchten, arbeitet das turian-Implementierungsteam mit SAP- und Dynamics-Umgebungen und kann Ihre aktuelle ERP-Konfiguration in einem 30-minütigen Gespräch auf das passende Integrationsdesign mappen.

Technisches Integrations-Review buchen

Bleiben Sie auf dem Laufenden!

Erfahren Sie, was es Neues im Bereich KI für Prozessautomatisierung gibt.
Danke! Deine Einreichung ist eingegangen!
Hoppla! Beim Absenden des Formulars ist ein Fehler aufgetreten. Bitte versuchen Sie es erneut.
Lösungen
Operativer EinkaufEinhaltung der LieferkettenvorschriftenVertrieb & After SalesQualitätsmanagement(E-)Rechnungen
Plattform
Generative KIVerwaltung des PosteingangsKI-DokumentenanalyseDatenextraktion und -eingabeKI-KundenserviceDer Mensch auf dem LaufendenLow-Code-Plattform
Ressourcen
BlogErfolgsgeschichtenHäufig gestellte FragenÜber unsKarriereKontakt
Rechtliches
ImpressumAllgemeine GeschäftsbedingungenHinweise zum Datenschutz
© Uify Technologies GmbH. 2025 - All rights reserved.

Durch Anklicken „Akzeptieren“, stimmen Sie der Speicherung von Cookies auf Ihrem Gerät zu, um die Seitennavigation zu verbessern, die Nutzung der Website zu analysieren und unsere Marketingaktivitäten zu unterstützen. Sehen Sie sich unsere an Datenschutzrichtlinie für weitere Informationen.

PräferenzenAblehnenAkzeptieren
Danke! Deine Einreichung ist eingegangen!
Hoppla! Beim Absenden des Formulars ist etwas schief gelaufen.