[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: =?UTF-8?B?VUJM5Lit5paH5pys5Zyw5YyW6L+b5bqm?=
文峰, 您好: 请问你现在的翻译进度如何? 麻烦你可以把已经完成了的部分发给我们吗? 如果你们现在有其他的事在忙, 我们可以接下余下的工作把它们给完成. 所 以请你无论如何尽快回复, 让我们可以在这边准备一下. 谢谢! -Patrick Wenfeng SUN wrote: >Patrick, > >您好， > >上一周休假，没有及时回复，请原谅。 > >现把index.html发给你，其他的部分整理后再发给你。 > >谢谢！ > >孙文峰 >中国标准化研究院 > > >----- Original Message ----- >From: "Patrick Yee" <kcyee@cecid.hku.hk> >To: "Wenfeng SUN" <sunwf@cnis.gov.cn> >Cc: <ubl-cnlsc@lists.oasis-open.org> >Sent: Monday, August 02, 2004 3:06 PM >Subject: Re: UBL中文本地化进度 > > > > >>文峰， >> >>谢谢！如果方便的话，请麻烦你把已完成的部分电邮过来给我， >>好让我在这边做繁体翻译这部分的工作。 >> >>谢谢！-Patrick >> >> >>Wenfeng SUN wrote: >> >> >> >>>Patrick, >>> >>>其他那8个文件还没有翻译，我将尽快将其完成。 >>> >>>全部翻译工作可在8月份完成。 >>> >>>谢谢！ >>>孙文峰 >>>中国标准化研究院 >>> >>>----- Original Message ----- >>>From: "Patrick Yee" <kcyee@cecid.hku.hk> >>>To: "Wenfeng SUN" <sunwf@cnis.gov.cn> >>>Cc: <william@npc.org.cn>; <weih@cnis.gov.cn>; <ubl-cnlsc@lists.oasis-open.org> >>>Sent: Friday, July 30, 2004 3:16 PM >>>Subject: Re: UBL中文本地化进度 >>> >>> >>> >>> >>> >>> >>>>文峰， >>>>谢谢你和你小组的努力。我现在有一问题想澄清一下，由于在 spreadsheet model >>>>中，除了 reusable 以外，还有八个文件 (mod/maindoc/UBL-*.xls) 是须要翻译 >>>>的，请问那些文件是否都已经完成？那八个文件，连同 reusable，将会是我们在 >>>>第一阶段须要提交的。 >>>>谢谢！ >>>>-Patrick >>>> >>>>Wenfeng SUN wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Patrick and William, >>>>>现在完成的部分为： >>>>>spreadsheet model中的reusabel部分的翻译基本完成； >>>>>index.htm的文件的翻译已完成； >>>>>NDR checklist的翻译已完成； >>>>>其他工作正在进行。 >>>>>谢谢！ >>>>>孙文峰 >>>>>中国标准化研究院 >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> ------------------------------------------------------------------------ >> >> [oasis logo] >> >> >> 统一业务语言（UBL） 1.0 >> >> >> 发布日期 >> >> 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 >> <mailto:bill.meadows@sun.com>> >> >> Lisa Seaburg, Aeon LLC <lseaburg@aeon-llc.com >> <mailto:lseaburg@aeon-llc.com>> >> >> >> 协助起草单位 >> >> Members of the Technical Committee <doc/etc/UBL-credits-1.0.html> >> >> >> 中文本地化工作单位 >> >> 中国标准化研究院<http://www.cnis.gov.cn> >> >> >> 中文本地化工作人员 >> >> 孙文峰<sunwf@cnis.gov.cn <mailto:sunwf@cnis.gov.cn>> >> >> 魏宏<weih@cnis.gov.cn <mailto:weih@cnis.gov.cn>> >> >> 程煌<> >> >> 等等 >> >> >> >> >> 摘要 >> >> 本规范定义了统一业务语言 >> >> >> 状态 >> >> 本文档是OASIS 统一业务语言技术委员会的委员会草案，由中文本地化分委员 >> 会翻译。有何意见请反映至UBL技术委员会的网址： >> >> http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=ubl >> >> >> 目 次 >> >> 1 前言 <#INTRO> >> >> 2 规范性引用文件 <#REFS> >> >> 3 术语和定义 <#DEFS> >> >> 4 符号和缩略语 <#ABBR> >> >> 5 UBL 1.0 采购流程 <#PROCURE> >> >> 6 UBL 1.0 Schemas <#SCHEMAS> >> >> 附录 <#NOTES> A ( <#NOTES>资料性附录 <#METHOD>)：版本说明 <#NOTES> >> >> 附录 <#METHOD> B (资料性附录)： UBL 方法 <#METHOD> >> >> 附录 <#METHOD> C ( <#FORMAT>资料性附录 <#METHOD>)：格式规范 <#FORMAT> >> >> 附录 <#METHOD> D ( <#INSTANCES>资料性附录 <#METHOD>)：实施实例 >> <#INSTANCES> >> >> 附录 <#METHOD> E ( <#CODES>资料性附录 <#METHOD>)：代码表 <#CODES> >> >> 附录 <#METHOD> F ( <#ASN1>资料性附录 <#METHOD>)：ASN.1 规范 <#ASN1> >> >> 附录 <#METHOD> G ( <#ONGOING>资料性附录 <#METHOD>)：现行工作项目 >> <#ONGOING> >> >> 附录 <#METHOD> H: 附注 <#NOTICES> >> >> >> 1 前言 >> >> 自从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规范 >> >> >> 2 规范性引用文件 >> >> *[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.iso.org/iso/en/ittf/PubliclyAvailableStandards/c002349_ISO_IEC_11179-1_1999%28E%29.zip> >> http://www.oasis-open.org/committees/download.php/6233/c002349_ISO_IEC_11179-1_1999%28E%29.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 术语和定义 >> >> *组合模型 Assembly model* >> 一个可作为单证的schema实施的树型结构的模型。 >> *类图表 Class diagram* >> [UML] <#uml> 使用其描述一个系统静态结构的图形标记，包括对象类及其 >> 属性和关联关系。 >> *构件模型 Component model* >> 一个规范化的数据构件的表示，该数据构件用来描述对象类之间一个可能 >> 的关联和角色的网络关系。 >> *语境Context* >> 某些事物存在或发生的环境，包括其中的条件或事件。 >> *依赖图表 Dependency diagram* >> 强调对象类之间依赖关系的一个细化的类图表。 >> *单证 Document* >> 作为业务交易的一部分来交换的一套信息构件，例如，发出一个订单。 >> *功能依赖关系Functional dependency* >> 一种聚合构件的方式，其依据是当一套属性改变时另一套属性是否改变， >> 即后者是否依赖于前者。 >> *规范化Normalization* >> 标识和定义功能依赖关系的一种正式的方法。 >> *表单模型Spreadsheet model* >> >> 用表格表示的组合模型的表示。 >> >> *XSD schema* >> 一个符合W3C XML Schema 语言[XSD1] <#xsd1>[XSD2] <#xsd2>的XML单证 >> 定义。 >> >> 本标准中也使用了一些核心构件、基本核心构件、聚合类核心构件、关联类核 >> 心构件、业务信息实体、基本业务信息实体、聚合类业务信息实体的术语，其 >> 定义见[CCTS] <#ccts>。 >> >> 本标准中也使用了一些对象类、属性词、表示词以及限定符，其定义见 >> [ISO11179] <#iso11179>。 >> >> 本标准中出现的“必须”、“必须不”、“所需的”、“应该”、“不应该”、“推荐”、 >> “可能”、“可选的”关键词见 [RFC2119] <#rfc2119>。 >> >> >> 4 符号和缩略语 >> >> *ABIE* >> 聚合类业务信息实体 >> *ACC* >> 聚合类核心构件 >> *ASBIE* >> 关联类业务信息实体 >> *ASCC* >> 关联类核心构件 >> *BBIE* >> 基本业务信息实体 >> *BCC* >> 基本核心构件 >> *BIE* >> 业务信息实体 >> *CC* >> 核心构件 >> *EAN* >> 欧洲物品编码委员会 >> *EDI* >> 电子数据交换 >> *ISO* >> 国际标准化组织 >> *NDR* >> UBL命名和设计规则（见附录B.4） >> *UML* >> 统一建模语言[UML] <#uml> >> *UN/CEFACT* >> 联合国贸易促进和电子业务中心 >> *XML* >> 可扩展置标语言 [XML] <#xml> >> *XSD* >> W3C XML Schema 语言 [XSD1] <#xsd1> [XSD2] <#xsd2> >> >> >> 5 UBL 1.0 采购流程 >> >> UBL1.0文档合构件库的设计支持典型的“发票——订单”的采购循环。本部分描述 >> 了基本流程以及UBL1.0中该流程的单证类型角色的业务规则和编排关系。 >> >> 非常需要注意的是UBL库的设计支持了UBL1.0文件包之外的很多种单证类型。希 >> 望当UBL发展时，再增加其他单证类型。 >> >> >> 5.1 “订单——发票”循环 >> >> 这一模型描述了一个从发票到订单的基本的贸易循环，包括三个参与方：货物 >> 的购买方、货物的销售方、以及货物的接收方，接收方可能与购买方不同。支 >> 持这一流程的UBL提供的单证类型包括： >> >> 订单 >> >> 简单订单应答 >> >> 详细订单应答 >> >> 订单更改 >> >> 订单撤销 >> >> 发货通知 >> >> 收货通知 >> >> 发票 >> >> 下边图标中的黑框中显示了基本流程中的每种文档类型。 >> >> [order-to-invoice diagram] >> >> *Figure 1. Order-to-Invoice Business Process* >> >> >> 5.2 单证业务规则 >> >> 本部分描述了基本“订单——发票”流程的业务规则，该规则在UBL1.0被看作单证 >> 类型的需求。 >> >> >> 5.2.1 订单 >> >> 订单可以规定折扣和费用方面的说明（如，运费，文档等。）来标识费用的类 >> 型以及由谁支付。订单付款方式可以依据给定的卖方的贸易信息帐户，或一个 >> 信用卡/借记卡帐户，或者签订一个直接借款协议。订单中可以规定一种缺省用 >> 于所有定价的和专门用于发票出票的全能货币。在一个订单中，可以再为其他 >> 单个的货项规定用于定价、折扣或费用的货币。 >> >> 贸易折扣可以在订单这一级规定。在未规定的情况下，买方可能不知道贸易折 >> 扣。卖方有必要给出详细的应答；见订单应答（5.2.3） >> >> 订单可以规定一些交货条款和条件，用于和交货地点有关的下列信息，这些信 >> 息通常在发货通知之后出现。 >> >> * >> >> 运输 >> >> o >> >> 工具 >> >> o >> >> 模式 >> >> o >> >> 一对多脚的运输阶段 >> >> + >> >> 日期 >> >> + >> >> 地点 >> >> o >> >> 到达“窗口” >> >> * >> >> 托运包装 >> >> o >> >> 类型，例如集装箱，托盘 >> >> o >> >> 标识符，例如SSCC，运货标记（发货通知） >> >> 订单提供了多个订单行项，每个订单行项给出单个发货地点的规定以及交货数 >> 量计划和所要求的交货日期。 >> >> 订单行项可以给出交货的说明，而订单可以规定交货条款。 >> >> 购买方可以给出其他可能被接受的备选方案。可为每个订单行项包括一个备选 >> 的货项。备选货项可以在货项限定符的范围内规定。例如，规定的数量可能会 >> 改变，如，20X6的包可有10X12作为备选方案。 >> >> >> 5.2.2 简单订单应答 >> >> 简单订单应答是卖方收到买方的订单的确认方式，表明该订单或者被承诺无修 >> 改地执行，或者被拒绝。 >> >> >> 5.2.3 订单应答 >> >> 卖方建议的修改通过全面的订单应答单证完成。 >> >> 订单应答建议替换原订单。它反映了订单交易的一个全新的阶段。它也提供了 >> 一种方法使得卖方向买方确认或提供买方在发出订单时并未获知或并未规定的 >> 一些关于订单的细目。包括： >> >> * >> >> 交货日期，在买方没有特别要求的情况下由卖方给出。 >> >> * >> >> 价格 >> >> * >> >> 贸易折扣 >> >> * >> >> 费用 >> >> * >> >> 海关物品分类编码 >> >> 卖方可以使用订单应答给出更改或替换，或者必要的更改的建议。更改或替换 >> 的货项可在货项标识符的范围内规定。例如，规定的数量可能会改变，如20X6 >> 的包装可替换10X12的包装。 >> >> >> 5.2.4 订单更改 >> >> 依据法定合同和贸易伙伴协议，购买方可以用两种方法更改一个已创建的订 >> 单：发送一个订单更改，或者先发送一个订单撤销（见5.2.5），再发送一个新 >> 的完整的代替的订单。 >> >> 一个订单更改反映了一个订单交易的全部当前的状态。 >> >> 出于多种原因，购买方可以对一个先前已接受的订单进行修改，如：更改订单 >> 项、数量、交货日期、货物运到地点等。供应商可以使用订单应答或者简单订 >> 单应答接受或者拒绝一个订单更改。 >> >> >> 5.2.5 订单撤销 >> >> 在流程中的任意一点，一个购买方可以使用订单撤销单证取消一个已创建的订 >> 单交易。订单撤销可以被忽略的情况（例如，在制造过程中或发货手续已开 >> 始），是由法定合同、贸易伙伴协议和业务规则限定的。在协议和规则的限定 >> 下，订单撤销可以是，也可以不是一个自动的业务交易。作为业务承诺的合同 >> 信息的条款和条件将决定哪些这样的限制或规则适用。 >> >> >> 5.2.6 发货通知 >> >> 下列信息可能出现在发货通知中： >> >> * >> >> 运输 >> >> o >> >> 工具 >> >> o >> >> 方式 >> >> o >> >> 一对多脚的运输阶段 >> >> + >> >> 日期 >> >> + >> >> 地点 >> >> o >> >> 到达窗口 >> >> * >> >> 托运包装 >> >> o >> >> 类型，如集装箱、托盘 >> >> o >> >> 标识符，如SSCC货运标签 >> >> 发货通知解决下面两种情况： >> >> * >> >> 发货机构使用运输处理单元安排货项，以便接收方可以检验运输处理单 >> 元以及装纳的货项。同一订单行项里的同一货项数量可以被分配到不同 >> 的运输处理单元，从而也出现在一个运输处理单元的不同的发货行项中。 >> >> * >> >> 发货机构使用发货行项安排货项，并标注货项所在的运输处理单元，来 >> 促进对订单的核对。为了方便，任何一个订单行项分散到多个运输处理 >> 单元的情况将导致货项所在的每个运输处理单元都有一个发货行项。 >> >> 另外，以上任一情况下，发货通知应给出： >> >> * >> >> 全部发货——告知接收方或购买方将要或正在将订单中所有的行项在一个 >> 给定的日期用一个完整的发货发出。 >> >> * >> >> 部分发货——告知接收方或购买方将要或正在将订单中的货项在一个给定 >> 的日期部分地发出。 >> >> 发货通知中的发货行项不需要与订单行项一一对应，应通过引用相关联。订单 >> 通知的信息结构可能导致一个订单行项对应多个发货行项的结果。同样，部分 >> 发货可能导致某些订单行项与一个订单通知中的行项不匹配。 >> >> 在一个发货通知中，一个货项可能会给出货物的原在国以及货物的危险程度。 >> >> >> 5.2.7 收货通知 >> >> 收货通知是由接收方（购买方）向销售方发出的，来确认货项的接收，而且能 >> 够说明货物的损失和损伤。 >> >> 收货通知解决了两种情况。每次已声明的发货对应的声明已处理的收货，必须 >> 与对应的发货通知结构相同。 >> >> * >> >> 通过运输处理单元以及其中包括的收货行项来声明货物接收，该收货行 >> 项与销售方详细给出的发货通知一一对应。 >> >> * >> >> 通过运输处理单元注明的收货行项声明货物接收，与销售方详细给出的 >> 发货通知一一对应。 >> >> 收货通知应允许接收方能够从声明的发货数量中报告货物的缺失，并报告由于 >> 给定的原因被拒绝的货物数量。 >> >> 就目前而言，收货行项中可以有一个拒绝数量和原因。然而，如果需要为同一 >> 个货项说明其他拒绝的原因，可以将收货行项分成多个收货行项，因此一个发 >> 货行项对应多个收货行项。 >> >> >> 5.2.8 发票 >> >> 一般来说，发票的发出基于一个发货事件激发一个发票的情况。一个发票单证 >> 也可以在全部或部分预付款的基础上发出。这些情况是： >> >> * >> >> 预付款发票（预期将收到付款） >> >> * >> >> 估价发票（前期建议，未预期收到付款） >> >> * >> >> 普通发票，在已发货项发货时给出 >> >> * >> >> 收货通知返回后给出的发票 >> >> 发票单证中仅包括出于发票目的的信息。并不重复订单、订单更改、订单应 >> 答、发货通知以及收货通知中开发票是并不需要的已有信息。如果需要，发票 >> 单证可以引用订单、发货通知或者收货通知。 >> >> 发票单证中的缴税项允许组合税项，其计算顺序参照在数据流中重复的信息的 >> 顺序（例如，能源税，带有VAT增值税，并重复征收）。 >> >> 费用可在计算税务之前规定，可按照一次付清额规定，也可按照适用于发票单 >> 证总额的百分比数规定。这些费用包括： >> >> * >> >> 包装 >> >> * >> >> 送递/邮寄 >> >> * >> >> 运费 >> >> * >> >> 文本起草费用 >> >> 每个发票行项可以引用任何相关的订单行项也可以引用发货行项和/或收货行项。 >> >> 发票单证并未包括借和贷附注，这个过程也不包括客户帐户声明，该声明中包 >> 括了需要付款的发票、借方附注和贷方附注。 >> >> >> 5.3 货项业务规则 >> >> 货项结构从所有基本过程中的单证类型中获得。 >> >> >> 5.3.1 货项标识 >> >> 每个货项用一个标识符进行标识（如，一个产品标识符），应为以下中之一种： >> >> * >> >> 买方货项标识 >> >> * >> >> 卖方货项标识 >> >> * >> >> 制造商货项标识 >> >> * >> >> 目录货项标识 >> >> * >> >> 参照一个标准化组织发布的标识系统的货项标识 >> >> 货项标识假定一个货项的每个不同的包装有一个不同的货项标识符。（如同一 >> 货项的6包和12包的包装）。 >> >> 货项可以通过计量单位和物理属性进一步进行区分。这使得以下各种货项规定 >> 成为可能。 >> >> >> 5.3.1.1 需要进行描述的货项 >> >> 该货项的产品代码标识不能被机器无歧异地处理，需要另外的描述性信息，来 >> 对其进行准确标识。 >> >> >> 5.3.1.2 客户定义的货项 >> >> 该货项由客户按照其需要在规定中对其进行描述，在规定中，客户可以引用可 >> 比较的 “标准的”货项。 >> >> >> 5.3.1.3 需要计量的货项 >> >> 该货项需要规定一个或多个计量，作为货项的描述性规定的一部分。 >> >> >> 5.3.2 货项的定价 >> >> 对于任何给定的货项，价格内容包括金额、数量等，并未回复给销售方；只规 >> 定动态价格。购买方可能并不知道货项的基准价格，在这种情况下不规定。因 >> 此，销售方有必要给出详细的应答信息，见订单应答。 >> >> >> 5.3.3 其他货项细目 >> >> 虽然已订货项可能包括危险货项，在订单阶段没有必要规定相关的信息。购买 >> 方可能不知道货项的性质。货项的危险性的说明以及其他相关的信息，将在发 >> 货通知中给出。 >> >> >> 6 UBL 1.0 Schema >> >> 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子目录有一个平行的（技术上是非规范性的） >> “运行时间”集，它带有节选出来的的标注元素。 >> >> >> 6.1 UBL单证schema >> >> 定义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 >> >> >> 6.2 UBL公共schema >> >> Xsd/common目录包括被8个xsd/maindoc下单证schema引用的6个schema。 这些 >> 公共schema中的的两个包括可重复使用的数据构件的UBL库，这些数据构件组合 >> 成了主要单证schema；其中的三个包括了需要实施 [CCTS] <#ccts> 一致性的 >> 定义；其中一个提供了schema元数据的一致性格式。下面给出了每个schema文 >> 件的名称，以及其名称的简要描述。 >> >> >> 6.2.1 可重复使用的业务信息实体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），其 >> 作用是用于创建主要单证的“全球基本业务信息实体类型数据库”。 >> >> >> 6.2.2 可重复使用的数据类型schema >> >> *核心构件类型* >> xsd/common/UBL-CoreComponentTypes-1.0.xsd >> 这一shema提供了[CCTS] <#ccts>定义的核心构件类型。这些类型用来 >> 以标准化和一致的方式构建更高层的数据类型。这一schema不能被修改。 >> *未限定的数据类型* >> xsd/common/UBL-UnspecializedDatatypes-1.0.xsd >> 这一schema定义了 [CCTS] <#ccts>规定的主要和二级表示术语的未限 >> 定的数据类型。这些XSD复合类型机构来自于核心构件类型，是生成其 >> 他数据类型的基本数据类型。这一schema不能被修改。 >> *限定的数据类型* >> xsd/common/UBL-SpecializedDatatypes-1.0.xsd >> 这一schema给出了[CCTS] <#ccts>定义的限定的数据类型。这些XSD复 >> 合类型结构通过扩展、限定、以及其他语境限制由未限定的数据类型 >> 生成。如facets.规定的数据类型已在UBL1.0采购流程中被客户化，可 >> 能会被进一步扩展来支持业务语境所需的其它数据类型。 >> >> *注：*在此使用“限定”和“未限定”的用语，而不使用“规定”和“未规定”的用 >> 语，目的是避免与[XSD1] <#xsd1>和[XSD2] <#xsd2>中规定的和未规定的名称 >> 相混淆。 >> >> >> 6.2.3 单证元数据schema >> >> *核心构件参数* >> xsd/common/UBL-CoreComponentParameters-1.0.xsd >> 这一schema定义了出现在所有其他schema中的标注和单证部分的结构，为 >> 诸如对象类、表示术语、语义描述和其他补充信息等元数据提供了一致格式。 >> >> >> 6.3 UBL代码表schema >> >> UBL1.0所需的13个代码表包括在xsd/codelist目录下。这些代码表schema允许 >> 符合任意主要单证schema的构件例子代码表中的值进行验证。关于UBL代码表使 >> 用的表示形式见附录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 schema依赖关系 >> >> 下面的图表显示了组成一个UBL1.0单证schema的schema模型之间的依赖关系。 >> 注（和本此发布版本中其他的UML的表示方法一样），依赖的构件指向了被其依 >> 赖的构件。 >> >> [schema dependency diagram] >> >> *Figure 2. UBL Schema Dependencies* >> >> >> 附录 A (资料性附录): 版本说明 >> >> >> A.1 获得本版本的地址 >> >> 在本文档开头的地方可以在线下载本版本。 >> >> >> A.2 文件包的结构 >> >> UBL1.0规范是作为一个名为cd-UBL-1.0.zip的文件发布的。将此文件包解压得 >> 到一个名为cd-UBL-1.0的目录，其中包括一个主超文本文件（本文件， >> index.html）和一些子目录。这些子目录中的文件从index.html中，被 >> index.html所链接，包括了1.0发布版本的不同的规范性的和资料性的材料。下 >> 面给出了每个目录的描述。 >> >> *|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部分。 >> >> >> A.3 工具 >> >> UBL激发了相关的免费以及商业软件工具的研制。目前可从UBL工具和方法分委 >> 员会的的网站上找到一系列的UBL工具： >> >> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl-ttsc. >> >> >> A.4 支持 >> >> UBL是国际业务领域内的自愿性项目，关于UBL的疑问可以发布在公共的目录 >> 上，位于： >> >> http://lists.oasis-open.org/archives/ubl-dev/ >> >> 可从下列网址向OASIS目录关联员索取 >> >> http://lists.oasis-open.org/ob/adm.pl >> >> >> A.5 递归结构 >> >> 库中某些构件允许递归结构。例如，一个包装可能包括其他包装，一个发货可 >> 以规定另一个发货。这些都是合乎规定的业务数据结构。多数实际的应用系统 >> 将限制这些结构中递归的次数，但是XSD schema 无法表示这个限制。实施人员 >> 应明白这一点并在其应用系统中加以限制。 >> >> >> 附录 B (资料性): UBL方法 >> >> >> B.1 UBL的研究方法 >> >> UBL没有强制使用一种规定的研制方法。本部分的目的是描述UBL研制过程中不 >> 断发展的流程，以使标准的实施人员能够理解本文件包里的各种技术工具的作 >> 用。他们也可以选择适应这种方法，使其符合其自身的需要。 >> >> 研制UBL1.0的方法如下所示： >> >> [development process diagram] >> >> *Figure B-1. The UBL Development Process* >> >> 最初的UBL数据构件库是基于xCBL3.0schema库的，该库又基于UN/EDIFACT 以及 >> ANSI X12 EDI构件库。在检查这一构件库时，感觉到有必要创建一套抽象的实 >> 体的概念模型，并采用一种能更好地支持循环的研制周期的形式。 >> >> UBL使用两种概念模型，一种单个的定义信息构件的模型和一套描述如何将这些 >> 构件组成单证定义的模型。前者作为单证构件模型引用，并通常使用UML类图表 >> （见下边的B.2）表示后者作为单证组合模型引用，并通常使用表单表示。 >> >> UBL1.0采购流程所需的构件的标识和组合是使用[CCTS] <#ccts>的域、构件模 >> 型和需求方面的业务知识手工生成的。在UBL1.0采购剧本中，每个单证类型都 >> 开发一套独立的表单；而可重复使用的构件组成了另一个独立的表单。其他的 >> 表单是用来对[CCTS] <#ccts>规定的核心构件类型、未限定数据类型、以及限 >> 定的数据类型建模的。UBL1.0使用的表单组合模型的全集在B.3中有叙述。 >> >> 本标准的第6部分中规定的UBL schema是由表单组合模型按照UBL命名和设计规 >> 则自动生成的，该命名和设计规则在B.4中由叙述，遵循B.5给出的流程。而 >> 后，可从schema生成实施模型作为实施UBL的辅助工具。B.6部分给出的这些UBL >> 类图表，表示了表单中描述的单证组合模型的实施。 >> >> >> B.2 构件模型 >> >> 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] >> >> *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 >> >> 并未给这些模型中的关联关系定义特定的方向；它们可以在两个方向中任意导 >> 向。当单证进行组合时，再对每个关联关系定义其特定的导向关系。 >> >> >> B.3 Document Assembly Models >> >> 为了定义不同类型的单证，前一节描述的构件根据语境需求（在这种情况下， >> 即UBL1.0采购流程）和[CCTS] <#ccts>的元数据需求组合成层次结构。 >> >> 单证组合开始于作为聚合类业务信息实体（对象类）的单证类型而组成UBL1.0 >> 的每个业务单证的定义。 >> >> 例如，处于最高层的UBL1.0订单单证的单证组合模型用UML类图表显示如下： >> >> [order assembly diagram] >> >> *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] <#ccts> 所需的其它元数据可以更容易定义。 >> >> * >> >> 可以将公式用于命名规则 >> >> * >> >> 可将表单直接映射到UN/CEFACT TBG17 所需的候选核心构件的提交格式。 >> >> * >> >> 负责数据建模的业务专家对表单更为熟悉。 >> >> * >> >> 实践证明这种格式可在应用系统中移植。 >> >> 表单标注的优点感觉要大于其缺点，即缺乏建模语言本身所具有的对引用的完 >> 整性控制；需要进行手工编辑来控制修改带来的影响。在这种情况下，幸运的 >> 是，用来从表单生成最终的schema的商业软件工具能够修正模型的一致性。 >> >> >> B.3.1 表单模型 >> >> UBL使用表单将构件组合描述成特定类型的单证。每个单证类型都有一个表单组合。 >> >> 依据CCTS的术语，文档组合模型由基本业务信息实体BBIE（构件模型的属 >> 性）、聚合类业务信息实体ABIE（构件模型的对象类）以及关联类业务信息实 >> 体ASBIE（构件模型中的关联角色）组成。BBIE可被看做是数据结构中的叶子节 >> 点，ABIE被看作包含基本业务信息实体的数据结构， ASBIE看做为一个ABIE包 >> 含另一个ABIE的关系。 >> >> 表单模型使用行来定义构件。构件或者是业务信息实体或者是数据类型。列定 >> 义与每个单证类型相关的元数据。多个表单的列由[CCTS] <#ccts>的需求决定。 >> >> 因此，一个表单组合模型由一个“根”ABIE，一套BBIE，以及一套ASBIE组成。与 >> “根”ABIE相关联的ABIE在可重复使用的 BIE表单模型中定义。 >> >> 所有BBIE的数据类型或者定义在未限定的数据类型表单模型中或者限定的数据 >> 类型表单模型中。 >> >> 这些表单组合模型中的依赖关系如下图所示： >> >> [spreadsheet model dependency diagram] >> >> *Figure B-5. Spreadsheet Model Dependencies* >> >> 本文件包中的所有表单文件用微软Excel格式和Open Office格式提供，如下所示： >> >> *注：*UBL单证schema从表单模型自动生成。*然而，UBL单证的规范形式不是这 >> 些表单模型而是XSD schema 本身，见第6节。* >> >> >> B.3.2 单证表单 >> >> 每个业务信息实体在一个单行里定义。行的背景颜色用来区分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 公共构件表单 >> >> *可重复使用BIE表单* >> 这一模型提供了UBL中普遍使用的聚合类业务信息实体，其作用是用于创建主要 >> 单证的“全球基本业务信息实体类型数据库”。这一模型可在客户化中进行修改。 >> /关键：每个业务信息实体在一个单行里定义。行的背景颜色用来区分BBIE（白 >> 色）、ABIE（粉色）和ASBIE（绿色）。/ >> mod/common/UBL-Reusable-1.0.sxc >> mod/common/UBL-Reusable-1.0.xls >> *核心构件类型表单* >> 这一模型提供了[CCTS] <#ccts>定义的核心构件类型。这些类型用来以标准化 >> 和一致的方式构建更高层的数据类型。这一 schema不能被修改。 >> /关键：每个核心构件类型用一个行定义，行的背景颜色用来区分补充性构件 >> （白色）和核心构件类型（粉色）。/ >> mod/common/UBL-CoreComponentTypes-1.0.sxc >> mod/common/UBL-CoreComponentTypes-1.0.xls >> *未限定的数据类型表单* >> 这一模型规定了[CCTS] <#ccts>定义的未规定的数据类型。这些类型用来以标 >> 准化和一致的方式构建更高层的数据类型。这一模型不能被修改。 >> /关键：每个数据类型用一个行定义，行的背景颜色用来区分补充性构件（白 >> 色）和核心构件类型（粉色）。/ >> mod/common/UBL-UnspecializedDatatypes-1.0.sxc >> mod/common/UBL-UnspecializedDatatypes-1.0.xls >> *限定的数据类型表单* >> 这一模型规定了[CCTS] <#ccts>定义的限定的数据类型。这些类型用来构建更 >> 高层次的数据类型，它们被客户化来满足特定的实施。对于有些作为限定的数 >> 据类型的BBIE，需要用代码表对其进行验证，UBL有意对其进行了定义。它们是 >> 带有这一模型中给定的固定值的限定的形式的代码数据类型。需注意这些代码 >> 表在应用中是每个代码表都用一个单独的schema实现。这一模型可在客户化中 >> 进行修改。 >> /关键：每个数据类型用一个行定义，行的背景颜色用来区分补充性构件（白 >> 色）和核心构件类型（粉色）。/ >> mod/common/UBL-SpecializedDatatypes-1.0.sxc >> mod/common/UBL-SpecializedDatatypes-1.0.xls >> >> >> B.3.4 客户化模型 >> >> 希望客户化UBL的用户需遵循以下B.7引用的UBL1.0的客户化规则；同时，那些 >> 有意去直接修改构件或者组合模型并将UBL作为一个新的词典的用户应注意以下 >> 几方面的考虑，它们可能会影响与UBL的兼容性。 >> >> * >> >> 第一，任何对表单模型的修改需要对其结构、ebXML核心构件技术规范以 >> 及各个UBL库的组成部分的理解。例如，一些列可以被直接更新，但是其 >> 他的列在其单元格中包含实施 [CCTS] <#ccts>和UBL命名和设计规则的 >> 公式。当增加或编辑行的内容时，了解这些很有必要。应注意避免更新 >> 带有公式的单元格。 >> >> * >> >> 第二，schema的生成应与UBL命名和设计规则（下面的B.4）一致，以提 >> 高与其他UBL构件库的兼容性。 >> >> * >> >> 第三，在核心构件类型和未限定的数据类型中定义的数据类型是[CCTS] >> <#ccts>中定义的数据类型的直接应用，不应忽略这一事实而对其进行修 >> 改。提供限定的数据类型模型的目的是针对应用的数据类型。 >> >> UBL1.0单证构件和单证组合模型是OASIS UBL 库内容分委员会的产品，其工作 >> 可从其网站上获得： >> >> http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-lcsc >> >> >> B.4 UBL命名和设计规则 >> >> 本文件包中包含的UBL XML 命名和设计规则的清单给出了决定UBL 1.0 XSD >> schema 结构及元素/属性名称的规则。NDR清单在本文件包中是下面这个文件。 >> >> doc/ndr/UBL-NDR-Checklist-1.0.pdf >> >> UBL命名和设计规则是OASIS UBL 命名和设计规则分委员会的产品，其工作可从 >> 其网站上获得： >> >> http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-ndrsc >> >> >> B.5 Schema Generation >> >> UBL 1.0 XSD schema是应用schema的构建规则将上面B.3描述的UBL表单表示的 >> 数据模型进行转换而产出的结果。转换过程包括如下几步： >> >> 1. >> >> 读取数据模型表单 >> >> 2. >> >> 从每个表单中创建一个基于UML的模型 >> >> 3. >> >> 明确外部的代码表标准，并在适当的情况下包括标准代码表的值 >> >> 4. >> >> 应用UBL命名和设计规则 >> >> 5. >> >> 产出一致的XSD schema >> >> 一个应用核心构件的商业软件，GEFEG EDIFIX® 5.0，用于将表单读取为UML的 >> 数据模型，进行质量测试，能生成一个符合UBL1.0 命名和设计规则的schema >> 表示，如下所示。关于GEFEG EDIFIX®的信息，请参考http: >> //www.gefeg.com/en/standard/xml/ubl.htm。GEFEG EDIFIX® 5.0 UBL阅读器 >> 是一个免费软件，能够方便地浏览UBL schema和数据模型。对于GEFEG EDIFIX® >> 5.0 UBL阅读器的信息，请参考http://www.gefeg.com/en/edifix/reader- >> ubl.html。 >> >> [ubl schema generation] >> >> *Figure B-6. UBL Schema Generation Process* >> >> UBL规范的前期版本对这个流程使用了不同的工具。对于产生 UBL 1.0 测试版 >> schema的过程的描述，请参考1.0测试版委员会草案的附录D： >> http://www.oasis-open.org/committees/ubl/lcsc/UBLv1-beta/. >> UBL 1.0 schema 的生成是在OASIS UBL 工具和方法分委员会的指导下进行的。 >> UBL TTSC的工作可从其网站上获得： >> >> http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-ttsc >> >> >> B.6 实施模型 >> >> UBL的实施模型用UML模型表示了实际的UBL XSD schema，它是将schema自动转 >> 换成符合统一建模语言[UML] <#uml>的模型而生成的。这些模型然后用来产生 >> 一套类图表，描述每一种主要单证及几种可重复使用构件的视图。这种自动转 >> 换以及图表的生成是用商业的“从schema到UML”的转换工具完成的，关于这一产 >> 品的进一步的信息，参见 http://www.xmlmodeling.com/. >> 本部分中的UML类图表有助于在不需要理解XSD语法的情况下理解UBL的schema。 >> 为了达到此目的，这些类图表有意地隐藏了相关schema中的细节。例如，关于 >> 在一个复合类型的定义中的订单的信息在图表中并没有保留。而其他的修改使 >> 得UML模型对软件工程更为有用；例如， XSD复合类型名称中的“类型”后缀在创 >> 建UML类名称时被删除，以产生一个独立于XSD语法的类名称；带有简单内容值 >> 的复合类型子元素作为类属性表示，而带有复合内容的元素作为那些类型类的 >> 关联表示。 >> 这些图表是单证组合表单模型的UML等同体。 >> >> >> B.6.1 单证实施图表 >> >> 8个UBL 1.0单证类型中的每一个都创建了一个实施类图表。如上所述，实施图 >> 表是隐藏了包括在这些聚合结构中的类型细节的简化视图。例如，UBL订单单证 >> 的类图表如下所示： >> >> [order implementation model] >> >> *Figure B-7. Implementation Model for the Order Document* >> >> 包括在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 可重复使用的构件实施图表 >> >> 除了主要的订单图表外，本发布版本还包括表示在单证中使用的可重复使用的 >> 构件包的视图的十个类图表。例如订单图表包括了与参与方、销售方、和购买 >> 方的关联。以下的实施图表详细显示了这些构件。 >> >> [party implementation model] >> >> *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 >> >> >> B.7 客户化规则 >> >> 关于取得UBL schema定制的兼容性的规则，以及无法使定制取得兼容性的情况 >> 下如何进一步实施的建议，见如下文件： >> >> doc/cm/wd-ubl-cmsc-cmguidelines-1.0.html >> <doc/cm/wd-ubl-cmsc-cmguidelines-1.0.html> >> >> UBL定制规则是OASIS UBL语境方法分委员会的产品，其工作见其网站： >> >> http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-cmsc >> >> >> 附录 C (资料性附录)：格式规范 >> >> UBL 1.0 文件包在一个超文档中包含一套内容众多的格式规范，其根目录位于： >> >> fs/index.html <fs/index.html> >> >> 文件包的本部分也包括了附录D的实例的PDF版本。 >> >> UBL格式规范是OASIS UBL 格式表示分委员会的产品，其工作见其网站： >> >> http://www.oasis-open.org/committees/sc_home.php?wg_abbrev=ubl-fpsc >> >> >> 附录 D (资料性附录)： 实例 >> >> 本附录提供了两个不同版本的“订单——发票”流程所用的UBL单证的实施实例。第 >> 一套实例说明了办公用品的购买，第二套说明了木工用品（建筑材料）的购 >> 买。本附录中还包含按照附录C中的格式规范每个创建的实例打整的打印版本。 >> >> >> D.1 实例1：购买办公用品 >> >> 购买方，比尔微设备公司从一家办公用品商店定购了几种不同的货项。购买方 >> 知道提供商每种货项的代码和价格。 >> >> *办公用品订单实例* >> 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 >> >> >> D.2 实例2：购买木工用品（建筑材料） >> >> 购买方，英国的杰瑞建筑有限公司为其一个需把货送到的建筑工地定购了一些 >> 窗户、一些门、以及一些木料。杰瑞公司知道供应商每个货项的号码，该公司 >> 必须规定一些物理属性来准确获得其想要的货项：一些窗户是对称的，是左开 >> 还是右开，多数门是手动的、合页位于一侧，规定其木料、表层漆，以及配件 >> （把手、支柱等）。货项的抛光方式有很多种。散装木料是按照其交叉部位编 >> 码的，必须规定其长度。购买方从目录中知道这些事宜的同时，并不知道它可 >> 能得到的价格和折扣比例。 >> >> *木工用品订单实例* >> 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 >> >> 本实例基于一个真实的英国木工用品制造商和销售商的产品、产品标识、业务 >> 需求以及实际情况。该公司有自己专业的运输船队，货运范围涉及全英国及其 >> 离岸岛屿。 >> >> >> 附录 E (资料性附录)：代码表 >> >> 在UBL 1.0中包含的代码表schema复合UBL代码表表示规范，见如下文件： >> >> doc/cl/wd-ublclsc-codelist-20040420.pdf >> <doc/cl/wd-ublclsc-codelist-20040420.pdf> >> >> UBL 代码表表示规范是OASIS UBL 代码表分委员会的产品，该委员会的工作可 >> 从如下网站获得。 >> >> 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] <#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/> (http://www.oss.com/)的工具生成的。 >> 转换后，生成的ASN.1使用ASN.1 信息网站(http://asn1.elibel.tm.fr) 上的 >> 一个格式工具PrettyPrint调整格式，产生本文件包中的HTML文件。 >> >> >> 附录 G (资料性附录): 现行工作项目 >> >> UBL的总体目标是研制一套实用的XML业务单证的标准库，现UBL 1.0已达到了第 >> 一阶段的目标。第二个阶段（UBL 2.0）目的是对UBL库和Schema集进行补充， >> 并产生自动生成面向特定语境的业务schema。 >> >> 这些阶段之间存在一些工作项目出于这样或那样的原因不能在发布UBL 1.0时按 >> 时完成。其中一些工作项目说明了业界愿意连续不断地工作；另一些的情况 >> 是，某个问题不能在UBL 1.0发布的时间限制内取得一致的解决方案，但是可采 >> 取可接受的短期的方案，同时对UBL 1.0的应用在长期范围内不影响或很少影响 >> 其有效性。 >> >> 下面的这些工作项目并不严格地纳入了四个标题：NDR 工作项目，互操作性工 >> 作项目，注册工作项目和本地化工作项目。欢迎对参与这些工作项目感兴趣的 >> 个人加入OASIS UBL 技术委员会。 >> >> >> G.1 NDR Work Items >> >> 下列工作项目与UBL命名和设计规则（NDR）有关。 >> >> >> G.1.1 Specification UBL 命名和设计规则作为一项单独的标准发布 >> >> 时间限制妨碍了UBL命名和设计规则成为与UBL 1.0一起发布一套单独的规范。 >> 本文件包中包括的被成为NDR的文档只包括一个1.0的一个规则清单。将NDR文档 >> 作为一套单独的OASIS技术规范的工作仍在继续。 >> >> >> G.1.2 代码表客户化的代替组 >> >> UBL代码表分委员会提供了一套综合的代码表（见附录E）解决方案，依据XSD组 >> 代替代码表客户化。由于在将XSD代替组用于业务单证 schema方面缺乏业界的 >> 共识，该UBL技术委员会没有采用这种代码表的扩展机制，等待进一步探讨。在 >> 研制UBL1.0时已注意了如果在今后的版本中允许采纳代替组（如果认为合 >> 适），将不会使UBL1.0的应用失效。 >> >> >> G.1.3 代码表schema模型的导出 >> >> 是否应将代码表schema模型通过限定的数据类型schema（见6.2.2）间接导出还 >> 是应将其直接导出为公共聚合构件schema (见6.2.1)及其所用到的任何单独的 >> 单证schema，已成为一个公开的问题。在UBL1.0中，代码表schema模型是直接 >> 导出的，但是已有一些关于其性能方面影响的考虑。UBL1.0应用的反馈将主要 >> 针对解决这个问题。如果改为另一个方案的话，应该不会影响UBL1.0的使用。 >> >> >> G.1.4 合格的BBIE属性元素定义 >> >> 在UBL 1.0中，所有的BBIE属性被声明为元素，并被定义为公共基本构件schema >> 中的复合类型。另一中方法是，合格的BBIE属性元素可在其被使用的公共聚合 >> 构件schema或单个单证schema中声明。这个问题仍然是公开的，但是未来的版 >> 本中任何修改不会影响UBL1.0的使用。 >> >> >> G.2 注册工作项目 >> >> 下列事宜与UBL schema的存储和注册有关。 >> >> >> G.2.1 Schema模型中的相对路径 >> >> UBL命名和设计规则标识了schema位置的绝对路径名称的需求，该需求需要一种 >> 要求基于标准的schema，来确保一致性和明确性，并绝对确保实际确实使用了 >> UBL的规范性schema。然而，当前的OASIS架构的限制排除了满足这一需求的适 >> 合的注册系统/库的可能。因此，发布 UBL1.0时使用了schema位置的相对路径 >> 名称，以绕过相关的限制，使其在离线的情况下生效。当支持的基础设施成为 >> 可能时，未来版本中将为构件库使用绝对路径和注册系统。 >> >> >> G.2.2 每个BIE的编写的版本元素 >> >> UBL 1.0 规定每个UBL 数据类型和BIE的版本号也是1.0。然而，这是创建一个 >> schema的问题还是一个存储问题目前存在争论。最终决定的结果可以导致为每 >> 个数据类型和 BIE schema的创建在编写标注时赋予一个版本号码的需求。 >> >> >> G.3 互操作性工作项目 >> >> 下列工作项目与UBL单证在不同行业中的互操作性有关，与其他的业务单证有关。 >> >> >> G.3.1 UBL一致性 >> >> 在UBL1.0 客户化规则（见附录B.7）中已经初步进行了UBL一致性概念的定义工 >> 作，然而为了在法律法规环境下使用，创建UBL 一致性的定义的进一步工作是 >> 必要的。 >> >> >> G.3.2 行业副本 >> >> 很可能UBL1.0会依据UBL客户化规则进行修改，已形成某一个行业或地区的标准 >> 版本。需要针对这一应用案例进一步制定规则。 >> >> >> G.3.3 公共的核心构件技术规范schema >> >> 本文件包（见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应用的有 >> 效性。 >> >> >> G.3.4 核心构件的协调 >> >> 作为CCTS的应用，UBL支持业务构件的公共语义库的概念。为达此目的，UBL正 >> 在与UN/CEFACT国际贸易和业务过程组织的协调工作组（即TBG17, >> http://webster.disa.org/cefact-groups/tbg/wg/tbg17_main.cfm）一同工 >> 作。该工作组负责跨业务领域和行业的业务流程模型和核心构件的一致性和协 >> 调性，致力于一套准确的定义良好的业务术语、业务数据语义定义和数据交换 >> 结构的词汇表。与TBG17 的合作是UBL的一项不断的工作项目。 >> >> >> G.3.5 语境方法 >> >> 发布一套自动的语境方法是UBL2.0的内容，然而在UBL1.1的时间框架内也包括 >> 这一工作项目。它包括将本标准B.7中引用的客户化规范的改进。 >> >> >> G.4 本地化工作项目 >> >> UBL已形成几个本地化委员会，来将UBL规范及相关的文档翻译成英语之外的语 >> 言，并在非英语地区的环境中代表UBL的工作。是 UBL1.1计划内的很多工作就 >> 是这些地区性的项目。到2004年4月，UBL已建成中文、日语、朝鲜语和西班牙 >> 语的本地化分委员会。 >> >> >> 附录 H: 声明 >> >> 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. >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]