Modernes E-Commerce-Fulfillment: Wenn Shop, Lager und Versand dieselbe Sprache sprechenModern e-commerce fulfilment: when shop, warehouse and shipping speak the same language
Es gibt einen Satz, an dem man sofort hört, wie alt eine Logistik ist: Schicken Sie uns die Bestellungen bitte bis 11 Uhr als Excel-Datei.
Diese Datei ist nicht nur unbequem. Sie ist der Grund für fast jedes Problem, das danach kommt. Sie ist immer ein bisschen veraltet. Sie kennt keine Stornierung, die um 11:05 Uhr eintrifft. Sie kennt keinen Bestand, der sich gerade auf einem Marktplatz verändert hat. Und sie kennt keinen Fehler – sie wird einfach verarbeitet, auch wenn eine Spalte verrutscht ist.
Modernes Fulfillment beginnt genau da, wo diese Datei aufhört.
Die Systemlandschaft eines heutigen Händlers
Ein durchschnittlicher Onlinehändler betreibt heute vier bis sieben Systeme, die alle etwas über dieselbe Bestellung wissen wollen:
- Der Shop. Shopware, Shopify, WooCommerce, Magento, OXID oder eine Eigenentwicklung.
- Die Marktplätze. Amazon, eBay, Otto, Kaufland, Zalando, Etsy, idealo – jeder mit eigenen Regeln, eigenen Fristen und eigenen Strafen bei Verspätung.
- Das Warenwirtschaftssystem. JTL-Wawi, plentymarkets, Xentral, Billbee, Afterbuy, weclapp oder ein klassisches ERP.
- Das Lagersystem des Dienstleisters. Sein WMS, in dem Plätze, Bestände und Pickaufträge leben.
- Die Versender. DHL, DPD, GLS, UPS, Hermes, dazu Speditionen für alles, was nicht auf ein Band passt.
- Die Buchhaltung. DATEV, lexoffice, sevdesk – und in den meisten Fällen zusätzlich ein Steuerdienstleister für den EU-Versand.
Jedes dieser Systeme ist für sich genommen ein gelöstes Problem. Teuer wird ausschließlich der Raum dazwischen.
Die vier Datenströme, die laufen müssen
1. Artikelstammdaten – vom Händler zum Lager
Nummer, Bezeichnung, EAN, Maße, Gewicht, Gefahrguthinweise, Mindesthaltbarkeit ja oder nein, Seriennummernpflicht ja oder nein. Klingt nach Fleißarbeit und ist die halbe Miete: ein Artikel ohne gepflegte Maße bekommt im Lager den falschen Karton, und der falsche Karton kostet bei jeder einzelnen Sendung Porto.
2. Bestände – vom Lager zurück in alle Kanäle
Der wichtigste Strom. Der reale Bestand liegt im Lager, verkauft wird er an sechs Stellen gleichzeitig. Wird er nicht in Minuten zurückgemeldet, entstehen Überverkäufe – auf Amazon nicht nur ärgerlich, sondern kontorelevant. Wird er zu vorsichtig gemeldet, verkaufen Sie zu wenig.
3. Aufträge – vom Kanal ins Lager
Nicht nur der Auftrag selbst zählt, sondern auch alles, was danach kommt: Änderung der Lieferadresse, Stornierung, Teilstornierung, Expresswunsch, Wunschtermin, Geschenkverpackung. Ein System, das nur den Erstauftrag kennt, erzeugt Sendungen, die niemand mehr aufhalten kann.
4. Status und Tracking – zurück zum Kunden
Kommissioniert, verpackt, versendet, Sendungsnummer, zugestellt, Retoure eingetroffen. Dieser Rückweg ist der, der Ihren Kundenservice entlastet: jede Statusmeldung, die automatisch beim Kunden landet, ist eine Anfrage, die niemand beantworten muss.
Warum API und nicht Datei
Der Unterschied ist nicht die Technik, sondern die Zeit. Eine Datei ist eine Momentaufnahme, die veraltet, sobald sie geschrieben ist. Eine Schnittstelle ist ein Gespräch.
- Später Versandschnitt. Wenn Aufträge in Sekunden im Lager sind, kann der Schnitt bei 16 Uhr liegen statt bei 11 Uhr. Das sind fünf Stunden Verkaufszeit pro Tag.
- Weniger Überverkäufe. Bestandsmeldung in Minuten statt am Abend.
- Stornierungen greifen noch. Solange der Pickauftrag nicht gestartet ist, kann er zurückgezogen werden.
- Fehler werden sichtbar. Eine Schnittstelle antwortet. Eine Datei schweigt.
Woran Anbindungen in der Praxis scheitern
Nicht an der Technik. Fast immer an denselben fünf Stellen:
- Uneindeutige Artikelnummern. Im Shop lautet die Nummer
A-1001, auf AmazonA1001, im ERP1001. Jede Zuordnung, die auf Zuruf entsteht, bricht beim ersten neuen Artikel. - Teillieferungen. Zwei von drei Artikeln sind da. Darf gesplittet werden? Wer zahlt das zweite Porto? Wenn diese Regel nicht im System steht, entscheidet sie der Packer.
- Retourenstatus. Die Ware ist im Lager, aber die Erstattung hängt an der Prüfung. Ohne Rückmeldung erstattet der Kundenservice zu früh oder gar nicht.
- Doppelte Verarbeitung. Eine Schnittstelle, die bei einer Zeitüberschreitung erneut sendet, muss beim zweiten Mal erkennen, dass der Auftrag schon da ist. Sonst geht das Paket zweimal raus.
- Bündel und Sets. Verkauft wird ein Set, gelagert werden drei Einzelteile. Wer das erst im Lager auflöst, hat nirgends einen richtigen Bestand.
Eine Anbindung ist nicht fertig, wenn der erste Auftrag durchläuft. Sie ist fertig, wenn der erste Fehlerfall sauber durchläuft.
Die Rolle der Mittelschicht
Zwischen Kanälen und Lager sitzt in guten Aufbauten eine Auftragssteuerung – im ERP oder als eigene Ebene. Sie sammelt alle Kanäle ein, führt sie zusammen, entscheidet nach Regeln (welches Lager, welcher Versender, splitten ja oder nein) und spricht dann mit dem Lager. Der Vorteil zeigt sich beim siebten Kanal: Sie binden ihn einmal an – und nicht an jedes nachgelagerte System einzeln.
Fünf Fragen an jeden Fulfillment-Anbieter
- Welche Systeme binden Sie fertig an, und welche kosten Projektarbeit?
- Wie schnell melden Sie Bestände zurück – in Minuten, stündlich oder täglich?
- Was passiert bei einem Ausfall der Schnittstelle? Läuft es nach, oder ist der Tag verloren?
- Sehe ich Bestände und Aufträge selbst in einem Portal, oder muss ich anrufen?
- Wie werden Retouren zurückgemeldet – mit Grund und Zustand oder nur als Menge?
Wer auf diese fünf Fragen konkrete Antworten bekommt, hat den wichtigsten Teil der Auswahl bereits hinter sich. Der Rest ist Preisverhandlung.
Schnittstellen-Check für Ihren Shop anfordern
Sagen Sie uns, welche Systeme Sie einsetzen – wir sagen Ihnen, was sich direkt anbinden lässt und wo Arbeit steckt.
There is one sentence that instantly reveals how old a logistics operation is: Please send us the orders as an Excel file by 11 a.m.
That file is not just inconvenient. It is the reason for almost every problem that follows. It is always slightly out of date. It knows nothing about a cancellation arriving at 11:05 a.m. It knows nothing about stock that has just changed on a marketplace. And it knows nothing about errors – it simply gets processed, even if a column has slipped.
Modern fulfilment begins exactly where that file ends.
The system landscape of today's retailer
An average online retailer today operates four to seven systems, all of which want to know something about the same order:
- The shop. Shopware, Shopify, WooCommerce, Magento, OXID or an in-house development.
- The marketplaces. Amazon, eBay, Otto, Kaufland, Zalando, Etsy, idealo – each with its own rules, its own deadlines and its own penalties for delays.
- The merchandise management system. JTL-Wawi, plentymarkets, Xentral, Billbee, Afterbuy, weclapp or a classic ERP.
- The service provider's warehouse system. Their WMS, where locations, stock and picking orders live.
- The carriers. DHL, DPD, GLS, UPS, Hermes, plus freight forwarders for everything that doesn't fit on a conveyor.
- Accounting. DATEV, lexoffice, sevdesk – and in most cases an additional tax service provider for EU shipping.
Each of these systems, taken on its own, is a solved problem. The only thing that gets expensive is the space in between.
The four data flows that have to run
1. Article master data – from the retailer to the warehouse
Number, description, EAN, dimensions, weight, hazardous goods information, best-before date yes or no, serial number requirement yes or no. It sounds like busywork and it's half the battle: an article without properly maintained dimensions gets the wrong box in the warehouse, and the wrong box costs postage on every single shipment.
2. Stock levels – from the warehouse back into all channels
The most important flow. The real stock sits in the warehouse, but it is sold in six places at once. If it isn't reported back within minutes, overselling occurs – on Amazon that isn't just annoying, it affects your account. If it is reported too cautiously, you sell too little.
3. Orders – from the channel into the warehouse
It isn't just the order itself that counts, but everything that comes afterwards: change of delivery address, cancellation, partial cancellation, express request, requested delivery date, gift wrapping. A system that only knows the original order creates shipments that no one can stop anymore.
4. Status and tracking – back to the customer
Picked, packed, shipped, tracking number, delivered, return received. This return path is the one that takes the load off your customer service: every status update that automatically reaches the customer is one enquiry nobody has to answer.
Why API and not file
The difference isn't the technology, it's the timing. A file is a snapshot that goes out of date the moment it is written. An interface is a conversation.
- Later shipping cut-off. If orders reach the warehouse within seconds, the cut-off can be at 4 p.m. instead of 11 a.m. That's five hours of selling time per day.
- Fewer oversells. Stock reporting in minutes instead of in the evening.
- Cancellations still take effect. As long as the picking order hasn't started, it can be withdrawn.
- Errors become visible. An interface answers. A file stays silent.
Where integrations fail in practice
Not on the technology. Almost always at the same five points:
- Ambiguous article numbers. In the shop the number is
A-1001, on AmazonA1001, in the ERP1001. Any mapping that is created by word of mouth breaks with the first new article. - Partial deliveries. Two of three articles are available. Is splitting allowed? Who pays the second postage? If this rule isn't in the system, the packer decides it.
- Return status. The goods are in the warehouse, but the refund depends on the inspection. Without feedback, customer service refunds too early or not at all.
- Duplicate processing. An interface that resends after a timeout must recognise on the second attempt that the order is already there. Otherwise the parcel goes out twice.
- Bundles and sets. A set is sold, three individual items are stored. Anyone who only breaks that down in the warehouse has correct stock nowhere.
An integration isn't finished when the first order runs through. It's finished when the first error case runs through cleanly.
The role of the middle layer
In good setups, an order management layer sits between channels and warehouse – within the ERP or as its own level. It collects all channels, consolidates them, decides according to rules (which warehouse, which carrier, split yes or no) and then talks to the warehouse. The advantage shows itself with the seventh channel: you connect it once – and not to each downstream system individually.
Five questions for every fulfilment provider
- Which systems do you connect out of the box, and which require project work?
- How quickly do you report stock back – in minutes, hourly or daily?
- What happens if the interface fails? Does it catch up, or is the day lost?
- Can I see stock and orders myself in a portal, or do I have to call?
- How are returns reported back – with reason and condition, or only as a quantity?
Anyone who gets concrete answers to these five questions has already completed the most important part of the selection process. The rest is price negotiation.
Request an interface check for your shop
Tell us which systems you use – we'll tell you what can be connected directly and where the work lies.
Einfach konfigurierenEasy configure
Konfigurieren Sie Ihr Fulfillment-AngebotConfigure Your Fulfillment Offering
Jetzt Angebot anfordernRequest a Quote Now