Available-to-promise per kanaal publiceren: maak van voorraad een leverbelofte

Je webshop toont 18 stuks. Het magazijn zegt 12. Een marketplace heeft gisteren nog 7 stuks verkocht en in je ERP staat een inkoopzending van 40 die pas vrijdag wordt gelost. Wie vandaag 18 belooft, verkoopt geen voorraad. Die verkoopt onzekerheid.

Een betrouwbare leverbelofte begint daarom niet bij het getal dat je op een productpagina wilt tonen. Ze begint bij de vraag welk systeem welk feit bezit, welke reservering al telt, welke voorraad in quarantaine staat, hoe vers de bron is en wat er gebeurt als een andere order je snapshot net voor de publicatie verandert.

De productdetails en prijzen in deze gids zijn gecontroleerd op 11 oktober 2026. Waar een documentatiepagina een eigen datum of API-versie noemt, staat die in de tekst.

Available-to-promise (ATP) is de hoeveelheid verkoopbare voorraad die je voor een specifieke SKU, locatie, verkoopkanaal en datum werkelijk kunt beloven. Je berekent haar uit voorraad die bruikbaar is, vermindert die met geldige reserveringen en veiligheidsbuffer, en telt alleen ontvangsten mee die vóór de beloofde datum betrouwbaar binnenkomen. ATP is dus een versieerbare belofte, geen live kopie van een voorraadveld. Microsoft omschrijft ATP als geprojecteerde voorraad die in een komende periode beschikbaar is voor klantorders en future supply en demand meeneemt in de ATP-documentatie voor Dynamics 365.

De rest van deze gids bouwt die belofte op van bronhouder naar kanaalpublicatie. De gids over bronhouderschap per veld en reconciliatie helpt bij het bredere gegevenslandschap. Hier zoom ik in op de voorraadbeslissing zelf.

Wat je nodig hebt voordat je voorraad belooft

Maak eerst de gegevensgrens scherp. Je hoeft niet meteen een nieuw voorraadpakket te kopen. Je hebt wel een vaste definitie, een sleutel en een herstelpad nodig. Zonder die drie automatiseer je vooral het doorgeven van tegenstrijdige getallen.

De minimale bronmatrix

Leg voor elk onderdeel één bronhouder vast. De bronhouder is het systeem of proces dat het feit kan bewijzen. Een webshop mag een order registreren, maar is daarom nog niet de bronhouder van fysieke voorraad.

De combinatie SKU plus locatie is de ondergrens. Voeg een batch, serienummer of voorraadpartij toe als houdbaarheid of kwaliteit per partij verschilt. Een productnaam is geen sleutel. Een SKU zonder locatie is onvoldoende zodra je vanuit meerdere magazijnen levert.

Toegang en testdata

Je hebt leestoegang tot WMS of ERP, order- en reserveringsdata uit je commerceplatform, en schrijfrechten alleen op de publicatielaag. Voor een Shopify-koppeling heb je bijvoorbeeld de GraphQL Admin API met read_inventory nodig om quantity states te lezen. De actuele Shopify-documentatie staat op API-versie 2026-10 latest en onderscheidt onder meer available, committed, reserved, incoming, quality control en safety stock in het object InventoryQuantity. Gebruik die namen als bronvelden, niet als universele formule.

Leg klaar:

• een testwinkel of testadministratie met minstens 20 SKU's;
• één SKU met fysieke voorraad, één met quarantaine en één met verwachte ontvangst;
• een order die reserveert, een order die annuleert en een gedeeltelijke levering;
• een centrale tabel voor snapshots, publicaties, bronversies en uitzonderingen;
• een kanaalregister met publicatiegrens, vervaltijd en prioriteit;
• een medewerker die een uitzondering mag vrijgeven;
• een dashboard dat stale, negatieve en niet-bevestigde waarden zichtbaar maakt.

Gebruik PostgreSQL of Supabase als centrale registratie wanneer je al een eigen datalaag beheert. Gebruik n8n of Make voor triggers, API-aanroepen en meldingen, maar laat de berekening en het formele goedkeuringsrecord niet alleen in de uitvoergeschiedenis van zo'n workflow staan.

Vink dit af voordat je een synchronisatie bouwt. De voorbereiding is klein vergeleken met de schade van een order die op basis van dezelfde 18 stuks naar drie kanalen wordt beloofd.

Concrete stappen: van bronhouder naar gecontroleerde publicatie

De route hieronder heeft acht controlepunten. De vaste regels rekenen de ATP uit. Een workflowtool brengt data heen en weer. Een mens beslist alleen waar het beleid of het bewijs tekortschiet.

1. Definieer de belofte die je werkelijk wilt doen

Schrijf eerst de belofte als een record, niet als een zin in een producttemplate. Minimaal:

sku, locatie, kanaal, aantal, beloofdatum, berekend_op, bronversie, geldig_tot, status

Vandaag leverbaar is een ander product dan levering op 15 oktober. De eerste belofte kijkt naar de huidige sellable stand. De tweede kijkt ook naar geplande ontvangsten, cut-off-tijd, verwerkingscapaciteit en transportbeleid.

Leg per kanaal vast wat het publiek ziet. De eigen webshop mag bijvoorbeeld 1 tot 3, 4 tot 9 of 10 plus tonen. Een marketplace krijgt alleen een getal dat al van een kanaalquota is afgetrokken. Een B2B-portaal kan een datum tonen na akkoord van de orderdesk. De interface is kanaalspecifiek, de onderliggende snapshot heeft één centrale identiteit.

Maak ook een versheidsbeleid. Een webshopwaarde mag bijvoorbeeld vijf minuten leven, een marketplace-feed vijftien minuten en een B2B-export één uur. Dit zijn beleidskeuzes, geen universele normen. Kies de termijn op basis van ordersnelheid en foutkosten. Als je in een piekuur twaalf orders per minuut krijgt, is een uur oude voorraad geen bruikbare belofte.

2. Scheid verkoopbaar, gereserveerd en onbruikbaar

Normaliseer de brondata naar vaste componenten. Begin met:

• sellable_on_hand: fysiek aanwezig en vrijgegeven voor verkoop;
• hard_reserved: orderregels die volgens je beleid al een leverbelofte vormen;
• soft_reserved: tijdelijke winkelmandjes of conceptorders met een vervaltijd;
• quarantine: schade, controle, retour of onbekende staat;
• safety_buffer: beleidsmatige voorraad die je niet verkoopt;
• confirmed_incoming: ontvangst met bron, datum en status.

De simpele huidige formule is:

ATP nu = sellable_on_hand - hard_reserved - soft_reserved - safety_buffer

Voor een latere leverdatum voeg je alleen bevestigde ontvangsten toe die vóór de cut-off vallen:

ATP op datum T = sellable_on_hand + confirmed_incoming vóór T - reservations vóór T - safety_buffer

Let op dubbele aftrek. Shopify heeft meerdere quantity states. Als je available leest en die waarde bevat al de reserveringslogica van je winkel, trek je niet nog eens committed af zonder de betekenis te controleren. De Shopify-handleiding voor de actuele GraphQL Admin API beschrijft een inventory level per item en locatie en laat zien dat je de states afzonderlijk beheert in de stappen voor inventory quantities.

De namen veranderen ook in betekenis. Shopify kondigde op 5 augustus 2026 aan dat actieve conceptorders, transfers en zendingen die eerder onder reserved vielen naar committed kunnen verschuiven. available en on_hand veranderen daardoor niet, maar een rapport dat reserved als enige bron voor alle holds gebruikt, kan wel een deel missen in de changelog over deze migratie. Bouw je formule daarom rond een genormaliseerd contract, niet rond één historische veldnaam.

3. Geef reserveringen een levenscyclus

Een reservering is geen aftrekpost zonder context. Sla type, eigenaar, starttijd, vervaltijd en compensatie op. Ik gebruik voor een praktische start deze indeling:

1. Hard. Een betaalde of commercieel geaccepteerde order die een echte leverbelofte vormt.
2. Zacht. Een winkelmand of conceptorder met een korte lease, bijvoorbeeld 20 minuten.
3. Intern. Een voorraadallocatie voor een project, winkel of B2B-klant met expliciete prioriteit.
4. Geblokkeerd. Een hold door kwaliteitscontrole, retouronderzoek of een afwijkende telling.

De reservering gaat pas uit ATP wanneer haar sleutel geldig is. Bij annuleren of verlopen schrijf je geen nieuw eindgetal over het oude heen. Je maakt een compensatiegebeurtenis en laat de nieuwe snapshot de som opnieuw berekenen. Adobe Commerce gebruikt precies zo'n append-only model: een order maakt een negatieve reservation, annuleren of verzenden maakt compensatie, en de som hoort uiteindelijk op nul uit te komen. De actuele Adobe-documentatie is in augustus 2026 bijgewerkt en beschrijft ook dat onvereffende reserveringen voorraad in stilstand kunnen houden in het overzicht van source algorithms en reservations.

Bij een winkelmand geldt een vervaltijd. Een taak die elk uur verlopen mandjes opruimt is te grof voor een voorraad die snel draait. Laat de reservering verlopen via het systeem dat haar bezit en laat daarna een voorraadgebeurtenis de ATP opnieuw berekenen.

4. Behandel quarantaine en ontvangsten als bewijs, niet als hoop

Quarantaine is geen negatieve voorraad. Het is voorraad die bestaat, maar die je niet mag beloven. Houd haar daarom apart met reden en vrijgavehouder. Na een fysieke telling moet je niet alleen het getal corrigeren. Je moet vastleggen welke voorraadpartij is geteld, wie het verschil heeft beoordeeld en vanaf welke bronversie je opnieuw publiceert. De Shopify-gids over voorraadverschillen na een fysieke telling behandelt die correctie uitgebreider.

Verwachte ontvangsten krijgen een zekerheidsklasse:

• Bevestigd: inkooporder, leverancier en ontvangstvenster staan vast, met een afgesproken cut-off.
• Waarschijnlijk: leverancier heeft toegezegd, maar er is nog geen scan, ASN of dockafspraak.
• Verwacht: forecast of planningsdatum zonder bevestigde ontvangst.

Mijn harde klantbelofte gebruikt alleen de eerste klasse. De tweede mag naar een latere datum met een lagere zekerheid of naar de orderdesk. De derde blijft interne planning. Als je verwachte voorraad toch op de productpagina zet, verwar je een inkoopplan met een leverbelofte.

Leg per ontvangst purchase_order_id, line_id, expected_at, confirmed_at, quantity, source_version en confidence vast. Een ontvangst die op 14 oktober staat maar op 13 oktober nog geen bevestiging heeft, mag niet stilletjes dezelfde belofte houden.

5. Bereken één versieerbare snapshot

Maak de berekening deterministisch en bewaar de invoer. Een snapshot bevat minstens:

{
  "sku": "P-400",
  "location": "ROTTERDAM",
  "channel": "shopify_web",
  "as_of": "2026-10-11T09:00:00+02:00",
  "source_version": "wms-731",
  "sellable_on_hand": 86,
  "hard_reserved": 27,
  "soft_reserved": 6,
  "quarantine": 4,
  "safety_buffer": 10,
  "confirmed_incoming": 40,
  "incoming_at": "2026-10-14T08:00:00+02:00",
  "atp_now": 43,
  "atp_2026_10_15": 83,
  "fresh_until": "2026-10-11T09:05:00+02:00"
}

Bewaar ook de formuleversie, de bronnen en de regels die niet zijn toegepast. Dat laatste is belangrijk. Als je een ontvangst uit klasse expected niet meetelt, moet een medewerker dat kunnen zien.

Gebruik voor de snapshot een oplopende source_version of een inhoudshash. Een tijdstip alleen is niet genoeg. Twee updates kunnen dezelfde seconde delen, terwijl de inhoud wel degelijk verandert.

6. Publiceer per kanaal, nooit vanuit losse schrijvers

Maak een publicatielaag tussen ATP en de kanalen. Daarin geef je een snapshot een publication_id, kanaal, payload, kanaalquota, status en bevestiging. Iedere kanaaladapter leest uit deze laag. Geen Shopify-worker en marketplace-worker trekt zelf nog eens voorraad af van dezelfde bron.

Een simpele allocatieregel is:

publiceerbaar kanaal = minimum(centrale ATP, kanaalquota, kanaalmaximum)

Een quota is geen extra voorraad. Het verdeelt het risico. Als centrale ATP 43 is en je reserveert 35 voor Shopify, 5 voor een marketplace en 3 voor B2B, dan moeten nieuwe orders de bronreservering verhogen. Anders blijft de som van de zichtbare kanaalgetallen 43 terwijl de onderliggende vraag al hoger is.

Voor een eigen webwinkel kun je voorraad tijdens checkout opnieuw reserveren. Voor een marketplace zonder directe reserveeractie publiceer je een strenger getal met een buffer. Voor een winkelafhaalbelofte publiceer je alleen de locatievoorraad die werkelijk aan die winkel is gekoppeld. Verkoop nooit Rotterdamse voorraad als Utrecht als fulfilmentlocatie aan de klant wordt getoond.

De onderliggende platformen werken verschillend. commercetools maakt onderscheid tussen supply channels, waar voorraad ligt, en distribution channels, die onder meer prijsselectie bepalen. De documentatie vermeldt ook dat availableQuantity na order- of cartreserveringen tot ongeveer tien seconden achter kan lopen, terwijl de reservering zelf wel wordt gegarandeerd in het actuele inventory-overzicht. Dat is precies waarom je versheid en bronversie apart van het zichtbare aantal opslaat.

BigCommerce beschrijft zijn Inventory API als asynchroon. Een write geeft een transaction_id en er kan een korte vertraging zitten tussen de write en de gelezen voorraad. De documentatie waarschuwt ook dat de Inventory API niet channel-aware is. Zet dus niet direct hetzelfde absolute voorraadgetal naar een kanaal zonder te weten welke storefronts en locaties het raakt in de Inventory API-documentatie.

7. Blokkeer stale writes met een versiecheck

Dit is de stap die het verschil maakt tussen een dashboard en een belofte. Bij het lezen neem je source_version = wms-731 mee. Vlak voor het schrijven controleer je opnieuw dat de WMS-versie nog 731 is en dat fresh_until niet is verstreken. Is de versie 732, dan schrijf je de oude 43 niet alsnog weg.

Een veilige publicatie doet conceptueel dit:

1. lees brondata en maak snapshot 731;
2. bereken ATP en maak publicatievoorstel;
3. controleer bronversie en versheid opnieuw;
4. schrijf alleen wanneer versie en beleid nog kloppen;
5. lees het kanaalresultaat terug;
6. markeer published of zet de write in de uitzonderingsqueue.

In een eigen publicatietabel kan de laatste stap een voorwaardelijke update zijn:

UPDATE publications SET status = 'published' WHERE publication_id = ... AND source_version = 'wms-731' AND status = 'ready'

Voor een externe API die geen voorwaardelijke write biedt, houd je de check in je eigen laag en behandel je een onzekere response als onbekend. BigCommerce schrijft bijvoorbeeld asynchroon. Shopify en andere platformen kunnen ook hun eigen voorraadstatussen bijwerken. Een time-out is dus geen bewijs dat de write niet is uitgevoerd. Zoek met publication_id of idempotentiesleutel naar het resultaat voordat je opnieuw schrijft.

8. Reconcileer en geef uitzonderingen vrij

Plan twee controles. Een snelle controle loopt vaak genoeg om stale publicaties te detecteren. Een diepere controle vergelijkt alle sleutels, waarden en totalen.

Controleer per combinatie van SKU, locatie en kanaal:

• Telling: hoeveel actieve snapshots, reserveringen en publicaties zijn er?
• Sleutelset: welke order- of ontvangst-ID staat alleen in de bron of alleen in de ATP-laag?
• Waarde: verschillen sellable, reserved, incoming, ATP of publiceerbaar aantal?
• Totaal: sluit de som van kanaalquota aan op de centrale ATP?
• Versheid: ligt published_at binnen de kanaaltermijn?
• Terugleesresultaat: kwam de publicatie overeen met de bevestigde API-response?

Laat de queue minimaal deze redenen onderscheiden: source_stale, negative_atp, reservation_missing, incoming_eta_changed, quarantine_unresolved, channel_write_timeout, source_version_conflict en reconciliation_drift.

De reviewer krijgt de snapshot, bronregels, formuleversie, laatste kanaalresponse en voorgestelde actie te zien. Hij kiest niet alleen tussen groen en rood. Hij moet kunnen besluiten: ontvangst verwijderen, quarantaine vrijgeven, kanaalquota verlagen, reservering herstellen of publicatie opnieuw laten berekenen.

De koppeling kan n8n, Make of maatwerk zijn. De controle moet hetzelfde blijven. OWASP adviseert voor agentische workflows minimale rechten per tool, schema-validatie van externe input en menselijke controle voor risicovolle acties in de actuele AI Agent Security Cheat Sheet. NIST AI RMF 1.0 uit 2023 legt dezelfde ontwerpkeuze breder uit: betrouwbaarheid vraagt testsets, monitoring en menselijke interventie waar een systeem fouten niet zelf kan detecteren of herstellen in de trustworthiness-richtlijnen, gecontroleerd op 11 oktober 2026. Meet dus niet alleen hoeveel writes slagen. Meet ook stale writes, vergeten reserveringen, te late ontvangsten en hoeveel uitzonderingen na menselijke beoordeling terecht waren.

Valkuilen die je leverbelofte breken

Je publiceert fysieke voorraad als beschikbare voorraad

Een telling van 86 stuks zegt niets over 27 orderreserveringen, 6 tijdelijke holds, 4 stuks quarantaine en een buffer van 10. De mitigatie is de genormaliseerde formule met losse componenten. Toon in je beheerlaag altijd de onderliggende aftrekposten.

Je trekt dezelfde reservering twee keer af

Dit gebeurt wanneer je Shopify available leest en daarna committed nog eens als eigen orderlijst optelt. Het gebeurt ook wanneer een WMS al gereserveerde voorraad levert en je OMS-reserveringen opnieuw toevoegt. Mitigatie: documenteer per bron of een veld bruto, netto of afgeleid is en test één order van begin tot eind.

Je telt een verwachte ontvangst mee omdat de datum mooi uitkomt

Een inkooporder is geen ontvangst. Vraag om status, bevestiging en een tijdvenster. Laat onbevestigde ontvangsten alleen interne planning voeden. Als je ze toch als scenario publiceert, label de belofte eerlijk als verwachting en laat haar niet dezelfde groene status krijgen als voorraad die al beschikbaar is.

Elk kanaal schrijft zijn eigen waarheid

Twee workers kunnen tegelijk een absoluut getal schrijven. Bij een asynchrone voorraad-API kan de tweede write ook op een oudere basisstand worden verwerkt. Gebruik één publicatielaag, een oplopende versie en één eigenaar van de mutatie. Zet kanaallimieten in je allocatiebeleid, niet verspreid in vijf scripts.

Je behandelt een time-out als een mislukte write

Blind opnieuw proberen kan dubbel publiceren of twee reserveringen maken. Zoek eerst op idempotentiesleutel, publication-ID en bronversie. Is de uitkomst onbekend, dan gaat het record naar de queue. Een medewerker kan de actuele kanaalstand lezen voordat de nieuwe poging start.

Je laat een oude snapshot lang genoeg leven voor de orderpiek

Een published_at is geen versheidsbewijs. Voeg fresh_until toe en laat de storefront bij een verlopen snapshot terugvallen op een veilige boodschap, zoals controle bij checkout of levering op aanvraag. Geen getal is beter dan een zelfverzekerd oud getal.

Je corrigeert drift door het doel stil te overschrijven

Een verschil tussen WMS en Shopify kan een vertraagde webhook, retour, handmatige correctie of verkeerde SKU-match zijn. Zet de reden eerst vast. De route voor gecontroleerde verkooporder-vrijgave laat hetzelfde principe zien aan de orderkant: uitlezen en voorstellen kan automatisch, een commercieel besluit vereist bewijs en vrijgave.

Beslis-kader: welke ATP-route past bij jouw situatie?

Kies de kleinste route die je belofte aantoonbaar kan dragen. Een native reserveringsmodel is vaak genoeg voor één commerceplatform met één magazijn. Het wordt krap wanneer je voorraad uit een ERP of WMS komt, meerdere verkoopkanalen tegelijk bedient of per kanaal een andere belofte wilt doen.

Kies een native platformroute wanneer

• je één commerceplatform gebruikt;
• voorraad, orders en reserveringen daar al bij elkaar horen;
• je geen toekomstige ontvangsten of complexe kanaalquota hoeft te combineren;
• je kunt leven met de versheid en locatiestructuur van dat platform;
• je reconciliatie vooral controleert of de eigen voorraadstroom intact is.

Shopify, Adobe Commerce en commercetools hebben elk eigen inventory- en reserveringsmodellen. Gebruik die eerst als ze je volledige job afdekken. Bouw er een dunne publicatie- en reconciliatielaag omheen zodra je externe WMS- of ERP-data toevoegt.

Kies een workflowlaag met eigen voorraadregister wanneer

• je Shopify of BigCommerce aan Exact Online, AFAS of een WMS koppelt;
• je drie tot enkele tientallen datastromen hebt;
• je snel wilt starten met n8n of Make;
• de formule en uitzonderingsqueue wel eigen logica vragen;
• je een technische eigenaar hebt die retries, sleutels en logs beheert.

n8n Cloud kost volgens de actuele prijspagina, gecontroleerd op 11 oktober 2026, €20 per maand bij jaarlijkse betaling voor Starter met 2.500 uitvoeringen en €50 voor Pro met 10.000 uitvoeringen. Make rekent in dezelfde controleperiode met credits per moduleactie; het gratis plan heeft 1.000 credits per maand, Core start bij 10.000 credits voor $9 per maand en Pro bij $16. Dat zijn gereedschapskosten, geen prijs voor een betrouwbare ATP-implementatie. De n8n-prijzen en Make-prijzen laten ook zien waarom je transacties, retries en reconciliatieruns vooraf moet tellen.

Kies maatwerk wanneer

• fysieke voorraad, reserveringen en ontvangsten uit meerdere bronhouders komen;
• kanalen verschillende beloftes, buffers of locaties hebben;
• een fout direct leidt tot boete, stilstand of verlies van een belangrijke klant;
• je terugleescontrole, audittrail en menselijke vrijgave verplicht nodig hebt;
• je formule per ordertype, partij, regio of fulfilmentregel verschilt.

Maatwerk betekent niet dat elk scherm zelf gebouwd moet worden. Het betekent dat je de waarheid, versiecheck, publicatiepoort en herstelroute zelf beheert. De commerceplatformen blijven de kanaaladapter; je eigen laag beheert de belofte.

De keuzehulp geeft dezelfde drie uitkomsten als het besliskader. Het belangrijkste criterium is niet hoeveel SKU's je hebt. Het is hoeveel onafhankelijke bronnen, kanalen en gevolgen je moet beheersen.

Uitgewerkt voorbeeld: Shopify, Exact Online en drie kanalen

Neem een fictieve groothandel met Shopify voor de webshop, Exact Online voor inkoop en verkoop, een WMS voor de magazijnstand en n8n voor de gebeurtenissen. De voorraad ligt in Rotterdam. De SKU is P-400.

Om 09:00 uur op 11 oktober 2026 levert het WMS deze stand:

• 90 stuks fysiek aanwezig;
• 4 stuks in kwaliteitscontrole;
• dus 86 stuks verkoopbaar;
• 27 stuks hard gereserveerd voor bevestigde orders;
• 6 stuks zacht gereserveerd in winkelmandjes met een lease van 20 minuten;
• 10 stuks veiligheidsbuffer;
• 40 stuks in een bevestigde ontvangst op 14 oktober om 08:00.

De webshopbelofte voor nu wordt:

86 - 27 - 6 - 10 = 43 stuks ATP

Voor 15 oktober wordt dat, onder dezelfde reserveringsaanname:

86 + 40 - 27 - 6 - 10 = 83 stuks ATP

De publicatielaag verdeelt de huidige 43 als volgt: maximaal 35 voor Shopify, 5 voor de marketplace en 3 voor het B2B-portaal. De kanalen tonen dus niet allemaal 43. De centrale ATP blijft 43, de kanaalquota voorkomen dat één kanaal de hele belofte opeist.

De snapshot wordt wms-731. De Shopify-publicatie is klaar om 09:00:03. Om 09:00:07 reserveert een nieuwe order 12 stuks. Het WMS verhoogt de bronversie naar wms-732. De Shopify-worker probeert toch de waarde 35 te schrijven. De voorwaardelijke controle weigert de publicatie, met reden source_version_conflict.

De n8n-flow doet daarna niet automatisch een tweede write op dezelfde payload. Hij leest de nieuwe stand, berekent ATP opnieuw en vindt:

86 - 39 - 6 - 10 = 31 stuks ATP

De kanaalquota worden nu 25 voor Shopify, 4 voor de marketplace en 2 voor B2B. De oude publicatie blijft in de audittrail staan als superseded, de nieuwe wordt gepubliceerd met bronversie wms-732.

De volgende ochtend schuift de leverancier de ontvangst van 14 naar 16 oktober. Exact Online bevat de nieuwe verwachte datum, maar de ontvangst is nog niet fysiek bevestigd. De reconciliatie markeert incoming_eta_changed. De belofte van 83 voor 15 oktober wordt ingetrokken. De orderdesk kan kiezen tussen 43 direct leverbaar tonen, 31 na de actuele reserveringen tonen, of een latere datum beloven. Wat niet mag, is de oude 83 laten staan omdat die gisteren nog uit de formule kwam.

De dagelijkse controle vindt vervolgens drie dingen:

1. de actieve Shopify-publicatie is 25, precies het nieuwe quota;
2. de som van de drie kanaalquota is 31, gelijk aan de actuele ATP;
3. de ontvangst van 40 staat alleen in de toekomstige planning en niet meer in de belofte voor 15 oktober.

Dit voorbeeld laat zien waar de waarde zit. De formule zelf is eenvoudig. De betrouwbaarheid komt uit bronhouderschap, reserveringslevenscyclus, versiecontrole, versheid en de beslissing wat er gebeurt als de werkelijkheid tussen twee API-calls verandert.

Vergelijkingstabel: native, workflow of maatwerk

De keuze hieronder is gecontroleerd op 11 oktober 2026. De productprijzen zijn publieke instapprijzen en geen implementatieofferte. De tabellen van n8n en Make rekenen ook met verschillende eenheden: uitvoeringen tegenover modulecredits.

Kies native als de belofte binnen één platform blijft. Kies een workflowlaag als de bronmatrix overzichtelijk is en je technische beheer kunt organiseren. Kies maatwerk zodra een oude of verkeerde publicatie geld, voorraad of klantvertrouwen direct raakt.

Een leverbelofte is pas volwassen wanneer je drie vragen op elk moment kunt beantwoorden: welke bron leverde dit getal, welke reserveringen zijn afgetrokken en wat gebeurt er als de bron intussen veranderde? Kun je dat niet aantonen, dan heb je beschikbare voorraad gepubliceerd als zekerheid. Dat is geen ATP. Het is een gok met een productpagina eromheen.