Alle Vorlagen bitten um lesende Abfragen. Prüfe Verbindung, Zeitraum und Ergebnis im Chat. Ein Prompt ersetzt keine technischen Zugriffsrechte; die verfügbaren Daten hängen vom Marktplatz und deinen Berechtigungen ab.
12 von 12 Prompts
Für diese Kombination gibt es noch keinen Prompt.
OTTO /
Listings
Warum ist mein OTTO-Artikel nicht online?
- Das brauchst du
- OTTO-Verbindung und SKU
- Das erhältst du
- Status, Originalmeldungen und nächste Prüfschritte je Variante.
Prüfe die OTTO-SKU [SKU] in [Verbindung] ausschließlich lesend.
Zeige Marketplace-Status, active, MOIN, Fehlercode und Originalmeldung, Hinweise sowie lastModified und vorhandenen Shop-Link.
Trenne Fehler von Optimierungshinweisen. Nenne Quelle und Abrufzeitpunkt. Fehlende Felder oder Datensätze sind unbekannt, kein abgeleiteter Status.
Erkläre, was belegt ist, was offen bleibt und was ich als Nächstes prüfen sollte. Ändere keine Produkte oder Aktivierungen.
Beispielergebnis ansehen
+
So kann eine Antwort mit Beispieldaten aussehen.
- Beispieleingaben
- Verbindung: OTTO-Demo · SKU: DEMO-SHIRT-M
Die Variante wird als RESTRICTED gemeldet. Der konkrete Fehlergrund bleibt offen, weil die Originalfehlermeldung fehlt.
Datengrundlage: OTTO-Statusabfragen für eine SKU.
Die Tabelle lässt sich bei Bedarf seitlich scrollen.
Statusprüfung für DEMO-SHIRT-M | Prüfung | Beispielbefund | Nächster Prüfschritt |
| Marketplace-Status | RESTRICTED | Die zugehörigen Originalfehler abrufen. |
| Aktivierung | active = true | Die Einschränkung trotz gewünschter Aktivierung prüfen. |
| Fehlercode und Originalmeldung | Nicht vorhanden | Die fehlenden Belege ergänzen, bevor du Produktdaten korrigierst. |
Was du daraus nicht ableiten kannst
active = true belegt keine Veröffentlichung. Aus dem Status allein lässt sich kein fehlerhaftes Produktfeld bestimmen. Ein Sandbox-Status belegt zudem keine Veröffentlichung im Live-Shop.
Anbindung ansehen ↗
OTTO /
Bestände
Welche OTTO-SKUs liegen unter meinem Mindestbestand?
- Das brauchst du
- OTTO-Verbindung und Mindestmenge
- Das erhältst du
- Gemeldete Mengen unter der Schwelle, Datenlücken separat.
Lies die verfügbaren OTTO-Mengen in [Verbindung] vollständig über alle Ergebnisseiten. Mein Mindestbestand ist [Menge] Stück.
Zeige SKUs mit quantity kleiner als dieser Schwelle, aufsteigend nach Menge: sku, quantity, lastModified. Kennzeichne Nullmengen gesondert.
Nenne Quelle, Abrufzeitpunkt und Vollständigkeit. Eine unbekannte SKU oder ein fehlender Wert ist nicht null. lastModified ist kein Abrufzeitpunkt und kein Beweis für einen Synchronisationsfehler.
Bezeichne die Werte als gemeldete OTTO-Mengen, nicht als verifizierten Lagerbestand. Führe nur lesende Abfragen aus.
Beispielergebnis ansehen
+
So kann eine Antwort mit Beispieldaten aussehen.
- Beispieleingaben
- Verbindung: OTTO-Demo · Mindestbestand: 5 Stück
Zwei SKUs liegen unter 5 Stück: DEMO-A mit null und DEMO-B mit zwei Stück. Bei DEMO-D fehlt die Menge.
Datengrundlage: vier SKUs, alle Ergebnisseiten erfasst. DEMO-C meldet genau 5 Stück und liegt damit nicht unter der Schwelle.
Die Tabelle lässt sich bei Bedarf seitlich scrollen.
Bestände unter der Schwelle, Datenlücke separat | SKU | Beispielbefund | Nächster Prüfschritt |
| DEMO-A | quantity = 0 | Die Nullmenge mit dem Quellsystem abgleichen. |
| DEMO-B | quantity = 2 | Prüfen, ob eine Nachversorgung vorgesehen ist. |
| DEMO-D · Datenlücke | quantity fehlt | Die Menge klären; nicht als Nullbestand zählen. |
Was du daraus nicht ableiten kannst
Das sind gemeldete OTTO-Mengen. Sie belegen weder den physischen Lagerbestand noch einen Synchronisationsfehler. Ohne Abgangsdaten lässt sich keine Bestandsreichweite bestimmen.
Anbindung ansehen ↗
OTTO /
Bestellungen & Retouren
Welche OTTO-Positionen sind versandbereit?
- Das brauchst du
- OTTO-Verbindung
- Das erhältst du
- PROCESSABLE-Positionen, älteste zuerst, ohne Käuferdaten.
Erstelle lesend eine Versandarbeitsliste für OTTO [Verbindung]. Suche fulfillmentStatus=PROCESSABLE mit mode=AT_LEAST_ONE, ohne Datumsuntergrenze. Folge allen nextcursor-Seiten.
Behalte nur PROCESSABLE-Positionen und zähle salesOrderId plus positionItemId jeweils einmal. Zeige die 20 ältesten nach processableDate mit Bestellkennung, Positionskennung, SKU und expectedDeliveryDate, soweit vorhanden.
Zeige Gesamtzahl und nicht angezeigte Positionen. Führe fehlende Zeitwerte separat; leite aus expectedDeliveryDate keine Versandfrist ab. Nenne Quelle, Abrufzeitpunkt und Vollständigkeit. Keine Käuferdaten ausgeben, nichts als versendet markieren.
Beispielergebnis ansehen
+
So kann eine Antwort mit Beispieldaten aussehen.
- Beispieleingaben
- Verbindung: OTTO-Demo
Drei Positionen sind PROCESSABLE. Für zwei ist die zeitliche Reihenfolge bekannt; bei einer fehlt processableDate.
Datengrundlage: alle Ergebnisseiten ohne Datumsuntergrenze. Drei eindeutige Bestell-/Positionspaare, alle drei angezeigt. Zeitangaben in MEZ.
Die Tabelle lässt sich bei Bedarf seitlich scrollen.
Versandliste mit separater Position ohne Zeitangabe | Bestellung / Position · SKU | Beispielbefund | Nächster Prüfschritt |
| DEMO-100 / 1 · DEMO-A | PROCESSABLE; processableDate: 27.10.2026, 09:00 | Die älteste bekannte Position zuerst im Versand prüfen. |
| DEMO-101 / 1 · DEMO-B | PROCESSABLE; processableDate: 28.10.2026, 14:00 | Die weitere Versandbearbeitung prüfen. |
| DEMO-102 / 1 · DEMO-C | PROCESSABLE; processableDate fehlt | Die Zeitangabe klären; die Position nicht als jüngste einordnen. |
Was du daraus nicht ableiten kannst
PROCESSABLE ist kein Versandnachweis. Eine fehlende Zeitangabe erlaubt keine Altersreihenfolge. expectedDeliveryDate beschreibt das erwartete Lieferdatum und ist keine daraus ableitbare Versandfrist.
Anbindung ansehen ↗
OTTO /
Buybox & Werbung
Welche OTTO-Ads-Kampagnen liegen unter meinem Ziel-ROAS?
- Das brauchst du
- Verbindung, Zeitraum und Ziel-ROAS
- Das erhältst du
- Kampagnen unter dem Zielwert, nach Werbekosten sortiert.
Prüfe OTTO Ads in [Verbindung] nur lesend für [Startdatum] bis [Enddatum] in CET/CEST. Nenne die genauen Zeitgrenzen und übergib beide Datumsgrenzen. Mein Ziel-ROAS ist [Zielwert].
Lies alle Kampagnenseiten. Zeige je Kampagne ID, Name, Status, totalCosts, totalSales, ROAS, dateRange und lastCalculatedAt. Prüfe Geldeinheiten im aktuellen Schema und normalisiere zu Euro.
Rechne den ROAS bei positiven Kosten nach. Sortiere Kampagnen unter dem Ziel nach Kosten absteigend. Fehlende Daten und null Kosten sind separat nicht bewertbar. ROAS ist kein Gewinn. Nenne Abrufzeitpunkt und Vollständigkeit. Ändere keine Budgets oder Kampagnen.
Beispielergebnis ansehen
+
So kann eine Antwort mit Beispieldaten aussehen.
- Beispieleingaben
- Verbindung: OTTO-Demo · Zeitraum: 01.–07.10.2026 einschließlich, MESZ · Ziel-ROAS: 3
Demo A und Demo B liegen unter dem Ziel-ROAS von 3. Demo A steht wegen der höheren Kosten zuerst in der Prüfliste. Demo C ist bei null Kosten nicht bewertbar.
Datengrundlage: drei Kampagnen, alle Ergebnisseiten erfasst; derselbe Berichtszeitraum je Kampagne. Geldwerte sind bereits zu Euro normalisiert, Umsätze der Werbung zugerechnet.
Die Tabelle lässt sich bei Bedarf seitlich scrollen.
ROAS nachrechnen und nach Kosten priorisieren | Kampagne | Beispielbefund | Nächster Prüfschritt |
| 101 · Demo A | 400 € Kosten; 800 € zugerechneter Umsatz; ROAS = 2,0 | Die umsatzstarken und kostentreibenden Produkte dieser Kampagne prüfen. |
| 102 · Demo B | 100 € Kosten; 50 € zugerechneter Umsatz; ROAS = 0,5 | Produktleistung und Zeitraum der Kampagne prüfen. |
| 103 · Demo C | 0 € Kosten; 0 € zugerechneter Umsatz; ROAS nicht berechenbar | Aktivität und Datenabdeckung prüfen; keinen ROAS von 0 unterstellen. |
Was du daraus nicht ableiten kannst
ROAS ist zugerechneter Umsatz geteilt durch positive Werbekosten, kein Gewinn. Die Zahlen belegen keinen zusätzlichen Umsatz durch Werbung und rechtfertigen allein keine automatische Budgetänderung.
Anbindung ansehen ↗
KAUFLAND /
Bestände
Welche Kaufland-Angebote melden null Bestand?
- Das brauchst du
- Verbindung, Storefront und Versandabwicklung
- Das erhältst du
- Nullmengen, Sichtbarkeit und fehlende Daten getrennt.
Lies meine Kaufland-Angebote in [Verbindung], storefront [Ländercode], fulfillment_type [Versandabwicklung], über alle limit/offset-Seiten.
Zeige Angebote mit amount=0: id_unit, id_offer, id_product, amount, status und is_live, soweit vorhanden. Führe fehlende Mengen separat; fehlend ist nicht null. Zeige positive Mengen mit is_live=false in einer eigenen Prüfliste.
Nenne Quelle, Abrufzeitpunkt, Filter, Gesamtzahl und Vollständigkeit. Neu angelegte Angebote können verzögert erscheinen. Leite aus Menge oder status allein keine Sichtbarkeit und keinen physischen Lagerbestand ab. Ändere nichts.
Beispielergebnis ansehen
+
So kann eine Antwort mit Beispieldaten aussehen.
- Beispieleingaben
- Verbindung: Kaufland-Demo · Storefront: de · Versandabwicklung: fulfilled_by_merchant
Ein Angebot meldet null Bestand. Ein weiteres meldet 12 Stück, ist aber nicht live. Beim dritten fehlt die Menge; es zählt nicht als Nullbestand.
Datengrundlage: drei Kaufland-Angebote, alle Ergebnisseiten erfasst.
Die Tabelle lässt sich bei Bedarf seitlich scrollen.
Gemeldete Mengen und Sichtbarkeit getrennt prüfen | Angebot (id_offer) | Beispielbefund | Nächster Prüfschritt |
| DEMO-A | amount = 0; is_live = false | Die gemeldete Menge mit dem Quellsystem abgleichen. |
| DEMO-B | amount = 12; is_live = false | Die Gründe für die fehlende Sichtbarkeit prüfen. |
| DEMO-C | amount fehlt; is_live = false | Die Datenlücke klären; die Menge bleibt unbekannt. |
Was du daraus nicht ableiten kannst
Gemeldete Angebotsmengen sind kein verifizierter Lagerbestand. Eine positive Menge garantiert keine Sichtbarkeit. Die Tabelle belegt weder die Ursache für is_live = false noch einen Synchronisationsfehler.
Anbindung ansehen ↗
KAUFLAND /
Buybox & Werbung
Wie steht mein Kaufland-Angebot in der Buybox?
- Das brauchst du
- Verbindung, Storefront, EAN/Produkt-ID, Zustand und eigene Angebotskennung
- Das erhältst du
- Gemeldeter Rang, Preis inklusive Versand und Lieferzeitvergleich.
Prüfe die reguläre Kaufland-Buybox nur lesend für [EAN oder id_product], storefront [Ländercode], Zustand [Zustand], in [Verbindung]. Mein id_offer ist [Kennung]. Löse eine EAN zuerst zur Produkt-ID auf und bestätige den Titel.
Zeige die bis zu zehn verfügbaren Angebote mit gemeldetem Rang, Verkäufer, Zustand, Artikelpreis, Versandkosten, Preissumme, Lieferzeitspanne und Versandabwicklung. Prüfe Einheiten vor Umrechnungen. Berechne Preissummen nur aus bestätigtem Artikelpreis und Versand; fehlende Versandkosten sind nicht null.
Markiere mein Angebot nur mit bestätigter Zuordnung. Nenne Abrufzeitpunkt, gelieferte Angebotszahl und num_units. Trenne Beobachtungen und mögliche Erklärungen. Versprich keinen Ranggewinn und ändere keine Preise.
Beispielergebnis ansehen
+
So kann eine Antwort mit Beispieldaten aussehen.
- Beispieleingaben
- Verbindung: Kaufland-Demo · Storefront: de · id_product: 123450, Demo-Tasse · Zustand: NEW · eigenes id_offer: DEMO-ME
Dein eindeutig zugeordnetes Angebot liegt auf Rang 2. Seine Preissumme entspricht Rang 1, die gemeldete Lieferzeit ist länger. Bei Rang 3 fehlt der Versandpreis.
Datengrundlage: reguläre Buybox für ein bestätigtes Produkt; 3 Angebote geliefert, num_units = 3. Preiswerte sind bereits zu Euro und Lieferzeiten zu Tagen normalisiert.
Die Tabelle lässt sich bei Bedarf seitlich scrollen.
Gemeldeten Rang und vergleichbare Preise lesen | Angebot / Rang | Beispielbefund | Nächster Prüfschritt |
| Händler A · Rang 1 | 19,90 € + 2,90 € Versand = 22,80 €; Lieferung: 2–3 Tage | Die Lieferzeit mit dem eigenen Angebot vergleichen. |
| Dein Angebot DEMO-ME · Rang 2 | 20,90 € + 1,90 € Versand = 22,80 €; Lieferung: 3–4 Tage | Die eigenen Liefer- und Versandangaben prüfen. |
| Händler C · Rang 3 | 21,90 €; Versandkosten fehlen; Preissumme und Lieferzeit unbekannt | Die fehlenden Vergleichswerte ergänzen. |
Was du daraus nicht ableiten kannst
Die Lieferzeitdifferenz belegt nicht die Ursache des Rangs. Ein einzelner Abruf zeigt keinen Verlauf und garantiert keinen Ranggewinn. Fehlende Versandkosten sind nicht null; der Endpunkt liefert höchstens zehn Angebote.
Anbindung ansehen ↗
KAUFLAND /
Bestellungen & Retouren
Welche Kaufland-Artikel werden oft bestellt und storniert?
- Das brauchst du
- Verbindung, Storefront, Versandabwicklung und Zeitraum
- Das erhältst du
- Bestellte und stornierte Einheiten je zugeordnetem Artikel.
Analysiere Kaufland [Verbindung], storefront [Ländercode], fulfillment_type [Versandabwicklung], nur lesend. Zeitraum nach Erstellungszeitpunkt: [Startdatum] 00:00 einschließlich bis [Enddatum] 00:00 ausschließlich, Europe/Berlin.
Lies alle Order-Unit-Seiten und alle Status. Zähle jede id_order_unit einmal. Gruppiere nur nach bestätigter SKU-Zuordnung und Zustand.
Zeige bestellte Einheiten, davon cancelled, Einheiten ohne Stornos und Stornoanteil. Berechne Anteile nur bei positivem Nenner. Unbekannte Status und Zuordnungslücken separat; betroffene Ränge bleiben vorläufig. Retouren sind nicht zusätzlich abgezogen. Nenne Filter, Abrufzeitpunkt und Vollständigkeit. Keine Käuferdaten, keine Umsatz- oder Gewinnschätzung, keine Änderungen.
Beispielergebnis ansehen
+
So kann eine Antwort mit Beispieldaten aussehen.
- Beispieleingaben
- Verbindung: Kaufland-Demo · Storefront: de · Versandabwicklung: fulfilled_by_merchant · Erstellung: 01.10.2026, 00:00 bis 08.10.2026, 00:00 ausschließlich, Europe/Berlin
Unter den zugeordneten Artikeln hat DEMO-A mehr Bestellungen und einen höheren Stornoanteil: 4 von 20 Einheiten, also 20 %. Zwei weitere Einheiten bleiben ohne SKU-Zuordnung separat.
Datengrundlage: 32 eindeutige Order Units, alle Seiten und Status erfasst. 30 Einheiten sind zwei SKUs im Zustand NEW zugeordnet. Retouren werden nicht zusätzlich abgezogen.
Die Tabelle lässt sich bei Bedarf seitlich scrollen.
Bestellte und stornierte Einheiten je Artikel | Artikel / Zuordnung | Beispielbefund | Nächster Prüfschritt |
| DEMO-A · NEW | 20 bestellt; 4 cancelled; 16 ohne Storno; Stornoanteil: 20 % | Die gemeldeten Stornogründe für diesen Artikel prüfen. |
| DEMO-B · NEW | 10 bestellt; 1 cancelled; 9 ohne Storno; Stornoanteil: 10 % | Den Unterschied über einen vergleichbaren Zeitraum prüfen. |
| Zuordnung offen | 2 Einheiten ohne bestätigte SKU | Die Artikelzuordnung ergänzen, bevor du die Produktkennzahlen abschließend bewertest. |
Was du daraus nicht ableiten kannst
Bestellte Einheiten sind weder versendete Stücke noch Umsatz. Der Stornoanteil belegt keine Ursache. Unzugeordnete Einheiten können Produktkennzahlen verändern; Retouren sind eine separate Auswertung.
Anbindung ansehen ↗
KAUFLAND /
Bestellungen & Retouren
Welche Kaufland-Retouren brauchen eine Prüfung?
- Das brauchst du
- Verbindung, Storefront und Versandabwicklung
- Das erhältst du
- Offene Rücksendepositionen nach Bearbeitungsstand.
Prüfe Kaufland [Verbindung], storefront [Ländercode], fulfillment_type [Versandabwicklung], nur lesend.
Lies return-units mit need_to_be_returned, return_arrived, return_in_clarification und return_in_repair, ohne Datumsuntergrenze, über alle Seiten. Zähle jede id_return_unit einmal.
Ergänze den Retourenstatus je id_return. Zeige Positionskennung, Retourenkennung, Positionsstatus, Retourenstatus und Erstellungsdatum. Gruppiere nach Bearbeitungsstand, älteste zuerst. Nenne nächste Prüfschritte, ohne aus dem Alter eine verbindliche Frist abzuleiten.
Nenne Quelle, Abrufzeitpunkt und Lücken. Keine Kunden- oder Adressdaten, keine Freitextnotizen. Ändere nichts und sende keine Nachrichten.
Beispielergebnis ansehen
+
So kann eine Antwort mit Beispieldaten aussehen.
- Beispieleingaben
- Verbindung: Kaufland-Demo · Storefront: de · Versandabwicklung: fulfilled_by_merchant
Drei Rücksendepositionen brauchen unterschiedliche Prüfungen: eine wartet auf Rücksendung, eine ist eingetroffen und eine befindet sich in Klärung.
Datengrundlage: alle Seiten der vier angefragten offenen Positionsstatus, ohne Datumsuntergrenze. Drei eindeutige Positionen in drei Retouren; keine Position in return_in_repair.
Die Tabelle lässt sich bei Bedarf seitlich scrollen.
Positionsstatus und Retourenstatus getrennt lesen | Position / Retoure · erstellt | Beispielbefund | Nächster Prüfschritt |
| 501 / 701 · 20.10.2026 | Position: need_to_be_returned; Retoure: label_generated | Prüfen, ob bereits ein Versand- oder Eingangsnachweis vorliegt. |
| 502 / 702 · 21.10.2026 | Position: return_arrived; Retoure: package_received | Den Wareneingang und die ausstehende Prüfung der Position abgleichen. |
| 503 / 703 · 22.10.2026 | Position: return_in_clarification; Retoure: package_received | Die offene Klärungsfrage und zuständige Bearbeitung prüfen. |
Was du daraus nicht ableiten kannst
Ein Paketeingang belegt keine Annahme oder Erstattung jeder Position. Das Erstellungsdatum zeigt nicht, seit wann der aktuelle Status gilt, und begründet allein keine Bearbeitungsfrist.
Anbindung ansehen ↗
MIRAKL /
Bestände
Welche Mirakl-Angebote sind knapp oder inaktiv?
- Das brauchst du
- Marktplatz-Verbindung, Shop und Mindestmenge
- Das erhältst du
- Angebotsmengen und Aktivität als getrennte Befunde.
Lies in [Mirakl-Verbindung] und [Shop] alle Angebotsseiten mit OF21, nur lesend und unter Beachtung der Abruflimits. Mein Mindestbestand ist [Menge].
Zeige offer_id, shop_sku, product_sku, quantity, active und gelieferte inactivity_reasons. Trenne quantity unter der Schwelle, quantity=0 und inaktive Angebote mit positiver Menge. Führe fehlende Werte separat.
Leite aus state_code keinen Aktivierungsstatus ab. Falls ein vorhandener OF26-Abruf null liefert, ist damit nicht entschieden, ob die Menge null oder das Angebot nicht verfügbar ist.
Nenne Quelle, Shop, Abrufzeitpunkt und Vollständigkeit. Die Daten beweisen keinen physischen Lagerbestand. Ändere keine Angebote.
Beispielergebnis ansehen
+
So kann eine Antwort mit Beispieldaten aussehen.
- Beispieleingaben
- Verbindung: Mirakl-Demo · Shop: 2000 · Mindestbestand: 5 Stück
Zwei Angebote liegen unter 5 Stück. Ein drittes meldet 12 Stück, ist aber inaktiv. Mengen und Aktivierung führen zu unterschiedlichen Prüfschritten.
Datengrundlage: drei Angebote aus OF21, alle Seiten erfasst. Die Tabelle zeigt einen Auszug mit bestätigter Zuordnung von offer_id und shop_sku; zur Inaktivität wurde kein Grund geliefert.
Die Tabelle lässt sich bei Bedarf seitlich scrollen.
Knappe Mengen und inaktive Angebote unterscheiden | offer_id / shop_sku | Beispielbefund | Nächster Prüfschritt |
| 801 / DEMO-A | quantity = 0; active = false | Die Nullmenge und den Aktivierungsstatus im Quellsystem prüfen. |
| 802 / DEMO-B | quantity = 2; active = true | Die Nachversorgung für das knappe Angebot prüfen. |
| 803 / DEMO-C | quantity = 12; active = false; Grund fehlt | Den Inaktivitätsgrund beim Marktplatz prüfen. |
Was du daraus nicht ableiten kannst
Ein positiver Bestand erklärt keine Inaktivität. state_code bezeichnet keinen Aktivierungsstatus. Gemeldete Angebotsmengen belegen keinen physischen Lagerbestand.
Anbindung ansehen ↗
MIRAKL /
Listings
Warum ist mein Mirakl-Produktimport fehlgeschlagen?
- Das brauchst du
- Marktplatz-Verbindung, Shop und bekannte Import-ID
- Das erhältst du
- Verarbeitungsstand, Originalfehler und nächste Prüfschritte.
Prüfe den bekannten Produktimport [Import-ID] auf [Mirakl-Verbindung, Shop] nur lesend.
Zeige import_status, reason_status, Erstellungszeit, Transformationszähler, verfügbare Integrationsdetails und Berichtsverfügbarkeit. Falls Verarbeitung läuft, benenne das.
Werte verfügbare Transformations- und Integrationsfehlerberichte aus. Gruppiere nach Stufe, Feld und Originalmeldung; zeige Zahl der Meldungen und eindeutig betroffener Produkte getrennt. Nenne Produktkennungen, Belegstellen und nächste Prüfschritte. Erfinde keine Fehlercodes oder Pflichtfelder.
Fehlende oder unlesbare Berichte sind kein Erfolgsnachweis. Nenne Abrufzeitpunkt und Lücken. Starte keinen Import und ändere keine Daten.
Beispielergebnis ansehen
+
So kann eine Antwort mit Beispieldaten aussehen.
- Beispieleingaben
- Verbindung: Mirakl-Demo · Shop: 2000 · bekannte Produktimport-ID: 64021
Der Import steht auf COMPLETE. Im Transformationsbericht betreffen drei Meldungen zwei Produkte. Der Integrationsbericht ist nicht lesbar; das Gesamtergebnis bleibt deshalb unvollständig.
Datengrundlage: P42-Status und P47-Bericht. P44 konnte nicht ausgewertet werden. Fehlermeldungen sind hier sinngemäß zusammengefasst.
Die Tabelle lässt sich bei Bedarf seitlich scrollen.
Meldungen und betroffene Produkte auseinanderhalten | Stufe / Beleg | Beispielbefund | Nächster Prüfschritt |
| Transformation · Berichtszeilen 2 und 3 | 2 Meldungen zu DEMO-VASE-01: Kategoriezuordnung und Attributwert prüfen. | Beide Originalmeldungen mit derselben Produktzeile in der Quelldatei abgleichen. |
| Transformation · Berichtszeile 4 | 1 Meldung zu DEMO-VASE-02: Kategoriezuordnung prüfen. | Die Zuordnung zur Kategorie dieses Marktplatzbetreibers prüfen. |
| Integration · P44-Bericht | Nicht lesbar; Zahl betroffener Produkte unbekannt. | Den Bericht in einem lesbaren Format bereitstellen und getrennt auswerten. |
Was du daraus nicht ableiten kannst
COMPLETE bedeutet nicht, dass alle Produkte erfolgreich integriert wurden. Drei Meldungen sind hier zwei eindeutig betroffene Produkte in einer Stufe, keine Gesamtfehlerzahl. Pflichtfelder und Berichtsformate hängen vom Betreiber ab.
Anbindung ansehen ↗
MIRAKL /
Bestellungen & Retouren
Welche Mirakl-Aufträge warten auf Annahme oder Versand?
- Das brauchst du
- Marktplatz-Verbindung und Shop
- Das erhältst du
- Getrennte Arbeitslisten für WAITING_ACCEPTANCE und SHIPPING.
Prüfe [Mirakl-Verbindung] und [Shop] nur lesend. Lies WAITING_ACCEPTANCE und SHIPPING getrennt mit order_state_codes, ohne Datumsuntergrenze und über alle Seiten unter Beachtung der Abruflimits.
Zähle order_id je Verbindung und Shop einmal, darin jede order_line_id einmal. Zeige Bestell- und Positionsstatus getrennt, offer_sku, created_date und shipping_deadline, soweit vorhanden.
Sortiere SHIPPING nach vorhandener shipping_deadline; fehlende Fristen separat. Sortiere WAITING_ACCEPTANCE nach Erstellungsdatum, ohne eine Annahmefrist abzuleiten.
Nenne Quelle, Abrufzeitraum und Vollständigkeit. Keine Käuferdaten. Nimm keine Aufträge an, bestätige keinen Versand und sende keine Nachrichten.
Beispielergebnis ansehen
+
So kann eine Antwort mit Beispieldaten aussehen.
- Beispieleingaben
- Verbindung: Mirakl-Demo · Shop: 2000
Ein Auftrag wartet auf Annahme, zwei stehen auf SHIPPING. Bei einem Versandauftrag fehlt die Versandfrist; er bleibt als offener Prüffall separat.
Datengrundlage: getrennte Abfragen für WAITING_ACCEPTANCE und SHIPPING, jeweils alle Seiten ohne Datumsuntergrenze. Drei eindeutige Aufträge mit je einer Position; Zeitangaben in MEZ.
Die Tabelle lässt sich bei Bedarf seitlich scrollen.
Annahme und Versand getrennt priorisieren | Auftrag / Position · SKU | Beispielbefund | Nächster Prüfschritt |
| DEMO-201 / 1 · DEMO-A | Auftrag und Position: WAITING_ACCEPTANCE; erstellt: 27.10.2026, 09:00 | Die Voraussetzungen für eine Annahme prüfen. |
| DEMO-202 / 1 · DEMO-B | Auftrag und Position: SHIPPING; shipping_deadline: 30.10.2026, 16:00 | Den Versand anhand der gemeldeten Frist prüfen. |
| DEMO-203 / 1 · DEMO-C | Auftrag und Position: SHIPPING; shipping_deadline fehlt | Die Frist beim Betreiber klären; keine geringe Dringlichkeit unterstellen. |
Was du daraus nicht ableiten kannst
SHIPPING belegt weder erfolgten Versand noch einen Zahlungseingang. Aus dem Erstellungsdatum folgt keine Annahmefrist. Bei mehreren Positionen müssen deren Status einzeln geprüft werden.
Anbindung ansehen ↗
Marktplatzübergreifend /
Bestände
Wo unterscheiden sich meine Marktplatzbestände?
- Das brauchst du
- Verbindungen, Storefronts/Shops und bestätigte Artikelzuordnung
- Das erhältst du
- Gemeldete Kanalmengen nebeneinander, ohne Lagerbestände zu addieren.
Vergleiche ausschließlich lesend die gemeldeten Mengen in [Verbindungen und Storefronts/Shops] anhand dieser bestätigten Zuordnung: [interne SKU, Kanal-SKU/Angebots-ID, Variante, Packungsgröße, Zustand].
Lies alle benötigten Seiten. Zeige je Artikel Kanalmengen, Status beziehungsweise Verfügbarkeit, Quellen und Abrufzeiten nebeneinander. Trenne fehlende Datensätze, fehlende Mengen, null und inaktive Angebote.
Markiere Mengenunterschiede als Prüfanlass. Addiere Kanalmengen nicht zu einem Gesamtbestand; mehrere Angebote können denselben Lagerpool nutzen. Leite keine Synchronisationsfehler allein aus Differenzen ab.
Führe ungeklärte Zuordnungen separat. Nenne Vollständigkeit und Zeitversatz. Ändere keine Bestände.
Beispielergebnis ansehen
+
So kann eine Antwort mit Beispieldaten aussehen.
- Beispieleingaben
- OTTO-Demo · Kaufland-Demo, Storefront de · Mirakl-Demo, Shop 2000 · bestätigte Zuordnung für interne SKU DEMO-TASSE, blau, Einzelstück, neu
Für denselben Artikel melden OTTO 8 und Kaufland 5 Stück. Das Mirakl-Angebot wurde gefunden, seine Menge fehlt. Die Differenz von drei Stück ist ein Prüfanlass.
Datengrundlage: vollständig abgerufene Kanaldaten mit bestätigter Artikelzuordnung. Der größte Abstand zwischen den Abrufen beträgt zwei Minuten.
Die Tabelle lässt sich bei Bedarf seitlich scrollen.
Kanalmengen nebeneinander, ohne Gesamtbestand | Kanal / Kennung | Beispielbefund | Nächster Prüfschritt |
| OTTO · SKU DEMO-TASSE | quantity = 8; Marketplace-Status: ONLINE | Die gemeldete Menge mit Kanalzuordnung und Quellsystem abgleichen. |
| Kaufland de · id_offer DEMO-TASSE | amount = 5; is_live = true | Die Differenz unter Berücksichtigung von Zuteilung und Abrufzeit prüfen. |
| Mirakl Shop 2000 · offer_id 804 | Angebot vorhanden; quantity fehlt; active = false | Die fehlende Menge und den Inaktivitätsgrund getrennt klären. |
Was du daraus nicht ableiten kannst
8 + 5 ergibt keinen belegten Gesamtbestand: Die Angebote können denselben Lagerpool nutzen. Die Differenz beweist keinen Synchronisationsfehler. Die fehlende Mirakl-Menge ist nicht null.