Freitag kurz nach zwei, der Anruf kommt aus dem Lager: Vierzehn Aufträge stehen seit Mittwoch auf „Freigegeben zum Versand", bezahlt, Ware liegt da, aber im Versandmodul erscheint keiner davon. Am Vormittag lief alles. Geändert hat angeblich niemand etwas.
Geändert hat meistens doch jemand etwas, nur nicht an der Stelle, an der der Auftrag stehenbleibt. Und das ist der Grund, warum die Suche fast immer in der falschen Ecke anfängt.
Ein hängender Auftrag ist kein Fehler, sondern ein ausgebliebenes Ereignis
PlentyONE bewegt Aufträge nicht von sich aus. Jeder Statuswechsel, jede Zahlungszuordnung, jede Versandregistrierung passiert, weil eine Ereignisaktion mit einem Auslöser gefeuert hat und alle ihre Filter zutrafen. Bleibt ein Auftrag stehen, gibt es dafür genau drei Möglichkeiten: Der Auslöser ist nie eingetreten, ein Filter hat den Auftrag ausgeschlossen, oder die Aktion selbst ist auf einen Fehler gelaufen.
Die dritte Variante ist die angenehmste, weil sie eine Spur hinterlässt. Die ersten beiden hinterlassen nichts. Kein Eintrag, keine Meldung, nur ein Auftrag, der auf demselben Status steht wie vorher. Wer nach einer Fehlermeldung sucht, sucht in der Mehrheit der Fälle nach etwas, das es nicht gibt.
Deshalb lohnt es sich, die Reihenfolge umzudrehen: erst den Auftrag lesen, dann die Konfiguration.
Fünf Werte am Auftrag, bevor du die Ereignisse öffnest
Öffne einen der betroffenen Aufträge und notiere Auftragstyp, Mandant beziehungsweise Herkunft, Zahlungsstatus mit dem tatsächlich zugeordneten Betrag, Versandprofil und das Lager der Positionen. Das sind die Felder, auf die in gewachsenen Systemen die meisten Filter zeigen.
Dann das Protokoll des Auftrags. Da steht, welche Ereignisaktion zuletzt gegriffen hat und wann. Wenn die letzte Zeile „Statuswechsel auf 5" von Mittwoch 11:42 ist und danach nichts kommt, weißt du, wo die Kette abbricht, und musst nur noch die Aktion finden, die auf Status 5 hören sollte.
Bei Plugin-Aktionen, Versandregistrierung eingeschlossen, reicht das Auftragsprotokoll oft nicht. Der Rückgabetext des Dienstleisters landet im Log unter Daten » Log; dort auf den Referenztyp Auftrag und die Auftrags-ID filtern. Wenn die Registrierung an einer ungültigen Adresszeile oder einem Gewicht von 0 scheitert, steht das dort im Wortlaut des Dienstleisters, und der Auftrag bleibt schlicht auf seinem Status stehen, weil die Statusänderung erst nach erfolgreicher Registrierung kommt.
Die Muster, die uns bei Übernahmen regelmäßig begegnen
Erstens: Der neue Verkaufskanal. Eine Ereignisaktion filtert auf Mandant oder Auftragsherkunft, weil das vor drei Jahren nötig war, als nur der eigene Shop und eBay angebunden waren. Dann kommt ein Marktplatz dazu, die Aufträge sehen im Grunde gleich aus, laufen aber nirgendwo mehr durch. Das Symptom: Der alte Kanal funktioniert, der neue nicht. Wenn dir jemand sagt „nur die Amazon-Aufträge hängen", ist der Filter mit hoher Wahrscheinlichkeit der Grund.
Zweitens: Zahlung fast vollständig. Der Auslöser „Zahlung vollständig zugeordnet" feuert nicht bei 49,98 Euro auf einen Auftrag über 49,99 Euro. Ein Cent Rundungsdifferenz von einem Zahlungsanbieter, und der Auftrag bleibt auf „Warten auf Zahlung". Dafür gibt es in den Auftragseinstellungen einen Toleranzbetrag für Zahlungsdifferenzen. Der steht in vielen Systemen auf 0, weil er bei der Einrichtung niemandem aufgefallen ist.
Drittens: Retouren und Gutschriften im Versandprozess. Fehlt der Filter auf den Auftragstyp, greifen Freigabe- und Versandaktionen auch auf Gutschriften. Manchmal fällt das nie auf, manchmal blockiert es einen Auftrag, weil eine Aktion einen Status setzt, den eine andere Aktion als Ausschluss verwendet.
Viertens: Der Bestand im falschen Lager. Die Freigabeaktion prüft die Verfügbarkeit, und zwar für das im Auftrag hinterlegte Lager. Ware im Zweitlager hilft nicht. Der Auftrag steht auf „Warten auf Ware", das Lager sieht die Palette und ist verständlicherweise irritiert.
Fünftens, seltener, aber unangenehm: die deaktivierte Aktion. Jemand hat für einen Test den Schalter umgelegt und ihn nicht zurückgestellt. In einer Liste mit sechzig Ereignissen sieht man das nicht beim Draufschauen.
Reihenfolge lässt sich nicht erzwingen, nur staffeln
Innerhalb einer Ereignisaktion laufen die einzelnen Aktionen in der Reihenfolge ab, in der sie dort stehen. Zwischen zwei Ereignisaktionen, die auf denselben Auslöser hören, gibt es diese Garantie nicht. Wenn die eine Aktion einen Status setzt, den die andere als Filter braucht, funktioniert das eine Weile und dann eben nicht mehr.
Wir haben in solchen Fällen zwei Wege: Entweder beide Schritte in eine Ereignisaktion zusammenfassen und über die Reihenfolge der Aktionen darin sortieren, oder über Zwischenstatus staffeln. Aktion A setzt Status 5.1, Aktion B hört auf den Statuswechsel nach 5.1 und macht weiter. Das kostet zwei zusätzliche Status, macht die Kette aber sichtbar und debuggbar. Ein Nebeneffekt der Staffelung: Jeder Schritt läuft asynchron über die Queue. Normalerweise sind das Sekunden, bei größeren Importläufen dauert eine dreistufige Kette auch mal ein paar Minuten. Für die Kollegin im Lager, die auf ein Label wartet, ist das der Unterschied zwischen „geht" und „geht nicht".
Was wir bis heute nicht verlässlich vorhersagen können, ist das Verhalten bei mehreren Statuswechseln innerhalb derselben Sekunde, etwa wenn eine Zahlungszuordnung und ein Marktplatz-Update zusammenfallen. Da hilft nur, die betroffene Kette so zu bauen, dass sie auch bei umgekehrter Reihenfolge zu einem sinnvollen Ergebnis kommt.
Den Bestand einmal ganz durchgehen
Unter Einrichtung » Aufträge » Ereignisse liegt die Liste. In Systemen, die fünf oder sechs Jahre gelaufen sind, stehen dort erfahrungsgemäß mehrere Dutzend Einträge, viele mit Namen wie „Status setzen" oder „Kopie von Versand DHL".
Geh sie nicht von oben nach unten durch. Sortiere im Kopf nach Auslöser und schreibe für jeden Auslöser auf, welche Aktionen daran hängen. Interessant sind die Auslöser, an denen mehr als eine Ereignisaktion hängt, insbesondere „Auftrag: Statuswechsel". Dort entstehen die Blockaden, weil eine Aktion Bedingungen für eine andere setzt oder zerstört.
Danach der umgekehrte Weg: Nimm den Status, den der Auftrag erreichen soll, und suche die Aktion, die ihn setzt. Lies deren Filter Zeile für Zeile gegen die fünf Werte, die du am Auftrag notiert hast. In den meisten Fällen fällt dabei genau ein Filter auf, der nicht passt, und der Rest der Untersuchung erledigt sich.
Bevor du etwas änderst, lege einen Testauftrag an und schreib die erwartete Kette vorher auf: Status 3 nach Zahlungseingang auf 5, von 5 nach Versandregistrierung auf 7. Wenn der Testauftrag an einer anderen Stelle abweicht als der Kundenauftrag, hast du zwei Probleme und nicht eins.
Was danach übrig bleibt
Der eigentliche Aufwand liegt selten im Finden der Blockade, sondern darin, dass niemand mehr weiß, warum es die Ereignisaktion 41 überhaupt gibt. Ein Namensschema mit Nummernpräfix, das die Kette abbildet, hilft mehr als jede Dokumentation außerhalb des Systems, weil es beim Öffnen der Liste sichtbar ist. „20 Zahlung » Freigabe" und „30 Freigabe » Versand" sagen einem in zwei Jahren noch, in welcher Reihenfolge gedacht wurde.
Und wenn du gerade eine Kette entwirrt hast: Notiere im Namen der Aktion, welcher Kanal oder Auftragstyp sie betrifft. Der nächste neue Marktplatz kommt bestimmt, und dann ist die Frage nicht mehr, welcher Filter blockiert, sondern nur, wo du ihn erweitern musst.
KI-generierter Inhalt.