![[oasis logo]](art/oasis-logo.jpg){kind=logo}
2004年8月1日
cd-UBL-1.0-cnlsc
本文件是对OASIS的委员会草案的中文版
暂无http://docs.oasis-open.org/ubl/cd-UBL-1.0/
http://docs.oasis-open.org/ubl/cd-UBL-1.0.zip
Bill Meadows, Sun Microsystems <bill.meadows@sun.com>
Lisa Seaburg, Aeon LLC <lseaburg@aeon-llc.com>
Members of the Technical Committee
中国标准化研究院<http://www.cnis.gov.cn>
孙文峰<sunwf@cnis.gov.cn>
魏宏<weih@cnis.gov.cn>
程煌<>
等等
本规范定义了统一业务语言
本文档是OASIS 统一业务语言技术委员会的委员会草案，由中文本地化分委员会翻译。有何意见请反映至UBL技术委员会的网址：
自从1998年W3C将XML批准为推荐性标准以来，XML已被一些行业采纳为定义其电子商务中报文交换的框架。XML的广泛使用导致了多种面向行业的业务单证的XML版本的发展，如订购单、发货通知和发票等。
面向行业的数据格式的优点是实现在其业务环境下的最优化，然而，在不同业务领域内为实现同一目的而存在不同的格式也具有一些严重的缺点。
开发并维护诸如定购单和发票之类的公共业务单证的多个版本造成了大量的重复劳动。
创建并维护多种转化工具来实现跨领域界限的贸易关系需要更大的投入。
多种XML格式的存在使得XML业务报文与办公系统之间的集成更为困难。
为了支持任意数量的XML格式使得相关的工具非常昂贵，并且很难为接受过培训的人员找到。
OASIS的统一业务语言(UBL)的目的是通过为业务单证定义一个通用的XML交换格式来解决这些问题，这个通用的交换格式可以通过进行扩展来满足特定行业的需要。具体来说，UBL1.0给出了如下内容：
诸如“地址”、“项目”和“付款”之类的可重用数据成分的XML schema库。
诸如“订单”、“发货通知”和“发票”之类的公共业务单证的XML Schema集合。
支持UBL在特定贸易关系中的具体化应用。
XML业务schema的标准基础可具有如下优点：
在企业之间和企业内部的集成通过重复使用公共的数据结构具有成本低的优点。
由于处理给定XML标记集的软件较处理无限数量的标记集的软件更为容易开发，商业软件的成本被大大降低。
由于用户仅需掌握单一的库，因而也更容易学习。
由于进入的成本较低，因此中小企业可以更快地采纳。
标准化的培训可以造就大量熟练的技术人员。
可以形成一批的统一的系统集成商。
标准化的成本低廉的数据导入导出工具。
UBL的目的是提供一套统一理解并确认的商业语法，用于合法地绑定业务单证并在标准化的业务框架（如ISO 15000, ebXML）内操作，以提供一套基于标准的将现有EDI系统带来的效益扩展到所有规模企业的基础设施。UBL可以为所有人免费提供，没有法律上的限制也不需要缴纳许可费。
UBL schema是模型化的、可重复使用的，且可用XML的相关方式进行扩展。作为ebXML核心构件技术规范2.01的应用，UBL库基于信息构件的概念模型，即业务信息实体（BIEs）。这些构件组合成特定的单证模型，例如订单和发票。这些单证组合模型按照UBL命名和设计规则被转换成W3C XSD schema语法。这一方法促进了1.0版本规定的之外的基于UBL的单证类型的生成。本标准描述了基本的UBL文档类型支持的“订单——发票”的业务过程。
为了便于实施，规范的UBL schema还带有一些资料性的辅助材料，其中一些包括在本标准内作为资料性附录；还有一些可以从参考的网址获得。这些材料包括：
Schema所基于的单证构件的UML类图表
描述单证组合的UML类的图表
定义单证组合的Spreadsheet（excel 文件）表单模型
两个应用实例的描述
每个UBL单证在上述两个应用实例中的使用范例
应用实例中所有文档的格式规范
对应每个UBL基本业务单证类型的联合国文件格式要求的格式规范
将UBL报文转化成二进制形式的ASN1.0规范
用表格表示的组合模型的表示。
本标准中也使用了一些核心构件、基本核心构件、聚合类核心构件、关联类核心构件、业务信息实体、基本业务信息实体、聚合类业务信息实体的术语，其定义见[CCTS]。
本标准中也使用了一些对象类、属性词、表示词以及限定符，其定义见 [ISO11179]。
本标准中出现的“必须”、“必须不”、“所需的”、“应该”、“不应该”、“推荐”、“可能”、“可选的”关键词见 [RFC2119]。
UBL1.0文档合构件库的设计支持典型的“发票——订单”的采购循环。本部分描述了基本流程以及UBL1.0中该流程的单证类型角色的业务规则和编排关系。
非常需要注意的是UBL库的设计支持了UBL1.0文件包之外的很多种单证类型。希望当UBL发展时，再增加其他单证类型。
这一模型描述了一个从发票到订单的基本的贸易循环，包括三个参与方：货物的购买方、货物的销售方、以及货物的接收方，接收方可能与购买方不同。支持这一流程的UBL提供的单证类型包括：
订单
简单订单应答
详细订单应答
订单更改
订单撤销
发货通知
收货通知
发票
下边图标中的黑框中显示了基本流程中的每种文档类型。
![[order-to-invoice diagram]](art/UBL-1.0-ProcurementActivity-096dpi.jpg)
Figure 1. Order-to-Invoice Business Process
本部分描述了基本“订单——发票”流程的业务规则，该规则在UBL1.0被看作单证类型的需求。
订单可以规定折扣和费用方面的说明（如，运费，文档等。）来标识费用的类型以及由谁支付。订单付款方式可以依据给定的卖方的贸易信息帐户，或一个信用卡/借记卡帐户，或者签订一个直接借款协议。订单中可以规定一种缺省用于所有定价的和专门用于发票出票的全能货币。在一个订单中，可以再为其他单个的货项规定用于定价、折扣或费用的货币。
贸易折扣可以在订单这一级规定。在未规定的情况下，买方可能不知道贸易折扣。卖方有必要给出详细的应答；见订单应答（5.2.3）
订单可以规定一些交货条款和条件，用于和交货地点有关的下列信息，这些信息通常在发货通知之后出现。
运输
工具
模式
一对多脚的运输阶段
日期
地点
到达“窗口”
托运包装
类型，例如集装箱，托盘
标识符，例如SSCC，运货标记（发货通知）
订单提供了多个订单行项，每个订单行项给出单个发货地点的规定以及交货数量计划和所要求的交货日期。
订单行项可以给出交货的说明，而订单可以规定交货条款。
购买方可以给出其他可能被接受的备选方案。可为每个订单行项包括一个备选的货项。备选货项可以在货项限定符的范围内规定。例如，规定的数量可能会改变，如，20X6的包可有10X12作为备选方案。
简单订单应答是卖方收到买方的订单的确认方式，表明该订单或者被承诺无修改地执行，或者被拒绝。
卖方建议的修改通过全面的订单应答单证完成。
订单应答建议替换原订单。它反映了订单交易的一个全新的阶段。它也提供了一种方法使得卖方向买方确认或提供买方在发出订单时并未获知或并未规定的一些关于订单的细目。包括：
交货日期，在买方没有特别要求的情况下由卖方给出。
价格
贸易折扣
费用
海关物品分类编码
卖方可以使用订单应答给出更改或替换，或者必要的更改的建议。更改或替换的货项可在货项标识符的范围内规定。例如，规定的数量可能会改变，如20X6的包装可替换10X12的包装。
依据法定合同和贸易伙伴协议，购买方可以用两种方法更改一个已创建的订单：发送一个订单更改，或者先发送一个订单撤销（见5.2.5），再发送一个新的完整的代替的订单。
一个订单更改反映了一个订单交易的全部当前的状态。
出于多种原因，购买方可以对一个先前已接受的订单进行修改，如：更改订单项、数量、交货日期、货物运到地点等。供应商可以使用订单应答或者简单订单应答接受或者拒绝一个订单更改。
在流程中的任意一点，一个购买方可以使用订单撤销单证取消一个已创建的订单交易。订单撤销可以被忽略的情况（例如，在制造过程中或发货手续已开始），是由法定合同、贸易伙伴协议和业务规则限定的。在协议和规则的限定下，订单撤销可以是，也可以不是一个自动的业务交易。作为业务承诺的合同信息的条款和条件将决定哪些这样的限制或规则适用。
下列信息可能出现在发货通知中：
运输
工具
方式
一对多脚的运输阶段
日期
地点
到达窗口
托运包装
类型，如集装箱、托盘
标识符，如SSCC货运标签
发货通知解决下面两种情况：
发货机构使用运输处理单元安排货项，以便接收方可以检验运输处理单元以及装纳的货项。同一订单行项里的同一货项数量可以被分配到不同的运输处理单元，从而也出现在一个运输处理单元的不同的发货行项中。
发货机构使用发货行项安排货项，并标注货项所在的运输处理单元，来促进对订单的核对。为了方便，任何一个订单行项分散到多个运输处理单元的情况将导致货项所在的每个运输处理单元都有一个发货行项。
另外，以上任一情况下，发货通知应给出：
全部发货——告知接收方或购买方将要或正在将订单中所有的行项在一个给定的日期用一个完整的发货发出。
部分发货——告知接收方或购买方将要或正在将订单中的货项在一个给定的日期部分地发出。
发货通知中的发货行项不需要与订单行项一一对应，应通过引用相关联。订单通知的信息结构可能导致一个订单行项对应多个发货行项的结果。同样，部分发货可能导致某些订单行项与一个订单通知中的行项不匹配。
在一个发货通知中，一个货项可能会给出货物的原在国以及货物的危险程度。
收货通知是由接收方（购买方）向销售方发出的，来确认货项的接收，而且能够说明货物的损失和损伤。
收货通知解决了两种情况。每次已声明的发货对应的声明已处理的收货，必须与对应的发货通知结构相同。
通过运输处理单元以及其中包括的收货行项来声明货物接收，该收货行项与销售方详细给出的发货通知一一对应。
通过运输处理单元注明的收货行项声明货物接收，与销售方详细给出的发货通知一一对应。
收货通知应允许接收方能够从声明的发货数量中报告货物的缺失，并报告由于给定的原因被拒绝的货物数量。
就目前而言，收货行项中可以有一个拒绝数量和原因。然而，如果需要为同一个货项说明其他拒绝的原因，可以将收货行项分成多个收货行项，因此一个发货行项对应多个收货行项。
一般来说，发票的发出基于一个发货事件激发一个发票的情况。一个发票单证也可以在全部或部分预付款的基础上发出。这些情况是：
预付款发票（预期将收到付款）
估价发票（前期建议，未预期收到付款）
普通发票，在已发货项发货时给出
收货通知返回后给出的发票
发票单证中仅包括出于发票目的的信息。并不重复订单、订单更改、订单应答、发货通知以及收货通知中开发票是并不需要的已有信息。如果需要，发票单证可以引用订单、发货通知或者收货通知。
发票单证中的缴税项允许组合税项，其计算顺序参照在数据流中重复的信息的顺序（例如，能源税，带有VAT增值税，并重复征收）。
费用可在计算税务之前规定，可按照一次付清额规定，也可按照适用于发票单证总额的百分比数规定。这些费用包括：
包装
送递/邮寄
运费
文本起草费用
每个发票行项可以引用任何相关的订单行项也可以引用发货行项和/或收货行项。
发票单证并未包括借和贷附注，这个过程也不包括客户帐户声明，该声明中包括了需要付款的发票、借方附注和贷方附注。
货项结构从所有基本过程中的单证类型中获得。
每个货项用一个标识符进行标识（如，一个产品标识符），应为以下中之一种：
买方货项标识
卖方货项标识
制造商货项标识
目录货项标识
参照一个标准化组织发布的标识系统的货项标识
货项标识假定一个货项的每个不同的包装有一个不同的货项标识符。（如同一货项的6包和12包的包装）。
货项可以通过计量单位和物理属性进一步进行区分。这使得以下各种货项规定成为可能。
该货项的产品代码标识不能被机器无歧异地处理，需要另外的描述性信息，来对其进行准确标识。
该货项由客户按照其需要在规定中对其进行描述，在规定中，客户可以引用可比较的“标准的”货项。
该货项需要规定一个或多个计量，作为货项的描述性规定的一部分。
对于任何给定的货项，价格内容包括金额、数量等，并未回复给销售方；只规定动态价格。购买方可能并不知道货项的基准价格，在这种情况下不规定。因此，销售方有必要给出详细的应答信息，见订单应答。
虽然已订货项可能包括危险货项，在订单阶段没有必要规定相关的信息。购买方可能不知道货项的性质。货项的危险性的说明以及其他相关的信息，将在发货通知中给出。
UBL XSD schema是UBL定义的文档组合模型的应用。他们是UBL1.0文档类型和库构件的唯一规范性表示。
所有UBL1.0 XSD schema包括在UBL1.0 发布的文件包(关于1.0版本文件包的结构见附录A，不同的schema模型的依赖关系见第6.4节)的xsd子目录下。xsd子目录又进一步分为xsd/maindoc/，xsd/common/，以及xsd/codelist/子目录。
为了便于实施schema，在xsdrt子目录有一个平行的（技术上是非规范性的）“运行时间”集，它带有节选出来的的标注元素。
定义8个支持基本的UBL1.0“订单——发票”流程的基本的单证类型的xsd schema 位于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
Xsd/common目录包括被8个xsd/maindoc下单证schema引用的6个schema。 这些公共schema中的的两个包括可重复使用的数据构件的UBL库，这些数据构件组合成了主要单证schema；其中的三个包括了需要实施 [CCTS] 一致性的定义；其中一个提供了schema元数据的一致性格式。下面给出了每个schema文件的名称，以及其名称的简要描述。
- 公共的基本构件
- xsd/common/UBL-CommonBasicComponents-1.0.xsd
- 这一schema定义了UBL中广泛使用的全球基本业务信息实体（BBIE），其作用是用于创建文档的“全球基本业务信息实体类型数据库”。根据UBL命名和设计规则的规定，这一schema不包括带有代码或标识符数据类型的BBIE；这些BBIE在使用时由本地定义。
- 公共的聚合构件
- xsd/common/UBL-CommonAggregateComponents-1.0.xsd
- 这一shema定义了UBL中广泛使用的聚合类业务信息实体（ABIE），其作用是用于创建主要单证的“全球基本业务信息实体类型数据库”。
- 核心构件类型
- xsd/common/UBL-CoreComponentTypes-1.0.xsd
- 这一shema提供了[CCTS]定义的核心构件类型。这些类型用来以标准化和一致的方式构建更高层的数据类型。这一schema不能被修改。
- 未限定的数据类型
- xsd/common/UBL-UnspecializedDatatypes-1.0.xsd
- 这一schema定义了 [CCTS]规定的主要和二级表示术语的未限定的数据类型。这些XSD复合类型机构来自于核心构件类型，是生成其他数据类型的基本数据类型。这一schema不能被修改。
- 限定的数据类型
- xsd/common/UBL-SpecializedDatatypes-1.0.xsd
- 这一schema给出了[CCTS]定义的限定的数据类型。这些XSD复合类型结构通过扩展、限定、以及其他语境限制由未限定的数据类型生成。如facets.规定的数据类型已在UBL1.0采购流程中被客户化，可能会被进一步扩展来支持业务语境所需的其它数据类型。
- 核心构件参数
- xsd/common/UBL-CoreComponentParameters-1.0.xsd
- 这一schema定义了出现在所有其他schema中的标注和单证部分的结构，为诸如对象类、表示术语、语义描述和其他补充信息等元数据提供了一致格式。
- 确认应答代码
- 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
![[schema dependency diagram]](art/UBL-1.0-SchemaDependency.jpg)
Figure 2. UBL Schema Dependencies
art/- 本标准中使用的图表。
asn/- ASN.1规范，见附录F
doc/- UBL 技术委员会创建的支持文档，也被本标准引用。
fs/- 格式规范见附录C
mod/- UBL表单模型，见附录B.3
uml/- UML图表，见附录B.2，B.3，和B.6
xml/- 实用范例，见附录D
xsd/- XSD schema见第6部分。
xsdrt/- “运行时间”XSD schema，见第6部分。
库中某些构件允许递归结构。例如，一个包装可能包括其他包装，一个发货可以规定另一个发货。这些都是合乎规定的业务数据结构。多数实际的应用系统将限制这些结构中递归的次数，但是XSD schema 无法表示这个限制。实施人员应明白这一点并在其应用系统中加以限制。
UBL没有强制使用一种规定的研制方法。本部分的目的是描述UBL研制过程中不断发展的流程，以使标准的实施人员能够理解本文件包里的各种技术工具的作用。他们也可以选择适应这种方法，使其符合其自身的需要。
研制UBL1.0的方法如下所示：
![[development process diagram]](art/UBL-1.0-DevProcess.jpg)
Figure B-1. The UBL Development Process
最初的UBL数据构件库是基于xCBL3.0schema库的，该库又基于UN/EDIFACT 以及ANSI X12 EDI构件库。在检查这一构件库时，感觉到有必要创建一套抽象的实体的概念模型，并采用一种能更好地支持循环的研制周期的形式。
UBL使用两种概念模型，一种单个的定义信息构件的模型和一套描述如何将这些构件组成单证定义的模型。前者作为单证构件模型引用，并通常使用UML类图表（见下边的B.2）表示后者作为单证组合模型引用，并通常使用表单表示。
UBL1.0采购流程所需的构件的标识和组合是使用[CCTS]的域、构件模型和需求方面的业务知识手工生成的。在UBL1.0采购剧本中，每个单证类型都开发一套独立的表单；而可重复使用的构件组成了另一个独立的表单。其他的表单是用来对[CCTS]规定的核心构件类型、未限定数据类型、以及限定的数据类型建模的。UBL1.0使用的表单组合模型的全集在B.3中有叙述。
本标准的第6部分中规定的UBL schema是由表单组合模型按照UBL命名和设计规则自动生成的，该命名和设计规则在B.4中由叙述，遵循B.5给出的流程。而后，可从schema生成实施模型作为实施UBL的辅助工具。B.6部分给出的这些UBL类图表，表示了表单中描述的单证组合模型的实施。
UBL单证构件模型描述了UBL1.0定义的所有单证使用的信息构件。
单证构件模型是为支持UBL1.0采购流程（见第5部分）而对数据需求进行详细分析的结果。在建模过程中，公共的数据项是通过使用功能依赖关系标识聚合体的规范化过程来标识的。适当时，这些数据项被通用化，以能够被重复用于支持不同类型的业务单证。
单证构件模型用于下列目的：
促进可重复使用的构件的标识——这些构件即UBL 1.0业务单证中公共的数据结构
帮助理解全部剧本的信息需求
作为UBL单证组合模型中生成并编写业务信息实体的来源
构件模型最好用UML类图表表示。为了便于识别，该模型并未包括单证组合所需的所有元数据。
图B-2表示了所有的UBL单证构件模型。
![[ubl document component model]](uml/concept/comp/UBL-1.0-DocumentComponents.jpg)
Figure B-2. UBL Document Component Model (click on image to enlarge)
为了便于对此图表的理解，已将其分解为多个构件包，每个构件包表示构件的一个逻辑组合，并通过UML类图表描述，该类图表同时给出了属于构件包中的构件的属性（基本业务信息实体）和对象类（聚合类业务信息实体）。各个构件包的范围是任意的，在这些类图表之外不具有重要性。
例如，参与方的可重复使用的构件包如下所示：
![[party component diagram]](uml/concept/comp/UBL-1.0-PartyPackage.jpg)
Figure B-3. Party Component Package
所有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
并未给这些模型中的关联关系定义特定的方向；它们可以在两个方向中任意导向。当单证进行组合时，再对每个关联关系定义其特定的导向关系。
为了定义不同类型的单证，前一节描述的构件根据语境需求（在这种情况下，即UBL1.0采购流程）和[CCTS]的元数据需求组合成层次结构。
单证组合开始于作为聚合类业务信息实体（对象类）的单证类型而组成UBL1.0的每个业务单证的定义。
例如，处于最高层的UBL1.0订单单证的单证组合模型用UML类图表显示如下：
![[order assembly diagram]](uml/concept/assy/UBL-1.0-OrderDocumentAssembly.jpg)
Figure B-4. Order Document Assembly Model
UBL1.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] 所需的其它元数据可以更容易定义。
可以将公式用于命名规则
可将表单直接映射到UN/CEFACT TBG17 所需的候选核心构件的提交格式。
负责数据建模的业务专家对表单更为熟悉。
实践证明这种格式可在应用系统中移植。
表单标注的优点感觉要大于其缺点，即缺乏建模语言本身所具有的对引用的完整性控制；需要进行手工编辑来控制修改带来的影响。在这种情况下，幸运的是，用来从表单生成最终的schema的商业软件工具能够修正模型的一致性。
UBL使用表单将构件组合描述成特定类型的单证。每个单证类型都有一个表单组合。
依据CCTS的术语，文档组合模型由基本业务信息实体BBIE（构件模型的属性）、聚合类业务信息实体ABIE（构件模型的对象类）以及关联类业务信息实体ASBIE（构件模型中的关联角色）组成。BBIE可被看做是数据结构中的叶子节点，ABIE被看作包含基本业务信息实体的数据结构，ASBIE看做为一个ABIE包含另一个ABIE的关系。
表单模型使用行来定义构件。构件或者是业务信息实体或者是数据类型。列定义与每个单证类型相关的元数据。多个表单的列由[CCTS]的需求决定。
因此，一个表单组合模型由一个“根”ABIE，一套BBIE，以及一套ASBIE组成。与“根”ABIE相关联的ABIE在可重复使用的BIE表单模型中定义。
所有BBIE的数据类型或者定义在未限定的数据类型表单模型中或者限定的数据类型表单模型中。
这些表单组合模型中的依赖关系如下图所示：
![[spreadsheet model dependency diagram]](art/UBL-1.0-ModelDependency.jpg)
Figure B-5. Spreadsheet Model Dependencies
本文件包中的所有表单文件用微软Excel格式和Open Office格式提供，如下所示：
注：UBL单证schema从表单模型自动生成。然而，UBL单证的规范形式不是这些表单模型而是XSD schema 本身，见第6节。
每个业务信息实体在一个单行里定义。行的背景颜色用来区分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
![[ubl schema generation]](art/UBL-1.0-SchemaGeneration.jpg)
Figure B-6. UBL Schema Generation Process
![[order implementation model]](uml/implem/doctypes/UBL-OrderImplementationDiagram-1.0.gif)
Figure B-7. Implementation Model for the Order Document
- 订单实施图表
- 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
除了主要的订单图表外，本发布版本还包括表示在单证中使用的可重复使用的构件包的视图的十个类图表。例如订单图表包括了与参与方、销售方、和购买方的关联。以下的实施图表详细显示了这些构件。
![[party implementation model]](uml/implem/packages/UBL-PartyImplementationDiagram-1.0.gif)
Figure B-8. Implementation Model for Party Components
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
关于取得UBL schema定制的兼容性的规则，以及无法使定制取得兼容性的情况下如何进一步实施的建议，见如下文件：
UBL定制规则是OASIS UBL语境方法分委员会的产品，其工作见其网站：
UBL 1.0 文件包在一个超文档中包含一套内容众多的格式规范，其根目录位于：
文件包的本部分也包括了附录D的实例的PDF版本。
UBL格式规范是OASIS UBL 格式表示分委员会的产品，其工作见其网站：
本附录提供了两个不同版本的“订单——发票”流程所用的UBL单证的实施实例。第一套实例说明了办公用品的购买，第二套说明了木工用品（建筑材料）的购买。本附录中还包含按照附录C中的格式规范每个创建的实例打整的打印版本。
购买方，比尔微设备公司从一家办公用品商店定购了几种不同的货项。购买方知道提供商每种货项的代码和价格。
- 办公用品订单实例
- 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
销售方，乔伊办公用品公司，用一个简单订单应答来表明接受了这个订单，销售方还给出了其订单的参考号码，即其系统中的销售单号码，并告诉购买方如果有任何问题找谁联系。
- 办公用品简单订单应答实例
- xml/office/UBL-OrderResponseSimple-1.0-Office-Example.xml
- 打印文件
- fs/OrderResponseSimple/pdf/OfficeOrderResponseSimple.Example-a4.pdf
- fs/OrderResponseSimple/pdf/OfficeOrderResponseSimple.Example-us.pdf
购买方撤销一个订单（为了便于说明，不是同一个订单）。
- 办公用品订单撤销实例
- 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
当货物发出时销售方自动生成发票，货项的短缺在发票之后解决。发票中显示了税金的金额。销售方通知要在发票开出的30日之内付款。
- 办公用品发票实例
- xml/office/UBL-Invoice-1.0-Office-Example.xml
- 打印文件
- fs/Invoice/pdf/OfficeInvoice.Example-a4.pdf
- fs/Invoice/pdf/OfficeInvoice.Example-us.pdf
购买方，英国的杰瑞建筑有限公司为其一个需把货送到的建筑工地定购了一些窗户、一些门、以及一些木料。杰瑞公司知道供应商每个货项的号码，该公司必须规定一些物理属性来准确获得其想要的货项：一些窗户是对称的，是左开还是右开，多数门是手动的、合页位于一侧，规定其木料、表层漆，以及配件（把手、支柱等）。货项的抛光方式有很多种。散装木料是按照其交叉部位编码的，必须规定其长度。购买方从目录中知道这些事宜的同时，并不知道它可能得到的价格和折扣比例。
- 木工用品订单实例
- xml/joinery/UBL-Order-1.0-Joinery-Example.xml
- 打印版本
- fs/Order/pdf/JoineryOrder.Example-a4.pdf
- fs/Order/pdf/JoineryOrder.Example-us.pdf
销售方，专业销售窗户有限公司，用一个详细的订单应答说明每个货项的单位价格，并通知购买方它可给出的贸易折扣。同时，销售方给出了订单的参考号码，即其系统中的销售单号码，并告诉购买方有何疑问时和谁联系。
- 木工用品订单应答实例
- xml/joinery/UBL-OrderResponse-1.0-Joinery-Example.xml
- 打印版本
- fs/OrderResponse/pdf/JoineryOrderResponse.Example-a4.pdf
- fs/OrderResponse/pdf/JoineryOrderResponse.Example-us.pdf
销售方通知购买方所订货物已发出，该货物实际上用两个托盘运出（运输单位），分别标识为A和B。发货通知中列明了订单行项系列中的货项，并指出货项位于哪个托盘。
- 木工用品发货通知实例
- xml/joinery/UBL-DespatchAdvice-1.0-Joinery-Example.xml
- 打印版本
- fs/DespatchAdvice/pdf/JoineryDespatchAdvice.Example-a4.pdf
- fs/DespatchAdvice/pdf/JoineryDespatchAdvice.Example-us.pdf
发货通知与发货同时进行；一份纸面拷贝在签署后作为收到的凭证。然后并不使用UBL收货通知。
当货物发出时销售方自动生成发票，货项的短缺在发票之后解决。发票中显示了缴税的日期，货项所属的增值税类目，增值税税率和发票中的各项税金的合计。一些费用如额外的发货费用也要用到增值税。为了鼓励尽快交付应交款项，销售商提供一种及时付款的折扣，只要购买方在30日之内付款就可扣除。（编写这个例子是为了表示一种语境：依据有关的法律规定要产生增值税，因此，此处的税金的计算依据贸易折扣后的总的贸易行项加一些费用，并减去结算折扣的金额。）
- 木工用品发票实例
- xml/joinery/UBL-Invoice-1.0-Joinery-Example.xml
- 打印版本
- fs/Invoice/pdf/JoineryInvoice.Example-a4.pdf
- fs/Invoice/pdf/JoineryInvoice.Example-us.pdf
本实例基于一个真实的英国木工用品制造商和销售商的产品、产品标识、业务需求以及实际情况。该公司有自己专业的运输船队，货运范围涉及全英国及其离岸岛屿。
在UBL 1.0中包含的代码表schema复合UBL代码表表示规范，见如下文件：
UBL 代码表表示规范是OASIS UBL 代码表分委员会的产品，该委员会的工作可从如下网站获得。
下面的UBL ASN.1 规范给出了另一种符合ITU-T X.680-X.693[ASN.1]的UBL单证的schema定义。UBL ASN.1规范定义了与第6章中组成有效UBL单证的规范定义的UBL XSD schema相同的UBL单证。UBL ASN.1 XML schema使得ASN.1 工具能够被用于转换UBL，与ASN.1 打包的编码规则一起，它提供了对UBL报文实施有效的二进制编码的规范。
- UBL ASN.1 规范
- asn/ASN.1-UBL-1.0.html
ASN.1 UBL规范是使用符合ITU-T Recommendation X.694 | ISO/IEC 8825-5的OSS Nokalva (http://www.oss.com/)的工具生成的。转换后，生成的ASN.1使用ASN.1 信息网站(http://asn1.elibel.tm.fr) 上的一个格式工具PrettyPrint调整格式，产生本文件包中的HTML文件。
UBL的总体目标是研制一套实用的XML业务单证的标准库，现UBL 1.0已达到了第一阶段的目标。第二个阶段（UBL 2.0）目的是对UBL库和Schema集进行补充，并产生自动生成面向特定语境的业务schema。
这些阶段之间存在一些工作项目出于这样或那样的原因不能在发布UBL 1.0时按时完成。其中一些工作项目说明了业界愿意连续不断地工作；另一些的情况是，某个问题不能在UBL 1.0发布的时间限制内取得一致的解决方案，但是可采取可接受的短期的方案，同时对UBL 1.0的应用在长期范围内不影响或很少影响其有效性。
下面的这些工作项目并不严格地纳入了四个标题：NDR 工作项目，互操作性工作项目，注册工作项目和本地化工作项目。欢迎对参与这些工作项目感兴趣的个人加入OASIS UBL 技术委员会。
下列工作项目与UBL命名和设计规则（NDR）有关。
时间限制妨碍了UBL命名和设计规则成为与UBL 1.0一起发布一套单独的规范。本文件包中包括的被成为NDR的文档只包括一个1.0的一个规则清单。将NDR文档作为一套单独的OASIS技术规范的工作仍在继续。
UBL代码表分委员会提供了一套综合的代码表（见附录E）解决方案，依据XSD组代替代码表客户化。由于在将XSD代替组用于业务单证schema方面缺乏业界的共识，该UBL技术委员会没有采用这种代码表的扩展机制，等待进一步探讨。在研制UBL1.0时已注意了如果在今后的版本中允许采纳代替组（如果认为合适），将不会使UBL1.0的应用失效。
是否应将代码表schema模型通过限定的数据类型schema（见6.2.2）间接导出还是应将其直接导出为公共聚合构件schema(见6.2.1)及其所用到的任何单独的单证schema，已成为一个公开的问题。在UBL1.0中，代码表schema模型是直接导出的，但是已有一些关于其性能方面影响的考虑。UBL1.0应用的反馈将主要针对解决这个问题。如果改为另一个方案的话，应该不会影响UBL1.0的使用。
在UBL 1.0中，所有的BBIE属性被声明为元素，并被定义为公共基本构件schema中的复合类型。另一中方法是，合格的BBIE属性元素可在其被使用的公共聚合构件schema或单个单证schema中声明。这个问题仍然是公开的，但是未来的版本中任何修改不会影响UBL1.0的使用。
下列事宜与UBL schema的存储和注册有关。
UBL命名和设计规则标识了schema位置的绝对路径名称的需求，该需求需要一种要求基于标准的schema，来确保一致性和明确性，并绝对确保实际确实使用了UBL的规范性schema。然而，当前的OASIS架构的限制排除了满足这一需求的适合的注册系统/库的可能。因此，发布UBL1.0时使用了schema位置的相对路径名称，以绕过相关的限制，使其在离线的情况下生效。当支持的基础设施成为可能时，未来版本中将为构件库使用绝对路径和注册系统。
UBL 1.0 规定每个UBL 数据类型和BIE的版本号也是1.0。然而，这是创建一个schema的问题还是一个存储问题目前存在争论。最终决定的结果可以导致为每个数据类型和BIE schema的创建在编写标注时赋予一个版本号码的需求。
下列工作项目与UBL单证在不同行业中的互操作性有关，与其他的业务单证有关。
在UBL1.0 客户化规则（见附录B.7）中已经初步进行了UBL一致性概念的定义工作，然而为了在法律法规环境下使用，创建UBL 一致性的定义的进一步工作是必要的。
很可能UBL1.0会依据UBL客户化规则进行修改，已形成某一个行业或地区的标准版本。需要针对这一应用案例进一步制定规则。
本文件包（见6.2.2）中包括的核心构件类型和数据类型的schema的研制是与Open Application Group公司的代表合作进行的，但目前这两个组织使用的版本并不完全一致。UBL1.0中使用的CCTS schema与OAGIS 9.0中使用的CCTS schema在下列5个方面存在差异：
作为属性的辅助性构件的命名
将XSD规范化的字串用于代码、标识符和文字构件
需要格式辅助构件（日期时间、指示符和数字型）的XSD内建的数据类型的使用
图形、图片、声音和视频数据类型的二进制对象的限制
指示符数据类型的模式
UBL1.1中可能会包括一套公共的CCTS schema。这应该不会影响UBL1.0应用的有效性。
作为CCTS的应用，UBL支持业务构件的公共语义库的概念。为达此目的，UBL正在与UN/CEFACT国际贸易和业务过程组织的协调工作组（即TBG17, http://webster.disa.org/cefact-groups/tbg/wg/tbg17_main.cfm）一同工作。该工作组负责跨业务领域和行业的业务流程模型和核心构件的一致性和协调性，致力于一套准确的定义良好的业务术语、业务数据语义定义和数据交换结构的词汇表。与TBG17的合作是UBL的一项不断的工作项目。
发布一套自动的语境方法是UBL2.0的内容，然而在UBL1.1的时间框架内也包括这一工作项目。它包括将本标准B.7中引用的客户化规范的改进。
UBL已形成几个本地化委员会，来将UBL规范及相关的文档翻译成英语之外的语言，并在非英语地区的环境中代表UBL的工作。是UBL1.1计划内的很多工作就是这些地区性的项目。到2004年4月，UBL已建成中文、日语、朝鲜语和西班牙语的本地化分委员会。
Copyright © 2001-2004 OASIS Open, Inc. All Rights Reserved.
对于本标准中描述的技术的使用和实施相关的可能要求的知识产权或其他权利的范围，或在这些权利下的许可可能或不可能适用的范围，OASIS没有任何立场；它也不表示它已标识了任何这些权利。关于OASIS规范的权利方面的OASIS的流程信息可从OASIS的网站中获得。用于公众使用的权利的声明以及能够使用许可证的保证的文本，或者本标准的实施方或用户需获得总的许可证或允许使用的权利可以从OASIS的行政长官获得。
OASIS欢迎有兴趣的各方就实施这一规范所需的技术可能涉及的版权、专利或所有权提醒OASIS的注意。请将此信息通知给OASIS的行政长官。
本文档和译文可以被拷贝并被提供给其他参与方，评论、解释或帮助其实施的一些派生的文件也可以被制定，拷贝、公开或发表，不论是全部或部分，都不受任何限制，但前提条件是以上的版权声明和本段包括在所有这些拷贝和派生的文件中。然而，本文档本身不能被修改，如，除了研制OASIS规范的目的需要之外，不能删除版权说明和对OASIS的引用，在这种情况下，必须遵循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.