SAP neemt de UN/CEFACT Core Components als basis voor WARP 10

De SAP medewerkers Mark Crawford en Gunther Stuhec hebben de voorbije twee jaar hard gewerkt aan de ontwikkeling van een nieuw modelleer- en transformatiegereedschap gebaseerd op de UN/CEFACT Core Components Specification (CCTS).

Beide heren zijn actief betrokken bij de UN/CEFACT en de CCTS: Gunther is de voorzitter van de UN/CEFACT Techniques and Methodologies Group (TMG) en voorzitter van het project team verantwoordelijk voor de ontwikkeling van de CCTS standaard. Mark is de voorzitter van de UN/CEFACT Applied Technologies Group (ATG), de projectverantwoordelijke voor de UN/CEFACT Naming and Design Rules Specification en het Core Components Harmonization Project.

In het verlengde van hun waardevolle bijdrage aan de UN/CEFACT hebben zij de Core Components Specification als basis genomen voor het ontwerpen van een modelleer en transformatiegereedschap met de werknaam SAP CCTS Modeler Warp 10. De architectuur van Warp 10 is gebaseerd op SAP NetWeaver en biedt zowel integratie en uitbreiding van de SAP Global Data Types (GDT's) als transformatie naar ieder ander logisch data model ongeacht de gegevensbron.

De SAP CCTS Modeler Warp 10 is ontworpen met als doel het verminderen van de ontwikkel- en integratieinspanningen van data modellering en mapping. Het gereedschap richt zich voornamelijk op het vereenvoudigen van de inspanningen voor het bouwen van transformatiedefinities. Daarbij wordt ondersteuning geboden voor het automatisch genereren van transformatiemappings tussen verschillende standaarden op basis van industrie, internationale standaard, berichttype en doel van het bericht.

De SAP CCTS Modelere Warp 10 is een web-gebaseerd gereedschap met repository waarin data structuren, modellen en mapping definities zijn opgeslagen.

Vrij recent (9 juli 2008) is door Gunther Stuhec de Community Advisory Group (CAH) 12 Business Data Interoperability opgericht met als doel het nieuwe prototype van CCTS Modeler Warp 10 een beetje dichter bij het grotere publiek te brengen. De vraag is of het publiek wel interesse heeft in een propriëtair online gereedschap. Het aantal deelnemers en activiteiten aan deze community is vrij beperkt wat meestal geen positief teken is.

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 informatieinteroperabiliteit tussen bedrijfsondersteunende systemen. Al jaren is het één van de beperkende factoren in de realisatie van inter-enterprise collaboratieve bedrijfsprocessen en gegevensuitwisseling. Zoals ik in mijn bloart Hoe lossen we het interoperabiliteitsvraagstuk op ? beschrijf zijn er reeds verschillende benaderingen ontwikkeld maar geen is momenteel voldoende volwassen om als uitgangspunt te dienen.

Ik geloof dat het bedrijfsleven behoefte heeft aan een Open Gemeenschappelijke Intelligente Oplossing die de brug slaat tussen al deze initiatieven en geaccepteerd wordt door de deelnemers in het integratie-speelveld. Daarbij valt te denken aan standaardisatieinstellingen, overheden tot leveranciers van oplossingen zoals SAP maar eveneens Open Source Communities zoals Eclipse.

Tags van Technorati: electronic data interchange,UDEF,CCTS,Government,Interoperability Frameworks

Last update: 26-11-2011

On what does the interoperability solution of the UN/CEFACT CCTS rest?

The UN/CEFACT Core Components Technical Specification (CCTS and ISO 15000-5) is developed by the UN/CEFACT Techniques and Methodologies Group (TMG), one of the permanent working groups of the UN/CEFACT. The most important goal of the UN/CEFACT TMG is the development of information and communication technology specifications and recommendations for the other UN/CEFACT working groups. The UN/CEFACT TMG group also developed the UN/CEFACT Modelling Methodology (UMM).

What is the goal of the UN/CEFACT CCTS ?
The UN/CEFACT Core Components Technical Specification (CCTS) provides in a syntax-neutral methodology for the design and development of semantic building blocks.

The goal of the specification is to provide a solution oriented approach for the well-known interoperability question. For years the lack of information interoperability between Business supporting systems has been a restricting factor in the realization of inter-enterprise collaborative Business processes and data exchange.

The UN/CEFACT CCTS constitutes the basis for the development of a grammar that organizations can use to develop new Business vocabularies. Those new vocabularies contribute to improving and simplifying the way parties communicate with each other across Business boundaries (applications and systems) and domains (sectors). To eliminate the interoperability problems the use of one generic grammar language is advised.

The UN/CEFACT takes care of the development and maintenance of a universal Core Component Library (CCL) and Data Type Catalogue with free access for the Core Component community.

What boundary conditions apply ?
For a proper working of the CCTS concept all standards organizations need to ensure their core components are included in the Core Component Library (CCL) and/or need to open up their libraries to others.

At the moment only a few standards organizations have adopted and partially implemented the CCTS approach. OAGIS and OASIS Universal Business Language (UBL) took the CCTS as a basis for the development of their message libraries. Some other standards organizations that adopted the CCTS approach are RosettaNet, CIDX, HR-XML en ACORD.

What approach does the CCTS takes in solving the interoperability question ?
The approach of the Core Components Technical Specification is based on commonly accepted and publicitely available Core Components and derived Business Information Entities. The most atomic information parts for assembling the core components and information entities, up to a complete Business document, are the Core Data Types (CDT).

The foundation for the interoperability solution of the UN/CEFACT CCTS are the Core Data Types (CDTs) and the Business Data Types (BDTs) which are stored in the Data Type Catalogue of the UN/CEFACT. All other Core Components and Business Information Entities are based on these atomic information parts.

Given the fact that all standards organizations that adopted the CCTS approach have based their message libraries on these atomic information parts and are making use of the Data Type Catalogue the future of the CCTS looks promising.

The OAGIS and the OASIS UBL standards took over the Core Data Types and Business Data Types as a set of Unqualified Data Types (UDT) in addition to their own specific data types. However since the UN/CEFACT CCTS was developed only recently these organizations have not yet been able to incorporate all of the CCTS concepts. Although it should be mentioned that the OASIS UBL standard was ahead of the UN/CEFACT.

Key principes of the CCTS Data Types
There are two kinds of Data Types: Core Data Types (CDT) and Business Data Types (BDT).

The Core Data Types identify the most atomic pieces of Business information and should be considered as generic data types. Every Core Data Type consists of a Content Component and one or more Supplementary Components.

The Content Component is the carrier of the actual value and the Supplementary Component give meaning to this value. Every Content Component and Supplementary Component has a Primitive Type that sets the initial Value Domains. The Value Domain of the Content Component defines the set of permissible values for the Core Data Type but is constrained by its Supplementary Component.

The Core Data Types defines the value space for the Core Component (CC). The Business Data Types for the Business Information Entity (BIE).

Example:
The Core Data Type Amount.Type contains a Content Component that carries the value and a Supplementary Component that gives meaning to that value.

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

The Core Components Technical Specification provides a fixed list of Core Data Types in the Data Type Catalogue. The catalogue contains the list of the UN/CEFACT permissible Representation Terms, Core Data Types and Business Data Types.

The list of Core Data Types includes types such as Amount. Type, Binary. Object. Type, Code. Type, Date. Type, Date. Time. Type, Duration. Type, Graphic. Vector, Identifier. Type, etcetera.

Focus areas of the CCTS are:
- Core Components (CC's):
Core Components are semantic buidling blocks, conceptual in nature, that can be used for all aspects of data and information modelling.

- Business Information Entities (BIE's)
Business Information Entities are context-specific uses of conceptual core components within a specific business domain. BIE's are always derived from CC's.

Import startingpoint for the methodology is the use of the Dictionary Entry Name (DEN). This is the unique official name of the core component in the dictionary. The CCTS specifies that the dictionary content shall be in the English Language following the primary Oxford English Dictionary English spellings to assure unambiguous spelling.

The Core Components Technical Specification provides companies a semantic base for the support of different XML-languages for electronic communication. The CCTS enables semantic mapping of components between different libraries.

What is the status on solving the interoperability question ?
In the UBL Developers Community Mark Crawford answers my question How will CCTS improve the interoperability between one or more communication partners, standards and systems as follows:

"The Data Type interoperability is just one aspect of the interoperability of CCTS. People are referring to the base data types from CEFACT, but much more importantly, they are doing this in the development of their syntax neutral data models. The Data Types are the basis for both the conceptual and logical data models. The conceptual data model and semantic focus are the keys to interoperability as every logical data model is derived from a single ubiquituous data model."

In other words the CCTS aims at realizing universal semantic interoperability of Business Information through one single conceptual data model from which all other context-specific logical data models are derived.

This means that the necessary interoperability can only be obtained when all data models from the different standards are derived from the CCTS conceptual data model, next to the use of the Data Type Catalogue and the Core Component Library (CLL).

Likely this will not happen in the next few years because the impact is very extreme. I do not believe that standard organizations and others are willing to abandon their approaches and knowledge base in favor of interoperability. Other less extreme initiatives will soon be launched and build upon the CCTS or follow a new direction (web ontology).

One thing is sure, all of us are behind the idea that Informationinteroperability should be realized by using one common notion of the meaning of data but the way this will be done is not yet determined.

Once the selected principle can be incorporated in systems and applications then interoperability will be commonly accepted.

I will stay on top of the latest developments of interoperability and will soon be back with more.

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

Last update: 26-11-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

Transformatiedefinities voor de elektronische factuur

Het opstellen van transformatieregels voor de transformatie van berichten tussen verschillende standaarden mag niet worden onderschat. Het vereist grondige kennis van berichtstandaarden en van de betekenis van gegevens binnen een bedrijfsdomein. De Core Components Technical Specification (CCTS) en de Universal Data Element Framework (UDEF) streven naar een semantisch referentiekader voor de realisatie van informatieinteroperabiliteit. Wanneer beide concepten algemeen geaccepteerd en doorgevoerd worden dan zal transformatie veel eenvoudiger worden.

De Core Components Technical Specification kent aan elke Business Information Entity een unieke identificatie en Dictionary Entry Name (DEN) toe, net als de Universal Data Element Framework. Voorbeeld: De Invoice Issuer, de persoon of organisatie die de factuur uitgeeft, heeft als CCTS Unique ID de waarde UN01001476 en als DEN Invoice Issuer_ Party. Primary_ Identification. Identifier gekregen. De Universal Data Element Framework UDEF ID die daarmee overeenkomt is y.3_2.35.8 en de UDEF Name is Supplier.Enterprise_Purchaser.Assigned.Identifier.

Voor het verkrijgen van een beter beeld van de complexiteit van het transformeren van berichten en ter voorbereiding van het gebruik van transformatiegereedschappen ga ik de transformatieregels van de factuur uitwerken.

Het factuurproces richt zich op de uitwisseling van de factuur tussen leverancier en klanten voor geleverde goederen of diensten. Ter vereenvoudiging van het proces worden andere deelnemers buiten beschouwing gelaten. Zowel de klant als de leverancier kan in het proces meerdere rollen vervullen. Zo kan de klant acteren als klant (customer), besteller (buyer), ontvanger (consignee), invoicee en payer (betaler). De leverancier als leverancier (supplier), verkoper (seller), afzender (consignor), invoice issuer en payee.

Er zijn twee soorten factuurprocessen:
- de traditionele of door de leverancier geïnitieerde factuur waarbij de factuur door de leverancier wordt gegenereerd naar de klant

- de self-billing invoicing waarbij de factuur door de klant wordt gegenereerd naar de leverancier

Ik ga de mappingdefinitie uitwerken voor de traditionele factuur voor volgende internationale berichtstandaarden.

- Universal Business Language (UBL) Release 2.0
- Open Applications Group (OAGIS) Release 9.1
- UN/CEFACT Cross Industry Invoice (CII) Release 1.0
- EDIFACT Release 0.7B
- SAP IDOC Invoice02

Voor de berichtdefinitie ga ik uit van de UN/CEFACT Cross Industry Invoice (CII) specificatie die is opgesteld door de UN/CEFACT in samenwerking met verschillende industriesectoren.

Verder heb ik de UDEF ID en Name evenals de CCTS Unique ID en Name toegekend aan de elementen.
- UDEF ID
- UDEF Name
- CCTS ID

Invoice Number
Description = The unique number assigned by the issuer to identify an invoice.

CII = Billing_ Document. Issuer Assigned_ Identification. Identifier

UBL NAME = ID
UBL DEN = Invoice. Identifier
Svefaktura = likewise

OAGIS = Invoice.InvoiceHeader.DocumentID.ID

EDIFACT =
- BGM.C106.1004

IDOC =
- E2EDK02.E1EDK02.QUALF [Qualifier: 009 Invoice Number]
- E2EDK02.E1EDK02.BELNR

UDEF ID = bd.2_17.35.8 (proposed)
UDEF Name = Invoice.Document_Creditor.Assigned.Identifier (proposed)

CCTS ID = UN01001356

Copy Indicator
Description = The indicator that identifies whether or not the invoice is a copy of the original invoice.

CII = Billing_ Document. Copy. Indicator

UBL NAME = CopyIndicator
UBL DEN = Invoice. Copy_ Indicator. Indicator
Svefaktura = not included

OAGIS = ?

EDIFACT =
- BGM.1225 [Code: 9 Original]

IDOC = not available

UDEF ID = bd.2_49.7 (proposed)
UDEF NAME = Invoice.Document_Copy.Indicator (proposed)

CCTS ID = UN01001359

Invoice Global Unique Identifier
Description = The Global Unique Identifier (GUID) of the invoice.

CII = ?

UBL NAME = UUID
UBL DEN = Invoice. UUID. Identifier
Svefaktura = not included

OAGIS = ?

EDIFACT = ?

IDOC = ?

UDEF ID = bd.2_50.4
UDEF NAME = Invoice.Document_Language.Code

CCTS ID = ?

Invoice Issue Date
Description = The date when the invoice was issued.

CII = Billing_ Document. Issue. Date Time

UBL NAME = IssueDate
UBL DEN = Invoice. Issue Date. Date
Svefaktura = likewise

OAGIS = Invoice.InvoiceHeader.DocumentDateTime

EDIFACT =
- DTM.C507.2005 [Qualifier: 3 Invoice Document Issue Date Time]
- DTM.C507.2380
- DTM.C507.2379 [Qualifier: 102 CCYYMMDD]

IDOC =
- E2EDK03.E1EDK03.IDDAT [Code: 016 Invoice Date]
- E2EDK03.E1EDK03.DATUM

UDEF ID = bd.2_9.6
UDEF Name = Invoice.Document_Issued.Date

CCTS ID = UN01001357

Invoice Type Code
Description = The code specifying the invoice type (e.g. invoice, debit note, credit note).

CII = Billing_ Document. Type. Code

UBL NAME = InvoiceTypeCode
UBL DEN = Invoice. Invoice Type Code. Code
Svefaktura = likewise

OAGIS = ?

EDIFACT =
- BGM.C002.1001 [Code: 380 Commercial Invoice]

IDOC =
- E2EDK01005.E1EDK01.BSART [Value: INVO = debit, CRME = credit]

UDEF ID = bd.2_33.4
UDEF NAME = Invoice.Document_Type.Code

CCTS ID = UN01001358

Note
Description = Free-form text applying to the Invoice not contained in another structure.

CII = ?

UBL NAME = Note
UBL DEN = Invoice. Note. Text
Svefaktura = likewise

OAGIS = ?

EDIFACT = ?

IDOC = ?

UDEF ID = ?
UDEF NAME = ?

CCTS ID = ?

Tax Point Date
Description = The date of the Invoice, used to indicate the point at which tax becomes applicable.

CII = ?

UBL NAME = TaxPointDate
UBL DEN = Invoice. Tax Point Date. Date
Svefaktura = likewise

OAGIS = ?

EDIFACT = ?

IDOC = ?

UDEF ID = ?
UDEF NAME = ?

CCTS ID = ?

[Remarks = Validate whether this remains valid with the new proposed VAT directives !]

Invoice Language
Description = The code specifying the language of the free text of the invoice.

CII = Billing_ Document. Language. Identifier

UBL NAME = not included
UBL DEN = not included
Svefaktura = not included

OAGIS = ?

EDIFACT = ?

IDOC = ?

UDEF ID = bd.2_50.4
UDEF NAME = Invoice.Document_Language.Code

CCTS ID = UN01001360

Invoicing Currency
Description = The code identifier of the monetary unit used for amounts.

CII = Billing_ Document. Billing_ Currency. Code

UBL NAME = InvoiceCurrency
UBL DEN = Invoice. Document_ Currency Code. Code
Svefaktura = Invoice. Invoice Currency. Code

OAGIS = not available for complete document

EDIFACT =
- GRP07.CUX.C504.6347 [Qualifier: 2 Reference Currency]
- GRP07.CUX.C504.6345 [Use ISO 4217 three alpha code]
- GRP07.CUX.C504.6343 [Qaulifier: 4 Invoicing Currency]

IDOC =
- E2EDK01005.E1EDK01.CURCY

UDEF ID = not available for complete document
UDEF NAME = not available for complete document

CCTS ID = UN01001361

Price Currency
Description = The code identifier of the monetary unit used for the price.
CII = Billing_ Document. Price_ Currency. Code

UBL = Invoice. Pricing_ Currency Code. Code

OAGIS = not available for complete document

EDIFACT =
- GRP07.CUX.C504.6347 [Qualifier: 2 Reference Currency]
- GRP07.CUX.C504.6345 [Use ISO 4217 three alpha code]
- GRP07.CUX.C504.6343 [Qaulifier: 10 Pricing Currency]

IDOC = not available

UDEF ID = not available for complete document
UDEF NAME = not available for complete document

CCTS ID = UN01001362

Payment Currency
Description = The code identifier of the monetary unit used for the payment of the invoice.
CII = Billing_ Document. Payment_ Currency. Code

UBL = Invoice. Payment_ Currency Code. Code

OAGIS = not available for complete document

EDIFACT =
- GRP07.CUX.C504.6347 [Qualifier: 3 Target Currency]
- GRP07.CUX.C504.6345 [Use ISO 4217 three alpha code]
- GRP07.CUX.C504.6343 [Qaulifier: 11 Payment Currency]

IDOC = not available

UDEF ID = not available for complete document
UDEF NAME = not available for complete document

CCTS ID = UN01001363

Alternative Payment Currency
Description = The code identifier of the monetary unit used as an alternate currency for the payment of the invoice.
CII = Billing_ Document. Alternative Payment_ Currency. Code

UBL = Invoice. Payment Alternative_ Currency Code. Code

OAGIS = not available for complete document

EDIFACT = not available

IDOC = not available

UDEF ID = not available for complete document
UDEF NAME = not available for complete document

CCTS ID = UN01001364

Number of Invoice Lines
Description = The number of invoice lines.
CII = Billing_ Document. Line Count. Numeric

UBL = Invoice. Line Count. Numeric

OAGIS = not available

EDIFACT =
- GRP51.CNT.C270.6069 [Qualifier: 2 Number of lines]
- GRP51.CNT.C270.6066

IDOC =
- E2EDS01.E1EDS01.SUMID [Qualifier: 001 Number of items]
- E2EDS01.E1EDS01.SUMME

UDEF ID = to be determined
UDEF NAME = to be determined

CCTS ID = UN01001365

Total Invoice Additional Charge Amount
Description = The sum of all charges at the invoice header level before tax or fee.
CII =

UBL =

OAGIS =

EDIFACT =

IDOC =

UDEF ID = to be determined
UDEF NAME = to be determined

CCTS ID =

Total Invoice Line Amount
Description = The sum of all invoice lines amounts, including all allowances and charges related to the invoice line before tax or fee.
CII = Billing_ Monetary Summation. Line Total. Amount

UBL = Invoice. Legal_ Monetary Monetary Total. Line Extension Amount. Amount

OAGIS = Invoice. InvoiceHeader. ExtendedAmount

EDIFACT =
- GRP52.MOA.C516.5025 [Qualifier: 340 Original Total Net Invoice Value]
- GRP52.MOA.C516.5004

IDOC =

UDEF ID = to be determined
UDEF NAME = to be determined

CCTS ID = UN01001367

Invoicing Period Start Date
Description = The date, time, date time or other date time value for the start of this billing period.
CII = Billing_ Period. Start. Date Time

UBL =
* Invoice. Invoice_ Period. Start Date. Date
* Invoice. Invoice_ Period. Start Date. Time

OAGIS = not available

EDIFACT =
- DTM.C507.2005 [Qualifier: 194 Start Date / Time Period]
- DTM.C507.2380
- DTM.C507.2379 [Qualifier: 102 CCYYMMDD]

IDOC =
- E2EDK03.E1EDK03.IDDAT [Code: 019 Start of validity]
- E2EDK03.E1EDK03.DATUM

UDEF ID =
* bd.2_18.6
* bd.2_1.15

UDEF NAME =
* Invoice.Document_Start.Date
* Invoice.Document_Start.Time

CCTS ID = UN01001386

Invoicing Period End Date
Description = The date, time, date time or other date time value for the end of this billing period.

CII = Billing_ Period. End. Date Time

UBL =
* Invoice. Invoice_ Period. End Date. Date
* Invoice. Invoice_ Period. End Date. Time

OAGIS = not available

EDIFACT =
- DTM.C507.2005 [Qualifier: 206 End Date / Time Period]
- DTM.C507.2380
- DTM.C507.2379 [Qualifier: 102 CCYYMMDD]

IDOC =
- E2EDK03.E1EDK03.IDDAT [Code: 020 End of validity]
- E2EDK03.E1EDK03.DATUM

UDEF ID =
* to be determined
* bd.2_2.15

UDEF NAME =
* to be determined
* Invoice.Document_End.Time

CCTS ID = UN01001387

Invoice Issuer Identification Code
Description = The invoice issuer is the person or organization making the invoice, claiming payment for the goods or services rendered.

CII = Invoice Issuer_ Party. Primary_ Identification. Identifier

UBL = Invoice. Accounting_ Supplier Party. Customer Assigned_ Account Identifier. Identifier

OAGIS = Invoice. InvoiceHeader.SupplierParty.PartyIDs.ID
<em>[Remark: OAGIS InvoicerParty is a better match but not provided]</em>

EDIFACT =
- GRP02.NAD.3035 [Qualifier: II Invoice Issuer]
- GRP02.NAD.C082.3039

IDOC =
- E2EDKA1003.E1EDKA1.PARVW [Qualifier: RS Invoicing Party - Invoice From]
- E2EDKA1003.E1EDKA1.PARTN

UDEF ID = y.3_2.35.8
UDEF NAME = Supplier.Enterprise_Purchaser.Assigned.Identifier

CCTS ID = UN01001476

Invoice Issuer Name
Description = The name, expressed as text, for this invoice issuer party.

CII = Invoice Issuer_ Party. Name. Text

UBL = Invoice. Accounting_ Supplier Party. Party Name

EDIFACT =
- GRP02.NAD.3035 [Qualifier: II Invoice Issuer]
- GRP02.NAD.C080.3036

IDOC =
- E2EDKA1003.E1EDKA1.PARVW [Qualifier: RS Invoicing Party - Invoice From]
- E2EDKA1003.E1EDKA1.NAME1

UDEF ID =
UDEF NAME =

CCTS ID = UN01001479

Invoice Issuer VAT ID
Description = vat-nbr / registrationnbr selling company

CII = Invoice Issuer_ Party. Tax_ Identification. Identifier

UBL = Invoice. Accounting_ Supplier Party. Party Tax Scheme. Company Identifier. Identifier

EDIFACT =
- GRP03.RFF.C506.1153 [Reference Qualifier: VA VAT Registration Number]
- GRP03.RFF.C506.1154

IDOC =
- E2EDK01005.E1EDK01.EIGENUINR

UDEF ID =
UDEF NAME =

CCTS ID = UN01001478

Chamber of Commerce Number
Description = Identifies a company as registered with the company registration scheme.

CII =

UBL = Invoice. Accounting_ Supplier Party. Party Legal Entity. Company Identifier. Identifier

EDIFACT =
- GRP03.RFF.C506.1153 [Reference CodeQualifier AHO Chamber of Commerce registration number]
- GRP03.RFF.C506.1154

IDOC =
- E2EDKA1003.E1EDKA1.PARVW [Qualifier: RS Invoicing Party - Invoice From]
- E2EDKA1003.E1EDKA1.NAME4

UDEF ID =
UDEF NAME =

CCTS ID =

Invoicee Identification Code
Description = The primary identifier of this invoicee party.

CII = Invoicee_ Party. Primary_ Identification. Identifier

UBL = Invoice. Accounting_ Customer Party. Customer Assigned_ Account Identifier. Identifier

EDIFACT =
- GRP02.NAD.3035 [Qualifier: IV Invoicee]
- GRP02.NAD.C082.3039

IDOC =
- E2EDKA1003.E1EDKA1.PARVW [Qualifier: RE Bill To]
- E2EDKA1003.E1EDKA1.PARTN

UDEF ID =
UDEF NAME =

CCTS ID =

Invoicee Name
Description = An association to Party Name.

CII = Invoicee_ Party. Name. Text

UBL = Invoice. Accounting_ Customer Party. Party. Party Name

EDIFACT =
- GRP02.NAD.3035 [Qualifier: IV Invoicee]
- GRP02.NAD.C080.3036

IDOC =
- E2EDKA1003.E1EDKA1.PARVW [Qualifier: RE Bill To]
- E2EDKA1003.E1EDKA1.NAME1

UDEF ID =
UDEF NAME =

CCTS ID =

Tags: CCTS, EDIFACT, electronic data interchange, HR-XML, UBL, UDEF

[Last update: 26-11-2011]

Transformation definitions for the electronic invoice

Defining transformation rules for the transformation of messages between different international standards should not be underestimated. It is a difficult task that requires extensive knowledge of these message standards and the data within the Business domain.

The Core Components Technical Specification (CCTS) and the Universal Data Element Framework (UDEF) define a semantic reference framework, principles and standards, for achieving information interoperability. Whenever both concepts are commonly accepted and implemented then transformation will become a lot easier.

The Core Components Technical Specification assigns each Business Information Entity a unique identifier and Dictionary Entry Name (DEN), similar to the Universal Data Element Framework. Example: The Invoice Issuer, the person or organization making and issuing the invoice, gets the CCTS Unique ID UN01001476 and DEN Invoice Issuer_ Party. Primary_ Identification.Identifier. The Universal Data Element Framework UDEF ID that corresponds is y.3_2.35.8 and the UDEF Name is Supplier.Enterprise_Purchaser.Assigned.Identifier.

For a better understanding of the complexity involved in the transformation of messages and in preparation of the usage of transformation tools I am going to work out the transformation rules for the invoice.

The invoicing process is used to exchange an invoice between a supplier and customer for the supply of goods or services. To simplify the process only the supplier and customer parties are taken into account. Each of the parties can have more than one role. The customer can act as the customer or ordering company, buyer, consignee, invoicee and payer. The supplier covers the roles of supplier or sales company, seller, consignor, invoice issuer and payee.

There are two variants of invoicing:
- the traditional or supplier initiated invoice, where the supplier generates and issues the invoice to the customer

- the self-billing invoicing, where the customer generates and issues the invoice to the supplier

I am going to work out the transformation rules for the traditional invoice from and to the following international standards.

- Universal Business Language (UBL) Release 2.0
- Open Applications Group (OAGIS) Release 9.1
- UN/CEFACT Cross Industry Invoice (CII) Release 1.0
- EDIFACT Release 0.7B
- SAP IDOC Invoice02

I will use the UN/CEFACT Cross Industry Invoice (CII) specification, defined by the UN/CEFACT organization together with participants from different industry sectors, as the starting point.

Besides that I have assigned the UDEF ID and Name, likewise for the CCTS Unique ID and Name.

- UDEF ID
- UDEF Name
- CCTS ID

Invoice Number
Description = The unique number assigned by the issuer to identify an invoice.

CII = Billing_ Document. Issuer Assigned_ Identification. Identifier

UBL NAME = ID
UBL DEN = Invoice. Identifier
Svefaktura = likewise

OAGIS = Invoice.InvoiceHeader.DocumentID.ID

EDIFACT =
- BGM.C106.1004

IDOC =
- E2EDK02.E1EDK02.QUALF [Qualifier: 009 Invoice Number]
- E2EDK02.E1EDK02.BELNR

UDEF ID = bd.2_17.35.8 (proposed)
UDEF Name = Invoice.Document_Creditor.Assigned.Identifier (proposed)

CCTS ID = UN01001356

Copy Indicator
Description = The indicator that identifies whether or not the invoice is a copy of the original invoice.

CII = Billing_ Document. Copy. Indicator

UBL NAME = CopyIndicator
UBL DEN = Invoice. Copy_ Indicator. Indicator
Svefaktura = not included

OAGIS = ?

EDIFACT =
- BGM.1225 [Code: 9 Original]

IDOC = not available

UDEF ID = bd.2_49.7 (proposed)
UDEF NAME = Invoice.Document_Copy.Indicator (proposed)

CCTS ID = UN01001359

Invoice Global Unique Identifier
Description = The Global Unique Identifier (GUID) of the invoice.

CII = ?

UBL NAME = UUID
UBL DEN = Invoice. UUID. Identifier
Svefaktura = not included

OAGIS = ?

EDIFACT = ?

IDOC = ?

UDEF ID = bd.2_50.4
UDEF NAME = Invoice.Document_Language.Code

CCTS ID = ?

Invoice Issue Date
Description = The date when the invoice was issued.

CII = Billing_ Document. Issue. Date Time

UBL NAME = IssueDate
UBL DEN = Invoice. Issue Date. Date
Svefaktura = likewise

OAGIS = Invoice.InvoiceHeader.DocumentDateTime

EDIFACT =
- DTM.C507.2005 [Qualifier: 3 Invoice Document Issue Date Time]
- DTM.C507.2380
- DTM.C507.2379 [Qualifier: 102 CCYYMMDD]

IDOC =
- E2EDK03.E1EDK03.IDDAT [Code: 016 Invoice Date]
- E2EDK03.E1EDK03.DATUM

UDEF ID = bd.2_9.6
UDEF Name = Invoice.Document_Issued.Date

CCTS ID = UN01001357

Invoice Type Code
Description = The code specifying the invoice type (e.g. invoice, debit note, credit note).

CII = Billing_ Document. Type. Code

UBL NAME = InvoiceTypeCode
UBL DEN = Invoice. Invoice Type Code. Code
Svefaktura = likewise

OAGIS = ?

EDIFACT =
- BGM.C002.1001 [Code: 380 Commercial Invoice]

IDOC =
- E2EDK01005.E1EDK01.BSART [Value: INVO = debit, CRME = credit]

UDEF ID = bd.2_33.4
UDEF NAME = Invoice.Document_Type.Code

CCTS ID = UN01001358

Note
Description = Free-form text applying to the Invoice not contained in another structure.

CII = ?

UBL NAME = Note
UBL DEN = Invoice. Note. Text
Svefaktura = likewise

OAGIS = ?

EDIFACT = ?

IDOC = ?

UDEF ID = ?
UDEF NAME = ?

CCTS ID = ?

Tax Point Date
Description = The date of the Invoice, used to indicate the point at which tax becomes applicable.

CII = ?

UBL NAME = TaxPointDate
UBL DEN = Invoice. Tax Point Date. Date
Svefaktura = likewise

OAGIS = ?

EDIFACT = ?

IDOC = ?

UDEF ID = ?
UDEF NAME = ?

CCTS ID = ?

[Remarks = Validate whether this remains valid with the new proposed VAT directives !]

Invoice Language
Description = The code specifying the language of the free text of the invoice.

CII = Billing_ Document. Language. Identifier

UBL NAME = not included
UBL DEN = not included
Svefaktura = not included

OAGIS = ?

EDIFACT = ?

IDOC = ?

UDEF ID = bd.2_50.4
UDEF NAME = Invoice.Document_Language.Code

CCTS ID = UN01001360

Invoicing Currency
Description = The code identifier of the monetary unit used for amounts.

CII = Billing_ Document. Billing_ Currency. Code

UBL NAME = InvoiceCurrency
UBL DEN = Invoice. Document_ Currency Code. Code
Svefaktura = Invoice. Invoice Currency. Code

OAGIS = not available for complete document

EDIFACT =
- GRP07.CUX.C504.6347 [Qualifier: 2 Reference Currency]
- GRP07.CUX.C504.6345 [Use ISO 4217 three alpha code]
- GRP07.CUX.C504.6343 [Qaulifier: 4 Invoicing Currency]

IDOC =
- E2EDK01005.E1EDK01.CURCY

UDEF ID = not available for complete document
UDEF NAME = not available for complete document

CCTS ID = UN01001361

Price Currency
Description = The code identifier of the monetary unit used for the price.
CII = Billing_ Document. Price_ Currency. Code

UBL = Invoice. Pricing_ Currency Code. Code

OAGIS = not available for complete document

EDIFACT =
- GRP07.CUX.C504.6347 [Qualifier: 2 Reference Currency]
- GRP07.CUX.C504.6345 [Use ISO 4217 three alpha code]
- GRP07.CUX.C504.6343 [Qaulifier: 10 Pricing Currency]

IDOC = not available

UDEF ID = not available for complete document
UDEF NAME = not available for complete document

CCTS ID = UN01001362

Payment Currency
Description = The code identifier of the monetary unit used for the payment of the invoice.
CII = Billing_ Document. Payment_ Currency. Code

UBL = Invoice. Payment_ Currency Code. Code

OAGIS = not available for complete document

EDIFACT =
- GRP07.CUX.C504.6347 [Qualifier: 3 Target Currency]
- GRP07.CUX.C504.6345 [Use ISO 4217 three alpha code]
- GRP07.CUX.C504.6343 [Qaulifier: 11 Payment Currency]

IDOC = not available

UDEF ID = not available for complete document
UDEF NAME = not available for complete document

CCTS ID = UN01001363

Alternative Payment Currency
Description = The code identifier of the monetary unit used as an alternate currency for the payment of the invoice.
CII = Billing_ Document. Alternative Payment_ Currency. Code

UBL = Invoice. Payment Alternative_ Currency Code. Code

OAGIS = not available for complete document

EDIFACT = not available

IDOC = not available

UDEF ID = not available for complete document
UDEF NAME = not available for complete document

CCTS ID = UN01001364

Number of Invoice Lines
Description = The number of invoice lines.
CII = Billing_ Document. Line Count. Numeric

UBL = Invoice. Line Count. Numeric

OAGIS = not available

EDIFACT =
- GRP51.CNT.C270.6069 [Qualifier: 2 Number of lines]
- GRP51.CNT.C270.6066

IDOC =
- E2EDS01.E1EDS01.SUMID [Qualifier: 001 Number of items]
- E2EDS01.E1EDS01.SUMME

UDEF ID = to be determined
UDEF NAME = to be determined

CCTS ID = UN01001365

Total Invoice Additional Charge Amount
Description = The sum of all charges at the invoice header level before tax or fee.
CII =

UBL =

OAGIS =

EDIFACT =

IDOC =

UDEF ID = to be determined
UDEF NAME = to be determined

CCTS ID =

Total Invoice Line Amount
Description = The sum of all invoice lines amounts, including all allowances and charges related to the invoice line before tax or fee.
CII = Billing_ Monetary Summation. Line Total. Amount

UBL = Invoice. Legal_ Monetary Monetary Total. Line Extension Amount. Amount

OAGIS = Invoice. InvoiceHeader. ExtendedAmount

EDIFACT =
- GRP52.MOA.C516.5025 [Qualifier: 340 Original Total Net Invoice Value]
- GRP52.MOA.C516.5004

IDOC =

UDEF ID = to be determined
UDEF NAME = to be determined

CCTS ID = UN01001367

Invoicing Period Start Date
Description = The date, time, date time or other date time value for the start of this billing period.
CII = Billing_ Period. Start. Date Time

UBL =
* Invoice. Invoice_ Period. Start Date. Date
* Invoice. Invoice_ Period. Start Date. Time

OAGIS = not available

EDIFACT =
- DTM.C507.2005 [Qualifier: 194 Start Date / Time Period]
- DTM.C507.2380
- DTM.C507.2379 [Qualifier: 102 CCYYMMDD]

IDOC =
- E2EDK03.E1EDK03.IDDAT [Code: 019 Start of validity]
- E2EDK03.E1EDK03.DATUM

UDEF ID =
* bd.2_18.6
* bd.2_1.15

UDEF NAME =
* Invoice.Document_Start.Date
* Invoice.Document_Start.Time

CCTS ID = UN01001386

Invoicing Period End Date
Description = The date, time, date time or other date time value for the end of this billing period.

CII = Billing_ Period. End. Date Time

UBL =
* Invoice. Invoice_ Period. End Date. Date
* Invoice. Invoice_ Period. End Date. Time

OAGIS = not available

EDIFACT =
- DTM.C507.2005 [Qualifier: 206 End Date / Time Period]
- DTM.C507.2380
- DTM.C507.2379 [Qualifier: 102 CCYYMMDD]

IDOC =
- E2EDK03.E1EDK03.IDDAT [Code: 020 End of validity]
- E2EDK03.E1EDK03.DATUM

UDEF ID =
* to be determined
* bd.2_2.15

UDEF NAME =
* to be determined
* Invoice.Document_End.Time

CCTS ID = UN01001387

Invoice Issuer Identification Code
Description = The invoice issuer is the person or organization making the invoice, claiming payment for the goods or services rendered.

CII = Invoice Issuer_ Party. Primary_ Identification. Identifier

UBL = Invoice. Accounting_ Supplier Party. Customer Assigned_ Account Identifier. Identifier

OAGIS = Invoice. InvoiceHeader.SupplierParty.PartyIDs.ID
<em>[Remark: OAGIS InvoicerParty is a better match but not provided]</em>

EDIFACT =
- GRP02.NAD.3035 [Qualifier: II Invoice Issuer]
- GRP02.NAD.C082.3039

IDOC =
- E2EDKA1003.E1EDKA1.PARVW [Qualifier: RS Invoicing Party - Invoice From]
- E2EDKA1003.E1EDKA1.PARTN

UDEF ID = y.3_2.35.8
UDEF NAME = Supplier.Enterprise_Purchaser.Assigned.Identifier

CCTS ID = UN01001476

Invoice Issuer Name
Description = The name, expressed as text, for this invoice issuer party.

CII = Invoice Issuer_ Party. Name. Text

UBL = Invoice. Accounting_ Supplier Party. Party Name

EDIFACT =
- GRP02.NAD.3035 [Qualifier: II Invoice Issuer]
- GRP02.NAD.C080.3036

IDOC =
- E2EDKA1003.E1EDKA1.PARVW [Qualifier: RS Invoicing Party - Invoice From]
- E2EDKA1003.E1EDKA1.NAME1

UDEF ID =
UDEF NAME =

CCTS ID = UN01001479

Invoice Issuer VAT ID
Description = vat-nbr / registrationnbr selling company

CII = Invoice Issuer_ Party. Tax_ Identification. Identifier

UBL = Invoice. Accounting_ Supplier Party. Party Tax Scheme. Company Identifier. Identifier

EDIFACT =
- GRP03.RFF.C506.1153 [Reference Qualifier: VA VAT Registration Number]
- GRP03.RFF.C506.1154

IDOC =
- E2EDK01005.E1EDK01.EIGENUINR

UDEF ID =
UDEF NAME =

CCTS ID = UN01001478

Chamber of Commerce Number
Description = Identifies a company as registered with the company registration scheme.

CII =

UBL = Invoice. Accounting_ Supplier Party. Party Legal Entity. Company Identifier. Identifier

EDIFACT =
- GRP03.RFF.C506.1153 [Reference CodeQualifier AHO Chamber of Commerce registration number]
- GRP03.RFF.C506.1154

IDOC =
- E2EDKA1003.E1EDKA1.PARVW [Qualifier: RS Invoicing Party - Invoice From]
- E2EDKA1003.E1EDKA1.NAME4

UDEF ID =
UDEF NAME =

CCTS ID =

Invoicee Identification Code
Description = The primary identifier of this invoicee party.

CII = Invoicee_ Party. Primary_ Identification. Identifier

UBL = Invoice. Accounting_ Customer Party. Customer Assigned_ Account Identifier. Identifier

EDIFACT =
- GRP02.NAD.3035 [Qualifier: IV Invoicee]
- GRP02.NAD.C082.3039

IDOC =
- E2EDKA1003.E1EDKA1.PARVW [Qualifier: RE Bill To]
- E2EDKA1003.E1EDKA1.PARTN

UDEF ID =
UDEF NAME =

CCTS ID =

Invoicee Name
Description = An association to Party Name.

CII = Invoicee_ Party. Name. Text

UBL = Invoice. Accounting_ Customer Party. Party. Party Name

EDIFACT =
- GRP02.NAD.3035 [Qualifier: IV Invoicee]
- GRP02.NAD.C080.3036

IDOC =
- E2EDKA1003.E1EDKA1.PARVW [Qualifier: RE Bill To]
- E2EDKA1003.E1EDKA1.NAME1

UDEF ID =
UDEF NAME =

CCTS ID =

Tags: CCTS, EDIFACT, electronic data interchange, HR-XML, UBL, UDEF

[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