Echtzeit, Abgleich und Protokoll

Wie Bestände zwischen den Stores wandern, was deine Regel entscheidet und wie du im Protokoll findest, warum eine Zahl so steht.

Echtzeit

Ändert sich in einem Store der Bestand einer zugeordneten SKU an einem verbundenen Standort, überträgt die App die Änderung in die anderen Stores desselben Standort-Verbunds.

Übertragen wird die Änderung, nicht der Wert. Fällt der Bestand in Store A von 10 auf 9, sinkt er in Store B um eins, egal wo B gerade steht.
Unter 0 geht es dabei nie.
Änderungen derselben SKU werden nacheinander übertragen und überholen sich nie.
Was die App selbst geschrieben hat, schickt sie nicht wieder zurück.
Wie lange eine Übertragung gedauert hat, zeigt die Übersicht unter „Verzögerung letzte Stunde“.

Die Echtzeit braucht keine Regel. Es gibt aber eine Richtung, einzustellen unter „Einstellungen“ → „Richtung der Echtzeit“:

Beidseitig: Jede Änderung aus jedem Store wandert weiter. Das ist die Vorgabe und der Normalfall gegen Überverkauf.
Einseitig: Nur Änderungen aus dem Store, der vorgibt, wandern weiter. Verkäufe in den anderen Stores senken ihn dann nicht.

Ausschalten geht jederzeit unter „Einstellungen“ mit „Echtzeit ausschalten“. Ab dann wird nichts mehr übertragen.

Abgleich

Der Abgleich ist das Netz unter der Echtzeit. Er liest die Bestände aller zugeordneten SKUs in allen Verbünden und zieht gleich, was auseinandergelaufen ist. Welche Zahl gewinnt, entscheidet deine Regel unter „Einstellungen“ → „Abgleich“:

Höchster Bestand gewinnt. Die Vorgabe.
Niedrigster Bestand gewinnt. Vorsicht: Meldet ein Store 0, weil er gerade leer ist, zöge diese Regel alle anderen mit. Die Sicherheitsbremse hält solche Änderungen zurück.
Ein bestimmter Store gewinnt. Du wählst den Store.

Die Regel gilt beim Abgleich von Hand, beim automatischen Abgleich und beim Einschalten der Echtzeit.

Eine SKU, für die die Echtzeit angehalten ist, lässt der Abgleich aus und nennt sie im Ergebnis.

Läuft die Echtzeit, lässt der Abgleich auch jede SKU aus, an der sie noch arbeitet:

Der Bestand ändert sich, während der Abgleich liest. Diese Änderung hat die Echtzeit schon übertragen; was der Abgleich gelesen hat, ist für diese SKU dann veraltet.
Für die SKU steht noch eine Übertragung aus, weil ein Store kurz nicht erreichbar war. Die App holt sie von selbst nach.
Der Bestand hat sich gerade erst geändert, und Shopify hat das der App noch nicht gemeldet. Die Meldung kommt meist nach wenigen Sekunden, dann überträgt die Echtzeit die Änderung. Gliche der Abgleich vorher an, schriebe er zum Beispiel einen Verkauf zurück. Er wartet deshalb zwei Minuten ab der Änderung.

Der nächste Abgleich nimmt diese SKUs wieder mit. Ist die Meldung von Shopify nach zwei Minuten nicht da, gilt sie als verloren, und der Abgleich gleicht nach deiner Regel an.

Das heißt auch: Korrigierst du einen Bestand von Hand und klickst gleich danach auf „Jetzt abgleichen“, kann genau diese SKU als ausgelassen im Ergebnis stehen. Die Echtzeit überträgt deine Korrektur trotzdem.

Wann der Abgleich läuft

Von Hand: unter „Abgleich“ mit „Jetzt abgleichen“.
Nach Zeitplan: unter „Einstellungen“ bei „Automatischer Abgleich“ „Einmal täglich“ oder „Zweimal täglich“ wählen, die Uhrzeit einstellen und „Regel und Zeitplan speichern“. Die Zeitzone steht darunter.
Beim Einschalten der Echtzeit, immer zuerst.
Von selbst, wenn die App länger als 15 Minuten nicht erreichbar war und die Echtzeit eingeschaltet ist. In so einer Lücke können Meldungen von Shopify verloren gehen.

Wenn ein Abgleich nach Zeitplan scheitert

Scheitert ein Abgleich nach Zeitplan, weil Shopify gerade nicht erreichbar war oder Anfragen gebremst hat, versucht die App es von selbst noch einmal. Dazu zählt auch, wenn die App ihren Zugangsschlüssel für einen Store erneuern wollte und Shopify in dem Moment nicht geantwortet hat. Die Abstände:

5 Minuten nach dem ersten Fehlschlag,
30 Minuten nach dem zweiten,
2 Stunden nach dem dritten.

Nach vier Versuchen ist für diesen Termin Schluss. Der vierte beginnt gut zweieinhalb Stunden nach dem ersten. Ein Abgleich um Mitternacht läuft also nicht erst am Vormittag. Der nächste automatische Abgleich kommt zum nächsten Termin.

Auf der Seite „Abgleich“ siehst du:

Unter „Letzter Abgleich fehlgeschlagen“ steht die Ursache. Solange ein Versuch aussteht, steht dort auch, wann er kommt und der wievielte es ist.
Sind alle Versuche verbraucht, steht das dort. Du kannst dann von Hand abgleichen oder auf den nächsten Termin warten.
Unter „Bisherige Abgleiche“ bleibt jeder Versuch als eigene Zeile stehen. Ein weiterer Versuch trägt seine Nummer, zum Beispiel „automatisch, 2. Versuch“.

Nicht wiederholt wird:

ein Abgleich, den du von Hand gestartet hast. Die Seite zeigt den Fehler, starte ihn noch einmal.
ein Fehler, der nicht von selbst vorbeigeht, zum Beispiel wenn die App keinen Zugang mehr zu einem Store hat oder Standorte nicht verbunden sind. Die Meldung nennt dann den nächsten Schritt.
ein Abgleich, den die Sicherheitsbremse abgebrochen hat. Das ist kein Fehler, sondern ihr Ergebnis.
der Abgleich, den die App nach einer eigenen Unterbrechung startet (Punkt 4 oben).

Ein weiterer Versuch startet nie neben einem laufenden Abgleich, er wartet auf dessen Ende. Er entfällt, wenn inzwischen ein anderer Abgleich durchgelaufen ist, wenn der nächste Termin ansteht oder wenn du den Zeitplan änderst.

Das Ergebnis eines Abgleichs

Unter „Letzter Abgleich“ steht, wann er lief, ob von Hand oder automatisch, und was dabei herauskam:

geschrieben: so viele Bestände hat er gesetzt.
abgelehnt: Der Bestand hatte sich zwischen Lesen und Schreiben geändert. Das ist richtig so, der nächste Abgleich holt es nach. Die App schickt die Änderungen für einen Store gebündelt an Shopify, bis zu 100 in einem Aufruf, und Shopify lehnt den ganzen Aufruf ab, wenn sich einer der Bestände darin geändert hat. Die App schickt die übrigen deshalb im selben Lauf noch einmal, ohne den geänderten. Ändert sich genau dann ein weiterer, warten auch sie auf den nächsten Abgleich und zählen als abgelehnt.
ausgelassen: Die Echtzeit arbeitet an diesen SKUs noch (siehe oben). Auch das ist richtig so. Darunter stehen die SKUs, jede führt ins Protokoll.
fehlgeschlagen: Hier lohnt ein Blick ins Protokoll.
„Alle abgleichbaren Bestände stimmten bereits überein.“ heißt: Es gab nichts zu tun.

Weitere Hinweise unter dem Ergebnis erklärt der Artikel „Hinweise und was zu tun ist“.

Frühere Abgleiche

Unter „Bisherige Abgleiche“ stehen die letzten acht Läufe mit Zeitpunkt, Art und Ergebnis: „geschrieben“ mit der Zahl, „läuft“, „hängt“, „abgebrochen“ oder „fehlgeschlagen“.

fehlgeschlagen: Direkt darunter steht, woran der Lauf gescheitert ist. Kennt die App die Ursache nicht, steht dort auch die technische Meldung für den Support.
abgebrochen: Die Sicherheitsbremse hat den Lauf gestoppt, es wurde nichts geschrieben. Darunter steht, was sie ausgelöst hat.

Für den letzten Abgleich steht der Grund nicht in der Liste, sondern oben auf der Seite, zusammen mit dem nächsten Schritt. Bei früheren Läufen fehlt der nächste Schritt mit Absicht: Was zu tun ist, richtet sich nach dem Stand von heute.

Die Sicherheitsbremse

Ein Bestand von 0 kann ein Ausverkauf sein, aber auch ein hängender Import oder ein leerer Store. Damit so ein Fehler nicht alle Stores leerräumt, gibt es zwei Bremsen.

Im Abgleich: Eine SKU, die auf 0 fiele, obwohl in einem anderen Store Ware liegt, wird nicht geschrieben, sondern als „zurückgehalten“ gemeldet. Betrifft das mindestens 5 SKUs und mehr als 10 % der abgleichbaren SKUs, bricht der ganze Abgleich ab und schreibt nichts.
In der Echtzeit: Fallen in einem Store binnen 10 Minuten mehr als 20 Bestände auf 0, hält die App die Echtzeit für genau diesen Store an. Die anderen Stores arbeiten weiter. Du gibst sie nach deiner Prüfung auf der Übersicht wieder frei.

Die Bremse gegen eine zweite Sync-App

Zwei Apps, die dieselben Stores abgleichen, schaukeln sich gegenseitig auf (siehe „Erste Schritte“, Abschnitt „Keine zweite Sync-App“). Verhindern kann die App das nicht. Sie begrenzt es. Verlass dich nicht allein darauf: In einem Test am 06.10.2026 hat die Bremse nach der ersten Runde angehalten. Da stand der Bestand in beiden Stores schon bei 140 statt 35. Der sichere Schutz bleibt, die andere App abzuschalten.

So arbeitet sie:

Meldet ein Store dieselbe Änderung noch einmal, die die App dort gerade übertragen hat, fragt sie bei Shopify nach, ob eine Bestellung dahintersteht. Wenn ja, überträgt sie wie immer.
Steht keine Bestellung dahinter, überträgt sie zunächst noch. Sie hält die Echtzeit für diese eine SKU an, sobald das binnen 15 Minuten in zwei Stores desselben Standort-Verbunds passiert ist oder dreimal im selben Store. Bis dahin ist die Änderung in jedem Store schon ein- bis dreimal zu viel gebucht, weil die zweite App zuerst schreibt.
Trifft es binnen 30 Minuten drei SKUs, hält sie die Echtzeit der ganzen Gruppe an.

Was sie nicht sieht:

Trägt die zweite App eine andere Menge ein als die, die gerade übertragen wurde, gilt das nicht als Verdacht. Das passiert, wenn sie mehrere Änderungen gesammelt nachträgt. Dann fällt sie frühestens eine Runde später auf.

Dieselbe Menge bis zu dreimal hintereinander in einem Store einzubuchen, löst nichts aus. Das kommt vor, wenn mehrere Retouren derselben Variante wieder eingebucht werden. Beim vierten Mal binnen 15 Minuten hält die App die SKU an: Ohne Bestellung dahinter sieht das für sie aus wie eine zweite App. Was bei einem Halt zu tun ist, steht im Artikel „Hinweise und was zu tun ist“.

Das Protokoll lesen: „Warum steht hier 3?“

Jede Zeile im Protokoll ist eine Zahl, die die App in einem Store gesetzt hat oder setzen wollte. So findest du die Erklärung zu einem Bestand:

Klicke auf eine SKU, zum Beispiel bei „Letzte Übertragung“ auf der Übersicht oder unter „Zugeordnet“ in der Zuordnung. Oder öffne „Protokoll“ und gib die SKU im Filter ein, genau so geschrieben wie im Store.
Du siehst die Geschichte dieser SKU, neueste zuerst.
Die oberste Zeile für den Store erklärt, warum der Bestand gerade so steht.

Jede Zeile hat drei Teile:

Was es ausgelöst hat, etwa „Bestand in store-a.myshopify.com fiel von 4 auf 3.“ oder „Abgleich von Hand nach der eingestellten Regel.“
Was die App getan hat, etwa „Übertragen nach store-b.myshopify.com: 4 → 3.“
Was zu tun ist, falls etwas zu tun ist.

Die App schreibt bewusst nicht „Verkauf“. Shopify meldet nur, dass sich ein Bestand bewegt hat, nicht warum. Eine Retoure „Verkauf“ zu nennen wäre geraten.

Die Ergebnisse im Protokoll

Geschrieben: Die Zahl steht so im Store.
Abgelehnt: Im Ziel hatte sich der Bestand zwischendurch geändert. Nichts zu tun: Die Echtzeit liest neu und wiederholt die Änderung, beim Abgleich holt es der nächste nach. Steht in der Zeile „Shopify hat den ganzen Aufruf abgelehnt“, hatte sich nicht dieser Bestand geändert, sondern ein anderer aus demselben Aufruf. Auch das holt der nächste Abgleich nach.
Zurückgehalten: Die Sicherheitsbremse hat nichts geschrieben. Prüfe, ob einer der Stores gerade leer oder unvollständig ist.
Angehalten: Die Echtzeit für diese SKU war angehalten, die Änderung ist nicht in den anderen Store gewandert. Auf der Übersicht steht, was zu tun ist.
Übersprungen: Am verbundenen Standort wird kein Bestand geführt. Die App schaltet das nie selbst ein.
Fehlgeschlagen: Die Zeile nennt die Ursache und den nächsten Schritt.

Filtern

Unter „Filter“ grenzt du nach SKU, Store, Ergebnis und Zeitraum („Von“, „Bis“) ein und klickst auf „Filtern“. „Filter zurücksetzen“ zeigt wieder alles. Mit „Ältere Einträge“ blätterst du zurück. Das Protokoll zeigt nur die Stores deiner eigenen Gruppe.