UBL$B$N

[Yukinori Saito <saito-yukinori@fujielectric.co.jp>]

UBL JPLSC$B0Q0w3F0L(B

UBL$B$Nu$N$G8x<0$N:G?7HG$G$9!#(B

$BHw9M(B
$BK\(Be-mail$B$r;d$,AwIU$7$?M}M3$O!$(BJPLSC Chair$B$N0KF#MM$N(BOASIS$B2q0w;q3J$,2?$+$NpJs%5!<%S%9-j!J(BFIS$B!K(B
$B>pJs(BSI$B;v6HIt(B $B;v6H4k2hIt(B
e-mail: saito-yukinori@fujielectric.co.jp
Tel: 03-5435-7333      Fax: 03-5435-7513
-------------------------------------

Title: ユニバーサルなビジネス言語1.0

Universal Business Language1.0

出版日

2004年5月1日

文書識別子

cd-UBL-1.0

編集の状態

この文書は、オアシス委員会ドラフトである。

場所

http://docs.oasis-open.org/ubl/cd-UBL-1.0/

ダウンロード可能なパッケージ場所

http://docs.oasis-open.org/ubl/cd-UBL-1.0.zip

編集者

Bill Meadows、サン・マイクロシステムズ〈 bill.meadows@sun.com〉

Lisa Seaburg、AeonLLC〈 lseaburg@aeon-llc.com〉

寄稿者

技術委員会のメンバー

要約：

この仕様は、Universal Business Languageを定義する。

状態

この文書は、オアシスUniversal Business Language ( UBL ) 技術委員会の委員会ドラフトである。OASIS UBL Technical Committeeは、UBL TCウェブページでコメントリンクを使うこのリリースについて論評するよう利害関係者に勧める:

http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=ubl

目次

1はじめに

2標準の参照

3条件定義

4シンボル、及び、省略

5 UBL 1.0調達プロセス

6 UBL 1.0 Schemas

参考A ( 有益な ) :リリース注意事項

参考B ( 有益な ) :UBL方法論

参考C ( 有益な ) :フォーマッティング仕様

参考D ( 有益な ) :参考例

参考E ( 有益な ) :コードリスト

参考F ( 有益な ) :ASN.1仕様

参考G ( 有益な ) :進行中の作業アイテム

参考H : 注意

1はじめに

XMLは、1998年にW3Cの勧告を受けて市場に登場して以来、電子商取引で交換されるメッセージ定義のフレームワークとして多くの業界で適用されてきた。しかし、XMLが普及した結果、発注書や出荷通知、請求書といった基本的な文書について各業界で特有のXMLバージョンが開発されるという事態を招いた。

業界特有のデータ形式にはその業界のビジネス コンテキストを最適化できるという利点がある一方で、異なるビジネス領域で同じ目的を達成するのに形式が異なるということには多くの重大なデメリットがあることも事実である。

·         発注書や請求書などの共通のビジネス文書に複数のバージョンを開発、保守することは膨大な労力の無駄である。

·         領域の境界を越えた取引を可能にするために複数のアダプターを構築し、保守することは更に多くの労力を必要とする。

·         複数のXML形式が存在すれば、XMLビジネス メッセージをバックオフィスのシステムと統合することが非常に困難となる。

·         無原則の数のXML形式をサポートするためには、高価なツールが必要なだけでなく、それを習得した作業員を見つけることが困難である。

OASIS ユニバーサル ビジネス言語 (UBL) は、総称的であり、かつ特定の業種要件に対応する拡張可能なビジネス文書のXML交換形式を定義することによって、相互運用性の問題を解決することを目的とする。特に、UBLでは次の事を提供する：

·         「住所（Address）」、「品目（Item）」および「支払（Payment）」 （日常的なビジネス文書に含まれる共通データ要素）などの再利用可能なデータ要素に対するXMLスキーマのライブラリ。

·         一般的な発注から請求までの取引コンテキストで使用される「オーダー（Order）」、「出荷通知（Despatch Advice）」、 「インボイス（Invoice）」などの共通のビジネス文書に対するXMLスキーマの小セット

·         規定の取引関係においてUBLを拡張する際のガイドライン。

XMLビジネススキーマの標準原則には、次の利点があると考えられる:

·         共通データ構造の再利用によって、企業内および企業間の統合コストを低減する

·         商用ソフトウェア コストを低減する。一定のXMLタグセットを処理するために書かれたソフトウェアの方が、無制限のタグセットに対応するソフトウェアよりはるかに開発が容易。

·         単一のライブラリをマスターすればよいことから、習得が容易である。

·         導入コストが低いことから、中小企業(SMEs)へ迅速に適用が可能である。

·         トレーニングが標準化されることから、スキルを持った作業員を多く輩出できる。

·         世界中から利用可能なシステム インテグレーターを選ぶことができる。

·         標準化と安価なデータの入出力。

UBLは法的に義務付けられたビジネス文書に対して世界中で理解かつ認知された商用構文を提供し、そして、完全な標準‐ベースのインフラストラクチャ ( 現存するEDIシステムの利益を全てのサイズのビジネスまで拡張し得る ) を提供するために、ISO 15000 ( ebXML ) のような標準のビジネスフレームワークの中で動くように設計されている。UBLは、自由に法律上の妨害、または、ライセンス料金なしで全ての人に利用可能である。

UBLスキーマの設計は、XMLと同様にモジュール形式であり、再利用および拡張が可能である。ebXML Core Components Technical Specification 2.01のインプリメンテーションとして設計されて、UBL Libraryは、Business Information Entities ( BIEs ) として知られている情報コンポーネントの概念のモデルに基づいている。これらのコンポーネントは、Order、及び、Invoiceのような特定の文書モデルに組み立てられる。これらの文書アセンブリモデルは、W3C XSD概要シンタックスへのUBL Naming、及び、Design Rulesに従って変換される。このアプローチは、この1.0のリリースにおいて指定されたそれらを越えてUBL‐ベースの文書タイプの作成を促進する。この文書は、基礎的なorder-to-invoiceビジネス手順 ( UBL文書タイプがサポートするように設計されている ) を記述する。

配置を援助するために、標準のUBL schemasは、多くの有益な支援する材料を伴う ( それらのうちのいくらかが有益なアペンディクス、及び、どちらが参照を付けられた場所から利用可能であるかのいくらかとしてこのパッケージに含まれる ) 。これらの材料は、以下を含む。

·         スキーマが基づく文書コンポーネントのUMLクラス図

·         全ての文書アセンブリを示すUMLクラス図

·         文書アセンブリを定義するスプレッドシートモデル

·         2つの実装事例に関する記述

·         それらの2つの実装に使われる各々のUBL文書の見本インスタンス

·         これらのインスタンスのレンダリング例についての表記

·         各々のUBLの基礎的なビジネス文書タイプと一致する国際連合Layout Keysのための表記法

·         バイナリー形式でのUBLメッセージ転送を可能にするASN.1 仕様

2標準の参照

[ ASN.1 ]、ITU-T X.680-X.683、シンタックス表記法1 ( ASN.1 ) を抽出;ITU-T X.690-X.693 :ASN.1符合化規則

http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-X.693-0207w.zip

http://www.oasis-open.org/committees/download.php/6320/X.680-X.693-0207w.zip

[ CCTS ] UN/CEFACT ebXML　コンポーネント技術仕様2.01

http://www.untmg.org/downloads/General/approved/CEFACT-CCTS-Version-2pt01.zip

http://www.oasis-open.org/committees/download.php/6232/CEFACT-CCTS-Version-2pt01.zip

[ ISO11179 ]、独房/IEC 11179-1:1999情報技術R12、データエレメントR12の仕様、及び、標準化;パート1 : データエレメントの仕様、及び、標準化のためのフレームワーク

http://www.iso.org/iso/en/ittf/PubliclyAvailableStandards/c002349_ISO_IEC_11179-1_1999%20(%20E%20)%20.zip

http://www.oasis-open.org/committees/download.php/6233/c002349_ISO_IEC_11179-1_1999%20(%20E%20)%20.pdf

RFCsにおける使用が要求レベルを示す[ RFC2119 ]重要なワード

http://www.faqs.org/rfcs/rfc2119.html

http://www.oasis-open.org/committees/download.php/6244/rfc2119.txt.pdf

[ UML ]モデル化言語バージョン1.5 ( 正式の/03-03-01 ) を統一、

http://www.omg.org/docs/formal/03-03-01.pdf

http://www.oasis-open.org/committees/download.php/6240/03-03-01.zip

[ XML ]拡張可能マークアップ言語 ( XML ) 1.0 ( 再版 ) 、W3C推薦2000年10月6日、

http://www.w3.org/TR/2000/REC-xml-20001006

http://www.oasis-open.org/committees/download.php/6241/REC-xml-20001006.pdf

[ XSD1 ]、XML概要パート1、構造、W3C推薦2001年5月2日

http://www.w3.org/TR/xmlschema-1/

http://www.oasis-open.org/committees/download.php/6248/xsd1.html

[ XSD2 ]、XML概要パート2、Datatypes、W3C推薦2001年5月2日

http://www.w3.org/TR/xmlschema-2/

http://www.oasis-open.org/committees/download.php/6247/xsd2.html

3条件定義

アセンブリモデル

文書概要として実行され得るツリー構造化されたモデル。

クラス図

対象クラス、及び、それらの属性、及び、関係を含んで、グラフィック表記法は、システムの静的な構造を示すために、 [ UML ]を使用した。

コンポーネントモデル

対象クラスの間での関係、及び、役割の潜在的なネットワークを示す規範化されたデータコンポーネントの表現。

コンテキスト

何かが存在する、もしくは起こる環境を形成する情況、または、出来事。

依存図

クラス図 ( 対象クラスの間で従属の関係を強調する ) の改良。

文書

情報コンポーネントのセット ( 商取引の一部として置き換えられる ) ;例えば、注文を出す際。

機能的依存

特質の別のセットが変わるとき、すなわち、前者が後者に依存しているか否かに拘らず、特質のセットの値が変わるかどうかに基づくコンポーネントを集める方法。

標準化

機能的依存を確認して、定義するための正式の技術。

スプレッドシートモデル

表のフォームにおけるアセンブリモデルの表現。

XSD概要

W3C XML Schema言語 [ XSD1 ] [ XSD2 ]に順応するXML文書定義。

コアコンポーネント ( CC ) 、基礎的なコアコンポーネント ( BCC ) 、総合したコアコンポーネント ( ACC ) 、関係コアコンポーネント ( ASCC ) 、ビジネス情報実体 ( BIE ) 、基礎的なビジネス情報実体 ( BBIE ) 、及び、総合したビジネス情報実体 ( ABIE ) は、 [ CCTS ]によって提供される意味を持って、この仕様において使われる。

Object Class、Property Term、Representation Term、及び、Qualifierは、提出された [ ISO11179 ]意味を持つこの仕様において使われる。

次に示すキーワード “MUST”、 “MUST NOT”、 “REQUIRED”、 “SHALL”、 “SHALL NOT”、 “SHOULD”、 “SHOULD NOT”、”RECOMMENDED”、 “MAY” および “OPTIONAL”が本文書内で使われる場合、これらは [RFC2119]より抜粋された下記の通りに解釈されなければならない。

4シンボル、及び、省略

ABIE

総合したビジネス情報実体

ACC

総合したコアコンポーネント

ASBIE

関連ビジネス情報実体

ASCC

関連コアコンポーネント

BBIE

基礎的なビジネス情報実体

BCC

基礎的なコアコンポーネント

BIE

ビジネス情報実体

CC

コアコンポーネント

EAN

ヨーロッパの標準化組織

EDI

電子データ交換

ISO

国際標準化機構

NDR

UBLネーミング、そして、設計規則 ( アペンディクスB.4を参照 )

UML

統合モデル化言語 [ UML ]

UN/CEFACT

取引簡易化、及び、電子ビジネスのための国連組職         

XML

拡張可能マークアップ言語 [ XML ]

XSD

W3C XML概要言語 [ XSD1 ] [ XSD2 ]

5 UBL 1.0調達プロセス

UBL 1.0文書、及び、コンポーネントライブラリは、典型的なorder-to-invoice調達サイクルをサポートするように設計されている。このセクションは、ビジネス規則、UBL 1.0文書の各々によって示された一般的プロセス、及び、役割について記述する。

UBLライブラリが1.0のパッケージにおいて供給されたそれらを越えて多種多様な文書タイプの構成をサポートするように設計されていることに注目することは、重要である。他の文書タイプが加えられ、UBLが拡張するであろうということが予測される。

5.1 Order-to-Invoiceサイクル

このモデルは、Orderから3つのパーティを包含するInvoiceまで基礎的な取引サイクルの:商品の買手、商品の売り手、及び、商品の受領者、（買手ではないかもしれない）について記述する。UBLによってこのプロセスをサポートするために供給された文書タイプは、下記を含む:

オーダ

オーダ応答　（簡易）

オーダ応答 ( 詳細 )

オーダ変更

オーダキャンセル

出荷通知

受領通知

インボイス

下の図における太枠は、一般的プロセスにおいて各文書タイプの役割を示す。

図1。Order-to-Invoiceビジネスプロセス

5.2文書ビジネス規則

このセクションは、一般的なorder-to-invoiceプロセス ( UBL 1.0における文書タイプのための情報要件として仮定される ) のビジネス規則を示す。

5.2.1　オーダー

オーダーでは輸送費、文書作成などの手数料支払（Charge Payment）について、手数料種別や、誰がどの手数料について支払うべきかについて指示することがある。オーダーは、売り手が保有する取引用のクレジット カードや、クレジット/デビット カード、または銀行引落契約で処理することができる。オーダーでは概して、価格（Pricing）、インボイス（Invoice）表示および税（Tax）処理に用いられる通貨（Currency）の指定のみが可能である。Orderの中で、追加の通貨は、個々のアイテム価格決定のためにそしてまたあらゆる割当、または、チャージのために指定され得る。

業者間割引はオーダー レベルで規定することができるが、買い手が業者間割引について知らない場合には規定されない。この場合には、売り手からの詳細な回答が必要となる。これについては、オーダ応答 ( 5.2.3 ) を参照されたい。

次に挙げる情報に関連して配送場所に適用される出荷条件や制約は、通常は出荷通知（Despatch Advice）まで表示されないが、これをオーダー上で規定することができる

: • 輸送（Transport）

• 手段（Means）

• 形態（Mode）

• 1対多行路(One-to-many-legged journey)

• 日付（Dates）

• 場所（Locations）

• 到着「時間帯」（Arrival ‘Window’）

• 積荷包装（Consignment packaging）

• 型（Type） 例：コンテナ（Container）、パレット（Pallet）

• 識別子（Identifier） 例：. SSCC, 出荷ラベル（Shipping label）[出荷通知（Despatch Advice）]

 

·         輸送

o        手段

o        形態

o        1対多行路(One-to-many-legged journey

§         日付

§         場所

o        到着「時間帯」

·         積荷包装

o        型、例：コンテナ、パレット

o        識別子、例：SSCC、出荷ラベル、出荷通知

オーダは、複数の明細行を持つ。各オーダー明細行は単一の出荷先、予定数量および希望納入日を規定する。

オーダー明細行が配送を指示する一方で、オーダーが出荷条件を規定することができる。

買い手は許容範囲で代替案を提示することができる。各オーダー明細行に代替品目（Alternative Item）を含めることができる。代替品目は品目識別子の範囲内の任意のひとつによって規定することができる。例えば、指定された数量（Quantity）は、「10x12個入りパック」の代替として「20×6入りパック」等に変更することができる。

5.2.2　オーダー確認　（簡易）

オーダー確認(簡易)　とは、売り手が買い手からのオーダーを受理したことを確認するための手段であり、変更なく納品が約束されるか、またはオーダーが拒否されたかのいずれかを意味する。

5.2.3　オーダー確認

売り手による変更案は、完全なOrder Response文書によって実現される。

オーダー確認(複合)　は、オーダーを完全に置き換えるものであり、発注取引の全状況を反映する。また、発注時点では買い手が利用できなかった、または買い手によって規定されなかったオーダーに関連する詳細について、売り手が買い手に対して確認または提供するための手段である。

·         買い手による指定日がない場合に売り手が提示する納入日（Delivery date）

·         価格

·         業者間割引

·         手数料

·         カスタム商品分類コード（Customs Commodity Classification codes）

売り手はオーダー確認(複合)を使って代替品や代用品、または必要に応じて変更を勧告することができる。代用品目（Substitute Item）または代替品目（Replacement Item）は、品目識別子の範囲内の任意のひとつによって規定することができる。例えば、指定された数量（Quantity）は「10x12個入りパック」の代替として「20×6入りパック」等に変更することができる。

5.2.4　　オーダー変更

買い手は、法的契約または業者間契約に従って、オーダー変更の送付またはオーダー取消（Order Cancellation　５．２．５を参照）とともに新規の代替オーダーを送付することによってオーダーを変更することができる。

“Order Change”は、オーダ取引の全体の現在の状態を反映する。

買い手は既に受理されたオーダーに対して変更を行うことができる。買い手は、発注品目、数量、納入日、出荷先住所の変更などの様々な理由でオーダーを変更することができる。売り手はいずれかのタイプのオーダー確認（Order Response）文書を使って、変更オーダーを受入または拒否することができる。

5.2.5　　オーダーキャンセル

買い手はプロセスの任意の時点において、オーダー取消（Order Cancellation）文書によって有効な発注取引を取り消すことができる。オーダー取消は、法的契約、業者間契約およびビジネス ルールによって、どの時点から無効になるかについて制限されることが想定される（例：製造または出荷プロセスが開始された時点）。契約や規則との関係から、オーダー取消が自動処理されるかどうかはまちまちである。ビジネス コミットメントの契約作成に関する契約条件において、これらの制約および／または規約の適用可否が決定される。

5.2.6　出荷通知

Despatch Adviceでは次に挙げる情報を含むことができる。:

·         輸送

o        手段

o        形態

o        １対多行路

§         日付

§         場所

o        到着時間帯

·         積荷包装

o        タイプ、例：容器、パレット

o        識別子、例：SSCC、出荷

o        ラベル

出荷通知は以下の2つの状況を満たす。

•　輸送制御単位（Transport Handling Unit）による品目の出荷セットの編成。これによって、受入先は輸送制御単位を検査した後に梱包品目を確認することができる。同一オーダー明細行にある同一品目のいくつかは、異なる輸送制御単位に分かれることがある。その場合はひとつの輸送制御単位で出荷明細行が分かれる。

•　出荷明細行（Despatch Line）による品目の出荷セットの編成。輸送制御単位は、オーダーとの検査を促すために注記される。便宜のために、オーダー明細行が複数の輸送制御単位に分割された場合は、それらが含まれるひとつの輸送制御単位に対してひとつの出荷明細行となる。

 

いずれの場合においても、出荷通知では以下のことを勧告することができる：

• 　全出荷（Full Despatch） — 受入先および／または買い手に対して、全ての発注品目が予定日に単一の完全な積荷で納入予定、または納入中である。

• 　部分出荷（Partial Despatch） —受入先および／または買い手に対して、発注品目の一部は予定日に単一の積荷で納入予定、または納入中である。

出荷通知の出荷明細行はオーダー明細行と1対１で対応する必要はないが、その場合は参照でリンクされる必要がある。出荷通知の情報構造は、物理的な要因によって変更された結果、ひとつのオーダー明細行が複数の出荷明細行を持つことがある。同様に、部分出荷では、ある出荷通知に含まれる明細行と照合しないオーダー明細行が存在することがある。

出荷通知では、品目の原産国（Country of Origin）および品目の危険性（Hazardous nature of the Item）について知らせることができる。

5.2.7　受領通知

Receipt Adviceは、アイテムの受取りを確認するために、売手へReceiver ( 買手 ) で送られ、そして、不足、もしくは、損傷したアイテムを報告することが可能である。

Receipt Adviceは以下の2つの状況を満たす。配送に関するクレーム処理を簡素化するためには、出荷通知の照合と同様の方法で編成される必要がある：

·         輸送制御単位（Transport Handling Unit）による受入の指示。受入明細行を含み、売り手側が詳細にした出荷通知と1対１で対応する。

·         受入明細行による受入の指示。輸送制御単位が注記され、売り手側が詳細にした出荷通知と1対１で対応する。

受入通知では、クレームによる数量不足やなんらかの理由によって受入拒否された数量について述べることができる。

現在の受入明細行（Receipt Line）では、受入拒否された数量およびその理由をひとつのみ指定することができるようになっている。しかし、複数の同一品目を異なる理由で受入拒否する場合は、受入明細行を分割し、ひとつの出荷明細行に対して複数の受入明細行を作ることで実現できる。

5.2.8　インボイス

インボイスは通常、ひとつの出荷イベントに対してひとつのインボイスという形で発行される。インボイスは全額または一部の前払支払について発行することもできる。以下のような可能性が考えられる：

·         前払いインボイス(支払が予定されている)

·         見積インボイス (支払通知であり、支払は行われない)

·         通常のインボイス（出荷された品目に対して出荷時に発行される）

·         受入通知到着後に発行されるインボイス

インボイスには請求処理に必要な情報のみが含まれる。オーダー、オーダー変更、オーダー確認（複雑）、出荷通知または受入通知などに既に含まれ、請求時に不要な情報は繰り返されない。インボイスは、オーダー、出荷通知または受入通知をレファレンス（Reference）によって参照する。

インボイスは、データ ストリームで繰り返される情報の順序に従った一連の計算を行う複合税に対応している（例：エネルギー税の上に消費税を乗せる）。

手数料には、定額または税計算前の総請求額に対する割合によって規定することができる。これには以下に挙げる手数料が含まれる：:

·         梱包料

·         配送料/郵便料金

·         運賃

·         文書作成料

インボイス明細行は関連するオーダー明細行(Order Line)を参照する。また、出荷通知明細行（Despatch Advice Line）および/または受入通知明細行(Receipt Advice Line)を参照することができる。

インボイスは現在、借方票（Debit Notes）および貸方票（Credit Notes）には対応していない。また、未決済のインボイスや借方票および貸方票を合算する残高確認書（Customer Account Statement） にも対応していない。

5.3アイテムビジネス規則

アイテム構造は、一般的プロセスにおける文書タイプの至る所を発見される。

5.3.1アイテム確認

Identifierは、各Item ( <例>、製品識別子 ) ( 下記のうちの1つであることになっている ) を確認する:

·         買手の製品識別子、または

·         売手の製品識別子、または

·         生産者の製品識別子、または

·         カタログアイテム確認、〜もしくは、

·         標準化組織によって発布されたシステムに基づいた製品識別子。

Item Identificationは、Item ( 例えば、6パック、及び、同じアイテム12パックの ) の異なる包装ごとに異なるItem Identifierを持っていると推測する。

Itemは、Measurement ( s ) 、もしくは、Physical Attribute ( s ) の仕様によって更に区別されるかもしれない。これは、次の種類のアイテムの仕様を可能にする:

5.3.1.1記述を必要とするアイテム

これは、曖昧でない機械‐processable商品コードで確認されず、そして、それを正確に確認するのに追加の記述的情報を必要とするアイテムである。

5.3.1.2顧客が定義したアイテム

This is an item that the customer describes according to his need, and in the specification of which the customer may make some reference to comparable “standard” items.

5.3.1.3測定を必要とするアイテム

これは、それがアイテムの記述的な仕様の一部として1以上の測定を指定するために必要であるアイテムである。

5.3.2アイテム価格

あらゆるあるItemに対し、amoutやquantity等による金額範囲は、売手へ繰り返されない、唯一、アクティブな価格のみが、指定される。買手は、どちらがそれをケースに入れるかにおけるItem Base Priceが指定されないということを知らないかもしれない。これによって、売手からの詳細な応答が必要になる;OrderResponseを見なさい。

5.3.3他のアイテム詳細

アイテムは、Hazardousアイテムを含むかもしれない ( オーダステージで関連の情報を指定することが必要ではないので ) 。買手は、Itemの性質に気づいていないかもしれない。ItemのHazardous性質の指示、及び、あらゆる関連情報は、Despatch Adviceで示されるであろう。

6 UBL 1.0 Schemas

UBL XSD schemasは、UBLによって定義された文書アセンブリモデルのインプリメンテーションである。それらは、UBL 1.0文書タイプ、及び、ライブラリコンポーネントの唯一の標準の表現である。

UBL 1.0 XSD schemasの全ては、UBL 1.0リリースパッケージのxsd/サブディレクトリに含まれる ( 1.0のリリースパッケージの構造に関する更に多くの情報のためのAppendix A、及び、概要モジュールの間の依存に関する情報のためのSection 6.4を見なさい ) 。xsd/ディレクトリは、更にxsd/maindoc/、xsd/common/、及び、xsd/codelist/サブディレクトリに細分化される。

For convenience in implementing the schemas, a parallel (and technically non-normative) “runtime” set with the annotation elements stripped out is provided in the xsdrt/ directory.

6.1 UBL文書Schemas

8つの基礎的な文書タイプ ( 一般的なUBL 1.0 order-to-invoiceプロセスをサポートする ) を定義するXSD schemasは、下でリストされたxsd/maindoc/ディレクトリに位置している。

オーダ

xsd/maindoc/UBL-Order-1.0.xsd

オーダ応答

xsd/maindoc/UBL-OrderResponse-1.0.xsd

オーダ応答（簡易）

xsd/maindoc/UBL-OrderResponseSimple-1.0.xsd

オーダー変更

xsd/maindoc/UBL-OrderChange-1.0.xsd

オーダキャンセル

xsd/maindoc/UBL-OrderCancellation-1.0.xsd

出荷通知

xsd/maindoc/UBL-DespatchAdvice-1.0.xsd

受領通知

xsd/maindoc/UBL-ReceiptAdvice-1.0.xsd

インボイス

xsd/maindoc/UBL-Invoice-1.0.xsd

6.2 UBLの一般のSchemas

xsd/一般のディレクトリは、xsd/maindocにおける8文書schemasが参照を付けた6 schemasを含む。これらの一般のschemasのうちの2つは、主な文書schemasが組み立てられる再利用可能なデータコンポーネントのUBLライブラリを含む;その中の３つは、類似を実行する [ CCTS ]に必要とされる定義を含む; そして、1つは、概要メタデータに一貫したフォーマットを提供する。その内容の簡単な説明と共に各概要ファイルの名前は、下で与えられる。

6.2.1再利用可能なBIE Schemas

一般の基礎的コンポーネント

xsd/common/UBL-CommonBasicComponents-1.0.xsd

This schema defines the global Basic Business Information Entities (BBIEs) that are used throughout UBL, serving, in effect, as a “global BBIE type database” for constructing documents.UBL Naming、及び、Design Rulesによって指定されたように、この概要は、Code、もしくは、Identifier datatypesを持つBBIEsを含まない;それらが使われるところはどこでも、これらは、局所的に定義される。

一般の総合したコンポーネント

xsd/common/UBL-CommonAggregateComponents-1.0.xsd

This schema defines the Aggregate Business Information Entities (ABIEs) that are used throughout UBL, serving, in effect, as an “ABIE type database” for constructing the main documents.

6.2.2再利用可能なDatatype Schemas

コアコンポーネントタイプ

xsd/common/UBL-CoreComponentTypes-1.0.xsd

この概要は、 [ CCTS ]に定義されたCore Component Typesを供給する。これらのタイプは、標準化された、そして、一貫した方法において更に高いレベルのdatatypesを組み立てるために使われる。この概要は、修正されるべきでない。

不特定のDatatypes

xsd/common/UBL-UnspecializedDatatypes-1.0.xsd

[ CCTS ]で指定されたように、この概要は、主要な、そして第2の表現期間の間Unqualified Data Typesを定義する。Core Component Typesから得られて、これらのXSD complexType構造は、全ての他のデータタイプが由来しなければならない基本資料タイプである。この概要は、修正されるべきでない。

特定のDatatypes

xsd/common/UBL-SpecializedDatatypes-1.0.xsd

この概要は、 [ CCTS ]に定義されたQualified Data Typesを供給する。これらのXSD complexType構造は、拡張、制限、及び、面のような他のコンテキスト上の制限によってUnspecialized Datatypesから得られる。 Specialized Datatypesは、UBL 1.0調達プロセスのために注文どおりに作られ、そして、更に他のビジネスコンテキストのために必要とされるサポートの追加のdatatypesまで拡張されるかもしれない。

注意事項:The terms “specialized” and “unspecialized” are used instead of the terms “qualified” and “unqualified” in order to avoid confusion with qualified and unqualified names in [XSD1] [XSD2] .

6.2.3文書メタデータ概要

コアコンポーネントパラメータ

xsd/common/UBL-CoreComponentParameters-1.0.xsd

この概要は、他の全てのschemasに現れる注釈/文書セクションの構造を定義する ( 対象クラス、表現ターム、意味の記述、及び、他の補足の情報のようなメタデータに一貫したフォーマットを提供して ) 。

6.3 UBLコードリストSchemas

13コードリストschemasは、UBLのために1.0がxsd/codelistディレクトリに含まれることを要求した。これらのコードリストschemasは、コードリスト値に対して有効とされるために、コンポーネント場合conformantを主な文書schemasのうちのどれにでも許す。UBLコードリストのために使われる表現のフォームに関する更なる情報のためにAppendix Eを見なさい。

承認応答コード

xsd/codelist/UBL-CodeList-AcknowledgementResponseCode-1.0.xsd

割当チャージ理由コード

xsd/codelist/UBL-CodeList-AllowanceChargeReasonCode-1.0.xsd

チャネルコード

xsd/codelist/UBL-CodeList-ChannelCode-1.0.xsd

チップコード

xsd/codelist/UBL-CodeList-ChipCode-1.0.xsd

国確認コード

xsd/codelist/UBL-CodeList-CountryIdentificationCode-1.0.xsd

通貨コード

xsd/codelist/UBL-CodeList-CurrencyCode-1.0.xsd

文書状態コード

xsd/codelist/UBL-CodeList-DocumentStatusCode-1.0.xsd

緯度方向コード

xsd/codelist/UBL-CodeList-LatitudeDirectionCode-1.0.xsd

ライン状態コード

xsd/codelist/UBL-CodeList-LineStatusCode-1.0.xsd

経度方向コード

xsd/codelist/UBL-CodeList-LongitudeDirectionCode-1.0.xsd

オペレータコード

xsd/codelist/UBL-CodeList-OperatorCode-1.0.xsd

支払い意味コード

xsd/codelist/UBL-CodeList-PaymentMeansCode-1.0.xsd

代用状態コード

xsd/codelist/UBL-CodeList-SubstitutionStatusCode-1.0.xsd

6.4概要依存

次の図は、UBL 1.0文書概要を含む概要モジュールの間で依存を示す。( もう一方のUMLにおいて図がこのリリースに使用したので ) 従属のコンポーネントがそれらが依存するコンポーネントを指し示すことに注目する。

図2。UBL概要依存

アペンディクスA ( 有益な ) :リリース注意事項

A.1有用性

このリリースのオンライン、そしてダウンロード可能なバージョンは、この文書のトップで指定された場所から利用可能である。

A.2パッケージ構造

UBL 1.0仕様は、cd-UBL-1.0.zipという名称のZipデータとして公表される。このZipデータを開けると、主なハイパーテキスト文書 ( この文書、index.html ) 、及び、いくつかのサブディレクトリを含むcd-UBL-1.0と指定されたディレクトリを造る。Index.htmlとリンクされたこれらのサブディレクトリにおいて、様々な１．０リリースにおける情報のピースを含む。各サブディレクトリの内容は以下に記述される。

art/

この仕様において使われる図、及び、実例

asn/

ASN.1仕様;アペンディクスFを見る

doc/

UBL TCによって造られ、そして、この仕様において参照を付けられた付属書類

fs/

書式設定仕様;アペンディクスCを見る

mod/

UBLスプレッドシートモデル;アペンディクスB.3を見る

uml/

UML図;アペンディクスB.2、B.3、及び、B.6を見る

xml/

実装例;アペンディクスDを見る

xsd/

XSD schemas ;セクション6を見る

xsdrt/

“Runtime” XSD schemas;セクション6を見る

A.3ツール

UBLは、自由なそしてまた商業UBLツールの開発を巻き起こした。UBLのための現在の利用可能なツールのリストは、UBL Tools、及び、Techniques Subcommitteeのウェブページで発見され得る:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl-ttsc.

A.4サポート

UBLは、国際的業界の有志のプロジェクトである。UBLに関する質問は、公のubl-devリストに提示され、以下のしめす場所にある。

http://lists.oasis-open.org/archives/ubl-dev/

ubl-devへの申込みは、OASISリストマネージャーを通じて、行われる

http://lists.oasis-open.org/ob/adm.pl

 

A.5の帰納的構造

ライブラリにおけるあるコンポーネントは、帰納的ネスティングを許す。例えば、Packageは、他のPackagesを含むかもしれない、Deliveryは、別のDeliveryを指定するかもしれない、等。これらは、合法的なビジネスデータ構造である。大部分の真の‐世界アプリケーションは、そのような構造において回帰の深さを制限するであろう。しかし、XSD schemasは、この制限を表すことが不可能である。Implementorsは、これに気づいているべきであり、そして、それらのアプリケーションにおいて帰納的構造の深さに制限を設けることを望むかもしれない。

アペンディクスB ( 有益な ) :UBL方法論

B.1、UBL開発アプローチ、

UBLは、特定の正式の開発方法の使用を命令しない。このセクションの目的は、implementersがこのパッケージに含まれる様々な技術的な人工品の役割を理解し得るように、UBLの開発の間に発展した手順を記述することである。それらは、それらの要求に適するために、このアプローチを適応させることに同じく決めるかもしれない。

UBL 1.0を開発するために使われるアプローチは、下の図において示される。

B-1　UBL開発プロセス

データコンポーネントの最初のUBLライブラリは、xCBL 3.0概要ライブラリ ( それ自体UN/EDIFACT、及び、ANSI X12 EDIコンポーネントライブラリに基づいた ) に基づいていた。レビューに関して、それは、反復の開発lifecycleを更によくサポートするであろうフォームにおいて実体の抽出された概念のモデルを造るために必要であると思われた。

UBLは、2タイプの概念のモデル、情報コンポーネント、及び、いかにこれらのコンポーネントが文書定義に組み立てられるかを示すことの一組のモデルを定義することの1つのモデルを使う。前者は、文書コンポーネントモデルと言われ、そして、一般にUMLクラス図を用いて提示される ( 下のB.2を見る ) ;後者は、文書アセンブリモデルと言われ、そして、一般にスプレッドシートを用いて提示される。

UBL 1.0 Procurement Processによって必要とされるコンポーネントの確認、及び、アセンブリは、領域、コンポーネントモデル、及び、要求のビジネス知識を用いてマニュアルで導かれた、の [ CCTS ]。個々のスプレッドシートは、UBL 1.0調達シナリオにおける各文書タイプのために開発され、そして、全ての再使用されたコンポーネントは、結合して個別のスプレッドシートになった。追加のスプレッドシートは、 [ CCTS ]指定されたように、Core Component Types ( CCTs ) 、Unspecialized Datatypes ( UDTs ) 、及び、Specialized Datatypes ( SDTs ) をモデル化するために使われた。UBL 1.0によって使われるスプレッドシートアセンブリモデルのフル・セットは、Section B.3において示される。

この仕様のSection 6に含まれるUBL schemasは、スプレッドシートアセンブリモデルから自動的にそれから発生した ( Section B.5において示されたプロセスに基づいたSection B.4において参照を付けられたUBL Naming、及び、Design Rulesの後で ) 。インプリメンテーションモデルは、UBLを実行する際援助として役立つために、schemasからそれから生まれた。Section B.6において供給されたこれらのUMLクラス図は、スプレッドシートにおいて示された文書アセンブリモデルのインプリメンテーションを表す。

B.2コンポーネントモデル

UBL文書コンポーネントモデルは、UBL 1.0によって定義された文書の全てにおいて使われる情報コンポーネントを示す。

文書コンポーネントモデルは、UBL 1.0 Procurement Processをサポートするために、データ要求の詳細な分析の結果である ( Section 5を見なさい ) 。モデル化プロセスの間、データの一般のアイテムは、標準化のプロセスによって機能的依存に基づく集合を確認するために確認された。適切な所で、様々なビジネス文書をサポートするためにそれらが再使用されるように、これらは、一般化された。

文書コンポーネントモデルは、次の目的のために使われる:

·         それは、再利用可能なコンポーネントR12の確認を促進する;すなわち、データ構造 ( UBL 1.0ビジネス文書の向こう側に一般的である )

·         それは、トータルのシナリオの情報要件を理解することを援助する

·         それは、BIEsがUBL文書アセンブリモデルにおいて得られて、実証されるソースである

コンポーネントモデルは、一連のUML Class Diagramsと最もよく見なされる。可読性のために、そのモデルは、文書アセンブリのために必要とされるメタデータ全てを含むとは限らない。

数字B-2は、全体のUBL文書コンポーネントモデルを示す。

B-2　UBL文書コンポーネントモデル ( 拡大するためのイメージのクリック )

この図の理解を促進するために、それは、いくらかのパッケージに分解された。各パッケージは、コンポーネントの論理的分類を表し、そして、それ自身のUMLクラス図 ( パッケージにおいて集められたコンポーネントに属する双方の属性 ( 基礎的BIEs ) 、及び、対象クラス ( 総合したBIEs ) を示す ) によって示される。各パッケージの範囲は、随意であり、そして、これらの図を越えて意味を全く保持しない。

例えば、Partyの再利用可能なコンポーネントパッケージは、下で示される。

B-3　パーティコンポーネントパッケージ

全てのUBLコンポーネントのためのパッケージの完全なセットは、下でリストされる。

アドレスパッケージ

uml/concept/comp/UBL-1.0-AddressPackage.jpg

契約パッケージ

uml/concept/comp/UBL-1.0-ContractPackage.jpg

供給パッケージ

uml/concept/comp/UBL-1.0-DeliveryPackage.jpg

文書参照パッケージ

uml/concept/comp/UBL-1.0-DocumentReferencePackage.jpg

冒険的なアイテムパッケージ

uml/concept/comp/UBL-1.0-HazardousItemPackage.jpg

アイテムパッケージ

uml/concept/comp/UBL-1.0-ItemPackage.jpg

パーティパッケージ

uml/concept/comp/UBL-1.0-PartyPackage.jpg

支払いパッケージ

uml/concept/comp/UBL-1.0-PaymentPackage.jpg

調達パッケージ

uml/concept/comp/UBL-1.0-ProcurementPackage.jpg

税パッケージ

uml/concept/comp/UBL-1.0-TaxPackage.jpg

特定の方向は、これらのモデルにおける関係のために定義されない;それらは、どちらの方向においてでも操縦され得る。文書が組み立てられるとき、各関係のための特定の航行道は、定義される。

B.3文書アセンブリモデル

異なるタイプの文書を定義するために、前のセクションで述べられたコンポーネントは、コンテキストR12の要求に基づくhierarachicalな構造に組み立てられる;このケースにおいて、UBL 1.0調達プロセスR12 ;そして、メタデータ要求、の [ CCTS ]。

文書アセンブリは、文書タイプのためにAggregate BIE ( 対象クラス ) としてUBL 1.0を含む各々のビジネス文書の定義で始まる。文書タイプのための他の全てのAggregate BIEs ( 対象クラス ) は、必要とされたヒエラルキーを形成するために、このAggregate BIEから関係を横切ることによって得られる。Aggregate BIEsの間の各関係に選ばれた役割は、関係BIEsになる。

例えば、トップレベルのUBL 1.0 Order文書の文書アセンブリモデルは、UMLクラス図を使うことの下方で示される。

B-4　オーダ文書アセンブリモデル

UBL 1.0によって定義された8つのビジネス文書のトップレベル文書アセンブリモデルは、下で与えられる。

オーダアセンブリモデル

uml/concept/assy/UBL-1.0-OrderDocumentAssembly.jpg

オーダ応答アセンブリモデル

uml/concept/assy/UBL-1.0-OrderResponseDocumentAssembly.jpg

オーダ応答シンプルなアセンブリモデル

uml/concept/assy/UBL-1.0-OrderResponseSimpleDocumentAssembly.jpg

オーダー変更アセンブリモデル

uml/concept/assy/UBL-1.0-OrderChangeDocumentAssembly.jpg

オーダキャンセルアセンブリモデル

uml/concept/assy/UBL-1.0-OrderCancellationDocumentAssembly.jpg

出荷通知アセンブリモデル

uml/concept/assy/UBL-1.0-DespatchAdviceDocumentAssembly.jpg

受領通知アセンブリモデル

uml/concept/assy/UBL-1.0-ReceiptAdviceDocumentAssembly.jpg

インボイスアセンブリモデル

uml/concept/assy/UBL-1.0-InvoiceDocumentAssembly.jpg

UMLを使う文書アセンブリモデルを開発することが可能である、と同時に、それは、スプレッドシート表記法、以下であるキー利点を使うために、実際上更に容易であるのを発見された。

·         [ CCTS ]必要とされる追加のメタデータは、容易に定義される

·         定式は、規則を指定することに適用され得る

·         スプレッドシートは、直接候補者Core Components必要とされたbyUN/CEFACT TBG17のための服従フォーマットにマップされ得る

·         スプレッドシートは、データモデル化に関して責任があるビジネスエキスパートによく知られている

·         そのフォーマットは、アプリケーションの間で携帯用であると証明された

これらの利点は、スプレッドシート表記法の主な欠点 ( モデル化言語そのものの参照の整合性コントロールの欠如である ) を上回るのが感じられた;手動の編集は、変化の衝撃をコントロールするのに必要とされる。幸いにも、この場合、幸いにも、スプレッドシートから最終のschemasを発生させるために使われる商業ツールは、同じくモデル完全性を証明することが可能であった。

B.3.1スプレッドシートモデル

UBLは、コンポーネントのアセンブリを特定のタイプの文書に示すためにスプレッドシートを使う。各文書タイプの1つのスプレッドシートアセンブリモデルがある。

用語の後で、の [ CCTS ]、文書アセンブリモデルは、Basic Business Information Entities ( コンポーネントモデルの属性 ) 、Aggregate Business Information Entities ( コンポーネントモデルの対象クラス ) 、及び、Associated Business Information Entities ( コンポーネントモデルにおける関係の役割 ) の結合から成る。BBIEs can be considered the “leaf nodes” of the data structures, ABIEs as structures that contain BBIEs, and ASBIEs as the containership of one ABIE within another.

スプレッドシートモデルは、コンポーネントを定義するために列を使う。コンポーネントは、BIEsかデータタイプのいずれかである。コラムは、各コンポーネントタイプと関連していたメタデータを定義する。多数のスプレッドシートコラムは、要求によって [ CCTS ]決定される。

A spreadsheet assembly model will therefore consist of a “root” ABIE, a set of BBIEs, and a set of ASBIEs.The ABIEs associated with the “root” ABIE are defined in a Reusable BIE spreadsheet model.

BBIEs全てのためのデータタイプは、同様にUnspecialized Datatypesスプレッドシートモデル、または、Specialized Datatypesスプレッドシートモデルにおいて定義される。

これらのスプレッドシートアセンブリモデルの間の依存は、下の図において示される。

B-5　スプレッドシートモデル依存

下で示されたように、このパッケージに含まれるスプレッドシートファイルは、マイクロソフトエクセルフォーマット ( .xls ) と、Open Officeフォーマット ( .sxc ) の両方において供給される。

注意事項:UBL文書schemasは、これらのスプレッドシートモデルから自動的に発生する。しかしながら、標準の形のUBL文書は、これらのスプレッドシートモデルではなく、XSD schemasそのもの ( Section 6に供給される ) である。

B.3.2文書スプレッドシート

各ビジネス情報実体 ( BIE ) は、1つの列において定義される。列バックグラウンド色は、BBIE ( 白 ) 、ABIE ( ピンクの ) 、及び、ASBIE ( グリーン ) を区別する。

オーダ文書スプレッドシート

mod/maindoc/UBL-Order-1.0.sxc

mod/maindoc/UBL-Order-1.0.xls

オーダ応答文書スプレッドシート

mod/maindoc/UBL-OrderResponse-1.0.sxc

mod/maindoc/UBL-OrderResponse-1.0.xls

オーダ応答シンプルな文書スプレッドシート

mod/maindoc/UBL-OrderResponseSimple-1.0.sxc

mod/maindoc/UBL-OrderResponseSimple-1.0.xls

オーダー変更文書スプレッドシート

mod/maindoc/UBL-OrderChange-1.0.sxc

mod/maindoc/UBL-OrderChange-1.0.xls

オーダキャンセル文書スプレッドシート

mod/maindoc/UBL-OrderCancellation-1.0.sxc

mod/maindoc/UBL-OrderCancellation-1.0.xls

出荷通知文書スプレッドシート

mod/maindoc/UBL-DespatchAdvice-1.0.sxc

mod/maindoc/UBL-DespatchAdvice-1.0.xls

受領通知文書スプレッドシート

mod/maindoc/UBL-ReceiptAdvice-1.0.sxc

mod/maindoc/UBL-ReceiptAdvice-1.0.xls

インボイス文書スプレッドシート

mod/maindoc/UBL-Invoice-1.0.sxc

mod/maindoc/UBL-Invoice-1.0.xls

B.3.3の一般のコンポーネントスプレッドシート

再利用可能なBIEsスプレッドシート
This model provides the Aggregate Business Information Entities (ABIEs) that are used throughout UBL, serving, in effect, as an “ABIE type database” for constructing the main documents. このモデルは、カスタマイゼーションにおいて修正されるかもしれない。
キー:各ビジネス情報実体 ( BIE ) は、1つの列において定義される。列バックグラウンド色は、BBIE ( 白 ) 、ABIE ( ピンクの ) 、及び、ASBIE ( グリーン ) を区別する。

mod/common/UBL-Reusable-1.0.sxc

mod/common/UBL-Reusable-1.0.xls

コアコンポーネントタイプスプレッドシート
このモデルは、 [ CCTS ]定義されたCore Component Typesを供給する。これらのタイプは、標準化された、そして、一貫した方法において更に高いレベルのdatatypesを組み立てるために使われる。このモデルは、修正されるべきでない。
キー:各コアコンポーネントタイプ ( CCT ) は、1つの列において定義される。列バックグラウンド色は、Supplementary Components ( 白 ) 、及び、コアコンポーネントタイプ ( ピンクの ) を区別する。

mod/common/UBL-CoreComponentTypes-1.0.sxc

mod/common/UBL-CoreComponentTypes-1.0.xls

不特定のDatatypesスプレッドシート
このモデルは、 [ CCTS ]定義されたUnqualified Data Typesを指定する。これらのタイプは、標準化された、そして、一貫した方法において更に高いレベルのdatatypesを組み立てるために使われる。このモデルは、修正されるべきでない。
キー:各データタイプ ( DT ) は、1つの列において定義される。列バックグラウンド色は、Supplementary Components ( 白 ) 、及び、データタイプ ( ピンクの ) を区別する。

mod/common/UBL-UnspecializedDatatypes-1.0.sxc

mod/common/UBL-UnspecializedDatatypes-1.0.xls

特定のDatatypesスプレッドシート
このモデルは、 [ CCTS ]定義されたQualified Data Typesを指定する。これらのタイプは、特定のインプリメンテーションに注文どおりに作られた更に高いレベルのdatatypesを組み立てるために使われる。UBLは、Specialized Datatypesとしてコードリストに対して確認を必要とするBBIEsのためにdatatypesを定義することに決めた。このモデルにおいて与えられたように、それらは、特定の形の一定値を持つCode datatypeである。これらのコードリストのインプリメンテーションが各コードリストのための個々のschemasとして実現することに注目しなさい。このモデルは、カスタマイゼーションにおいて修正されるかもしれない。
キー:各データタイプ ( DT ) は、1つの列において定義される。列バックグラウンド色は、Supplementary Components ( 白 ) 、及び、データタイプ ( ピンクの ) を区別する。

mod/common/UBL-SpecializedDatatypes-1.0.sxc

mod/common/UBL-SpecializedDatatypes-1.0.xls

B.3.4　カスタマイジング・モデル

UBLを注文どおりに作ることを望むそれらが下のB.7から参照を付けられたUBL 1.0 schemasのカスタマイゼーションのガイドラインに従うべきである、と同時に、ComponentかAssemblyモデルのいずれかを直接修正し、そして、UBLを新しい語彙のベースとして使うことに決める人々は、次の考察事項に気づいているべきである、それ、UBLを持つ衝撃両立性:

·         最初に、スプレッドシートモデルのあらゆる修正は、それらの構造、ebXML Core Components Technical Specification [ CCTS ]、及び、様々なUBLライブラリ成分の理解を必要とする。例えば、いくらかのコラムは、直接アップデートされる、一方、他のものは、それらの細胞に定式を持っている、インプリメント [ CCTS ]、及び、UBL Naming、及び、Design Rules。これの認識は、列内容を加えている、もしくは編集していたとき、必要である。注意は、定式を含む細胞をアップデートすることを回避するように払われるべきである。

·         第二に、概要世代は、他のUBLコンポーネントライブラリと共に両立性を促進するために、UBL Naming、及び、Design Rules ( 下のB.4 ) と共に従順であるべきである。

·         3番目に、Core Component Types、及び、Unspecialized Datatypesモデルにおいて定義されたデータタイプは、 [ CCTS ]定義されたそれらの直接的なインプリメンテーションであり、そして、この事実の認識なしでは修正されるべきでない。Specialized Data Typesモデルは、インプリメンテーション‐特定のデータタイプに提供される。

UBL 1.0文書コンポーネント、及び、文書アセンブリモデルは、OASIS UBL Library Content Subcommitteeの製品である。UBL LCSCの仕事は、LCSCウェブページで見られ得る:

http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-lcsc

B.4 UBLネーミング、そして、設計規則

このパッケージに含まれるUBL XML Naming、そして、Design Rules ( NDR ) 照合表は、UBL 1.0 XSD概要構造、及び、エレメント/属性の名前を決定するために使われる規則を示す。NDR照合表は、次のファイルとしてこのパッケージにおいて発見され得る:

doc/ndr/UBL-NDR-Checklist-1.0.pdf

UBLネーミング、そして、設計規則は、オアシスUBL NDR小委員会の製品である。UBL NDRSCの仕事は、NDRSCウェブページで見られ得る:

http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-ndrsc

B.5概要世代

UBL 1.0 XSD schemasは、概要建設規則を上のB.3において示されたUBLスプレッドシートによって表されたData Modelに適用する変形のアウトプットである。変形プロセスは、次のステップから成った:

1. データモデルスプレッドシートを丹念に調べること
2. 各スプレッドシートから増大すること、内部のUML‐ベースのモデル、
3. 適切であるので、コードリストの外部の基準を確認し、しかも、標準のコードを含むことは、値をリストする
4. UBLネーミング、そして、設計規則を適用すること
5. conformant XSD schemasをアウトプットすること

商業のCC‐知識がある概要世代ツール、GEFEG EDIFIX 5.0は、UMLデータモデルとしてスプレッドシートを読むために使われ、それらと共にQ/Aを遂行し、そして、下で例証されたように、UBL 1.0 Naming、及び、Design Rulesに付着する概要表現を生み出す。GEFEG EDIFIXに関する情報のために、 http://www.gefeg.com/en/standard/xml/ubl.htm見る。 GEFEG EDIFIX 5.0 UBL Readerは、自由で、そして、UBL schemas、そして、データモデルの容易な見ることを提供する。GEFEG EDIFIX UBLリーダに関する情報のために、 http://www.gefeg.com/en/edifix/reader-ubl.html見る。

B-6　UBL概要世代プロセス

UBL仕様の前のドラフトは、このプロセスのために異なるツールを使った。1.0 Beta schemasをUBLにもたらすために使われるプロセスの記述のために、 http://www.oasis-open.org/committees/ubl/lcsc/UBLv1-beta/で1.0 Beta Committee DraftのAppendix Dを見る。

UBL 1.0概要生成は、OASIS UBL Tools、及び、Techniques Subcommitteeの方向の下で行われた。UBL TTSCの仕事は、TTSCウェブページで見られ得る:

http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-ttsc

B.6インプリメンテーションモデル

UBLのインプリメンテーションモデルは、UMLモデルとして現実のUBL XSD schemasを表す。これは、schemasをUnified Modeling Language [ UML ]を持つモデルconformantに自動的に変えることによって生産される。このモデルは、各々の主な文書を例証するクラス図のセット、及び、再利用可能なコンポーネントのいくらかの見解を生み出すためにそれから使われる。自動化された変形、及び、図創造は、商業schema-to-UML変形ツール、Ontogenicsハイパー‐モデルを用いて行われた。この製品に関する更なる詳細のために、 http://www.xmlmodeling.com/見る。

このセクションに含まれるUMLクラス図は、XSDシンタックスの理解を必要とせずにUBL schemasを理解するのを助けることを意図している。これをするために、それらの図は、schemasに含まれるいくらかの詳細を故意に隠す。例えば、複合的なタイプ定義の中のエレメントのオーダに関する情報は、図において守られない。 UMLモデルをソフトウェアエンジニアリングにとって有益にするために他の変更が行われた; for example, the “Type” suffixes of XSD complexType names are removed when creating the UML class name to yield an object class name independent of XSD syntax, and complex type child elements with simple content values are represented as class attributes, whereas elements with complex content are represented as associations to those type classes.

これらの図は、文書アセンブリスプレッドシートモデルの相当するUMLである。

B.6.1文書インプリメンテーション図

インプリメンテーションクラス図は、8 UBL 1.0文書タイプの各々のために造られた。上で注目に値されたように、インプリメンテーション図は、これらの総合した構造に含まれるタイプの詳細を隠す単純化された見解である。例として、UBL Order文書のためのクラス図は、下の数字において示される。

B-7　オーダ文書のインプリメンテーションモデル

UBL 1.0パッケージに含まれる文書インプリメンテーションクラス図は、下でリストされる。

オーダインプリメンテーション図

uml/implem/doctypes/UBL-OrderImplementationDiagram-1.0.gif

オーダ応答インプリメンテーション図

uml/implem/doctypes/UBL-OrderResponseImplementationDiagram-1.0.gif

オーダ応答シンプルなインプリメンテーション図

uml/implem/doctypes/UBL-OrderResponseSimpleImplementationDiagram-1.0.gif

オーダー変更インプリメンテーション図

uml/implem/doctypes/UBL-OrderChangeImplementationDiagram-1.0.gif

オーダキャンセルインプリメンテーション図

uml/implem/doctypes/UBL-OrderCancellationImplementationDiagram-1.0.gif

出荷通知インプリメンテーション図

uml/implem/doctypes/UBL-DespatchAdviceImplementationDiagram-1.0.gif

受領通知インプリメンテーション図

uml/implem/doctypes/UBL-ReceiptAdviceImplementationDiagram-1.0.gif

インボイスインプリメンテーション図

uml/implem/doctypes/UBL-InvoiceImplementationDiagram-1.0.gif

B.6.2の再利用可能なコンポーネントインプリメンテーション図

主な文書図に加えて、このリリースは、10のクラス図 ( 文書において使われる再利用可能なコンポーネントのパッケージの見解を提示する ) を含む。例えば、Order図は、Party、売手Party、及び、買手Partyに関係を含む。次のインプリメンテーション図は、詳細にこれらのコンポーネントを示す。

B-8　パーティコンポーネントのインプリメンテーションモデル

UBL 1.0を供給されたコンポーネントインプリメンテーション図は、次のとおりである:

アドレスインプリメンテーション図

uml/implem/packages/UBL-AddressImplementationDiagram-1.0.gif

契約インプリメンテーション図

uml/implem/packages/UBL-ContractImplementationDiagram-1.0.gif

配送ラインインプリメンテーション図

uml/implem/packages/UBL-DespatchLineImplementationDiagram-1.0.gif

文書リファレンス・インプリメンテーション図

uml/implem/packages/UBL-DocumentReferenceImplementationDiagram-1.0.gif

冒険的なアイテムインプリメンテーション図

uml/implem/packages/UBL-HazardousItemImplementationDiagram-1.0.gif

アイテムインプリメンテーション図

uml/implem/packages/UBL-ItemImplementationDiagram-1.0.gif

パーティインプリメンテーション図

uml/implem/packages/UBL-PartyImplementationDiagram-1.0.gif

支払いインプリメンテーション図

uml/implem/packages/UBL-PaymentImplementationDiagram-1.0.gif

調達インプリメンテーション図

uml/implem/packages/UBL-ProcurementImplementationDiagram-1.0.gif

出荷インプリメンテーション図

uml/implem/packages/UBL-ShipmentImplementationDiagram-1.0.gif

税インプリメンテーション図

uml/implem/packages/UBL-TaxImplementationDiagram-1.0.gif

B.7カスタマイゼーションガイドライン

いかに互換性があるカスタマイゼーションが可能ではないとき、続くかのために提案と共にUBL schemasと互換性があるカスタマイゼーションを行うためにガイドライン、このパッケージにおいて発見され得る、際、

doc/cm/wd-ubl-cmsc-cmguidelines-1.0.html

UBLカスタマイゼーションガイドラインは、オアシスUBLコンテキスト方法論小委員会の製品である。UBL CMSCの仕事は、CMSCウェブページで見られ得る:

http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-cmsc

アペンディクスC ( 有益な ) :フォーマッティング仕様

UBL 1.0パッケージは、ハイパードキュメントにおいてフォーマッティング仕様にもとづく広いセットを含む、

fs/index.html

同じくパッケージのこの部分は、下のAppendix Dで供給された例場合のPDF演技表現を含む。

UBL書式設定仕様は、オアシスUBLフォーム提示小委員会の製品である。UBL FPSCの仕事は、FPSCウェブページで見られ得る:

http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-fpsc

アペンディクスD ( 有益な ) :実装例

このアペンディクスは、order-to-invoiceプロセスの2つの異なる説明に使われるUBL文書の例を提供する。例の最初のセットは、事務用品の購入を例証し、そして、第2のセットは、建具職 ( 建設用備品 ) の購入を例証する。同じく含まれる、Appendix Cで参照を付けられた書式設定仕様に従って造られた各例文書のプリントされたバージョンである。

D.1例1 :事務用品を買うこと

The 買手, Bill’s Microdevices, orders several different items from an office supply store.The 買手 knows the supplier’s codes for the items and the price for each.

事務用品Order例場合

xml/office/UBL-Order-1.0-Office-Example.xml

プリントアウト

fs/Order/pdf/OfficeOrder.Example-a4.pdf

fs/Order/pdf/OfficeOrder.Example-us.pdf

その買手は、オリジナルのオーダを変えることを決定する。

事務用品のオーダー変更

xml/office/UBL-OrderChange-1.0-Office-Example.xml

プリントアウト

fs/OrderChange/pdf/OfficeOrderChange.Example-a4.pdf

fs/OrderChange/pdf/OfficeOrderChange.Example-us.pdf

The 売手, Joe’s Office Supply, replies with an Order Response Simple to indicate the acceptance of the order.同じく売手は、彼の参照番号をオーダに与える、すなわち、それらの販売は、彼のシステムにおいて命令し、そして、彼にあらゆる質問があるならば、誰に連絡するかを買手に告げる。

事務用品のオーダー応答（簡易）

xml/office/UBL-OrderResponseSimple-1.0-Office-Example.xml

プリントアウト

fs/OrderResponseSimple/pdf/OfficeOrderResponseSimple.Example-a4.pdf

fs/OrderResponseSimple/pdf/OfficeOrderResponseSimple.Example-us.pdf

その買手は、Order ( 同じものではなく実例の目的のために ) をキャンセルする。

事務用品のオーダーキャンセル

xml/office/UBL-OrderCancellation-1.0-Office-Example.xml

プリントアウト

fs/OrderCancellation/pdf/OfficeOrderCancellation.Example-a4.pdf

fs/OrderCancellation/pdf/OfficeOrderCancellation.Example-us.pdf

その売手は、命令されたアイテムを急送の買手に通知する。

事務用品の出荷通知

xml/office/UBL-DespatchAdvice-1.0-Office-Example.xml

プリントアウト

fs/DespatchAdvice/pdf/OfficeDespatchAdvice.Example-a4.pdf

fs/DespatchAdvice/pdf/OfficeDespatchAdvice.Example-us.pdf

その買手は、欠けているアイテムを売手に通告する。

事務用品受領通知に実装零

xml/office/UBL-ReceiptAdvice-1.0-Office-Example.xml

プリントアウト

fs/ReceiptAdvice/pdf/OfficeReceiptAdvice.Example-a4.pdf

fs/ReceiptAdvice/pdf/OfficeReceiptAdvice.Example-us.pdf

その急送が発生するとき、その売手は、自動的にInvoiceを上げ、そして、不足等の分解は、扱われたポスト‐インボイスを作ることである。Invoiceは、課税額を示す。その売手は、支払いがInvoiceの30日以内に支払われるべきであることに注目する。

事務用品Invoiceの実装例

xml/office/UBL-Invoice-1.0-Office-Example.xml

プリントアウト

fs/Invoice/pdf/OfficeInvoice.Example-a4.pdf

fs/Invoice/pdf/OfficeInvoice.Example-us.pdf

D.2例2 :建具職 ( 建設用備品 ) を買うこと

買手、Jerry Builders、UKにおける社は、いくつかの窓、ドアセット、及び、建築現場への供給のための材木のいくらかの長さを整理する。Jerry knows the supplier’s codes for the items, and that he must also specify a number of physical attributes to get the precise item that he wants:some windows are asymmetric and are “handed” left or right;大部分のドアセットは、1つのサイドで蝶番が付いているので、手がある;the wood and its finish must be specified, as must the “fittings” (handles, stays etc.).アイテムは、異なる方法でガラスをはめられ得る。緩い材木は、その断面積に従ってコード化され、そして、その長さは、指定されなければならない。その買手がこれらのものをカタログと区別する、と同時に、彼は、得るかもしれない時価、及び、全く割引率を知らない。

建具職オーダ例場合

xml/joinery/UBL-Order-1.0-Joinery-Example.xml

プリントアウト

fs/Order/pdf/JoineryOrder.Example-a4.pdf

fs/Order/pdf/JoineryOrder.Example-us.pdf

売手、Specialist Windows PLCは、各アイテムの単価を示し、そして、与えられるであろう業者間取引を買手に通知するために、詳細なOrder Responseと共に返答する。それと同時に、その売手は、彼の参照番号をオーダ、すなわち、彼のシステムにおけるオーダの同一性に与え、そしてまた、彼にあらゆる質問があるならば、誰に連絡するかを買手に告げる。

建具職オーダ応答の実装例

xml/joinery/UBL-OrderResponse-1.0-Joinery-Example.xml

プリントアウト

fs/OrderResponse/pdf/JoineryOrderResponse.Example-a4.pdf

fs/OrderResponse/pdf/JoineryOrderResponse.Example-us.pdf

The 売手 advises the 買手 of the despatch of the items ordered, which will in fact be delivered on two pallets (i.e., transportation units) identified as “A” and “B”.それらのアイテムが順番に線を引くDespatch Adviceリスト、連続、そして、そのアイテムが配達されるパレットを参照する。

建具職出荷通知の実装例

xml/joinery/UBL-DespatchAdvice-1.0-Joinery-Example.xml

プリントアウト

fs/DespatchAdvice/pdf/JoineryDespatchAdvice.Example-a4.pdf

fs/DespatchAdvice/pdf/JoineryDespatchAdvice.Example-us.pdf

Despatch Adviceは、供給と共に旅行する;紙コピーは、受取りの証拠として署名されて、返される。従って、UBL受領通知は、使われない。

その急送が発生するとき、売手は、自動的にInvoiceを上げ、そして、あらゆる不足の分解は、扱われたポスト‐インボイスを作ることである。Invoiceは、税ポイント日付、そのアイテムが属する付加価値税 ( Value Added Tax ) カテゴリ、そしてまた、付加価値税レート、及び、インボイス上の各税区分のためのトータルを示さなければならない。付加価値税は、同じく供給追加料金のようなチャージに適用される。満期支払高の速い支払いを奨励するために、売手は、迅速な解決 ( 30日以内に支払っているならば、その買手が差し引くことができる ) のために割引をする。( この例は、規則が割引かれた取引に関して付加価値税がとられるであろう、従って、ここの税が計算される、と推測するコンテキストのためにラインアイテム、プラス、あらゆるチャージのトータル、及び、あまり解決が量を割引かないということを手紙で知らせられた。 )

建具職インボイスに実装例

xml/joinery/UBL-Invoice-1.0-Joinery-Example.xml

プリントアウト

fs/Invoice/pdf/JoineryInvoice.Example-a4.pdf

fs/Invoice/pdf/JoineryInvoice.Example-us.pdf

この例は、製品、製品確認、ビジネス要求、及び、真のUK建具職メーカー、及び、販売会社の実践に基づいている。それは、それ自身の特定の輸送艦隊、英国の至る所の、そして、沖合の島への荷渡しを手術する。

アペンディクスE ( 有益な ) :コードリスト

UBL 1.0に含まれるコードリストschemasは、Code List Representation ( このパッケージにおいて発見され得る、際 ) のためのUBL仕様に順応する

doc/cl/wd-ublclsc-codelist-20040420.pdf

UBLコードリスト表現仕様は、オアシスUBLコードリスト小委員会の製品である。UBL CLSCの仕事は、CLSCウェブページで見られ得る:

http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-clsc

アペンディクスF ( 有益な ) :ASN.1仕様

下で参照を付けられたUBL ASN.1仕様は、ITU-T X.680-X.693 [ ASN.1 ]に従ったUBL文書に代替概要定義を提供する。UBL ASN.1仕様は、正当なUBL文書の標準の定義を構成するSection 6においてUBL XSD schemasと同じUBL文書を定義する。UBL ASN.1 XML概要によって、ASN.1ツールはUBL移動のために使われることが可能になり、そして、ASN.1 Packed Encoding Rulesと共に、それは、UBLメッセージの効率的な2元エンコーディングに仕様を提供する。

UBL ASN.1仕様

asn/ASN.1-UBL-1.0.html

ASN.1 UBL仕様は、順応する OSS Nokalva ( http://www.oss.com/ ) からITU-T Recommendation X.694までツールを用いて造られた|XSD概要をASN.1に変えるための独房/IEC 8825-5。変換の後で、発生したASN.1は、 ASN.1 Information Site ( http://asn1.elibel.tm.fr ) のPrettyPrintツールによってこのパッケージに含まれるHTMLファイルを生産するためにフォーマットされた。

アペンディクスG ( 有益な ) :進行中の作業アイテム

UBL 1.0は、UBLチャーターR12の最初のフェーズの基礎的な目的を達成する; XMLビジネス文書の使える標準のライブラリを開発するために。セカンド・フェーズ ( UBL 2.0 ) は、UBLライブラリ、及び、概要セット、及び、コンテキスト‐特定のビジネスschemasの自動世代のメカニズムへの追加を生み出すことを意図している。

これらの間に、マイルストーンは、ある、いくつかの仕事アイテム、それは、どういうわけか完成されないであろう、UBL 1.0の供給に間に合うように。いくらかのこれらのアイテムは、継続的関心の仕事を表す;他のものは、問題がUBL 1.0供給 ( 受け入れられる短期戦略がUBL 1.0文書の長期の妥当性に対する衝撃はほとんどなしで採用されるであろう ) にセットされた時間の内にコンセンサスソリューションを達成しないであろう場合を表す、場合。UBL TCは、これらの問題を解決し、そして、UBL 1.0場合を持つ上位互換性であろうUBL 1.1と呼ばれるアップデートされたバージョンをリリースするつもりである。

下記において、これらの仕事アイテムは、4つの見出しの下で緩く集められた:NDR仕事アイテム、インタオペラビリティ仕事アイテム、登記仕事アイテム、及び、局部化は、アイテムを機能させる。仕事のこのプログラムに参加することに関心を持つ人は、OASIS UBL TCを結合するよう勧められる。

G.1 NDR仕事アイテム

次のアイテムは、UBL Naming、及び、Design Rules ( NDR ) と関係がある。

個別の仕様としてのUBL NDRのG.1.1発表

時間制限は、UBL 1.0による供給のための個別の仕様としてのUBL Naming、そして、Design Rules ( NDR ) 文書の完成を妨げた;このパッケージに含まれ、そして、1.0のために規則照合表のみ含むように[ NDR ]、参照を付けられた文書。仕事は、個別のOASIS技術仕様として服従に備えてNDR文書を準備し続ける。

コードリストカスタマイゼーションのためのG.1.2代用グループ

UBL Code List Subcommitteeは、コードリストカスタマイゼーションの件をXSD代用グループに頼るコードリスト ( Appendix Eを見る ) に対する包括的な解決を生み出した。ビジネス文書schemasにおけるXSD代用グループの使用に関して明瞭な産業コンセンサスを欠いて、UBL TCは、コードリストの未決定の更なる討論のためにこの拡張メカニズムの採用を延期した。注意は、UBL 1.0場合を無効にすることなしの後のリリースにおける代用グループ ( 適切であると思われたならば ) の採用を許すであろう方法でUBL 1.0を組み立てるように払われた。

Codelist概要モジュールのG.1.3輸入

Specialized Datatype概要 ( セクション6.2.2 ) によって、もしくは、直接Common Aggregate Component概要 ( セクション6.2.1 ) 、及び、それらが使われるあらゆる個々の文書schemasに間接的にcodelist概要モジュール ( セクション6.3 ) を輸入することが更に良いか否かに拘らず、それは、未決問題である。UBL 1.0において、codelist概要モジュールは、直接輸入される。しかし、懸念は、可能なパフォーマンスに対する衝撃に関して生じた。UBL 1.0インプリメンテーションからのフィードバックは、この問題を解決する際頼られるであろう。これに代るものへの変化は、UBL 1.0例を好むと予測されない。

資格のあるBBIE特質エレメント定義のG.1.4場所

UBL 1.0において、全てのBBIE特質は、エレメントとして宣言され、そして、Common Basic Components概要 ( セクション6.2.1 ) における複合的なタイプと定義される。代りに、資格のあるBBIE特質エレメントは、どちらにおいてでも宣言されるであろう、Common Aggregate Components概要、〜もしくは、個々の文書schemasにおいて、それらがどこにあるかは、使用した。この問題は、開いた状態を維持する。しかし、将来のリリースの変化は、UBL 1.0場合に全く影響を及ぼさないであろう。

G.2登記仕事アイテム

次の問題は、UBL schemasの保管、及び、登録に関係する。

概要モジュールにおけるG.2.1の相対的な道

UBL NDRは、概要場所のための絶対的道名の必要条件を確認した ( 一貫性、明瞭さ、及び、UBLの標準のschemasが実際使われつつあるという絶対的保証を保証するために標準の必要な必要条件がschemasの基礎を築いたので ) 。しかしながら、現在のOASISアーキテクチャ制限は、この要求を立証するために、適当な登記/貯蔵所の有用性を排除する。その結果、UBL 1.0は、オフラインの確認を促進し、そして、それらの制限の周辺で働くために、schemasの場所のための相対的な道名を用いて解放された。支援するインフラストラクチャが利用可能になるので、絶対的道、及び、コンポーネントライブラリのための登記の使用は、将来のバージョンにおいて実行されるであろう。

全てのBIEの文書におけるG.2.2バージョンエレメント

UBL 1.0は、各UBL datatype、及び、BIEのバージョン数が同じく1.0であると推測する。しかしながら、これが概要構造物人工品、または、貯蔵人工品であるかどうかに関してはいくらかの討論がある。この決定の結果は、datatype、及び、BIE概要が構成する各々の注釈文書におけるバージョン番号を定めるために、要求に帰着するかもしれない。

G.3インタオペラビリティ仕事アイテム

次の仕事アイテムは、産業を横断して、そして、他のビジネス文書標準に関してUBL文書のインタオペラビリティに関係する。

G.3.1 UBL類似

非常に最初の仕事がUBL 1.0 Customization Guidelines ( Appendix B.7を見る ) でUBL類似の概念を定義する方へされた、と同時に、更なる仕事は、UBL類似 ( 法律上の、そして規定のコンテキストにおいて使用できる ) の定義を引き起こすために必要である。

G.3.2産業プロフィール

特別な産業、及び、地理的領域の中でスタンダードであるバージョンを造るためにUBL 1.0がUBL Customization Guidelinesに従って修正されるであろうということが多分考えられる。更なる仕事は、この使用ケースに特有のガイドラインを開発するのに必要とされる。

G.3.3の一般のCCTS Schemas

このパッケージ ( セクション6.2.2 ) に含まれるCore Component Types、及び、Datatypesのためのschemasは、Open Applications Group社の代表と協力して開発された。しかし、2つの組織によって現在使われるバージョンは、まだ同じではない。UBL 1.0、及び、OAGIS 9.0に使われるCCTS schemasの間の差異は、これらの5つのエリアで確認された:

·         属性としての補足のコンポーネントのネーミング

·         コード、識別子、及び、テキストコンポーネントのためのXSD normalizedStringの使用

·         フォーマットの補足のコンポーネント ( 日付時間、インジケータ、及び、数値 ) を必要とするXSDの組み込み式のdataypesの使用

·         グラフィック、絵、音、及び、ビデオデータタイプのための2元対象に対する制限

·         Indicatorデータタイプのためのパターン

CCTS schemasの一般のセットは、UBL 1.1に利用可能であると予測され、そして、その時含まれるであろう。これは、UBL 1.0場合の妥当性に影響を及ぼすと予測されない。

G.3.4コアコンポーネント調和

インプリメンテーションとして、の[ CCTS ]、UBLは、ビジネスコンポーネントの一般の意味のライブラリの概念をサポートする。これを達成するためにUBLが調和に関するUN/CEFACT国際貿易、及び、ビジネス手続きワーキング・グループによって働いている ( TBG17 ( http://webster.disa.org/cefact-groups/tbg/wg/tbg17_main.cfm ) として知られてい ) このグループは、取引条件、ビジネスデータの意味の定義、及び、データ交換をstructuringすることの簡潔で、明確な用語解説に貢献するビジネス領域、及び、セクタを横断するビジネスプロセスモデル、及び、コアコンポーネントの一貫性、及び、調和に関して責任がある。TBG17との協力は、UBLのための継続的な仕事アイテムである。

G.3.5コンテキスト方法論

自動コンテキスト方法論の供給がUBL 2.0に属する、と同時に、このアイテムに関する仕事は、UBL 1.1タイムフレームに続く。これは、この仕様のB.7において参照を付けられたCustomization Guidelinesの更なる精製を含む。

G.4ローカライズ作業

UBLは、UBL仕様、及び、関連する文書を英語以外の言語に翻訳し、そして、非‐英語を話す地方のコンテキストにおいてUBL努力を表すために、いくらかのローカライズ ( L10N ) 小委員会を形成した。これらの地方のイニシアティブは、UBL 1.1タイムフレームに行われるために、仕事の大部分の原因となるであろう。2004年4月現在で、UBLローカライズ小委員会は、中国語、日本語、韓国語、及び、スペイン語のために設立された。

アペンディクスH :注意

著作権© 20012004年オアシスオープンが版権所有。

全く知的財産、及び、他の権利の妥当性、及び、範囲に関するポジションは、OASISにそれを要しない、である、インプリメンテーションと関係がある、もしくは、使用すると主張した、この文書、または、範囲において示された技術のうちで、に、全くライセンス、下に、そのような権利、及び、利用可能ではないであろう;そしてまた、それは、あらゆるそのような権利を確認することが、あらゆる努力をしたことを示さない。OASISに関する情報は、OASIS仕様において整然と点による手続きである、OASISウェブサイトで発見され得る。発表に利用可能にされた権利のクレーム、及び、利用可能にされるライセンス、または、implementorsによるそのような所有権の使用に一般的ライセンス、または、許可をもたらさせられた試みの結果のあらゆる保証のコピー、または、この仕様のユーザーは、OASIS Executive Directorから獲得され得る。

OASISは、その注意をあらゆる著作権、特許、または、特許出願、または、この仕様を実行するのに必要とされるかもしれない技術をカバーするかもしれない他の所有権に向けるようあらゆる利害関係者に勧める。どうぞ、情報をOASIS Executive Directorに申し立ててください。

それのこの文書、及び、翻訳は、コピーされ、そして、他のもの、及び、論評する派生した仕事に供給されるかもしれない、へ、〜もしくは、他の場合はそれに説明する、〜もしくは、そのインプリメンテーションを援助する、前述の版権情報、及び、このパラグラフが含まれるならば、あらゆる種類の制限なしで準備をされて、写されて、公表されて、分配される ( 全部もしくは一部 ) へ、全て、そのようなコピー、及び、派生した仕事。しかしながら、この文書そのものは、いかなる点でも修正されないかもしれない ( OASIS仕様を開発するために必要とされるように、著作権のための手続きがOASIS Intellectual Property Rightsでどちらのケースを定義したかで文書が進められなければならないということを除けば、もしくは、それを英語以外の言語に翻訳する必要があるように、版権情報、または、参照をOASISに取り除くことのように ) 。

上で与えられた限られた許可は、永続的で、そして、OASIS、及び、その後継者、及び、譲受人によって取り消されないであろう。

This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Title: Universal Business Language 1.0

Universal Business Language 1.0

Publication Date

1 May 2004

Document identifier

cd-UBL-1.0

Editorial Status

This document is an OASIS Committee Draft.

Location

http://docs.oasis-open.org/ubl/cd-UBL-1.0/

Downloadable Package Location

http://docs.oasis-open.org/ubl/cd-UBL-1.0.zip

Editors

Bill Meadows, Sun Microsystems <bill.meadows@sun.com>

Lisa Seaburg, Aeon LLC <lseaburg@aeon-llc.com>

Contributors

Members of the Technical Committee

Abstract

This specification defines the Universal Business Language.

Status

This document is a Committee Draft of the OASIS Universal Business Language (UBL) Technical Committee. The OASIS UBL Technical Committee invites interested parties to comment on this release using the comment link on the UBL TC web page:

http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=ubl

Table of Contents

1 Introduction

2 Normative References

3 Terms and Definitions

4 Symbols and Abbreviations

5 UBL 1.0 Procurement Process

6 UBL 1.0 Schemas

Appendix A (Informative): Release Notes

Appendix B (Informative): UBL Methodology

Appendix C (Informative): Formatting Specifications

Appendix D (Informative): Example Instances

Appendix E (Informative): Code Lists

Appendix F (Informative): ASN.1 Specification

Appendix G (Informative): Ongoing Work Items

Appendix H: Notices

1 Introduction

Since its approval as a W3C recommendation in 1998, XML has been adopted in a number of industries as a framework for the definition of the messages exchanged in electronic commerce. The widespread use of XML has led to the development of multiple industry-specific XML versions of such basic documents as purchase orders, shipping notices, and invoices.

While industry-specific data formats have the advantage of maximal optimization for their business context, the existence of different formats to accomplish the same purpose in different business domains is attended by a number of significant disadvantages as well.

• Developing and maintaining multiple versions of common business documents like purchase orders and invoices is a major duplication of effort.

• Creating and maintaining multiple adapters to enable trading relationships across domain boundaries is an even greater effort.

• The existence of multiple XML formats makes it much harder to integrate XML business messages with back-office systems.

• The need to support an arbitrary number of XML formats makes tools more expensive and trained workers harder to find.

The OASIS Universal Business Language (UBL) is intended to help solve these problems by defining a generic XML interchange format for business documents that can be extended to meet the requirements of particular industries. Specifically, UBL 1.0 provides the following:

• A library of XML schemas for reusable data components such as “Address,” “Item,” and “Payment” — the common data elements of everyday business documents.

• A small set of XML schemas for common business documents such as “Order,” “Despatch Advice,” and “Invoice” that are constructed from the UBL library components and can be used in a generic order-to-invoice trading context.

• Support for the customization of UBL in specific trading relationships.

A standard basis for XML business schemas is expected to have the following advantages:

• Lower cost of integration, both among and within enterprises, through the reuse of common data structures.

• Lower cost of commercial software, because software written to process a given XML tag set is much easier to develop than software that can handle an unlimited number of tag sets.

• An easier learning curve, because users need master just a single library.

• Lower cost of entry and therefore quicker adoption by small and medium-size enterprises (SMEs).

• Standardized training, resulting in many skilled workers.

• A universally available pool of system integrators.

• Standardized, inexpensive data input and output tools.

UBL is designed to provide a universally understood and recognized commercial syntax for legally binding business documents and to operate within a standard business framework such as ISO 15000 (ebXML) to provide a complete, standards-based infrastructure that can extend the benefits of existing EDI systems to businesses of all sizes. UBL is freely available to everyone without legal encumbrance or licensing fees.

UBL schemas are modular, reusable, and extensible in XML-aware ways. Designed as an implementation of ebXML Core Components Technical Specification 2.01, the UBL Library is based on a conceptual model of information components known as Business Information Entities (BIEs). These components are assembled into specific document models such as Order and Invoice. These document assembly models are then transformed in accordance with UBL Naming and Design Rules into W3C XSD schema syntax. This approach facilitates the creation of UBL-based document types beyond those specified in this 1.0 release. This document describes the basic order-to-invoice business process that the UBL document types are designed to support.

To aid in deployment, the standard UBL schemas are accompanied by a multitude of informative supporting materials, some of which are included in this package as informative appendices and some of which are available from referenced sites. These materials include:

• UML class diagrams of the document components on which the schemas are based

• UML class diagrams describing all the document assemblies

• Spreadsheet models defining the document assemblies

• Descriptions of two example implementations

• Sample instances of each of the UBL documents used in those two implementations

• Formatting specifications for rendering all of the documents in the example use cases

• Formatting specifications for the United Nations Layout Keys corresponding to each of the UBL basic business document types

• An ASN.1 specification to enable the transmission of UBL messages in binary form

2 Normative References

[ASN.1] ITU-T X.680-X.683: Abstract Syntax Notation One (ASN.1); ITU-T X.690-X.693: ASN.1 encoding rules

http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-X.693-0207w.zip

http://www.oasis-open.org/committees/download.php/6320/X.680-X.693-0207w.zip

[CCTS] UN/CEFACT ebXML Core Components Technical Specification 2.01

http://www.untmg.org/downloads/General/approved/CEFACT-CCTS-Version-2pt01.zip

http://www.oasis-open.org/committees/download.php/6232/CEFACT-CCTS-Version-2pt01.zip

[ISO11179] ISO/IEC 11179-1:1999 Information technology — Specification and standardization of data elements — Part 1: Framework for the specification and standardization of data elements

http://www.iso.org/iso/en/ittf/PubliclyAvailableStandards/c002349_ISO_IEC_11179-1_1999(E).zip

http://www.oasis-open.org/committees/download.php/6233/c002349_ISO_IEC_11179-1_1999(E).pdf

[RFC2119] Key words for use in RFCs to Indicate Requirement Levels

http://www.faqs.org/rfcs/rfc2119.html

http://www.oasis-open.org/committees/download.php/6244/rfc2119.txt.pdf

[UML] Unified Modeling Language Version 1.5 (formal/03-03-01)

http://www.omg.org/docs/formal/03-03-01.pdf

http://www.oasis-open.org/committees/download.php/6240/03-03-01.zip

[XML] Extensible Markup Language (XML) 1.0 (Second Edition),W3C Recommendation 6 October 2000

http://www.w3.org/TR/2000/REC-xml-20001006

http://www.oasis-open.org/committees/download.php/6241/REC-xml-20001006.pdf

[XSD1] XML Schema Part 1: Structures, W3C Recommendation 2 May 2001

http://www.w3.org/TR/xmlschema-1/

http://www.oasis-open.org/committees/download.php/6248/xsd1.html

[XSD2] XML Schema Part 2: Datatypes, W3C Recommendation 2 May 2001

http://www.w3.org/TR/xmlschema-2/

http://www.oasis-open.org/committees/download.php/6247/xsd2.html

3 Terms and Definitions

Assembly model

A tree-structured model that can be implemented as a document schema.

Class diagram

A graphical notation used by [UML] to describe the static structure of a system, including object classes and their attributes and associations.

Component model

A representation of normalized data components describing a potential network of associations and roles between object classes.

Context

The circumstance or events that form the environment within which something exists or takes place.

Dependency diagram

A refinement of a class diagram that emphasizes the dependent associations between object classes.

Document

A set of information components that are interchanged as part of a business transaction; for example, in placing an order.

Functional dependency

A means of aggregating components based on whether the values of a set of properties change when another set of properties changes, that is, whether the former is dependent on the latter.

Normalization

A formal technique for identifying and defining functional dependencies.

Spreadsheet model

A representation of an assembly model in tabular form.

XSD schema

An XML document definition conforming to the W3C XML Schema language [XSD1][XSD2].

The terms Core Component (CC), Basic Core Component (BCC), Aggregate Core Component (ACC), Association Core Component (ASCC), Business Information Entity (BIE), Basic Business Information Entity (BBIE), and Aggregate Business Information Entity (ABIE) are used in this specification with the meanings given in [CCTS].

The terms Object Class, Property Term, Representation Term, and Qualifier are used in this specification with the meanings given in [ISO11179].

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].

4 Symbols and Abbreviations

ABIE

Aggregate Business Information Entity

ACC

Aggregate Core Component

ASBIE

Association Business Information Entity

ASCC

Association Core Component

BBIE

Basic Business Information Entity

BCC

Basic Core Component

BIE

Business Information Entity

CC

Core Component

EAN

European Article Numbering Association

EDI

Electronic Data Interchange

ISO

International Organization for Standardization

NDR

UBL Naming and Design Rules (see Appendix B.4)

UML

Unified Modeling Language [UML]

UN/CEFACT

United Nations Centre for Trade Facilitation and Electronic Business

XML

Extensible Markup Language [XML]

XSD

W3C XML Schema Language [XSD1] [XSD2]

5 UBL 1.0 Procurement Process

The UBL 1.0 documents and component library are designed to support a typical order-to-invoice procurement cycle. This section describes the business rules and choreography of the generic process and the role played by each of the UBL 1.0 document types in that process.

It is important to note that the UBL library is designed to support the construction of a wide variety of document types beyond those provided in the 1.0 package. It is expected that other document types will be added as UBL evolves.

5.1 The Order-to-Invoice Cycle

This model describes a basic trading cycle from Order to Invoice that involves three parties: a Buyer of goods, a Seller of goods, and a Recipient of goods, who may or may not be the Buyer. The document types provided by UBL to support this process include the following:

Order

Order Response Simple

Order Response (detailed)

Order Change

Order Cancellation

Despatch Advice

Receipt Advice

Invoice

The bold boxes in the diagram below show the role of each document type in the generic process.

Figure 1. Order-to-Invoice Business Process

5.2 Document Business Rules

This section describes the business rules of the generic order-to-invoice process that are assumed as information requirements for the document types in UBL 1.0.

5.2.1 Order

The Order may specify allowance and charge instructions (e.g. freight, documentation, etc.) that identify the type of charge and who pays which charges. The Order can be placed “on account” against a trading credit account held by the Seller, or against a credit/debit card account, or a direct debit agreement. The Order allows for an overall currency defining a default for all pricing and also a specific currency to be used for Invoicing. Within an Order, additional currencies can be specified both for individual item pricing and for any allowances or charges.

Trade discount may be specified at the Order level. The Buyer may not know the trade discount, in which case it is not specified. This makes a detailed response from the Seller necessary; see Order Response (5.2.3).

The Order may specify delivery terms and constraints that apply for the delivery location in relation to the following information that would normally not appear until the Despatch Advice:

• Transport

  • Means

  • Mode

  • One- to many-legged shipment stages

    • Dates

    • Locations

  • Arrival “window”

• Consignment packaging

  • Type, e.g. Container, Pallet

  • Identifier, e.g. SSCC, Shipping label (Despatch Advice)

The Order provides for multiple Order Lines. Each Order Line provides for specification of a single place of delivery, and a schedule of quantities and requested delivery dates.

The Order may specify delivery terms, while the Order Line may provide instructions for delivery.

The Buyer may indicate potential alternatives that are acceptable. For each Order Line, an Alternative Item can be included. The Alternative Item may be specified by any one of the range of Item identifiers. For example, the specified Quantity may change, e.g. 20x6-packs as an alternative to 10x12-packs.

5.2.2 Order Response Simple

The Order Response Simple is the means by which the Seller confirms receipt of the Order from the Buyer, indicating either commitment to fulfill without change or that the Order has been rejected.

5.2.3 Order Response

Proposed changes by the Seller are accomplished through the full Order Response document.

The Order Response proposes to replace the original Order. It reflects the entire new state of an order transaction. It also is the means by which the Seller confirms or supplies Order-related details to the Buyer that were not available to, or specified by, the Buyer at the time of ordering. These may include:

• Delivery date, offered by the Seller if not specifically requested by the Buyer

• Prices

• Trade Discount

• Charges

• Customs Commodity Classification codes

The Seller may advise replacements or substitutes which will be made, or changes necessary, using the Order Response. The Substitute or Replacement Item may be specified by any one of the range of Item identifiers. For example, the specified Quantity may change, e.g. 20x6-packs as a replacement for 10x12-packs.

5.2.4 Order Change

The Buyer can change an established Order in two ways, subject to the legal contract or trading partner agreement: first, by sending an Order Change, or second, by sending an Order Cancellation (see 5.2.5) followed by a new, complete replacement Order.

An Order Change reflects the entire current state of an order transaction.

Buyers can initiate a change to a previously accepted order for various reasons, such as changing ordered items, quantity, delivery date, ship-to address, etc. Suppliers can accept or reject the Order Change using either Order Response or Order Response Simple.

5.2.5 Order Cancellation

At any point of the process, a Buyer can cancel an established order transaction using the Order Cancellation document. Legal contracts, trading partner agreements, and business rules will restrict at what point an Order Cancellation will be ignored (e.g. at the point of manufacture or delivery process initiation). Given the agreements and rules, an Order Cancellation may or may not be an automated business transaction. The terms and conditions of contract formation for business commitments will dictate which, if any, of these restrictions or guidelines will apply.

5.2.6 Despatch Advice

The following information may appear in the Despatch Advice:

• Transport

  • Means

  • Mode

  • One- to many-legged shipment stages

    • Dates

    • Locations

  • Arrival “window”

• Consignment packaging

  • Type, e.g. Container, Pallet

  • Identifier, e.g. SSCC, Shipping label (DespatchAdvice)

The Despatch Advice provides for two situations:

• Organization of the delivery set of items by Transport Handling Unit(s) so that the Receiver can check the Transport Handling Unit and then contained items. Quantities of the same item on the same Order Line may be separated into different Transport Handling Units, and hence appear on separate Despatch Lines within a Transport Handling Unit.

• Organization of the delivery set of items by Despatch Line, annotated by the Transport Handling Unit in which they are placed, to facilitate checking against the Order. For convenience, any Order Line split over multiple Transport Handling Units will result in a Despatch Line for each Transport Handling Unit they are contained in.

Additionally, in either case, the Despatch Advice can advise:

• Full Despatch — advising the Recipient and/or Buyer that all the items on the order will be, or are being, delivered in one complete consignment on a given date.

• Partial Despatch — advising the Recipient and/or Buyer that the items on the order will be, or are being, partially delivered in a consignment on a given date.

Despatch Lines of the Despatch Advice need not correspond one-to-one with Order Lines, and are linked by a reference. The information structure of the Despatch Advice may result in multiple Despatch Lines from one Order Line. Equally, partial despatch may result in some Order Lines not being matched by any Line in a Despatch Advice.

Within a Despatch Advice, an Item may also indicate the Country of Origin and the Hazardous nature of the Item.

5.2.7 Receipt Advice

The Receipt Advice is sent by the Receiver (Buyer) to the Seller to confirm receipt of items and is capable of reporting shortages or damaged items.

The Receipt Advice provides for two situations. For ease of processing claimed receipt against claimed delivery, it must be organised in the same way as the corresponding Despatch Advice:

• Indication of receipt by Transport Handling Unit(s) and contained Receipt Lines one-to-one with the Despatch Advice as detailed by the Seller party.

• Indication of receipt by Receipt Lines annotated by Transport Handling Unit, one-to-one with the Despatch Advice as detailed by the Seller party.

The Receipt Advice allows the Receiver to state any shortages from the claimed despatch quantity and to state any quantities rejected for a given reason.

As presently arranged, the Receipt Line allows for one rejection quantity and reason. However, additional reasons for rejection of quantities of the same item could be achieved by subdividing the Receipt Line so that there are multiple Receipt Lines to one Despatch Line.

5.2.8 Invoice

The Invoice is normally issued on the basis of one despatch event triggering one invoice. An Invoice may also be issued for pre-payment on a whole or partial basis. The possibilities are:

• Prepayment invoice (payment expected)

• Pro-forma invoice (pre advice, payment not expected)

• Normal Invoice, on despatch for despatched items

• Invoice after return of ReceiptAdvice

The Invoice only contains the information that is necessary for invoicing purposes. It does not reiterate any information already established in the Order, Order Change, Order Response, Despatch Advice, or Receipt Advice that is not necessary when invoicing. If necessary, the Invoice refers to the Order, Despatch Advice or Receipt Advice by a Reference for those documents.

Taxation on the Invoice allows for compound taxes, the sequence of calculation being implied by the sequence of information repeated in the data stream (e.g., Energy tax, with VAT — Value Added Tax — superimposed).

Charges can be specified either as a lump sum or by percentage applied to the whole Invoice value prior to calculation of taxes. Such charges cover:

• Packaging

• Delivery/postage

• Freight

• Documentation

Each Invoice Line refers to any related Order Line(s) and may also refer to the Despatch Line and/or Receipt Line.

The Invoice does not cover Debit and Credit Notes, nor does the process include a Customer Account Statement that summarises Invoices, Credit Notes, and Debit Notes to be paid.

5.3 Item Business Rules

Item structures are found throughout the document types in the generic process.

5.3.1 Item Identification

An Identifier identifies each Item (e.g. a product identifier), which shall be one of the following:

• Buyer’s Item Identification, or

• Seller’s Item Identification, or

• Manufacturer’s Item Identification, or

• Catalogue Item Identification, or

• Item Identification according to a system promulgated by a standards body.

The Item Identification assumes that each different packaging of an Item (e.g. a 6-pack and a 12-pack of the same item) has a different Item Identifier.

The Item may be further distinguished by the specification of Measurement(s) or Physical Attribute(s). This enables specification of the following kinds of item:

5.3.1.1 Item Requiring Description

This is an item that is not identified by an unambiguous machine-processable product code and requires additional descriptive information to precisely identify it.

5.3.1.2 Customer Defined Item

This is an item that the customer describes according to his need, and in the specification of which the customer may make some reference to comparable “standard” items.

5.3.1.3 Item Requiring Measurements

This is an item for which it is necessary to specify one or more measurements as part of the descriptive specification of the item.

5.3.2 Item Pricing

For any given Item, price ranges by amount, quantity, etc. are not repeated back to the Seller; only the active price is specified. The Buyer may not know the Item Base Price, in which case it is not specified. This makes a detailed response from the Seller necessary; see OrderResponse.

5.3.3 Other Item Details

Although ordered items may include Hazardous items, as it is not necessary to specify related information at the order stage. The Buyer may not be aware of the nature of the Item. Indication of the Hazardous nature of the Item, and any relevant information, would be indicated in the Despatch Advice.

6 UBL 1.0 Schemas

The UBL XSD schemas are implementations of the document assembly models defined by UBL. They are the only normative representation of the UBL 1.0 document types and library components.

All of the UBL 1.0 XSD schemas are contained in the xsd/ subdirectory of the UBL 1.0 release package (see Appendix A for more information regarding the structure of the 1.0 release package and Section 6.4 for information regarding dependencies among the schema modules). The xsd/ directory is further subdivided into xsd/maindoc/, xsd/common/, and xsd/codelist/ subdirectories.

For convenience in implementing the schemas, a parallel (and technically non-normative) “runtime” set with the annotation elements stripped out is provided in the xsdrt/ directory.

6.1 UBL Document Schemas

The XSD schemas defining the eight basic document types that support the generic UBL 1.0 order-to-invoice process are located in the xsd/maindoc/ directory, as listed below.

Order

xsd/maindoc/UBL-Order-1.0.xsd

Order Response

xsd/maindoc/UBL-OrderResponse-1.0.xsd

Order Response Simple

xsd/maindoc/UBL-OrderResponseSimple-1.0.xsd

Order Change

xsd/maindoc/UBL-OrderChange-1.0.xsd

Order Cancellation

xsd/maindoc/UBL-OrderCancellation-1.0.xsd

Despatch Advice

xsd/maindoc/UBL-DespatchAdvice-1.0.xsd

Receipt Advice

xsd/maindoc/UBL-ReceiptAdvice-1.0.xsd

Invoice

xsd/maindoc/UBL-Invoice-1.0.xsd

6.2 UBL Common Schemas

The xsd/common directory contains six schemas referenced by the eight document schemas in xsd/maindoc. Two of these common schemas contain the UBL library of reusable data components from which the main document schemas are assembled; three contain definitions needed to implement [CCTS] conformance; and one provides a consistent format for schema metadata. The name of each schema file together with a brief description of its contents is given below.

6.2.1 Reusable BIE Schemas

Common Basic Components

xsd/common/UBL-CommonBasicComponents-1.0.xsd

This schema defines the global Basic Business Information Entities (BBIEs) that are used throughout UBL, serving, in effect, as a “global BBIE type database” for constructing documents. As specified by the UBL Naming and Design Rules, this schema does not include BBIEs having Code or Identifier datatypes; these are defined locally wherever they are used.

Common Aggregate Components

xsd/common/UBL-CommonAggregateComponents-1.0.xsd

This schema defines the Aggregate Business Information Entities (ABIEs) that are used throughout UBL, serving, in effect, as an “ABIE type database” for constructing the main documents.

6.2.2 Reusable Datatype Schemas

Core Component Types

xsd/common/UBL-CoreComponentTypes-1.0.xsd

This schema provides Core Component Types as defined by [CCTS]. These types are used to construct higher-level datatypes in a standardized and consistent manner. This schema should not be modified.

Unspecialized Datatypes

xsd/common/UBL-UnspecializedDatatypes-1.0.xsd

This schema defines Unqualified Data Types for primary and secondary representation terms as specified by [CCTS]. Derived from Core Component Types, these XSD complexType structures are the basic data types from which all other data types must derive. This schema should not be modified.

Specialized Datatypes

xsd/common/UBL-SpecializedDatatypes-1.0.xsd

This schema provides Qualified Data Types as defined by [CCTS]. These XSD complexType structures are derived from Unspecialized Datatypes by extension, restriction, and other contextual constraints, such as facets. The Specialized Datatypes have been customized for the UBL 1.0 procurement process and may be further extended to support additional datatypes required for other business contexts.

NOTE: The terms “specialized” and “unspecialized” are used instead of the terms “qualified” and “unqualified” in order to avoid confusion with qualified and unqualified names in [XSD1][XSD2].

6.2.3 Documentation Metadata Schema

Core Component Parameters

xsd/common/UBL-CoreComponentParameters-1.0.xsd

This schema defines the structure of the annotation/documentation sections that appear in all the other schemas, providing a consistent format for metadata such as object class, representation terms, semantic descriptions, and other supplementary information.

6.3 UBL Code List Schemas

The thirteen code list schemas required for UBL 1.0 are included in the xsd/codelist directory. These code list schemas allow component instances conformant to any of the main document schemas to be validated against code list values. See Appendix E for further information about the form of representation used for UBL code lists.

Acknowledgement Response Code

xsd/codelist/UBL-CodeList-AcknowledgementResponseCode-1.0.xsd

Allowance Charge Reason Code

xsd/codelist/UBL-CodeList-AllowanceChargeReasonCode-1.0.xsd

Channel Code

xsd/codelist/UBL-CodeList-ChannelCode-1.0.xsd

Chip Code

xsd/codelist/UBL-CodeList-ChipCode-1.0.xsd

Country Identification Code

xsd/codelist/UBL-CodeList-CountryIdentificationCode-1.0.xsd

Currency Code

xsd/codelist/UBL-CodeList-CurrencyCode-1.0.xsd

Document Status Code

xsd/codelist/UBL-CodeList-DocumentStatusCode-1.0.xsd

Latitude Direction Code

xsd/codelist/UBL-CodeList-LatitudeDirectionCode-1.0.xsd

Line Status Code

xsd/codelist/UBL-CodeList-LineStatusCode-1.0.xsd

Longitude Direction Code

xsd/codelist/UBL-CodeList-LongitudeDirectionCode-1.0.xsd

Operator Code

xsd/codelist/UBL-CodeList-OperatorCode-1.0.xsd

Payment Means Code

xsd/codelist/UBL-CodeList-PaymentMeansCode-1.0.xsd

Substitution Status Code

xsd/codelist/UBL-CodeList-SubstitutionStatusCode-1.0.xsd

6.4 Schema Dependencies

The following diagram shows the dependencies among the schema modules comprising a UBL 1.0 document schema. Note that (as in the other UML diagrams used in this release) dependent components point to the components upon which they depend.

Figure 2. UBL Schema Dependencies

Appendix A (Informative): Release Notes

A.1 Availability

Online and downloadable versions of this release are available from the locations specified at the top of this document.

A.2 Package Structure

The UBL 1.0 specification is published as a zip archive named cd-UBL-1.0.zip. Unzipping this archive creates a directory named cd-UBL-1.0 containing a master hypertext document (this document, index.html) and a number of subdirectories. The files in these subdirectories, linked to from index.html, contain the various normative and informational pieces of the 1.0 release. A description of each subdirectory is given below.

art/

Diagrams and illustrations used in this specification

asn/

ASN.1 specification; see Appendix F

doc/

Supporting documents created by the UBL TC and referenced in this specification

fs/

Formatting specifications; see Appendix C

mod/

UBL spreadsheet models; see Appendix B.3

uml/

UML diagrams; see Appendices B.2, B.3, and B.6

xml/

Example instances; see Appendix D

xsd/

XSD schemas; see Section 6

xsdrt/

“Runtime” XSD schemas; see Section 6

A.3 Tools

UBL has inspired the creation of both free and commercial UBL tools. A list of tools currently available for UBL can be found on the web page of the UBL Tools and Techniques Subcommittee:

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl-ttsc.

A.4 Support

UBL is a volunteer project of the international business community. Inquiries regarding UBL may be posted to the public ubl-dev list, archives for which are located at

http://lists.oasis-open.org/archives/ubl-dev/

Subscriptions to ubl-dev can be made through the OASIS list manager at

http://lists.oasis-open.org/ob/adm.pl

A.5 Recursive Structures

Certain components in the library allow recursive nesting. For example, a Package may contain other Packages, a Delivery may specify another Delivery, etc. These are legitimate business data structures. Most real-world applications will limit the depth of recursion in such structures, but XSD schemas are incapable of expressing this constraint. Implementors should be aware of this and may wish to set limits on the depth of recursive structures in their applications.

Appendix B (Informative): UBL Methodology

B.1 The UBL Development Approach

UBL does not mandate the use of a specific formal development method. The purpose of this section is to describe the process that evolved during the development of UBL so that implementers can understand the role of the various technical artifacts included in this package. They may also choose to adapt this approach to suit their requirements.

The approach used to develop UBL 1.0 is shown in the diagram below.

Figure B-1. The UBL Development Process

The initial UBL library of data components was based upon the xCBL 3.0 schema library, which was itself based on the UN/EDIFACT and ANSI X12 EDI component libraries. Upon review, it was felt necessary to create an abstracted conceptual model of the entities in a form that would better support an iterative development lifecycle.

UBL uses two types of conceptual models, a single model for defining information components and a set of models for describing how these components are assembled into document definitions. The former is referred to as the document component model and is generally presented using UML class diagrams (see B.2 below); the latter are referred to as the document assembly models and are generally presented using spreadsheets.

The identification and assembly of the components required by the UBL 1.0 Procurement Process was carried out manually using business knowledge of the domain, the component model, and the requirements of [CCTS]. Individual spreadsheets were developed for each document type in the UBL 1.0 procurement scenario, and all re-used components were combined into a separate spreadsheet. Additional spreadsheets were used to model the Core Component Types (CCTs), Unspecialized Datatypes (UDTs), and Specialized Datatypes (SDTs) as specified by [CCTS]. The full set of spreadsheet assembly models used by UBL 1.0 is described in Section B.3.

The UBL schemas contained in Section 6 of this specification were then generated automatically from the spreadsheet assembly models following the UBL Naming and Design Rules referenced in Section B.4 according to the process described in Section B.5. Implementation models were then generated from the schemas to serve as an aid in implementing UBL. These UML class diagrams, provided in Section B.6, represent the implementation of the document assembly models described in the spreadsheets.

B.2 Component Model

The UBL document component model describes the information components used in all of the documents defined by UBL 1.0.

The document component model is the result of a detailed analysis of the data requirements to support the UBL 1.0 Procurement Process (see Section 5). During the modeling process, common items of data were identified by a process of normalization to identify aggregates based on functional dependency. Where appropriate, these were generalized so that they could be re-used to support the various business documents.

The document component model is used for the following purposes:

• It facilitates the identification of the reusable components — i.e., the data structures that are common across the UBL 1.0 business documents

• It aids in understanding the information requirements of the total scenario

• It is the source from which the BIEs are derived and documented in the UBL document assembly models

The component model is best viewed as a series of UML Class Diagrams. For legibility, the model does not contain all the metadata required for document assembly.

Figure B-2 shows the overall UBL document component model.

Figure B-2. UBL Document Component Model (click on image to enlarge)

To facilitate comprehension of this diagram, it has been decomposed into several packages. Each package represents a logical grouping of components and is described by its own UML class diagram, which displays both the attributes (Basic BIEs) and object classes (Aggregate BIEs) belonging to the components grouped in the package. The scope of each package is arbitrary and does not hold any significance beyond these diagrams.

For example, the Party reusable component package is shown below.

Figure B-3. Party Component Package

The complete set of packages for all the UBL components is listed below.

Address Package

uml/concept/comp/UBL-1.0-AddressPackage.jpg

Contract Package

uml/concept/comp/UBL-1.0-ContractPackage.jpg

Delivery Package

uml/concept/comp/UBL-1.0-DeliveryPackage.jpg

Document Reference Package

uml/concept/comp/UBL-1.0-DocumentReferencePackage.jpg

Hazardous Item Package

uml/concept/comp/UBL-1.0-HazardousItemPackage.jpg

Item Package

uml/concept/comp/UBL-1.0-ItemPackage.jpg

Party Package

uml/concept/comp/UBL-1.0-PartyPackage.jpg

Payment Package

uml/concept/comp/UBL-1.0-PaymentPackage.jpg

Procurement Package

uml/concept/comp/UBL-1.0-ProcurementPackage.jpg

Tax Package

uml/concept/comp/UBL-1.0-TaxPackage.jpg

No specific directions are defined for the associations in these models; they can be navigated in either direction. The specific navigation path for each association is defined when documents are assembled.

B.3 Document Assembly Models

To define different types of documents, the components described in the previous section are assembled into hierarachical structures based on the requirements of the context — in this case the UBL 1.0 Procurement Process — and the metadata requirements of [CCTS].

Document assembly starts with the definition of each of the business documents comprising UBL 1.0 as an Aggregate BIE (object class) for the document type. All the other Aggregate BIEs (object classes) for the document type are derived by traversing the associations from this Aggregate BIE to form the required hierarchy. The roles chosen for each association between Aggregate BIEs become Association BIEs.

For example, the document assembly model for the top level of the UBL 1.0 Order document is shown below using a UML class diagram.

Figure B-4. Order Document Assembly Model

The top level document assembly models for the eight business documents defined by UBL 1.0 are given below.

Order assembly model

uml/concept/assy/UBL-1.0-OrderDocumentAssembly.jpg

Order Response assembly model

uml/concept/assy/UBL-1.0-OrderResponseDocumentAssembly.jpg

Order Response Simple assembly model

uml/concept/assy/UBL-1.0-OrderResponseSimpleDocumentAssembly.jpg

Order Change assembly model

uml/concept/assy/UBL-1.0-OrderChangeDocumentAssembly.jpg

Order Cancellation assembly model

uml/concept/assy/UBL-1.0-OrderCancellationDocumentAssembly.jpg

Despatch Advice assembly model

uml/concept/assy/UBL-1.0-DespatchAdviceDocumentAssembly.jpg

Receipt Advice assembly model

uml/concept/assy/UBL-1.0-ReceiptAdviceDocumentAssembly.jpg

Invoice assembly model

uml/concept/assy/UBL-1.0-InvoiceDocumentAssembly.jpg

While it is possible to develop document assembly models using UML, it was found easier in practice to use a spreadsheet notation, the key advantages being:

• The additional metadata required by [CCTS] is easily defined

• Formulas can be applied to naming rules

• Spreadsheets can be mapped directly to the submission format for candidate Core Components required byUN/CEFACT TBG17

• Spreadsheets are familiar to the business experts responsible for the data modeling

• The format has proven portable between applications

These advantages were felt to outweigh the main disadvantage of spreadsheet notation, which is the lack of referential integrity controls in the modeling language itself; manual editing is required to control the impact of changes. In this case, fortunately, the commercial tool used to generate the final schemas from the spreadsheets was also capable of verifying model integrity.

B.3.1 Spreadsheet Models

UBL uses spreadsheets to describe the assembly of components into specific types of documents. There is one spreadsheet assembly model for each document type.

Following the terminology of [CCTS], the document assembly models are composed of a combination of Basic Business Information Entities (the attributes of the component model), Aggregate Business Information Entities (the object classes of the component model), and Association Business Information Entities (the roles of associations in the component model). BBIEs can be considered the “leaf nodes” of the data structures, ABIEs as structures that contain BBIEs, and ASBIEs as the containership of one ABIE within another.

The spreadsheet models use rows to define components. Components are either BIEs or Data Types. Columns define the metadata associated with each component type. Many of the spreadsheet columns are determined by [CCTS] requirements.

A spreadsheet assembly model will therefore consist of a “root” ABIE, a set of BBIEs, and a set of ASBIEs. The ABIEs associated with the “root” ABIE are defined in a Reusable BIE spreadsheet model.

The data types for all BBIEs are defined either in the Unspecialized Datatypes spreadsheet model or the Specialized Datatypes spreadsheet model.

The dependencies among these spreadsheet assembly models are shown in the diagram below.

Figure B-5. Spreadsheet Model Dependencies

The spreadsheet files included in this package are provided in both Microsoft Excel format (.xls) and Open Office format (.sxc) as described below.

NOTE: The UBL document schemas are automatically generated from these spreadsheet models. However, the normative forms of the UBL documents are not these spreadsheet models but the XSD schemas themselves, which are provided in Section 6.

B.3.2 Document Spreadsheets

Each business information entity (BIE) is defined in a single row. Row background colour distinguishes between BBIE (white), ABIE (pink), and ASBIE (green).

Order document spreadsheet

mod/maindoc/UBL-Order-1.0.sxc

mod/maindoc/UBL-Order-1.0.xls

Order Response document spreadsheet

mod/maindoc/UBL-OrderResponse-1.0.sxc

mod/maindoc/UBL-OrderResponse-1.0.xls

Order Response Simple document spreadsheet

mod/maindoc/UBL-OrderResponseSimple-1.0.sxc

mod/maindoc/UBL-OrderResponseSimple-1.0.xls

Order Change document spreadsheet

mod/maindoc/UBL-OrderChange-1.0.sxc

mod/maindoc/UBL-OrderChange-1.0.xls

Order Cancellation document spreadsheet

mod/maindoc/UBL-OrderCancellation-1.0.sxc

mod/maindoc/UBL-OrderCancellation-1.0.xls

Despatch Advice document spreadsheet

mod/maindoc/UBL-DespatchAdvice-1.0.sxc

mod/maindoc/UBL-DespatchAdvice-1.0.xls

Receipt Advice document spreadsheet

mod/maindoc/UBL-ReceiptAdvice-1.0.sxc

mod/maindoc/UBL-ReceiptAdvice-1.0.xls

Invoice document spreadsheet

mod/maindoc/UBL-Invoice-1.0.sxc

mod/maindoc/UBL-Invoice-1.0.xls

B.3.3 Common Component Spreadsheets

Reusable BIEs spreadsheet
This model provides the Aggregate Business Information Entities (ABIEs) that are used throughout UBL, serving, in effect, as an “ABIE type database” for constructing the main documents. This model may be modified in customization.
Key: each business information entity (BIE) is defined in a single row. Row background colour distinguishes between BBIE (white), ABIE (pink) and ASBIE (green).

mod/common/UBL-Reusable-1.0.sxc

mod/common/UBL-Reusable-1.0.xls

Core Component Types spreadsheet
This model provides Core Component Types as defined by [CCTS]. These types are used to construct higher-level datatypes in a standardized and consistent manner. This model should not be modified.
Key: each core component type (CCT) is defined in a single row. Row background colour distinguishes between Supplementary Components (white) and core component types (pink).

mod/common/UBL-CoreComponentTypes-1.0.sxc

mod/common/UBL-CoreComponentTypes-1.0.xls

Unspecialized Datatypes spreadsheet
This model specifies Unqualified Data Types as defined by [CCTS]. These types are used to construct higher-level datatypes in a standardized and consistent manner. This model should not be modified.
Key: each data type (DT) is defined in a single row. Row background colour distinguishes between Supplementary Components (white) and data types (pink).

mod/common/UBL-UnspecializedDatatypes-1.0.sxc

mod/common/UBL-UnspecializedDatatypes-1.0.xls

Specialized Datatypes spreadsheet
This model specifies Qualified Data Types as defined by [CCTS]. These types are used to construct higher-level datatypes customized to specific implementations. UBL has chosen to define datatypes for BBIEs that require validation against a code list as Specialized Datatypes. They are specialized forms of the Code datatype with fixed values as given in this model. Note that the implementation of these code lists is realized as individual schemas for each code list. This model may be modified in customization.
Key: each data type (DT) is defined in a single row. Row background colour distinguishes between Supplementary Components (white) and data types (pink).

mod/common/UBL-SpecializedDatatypes-1.0.sxc

mod/common/UBL-SpecializedDatatypes-1.0.xls

B.3.4 Customizing Models

While those wishing to customize UBL should follow the guidelines for the customization of UBL 1.0 schemas referenced from B.7 below, those who choose to modify either the Component or Assembly models directly and use UBL as the basis for a new vocabulary should be aware of the following considerations that may impact compatibility with UBL:

• First, any modification of the spreadsheet models requires an understanding of their structure, the ebXML Core Components Technical Specification [CCTS], and the various UBL library constituents. For example, some columns are updated directly, while others have formulas in their cells which implement [CCTS] and UBL Naming and Design Rules. Awareness of this is necessary when adding or editing the row contents. Care should be taken to avoid updating cells that contain formulas.

• Second, schema generation should be compliant with the UBL Naming and Design Rules (B.4 below) to promote compatibility with other UBL component libraries.

• Third, the data types defined in the Core Component Types and Unspecialized Datatypes models are direct implementations of those defined in [CCTS] and should not be modified without recognition of this fact. The Specialized Data Types model is provided for implementation-specific data types.

The UBL 1.0 document component and document assembly models are the product of the OASIS UBL Library Content Subcommittee. The work of the UBL LCSC can be viewed on the LCSC web page:

http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-lcsc

B.4 UBL Naming and Design Rules

The UBL XML Naming and Design Rules (NDR) checklist included in this package describes the rules used to determine UBL 1.0 XSD schema structures and element/attribute names. The NDR checklist can be found in this package as the following file:

doc/ndr/UBL-NDR-Checklist-1.0.pdf

The UBL Naming and Design Rules are the product of the OASIS UBL NDR Subcommittee. The work of the UBL NDRSC can be viewed on the NDRSC web page:

http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-ndrsc

B.5 Schema Generation

The UBL 1.0 XSD schemas are the output of a transformation that applies schema construction rules to the Data Model represented by the UBL spreadsheets described in B.3 above. The transformation process consisted of the following steps:

1. Reading in the data model spreadsheets
2. Building from each spreadsheet an internal UML-based model
3. Identifying external standards for code lists and including standard code list values as appropriate
4. Applying UBL Naming and Design Rules
5. Outputting conformant XSD schemas

A commercial CC-aware schema generation tool, GEFEG EDIFIX® 5.0, was used to read the spreadsheets as UML data models, perform Q/A with them, and produce a schema representation adhering to the UBL 1.0 Naming and Design Rules, as illustrated below. For information regarding GEFEG EDIFIX®, see http://www.gefeg.com/en/standard/xml/ubl.htm. The GEFEG EDIFIX® 5.0 UBL Reader is free and offers easy viewing of UBL schemas and data models. For information regarding GEFEG EDIFIX® UBL Reader, see http://www.gefeg.com/en/edifix/reader-ubl.html.

Figure B-6. UBL Schema Generation Process

Previous drafts of the UBL specification used different tools for this process. For a description of the process used to produce the UBL 1.0 Beta schemas, see Appendix D of the 1.0 Beta Committee Draft at http://www.oasis-open.org/committees/ubl/lcsc/UBLv1-beta/.

UBL 1.0 schema generation was performed under the direction of the OASIS UBL Tools and Techniques Subcommittee. The work of the UBL TTSC can be viewed on the TTSC web page:

http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-ttsc

B.6 Implementation Model

The implementation model of UBL represents the actual UBL XSD schemas as a UML model. This is produced by automatically transforming the schemas into a model conformant with the Unified Modeling Language [UML]. This model is then used to produce a set of class diagrams that illustrate each of the main documents and several views of the reusable components. The automated transformation and diagram creation was performed using a commercial schema-to-UML transformation tool, Ontogenics hyperModel. For further details regarding this product, see http://www.xmlmodeling.com/.

The UML class diagrams contained in this section are intended to help understand the UBL schemas without requiring an understanding of XSD syntax. In order to do this, the diagrams intentionally suppress some of the detail contained in the schemas. For example, information regarding the order of elements within a complex type definition is not preserved in the diagrams. Other changes were made to make the UML model useful for software engineering; for example, the “Type” suffixes of XSD complexType names are removed when creating the UML class name to yield an object class name independent of XSD syntax, and complex type child elements with simple content values are represented as class attributes, whereas elements with complex content are represented as associations to those type classes.

These diagrams are the UML equivalent of the document assembly spreadsheet models.

B.6.1 Document Implementation Diagrams

An implementation class diagram has been created for each of the eight UBL 1.0 document types. As noted above, the implementation diagrams are simplified views that suppress details of the types contained in these aggregate structures. As an example, the class diagram for the UBL Order document is shown in the figure below.

Figure B-7. Implementation Model for the Order Document

The document implementation class diagrams contained in the UBL 1.0 package are listed below.

Order implementation diagram

uml/implem/doctypes/UBL-OrderImplementationDiagram-1.0.gif

Order Response implementation diagram

uml/implem/doctypes/UBL-OrderResponseImplementationDiagram-1.0.gif

Order Response Simple implementation diagram

uml/implem/doctypes/UBL-OrderResponseSimpleImplementationDiagram-1.0.gif

Order Change implementation diagram

uml/implem/doctypes/UBL-OrderChangeImplementationDiagram-1.0.gif

Order Cancellation implementation diagram

uml/implem/doctypes/UBL-OrderCancellationImplementationDiagram-1.0.gif

Despatch Advice implementation diagram

uml/implem/doctypes/UBL-DespatchAdviceImplementationDiagram-1.0.gif

Receipt Advice implementation diagram

uml/implem/doctypes/UBL-ReceiptAdviceImplementationDiagram-1.0.gif

Invoice implementation diagram

uml/implem/doctypes/UBL-InvoiceImplementationDiagram-1.0.gif

B.6.2 Reusable Component Implementation Diagrams

In addition to the main document diagrams, this release contains ten class diagrams that present views of the packages of reusable components used in the documents. For example, the Order diagram includes associations to Party, SellerParty, and BuyerParty. The following implementation diagram shows these components in detail.

Figure B-8. Implementation Model for Party Components

The component implementation diagrams provided with UBL 1.0 are as follows:

Address implementation diagram

uml/implem/packages/UBL-AddressImplementationDiagram-1.0.gif

Contract implementation diagram

uml/implem/packages/UBL-ContractImplementationDiagram-1.0.gif

Despatch Line implementation diagram

uml/implem/packages/UBL-DespatchLineImplementationDiagram-1.0.gif

Document Reference implementation diagram

uml/implem/packages/UBL-DocumentReferenceImplementationDiagram-1.0.gif

Hazardous Item implementation diagram

uml/implem/packages/UBL-HazardousItemImplementationDiagram-1.0.gif

Item implementation diagram

uml/implem/packages/UBL-ItemImplementationDiagram-1.0.gif

Party implementation diagram

uml/implem/packages/UBL-PartyImplementationDiagram-1.0.gif

Payment implementation diagram

uml/implem/packages/UBL-PaymentImplementationDiagram-1.0.gif

Procurement implementation diagram

uml/implem/packages/UBL-ProcurementImplementationDiagram-1.0.gif

Shipment implementation diagram

uml/implem/packages/UBL-ShipmentImplementationDiagram-1.0.gif

Tax implementation diagram

uml/implem/packages/UBL-TaxImplementationDiagram-1.0.gif

B.7 Customization Guidelines

Guidelines for performing a compatible customization of UBL schemas, together with suggestions for how to proceed when a compatible customization is not possible, can be found in this package at

doc/cm/wd-ubl-cmsc-cmguidelines-1.0.html

The UBL Customization Guidelines are the product of the OASIS UBL Context Methodology Subcommittee. The work of the UBL CMSC can be viewed on the CMSC web page:

http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-cmsc

Appendix C (Informative): Formatting Specifications

The UBL 1.0 package includes an extensive set of formatting specifications in a hyperdocument rooted at

fs/index.html

This part of the package also includes PDF renderings of the example instances provided in Appendix D below.

The UBL Formatting Specifications are the product of the OASIS UBL Forms Presentation Subcommittee. The work of the UBL FPSC can be viewed on the FPSC web page:

http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-fpsc

Appendix D (Informative): Example Instances

This appendix provides example instances of UBL documents being used in two different versions of the order-to-invoice process. The first set of examples illustrates the buying of office supplies, and the second set illustrates the buying of joinery (building supplies). Also included are printed versions of each example document created in accordance with the formatting specifications referenced in Appendix C.

D.1 Example One: Buying Office Supplies

The buyer, Bill’s Microdevices, orders several different items from an office supply store. The buyer knows the supplier’s codes for the items and the price for each.

Office supplies Order example instance

xml/office/UBL-Order-1.0-Office-Example.xml

Printouts

fs/Order/pdf/OfficeOrder.Example-a4.pdf

fs/Order/pdf/OfficeOrder.Example-us.pdf

The buyer decides to change the original order.

Office supplies Order Change example instance

xml/office/UBL-OrderChange-1.0-Office-Example.xml

Printouts

fs/OrderChange/pdf/OfficeOrderChange.Example-a4.pdf

fs/OrderChange/pdf/OfficeOrderChange.Example-us.pdf

The seller, Joe’s Office Supply, replies with an Order Response Simple to indicate the acceptance of the order. The seller also gives his reference number for the order, i.e., the sales order in his system, and tells the buyer whom to contact if he has any queries.

Office supplies Order Response Simple example instance

xml/office/UBL-OrderResponseSimple-1.0-Office-Example.xml

Printouts

fs/OrderResponseSimple/pdf/OfficeOrderResponseSimple.Example-a4.pdf

fs/OrderResponseSimple/pdf/OfficeOrderResponseSimple.Example-us.pdf

The buyer cancels an Order (for purposes of illustration, not the same one).

Office supplies Order Cancellation example instance

xml/office/UBL-OrderCancellation-1.0-Office-Example.xml

Printouts

fs/OrderCancellation/pdf/OfficeOrderCancellation.Example-a4.pdf

fs/OrderCancellation/pdf/OfficeOrderCancellation.Example-us.pdf

The seller advises the buyer of the despatch of the items ordered.

Office supplies Despatch Advice example instance

xml/office/UBL-DespatchAdvice-1.0-Office-Example.xml

Printouts

fs/DespatchAdvice/pdf/OfficeDespatchAdvice.Example-a4.pdf

fs/DespatchAdvice/pdf/OfficeDespatchAdvice.Example-us.pdf

The buyer notifies the seller of missing items.

Office supplies Receipt Advice example instance

xml/office/UBL-ReceiptAdvice-1.0-Office-Example.xml

Printouts

fs/ReceiptAdvice/pdf/OfficeReceiptAdvice.Example-a4.pdf

fs/ReceiptAdvice/pdf/OfficeReceiptAdvice.Example-us.pdf

The seller raises the Invoice automatically when the despatch occurs, and the resolution of shortages etc. is handled post-invoicing. The Invoice shows the tax amount. The seller notes that payment is due within 30 days of Invoice.

Office supplies Invoice example instance

xml/office/UBL-Invoice-1.0-Office-Example.xml

Printouts

fs/Invoice/pdf/OfficeInvoice.Example-a4.pdf

fs/Invoice/pdf/OfficeInvoice.Example-us.pdf

D.2 Example Two: Buying Joinery (Building Supplies)

The buyer, Jerry Builders, PLC. in the UK, orders a number of windows, a door set, and some lengths of timber for delivery to a building site. Jerry knows the supplier’s codes for the items, and that he must also specify a number of physical attributes to get the precise item that he wants: some windows are asymmetric and are “handed” left or right; most door sets are handed, as they are hinged on one side; the wood and its finish must be specified, as must the “fittings” (handles, stays etc.). Items can be glazed in different ways. Loose timber is coded according to its cross section, and the length must be specified. While the buyer knows these things from the catalogue, he does not know the current prices or any discount rate he may get.

Joinery Order example instance

xml/joinery/UBL-Order-1.0-Joinery-Example.xml

Printouts

fs/Order/pdf/JoineryOrder.Example-a4.pdf

fs/Order/pdf/JoineryOrder.Example-us.pdf

The seller, Specialist Windows PLC, replies with a detailed Order Response to indicate the unit price of each item and to inform the buyer of the trade discount that he will be given. At the same time, the seller gives his reference number for the order, i.e. the identity of the order in his system, and also tells the buyer whom to contact if he has any queries.

Joinery Order Response example instance

xml/joinery/UBL-OrderResponse-1.0-Joinery-Example.xml

Printouts

fs/OrderResponse/pdf/JoineryOrderResponse.Example-a4.pdf

fs/OrderResponse/pdf/JoineryOrderResponse.Example-us.pdf

The seller advises the buyer of the despatch of the items ordered, which will in fact be delivered on two pallets (i.e., transportation units) identified as “A” and “B”. The Despatch Advice lists the items in order line sequence and refers to the pallet on which the item is delivered.

Joinery Despatch Advice example instance

xml/joinery/UBL-DespatchAdvice-1.0-Joinery-Example.xml

Printouts

fs/DespatchAdvice/pdf/JoineryDespatchAdvice.Example-a4.pdf

fs/DespatchAdvice/pdf/JoineryDespatchAdvice.Example-us.pdf

The Despatch Advice travels with the delivery; a paper copy is signed and returned as proof of receipt. Hence the UBL Receipt Advice is not used.

The Seller raises the Invoice automatically when the despatch occurs, and the resolution of any shortages is handled post-invoicing. The Invoice has to show the tax point date, the VAT (Value Added Tax) category to which the item belongs, and also the VAT rate and total for each tax category on the invoice. VAT is also applied to charges such as the delivery surcharge. In order to encourage speedy payment of the amount due, the Seller offers a discount for prompt settlement, which the buyer can deduct if paying within 30 days. (This example was written for a context in which regulations assume the VAT will be taken, so the tax here is calculated on the trade discounted total of line items plus any charges and less the settlement discount amount.)

Joinery Invoice example instance

xml/joinery/UBL-Invoice-1.0-Joinery-Example.xml

Printouts

fs/Invoice/pdf/JoineryInvoice.Example-a4.pdf

fs/Invoice/pdf/JoineryInvoice.Example-us.pdf

This example is based on the products, product identification, business requirements, and practices of a real UK joinery manufacturer and sales company. It operates its own specialized transport fleet, delivering all over the United Kingdom and to offshore islands.

Appendix E (Informative): Code Lists

The code list schemas included in UBL 1.0 conform to the UBL specification for Code List Representation, which can be found in this package at

doc/cl/wd-ublclsc-codelist-20040420.pdf

The UBL Code List Representation specification is the product of the OASIS UBL Code List Subcommittee. The work of the UBL CLSC can be viewed on the CLSC web page:

http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-clsc

Appendix F (Informative): ASN.1 Specification

The UBL ASN.1 specification referenced below provides an alternative schema definition for UBL documents in accordance with ITU-T X.680-X.693 [ASN.1]. The UBL ASN.1 specification defines the same UBL documents as the UBL XSD schemas in Section 6 that constitute the normative definitions of valid UBL documents. The UBL ASN.1 XML schema enables ASN.1 tools to be used for UBL transfers, and in conjunction with the ASN.1 Packed Encoding Rules, it provides a specification for an efficient binary encoding of UBL messages.

UBL ASN.1 Specification

asn/ASN.1-UBL-1.0.html

The ASN.1 UBL specification was created using a tool from OSS Nokalva (http://www.oss.com/) that conforms to ITU-T Recommendation X.694 | ISO/IEC 8825-5 for converting XSD Schema to ASN.1. After conversion, the generated ASN.1 was formatted by the PrettyPrint tool at the ASN.1 Information Site (http://asn1.elibel.tm.fr) to produce the HTML file included in this package.

Appendix G (Informative): Ongoing Work Items

UBL 1.0 achieves the basic objective of the first phase of the UBL charter — to develop a workable standard library of XML business documents. The second phase (UBL 2.0) is intended to produce additions to the UBL library and schema set and a mechanism for the automatic generation of context-specific business schemas.

Between these milestones lie a number of work items that for one reason or another could not be completed in time for delivery of UBL 1.0. Some of these items represent work of continuing interest; others represent cases where an issue could not achieve a consensus solution within the time set for UBL 1.0 delivery but for which an acceptable short-term strategy could be adopted with little or no impact on the long-term validity of UBL 1.0 document instances. The UBL TC intends to resolve these issues and release an updated version called UBL 1.1 that will be backward-compatible with UBL 1.0 instances.

In the following, these work items have been loosely grouped under four headings: NDR Work Items, Interoperability Work Items, Registry Work Items, and Localization Work Items. Persons interested in participating in this program of work are invited to join the OASIS UBL TC.

G.1 NDR Work Items

The following items are related to UBL Naming and Design Rules (NDR).

G.1.1 Publication of UBL NDR as a Separate Specification

Time constraints prevented completion of the UBL Naming and Design Rules (NDR) document as a separate specification for delivery with UBL 1.0; the document included in this package and referenced as [NDR] contains only the rules checklist for 1.0. Work continues to prepare the NDR document for submission as a separate OASIS technical specification.

G.1.2 Substitution Groups for Code List Customization

The UBL Code List Subcommittee has produced a comprehensive solution for code lists (see Appendix E) that relies upon XSD substitution groups for code list customization. Lacking a clear industry consensus on the use of XSD substitution groups in business document schemas, the UBL TC has deferred the adoption of this extension mechanism for code lists pending further discussion. Care has been taken to construct UBL 1.0 in a way that will allow the adoption of substitution groups (if deemed appropriate) in later releases without invalidating UBL 1.0 instances.

G.1.3 Importation of Codelist Schema Modules

It is an open question whether it is better to import the codelist schema modules (Section 6.3) indirectly via the Specialized Datatype schema (Section 6.2.2) or directly into the Common Aggregate Component schema (Section 6.2.1) and any individual document schemas where they are used. In UBL 1.0, codelist schema modules are imported directly, but concerns have been raised regarding a possible impact on performance. Feedback from UBL 1.0 implementation will be relied upon in resolving this issue. A change to the alternative is not expected to affect UBL 1.0 instances.

G.1.4 Location of Qualified BBIE Property Element Definitions

In UBL 1.0, all BBIE properties are declared as elements and defined as complex types in the Common Basic Components schema (Section 6.2.1). Alternatively, the qualified BBIE property elements could be declared in either the Common Aggregate Components schema or in the individual document schemas where they are used. This issue remains open, but any change in future releases will not affect UBL 1.0 instances.

G.2 Registry Work Items

The following issues relate to the storage and registration of UBL schemas.

G.2.1 Relative Paths in Schema Modules

UBL NDR identified a requirement for absolute path names for schema locations as a necessary requirement for standards based schemas to ensure consistency, clarity, and absolute assurances that the UBL normative schemas are in fact being used. However, current OASIS architecture limitations preclude the availability of a suitable registry/repository to support this requirement. As a result, UBL 1.0 has been released using relative path names for the location of schemas in order to facilitate offline validation and to work around those limitations. Use of absolute paths and a registry for the component library will be implemented in a future version as the supporting infrastructure becomes available.

G.2.2 Version Element in the Documentation of Every BIE

UBL 1.0 assumes that the version number of each UBL datatype and BIE is also 1.0. However, there is some debate as to whether this is a schema construct artifact or a storage artifact. The outcome of this decision may result in a requirement to assign a version number in the annotation documentation for each datatype and BIE schema construct.

G.3 Interoperability Work Items

The following work items relate to the interoperability of UBL documents across industries and in relation to other business document standards.

G.3.1 UBL Conformance

While much initial work has been done toward defining the concept of UBL conformance in the UBL 1.0 Customization Guidelines (see Appendix B.7), further work is necessary to create a definition of UBL conformance that is usable in legal and regulatory contexts.

G.3.2 Industry Profiles

It is considered likely that UBL 1.0 will be modified according to the UBL Customization Guidelines to create versions that are standard within particular industries and geographical regions. Further work is needed to develop guidelines specific to this use case.

G.3.3 Common CCTS Schemas

The schemas for Core Component Types and Datatypes included in this package (Section 6.2.2) were developed in cooperation with representatives of the Open Applications Group, Inc., but the versions currently used by the two organizations are not yet identical. Differences between the CCTS schemas used in UBL 1.0 and OAGIS 9.0 have been identified in these five areas:

• Naming of Supplementary Components as attributes

• Use of XSD normalizedString for code, identifier, and text components

• Use of XSD built-in dataypes requiring format Supplementary Components (Date Time, Indicator and Numeric)

• Restrictions on Binary Object for Graphic, Picture, Sound and Video data type

• Patterns for Indicator data type

A common set of CCTS schemas are expected to be available for UBL 1.1 and will be included at that time. This is not expected to affect the validity of UBL 1.0 instances.

G.3.4 Core Component Harmonization

As an implementation of [CCTS], UBL supports the concept of a common semantic library of business components. To achieve this, UBL is working with the UN/CEFACT International Trade and Business Procedures Working Group on Harmonization, known as TBG17 (http://webster.disa.org/cefact-groups/tbg/wg/tbg17_main.cfm). This group is responsible for consistency and harmonization of business process models and core components across business domains and sectors, contributing to a concise and well-defined glossary of business terms, business data semantic definitions, and structuring of data exchanges. Cooperation with TBG17 is a continuing work item for UBL.

G.3.5 Context Methodology

While the delivery of an automatic context methodology belongs to UBL 2.0, work on this item continues in the UBL 1.1 time frame. This includes further refinement of the Customization Guidelines referenced in B.7 of this specification.

G.4 Localization Work Items

UBL has formed several localization (L10N) subcommittees to translate the UBL specification and associated documentation into languages other than English and to represent the UBL effort in non-English-speaking regional contexts. These regional initiatives will account for much of the work to be performed in the UBL 1.1 time frame. As of April 2004, UBL localization subcommittees had been established for Chinese, Japanese, Korean, and Spanish.

Appendix H: Notices

Copyright © 2001-2004 OASIS Open, Inc. All Rights Reserved.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.