Zwei getrennte PrestaShop-Installationen, die dieselben Produkte aus demselben physischen Lager verkaufen: Der Fall ist häufig. Ein Endkundenshop und ein B2B-Shop, ein französischer und ein deutscher Shop auf getrennten Domains, oder eine Hauptmarke und ein Outlet.
Solange der Bestand nicht geteilt wird, glaubt jeder Shop, über die Gesamtmenge zu verfügen. Der erste Überverkauf kommt innerhalb einer Woche.
Drei mögliche Architekturen
Der native Multishop. Eine Installation, mehrere logische Shops. Der Bestand wird nativ geteilt, die Frage stellt sich gar nicht. Es ist die einfachste Lösung, und sie wird oft zu Unrecht verworfen: Viele Projekte starten mit zwei getrennten Installationen, obwohl der Multishop genügt hätte.
Zwei synchronisierte Installationen. Jede hat ihre Datenbank, ihr Theme, ihre Module, und ein Mechanismus hält den Bestand konsistent. Schwerer, aber notwendig, sobald sich beide Sites unabhängig entwickeln müssen oder verschiedenen Rechtsträgern gehören.
Ein führendes Drittsystem. Ein ERP oder eine Warenwirtschaft hält den Bestand, und beide Shops beziehen ihn. Das ist die gesündeste Architektur, sobald ein dritter Kanal existiert, ein Ladengeschäft oder ein Marktplatz.
Bevor Sie eine Synchronisierung bauen, prüfen Sie, ob die erste Option nicht ausreicht. Sie beseitigt das Problem, statt es zu verwalten.
Ein Master, nur einer
Das ist die Grundsatzentscheidung, und die naive bidirektionale Synchronisierung ist die klassische Falle.
Wenn beide Shops den Bestand ändern und sich gegenseitig zusenden können, entstehen Schleifen: Shop A bucht ab, sendet an B, B übernimmt und sendet zurück an A, der erneut abbucht. Die Bestände laufen innerhalb weniger Stunden auseinander, und zwar in die falsche Richtung.
Zwei korrekte Modelle existieren.
Das Master-Slave-Modell: Ein Shop besitzt die Wahrheit, der andere empfängt sie. Einfach, aber die Verkäufe des Slaves müssen zurückfließen, was einen eigenen Kanal für die Abbuchungen voraussetzt.
Das Modell mit zentralisiertem Bestand: Keiner der beiden Shops besitzt den Bestand, ein externes Referenzsystem tut es. Jeder Verkauf löst dort eine Abbuchung aus, und das System verteilt die Werte neu. Das ist robuster und setzt eine zusätzliche Komponente voraus.
Multi-Shop-SynchronisationSynchronisieren Sie Katalog, Bestände und Preise zwischen mehreren PrestaShop-Shops99,00€
Die Frequenz und das Überverkaufsfenster
Jede periodische Synchronisierung lässt ein Fenster, in dem beide Shops unterschiedliche Zahlen sehen. Dieses Fenster lässt sich berechnen.
Synchronisieren Sie alle fünfzehn Minuten und verkaufen drei Stück einer Referenz pro Stunde, entspricht das Fenster im Schnitt weniger als einem Stück: Das Risiko ist gering. Bei einem Flash-Sale mit fünfzig Stück pro Stunde lässt dasselbe Fenster ein Dutzend Bestellungen zu viel durch.
Daraus folgen drei Einstellungen. Eine hohe Frequenz, fünf bis fünfzehn Minuten, für schnelldrehende Referenzen. Eine ereignisgesteuerte statt periodische Synchronisierung für kritische Produkte: Jeder Verkauf löst sofort die Weitergabe aus. Und eine Sicherheitsmarge, indem ein oder zwei Stück pro Shop reserviert werden, die das Fenster ohne zusätzliche Komplexität abfedert.
Die Zuordnung der Referenzen
Ein technischer Punkt, der über die Machbarkeit entscheidet. Die Produkt-IDs sind zwischen zwei Installationen nie identisch: Produkt 421 in Shop A ist nicht Produkt 421 in Shop B.
Die Zuordnung muss sich daher auf einen stabilen Geschäftsschlüssel stützen, der auf beiden Seiten vorhanden ist und nie geändert wird. Die Produktreferenz eignet sich, sofern sie überall gepflegt und eindeutig ist. Der Barcode ist eine solide Alternative.
Zwei Fallen. Die Varianten müssen ihre eigene Referenz haben, sonst erfolgt die Synchronisierung auf Produktebene und der Bestand pro Größe bleibt falsch. Und Produkte, die nur auf einer Seite existieren, müssen explizit ignoriert werden, statt in jedem Zyklus als Fehler behandelt zu werden.
Was man nicht synchronisiert
Die Versuchung ist, alles anzugleichen. Das ist ein Fehler, und er macht das System fragil.
Synchronisieren Sie keine Preise, wenn Ihre beiden Shops unterschiedlich positioniert sind, was fast immer der Grund für ihre getrennte Existenz ist. Synchronisieren Sie keine übersetzten Beschreibungen und keine SEO-Metadaten, sonst entsteht doppelter Inhalt zwischen zwei Domains. Synchronisieren Sie weder Bestellungen noch Kunden, außer bei explizitem Bedarf: Das sind Daten mit hoher regulatorischer Last.
Der minimale Umfang, der funktioniert: der Bestand, die Verfügbarkeit und gegebenenfalls der Status aktiv oder inaktiv des Produkts.
Konflikte und die Wiederherstellung nach einem Zwischenfall
Zwei Situationen, die schon beim Entwurf einzuplanen sind.
Der Konflikt. Beide Seiten haben sich zwischen zwei Synchronisierungen geändert. Die Regel muss schriftlich festgelegt sein: Entweder gewinnt immer der Master, oder der niedrigere Wert gewinnt, was bei Beständen vorsichtig ist. Eine ungeschriebene Regel wird zur Zufallsregel.
Der Ausfall. Was passiert, wenn die Synchronisierung sechs Stunden lang stillsteht und niemand es bemerkt? Drei Schutzmaßnahmen: ein einsehbares Protokoll der Synchronisierungen mit ihrem Ergebnis, ein Alarm bei wiederholten Fehlern und eine manuell auslösbare vollständige Resynchronisierung.
Letztere ist die, die systematisch vergessen wird, und die, die man an einem Samstagmorgen dringend braucht.
Kontrollieren
Eine Bestandsabweichung sieht man nicht, man stellt sie beim Überverkauf fest. Eine wöchentliche Kontrolle, die die Mengen beider Seiten Referenz für Referenz vergleicht, dauert wenige Minuten und deckt Abweichungen auf, bevor sie eine stornierte Bestellung kosten.
Das Modul Multi-Shop-Synchronisierung deckt diese Kette auf PrestaShop 8 und 9 ab: Zuordnung per Referenz oder Barcode auf Variantenebene, Bestandssynchronisierung mit konfigurierbarer Richtung und Frequenz, Betriebsprotokoll und vollständige Resynchronisierung auf Abruf.
