Montagmorgen, dreiundvierzig Bestellungen aus dem Wochenende. Jemand öffnet das Shop-Backend, überträgt Kundennummer, Artikelnummern und Mengen in einen Verkaufsauftrag in MS Dynamics 365, prüft nebenbei den Bestand und legt für zwei Neukunden erst einmal ein Debitorenkonto an. Gegen Mittag ist die Liste abgearbeitet. Zwischen dem Klick auf „Bestellen" und dem gebuchten Beleg im ERP liegt in vielen Häusern genau diese Strecke: Handarbeit.
Das kommt Ihnen bekannt vor: die Bestellung entsteht zweimal
Der Shop hat alles, was gebraucht wird. Kunde, Positionen, Mengen, Lieferadresse, Zahlart. Trotzdem entsteht die Bestellung im ERP ein zweites Mal, weil beide Systeme unterschiedliche Vorstellungen davon haben, was ein Kunde ist und wie ein Artikel heißt.
Der Aufwand steckt nicht im Abtippen, sondern in den Ausnahmen. Ein Neukunde ohne Debitorenkonto. Ein Artikel, den der Shop unter einer anderen Nummer führt. Eine Staffelpreisstufe, die der Shop anders gerechnet hat als das ERP. Jeder dieser Fälle unterbricht die Reihe und endet in einer Rückfrage bei jemandem, der gerade etwas anderes tut.
Dazu kommt der zeitliche Versatz. Solange die Bestellung nur im Shop steht, sieht das Lager sie nicht und die Buchhaltung auch nicht. Auf die Frage nach dem Liefertermin bekommt der Kunde deshalb eine Schätzung statt einer Auskunft.
Vier Übergabepunkte zwischen Shop und MS Dynamics 365
Order-to-Cash klingt nach einem durchgehenden Prozess. Tatsächlich sind es vier Übergaben, die unabhängig voneinander gelingen oder scheitern:
- Auftrag: Die Shop-Bestellung wird zum Verkaufsauftrag in MS Dynamics 365, mit Debitor, Positionen und Konditionen.
- Bestand: Die Verfügbarkeit aus dem ERP steht im Shop, über alle Lagerorte hinweg.
- Lieferung: Lieferschein und Trackingnummer laufen aus dem ERP zurück in den Shop und in die Kundenkommunikation.
- Rechnung: Der Rechnungsbeleg entsteht im ERP und ist dort buchhalterisch dokumentiert.
Diese vier lassen sich einzeln automatisieren, und genau das passiert in der Praxis meistens. Ein Haus hat den Bestand live und tippt die Aufträge. Ein anderes überträgt Aufträge automatisch und meldet den Versandstatus per Sammelmail zurück. Beides funktioniert, aber die Kette trägt nur so viel wie ihr schwächster Übergang.
ℹ️ Order-to-Cash bezeichnet die Strecke vom Kundenauftrag bis zum Zahlungseingang. Dieser Beitrag behandelt sie bis zum Rechnungsbeleg im ERP. Zahlungsabgleich, offene Posten und Mahnlauf schließen daran an, laufen aber innerhalb von MS Dynamics 365 und nicht mehr über die Shop-Schnittstelle.
Stammdaten entscheiden, ob die Automatisierung trägt
Die Versuchung ist groß, mit dem Auftrag anzufangen. Er ist sichtbar, er kostet die meiste Handarbeit, und die Wirkung zeigt sich am ersten Tag. Eine Auftragsschnittstelle auf einem uneinheitlichen Stammdatenbestand automatisiert allerdings vor allem die Fehler.
Drei Zuordnungen gehören davor geklärt. Welche Artikelnummer gilt, wenn Shop und ERP unterschiedliche führen? Wie findet die Schnittstelle den Debitor zu einem Shop-Konto, und was tut sie bei einem Neukunden: anlegen, oder in eine Prüfliste schreiben? Welches System rechnet den Preis, wenn im ERP Staffelpreise hinterlegt sind und im Shop eine Aktionslogik läuft?
Diese Fragen sind unangenehm, weil sie nicht technisch sind. Sie klären Zuständigkeiten zwischen Vertrieb, Einkauf und Buchhaltung, und dafür ist selten jemand allein zuständig. Wer sie überspringt, merkt es an dem Punkt, an dem die Schnittstelle läuft und trotzdem jeden Morgen zwanzig Aufträge im Fehlerprotokoll liegen. Dann arbeitet das Team dieselbe Liste ab wie vorher, nur an einer anderen Stelle.
Order-to-Cash mit OXID eShop und MS Dynamics 365: das Beispiel Voltus
Voltus handelt mit Elektromaterial und Beleuchtung und bedient B2B und B2C aus demselben Sortiment. ESYON hat dort ein OXID ePortal mit MS Dynamics 365 Finance and Operations und Perfion PIM verbunden. Rund 35.000 Produkte laufen über diese ERP-Integration, Go-Live war im Mai 2024.
zur ganzen Voltus-Story ➞
Aufschlussreich an dem Fall ist die Rollenverteilung. Perfion hält die Produktdaten, MS Dynamics 365 hält Preise, Bestände und Belege, der Shop hält die Bestellung, bis sie als Verkaufsauftrag übernommen ist. Jedes System führt genau das, was zu seiner Aufgabe gehört. Die Schnittstelle transportiert, sie entscheidet nicht.
An OXID gebunden ist dieser Weg nicht. Alphabetisch: Für Amazon gibt es den Amazon Marketplace Connector samt Abgleich gegen den Settlement Report, für OXID die OXID eShop Integration, für Shopify die Shopify Integration. Die vier Übergabepunkte bleiben in allen Fällen dieselben. Was sich unterscheidet, ist der Umfang dessen, was der Standard schon abdeckt, und wie viel im Projekt dazukommt.
Woran Sie merken, dass die Kette läuft Drei Werte zeigen den Fortschritt, und alle drei lassen sich schon vor dem Projekt erheben:
- die Zeit zwischen Bestelleingang im Shop und Auftrag im ERP
- der Anteil der Aufträge, die ohne manuellen Eingriff durchlaufen
- die Zahl der Rückfragen zum Liefer- und Rechnungsstatus
Ohne diese Ausgangswerte bleibt jede spätere Aussage über den Nutzen eine Behauptung. Zwei Wochen mitschreiben reicht, und die Erhebung kostet niemanden mehr als eine Strichliste. Realistisch ist dabei nicht, dass jeder Auftrag ohne Zutun durchgeht. Sonderkonditionen, Teillieferungen und Reklamationen brauchen weiterhin einen Menschen, der entscheidet. Realistisch ist, dass der Normalfall ohne Zutun läuft und die Ausnahmen sichtbar in einem Protokoll landen, statt sich in einem Posteingang zu verstecken.
