Mirakl-Bestellstatus prüfen: Offene Aufträge und Vorfälle finden

Offene Mirakl-Aufträge findest du über den Bestellstatus: WAITING_ACCEPTANCE kennzeichnet die ausstehende Annahme, SHIPPING den noch zu bestätigenden Versand. Offene Vorfälle prüfst du zusätzlich über has_incident, unabhängig von dieser Statusauswahl. Für eine brauchbare Arbeitsliste brauchst du außerdem den richtigen Marktplatz und Shop, die einzelnen Bestellpositionen und vorhandene Versandfristen.

Mit Backlane kannst du die dafür freigegebenen Daten einer Mirakl-Verbindung im KI-Chat prüfen. Die Einrichtung steht in der Backlane-Dokumentation, die Grundlagen im Praxisleitfaden zur Marktplatzanalyse. Die folgenden Prompts sind Vorlagen für lesende Prüfungen. Sie wurden nicht mit einem Händlerkonto ausgeführt.

Welcher Mirakl-Status verlangt welche Prüfung?

Beginne mit dem Unterschied zwischen einem Auftrag, den du bearbeiten kannst, und einem Auftrag, der auf einen anderen Prozessschritt wartet. Mirakl führt einen Status für die Bestellung und zusätzlich für jede Position. Bei Teilstornos oder Vorfällen darf der Gesamtstatus die betroffene Position nicht ersetzen.

Status oder Merkmal	Bedeutung für die Prüfung	Nächster Schritt
WAITING_ACCEPTANCE	Die Entscheidung über die Annahme steht aus.	Betroffene Positionen und tatsächliche Lieferfähigkeit prüfen.
WAITING_DEBIT / WAITING_DEBIT_PAYMENT	Die Bestellung wartet auf einen Schritt im Zahlungsprozess.	Status und Zahlungsablauf im Händlerportal prüfen; nicht allein wegen des Alters zum Versand einplanen.
SHIPPING	Der Auftrag befindet sich in der Versandbearbeitung.	Offene Positionen, vorhandene Versandfrist und Lager-/Versandbelege abgleichen.
SHIPPED	Versand ist im Marktplatz bestätigt.	Bei einem Problem Sendungs- und Positionsdaten nachprüfen; der Status allein belegt keine Zustellung.
has_incident: true	Mindestens eine Position der Bestellung hat einen Vorfall.	Die betroffene Position und den gemeldeten Grund ermitteln.

Die Mirakl-Bestellschnittstelle OR11 beschreibt diese getrennten Felder. Die Dokumentation zu Annahmeentscheidungen und Versandbestätigungen ordnet die beiden Arbeitsschritte den Statuswerten WAITING_ACCEPTANCE und SHIPPING zu. Diese Anleitung liest die Daten; sie löst diese Änderungen nicht aus.

Weitere Statuswerte, etwa TO_COLLECT für einen Abholprozess, gehören bei entsprechenden Geschäftsabläufen in eine eigene Prüfung. Die Tabelle ist eine gezielte Auswahl für Annahme, Versand und Vorfälle. Auch der Zahlungsablauf kann je Betreiber oder Bestellung unterschiedlich sein: Aus SHIPPING allein solltest du daher keine allgemeine Aussage über einen erfolgten Zahlungseingang ableiten.

Wie findest du den gesamten offenen Arbeitsbestand?

Wähle zuerst die konkrete Mirakl-Verbindung und den Shop. Gleiche Bestellnummern aus verschiedenen Marktplätzen dürfen nicht zusammengeführt werden. Backlane stellt die Schnittstellen bereit; welche davon dein Marktplatz und deine Berechtigungen freigeben, zeigt sich beim Abruf.

Für einen vollständigen offenen Arbeitsbestand setzt du keine Untergrenze wie „seit gestern bestellt“. Ein Auftrag von letzter Woche kann noch auf Annahme warten. Auch ein Filter auf kürzlich geänderte Bestellungen ist dafür ungeeignet: Gerade ein lange unveränderter Auftrag könnte fehlen.

Die Ergebnislisten sind paginiert. Alle Seiten müssen gelesen und Bestellungen innerhalb derselben Verbindung und desselben Shops anhand ihrer Kennung eindeutig zugeordnet werden. Währenddessen können Status wechseln; die Liste dokumentiert deshalb einen Abruf mit Beginn und Ende, keinen unveränderlichen historischen Stand. Mirakl dokumentiert Filter und Seitennavigation in OR11.

Prüfe die Mirakl-Verbindung [Verbindung] und den Shop [Shop]
ausschließlich lesend. Erstelle getrennte Listen für
WAITING_ACCEPTANCE und SHIPPING mit order_state_codes.
Setze keine Untergrenze für Erstellungs- oder Änderungsdaten.
Lies alle Ergebnisseiten unter Beachtung der Abruflimits.
Zähle je Verbindung und Shop jede order_id einmal und darin
jede order_line_id einmal. Kennzeichne widersprüchliche Mehrfachtreffer.

Zeige Verbindung, Shop, order_id und je Position order_line_id,
offer_sku und order_line_state. Ergänze created_date,
last_updated_date und shipping_deadline, soweit geliefert.
Übernimm den Bestellstatus nicht ungeprüft auf alle Positionen.
Gib keine Namen, Adressen oder Kontaktdaten aus.

Sortiere SHIPPING nach vorhandener shipping_deadline aufsteigend.
Führe fehlende Fristen separat. Sortiere WAITING_ACCEPTANCE
nach Erstellungsdatum, ohne daraus eine Annahmefrist abzuleiten.
Nenne Quelle, Abrufbeginn/-ende in Europe/Berlin, Anzahl der
Bestellungen und Positionen sowie die Vollständigkeit.
Kennzeichne Fehler und Teilabrufe; ändere keine Daten.

Der Prompt erzeugt zwei fachlich unterschiedliche Listen. Eine Bestellung mit drei Positionen bleibt eine Bestellung und drei Positionen. Diese Zahlen getrennt auszugeben verhindert, dass eine Arbeitsliste versehentlich als Bestellstatistik gelesen wird.

Welche Frist ist wirklich belegt?

shipping_deadline bezeichnet die von Mirakl gelieferte Versandfrist. Ist sie vorhanden, kannst du sie mit dem Abrufzeitpunkt vergleichen. Ein bereits vergangener Zeitpunkt bei SHIPPING ist ein Anlass, den tatsächlichen Versand und die Rückmeldung an den Marktplatz zu prüfen. Er beweist allein nicht, dass das Paket noch im Lager liegt.

created_date ist das Erstellungsdatum. last_updated_date beschreibt die letzte Änderung am Datensatz. Aus beiden lässt sich ohne weitere Ereignisdaten nicht berechnen, wie lange die Bestellung bereits im aktuellen Status steht. Eine fehlende Versandfrist wird als fehlend ausgegeben; sie wird nicht aus einem pauschalen Standardwert errechnet. Die Felddefinitionen stehen im OR11-Antwortschema.

Wie findest du Vorfälle auch bei bereits versendeten Bestellungen?

Führe eine zweite Abfrage mit has_incident=true durch, ohne sie auf die beiden offenen Versandstatus zu begrenzen. Andernfalls würden etwa Vorfälle an bereits versendeten Aufträgen aus dem Ergebnis fallen.

Der Hinweis auf Bestellungsebene benennt noch nicht die Ursache. Prüfe order_line_state, vorhandene Grundcodes und Beschreibungen an den Positionen. Wenn die Antwort die betroffene Position oder den Grund nicht erkennen lässt, bleibt genau das die nächste Prüfung im Händlerportal. Fehlende Angaben sind keine Erlaubnis, eine plausible Ursache zu ergänzen.

Lies in [Mirakl-Verbindung] und [Shop] alle Bestellungen mit
has_incident=true. Verwende keinen order_state_codes-Filter
und keine Erstellungs- oder Änderungs-Untergrenze.
Lies alle Seiten unter Beachtung der Abruflimits.

Zeige je Bestellung Kennung, Bestellstatus und die betroffenen
Positionen, soweit eindeutig erkennbar. Zeige Positionsstatus,
order_line_state_reason_code und order_line_state_reason_label,
sofern vorhanden. Kennzeichne fehlende oder unklare Zuordnungen.
Formuliere pro Fall eine nächste Prüfung und trenne sie
ausdrücklich vom tatsächlich gemeldeten Befund.

Nenne Quelle, Abrufzeitraum und Vollständigkeit. Verknüpfe
Doppeleinträge aus der offenen Auftragsliste über Verbindung,
Shop und order_id; erhalte beide Prüfgründe. Gib keine
Käuferdaten aus. Sende keine Nachrichten und ändere nichts.

Wie sieht die Priorisierung an einem Beispiel aus?

Angenommen, du prüfst einen Shop am 30. Oktober um 09:00 Uhr, Europe/Berlin. Alle folgenden Kennungen und Werte sind frei erfunden:

Beispiel	Gemeldeter Befund	Konkrete nächste Prüfung
BEISPIEL-A	SHIPPING, Versandfrist heute 08:00 Uhr	Versandbeleg und Marktplatzmeldung zuerst abgleichen.
BEISPIEL-B	WAITING_ACCEPTANCE, erstellt am Vortag	Lieferfähigkeit der offenen Positionen vor einer Annahmeentscheidung prüfen.
BEISPIEL-C	SHIPPED, has_incident: true, Grund fehlt	Betroffene Position und Vorfalldetails im Händlerportal nachsehen.

Für BEISPIEL-A liegt eine konkrete Fristüberschreitung im Datenstand vor. Bei BEISPIEL-B ist nur das Auftragsalter bekannt. BEISPIEL-C gehört trotz Versandstatus auf die Arbeitsliste. Die KI kann diese Unterschiede zusammenfassen; die tatsächliche Bearbeitung und eine anschließende Kontrollabfrage bleiben eigene Schritte.