Een koppeling dieje zelf kuntzien en sturen.
Gastrohome verkoopt keuken- en horeca-apparatuur en koopt in bij één vaste groothandel. Elke nacht moeten voorraad, verwachte leverdatum en op vaste dagen ook de prijzen van ruim vijfduizend producten overeenkomen met wat die leverancier doorgeeft. Zo'n koppeling snel werkend krijgen is het makkelijke deel. Wij vinden het belangrijker dat de eigenaar van de winkel erbij kan: dat ze kan zien wat er vannacht met haar prijzen is gebeurd, dat ze vooraf kan proefdraaien, en dat ze het ding kan stilzetten zonder ons te bellen. Daarom is het een Magento-module geworden en geen script in een mapje op de server.
- Voor
- Gastrohome
- Discipline
- Leverancierkoppeling · Magento 2
- Jaar
- 2026
- duur van de ronde
- 0,6 s
- verzoeken aan Magento
- 0
Een script dat ’s nachts je prijzen aanpast
De koppeling stond in een eigen mapje op de server, met een eigen cronjob en een eigen configuratiebestand. Wat hij precies gedaan had kwam in een logbestand op diezelfde server, en dat zag je alleen als je erheen ging kijken en wist waar je moest zoeken.
De eigenaar zag ’s ochtends dat een artikel duurder was geworden en had geen manier om vast te stellen of de leverancier zijn adviesprijs had opgehoogd of dat iemand er met de hand aan had gezeten. Vooraf zien wat een prijsronde zou gaan doen kon niet. En de koppeling even stilzetten ging via ons.
Om in de winkel te mogen schrijven had het programma een eigen beheerdersaccount met volledige rechten, buiten de rollen om die Magento zelf kent. De inloggegevens van de leverancier stonden leesbaar in een tekstbestand naast de code. Wie dat bestand kon lezen, kon inkopen doen op naam van de winkel.
Het programma liep drie keer langs alle producten: ze ophalen uit de winkel, ze stuk voor stuk bij de leverancier opvragen, en de uitkomst stuk voor stuk terugschrijven. Ruim tienduizend aanroepen aan de winkel en ruim vijfduizend aan de leverancier, elke nacht. Een ronde duurde vijfentwintig tot veertig minuten, met prijzen erbij ruim een uur.
Door de aanroepen te bundelen ging het van tienduizend naar drie, en van vijfentwintig minuten naar vierenvijftig seconden. Daarmee was de snelheid weg als probleem en stond de rest er nog: een los programma, een eigen account, een logbestand dat niemand opendoet.
Zes dingen, en alle zes staan ze op papier
- 01
's Nachts vergelijken
De cronjob haalt voorraad en leverdatum op voor de producten die meelopen, en vergelijkt met de winkel.
- 02
Alleen wijzigen wat wijzigt
Wat gelijk is blijft staan. Alleen echte verschillen worden weggeschreven.
- 03
Prijzen op de ingestelde dag
Prijzen lopen niet elke nacht mee. Op welke dag wel is een instelling.
- 04
Alles in het logboek
Per wijziging: soort, oude waarde, nieuwe waarde, en of hij is doorgevoerd.
- 05
Signalen bovenaan
Mislukte ronde, onbekende artikelen of een prijs die meer dan een kwart afwijkt komen op het overzicht.
- 06
Oud logboek opruimen
Een tweede cronjob ruimt elke nacht op wat ouder is dan de ingestelde bewaartermijn.
Zet het waar de winkelier al inlogt
Wij hadden hier opnieuw een script kunnen neerzetten. Dat is sneller gebouwd en het werkt. Het levert alleen een winkel op waarin de eigenaar afhankelijk is van ons voor de vraag wat er vannacht met haar assortiment gebeurd is. Dat vinden we een slechte ruil, en daarom is het een gewone Magento-module geworden.
Daar zit de rest in besloten. Het menu staat in de beheeromgeving waar ze elke dag al is. De rechten zijn de Magento-rollen die er al waren. De sleutels van de leverancier staan versleuteld in de database. En omdat de koppeling van binnenuit schrijft hoeft ze niet meer aan te bellen.
- 01de producten → scriptlezen, per product
- 02script → de leverancieropvragen, per product
- 03script → de productenschrijven, per product
- 10.050
- aan de winkel
- 5.018
- aan de leverancier
Drie stappen, alle drie per product: lezen uit de winkel, opvragen bij de leverancier, terugschrijven. Elke nacht opnieuw.
- 01module → de productenschrijft, binnen de winkel
- 02module → de leverancier1× voor alle producten
- 0
- aan de winkel
- 1
- aan de leverancier
Eén vraag aan de leverancier voor alle producten tegelijk, en wegschrijven gebeurt binnen de winkel zelf.
onderbroken lijn = per product · doorgetrokken lijn = in één keer
Een extern programma belt per product twee keer aan. Een module die in de winkel zelf zit hoeft dat nul keer.
Veertig minuten tegenover zes tienden van een seconde. Met prijzen erbij is het 24,7 seconden, en daarvan is bijna alles wachten op de leverancier.
In vijf seconden weten of het goed ging
Het overzichtsscherm is bewust geen lijst. Een nachtelijke ronde levert al snel duizend regels op, en die wil je niet doorbladeren. Bovenaan staan alleen de signalen: een mislukte ronde, een koppeling die uitstaat, artikelen die de leverancier niet meer kent, of prijzen die meer dan een kwart afwijken. Is er niets, dan staat er dat er niets is.
Elke wijziging is terug te vinden
Prijzen
Elke prijswijziging met het verschil in euro's en in procenten, groen omhoog en rood omlaag, en of hij echt is doorgevoerd. Op de productpagina staat de prijshistorie van dat ene artikel, zodat de vraag waarom iets duurder is in één klik beantwoord is.
Rondes
Elke synchronisatie blijft staan: wanneer, hoeveel producten, hoeveel wijzigingen en hoe lang het duurde. Vanaf het overzicht klik je door naar de ronde van vannacht, al voorgefilterd.
Instellingen
Bovenaan de schakelaar waarmee de nachtelijke ronde stilstaat terwijl handmatig synchroniseren blijft werken. Daaronder op welke dag prijzen meelopen, en de sleutels van de leverancier, afgeschermd.
Producten erbij
Importeren op artikelnummer of op een van de 221 categorieën van de leverancier. Nieuwe producten komen uitgeschakeld binnen, zodat iemand ze naloopt voor ze in de winkel staan. Wat de leverancier uit zijn assortiment heeft gehaald blijft buiten de deur.
Importgeschiedenis
Een import over duizenden producten gaat naar de wachtrij en wordt in stukken afgewerkt, met een voortgangsbalk. Staat een opdracht langer dan twee minuten stil, dan meldt hij dat de cron waarschijnlijk niet draait.
Wat de winkelier zelf in de hand heeft
Dit is het punt van de hele case. Alles hieronder kan de eigenaar van de winkel zelf, in haar eigen beheeromgeving, zonder ons te bellen en zonder dat er iemand op een server hoeft in te loggen.
Aan en uit
- De nachtelijke ronde stilzetten
- Handmatig synchroniseren blijft dan werken
- Op welke dag prijzen meelopen
- Prijzen meenemen of overslaan in een losse ronde
Eerst kijken
- Proefrun die niets wegschrijft
- Wat er zou wijzigen komt wel in het logboek
- Een paar artikelnummers live opvragen om te testen
Wie meedoet
- Een ja-nee-veld op het product bepaalt of het meeloopt
- Onbekende artikelen per stuk overslaan of op nul zetten
- Welke leverancierscategorieën je mag importeren
- In welke eigen categorie een geïmporteerd product landt
Terugkijken
- Elke ronde met looptijd en resultaat
- Elke wijziging met oude en nieuwe waarde
- Prijshistorie per artikel op de productpagina
- Hoe lang het logboek bewaard blijft
Dezelfde nacht, twee keer
Deze aanpak kost meer bouwtijd dan een script. Dat is de reden dat het vaak een script wordt.
Wij kiezen bij een koppeling standaard voor een module, omdat het alternatief een winkel oplevert die op één punt van zijn bouwer afhankelijk blijft: de vraag wat er eigenlijk gebeurt met de voorraad en de prijzen. Zou Gastrohome morgen met een andere partij verder willen, dan staat alles wat de koppeling doet in hun eigen beheeromgeving en niet in ons hoofd.
De schermafdrukken komen uit de echte beheeromgeving, met de echte producten en de echte bedragen van deze winkel. De genoemde tijden zijn gemeten over de 5.018 producten die met de koppeling meelopen.
Dit koppelen we ook aan jouw leverancier.
Vertel welk systeem er nu 's nachts aan je winkel trekt, en of je kunt nakijken wat het doet. Dat tweede is meestal het antwoord.