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]

Continue!

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]

Continue!

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

Continue!

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

Continue!