Einer der lästigsten Nebeneffekte, wenn man Systeme miteinander verbindet, sind Duplikate. Dieselbe Rechnung zweimal verbucht, dieselbe Bestellung zweimal versendet, derselbe Kunde in drei verschiedenen CRM-Karteikarten. Klingt banal — bis man anfängt, die Stunden zu zählen, die dabei für Aufräumarbeiten und Zusatzkurier draufgehen.
Duplikate entstehen nicht, weil „das System eben mal spinnt". Sie entstehen durch einen ganz konkreten Mechanismus, den niemand im Demo erwähnt. Und die gute Nachricht: Man kann sie beseitigen, ohne die gesamte Integration neu zu bauen — vorausgesetzt, man versteht, wo sie wirklich herkommen.
Woher die Duplikate kommen
Eine klassische Integration zwischen zwei Systemen — sagen wir Online-Shop und ERP — läuft grob so: Der Shop schickt „hier ist eine neue Bestellung, Nr. 12345" an das ERP. Das ERP antwortet „angenommen". Eine Bestellung, eine Bestätigung, fertig.
Ärger fängt an, wenn die Bestätigung nicht ankommt. Das Netz hat eine Sekunde gehustet, das ERP war kurz nicht erreichbar, ein Timeout — egal. Der Shop weiß nicht, ob die Bestellung angekommen ist oder nicht. Zwei Möglichkeiten: annehmen, dass sie nicht durchging (und erneut senden), oder annehmen, dass sie durchging (und in Ruhe lassen). Fast jede Umsetzung wählt die erste — lieber zweimal senden als eine Bestellung verlieren.
Und da haben Sie Ihr Duplikat. Das ERP hatte den ersten Versuch tatsächlich angenommen — nur die Antwort kam nicht zurück. Der zweite Versuch trifft das ERP wie eine völlig neue Bestellung. Nichts hindert es daran, beide zu speichern.
Derselbe Mechanismus greift überall dort, wo Systeme aufeinandertreffen: Bank → ERP, ERP → WMS, Kurier → Shop, POS → Buchhaltung. Immer wenn „einer sendet, einer empfängt und dazwischen ein Netz liegt", das gelegentlich stockt.
Idempotenz — das Konzept in drei Sätzen
Die Lösung heißt technisch Idempotenz und klingt komplizierter, als sie in der Praxis ist. Grundgedanke: Man schickt dieselbe Operation zehnmal ab und ist sicher, dass das Ergebnis dasselbe ist, als hätte man sie einmal geschickt. Wie ein Lichtschalter: Beim ersten Drücken geht das Licht an, die nächsten neun ändern nichts.
Praktisch geht das so: Der Sender (Shop, Kurier, Bank) hängt an jede Operation eine eindeutige Nummer an — den Idempotenzschlüssel. Der Empfänger (ERP, WMS) merkt sich, welche Schlüssel er bereits verarbeitet hat. Kommt derselbe Schlüssel erneut, antwortet er einfach „habe ich, danke" und dupliziert nichts. Stripe und PayU nutzen dasselbe Prinzip für Zahlungstransaktionen.
Es gehört zu den Dingen, die man am besten schon beim Bau der Integration mit einplant — nachträglich einbauen kostet mehr. Machbar bleibt es trotzdem immer.
Beispiel: ein Kfz-Teilehändler
Bei einem unserer Kunden — einem 22-köpfigen Kfz-Teilehändler in Großpolen — sah es so aus: Comarch Optima als ERP, BaseLinker als Brücke zu Allegro und einem Shoper-Shop, ein schlankes WMS im Lager. Bestellungen aus Allegro liefen über BaseLinker in Optima und von dort zur Kommissionierung ins Lager.
Im Schnitt 14 Duplikatbestellungen pro Monat. Gemessen am Umsatz nicht dramatisch, operativ aber ein echter Klotz am Bein. Die Buchhalterin verbrachte rund 6 Stunden pro Monat mit dem Aufspüren und Stornieren von Duplikaten. Der Lagerkollege verschickte gelegentlich dasselbe Paket zweimal — Kurierkosten plus Aufwand, die Ware vom Kunden zurückzuholen, plus das „bitte entschuldigen Sie"-Telefonat. Kunden sahen zwei Kartenbelastungen und griffen zum Hörer. Aufs Jahr gerechnet kamen mehrere Dutzend Stunden Geschäftsleitungszeit für Entschuldigungen zusammen.
Die Diagnose hat uns einen halben Tag mit den Logs gekostet. BaseLinker schob die Bestellungen über eine Middleware in Optima (Eigenbau, geschrieben vor 4 Jahren von jemandem, der die Firma längst verlassen hatte). Die Middleware wiederholte bei Timeouts den Versuch — ohne Marker, dass es dieselbe Operation ist wie zuvor. Optima speicherte die zweite Kopie brav ab.
Der Fix war unspektakulär. Wir haben in die Middleware einen Idempotenzschlüssel eingebaut, gebildet aus baselinker_order_id + created_at. Optima bekam eine einfache Datenbanksicht, die prüft, ob der Schlüssel schon einmal durchlief. Als Sicherheitsnetz für alte Sünden lief außerdem ein Nachtjob, der identische Bestellungen im 24-Stunden-Fenster suchte und einen Alarm auslöste.
In den folgenden 3 Monaten: null Duplikate. Langweilig, aber wirksam.
Was Sie diese Woche tun können
Auch ohne Budget für eine große Umarbeitung lässt sich der Schaden mit ein paar schnellen Schritten begrenzen:
- Größe des Problems messen. Fragen Sie die Buchhaltung, wie viele stornierte Rechnungen und Bestellungen es im letzten Quartal gab. Solange Sie keine Zahl haben, nimmt es keiner ernst.
- Alarme einschalten. Ein simpler Report — „Bestellungen desselben Kunden über denselben Betrag im Fenster von 15 Minuten" — fängt die meisten Duplikate ab, bevor sie ins Lager rutschen. Als SQL-Report in Optima, enova oder Subiekt schnell gebaut.
- Einstellungen der Brücke prüfen. Viele Bridges (BaseLinker, Selly und ähnliche) haben eine Option „dieselbe Bestellung nicht erneut senden innerhalb von X Minuten". Standardmäßig oft aus.
- Middleware-Anbieter nach Idempotenz fragen. Wenn die Integration extern gebaut wurde, gibt es eine gute Frage: „Nutzt euer Code auf dieser Integration einen Idempotenzschlüssel?" Kommt „was ist das?" zurück, kennen Sie den Grund für Ihre Duplikate.
- Nicht im ERP reparieren. Für die einmalige Zustellung ist die Middleware-Schicht zuständig. Dedup-Logik ins ERP zu quetschen endet meist in verhedderten Buchungsregeln.
Wann Hilfe holen
Bleiben trotz dieser Schritte Duplikate — oder erzeugt die Integration ganze Kaskaden von Folgeschäden (doppelte Lagerreservierungen, doppelte Versandaufträge, doppelte Gutschriften) — ist es Zeit, einen sauberen Idempotenzschlüssel nachzurüsten. Das ist keine Revolution: Für die meisten Integrationen zwischen gängigen Systemen (Comarch Optima, enova365, Subiekt GT, Microsoft Dynamics AX, BaseLinker, Shoper, WooCommerce) reichen ein paar Arbeitstage, ohne dass an den Quellsystemen selbst etwas geändert werden muss.
Duplikate sind langweilig. Aber die Kosten ihrer Behandlung wachsen mit dem Umsatz — und irgendwann kosten sie mehr, als die Integration neu zu bauen.
Idempotenz ist eines dieser Dinge, die im Demo nie zur Sprache kommen — und die ein Jahr später darüber entscheiden, ob Ihre Integration ein Segen ist oder eine ständige Quelle für Korrekturen.