← Prev in month
← Prev in thread
Next in thread →
Next in month →
UBL V2.0のチェック・評価依頼
MHonArc v2.5.0b2 --> ubl-jplsc message [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home] Subject: UBL V2.0$B$N%A%'%C%/!&I>2A0MMj(B From: "Yukinori Saito" <> To: "UBL JPLSC" <>, $BBg:e9)6HBg3X!KFbF#MM(B <>, $B@PL}2=3X9)6H6(2q!K>eLnMM(B <> Date: Tue, 10 Jan 2006 16:28:11 +0900 UBL JPLSC$B%a%s%P!<3F0L(B $BTitle: Universal Business Language 2.0 Universal Business Language 2.0 Publication Date 3 January 2006 Document identifier wd-UBL-2.0 Editorial Status Draft in progress Location [temporary] http://ibiblio.org/bosak/ubl/wd-UBL-2.0/ Downloadable Package Location [temporary] http://ibiblio.org/bosak/ubl/wd-UBL-2.0.zip Package Assembly Jon Bosak Contributors Members of the OASIS UBL Technical Committee Abstract This specification defines the Universal Business Language version 2.0. Status This document is a working 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 Viewing this Document Older web browsers such as Internet Explorer may not correctly support the CSS styles and XHTML markup used for this document. For best results, the Firefox 1.5 and Opera 8.5 (or later) browsers are recommended. Table of Contents 1 Introduction 2 Normative References 3 Terms and Definitions 4 Symbols and Abbreviations 5 UBL 2.0 Process Context 6 UBL 2.0 Schemas Appendix A (Informative): Release Notes Appendix B (Informative): UBL 2.0 Data Models Appendix C (Informative): UBL 2.0 Code Lists Appendix D (Informative): UBL 2.0 Naming and Design Rules Appendix E: 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 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 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 generic procurement and transportation contexts. A standard basis for XML business schemas is expected to provide 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. A standard target for inexpensive off-the-shelf business software. 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. As the first standard 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 release. 1.1 The Original UBL 1.0 Order-to-Invoice Process UBL 2.0 builds upon the basic procurement process established in UBL 1.0. That process, based on eight basic document types shown in bold outline, is illustrated in the diagram below. Figure 1. UBL 1.0 Order-to-Invoice Business Process Though apparently limited in scope, the eight document types provided in UBL 1.0 are applicable to a very large number of real-world use cases and have been widely deployed. 1.2 New in UBL 2.0 Adoption of UBL 1.0 following ratification as an OASIS Standard in November 2004 has resulted in major inputs of new content beyond the eight basic order-to-invoice business documents specified in the original release. In particular, contributions from representatives of government procurement, taxation, and transportation agencies in Europe, Asia, and the United States have resulted in greatly expanded pre-order and post-invoice capabilities together with the addition of several transport-related document types. These additions have increased the number of UBL document types from eight in UBL 1.0 to 29 in UBL 2.0. Original UBL 1.0 order-to-invoice document types: Order, OrderResponse, OrderResponseSimple, OrderChange, OrderCancellation, DespatchAdvice, ReceiptAdvice, Invoice New UBL 2.0 document types for sourcing: CatalogueRequest, Catalogue, CatalogueItemSpecificationUpdate, CataloguePricingUpdate, CatalogueDeletion, RequestForQuotation, Quotation New UBL 2.0 document types for fulfilment: ForwardingInstruction, PackingList, BillOfLading, Waybill, CertificateOfOrigin New UBL 2.0 document types for billing: CreditNote, DebitNote, SelfBilledInvoice, SelfBilledCreditNote, FreightInvoice New UBL 2.0 document types for payment: RemittanceAdvice, Statement New UBL 2.0 supplementary document types: ApplicationResponse, AttachedDocument The role of the 21 new UBL 2.0 document types is described in further detail below. 1.3 Other Differences between UBL 1.0 and UBL 2.0 While every effort has been made to keep UBL 2.0 backward-compatible with UBL 1.0, several changes resulting from experience with 1.0 have proven extensive enough to make this a major release instead of a minor version update. These changes must be considered in upgrading existing UBL-based systems to take advantage of the greatly expanded applicability of UBL 2.0. 1.3.1 Global Scoping In UBL 1.0, the great majority of element types were globally scoped, the only exceptions being ID and Code. In UBL 2.0, all types are globally scoped. 1.3.2 Code Lists The UBL mechanism for specifying and validating code lists has been completely revamped using the power of Schematron [SCH] (ISO/IEC 19757-3) to make it easier to modify code lists and perform basic business rule checking. See Appendix C, Code Lists. 1.3.3 Data Elements A number of elements have been changed to reflect actual practice, as shown in the following two tables. Aggregate BIEBasic or Association BIEChange in UBL 2.0 Address AddressLineChanged cardinality to 0..n AddressLine LineChanged cardinality to 1 AllowanceCharge CurrencyCodeRemoved BasePrice MaximumQuantityRemoved MinimumQuantityRemoved MaximumAmountRemoved MinimumAmountRemoved BuyerParty Renamed to CustomerParty BuyerAssignedAccountIDRenamed to CustomerAssignedAccountID SellerAssignedAccountIDRenamed to SupplierAssignedAccountID Delivery DespatchAddressReplaced by Despatch DespatchLine DeliveryReplaced by Shipment DeliveryTermsReplaced by Shipment Item TransportHandlingUnitReplaced by Shipment DocumentReference CopyIndicatorChanged cardinality to 1 InvoiceLine LineStatusCodeRemoved Item SalesConditionsRenamed to TransactionConditions TaxCategoryRenamed to ClassifiedTaxCategory BasePriceRemoved LineItem BuyersIDRenamed to ID SellersIDRenamed to SalesOrderID OrderLineReference BuyersLineIDRenamed to LineID and changed cardinality to 1 SellersLineIDRenamed to SalesOrderLineID OrderReference BuyersIDRenamed to ID and changed cardinality 10 1 SellersIDRenamed to SalesOrderID Party PartyNameChanged cardinality to 0..n PartyName NameChanged cardinality to 1 ReceiptLine LineStatusCodeRemoved DeliveryReplaced by Shipment TransportHandlingUnitReplaced by Shipment OrderedItemIdentificationReplaced by Item SalesConditions Renamed to TransactionConditions SellerParty Renamed to SupplierParty BuyerAssignedAccountIDRenamed to CustomerAssignedAccountID SellerAssignedAccountIDRenamed to SupplierAssignedAccountID Shipment TransportEquipmentReplaced by TransportHandlingUnit TaxCategory ExemptionReasonRemoved TaxScheme JurisdictionAddressRenamed to JurisdictionRegionAddress TaxTotal TotalTaxAmountRenamed to TaxAmount TransportEquipment DimensionRenamed to MeasurementDimension TransportEquipmentSeal IssuerTypeCodeRenamed to SealIssuerTypeCode TransportHandlingUnit UnitTypeCodeRenamed to TransportHandlingUnitTypeCode Table 1. Changes to Library Elements in UBL 2.0 Aggregate BIEBasic or Association BIEChange in UBL 2.0 DespatchAdvice CopyIndicatorChanged cardinality to 1 BuyerPartyRenamed to BuyerCustomerParty SellerPartyRenamed to SellerSupplierParty FreightForwarderPartyReplaced by Shipment DeliveryReplaced by Shipment DeliveryTermsReplaced by Shipment DespatchedTransportHandlingUnitReplaced by Shipment ActualShipmentReplaced by Shipment Invoice CopyIndicatorChanged cardinality to 1 InvoiceCurrencyCodeRenamed to DocumentCurrencyCode and changed cardinality to 1 LineItemCountNumericRemoved BuyerPartyRenamed to BuyerCustomerParty and changed cardinality to 0..1 SellerPartyRenamed to SellerSupplierParty and changed cardinality to 0..1 PaymentMeansChanged cardinality to 0..n ExchangeRateRenamed to TransactionExchangeRate Order BuyersIDRenamed to ID and changed cardinality to 1 SellersIDRenamed to SalesOrderID CopyIndicatorChanged cardinality to 1 AcknowledgementResponseCodeRemoved TransactionCurrencyCodeRenamed to DocumentCurrencyCode and changed cardinality to 1 EarliestDateRemoved ExpiryDateRemoved ValidityDurationMeasureRemoved TaxTotalAmountRemoved LineExtensionTotalAmountRemoved TotalPackagesQuantityRemoved GrossWeightMeasureRemoved NetWeightMeasureRemoved NetNetWeightMeasureRemoved GrossVolumeMeasureRemoved NetVolumeMeasureRemoved LineItemCountNumericRemoved ContractDocumentReferenceReplaced by Contract QuoteDocumentReferenceRenamed to QuotationDocumentreference BuyerPartyRenamed to BuyerCustomerParty SellerPartyRenamed to SellerSupplierParty OriginatorPartyRenamed to OriginatorCustomerParty SalesConditionsRenamed to TransactionConditions OrderCancellation CopyIndicatorChanged cardinality to 1 IssueDateTimeRenamed to IssueDate and changed to Date datatype DocumentStatusCodeRemoved ResponseRequiredIndicatorRemoved AcceptedIndicatorRemoved BuyerPartyRenamed to BuyerCustomerParty SellerPartyRenamed to SellerSupplierPArty OrderChange BuyersIDRenamed to ID SellersIDRenamed to SalesOrderID CopyIndicatorChanged cardinality to 1 DocumentStatusCodeRemoved AcknowledgementResponseCodeRemoved TransactionCurrencyCodeRenamed to DocumentCurrencyCode and changed cardinality to 1 EarliestDateRemoved ExpiryDateRemoved ValidityDurationMeasureRemoved TaxTotalAmountRemoved LineExtensionTotalAmountRemoved TotalPackagesCountQuantityRemoved GrossWeightMeasureRemoved NetWeightMeasureRemoved NetNetWeightMeasureRemoved GrossVolumeMeasureRemoved NetVolumeMeasureRemoved LineItemCountNumericRemoved OrderReferenceChanged cardinality to 1 ContractDocumentReferenceReplaced by Contract QuoteDocumentReferenceRenamed to QuotationDocumentReference BuyerPartyRenamed to BuyerCustomerParty SellerPartyRenamed to SellerSupplierParty OriginatorPartyRenamed to OriginatorCustomerParty SalesConditionsRenamed to TransactionConditions OrderResponse BuyersIDRenamed to ID and changed cardinality to 1 SellersIDRenamed to SalesOrderID CopyIndicatorChanged cardinality to 1 DocumentStatusCodeRemoved EarliestDateRemoved ExpiryDateRemoved ValidityDurationMeasureRemoved TaxTotalAmountRemoved LineExtensionTotalAmountRemoved TotalPackagesCountQuantityRenamed to TotalPackagesQuantity LineItemCountNumericRemoved BuyerPartyRenamed to BuyerCustomerParty SellerPartyRenamed to SellerSupplierParty OriginatorPartyRenamed to OriginatorCustomerParty SalesConditionsRenamed to TransactionConditions RespondedOrderLineRenamed to OrderLine OrderResponseSimple CopyIndicatorChanged cardinality to 1 DocumentStatusCodeRemoved BuyerPartyRenamed to BuyerCustomerParty SellerPartyRenamed to SellerSupplierParty ReceiptAdvice CopyIndicatorChanged cardinality to 1 BuyerPartyRenamed to BuyerCustomerParty SellerPartyRenamed to SellerSupplierParty FreightForwarderPartyReplaced by Shipment DeliveryReplaced by Shipment ReceivedTransportHandlingUnitReplaced by Shipment Table 2. Changes to Document Elements in UBL 2.0 1.3.4 Attributes Several attribute names have been changed to implement the UN/CEFACT Core Component Type schemas, as shown in the following table. TypeAttributeChange in UBL 2.0 AmountType amountCurrencyIDRenamed to CurrencyID amountCurrencyCodeListVersionIDRemoved BinaryObjectType formatAdded mimeCodeAdded encodingCodeAdded uriAdded filenameAdded GraphicType formatAdded mimeCodeAdded encodingCodeAdded uriAdded filenameAdded characterSetCodeRemoved PictureType formatAdded mimeCodeAdded encodingCodeAdded uriAdded filenameAdded characterSetCodeRemoved SoundType formatAdded mimeCodeAdded encodingCodeAdded uriAdded filenameAdded characterSetCodeRemoved VideoType formatAdded mimeCodeAdded encodingCodeAdded uriAdded filenameAdded characterSetCodeRemoved CodeType codeListIDRenamed to listID codeListAgencyIDRenamed to listAgencyID codeListAgencyNameRenamed to listAgencyName codeListNameRenamed to listName codeListVersionIDRenamed to listVersionID codeListURIRenamed to listURI codeListSchemeURIRenamed to listSchemeURI IdentifierType identificationSchemeIDRenamed to schemeID identificationSchemeNameRenamed to schemeName identificationSchemeAgencyIDRenamed to schemeAgencyID identificationSchemeAgencyNameRenamed to schemeAgencyName identificationSchemeVersionIDRenamed to schemeVersionID identificationSchemeURIRenamed to schemeURI identificationSchemeDataURIRenamed to schemeDataURI MeasureType measureUnitCodeRenamed to unitCode measureUnitCodeListVersionIDRenamed to unitCodeListVersionID QuantityType quantityUnitCodeRenamed to unitCode quantityUnitCodeListIDRemoved quantityUnitCodeListAgencyIDRemoved quantityUnitCodeListAgencyNameRemoved Table 3. Changes to Attributes in UBL 2.0 1.4 Supporting Materials As an aid to deployment, the standard XML schemas in UBL 1.0 were accompanied by a large quantity of supporting materials, most of them included in the UBL 1.0 release package as informative appendices and the remainder available from sites referenced in the release package. These materials included descriptions of example implementations, sample instances of each of the UBL documents used in the example implementations, formatting specifications for the United Nations Layout Keys corresponding to each of the UBL basic business document types, and an ASN.1 specification to enable the transmission of UBL messages in binary form. Also included were documents describing the UBL 1.0 Naming and Design Rules, the UBL 1.0 code list mechanism, and UBL 1.0 customization guidelines. Due to the greatly increased scope of UBL 2.0, the supporting documents and informative materials corresponding to those in the UBL 1.0 Standard are being provided in a separate UBL 2.0 Support Package in order to reduce scheduling dependencies between the normative and informative parts of the specification. The Support Package is being developed in parallel with the UBL 2.0 specification and will be made available after ratification of UBL 2.0 as an OASIS Standard. 1.5 Taxation Rules UBL 2.0 does not provide documents for tax reporting. It provides the structures on which tax information is based rather than implementations of specific tax rules. To implement support for specific tax regimes, the OASIS UBL Technical Committee intends to work with the OASIS TaxXML Technical Committee to provide guidelines that explain how specific tax requirements (e.g., audit trails) are implemented using UBL. 1.6 UBL Customization and Profiling Recommendations for the development of derivative implementations such as national and industry profiles of UBL will be provided as part of the UBL 2.0 Support Package. 1.7 UBL Development Methodology UBL 2.0 has been developed based on the principles of the ebXML Core Components Technical Specification [CCTS]. This entailed developing conceptual models of Basic Information Entities. To gather requirements and business rules, several workshops were held involving participants from a range of industries and countries. Based on the defined processes and business rules for the context of use, Business Information Entities were identified and aggregated using normalization techniques to maximize re-use and clarify meanings. This resulted in a comprehensive model of all BIEs relevant to the UBL 2.0 use case. The design strategy has been to provide an 80/20 solution — describing 80% of the required components with 20% of the complexity. This meant that in some cases, components less commonly used or used only in particular contexts were dropped on the understanding that specific implementations may extend UBL to satisfy these requirements. The resultant conceptual model of BIE components forms the library from which all UBL document models are assembled. Every UBL 2.0 conceptual model of a document (known as a document assembly model) contains the “root” ABIE for the document. This itself contains several BBIEs (individual pieces of information) and ASBIEs (associations to other ABIEs in one of the three libraries). This creates the hierarachical structure necessary to represent an XML document schema. The artifacts used to express these conceptual models are UML Class Diagrams and UBL-specific spreadsheets. The spreadsheets are the artifacts used to automatically generate schemas based on the UBL Naming and Design rules. As was the case in UBL 1.0, the UBL 2.0 schemas were generated by EDIFIX (see Appendix B, UBL 2.0 Data Models). 1.8 Acknowledgements The UBL Technical Committee thanks Altova for its donation of XML Spy licenses and GEFEG for both its donation of EDIFIX licenses and its untiring programming and technical assistance. 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] ISO/TS 15000-5:2005 Electronic Business Extensible Markup Language (ebXML) — Part 5: ebXML Core Components Technical Specification, Version 2.01 (ebCCTS) 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.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 [SCH] Document Schema Definition Languages (DSDL) - Part 3: Rule-based validation (Schematron) http://www.iso.ch/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=40833 [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 of ABIEs 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. Context The circumstance or events that form the environment within which something exists or takes place. Document A set of information components that are interchanged as part of a business transaction; for example, in placing an order. 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 ASBIE Association Business Information Entity BBIE Basic Business Information Entity BIE Business Information Entity CC Core Component EDI Electronic Data Interchange ISO International Organization for Standardization NDR UBL Naming and Design Rules (see Appendix D) 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 Context of Use This section defines the business process and contextual rules and requirements for the exchange of document types included in the UBL 2.0 release. These processes (and the business rules associated with them) define a context for the use of the documents identified. They are normative insofar as they provide semantics for the UBL document schemas, but they should not be construed as limiting the application of those schemas. UBL 2.0 extends the order-to-invoice processs of UBL 1.0 to cover sourcing-to-payment and includes the commercial collaborations for international trade. The following use case diagram defines the scope of UBL 2.0 documents. Figure 2. Use Case covered by UBL 2.0 One of the guiding factors in defining this scope has been a focus on key documents for paperless trading. The following table lists the key document types for international trade as identified by the APEC Paperless Trading Initiative, with the names of the documents that are included in UBL 2.0 rendered in bold italic. Insurance Certificate Payment Order Certificate Of Origin Remittance Advice Letter Of Credit Debit Advice Bill Of Lading Customs Clearance Waybill Purchase Order Manifest Invoice Declarations Forwarding Instruction Sanitary (health/hygiene) and Phytosanitary Certificates Stowage Plan/Bay Plan Arrival Notice Advice Table 4. Documents Used for International Trade (APEC) While this section describes the business rules and choreography of the generic process and the context played by each of the UBL 2.0 document types in that process, it is important to stress that these are indicative and demonstrative scenarios only and are not intended to limit the uses to which UBL documents can be put. Also, it is important to note that the UBL 2.0 library is designed to support the construction of a wide variety of document types beyond those provided in the 2.0 package. It is expected that implementers will develop their own customized document types and that other UBL document types will be added as the library evolves. 5.1 General Business Rules This section describes the requirements and general business rules that are assumed for collaborations and document exchanges in UBL 2.0. 5.1.1 Items An item may be a product or a service Items can have multiple classifications A contract can influence prices An item may be part of another item An item may have a price per unit and an order unit An item can reference pictures and documents An item may have a validity period An item may refer to other relevant or necessary items 5.1.2 Item Identification One of the following identifiers may be used to identify each Item (for example, a product): 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 may be further distinguished by the specification of Measurement(s) or Physical Attribute(s). This enables specification of the following kinds of item: Item Requiring DescriptionThis is an item that is not identified by an unambiguous machine-processable product code and requires additional descriptive information to precisely identify it. Customer Defined ItemThis 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. Item Requiring MeasurementsThis is an item for which it is necessary to specify one or more measurements as part of the descriptive specification of the item. 5.1.3 Item Instances Certain Items may be identified and ordered as individual, unique objects, for example, a specific car rather than a make and model of a car. This form of identification may also be needed for product tracing (e.g., perishable goods) or because of the nature of the commodity (e.g., used, collectible, specialized, or rare). In data modeling terms, an Item Instance is an extension of an Item. 5.1.4 Item Pricing For any given Item, price ranges by amount, quantity, location, etc., are specified by the Seller during the sourcing stage. They are not repeated back to the Seller during Ordering; only the active price is specified. In some cases, 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 Order Response. 5.1.5 Hazardous Items Although ordered items may include Hazardous items, 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 and Transportation documents. 5.1.6 Parties In UBL, a party is defined as an individual, a group, or a body having a role in a business function. Dependent on the business process, a Party may play various roles in the document exchange. 5.1.7 Multilingual Text Descriptive components may be specified in several alternate languages. 5.2 Business Processes The UBL 2.0 documents and library are designed to support a typical sourcing-to-payment procurement cycle. The following sections describe each business collaboration in more detail. But first we should explain the roles that the parties involved in these processes may perform. 5.2.1 Party Roles In the UBL procurement processes there are two main actors representing the key organizations or individuals involved in the process, Customer and Supplier. Each of these may play various roles. Processes may also involve supplementary roles which may be provided by different parties. The actual role undertaken is dependant on the context of use. For example, the Despatch Party and Delivery Party as applied to the Procurement process may differ in the Transportation process. In other words, whether the Consignor in transportation process is actually equal to the Despatch Party or Seller in procurement depends on different business cases. The following table contains a description of the proposed procurement roles for the actor known as “Party”. Actor Role Description Example Synonyms Sends Receives Customer Originator The party that had the original demand for the goods and/or services and therefore initiated the procurement transaction. The Originator participates in pre-ordering activity either through RFQ and Quotation or by receiving a Quotation as a response to a punchout transaction on a marketplace or Seller’s website. If the Originator subsequently places an Order, the Originator adopts the role of Buyer. The Originator is the typically the contact point for queries regarding the original requirement and can be referred to in an Order Change, Order Cancellation, or Order Response. If an employee requests a computer, the employing company may become the Buyer, but the employee is the Originator. They need to receive information about the order. Request for Quotation Quotation Customer Buyer The party that purchases the goods or services on behalf of the Originator. The Buyer can be referred to in Order Response, Despatch Advice, Invoice, Self Billed Invoice, Credit Note, and Account Statement. A company may delegate the task of purchasing to a specialized group to consolidate orders and gain greater discounts. Order Point Order, Order Change, and Order Cancellation Order Response Customer Delivery The party to whom goods should be delivered. The Delivery Party can be the same as the Originator. The Delivery Party must be referred to at line item level in RFQ, Quotation, Order, Order change, Order Cancellation, and Order Response. The Delivery Party may be referred to at line level in Invoice, Self Billed Invoice, Credit Note, and Debit Note. The Delivery Party may be stipulated in a transport contract. If a municipality buys a wheelchair for a citizen, the wheelchair must be delivered to the citizen (the Delivery Party). In such cases the citizen may be notified before delivering the wheelchair. Delivery Point, Destination Party, Receiver, Recipient Receipt Advice Despatch Advice Customer Debtor The party responsible for making settlement relating to a purchase and resolving billing issues using a Debit Note. The Debtor must be referred to in an Order and may be referred to in an Order Response. In a Self Billing scenario, the Debtor is responsible for calculating and issuing tax invoices. If a kindergarten buys some toys they may be the Originator, Buyer, and Delivery Party, but the municipality may play the role of Debtor — they are going to pay for it. Invoicee, Accounts Payable In a traditional Billing scenario: Debit Note, Account Response, and Remittance Advice In a Self Billing scenario: Self Billed Invoice, Self Billed Credit Note, and Remittance Advice In a traditional Billing scenario: Invoice, Credit Note, and Statement of Account In a Self Billing scenario: Credit Note, Account Response, and Statement of Account Supplier Seller The party responsible for handling Originator and Buyer services. The Seller party is legally responsible for providing the goods to the Buyer. The Seller party receives and quotes against RFQs and may provide information to the Buyer’s requisitioning process through Catalogues and Quotations. The organization that sells wheelchairs to municipalities. Sales Point, Provider, Customer Manager Quotation, Order Response, Order Response Simple, Catalogue, Catalogue Deletion, Catalogue Item Specification Update, Catalogue Pricing Update RFQ, Order, Order Change, Order Cancellation, Request for Catalogue Supplier Despatch The party where goods are to be collected from. The Despatch Party may be stipulated in a transport contract. The wheelchair Supplier may store chairs at a local warehouse. The warehouse will actually despatch the chair to the Delivery Party. The local warehouse is then the Despatch Party. Despatch Point, Shipper, Sender Despatch Advice Receipt Advice Supplier Creditor The party who claims the payment and is responsible for resolving billing issues and arranging settlement. There are cases where the Creditor is not the Seller party. For example, factoring, where the invoicing is outsourced to another company. Accounts Receivable, Invoice Issuer In a traditional Billing scenario: Invoice, Credit Note, and Statement of Account In a Self Billing scenario: Credit Note, Account Response and Statement of Account In a traditional Billing scenario: Debit Note, Account Response, and Remittance Advice In a Self Billing scenario: Self Billed Invoice, Self Billing Credit Note, and Remittance Advice Supplier Payee The party to whom the Invoice is paid. The Creditor may not be the party to be paid due to changes in the organization, e.g., a company merger. Accounts Receivable Remittance Advice Party Catalogue Managing The party receiving a catalogue. Catalogue items may never be ordered, so the recipient of the catalogue is not an Originator or a Buyer. An organization has a central office for maintaining catalogues of approved items for purchase. Central Catalogue Party, Purchasing Manager Request for Catalogue Catalogue, Catalogue Deletion, Catalogue Item Specification Update, Catalogue Pricing Update Party Information Content Owner The party responsible for the integrity of the information provided about an item. The manufacturer may publish and maintain the data sheets about a product. Party Receiver The party receiving a document. A marketplace may receive an Application Response. Application Response Party Sender The party sending a document. A marketplace may send an Application Response. Application Response Party Consignor The party where goods are to be collected from. The Consignor may be stipulated in a transport contract. The Consignor will receive an invoice and make payments for the transport service provided. The wheelchair Supplier may store chairs at a local warehouse. The Freight Forwarder will collect the chair from the local warehouse, which is thus the Consignor. In this case, the warehouse also plays the role of Despatch Party to the Freight Forwarder. The consignor will pay the freight forwarder for shipping the wheelchair to the destination. Despatch Point, Shipper, Sender Forwarding Instruction, Packing List Bill of Lading, Waybill, Freight Invoice Party Consignee The party receiving a consignment of goods as stipulated in the transport contract. The party taking responsibility for the receipt of the consignment covering the wheelchair. Delivery Point Party Freight Forwarder The party arranging the carriage of goods, including connected services and/or associated formalities, on behalf of a Consignor or Consignee. The Freight Forwarder may also be the Carrier. The Freight Forwarder will create an invoice and bill to the consignor for the transportation service provided. The Consignor may have a contract with this Freight Forwarder, which is a transport services provider, to arrange all their transport needs. This Freight Forwarder may then engage the Airline to transport the wheelchair. In this case, the Freight Forwarder is still the transport services provider while the Airline becomes the Carrier. The Freight Forwarder will then bill the consignor for shipping the wheelchairs. Shipping Agent, Broker, Courier Forwarding Instruction, Freight Invoice Bill of Lading, Waybill, Packing List Party Carrier The party providing physical transport services. The Freight Forwarder may engage the Airline to deliver the wheelchair. The Airline is then the Carrier and delivers the chair to the Delivery Party. Freight Haulier, Shipper, Ships Agent, Shipping Company, Airline, Rail Operator, Road Haulier Bill of Lading, Waybill Forwarding Instruction Party Exporter The party supplies goods through the international purchase. The wheelchair Supplier has to apply for a Certificate of Origin in order to sell the chairs overseas. Seller, Consignor Certificate of Origin Application Response Party Endorser The party appointed by the Government of a country who has the right to certify a Certificate of Origin. This endorsement restricts goods imported from certain countries for political or other reasons. The Government agency validates all the information provided by Exporter for Certificate of Origin approval. Authorized Organization, Embassy Certificate of Origin, Application Response Certificate of Origin Party Importer The party receiving a consignment of goods as stipulated in the transport contract. A specialized group in a company consolidates the purchase request and handles the receiving of goods. Order Point, Delivery Party, Buyer, Customer, Consignee Certificate of Origin Party Freight Forwarder The Freight Forwarder will create an Invoice and bill to the consignor for the transportation service provided. Freight Forwarder is a transport services provider who arranges all the transport needed for transporting the wheelchairs. The freight forwarder will then bill the consignor for shipping the wheelchairs. Shipping Agent, Broker, Courier Freight Invoice Party Consignor The consignor will receive an invoice and make payments for the transport service provided. The consignor will pay the freight forwarder for shipping the wheelchair to the destination. Despatch Point, Shipper, Sender Freight Invoice Table 5. Party Roles 5.3 Sourcing Collaboration There are three kinds of sourcing: Catalogue provision Buyer initiated sourcing Punchout A Seller, Catalogue Managing Party, Originator, or Buyer Party can initiate sourcing. 5.3.1 Catalogue Provision A catalogue is defined as a document produced by a party in the procurement chain that describes items and prices. Catalogue provision is the case where a Seller sends information regarding items available for purchase to a potential customer. This may be on request or unsolicited. Because they are only potential customers, the role that receives a catalogue is always the Catalogue Managing Party. 5.3.1.1 Sourcing Business Rules Any conditions specified in the contract will overrule those stated in the common catalogue. A catalogue exchange is between one seller and one Catalogue Managing Party. A classification system may have its own set of properties. A classification scheme will have metadata. A catalogue may have a validity period. A catalogue should include item classifications. Classification schemes should include standard and specific properties. A catalogue may refer to the lot (sub-section) of a contract. A catalogue can explicitly specify the framework contract reference. A catalogue can refer to a DPS contract number. When a catalogue item is updated, the item is replaced in the catalogue. When a catalogue item is updated, historical information about replaced or updated items must be available to reconcile with outstanding transactions. Prices can be updated independently of other catalogue information. Catalogue distribution may be Seller initiated or Catalogue Managing Party initiated. If a Catalogue Managing Party initiates a request for a catalogue, they may request an entire catalogue or only updates to either pricing or item specification details. Whether Catalogue Managing Party initiated or not, the decision to issue a new catalogue or update an existing one is at the discretion of the Seller Party. If an updated catalogue is issued, then an action code will define the status of the items in the catalogue. 5.3.1.2 Create Catalogue The process of creating a Catalogue is shown in the following activity diagram. Figure 3. Create Catalogue Process Model 5.3.1.3 Update Catalogue Item Specification The process of updating a Catalogue Item Specification is shown in the following activity diagram. Figure 4. Update Item Specification Process Model 5.3.1.4 Update Catalogue Pricing The process of updating Catalogue pricing is shown in the following activity diagram. Figure 5. Update Catalogue Pricing Process Model 5.3.1.5 Delete Catalogue Deletion of a Catalogue is shown in the following activity diagram. Figure 6. Delete Catalogue Process Model 5.3.2 Customer Initiated Sourcing Customer initiated sourcing is the case where the Originator asks for a quotation, as shown in the following activity diagram. Figure 7. Customer Initiated Sourcing Process Model 5.3.3 Punchout Punchout applications are a technological innovation whereby an Originator is able to directly access a Seller's application from within their own procurement application. Figure 8. Punchout Sourcing Process Model The Originators leave (“punch out” from) their system and interact with the Seller’s catalogue to locate and order products, while their application transparently gathers pertinent information. While conceptually the punchout request is a form of Request for Quote, the exchange transaction is tightly coupled to the specific catalogue application and considered outside the scope of UBL 2.0. 5.4 Ordering Collaboration Ordering is the collaboration that creates a contractual obligation between the Seller and the Buyer. Figure 9. Ordering Process Model 5.4.1 Ordering Business Rules 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.4.3). The Order provides for multiple Order Lines. The Order may specify delivery terms, while the Order Line may provide instructions for delivery. The Buyer may indicate potential alternatives that are acceptable. 5.4.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 fulfil without change or that the Order has been rejected. 5.4.3 Order Response Proposed changes to an Order 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 Discounts Charges Item Classification codes The Seller may advise on replacements or substitutes which will be made, or changes necessary, using the Order Response. 5.4.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.4.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.4.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 the initiation of the delivery process). 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.5 Fulfilment Collaboration Fulfilment is the collaboration in which the goods or services are transferred from the Despatch Party to the Delivery Party. In common practice, fulfilment is either supported by a proactive Despatch Advice from the Despatch Party or by a reactive Receipt Advice from the Delivery Party. If the Customer is not satisfied with the goods or services, they may then cancel or change the order (see Section 5.4, Ordering). The Seller may have a fulfilment (or customer) service dealing with anomalies. Figure 10. Fulfilment with Despatch Advice Process Model 5.5.1 Despatch Advice Business Rules The Despatch Advice is sent by the Despatch Party to the Delivery Party to confirm shipment of items. 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.5.2 Receipt Advice Business Rules The Receipt Advice is sent by the Delivery Party to the Despatch Party to confirm receipt of items and is capable of reporting shortages or damaged items. Figure 11. Fulfilment with Receipt Advice Process Model 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 Delivery Party to state any shortages from the claimed despatch quantity and to state any quantities rejected for a given reason. 5.6 Billing Collaboration In the Billing collaboration, a request is made for payment for goods or services that have been ordered, received, or consumed. In practice, there are several ways in which goods or services can be billed. For UBL 2.0, we propose the following methods: Traditional Billing Using Credit Note Using Debit Note Self Billing (also known as billing on receipt) Using Credit Note Using Self billed Credit Note 5.6.1 Billing Business Rules 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 Receipt Advice 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. 5.6.2 Traditional Billing Traditional billing is where the supplier invoices the customer when the goods are delivered or the services provided. In this case, the invoice can be created at the time of despatch or when the Delivery Party acknowledges that the goods have been received (using a Receipt Advice). When there are discrepancies between the Despatch Advice, Receipt Advice, and/or the Invoice and the goods actually received, or the goods are rejected for quality reasons, the customer may send an Application Response or a Debit Note to the supplier. The supplier may then issue a Credit Note or another Invoice as required. A Credit Note or Debit Note may also be issued in the case of retrospective price change. Credit Notes or Debit Notes may be also issued after the Billing collaboration (as part of the Payment collaboration). 5.6.2.1 Billing using Credit Notes Billing using Credit Notes is shown in the following activity diagram. Figure 12. Billing with Credit Note Process Model When using Credit Notes, the supplier (in their role as Creditor) is responsible for specifying the tax requirements. 5.6.2.2 Billing using Debit Notes Billing using Debit Notes is shown in the following activity diagram. Figure 13. Billing with Debit Note Process Model When using Debit Notes, both the supplier (as Creditor) and the customer (as Debtor) are responsible for providing taxation information. 5.6.3 Self Billing A self billing process is where a customer “invoices” themselves, in the name and on behalf of the supplier, and provides the supplier with a copy of the self billed invoice. Therefore the supplier still has the role of Creditor, and the Debtor is still the customer. 5.6.3.1 Self Billing using Credit Notes Self Billing using Credit Notes is shown in the following activity diagram. Figure 14. Self Billing with Credit Note Process Model If the supplier finds that the self billed invoice is incorrect, e.g., wrong quantities or wrong prices, or if the goods have not been invoiced at all, they may send an Application Response or a Credit Note to the customer. The customer may then verify whether the adjustment is acceptable or not and consequently issue another self billed invoice or a self billing credit note. 5.6.3.2 Self Billing using Self Billed Credit Notes Self Billing using Self Billed Credit Notes is shown in the following activity diagram. Figure 15. Self Billing with Self Billed Credit Note Process Model When using Self Billed Credit Notes, the customer is raising the Self Billed Credit Note in the name and on behalf of the supplier. Therefore the supplier (as Creditor) and the customer (as Debtor) are still both responsible for providing taxation information. 5.6.4 Freight Billing Process An extension of the Billing process is that of Freight Billing. This use case represents the billing process between the Consignor and the Freight Forwarder through the use of an Invoice for freight charges. The party acting the role of Freight Forwarder initiates the process of billing the Consignor for logistic services. A Freight Invoice is issued by the party who provides the logistics services to the party who requests the service. The Freight Invoice lists the charges incurred in order to fulfill the agreed service. Figure 16. Freight Billing Process Model 5.7 Payment Collaboration The payment collaboration is where the Payee (who is most often the Creditor) is notified of any funds transferred against the account of the Debtor using a Remittance Advice. Figure 17. Payment Process Model 5.7.1 Statement of Account A Statement of Account can be used to notify the Debtor of the status of the billing. Figure 18. Statement Process Model 5.8 Initiate Transport Services Collaboration This use case defines the ordering of logistical services for international trade. With receipt of an order and acknowledgement by the Consignor that the goods are available and ready to be shipped, the Consignor initiates the transportation arrangements. This includes booking the consignment with a Transportation Provider such as the Freight Forwarder or the Carrier and advising the Delivery Party of the arrangements as needed. It should be noted that this use case does not cover regulatory notifications such as Customs declarations or arrangements for the physical movement of goods. Figure 19. Initiate Transport Services Process Model The party acting the role of Consignor initiates the process of delivery. There are four types of documents involved in the process, namely: Forwarding Instruction Bill of Lading Waybill Packing List 5.8.1 Forwarding Instruction A Forwarding Instruction is normally used by any party who gives instructions for the transportation services required for a consignment of goods to any party who is contracted to provide the transportation services. It can also be used by any party who requests a booking of shipment space to be made for the transportation services required for a consignment of goods to any party who will provide the underlying transportation services. The parties who issue this document are commonly referred to as the shipper or consignor while the parties who receive this document are forwarders, carriers, shipping agents, etc. A Forwarding Instruction may also be issued by a freight forwarder or shipping agent in their capacity as a “shipper”. This document can be used to arrange for the transportation: of different types of goods or cargoes whether containerized or non-containerized through different modes of transport, including multi-modal, and from any origin to any destination. 5.8.2 Bill of Lading A Bill of Lading is issued by the party who provides the physical transportation services (e.g. carrier) to the party who gives instructions for the transportation services (shipper, consignor, etc.) stating the details of the transportation, charges, and terms and conditions under which the transportation service is provided. It can also be issued by the party who acts as an agent for the carrier or other agents to the party who gives instructions for the transportation services (shipper, consignor, etc.) stating the details of the transportation, charges, and terms and conditions under which the transportation service is provided but does not provide the physical transportation service. A Bill of Lading corresponds to the information on the Forwarding Instruction. It is used for ocean or river modes of transport. A Bill of Lading can serve as a contractual document between the parties for the transportation service. The document evidences a contract of carriage by sea and the acceptance of responsibility for the goods by the carrier, by which the carrier undertakes to deliver the goods against surrender of the document. A provision in the document that the goods are to be delivered to the order of a named person, or to order, or to bearer, constitutes such an undertaking. 5.8.3 Waybill A Waybill is issued by the party who provides the physical transportation services to the party who gives instructions for the transportation services (shipper, consignor, etc.). It states the details of the transportation, charges, and terms and conditions under which the transportation service is provided. Unlike a Bill of Lading, a Waybill is not negotiable and cannot be assigned to a third party. It is issued as a cargo receipt and is not required to be surrendered at the destination in order to pick up the cargo. This simplifies the documentation procedures between shipper and consignee. 5.8.4 Packing List A Packing List is normally issued by the consignor. It states the distribution of goods in individual packages. Based on this detail, the party who provides the logistic services will make arrangement for the transportation of the goods. 5.9 Certification of Origin of Goods Collaboration A Certificate of Origin (CO) is a document required by governments declaring that goods in a particular international shipment are of a certain origin. It is the responsibility of the Exporter to sign the Certificate of Origin document and apply it to a local chamber of commerce or any designated government agency/board, i.e., the Endorser and Issuer of the Certificate of Origin. The Endorser must have access to other documents such as the commercial invoice and Bill of Lading in order to verify that the Exporter claims the goods originated in that country. Finally, the issued Certificate of Origin is received by the Importer. Figure 20. Certification Of Origin Of Goods Process Model The party acting the role of Exporter initiates the process of certification of origin of goods. It is the responsibility of the party acting the role of Exporter to initiate the process by submitting an application to an authorized Issuer. 5.10 Document Types The following table lists all the documents used in each collaboration. Document Description Use case(s) involved Submitter Role Receiver Role Catalogue Request A document to request a Catalogue from a seller. May be either an entire new Catalogue or an update (at the discretion of the Seller). Create Catalogue, Update Item Specification, Update Pricing Catalogue Managing Seller Catalogue A document produced by a party in the procurement chain that describes items and prices. Create Catalogue Seller Catalogue Managing Catalogue Deletion A document to cancel an entire Catalogue. All previous Catalogue information becomes obsolete. Delete Catalogue Seller Catalogue Managing Catalogue Item Specification Update A document to update information about Items in an existing Catalogue. Update Catalogue Item Specification Seller Catalogue Managing Catalogue Pricing Update A document to update information about Prices in an existing Catalogue. Update Catalogue Pricing Seller Catalogue Managing Request For Quotation A document to request pricing and availability information about goods or services. Sourcing Originator Seller Quotation A document to specify pricing and availability information about goods or services. Sourcing Seller Originator Order A document that contains information directly relating to the economic event of ordering products. Ordering Buyer Seller Order Response A document responding to the customer to indicate detailed responses against a single Order. Ordering Seller Buyer Order Response Simple A document responding to the customer to indicate simple acceptance or rejection of the entire Order. Ordering Seller Buyer Order Change A document that contains information directly relating to the economic event of changing an Order. Ordering, Fulfilment Buyer Seller Order Cancellation A document that advises either party of the cancellation of an Order. Ordering, Fulfilment Buyer Seller Despatch Advice A document that describes the content of goods shipped. Fulfilment Despatch Delivery Receipt Advice A document that advises the goods received and accepted by the buyer. Fulfilment Delivery Despatch Invoice A document claiming payment for goods or services supplied under conditions agreed between the supplier and the customer. In most cases this document describes the actual financial commitment of goods or services ordered from the supplier. Billing Creditor Debtor Self Billed Invoice A document provided by a customer, in the name and on behalf of the supplier, describing the claim for payment for goods or services supplied under conditions agreed between the supplier and the customer. Billing Debtor Creditor Credit Note A document for a supplier to specify a reduced payment. Billing Creditor Debtor Debit Note A document for a customer to specify a reduced payment. Billing Debtor Creditor Self Billing Credit Note A document for a customer to specify a reduced payment in a Self Billing environment. Billing Debtor Creditor Statement A document to list the financial transactions between customer and supplier and notify of their status. Billing Creditor Debtor Remittance Advice A document to specify that funds have been transferred from the customer to the supplier. Payment Debtor Creditor and/or Payee Forwarding Instruction A document used by any party who gives instructions for the transportation services required for a consignment of goods to any party who is contracted to provide the transportation services. Initiate Transport Services Process Consignor, Freight Forwarder Freight Forwarder, Carrier Bill of Lading A document stating the details of the transportation, charges, and terms and conditions under which the transportation service is provided. Initiate Transport Services Process Freight Forwarder, Carrier Consignor, Freight Forwarder Waybill A document that provides information similar to Bill of Lading but is not negotiable and cannot be assigned to a third party. Initiate Transport Services Process Freight Forwarder, Carrier Consignor, Freight Forwarder Packing List A document stating the detail of how goods are packed. Initiate Transport Services Process Consignor Freight Forwarder Freight Invoice A document stating the charges incurred for the logistics service. Freight Billing Process Freight Forwarder Consignor Certificate of Origin A signed document, required by governments, declaring that goods in a particular international shipment are of a certain origin. Customs offices will use this document to determine whether or not a preferential duty rate applies on the products being imported and whether a shipment may be legally imported during a specific quota period. Certification of Origin of Goods Process Exporter, Issuer Issuer, Importer Application Response A document to indicate the application’s response to a transaction. All Sender Receiver Attached Document In effect a ’wrapper’ UBL document that can contain anything. This allows a referenced document to be included in the package of documents being exchanged. All Sender Receiver Table 6. Documents Used in Each Transaction 6 UBL 2.0 Schemas The UBL 2.0 XSD schemas are the only normative representations of the UBL 2.0 document types and library components. All of the UBL 2.0 XSD schemas are contained in the xsd/ subdirectory of the UBL 2.0 release package (see Appendix A for more information regarding the structure of the 2.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 2.0 Document Schemas XSD schemas defining the 29 UBL 2.0 document types are located in the xsd/maindoc/ directory, as listed below. ApplicationResponse xsd/maindoc/UBL-ApplicationResponse-2.xsd AttachedDocument xsd/maindoc/UBL-AttachedDocument-2.xsd BillOfLading xsd/maindoc/UBL-BillOfLading-2.xsd Catalogue xsd/maindoc/UBL-Catalogue-2.xsd CatalogueDeletion xsd/maindoc/UBL-CatalogueDeletion-2.xsd CatalogueItemSpecificationUpdate xsd/maindoc/UBL-CatalogueItemSpecificationUpdate-2.xsd CataloguePricingUpdate xsd/maindoc/UBL-CataloguePricingUpdate-2.xsd CatalogueRequest xsd/maindoc/UBL-CatalogueRequest-2.xsd CertificateOfOrigin xsd/maindoc/UBL-CertificateOfOrigin-2.xsd CreditNote xsd/maindoc/UBL-CreditNote-2.xsd DebitNote xsd/maindoc/UBL-DebitNote-2.xsd DespatchAdvice xsd/maindoc/UBL-DespatchAdvice-2.xsd ForwardingInstruction xsd/maindoc/UBL-ForwardingInstruction-2.xsd FreightInvoice xsd/maindoc/UBL-FreightInvoice-2.xsd Invoice xsd/maindoc/UBL-Invoice-2.xsd Order xsd/maindoc/UBL-Order-2.xsd OrderCancellation xsd/maindoc/UBL-OrderCancellation-2.xsd OrderChange xsd/maindoc/UBL-OrderChange-2.xsd OrderResponse xsd/maindoc/UBL-OrderResponse-2.xsd OrderResponseSimple xsd/maindoc/UBL-OrderResponseSimple-2.xsd PackingList xsd/maindoc/UBL-PackingList-2.xsd Quotation xsd/maindoc/UBL-Quotation-2.xsd ReceiptAdvice xsd/maindoc/UBL-ReceiptAdvice-2.xsd RemittanceAdvice xsd/maindoc/UBL-RemittanceAdvice-2.xsd RequestForQuotation xsd/maindoc/UBL-RequestForQuotation-2.xsd SelfBilledCreditNote xsd/maindoc/UBL-SelfBilledCreditNote-2.xsd SelfBilledInvoice xsd/maindoc/UBL-SelfBilledInvoice-2.xsd Statement xsd/maindoc/UBL-Statement-2.xsd Waybill xsd/maindoc/UBL-Waybill-2.xsd 6.2 UBL Common Schemas The xsd/common directory contains schemas referenced by the 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 CommonBasicComponents xsd/common/UBL-CommonBasicComponents-2.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. BBIEs are the “leaf nodes” of UBL documents. CommonAggregateComponents xsd/common/UBL-CommonAggregateComponents-2.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 CCTS_CCT_SchemaModule xsd/common/CCTS_CCT_SchemaModule-2.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 is defined by UN/CEFACT and should not be modified. UnqualifiedDataTypeSchemaModule xsd/common/UnqualifiedDataTypeSchemaModule-2.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 is defined by UN/CEFACT and should not be modified. QualifiedDatatypes xsd/common/UBL-SpecializedDatatypes-2.xsd This schema provides Qualified Data Types as defined by [CCTS]. These XSD complexType structures are derived from Unqualified Data Types by extension, restriction, and other contextual constraints, such as facets. The Qualified Datatypes have been customized for UBL and may be further extended to support additional datatypes required for other business contexts. 6.2.3 Documentation Metadata Schema CoreComponentParameters xsd/common/UBL-CoreComponentParameters-2.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 Imported Code List Schemas Four standard code list schemas used in UBL 2.0 are included in the xsd/common directory. See Appendix C for further information about the structure and form of representation used for UBL code lists. CodeList_CurrencyCode xsd/common/CodeList_CurrencyCode_ISO_7_04.xsd CodeList_LanguageCode xsd/common/CodeList_LanguageCode_ISO_7_04.xsd CodeList_MIMEMediaTypeCode xsd/common/CodeList_MIMEMediaTypeCode_IANA_7_04.xsd CodeList_UnitCode xsd/common/CodeList_UnitCode_UNECE_7_04.xsd 6.4 Schema Dependencies The following diagram shows the dependencies among the schema modules comprising a UBL 2.0 document schema. Figure 21. 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 current working draft of the UBL 2.0 specification is published as a zip archive named wd-UBL-2.0.zip. Unzipping this archive creates a directory named wd-UBL-2.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 2.0 release. A description of each subdirectory is given below. art/ Diagrams and illustrations used in this specification mod/ Spreadsheet data models; see Appendix B xsd/ XSD schemas; see Section 6 xsdrt/ “Runtime” XSD schemas; see Section 6 A.3 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.4 Known Issues As the purpose of this release is to gain early input from interested parties, the focus has been on exposing the UBL 2.0 data models and derived schemas rather than achieving perfection in editorial aspects of the specification. The present draft therefore exhibits the imperfections that would be expected at this stage of development. A list of known issues will be made available from the UBL TC web site during the public review period. See Appendices C and D below for known issues regarding code lists and the UBL Naming and Design rules. Appendix B (Informative): UBL 2.0 Assembly Models UBL assembly models are expressed using UML Class Diagrams and spreadsheets. Class Diagrams are provided as useful guides to the overall UBL structures. They follow the UML profile currently under development for the UN/CEFACT Business Collaboration Schema Specification. To assist in migrating from UBL 1.0 to UBL 2.0, these diagrams use pink boxes to represent ABIEs that existed in UBL 1.0 and red lines for ASBIEs that existed in UBL 1.0. BBIEs that existed in UBL 1.0 are marked with a "#" symbol. An XMI copy of the UBL 2.0 UML model will be provided as part of the UBL 2.0 Support Package. Spreadsheets provide the supplementary metadata required by [CCTS]. Their format has been developed by UBL and extends the spreadsheet format used for UBL 1.0. They are provided in Open Document (ods) format as well as proprietary xls format. The OASIS Open Document Format for Office Applications (OpenDocument) is supported by OpenOffice, a free multiplatform, multilingual, open-source office suite. UBL spreadsheet models can be used to generate XML Schemas using the EDIFIX software tool from GEFEG. B.1 Library Assembly Model UBL has been designed as a re-usable library of Aggregate Business Information Entities. To aid readability, this library has been separated into three parts: A Common Library containing ABIEs used throughout the various document types. A Procurement Library containing ABIEs used mainly for the document types associated with buying and selling. A Transportation Library containing ABIEs used mainly for the document types associated with the transportation of goods. Common Library Common Library Class Diagram mod/lib/UBL-CommonLibrary-2.ods mod/lib/UBL-CommonLibrary-2.xls Procurement Library Procurement Library Class Diagram mod/lib/UBL-ProcurementLibrary-2.ods mod/lib/UBL-ProcurementLibrary-2.xls Transportation Library Transportation Library Class Diagram mod/lib/UBL-TransportationLibrary-2.ods mod/lib/UBL-TransportationLibrary-2.xls B.2 Document Assembly Models Every UBL 2.0 document assembly model contains the 'root' ABIE for the document. This itself contains several BBIEs (individual pieces of information) and ASBIEs (associations to other ABIEs in one of the three libraries). This creates the hierarachical structure necessary to represent an XML document schema. Application Response Application Response Class Diagram mod/maindoc/UBL-ApplicationResponse-2.ods mod/maindoc/UBL-ApplicationResponse-2.xls Attached Document Attached Document Class Diagram mod/maindoc/UBL-AttachedDocument-2.ods mod/maindoc/UBL-AttachedDocument-2.xls Bill Of Lading Bill Of Lading Class Diagram mod/maindoc/UBL-BillOfLading-2.ods mod/maindoc/UBL-BillOfLading-2.xls Catalogue Catalogue Class Diagram mod/maindoc/UBL-Catalogue-2.ods mod/maindoc/UBL-Catalogue-2.xls Catalogue Deletion Catalogue Deletion Class Diagram mod/maindoc/UBL-CatalogueDeletion-2.ods mod/maindoc/UBL-CatalogueDeletion-2.xls Catalogue Item Specification Update Catalogue Item Specification Update Class Diagram mod/maindoc/UBL-CatalogueItemSpecificationUpdate-2.ods mod/maindoc/UBL-CatalogueItemSpecificationUpdate-2.xls Catalogue Pricing Update Catalogue Pricing Update Class Diagram mod/maindoc/UBL-CataloguePricingUpdate-2.ods mod/maindoc/UBL-CataloguePricingUpdate-2.xls Catalogue Request Catalogue Request Class Diagram mod/maindoc/UBL-CatalogueRequest-2.ods mod/maindoc/UBL-CatalogueRequest-2.xls Certificate Of Origin Certificate Of Origin Class Diagram mod/maindoc/UBL-CertificateOfOrigin-2.ods mod/maindoc/UBL-CertificateOfOrigin-2.xls Credit Note Credit Note Class Diagram mod/maindoc/UBL-CreditNote-2.ods mod/maindoc/UBL-CreditNote-2.xls Debit Note Debit Note Class Diagram mod/maindoc/UBL-DebitNote-2.ods mod/maindoc/UBL-DebitNote-2.xls Despatch Advice Despatch Advice Class Diagram mod/maindoc/UBL-DespatchAdvice-2.ods mod/maindoc/UBL-DespatchAdvice-2.xls Forwarding Instruction Forwarding Instruction Class Diagram mod/maindoc/UBL-ForwardingInstruction-2.ods mod/maindoc/UBL-ForwardingInstruction-2.xls Freight Invoice Freight Invoice Class Diagram mod/maindoc/UBL-FreightInvoice-2.ods mod/maindoc/UBL-FreightInvoice-2.xls Invoice Invoice Class Diagram mod/maindoc/UBL-Invoice-2.ods mod/maindoc/UBL-Invoice-2.xls Order Order Class Diagram mod/maindoc/UBL-Order-2.ods mod/maindoc/UBL-Order-2.xls Order Cancellation Order Cancellation Class Diagram mod/maindoc/UBL-OrderCancellation-2.ods mod/maindoc/UBL-OrderCancellation-2.xls Order Change Order Change Class Diagram mod/maindoc/UBL-OrderChange-2.ods mod/maindoc/UBL-OrderChange-2.xls Order Response Order Response Class Diagram mod/maindoc/UBL-OrderResponse-2.ods mod/maindoc/UBL-OrderResponse-2.xls Order Response Simple Order Response Simple Class Diagram mod/maindoc/UBL-OrderResponseSimple-2.ods mod/maindoc/UBL-OrderResponseSimple-2.xls Packing List Packing List Class Diagram mod/maindoc/UBL-PackingList-2.ods mod/maindoc/UBL-PackingList-2.xls Quotation Quotation Class Diagram mod/maindoc/UBL-Quotation-2.ods mod/maindoc/UBL-Quotation-2.xls Receipt Advice Receipt Advice Class Diagram mod/maindoc/UBL-ReceiptAdvice-2.ods mod/maindoc/UBL-ReceiptAdvice-2.xls Remittance Advice Remittance Advice Class Diagram mod/maindoc/UBL-RemittanceAdvice-2.ods mod/maindoc/UBL-RemittanceAdvice-2.xls Request For Quotation Request For Quotation Class Diagram mod/maindoc/UBL-RequestForQuotation-2.ods mod/maindoc/UBL-RequestForQuotation-2.xls Self Billed Credit Note Self Billed Credit Note Class Diagram mod/maindoc/UBL-SelfBilledCreditNote-2.ods mod/maindoc/UBL-SelfBilledCreditNote-2.xls Self Billed Invoice Self Billed Invoice Class Diagram mod/maindoc/UBL-SelfBilledInvoice-2.ods mod/maindoc/UBL-SelfBilledInvoice-2.xls Statement Statement Class Diagram mod/maindoc/UBL-Statement-2.ods mod/maindoc/UBL-Statement-2.xls Waybill Waybill Class Diagram mod/maindoc/UBL-Waybill-2.ods mod/maindoc/UBL-Waybill-2.xls Appendix C (Informative): UBL 2.0 Code Lists The code list mechanism used in UBL 1.0 is being completely revised for UBL 2.0. That revision is not yet complete as of the initial UBL 2.0 review cycle (January 2006). In particular, enumerated values for some of the code lists "hardwired" in UBL 2.0 are missing from this initial review; as a result, incorrect values for these code lists appearing in document instances will not be caught in XSD validation at this stage, though this should not affect the utility of the draft document schemas. A brief description of the new code list mechanism will be included in this appendix following the initial public review, and a complete description of its use will be included in the UBL 2.0 Support Package following release of UBL 2.0 as an OASIS Standard. Appendix D (Informative): UBL 2.0 Naming and Design Rules The XML Naming and Design Rules (NDRs) used in creating the UBL schemas in this draft specification are complete but have not yet been incorporated into a document suitable for publication. The final NDR document will be released as part of UBL 2.0 publication. Appendix E: Notices Copyright © 2001-2005 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. UBL-Waybill-2.xls UBL-AttachedDocument-2.xls UBL-BillOfLading-2.xls UBL-Catalogue-2.xls UBL-CatalogueDeletion-2.xls UBL-CatalogueItemSpecificationUpdate-2.xls UBL-CataloguePricingUpdate-2.xls UBL-CatalogueRequest-2.xls UBL-CertificateOf Origin-2.xls UBL-CommonLibrary-2.xls UBL-CreditNote-2.xls UBL-DebitNote-2.xls UBL-DespatchAdvice-2.xls UBL-ForwardingInstruction-2.xls UBL-FreightInvoice-2.xls UBL-Invoice-2.xls UBL-Order-2.xls UBL-OrderCancellation-2.xls UBL-OrderChange-2.xls UBL-OrderResponse-2.xls UBL-OrderResponseSimple-2.xls UBL-PackingList-2.xls UBL-ProcurementLibrary-2.xls UBL-Quotation-2.xls UBL-ReceiptAdvice-2.xls UBL-RemittanceAdvice-2.xls UBL-RequestForQuotation-2.xls UBL-SelfBilledCreditNote-2.xls UBL-SelfBilledInvoice-2.xls UBL-Statement-2.xls UBL-TransportationLibrary-2.xls UBL-ApplicationResponse-2.xls [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
← Prev in month
← Prev in thread
Next in thread →
Next in month →