Twee aparte PrestaShop-installaties die dezelfde producten verkopen uit dezelfde fysieke voorraad: het geval komt vaak voor. Een consumentensite en een zakelijke site, een Nederlandse en een Duitse webshop op aparte domeinen, of een hoofdmerk en een outletshop.
Zolang de voorraad niet wordt gedeeld, denkt elke webshop over het geheel te beschikken. De eerste oververkoop volgt binnen een week.
Drie mogelijke architecturen
Het native multistore. Eén installatie, meerdere logische webshops. De voorraad wordt native gedeeld, de vraag stelt zich niet. Dit is de eenvoudigste oplossing, en ze wordt vaak ten onrechte terzijde geschoven: veel projecten vertrekken met twee aparte installaties terwijl multistore had volstaan.
Twee gesynchroniseerde installaties. Elk heeft zijn eigen database, thema en modules, en een mechanisme houdt de voorraad samenhangend. Zwaarder, maar noodzakelijk zodra beide sites onafhankelijk moeten evolueren of aan verschillende juridische entiteiten toebehoren.
Een extern systeem als meester. Een ERP of beheerpakket bezit de voorraad, en beide webshops consumeren die. Dit is de gezondste architectuur zodra er een derde kanaal bestaat, een fysieke winkel of een marktplaats.
Controleer vóór u een synchronisatie bouwt of de eerste optie niet volstaat. Ze schaft het probleem af in plaats van het te beheren.
Eén meester, en maar één
Dit is de funderende beslissing, en de naïeve tweerichtingssynchronisatie is de klassieke valkuil.
Kunnen beide webshops de voorraad wijzigen en naar elkaar terugsturen, dan krijgt u lussen: webshop A boekt af, stuurt naar B, B past toe en stuurt terug naar A, die opnieuw afboekt. De voorraden lopen binnen enkele uren uiteen, en in de verkeerde richting.
Twee correcte modellen bestaan.
Het meester-slaafmodel: één webshop bezit de waarheid, de andere ontvangt. Eenvoudig, maar de verkopen van de slaaf moeten terugstromen, wat een apart kanaal voor de afboekingen veronderstelt.
Het model met gecentraliseerde voorraad: geen van beide bezit de voorraad, een externe referentiebron doet dat. Elke verkoop triggert een afboeking op die bron, die herverdeelt. Robuuster, en het veronderstelt een extra bouwsteen.
Multistore Synchronisatie: PrestaShop 8 & 9 ModuleSynchroniseer catalogus, voorraad en prijzen tussen meerdere PrestaShop-winkels€99,00
De frequentie, en het oververkoopvenster
Elke periodieke synchronisatie laat een venster waarin beide webshops een verschillend beeld hebben. Dat venster is te berekenen.
Synchroniseert u elk kwartier en verkoopt u drie stuks per uur van een referentie, dan vertegenwoordigt het venster gemiddeld minder dan één stuk: het risico is klein. Bij een flashverkoop van vijftig stuks per uur laat hetzelfde venster een dozijn bestellingen te veel door.
Drie instellingen volgen daaruit. Een hoge frequentie, vijf tot vijftien minuten, op snel roterende referenties. Een gebeurtenisgestuurde in plaats van periodieke synchronisatie op kritieke producten: elke verkoop triggert onmiddellijk de doorgifte. En een veiligheidsmarge, door één of twee stuks per webshop te reserveren, die het venster opvangt zonder extra complexiteit.
De koppeling van de referenties
Het technische punt dat over de haalbaarheid beslist. De product-ID’s zijn nooit dezelfde tussen twee installaties: product 421 op webshop A is niet product 421 op webshop B.
De koppeling moet dus steunen op een stabiele bedrijfssleutel, aan beide kanten aanwezig en nooit gewijzigd. De productreferentie voldoet, op voorwaarde dat ze overal is ingevuld en uniek is. De barcode is een stevig alternatief.
Twee valkuilen. Varianten moeten een eigen referentie hebben, anders gebeurt de synchronisatie op productniveau en blijft de voorraad per maat fout. En producten die maar aan één kant bestaan, moeten uitdrukkelijk worden genegeerd, niet bij elke cyclus als fouten worden behandeld.
Wat u niet synchroniseert
De verleiding is om alles gelijk te trekken. Dat is een fout, en ze maakt het systeem breekbaar.
Synchroniseer de prijzen niet als uw twee webshops een verschillende positionering hebben, wat bijna altijd de reden van hun gescheiden bestaan is. Synchroniseer de vertaalde beschrijvingen en de SEO-metadata niet, op straffe van dubbele content tussen twee domeinen. En synchroniseer bestellingen noch klanten, behalve bij een uitdrukkelijke behoefte: dat zijn gegevens met een zware regelgevende lading.
De minimale reikwijdte die werkt: de voorraad, de beschikbaarheid, en eventueel de actieve of inactieve status van het product.
De conflicten, en het herstel na een incident
Twee situaties om al bij het ontwerp te voorzien.
Het conflict. Beide kanten zijn veranderd tussen twee synchronisaties. De regel moet uitgeschreven zijn: ofwel wint de meester altijd, ofwel wint de laagste waarde, wat voorzichtig is bij voorraad. Een ongeschreven regel wordt een willekeurige regel.
De storing. Wat gebeurt er als de synchronisatie zes uur stilvalt zonder dat iemand het merkt? Drie beschermingen: een raadpleegbaar logboek van de synchronisaties met hun resultaat, een melding bij herhaald falen, en een volledige hersynchronisatie die handmatig te starten is.
Die laatste wordt stelselmatig vergeten, en het is precies degene die u op een zaterdagochtend dringend nodig hebt.
Controleren
Een voorraadafwijking zie je niet, je stelt haar vast op het moment van de oververkoop. Een wekelijkse controle die de aantallen aan beide kanten vergelijkt, referentie per referentie, kost enkele minuten en legt de afwijkingen bloot voordat ze een geannuleerde bestelling kosten.
De module Multi-Webshopsynchronisatie behandelt deze keten op PrestaShop 8 en 9: koppeling per referentie of barcode op variantniveau, voorraadsynchronisatie met instelbare richting en frequentie, logboek van de bewerkingen en volledige hersynchronisatie op aanvraag.
