Exporteren en dan importeren via CSV is de reflexmethode om producten van de ene winkel naar de andere te verplaatsen. Ze werkt op eenvoudige catalogi en verliest veel zodra de productfiches compleet zijn.
Dit artikel vergelijkt de methoden. Het dupliceren van een volledige boomstructuur is een aangrenzend project, dat apart wordt behandeld.
Wat de CSV correct transporteert
Laten we precies zijn: de bestandsimport is niet slecht, hij heeft een bereik.
Hij verwerkt de eenvoudige velden goed: naam, referentie, prijs, beschrijving, gewicht, status. Hij verwerkt de koppelingen op naam: categorieën, merk, leverancier, op voorwaarde dat die entiteiten al bestaan aan de bestemmingskant.
Hij is ook het enige bruikbare instrument voor een massale update: driehonderd prijzen wijzigen, beschrijvingen corrigeren, een partij activeren of deactiveren.
Op een catalogus van eenvoudige producten zonder varianten, met één afbeelding per fiche, doet de export-import het werk.
Wat hij verliest
Vijf elementen, in volgorde van ernst.
De afbeeldingen. Het formaat verwacht publiek toegankelijke adressen, geen bestanden. Dat veronderstelt dat de afbeeldingen van de bronwinkel bereikbaar zijn vanaf de bestemming tijdens de hele import, en het downloaden van duizenden visuals is traag en fragiel.
Vooral de koppelingen tussen afbeelding en variant gaan niet mee. Al uw afbeeldingen komen aan het product te hangen, zonder verband met de varianten.
De varianten. Ze worden geïmporteerd via een apart bestand, met een attribuutsyntaxis die tot op het teken moet worden gerespecteerd. De prijsimpacten, de referenties per combinatie en de voorraden per variant vragen elk hun kolom, en een formaatfout produceert gedeeltelijke combinaties die moeilijk op te sporen zijn.
De kenmerken en aangepaste waarden, die dezelfde syntaxislogica volgen en stilzwijgend mislukken wanneer een waarde niet bestaat.
De posities in de categorieën. Ze staan niet in het standaardformaat. Al uw producten komen aan gesorteerd op identifier, wat merchandisingwerk uitwist.
De relaties tussen producten: accessoires, gerelateerde producten, packs. Ze steunen op interne identifiers die geen enkele betekenis hebben in de bestemmingswinkel.
Multistore Duplicatie van een Volledige Categorie: PrestaShop 8 & 9Kopieer een volledige categorie van de ene winkel naar de andere, met één klik€109,00
Het probleem van de identifiers
Dit is de structurele moeilijkheid van de bestandsoverdracht, en ze verklaart de meeste mislukkingen.
Een geëxporteerd product draagt zijn identifier van de bronwinkel. Bij de import zijn twee gedragingen mogelijk: ofwel maakt het systeem een nieuw product met een nieuwe identifier, wat alle relaties breekt, ofwel probeert het de identifier te hergebruiken, wat mogelijk een bestaand product overschrijft.
Dezelfde vragen stellen zich voor de categorieën, de merken, de attributen en de kenmerken. Elk heeft zijn eigen identifier, en niets garandeert de overeenstemming tussen de twee winkels.
Het praktische gevolg: na een CSV-import blijft er altijd handmatig reconstructiewerk van de koppelingen over. Op honderd producten is dat meerdere uren.
De directe kopie
Het alternatief bestaat erin de data nooit uit de database te halen: de kopie gebeurt intern, met resolutie van de overeenkomsten onderweg.
Vier praktische verschillen.
De afbeeldingen blijven bestanden, gekopieerd op de schijf met hun koppelingen aan de varianten intact.
De varianten worden gereconstrueerd met hun attributen, waarbij ontbrekende waarden aan de bestemmingskant zo nodig worden aangemaakt.
De overeenkomsten worden berekend en bewaard: het systeem weet dat bronproduct 1245 product 3891 is geworden, wat toelaat de relaties te reconstrueren.
De posities worden doorgegeven, aangezien ze rechtstreeks in de structuur worden gelezen.
De keerzijde: deze methode veronderstelt dat de twee winkels dezelfde installatie delen, wat het geval is in multistore maar niet tussen twee aparte installaties.
Welke methode volgens de situatie
Drie scenario’s.
Twee winkels van dezelfde multistore-installatie: directe kopie, zonder aarzelen. Het is het meest voorkomende geval en dat waar het verschil het grootst is.
Twee aparte installaties, zelfde hosting: directe kopie mogelijk met toegang tot beide databases, of overdracht via programmeerbare interface, die de structuren behoudt.
Twee installaties zonder verband: het bestand blijft de enige eenvoudige weg. Voorzie dan de handmatige reconstructie en behandel de afbeeldingen apart.
Wat te controleren voor het kopiëren
Vier voorbereidingen, ongeacht de methode.
De bestemmingsentiteiten bestaan. Merken, leveranciers, attributen, kenmerken, vervoerders. Een product gekopieerd naar een winkel zonder de overeenkomstige attributen verliest zijn varianten.
De actieve talen komen overeen. Een drietalig product kopiëren naar een eentalige winkel verliest twee vertalingen, en het omgekeerde laat velden leeg.
De belastingregels zijn geconfigureerd. Zonder komen de prijzen aan zonder toepasbare btw.
Een back-up bestaat. Een slecht gekalibreerde kopie van driehonderd producten maakt u niet product per product ongedaan.
Na de kopie
Vijf controles op een steekproef van tien producten.
De afbeeldingen worden weergegeven, met de juiste koppelingen aan de varianten.
De varianten zijn compleet, met hun voorraden en prijsimpacten.
De prijzen zijn correct inclusief belastingen.
De producten verschijnen in de front-office, niet alleen in de back-office.
De interne zoekfunctie vindt ze terug, wat de regeneratie van de index valideert.
Twee bewerkingen om na elke overdracht niet te vergeten: het opnieuw genereren van de miniaturen voor de nieuwe winkel, en dat van de zoekindex. Ze verklaren het merendeel van de situaties waarin producten afwezig lijken terwijl ze wel degelijk zijn aangemaakt.
Het geval van de regelmatige update
Een andere vraag dan de initiële overdracht, en vaak belangrijker op termijn.
Eenmaal de producten gekopieerd, hoe houdt u de samenhang wanneer de bron evolueert?
Drie benaderingen. Het delen in plaats van kopiëren, als de inhoud identiek moet blijven: één product gekoppeld aan beide winkels, één keer gewijzigd. De periodieke synchronisatie op de gekozen velden, typisch prijs en voorraad, terwijl de beschrijvingen mogen uiteenlopen. Of de bewuste onafhankelijkheid, als de catalogi uit elkaar zullen groeien.
De keuze wordt gemaakt op het moment van de kopie, niet erna: terugkeren betekent het werk overdoen.
De module Multistore-duplicatie van een Volledige Categorie voert deze directe kopie uit op PrestaShop 8 en 9: overdracht van de producten met varianten, afbeeldingen en hun koppelingen, posities in de categorieën, aanmaak van ontbrekende entiteiten aan de bestemmingskant en behoud van de identifier-overeenkomsten om de relaties te reconstrueren.