Direct store delivery (DSD)-software laten maken
Bij direct store delivery is de chauffeur vaak ook de verkoper: hij verkoopt uit de voorraad in zijn bus, past aan wat de winkel nodig heeft en factureert ter plekke. Dat maakt de bus een mobiel magazijn met een eigen voorraadadministratie, en een verbinding met kantoor iets waar u niet op mag rekenen.
Waarom van sales andere software vraagt dan bezorgen
Bij direct store delivery gaan goederen rechtstreeks naar het verkooppunt, buiten het distributiecentrum van de retailer om. Binnen dat model bestaan twee werkwijzen die op elkaar lijken. Bij voorverkoop neemt een vertegenwoordiger de order op en rijdt de chauffeur uit wat al verkocht is. Bij van sales is de chauffeur zelf de verkoper: hij bepaalt met de bedrijfsleider wat nodig is, laadt dat uit eigen voorraad en factureert direct.
Die tweede werkwijze draait de software om. De bus is geen transportmiddel maar een magazijnlocatie met een eigen saldo per artikel, en het verkoopdocument ontstaat aan de deur. Aannames die op kantoor vanzelfsprekend zijn vervallen: de prijs komt niet uit een centrale lijst en het factuurnummer niet uit een centrale teller.
Zit uw vraagstuk elders, dan is een andere pagina passender. Levert uw chauffeur alleen vooraf verkochte orders af en is de ontvangstbevestiging het sluitstuk, dan zoekt u een proof of delivery-app. Gaat het om de bredere werkdag met rittenlijst, taken en planning, kijk dan bij de chauffeursapp. Zit het knelpunt in de planning, begin dan bij een transport planning-API.
De bus als voorraadlocatie
Elke wagen heeft een eigen saldo per artikel. Wat op wagen A staat, kan wagen B niet verkopen.
Factuur aan de deur
Prijs en klantafspraak worden op het toestel bepaald en bij de regel vastgelegd.
Twee tegengestelde stromen
Emballage, statiegeld en retouren lopen de andere kant op en worden het vaakst vergeten.
Offline is de normale toestand, geen storing
De chauffeur staat in een laadkuil onder een supermarkt, in een achterstraat of op een terrein waar het net niet wil. Software die een verbinding nodig heeft voor een prijs of een nummer, staat dan stil, en de chauffeur ook. Offline-first is daarom geen noodstand: het toestel is de plek waar de transactie ontstaat.
Dat vraagt een expliciete keuze over wat het toestel zelf mag beslissen. Prijzen en klantafspraken staan lokaal, met de gehanteerde versie vast op de regel. Elk toestel krijgt een eigen factuurnummerreeks; de factuureisen van de Belastingdienst laten meerdere reeksen toe zolang elk nummer uniek en de reeks navolgbaar is. Kredietstops gaan mee bij het laden, want online ophalen werkt precies dan niet wanneer het nodig is.
Bij synchroniseren telt dat een verkoop geen verzoek is maar een feit dat al heeft plaatsgevonden. Bezoeken gaan als gebeurtenissen omhoog, met toestel-id, volgnummer en idempotentiesleutel, zodat een herhaalde upload nooit een tweede factuur oplevert. Stamgegevens lopen de andere kant op en overschrijven het toestel.
De echte conflicten zitten in schaarste, niet in gewijzigde velden. Twee chauffeurs die dezelfde restpartij claimen kan alleen ontstaan als beide toestellen offline uit dezelfde centrale pot afboeken. De oplossing is dat elke wagen een eigen locatie is. Onderling ruilen kan dan alleen tweezijdig: de een boekt uit, de ander bevestigt met een scan, en zolang één kant ontbreekt is de partij voor niemand verkoopbaar. Omslachtiger dan een gedeelde voorraadpot, en de enige variant die offline sluitend blijft.
- Prijzen en klantafspraken lokaal, versie vast op de regel
- Eigen factuurnummerreeks per toestel
- Afboeken tot nul, nooit negatieve wagenvoorraad
- Hervatbare sync per bezoek, niet één upload per dag
- Overdracht tussen wagens alleen tweezijdig bevestigd
- Uitzonderingen naar een werklijst, geen stille correcties
De dagafsluiting is het moment van de waarheid
Aan het eind van de rit moeten drie tellingen op elkaar aansluiten: wat is uitgeladen, wat is volgens de bezoeken verkocht en teruggenomen, en wat komt er fysiek terug. In de pakketwereld heet dat route accounting; SAP kent er een settlement cockpit voor. Belangrijker dan de naam is wanneer een verschil zichtbaar wordt. Komt dat pas de volgende ochtend, dan is de chauffeur weg en gaat de reconstructie over herinneringen.
Verschillen ontstaan zelden door onwil: een mispick bij het laden, breuk, een achtergelaten monster, een variant die qua verpakking nauwelijks van zijn buurartikel verschilt, en vooral verwarring tussen colli en consumenteneenheden. Een krat dat de ene dag als twaalf flessen wordt geteld en de volgende als één krat, levert een onverklaarbaar verschil op.
Een bruikbare afsluiting confronteert daarom bij de inname, per artikel, en dwingt af dat een verschil een categorie krijgt: breuk, retour, weggever of onverklaard. Onverklaarde verschillen verdwijnen nooit helemaal, en een systeem dat doet alsof, wordt omzeild. Wat u wel kunt eisen is dat vrijgeven een vastgelegde handeling is, zodat patronen per route zichtbaar worden. Kasverschil sluit los van voorraadverschil af.
Wat er tegen de verkoopstroom in beweegt
Emballage, statiegeld en retouren
Statiegeld is geen omzet maar een verplichting die heen en terug beweegt en apart op de factuur hoort. Verpact voert het Nederlandse statiegeldsysteem uit en publiceert jaarlijks de tarieven, dus uw software moet een tariefwijziging met ingangsdatum dragen zonder oude bonnen te herschrijven. Kratten, rolcontainers en pallets werken als ruilsysteem: wat vol naar binnen gaat, hoort leeg terug, en het verschil is een lopende rekening per verkooppunt. Voor de vastlegging bestaan GS1-codelijsten voor emballage.
Daarnaast komen niet-verkochte artikelen terug. Verordening (EU) nr. 1169/2011 kent twee markeringen die verschillend uitpakken: tenminste houdbaar tot gaat over kwaliteit, te gebruiken tot over voedselveiligheid. Bij inname legt het systeem per artikel vast wat er gebeurt: terug in verkoopbare voorraad, afgekeurd of afgeschreven. Bij gekoelde producten hangt dat aan temperatuur, en daar schrijft de hygiënecode voor transport, opslag en distributie registratie voor.
Route, tijdvenster en losplek
Winkels hebben leveringsvensters, gedeelde laadkuilen en losplekken achter het pand. Een route die op papier klopt maar het venster mist, kost geen minuten maar een rit: de wagen komt terug met de partij aan boord en het schap blijft leeg. Het venster is dus een harde randvoorwaarde, en wachttijd bij een laadkuil hoort in de rijtijd.
Daar komen voertuiggebonden beperkingen bij. Gemeenten voeren zero-emissiezones voor stadslogistiek in, waardoor niet elke wagen elke klant kan bedienen. Rijdt u met bestelwagens de grens over, houd dan rekening met de tachograafplicht die sinds 1 juli 2026 geldt voor voertuigen boven 2.500 kilo in internationaal vervoer en cabotage; nationaal blijft de grens 3.500 kilo.
De bezoekvolgorde bepaalt bovendien de laadvolgorde: gooit de planner de route om zonder dat de wagen anders geladen wordt, dan staat de eerste partij achterin.
Test je idee eerst — werkend prototype in 1 dag
Met OneDayBuild maken we je idee in één dag tastbaar voor €950, zodat je weet of verdere ontwikkeling de investering waard is. Besluit je door te gaan met de volledige bouw? Dan verrekenen we de kosten volledig.
Bekijk OneDayBuild →Koppelingen, berichten en kaders
Aan de kantoorkant hangt de wagenapp aan uw ERP of magazijnsysteem, waar de wagen een voorraadlocatie is en de uitgifte een boeking. Aan de klantkant werken ketens vaak met GS1-berichten als ORDERS, DESADV met een SSCC per verzendeenheid, RECADV voor wat werkelijk is ontvangen en INVOIC voor de factuur.
Daar zit een spanning die u vooraf oplost. Een verzendbericht vooraf sturen veronderstelt dat de hoeveelheid vaststaat, terwijl bij van sales pas aan de deur blijkt wat de winkel afneemt. Per afnemer kiest u dan een variant: het bericht na het bezoek opbouwen uit de werkelijke afname, of afwijkingen via de ontvangstmelding laten lopen. Dat is een afspraak met uw klant, geen instelling. Voor temperatuur gelden de eisen waarop de NVWA toeziet.
Wanneer een standaardpakket de betere keuze is
DSD is geen onontgonnen terrein. SAP biedt een oplossing voor direct store delivery met route accounting en een settlement cockpit, er zijn van sales-apps die op Microsoft Dynamics 365 aansluiten, en in de drank- en foodservicedistributie bestaan volwassen route accounting-pakketten waarin dagafsluiting, kasstroom en emballage al jaren zijn uitgesleten. Herkent u uw proces daarin, dan koopt u een opgelost probleem.
Maatwerk wordt logisch wanneer uw verkoopmodel afwijkt van wat die pakketten veronderstellen: levering op retourbasis, verkoop per gewicht, of prijsafspraken per winkel die niet in de standaardstructuur passen. En vooral bij de offline-realiteit. Modules die offline invoeren toestaan maar voor prijsbepaling, kredietcontrole of nummertoekenning toch een verbinding nodig hebben, werken op echte routes niet. Test dat vóór de keuze, in een laadkuil en niet in een demo-opstelling.
Wees ook eerlijk over de last van maatwerk. De aantoonbaarheid verschuift naar u: welke versie van de app op welk toestel draaide, hoe de factuurreeksen zijn opgebouwd, hoe de temperatuurregistratie is geborgd. Dat vraagt documentatie, versiebeheer en logging, en beheer hoort bij de keuze omdat uw vloot er elke ochtend op start. Vaak is hybride het verstandigst: het ERP standaard houden en alleen de wagenapp op maat bouwen.
- Uw verkoopmodel wijkt af van standaard voorverkoop of van sales
- Prijsafspraken per winkel passen niet in de standaardstructuur
- Emballage en retouren worden door het pakket niet echt gevolgd
- De bestaande module blijkt offline niet volledig te kunnen afronden
- Een hybride opzet volstaat: standaard ERP, maatwerk op de wagen
Veelgestelde vragen over DSD-software
Een proof of delivery-app legt vast dat een vooraf verkochte order is afgeleverd: scan, handtekening, afwijking, foto. Een chauffeursapp gaat over de werkdag: rittenlijst, taken en contact met de planning. DSD-software voegt daar de verkoop aan toe, met prijsbepaling, wagenvoorraad, facturering en dagafsluiting. Stel eerst vast welk van de drie uw knelpunt is.
Dat is de eis waar het ontwerp op staat of valt. Een laadkuil is vaak een betonnen bak zonder bereik en een chauffeur kan niet wachten op signaal. Het toestel beslist daarom zelf over prijs, voorraad en factuurnummer, en ook de dagafsluiting ontstaat lokaal. Let op het verschil tussen offline invoeren en offline afronden: kan een pakket alleen het eerste, dan loopt u alsnog vast.
Vaak is dat de verstandigste keuze. SAP heeft een DSD-oplossing met route accounting en een settlement cockpit, er zijn van sales-apps op Microsoft Dynamics 365, en in de drankdistributie bestaan volwassen route accounting-pakketten. Bij een gangbaar verkoopmodel koopt u daar een opgelost probleem. Maatwerk wordt pas logisch bij een afwijkend verkoopmodel of een module die offline niet kan afronden.
Door drie tellingen tegen elkaar te zetten: wat is uitgeladen, wat is volgens de bezoeken verkocht en teruggenomen, en wat komt er terug. Toon het verschil bij de inname, per artikel en op verpakkingsniveau. Verschillen verdwijnen nooit volledig; het doel is dat ze een naam krijgen en dat vrijgeven wordt vastgelegd.
Bij maatwerk hoort de broncode in een repository te staan waarvan u zelf eigenaar bent, met de omgevingen en de documentatie erbij. Leg dat vast in de overeenkomst, ook als de samenwerking goed loopt. Belangrijker is of een andere partij het kan overnemen, en dat hangt op leesbare code, actuele documentatie en gangbare technologie.
Dat de aantoonbaarheid bij u ligt in plaats van bij een pakketleverancier. Vervoert u gekoelde producten, dan valt uw proces onder Verordening (EG) nr. 852/2004, ingevuld via de Hygiënecode voor transport, opslag en distributie. Voor facturen gelden de factuureisen van de Belastingdienst, ook als het nummer op een handterminal ontstaat.
Gerelateerde diensten
Proof of delivery-app
Voor ritten waarbij vooraf verkochte orders worden afgeleverd en de ontvangstbevestiging het sluitstuk is.
Chauffeursapp laten maken
De bredere werkdag op één toestel: rittenlijst, taken, documenten en contact met de planning.
Transport planning-API
Routes, tijdvensters en voertuigprofielen koppelen aan uw planningssysteem.
Uw route als uitgangspunt, niet een demo-opstelling
Vertel ons wat er wordt geladen, wat de chauffeur bij de klant mag beslissen en waar de dagafsluiting nu vastloopt. Daarna bepalen we samen of een standaardpakket volstaat of maatwerk op de wagen de betere weg is.