IFTMIN opzetten met je vervoerder: 7 stappen

Je PostNL- en DPD-koppelingen draaien op REST-API's met JSON-payloads en webhooks. Fijn, tot je bij een pallet- of FTL-vervoerder komt die nog gewoon met EDIFACT werkt. Dan moet je IFTMIN opzetten voor de transportopdracht en IFTSTA terugkoppelen voor de status, en dat is een ander vak dan een API-key aanvragen. Deze gids loopt het proces stap voor stap door: van trading partner agreement tot pilotrit, met de exacte segmenten die je nodig hebt.

Reden dat dit nog steeds relevant is: bij B2B pallet/distributie en 3PL's in Nederland en België draait de EDI-koppeling meestal nog op de klassieke set berichten. EDI-koppelingen tussen je TMS en je ketenpartners laten orders, statussen (IFTSTA) en facturen (INVOIC) automatisch doorstromen. Concreet gaat het om orders en orderbevestigingen (ORDERS, ORDRSP), de transportopdracht en vrachtbrief (IFTMIN), statusberichten (IFTSTA) en facturen (INVOIC). In de geschiedenis van transportsoftware is dat geen toeval: IFTMIN werd het meest gebruikte EDIFACT-bericht in de logistiek, voor het versturen van zendingsgegevens van verlader naar vervoerder, zoals Cargoson in een overzicht van de TMS-geschiedenis beschrijft.

Wat je nodig hebt voordat je begint

Je hebt vier dingen op orde nodig voordat je één testbericht verstuurt. Zonder deze basis loop je vast op de eerste CONTRL-terugkoppeling.

• Een getekende trading partner agreement met de vervoerder: wie stuurt IFTMIN, wie stuurt IFTSTA, en op welke milestones.
• Vaste EDI-identificaties (GLN of eigen sender/receiver-ID's) voor het UNB-segment van de interchange.
• Een gekozen communicatiekanaal: AS2, SFTP, OFTP2 of een VAN-verbinding.
• Een TMS of EDI-vertaalmodule die D96A-berichten kan opbouwen en parsen, plus een testomgeving bij de vervoerder.

Voor het kanaal: AS2 stuurt EDI direct tussen partners via HTTPS, met encryptie en handtekeningen, wat de meeste grote NL/BE-pallet- en distributievervoerders inmiddels als standaard eisen. SFTP en VAN's komen nog voor bij kleinere of oudere trajecten.

Stap voor stap: IFTMIN opzetten met je vervoerder

Zeven stappen tussen "we willen EDI" en een werkende koppeling die dagelijks transportopdrachten verstuurt.

1. Leg de berichtroutes vast. Bepaal wie sender en wie receiver is in het UNB-segment, en documenteer dit in de trading partner agreement. Bevestig ook de richting van de statusflow: in de meeste opzetten levert de vervoerder of forwarder de IFTSTA-updates aan de verlader, niet omgekeerd.
2. Kies en test het communicatiekanaal. Zet AS2 of SFTP op en verstuur eerst een lege testboodschap. Controleer of je een positieve CONTRL-acknowledgement terugkrijgt; CONTRL-berichtbevestigingen zijn bij veel EDI-netwerken verplicht voordat productieverkeer wordt geaccepteerd.
3. Map je TMS-orderdata naar de IFTMIN-segmenten. Het bericht moet in de header exact het juiste versie-ID meegeven: instructieberichten conform D96A moeten in het UNH-segment, composiet S009, data element 0065 IFTMIN, 0052 D, 0054 96A, 0051 UN bevatten. Daarna vul je BGM (opdrachtnummer en type), DTM (data zoals gewenste laad- en levertijd), NAD (afzender en ontvanger), LOC (laad- en loslocatie) en RFF (referenties zoals PO-nummer of jouw eigen TMS-ID).
4. Voeg colli- en gewichtsgegevens toe. Gebruik PAC voor het aantal pallets of colli en MEA voor gewicht en volume, zodat de vervoerder kan plannen op capaciteit in plaats van te gokken.
5. Stuur een testbericht en controleer de acknowledgement. Een geslaagde test geeft een positieve CONTRL terug binnen de afgesproken tijd (vaak enkele minuten tot een uur, afhankelijk van het kanaal).
6. Vraag IFTSTA-koppeling terug op de afgesproken milestones. IFTSTA rapporteert de transportstatus van een zending op vastgelegde milestones: booked, collected, gated in, loaded, departed, arrived, discharged, delivered. Voor de mapping in je TMS geldt: je hebt minimaal BGM voor de zendingsreferentie en berichtfunctie nodig, DTM voor bericht- en event-datum/tijd, TSR voor transportvereisten, LOC voor de locatie, en de herhalende STS-segmentgroep met de eigenlijke statuscode en reden.
7. Draai een pilot met 5 tot 10 zendingen. Volg elke IFTMIN en de bijbehorende IFTSTA-updates handmatig na, voordat je het volledige volume overzet. Zo vang je mapping-fouten op zonder dat je hele planning ervan afhangt.

Hoe je weet dat de koppeling werkt

Drie signalen dat de IFTMIN/IFTSTA-koppeling productieklaar is: elk verstuurd bericht krijgt een positieve CONTRL terug, de IFTSTA-milestones komen op tijd binnen en matchen de referentie uit je oorspronkelijke IFTMIN, en je planners bellen niet meer naar de vervoerder om te vragen waar een pallet is. Als dat laatste nog gebeurt, ligt de koppeling er wel, maar wordt de data niet gebruikt in het TMS-dashboard. Check dan of de RFF-referentie in de IFTSTA daadwerkelijk 1-op-1 matcht met het RFF-veld dat je in de IFTMIN verstuurde.

Veelvoorkomende storing: statuscodes komen niet overeen

De meest voorkomende fout is niet een verbindingsprobleem, maar een codelijst-mismatch. Vervoerders implementeren D96A niet altijd identiek: de ene vervoerder gebruikt code 6E voor "booked", een andere gebruikt een eigen interne code op dezelfde plek in het STS-segment. Het gevolg is dat je TMS een status binnenkrijgt die het niet herkent, en de zending in je dashboard blijft hangen op de vorige status.

De fix ligt niet in de techniek maar in de afspraak vooraf. Vraag altijd de vervoerder-specifieke implementatiegids en codelijst op vóórdat je livegaat, en test eerst met een beperkte set statuscodes (booked, collected, delivered) voordat je de volledige milestone-set aanzet. Een schriftelijke trading partner agreement die vastlegt welke partij welke milestones stuurt voorkomt dat je na livegang nog discussies voert over wie welk statuscode-schema volgt.

EDI of API: welke koppeling past bij welk type vervoerder

Voor parcel-vervoerders in de e-commerce is de keuze meestal al gemaakt: die draaien op REST-API's. Bij pallet-, FTL- en 3PL-vervoerders ligt dat anders, en daar loont het om per vervoerder te kijken wat het aanbiedt.

Dit sluit aan bij hoe EDI werkt met gestandaardiseerde, vaak batchgewijze berichten en de norm is tussen verladers, vervoerders en platforms, terwijl een API-koppeling realtime en bidirectioneel is. In de praktijk kombineer je dat vaak: parcel-carriers via API, pallet-vervoerders via EDIFACT. TMS-vendors die beide naast elkaar ondersteunen zijn onder meer Cargoson, MercuryGate, Descartes, Transporeon en Alpega — check per vendor wel of IFTMIN/IFTSTA standaard in de module zit of los moet worden bijgebouwd.

Checklist en volgende stap

Kort samengevat: leg de trading partner agreement en berichtroutes vast, kies AS2 of SFTP en test met CONTRL, map je orderdata naar UNH/BGM/DTM/NAD/LOC/RFF/PAC, vraag IFTSTA terug op vaste milestones met BGM/DTM/TSR/LOC/STS, en draai eerst een pilot met een handvol zendingen voordat je live gaat.

Zodra de IFTSTA-data stabiel binnenkomt, is de logische volgende stap om die data te koppelen aan freight audit: elke afwijking tussen de afgesproken milestone-tijden en de werkelijke IFTSTA-timestamps geeft je direct een aanknopingspunt om vrachtprijzen en SLA's te toetsen, zonder dat je planners daar handmatig achteraan moeten.