Visit our main site www.danga.biz

Sunday, June 1, 2008

Installatie van Eclipse Subversive

Het Eclipse Subversive project richt zich op het beschikbaar maken van Subversion (SVN) functionaliteit in de Eclipse workbench. Subversive maakt het mogelijk om op dezelfde wijze als CVS (Concurrent Versions System) met repositories te werken. Subversion is net als Concurrent Versions System een versie controle beheersysteem voor het beheren van de broncode van programma's.

Voorheen moest u Subclipse, de Subversion plug-in van Tigris, installeren wanneer u gebruik wilde maken van Subversion functionaliteit in Eclipse. Op termijn zal Eclipse Subversive waarschijnlijk volledig worden geïntegreerd in de standaard Eclipse distributie.

Voordat u Eclipse Subversive installeert moet u zorgen dat Eclipse Mylyn is geïnstalleerd. Volg daarvoor de instructies in mijn bloart Installatie van Eclipse Mylyn.

Wanneer u Eclipse hebt opgestart kunt u Subversive installeren via het menu Help > Software Updates > Find and Install.

Selecteer Search for new features to install en in het dialoogscherm Install klik op de knop New Remote Site.

In het dialoogscherm New Update Site moet u de gegevens van de update site invoeren:
Naam: Subversive Update Manager Site
URL: http://download.eclipse.org/technology/subversive/0.7/update-site/

Klik op de knop OK om verder te gaan.

Klik daarna op de knop Finish voor het openen van het dialoogscherm Updates.

Vink de node Subversive aan en klik op de knop Next.

Accepteer de licentievoorwaarden en klik op de knop Next.

Daarna kunt u de locatie van de plugin's instellen als u niet wil dat deze in uw standaard Eclipse omgeving worden geïnstalleerd.

Nadat de installatie is afgerond moet Eclipse opnieuw opgestart worden.

Open het menu Help en dan ziet u dat de menuoptie Subversive is toegevoegd onder Software Updates.

Om met Subversive te kunnen werken zult u een Subversive SVN Connector moeten installeren. De Subversive plug-in en Subversive SVN Connectors worden gedistribueerd via verschillende updates sites. Installeer nu de Subversive SVN Connectors.

Open het menu Help > Software Updates > Find and Install.

Selecteer Search for new features to install en in het dialoogscherm Install
klik op de knop New Remote Site.
Open het menu Help

Selecteer Search for new features to install en in het dialoogscherm Install klik op de knop New Remote Site.

In het dialoogscherm New Update Site moet u de gegevens van de update site invoeren:
Naam: Subversive SVN Connectors Update Manager Site
URL: http://www.polarion.org/projects/subversive/download/eclipse/2.0/update-site/

Klik op de knop OK om verder te gaan.

Klik daarna op de knop Finish voor het openen van het dialoogscherm Updates.

Open achtereenvolgens de node Subversive SVN Connectors Update Manager Site en de node Subversive SVN Connectors. Selecteer de Connectors Native JavaHL x.y.z Implementation en JavaHL x.y.z Win32 Binaries aan.

Klik op de knop Next.

Accepteer de licentievoorwaarden en klik op de knop Next.

Daarna kunt u de locatie van de plugin's instellen als u niet wil dat deze in uw standaard Eclipse omgeving worden geïnstalleerd.

Nadat de installatie is afgerond moet Eclipse opnieuw opgestart worden.

Nu moet u nog onder Preferences controleren of de een Subversive SVN Connector is geselecteerd. Open het menu Window en selecteer de menuoptie Preferences.

Ga naar de node Team en selecteer de node SVN.

Controleer onder het tabblad SVN Connector een connector is geselecteerd: de Native JavaHL of de default SVN Kit.

Tags van Technorati:

Last update: 3-12-2011

Installatie van Eclipse Mylyn

Het Eclipse Mylyn is een taak-gerichte interface voor Eclipse met als doel het verhogen van de productiviteit van ontwikkelaars. Mylyn zorgt ervoor dat de ontwikkelaar direct toegang heeft tot informatie relevant voor het werk waar deze mee bezig is. Tevens voorziet Mylyn in functionaliteit voor het opvolgen van taken. Taken kunnen lokaal worden opgeslagen maar eveneens in een webgebaseerde repository zoals Bugzilla, Trac of Jira.

Wanneer u Eclipse hebt opgestart kunt u Mylyn installeren via het menu Help > Software Updates > Find and Install.

Selecteer Search for new features to install en in het dialoogscherm Install klik op de knop New Remote Site.

In het dialoogscherm New Update Site moet u de gegevens van de update site invoeren:
Naam: Mylyn Update Manager Site
URL: http://download.eclipse.org/tools/mylyn/update/weekly/e3.3/

Klik op de knop OK om verder te gaan.

Klik daarna op de knop Finish voor het openen van het dialoogscherm Updates.

Vink de node Mylyn aan en klik op de knop Next.

Accepteer de licentievoorwaarden en klik op de knop Next.

Daarna kunt u de locatie van de plugin's instellen als u niet wil dat deze in uw standaard Eclipse omgeving worden geïnstalleerd.

Nadat de installatie is afgerond moet Eclipse opnieuw opgestart worden.

Tags van Technorati:

Last update: 3-12-2011

Thursday, April 24, 2008

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]

Saturday, April 5, 2008

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

Sunday, March 30, 2008

Transformatie van een UBL Invoice naar een OAGI Invoice met ChainBuilder ESB IDE

In mijn vorige bloart over de Installatie van de Bostech ChainBuilder ESB heb ik u een algemene introductie gegeven in de ChainBuilder Enterprise Service Bus van Bostech en de Java Business Integration (JBI) specificatie.

Hierna ga ik met behulp van de de Map Editor van ChainBuilder ESB een Message (Transformatie) Map ontwikkelen waarmee een UBL Invoice ingelezen en getransformeerd kan worden naar een OAGI Invoice. Voor de transformatie ga ik uit van de laatste versies (UBL 2.0 en OAGI 9.1) van beide standaarden omdat deze beter aansluiten bij de UN/CEFACT Core Components Specification.

De UBL Standaard kunt u downloaden van de website: www.oasis-open.org via de optie OASIS Standards in de linker kolom.

De OAGI Standaard kunt u downloaden van de website: www.oagi.org via de optie Free Downloads in de linker kolom.

De Map Editor maakt het de gebruiker mogelijk om de relaties tussen gegevenselementen uit twee modellen (input en output) alsook een aantal transformatieregels vast te leggen.

De volgende stappen moeten doorlopen worden:
- Stap 1: Creatie ESB project
- Stap 2: Creatie JBI Service Assembly project voor de UBL to OAGI Invoice
- Stap 3: Kopieer de XSD bestanden van de UBL Invoice en de OAGI Invoice naar de folder src/formats
- Stap 4: Creatie van de Message Map
- Stap 5: Bouwen van een Component Flow Definition

Stap 1: Creatie ESB project
- Klik met uw rechtermuisknop in de Package Explorer en selecteer de menuoptie New > Other.

- Open de node ChainBuilder ESB-IDE en ChainBuilder ESB Project

- Selecteer de optie New ChainBuilder ESB Project en klik op de knop Next

- Geef uw project de naam ESB en klik op de knop Next om verder te gaan

- Klik op de knop Finish

Stap 2: Creatie JBI Service Assembly project voor de UBL to OAGI Invoice
- Klik met uw rechtermuisknop in de Package Explorer en selecteer de menuoptie New > Other.

- Open de node ChainBuilder ESB-IDE en ChainBuilder ESB Project

- Selecteer de optie New JBI Service Assembly Project en klik op de knop Next

- Geef uw project de naam UBLtoOAGIInvoice en klik op de knop Next

- Klik op de knop Next en vink in het dialoogscherm Setup Reference Relationship with Other project uw ESB Project aan

- Klik op de knop Finish

- Beantwoord de vraag voor het openen van de Component Flow Editor Perspective met Yes.

Stap 3: Kopieer de XSD bestanden van de UBL Invoice en OAGI Invoice naar de folder src/formats

- Kopieer het bestand UBL-Invoice-2.o.xsd naar de directory
\cbesb-1.2\ideworkspace\UBLtoOAGIInvoice\src\formats\.

- Kopieer de folders common en maindocs die u kunt terugvinden in de UBL specificatie onder de folder \os-UBL-2.0\xsd\ naar de directory \ideworkspace\UBLtoOAGIInvoice\src\

- Kopieer het bestand Invoice.xsd (OAGI) die u kunt terugvinden in de OAGI specificatie onder de folder \oagis\9_1\Resources\Nouns\ naar de directory \cbesb-1.2\ideworkspace\UBLtoOAGIInvoice\src\formats\.

- Kopieer de folder components die u kunt terugvinden in de OAGI specificatie onder de folder \oagis\9_1\Resources\ naar de directory \ideworkspace\UBLtoOAGIInvoice\src\

Nadat u deze stappen hebt doorlopen ziet de structuur van uw JBI Service Assembly project UBLtoOAGIInvoice er als volgt uit:

Stap 4: Creatie van de Message Map
Met de Map Editor gaat u nu een Message Map aanmaken onder de uw UBLtoOAGIInvoice JBI SA project.

- Klik met uw rechtermuisknop op de folder src/xlate en selecteer de menuoptie New > Map File

- Geef uw Map File de naam UBLtoOAGIInvoiceMap en klik op de knop Next

- In het dialoogscherm Choose Formats klik achtereenvolgens op de knop Browse achter de velden voor de source definition file en de target definition file.

- Selecteer de source definition file (UBL-Invoice-2.o.xsd) en daarna de target definition file (Invoice.xsd).

Zorg ervoor dat u beide definitiebestanden hebt geselecteerd:

- Klik op de knop Next om verder te gaan naar het volgende dialoogscherm waar u de Root nodes van de definities bestanden moet selecteren.

- Selecteer nu de Root nodes: voor beide message definities is dat Invoice.

- Klik op de knop Finish voor het afsluiten van de wizard

De Map Editor Perspective wordt nu geopend met aan de linkerkant het lege tabblad OperationProperties en in het midden het midden de Source en Target structuren.

Aan de rechterkant vindt u de kolom met de verschillende toepasbare operatie types.

Aan de linkerkant ziet u de tab Operation Properties naast de tab Package Explorer.

Nu komt het moeilijkste deel het opstellen van de transformatieregels. Blijf deze bloart volgen, binnenkort ga ik hier verder op in.

Tags: electronic data interchange, eclipse, data mapping tool, UBL

Last update: 26-11-2011