Wordt UBL, de elektronische communicatiestandaard in Europa ?

In september 2001 is op voorstel van een aantal leden van OASIS (Organization for the Advancement of Structured Information Standards) waaronder Sun Microsystems, Commerce One, SAP en Boeing de OASIS Universal Business Language Technical Committee (UBL TC) opgericht. Het voornaamste doel van de UBL TC, voorgezeten door Jon Bosak (Sun Microsystems), was / is het ontwikkelen van een gratis bibliotheek van gestandaardiseerde elektronische op XML gebaseerde bedrijfsdocumenten.

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.

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 standaardisatie instellingen, 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 facturatie-systeem 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 overheidsinstelling 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 initiatief 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 gezamenlijk 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. Voor het bestelproces is sinds juni 2010 de CEN/BII Basic Order de aanbevolen standaard voor de publieke sector

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.

De specificaties van de CODICE standaard zijn terug te vinden op de website contrataciondelestado.es.

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.

Tags van Technorati: electronic data interchange,UBL,EDIFACT,UN/CEFACT,CEN/BII Government,enterprise service bus

Tags: electronic data interchange, Enterprise Service Bus, EDIFACT, Government, UBL, UN/CEFACT, CEN/BII

Last update: 3-12-2011

Definitie Elektronisch Factureren

In opdracht van het Forum Standaardisatie is een onderzoek uitgevoerd naar de stand van elektronisch factureren in Nederland. (Zie Eindrapport e-Factureren en standaarden voor e-invoicing in Nederland). Voor het verkrijgen van een gemeenschappelijk begrippenkader zijn hieronder een aantal van de voornaamste uitvoeringsvormen van elektronische factureren in Nederland geschetst.

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 web-gebaseerde 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 web-gebaseerde 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 web-gebaseerde 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 uitzendbureaus.

HR-XML, electronic data interchange, Overheid

Last update: 26-11-2011

Welke vormen van Elektronisch Factureren zijn toegestaan in Nederland

In december 2001 werd de Europese richtlijn 2001/115/EG goedgekeurd. Deze richtlijn gaat over de vereenvoudiging, modernisering en harmonisering van de ter zake van de facturering geldende voorwaarden op het gebied van de belasting over de toegevoegde waarde. In de richtlijn wordt een geharmoniseerde lijst vastgesteld van verplichte vermeldingen die een factuur moet bevatten en worden een aantal gemeenschappelijke voorwaarden voor elektronische facturering, elektronische opslag van de facturen, eigenhandige facturering en uitbesteding van de factureringswerkzaamheden vastgelegd.

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 handtekening. 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 Elektronische 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 Elektronische 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.

Tags: e-Factureren, Overheid

Last update: 26-11-2011

European Interoperability Framework (EIF)

Het Europese Interoperabiliteitsraamwerk (EIF)

De elektronische overheid (e-overheid) valt niet meer weg te denken in de huidige Internetmaatschappij. De e-overheid biedt burgers, bedrijven en overheidsinstellingen een nieuw communicatiekanaal om met elkaar in gesprek te gaan. Door het toepassen van informatie- en communicatietechnologie (ICT) kunnen de administratieve lasten van burgers en bedrijfsleven worden verminderd en de kwaliteit van de dienstverlening worden verbeterd.

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 IDABC programma liep tot 31 December 2009 en is daarna opgevolgd door het ISA programma (Interoperability Solutions for European Public Administrations).

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 niveaus afstemming nodig is en dat binnen en tussen deze drie niveaus 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 Standaard 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 Interoperabiliteitsraamwerk 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 ?

Tags: Overheid, Interoperability-Frameworks

Last update: 26-11-2011

UN E-Government Readiness Survey (EN)

The European Interoperability Framework (EIF is a set of guidelines and recommendations to enable interoperability of government systems and processes with a view to delivering pan-European e-Government services (PEGS).

The EIF is developed under the IDABC (Interoperable Delivery of European eGovernment Services to public Administrations, Business and Citizens) program. The IDABC program lasted till 31 December 2009 and has been superseded by the ISA program (Interoperability Solutions for European Public Administrations).

What is the ISA program ?
Public administrations are expected to provide efficient public services to businesses and citizens across Europe. ISA, the programme on Interoperability Solutions for European Public Administrations, addresses this need. ISA supports and facilitates efficient and effective cross-border electronic collaboration between European public administrations. The programme enables the delivery of electronic public services and ensures the availability, interoperability, re-use and sharing of common solutions.

Interoperability Frameworks in Europe
Almost all European Governments are in the process of developing and implementing the electronic government. The starting point of the EIF is that each member state has or is actively working on the development of its national Government Interoperability Framework (GIF).

A few examples of frameworks are available on the next websites:
# BELGIF: BELgian Governement Interoperability Framework.

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

For a complete overview of the Interoperability Frameworks of all European countries visit the website epractice.eu. Another overview of e-Government initiatives in Europe can be found on Wikipedia: eGovernement in Europe.

Interoperability Frameworks outside Europe
Also governments outside of Europe are working on developing interoperability frameworks:

# New Zealand: NZ E-government Interoperability Framework

# Australia: Australian Government Information Interoperability Framework

# Tasmania: Interoperability Program

The role of the United Nations
The United Nations plays an important role in the promotion of the Interoperability Frameworks. Regularly the United Nations examines the Interoperability Frameworks of the connected countries. The results of the investigation are published on the United Nations Online Network in Public Administration and Finance (UNPAN).

The United Nations Online Network in Public Administration and Finance (UNPAN) is a virtual electronic network that promotes the exchange of expertise and sharing of experiences and lessons learned in public administration and finance at local, national, sub regional, regional and international levels.

On the website of the UNPAN you can find the E-Government Readiness Knowledge Base of the United Nations . The United Nations E-Government Readiness Knowledge Base (UNKB) is a benchmarking tool that provides a comparative assessment for monitoring progress of a country’s e-government readiness.

Yearly the United Nations publishes the Survey e-government readiness. At the begin of the year (2008) the Division for Public Administration and Development Management (DPADM) of the United Nations Department of Economic and Social Affairs (UNDESA) published the UN E-Government Survey 2008: From E-Government to Connected Governance. The survey assesses the e-government readiness of the 192 Member States of the UN according to a quantitative composite index of e-readiness based on website assessment, telecommunication infrastructure, and human resource endowment.

The Scandinavian countries (Sweden, Denmark and Norway) took the top three in the survey followed by the United States. The European countries made up 70 per cent of the top 35 countries with the Netherlands ranked fifth.

The survey can be found on the website of the United Nations Public Administration Network (UNPAN). Open the top level menu Library, go to the option Major Publications and select the item UN E-Government survey.

Last year (2007) the regional centre for the Asia-Pacific of the United Nations Development Program (UNDP) in Bangkok has investigated the Interoperability Frameworks of seven countries including Australia, New Zealand, UK and Denmark. The analysis has been performed under the Asia-Pacific Development Information Programma (APDIP).

The comparisons are intended to provide supplementary information for countries interested in developing their own Governement Interoperability Framework (GIF) and/or updating an existing framework.

During the investigation the focus has been on how Government Interoperability Frameworks (GIFs) in different countries are developed, implemented and maintained. The emphasis has been on the sections: Context, Technical Content, Development Process, Implementation and Compliance.

The Context includes the definition of the GIF, aims of the document, principles that support the selection of standards, scope and limitations, agencies bound by the specifications of the GIF, and the relationship of the GIF with other government documents.

The Technical Content contains the standards and recommendations of the GIF regarding the development of ICT systems and contains a listing of the standards categorized according to the defined interoperability layers.

The Implementation describes the support tools that are provided and/or being developed to aid the widespread adoption of the GIF.

The Compliance references indicators for interoperability, strategies for ensuring compliance, and additional guidance for stakeholders that are provided.

The results are presented in the document e-Government Interoperability: A review of Government Interoperability Frameworks in Selected Countries (GIF-Review.pdf).

Tags: Government, Interoperability-Frameworks

Last update: 26-11-2011

UN E-Government Readiness Survey (NL)

Het Europese Interoperabiliteitsraamwerk - European Interoperability Framework (EIF) is een 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 is ontwikkeld onder het IDABC (Interoperable Delivery of European eGovernment Services to public Administrations, Business and Citizens) programma. Het IDABC programma liep tot 31 December 2009 en is daarna opgevolgd door het ISA programma (Interoperability Solutions for European Public Administrations).

Wat is het ISA programma ?
Public administrations are expected to provide efficient public services to businesses and citizens across Europe. ISA, the programme on Interoperability Solutions for European Public Administrations, addresses this need. ISA supports and facilitates efficient and effective cross-border electronic collaboration between European public administrations. The programme enables the delivery of electronic public services and ensures the availability, interoperability, re-use and sharing of common solutions.

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.

Voor een overzicht van de Interoperabiliteitsraamwerken van alle Europese landen ga naar de website epractice.eu. Een anderoverzicht van e-Government initiatieven in Europa kunt u terugvinden op Wikipedia: eGovernement in Europe.

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

Rol van de Verenigde Naties
De Verenigde Naties speelt een belangrijke rol in de promotie van de Interoperabiliteitsraamwerken. Zo verricht de Verenigde Naties jaarlijks onderzoek naar de interoperabiliteitsraamwerken van de aangesloten landen en stelt deze onderzoeksresultaten beschikbaar via het United Nations Public Administration Network (UNPAN).

De UNPAN is een virtueel elektronisch netwerk ter promotie van het uitwisselen en delen van kennis, ervaring en "lessons learned" in publieke administraties en financiën op lokaal, nationaal, regionaal en internationaal niveau.

Op de website van de UNPAN kunt u de E-Government Readiness Knowledge Base van de Verenigde Naties vinden. De Knowledge Base is een benchmark tool waarmee de gereedheid voor e-overheid van een land gevolgd kan worden in vergelijking met andere landen.

Jaarlijkst publiceert de Verenigde Naties de Ranglijst e-overheid readiness. De Divisie voor Public Administration and Development Management (DPADM) van het Departement Economische en Sociale Zaken van de Verenigde Naties (UNDESA) heeft begin van het jaar (2008) de UN E-Government Survey 2008: From E-Government to Connected Governance gepubliceerd. Dit onderzoek maakt de balans op van de gereedheid van de e-overheid in de 192 lidstaten van de Verenigde Naties op basis van een aantal kwantitatieve indicatoren. Daarbij werd gekeken naar webtoegankelijkheid en internetpenetratie, de telecommunicatie infrastructuur en de opleidingsgraad van burgers.

De top 3 van landen die het best zijn voorbereid op e-overheid zijn de Scandinavische landen Zweden, Denemarken en Noorwegen gevolgd door de Verenigde Staten. De Europese landen nemen 70 procent in van de top 35 landen in de ranglijst, met Nederland op de vijfde plaats.

Het onderzoeksrapport kun u vinden op de website van de United Nations Public Administration Network (UNPAN). Open het menu Library, ga naar de optie Major Publications en selecteer het onderwerp UN E-Government survey.

Vorig jaar (2007) heeft het regionale kantoor voor de Asia-Pacific van de ontwikkelingsorganisatie van de Verenigde Naties (UNDP - United Nations Development Programma) in Bangkok een vergelijkend onderzoek uitgevoerd naar de Interoperabiliteitsraamwerken van zeven landen waaronder Australië, Nieuw Zeeland, UK en Denemarken. Deze vergelijkende analyse werd uitgevoerd als onderdeel van het Asia-Pacific Development Information Programma (APDIP).

De vergelijkende analyses zijn bedoeld om meer en additionele informatie beschikbaar te stellen aan landen die een Interoperabiliteitsraamwerk - Government Interoperability Framework (GIF) - willen ontwikkelen en/of een bestaand raamwerk willen upgraden / verbeteren.

Tijdens het onderzoek is voornamelijk gekeken naar hoe de Government Interoperability Frameworks (GIFs) in de verschillende landen tot stand zijn gekomen, zijn geïmplementeerd en worden onderhouden. Daarbij is met nadruk onderzoek gepleegd naar de invulling van de onderdelen: Context, Technische Inhoud, Development Process, Implementatie en Compliance.

De Context gaat over de definitie en het doel van de GIF, de principes voor het selecteren van standaarden, het bereik en de beperkingen, de organisatie die zich dienen te houden aan de specificaties van de GIF en de relatie van de GIF met andere overheidsdocumenten.

De Technische Inhoud heeft betrekking op de standaarden en aanbevelingen van de GIF voor de realisatie van informatie- en communicatie systemen en bevat een lijst met standaarden gegroepeerd naar de gehanteerde interoperabiliteitslagen.

Het Development Process betreft het proces van ontwikkelen, goedkeuren en implementeren van de GIF. Daarbij is gekeken naar de stappen die doorlopen werden voor het ontwikkelen van de GIF, de organisaties die daarbij betrokken zijn, en stappen die gevolgd moeten worden voor het updaten van de GIF.

De Implementatie beschrijft de ondersteunende gereedschappen die beschikbaar worden gesteld of ontwikkeld ten behoeve van de algemene (wijdvertakte) acceptatie van de GIF.

De Compliance bespreekt het gebruik van indicatoren voor het meten van interoperabiliteit, de strategieën voor het borgen van de naleving van het raamwerk en de richtlijnen voor belanghebbenden.

De resultaten van het onderzoek staan beschreven in het document e-Government Interoperability: A review of Government Interoperability Frameworks in Selected Countries (GIF-Review.pdf).

Tags: Government, Interoperability Frameworks

Last update: 26-11-2011

the XAware Sandbox EDIFACT project requirements

A few weeks ago I wrote about the missing support for EDIFACT and derived standards in Open Source XML-based Transformation Tools such as XAware and Chainbuilder.

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

. 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

Tags van Technorati: electronic data interchange,eclipse,data mapping tool,EDIFACT

Last update: 26-11-2011