Memorandum
Onderwerp
Scenario's eValidator
1
Scenarios eValidator Dit document bevat een aantal eenvoudige scenario’s waarmee de functionaliteit van de eValidator wordt toegelicht. Hierbij wordt benadruk dat de kracht in de eenvoud van de scenario’s zit. Het doel hiervan is dat partijen en beslissingnemers het concept “eValidator” begrijpen en zelf kunnen vertalen naar hun eigen situatie.
2
Scenario I uitwisseling transportinformatie Er is een belangenorganisatie in de transportsector die een bepaalde standaard heeft geadopteerd. Om het gebruik van deze standaard te stimuleren heeft deze organisatie de eValidator ingericht om partijen in de transportsector te ondersteunen bij het gebruik van deze standaard. Eén van de geïnteresseerden is een fabrikant van meubels. Deze fabrikant heeft een partij meubels staan die door zijn vaste transporteur naar de klant gebracht zal worden. Om optimaal gebruik te maken van elektronische dienstverlening, is besloten om gebruik te maken van de standaard die de brancheorganisatie onlangs geadopteerd heeft: TransportXML. In deze standaard is vastgelegd hoe de betrokken informatiesystemen met elkaar kunnen samenwerken op basis van XML berichten.
Zo wordt in dit bericht precies opgenomen waaruit de lading zal bestaan en wat het adres en gewenste tijdstip van aflevering is. De TransportXML standaard is zó opgezet, dat fouten tijdens het inboeken van een transport-order voorkomen kunnen worden: • Capaciteitscontrole • Goede match tussen vrachtwagen en lading (geen vriesgroenten in een vrachtwagen zonder koeling) Om ervoor te zorgen dat de betrokken informatiesystemen op een juiste manier met elkaar communiceren, is het van belang dat zowel de fabrikant als de transporteur de
TNO Informatie- en Communicatietechnologie Wireline E-IT Colosseum 27 7521 PV Enschede
T +31 53 483 52 00 F +31 53 483 52 22
[email protected]
Datum
ontwikkelde standaard correct gebruik. Validatie van het gebruik van de standaard kan hieraan bijdragen. In de TransportXML standaard is afgesproken dat een opdracht de volgende onderdelen bevat: • Omvang lading (aantal pallets) • Type lading (normaal / koel / vries) • Adres klant Ook is algemeen overeengekomen dat de verschillende typen vrachtwagens de volgende capaciteiten hebben: • Normale vrachtwagen 30 pallets • Vrachtwagen met een koeling 28 pallets • Vrachtwagen met een vriezer 25 pallets In XML ziet een order er als volgt uit:
30 cooled <customerAddress> <street>Coolsingel 21 3012 AA Rotterdam The Netherlands
In het voorbeeld is te zien dat er iets fout gaat. Door de fabrikant wordt immers een transportopdracht voorbereid waarbij er 30 pallets in een vrachtwagen met koeling geplaatst worden. Dit is niet mogelijk omdat de capaciteit van een dergelijk type vrachtwagen slechts 28 is. Met behulp van standaarden validatie kan deze fout voorkomen worden door de gebruiker tijdig te waarschuwen dat de order niet aan de TransportXML standaard voldoet. Bijvoorbeeld met de volgende melding: U probeert een order van het type 'cooled' met een omvang van 30 pallets te plaatsen. Voor vrachtwagens die orders van het type 'cooled' vervoeren, is het maximum aantal te vervoeren pallets vastgesteld op 28. Doordat de softwareleverancier van de meubelfabrikant het gebruik van de standaard uitgebreid kan testen met de eValidator, weet de fabrikant zeker dat zijn systemen kunnen communiceren met alle andere systemen die TransportXML gebruiken. In dit geval heeft de transporteur ook een systeem dat TransportXML ondersteunt. In feite praten beide partijen nu ‘dezelfde taal’ en ontstaan er minder fouten in het orderproces.
Onze referentie Blad 2/6
Datum
3
Demonstratie scenario I Op www.validatieservice.nl/demo/ wordt het bovenbeschreven scenario aangeboden in een interactieve demonstratie die u zelf uit kunt voeren. Stap 1. Instellingen Zorg ervoor dat de volgende instellingen geselecteerd zijn:
Stap 2. Te valideren bestand U kunt een voorbeeld selecteren, of zelf de XML content aanpassen om te kijken wat dit voor effect heeft op het validatie resultaat.
Stap 3. Start validatie Klik op de knop ‘Valideer’. De validatie wordt gestart en de resultaten worden onderaan de pagina toegevoegd.
Onze referentie Blad 3/6
Datum
4
Scenario II Elektronisch factureren Om kosten te besparen heeft een financiële dienstverlener besloten om haar facturen voortaan elektronisch te versturen. Om dit op een gestructureerde manier te doen heeft zij de standaard InvoiceXML geadopteerd. In deze standaard is precies beschreven waaraan een elektronische factuur moet voldoen. Indien alle partijen zich aan deze standaard houden, zijn er weinig problemen te verwachten met het verwerken van deze facturen door de informatiesystemen van de betrokken partijen. Erik van Veen is een MKB’er die met zijn bedrijf de facilitaire dienstverlening bij een groot aantal partijen op een industrieterrein verzorgt. Onlangs is er op dit industrieterrein een glasvezelverbinding aangelegd en iedereen heeft nu toegang tot email en Internet. Een aantal grote klanten van Erik werkt al met InvoiceXML, daarom overweegt Erik om zijn facturen voortaan elektronisch te versturen. Hij vindt het echter lastig om de InvoiceXML standaard te interpreteren en twijfelt of zijn werknemers met de beschikbare open source facturatie systemen overweg kunnen. Daarom bekijkt hij binnen de omgeving van InvoiceXML een demonstratie waarin duidelijk wordt aangegeven aan welke eisen elektronische facturen moeten voldoen. Mede dankzij de duidelijke foutmeldingen in het Nederlands dring het al snel tot hem door dat een elektronische factuur eigenlijk niet veel verschilt van een papieren factuur, maar dat je gewoon aan een aantal afspraken moet voldoen. Deze afspraken kunnen getoetst worden door de facturen even te valideren. Door zijn administratieve systemen direct te sluiten op de validatie service, is het zelfs mogelijk om deze controles automatisch voor elke gegenereerde factuur uit te voeren.
Een elektronische factuur ziet er in het geval van Erik van Veen als volgt uit:
In het XML document is goed te zien dat de naam van de medewerker, de klant en de bestede tijd aangegeven zijn. De verschillende onderdelen moeten voldoen aan een
Onze referentie Blad 4/6
Datum
aantal regels. Zo moet elke medewerker en klant uniek identificeerbaar zijn met een nummer en geldt dat het aantal gewerkte uren nooit meer mag zijn dan ‘de eindtijd – de begintijd’. 5
Demonstratie scenario II Op www.validatieservice.nl/demo/ wordt het bovenbeschreven scenario aangeboden in een interactieve demonstratie die u zelf uit kunt voeren. Stap 1. Instellingen Zorg ervoor dat de volgende instellingen geselecteerd zijn:
Stap 2. Te valideren bestand U kunt een voorbeeld selecteren, of zelf de XML content aanpassen om te kijken wat dit voor effect heeft op het validatie resultaat.
Stap 3. Start validatie Klik op de knop ‘Valideer’. De validatie wordt gestart en de resultaten worden onderaan de pagina toegevoegd.
Onze referentie Blad 5/6
Datum Onze referentie Blad 6/6
