Bouw een app voor voorraadherbestelsuggesties om min/max per SKU op te slaan, bestelhoeveelheden te berekenen en een concept inkooplijst te maken die je team kan reviewen.
Een winkel runnen betekent meestal balanceren tussen twee dure fouten: populaire artikelen zonder voorraad (misgelopen verkoop, gefrustreerde klanten) of te veel inkopen (kapitaal vast in langzaam lopende voorraad). Het dagelijkse probleem is niet "hebben we voorraad?" maar "wat moeten we nu bestellen, en hoeveel?" zonder een uur met spreadsheets bezig te zijn.
Een min/max-opzet maakt die beslissing simpel. Voor elke SKU sla je twee getallen op:
Als een SKU 6 eenheden heeft, de min 10 is en de max 25, is de suggestie om 19 te bestellen. Je raadt niet uit je hoofd; je gebruikt een duidelijke regel die week na week consistent blijft.
Een inventory reorder suggestions app neemt je huidige on-hand aantallen (en optioneel wat al in bestelling is), past die min/max-regels per SKU toe en produceert een concept inkooplijst. Dat concept is de belangrijkste output: een korte, toetsbare lijst die antwoord geeft op "wat moeten we bestellen en hoeveel?" voordat iemand een leveranciersportaal opent of een vertegenwoordiger mailt.
Wat de app niet doet, is automatisch aankopen doen. Dat is belangrijk: echte inkoop kent uitzonderingen: een leverancier is uitverkocht, case packs forceren afronding, een seizoenartikel moet overgeslagen worden of er komt een promo aan. De app moet snel suggesties genereren en vervolgens een mens toestaan regels te bevestigen, bewerken of regels te verwijderen.
Dit soort tool wordt meestal gebruikt door filiaalmanagers, operationele leads en inkoopmedewerkers. Het is ook nuttig voor kleine teams waar één persoon meerdere petten draagt en gewoon een betrouwbaar vertrekpunt nodig heeft.
Goede suggesties beginnen met saaie, consistente SKU-data. Als de basis rommelig is, voelt je conceptinkooplijst willekeurig en verliest men het vertrouwen.
Streef naar een SKU-record dat in de loop van de tijd dezelfde "vorm" behoudt, zelfs als je proces verandert.
Om vanaf dag één bruikbaar te zijn heb je nodig:
Min en max zijn de vangrails. Een apart reorder point is optioneel, maar nuttig als je eerder wilt bijbestellen dan de min vanwege lange levertijden of onbetrouwbare bevoorrading.
Deze details veranderen "hoeveel kopen" in "wat kun je daadwerkelijk bestellen":
Wees expliciet over waar "on hand" vandaan komt. Als je begint met handmatige invoer, sla de datum van de laatste telling op. Als je later synchroniseert met een POS of warehouse tool, sla ook de laatste synctijd op. Die ene detail verklaart veel vragen van het type "waarom stelde het dit voor?"
Min/max is een eenvoudige regel: je bestelt alleen wanneer de voorraad laag is en je bestelt genoeg om terug te gaan naar een veilig niveau. Het resultaat is een conceptlijst die makkelijk te begrijpen en te auditen is.
Kies één trigger en houd die consistent. De meest gebruikelijke is:
Dit voorkomt lawaaierige aanbevelingen voor items die al gezond zijn.
Zodra een item in aanmerking komt, is het basisidee "bestel tot Max." De simpele formule is:
base_suggested = max - on_hand
suggested = max(0, base_suggested)
Voorbeeld: Min = 10, Max = 40, On Hand = 14.
Als On Hand naar 8 daalt:
Na de basisberekening voeg je een paar kleine regels toe om aan te sluiten bij hoe inkoop in de praktijk werkt:
Slechte data levert slechte suggesties op, dus maak deze situaties duidelijk:
De beste flow is degene die je team daadwerkelijk gebruikt. Houd het simpel: registreer wat je hebt en genereer vervolgens suggesties. Extra's (labels, dashboards, analytics) kunnen later.
Een typische sessie ziet er zo uit: de gebruiker doet een snelle telling, kiest een locatie (indien nodig), voert tellingen per SKU in, slaat op en tikt dan op één knop om een conceptbestelling te maken. De inkoper bekijkt dat concept en past het aan voordat iets wordt goedgekeurd.
Om het scherm rustig te houden, voeg één praktische filter toe: toon alleen SKU's onder min, of toon alle SKU's met een duidelijke status. "Alleen onder min" is sneller op drukke dagen. "Alles tonen" helpt wanneer je zekerheid wilt dat niets is gemist.
Een eenvoudige flow die voor de meeste kleine teams werkt:
Overrides zijn belangrijk omdat de realiteit rommelig is. Een inkoper kan extra bestellen voor een promotie of minder omdat het budget krap is of een leverancier vertraagd is. Behandel de voorgestelde hoeveelheid als een vertrekpunt, niet als een regel.
Een paar kleine controls voorkomen veel frustratie:
Sla tenslotte een snapshot op wanneer het concept wordt gegenereerd: timestamp, de gebruikte on-hand tellingen, de min/max waarden op dat moment en de voorgestelde hoeveelheden vóór overrides. Als iemand vraagt "Waarom bestelden we 24 van dit?", kun je het concept openen en de exacte inputs zien die het produceerden.
Een goede reorder-app begint met een klein aantal tabellen waarop je kunt vertrouwen. Het doel is geen perfect ERP, maar een schone basis die kan groeien zodra je leveranciers, locaties of slimmere regels toevoegt.
Voor één winkel, scheid "wat het item is" van "wat je hebt" en "hoe je het herbestelt":
Dit blijft flexibel omdat je reorderregels kunt wijzigen zonder je SKU-lijst te herschrijven, en je conceptorders als een record kunt bewaren van wat werd voorgesteld versus wat werd goedgekeurd.
Als je vandaag maar één winkel hebt, bouw dan niet te veel locaties in. Sla voorraad op als één getal per SKU. Wanneer je een tweede winkel of een magazijn toevoegt, introduceer dan een Locations-tabel en schakel Inventory levels naar één rij per SKU per locatie.
Kleine validatieregels voorkomen dat foute invoer in verkeerde bestellingen verandert. Voeg controles toe zoals: min moet kleiner zijn dan max, reorder points mogen niet negatief zijn en pack size mag niet nul zijn. Bepaal wat er gebeurt als instellingen ontbreken: blokkeer suggesties of markeer SKU's als "needs setup."
Rollen helpen wanneer meerdere mensen voorraad tellen en regels aanpassen:
Plan hoe je orders uitstuurt. Zelfs als je later inkopen automatiseert, beginnen de meeste teams met een eenvoudige export: een CSV-download of een leverancierklare lijst die ze van het conceptorder-scherm kunnen kopiëren.
Begin met twee eenvoudige lijsten: je SKU-catalogus en je leveranciers. Elke SKU moet een naam hebben die mensen herkennen, een standaardleverancier en een inkoopeenheid (stuk, case, karton). Houd het praktisch. Dit is de lijst die je team elke dag zal doorzoeken.
Voeg daarna reorder-instellingen toe aan het SKU-record. Min en max zijn de basis, maar je krijgt betere suggesties als je ook pack size en levertijd opslaat. Als je hetzelfde item bij twee leveranciers koopt, kies er één als standaard en sta wijzigingen toe op het conceptorder later.
Voor voorraadtelling bouw je een snel scherm dat snelheid boven perfectie stelt. Een snelle bewerkgrid werkt goed: filter op gangpad of categorie, typ de getelde hoeveelheid en sla op.
De meeste teams hebben deze kernschermen nodig:
Implementeer daarna de suggestielogica: voor elke SKU vergelijk je "on hand" (en optioneel "on order") met je reorderregels, bereken je een voorgestelde hoeveelheid om terug naar max te gaan en pas je pack size afronding toe zodat je niet 13 eenheden voorstelt als de leverancier alleen cases van 12 verkoopt.
Genereer een conceptorder voor review en behandel het als een document met statussen zoals Draft, Approved, Sent. Wanneer een gebruiker een concept aanmaakt, kopieer dan de suggestieregels naar orderregels gegroepeerd per leverancier en laat mensen hoeveelheden bewerken, leveranciers wisselen of items verwijderen.
Rond af met een duidelijke exportstap. Sommige teams printen het concept en plaatsen bestellingen handmatig. Anderen exporteren een bestand. Hoe dan ook, sla op wat goedgekeurd is zodat je later "voorgesteld vs besteld" kunt vergelijken en je regels met echte data kunt verbeteren.
De rekenkunde voor herbestellen is simpel. Wat het vertrouwen breekt is rommelige setup. De meeste problemen tonen zich als een conceptlijst die "verkeerd" aanvoelt, zelfs wanneer de formule correct is.
Een klassiek probleem is gemengde eenheden. Je telt per stuk, maar bestelt per case, of je ontvangt per pack. Als de eenheid van een SKU onduidelijk is, kan de app 24 voorstellen wanneer je 24 cases bedoelde. Kies één basiseenheid per SKU (vaak "each") en sla een conversie op zoals "1 case = 24 each" zodat de uiteindelijke bestelhoeveelheid correct wordt vertaald.
Min en max worden ook vaak als giswerk ingesteld. Als je verkooptempo en levertijd negeert, zien de regels er netjes uit maar falen ze in de praktijk. Een langzaam lopend product met een hoge max bindt geld, terwijl een snel lopend product met een lage min tekorten veroorzaakt.
Andere veelgemaakte fouten:
Een simpel scenario: je verkoopt koffiecups. Het schap toont 6 dozen, het achtermagazijn heeft 18 en een tweede winkel heeft 12. Als je slechts één "on hand" nummer bijhoudt, telt iemand 6 en suggereert het systeem bestellen, terwijl je in werkelijkheid 36 hebt. Locatievelden lossen dit snel op.
Een min/max-systeem is simpel, maar de conceptlijst is alleen zo goed als de data erachter. Voordat je iets naar een leverancier stuurt, neem even de tijd voor de stille fouten die de suggesties betrouwbaar doen klinken terwijl ze dat niet zijn.
Begin met setup: elke reorderbare SKU heeft een minimum, een maximum (of target) en de juiste pack size nodig. Als er iets ontbreekt, moet de app de SKU markeren en het item overslaan of "needs setup" tonen. Eén leeg veld kan stilletjes een enorme order of geen order opleveren.
Controleer daarna de on-hand hoeveelheden op realisme. Negatieve voorraad komt voor (retouren die laat verwerkt zijn, ontvangst niet geboekt, eenheidverwisselingen), maar het hoort zeldzaam te zijn. Zie je -12 on-hand voor een traag artikel, behandel de suggestie dan als "onderzoek" en niet als direct kopen. Een hertelling of een korte transactiecontrole is goedkoper dan overtollige voorraad later terugdraaien.
Een korte checklist die de meeste problemen vangt:
Verpakkingsregels verdienen speciale aandacht. Als je leverancier in cases van 24 levert en je concept stelt 13 voor, moet je systeem aanpassen op basis van beleid (vaak afronden naar boven om stockouts te vermijden). Toon ook de oorspronkelijke suggestie en de aangepaste suggestie zodat de reviewer begrijpt wat er veranderde.
Bepaal ook wat "goed genoeg" betekent voor je team. Bestellen naar max is agressief en kan geld vastzetten. Een conservatiever target (bijvoorbeeld alleen naar max voor top movers en naar een middenwaarde voor tragere items) kan overvoorraad verminderen terwijl je vertrouwen opbouwt.
Tot slot, houd een audit trail. Zelfs een eenvoudige "Laatst gewijzigd door" en "Laatst gewijzigd op" op elke regel vergroot het vertrouwen en helpt later bij het oplossen van discussies.
Stel je een buurtwinkeltje voor met 30 SKU's. De eigenaar doet elke maandag een fysieke telling en wil een inventory reorder suggestions app die een conceptinkooplijst maakt die snel gecontroleerd kan worden.
Ze kopen bij twee leveranciers: Supplier A (snacks en dranken) en Supplier B (huishoudelijke basisartikelen).
SKU 1: Sparkling Water 12-pack (Supplier A)
On hand: 8 packs. Min: 10. Max: 30. Pack size: 6.
Omdat 8 onder de min (10) zit, suggereert de app aanvullen tot de max.
Nodig om max te bereiken = 30 - 8 = 22 packs.
Afronding naar pack size (6): 22 wordt 24.
Voorgestelde bestelling: 24 packs.
SKU 2: Potato Chips (Supplier A)
On hand: 14 zakken. Min: 12. Max: 36. Pack size: 12.
Omdat 14 boven de min is, is de suggestie 0. Hoewel het niet op max is, is het gezond en hoeft het deze week niet bijgevuld te worden.
SKU 3: Vaatwasmiddel 500 ml (Supplier B)
On hand: 3 flessen. Min: 6. Max: 18. Pack size: 6.
Omdat 3 onder min is, aanvullen tot max.
Nodig om max te bereiken = 18 - 3 = 15 flessen.
Afronding naar pack size (6): 15 wordt 18.
Voorgestelde bestelling: 18 flessen.
De conceptlijst is een vertrekpunt, geen bevel. Deze week heeft de eigenaar minder budget en weet ook dat de verkoop van bruiswater daalt bij regen.
Ze passen Sparkling Water aan van 24 packs naar 18 packs (nog steeds een veelvoud van 6). Chips blijven op 0. Vaatwasmiddel blijft op 18 omdat het een stabiele verkoper is en nu risicovol lijkt.
Die review-en-aanpassing stap is waarom een concept vaak nuttiger is dan automatische orders.
Supplier A
Supplier B
Met slechts 30 SKU's kan deze wekelijkse loop ongeveer 10 minuten duren: tellen, suggesties reviewen, een paar aanpassingen maken en dan de gegroepeerde concepten met elke leverancier delen.
De snelste manier om waarde te halen is smal starten. Kies één winkel (of één locatie) en één leveranciersgroep met een beheersbaar aantal SKU's. Je leert meer van een schone, gecontroleerde conceptlijst dan van proberen elke randvoorwaarde op dag één te dekken.
Bepaal vroeg hoe je on-hand tellingen vastlegt. Handmatige invoer is prima in het begin, zolang het consistent is. Een eenvoudige regel zoals "tellingen worden elke donderdag bijgewerkt vóór bestellen" werkt beter dan een complexe setup die niemand vertrouwt.
Een praktisch uitrolplan:
Zodra de basis werkt, verbeter je de wiskunde langzaam. Twee upgrades betalen zich meestal snel terug: een gemiddelde vraagschatting (zoals "gemiddelde wekelijkse verkoop over de laatste 4 weken") en een beetje veiligheidsvoorraad gebaseerd op levertijd. Als een leverancier 10 dagen nodig heeft, kan het verhogen van het reorder point om een extra week vraag te dekken helpen vertragingen op te vangen.
Stel een ritme in om de regels eerlijk te houden. Wekelijks, review de voorgestelde bestelling en corrigeer duidelijke missers. Maandelijks, stem min/max waarden bij, met focus op top movers en de grootste risico's van overvoorraad.
Als je dit bouwt als een no-code voorraadapp, is AppMaster (appmaster.io) één optie die bij de workflow past: modelleer SKU's en leveranciers in een database, zet de min/max-logica in een visueel proces en genereer een conceptorder dat medewerkers kunnen reviewen en goedkeuren voordat er iets wordt verzonden.
Wat is een min/max herbestelsysteem in eenvoudige woorden?Een min/max-systeem slaat per SKU twee niveaus op: een minimum waaronder je niet wilt zakken en een maximum waarnaar je wilt aanvullen. Wanneer de voorraad op of onder het minimum zakt, stelt de app een bestelhoeveelheid voor om de voorraad weer richting het maximum te brengen.
Wanneer moet de app eigenlijk aanraden om een item te herbestellen?Gebruik één duidelijke regel en houd je daaraan: trigger een voorstel wanneer de on-hand hoeveelheid op of onder de min staat (of je reorder point als je die gebruikt). Als on-hand boven die trigger is, moet de voorgestelde hoeveelheid nul zijn zodat de conceptlijst stil en overzichtelijk blijft.
Hoe bereken je de voorgestelde hoeveelheid?De eenvoudigste berekening is suggested = max(0, max_level - on_hand) nadat het item in aanmerking is gekomen voor herbestelling. Dit houdt de uitkomsten makkelijk uitlegbaar, omdat je gewoon bijvult naar een bekend doel.
Moet ik artikelen die al in bestelling zijn meerekenen in de berekening?Ja — als je “on order” betrouwbaar bijhoudt, trek het dan af van wat je nodig hebt zodat je niet dubbelbestelt. Een gebruikelijke aanpak is beschikbare voorraad als on_hand + on_order te behandelen en de aanvulhoeveelheid van dat getal te berekenen.
Hoe werken case packs en afronding in een herbestelapp?Rond suggesties af naar wat je daadwerkelijk kunt kopen en toon het aangepaste aantal duidelijk. Bijvoorbeeld: als de leverancier cases van 12 verkoopt, moet een berekende behoefte van 32 veranderen in 36 als je beleid is om naar boven af te ronden om uitverkochte situaties te vermijden.
Wat moet er gebeuren als een SKU geen min/max instellingen heeft?Raad nooit en maak geen stille aannames. Als min of max ontbreekt, zet de suggestie op 0 en markeer de SKU als "needs setup" zodat iemand de data kan corrigeren voordat het invloed heeft op aankopen.
Hoe moet de app omgaan met negatieve voorraadtellingen?Behandel negatieve on-hand aantallen als een waarschuwingsbord, niet als normale invoer. Je kunt nog steeds een suggestie berekenen zodat de inkoper risico ziet, maar de UI moet aangeven dat de telling waarschijnlijk een hertelling of transactiereparatie nodig heeft.
Moet ik voorraad per locatie bijhouden (achtermagazijn vs schap, meerdere winkels)?Als je meerdere plaatsen hebt waar voorraad kan liggen, track die dan afzonderlijk; anders zijn je suggesties fout, zelfs met correcte min/max. Splits in elk geval shelf en backroom, en breid later uit naar winkel-per-winkel of magazijnlocaties indien nodig.
Hoe maak ik herbestelsuggesties controleerbaar en betrouwbaar?Sla een snapshot op van de inputs die gebruikt zijn om het concept te genereren, inclusief on-hand waardes, min/max op dat moment en wie bewerkingen goedkeurde. Dit maakt het eenvoudig om te beantwoorden "waarom hebben we dit besteld?" en vergroot het vertrouwen in het systeem.
Kan deze workflow handmatig blijven maar toch tijd besparen, en kan ik dit in AppMaster bouwen?Houd inkoop standaard human-approved: genereer een conceptbestelling, laat iemand hoeveelheden bewerken en markeer het dan goedgekeurd voordat je exporteert of kopieert voor bestellen. Je kunt deze workflow bouwen in AppMaster door SKU's en conceptorders in de database te modelleren en de min/max-logica in een visueel bedrijfsproces te plaatsen dat gegroepeerde conceptorderregels maakt voor review.
21 jan 2026
8 min
20 jan 20268 min
20 jan 20267 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
