Using the power of OOXML for bringing electronic invoicing to SME's

During the past years Albalia Interactiva, a Spanish consulting firm, has developed solutions for managing XML-based invoices using Microsoft Office. Albalia Interactiva is a company specialized in systems that provide legal certainty for electronic transactions.

In 2009 Albalia has developed an add-in for Microsoft Word 2007, called FactOffice, that enables the management (issuing, receiving and visualizing) of electronic invoices based on the Spanish XML format Facturae.

In 2010 Albalia upgraded the functionality to Microsoft Office 2010 (Word and Excel), rebranded the name to OffInvoice and extended the supported XML formats. Now the solution supports Facturae V3.1 and V3.2, UBL (Universal Business Language) and the UN/CEFACT Cross Industry Invoice, commonly known as CII.

Both solutions are developed as an extension to the Ribbon User Interface, the task-oriented Graphical User Interface (GUI) introduced in Office 2007, and the solutions are available as open source projects on CodePlex (the Open Source Project Community site hosted by Microsoft).

There are three licenses involved:

- For the Add-in there is a Dual licensing approach:
Microsoft Public License (Ms - PL)
European Union Public Licence (EU-PL)

- For the bouncycastle library: The Legion of Bouncycastle http://www.bouncycastle.org/licence.html

- For the Backtrust signature library developed by Albalia Interactiva S.L.: http://www.backtrust.net/index.php?page=backtrust-for-offinvoice-license

The solutions use Word or Excel as a template for capturing data in the case of issuing and visualizing in the case of receiving. Additionally they enable the validation of and signing with electronic signatures in XAdES-EPES (Explicit Policy Electronic Signatures) and XAdES-X-L (Extended Long-term Signatures) formats (XAdES).

For installing the add-in download the installer for FactOffice or OffInvoice from the CodePlex site, choose FactOffice.Codeplex.com or OffInvoice.CodePlex.com. But first check the requirements to find out what software is required to run the solution.

The approach taken by Albalia uses the power of the Microsoft Office Open XML (OOXML) format and complies with the multi-purpose exchange format I described in a bloart of October 2009. In this weblog article I present the multi-purpose exchange standard as a solution for opening Electronic Invoicing on a larger scale to all companies.

Tags: Adobe XML Data Package (XDP), Open Document Format (ODF), Office Open XML (OOXML), UBL, e-Invoicing, UN/CEFACT

Last update: 24-11-2011

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

Waarop berust de interoperabiliteitsoplossing van de UN/CEFACT CCTS ?

De UN/CEFACT Core Components Technical Specification (CCTS en ISO 15000-5) is ontwikkeld door de UN/CEFACT Techniques and Methodologies Group (TMG), één van de permanente werkgroepen van de UN/CEFACT. De voornaamste taak van de UN/CEFACT TMG is het ontwikkelen van informatie- en communicatietechnologie specificaties en aanbevelingen ten behoeve van de andere UN/CEFACT werkgroepen. De UN/CEFACT TMG groep heeft eveneens de UN/CEFACT Modelling Methodology (UMM) ontwikkeld.

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.

Welke benadering volgt de CCTS voor het oplossen van het interoperabiliteitsvraagstuk ?
De benadering van de Core Components Technical Specification gaat uit van algemeen geaccepteerde en publiekelijk beschikbare Core Components en daarop gebaseerde Business Information Entities. De meest elementaire informatiedeeltjes voor het assembleren van de core componenten en informatieentiteiten, tot en met een volledig bedrijfsdocument, zijn de Core Data Types (CDTs).

Het fundament voor de interoperabiliteitsoplossing van de UN/CEFACT Core Components Technical Specification wordt gevormd door de Core Data Types (CDTs) en de Business Data Types (BDTs) die zijn vastgelegd in de Data Type Catalogue van de UN/CEFACT. Al de andere Core Components en Business Information Entities zijn op deze elementaire informatiedeeltjes gebaseerd.

Het feit dat al de standaardisatieinstellingen die de CCTS aanpak hebben onderschreven hun berichtenbibliotheken eveneens baseren op deze elementaire informatiedeeltjes en gebruik maken van de Data Type Catalogue legt de basis voor de toekomst.

De OAGIS en de OASIS UBL standaarden hebben de Core Data Types en Business Data Types overgenomen als een verzameling van Unqualified Data Types (UDT) in aanvulling op de eigen specifieke data types. Aangezien de UN/CEFACT CCTS pas recent is ontwikkeld hebben deze instellingen de nodige achterstand in het inpassen van de CCTS concepten in hun standaarden. Het moet echter gezegd dat in feite de OASIS UBL standaard de voorloper is geweest van de UN/CEFACT CCTS.

Basisprincipes van de CCTS Data Types
Er zijn twee soorten Data Types: Core Data Types (CDT) en Business Data Types (BDT).

De Core Data Types identificeren de meest elementaire stukjes bedrijfsinformatie en worden beschouwd als generieke data types. Elke Core Data Type bestaat uit een Content Component en één of meer Supplementary Components.

De Content Component is de drager van de actuele waarde en de Supplementary Component geeft betekenis aan deze waarde. Elke Content Component en Supplementary Component is afgeleid van slechts één Primitive Type welke het Value Domain, de verzameling toegestane waarden, vastlegd. Het Value Domain van de Content Component bepaalt de verzameling van toegestane waarden van de Core Data Type die verder nog beperkt kunnen door de gedefinieerde Supplementary Components.

De Core Data Types bepalen het karakter van de inhoud van een Core Component (CC). De Business Data Types doen dat voor een Business Information Entity (BIE).

Voorbeeld:
Het Core Data Type <em>Amount.Type</em> bevat een Content Component die de waarde met zich meedraagt en een Supplementary Component die betekenis geeft aan de waarde.

CDT = Amount. Type
Primitive = Decimal
Content Component = 12 (Amount. Content)
Supplementary Component = EUR (Amount. Currency. Code)

De Core Components Technical Specification voorziet in een vaste lijst van Core Data Types opgenomen in de Data Type Catalogue. Deze catalogus bevat de lijst van door de UN/CEFACT toegestane Representation Terms, Core Data Types en Business Data Types.

De lijst van Core Data Types bevat ondermeer de types Amount. Type, Binary. Object. Type, Code. Type, Date. Type, Date. Time. Type, Duration. Type, Graphic. Vector, Identifier. Type, enzovoort.

Focusgebieden van de CCTS zijn:
De Core Component Technical Specification richt zich op twee gebieden:
- Core Components (CC's):
Core Components zijn de semantische bouwstenen, conceptueel van aard, voor het ontwikkelen van data- en informatiemodellen.

- Business Information Entities (BIE's):
Business Information Entities zijn context-specifieke toepassingen of afbeeldingen van conceptuele core components binnen een bedrijfsdomein. BIE's worden altijd afgeleid van CC's.

Belangrijk uitgangspunt voor de methodologie is het gebruik van de Dictionary Entry Name (DEN). Dit is de unieke officiële naam van een core component in het woordenboek. De CCTS schrijft voor dat voor de naamgeving (Dictionary Entry Name) van de Core Componenten de Oxford English Dictionary gevolgd dient te worden. Hetzelfde geldt voor de andere componenten uit de Core Component Technical Specification.

De Core Components Technical Specification biedt bedrijven een semantische basis voor de ondersteuning van verschillende XML-talen voor elektronische communicatie. Door het gebruik van CCTS kunnen semantisch equivalente componenten eenvoudiger gemapped worden tussen verschillende bibliotheken.

Hoe ver staat het met het oplossen van het interoperabiliteitsvraagstuk ?
In de UBL Developers Community antwoordt Mark Crawford op mijn vraag op welke wijze CCTS de interoperabiliteit tussen één of meer communicatiepartners, standaarden en systemen bevordert als volgt:

“CCTS richt zich op het bereiken van universele semantische interoperabiliteit van Business Information via één enkel conceptueel data model en daarvan afgeleid diverse contextspecifieke logische data modellen.”

Dit betekent dat de noodzakelijke interoperabiliteit alleen gerealiseerd kan worden wanneer naast het gebruik van de Data Type Catalogue en de Core Component Library (CCL) eveneens de datamodellen van de verschillende standaarden worden afgeleid van het CCTS conceptuele data model.

Vermoedelijk zal dit niet binnen nu en enkele jaren worden gerealiseerd omdat dit vrij ingrijpend is. Ik geloof niet dat de standaardisatieinstellingen en andere organisaties bereid zijn om hun gevolgde aanpak en knowledge base op te geven ten gunste van de interoperabiliteit. Er zullen andere iniatieven worden opgestart die minder ingrijpend zijn en verder borduren op de CCTS of een totaal andere invalshoek hanteren (web ontology).

Eén ding is zeker, we staan wel met zijn allen achter het idee dat Informatieinteroperabiliteit gerealiseerd moet worden door een gemeenschappelijk begrip van de betekenis van gegevens maar de wijze waarop dit tot stand moet komen is nog niet definitief bepaald.

Wanneer het toch ooit zover komt en het gekozen principe(s) ingebed kan worden in systemen en applicaties dan zal interoperabiliteit gemeengoed zijn. Ik blijf de ontwikkelingen op de voet volgen en zal hier binnenkort op doorgaan.

Tags van Technorati: electronic data interchange,UDEF,CCTS,UN/CEFACT

Last update: 26-11-2011

How do we solve the interoperability question ?

For realizing integration between business processes and -systems it is of great importance that a solution is found for the interoperability question. The core of the issue is the lack of information interoperability between business support systems. For years it is one of the mitigating factors in the realization of inter-enterprise collaborative business processes and information exchanges.

For overcoming the problems surrounding the transformation of information elements between different standards, the last few years two approaches are worked out:
- de UN/CEFACT Core Components Technical Specification (CCTS)

- Universal Data Element Framework (UDEF)

The UN/CEFACT Core Components Technical Specification (CCTS) is a syntax-neutral methodology for developing a common collection of semantic building blocks of information elements. The Core Components Technical Specification is based on ISO 15000-5 (ebXML Core Components Technical Specification).

This specification wants to provide a solution-oriented approach for the well-known interoperability question. The Core Components Technical Specification defines a semantic basis for XML Standards.

The specification focuses on two areas:

- Core Components (CC’s):
Core Components are semantic building blocks, conceptual in nature, for developing data- and information models.

- Business Information Entities (BIE’s):
Business Information Entities are context-specific applications or expressions of conceptual core components within a business domain. BIE’s are always derived from CC’s.

The UN/CEFACT develops and maintains a universal Core Component Library (CCL) that is freely available to the entire Core Component community. The UN/CEFACT would like to make a contribution to improving and simplifying the way parties beyond corporate boundaries (applications and systems) and domains (sectors) exchange information with each other. The Core Component Library contains only Business Information Entities.

A number of important principles and rules that should be endorsed are:

- The use of the Dictionary Entry Name (DEN):
The Dictionary Entry Name (DEN) is the unique official name of a Core Component and of a Business Information Entity in the dictionary. The CCTS prescribes that the Oxford English Dictionary shall be followed for the naming convention (Dictionary Entry Name).

- Assigning Unique Identifiers to instances of Core Components:
The Unique Identifier ensures that a Core Component and a Business Information Entity can be referenced in a unique way.

To ban all interoperability problems permanently standardization institutes should adhere to the CCTS approach and rules. Moreover the Core Components of these institutes should be included in the Core Component Library (CCL) with a unique identifier.

Only then it is possible to establish straightforward and possibly in the future automatic transformations between different standards. The standards that are currently based on the CCTS have for the greater part complied with the development and use of Core Components and Business Information Entities.

XML Standards based on the Core Components Technology Specification are among others:
- OASIS Universal Business Language (UBL)
- Open Applications Group (OAGIS)
- UN/CEFACT

Unfortunately the institutions assign different names to Business Information Entities that represent the same objects. Thus it remains difficult to draw unique and uniform transformation rules.

The other approach that can be followed is that of the Open Group, the Universal Data Element Framework (UDEF). The Universal Data Element Framework is an implementation of the naming conventions as specified by the International Standardization Organization for Metadata Registries (MDR) in the document ISO/IEC 11179. The UN/CEFACT Core Components Technology Specification naming convention rules are also based on the ISO 11179 specification.

The UDEF is a method for categorizing information elements by means of assigning an alphanumeric key (tag) and a simple name to the data. The full UDEF ID of an information element is determined by looping through the UDEF Tree which consists of Objects and Properties.

For the information element Purchase Order Document Number this results into:
UDEF Tag = “d.t.2_8” and the UDEF Name = “purchase.order.document_identifier”.

The tree structure of the Object “Purchase Order Document” is composed of:
Document (tag 2)
- Order (tag t).
- Purchase (tag d).

The tree structure of the Property is composed of:
Identifier (tag 8 )

To get a better view of, on the one hand, the complexity of the use of the CCTS by different standardization institutes and on the other hand the problems of drafting transformation rules I will work out the transformation of an invoice into different standards on the basis of UN/CEFACT Cross Industry Invoice (CII) specification drawn up by the UN/CEFACT in collaboration with different industry sectors.

Read more in my bloart: Transformation definitions for the electronic invoice.

Tags: electronic data interchange, UDEF, CCTS, UN/CEFACT

Last update: 26-11-2011

Hoe lossen we het interoperabiliteitsvraagstuk op ?

Voor het realiseren van integratie tussen bedrijfsprocessen en -systemen is het van groot belang dat een oplossing wordt gevonden voor het interoperabiliteitsvraagstuk. De kern van het vraagstuk is het ontbreken van informatie interoperabiliteit tussen bedrijfsondersteunende systemen. Al jaren is het één van de beperkende factoren in de realisatie van inter-enterprise collaboratieve bedrijfsprocessen en gegevensuitwisseling.

Voor het doorbreken van de problematiek rondom de transformatie van informatie elementen tussen verschillende standaarden zijn de laatste jaren een tweetal benaderingen uitgewerkt:
- de UN/CEFACT Core Components Technical Specification (CCTS)

- Universal Data Element Framework (UDEF)

De UN/CEFACT Core Components Technical Specification (CCTS) is een syntax-neutrale methodologie voor het ontwikkelen van een gemeenschappelijke verzameling semantische bouwstenen of informatie elementen. De Core Components Technical Specification is gebaseerd op de ISO 15000-5 (ebXML Core Components Technical Specification).

Deze specificatie wil een oplossingsgerichte aanpak bieden voor het alom bekende interoperabiliteitsvraagstuk. De Core Components Technical Specification definieert een semantische basis waarop XML Standaarden gebaseerd kunnen worden.

De specificatie richt zich op twee gebieden:

- Core Components (CC’s):
Core Components zijn de semantische bouwstenen, conceptueel van aard, voor het ontwikkelen van data- en informatiemodellen.

- Business Information Entities (BIE’s):
Business Information Entities zijn context-specifieke toepassingen of afbeeldingen van conceptuele core components binnen een bedrijfsdomein. BIE’s worden altijd afgeleid van CC’s.

De UN/CEFACT ontwikkelt en onderhoudt een universele Core Component Library (CCL) met gratis toegang voor de Core Component gemeenschap. Hiermee wil de UN/CEFACT een bijdrage leveren aan het verbeteren en vereenvoudigen van de wijze waarop partijen overheen bedrijfsgrenzen (applicaties en systemen) en domeinen (sectoren) met elkaar elektronisch gegevens kunnen uitwisselen. De Core Component Library bevat alleen Business Information Entities.

Een aantal belangrijke uitgangspunten en regels die onderschreven moeten worden zijn:

- Het gebruik van de Dictionary Entry Name (DEN):
De Dictionary Entry Name (DEN) is de unieke officiële naam van een Core Component en van een Business Information Entity in het woordenboek. De CCTS schrijft voor dat voor de naamgeving (Dictionary Entry Name) de Oxford English Dictionary gevolgd dient te worden.

- Het toekennen van Unique Identifier aan instanties van Core Components:
De Unique Identifier zorgt ervoor dat naar een Core Component en een Business Information Entity op een unieke wijze gerefereerd kan worden.

Om alle interoperabiliteitsproblemen nu voorgoed uit te bannen dienen alle standaardisatie instellingen de CCTS benadering en regels door te voeren en te volgen. Daarenboven moeten de Core Componenten van deze instellingen eveneens opgenomen worden in de Core Component Library (CCL) met een unieke identifier.

Alleen dan wordt het mogelijk om in de toekomst eenvoudig en misschien zelfs automatisch transformaties tussen verschillende standaarden te realiseren. De standaarden die momenteel zijn gebaseerd op de CCTS hebben zich grotendeels geconformeerd aan de ontwikkeling en het gebruik van Core Components en Business Information Entities.

XML Standaarden gebaseerd op de Core Components Technology Specification zijn ondermeer:
- OASIS Universal Business Language (UBL)
- Open Applications Group (OAGIS)
- UN/CEFACT

Helaas hanteren de instellingen voor de naamgeving van de Business Information Entities verschillende namen voor dezelfde objecten. Daardoor blijft het moeilijk om eenduidige uniforme transformatieregels op te stellen.

De andere benadering die gevolgd kan worden is deze van de Open Group, de Universal Data Element Framework (UDEF). Het Universal Data Element Framework is een uitvoering van de naamgeving conventies zoals gespecificeerd door de International Standardization Organization for Metadata Registries (MDR) in het document ISO/IEC 11179. De UN/CEFACT Core Components Technology Specification naamgeving regels zijn eveneens gebaseerd op de ISO 11179 specificatie.

De UDEF is een methode voor het categoriseren van informatie elementen door middel van het toekennen van een alfanumerieke sleutel (tag) en een eenvoudige naam aan een gegeven. Het volledige UDEF ID van een informatie element wordt bepaald door het doorlopen van de UDEF Tree bestaande uit Objecten en Properties.

Voor het informatie element Inkoop Order Nummer (Purchase Order Document Number) betekent dit:
UDEF Tag = “d.t.2_8” en de UDEF Name = “purchase.order.document_identifier”.

De boomstructuur voor het Object “Purchase Order Document” is opgebouwd uit:
Document (tag 2)
- Order (tag t).
- Purchase (tag d).

De boomstructuur voor de Property is opgebouwd uit:
Identifier (tag 8 )

Om een beter beeld te krijgen van enerzijds de complexiteit van het gebruik van de CCTS door de verschillende standaardisatie instellingen en anderzijds de problematiek van het opstellen van transformatieregels ga ik de transformatie van een factuur naar verschillende standaarden uitwerken. Daarbij zal ik uitgaan van de UN/CEFACT Cross Industry Invoice (CII) specificatie die is opgesteld door de UN/CEFACT in samenwerking met verschillende industriesectoren.

Ga hiervoor naar mijn bloart: Transformatiedefinities voor de elektronische factuur.

Tags: electronic data interchange, UDEF, CCTS, UN/CEFACT

Last update: 26-11-2011

UN/CEFACT Modeling Methodology

Elektronisch zakendoen vraagt om gestructureerde informatieuitwisseling tussen verschillende partijen waaronder bedrijven (B), overheid (G) en consumenten (C). De UN/CEFACT Modeling Methodology (UMM) voorziet in procedures en concepten voor het modelleren van alle mogelijke combinaties van collaboratieve bedrijfsprocessen waaronder B2B en G2G.

De UN/CEFACT Modeling Methodology (umm) is een methodologie voor het analyseren, beschrijven en specificeren van inter-organisatorische bedrijfsprocessen en informatieobjecten ten behoeve van elektronisch zakendoen.

Het bijzondere aan de UMM is dat het een incrementele methode is voor het construeren van collaboratieve business proces- en informatiemodellen op een technologie-neutrale en implementatie-onafhankelijke manier. De UMM bedrijfsproces- en informatiemodelleringstechniek is gebaseerd op de Unified Modelling Language (UML) van de Open Management Group (OMG).

Het doel van de UMM is het aanreiken van een methode voor het modelleren van bedrijfsprocessen. De UMM geeft daarmee ondersteuning aan het beschrijven van Open-edi scenario's volgens het Open-edi Reference Model (ISO/IEC 14662) van December 1997. Het resultaat van de UMM is een Business Collaboration Framework tussen twee of meer partijen.

Open-edi Reference Model
Het Open-EDI Reference Model kent twee perspectieven voor het beschrijven van de verschillende aspecten van business transacties:
- Business Operational View (BOV)
- Functional Service View (FSV)

Het BOV concept fungeert als middel om de business aspecten van de gegevensuitwisseling vast te leggen. De BOV beschrijft de gegevensinhoud (semantiek) van de bedrijfsinformatie die schuilgaat in de transacties en aanverwante gegevensuitwisselingen. Het benoemt de spelregels voor het aangaan van bedrijfstransacties waaronder de operationele afspraken, de overeenkomsten en onderlinge verplichtingen.

Het FSV concept betreft het ondersteunen van de technologische eisen van Open-edi. Het FSV concept identificeert en beschrijft de implementatiespecifieke generieke functionele eigenschappen van systemen die nodig zijn voor de uitvoering van Open-edi transacties. Het concentreert zich daarbij op de Informatie Technologie aspecten, in het bijzonder: de vereiste functionele eigenschappen van de diensten; de interfaces tussen de diensten; protocol- en berichtuitwisselingsdiensten.

De UMM richt zich primair op de Business Operational View (BOV) en hanteert vier perspectieven (views).
- Business Domain View (BDV)
- Business Requirements View (BRV)
- Business Transaction View (BTV
- Business Service View (BSV)

Het enige aspect van de Functional Service View (FSV) dat binnen het bereik van de UMM valt is de ontwikkeling van berichtdefinities. Hierover later misschien meer.

Business Domain View (BDV)

De BDV richt zich voornamelijk op het begrijpen van het bedrijfsdomein in kwestie.

De BDV resulteert in een opdeling van de bedrijfsomgeving, binnen een bepaalde bedrijfstak (business domain), naar bedrijfsgebieden (business areas), procesgebieden (process areas) en bedrijfsprocessen (business processes).

Daarnaast worden de verschillende partnertypes (organisaties, organisatieonderdelen, personen) die participeren in een bedrijfsproces vastgelegd in de vorm van belanghebbenden. Tevens worden de relaties (Association) tussen partnertypes en bedrijfsprocessen en de afhankelijkheden (Dependency) tussen een bedrijfsproces en belanghebbenden geïdentificeerd.

De UN/CEFACT Modeling Methodology User Guide adviseert om voor het opstellen van de Business Domain View gebruik te maken van een bestaand referentiemodel voor de betreffende industrietak of branche.

De BPAWG Reference Model of the International Supply Chain is het standaard Business Domain Model voor de UN/CEFACT. Dit referentiemodel wordt opgevolgd door het International Supply Chain Reference Model (ISC Model).

Het belangrijkste doel van de BDV is:
- het begrijpen van de structuur van het bedrijfsdomein
- het begrijpen van de dynamiek binnen het bedrijfsdomein
- het zorgdragen voor een gemeenschappelijk begrippenkader
- het doorgronden van de dagelijkse activiteiten binnen het bedrijfsdomein onafhankelijk van de technische oplossing
- het identificeren van de belanghebbenden bij het bedrijfsdomein
- het zoeken en vinden van de rechtvaardiging voor de Business Domain View

De resultaten van de Business Domain View zijn:
- Business Area's
- Process Area's
- Business Processes
- Business Partner Types
- Associations
- Dependencies

Business Requirements View (BRV)

Het voornaamste doel van de BRV is het identificeren van de collaboratieve bedrijfsprocessen tussen verschillende partners en het beschrijven van de eisen gesteld aan deze bedrijfsprocessen.

De BRV resulteert in een gedetailleerde beschrijving van de bedrijfsprocessen, van de entiteiten en de samenwerkingsverbanden. De eisen die gesteld worden aan een samenwerkingsverband (partnership) worden weergegeven door de vereisten van (dat wat vereist wordt door) transacties en samenwerking.

De resultaten van de Business Requirements View zijn:
- Business Process View
- Business Entity View
- Partnership Requirements View

De Business Process View geeft een overzicht van de werkstromen, informatiestromen en betrokken partnertypes in de vorm van een Business Process Activity Model waarin een partitie (verticale kolom) is opgenomen voor elke partner.

De Business Entity View geeft een overzicht van de bedrijfsdocumenten of objecten, levensduur en stadia waarin deze zich bevinden. Business Entities zijn documenten of objecten die van belang zijn voor twee of meer partnertypes in een bedrijfsproces. Denk hierbij aan offertes of inkooporder in een inkoop/verkoopmodel.

De Partner Requirements View geeft een gedetailleerde beschrijving van de samenwerking en de transacties tussen partner types op het niveau van rollen en verantwoordelijkheden via Use Cases.

Business Transaction View (BTV)

De Business Transaction View is een verdere uitdieping van de Business Requirements View. De BTV beschrijft de semantiek van de informatieentiteiten, de verschillende stappen in de samenwerking tussen verschillende partnertypes, de momenten waarop alsook de rollen waartussen de uitwisseling van informatie gebeurt.

De resultaten van de Business Transaction View zijn:
- Choreography
- Interaction
- Information

UMM top-down benadering
De UMM volgt een top-down benadering voor het opstellen van een Business Operational View. De UMM Gebruikers Handleiding kent 3 werkgebieden (work areas) die corresponderen met de eerste drie perspectieven. Voor elk van de werkgebieden worden business proces en informatie analyse worksheets en procedures aangereikt als hulpmiddel voor het vergaren van de vereiste informatie. De procedures binnen elk werkgebied beschrijven hoe de worksheets ingevuld kunnen worden.

Voor het opstellen van Business Requirements Specifications wordt gebruik gemaakt van de UN/CEFACT Modeling Methodology en van de Core Components Technical Specification. De Business Requirements Specification (BRS) is het document waarmee de eisen gesteld aan een bedrijfsproces, een uitgebreide beschrijving en informatiemodel van het bedrijfsdomein wordt vastgelegd. Daarvoor gebeurt volgens de aanpak gedefinieerd voor de eerste drie werkgebieden van de BOV. De Core Components Technical Specification beschrijft de aanpak voor het opstellen van het informatiemodel voor het betreffende bedrijfsdomein.

Voor het vierde perspectief van de BOV is geen werkgebied gedefinieerd in de UMM Gebruikers Handleiding omdat deze volgt uit de resultaten van de opeenvolgende werkgebieden.

Tags van Technorati: electronic data interchange,UN/CEFACT

Last update: 26-11-2011