Tux Paint is een gratis tekenprogramma voor kinderen tussen 3 en 12 jaar dat hieraan voldoet. Tux Paint wordt ontwikkeld door vrijwilligers wereldwijd en is gratis beschikbaar onder de GNU General Public License. Lead Developer en Designer is Bill Kendrick, eigenaar van het bedrijf New Breed Software. Tux Paint draait onder verschillende besturingssystemen waaronder Windows (incl. Tablet PC), Mac OS X, Linux, FreeBSD en NetBSD. Het programma draait zelfs onder Citrix® en Windows Terminal Services en op handheld computers.

Tux Paint is in gebruik bij verschillende scholen in de wereld van België tot in de Verenigde Staten.

Tux Paint combineert een handige gebruikersinterface met geluiden en uitdagende humoristische mascotte die de kinderen richting geven tijdens het gebruik van het programma.

Downloaden en installeren
U kunt Tux Paint downloaden van de website tuxpaint.org maar u kunt ook de Tux Paint CD bestellen bij CafePress

Ga naar de website en klik op de link Download in de linkderkolom.

Selecteer de versie voor uw besturingssysteem.

Tux Paint komt in twee delen: het Tux Paint programma en de verzameling van stempels.

Download beide installatieprogramma’s.

Na het downloaden start achtereenvolgens de programma’s tuxpaint-0.9.20b-win32-installer.exe en tuxpaint-stamps-2008.06.30-win43-installer.exe.

Volg de installatieinstructies.

Opstarten Tux Paint
Ga naar Start > Alle programma’s > Tux Paint en selecteer de optie Tux Paint (Windowed).

Wanneer u Tux Paint opstart krijgt u direct de beschikking over een lege canvas en een verscheidenheid aan tekengereedschappen. Aan de linkerkant van het canvas staan de hulpmiddelen en aan de rechterkant staan bij het hulpmiddel horende knoppen.

De hulpmiddelen kunt u activeren door de knop van het betreffende hulpmiddel dat u wenst te gebruiken aan te raken met uw muis. Tussen de hulpmiddelen vindt u ook de knoppen Terugwijzigen, Opnieuw doen, Nieuw, Opslaan, Openen en Stoppen.

Wanneer u een hulpmiddel selecteert ziet u aan de rechterkant de verzameling knoppen eveneens veranderen. Kiest u het hulpmiddel stempel dan ziet u daar een overzicht verschijnen van stempels. Het overzicht bestaat uit een grote verzameling van dieren. Het grappige is dat wanneer u één van deze dieren aanklikt u het geluid van het dier en de naam van het dier te horen krijgt.

Wist u al welk geluid een pinguïn maakt ? Nee zorg ervoor dat het volume van uw luidsprekers openstaat en het niveau van Tux Paint voldoende luid staat. Het niveau kunt u instellen met de volumebalk onder de stempels.

Zoek nu de pinguïn op in de lijst met stempels en klik op de stempel. Voor bijna elk dier is het geluid aanwezig. Een handige manier om kinderen vertrouwd te maken met dieren en met hun geluiden. Volwassenen raken natuurlijk snel uitgekeken op Tux Paint maar ik beveel het toch aan voor kinderen rond de leeftijd van 4 tot 6 jaar.

Tux Typing en Tux Math
Naast Tux Paint zijn er nog Tux Typing en Tux Math Command.

Spelenderwijs proberen deze programma’s kinderen kennis van rekenen en van typen bij te brengen.

Als u deze programma’s wilt uitproberen ga dan naar de betreffende website, klik op de knop download en download de versie van het installatieprogramma voor uw computer en besturingssysteem.

Dubbelklik daarna op het installatieprogramma en volg de instructies.

Ik heb deze programma’s één voor één uitgeprobeerd en ze zijn prachtig. Vooral de intromuziek van Tux Typing moet u horen.

Spelen met Tux Typing en Tux Math
Via het menuscherm van Tux Typing kunt een aantal opties instellen waaronder de taalcode en kunt u eveneens de lijst met woorden waarmee gewerkt wordt onderhouden.

Tux Typing en Tux Math presenteren de gebruiker een scherm waar letters of rekenformules naar beneden dwarrelen. Door de letters in te tikken of het juiste antwoord te geven op de rekenformules kunnen punten verdiend worden. De gebruiker met de hoogste score - vanzelfsprekend - wint natuurlijk.

Tux Typing is vergeleken met Tux Math rijker aan variaties maar u moet het zelf maar eens proberen.

Ik wens u veel plezier met Tux en laat even weten wat uw kinderen van Tux vinden.

Ik gebruik MWSnap als hulpmiddel voor het maken van screenshots van afbeeldingen die ik dan weer verwerk ik handleidingen en mijn weblog artikelen.

MWSnap biedt gebruikers een aantal functies:
1) een aantal standaard capture - opname mogelijkheden
- een vaste rechthoek
- een vrij te selecteren rechthoek
- een dialoogvenster
- het volledige bureaublad
- initiëren met sneltoetsen

2) een aantal edit functions - bewerkingsfuncties
- transformeren (spiegelen, omkeren, links roteren, rechts roteren)
- inlijsten:
- toevoegen van cursors

3) extra functionaliteit
- System Tray Launcher
- Automatisch opslaan
- Geluiden bij opname
- Undo / Redo
- Herhalen laatste schermopname

Ik heb de laatste jaren gezocht naar Open Source Screen Capture gereedschappen die eveneens deze functies bieden. De voorbije week heb ik een aantal Screen Capture gereedschappen gevonden. Het mooie is dat deze gereedschappen in verschillende talen (Java, C#) ontwikkeld zijn waardoor een gebruiker een keuze kan maken.

- JShot is ontwikkeld in Java door Attila Magyar (Zeroflag) uit Hongarije.

- ZScreen is ontwikeld in C# door BrandonZ

Een lijst van Screen Capture gereedschappen kunt u terugvinden op mijn website onder de menuoptie Links, categorie Desktop Tools.

Met ZScreen kunt u screenshots maken van het volledige scherm, een actief scherm of een selectie van het scherm. Het is zelfs mogelijk om een screenshot te maken van een context menu, wat met sommige Screen Capture gereedschappen niet kan. Wanneer u ZScreen opstart wordt deze automatisch geladen in de system tray en kunt u met de rechtermuisknop het ZScreen context menu oproepen. Via het context menu krijgt u toegang tot een aantal menufuncties waaronder het bekijken van de verschillende instellingen.

Het is niet mogelijk om via het context menu afbeeldingen vast te leggen. ZScreen maakt gebruik van sneltoetsen die u zelf kunt instellen op het moment dat u ZScreen installeert of later door het instellingenscherm te openen vanuit het context menu.

Downloaden en installeren van ZScreen
U kunt het installatieprogramma van ZScreen downloaden van de website www.brandonz.net. Ga naar de website en selecteer de optie ZScreen onder het menu Projects. In de volgende webpagina klik onder het menu ZScreen Downloads op de link naar het Setup programma.

Sla het bestand (ZScreenSetup-abcd.exe) op in een folder van uw keuze en ga daarna naar deze folder.

Dubbelklik op het bestand en volg de installatieprocedure.

Na het opstarten van ZScreen wordt het scherm met instellingen geopend waar u alle benodigde instellingen kunt bekijken en aanpassen.

ZScreen Instellingen
Het scherm met instellingen bestaat uit een aantal tabbladen waarmee u het gebruik en functioneren van ZScreen naar uw hand kunt zetten.

Wanneer u onder het tabblad Basis op het ikoon van ZScreen klikt wordt de documentatie geopend. Hier kunt u meer informatie terugvinden over de verschillende instellingen en het gebruik van ZScreen.

Onder het tabblad Basis kunt u de taal van de gebruikersinterface definiëren en de bestemming van de screenshot vastleggen:
- Klembord (Clipboard)
- Bestand (File)
- FTP
- ImageShack

Via het tabblad Bestand Instellingen kunt u aangeven in welke folder afbeeldingen (tijdelijk) opgeslagen moeten worden. Standaard worden alle afbeeldingen in deze folder opgeslagen ongeacht of u deze bewerkt met een tekenprogramma of naar een FTP server upload. In het laatste geval kunt u hier wel aangeven of de afbeelding na het uploaden uit deze folder verwijderd moet worden.

Standaard wordt ZScreen geïnstalleerd met voorgedefinieerde Automatic Naming Conventions en Picture Quality. U kunt de naamgeving en kwaliteit die ZScreen moet gebruiken voor het vastleggen van afbeeldingen aanpassen. Zelf heb ik het bestandsformaat aangepast van PNG naar JPG omdat dit het formaat is dat ik het meest gebruik. Voor de naamgeving kunt u twee conventies instellen: (1) voor het maken van een screenshot van het Actieve Scherm en (2) voor het maken van een Verkleind /Volledig Venster.

Het is eveneens mogelijk om ZScreen zo in te stellen dat u tijdens het maken van een screenshot de naam van het bestand kunt aanpassen. Een instelling die wel handig is omdat de naamgeving van ZScreen vrij cryptisch is, voorbeeld SS-18.08.2008-11.31.10AM.

Voor het weergeven en aanpassen van de afbeelding kan ZScreen gebruik maken van een tekenprogramma. Standaard is het gebruik van een tekenprogramma niet geactiveerd. U kunt zelf instellen welk tekenprogramma u wilt gebruiken of u kunt gewoon MS Paint selecteren. Dit dient u wel te doen alvorens u een afbeelding vastlegd. Ga daarvoor naar het tabblad Image Software Instellingen en selecteer MS Paint of voeg uw tekenprogramma toe.

Maken van screenshots
ZScreen geeft u de mogelijkheid om een deel van het scherm te selecteren, vast te leggen en te publiceren. Publiceren wil zeggen dat u uw screenshot kunt uploaden naar een FTP server, een Image Hosting server (ImageShack) of opslaan als een bestand.

ZScreen maakt gebruik van sneltoetsen voor het vastleggen van screenshots. Deze sneltoetsen kunt u zelf instellen onder het tabblad Sneltoetsen. Ik heb de sneltoetsen als volgt ingesteld zodat deze overeenkomen met de instellingen van MWSnap:
- Actieve scherm: Shift+Control+W, voor het maken van een screenshot van het openstaande actieve venster

- Verkleind screenshot: Shift+Control+A, voor het maken van een screenshot van een geselecteerd deel van een venster

- Volledige scherm: Shift+Control+D, voor het maken van een screenshot van het volledige venster

Conclusies
ZScreen waarschuwt u niet waneer u een screenshot hebt gemaakt. Alleen wanneer u een tekenprogramma hebt gekoppeld aan ZScreen of de optie Prompt for File Name hebt aangezet kunt u zien dat een screenshot wordt vastgelegd. Het onbreken van geluiden is één van de enige beperkingen van ZScreen.

Verder biedt ZScreen alle functies die nodig zijn waaronder sneltoetsen en het tonen van de screenshot. Met een ander tekenprogramma dan MS Paint is het mogelijk om cursors en andere tekens toe te voegen aan de gemaakte screenshot.

De ondersteuning voor sneltoetsen en de mogelijkheid om eveneens screenshots te kunnen maken van context menu’s zijn wel de voornaamste redenen waarom ZScreen mij aanspreekt.

Hierna zal ik aangeven welke functionaliteit aanwezig is:
een aantal standaard capture - opname mogelijkheden
- een vaste rechthoek: niet aanwezig
- een vrij te selecteren rechthoek: aanwezig
- een dialoogvenster: aanwezig
- onderdelen van het venster: niet aanwezig
- het volledige openstaande scherm: aanwezig
- het volledige bureaublad: niet aanwezig

- initiëren van screenshot met sneltoetsen: aanwezig

een aantal edit functions - bewerkingsfuncties
- instellen van tekenprogramma: aanwezig

- transformeren (spiegelen, omkeren, links roteren, rechts roteren): afhankelijk van tekenprogramma
- inlijsten: afhankelijk van tekenprogramma
- toevoegen van cursors: afhankelijk van tekenprogramma

extra functionaliteit
- System Tray Launcher: aanwezig
- Automatisch opslaan: aanwezig
- Geluiden bij opname: niet aanwezig
- Undo / Redo: afhankelijk van tekenprogramma
- Herhalen laatste schermopname: niet aanwezig

JShot geeft u de mogelijkheid om een deel van het scherm te selecteren, vast te leggen en te publiceren. Publiceren wil zeggen dat u uw screenshot kunt uploaden naar een FTP server, een Image Hosting server (ImageShack) of kunt verzenden naar uw Instant Messaging partner (Skype, MSN). JShot kent echter geen sneltoetsen waardoor het niet mogelijk is om een screenshot te maken van een context menu.

JShot beschikt eveneens over teken- en bewerkingsfunctionaliteit waaronder het aanbrengen van cursors of andere vormen (lijnen, tekst) op uw afbeelding. JShot maakt daarvoor gebruik van het tekenprogramma dat standaard aanwezig is of dat u instelt via het configuratiescherm.

Helaas is er nog geen documentatie of helpfunctie beschikbaar en zult u wat moeten experimenteren om met JShot te leren werken. Echter in een mum van tijd hebt u wel begrepen hoe één en ander werkt. Ik zal hierna een aantal basis functies toelichten.

Downloaden en installeren van JShot
U kunt JShot downloaden van de website JShot.info via het hoofdmenu. Klik op de link Download en in het download scherm selecteer de versie voor uw besturingssysteem (Windows, Linux of ander platform).

Sla het bestand jshotinstall.exe (of jshotinstall.jar voor Linux) op in een folder van uw keuze.

Ga naar de folder waar u het bestand hebt opgeslagen en dubbelklik op het bestand.

Volg de installatieprocedure. Tijdens de installatie moet u de licentie overeenkomst (geen open source licentie) accepteren en aangeven in welke folder u JShot wilt installeren. U kunt tijdens de installatie van JShot eveneens de plugin’s voor ImageShack en Skype selecteren.

JShot beschikt momenteel nog niet over een plugin-manager, deze is in ontwikkeling, maar optionele plugin’s kunnen wel handmatig worden toegevoegd in een eigen folder onder de directory plugins. Een plugin bestaat uit een .jar-bestand, plugin.xml met daarin de beschrijving en een optionele lib-folder.

Wanneer u JShot voor de eerste maal opstart wordt de configuratie wizard geopend waarin u geadviseerd wordt om uw configuratieinstellingen te controleren en een uploader profiel aan te maken.

Klik op de knop Next om naar de configuratieinstellingen te gaan. U kunt ondermeer instellen in welk formaat uw afbeeldingen opgeslagen moet worden en welke look-en-feel u wilt hanteren.

Klik op de knop Next om naar het upload profiel te gaan. Hier kunt u de instellingen voor ImageShack invoeren, als u over een login beschikt, en/of een profiel voor Skype of een andere FTP uploader aanmaken.

Klik hiervoor op de Add en vul de gevraagde gegevens in. U moet wel de benodigde plugin installeren voor uw FTP uploader en eventueel als deze nog niet beschikbaar is moet u deze ontwikkelen.

Klik op de knop Finish om de configuratie af te ronden en JShot te starten.

Maken van screenshots
JShot kunt u op twee manier openen: als applicatie en in de system tray.

Als u alleen de applicatie hebt geopend is het alleen maar mogelijk om een screenshot te maken van een volledig venster. Voor het maken van een screenshot vanuit de applicatie open JShot en klik op de knop New Screenshot bovenaan in de toolbar.

Wanneer u JShot hebt geopend in de system tray kunt u de gewenste screenshot maken via het context menu. Klik voor het openen van het context menu met uw rechtermuisknop op het JShot ikoontje in de system tray en selecteer de screenshot die u wilt maken.

JShot biedt u 4 mogelijke screenshots aan via het context menu:
- het volledige scherm (whole screen)
- het openstaande scherm (foreground window)
- de desktop - bureaublad (desktop)
- de taskbar (taskbar)

- de vijfde mogelijkheid - Wanneer u dubbelklikt op het JShot ikoontje in de system tray kunt u een rechthoekig venster selecteren voor het maken van een screenshot. Er verschijnt op het scherm de melding Drag your mouse to select a portion of the screen.

Conclusies
Na wat experimenteren kan ik voorlopig de volgende conclusies trekken. JShot biedt heel wat voorzieningen voor het aanpassen van uw screenshots. Dit komt met name omdat JShot gebruik maakt van een tekenprogramma dat u zelf kunt instellen. Standaard is MS Paint ingesteld als tekenprogramma maar dit kunt aanpassen aan uw eigen voorkeur.

JShot kent geen sneltoetsen wat het gebruik toch in enige mate beperkt zoals ik reeds heb aangegeven. Wel is het aardig dat JShot op twee manieren geopend kan worden:
- in de system tray
- als afzonderlijke applicatie

Helaas kan in de laatste modus alleen maar een screenshot van een volledig venster gemaakt worden.

Tijdens het opslaan van bestanden en het doorlopen van folders gaat JShot hangen. Een verschijnsel wat ik wel vaker bij toepassingen gebouwd in Java tegenkom maar uiteindelijk wel oplost.

Hierna zal ik aangeven welke functionaliteit aanwezig is:
een aantal standaard capture - opname mogelijkheden
- een vaste rechthoek: niet aanwezig
- een vrij te selecteren rechthoek: aanwezig
- een dialoogvenster: aanwezig
- onderdelen van het venster: niet aanwezig
- het volledige openstaande scherm: aanwezig
- het volledige bureaublad: aanwezig

- initiëren van screenshot met sneltoetsen: niet aanwezig

een aantal edit functions - bewerkingsfuncties
- instellen van tekenprogramma: aanwezig

- transformeren (spiegelen, omkeren, links roteren, rechts roteren): afhankelijk van tekenprogramma
- inlijsten: afhankelijk van tekenprogramma
- toevoegen van cursors: afhankelijk van tekenprogramma

extra functionaliteit
- System Tray Launcher: aanwezig
- Automatisch opslaan: niet aanwezig
- Geluiden bij opname: aanwezig
- Undo / Redo: afhankelijk van tekenprogramma
- Herhalen laatste schermopname: aanwezig

Wanneer een bedrijf kiest voor één bedrijfsondersteunend systeem dat voorziet in alle benodigde functies voor het ondersteunen van de bedrijfsprocessen dan kan dit voorkomen worden. Helaas is dit niet altijd mogelijk of soms zelfs onmogelijk. Mogelijke verklaringen hiervoor zijn:
- Gewenste functionaliteit is misschien niet voorzien of onvoldoende ontwikkeld.
- Bedrijfsonderdelen hebben teveel autonomiteit en schaffen zelfstandig systemen aan.
- Door overname’s zijn systemen toegevoegd aan de IT omgeving.

Aan het eind van de rit moeten al deze applicaties wel met elkaar kunnen samenwerken en informatie kunnen uitwisselen opdat een bedrijf snel en adequaat kan reageren op veranderingen in de markt.

Oracle zegt met haar Oracle Application Integration Architecture (AIA) Foundation Pack over een nieuwe aanpak te beschikken voor het integreren van deze applicaties. Oracle Application Integration Architecture Foundation Pack is een open, op standaarden gebaseerd platform voor de integratie van bedrijfsprocessen van zowel Oracle-applicaties als maatwerkoplossingen en applicaties van derde partijen. De Foundation Pack geeft klanten en partners tools waarmee ze zelfgekozen bedrijfsprocessen kunnen implementeren, over alle applicaties heen.

De Foundation Pack bevat volgende componenten:
- Enterprise Business Objects
- Enterprise Business Services
- SOA Governance Tools
- Reference Architecture

De Enterprise Business Objects (EBO) zijn standaard business data object definities en herbruikbare data componenten voor bedrijfsgegevens. Deze objecten worden geleverd als XML Schema Definities (XSDs).

De Enterprise Business Services zijn de bouwstenen voor het realiseren van integratie. Het zijn applicatie onafhankelijke web service definities voor het uitvoeren van een specifieke taak en kunnen onafhankelijk van andere services gebruikt worden. Enterprise Business Services zijn te beschouwen als standaard interfaces die geïmplementeerd kunnen worden door applicaties.

Ten behoeve van SOA Governance bevat de Foundation Pack een aantal gereedschappen voor het beheren en besturen van de integratie levenscyclus waaronder Business Service Repository (BSR), Composite Application Validation System (CAVS) en Composite Application Error Management and Resolution.

De Business Service Repository is een Service Oriented Architecture repository en zorgt voor zichtbaarheid van de Business Services in de AIA Integration Layer op basis van UDDI functionaliteit.

Voor het realiseren van de gewenste integraties dient u niet alleen te beschikken over een rijke verzameling gereedschappen maar hebt u eveneens een methodologie en een aanpak nodig. De Reference Architecture bestaat uit handleidingen die een beschrijving geven van de applicatie integratie methodologie en de stappen voor het ontwerpen en ontwikkelen van uw integraties.

De Application Integration Architecture draait bovenop de Oracle Fusion Middleware en Oracle Fusion Middleware SOA suite is de onderliggende technologie die gebruikt wordt voor het bouwen van integraties met de Foundation Pack.

De complexiteit van de Oracle AIA Foundation Pack ligt vrij hoog en daarbij doel ik met name op de verscheidenheid aan technologische componenten en standaarden. Bedrijven zijn niet zonder ondersteuning van specialisten in staat om de Oracle AIA Foundation Pack te implementeren. Daarnaast is het ook niet mogelijk om één en ander vrijblijvend uit te proberen zoals dat met Open Source oplossingen kan.

Grote vraag is welke bedrijven en welk type bedrijven daadwerkelijk de Oracle Application Integration Architecture Foundation Pack hebben geïmplementeerd sinds eind vorig jaar. Er zijn weinig of geen concurrenten van Oracle die momenteel zover zijn dat zij deze integratiemogelijkheden kunnen leveren.

Het moet wel gezegd dat voor Oracle de AIA Foudation Architectuur een noodzaak was om al de applicaties die de voorgaande jaren zijn overgenomen te kunnen integreren en met elkaar te laten samenwerken.

Oracle is een leverancier van een grote diversiteit aan oplossingen en is er wonderwel in geslaagd om deze oplossingen zoals Siebel CRM, Oracle Applications en Financials met elkaar te laten samenwerken. Met de overname van Bea Systems zal Oracle nog sterker worden op het gebied van integratie en interoperabiliteit.

Ik verwacht dat de concurrentie voornamelijk uit de hoek van SAP en Open Source groeperingen en/of leveranciers zal komen. Een ontwikkeling die ik de komende jaren nauwlettend ga volgen.

De ontwikkeling van UBL is gestart gedeeltelijk als reactie op de veelheid en verscheidenheid aan XML standaarden / bibliotheken voor elektronische handel maar eveneens om de toegankelijkheid van elektronische handel te vergroten. UBL moet elektronisch zakendoen voor kleine en middelgrote bedrijven mogelijk maken en de basis leggen voor de wereldwijde overgang van traditioneel zakendoen naar elektronische handel.

De OASIS Universal Business Language (UBL) is gebaseerd op de XML Common Business Language xCBL versie 3.0 van Commerce One. Commerce One nam in 1999 het bedrijf Veo Systems over en kwam zo in het bezit van de Common Business Language (CBL) technologie. Deze technologie is door Commerce One verder uitgebreid en omgedoopt tot xCBL om de relatie met XML te identificeren. De XML Common Business Language (xCBL) is een verzameling van XML bouwstenen en een raamwerk voor de ontwikkeling van herbruikbare XML berichten. xCBL richt zich op documenten en transacties ter ondersteuning van de internationale elektronische handel. Commerce One heeft de versie 3.0 van xCBL ingebracht in de OASIS UBL Technical Committee als startpunt voor de ontwikkeling van UBL.

In februari 2003 werd de eerste versie van UBL (Op70 version) vrijgegeven aan het publiek voor review waarna in november 2004 de eerste officiële versie van UBL, release 1.0, na drie jaar ontwikkeling werd uitgebracht. Twee jaar later, november 2006, werd UBL 2.0 uitgebracht en als formele standaard geaccepteerd door OASIS.

De Universal Business Language maakt gebruik van XML Schema’s voor het beschrijven van gestandaardiseerde bedrijfsdocumenten. Een XML Schema Definitie Document (XSD) beschrijft de structuur van een XML document. UBL 2.0 ondersteunt 31 bedrijfsdocumenten (document types) en voor elk document is een XSD Schema opgesteld.

Verschil tussen UBL 2.0 en UBL 1.0
Een belangrijk verschil tussen UBL 2.0 en de voorgaande releases is het gebruik van een getrapt (twee-fase) validatiemodel. Tijdens het verwerken van een UBL bericht moet de structuur en het juist gebruik van gestandaardiseerde codes worden gevalideerd. UBL maakt gebruik van internationaal gestandaardiseerde codelijsten, verzameling van toegestane waarden, die worden uitgegeven en onderhouden door standaardisatieinstellingen, waaronder ISO (landencodes) en UN/CEFACT (valutacodes, eenheidsmaten, taalcodes). Codelijsten kunnen ook gebruikt worden voor het vastleggen van afgesproken waarden tussen twee of meer handelspartners.

In de voorgaande releases werden de verzameling toegestane waarden of codes rechtstreeks vastgelegd in de XML Schema’s van de bedrijfsdocumenten en kon validatie van structuur en codes gelijktijdig uitgevoerd worden. In UBL 2.0 worden de codelijsten vastgelegd in afzonderlijke configuratiebestanden en kan een getrapt validatieproces gevolgd worden. Hierdoor is het mogelijk om verschillende versies van een codelijst te hanteren per situatie. Zo kan per bedrijf waarmee zaken gedaan wordt een andere versie van een codelijst gehanteerd worden.

UBL 2.0 schema’s ondersteunen het gebruik van een getrapt validatie proces dat schematisch als volgt wordt weergegeven en bestaat uit twee stappen (fasen):

- Stap 1: Controle op structuur, data typing en vocabulary via UBL XSD bestanden en een generieke XSD validator
- Stap 2: Controle op het juist gebruik van waarden uit de codelijsten via UBL XSLT bestanden en een generieke XSLT processor. In deze stap vindt validatie van internationaal gestandaardiseerde codes plaats via de standaard UBL 2 .xsl bestanden en validatie van trading-partner specifieke codes via de customized .xsl bestanden.

Hoe staat het met het gebruik van UBL voor elektronisch zakendoen
Wereldwijd is UBL in gebruik als de elektronische berichtenstandaard voor elektronisch zakendoen tussen bedrijven en overheden. Binnen Europa lopen een aantal landen voorop in de ontwikkeling van een elektronische communicatiestandaard voor elektronisch zakendoen tussen bedrijven en overheden.

Denemarken (National IT and Telecom Agency)
Denemarken heeft de invoering van elektronisch factureren vrij rigoureus aangepakt. Vanaf 1 februari 2005 mogen overheidsinstellingen in Denemarken - dit werd zo vastgelegd in de wetgeving - alleen facturen van leveranciers accepteren in een elektronisch formaat, de OIOXML Electronic Invoice. De OIOXML (Open public Information Online XML) Electronic Invoice is de Deense XML-standaard voor de elektronisch factuur gebaseerd op de eerste versie van UBL release 0.7. Voor meer informatie: OIOXML Electronic Invoicing.

Bedrijven kunnen op een aantal manieren facturen aanleveren:
1) via het aanmaken en verzenden van een elektronische factuur vanuit het fakturatiesysteem via de elektronische postbus van een Value Added Network (VAN).

2) via een Read-In Bureau die zorgdraagt voor het scannen en converteren van een papieren factuur naar het elektronische formaat en het verzenden van deze elektronische factuur naar de juiste overheidsinstelling via een Value Added Network.

3) via het handmatig invoeren van de factuur in een Internet Invoice Portal die zorgdraagt voor het aanmaken van de factuur in het elektronische formaat en het verzenden van deze elektronische factuur naar de juiste overheidsintelling via een Value Added Network

Schematisch ziet dit er op hoofdlijnen als volgt uit:

De Deense overheid stelt volgende eisen aan de informatie in de factuur:
- het gebruik van de EAN locatiecode voor identificatie van de klant is verplicht en de klant moet de EAN code verstrekken tijdens het plaatsen van de order
- een referentie naar de inkooporder of bestelling is verplicht
- een referentie naar de persoon die de order heeft geplaatst is verplicht
- interne identificatiecode van de klant is verplicht als deze verstrekt werd tijdens het plaatsen van de order

Let op: Denemarken maakt vooralsnog geen gebruik van de OIOUBL Invoice. De OIOUBL standaard wordt wel aanbevolen voor het uitwisselen van elektronische catalogi en inkooporders. OIOUBL is gebaseerd op UBL release 2.0 (Voor informatie: Online OIOUBL Documentation)

Noord-Europa
Northern European Subset (NES) is een intiatief dat voortvloeit uit de samenwerking tussen enkele Noord-Europese landen op het gebied van e-commerce en e-procurement. Onder aanvoering van Denemarken hebben vertegenwoordigers van de Noord-Europese landen Denemarken, Zweden, Noorwegen, Ijsland, Finland en van het Verenigd Koninkrijk begin 2007 een werkgroep opgericht voor het ontwikkelen van een Noord-Europese Subset (Northern European Subset (NES)) van op UBL 2.0 gebaseerde documenten.

De NES organisatie heeft de Universal Business Language (UBL) geselecteerd als de Open berichtenstandaard - met op dit moment de meeste potentie - voor het realiseren van grootschalige e-commerce en e-procurement handelstransacties tussen overheden onderling en bedrijven, zowel grensoverschrijdend (cross-border) als nationaal (domestic).

Het NES project richt zich niet op het uitvoeren van implementaties maar heeft als voornaamste doel zorgdragen voor het tot stand komen van een gezamelijk platform voor e-procurement.

De belangrijke resultaten van het NES project zijn:
- Profielen die bedrijfsprocessen en scenario’s beschrijven uitgaande van UBL voor handelstransacties
- Berichtdefinities gebaseerd op een gemeenschappelijke subset (deelverzameling) van UBL handelsdocumenten
- Handleidingen en codelijsten
- Validatiegereedschappen

De aangesloten landen zijn zelf verantwoordelijk voor de uitvoering en coördinatie van implementaties. De laatste versie van NES is op 11 juli 2007 vrijgegeven en kunt u terugvinden onder de rubriek Documents op de website van NES. Al het materiaal van NES is gepubliceerd onder de Creative Common license.

Zweden
In Zweden loopt het project Single Face To Industry (SFTI). Het is een alles-in-één e-procurement standaard waarmee het bestel- en facturatieproces tussen handelspartners wordt ondersteund.

Duitsland
In Duitsland is deze maand de German Localization Subcommittee (DELSC) samengesteld. Deze gaat zich buigen over de realisatie van een Duitse UBL Data Dictionary.

Spanje
CODICE is het Spaanse overheidsinitiatief voor het ontwikkelen van een verzameling elektronisch documenten gebaseerd op UBL voor de ondersteuning van het aanbestedingsproces. Vereenvoudigd zijn er drie processtappen die worden ondersteund: aankondigen of bekendmaken, aanbieden en gunnen.

ABILITIES
Het Europees project “Application Bus for InteroperabiLITy In enlarged Europe SMEs”, kortweg ABILITIES, is gestart begin 2006 en heeft een looptijd van 2 jaar. Het voornaamste doel van het project is het onderzoeken en ontwikkelen van een architectuur gebaseerd op UBL voor de ondersteuning van e-commerce transacties tussen kleine en middelgrote bedrijven (SMEs) voornamelijk in de minder ontwikkelde landen.

ABILITIES voorziet in drie interfaces:
- een Web portaal
- een GUI voor mobiele toegang
- een interface voor legacy systemen gebaseerd op web services

U.S. Department of Transportation (USDOT) Electronic Freight Management (EFM) initiatief
Het Electronic Freight Management (EFM) initiatief richt zich op de promotie en evaluatie van innovatieve e-business concepten. Het is een Research & Development project dat gesponsord wordt door de U.S. Department of Transportation (USDOT). De Electronic Freight Management (EFM) is geïmplementeerd op basis van de Freight Information Highway (FIH) architectuur. De FIH is een innovatieve non-propriëtaire service-georiënteerde architectuur voor de ondersteuning van de coördinatie tussen bedrijfsprocessen en veilige real-time gegevensuitwisseling.

Het EFM maakt gebruik van gestandaardiseerde berichten gebaseerd op UBL waaronder Advance Ship Notice, Dispatch Advice, Receipt Advice en Transportation Status.

Meer projecten en initiatieven staan op stapel en hierover zal ik later berichten.

Er worden vier vormen van elektronisch factureren onderscheiden:
1) Electronic Invoice Presentment (EIP) – Seller Direct variant

2) Electronic Invoice Presentment (EIP) – Consolidator variant

3) Electronic Invoice Presentment (EIP) – Buyer Direct variant

4) Electronic Invoicing (E-Invoicing of eInvoicing) variant

Elektronisch Factureren via Electronic Invoice Presentment (EIP) betreft het aanbieden van factuurinformatie in een leesbare vorm via het Internet (een webgebaseerde oplossing) in een Business-to-Business (B2B) Context, de zakelijke markt. Voor de consumenten markt (Business-to-Consumer context B2C) wordt de term Electronic Bill Presentment (EBP) gehanteerd. De wet- en regelgeving t.a.v. deze laatste verschilt in belangrijke mate van EIP ondermeer omdat een factuur niet verplicht gesteld wordt voor de levering van goederen of diensten aan particulieren.

In de Seller Direct variant stelt de verkoper de factuurinformatie in zijn eigen systeem via een webgebaseerde toegang beschikbaar aan de koper. De koper dient handmatig de factuurinformatie te verwerken in zijn eigen crediteurenadministratie en controle uit te voeren of de geleverde goederen of diensten overeenkomen met de factuur waarna de factuur betaalbaar gesteld kan worden. Via een aankondiging dient de koper op de hoogte gesteld te worden van de ontvangst van een factuur. Dit heeft te maken met de factureringsverplichting. (Zie mijn bloart Welke vormen van Elektronisch Factureren zijn in Nederland toegestaan ?)

In de Buyer Direct variant stelt de koper zijn eigen systeem via een webgebaseerde oplossing of toegang ter beschikking aan de verkoper ten behoeve van de overdracht van de factuurinformatie. De verkoper dient dan handmatig de factuurinformatie in te voeren in het systeem van de koper.

In de Consolidator variant stelt de verkoper de factuurgegevens ter beschikking aan een derde partij, de consolidator, waarna deze laatste op zijn beurt de gegevens ter beschikking stelt van de koper voor controle en verwerking

De E-Invoicing variant betreft de meest directe vorm van elektronisch factureren waarbij de informatie uit de factuur rechtstreeks en geautomatiseerd wordt overgedragen aan de gegevensverwerkende systemen waaronder ERP applicaties. Elektronisch factureren kan omschreven worden als het automatisch genereren van facturen uit ERP- en/of facturatiesystemen en/of opslagomgevingen, het automatisch verzenden van facturen in een gestandaardiseerd formaat gebaseerd op een internationale standaard (EDIFACT, UN/CEFACT CII, UBL, ETIX XML INVOICE) naar de klant waar de factuur eveneens automatisch verwerkt wordt in de crediteuren administratie.

Traditioneel worden bij deze vorm van factureren point-to-point verbindingen gerealiseerd tussen klanten en leveranciers en dienen beide partijen afspraken te maken over de Syntax: de structuur of opbouw van een bericht, de Semantiek: de omschrijving en betekenis van gegevenselementen en gehanteerde codes, de Business regels voor het verwerken van de factuur en het transportprotocol, de wijze van verzenden en ontvangen van berichten. Dit alles komt neer op het selecteren van een berichtstandaard voor het uitwisselen van factuurinformatie, het vastleggen van de betekenis van de aanwezige gegevenselementen en het definiëren of afspraken maken over codelijsten en het maken van afspraken het communicatieprotocol.

Deze vorm van elektronisch factureren wordt tegenwoordig eveneens ondersteund in een Consolidator – model waarbij een derde partij met elke partner afzonderlijk afspraken maakt over de gehanteerde syntax en semantiek, anders gezegd de berichtstandaard, het gebruik van gegevenselementen en het communicatieprotocol.

Afbakening van het begrip Elektronisch Factureren
Een belangrijk standpunt (conclusie) dat wordt ingenomen is dat het versturen of ontvangen van facturen in PDF – formaat volgens de definitie van het Forum Standaardisatie geen e-Factureren is. De eerder genoemde varianten zijn dat wel.

Samengevat zijn dat: het koppelen van informatiesystemen zodat factuurpartners facturen geautomatiseerd kunnen verwerken is dat wel. Dat kan via (1) directe, tweezijdige koppeling tussen ontvanger en verzender (e-invoicing), (2) via een eenzijdige oplossing waarin de verzender aan de ontvanger de factuur elektronisch of via Internet beschikbaar stelt (Electronic Invoice Presentment, EIP), en (3) via een derde partij die de factuur voor de verzender aan de ontvanger beschikbaar stelt (een ‘consolidator’).

Een ander belangrijk standpunt is dat het factuurproces niet los kan worden gezien van het totale order- en betalingsproces tussen twee partijen. Het traject van Elektronisch Bestellen en Factureren (EB&F) dat een aantal Overheden heeft ingezet als uitvloeisel van het project Professioneel Inkopen en Aanbesteden (PIA) zal naar (mijn) verwachting meer geaccepteerd worden door bedrijven. Immers dan wordt het volledige inkoop- en verkoopproces elektronisch ondersteund en levert dat beide partijen (leverancier en klant) voordelen en besparingen op.

De Belastingdienst is één van de Overheden die Elektronisch Bestellen en Factureren (EB&F) met leveranciers implementeert zowel met dienstverleners als met leveranciers van producten. De Belastingdienst heeft begin van de maand juli de eerste implementatie van EB&F op basis van HR-XML, de standaard voor inhuur van personeel, met een leverancier van ICT personeel succesvol afgerond. Met een drankje en hapje is dat vanavond gevierd. De Belastingdienst gaat nu verder met het aansluiten van uitzendbureau’s.

Op 1 januari 2004 werd de Europese richtlijn omgezet naar Nederlands recht, zie aankondiging op de website van het Ministerie van Financiën, maar helaas heeft dat niet geleid tot een sterke toename van Elektronisch Factureren. De Nederlandse Overheid gaat nu Elektronisch Factureren de komende jaren stimuleren met als streven om in 2010 tien procent van de facturen elektronisch te ontvangen en te verwerken. Uit de bevindingen van de Factuurmonitor 2008 blijkt dat het merendeel van de bedrijven en organisaties in Nederland eveneens de komende drie jaar willen overstappen op geautomatiseerde factuurverwerking. De Factuurmonitor is een onderzoek naar het gebruik van elektronisch factureren en geautomatiseerde factuurverwerking in Nederland en in Europa.

Het onderzoek geeft aan dat onduidelijke wet- en regelgeving de grootste belemmering vormt voor het in gebruik nemen van Elektronische Facturatie. Daarom is het goed om te eens te kijken naar hoe de Europese richtlijn in Nederland is vormgegeven en/of ingevuld. Het gaat dan met name over de wettelijke eisen en voorwaarden waaraan voldaan moet zijn.

De Europese richtlijn stelt dat elektronisch factureren toegestaan is mits:
1) De afnemer / koper heeft bevestigd een factuur in elektronisch formaat te willen accepteren.

2) De authenticiteit van de herkomst en de integriteit van de inhoud worden gewaarborgd door middel van:
• Een beveiligde elektronische handtekening ofwel een geavanceerde elektronische handtekening6. Lidstaten kunnen eisen dat de handtekening is voorzien van een goedgekeurd certificaat, de handtekening wordt dan een gekwalificeerde elektronische handtekening.

• EDI (Electronic Data Interchange)

• Een andere manier onder de voorwaarde dat de lidstaat dit goedkeurt

Opmerking: De Belastingdienst heeft op 17 november 2005 de eis laten vervallen om bij een EDI-factuur een afstemmingsoverzicht op papier aan te maken en deze vervolgens naar de ontvanger te versturen. Ondanks het feit dat deze eis is vervallen, adviseert de EDI Toetsing Commissie (ETC) het afstemmingsoverzicht te handhaven. Het afstemmingsoverzicht vormt voor de ontvanger namelijk een belangrijk hulpmiddel om te controleren of alle EDI-facturen ook daadwerkelijk zijn binnengekomen en of de factuurtotalen op het afstemmingsoverzicht overeenstemmen met de totalen van de EDI-facturen. Door middel van het afstemmingsoverzicht is de controleerbaarheid van de EDI-facturen goed uit te voeren.

In Nederland worden de volgende eisen gesteld aan Elektronisch Factureren:
1) De ontvanger of afnemer van de factuur moet vooraf akkoord gaan met elektronische facturatie.

2) De elektronisch factuur moet ten minste alle gegevens bevatten die wettelijk vereist zijn bij papieren facturen. Ga voor een overzicht van verplichte gegevens naar de website van de Belastingdienst, www.belastingdienst.nl. Kies Zakelijk en vervolgens “Omzet, btw en winst”. Selecteer daarna “Btw berekenen over uw omzet” en “Tijdstip van aangifte”. Onder “Onderdelen factuur” vindt u het overzicht van gegevens die op de factuur moeten staan.

3) De authenticiteit (echtheid) van de herkomst en de integriteit van de inhoud moet gewaarborgd zijn.
De afnemer moet er zeker van zijn dat de factuur werkelijk van de leverancier afkomstig is.
De leverancier en de afnemer moeten er zeker van zijn dat de factuur niet veranderd is.

4) De Belastingdienst moet de factuur kunnen controleren.

Verder gelden dat de regels voor de verschuldigdheid en aftrek van btw op een zelfde wijze moeten worden toegepast en het moment van uitreiken van de factuur wordt bepaald door de factuurdatum.

Vergeleken met papieren facturen zijn elektronische facturen makkelijker te veranderen zonder dat de afzender en/of ontvanger hier iets van merkt. De authenticiteit van de herkomst en de integriteit van de inhoud van de elektronische factuur moet in alle gevallen worden gegarandeerd. Bij een papieren factuur kunt u dat bereiken door gebruik te maken van facturen met een logo of een watermerk in het factuurpapier maar bij een elektronische factuur is zo’n watermerk - op dit moment - niet voorzien.

De Nederlandse Belastingdienst heeft analoog aan de Europese richtlijn 2001/115/EG een aantal voorwaarden gedefinieerd waaraan elektronisch verzonden facturen moeten voldoen. Deze voorwaarden zijn vertaald naar methoden voor elektronisch factureren die door de Belastingdienst zijn goedgekeurd. Als gebruik gemaakt wordt van één van deze methoden dan is voldaan aan de eis van authenticiteit en integriteit van de elektronisch factuur.

De Belastingdienst heeft de volgende methoden voor elektronisch factureren goedgekeurd:
1) Verzenden van facturen door gebruik te maken van een geavanceerde elektronische handtekening, het is niet verplicht gebruik te maken van een gekwalificeerde elektronische handtekening

2) Elektronische uitwisseling van gegevens via Electronic Data Interchange (EDI)
Electronic Data Interchange (EDI) is de geautomatiseerde, elektronische uitwisseling van gestructureerde en genormeerde berichten tussen computers van verschillende organisaties.

Een andere methode waarbij in ieder geval de authenticiteit van de herkomst en de integriteit van de inhoud is gewaarborgd is toegestaan mits deze is gemeld aan de inspecteur van de belastingdienst.

Bij het gebruik van een geavanceerde elektronisch handtekening geldt:
- de elektronische handtekening is op unieke wijze aan de ondertekenaar verbonden
- de elektronische handtekening maakt het mogelijk de ondertekenaar te identificeren
- de elektronische handtekening komt tot stand met middelen die de ondertekenaar onder zijn uitsluitende controle kan houden
- de elektronische handtekening is op zodanige wijze aan het elektronisch bestand waarop zij betrekking heeft verbonden, dat elke wijziging achteraf van de gegevens kan worden opgespoord.

De laatste jaren zijn een aantal vormen voor het aanbieden van digitale facturen meer in de belangstelling gekomen. Denk ondermeer aan Electronic Invoice Presentment (EIP) en het versturen van een factuur als een e-mailbericht of als bijlage bij een e-mail. In de consumentenmarkt is deze trend al jaren gaande (bijvoorbeeld: telefoon- en energierekeningen) en in de zakelijk markt vindt momenteel een behoorlijke inhaalslag plaats. Het aantal aanbieders van deze oplossingen voor de zakelijke markt is de laatste maanden enorm toegenomen. De belangrijkste vraag die gesteld moet worden is dan ook of deze vormen voldoen aan de eisen gesteld door de Belastingdienst.

(Wanneer) Voldoet Electronic Invoice Presentment (EIF) of Elektronische Factuurpresentatie aan de eisen gesteld door de Belastingdienst ?
Elektronische Factuurpresentatie wil zeggen dat de factuur aangeboden wordt aan afnemers via een website.
Voor toepassing van deze vorm van elektronische facturering geldt dat enerzijds de afnemer van de factuur deze vorm moet aanvaarden en anderzijds dat de authenticiteit en integriteit van de factuur gewaarborgd wordt.

Een ander belangrijk aspect in dit verband is de factureringsverplichting. Ondernemers zijn in principe verplicht een op juiste wijze opgemaakte factuur uit te reiken over hun met btw belaste leveringen en diensten aan andere ondernemers. Om aan de term uitreiken, officieel overhandigen, te kunnen voldoen zal een aankondiging naar de klant gestuurd moeten worden waarin verteld wordt dat de factuur beschikbaar is op de website en daar geraadpleegd of opgehaald kan worden.

Het waarborgen van de authenticiteit en integriteit van de factuur kan gebeuren door gebruik te maken van een geavanceerde elektronische handtekening.

Is het versturen van een factuur als bijlage bij een e-mail toegestaan ?
Voor het versturen van een factuur als e-mail of het opnemen van een factuur als bijlage bij een e-mail blijven de regels gelden. De afnemer moet deze vorm aanvaarden en er moet gebruik gemaakt worden van een geavanceerde elektronische handtekening.

Tip: Op de website van Factuurwijzer.nl kunt u meer antwoorden vinden op fiscale vragen over elektronisch factureren.

Met deze nieuwe vormen van het uitreiken van facturen aan klanten ontstaan automatisch vragen over de opslag van elektronische facturen en uitbesteden van het opmaken en/of verzenden van facturen door derden.

Welke voorwaarden worden gesteld aan de opslag van Electronische Facturen ?
De EU richtlijn maakt elektronisch factureren mogelijk maar de richtlijn laat in het midden hoe en hoe lang de leverancier en klant gegevens moeten bewaren.

In Nederland moet u als ondernemer alle gegevens uit uw geautomatiseerde administratie bewaren die belangrijk zijn voor de belastingheffing. Deze fiscale bewaarplicht geldt in principe voor een periode van zeven jaar. Bij de invoering van een systeem van elektronisch factureren is het dan ook belangrijk dat aandacht wordt besteed aan de wijze waarop de gegevens worden bewaard en hoe deze gegevens toegankelijk blijven.

De Belastingdienst heeft de brochure Uw geautomatiseerde administratie en de fiscale bewaarplicht” uitgebracht waarin beschreven staat waaraan voldaan moet worden. De Belastingdienst stelt dat facturen bewaard moeten worden in de vorm waarin de facturen zijn uitgestuurd of ontvangen. Elektronische facturen moeten dus als elektronisch bericht worden bewaard inclusief de digitale handtekening.

Welke voorwaarden worden gesteld aan het opmaken van een Electronische Factuur ?
De Belastingdienst stelt eisen aan de manier waarop de factuur wordt opgemaakt. Opmaken van een factuur door een derde partij is toegestaan maar de leverancier blijft verantwoordelijk voor de juistheid van de factuur. Tevens blijft de leverancier er verantwoordelijk voor dat degene die de factuur opmaakt deze op de juiste manier bewaart.

Voor het laten verzorgen van de transformatie van facturen van een interne bestandsformaat naar een extern formaat door derden. Hierbij is het belangrijk dat partijen (klant, leverancier) duidelijke afspraken maken over de wijze waarop partijen elektronisch gaan communiceren, bijvoorbeeld bij het gebruik van EDI, maakt men gebruik van een interchange agreement. Het onderling elektronisch uitwisselen van berichten vormt de
centrale bepaling (kernbeding) van de interchange agreement. Onderwerpen die worden geregeld in een interchange agreement zijn technische aspecten, zoals de berichtenstandaards en de benodigde telecommunicatievoorzieningen, beveiligingsaspecten, zoals de beveiliging van informatiesystemen en de encryptie van berichten, en juridische aspecten, zoals de bewijskracht van de elektronische registratie van berichten.

Het EIF is ontwikkeld onder het IDABC (Interoperable Delivery of European eGovernment Services to public Administrations, Business and Citizens) programma.

Interoperabiliteitsraamwerken in Europa
Vrijwel alle Europese overheden zijn druk bezig een bijdrage te leveren aan het ontwikkelen en inrichten van de elektronische overheid. Het uitgangspunt van de EIF is dat elke lidstaat beschikt over of actief werkt aan het ontwikkelen van een eigen Government Interoperability Framework (GIF).

Een aantal voorbeelden van raamwerken zijn terug te vinden op de volgende websites:
# BELGIF: BELgian Governement Interoperability Framework.

# UK e-GIF: UK e-Government Interoperability Framework.

# DIF: Danish e-Government Interoperability Framework.

Voor een overzicht van de Interoperabiliteitsraamwerken van alle Europese landen ga naar de website epractice.eu.

Interoperabiliteitsraamwerken buiten Europa
Ook buiten Europa werken overheden aan interoperabiliteitsraamwerken:
# Nieuw Zeeland: NZ E-government Interoperability Framework

# Australië: Australian Government Information Interoperability Framework

# Tasmanië: Interoperability Program

De verhoogde toename van het vrije verkeer van burgers en bedrijven in Europa vraagt om meer aandacht voor de ontwikkeling van de grensoverschrijdende dimensie van e-overheid. De informatiesystemen van lidstaten moeten steeds meer informatie onderling uitwisselen. Hierbij valt ondermeer te denken aan de uitwisseling van gegevens over verkeersovertredingen, diploma’s en justitiële veroordelingen.

Voor het verkrijgen van een eenduidig gezamenlijk beeld van de huidige en toekomstige Europese informatievoorziening en organisatiestructuur is een gemeenschappelijk referentiekader nodig voor alle betrokkenen. Het aanbrengen van structuur in deze complexe informatievoorziening gebeurt door het ontwerpen van een referentiekader waarin de samenhang tussen organisatie, processen, diensten, informatievoorziening en infrastructuur inzichtelijk wordt gemaakt. Naast de ontwikkeling van een referentiearchitectuur is een interoperabiliteitsraamwerk vereist waarin richting gegeven wordt aan de te hanteren standaarden.

Een interoperabiliteitsraamwerk bestaat uit een verzameling van standaarden, richtlijnen en regels die beschrijven op welke wijze bedrijven willen (of moeten) samenwerken. Het raamwerk is (moet) in staat (zijn) om mee te evolueren met technologische veranderingen, administratieve wijzigingen en nieuwe standaarden.

Het Europese Interoperabiliteitsraamwerk - European Interoperability Framework (EIF) voorziet in een dergelijke verzameling van richtlijnen en aanbevelingen die de interoperabiliteit van overheidssystemen en processen mogelijk maken ten behoeve van het leveren van pan-Europese elektronische overheidsdiensten (PEGS)

Het EIF identificeert een aantal algemene principes voor de levering van pan-Europese elektronische overheidsdiensten: toegankelijkheid, meertaligheid, security, privacy, subsidiariteit en het gebruik van open standaarden. Het raamwerk bespreekt verder de voordelen van Open Source Software.

Het EIF is ontwikkeld onder het IDABC (Interoperable Delivery of European eGovernment Services to public Administrations, Business and Citizens) programma.

Het EIF onderscheidt 3 niveaus van interoperabiliteit:
- Organisatorische interoperabiliteit
Deze vorm van interoperabiliteit houdt in dat kan worden vastgesteld welke spelers en organisatieprocessen nodig zijn voor de verlening van een specifieke e-overheidsdienst en dat zij onderling overeenstemming bereiken over de structuur van hun interacties, d.w.z. het vaststellen van hun “samenwerkingsverbanden”[

- Technische interoperabiliteit
Deze vorm van interoperabiliteit houdt in dat IT-systemen en software met elkaar worden verweven en dat er open interfaces, normen en protocollen worden gedefinieerd en gebruikt om betrouwbare, doelmatige en efficiënte informatiesystemen op te bouwen.

- Semantische interoperabiliteit (betekenis en formaat)
Deze vorm van interoperabiliteit zorgt ervoor dat de betekenis van de uitgewisselde informatie niet in het proces verloren gaat, en dat deze wordt bewaard en begrepen door de betrokken personen, toepassingen en instellingen.

Belangrijk is dat op al deze niveau’s afstemming nodig is en dat binnen en tussen deze drie niveau’s eveneens coördinatie noodzakelijk is.

Er bestaat niet één universele definitie voor het begrip Open Standaard.
Interoperabiliteit betekent samenwerking tussen systemen, diensten en mensen. Een vraag die automatisch opkomt is hoe realiseren en/of bevorderen we interoperabiliteit.

Door de jaren heen is het duidelijk geworden dat platform onafhankelijke en open standaarden het fundament vormen voor interoperabiliteit. Interoperabiliteit is vooral gebaseerd op afspraken vastgelegd in technische specificaties of in standaarden. Zuivere interoperabiliteit betekent connectiviteit gebaseerd op zuivere open standaarden die per definitie geen enkele software leverancier begunstigen.

Op de XML Cover Pages staan de definities en formuleringen van enkele voorname internationale instellingen en bedrijven zoals de Business Software Alliance (BSA) en Sun Microsystems.

De definitie van een Open Standard volgens de European Interoperability Framework (EIF) is eveneens opgenomen in deze lijst met definities.

Op de Engelse Wikipedia wordt de definitie van een Open Standaard volgens de European Interoperability Framework (EIF) vermeld naast 10 andere specifieke definities waaronder deze van de World Wide Web Consortium (W3C) en de International Telecommunication Union (ITU).

De definities van de W3C en de ITU hebben veel overeenkomsten onderling en met de EIF.

W3C en ITU komen op volgende punten overeen met elkaar:
# Collaborative process (ITU) - Transparancy (W3C), Openness (W3C)
# Reasonably balanced (ITU) - Impartiality and consensus (W3C), Openness (W3C)
# Due process (ITU) - Transparancy (W3C)
# Publicly available (ITU) - Availability (W3C)
# On-going support (ITU) - Maintenance (W3C)

Voor de volgende punten van de ITU definitie is de overeenkomst met W3C niet of in mindere mate terug te vinden:
# Intellectual property rights (ITU)
# Quality and level of detail (ITU)

Wat is de definitie van een Open Standaard volgens de EIF ?
De minimale eisen waaraan een Open Standaard moet voldoen volgens het Europese Interoperabiliteits Raamwerk (EIF) zijn:

1. De standaard is goedgekeurd en zal worden gehandhaafd door een not-for-profit organisatie, en de lopende ontwikkeling gebeurt op basis van een open besluitvormingsprocedure die toegankelijk is voor alle belanghebbende partijen (consensus of meerderheidsbeschikking enz.);

2. De standaard is gepubliceerd en over het specificatie document van de standaard kan vrijelijk worden beschikt of het is te verkrijgen tegen een nominale bijdrage. Het moet voor een ieder mogelijk zijn om het te kopiëren, beschikbaar te stellen en te gebruiken om niet of tegen een nominale prijs;

3. Het intellectuele eigendom - m.b.t. mogelijk aanwezige patenten - van (delen van) de standaard is onherroepelijk ter beschikking gesteld op een royalty-free basis;

4. Er zijn geen beperkingen omtrent het hergebruik van de standaard;

Wat is het verschil tussen Open Standaarden en Open Source ?
Het is goed om hier te benadrukken dat Open Standaarden en Open Source géén synoniemen zijn. Open Standaarden gaat over specificaties die de karakteristieken van een technologie beschrijven en publiekelijk beschikbaar zijn.

Open Source is een verzamelnaam voor alle software waarvan de broncode vrij beschikbaar gesteld wordt en waarbij in het licentiemodel het gebruik van de software alsook het gebruiken, verbeteren, uitbreiden en distribueren van de broncode geregeld wordt. Let op: Open source software mag vrijelijk gebruikt worden maar is geen publiek domein.

Standaarden en interoperabiliteit zijn onlosmakelijk met elkaar verbonden maar dat geldt niet of nauwelijks voor open source software.

Een aantal belangrijke vragen die ik de komende tijd wil beantwoorden zijn:
- Hoe realiseren of bevorderen we pan-Europese semantische interoperabiliteit ?

- Welke Open Standaarden zijn in gebruik binnen Europa ?

The goal was to get the people behind these communities motivated to provide the means and tools for managing Community projects. One of these will of course be the development of EDIFACT functionality.

Meanwhile the XAware Company has established a Sandbox environment for Community Members to start their development projects but moreover to enable knowledge transfer and share prebuilt transformation routines and connectors / adaptors.

The guidelines and procedures for contributing code to the core software are under development. These will include coding guidelines and standards, test and certification guidelines, contributor agreement required for developers wishing to contribute code to the project, acceptance criteria and procedures for the adoption into the core project.

One of the first Community projects will be the development of EDIFACT functionality. A short summary of the UN/EDIFACT message structure can be found in my bloart Short description of the EDIFACT Message Structure.

People from XAware-europe, Atos Origin, freelancers and private persons are participating on a voluntary basis to establish the first XAware Sandbox project, the EDIFACT functionality. Last week the functional requirements and technical design were discussed in the Netherlands based on a draft proposal from one of the participants.

The goal is to establish a generic approach that will become available for the whole community. The preliminary functional requirements and technical design are described hereafter. You are welcome to join us in the development of the EDIFACT functionality or to comment on the preliminary requirements and design approach.

Background
XAware is Data Integration Middleware provided under the Open Software Foundation approved GNU General Public License Version 2 GPLv2. People all over the world are using XAware technology for various projects and purposes. The main reasons for the popularity are:

1. Benefits of Open Source software.

2. XAware has an open architecture and Application Programming Interface (API)

3. Solutions can be implemented in a short period of time

4. Reusable integration solutions for message standards

The benefits of Open Source software are:
- Lower software licensing costs

- Avoidance of proprietary lock-in

- Compliance with accepted industry standards

- High innovation speed

- Freedom to study how the programs works and adapt it to your needs

- Freedom to run the program

To use XAware as a generic transformation tool in large scale B2B environments the support for EDIFACT and alike standards is imperative.

EDIFACT contains a standard set of message definitions used for particular business functions such as shipment, warehousing and invoicing. This standard has been around for at least two decades and is expected to be replaced by a suitable XML standard in the future. Support for EDIFACT will allow XAware technology to be used for EDIFACT integration and EDIFACT migration projects where EDIFACT is replaced by an XML standard.

Purpose
This document describes the functionality to be provided and/or developed for EDIFACT support in XAware.

User requirements:
1. XAware must support reading, processing and writing of EDIFACT messages

2. Supported EDIFACT messages and specifics are:

a. Message definitions from the UN/EDIFACT Standard Directories

b. Messages with zero or one Functional Group containing the contents of the message

c. XAware will not support customizing EDIFACT message structures such as adding or removing segments

d. Subsets of EDIFACT messages

e. Parts of EDIFACT messages

3. EDIFACT support should be built under (commercial) open source conditions, meaning that it is reusable for all customers and users in the community

4. The Project, project documentation and other artifacts should be made available through the XAware community site and forum. This helps the community awareness of the EDIFACT initiative and reuse of the solution.

5. EDIFACT messages must be readable from multiple channels (file, queue, ws, etc)

6. EDIFACT communication configuration must be done at EDIFACT directory level

7. XAware must support multiple versions of the EDIFACT directory provided by UN/ECE

8. XAware must provide a solution that enables reuse of mappings between various standards

9. A methodology for future integration/migration projects using the EDIFACT solution should be defined. This methodology should address the following requirements:

a. EDIFACT message discovery and exploration at business level

b. Mapping specification at business level

c. Mapping based on metadata (XML Schema Definition (XSD))

d. Reusable mapping components

e. Incremental process

f. Define the proper workflow in XAware designer to support this methodology

g. Select (or built in XAware) a powerful mapping facility (IDE) needed to support business consultants in defining the mapping from EDIFACT to other standards at the customer site

Functional requirements
1. XAware must read EDIFACT message definition from multiple files from the directory (edmd.zip, edsd.zip, eded.zip, edcd.zip, message definition)

2. XAware must implement logic to generate the corresponding EDIFACT XML XSD for a specified EDIFACT message definition.

3. XAware must map all messages to the corresponding ‘EDIFACT XML’ as the Common Information Model (CIM) and vice versa.

4. Reusable XAware mappings at segment level, composite data element and primitive data types

5. Separators for segments (‘’’), composite data elements (‘:’) and data elements (‘+’) should be made configurable. Reason is that the default values can be overridden in the message header.

6. The design of the solution should include a plug point for adding business logic (for validation or transformation)

7. The design of the segment processing logic should address

a. Filter(s) for removing and selecting optional sections

b. Handle qualified data elements and data types (composite data elements & primitive data type conversion)

c. Reuse components that map segments, composite data types and primitive data types (e.g date time mappings).

d. Allow for generation of a skeleton BizDocument that implements the processing logic

8. Performance requirements are not clear at this time. Process messages up till certain size under a second.

9. Scalability requirements are not clear at this time.
Rough estimate: Technology should be able to cope with Millions of messages per day?

Technical Design
This section describes the design, considerations and decisions for implementing the EDIFACT functionality.
The approach is to split development into two focus areas: the required XAware technology for working with the EDIFACT directories and the XAware scripts and process for building transformation routines.

XAware technology
1. Parser for reading EDIFACT message types and convert this to corresponding XML Schema Definition (XSD).

2. Instruction for processing messages in EDIFACT format similar to multi format instruction

a. Parsing of the messages using EDIFACT directory (or EDIFACT metadata included in BizComponent at design time)

b. Convert the message to corresponding XML structure that conforms to the generated EDIFACT XSD and deliver that in the response

3. User interface wizard to create an EDIFACT BizComponent based on directory version and message id.

4. Where do we want to place EDIFACT directory in the architecture?

XA script
Building blocks for the segment processing logic are:
1. BizComponent that reads the EDIFACT message and returns the corresponding EDIFACT XML

2. (Generated) BizDocument skeleton that maps EDIFACT XML to the source/target system.

a. Data type conversion logic?

b. Transformation logic?

c. Business logic?

3. XML mapper for handling repeatable groups in the EDIFACT XML

Wat wordt beoogd met de UN/CEFACT CCTS ?
De UN/CEFACT Core Components Technical Specification (CCTS) voorziet in een syntax-neutrale methodologie voor het ontwerpen en ontwikkelen van een verzameling semantische bouwstenen.

De specificatie richt zich op het aanbieden van een oplossingsgerichte aanpak voor het alom bekende interoperabiliteitsvraagstuk. H et ontbreken van informatieinteroperabiliteit tussen bedrijfsondersteunende systemen is al jaren één van de beperkende factoren in de realisatie van inter-enterprise collaboratieve bedrijfsprocessen en gegevensuitwisseling.

De UN/CEFACT CCTS vormt de basis voor het ontwikkelen van een grammaticataal waarmee organisaties nieuwe woordenboeken - Business vocabulaires - kunnen ontwikkelen. Deze nieuwe woordenboeken dragen bij tot het verbeteren en vereenvoudigen van de wijze waarop partijen overheen bedrijfsgrenzen (applicaties en systemen) en domeinen (sectoren) met elkaar elektronisch gegevens kunnen uitwisselen. Om interoperabiliteitsproblemen voorgoed uit te bannen is het gebruik van één generieke grammaticataal aanbevolen.

De UN/CEFACT draagt zorg voor de ontwikkeling en het onderhoud van een universele Core Component Library (CCL) en Data Type Catalogue met gratis toegang voor de Core Component gemeenschap.

Welke randvoorwaarden gelden ?
Voor de goede werking van het CCTS concept dienen alle standaardisatieinstellingen hun core componenten op te laten nemen in de Core Component Library (CCL) en/of hun libraries open te stellen voor anderen.

Momenteel hebben slechts een aantal standaardisatieinstellingen de CCTS aanpak onderschreven en gedeeltelijk doorgevoerd. OAGIS en OASIS Universal Business Language (UBL) hebben CCTS als basis genomen voor de ontwikkeling van hun berichtenbibliotheken. Andere standaarden die de CCTS aanpak hebben overgenomen zijn ondermeer RosettaNet, CIDX, HR-XML en ACORD.

Ik zal hierna beknopt de UN/EDIFACT Standaaard proberen uit te leggen. Achtereenvolgens zullen de volgende onderwerpen aan bod komen:
- enkele belangrijke karakters
- de verschillende structuurelementen
- een beschrijving van de structuur
- de positiebepaling, status en herhalende factor van structuurelementen
- de compressieregels

enkele belangrijke karaktertekens
- Segment einde teken = apostrophe ‘

- Segment tag en data element separator = plus sign +

- Component data element separator = colon :

- Release character = question mark ? herstelt de betekenis van het daaropvolgend teken
Voorbeeld: 10?+10=20 betekent 10+10=20

de structuurelementen
De structuur van een EDIFACT bericht is vastomlijnd en bestaat uit een aantal verplichte en optionele elementen. De belangrijkste bouwsteen van een EDIFACT bericht is het segment en de structuur waaraan een bericht moet voldoen is daarom vastgelegd in segment tabellen. Deze tabellen beschrijven welke segmenten in een bericht voorkomen en in welke volgorde.

Een eenvoudig voorbeeld van zo’n segment tabel ziet er als volgt uit: