Was ist E-Commerce-ERP-Integration: wie eine Bestellung vom Bestand abgeht

In einem Betrieb ohne Integration öffnet morgens jemand das Shop-Backend, tippt die nächtlichen Bestellungen einzeln ins ERP, prüft dann den Lagerbestand und korrigiert den Bestand auf der Website von Hand. Solange das Geschäft klein ist, geht das. Mit mehr Bestellungen wachsen auch Tippfehler, Verzögerungen und vergessene Bestellungen. Die Informationen, die eine Integration überträgt, teilen sich nach Richtung:

• Vom Shop ins ERP: Bestellung, Kundendaten, Zahlungsstatus.
• Vom ERP in den Shop: Bestand, Preis, Produktinformationen.
• In beide Richtungen: Auftragsstatus, Sendungsverfolgung, Retouren und Stornierungen.

Integration ist weniger eine Softwarefunktion als eine Vereinbarung: Zwei Systeme einigen sich, welche Informationen sie in welcher Reihenfolge und nach welchen Regeln teilen. Integrationen ohne schriftliche Vereinbarung werden beim ersten Problem zum Streit darüber, wer recht hat.

Auch der Umfang der Integration sollte von Anfang an feststehen: Werden nur Bestellungen übertragen oder auch Kundendatensätze, Preislisten und Aktionspreise? Je größer der Umfang, desto mehr Zuordnungsregeln.

Alles beginnt mit dem Abgleich. Der Artikelcode im Shop und der Code der Lagerkarte im ERP müssen gleich sein. Die „Chiliflocken, mittelscharf, ein halbes Kilo“ des Gewürzherstellers sind auf der Website eine Variante, im ERP aber eine eigene Lagerkarte. Passen Variante und Lagerkarte nicht zusammen, kommt die Bestellung zwar im ERP an, berührt aber den Bestand nicht. Wo eine Lagerkarte in einem separaten Programm nicht ausreicht, beschreiben wir im Beitrag Lagerkarte und ERP.

Dann gibt es noch den Einheitenunterschied: Packung im Webshop, Karton im Lager, Kilogramm im ERP. Ist die Umrechnung nicht festgelegt, landet die Bestellung zwar beim richtigen Produkt, aber vom Bestand wird die falsche Menge abgezogen. Dass der Bestand zurück in den Shop fließt, ist das andere Ende der Kette; hat das Lager nur noch eine Packung, sollte auch der Shop nur noch eine zeigen.

Stimmt die Zuordnung, gibt es zwei Ansätze. Manche Betriebe reservieren die Menge, sobald die Bestellung eingeht, und buchen sie beim Versand ab; andere buchen sofort ab. Die Reservierung verhindert, dass der Bestand bei Bestellungen falsch erscheint, deren Zahlung noch nicht bestätigt ist oder die storniert werden könnten. Welcher Ansatz passt, hängt von Ihrer Buchhaltung und Ihrem Lager ab.

Beispielszenario: Stellen Sie sich eine Aktionsnacht vor einem Feiertag vor. Der letzte Karton im Lager wird über den Webshop verkauft; wird derselbe Karton am Nachmittag auch einem Lebensmittelhändler zugesagt, der anruft, muss am Morgen jemand einen der beiden anrufen und sich entschuldigen. Der Verkauf war richtig; was hakt, sind die zwei getrennten Lagerbestände.

Retouren rutschen auf dieselbe Weise durch. Der Kunde schickt die Ware zurück, der Shop bucht die Retoure, im ERP bleiben Bestand und Kundenkonto aber unverändert. Am Monatsende legt die Buchhaltung Shopbericht und ERP-Bericht nebeneinander und sucht tagelang, woher die Differenz kommt.

Der Ablauf ohne Integration hat auch versteckte Kosten: die Zeit der Person, die Bestellungen von Hand abtippt. In Aktionszeiten zieht sich diese Arbeit bis spät in die Nacht, und mit der Müdigkeit steigt das Fehlerrisiko.

Auch nach dem Start ist es in den ersten Wochen eine gute Gewohnheit, beide Seiten abzugleichen: Stimmt zum Tagesende die Bestellliste im Shop mit der im ERP überein?

Verkaufen Sie neben Ihrer eigenen Website auch auf Marktplätzen, wird derselbe Bestand über mehrere Kanäle verkauft. Die Bestellungen jedes Kanals sollten nach denselben Zuordnungsregeln im ERP ankommen; sonst aktualisiert ein Verkauf in einem Kanal den Bestand des anderen nicht. Manche Betriebe reservieren deshalb einen Teil des Bestands je Kanal.

Auch buchhalterisch sind Marktplatzverkäufe anders: Nicht der Kunde, sondern der Marktplatz zahlt, nach Abzug von Provision und Versandkosten. Werden diese Abzüge im ERP nicht gesondert gebucht, passen Debitorenkonto und Bankbewegung nicht zusammen.

Jeder Marktplatz hat eigene Regeln für Bestellstatus, Versand und Retouren. Ordnet die Integration diese Status nicht den Status im ERP zu, erscheint eine Bestellung auf der einen Seite als „versendet“ und auf der anderen als „in Vorbereitung“. Auch Marktplatzzahlungen kommen oft nicht am Bestelltag, sondern gesammelt in Perioden; zuzuordnen, welche Bestellung mit welcher Zahlung ausgeglichen wurde, ist eine eigene Aufgabe der Buchhaltung.

• Sind die Artikelnummern im Shop und im ERP gleich; wie werden Varianten zugeordnet?
• Was ist die maßgebliche Quelle für den Bestand: das ERP oder der Shop?
• Werden Daten in Echtzeit oder in festen Abständen übertragen?
• Wo erscheint ein Auftrag, der nicht übertragen werden konnte, und wer wird informiert?
• In welche Richtung und über welchen Datensatz laufen Retouren und Stornierungen?
• Auf welcher Seite wird die Rechnung erstellt, und als welche Belegart?

Die letzte Frage berührt steuerliche Vorschriften; klären Sie mit Ihrem Steuerberater, welcher Beleg auszustellen ist. Die Frage nach Bestellungen, die nicht übertragen werden, wird am häufigsten übersprungen: Bleibt die Integration still stehen, merkt es niemand, bis ein Kunde nach seinem Paket fragt. Sind die Partei, die die Integration aufbaut, und die, die sie betreibt, verschieden, sollte auch schriftlich feststehen, an wen man sich bei einer Störung wendet. Wer morgens als Erster erfährt, dass die Übertragung nachts stehen geblieben ist, ist die Antwort auf diese Frage.

Der Kunde des Gewürzherstellers fragt nach der Bestellung per WhatsApp nach dem Paket und eine Woche später nach einem Großhandelspreis. Diese Gespräche gehören zur Kundenbeziehung, nicht ins ERP. Die Trennung zwischen beiden haben wir im Beitrag Unterschied zwischen CRM und ERP ausführlich erklärt.

Deshalb darf die Kundenbeziehung nicht außerhalb der Integration bleiben. Stehen die Frage zur Sendung, die Retourenanfrage und die Anfrage nach Großhandelspreisen im selben Kundendatensatz, lässt sich dort auch ablesen, wem man in der nächsten Kampagne was anbietet.

Wir stellen Corex360 nicht als Integrationswerkzeug für Onlineshops oder Marktplätze vor. Der Kern von Corex360 führt Kunde, Angebot, Vertrag, Rechnung, Personal und Datei im selben Datensatz; WhatsApp-, Instagram- und Web-Nachrichten landen über einen Posteingang auf der Kundenkarte. Diese Struktur sehen Sie auf der Seite Kanäle in einem Posteingang zusammenführen.

Corex360 wird nicht als Lager-, Bestell- oder Marktplatz-Integrationsprogramm dargestellt; eine Bestellung vom Bestand abzubuchen ist Aufgabe Ihrer E-Commerce-Plattform und Ihres ERP. WhatsApp, Instagram und Web-Chat des Kunden landen im Nachrichten-Fenster in einem Posteingang, und die Herkunft der Verkaufschance wird im Datensatz festgehalten. Das Angebotsformular auf der Website öffnet automatisch eine Karte für die Verkaufschance. Die Ausgangsrechnung wird im Buchhaltungsmodul erstellt. Corex360 hat eine API für den Datenaustausch mit externen Systemen.