Angebotsabruf und Preissynchronisierung

Angebote abrufen — Marketplace zu uns

Abrufanforderungen gelangen in die Abrufwarteschlange, die jede Minute verarbeitet wird. Ein separater Mechanismus plant alle paar Stunden vollständige Abrufe.

Einträge haben eine Priorität von kritisch bis Hintergrund sowie eine Quelle: manueller Klick, Zeitplan oder Prüfung nach einer Preisänderung.

Abrufmodi

• Vollständig — das ganze Angebot;
• Inkrementell — nur Änderungen;
• Einzelnes Angebot;
• Nur Preise — nur bei einigen Kanälen verfügbar;
• Nur Bestände;
• Angebote Produkten zuordnen.

Abrufauftrag und Status

Jeder Lauf erstellt einen Auftrag mit Status, Zählern und einem Lebenszeichen. So lässt sich ein Auftrag, der mittendrin ausgefallen ist, von einem unterscheiden, der einfach lange dauert.

Aufträge ohne Lebenszeichen gelten als hängengeblieben und werden regelmäßig bereinigt. Steht ein Auftrag seit vielen Stunden auf „in Bearbeitung“, kümmert sich die Bereinigung darum. Das ist jedoch ein Hinweis, dass der Kanal nicht antwortet.

Preise — von uns zum Marketplace

Eine Produktpreisänderung gelangt in die Preise-Warteschlange, die jede Minute verarbeitet wird. Von dort geht sie in die Warteschlange der Änderungen, die bei den Angeboten sichtbar ist (Änderungen und Warnungen – Übertragungswarteschlange und Bestandsabweichungen).

Die Preiskonfiguration wird separat für jede Kombination aus Kanal + Land eingerichtet. Dort stehen der Schalter für automatische Synchronisierung, Modus und Häufigkeit. Außerdem gibt es den Testmodus, mit dem du sehen kannst, was gesendet würde, ohne es tatsächlich zu senden.

Das ist keine Einstellung der Verbindung. Die automatische Preissynchronisierung aktivierst du in der Preiskonfiguration, nicht im Integrationsformular. Sie in den Verbindungseinstellungen zu suchen, ist ein häufiger Fehler — und ein häufiger Grund dafür, dass „nie Preise gesendet wurden“.

Empik: Der Preis wird zusammen mit dem gesamten Angebot gesendet

Bei einer Angebotsänderung überschreibt Empik (Mirakl) jedes Feld, das es nicht erhält — der Bestand fällt auf null und eine laufende Aktion verschwindet. Deshalb liest eine Preisänderung bei Empik zuerst das Angebot von Empik aus und sendet es vollständig zurück, wobei nur der Preis geändert wird (bei einer Aktion der Rabatt). Eine Änderung des regulären Preises während einer Aktion lässt diese bestehen. Lehnt Empik den Preis schnell ab (zum Beispiel unter dem Kategorie-Mindestpreis), schlägt die Änderung mit Empiks Ablehnungsgrund fehl; er ist in der Änderungsliste des Angebots sichtbar. Dauert der Import bei Empik länger, entscheidet eine spätere Prüfung: Sie vergleicht den bei Empik sichtbaren Preis, liefert aber keinen Ablehnungsgrund.

Angebote mit kanalbezogenen Preisen oder Mengenrabattstaffeln werden nicht geändert — eine Sendung ohne diese Daten würde sie löschen. Die Änderung schlägt mit dem Hinweis fehl, sie im Empik-Panel vorzunehmen.

Während einer Aktion zeigt Empik im Preisfeld den Betrag nach Abzug. Der Angebotsabruf speichert ihn als Aktionspreis und den Preis vor dem Rabatt als regulären Preis.

Angebote ohne Land

Ein-Land-Kanäle (PrestaShop, Allegro) speichern Angebote ohne Land, auch wenn in der Preiskonfiguration ein Land ausgewählt ist. Welche Preiskonfiguration sie bewertet, stellst du in den Verbindungseinstellungen im Preisbereich ein: Angebote ohne Land: Welche Preiskonfiguration bewertet sie?

• Automatisch (Standard) — die Konfiguration ohne Land oder, falls es keine gibt, die einzige aktive Konfiguration der Verbindung, auch wenn dort ein Land eingestellt ist.
• Land (zum Beispiel PL) — die Preiskonfiguration dieses Landes. Die Liste zeigt nur Länder mit einer aktiven Konfiguration für die Verbindung.
• Nicht synchronisieren — Preise für Angebote ohne Land werden nicht gesendet (Grund countryless_offers_off).

Lässt sich keine Konfiguration bestimmen — Automatisch bei mehreren Länderkonfigurationen und keiner ohne Land oder ein Land ohne aktive Konfiguration — wird das Angebot mit dem Grund offer_country_unknown übersprungen.

Die Konfiguration enthält außerdem Schutzgrenzen für den Umfang einer einmaligen Änderung. Sie verhindern, dass eine fehlerhafte Preisliste im ganzen Sortiment ausgespielt wird.

Netto oder brutto — vor dem Vergleich vereinheitlichen

Nicht jeder Kanal speichert Preise mit derselben Steuerbasis. PrestaShop speichert in products.price den Nettopreis und berechnet die Mehrwertsteuer anhand der Steuerregelgruppe des Produkts selbst dazu. Ceneo meldet Bruttopreise. Die meisten Endkunden-Marketplaces geben keine Basis an; der Preis wird so übernommen, wie er ankommt. Bei uns gibt das Feld Basis des Quellpreises (netto / brutto) in der Preiskonfiguration die Basis der Preisgruppe an.

Wenn die beiden Seiten verschiedene Basen angeben, rechnet das System den Angebotspreis auf die WMS-Basis um, anhand des beim Angebot gespeicherten Mehrwertsteuersatzes (zusammen mit dem Preis abgerufen — bei PrestaShop aus den Steuerregeln des Produkts für das Standardland des Shops, eingestellt unter Standardland des Shops). Das gilt überall:

• Angebotsliste und Details zeigen die Basis des Marketplace-Preises (zum Beispiel 1300,80 zł netto) und die Umrechnung ≈ 1599,98 zł brutto. Preis Δ und der Abweichungsfilter rechnen mit dem umgerechneten Betrag. Ein Nettopreis von 1300,80 bei einer Bruttopreisgruppe von 1599,99 ist also stimmig, nicht „−19 %“. Das Zeichen ≈ ist beabsichtigt: Der Shop speichert sechs Nachkommastellen, Noxti dagegen auf Groschen genau. Nach der Umrechnung kann daher ein Groschen fehlen. Eine Abweichung von höchstens einem Groschen gilt in der Liste, bei den Filtern eq/ne/gt/lt und im Lauf als Übereinstimmung.
• Ein Synchronisierungslauf vergleicht auf WMS-Basis und sendet den Betrag auf Basis des Kanals (an PrestaShop geht netto, selbst wenn die Gruppe brutto ist). Grenzwerte und Limits für Preissenkung oder -erhöhung werden nach der Umrechnung berechnet.
• Ein bei einem Angebot beauftragte Preisänderung speichert Betrag und Basis, mit der der Kanal ihn erhält.

Hat ein Angebot keinen Mehrwertsteuersatz (PrestaShop hat auf /tax_rules nicht geantwortet oder der Webservice-Schlüssel hat keine Berechtigung für /taxes), wird es bei verschiedenen Basen nicht verglichen. Die Angebotsdetails zeigen eine Warnung statt „Preise stimmen überein“, der Abweichungsfilter zeigt das Angebot an und der Lauf überspringt es mit Kein Mehrwertsteuersatz zur Umrechnung netto/brutto (tax_basis_unknown). Die Abhilfe: Angebote nach Vergabe der Schlüsselberechtigung aktualisieren — nicht den Preis von Hand eintragen.

PrestaShop: Alle Größen eines Modells haben denselben Modellpreis

Bei Shops mit Größen ist jedes PrestaShop-Angebot eine Kombination (ID wie 129018-1306: Modell + Größe). Der Kombinationspreis in PrestaShop ist nur ein Aufschlag auf den Modellpreis. Deshalb ändert Noxti den Modellpreis — eine Änderung stellt alle Größen auf einmal um. Die Angebotsdetails der Größe weisen ausdrücklich darauf hin.

Der Synchronisierungslauf sorgt für Sicherheit:

• Pro Modell ist nur ein aktiver Änderungsauftrag erlaubt, gleich aus welcher Quelle: manuell, gesammelt oder automatisiert. Ein zweiter Auftrag für eine andere Größe desselben Modells wird abgelehnt, bis der erste ausgeführt ist. Andere Größen werden mit Durch Preisänderung des Modells abgedeckt übersprungen. Das ist kein Fehler; ihr Preis ändert sich mit dem Modell.
• Haben Größen desselben Modells in der WMS-Preisgruppe unterschiedliche Preise, wird das Modell mit Modellgrößen haben unterschiedliche WMS-Preise übersprungen. Ein einzelner Modellpreis lässt sich daraus nicht ableiten; gleiche die Größenpreise im Katalog an.
• Ist eine Größe von der Synchronisierung ausgeschlossen, wird das ganze Modell übersprungen (Modellgröße ist von der Synchronisierung ausgeschlossen), weil die Preisänderung sie ebenfalls betreffen würde.
• Sind im Shop-Panel Aufpreise für einzelne Größen eingetragen, wird der Auftrag abgelehnt und nennt die Kombinationen mit Aufpreis. Noxti überschreibt sie nicht.
• Die Schwelle „unter Einkaufspreis“ richtet sich nach dem höchsten Einkaufspreis der Modellgrößen — der Modellpreis gilt für alle.
• Wurde ein als normales Produkt abgerufenes Angebot inzwischen im Shop mit Größen versehen, wird der Auftrag abgelehnt und fordert einen erneuten Angebotsabruf. Andernfalls würde er alle neuen Größen verändern.
• Sendet die Integration Preise in die Spalte wholesale_price, wird eine Preisänderung der Größe abgelehnt. In dieser Spalte hat die Kombination einen eigenen Preis statt eines Aufschlags; eine Änderung des Modellpreises betrifft sie daher nicht.

Der Preis, den Kunden im Shop sehen, kann weiterhin vom umgerechneten Preis abweichen: PrestaShop kann eigene spezifische Preise (Aktionen oder prozentuale Rabatte) anwenden. Noxti verwaltet diese nicht; die Abweichung muss im Shop-Panel entfernt werden.

Was der Lauf vergleicht — nur geänderte oder alle Preise

Standardmäßig nimmt ein Lauf nur Preise, die sich seit dem letzten Mal im Katalog geändert haben (Preise-Warteschlange). Ein Preis, der von Hand im Marketplace korrigiert wurde, oder eine Abweichung von vor Aktivierung der Synchronisierung gelangt nicht in die Warteschlange und wird nicht angeglichen.

Der Schalter Alle Preise vergleichen, nicht nur geänderte in der Preiskonfiguration ändert das: Der Lauf liest den gesamten Katalog — jedes Produkt mit einem Angebot auf diesem Kanal — vergleicht den Preis aus der Preisgruppe mit dem zuletzt bekannten Angebotspreis und sendet Abweichungen. Der Katalog wird seitenweise verarbeitet (Produktlimit pro Lauf unter „Limit / Zyklus“); die Position wird gespeichert. Daher gilt:

• Ein automatischer Lauf (je Intervall) bearbeitet pro Takt eine Seite und durchläuft den Katalog in mehreren Takten.
• Preise jetzt senden beginnt in diesem Modus am Anfang des Katalogs und arbeitet Seite für Seite bis zum Ende. Ein Klick prüft alles, auch eine konfigurierte Aktionspreisgruppe. Ein weiterer Klick währenddessen wird abgelehnt, da der Lauf bereits läuft.

Verglichen wird mit dem zuletzt abgerufenen Angebotspreis, nicht mit einer Live-Abfrage beim Marketplace. Der Vergleich ist nur so aktuell wie der letzte Angebotsabruf des Kanals. Grenzwerte, Limits für Preisänderungen und Schutz des Einkaufspreises funktionieren wie bei Änderungen aus der Warteschlange.

Live-Fortschritt eines Preisvergleichslaufs

In der Phase Preise, unter Preise jetzt senden, gibt es pro Konfiguration eine Laufkarte. Während des Laufs zeigt sie die Phase (Warteschlange / Katalog), den Fortschritt und die Katalogposition, die Seitenzahl sowie Zähler für gesendete Änderungen, übersprungene Positionen nach Grund (Preis unverändert, unter Grenzwert, Senkung über Limit, unter Einkaufspreis, kein Angebot usw.) und Fehler. Nach Abschluss bleibt die Karte als Ergebnis des letzten Laufs stehen. Keine Antwort mehr bedeutet, dass sich der Lauf seit einer halben Stunde nicht bewegt hat — die Verarbeitung wurde unterbrochen. Der nächste Klick startet einen neuen Lauf.

Zwei Kartenmeldungen erklären, warum ein Lauf leer wirkt:

• Keine Preise verglichen — die Konfiguration sendet nur geänderte Preise, aber seit dem letzten Lauf gab es keine Katalogänderung. „0 gesendet, 0 übersprungen“ heißt nicht, dass die Preise übereinstimmen. Aktiviere Alle Preise vergleichen, nicht nur geänderte, speichere und klicke auf Preise jetzt senden.
• Wartet in der Warteschlange — der Lauf wartet darauf, dass der Angebotsabruf eines anderen Kanals endet. Er startet von selbst; erneutes Klicken beschleunigt ihn nicht.

Wo du siehst, welche Preise gesendet wurden

In der Integration, Phase Preise. Dort gibt es ähnliche Zähler wie bei den Beständen:

• Zuletzt gesendeter Preis — wann tatsächlich etwas beim Kanal angekommen ist;
• Gesendet (24 Std.) — wie viele Änderungen der Kanal angenommen hat;
• In Warteschlange — wartende Positionen, daneben das Alter der ältesten Position als Hinweis, ob die Warteschlange steht;
• Übersprungen (24 Std.) — Positionen, die ohne Versand abgeschlossen wurden.

Darunter stehen die letzten Änderungen: Produkt, vorheriger/neuer Preis, Status und Grund für das Überspringen.

Ein grüner Status des letzten Laufs bedeutet nicht, dass ein Preis gesendet wurde. Er sagt nur, dass der Lauf beendet ist. Die Preise-Warteschlange hat keinen Status „Fehler“: Ein nicht sendbarer Preis endet als übersprungen mit einem Grund (meist „keine passenden Angebote oder unter Grenzwert“). Der Zähler „Gesendet“ kommt aus der Angebotsänderungs-Warteschlange, nicht aus der Preise-Warteschlange, damit dieser Unterschied sichtbar bleibt.

Drei unauffällige Zustände, die bedeuten „Von hier wird nichts gesendet“, benennt das Panel ausdrücklich:

• Keine Konfiguration kann senden — es gibt keine Konfiguration, die gleichzeitig aktiviert ist, eine reguläre Preisgruppe verwendet und auf den Kanal gerichtet ist. Eine Aktionsgruppe allein oder die Richtung „vom Kanal zum Katalog“ reicht nicht. Auch Preise jetzt senden wird dann abgelehnt.
• Preise werden nicht automatisch gesendet — die Konfiguration könnte senden, aber die Automatik ist ausgeschaltet. Änderungen sammeln sich in der Warteschlange und gehen erst nach einem manuellen Senden raus.
• Testmodus — der Lauf vergleicht Katalog und Kanal, sendet aber nichts.

Die Zähler umfassen Preisgruppen, über die dieser Kanal verkauft. Die Preise-Warteschlange selbst kennt keine Kanäle. Verwendet ein zweiter Kanal dieselbe Gruppe, weist das Panel darauf hin: Dieselbe Änderung zählt für beide.

Verarbeitete Warteschlangeneinträge werden nach 7 Tagen entfernt. Ältere Änderungen findest du dort nicht mehr. Den Verlauf eines einzelnen Produkts kannst du in der Synchronisierungskonsole über den EAN durchsuchen.

Reihenfolge beim Anschließen eines Kanals

1. Angebote abrufen.
2. Den Produkten zuordnen (Angebot einem Produkt zuordnen – ohne Zuordnung läuft nichts).
3. Lagerzuordnung prüfen (Zuordnungen – Lager, Versanddienstleister, Preislisten, Kategorien).
4. Erst dann das Senden von Beständen und Preisen aktivieren.

In umgekehrter Reihenfolge werden Bestände ins Leere gesendet.