ERP-Integration im B2B-Industrieshop: SAP, proALPHA, Infor und weitere deutsche Systeme anbinden

Die ERP-Integration ist selten der sichtbarste Teil eines B2B-Commerce-Projekts. Für den späteren Erfolg ist sie jedoch häufig wichtiger als das Design des Shops oder die Wahl einzelner Frontend-Funktionen.

Denn Geschäftskunden erwarten online dieselben Informationen und Konditionen, die auch im klassischen Vertrieb gelten:

ihre individuellen Preise,
aktuelle Bestände,
realistische Liefertermine,
vereinbarte Zahlungsbedingungen,
bekannte Artikelnummern,
offene Aufträge,
Rechnungen und Gutschriften.

Diese Informationen befinden sich in Industrieunternehmen meist im ERP-System. Der B2B-Shop kann deshalb nicht als isolierte Anwendung geplant werden. Er muss sich in die vorhandene Systemlandschaft einfügen und klar definierte Daten mit SAP, proALPHA, Infor, Sage, Microsoft Dynamics oder einer anderen Unternehmenssoftware austauschen.

Dieser Leitfaden zeigt, wie die ERP-Integration eines B2B-Shops in der Industrie strukturiert geplant wird, welche Schnittstellen die wichtigsten DACH-Systeme bereitstellen und wo in realen Projekten die größten Risiken liegen.

Einen übergeordneten Einstieg finden Sie unter Industrie E-Commerce – Plattformen und Strategie.

Warum die ERP-Integration der heimliche Erfolgsfaktor jedes Industrieshops ist

Ein B2B-Shop besteht technisch aus mehreren Schichten:

Commerce-Plattform,
ERP,
Produktinformationsmanagement,
CRM,
Dokumentenmanagement,
Suchtechnologie,
Integrationsschicht,
und gegebenenfalls Konfigurator oder Serviceplattform.

Die zentrale Frage lautet deshalb nicht nur:

Welche Daten müssen ausgetauscht werden?

Ebenso wichtig ist:

Welches System darf welche Daten erzeugen, verändern und überschreiben?

Stammdatenhoheit als Kernfrage

Vor der technischen Entwicklung muss für jedes Datenobjekt ein führendes System festgelegt werden.

Eine typische Verteilung kann so aussehen:

Datenobjekt	Mögliches führendes System
Kundenstammdaten	ERP oder CRM
Benutzer und Shoprollen	Commerce-Plattform
Artikelnummern und Basiseinheiten	ERP
Marketingtexte und Medien	PIM
Preise und Konditionen	ERP
Shopkategorien	PIM oder Commerce-Plattform
Lagerbestände	ERP oder Lagerverwaltung
Aufträge und Rechnungen	ERP
Warenkörbe und Merklisten	Commerce-Plattform
technische Dokumente	PIM oder DMS

Problematisch wird es, wenn dieselben Informationen in mehreren Systemen unabhängig gepflegt werden.

Beispiel: Der Shop führt eine Lieferadresse, das ERP eine andere und das CRM eine dritte. Ohne eindeutige Regeln ist unklar, welche Änderung gültig ist und wie Dubletten verhindert werden.

Für Produktinformationen übernimmt häufig ein PIM die Rolle zwischen ERP und Shop. Das ERP liefert kaufmännische Grunddaten, während das PIM Beschreibungen, Merkmale, Klassifikationen, Dokumente und Medien ergänzt.

Mehr dazu lesen Sie unter PIM als Bindeglied zwischen ERP und Shop.

Realtime oder Batch: eine grundlegende Architekturentscheidung

Nicht alle Daten müssen in Echtzeit übertragen werden.

Eine sinnvolle Integrationsarchitektur unterscheidet mindestens drei Kategorien:

Echtzeit oder nahezu in Echtzeit

kundenspezifische Preise,
verfügbare Mengen,
konkrete Liefertermine,
Kreditlimitprüfungen,
Auftragserstellung,
Angebotsvalidierung.

Ereignisbasiert oder in kurzen Intervallen

Auftragsstatus,
Versandinformationen,
Kundendatenänderungen,
neue Rechnungen,
Änderungen an Konditionen.

Periodisch als Batch

vollständige Produktstämme,
Klassifikationen,
historische Dokumente,
umfangreiche Preislisten,
Medien und technische Dateien.

Eine vollständige Echtzeitarchitektur klingt zunächst attraktiv, erhöht aber Abhängigkeiten. Ist das ERP vorübergehend nicht erreichbar, kann möglicherweise auch der Shop keine Preise oder Lieferzeiten anzeigen.

Deshalb werden häufig hybride Modelle eingesetzt:

Grunddaten werden regelmäßig synchronisiert.
Kritische Informationen werden bei Bedarf live geprüft.
Zwischenspeicher sichern den Betrieb bei kurzen Ausfällen.
Bestellungen werden über eine Warteschlange zuverlässig übertragen.

Die richtige Strategie hängt von Datenmenge, Änderungsfrequenz, Ausfalltoleranz und Geschäftsprozess ab.

SAP-Integration: Business One, S/4HANA und ECC

Unter dem Begriff „SAP-Integration“ verbergen sich sehr unterschiedliche Ausgangslagen. SAP Business One, S/4HANA und ältere ECC-Systeme stellen andere Schnittstellen, Datenmodelle und Betriebsbedingungen bereit.

SAP Business One Service Layer

SAP Business One wird häufig im kleineren und mittleren industriellen Mittelstand eingesetzt.

Der Service Layer stellt Geschäftsobjekte von SAP Business One über HTTP und OData bereit. Dazu können beispielsweise Geschäftspartner, Artikel, Bestellungen und andere kaufmännische Objekte gehören. SAP beschreibt den Service Layer als API-Schicht, die Geschäftsdaten und Services einheitlich über Webprotokolle zugänglich macht. (SAP Hilfeportal – Service Layer API Reference)

Typische Integrationsobjekte sind:

Geschäftspartner,
Ansprechpartner,
Artikel,
Preislisten,
Lagerbestände,
Kundenaufträge,
Lieferungen,
Rechnungen,
Gutschriften.

Für einen B2B-Shop reicht der technische Zugriff allein jedoch nicht aus. Die vorhandenen Erweiterungen und individuellen Felder des SAP-Business-One-Systems müssen ebenfalls betrachtet werden.

In vielen Unternehmen liegen wichtige Informationen in:

benutzerdefinierten Feldern,
Zusatzmodulen,
Partnerlösungen,
individuellen Tabellen,
oder eigens entwickelten Preis- und Freigabelogiken.

Die Integration muss deshalb immer gegen das tatsächlich eingesetzte System geprüft werden, nicht nur gegen den SAP-Standard.

SAP S/4HANA, OData und Integration Suite

S/4HANA stellt eine Vielzahl fachlicher APIs bereit. Je nach Edition und Szenario werden beispielsweise OData-basierte Schnittstellen, Events oder weitere SAP-Integrationsmechanismen eingesetzt. SAP dokumentiert unter anderem OData-V4-basierte Domain APIs für S/4HANA. (SAP Hilfeportal – Domain APIs)

Die SAP Integration Suite kann als zentrale Integrationsschicht zwischen Shop, S/4HANA und weiteren Systemen dienen. Über Cloud Integration lassen sich Integrationsflüsse, Transformationen, Monitoring und Schnittstellen zentral verwalten. SAP stellt hierfür ebenfalls OData- und REST-basierte Möglichkeiten bereit. (SAP Hilfeportal- OData API)

Typische Shopprozesse sind:

Abruf von Geschäftspartnern,
Ermittlung kundenbezogener Preise,
Prüfung von Verfügbarkeit,
Übertragung von Kundenaufträgen,
Bereitstellung von Auftragsstatus,
Übergabe von Rechnungs- und Lieferdokumenten.

Die eigentliche Herausforderung ist meist nicht der verfügbare API-Endpunkt, sondern die fachliche Ausgestaltung.

Beispielsweise kann eine Preisanfrage abhängen von:

Verkaufsorganisation,
Vertriebsweg,
Sparte,
Werk,
Lieferland,
Incoterm,
Mengeneinheit,
Kundengruppe,
Vertragsnummer,
Aktionszeitraum.

Der Shop muss den vollständigen Kontext übergeben, damit SAP denselben Preis berechnet wie im klassischen Vertriebsprozess.

IDocs und klassische ECC-Integration

Bei älteren SAP-ECC-Landschaften werden weiterhin häufig IDocs, RFC-Verbindungen, BAPIs, Dateien oder bestehende Middleware-Strecken verwendet.

Ein typisches Integrationsmodell lautet:

Artikel und Kunden werden regelmäßig exportiert.
Preis- und Bestandsdaten werden in definierten Intervallen aktualisiert.
Bestellungen werden als IDoc oder über einen bestehenden Integrationsprozess übertragen.
Auftragsstatus und Lieferinformationen werden zurückgespielt.

Dieses Modell ist nicht grundsätzlich veraltet. Eine stabile, überwachte Batch-Integration kann wirtschaftlich sinnvoller sein als eine umfassende Echtzeitmodernisierung.

Problematisch wird es, wenn die bestehenden Schnittstellen:

nicht dokumentiert sind,
von Einzelpersonen abhängen,
keine Fehlerwarteschlange besitzen,
keine Wiederholungslogik unterstützen,
oder Änderungen direkt in produktiven Dateien vorgenommen werden.

Auch BMEcat- und openTRANS-Prozesse können in die Integrationsarchitektur einbezogen werden. Mehr dazu finden Sie unter BMEcat und openTRANS in der ERP-Integration.

proALPHA: DACH-Klassiker im Maschinen- und Anlagenbau

proALPHA ist in vielen mittelständischen Produktions-, Maschinenbau- und Anlagenbauunternehmen vertreten.

Aktuelle proALPHA-Versionen stellen ein REST-API-Framework für die Integration externer Anwendungen bereit. Welche Objekte tatsächlich verfügbar sind, hängt jedoch von Version, Lizenzierung, Modulen und projektspezifischen Erweiterungen ab. (docs.proalpha.com)

REST-API und proALPHA-Datenmodell

Eine Shopintegration greift typischerweise auf folgende Datenbereiche zu:

Kunden,
Ansprechpartner,
Artikel,
Verkaufseinheiten,
kundenspezifische Artikelnummern,
Preise und Konditionen,
Lagerbestände,
Aufträge,
Lieferungen,
Rechnungen,
Dokumentreferenzen.

Gerade im Maschinenbau kommen häufig weitere Objekte hinzu:

Seriennummern,
Maschinenakten,
Stücklisten,
Ersatzteilzuordnungen,
Projektnummern,
kundenspezifische Konstruktionen.

Ein häufiger Fehler besteht darin, die Integration ausschließlich aus Sicht eines Standardproduktshops zu planen. Für ein Ersatzteilportal muss beispielsweise geklärt werden, wie eine installierte Maschine mit den dazugehörigen Baugruppen und gültigen Ersatzteilen verbunden wird.

Typische Datenobjekte und Aktualisierungsintervalle

Eine pragmatische Verteilung kann folgendermaßen aussehen:

Datenobjekt	Typische Übertragung
Artikelstamm	nächtlich oder ereignisbasiert
Produktänderungen	mehrmals täglich
Preislisten	nächtlich oder bei Änderung
kundenindividuelle Preise	live oder gecacht
Bestände	alle 5–30 Minuten oder live
Aufträge	unmittelbar
Auftragsstatus	ereignisbasiert oder regelmäßig
Rechnungen	täglich oder bei Verbuchung
technische Dokumente	bei Änderung

Diese Werte sind keine allgemeingültige Vorgabe. Ein Hersteller mit wenigen Bestellungen benötigt eine andere Architektur als ein Großhändler mit hunderttausenden Artikeln und hoher Transaktionszahl.

Infor LN, M3 und weitere Infor-Systeme

Infor wird insbesondere in Fertigung, Maschinenbau, Automotive, Distribution und international aufgestellten Industrieunternehmen eingesetzt.

Für moderne Integrationsszenarien spielt Infor ION eine zentrale Rolle. Der ION API Gateway stellt APIs kontrolliert bereit und unterstützt Authentifizierung, Zugriff und die Integration von Infor- sowie Drittsystemen. (Infor Dokumentation -Ifor ION API Administration Guide)

Für Infor M3 sind über den API Gateway unter anderem REST-basierte Zugriffe auf M3-APIs vorgesehen. (Infor Dokumentation – Creating the ION API suite)

Typische Besonderheiten in Infor-Projekten sind:

mehrere Mandanten oder Werke,
internationale Unternehmenseinheiten,
komplexe Artikel- und Lagerstrukturen,
unterschiedliche Einheiten,
verfügbare Mengen je Standort,
umfangreiche kundenspezifische Anpassungen.

Für die Shopintegration muss deshalb geklärt werden:

Aus welchem Werk wird geliefert?
Welche Verkaufsorganisation ist zuständig?
Welche Einheit ist im Shop sichtbar?
Welche Einheit wird im ERP gebucht?
Wie werden Teilbestände und erwartete Zugänge berücksichtigt?
Welche Preislogik gilt bei internationalen Kunden?

Bei älteren Infor-Installationen können neben modernen APIs weiterhin Dateien, Datenbankzugriffe oder individuell entwickelte Schnittstellen vorhanden sein. Eine Modernisierung sollte nicht automatisch alle bestehenden Wege ersetzen. Entscheidend ist, welche Schnittstellen stabil, dokumentiert und wartbar sind.

Sage 100 und Sage X3

Sage-Systeme sind in vielen mittelständischen Handels- und Industrieunternehmen vertreten. Dabei unterscheiden sich Sage 100 und Sage X3 deutlich hinsichtlich Zielgruppe, Architektur und Integrationsmöglichkeiten.

Sage 100

Bei Sage 100 hängt die technisch sinnvollste Anbindung stark von der eingesetzten Version, vorhandenen Zusatzmodulen und der individuellen Systemlandschaft ab.

In der Praxis finden sich unter anderem:

vorhandene Shopkonnektoren,
Partner-APIs,
Import- und Exportprozesse,
Dateischnittstellen,
individuelle Dienste,
oder direkte Erweiterungen innerhalb der Sage-Umgebung.

Vor Projektbeginn sollte deshalb geprüft werden:

Welche Sage-Version ist im Einsatz?
Welche Module und Branchenlösungen sind installiert?
Gibt es bereits eine Integrationsplattform?
Welche Daten dürfen über vorhandene Schnittstellen gelesen und geschrieben werden?
Welche individuellen Tabellen oder Felder sind geschäftskritisch?

Gerade bei gewachsenen Sage-100-Systemen ist eine technische Bestandsaufnahme oft wichtiger als die Auswahl eines vermeintlichen Standardkonnektors.

Sage X3

Sage X3 bietet mehrere Integrationswege. Die aktuelle Herstellerdokumentation nennt unter anderem GraphQL für transaktionale Echtzeitszenarien, Import- und Export-Templates für größere Batchmengen sowie SOAP-basierte Dienste für bestehende oder templateorientierte Integrationen. REST-basierte Dienste können ebenfalls über das X3-Entwicklungsmodell bereitgestellt werden. (developer.sage.com)

Für einen Shop können beispielsweise folgende Muster kombiniert werden:

Produkt- und Preisdaten als Batch,
Live-Abfragen für kundenspezifische Informationen,
unmittelbare Übertragung von Aufträgen,
periodische Bereitstellung von Rechnungen,
ereignisbasierte Aktualisierung von Statusinformationen.

Auch hier ist die Entscheidung zwischen Echtzeit und Batch anhand von Volumen, Latenzbedarf und Betriebsrisiko zu treffen.

Microsoft Dynamics 365 Business Central

Microsoft Dynamics 365 Business Central gewinnt im Mittelstand an Bedeutung, insbesondere bei Unternehmen, die bereits Microsoft 365, Power Platform oder Azure einsetzen.

Business Central verfügt über standardisierte APIs und OData-Webservices. Microsoft empfiehlt für Integrationen bevorzugt die API-Schicht, während eigene APIs über sogenannte API Pages und API Queries entwickelt werden können. (Microsoft Learn)

Typische Shopobjekte sind:

Kunden,
Artikel,
Varianten,
Einheiten,
Preis- und Rabattinformationen,
Verkaufsaufträge,
Lieferungen,
Rechnungen.

Für individuelle Anforderungen können Erweiterungen in AL entwickelt und als eigene APIs bereitgestellt werden.

Bei der Planung sollte berücksichtigt werden:

SaaS oder On-Premises,
eingesetzte Business-Central-Version,
vorhandene Extensions,
Authentifizierung über Microsoft Entra ID,
API-Limits und Abfrageverhalten,
Mandanten- und Gesellschaftsstruktur.

Microsoft dokumentiert außerdem OAuth für OData- und Webservice-Zugriffe sowie konkrete Empfehlungen zur Performance von API-Clients. (Microsoft Learn – Creating a console application that uses OAuth to Authenticate Business Central Web Services)

Stolperfallen aus realen Integrationsprojekten

Preislogik: der häufigste Showstopper

Die größte Schwierigkeit ist häufig nicht die Übertragung eines Auftrags, sondern die korrekte Berechnung des Preises.

Industriepreise können abhängen von:

Kunde,
Kundengruppe,
Artikel,
Artikelgruppe,
Menge,
Verpackungseinheit,
Vertrag,
Projekt,
Lieferland,
Währung,
Datum,
Bonusvereinbarung,
Verkaufsorganisation.

Ein einfacher Export einer Preisliste reicht dann nicht aus.

Vor der Entwicklung muss geklärt werden:

Berechnet das ERP den Preis live?
Werden Preise vorberechnet und in den Shop importiert?
Gibt es eine Kombination aus Grundpreisen und Live-Prüfung?
Wie werden Sonderpreise und manuelle Freigaben behandelt?
Was passiert, wenn die Preisberechnung nicht erreichbar ist?

Auch eine B2B-Plattform mit umfangreichen Preislistenfunktionen darf die ERP-Logik nicht unbeabsichtigt duplizieren. OroCommerce bietet beispielsweise starke B2B- und Preislistenmodelle, dennoch muss die Systemführerschaft sauber definiert werden.

Mehr dazu unter OroCommerce ERP-Integrationsstärken.

Bestandsverfügbarkeit: live oder periodisch?

Ein Lagerbestand ist nicht automatisch die verkaufbare Menge.

Zu unterscheiden sind beispielsweise:

physischer Bestand,
reservierter Bestand,
frei verfügbarer Bestand,
erwarteter Zugang,
Sicherheitsbestand,
Bestand je Werk,
Bestand je Lagerort,
bereits kommissionierte Menge.

Der Shop benötigt meist nicht jeden ERP-Wert. Er benötigt eine geschäftlich belastbare Aussage wie:

sofort lieferbar,
lieferbar in fünf Tagen,
teilweise verfügbar,
Liefertermin auf Anfrage.

Eine Live-Abfrage ist sinnvoll, wenn Verfügbarkeit stark schwankt oder geschäftskritisch ist. Bei stabilen Beständen kann ein regelmäßiger Import ausreichen.

Reklamation, Gutschrift und Retoure

Viele Integrationen enden gedanklich bei der Bestellung. Der Kundenprozess endet dort jedoch nicht.

Ein vollständiges Kundenportal benötigt gegebenenfalls:

Reklamationsmeldung,
Auswahl einer Bestellposition,
Upload von Bildern und Dokumenten,
Retourenanfrage,
Freigabe der Rücksendung,
Statusanzeige,
Gutschrift,
Ersatzlieferung.

Im ERP existieren diese Prozesse häufig in unterschiedlichen Modulen oder sogar in externen Systemen. Die Integration muss deshalb nicht nur einen Auftrag schreiben, sondern den gesamten späteren Lebenszyklus betrachten.

Aufwandsspannen für die Erstintegration

Die Kosten einer ERP-Integration hängen stärker von Prozess- und Datenkomplexität ab als vom Namen des ERP-Systems.

Als grobe Projektbandbreiten können gelten:

Integrationsumfang	Typische Größenordnung
einfacher Produkt- und Auftragsaustausch	20.000–40.000 EUR
Preise, Bestände, Kunden und Auftragsstatus	40.000–80.000 EUR
komplexe Konditionen, mehrere Gesellschaften, Dokumente	80.000–150.000 EUR
internationale Plattform mit vielen Echtzeitprozessen	ab 150.000 EUR

Diese Spannen umfassen typischerweise:

Analyse,
Mapping,
Schnittstellenentwicklung,
Fehlerbehandlung,
Tests,
Dokumentation,
und Inbetriebnahme.

Nicht enthalten sind gegebenenfalls:

ERP-Anpassungen durch den ERP-Dienstleister,
zusätzliche Lizenzen,
Middlewarekosten,
Datenbereinigung,
PIM-Einführung,
umfassende Migration,
oder mehrere länderspezifische Rollouts.

Der sicherste Weg zu einer belastbaren Kalkulation ist ein vorgeschalteter Integrationsworkshop mit Datenobjektliste und konkreten Prozessfällen.

Middleware-Strategie: direkter Konnektor oder Integrationsschicht?

Nicht jede Verbindung sollte direkt zwischen Shop und ERP entwickelt werden.

Eine Middleware kann sinnvoll sein, wenn:

mehrere Systeme angebunden werden,
Formate transformiert werden müssen,
Prozesse überwacht werden sollen,
Daten zwischengespeichert werden,
mehrere Länder oder Gesellschaften beteiligt sind,
oder das ERP vor direkten Zugriffen geschützt werden soll.

Mögliche Werkzeuge sind beispielsweise:

SAP Integration Suite,
Infor ION,
MuleSoft,
Lobster,
Talend,
Patchworks,
n8n,
oder eine individuell entwickelte Integrationsschicht.

n8n kann beispielsweise selbst betrieben und für API-basierte Workflows eingesetzt werden. Für geschäftskritische ERP-Prozesse müssen jedoch Monitoring, Skalierung, Berechtigungen, Versionierung und Wiederanlaufkonzepte professionell umgesetzt werden. (n8n Docs)

Wann eine direkte Verbindung sinnvoll ist

Eine direkte Integration kann passen, wenn:

nur ERP und Shop beteiligt sind,
das Datenmodell überschaubar ist,
eine stabile Standard-API existiert,
wenige Transformationen notwendig sind,
und der Betrieb klar verantwortet wird.

Wann Middleware sinnvoller ist

Eine Integrationsplattform ist häufig die bessere Wahl, wenn:

ERP, PIM, CRM, DMS und Shop zusammenspielen,
mehrere Zielsysteme dieselben Daten benötigen,
zahlreiche Formate verarbeitet werden,
komplexe Fehlerbehandlung erforderlich ist,
oder weitere digitale Kanäle geplant sind.

Wichtig ist, dass Middleware nicht nur Daten weiterleitet. Sie sollte einen klaren fachlichen Zweck erfüllen und nicht zu einer zweiten, schlecht dokumentierten Geschäftslogikschicht werden.

Fazit: Die ERP-Integration beginnt mit Prozessen, nicht mit APIs

SAP, proALPHA, Infor, Sage und Microsoft Dynamics 365 Business Central bieten grundsätzlich Möglichkeiten zur Integration eines B2B-Shops.

Die technische Verfügbarkeit einer API beantwortet jedoch noch nicht die entscheidenden Fragen:

Welches System führt welche Daten?
Wie komplex ist die Preislogik?
Welche Informationen müssen live bereitstehen?
Welche Daten können periodisch übertragen werden?
Was passiert bei Ausfällen?
Wie werden Fehler erkannt und erneut verarbeitet?
Welche Prozesse folgen nach der Bestellung?

Der häufigste Fehler besteht darin, zu früh mit der technischen Implementierung zu beginnen.

Eine belastbare ERP-Integration startet mit:

Prozessaufnahme,
Datenobjektliste,
Festlegung der Stammdatenhoheit,
Entscheidung über Echtzeit und Batch,
Definition der Fehlerprozesse,
Erstellung eines realistischen Testkonzepts.

Erst danach sollte festgelegt werden, ob ein Standardkonnektor, eine direkte API-Anbindung oder eine Middleware-Architektur die beste Lösung ist.

Häufig gestellte Fragen zur ERP-Integration von B2B-Shops

Welche Daten werden zwischen ERP und B2B-Shop ausgetauscht?

Typischerweise werden Kunden, Artikel, Preise, Bestände, Aufträge, Lieferinformationen, Rechnungen und Gutschriften ausgetauscht. Welche Daten tatsächlich benötigt werden, hängt vom Geschäftsmodell und den geplanten Self-Service-Funktionen ab.

Müssen Preise in einem B2B-Shop immer live aus dem ERP abgefragt werden?

Nein. Bei überschaubaren Preislisten können Preise regelmäßig importiert werden. Bei komplexen kundenspezifischen Konditionen ist häufig eine Live-Abfrage oder eine Kombination aus vorgeladenen Preisen und Echtzeitvalidierung sinnvoll.

Wie wird SAP mit einem B2B-Shop verbunden?

Je nach SAP-System kommen unterschiedliche Wege infrage. SAP Business One bietet den Service Layer, S/4HANA stellt moderne APIs und OData-Dienste bereit. In älteren ECC-Landschaften werden häufig IDocs, BAPIs, RFC-Verbindungen oder bestehende Middleware-Prozesse genutzt.

Kann proALPHA an einen B2B-Shop angebunden werden?

Ja. Moderne proALPHA-Versionen verfügen über REST-basierte Integrationsmöglichkeiten. Der konkrete Umfang hängt von Version, Modulen, individuellen Erweiterungen und den benötigten Datenobjekten ab.

Welche Schnittstellen bietet Microsoft Dynamics 365 Business Central?

Business Central stellt standardisierte APIs und OData-Webservices bereit. Zusätzliche unternehmensspezifische Schnittstellen können über Erweiterungen und eigene API Pages beziehungsweise API Queries entwickelt werden.

Benötigt jeder B2B-Shop eine Middleware?

Nein. Bei wenigen Systemen und klaren Standard-APIs kann eine direkte Integration sinnvoll sein. Sobald mehrere Systeme, umfangreiche Transformationen oder komplexe Fehlerprozesse beteiligt sind, bietet eine Middleware häufig Vorteile.

Wie viel kostet eine ERP-Integration für einen B2B-Shop?

Einfache Integrationen beginnen häufig bei etwa 20.000 bis 40.000 Euro. Komplexere Projekte mit individuellen Preisen, Echtzeitbeständen, mehreren Gesellschaften und umfangreichen Folgeprozessen können 80.000 bis 150.000 Euro oder mehr kosten.

Was ist die wichtigste Entscheidung bei der ERP-Integration?

Die wichtigste Entscheidung ist die Festlegung der Datenhoheit. Für jedes Datenobjekt muss eindeutig definiert sein, welches System führend ist und welche Systeme Daten lediglich übernehmen oder anzeigen.

Sie planen einen B2B-Industrieshop und müssen Ihr ERP anbinden?

Unit M entwickelt ERP-Integrationen für SAP, proALPHA, Infor, Sage, Microsoft Dynamics und weitere im deutschen Mittelstand verbreitete Systeme.

Gemeinsam analysieren wir Prozesse, Datenobjekte, Preislogiken und Schnittstellen, bevor die eigentliche Shopentwicklung beginnt. So entsteht eine Integrationsarchitektur, die nicht nur beim Go-live funktioniert, sondern langfristig wartbar bleibt.

Vereinbaren Sie einen ERP-Integrationsworkshop für Ihr B2B-Commerce-Projekt.