Papierloos Transport in deelmarkt TLN Distributie

Papierloos Transport in deelmarkt TLN Distributie Onderzoek naar optimale toepassing en implementatie van TLN standaarden in de deelmarkt TLN Distributie Menno Lambooij, adviseur ICT Lambooy Logistiek Maart 2018 menno@lambooylogistiek.nl

1 Documentinformatie Titel : Papierloos transport in deelmarkt Distributie Subtitel : Onderzoek naar optimale toepassing en implementatie van TLN standaarden in de deelmarkt TLN Distributie In opdracht van : Transport en Logistiek Nederland (Anne-Marie Nelck) Auteur : Menno Lambooij Medewerking van : TLN en vervoerders deelmarkt distributie Versie : 1.3 Datum : Maart 2018 File : Eindrapportage Papierloos TLN distributie v1.3.docx Project : TLN / Deelmarkt Distributie NLIP Project nr. : PTL 01.040 Documentversies: Nr. Datum Status Auteur(s) projectplan Aard van de wijziging 1.0 13-03-2018 Concept Menno Lambooij 1 e versie ter controle 1.1 19-03-2018 Concept Menno Lambooij Concept eindrapport 1.2 20-03-2018 Concept Menno Lambooij Aanpassingen na opmerkingen Anne-Marie Nelck en Wout v.d. Heuvel 1.3 Definitief Menno Lambooij Laatste aanpassingen stuurgroep verwerkt Aan dit project hebben actief meegewerkt in verschillende rollen: Anne-Marie Nelck Transport en Logistiek Nederland Wout van den Heuvel Transport en Logistiek Nederland Bas Koopmanschap - Nextpage Peter de Rooy de Rooy Transport BV Niels Verdel Dobbe Transport Ben Hendriks V&M Management Consulting Bemmel b.v. Ivonne Derksen TLN Consultancy Menno Lambooij Lambooy Logistiek

2 Samenvatting In de logistieke sector is veel te doen rondom het thema data delen. Er is een ontwikkeling gaande naar toenemend gebruik van standaarden. Al in de jaren 60 werd Electronic Data Interchange (EDI) ontwikkeld met als doel het versneld uitwisselen van transportgegevens en bijbehorende documenten. Het gebruik ervan is nooit volledig doorgedrongen. Nieuwe technieken en het ontstaan van nieuwe tools als control towers en platforms zorgen ook voor een toegenomen behoefte aan standaarden. Het bestuur van de deelmarkt TLN Distributie onderkende al in een vroeg stadium de noodzaak van standaarden. Hiervoor is het project Papierloos Transport binnen deze deelmarkt in het leven geroepen. De doelstelling werd als volgt geformuleerd: Het informeren en begeleiden van vervoerders in de deelmarkt TLN Distributie bij de implementatie van de TLN standaarden voor digitale gegevensuitwisseling van de transportopdracht, factuur en vrachtbrief. Als eindresultaat moeten begin 2018 minstens 20 unieke koppelingen op basis van de TLN standaarden gerealiseerd zijn. Uit dit onderzoek is vastgesteld dat de meeste bedrijven positief staan tegenover het gebruik van de standaarden. Tegelijkertijd gaf ook een deel van de TMS leveranciers aan de standaarden op te nemen in hun software. Hier ligt ook een belangrijk deel van het succes. Bij de implementaties is duidelijk geworden, dat de documentatie niet aanmoedigt tot snelle acceptatie van de standaarden. Net als de standaarden zelf is de documentatie erg uitgebreid. Dit is niet de enige reden dat de implementaties langzaam op gang zijn gekomen. TMS leveranciers blijken ook erg afwachtend, hebben het druk en reageren vooral eerst op concrete klantvragen. Grotere bedrijven met eigen ICT kennis blijken wel snel te kunnen schakelen. Qua functionaliteit blijken de TLN standaarden geschikt voor de deelmarkt TLN Distributie. Na een stroeve start lijkt het vliegwiel op gang gekomen te zijn. Wel is een aantal verzoeken tot aanpassing en uitbreiding van de standaard geformuleerd. Deze hebben o.a. te maken met aansluiting op Transfollow, uitbreiding van functionaliteit voor statusberichten, vereenvoudiging van de structuur rond goederenregels en verduidelijking van restricties en locatiecodes. Het bestuur van TLN Distributie kan het succesvolle project vervolg geven door de positieve resultaten goed over te dragen aan de leden, nieuwe pilots aan te jagen en het initiëren van aansluiting met de Stichting Uniforme Transport Code (SUTC) waar de verdere ontwikkeling gecoördineerd gaat worden. Voor de langere termijn dient het bestuur het onderwerp te agenderen om aan te blijven haken op alle ontwikkelingen. Duidelijk is dat best practices ideaal blijken om de vertaling te maken naar concrete aangrijpingspunten voor de leden van de deelmarkt.

3 Inhoudsopgave Samenvatting... 2 1. Inleiding... 4 1.1 Aanleiding... 4 1.2 Doelstelling... 5 1.3 Aanpak project... 5 1.5 Leeswijzer... 6 2. Status en de behoefte tot standaardisering... 7 2.1 Inleiding... 7 2.2 Voorgeschiedenis... 7 2.3 Inventarisatie in de deelmarkt... 7 2.4 Bevindingen in de deelmarkt... 8 2.4.1 Resultaten inventarisatie... 8 2.4.2 Reactie op inzet standaarden... 9 2.4.3 Interfacing in de praktijk... 10 2.5 Conclusies... 10 3. TLN standaarden in gebruik... 12 3.1 Inleiding... 12 3.2 TMS en integratie... 12 3.3 TLN en papierloos transport... 12 3.4 Impulsen voor implementatie... 13 3.5 Vertragende factoren... 14 3.6 Koplopers gaan voor standaarden... 15 3.7 Conclusies... 17 4. Gebruikerservaringen bij implementatie... 19 4.1 Inleiding... 19 4.2 Structuur TLN transportopdracht... 19 4.3 Praktische zaken bij implementatie... 20 4.4 Conclusies... 25 5. Aanbevelingen... 26 5.1 Inleiding... 26 5.2 Aanbevelingen bestuur TLN Distributie... 26 Bijlage A: Overzicht implementaties... 28

4 1. Inleiding 1.1 Aanleiding In de logistieke sector is veel te doen rondom het thema uitwisseling van gegevensstromen. Er is een ontwikkeling waarneembaar naar toenemend gebruik van standaarden. Standaardisatie is niet nieuw. Al in de jaren 60 werd Electronic Data Interchange (EDI) ontwikkeld met als doel het versneld uitwisselen van transportgegevens en bijbehorende documenten. Dit heeft zich verder ontwikkeld tot elektronische uitwisseling o.a. inkooporders, bevestigingen en facturen. In de transportsector is EDI een bekende standaard, maar het gebruik ervan is nooit volledig doorgedrongen tot alle schakels in de wegtransportketens. Papierloos transport Mede dankzij het topsectorenbeleid heeft TLN de standaardisatie in digitale uitwisseling in 2013 nieuw leven ingeblazen met het project papierloos transport. Het doel was om standaarden en datadiensten te ontwikkelen, die alle transportondernemers in staat stelt om vrachtbrieven, facturen en transportopdrachten elektronisch met elkaar uit te wisselen. Niet gericht op een specifieke branche, maar breed toepasbaar voor de gehele sector. TLN stimuleert met dit initiatief ondernemers in het innoveren binnen de keten om nog efficiënter te werken, kosten te besparen en administratieve lasten te verlichten. De standaarden zijn ontwikkeld met afgevaardigden van de sector en TNO. En niet alleen maar berichtstandaarden, want het heeft ook geleid tot een platform waarmee berichten kunnen worden uitgewisseld. De standaard transportopdracht en factuur zijn door TLN zelf opgepakt, de standaard digitale vrachtbrief is in de markt vooral dankzij Transfollow bekend geworden. Uitrol standaarden Onder de impulsen van TLN neemt het aantal implementaties van de standaarden langzaam toe in de branche. Steeds meer TMS leveranciers nemen de standaarden op in hun software. Dit betekent dat vervoerders bij het onderling uitwisselen niet meer afhankelijk zijn van hetzelfde systeem of tijdrovend maatwerk. Niet alleen de transportopdrachten, maar ook de statusberichten tijdens en na uitvoering van het transport kunnen gedeeld worden. Inmiddels zijn ook andere schakels in de logistieke keten bezig om de standaarden op te nemen. Zo wil Synple met hun platform voor slimme vrachtuitwisseling opdrachten aan kunnen bieden volgens de TLN transportopdracht. En partijen zoals ZET Solutions en Transport-info die zorgdragen voor conversie van digitale bestanden hebben de standaarden inmiddels in hun systemen opgenomen. Stichting Uniforme Transport Code Het verder toepassen van de standaarden past ook uitstekend in de activiteiten van de SUTC. De bestuurders van TLN en evofenedex hebben samen met de Topsector Logistiek besloten om de SUTC weer te activeren. De stichting gaat fungeren als een beheers- en expertisecentrum voor standaarden in de logistiek waaronder de standaarden van papierloos transport en het Open Trip Model (OTM).

5 Stimulering gebruik in deelmarkt TLN Distributie Het bestuur van de deelmarkt TLN Distributie onderkende al in een vroeg stadium de noodzaak om meer gebruik te maken van standaarden. Niet alleen om het IT beheer en interne processen van de leden te optimaliseren. Ook de samenwerking tussen de leden kan een stuk efficiënter. Er wordt onderling immers veel uitgewisseld en dat gaat vaak nog op de traditionele manieren per telefoon en e-mail. Ter stimulering van standaardisatie is het project papierloos transport voor deze deelmarkt ontstaan. 1.2 Doelstelling Het project Papierloos Transport binnen de TLN deelmarkt Distributie is dus tot stand gekomen om de standaarden in de elektronische gegevensuitwisseling te promoten uit te rollen. Als doelstelling is geformuleerd: Het informeren en begeleiden van vervoerders in de deelmarkt TLN Distributie bij de implementatie van de TLN standaarden voor digitale gegevensuitwisseling van de transportopdracht, factuur en vrachtbrief. Als eindresultaat moeten begin 2018 minstens 20 unieke koppelingen op basis van de TLN standaarden gerealiseerd zijn. Er is ook nog een aantal afgeleide doelen geformuleerd, te weten: Overtuigen en begeleiden van TMS leveranciers in het ontwikkelen van de TLN standaarden in hun standaard software, zodat hun klanten hier gebruik van kunnen maken. Toetsen of de TLN standaarden werkbaar zijn voor de deelmarkt TLN Distributie. Voorgestelde wijzigingen worden verzameld en ter beoordeling en mogelijke aanpassingen van de standaarden overgedragen aan de SUTC. 1.3 Aanpak project De opzet van het project is verdeeld in een aantal stappen. Deze zijn als volgt bepaald: 1 Promotie en uitleg (veldwerk) Vanaf de start van het project zijn zowel TMS leveranciers als vervoerders benaderd voor uitleg en stimulering om de TLN standaarden toe te passen. Om de drempel van acceptatie enigszins te verlagen zijn vouchers beschikbaar gesteld, die de benodigde inspanningen voor het implementeren (ontwikkeling, project management) deels vergoeden. 2 Implementatiebegeleiding en projectmanagement Bij iedere use case, waarin de TLN standaarden toegepast zijn, is binnen dit project opgetreden als intermediair tussen de betrokken partijen (TMS leverancier, vervoerder en opdrachtgever). De rol van de stuurgroep liep hier uiteen van adviseren en organiseren tot het zorgen dat onverwachte problemen snel en effectief worden opgepakt. Belangrijke taken:

6 Aanspreekpunt voor de implementaties (zowel bij de vervoerders als bij TMS leveranciers); Het opstellen, realiseren en bewaken van de afspraken samen met het aanspreekpunt van de leverancier en overige betrokkenen. Uitvoeren van consultancy diensten m.b.t. het gebruik van de standaarden en inrichting. 3 Analyse en toetsing van de standaarden De specifieke eisen en wensen bij iedere implementatie zijn bij iedere implementatie verzameld en beoordeeld. In een groot deel van de gevallen zijn deze binnen de mogelijkheden van de standaarden opgelost. In enkele gevallen zijn hebben deze verzoeken geleid tot een no-go (geen passende functionaliteit) of een wijzigingsverzoek van de standaarden indien dit een aantoonbare verrijking en breed toepasbaar blijkt te zijn. 4 Rapportage Het onderzoek wordt afgesloten met een eindrapportage met de ervaringen, resultaten en een advies aan het bestuur van de deelmarkt. 1.5 Leeswijzer Na deze inleiding volgt in hoofdstuk 2 een beschrijving van de actuele stand van zaken op het gebied van ICT in deze deelmarkt. Er is bij een representatieve groep onderzoek gedaan naar de mate van automatisering, ICT beheer en de vormen van interfacing. De resultaten komen in dit hoofdstuk aan bod. Hoofdstuk 3 gaat in op de TLN standaarden, de inspanningen van TMS leveranciers om deze in te bouwen en de implementaties hiervan bij koplopers in de markt. In hoofdstuk 4 worden de praktische ervaringen uit de implementaties uitgebreid beschreven. Bovendien komen hier de aangetoonde verbeterpunten van de standaarden aan de orde. Hoofdstuk 5 sluit af met de belangrijkste conclusies en een advies aan het bestuur van TLN Distributie voor de korte, middellange en lange termijn.

7 2. Status en de behoefte tot standaardisering 2.1 Inleiding Er wordt door vervoerders in het algemeen, maar zeker ook in de deelmarkt Distributie, al veel digitaal uitgewisseld met opdrachtgevers. Het gaat dan met name om de ontvangst van transportorders, maar steeds vaker ook meldingen over de uitvoering terug. Dit zijn vooral eigen initiatieven en, in samenwerking met de ICT leverancier, zelf ontwikkelde toepassingen. Om de uitwisseling te vereenvoudigen en beter beheersbaar te maken is het initiatief papierloos transport opgestart: het ontwikkelen van standaarden voor de belangrijkste documentstromen in transport. Binnen de deelmarkt distributie is het toepassen van standaarden een belangrijk aandachtspunt. De stuurgroep Implementatie standaarden in distributie wil ook echt tot implementatie hiervan komen. Hiervoor was een inventarisatie noodzakelijk. Eén van de vragen die in de stuurgroep is gesteld: Voegt de TLN standaard wel iets toe als er al zo veel gebruik wordt gemaakt van digitale uitwisseling? En zeker ook: voldoet de standaard of worden er in de (stads-)distributie specifieke zaken gevraagd, die niet in de standaarden van TLN zijn opgenomen. Besloten is om de inventarisatie uit te voeren bij een representatieve groep uit deze deelmarkt. Verder in dit hoofdstuk worden de belangrijkste bevindingen beschreven. 2.2 Voorgeschiedenis Alvorens het project papierloos voor TLN Distributie is opgestart, zijn al diverse acties opgepakt om de TLN standaarden branchebreed geaccepteerd en geïmplementeerd te krijgen. In het kort een stukje voorgeschiedenis: Een aantal betrokkenen, die destijds aan de ontwikkeling van de standaarden hebben bijgedragen, hebben deze ook geïmplementeerd. Hieronder o.a. Neele Vat Logistics, die de standaard opdracht bij een aantal onderaannemers heeft draaien. De TMS leveranciers Centric en TANS zijn ook vanaf het begin betrokken geweest en hebben de standaarden in hun basisversie opgenomen. Bij diverse vervoerders en andere TMS leveranciers is toelichting gegeven op de mogelijkheden van papierloos transport. Hieruit zijn diverse initiatieven gestart. 2.3 Inventarisatie in de deelmarkt In samenspraak met het projectteam is een uitgebreide inventarisatielijst opgesteld met als doel inzicht te krijgen in de mate van automatisering bij transportbedrijven. In hoofdlijnen zijn de volgende aspecten meegenomen: 1. Algemeen Wat zijn de contactgegevens en de belangrijke kengetallen (aantal orders, vrachtbrieven etc.)?

8 2. Organisatie Is er een IT-afdeling, hoe is deze opgebouwd, welke verantwoordelijkheid ligt intern en wat wordt uitbesteed? 3. Techniek Welke applicaties zijn in gebruik en welke vormen van digitale uitwisseling komen er voor? 4. Proces Welke informatie wordt uitgewisseld (opdrachten, vrachtbrieven, facturen) en op welke wijze wordt dat gedaan? 5. Commerciële invloeden Welke informatie wordt gevraagd door klanten? 6. Financieel Wat zijn de jaarlijkse uitgaven voor IT en is er een budget? In de stuurgroep is de lijst met leden van de deelmarkt TLN distributie doorgenomen. Op basis van bestaande contacten bij de bedrijven en een globale classificatie (op basis van grootte, automatiseringsgraad en mogelijk daarmee een interessante partij voor gebruik van standaarden) zijn de namen van de te bezoeken bedrijven opgesteld. Deelnemende bedrijven waren o.a.: Ploeger, Dobbe, Rotra, Peeters, BrinkXL, Noordendorp, Bakker&Schilder, Veenstra Fritom, HaCas, van Caem Transporten en Martin Slangen. De inventarisatielijst is ter voorbereiding op het bezoek naar de contactpersoon van het betreffende bedrijf opgestuurd. Tijdens de afspraak is de vragenlijst doorgenomen, zijn de vragen toegelicht en zijn er vanuit de bedrijven voorbeelden aangedragen. De resultaten zijn uiteindelijk in een totaaloverzicht verzameld. 2.4 Bevindingen in de deelmarkt Het afnemen van de vragenlijst ten behoeve van de ICT inventarisatie is over het algemeen bijzonder positief ontvangen door de vervoerders. Een aantal keren is zelfs geopperd, dat het bespreken en uitzoeken van de vragen tot meer inzicht heeft geleid. Bijvoorbeeld: De meeste bedrijven konden doorgaans niet direct aangeven welk deel van de orders inmiddels digitaal ontvangen wordt. Een klein onderzoek hiernaar leverde in een aantal gevallen verrassende inzichten op. In het vervolg een overzicht van de belangrijkste bevindingen. 2.4.1 Resultaten inventarisatie In totaal zijn 13 bedrijven ondervraagd. Deze bedrijven vallen qua omvang in de categorieën middelgroot (van 50 tot 150 voertuigen) tot groot (> 150 voertuigen). In het algemeen konden de volgende zaken geconcludeerd worden: Het belang van ICT wordt steeds groter voor transportbedrijven. De grote bedrijven hebben een eigen ICT-afdeling met één of enkele applicatiebeheerders, technische beheerders en soms zelfs ontwikkelaars. In de categorie middelgroot zijn er nog voldoende bedrijven zonder ICT mensen in dienst. De verantwoordelijkheid ligt vaak wel bij een medewerker (niet dedicated), dus hier is zeker nog sprake van een grote afhankelijkheid bij de leverancier. Het technisch beheer (onderhoud hardware en netwerk) wordt het meest uitbesteed.

9 Alle bedrijven zijn inmiddels voorzien van een Transport Management Systeem (TMS), boordcomputers, Warehouse Management Systeem (WMS), software voor digitalisatie van documenten (scanning) en verloning. Een CRM applicatie en een personeelsinformatie systeem zijn minder vertegenwoordigd. Er wordt meer gebruik gemaakt van toepassingen in de cloud. Er wordt steeds meer gebruik gemaakt van standaard software ten opzichte van maatwerk applicaties. Opvallend was dat het TMS Transpas Enterprise van Art Systems het meest gebruikt werd binnen de deelmarkt TLN distributie. Deze leverancier had nog geen actie ondernomen om de TLN standaarden in hun systeem op te nemen. De gebruikte systemen zijn in de meeste gevallen ook aan elkaar gekoppeld middels interfaces, in ieder geval tussen het TMS en boordcomputers, het TMS en het financieel pakket (boekhouding). De meeste bedrijven hebben ook een webportal als verlengstuk van hun interne automatisering. Enerzijds wordt dit gebruikt voor invoer van opdrachten, maar in de meeste gevallen ook voor het beschikbaar stellen van statusinformatie (ETA s en realisatie) en documenten (getekende vrachtbrieven, POD s). Er wordt binnen de deelmarkt distributie ook veel samengewerkt tussen de vervoerders onderling. Standaardisering in uitwisseling tussen de verschillende TMS systemen moet dus voordelen opleveren. Bedrijven geven jaarlijks meer uit aan ICT. Bedragen liepen hier uiteen van 20/25k tot enkele tonnen op jaarbasis. Belangrijkste kostenposten zijn de jaarlijkse onderhoudskosten (15-20% van de licentiekosten) en externe inhuur (leveranciers). 2.4.2 Reactie op inzet standaarden Het onderwerp standaarden is heel actueel. Dat bleek uit de meeste reacties. Vrijwel iedereen staat positief tegenover het gebruik van standaarden. Het zijn de voor de hand liggende voordelen, die veelal genoemd worden: 1. Snelle implementatie 2. Geen aanpassingen/maatwerk benodigd 3. Minder afhankelijkheid van de leverancier 4. Makkelijker beheer Uit de inventarisatie is in ieder geval gebleken, dat de bedrijven al veel ervaring hebben in het inlezen van digitale transportorders. Op het gebied van facturen wordt vaker nog voor de oude manier van versturen gekozen (soms nog papier, maar steeds vaker als PDF per mail). De echte digitale factuur moet z n echte entree nog doen. Veel koppelingen met klanten zijn niet zonder slag of stoot tot stand gekomen. Een dergelijk proces verloopt doorgaans moeizaam vanwege afstemming met de opdrachtgever en de eigen ICT leverancier. Bovendien is de ervaring, dat een dergelijke koppeling na het nodige testwerk ook niet gelijk goed werkt. Dit veroorzaakt zeker wat scepsis omtrent de realiseerbaarheid van één uniforme standaard.

10 2.4.3 Interfacing in de praktijk Bij een transportonderneming met gemiddelde omvang komen al snel één of meerdere backoffice koppelingen om de hoek kijken. Klanten moeten natuurlijk de mogelijkheid hebben om orders digitaal aan te bieden, de gegevens online kunnen inzien of vrachtdocumenten en facturen kunnen opvragen. De methodieken om te koppelen worden steeds slimmer en beter; van ascii, txt, csv files naar xml overdracht en tegenwoordig hebben de meeste leveranciers al de mogelijkheid om op basis van web services te koppelen. Zoals hiervoor al beschreven, wordt bij de ondervraagde transportbedrijven al op grote schaal gebruik gemaakt van digitaal inlezen van transportorders. De belangrijkste bevindingen uit de inventarisatie zijn: Bij de middelgrote bedrijven wordt ongeveer 50% van de orders ingelezen; de overige 50% wordt nog handmatig ingevoerd. Bij de grotere bedrijven ligt het percentage digitaal ingelezen orders op minimaal 85%. Er is bij ieder bedrijf een grote variëteit aan bestandsformaten, die worden ingelezen: weborders, maar ook directe orders uit het systeem van de klant in txt, csv of xml formaten. Daarnaast worden Excel documenten (veelal vaste templates) ingelezen, die door klanten worden geëxporteerd of handmatig gevuld worden. De meeste bedrijven hebben voor iedere klant een eigen importdefinitie gemaakt of laten bouwen. Zo waren er bedrijven bij met minimaal 50 verschillende importdefinities. Slechts een klein deel van de beschikbare definities wordt voor meerdere klanten gebruikt. Deze moeten allemaal beheerd worden. De middelgrote bedrijven laten de importdefinities veelal door de TMS leverancier maken. De gemiddelde ontwikkeltijd is 1 tot 2 dagen. De grote bedrijven kunnen zelf ontwikkelen of hebben eigen EDI/file converters om de klantenfiles om te zetten naar een leesbaar format of een eigen standaard. 2.5 Conclusies Vastgesteld is, dat de meeste distributiebedrijven positief staan tegenover het gebruik van de standaarden. Tegelijkertijd heeft ook een groot deel van de TMS leveranciers aangegeven deze standaarden op te nemen en te ontwikkelen. Tijdens de inventarisatie werd duidelijk dat de meeste bedrijven het intern al redelijk goed geregeld hebben. De meeste orders worden digitaal ontvangen en vanuit de eigen boordcomputers worden statusmeldingen ontvangen, die uiteindelijk via een webportal ook zichtbaar zijn voor de klant. Kijkend naar de koppelingen met klanten wordt de situatie in de meeste gevallen al een stuk complexer. Vervoerders stellen zich dienstbaar op en conformeren zich veelal aan de bestandsformaten die opdrachtgevers aan kunnen leveren. Dit zorgt ervoor dat iedere koppeling specifiek wordt met extra werkzaamheden en lastiger beheer tot gevolg. Indien men een ondervervoerder (charter) inschakelt, is de informatievoorziening vaak ook minder. Orders worden in de meeste gevallen per e-mail verstuurd en automatische terugmelding is vaak niet aanwezig. Er blijkt dus een duidelijke behoefte aan een gestandaardiseerde manier van onderlinge opdrachtuitwisseling en

11 terugkoppeling van statusmeldingen. De sleutel van succes ligt ook bij de TMS leveranciers. Indien zij de standaarden opnemen in hun applicatie kunnen vervoerders hier ten alle tijden gebruik van maken. Uitwisseling tussen vervoerders kan dan laagdrempelig en onafhankelijk van het gebruikte TMS systeem opgezet worden.

12 3. TLN standaarden in gebruik 3.1 Inleiding Zoals in het vorige hoofdstuk al duidelijk werd, is er veel steun in de branche voor het standaardiseren van de belangrijkste documentstromen. Ondanks deze interesse blijven de meeste vervoerders kiezen voor klantspecifieke koppelingen. Hoe de TMS leveranciers hier tegenaan kijken en welke ervaringen worden opgedaan bij het implementeren van de TLN standaarden komt in dit hoofdstuk aan bod. 3.2 TMS en integratie Architecturen en technologieën volgen elkaar in een steeds sneller tempo op. Daarnaast is de behoefte aan integratie is met de opkomst van cloud, Internet of Things, mobile en Big Data alleen maar groter geworden. Integratie binnen TMS systemen begint vaak met een eerste eenvoudige koppeling die prima door de ontwikkelaars kan worden geschreven in de originele software. Dit kan initieel eenvoudig gerealiseerd worden, omdat er in dit stadium nog niet uitgebreid is nagedacht over de niet functionele eisen. Veiligheid, schaalbaarheid, testbaarheid, flexibiliteit, beschikbaarheid, ontkoppeling en beheersbaarheid zijn vaak nog niet aan de orde in dit stadium. Vaak worden deze pas meegenomen als er iets misgaat. Dan vergt het aanzienlijk veel programmeer energie om dit alsnog in de software voor elkaar te krijgen. De complexiteit van de koppelingen heeft dus de neiging toe te nemen. Daarnaast is het nog vrij eenvoudig wanneer men start met de eerste koppeling. Er is overzicht en gewenste aanpassingen zijn snel aan te brengen. Het wordt moeilijker indien er meerdere interfaces gerealiseerd moeten worden en daarmee het overzicht een stuk minder wordt. Er zijn bedrijven die al tientallen interfaces hebben draaien en moeten beheren. Het is dus duidelijk: hoe minder interfaces, hoe beter. Gebruik van standaarden dus. 3.3 TLN en papierloos transport In 2013 is TLN gestart met het project papierloos transport, dat is voortgekomen uit het Topsectorenbeleid. Het doel was om standaarden en datadiensten te ontwikkelen, die alle transportondernemers in staat stelt om vrachtbrieven, facturen en transportopdrachten elektronisch met elkaar uit te wisselen. TLN stimuleert met dit initiatief ondernemers in het innoveren binnen de keten om nog efficiënter te werken, kosten te besparen en administratieve lasten te verlichten. TLN heeft de standaarden ontwikkeld met afgevaardigden van de sector en TNO. Het heeft geleid tot berichtstandaarden en een platform waarmee berichten kunnen worden uitgewisseld.

13 Afbeelding 3.1: Onderdelen TLN Papierloos transport De standaarden van Papierloos Transport zijn hierboven afgebeeld, te weten: de transportopdracht, de factuur en de digitale vrachtbrief (Transfollow). 3.4 Impulsen voor implementatie In het project Papierloos Transport binnen de deelmarkt TLN Distributie is de stuurgroep in 2017 en begin 2018 actief bezig geweest met het promoten en verder uitrollen van de standaarden. Daarbij zijn de volgende activiteiten uitgevoerd: Uitgebreid contact met de belangrijkste TMS leveranciers, zodat zij de standaarden in hun basisversie van het TMS opnemen. Deze inspanningen hebben opgeleverd dat de TLN standaarden zijn toegevoegd in de software van de volgende leveranciers: o Art Systems Groningen (TMS: Transpas Enterprise) o Centric Gouda (TMS: Plan&Go) o Rainbow Solutions Geldermalsen (TMS: Navitrans) o TANS Eindhoven (TMS: TALIS) Opzetten van use cases bij vervoerders om de koppelingen op basis van de standaarden in werking te krijgen. Er wordt een overzicht bijgehouden van de lopende implementaties. Op dit moment zijn er 32 specifieke koppelingen in behandeling of reeds gereed gemeld. Promotie en toelichting over de mogelijkheden van de standaarden bij vervoerders. Het contact hierover komt vooral tot stand dankzij: o Lopende use cases. De meeste bedrijven die reeds bezig zijn met de implementatie van de standaarden willen het aantal koppelingen uitbreiden. o TMS leveranciers. De TMS leveranciers die de standaarden hebben toegevoegd, promoten het gebruik hiervan bij hun klanten.

14 o Promotie via andere kanalen. Er ontstaat meer vraag naar toepassing van de standaarden door o.a. publicaties in de vakbladen en aandacht voor andere standaarden zoals Transfollow en het OpenTrip Model (OTM). Werken aan aansluiting met andere standaarden en platforms. Er zijn gesprekken gevoerd om de aansluiting tussen Transfollow en de standaard transportopdracht te verbeteren. Verder heeft ook Synple, initiatiefnemer van het platform voor slimme vrachtuitwisseling, een mogelijkheid ingebouwd om de standaard transportopdracht te gebruiken. 3.5 Vertragende factoren De ontwikkeling van de standaarden in de basissoftware bij TMS leveranciers is zeker niet sneller verlopen dan verwacht. De belangrijkste redenen voor de langere ontwikkeltijd zijn: 1. Uitgebreide definitie en branche-breed opgezet De standaarden zijn uitgebreider dan de gemiddelde maatwerkkoppeling die men doorgaans maakt. Dit komt vooral omdat de standaarden ontwikkeld zijn voor branche-brede toepassing, dus niet alleen specifiek voor distributie maar bijvoorbeeld ook voor internationale groepage of containervervoer. 2. Verschillen in opbouw en structuur TMS-en In grote lijnen is de structuur en opbouw van de meeste Transport Management Systemen gelijk. Dat betekent niet zondermeer, dat de implementatie van de standaarden voor iedere leverancier hetzelfde of even makkelijk is. Op detailniveau zit er wel degelijk verschil in de wijze waarop TMS systemen met belangrijke onderdelen als dossier, zending, rit, trajecten en goederenregels omgaan. Het ene pakket laat bovendien meer ruimte tot eigen interpretatie dan andere pakketten. Zelfs in situaties waarbij vervoerders hebben gekozen voor standaard software is er altijd wel iets van maatwerk te vinden. Dit maakt vrijwel iedere implementatie van een standaard interface tot een uitdaging. 3. Pas actie na concrete klantvraag Veel leveranciers komen pas in actie als er een concrete klantvraag ligt. Met andere woorden: zo lang klanten (lees: vervoerders) niet vragen om een koppeling op basis van de standaard, wordt er vanuit de leverancier weinig tot geen actie ondernomen. 4. Overvolle ontwikkelagenda s De economie zit in de lift en meer vervoerders durven weer te investeren, zeker ook op ICT gebied. Dit betekent dat de meeste ICT leveranciers aan hun maximale capaciteit zitten en de ontwikkelagenda s voor de komende tijd overvol zitten. Dit staat de ontwikkeling op het gebied van de standaarden ook zeker in de weg.

15 5. Interfacing is verdienmodel Sommige leveranciers moeten nog overtuigd worden. Nog altijd is het bouwen van klant specifieke interfaces een belangrijk verdienmodel voor ICT leveranciers. Sommigen zijn (nog) huiverig voor het inbouwen van standaarden, waardoor ze in hun ogen een deel van de verwachte omzet verloren zien gaan. Enkele leveranciers die de standaarden al wel hebben ingebouwd, waaronder TANS en Centric, blijven voorzichtig in het aanbieden van een voorstel voor implementatie van de TLN standaard. Vervoerders zien nog te weinig financieel voordeel ten opzichte het bouwen van een klantspecifieke koppeling. Reden is dat vervoerders mogelijk voor een vrije inrichting van hun TMS hebben gekozen, waardoor er alsnog aanpassingen nodig zijn om de standaarden te gaan gebruiken. 6. Klantbinding dankzij maatwerk Niet alleen ICT leveranciers moeten overtuigd worden. Ook een aantal vervoerders gelooft niet direct in toepassing van standaarden. Zij zien het bouwen van specifieke interfaces met klanten als een toegevoegde waarde. Sommigen zijn ook bang voor de minder hechte binding met opdrachtgevers. Theoretisch zou de opdrachtgever met een standaard koppeling sneller in staat moeten zijn om te wisselen van vervoerder. Het is een aanneembaar argument, maar tevens ook een korte termijn visie. 7. Verladers moeilijk te overtuigen De mate van acceptatie bij vervoerders en ICT leveranciers wordt beïnvloed door de moeilijkheid om verladers te overtuigen. Het helpt wel dat partijen, die zorgen voor conversies van digitale bestanden in de uitwisseling tussen verlader en vervoerder, ook kiezen om de standaarden in te bouwen. Een voorbeeld hiervan is Transport-info B.V. 3.6 Koplopers gaan voor standaarden Gedurende de projectperiode hebben diverse vervoerders voor implementatie van de TLN standaarden gekozen. Hieronder een aantal voorbeelden met daarbij een korte reactie op de implementatie. Voor een compleet overzicht, zie bijlage A. Vervoerder: Implementatie van: Toelichting: HaCas Transport (Gilze) Transportopdracht (TMS: Transpas Enterprise) Koppeling tot stand gebracht met collegavervoerders Claassen Logistics en Versteijnen Logistics (Tilburg). Koppelingen werken beide kanten. HaCas Transport is voorstander van de TLN standaarden en is voornemens het aantal verbindingen op basis van deze specificatie verder uit te breiden. Versteijnen Logistics (Tilburg) Transportopdracht (TMS: Plan&Go) Dankzij HaCas is Versteijnen aan de slag gegaan met de standaard transportopdracht. Hierbij is men bijgestaan door leverancier Centric. Zij zijn al vanaf de ontwikkeling van de standaarden bij Papierloos Transport betrokken.

16 Claassen Logistics (Tilburg) Transportopdracht (TMS: RGB+) Vergelijkbaar met Versteijnen Logistics. Claassen heeft met behulp van een eigen mapping tool de TLN standaard in gebruik kunnen nemen. Ze gaan ervan uit dat ze de TLN standaard nog met meerdere bedrijven kunnen gaan gebruiken. Bakker & Schilder ( t Zand) Transportopdracht (TMS: Navitrans) Bakker & Schilder heeft de TLN standaard in eigen beheer in Navitrans toegevoegd. Ze willen deze specificatie voor 5 collega-vervoerders in gaan zetten. De connectie met Sanders Fritom is gereed; bij de andere vervoerders (DGO, Houtman, Dobbe en Van Dooren) wordt nog aan de koppeling gewerkt. Van Dooren Transport (Hillegom) Factuur (TMS: Transpas Enterprise) Van Dooren heeft de TLN standaard factuur laten bouwen door leverancier Art Systems. Voor 1 opdrachtgever is deze inmiddels in gebruik. Meerdere klanten volgen. Art Systems heeft de definitie gelijk met de transportopdracht in hun TMS ingebouwd. Voor alle TMS gebruikers komen de standaarden in de nieuwste release beschikbaar. Naast de factuur wordt inmiddels ook gewerkt aan de koppeling met Bakker & Schilder (opdrachten). Sanders Fritom (Uden) Transportopdracht (TMS: Transpas Enterprise) De Fritom Groep heeft een eigen standaard ontwikkeld voor uitwisseling van digitale informatie, zoals transportorders, status emballage. Ze hebben echter aangegeven ook de TLN standaarden te willen hanteren. Om die reden is de definitie bij Sanders in gebruik genomen. Ook de andere Fritom bedrijven, waaronder Veenstra Fritom wil de TLN standaard in gaan zetten. Post & Zonen B.V. (Pijnacker) Transportopdracht en factuur (TMS: ixolution) Post & Zonen B.V. is actief in meerdere segmenten waaronder vervoer van bouwmaterialen en (zee-)containers. In beide segmenten heeft men de transportopdracht inmiddels draaien. In het containervervoer was Post zelfs de eerste. Ook heeft men inmiddels een pilot gedaan met Transfollow. Post & Zonen is met al deze inspanningen zeker een van de ambassadeurs van Papierloos Transport. Wessels Transport (Rijssen) Transportopdracht (TMS: Transpas Enterprise) Wessels Transport in Rijssen heeft in samenwerking met TMS leverancier Art Systems de transportopdracht ontwikkeld voor opdrachtgever Volker Wessels. De transportopdracht is voor deze opdrachtgever in gebruik in samenwerking met E. Lafeber

17 Transport. Mooie aan deze koppeling is dat ook de terugmeldingen (status) geïmplementeerd zijn. E. Lafeber Int. Transporten (Hillegom) Transportopdracht (TMS: TALIS) Zie hiervoor ook de omschrijving bij Wessels Rijssen. E. Lafeber kan de transportopdracht lezen en statusberichten retour sturen. Verder heeft E. Lafeber inmiddels ook een volledige integratie met Transfollow gerealiseerd. Pultrum Rijssen B.V. (Rijssen) Transportopdracht (TMS: Transpas Enterprise) Pultrum heeft voor opdrachtgever Outdoor Life Group Nederland de regie over alle transporten in België en Nederland. Hiervoor is een samenwerking met meerdere collegavervoerders aangegaan. Met 5 vervoerders is inmiddels een koppeling gerealiseerd op basis van de TLN standaard. Daarnaast draait de standaard voor zeker 3 opdrachtgevers in testfase. 3.7 Conclusies De doelstelling was om minimaal 20 koppelingen op basis van de TLN standaarden te realiseren voor de einddatum van het project. Begin 2018 staat het aantal op 27 succesvolle implementaties. Nr. Onderdeel papierloos Afzender TMS afzender Ontvanger TMS ontvanger 1 Transportopdracht HaCas Art Systems (Transpas) Claassen RGB+ 2 Transportopdracht Claassen RGB+ HaCas Art Systems (Transpas) 3 Transportopdracht HaCas Art Systems (Transpas) Versteijnen Centric (Plan&Go) 4 Transportopdracht Versteijnen Centric (Plan&Go) HaCas Art Systems (Transpas) 7 Factuur Post Pijnacker Ixolution ADB Cool Eigen ERP 8 Transportopdracht Steinweg ERP verlader Post Pijnacker Ixolution 9 Transportopdracht BMN ERP verlader Post Pijnacker Ixolution 14 Factuur Van Dooren Art Systems (Transpas) Warmerdam Spoelbedrijf Fin. systeem 15 Transportopdracht Wessels Art Systems (Transpas) Lafeber TANS (Talis) 18 Transportopdracht Bakker & Schilder Rainbow (Navitrans) Sanders Fritom Art Systems (Transpas) 21 Transportopdracht Bakker & Schilder Rainbow (Navitrans) Van Dooren Art Systems (Transpas) 27 Transportopdracht Pultrum Art Systems (Transpas) Melis Art Systems (Transpas) 28 Transportopdracht Outdoor Life Group NederlArt Systems (Transpas) Pultrum Rijssen Art Systems (Transpas) 29 Transportopdracht Outdoor Life Group NederlArt Systems (Transpas) Addink Zutphen MendriX TMS 30 Transportopdracht Outdoor Life Group NederlArt Systems (Transpas) Swijnenburg Werkendam MendriX TMS 31 Transportopdracht Outdoor Life Group NederlArt Systems (Transpas) LCW Groningen Art Systems (Transpas) 32 Transportopdracht Outdoor Life Group NederlArt Systems (Transpas) St. van den Brink Ermelo Art Systems (Transpas) 33 Transportopdracht Emergo ERP Pultrum Rijssen Art Systems (Transpas) 34 Transportopdracht Barenbrug ERP Pultrum Rijssen Art Systems (Transpas) 37 Transportopdracht Transport Info Portal Van Doesburg TANS (Talis) 38 Transfollow Royal Lemkes ERP verlader Gist Art Systems (Transpas) 39 Transfollow Royal Lemkes ERP verlader Oldenburger Art Systems (Transpas) 42 Transportopdracht Synple platform Portal Div. Vervoerders n.v.t. 46 Transportopdracht Vervoerder XX Via Transportinfo Klant TANS TANS (Talis) 47 Transfollow Klant Eigen ERP Baetsen TANS (Talis) 48 Transfollow Klant Eigen ERP Lafeber TANS (Talis) 49 Transfollow Klant Eigen ERP Van Hooft TANS (Talis) Daarnaast wordt nog aan meerdere koppelingen gewerkt. Met de steun van een aantal TMS leveranciers is een voorzichtige trend waarneembaar, dat ook zij hun klanten positief informeren over het gebruik van de TLN standaarden. Hoewel het in de meeste gevallen nog altijd geen plug and play koppelingen zijn, is wel duidelijk geworden dat men met minder

18 inspanning een koppeling kan realiseren als de standaarden opgenomen zijn in hun standaard software (TMS). Kort samengevat zijn de algemene conclusies na de lopende pilots en implementaties als volgt: De samenstelling van de standaard transportopdracht is tamelijk uitgebreid. Concreet betekent dit: veel beschikbare velden, waarvan slechts een deel daadwerkelijk gebruikt wordt. De opbouw van het bestand is niet altijd overeenkomstig de standaard opbouw binnen het TMS systeem: Dossier, order, zending, rit, opdrachtgever, laad- en losgegevens, ladinginformatie etc. Vooralsnog heeft dit niet geleid tot echt missende velden. Eerder levert het vertraging op door afstemming over waar de informatie exact ondergebracht dient te worden. De bijgeleverde documentatie (TNO) is zo uitgebreid, dat het vervoerders afschrikt om zich hier in te verdiepen. Men kiest dan eerder voor de pragmatische weg door een vergelijkbaar voorbeeld naar de opdrachtgever te sturen in de hoop, dat men hiermee de koppeling tot stand kan brengen. De standaard voor Duitse netwerken (Fortras) is eveneens erg uitgebreid, maar in een aantal opzichten verder doorontwikkeld. Door de grote afstanden en de structuur van distributienetwerken in Duitsland heeft men hier een grote voorsprong in het gebruik van standaarden. De Fortras documentatie is gebruikt om te beoordelen of de standaarden te vergelijken zijn. De transportopdracht is vergelijkbaar, maar voor de statusmeldingen kan het goed zijn dat er elementen uit de Duitse variant voorgedragen gaan worden. Leverancier Art Systems heeft inmiddels beide standaarden in het systeem opgenomen, waardoor zij een belangrijke partij geworden zijn in het optimaliseren van de TLN standaard. Dit wordt in de lopende pilots verder opgepakt. Ten aanzien van de daadwerkelijke implementaties is het volgende duidelijk geworden: Implementaties zijn langzaam op gang gekomen; De meeste bedrijven zijn afhankelijk van hun TMS leverancier. De keuze om deze leveranciers allereerst te overtuigen van de standaarden is een goede stap geweest. TMS leveranciers ondersteunen het gebruik van standaarden, maar men is nog behoudend in de daadwerkelijke ontwikkeling, advisering en uitrol onder klanten; Als de standaarden eenmaal onderdeel zijn van de standaard software (zoals bij Art Systems) komen implementaties sneller op gang; Eerste implementaties zijn uitgevoerd bij bedrijven met eigen ICT kennis in huis. Vervoerders met eigen ICT experts nemen ook hierin een voorsprong. Qua functionaliteit zijn de TLN standaarden ook geschikt voor de deelmarkt TLN Distributie. Een aantal toevoegingen is raadzaam. Zie hiervoor het volgende hoofdstuk; Nu het vliegwiel op gang is gebracht, lijken nieuwe implementaties vanzelf op gang te komen.

19 4. Gebruikerservaringen bij implementatie 4.1 Inleiding Met de beschreven implementaties uit het vorige hoofdstuk en daarnaast alle initiatieven die nog lopen, is veel ervaring opgedaan met de inzet van de TLN standaarden. De meest gestelde vragen en opmerkingen worden in dit hoofdstuk behandeld. De meeste implementaties hadden betrekking op de transportopdracht, dus vrijwel alle verzamelde punten in dit hoofdstuk gaan hierover. Over de factuur is niets noemenswaardig gemeld en de vragen over Transfollow zijn direct door de implementatiedeskundigen van hun opgepakt. De punten die als verzoek tot wijziging of uitbreiding geclassificeerd zijn, worden overgedragen aan de SUTC. 4.2 Structuur TLN transportopdracht Er zijn verschillende koppelingen op basis van de standaard transportopdracht gerealiseerd. In alle situaties is uitgegaan van de TransportExecutionPlanRequest (TEPR). Het TEPR, ook wel de transportopdracht, wordt gebruikt voor geven van een opdracht tot het verlenen van een transportdienst. De structuur van de standaard transportopdracht is weergegeven in onderstaande figuur. Afbeelding 4.1: Structuur TLN transportopdracht Bij het gebruik van de transportopdracht geldt een aantal basisvoorwaarden die voor iedereen gelden: De transportopdracht is verdeeld in 1 of meerdere Consignments (zendingen); 1 assignment bestaat uit 1 Transporthandlingunit;

20 De afmetingen (MeasurementDimensions) van de transporthandlingunit omvatten de measurementdimensions van de gehele consignment. Dezelfde partij kan meerdere rollen vervullen. Bijvoorbeeld: de opdrachtgever (TransportUserParty) is tevens de verzender (Consignor) van de goederen vanaf het eigen magazijn (RequestedPickupTransportEvent/Location). Hier komen dan ook dezelfde gegevens voor. 4.3 Praktische zaken bij implementatie Op basis van de ervaringen en opgeloste vraagstukken bij de implementaties kan gesteld worden dat de standaard transportopdracht bruikbaar is in de (stedelijke) distributie. Hieronder volgt een aantal praktische zaken, waarover de meeste vragen tijdens de implementaties gesteld zijn. De gekozen volgorde is willekeurig en zegt niets over het effect of prioriteit. 1. Laadmeters invoegen De standaard transportopdracht laat toe dat er verschillende measurements opgeven kunnen worden. Hierin is LOADLENGT ook één van de codes die je kunt opgeven. Bij veel distributiebedrijven is het aantal laadmeters de uniforme planeenheid. 2. Opmerkingen (bij laden/lossen) Deze worden in de standaardopdracht nu bij de remarks (opmerkingen) op consignment (zending) niveau geplaatst. De praktijk is echter wel, dat hier ook weer te veel informatie in wordt geplaatst, bijvoorbeeld tijden en transporttype of restricties. Nu is er vaak toch nog een handmatige controleslag nodig om deze informatie naar de juiste velden te verplaatsen. Veel distributiebedrijven werken met een automatisch ritplanningssysteem. Voor een juiste verwerking en planning van de orders in een dergelijk systeem dienen de restricties in de juiste velden te staan. In het voorbeeld hierboven is de tekst ACHTERUIT DE STRAAT IN RIJDEN als extra adresregel in het TMS opgenomen. Dit hoort bij opmerkingen lossen thuis. Bij de opmerkingen staat bakwagen met klep. Dit is eigenlijk een restrictie. Het blijft dus moeilijk om data in een standaard transportopdracht te versturen terwijl de informatie niet op de juiste plaats in het TMS van de verzender staat.

21 3. Laad- en losreferenties Laad- en losreferenties dienen te worden geplaatst bij de ConsigneeAssignedID (ontvanger) en ConsignorAssignedID (verzender). Een voorbeeld: <cbc:id>xyz987</cbc:id> <cbc:carrierassignedid>b00001</cbc:carrierassignedid> <cbc:consigneeassignedid>a123789</cbc:consigneeassignedid> <cbc:consignorassignedid>z987321</cbc:consignorassignedid> 4. Extra adresgegevens (telefoonnummer, e-mailadres etc.) Bij de verschillende party elementen in de XML zitten mogelijkheden om extra contactgegevens op te nemen. Dit zit ook op consignment niveau. 5. Kilogrammen (gewicht) invullen Diverse keren is aangegeven, dat er geen gewicht meegestuurd werd. Dit blijkt geen tekortkoming in de standaard te zijn, maar deze gegevens werden niet meegestuurd vanaf de bron of er stond 0 kg. In dat geval wordt er ook niets verstuurd. 6. Openingstijden toevoegen De openingstijden zijn toe te voegen aan een RequestedPickupTransportEvent (laadactie) en een RequestedDeliveryTransportEvent (losactie), Hier kan ook nog een (validityperiod) periode aan toe worden gevoegd, waarbinnen deze tijden van toepassing zijn. 7. Type zending toevoegen (afhaler of levering) Sommige vervoerders maken in hun TMS of ritplanningspakket onderscheid in het type zending, met andere woorden: of het een afhaal- of leverzending is. Dit is geen functionaliteit in de standaard transportopdracht. In de praktijk is dit opgelost door te kijken naar het laad- en leveradres. In sommige gevallen heeft de vervoerder zelf logica toegevoegd, dus het type zending wordt dan bepaald via het laad- of losadres. 8. Problematiek bij goederenregels Zoals uit de uitgangspunten van de stransport transportopdracht blijkt, bestaat een Consignment (zending) uit 1 TransportHandlingUnit. Binnen een TransportHandlingUnit kunnen nog drie gelaagde eenheden voorkomen: TransportEquipment Package Goods Item Deze eenheden kunnen tevens genest worden; zo kan een TransportEquipment x aantal Packages en x aantal Goods Items bevatten, en een Package kan tevens x aantal Goods Items

22 bevatten. Dit concept is goed doordacht en hiermee is de werkelijkheid prima over te nemen. De meeste TMS en werken echter met een eenvoudige goederenregel, waarop slechts één of enkele eenheden vastgelegd worden. Ook dat is prima werkbaar met bovenstaand concept; iedere goederenregel is 1 dan TransportHandlingUnit met 1 TransportEquipment en eventueel nog 1 Package en/of 1 Goods Item. Het probleem ontstaat als er wél complexe TransportHandlingUnits worden gevormd. Hier volgt een simpel voorbeeld conform de standaard: TransportHandlingUnit TransportEquipment (2 Poolpallets, 1 laadmeter) Goods Item (Bananen) Package (40 Dozen, omgerekend 0,8 laadmeter, want normaal gaan er 25 dozen op een blokpallet) Goods Item (Bananen) Wat is nu de werkelijke laadlengte van de goederen? 1 laadmeter, 0,8 laadmeter of mogelijk zelfs 1,8 laadmeter? Er zijn verschillende mogelijkheden, dus de kans blijft aanwezig dat interpretatie van het ene TMS niet aansluit op de interpretatie van een ander TMS. Kort gezegd: De mogelijkheden van goederenregels in de standaard transportopdracht zijn eigenlijk zo groot, dat er een standaard binnen de standaard afgesproken moet worden. 9. Statusberichten met vrije interpretatie In de documentatie van de standaard transportopdracht zijn ook statusmeldingen opgenomen. Het gaat hier om vrij beperkte informatie over de uitvoering van een transportorder. Een aantal leden van de deelmarkt Distributie is aangesloten bij Netwerk Benelux (NBX). Zij werken sinds een klein jaar met een nieuw systeem, dat afkomstig is uit Duitsland en ook gebruik maakt van Duitse standaarden. Voor het statusbericht binnen de TLN standaard is goed gekeken naar het NBX statusbericht. Op verzoek van een aantal distributiebedrijven is daar nog een aanvulling op voorgesteld. Er zijn vervoerders (en opdrachtgevers) die extra informatie nodig hebben van een levering. Bijvoorbeeld: hoe lang heeft deze geduurd en hoe lang was er montagetijd. Dit is feitelijk een weerspiegeling van het vragenpad van de boordcomputer. Dit is moeilijk te standaardiseren, aangezien ieder vragenpad anders is. Er is daarom voorgesteld om hier een extra vrij element voor op te nemen. Dit vrije element bevat de informatie van een extra activiteit of bewerking. Een voorbeeld van zo n statusbericht:

23 <xmlstat xmlns:xsi="http://www.w3.org/2001/xmlschemainstance" xmlns:xsd="http://www.w3.org/2001/xmlschema"> <datetime type="at">20170228105214</datetime> <senderid>150</senderid> <receiverid>161</receiverid> <codelist>nbx</codelist> <consignmentstat> <id type="noc" datatype="con">n00161.125546_1</id> <status>l00</status> <datetime type="at">20170228104700</datetime> <name /> <note /> <signature /> <poa type="nbx"> <checkpoint>l</checkpoint> <action>l</action> <object type="tou">bp-lp-74</object> </poa> <extra><starttime>2017-02- 28T15:33:24.553</starttime><endtime>2017-02- 28T16:33:24.553</endtime><contructionduration>0.5</con tructionduration></extra> </consignmentstat> </xmlstat> In element extra staat in dit voorbeeld: <starttime>2017-02-28t15:35:16.013</starttime> <endtime>2017-02-28t16:35:16.013</endtime> <contructionduration>0.5</contructionduration> Verder is het van belang, dat er code-tabel opgenomen gaat worden voor de statussen. 10. Juiste ID voor koppeling statusbericht aan order en kenteken voertuig Bij de koppeling tussen Wessels Transport en Lafeber Transport wordt al een kenteken van het geplande voertuig meegestuurd. Dit is normaal niet voorzien in de standaard. Dit is uiteindelijk opgelost met het veld CarrierAssignedID. Zie onderstaand voorbeeld:

24 In "cbc:id" staat het technische nummer van de zending met een '_' gevolgd door het dossiernummer en het dossier volgnummer. Dit is de unieke identificatie om de koppeling tussen het statusbericht en de oorspronkelijke opdracht juist te laten verlopen. In "cbc:carrierassignedid" staat dus het kenteken. Dit is de truck waarmee de zending gelost wordt. Als er met een andere truck geladen wordt, dan wordt deze niet meegestuurd. De onderste twee velden zijn de laad- en losreferentie die in dit voorbeeld niet gevuld zijn (zie punt 3). 11. Lijst met locatie condities (bijv. laadklep, kooiaap, milieuzone) gebruiken Meerdere klanten hebben aangegeven om onderstaande lijst met locatie condities in de transportopdracht te gebruiken. In de XML definitie staat in het "Location" segment de tag "Conditions". Deze kan meerdere keren voorkomen, maar er wordt in de toelichting naar een vrij tekstveld verwezen en niet specifiek naar deze codelijst. Dit moet verduidelijkt worden.