IDA E-PROCUREMENT PROTOCOL XML SCHEMAS INITIATIVE

Transcription

1 IDA E-PROCUREMENT PROTOCOL XML SCHEMAS INITIATIVE E-ORDERING AND E-INVOICING PHASES

2 Version R0.3, January / 82

3 Disclaimer "The views expressed in this document are purely those of the writer and may not, in any circumstances, be interpreted as stating an official position of the European Commission. The European Commission does not guarantee the accuracy of the information included in this study, nor does it accept any responsibility for any use thereof. Reference to any specific products, specifications, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favouring by the European Commission. Every care has been taken by the author to ensure that he has obtained, where necessary, permission to use any parts of manuscripts including illustrations, maps, and graphs, on which intellectual property rights already exist from the titular holder(s) of such rights or from his or their legal representative." Copyright: European Communities / 82

4 TABLE OF CONTENTS 1 Introduction Context Scope Methodology overview Document structure Business requirements Scope Definition Introduction Actors Use cases The Ordering process The fulfilment process The accounting process Information Model Introduction General principles and assumptions Generic rules Documents and lines References between business documents and lines UML notation Package description The Datatypes package The Document package The Line package The Item package The Party package Purchase order PO response PO change / 82

5 3.14 Despatch Advice Receipt advice Rectification advice Invoice Invoice response Credit note Remittance advice Extending the IDA e-procurement model Gap with UBL Gap with ehandel Gap with OGC Appendix 1: Issues and decisions made Appendix 2: UML to XML schemas conversion rules Appendix 3: XML schemas design guidelines Naming conventions Namespace Versioning Use of Data types definition Use of attributes Multilingual content Extension mechanism Schema documentation elementformdefault and attributeformdefault Appendix 4: Acronyms Appendix 5 : Country Code ISO / 82

6 1 INTRODUCTION 1.1 CONTEXT Public eprocurement has been identified as one of the priorities in the eeurope initiative to enable electronic business interoperability between enterprises and public administrations, and to create a more dynamic and trans-national market. A legislative framework for electronic public procurement procedures has been established by the new public procurement Directives 1. In the public procurement area, interactive services have been identified as key to reducing borders and contributing to the enforcement of the single European Market and the competitiveness of European businesses. IDA (now IDABC 2 ) is a European programme using information and communication technologies to support exchange of information between administrations. Its objective is to improve Community decision-making, facilitate operation of the internal market and accelerate policy implementation. Therefore, IDA has undertaken in 2003 and 2004 a study in order to define and promote pan-european guidelines for data exchange in the public e-procurement domain 3, using common and standard data description syntax - XML schemas. This study is in line with the new legislative framework for electronic public procurement in the European Union. The four first phases of e-procurement that are covered by this study are the following: e-ordering and e-invoicing (present document); e-tendering and e-awarding. 1.2 SCOPE The scope of this document is the specification of business documents exchanged between a public sector buyer and an external supplier during the ordering and invoicing phases, from the phase of ordering through to remittance. It covers any type of purchase made in the public sector, ie supplies, services or works. The specification has been greatly inspired from the OGC model developed by the Office of Government Commerce in the UK, the ehandel model developed in Norway and the UBL standard edited by OASIS. It describes business processes involved and data models using UML diagrams. This document includes in appendix a gap analysis between the three models indicated above and the one we herein propose. Many projects or standards (EDIFACT, X12, Rosettanet, UBL and other national, regional or industryspecific initiatives) have developed electronic order and invoice messages. All the message definitions are very similar in essence but all have significant differences. The gap is usually due to different decisions as regards recurring questions or issues that arose during the process of designing them. For this reason, a dedicated section (8. Appendix 1: Issues and decisions madeappendix 1: Issues and decisions made, page 67) lists issues and decisions made. This section ensures traceability and subsequently eases understanding of the IDA e-procurement model as well as maintaining it / 82

7 Note: Although an implementation of the proposed model in the form of a set of XML schemas is also provided, the model (processes and information model) does not rely on XML. It could therefore be implemented using a different technology such as ASN1 for example. 1.3 METHODOLOGY OVERVIEW The methodology used is based on: The description of the business requirements by modelling business processes and business documents exchanged between parties; The conversion of the UML data model into XML schemas using conversion rules. The specification cycle, based on a bottom-up approach, relied heavily upon existing work, namely: The OGC model 4 developed by the Office of Government Commerce in the UK; The ehandel 5 model developed by the ehandel project led in Norway; The UBL (v0.7 and v1.0 beta) model edited by OASIS. UBL is used in Denmark 6 UBL, new e-business standard edited by OASIS with a similar scope, was not taken as-is for the following reasons: Needs and requirements specific to Europe and the public sector have to be addressed; At the time we started the study UBL was still under development (v1.0 was not released yet); There is no certainty that UBL will be widely adopted. To a lesser extent, the model, when necessary, was compared to the corresponding Rosettanet PIPs. The Invoice business document has also been checked against the Finvoice DTD developed and widely used in Finland. The final report from the CEN e-invoicing focus group and the European directive 2001/115/CE were also taken into account for the design of the Invoice business document. Although the IDA specification is based on three existing models, which comply with their national regulations (UBL being in fact a world-wide standard), an exhaustive study against all applicable national regulations and practices has not been carried out. At European level, the new public procurement directives (2004/18/EC and 2004/17/EC) and the invoicing (2001/115/EC) directive have been taken into consideration. 1.4 DOCUMENT STRUCTURE This document is structured as follows: Business Requirements: define the business processes and identify business documents exchanged; Information model: describes the data composing business documents using UML class diagrams; Gap with UBL: summarises the differences between UBL 1.0 beta and the IDA e-procurement model Gap with ehandel: summarises the differences between the ehandel model and the IDA e-procurement model; Gap with OGC: lists the differences between the OGC model and the IDA e-procurement model; Issues and decisions made: lists questions and issues encountered as well as decisions made; 4 eprocurement Functional Requirements Specification, v3.0b. 5 Platform independent model activity model (dated 2002/10/15) and information model (dated 2002/10/16) / 82

8 UML to XML schemas conversion rules: describes the rules that enable the generation of XML schemas from the UML class diagrams; XML schema design guidelines: indicate the design rules applied in the design of XML schemas. 8 / 82

9 2 BUSINESS REQUIREMENTS 2.1 SCOPE The scope of this model is the specification of business documents exchanged between a public sector buyer within Europe and an external supplier in the procurement cycle from the phase of ordering through to remittance. It covers any type of purchase made in the public sector: supplies, services or works. The business documents are specified for implementation as XML documents, exchanged between buyers and sellers. The business document structure is defined by an (W3C) XML schema. Processes internal to the buyer and seller parties are not in the scope of our model. The following aspects of procurement are beyond the scope: Search for Supplier; Sourcing; Communication with third parties and intermediaries such as carriers, trusted third parties service providers (for time-stamping, managing of digital certificates or archiving), banks or fiscal authorities; Messaging transport (SMTP, HTTP, SOAP, ebms, etc.) and security DEFINITION A business document is a unit of business information exchanged in a business transaction. An (information) component is a collection of data making a coherent whole (such as Address, Party, ContactInformation). A reusable component is an information component that, although it does not correspond to a business document as such, it is (or is likely to be) used in different business documents. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC as quoted here: 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. Bradner Best Current Practice 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides) 7 Apart from an optional signature element attached to each business document. 9 / 82

10 2.3 INTRODUCTION This section describes the functional requirements of the e-procurement cycle as described above by defining: Actors involved in the different processes necessitating an exchange of data; Business processes described by UML diagrams. 2.4 ACTORS The two main actors considered in our model are: The (public sector) buyer: the party that buys goods, services or works; The supplier (also called seller): the economic operator that supplies goods/services or works to the buyer. All processes (and subsequent information exchange) internal to either the buyer party or the supplier party are outside the scope of our model. Nevertheless, we have identified, for clarity purposes, particular roles within the two parties that are involved in the processes hereafter described. These roles are as follows: Buyer: Order Point: buyer party for issues related to purchase orders; Delivery Point: buyer party that receives goods/works/services and identifies variances in receipt; Invoice Point: buyer party for payment-related issues. Supplier: Sales Point: supplier party responsible for purchasing issues prior to fulfilment of Purchase Order. Despatch Point: supplier party responsible for the delivery of goods; Customer Service: supplier party responsible for issues related to purchase order fulfilment (despatch, delivery and carriage); Accounts Receivable: supplier party for payment-related issues; Tax Representative: supplier party responsible for keeping VAT records and accounts for taxable transactions in another Member State. 10 / 82

11 Buyer Order Point Delivery Point Invoice Point Supplier Sales Point Despatch Point Customer Service Accounts Receivable Tax Representative UML presentation of roles 2.5 USE CASES Use cases define specific functions that necessitate electronic data exchange covered by our model 8. The functions covered by our model are: Ordering: the buyer notifies a supplier of his intention to buy goods, services or works; Fulfilment: the supplier organises the delivery of the products ordered (goods, services or works) by the buyer; Accounting: the supplier sends the buyer an invoice corresponding to previously ordered and delivered goods, services or works. 8 Note that in our case we are not designing a software application but rather a set of messages (or business documents). 11 / 82

12 Buyer Supplier Order Order Point Sales Point Fulfil Despatch Point Buyer Delivery Point Supplier Customer Service Accounting Invoice Point Accounts Receivable Use case diagram 2.6 THE ORDERING PROCESS The ordering process starts with the preparation of the purchase order by the buyer. The purchase order is sent to the supplier that receives the order. The order is accepted, rejected or accepted with changes by the supplier. Depending on trading agreements and/or applicable legislations: An order may be cancelled or changed at any moment by the buyer by sending a Purchase order change document (PO Change); in this case, the supplier has to go through the process of acceptance of the order and send a Purchase order response document (PO Response) to the buyer; The supplier may change an order that he has already replied to (with a previous PO Response) by sending a new PO Response. 12 / 82

13 Buyer Supplier Complete Purchase order Send purchase Order Purchase Order Receive order PO Response Reject order Receive Response PO Response Accept order PO Response Accept with changes Buyer Supplier Receive Response PO Response Send changes In PO Response Activity diagram for the Purchase order process Buyer Wishes to change a previous order Supplier Complete Change order Send Change Order PO Change Receive Change order PO Response Reject Order change Receive Response PO Response Accept order change PO Response Accept with changes Buyer Supplier Complete Cancellation order Wishes to cancel a previous order Send Cancellation Order PO Change Receive Cancellation order Activity diagram for the Change and Cancel order process 13 / 82

14 Business document Purchase Order PO Response (for Purchase order response) PO Change (for Purchase order change) Description Sent by the buyer to the supplier to inform him that he wishes to purchase goods, services or works. Sent by the supplier to the buyer (who has previously sent him an order) to accept the order fully or partially or to reject the order. Sent by the buyer to the supplier to inform him that he wishes to modify or cancel a previous order. 2.7 THE FULFILMENT PROCESS The delivery process starts when the supplier dispatches the goods or services to the buyer. He sends a dispatch advice to inform the buyer. When the goods or services are actually delivered, the buyer checks the delivery (in terms of quantity and quality) and sends a receipt advice in order to acknowledge the receipt in full or in part and notify when necessary of under/over-delivery, error or damage in the delivery. If the receipt advice contains variances, the supplier can send a rectification advice to the buyer to inform him of the corrective action to be taken. Buyer Supplier Dispatch Ordered items Receive Dispatch Advice Despatch Advice Send Fulfilment Notification Wait for delivery Check delivery Deliver Ordered Items Send Receipt advice Receipt Advice Receive Receipt adive Receive Rectification advice Rectification Advice Send rectification Advice Activity diagram for the fulfilment process Business document Despatch Advice Receipt Advice Rectification Advice Description Sent by the supplier to the buyer to inform him that goods or services have been dispatched and/or delivered. Sent by the buyer to the supplier to acknowledge receipt in full or in part and notify when necessary of under/over-delivery, error or damage in the delivery. Sent by the supplier to inform the buyer of the action to be taken as regards as variances notified in the receipt advice. 14 / 82

15 2.8 THE ACCOUNTING PROCESS A supplier sends an invoice to the buyer as a request for payment related to the provision of goods, services or works. The buyer reconciles receipt advice, order and invoice and MAY either: Authorise payment: in that case, he notifies the payment by sending a remittance advice to the supplier; In case of discrepancy, notifies the supplier by the sending of an Invoice Response describing the reason. Should the invoice amount be superior to the amount actually due, the supplier sends a Credit note to balance the invoice. If the invoice amount is inferior to the amount due by the buyer, the supplier sends a new invoice for the difference. Not that in some cases (in particular with particular payment means) not illustrated in our diagram, the invoice MAY be sent after payment is made. Buyer Supplier Reconcile Invoice, Order & Receipt advice Invoice Send Invoice [Invoice not OK] [Invoice OK] Authorise payment Notify payment Remittance Advice Receive Remittance advice Notify discrepancy Invoice Response Review response [Invoice > PO] [Invoice < PO] Receive credit note Credit Note Send credit note Activity diagram for the accounting process Business document Invoice Remittance Advice Invoice Response Credit Note Description Sent by the supplier to the buyer to request for payment for goods, services or works. Sent by the buyer to the supplier to notify payment. Sent by the supplier to the buyer in response to an invoice to inform him of discrepancies in the invoicing process. Sent by the supplier to the buyer confirming that the supplier owes him money. 15 / 82

16 3 INFORMATION MODEL 3.1 INTRODUCTION This section defines the Information Model for the different business processes that are described in the previous section. The Information Model is composed of: A set of 5 reusable components, organised into packages, that are involved in the different business messages: o Document; o Line; o Item; o Party; o Data type; A Message Model that describes the 10 business documents identified in the business process description (2. Business requirements, page 9): o PurchaseOrder; o POResponse (PurchaseOrderResponse); o POChange (PurchaseOrderChange); o DespatchAdvice; o ReceiptAdvice; o RectificationAdvice; o Invoice; o InvoiceResponse; o CreditNote; o RemittanceAdvice. For each UML diagram, all classes and attributes are listed and defined, with: The name of the attribute, A description of the attribute, The data type of the attribute, The cardinality of the attribute (whether it is mandatory or not): 0..1 means the attribute is optional (it may have no value); 1..1 means the attribute is mandatory (it must have a value). 3.2 GENERAL PRINCIPLES AND ASSUMPTIONS Combination of paper and electronic exchanges: any business transaction can be through electronic means even if other business transactions in the same procurement cycle are carried out through paper. In some cases, a business document may also be sent by electronic means to a third party that will send a paper copy to the final recipient or vice-versa. Simplicity: the model should be simple in order to facilitate its adoption by Small and Medium-sized Enterprises (SMES). To ensure that the IDA model remain simple enough, we decided to apply the following rule: In order for a piece of information to be added to the model: Someone should provide a well defined business case where this information is necessary and used AND It should be proven that this information could be processed automatically in a reliable manner and that this represents an important benefit 9. 9 Otherwise, this information can be, when required, added to the free text notes attributes at either document or line level. 16 / 82

17 Clarity and Explicitness: other well-known B2B standards make heavy use of complex rules in order to interpret the content of a business document. For example, standards like xcbl or RosettaNet frequently use default attributes (like currency, exchange rates, etc.) defined at document level that can be overridden at line-level. We decided that all information should be specified explicitly should it be repeated several times. The reason behind this is that this simplifies automatic processing and makes the business documents more human-readable and less ambiguous. For clarity purposes, all business documents should as far as possible contain all pertinent information (reiteration of items ordered, parties involved, etc.). We thereby ensure that each business document is selfsufficient in interpreting it. Traceability: many projects or standards (EDIFACT, X12, Rosettanet, UBL and other national, regional or industry-specific initiatives) have developed electronic orders and invoicing messages. All the message definitions are very similar in essence but all have significant differences. The gap is usually due to different decisions as regards recurring questions or issues that arose during the process of designing them. For this reason, a dedicated section of this document lists issues and decisions made. This section ensures traceability and subsequently eases understanding of the IDA e-procurement model as well as maintaining it. 3.3 GENERIC RULES DOCUMENTS AND LINES All information exchanged between buyer and supplier shown on the UML diagrams in 2. Business requirements constitute a business document. Each of the business documents mentioned above corresponds to a class (called Business document class) with the same name in the document package. All business documents classes are a specialisation of the Document class. All business documents MUST have a document identifier so it can be referenced to later in the procurement cycle. All business documents are composed of specific types of lines (class named <BusinessDocument>Line, i.e. PurchaseOrderLine, InvoiceLine, etc.). Each specific line class is a specialisation of the Line class. All business documents MAY carry a digital signature. All Lines MUST have an identifier, unique within the Document it belongs to, so that it can be referenced to later in the procurement cycle. A line MUST be identified with a pair of attributes corresponding to a Line identifier AND a Document identifier. All business document class specifies at least one buyer party (OrderPoint, DeliveryPoint, InvoicePoint) and one supplier party (SalesPoint, AccountsReceivable, CustomerService, DespatchPoint). The response documents (POResponse, InvoiceResponse) repeats all the information (amended when necessary) of the business document it replies to (respectively PurchaseOrder and Invoice) REFERENCES BETWEEN BUSINESS DOCUMENTS AND LINES When a paper business document has to be referred to by an electronic one it simply specifies the identifier given on the paper document. In order, to participate efficiently in an electronic procurement cycle, a paper document has to explicitly specify a unique 10 identifier. 10 Unique at least within all business documents exchanged with the other party. 17 / 82

18 When referring to a line of a paper business document, the position of the line (from the top of the document starting from 1) as it appears on paper should be used. In an ideal case, the lines of all the business documents from PurchaseOrder to Invoice would match exactly: What was ordered (PurchaseOrder business document) was accepted by the supplier (POResponse) then delivered (DespatchAdvice) to the buyer, received and accepted by him (ReceiptAdvice) and finally invoiced (Invoice) by the supplier to the buyer. For the sake of readability and visual matching, we recommend that business documents, when referring to lines from previous business documents use the same order. 3.4 UML NOTATION The information model specification relies on UML class diagrams showing a group of classes and the relationships between them. To understand this specification, it is therefore necessary to have a basic knowledge of the concepts and notation used in UML and in particular in class diagrams. The following diagram serves as a legend for all the class diagrams given hereafter: PricedItem +unitprice Specialisation/Inheritance: the Item class is specialisation of (or inherits from) the class PricedItem Is made by 0..* Item Is a +itemname +unitofmeasure +itemdescription +selleritemid +gtin +commodityclass Attribute definition: unitofmeasure is an attribute of the class Item. Class definition Manufacturer +name +address Aspect includes 1..* +aspectname +aspectvalue +aspectvalueunit Relationship: there is a relationship Is made by between an Item and a Manufacturer. Its cardinality is 0..* meaning that there MAY be no Manufacturerfor an Item and there MAY also be several. An aggregation (hollow diamond) is a special kind of relationship recording that an object of one class (class Aspect here) is part of an object of the other (class Item here). A composition (solid diamond) is a special kind of aggregation where the part cannot exist independently of the whole. 3.5 PACKAGE DESCRIPTION The model is organised into 5 different packages: Document package, containing general information related to any document as well as pricing, charges, discounts and taxes; Line package, containing general information related to any line as well as pricing and exchange rate data; Item package, containing general information about sold items; 18 / 82

19 Party package, containing information (party and contact person details, addresses and bank data) concerning each party; Datatypes package, containing the data types used throughout the whole model. The package diagram of the global UML model is illustrated below. Arrows designate the references between packages. The Datatypes package is used by all other packages 11. Document Line Party Item Datatypes 3.6 THE DATATYPES PACKAGE Data types correspond to UBL/Core components data types and representation terms. They have been completed with other ones (URI, DigitalSignature and CountryCode). The following picture shows 12 the different data types used in the model: 11 In order to simplify the package diagram, arrows between all the packages to th Datatypes package are not shown. 12 The definition of the different attributes is given in the ebxml Core Components technical specifications. 19 / 82

20 +content +content +listid +listagencyid +listagencyname +listname +listversionid +name +languageid +listuri +listschemeuri +content Amount +currencyid +codelistversionid +schemeid +schemename +schemeagencyid +schemeagencyname +schemeversionid +schemedatauri +schemeuri Code Identifier DateTime +content Date +content Numeric +content +content Measure +unitcode +unitcodelistversionid +content +languageid +content Text DigitalSignature +content +code +content +unitcode +unitcodelistid +unitcodelistagencyid +unitcodelistagencyname URI Country Quantity Data type Amount Code DateTime Date Identifier Measure Numeric Quantity Text URI Description A number of monetary units specified in a currency where the unit of the currency is explicit or implied A character string (letters, figures, or symbols) that for brevity and/or language independence may be used to represent or replace a definitive value or text of an attribute together with relevant supplementary information. A particular point in the progression of date & time together with the relevant supplementary information A particular point in the progression of date together with the relevant supplementary information A character string to identify and distinguish uniquely, one instance of an object in an identification scheme from all other objects in the same scheme together with relevant supplementary information A numeric value determined by measuring an object along with the specified unit of measure Numeric information that is assigned or is determined by calculation, counting, or sequencing. It does not require a unit of quantity or unit of measure A counted number of non-monetary units possibly including fractions along with the specified unit of quantity A character string (i.e. a finite set of characters) generally in the form of words of a language Uniform Resource Identifier DigitalSignature A digital signature of a document. Content correspond to W3C XML Signature. The ISO country code along with the optional name of the related country (cf. Appendix Country 5) 20 / 82

21 International code lists used in the model: Code type International code list Country ISO (cf. Appendix 5) Currency ISO 4217 Delivery terms UN/EDIFACT No 5 Language ISO 639 Payment method UN/ECE N 17 Unit of Measure UN/ECE N 20 Commodity class UNSPSC, CPV, ecl@ss 3.7 THE DOCUMENT PACKAGE The Document Package UML class diagram is illustrated below. DespatchAdvice Document +documentid +documentdate +documentnote +digitalsignature May have 0..* Attachment +attachment +filename +description +size +MIMEType ReceiptAdvice RectificationAdvice OrderPaymentDocument +contractref +paymenttmethod +settlementterms +termsconditions +paymentschedule RemittanceAdvice ExchangeCurrency +targetcurrencycode +basecurrencycode +targettobaserate +exchangeratedate +exchangeratesource 0..1 PricedDocument +documenttotal +netdocumenttotal +chargestotal +discountstotal May have 0..* TaxTypeTotal +taxtypetotal StandardTaxData +taxtype +taxband +taxpercent 1..1 PurchaseOrder POResponse POChange Invoice InvoiceResponse CreditNote A specific section is dedicated to the description of each business document class. Attribute Description Type Cardinality Document This class contains general information which allows identifying documents documentid The document identifier in the sender's system Identifier 1..1 documentdate Date & time when the document has been issued DateTime 1..1 documentnote Free text note on document Text 0..1 digitalsignature The digital signature for the whole of the document payload Signature 0..1 OrderPaymentDocument This class is a specialisation of Document that contains common data used in e-procurement 21 / 82

22 Attribute Description Type Cardinality processes contractref The reference to the contract that governs the transaction Text 0..1 paymentmethod The method that will be used for payment. Values list: Cheque, Direct debit, Standing Order, BACS, SWIFT, Promissory note, Letter of credit, Cash, Cash on delivery, Credit card, Debit card, Charge card, Pre-paid Code 0..1 settlementterms termsconditions Free text that describes the terms of the document for the payment of the invoice Text 0..1 Free text (or even a URL) that describes the terms & conditions (excluding delivery terms) related to the document Text 0..1 paymentschedule Free text describing the payment schedule of the transaction Text 0..1 PricedDocument This class is a specialisation of Document that contains financial data relating to document including gross and net total, charges and discount amounts documenttotal The total of the document, including charges, discounts and taxes when appropriate Amount 1..1 netdocumenttotal The net total of the document, before charges, discounts and taxes when appropriate Amount 1..1 chargestotal The total amount for all charges, if any Amount 0..1 discountstotal The total amount for all discounts Amount 0..1 Attachment This class allows attaching files (images, PDFs, ) or URL to a document or a line attachment Attached files or URLs URI 1..1 description Free text describing the purpose of the attachments to which it refers Text 0..1 filename File name of the attached file Text 1..1 MIMEType MIME type of the attached file Code 0..1 size Size of the related attachment Measure 0..1 TaxTypeTotal This class contains the total amount for a specific tax type of a document taxtypetotal Total amount for a specific tax type (at specified band or percentage) Amount 1..1 StandardTaxData This class contains the detailed information when considering tax of a document or of a line taxtype Type of tax (e.g. VAT). Mandatory if taxtypetotal exists Code 1..1 taxband Band of tax. Values list: Standard, Zero-rated, Exempt, Reduced Code 0..1 taxpercent Percentage of tax Percent 1..1 ExchangeCurrency This class contains information relating to exchange currency used at Document level targetcurrencycode The target currency ISO code of the document Code 1..1 basecurrencycode The operational and original currency ISO code of the document Code 1..1 targettobaserate The exchange rate that is used Rate 1..1 exchangeratedate The date upon which the exchange rate is set DateTime 0..1 exchangeratesource The source of the exchange rate data Text / 82

23 3.8 THE LINE PACKAGE Lines are components of a document (which may contain one or several ones). A business document, except for RemittanceAdvice, is composed of either PricedLine or ItemLine. A PricedLine corresponds to a quantity of only one Item indicating all relevant pricing information (including taxes, charges and discounts). ItemLines are used by business documents related to the delivery process (DespatchAdvice, ReceiptAdvice, RectificationAdvice). They correspond to a quantity of only one Item (without mentioning pricing information) and may specify information (serial number, batch number, etc.) related to specific ItemInstances. Note that sub lines are not supported. The Line Package UML class diagram is illustrated below. Line +lineid +linenote May have 0..* Attachment (from document) QuantifiedLine +linequantity LineTax +linetax 0..* May have StandardTaxData (from document) PricedLine +totallinevalue +netlinevalue +chargeslinevalue +discountslinevalue ItemLine 0..* ItemInstance (from item) PricedItem (from item) Item (from item) Attribute Description Type Cardinality Line This class contains general information allowing identifying and describing a line lineid The line identifier or the line number within a document Identifier 1..1 linenote Free text note on line Text 0..1 QuantifiedLine 23 / 82

24 Attribute Description Type Cardinality This class is a specialisation of Line that contains a line quantity for the Item linequantity Number of item units of the line Quantity 1..1 PricedLine This class is a specialisation of Line that contains financial information including gross and net total amounts totallinevalue netlinevalue The total of the line including charges, discounts and taxes when appropriate Amount 1..1 The net total of the line before charges, discounts and taxes when appropriate (unit price * line quantity) Amount 1..1 chargeslinevalue The amount for all charges for the line, if any Amount 0..1 discountslinevalue The total discount for the line, if any Amount 0..1 LineTax This class contains the total amount for tax of a line linetax Total amount of tax to be charged on the line Amount 1..1 ItemLine This class is a specialisation of Line that may relate to item instance information 3.9 THE ITEM PACKAGE Items are composed of information that allows identifying (itemname, selleritemid, gtin, commodityclass) and describe (itemdescription, Aspect class) the goods, products, items or services to procure. The Item Package UML class diagram is illustrated below. Item +itemname +unitofmeasure +itemdescription +selleritemid +gtin +commodityclass May include 0..* Aspect +aspectname +aspectvalue +aspectvalueunit PricedItem +unitprice ItemInstance +instanceserialnumber +instancebatchnumber +instancesupplierreference +instanceregistration Number +instancemanufacturedate +instanceregistrationdate +instanceexpirydate Attribute Description Type Cardinality Item 24 / 82

25 Attribute Description Type Cardinality This class contains general information allowing a specific item itemname The name of the good or service Text 1..1 unitofmeasure itemdescription A UN/ECE No 20 code for the quantity in which items are priced. Code 1..1 Free text for a complete and full description of the item Text 0..1 selleritemid The identifier for the item (from the seller form) Identifier 0..1 gtin The Global trade Identification Number (EAN/UCC) for the item Text 0..1 The commodity class of the item using UNSPSC, CPV, ecl@ss or any other commodityclass classification Code 0..1 PricedItem This class is a specialisation of Item that contains financial information including the unit price of an item unitprice The unit price of the item (including the currency code) Amount 1..1 Aspect This class allows providing additional information on the characteristics of an item aspectname aspectvalue Type of the item aspect (e.g. colour, height, length width, weight, collar size) Text 1..1 Value of the aspect type that has been indicated Text 1..1 aspectvalueunit The unit code relating to the item aspect value Code 0..1 ItemInstance This class contains detailed information of a particular instance of an item of a line instanceserialnumber Product serial number Text 0..1 instancebatchnumber The manufacturer s batch number Text 0..1 instancesupplierreference The supplier's own reference of the item instance Text 0..1 instanceregistrationnumber The registration number of the item instance Text 0..1 instancemanufacturedate The date of manufacture of the item instance DateTime 0..1 instanceresgistrationdate The date of registration for the item instance DateTime 0..1 instanceexpirydate The expiry date of the item instance DateTime / 82

26 3.10 THE PARTY PACKAGE The Party class manages information on the organisation and people involved in a Document. Parties are composed of general information that allows identifying them. They also contain contact people details information as well as postal and electronic addresses. Finally they may include bank information such as the Electronic Funds Transfer address of the Accounts receivable or the Invoice Point parties and the Purchase Card information of the Order Point (required to process the payment). The Party Package UML class diagram is illustrated below. AccountsReceivable InvoicePoint TaxRepresentative accountnumber +branchid EFTaddress +bankname +accountname +SWIFTCode DespatchPoint SalesPoint OrderPoint 0..1 PurchaseCard +cardnumber +cardholdername +expirymonth +validfrommonth +verificationvalue +issuenumber +CRI DeliveryPoint Party Carrier CustomerService organisationname +partynote +dunsnumber +gln +taxnumber +registrationnumber +registrationcountrycode 0..* ContactInformation +countrycode +postcode +streetdescription +addressline +postbox +cityname +region Address +contactname +department +jobtitle +directline +mobilephone +switchboard +fax + Attribute Description Type Cardinality Party This class contains general information which allows identifying a party organisationname partynote dunsnumber gln The name of the organisation sending, receiving or referenced in any document Text 1..1 Free text that describes the party (including map or image of the location) Text 0..1 An identifier assigned to a company in the D&B Company Register Text 0..1 A Global Location Number assigned to an organisation by the EAN.UCC Text / 82

27 Attribute Description Type Cardinality The VAT number assigned to an organisation taxnumber registered for tax by the relevant national authority Text 1..1 registrationnumber The company's registration number Text 0..1 registrationcountrycode The country where the organisation is registered Code 0..1 ContactInformation This class contains information which provides contact details relating to a party contactname Name of the contact person of the organisation Text 1..1 department Name of the department to which the contact person belongs Text 0..1 jobtitle Job title of the contact person Text 0..1 directline Direct line of the contact person of the organisation Text 0..1 Mobile phone number of the contact person of the mobilephone organisation Text 0..1 switchboard Switchboard of the organisation Text 0..1 fax Fax number of the contact person of the organisation Text address of the contact person of the organisation Text 0..1 Address This class provides information relating to the postal address of a party countrycode Country code of the organisation (cf. Appendix 5) Country 1..1 postcode Post code of the organisation Text 1..1 streetdescription Street description of the organisation Text 0..1 addressline Lines that allows specifying additional information concerning the exact location of the party Text 0..5 postbox Postbox of the organisation Text 0..1 cityname City name of the organisation Text 1..1 region Region of the organisation Text 0..1 PurchaseCard This class contains information required by the seller to process purchase card payments cardnumber The number of the card of the order point Identifier 1..1 The name of the holder of the card (with eventually cardholdername the organisation name) Text 1..1 expirymonth The month and year of the expiry date Date 1..1 validfrommonth The month and year from which the card is valid Date 0..1 verificationvalue A digit number that suffixes the card number Text 0..1 issuenumber The issue number of the card Text 0..1 CRI Customer reference indicator (CRI), which is used to enable transmission of customer specific information with the card transaction. Text 0..1 EFTaddress This class contains information on the bank account of the party, required to process funds transfer accountnumber The account number of the accounts receivable or the invoice point Identifier 1..1 branchid The identifier of the branch the account is issued Identifier / 82

28 bankname accountname Attribute Description Type Cardinality The name of the bank of the accounts receivable or the invoice point Text 1..1 The name of the account of the accounts receivable or the invoice point Text 0..1 SWIFTCode The international bank transfer code of the bank of the accounts receivable or the invoice point Identifier 0..1 OrderPoint Buyer party for issues related to purchase orders SalesPoint Supplier party responsible for purchasing issues prior to fulfilment of Purchase Order AccountsReceivable Supplier party for payment-related issues Buyer party for payment-related issues InvoicePoint DeliveryPoint Buyer party that receives goods/works/services and identifies variances in receipt DespatchPoint Supplier party responsible for the delivery of goods Carrier Third party responsible for the delivery of goods CustomerService Supplier party responsible for issues related to purchase order fulfilment (despatch, delivery and carriage) TaxRepresentative Supplier party responsible for keeping VAT records and accounts for taxable transactions in another Member State 28 / 82

29 3.11 PURCHASE ORDER The whole procurement cycle usually starts with a PurchaseOrder placed by the buyer. Only one Item can be referenced in one PurchaseOrderLine. Nevertheless, there MAY be several lines corresponding to the same type of item, if different quantities of the same product have to be delivered at different point in time. The Purchase Order UML class diagram is illustrated below OrderPoint (from party) Is sent from Is sent to SalesPoint PurchaseOrder 1..1 (from party) +invoicecurrency InvoicePoint 1..1 (from party) 1..* PurchaseOrderLine +costcentercode +requiredbydate +deliveryterms +maxbackorderquantity May Specify 0..1 DeliveryPoint (from party) PricedDocument (from document) PricedLine (from line) Attribute Description Type Cardinality PurchaseOrder This class inherits from PricedDocument and specifies the currency to be used for the invoice invoicecurrency ISO code of the currency to be used for the invoice Code 0..1 PurchaseOrderLine This class inherits from Line and contains information relating to the delivery costcentercode Code used by the buyer for the type of goods being purchased. Code 0..1 requiredbydate Date by when the line items delivery is expected DateTime 0..1 deliveryterms INCOTERM Code & qualifier (if any) Code 0..1 maxbackorderquantity The quantity the Supplier is allowed to back order Quantity / 82

30 3.12 PO RESPONSE There SHOULD always be a POResponse to a PurchaseOrder although, depending on the trading agreement or practices between the buyer and the supplier, this MAY not be the case. A POResponse MUST refer to one and only one PurchaseOrder whether it is paper or electronic. A POResponse MUST repeat all the PurchaseOrderLines whether they are accepted, rejected or accepted in part. Thereby, the POResponse summarises the supplier s commitment. There MAY be several POResponses for the same PurchaseOrder. All POResponseLines MUST explicitly reference a PurchaseOrderLine. The supplier MAY respond to a PurchaseOrderLine with different PO response lines in particular when he plans several deliveries. A POResponse contains a status (accepted, modified or rejected) for the whole of the document as well as a status for each line. Therefore, a rejected respectively accepted status at document level implicitly means that all the lines of the document are accordingly rejected respectively accepted. A modified status at the document level implies that the status has to be specified for each line of the document mentioning accepted, rejected or modified. The Purchase Order Response UML class diagram is illustrated below SalesPoint (from party) Is sent from POResponse +invoicecurrency +postatus +poresponsestatus +poresponsecomment May specify Is sent to OrderPoint (from party) InvoicePoint (from party) 1..* 0..1 CustomerService (from party) POResponseLine +costcentercode +expecteddeliverydate +deliveryterms +maxbackorderquantity +polineid +purchaseorderid +pochangelineid +pochangeid +polinestatus +poresponselinecomment May Specify 0..1 DeliveryPoint (from party) PricedDocument (from document) PricedLine (from line) 30 / 82

31 Attribute Description Type Cardinality POResponse This class inherits from PricedDocument and contains the same data as for the order as well as information about the Seller s answer to the order invoicecurrency ISO code of the currency to be used for the invoice Code 0..1 postatus The purchase order status (Rejected, Modified, Accepted) Code 1..1 The nature of modification in case of purchase order modification (Line addition, Line deleted, Price modification, Date, Quantity, Terms) poresponsestatus Mandatory in case of postatus= Modified Code 0..1 poresponsecomment Free text for the order response Text 0..1 POResponseLine This class inherits from Line and contains information that allows commenting the answer as well as identifying to which order, order response and/or order change, the purchase order response line refers Code used by the buyer for the type of goods being costcentercode purchased. Code 0..1 expecteddeliverydate Date by when the line items delivery is expected DateTime 0..1 deliveryterms INCOTERM Code & qualifier (if any) Code 0..1 maxbackorderquantity The quantity of items the Supplier is allowed to back order Quantity 0..1 polineid purchaseorderid pochangelineid The identifier of the purchase order line that the current PO Response Line refers to Identifier 0..1 The identifier of the purchase order that the above PO Line refers to Mandatory if polineid is not empty Identifier 0..1 The identifier of the purchase order change line that the current PO Response Line refers to Identifier 0..1 The identifier of the purchase order change that the above PO Change Line refers to pochangeid Mandatory if pochangelineid is not empty Identifier 0..1 polinestatus The purchase order line status (Rejected, Modified, Accepted) Code 1..1 poresponselinecomment Free text for the response line Text PO CHANGE A POChange is sent by the buyer to inform the seller that he wishes to modify or cancel the purchase order he has issued. The structure of a POChange is similar to a POResponse. The only difference is that it MAY reference a previous POResponse. 31 / 82

32 The Purchase Order Change UML class diagram is illustrated below SalesPoint (from party) Is sent from POChange +invoicecurrency +postatus +pochangestatus +pochangecomment May specify Is sent to OrderPoint (from party) InvoicePoint (from party) 1..* POChangeLine +costcentercode +requiredbydate +deliveryterms +maxbackorderquantity +polineid +purchaseorderid +poresponselineid +poresponseid +polinestatus +pochangelinecomment May Specify CustomerService (from party) DeliveryPoint (from party) PricedDocument (from document) PricedLine (from line) Attribute Description Type Cardinality POChange This class inherits from PricedDocument and contains the same data as for the order or the order response as well as information about the Buyer s order modifications invoicecurrency ISO code of the currency to be used for the invoice Code 0..1 postatus The purchase order status (Cancelled, Modified, Accepted) Code 1..1 pochangestatus The nature of modification in case of purchase order modification (line modification, price modification, terms modification, ) Code 0..1 pochangecomment Free text for the order change Text 0..1 POChangeLine This class inherits from Line and contains information that allows commenting the modifications as well as identifying to which order and/or, order response, the purchase order change line refers Code used by the buyer for the type of goods being costcentercode purchased. Code 0..1 requiredbydate Date by when the line items delivery is expected DateTime 0..1 deliveryterms INCOTERM Code & qualifier (if any) Code 0..1 maxbackorderquantity The quantity of items the Supplier is allowed to back order Quantity 0..1 polineid The identifier of the purchase order line that the current PO Change Line refers to Identifier 0..1 The identifier of the purchase order that the above PO Line refers to purchaseorderid Mandatory if polineid is not empty Identifier 0..1 poresponselineid The identifier of the purchase order response line Identifier / 82

33 poresponseid polinestatus Attribute Description Type Cardinality that the current PO Change Line refers to The identifier of the purchase order response that the above PO Response Line refers to Mandatory if poresponselineid is not empty Identifier 0..1 The purchase order line status (Cancelled, Modified, Accepted) Code 1..1 pochangelinecomment Free text for the purchase order change line Text DESPATCH ADVICE A DespatchAdvice is sent by the seller to inform the buyer of that goods have been shipped to him or services fulfilled. A DespatchAdvice corresponds to only one delivery (one or several items delivered at the same time). A DespatchAdvice SHOULD reference one or more POResponses and/or PurchaseOrders and/or POChanges (i.e. goods or services ordered separately can be shipped and/or delivered at the same time). There MAY, in case of partial delivery, be several DespatchAdvices for the same PurchaseOrder. A DespatchAdviceLine SHOULD reference a POResponseLine and/or a PurchaseOrderLine and/or a POChangeLine. The Despatch Advice UML class diagram is illustrated below DespatchPoint (from party) Is sent from DeliveryPoint DespatchAdvice +despatchdate +consignmentreference +expecteddeliverydate May specify Is sent to May specify (from party) OrderPoint (from party) 1..* 0..1 CustomerService (from party) DespatchAdviceLine +polineid +purchasesorderid +poresponselineid +poresponseid +pochangelineid +pochangeid +expectedquantity +outstandingquantity +deliveryterms 1..1 Carrier (from party) OrderPaymentDocument (from document) ItemLine (from line) Attribute Description Type Cardinality 33 / 82

34 Attribute Description Type Cardinality DespatchAdvice This class inherits from OrderPaymentDocument and contains general information about the despatch process despatchdate The date when items are expected to be despatched (according to the related order) DateTime 0..1 consignmentreference The reference of the consignment related to this operation Text 0..1 expecteddeliverydate The estimated time of delivery of the items DateTime 0..1 DespatchAdviceLine This class inherits from Line and contains information that allows commenting the answer as well as identifying to which order, order response and/or order change, the dispatch advice line refers polineid purchaseorderid poresponselineid poresponseid pochangelineid pochangeid expectedquantity The identifier of the purchase order line the current despatch advice line refers to Identifier 0..1 The identifier of the purchase order the above purchase order line refers to Mandatory if polineid is not empty Identifier 0..1 The identifier of the purchase order response line the current despatch advice line refers to Identifier 0..1 The identifier of the purchase order response the above order response line refers to Mandatory if poresponselineid is snot empty Identifier 0..1 The identifier of the purchase order change line the current despatch advice line refers to Identifier 0..1 The identifier of the purchase order change the above order change line refers to Mandatory if pochangelineid is empty Identifier 0..1 The quantity of items that is expected in this delivery (according to the delivery terms) Quantity 0..1 The quantity of items still to be shipped (with outstandingquantity regards to the delivery terms) Quantity 0..1 deliveryterms The terms of delivery of the items Text RECEIPT ADVICE A Receipt Advice is sent by the buyer to the seller to acknowledge the total or partial reception of what has been ordered, indicating the variances related to the items, the delivery terms or any other differences. A ReceiptAdvice SHOULD correspond to one and only one DespatchAdvice. For one DespatchAdvice, there SHOULD be only one ReceiptAdvice. A ReceiptAdviceLine SHOULD reference a DespatchAdviceLine as well as a POResponseLine and/or a PurchaseOrderLine and/or a POChangeLine. 34 / 82

35 The Receipt Advice UML class diagram is illustrated below. ReceiptAdvice +expecteddeliverydate +receiptdate Is sent from Is sent to 1..1 DeliveryPoint (from party) 1..* ReceiptAdviceLine +polineid +purchaseorderid +poresponselineid +poresponseid +pochangelineid +pochangeid +despatchadviceid +despatchadvicelineid +outstandingquantity +expectedquantity +rejectquantity +rejectreason +shortquantity +shortreason +acceptedquantity 1..1 CustomerService (from party) OrderPaymentDocument (from document) ItemLine (from line) Attribute Description Type Cardinality ReceiptAdvice This class inherits from OrderPaymentDocument and contains the information relating to the date of items reception The estimated time of delivery of the items (according to expecteddeliverydate the despatch advice) DateTime 0..1 receiptdate The date when the goods were received or services completed by the Delivery Point DateTime 1..1 ReceiptAdviceLine This class inherits from Line and contains quantitative and qualitative information relating to the items that have been delivered as well as data identifying to which order, order response, order change and/or dispatch advice, the receipt advice line refers polineid purchaseorderid poresponselineid poresponseid pochangelineid The identifier of the purchase order line the current receipt advice line refers to Identifier 0..1 The identifier of the purchase order the above purchase order line refers to Mandatory if polineid is not empty Identifier 0..1 The identifier of the purchase order response line the current receipt advice line refers to Identifier 0..1 The identifier of the purchase order response the above purchase order response line refers to Mandatory if poresponselineid is not empty Identifier 0..1 The identifier of the purchase order change line the current receipt advice line refers to Identifier / 82

36 pochangeid Attribute Description Type Cardinality despatchadvicelineid despatchadviceid outstandingquantity The identifier of the purchase order change the above purchase order change line refers to Mandatory if pochangelineid is not empty Identifier 0..1 The identifier of the despatch advice line the current receipt advice line refers to Identifier 0..1 The identifier of the despatch advice the above despatch advice refers to Identifier 1..1 The quantity of items still to be shipped (with regards to the delivery terms) Quantity 0..1 rejectquantity The quantity of delivered items that are rejected by the Buyer Quantity 0..1 rejectreason Reason of the items rejection Text 0..1 shortquantity The quantity of delivered items that are missing Quantity 0..1 shortreason Comment on the items that are missing Text 0..1 acceptedquantity The quantity of delivered items that are accepted by the Buyer Quantity RECTIFICATION ADVICE A Rectification Advice is sent by the seller to the buyer to inform him on the action to be taken according to the variances that have been observed on delivered items. A RectificationAdvice SHOULD correspond to one and only one ReceiptAdvice. For one ReceiptAdvice, there MAY be a single RectificationAdvice. A RectificationAdviceLine SHOULD reference a (and only one) ReceiptAdviceLine as well as a POResponseLine and/or a PurchaseOrderLine and/or a POChangeLine. 36 / 82

37 The Rectification Advice UML class diagram is illustrated below. RectificationAdvice Is sent from 1..1 CustomerService (from party) Is sent to * RectificationAdviceLine +polineid +purchaseorderid +poresponselineid +poresponseid +pochangelineid +pochangeid +receiptadvicelineid +receiptadviceid +rectificationaction +intendedrectificationdate DeliveryPoint (from party) OrderPaymentDocument (from document) ItemLine (from line) Attribute Description Type Cardinality RectificationAdvice This class inherits from OrderPaymentDocument RectificationAdviceLine This class inherits from Line and contains information relating to the corrective actions that could be handle as well as data identifying to which order, order response, order change and/or receipt advice, the rectification advice line refers polineid purchaseorderid poresponselineid poresponseid pochangelineid pochangeid receiptadvicelineid The identifier of the purchase order line the current rectification advice line refers to Identifier 0..1 The identifier of the purchase order the above order line refers to Mandatory if polineid is not empty Identifier 0..1 The identifier of the purchase order response line the current rectification advice line refers to Identifier 0..1 The identifier of the purchase order response the above order response line refers to Mandatory if poresponselineid is not empty Identifier 0..1 The identifier of the purchase order change line the current rectification advice line refers to Identifier 0..1 The identifier of the purchase order change the above order change line refers to Mandatory if pochangelineid is not empty Identifier 0..1 The identifier of the receipt advice line the current rectification advice line refers to Identifier / 82

38 receiptadviceid Attribute Description Type Cardinality The identifier of the receipt advice the above receipt advice line refers to Identifier 1..1 rectificationaction Free text that describes the corrective actions to be taken Text 1..1 intendedrectificationdate The intended date where the action could be taken DateTime INVOICE Invoices are sent by the seller to the buyer for payment for delivered items or performed services. An Invoice MAY correspond to one or more PurchaseOrders in full or in part. An InvoiceLine SHOULD correspond to only one PurchaseOrderLine as well as one ReceiptAdviceLine. It is also recommended that a PurchaseOrderLine is invoiced only in one go, thereby corresponding to a unique InvoiceLine of a unique Invoice. However, a PurchaseOrderLine MAY correspond to a repetitive provision of supplies or of a service and will subsequently lead to several invoices (placed by the seller on a regular basis). The Invoice UML class diagram is illustrated below AccountsReceivable (from party) Is sent from InvoicePoint Invoice Is sent to 1..1 (from party) +taxtotal May specify 0..1 OrderPoint (from party) May specify 1..* InvoiceLine 0..1 TaxRepresentative (from party) +receiptdate +paymentexpecteddate +polineid +purchaseorderid +poresponselineid +poresponseid +pochangelineid +pochangeid +receiptadviceid +receiptadvicelineid May Specify 0..1 DeliveryPoint (from party) PricedDocument (from document) PricedLine (from line) 38 / 82

39 Attribute Description Type Cardinality Invoice This class inherits from PricedDocument and contains information relating to the tax amount of the invoice taxtotal The total amount of the tax related to the invoice Amount 1..1 InvoiceLine This class inherits from Line and contains information that allows identifying to which order and order line the invoice line refers receiptdate paymentexpecteddate polineid purchaseorderid poresponselineid poresponseid pochangelineid pochangeid receiptadviceid receiptadvicelineid The date when the goods were received or services completed by the Delivery Point DateTime 1..1 The expected date of payment or the effective date of payment if payment has already been made DateTime 0..1 The identifier of the purchase order line related to the invoice line Identifier 0..1 The identifier of the purchase order related to the invoice Identifier 0..1 The identifier of the purchase order response line that the current PO Change Line refers to Identifier 0..1 The identifier of the purchase order response that the above PO Response Line refers to Mandatory if poresponselineid is not empty Identifier 0..1 The identifier of another purchase order change line that the current PO Change Line refers to Identifier 0..1 The identifier of the purchase order change that the above PO Change Line refers to Madatory if pochangelineid is not empty Identifier 0..1 The identifier of the receipt advice line the current rectification advice line refers to Identifier 0..1 The identifier of the receipt advice the above receipt advice line refers to Identifier 0..1 Note that the Invoice business document can also be used in a self-billing scenario INVOICE RESPONSE An Invoice Response is sent by the buyer to inform the seller on discrepancies in the payment process that will probably require a credit note from the supplier. It may be associated with the purchase order as well as the receipt advice and the rectification advice, if relevant. An InvoiceResponse MUST refer to one and only one Invoice whether it is paper or electronic. An InvoiceResponse MUST repeat all the InvoiceLines whether they are accepted, rejected or accepted in part. Thereby, the InvoiceResponse summarises the buyer s commitment. There MAY be several InvoiceResponses for the same Invoice although this SHOULD not be the case. Each InvoiceResponseLine MUST reference an InvoiceLine. 39 / 82

40 The Invoice Response UML class diagram is illustrated below. InvoiceResponse Is sent from 1..1 InvoicePoint (from party) +taxtotal +invoicestatus +invoiceresponsecomment Is sent to May specify 1..1 AccountsReceivable (from party) 1..* InvoiceResponseLine May specify 0..1 OrderPoint (from party) +receiptdate +paymentexpecteddate +polineid +purchaseorderid +poresponselineid +poresponseid +pochangelineid +pochangeid +invoicelineid +invoiceid +receiptadviceid +receiptadvicelineid +invoicelinestatus +invoiceresponselinecomment May Specify TaxRepresentative (from party) DeliveryPoint (from party) PricedDocument (from document) PricedLine (from line) Attribute Description Type Cardinality InvoiceResponse This class inherits from PricedDocument and contains the same data as for the invoice as well as information about the buyer s answer to the invoice The total amount of the tax related to the taxtotal invoice Amount 0..1 The invoice status (Cancelled, Modified, invoicestatus Accepted) Code 1..1 invoiceresponsecomment Free text for the response Text 1..1 InvoiceResponseLine This class inherits from Line and contains information that allows commenting the answer as well as identifying to which order, order response, order change and/or invoice, the invoice response line refers receiptdate paymentexpecteddate polineid purchaseorderid poresponselineid The date when the goods were received or services completed by the Delivery Point DateTime 1..1 The expected date of payment (according to the related order s payment schedule) or the effective date of payment (if payment has already been made) DateTime 0..1 The identifier of the purchase order line that the current invoice Response Line refers to Identifier 0..1 The identifier of the purchase order that the above purchase order line refers to Mandatory if polineid is not empty Identifier 0..1 The identifier of the purchase order response line that the current invoice Response Line refers to Identifier / 82

41 poresponseid pochangelineid pochangeid invoicelineid invoiceid Attribute Description Type Cardinality The identifier of the purchase order response that the above order response line refers to Mandatory if poresponselineid is not empty Identifier 0..1 The identifier of the purchase order change line that the current invoice Response Line refers to Identifier 0..1 The identifier of the purchase order change that the above order change line refers to Mandatory if pochangelineid is not empty Identifier 0..1 The identifier of the invoice line that the current invoice Response Line refers to Identifier 0..1 The identifier of the invoice that the above invoice line refers to Identifier 0..1 receiptadviceid The identifier of the receipt advice line the current rectification advice line refers to Identifier 0..1 receiptadvicelineid The identifier of the receipt advice the above receipt advice line refers to Identifier 0..1 invoicelinestatus The invoice line status (Cancelled, Modified, Accepted) Code 1..1 invoiceresponselinecomment Free text for the invoice response line Text CREDIT NOTE A Credit note is sent by the seller to confirm to the buyer that the seller owes the buyer money. It follows an invoice response. A CreditNote can be seen as a negative invoice. Therefore, it has a similar structure to an Invoice. A CreditNote MUST make reference to at least one Invoice but MAY reference several ones. A CreditNoteLine MUST reference one and only one InvoiceLine. 41 / 82

42 The Credit Note UML class diagram is illustrated below. Is sent from 1..1 AccountsReceivable (from party) CreditNote +taxtotal Is sent to May specify 1..1 InvoicePoint (from party) +receiptdate CreditNoteLine +paymentexpecteddate +polineid +purchaseorderid +poresponselineid +poresponseid +pochangelineid +pochangeid +invoicelineid +invoiceid +receiptadviceid 1..* +receiptadvicelineid +invoiceresponselineid +invoiceresponseid May Specify May specify OrderPoint (from party) TaxRepresentative (from party) DeliveryPoint (from party) PricedDocument (from document) PricedLine (from line) Attribute Description Type Cardinality CreditNote This class inherits from PricedDocument and contains information about the amount of the credit note taxtotal The total amount of the credit note document Amount 1..1 CreditNoteLine Line of a CreditNote receiptdate paymentexpecteddate polineid purchaseorderid poresponselineid poresponseid The date when the goods were received or services completed by the Delivery Point DateTime 1..1 The expected date of payment (according to the related order s payment schedule) or the effective date of payment (if payment has already been made) DateTime 0..1 The identifier of the purchase order line that the current invoice Response Line refers to Identifier 0..1 The identifier of the purchase order that the above purchase order line refers to Mandatory if polineid is not empty Identifier 0..1 The identifier of the purchase order response line that the current invoice Response Line refers to Identifier 0..1 The identifier of the purchase order response that the above order response line refers to Mandatory if poresponselineid is not empty Identifier / 82

43 Attribute Description Type Cardinality pochangelineid pochangeid invoicelineid invoiceid receiptadviceid receiptadvicelineid invoiceresponselineid invoiceresponseid The identifier of the purchase order change line that the current invoice Response Line refers to Identifier 0..1 The identifier of the purchase order change that the above order change line refers to Mandatory if pochangelineid is not empty Identifier 0..1 The identifier of the invoice line that the current invoice Response Line refers to Identifier 0..1 The identifier of the invoice that the above invoice line refers to Identifier 0..1 The identifier of the receipt advice line the current rectification advice line refers to Identifier 0..1 The identifier of the receipt advice the above receipt advice line refers to Identifier 0..1 The identifier of the invoice response line the current rectification advice line refers to Code 1..1 The identifier of the invoice response the above receipt advice line refers to Text REMITTANCE ADVICE A RemittanceAdvice is sent by the buyer to notify the seller that payment has been made. A RemittanceAdvice MAY correspond to one or more Invoice or InvoiceResponse. Each RemittanceAdviceLine MUST refer to one single InvoiceLine or InvoiceResponseLine. 43 / 82

44 The Remittance Advice UML class diagram is illustrated below. RemittanceAdvice +documenttotal +paymentreference +paymentreferencedate Is sent from Is sent to 1..1 AccountsReceivable (from party) InvoicePoint 1..1 (from party) 1..* RemittanceAdviceLine +polineid +purchasesorderid +poresponselineid +poresponseid +pochangelineid +pochangeid +invoicelineid +invoiceid +invoiceresponselineid +invoiceresponseid +creditnotelineid +creditnoteid +totallinevalue +paymentexpecteddate OrderPaymentDocument (from document) Line (from line) Attribute Description Type Cardinality RemittanceAdvice This class inherits from OrderPaymentDocument and contains general information concerning the payment documenttotal The total amount of the remittance document Amount 1..1 paymentreference The reference of the payment the remittance refers to Text 0..1 paymentreferencedate The reference date of the payment the remittance refers to DateTime 0..1 RemittanceLine This class inherits from Line and contains information relating to the line amount as well as data identifying to which order, order response, order change, invoice, invoice response and/or credit note, the remittance advice line refers polineid purchaseorderid poresponselineid poresponseid The identifier of the purchase order line the current remittance line refers to Identifier 0..1 The identifier of the purchase order the above purchase order line refers to Mandatory if polineid is not empty Identifier 0..1 The identifier of the purchase order response line the current remittance line refers to Identifier 0..1 The identifier of the purchase order response the above purchases order response line refers to Mandatory if poresponselineid is not empty Identifier / 82

45 Attribute Description Type Cardinality pochangelineid pochangeid invoicelineid invoiceid invoiceresponselineid invoiceresponseid creditnotelineid The identifier of the purchase order change line the current remittance line refers to Identifier 0..1 The identifier of the purchase order change the above purchase order change line refers to Mandatory if pochangelineid is not empty Identifier 0..1 The identifier of the invoice line the current remittance line refers to Identifier 0..1 The identifier of the invoice the above invoice line refers to Mandatory if invoicelineid is not empty Identifier 0..1 The identifier of the invoice response line the current remittance line refers to Identifier 0..1 The identifier of the invoice response the above invoice response line refers to Mandatory if invoiceresponselineid is not empty Identifier 0..1 The identifier of the credit note line the current remittance line refers to Identifier 0..1 The identifier of the credit note the above credit note line refers to creditnoteid Mandatory if creditnotelineid is not empty Identifier 0..1 totallinevalue The total amount of the remittance line Amount 0..1 paymentexpecteddate The expected date of the payment (according to the related order s payment schedule) the remittance refers to DateTime / 82

46 4 EXTENDING THE IDA E-PROCUREMENT MODEL 1. The easiest way to add extra-information is to use the free-text attributes provided by the IDA model at different level: At Document level (Document.documentNote) when one needs to specify information related to the whole Document; At Line level (Line.lineNote) when one needs to specify information related to a particular Line; Related to a Party (Party.partyNote) when extra-information concerning one of the parties involved is required. This however presents limitations: Those attributes are free-text that can contain varied information; thus, automatic processing of their content can barely be envisaged; The content of those attributes is unstructured and cannot easily hold structured data. 2. Should you require extra-data that you want to process automatically and/or that can hold structured data, you may extend of any of the complextypes defined in our model by deriving them An example is given at the following address 46 / 82

47 5 GAP WITH UBL The UBL model is globally more complete and more complex than the IDA one although very similar in scope. The main differences are listed below: In the IDA model, business documents contain references to all the relevant other business documents or lines they are associated with. For instance, (at both document and line level) a receipt advice may refer to a purchase order or a purchase order response or a purchase order change, and the related dispatch advice. Some information exists only in the UBL model o Acknowledgement response attribute o Shipping information o Copy indicator attribute o GUID attribute o Language attribute o Base price class o Contract message o Allowance charge Some information exists only in the IDA model o costcentre attribute o ItemInstance class o Charges and discounts information o Invoice Response message o Credit Note message o Remittance advice message o Rectification advice message UBL model describes in more details packaging, transport and shipping information Currency can be specified for any business documents, at the document level, in the IDA model The line Item class is more complex in the UBL model Tax and Address information is more accurate in the UBL model Order cancellation is covered in the same message than Order Change or Order Response in the IDA model There are more details describing the items in the UBL model Payment, terms and conditions information is structured in different attributes in the IDA model Detailed information on the exchange currency is managed in the IDA model. The following table details the mapping between the two models for the PurchaseOrder and Invoice business document and their related information components. UBL Order BuyersID SellersID CopyIndicator GUID IssueDate Note AcknowledgementResponseCode TransactionCurrencyCode PricingCurrencyCode EarliestDate CancelledByDate ValidityDurationMeasure IDA ORDER PurchaseOrder Document.documentID (cf. 8. Appendix 1: Issues and decisions made, page67, issue #BDC6) Document.documentDate Document.documentNote Part of the PO Response document. Part of the Amount datatype. as a separate attribute but an currency attribute is attached to all Amount attribute. Similar to PurchaseOrder.requiredByDate 47 / 82

48 UBL TaxTotalAmount LineExtensionTotalAmount TotalPackagesQuantity GrossWeightMeasure NetWeightMeasure NetNetWeightMeasure GrossVolumeMeasure NetVolumeMeasure LineItemCountQuantity OrderLine SubstitutionStatusCode Note LineItem BuyersID SellersID LineStatusCode Quantity LineExtensionAmount TaxTotalAmount MinimumQuantity MaximumQuantity MaximumBackorderQuantity MinimumBackOrderQuantity Note Invoice ID CopyIndicator GUID IssueDate InvoiceTypeCode Note TaxPointDate InvoiceCurrencyCode TaxCurrencyCode PricingCurrencyCode LineItemCountQuantity InvoiceLine ID LineStatusCode InvoiceQuantity IDA TaxTypeTotal.taxTypeTotal PricedLine.netLineValue (cf. 8. Appendix 1: Issues and decisions made, page 67, issue #BDC12) PurchaseOrderLine deliveryterms costcentercode Line.lineNote Item & Line Item.sellerItemID QuantifiedLine.lineQuantity PricedLine.netLineValue PricedLine->LineTax.lineTax PurchaseOrderLine.maxBackOrderQuantity Item.itemDescription INVOICE Document & Invoice Document.documentID (cf. 8. Appendix 1: Issues and decisions made, page 67, issue #BDC6) Document.documentDate. Note that such information might not be necessary since a CreditNote is a separate business document in the IDA model. Document.documentNote Managed differently (at line level): InvoiceLine.receiptDate PurchaseOrder.invoiceCurrency PricedDocument->TaxTypeTotal.taxTypeTotal (currency attribute) Managed at line level: Line.netLineValue (currency attribute). InvoiceLine Line.lineID Line.lineQuantity 48 / 82

49 UBL LineExtensionAmount Note Managed differently (at document Level). Invoice.TaxPointDate) Party SellerParty BuyerAssignedAccountID SellerAssignedAccountID AdditionalAccountID IDA PricedLine.netLineTotal Line.lineNote receiptdate paymentexpecteddate polineid purchaseorderid poresponselineid poresponseid pochangelineid pochangeid receiptadvicelineid receiptadviceid PARTY Party NOT AN "EMPTY" CLASS BuyerParty BuyerAssignedAccountID SellerAssignedAccountID AdditionalAccountID Contact ID Name Telephone Telefax ElectronicMail Communication ChannelCode Value PartyIdentification ID PartyName Name ContactInformation contactname directline fax jobtitle switchboard mobilephone Managed differently. In the IDA model parties can be identified by Party.gln, Party.dunsNumber or Party.taxNumber) Party organisationname partynote dunsnumber Gln taxnumber 49 / 82

50 UBL Language ID Name LocaleCode BasePrice PriceAmount BasesQuantity MinimumQuantity MaximumQuantity MinimumAmount MaximumAmount IDA registrationnumber registrationcountrycode All Text attributes may have a language attached to it. OrderPoint SalesPoint InvoicePoint DespatchPoint DeliveryPoint Carrier CustomerService AccountsReceivable. TaxTotal TotalTaxAmount TaxSubTotal TaxableAmount TaxAmount TaxCategory ID RatePercentNumeric PartyTaxScheme RegistrationName Company TaxLevelCode ExemptionReasonCode TAX Invoice & Line Invoice.taxTotal & LineTax.lineTax Document, Line, Invoice PricedDocument.netDocumentTotal & PricedLine.netLineValue Invoice.taxTotal & LineTax.lineTax StandardTaxData taxpercent taxband Party. For the VAT, an equivalent would be the Party.taxNumber. organisationname 50 / 82

51 UBL TaxScheme ID TaxTypeCode CurrencyCode ID IssueDate ContractTypeCode Period StartDateTime EndDateTime DurationMeasure DescriptionCode IDA StandardTaxData. taxtype. CONTRACT (cf. 8. Appendix 1: Issues and decisions made, page 67, issue #BDC15) Address ID postbox Floor Room StreetName AdditionalStreetName BuildingName BuildingNumber Inhous Department CityName PostalZone CountrySubentity CountrySubentityCode Region District TimezoneOffset Country IdentificationCode Name AddressLine Line ADDRESS Address as a specific attribute but the addressline attribute can be used for all extra-information on an address. postbox as a specific attribute but the addressline attribute can be used for all extra-information on an address. streetdescription as a specific attribute but the addressline attribute can be used for all extra-information on an address. ContactInformation.department cityname Postcode as a specific attribute but the addressline attribute can be used for all extra-information on an address. Region as a specific attribute but the addressline attribute can be used for all extra-information on an address. Address countrycode Address addressline LocationCoordinate (latitude, longitude) Country IdentificationCode Name Address code of all attribute of type Country. Value of all attribute of type Country. 51 / 82

52 UBL CommodityClassification NatureCode CargoTypeCode CommodityCode SalesConditions ID ActionCode Description PhysicalAttribute AttributeID PositionCode DescriptionID Description Dimension AttributeID Measure Description MinimumMeasure MaximumMeasure IDA Item. commodityclass. Aspect aspectname & aspectvalue & aspectvalueunit LineReference LineID linestatuscode DocumentReference ID CopyIndicator IssueDate GUID ItemInstance intanceserialnumber intancebatchnumber instancesupplierreference instanceregistrationnumber instancemanufacturedate instanceregistrationdate instanceexpirydate DOCUMENT REFERENCE Line lineid linenote PricedLine totallinevalue chargeslinevalue discountslinevalue ItemLine Document documentid documentdate (cf. 8. Appendix 1: Issues and decisions made, page67, issue #BDC6) 52 / 82

53 UBL OrderLineReference BuyersLineID SellersLineID LineStatusCode IDA OrderPaymentDocument contractreference paymentmethod settlementterms termsconditions paymentschedule digitalsignature as a separate class but with a list of attributes OrderReference BuyersID SellersID CopyIndicator IssueDate GUID DocumentReference Branch ID Name Country IdentificationCode Name FinancialInstitution ID Name as a separate class but with a list of attributes PricedDocument documenttotal chargestotal discountstotal Attachment attachment filename description size MIMEType ExchangeCurrency targetcurrencycode basecurrencycode targettobaserate exchangeratedate exchangeratesource EFTaddress branchid bankname Address countrycode 53 / 82

54 6 GAP WITH EHANDEL The ehandel model is globally more limited in scope (covers mainly Ordering and invoicing) and is based on the assumption that it is related to e-commerce conducted through the ehandel marketplace. The main differences are listed below: In the IDA model, business documents contain references to all the relevant other business documents or lines they are associated with. For instance, (at both document and line level) a receipt advice may refer to a purchase order or a purchase order response or a purchase order change, and the related dispatch advice. Some information exists only in the ehandel model o Language attribute o OffCatalogueFlag attribute o Account information o PriceCheckRequest message o PriceCheckResult message o AvailabilityCheckRequest message o AvailabilityCheckResult message Some information exists only in the IDA model o Document, Line, Item, Party reusable packages o Charges and discounts information o Item instance information o Item aspect information o Purchase card information o Invoice response message o Despatch advice message o Rectification advice message o Credit note message o Remittance advice Detailed information on the exchange currency is managed in the IDA model Party description, Order contact as well as EFT address are less exhaustive in the ehandel model Currency can be specified for any business documents, at the document level, in the IDA model Totals have to be expressed also in the tax currency in the ehandel model The following table details the mapping between the two models for the PurchaseOrder and Invoice business document and their related information components. ehandel Order buyerordernumber orderissuedate costcenter purpose headercurrency language requestedshipbydate requesteddeliverbydate requisitiondate termsofdelivery transportterms shipmentmethodofpayment transportdescription paymentterm netdaysdue netduedate netdatetimeref IDA PurchaseOrder Document.documentID Document.documentDate PurchaseOrderLine.costCenterCode as a specific attribute Part of each Amount attribute Part of each Text attribute. PurchaseOrderLine.expectedDeliveryDate PurchaseOrderLine.deliveryTerms OrderPaymentDocument.settlementTerms OrderPaymentDocument.paymentSchedule 54 / 82

55 ehandel paymentmean headernote headerattachment totalamount OrderItem lineitemnumber productdescription commoditycode totalquantity maxbackorderquantity offcatalogueflag unitprice IDA OrderPaymentDocument.paymentMethod Document.documentNote Attachment.attachment PricedDocument.documentTotal OrderPaymentDocument contractreference termsconditions Document digitalsignature StandardTaxData taxtype taxband PricedDocument chargestotal discountstotal ExchangeCurrency targetcurrencycode basecurrencycode targettobaserate exchangeratedate exchangeratesource OrderPoint SalesPoint InvoicePoint DespatchPoint DeliveryPoint Carrier CustomerService AccountsReceivable Line & Item Line.lineID Item.itemDescription Item.commodityClass QuantifiedLine.lineQuantity PurchaseOrderLine.maxBackOrderQuantity. PricedItem.unitPrice 55 / 82

56 ehandel monetaryamount requesteddeliverydate itemnote itemattachment Product supplierpartid manufacturerpartid buyerpartid TaxInformation taxregistrationid registeredname resgisteredoffice companyresgistration IDA PricedLine.netLineValue PurchaseOrderLine.expectedDeliveryDate Item.itemDescription Attachment.attachment Line linenote PricedLine totallinevalue chargeslinevalue discountslinevalue ItemLine ItemInstance intanceserialnumber intancebatchnumber instancesupplierreference instanceregistrationnumber instancemanufacturedate instanceregistrationdate instanceexpirydate Item itemname unitofmeasure Gtin Aspect aspectname aspectvalue aspectvalueunit Item Item.sellerItemID Party Party.taxNumber Party.registrationNumber Party partynote dunsnumber Gln registrationcountrycode 56 / 82

57 ehandel SellerBankInformation financialinstitutename bankaccount OrderContact contactname telephonenumber faxnumber address IDA EFTaddress EFTaddress.bankName EFTaddress.accountNumber accountnumber branched SWIFTCode PurchaseCard cardnumber cardholdername expirymonth validfrommonth verificationvalue issuenumber CRI ContactInformation contactname directline Fax jobtitle mobilephone switchboard department InvoiceVatSummary StandardTaxTotal, TaxTypeTotal, PricedDocument vatrate StandardTaxTotal.taxPercent vatamounttotal TaxTypeTotal.taxTypeTotal taxableamounttotal PricedDocument.netDocumentTotal vatamounttotalintaxcurrency taxableamounttotalintaxcurrency Account accountcode supplieraccountcode description supplierapprove allowbackorder allowpartialshipment preferredsupplier Party identifier name1 name2 name3 housenumber street building Party & Address Only one name: Party.organisationName as a specific attribute but the addressline attribute can be used for all extra-information on an address. Address.streetDescription as a specific attribute but the addressline attribute can 57 / 82

58 ehandel roomnumber inhous postalcode city region country Invoice invoicenumber invoicedate paymentreference invoicepurpose invoicetype invoicecurrency paymentcurrency taxaccountingcurrency language medium duedate paymentterm paymentmean headernote netamount vatamount grossamount InvoiceItem lineitemnumber productdescription commoditycode totalquantity offcatalogueflag purchaseordernumber purchaseorderdate purchaseorderlinenumber supplierordernumber deliverynotenumber relatedinvoicenumber unitprice vatrate vatamount vatamountinttaxcurrency taxableamount taxableamountintaxcurrency itemamount IDA be used for all extra-information on an address. Address.postCode Address.cityName Address.region Address.countryCode Address addressline postbox Invoice Document.documentID Document.documentDate RemittanceAdvice.paymentReference. Note that such information might not be necessary since a CreditNote is a separate business document in the IDA model. PurchaseOrder.invoiceCurrency PricedDocument->TaxTypeTotal.taxTypeTotal (currency attribute) managed with the Language attribute on all Text value.. OrderPaymentDocument.settlementTerms OrderPaymentDocument.paymentMethod Document.DocumentNote PricedDocument.netDocumentTotal Invoice.taxTotal PricedDocument.DocumentTotal InvoiceLine Line.lineID Item.itemDescription Item.commodityClass Line.lineQuantity purchaseorderid polineid receiptadviceid Invoice.invoiceID PricedItem.unitPrice StandardTaxData.taxPerCent LineTax.lineTax PricedLine.netLineTotal PricedLine.netLineTotal 58 / 82

59 ehandel itemamountintaxcurrency itemnote IDA but can be specified at document level with the PricedDocument->ExchangeCurrency class. Item.itemDescription 59 / 82

60 7 GAP WITH OGC The OGC model is very close to the IDA one in terms of scope and design. On of the major differences is that the IDA model does not cover sourcing and that it is significantly simpler (globally fewer classes/attributes and simpler design). The main differences are listed below: in the IDA model, business documents contain references to all the relevant other business documents or lines they are associated with. For instance, (at both document and line level) a credit note may refer to a purchase order or a purchase order response or a purchase order change, the related receipt advice, the related invoice or invoice response. Some information exists only in the OGC model: o Document metadata class (apart from the digital signature attribute) o Shipping Information class o Priced item validity class o RFQ message o Catalogue update message: this is not part of our model for now; nevertheless, the exchange of catalogues have been identified as one of the way to significantly streamline e- procurement processes and will be studied in a second time; o Draft supply requisition message o Statement message o Debit note message Some information exists only in the IDA model: o MaxBackOrderQuantity attribute o Purchase order change class In the OGC model, at the line level, only charges and discounts totals are managed (no detail is available) Address information is less complex in the IDA model Receipt Advice information is more structured within the IDA model The Credit Note class is more complex in the IDA model since it contains the same information as for the Invoice class In the IDA model, responses contain a specific attribute (different from the ones available in the Document and Line packages) allowing describing the comment and the status of the response The OGC model manages several identifiers for business documents.. The following table details the mapping between the two models for the PurchaseOrder and Invoice business document and their related information components. OGC DocumentID documentid documentdate documentstatus docuuid Digital Signature digitalsignature DocumentAttachment attachment IDA DOCUMENT PACKAGE Document documentid documentdate Only specific to business document type (PO Response, PO Change, etc.) (cf. 8. Appendix 1: Issues and decisions made, page 67, issue #BDC6) Document digitalsignature Attachment attachment filename description size 60 / 82

61 OGC Document documentnote contractref paymentmethod settlementterms termsconditions paymentschedule ReferencedDocument PricedDocument DocumentMetaData teststatus senderswmanufacturer senderswproduct senderswversion schemaversion stylesheetreference sendersystemid senderslogo IDA MIMEType Document documentnote OrderPaymentDocument.contractReference OrderPaymentDocument.paymentMethod OrderPaymentDocument.settlementTerms OrderPaymentDocument.termsConditions OrderPaymentDocument.paymentSchedule as a specific class but by specific attributes (referring to a document id). PricedDocument LineID linenumber lineuuid LineAttachment attachment Line linestatus linenote projectref ReferencedLineID QuantifiedLine linequantity PricedLine UnPricedLine LINE PACKAGE Line lineid (cf. 8. Appendix 1: Issues and decisions made, page67, issue #BDC6) Document package.attachment attachment Line Only specific to business document type (PO Response, PO Change, etc.) linenote Managed through the contractref at document level. Only specific to business document type (PO Response, PO Change, etc.) Line linequantity PricedLine NOT AN "EMPTY" CLASS (described below) ItemLine 61 / 82

62 OGC SummaryLine ItemInstance intanceserialnumber intancebatchnumber instancesupplierreference instanceregistrationnumber instancemanufacturedate instanceregistrationdate instanceexpirydate Aspect aspectname aspectvalue aspectvalueunit Item itemname unitofmeasure itemdescription selleritem Gtin itemuuid ExtendedItemID extendeditemid extendeditemidsource PricedItem unitprice commodityclass PricedItemValidity quantityfrom quantityto pricevalidfrom pricevalidto IDA CurrencyLine ItemInstance intanceserialnumber intancebatchnumber instancesupplierreference instanceregistrationnumber instancemanufacturedate instanceregistrationdate instanceexpirydate Aspect aspectname aspectvalue aspectvalueunit Item itemname unitofmeasure itemdescription selleritem gtin (cf. 8. Appendix 1: Issues and decisions made, page 67, issue #BDC6) PricedItem PricedItem.unitPrice Item.commodityClass LineValue totallinevalue PricedLineValue extendednetlinevalue LineTax linetax FINANCIAL PACKAGE PricedLine totallinevalue PricedLine netlinevalue LineTax linetax 62 / 82

63 OGC LineChargeDiscount linechargediscount DocumentChargeDiscount documentchargediscount ChargeDiscountData chargediscounttype chargediscountpercent chargediscountname IDA PricedLine chargeslinevalue discountslinevalue PricedDocument chargestotal discountstotal (only totals are managed, see above) DocumentTotals DocumentTotals PricedDocumentTotals subtotal chargestotal discountstotal StandardTaxData taxtype taxband taxpercent TaxTypeTotal taxtypetotal ExchangeCurrency targetcurrencycode basecurrencycode targettobaserate exchangeratedate exchangeratesource Party organisationname contactname partynote partyuuid Address postcode countrycode UnstruturedAddress addressline PricedDocument DocumentTotal PricedDocument netdocumenttotal chargestotal discountstotal StandardTaxData taxtype taxband taxpercent TaxTypeTotal taxtypetotal ExchangeCurrency targetcurrencycode basecurrencycode targettobaserate exchangeratedate exchangeratesource PARTY PACKAGE Party & ContactInformation Party..organisationName ContactInformation..contactName Party.partyNote (cf. 8. Appendix 1: Issues and decisions made, page67, issue #BDC6) Address postcode countrycode Address addressline 63 / 82

64 OGC StructuredPostalAddress streetdescription locality town administrativearea primaryaddressableobjectname secondaryaddressableobjectname ukinternalcode ElectronicAddress directline switchboard fax mobilephone ExtendedElectronicAddress electronicaddress eaddresschannel eaddressuse eaddresstimevalidity PersonStructuredName title forename surname namesuffix jobtitle department knownas OrganisationIdentifier dunsnumber gln taxidentifier registrationnumber registrationin OrganisationDetail tradingas parentorganisation registeredname registeredaddress PurchaseCard CardNumber IDA Address streetdescription Only one attribute (cityname) for the two attributes locality and town. cityname as a specific attribute but the addressline attribute can be used for all extra-information on an address. postbox region ContactInformation directline switchboard fax mobilephone ContactInformation Managed as a single attribute (contactname) jobtitle department Party dunsnumber Gln taxnumber registrationnumber registrationcountrycode. The Party.partyNote attribute can be used in order to specify any extra information on a party. PurchaseCard CardNumber 64 / 82

65 OGC CardHolderName ExpiryMonth ValidFromMonth VerificationValue IssueNumber CRI EFTaddress AccountNumber BranchID BankName AccountName SWIFTCode SalesPoint buyerrefforseller AccountsReceivable buyerrefforseller OrderPoint sellerrefforbuyer DeliveryPoint InvoiceTo CustomerService DespatchPoint Carrier Factor Originator PurchasingManager PURCHASE ORDER PurchaseOrder requinvcurrency PurchaseOrderID PurchaseOrderLine requiredbydate deliveryterms IDA CardHolderName ExpiryMonth ValidFromMonth VerificationValue IssueNumber CRI EFTaddress AccountNumber BranchID BankName AccountName SWIFTCode SalesPoint AccountsReceivable OrderPoint DeliveryPoint InvoiceTo CustomerService DespatchPoint Carrier PurchaseOrder invoicecurrency Managed as a single attribute (Document.documentID) PurchaseOrderLine requiredbydate deliveryterms maxbackorderquantity INVOICE 65 / 82

66 OGC Invoice invoicetype taxpointdate taxtotal cardauthorisation InvoiceLine costcenterref costcoderef Managed in a dedicated class Managed differently (see below) POlineNumber PurchaseOrderID IDA Invoice. Note that such information might not be necessary since a CreditNote is a separate business document in the IDA model. Managed at line level (Invoice->InvoiceLine.receiptDate) taxtotal InvoiceLine & PurchaseOrderLine Only managed in the PurchaseOrder document receiptdate paymentexpecteddate polineid purchaseorderid poresponselineid poresponseid pochangelineid pochangeid ReceiptAdviceLineID ReceiptAdviceID Managed differently (not in a dedicated class): polineid + purchaseorderid Managed differently (see above). 66 / 82

67 8 APPENDIX 1: ISSUES AND DECISIONS MADE This section gives the different issues that arose during the modelling of business documents together the associated decision. The status of an issue can be one of the following: OK: a decision that we think is satisfying was taken; Unresolved yet: no decision was taken yet; Open: a decision was taken but we feel that it has almost as many cons as pros. # Issue description Status Decision GEN1 General Why not use an existing standard rather than develop a new model? Open The main reasons why it was decided to propose a new model are the following: There are numerous existing standards covering the e-ordering and e-invoicing process; but most existing models, such as Rosetta.net and OAGIS are very complex and difficult to implement; Work was already carried out on the subject by other Member states providing us with a solid base for describing a core set of requirements; UBL, seen by many as one of the most promising standard in the domain, was in its version 0.7 at the time we started our work. Furthermore, the IDA model could also be considered as the description of a common denominator for the requirements in public e-procurement in Europe. Apart from its XML implementation, it could also: Be used as a common basis for mapping different existing standards thus facilitating interoperability between them (each particular standard only has to provide a converter to the IDA model rather than to all other standards); Be seen as a contribution to enrich other existing standard in particular UBL. UML modelling UM1 Use of inheritance? OK Inheritance should be used when the generalisation of two or more subclasses and its parent class appears natural and that it facilitates the comprehension of the model. UM2 Use of packages? Is it useful to split classes from the OK We used packages in order to structure the classes constituting our 67 / 82

68 # Issue description Status Decision BDC1 BDC2 information model between packages? What should be the logic of this separation? Business documents content/structure Is it desirable that the content of a business document be redundant? For example should price totals that could be calculated automatically from detailed price be included creating redundancy in the message. Should documents be self-contained? For example when accepting an order (Order Response business document) should the detail of the Order be repeated in the response? OK OK information model and its documentation. Redundant information can be added when necessary: It can make information as explicit as possible; Redundancy has very few cons. Business documents should be, as much as possible, self-contained: Repeating information does not make the process significantly more complex or time-consuming; This makes the agreement between trading partners les ambiguous/more explicit; This can avoid having to consolidate several business documents in order to check or understand the information contained in one document; this is particularly important when documents serves as a proof for non-repudiation and/or they are archived as separate files. BDC3 How should references between parts of the same or different documents be modelled? OK We decided not to use references from one part to another one in the same document: As most business documents are data-centric 14, the most frequent case where internal references are needed is to avoid repeating the same information several times; we believe that the price for repeating information in the same business document is not very high (the difference in size is low); On the contrary, generating and handling internal references is relatively difficult technically. BDC4 How could we lower the cost of implementation for SMEs? 1/ OK. 2/ Unresolved yet. For references between different documents, this can be done at document and line level. 1/ The following rules should tend to reduce the cost of adoption in general: The creation of business documents should not require complex or expensive software; the simplest scenario consisting of the use of a spreadsheet/word processor + a macro should be possible; The handling of a business document 14 As opposed to text-centric documents in which cross-references are common practice. 68 / 82

69 # Issue description Status Decision should not require complex and expensive software; business documents should be viewable in an Internet browser 15 ; this also explains BDC2; The transmission of business documents should not require specific software and should be independent from any transport protocol; the simple scenario consisting of using should be possible. BDC5 Should the IDA e-procurement model should remain simple or should it be as complete as possible? BDC6 Should we use UUID 16? UUID provide the simplest mechanism, at machine level, to generate identifiers for business documents that are guaranteed to be unique. Open Open 2/ Another possible option is to develop different levels of agreements defining processes and business documents (more or less complex) for each level. We opted for a compromise between a simple model and a complete model covering all possible cases, i.e. extensible for big companies and manageable for SMEs. We decided not to: They need to be generated automatically, which contradicts decision BDC4. BDC7 Use XHTML as a structured text type? OK For the time being, we made the decision not to: Although generating XHTML text can be relatively easy (one can always generate plain text or simply a series of paragraphs marked by P elements), receiving and handling information that might be structured with XHTML is significantly more difficult. BDC8 Use of UBL core components/representation terms? BDC9 Structured vs. unstructured addresses? UBL defines a very structured address component with many specific fields (floor, room, buildingname, buildingnumber, etc.) whereas Rosettanet and ehandel define an unstructured version of an address composed mainly of Country, ZipCode, Open We have decided to conform when possible some to the Core components data types with the same definition. Whether the IDA XML schemas will use their XML schemas definition (making our model dependent from theirs) is not decided yet. OK The IDA e-procurement Address component is a happy medium: The great variety of the form an address can take (even within the same country) proves that it is always necessary to have free lines of text (i.e. it is possible not to structure an address by way of a list of specific 15 This will necessitate in a second phase to, similarly to UBL and other recent XML-based standards, the development of one or more XSLT stylesheets for each business document type. 16 UUID stands for a Universal Unique IDentifier. These are 128 bit numbers assigned to any object which is guaranteed to be unique. The mechanism used to guarantee that UUIDs are Unique is through combinations of hardware addresses, time stamps and random seeds 69 / 82

70 # Issue description Status Decision PostBox and a series of address lines. In OGC, an address can be either structured or unstructured. fields); Pieces of information might still be processed automatically and are specified as specific fields. BDC10 BDC11 BDC12 BDC13 BDC14 Commodity codes for items? OGC and ehandel specify one commodity code element corresponding explicitly to UNSPSC. Should the choice of the classification not be left to users (for example e- cl@ss or CPV)? Shouldn t there be several commodity codes elements to allow users to specify different codes for the same item? Structured person name? Is it necessary to allow for the decomposition of a person s name (forename, middle name, surname, title, etc.). Transport and packaging information? A lot of information related to the transport and packaging of goods are important especially in the process of delivery. Should it be taken into account in the model? Should there be, on top of the linenote generic attribute a specific attribute for comments in response documents Language attribute Should a language attribute be added to all text attributes to allow specifying the language they are expressed in? OK OK Open OK Open For the sake of simplicity, we propose to have only one commodity code but the corresponding attribute can refer (code datatype) to any classification standard. Although having a structured person name can be a benefit since it allows for more precision, we have not found a real case where distinguishing the different components of a name was a real necessity. Therefore, for the sake of simplicity, a person name in the IDA model is a simple free text attribute. Logistics and transport can be complex field. Although there is a requirement for exchanging information related to transport and packaging between buyer and seller, we could not find a simple way to model it (in particular because we did not want to break the structure of lines on which all business documents rely and on which the simplicity and homogeneity of the whole model relies). Furthermore, transport and packaging information can always be provided in corresponding business documents (DespatchAdvice in particular) free-text attributes 17 (documentnote, linenote, partynote). A specific note attribute has been added to POResponse, POChange and InvoiceResponse at line level so that a comment could be added, without deleting the comment present in the original message. For example, a seller may wish to reply to a PurchaseOrder and add a comment on a particular line for which the buyer has already specified a comment using linenote. The seller can use the poresponselinecomment attribute without having to modify the original content of the linenote attribute. As far e-ordering and e-invoicing are concerned, very little free text is generally used. Nevertheless, all textual attribute (attributes of type Text) have a dedicated language attribute. 17 cf. 4. Extending the IDA e-procurement model, page / 82

71 # Issue description Status Decision BDC15 BDC16 Contract reference All business messages may (and usually does) refer to a specific contract. How much information on that contract should be repeated in each message? Currency information The whole cycle from ordering through to payment could involve many different currencies. How can different currencies be managed whil keeping the model relatively simple? Open Open For the sake of simplicity, we propose to only specify the contract reference (but not information like start date and end date) First, all attributes containing an amount has a currency attribute attached to it (cf. datatype Amount). As a general rule and in order to keep the business document s structure simple, when amounts are to be given in two different currencies, this is done at document level (only for totals) and not at line level. XML XML1 Use of attributes vs. elements Open Elements should be the main holders of content. Attributes should be used to hold metadata or characteristics of element content. We think that we should use attributes only for defining data types. In that case, attributes are used as qualifiers (such as currencycode for data type Amount or unitofmeasure for data type Quantity). XML2 Use of namespaces Open There will be one namespace per package: Not using namespaces reduce interoperability; Using too many namespaces makes the XML schemas more difficult to use/implement. XML3 XML4 What extension mechanism should be used? How should be files attached to messages? Should we allow for inline binary files or just a simple URI? There are many scenarios where attaching a file, either to the business document or a specific line, is a requirement or a real benefit. There is mainly two ways to include binary data in an XML message. The first one is to have inline binary data encoded in base64 in a dedicated XML element. The second one is to specify a URI in the XML document identifying the location of the attached file. In practice this may be a URI pointing to a document located somewhere on the Internet and accessible by a Internet browser. Another common practice is to use MIME as a packaging mechanism to embed in a single message different files. Open Open See the XML schema design guidelines document. The first solution which consists in having inline binary data has several drawbacks. First, base64-encoding files makes them one-third larger. Second, this solution may lead to extremely large XML files that will be more time and memoryconsuming to process if you just want to interpret the XML content. Again for simplicity purposes, we decided that a URI would be the only attribute of the Attachment object. 71 / 82

72 9 APPENDIX 2: UML TO XML SCHEMAS CONVERSION RULES R1/ file and directory structure: There is one schema file per package except for the Document package where there will be one common schema (document.xsd) and one schema per business document class There is one directory per package with the same name as the package (document, line, item, ) R2/ Classes: For each class that does not correspond to a business document (top-level class) of the information model: => a complex type of name: class name + Type For each class that correspond to a business document (PurchaseOrder, Invoice, POResponse, etc.): => a complex type of name: class name + Type is defined => an element with the same name as the class referencing that comlextype is also defined R3/ Associations: => When the association is of cardinality 0..1 or 1..1, a specific element is defined with the same name as the target class; the type of this element is the type corresponding to the target class; => When the association is of cardinality 0..* or 1..* a specific repetitive XML element is defined with the same name as the target class; the type of this element is the type corresponding to the target class. R4/ Attributes: => A local element is defined with the same name as the attribute; the XML element type is the class that corresponds to its type as defined in the UML diagram. R5/ Digital signature: For the digital signature attached to business document an optional element conforming to the W3C xml dsig schema was added to the Document class. 72 / 82

73 10 APPENDIX 3: XML SCHEMAS DESIGN GUIDELINES 10.1 NAMING CONVENTIONS RNM1. In order to conform to common practice as regards XML schemas, elements names MUST use upper camel case : MUST start with a capital. When a name is composed of several words: they should not be separated by an underscore (_) character; each word starts with a capital letter. In order to conform to ebxml conventions, attribute names should use lower camel case (i.e. starts with a lower-case initial). Example: <ItemDescription versionid= v3 > </ItemDescription> RNM2. Underscores ( _ ), dots (. ) and dashes ( - ) MUST NOT be used in component names NAMESPACE RNS1. An XML schema should have a target namespace. RNS2. A particular namespace should correspond to a coherent collection of schemas or components VERSIONING RVER1. The version of an XML schema is indicated, in accordance with W3C practice, in the version attribute of the xsd:schema element. RVER2. The version MUST not be part of the namespace URI USE OF DATA TYPES DEFINITION RDT1. A component MUST be defined as a data type if: it can be used in different contexts with different element names or it has or it is foreseen to have other data types derived from it. In all other cases, a component can be defined as a simple element USE OF ATTRIBUTES RAT1. Elements should be the main holders of content. Attributes should be used to hold metadata or characteristics of element content MULTILINGUAL CONTENT Although one should use when possible codified values that would be independent from the language, there are many cases where the value of a component is textual. It therefore depends on the language and can also be given in different languages (for example for textual description of items of a catalogue). RMC1. Components that can have a textual value SHOULD be characterised by an xml:lang attribute. 73 / 82

74 RMC2. Components that can have a textual value SHOULD, when applicable, be made repetitive (cardinality 0..* or 1..*) and hold a language attribute (xml:lang) so that its value can be produced in several languages. Example: <Item> <Description xml:lang= en >Video Camera</Description> <Description xml:lang= fr >Caméra Vidéo</Description> <Description xml:lang= es >Viodeocámara</Description> </Item> 10.7 EXTENSION MECHANISM REM1. In order to design extensible components, we suggest using inheritance/specialisation of complextypes SCHEMA DOCUMENTATION RSD1. All components should have a corresponding documentation (in English) using the xsd:annotation element elementformdefault AND attributeformdefault RFD1. elementformdefault MUST be set to qualified and attributeformdefault SHOULD be set to unqualified. Example: <xsd:schema targetnamespace=" xmlns=" elementformdefault="qualified" attributeformdefault="unqualified" version="1.0"> 74 / 82

75 11 APPENDIX 4: ACRONYMS Acronym BACS (Banker s Automated Clearing System) B2B (Business to Business) CEN (European Committee of Standardization) CPV (Common Procurement Vocabulary) CRI (Customer Reference Identifier) DTD (Document Type Definition) DUNS Description Electronic payment method. ( B2B is e-commerce transaction between two companies. The CEN is a European standardisation body contributing to the objectives of the European Union and European Economic Area with voluntary technical standards. ( Standard codification for use in public procurement. ( Unique company registration identifier. Specific definition that follows the rules of the Standard Generalized Markup Language (SGML). A DTD is a specification that accompanies a document and identifies what the codes (or mark-up) are that separate paragraphs, identify topic headings, and so forth and how each is to be processed. DUNS stands for "Data Universal Numbering System." It is a unique nine-digit numbering system that is used to identify a business. EAN Non-profit, business-led association that manages a worldwide system that enables the identification of items, trade and logistic units, services and locations. The purpose is to provide a common language for international trade and commerce that is applicable to virtually all industrial and commercial sectors. The system includes standards that cover; identification and supplementary information, bar code specifications, and an internationally used subset of the EDIFACT EDI messages called EANCOM. ( EbMS ebxml Messaging Infrastructure. Messaging framework on which ebxml is based. ( EbXML Electronic Business extensible Markup Language ( ecl@ss Classification standard ( EFT Electronic Funds Transfer. GLN The GLN (Global Location Number) provides a standard (EAN/UCC) means to identify legal entities, trading parties and locations to support the requirements of electronic commerce. GTIN The GTIN (Global Trade Item Number) is the foundation for the EAN.UCC System for uniquely identifying trade item (products and services). HTTP Hypertext Transfer Protocol used for the Web. IDA Interchange of Data between Administrations INCOTERM (International Commercial Terms) ISO OASIS Standard trade definitions that are most commonly used in international contracts. ( International Organization for Standardization ( Organization for the Advancement of Structured Information 75 / 82

76 OGC PDF PO RFC Rosettanet PIPS (Rosettanet Partner Interface Processes) SMEs SMTP SOAP SWIFT (Society of Worldwide Interbank Financial Telecommunications) UBL UCC (Uniform Code Council ) UML (Unified Modeling Language Standards. not-for-profit, global consortium that drives the development, convergence, and adoption of e-business standards. ( -open.org/) The Office of Government Commerce (OGC) is an independent Office of the Treasury (UK) reporting to the Chief Secretary. It is responsible for a wide-ranging programme which focuses on improving the efficiency and effectiveness of central civil Government procurement. ( Adobe Portable Document Format ( Purchase Order Request For Comment. Set of standard specifications related to the Internet. ( Set of process and message definition for e-commerce. ( Small and Medium Enterprises Simple Mail Transfer Protocol. Standard protocol for delivering s over the Internet. Simple Object Access Protocol. Protocol allowing transport of XML information on which Web Services are based. ( ) SWIFT is the industry-owned cooperative supplying secure, standardised messaging services and interface software to 7,500 financial institutions in 200 countries. ( Universal Business Language. Standard library of XML business documents (purchase orders, invoices, etc.) develop by OASIS. ( - open.org/committees/tc_home.php?wg_abbrev=ubl) Global, multi-sectoral standards for supply-chain efficiency in electronic environment. ( Standard notation for object-oriented software design. UN/EDIFACT United Nations / Electronic Data Interchange for Administration, Commerce and Transport UNSPSC United Nations Standard Products and Services Code. Classification standard for product. URI (Unified Resource Identifier) Way to identify any of those points of content, whether it be a page of text, a video or sound clip, a still or animated image, or a program. URL (Uniform Resource Locator) Most common form of URI (Web page address), which is a particular form or subset of URI called a Uniform Resource Locator (URL). VAT Value Added Tax X12 ANSI standard for the exchange of business transaction information xcbl XML Common Business Library. Royalty-free XML-based B2B standard originally developed by Commerce One. ( XML EXtensible Markup Language. ( 76 / 82

77 W3C (World Wide Web Consortium) The World Wide Web Consortium (W3C) develops interoperable technologies (specifications, guidelines, software, and tools) to lead the Web to its full potential. ( 77 / 82

78 12 APPENDIX 5 : COUNTRY CODE ISO ISO_3166-1_Country_name AFGHANISTAN ÅLAND ISLANDS ALBANIA ALGERIA AMERICAN SAMOA ANDORRA ANGOLA ANGUILLA ANTARCTICA ANTIGUA AND BARBUDA ARGENTINA ARMENIA ARUBA AUSTRALIA AUSTRIA AZERBAIJAN BAHAMAS BAHRAIN BANGLADESH BARBADOS BELARUS BELGIUM BELIZE BENIN BERMUDA BHUTAN BOLIVIA BOSNIA AND HERZEGOVINA BOTSWANA BOUVET ISLAND BRAZIL BRITISH INDIAN OCEAN TERRITORY BRUNEI DARUSSALAM BULGARIA BURKINA FASO BURUNDI CAMBODIA CAMEROON CANADA CAPE VERDE CAYMAN ISLANDS CENTRAL AFRICAN REPUBLIC CHAD CHILE CHINA CHRISTMAS ISLAND COCOS (KEELING) ISLANDS COLOMBIA COMOROS Alpha-2_Code AF AX AL DZ AS AD AO AI AQ AG AR AM AW AU AT AZ BS BH BD BB BY BE BZ BJ BM BT BO BA BW BV BR IO BN BG BF BI KH CM CA CV KY CF TD CL CN CX CC CO KM 78 / 82

79 ISO_3166-1_Country_name CONGO CONGO, THE DEMOCRATIC REPUBLIC OF THE COOK ISLANDS COSTA RICA COTE D'IVOIRE CROATIA CUBA CYPRUS CZECH REPUBLIC DENMARK DJIBOUTI DOMINICA DOMINICAN REPUBLIC ECUADOR EGYPT EL SALVADOR EQUATORIAL GUINEA ERITREA ESTONIA ETHIOPIA FALKLAND ISLANDS (MALVINAS) FAROE ISLANDS FIJI FINLAND FRANCE FRENCH GUIANA FRENCH POLYNESIA FRENCH SOUTHERN TERRITORIES GABON GAMBIA GEORGIA GERMANY GHANA GIBRALTAR GREECE GREENLAND GRENADA GUADELOUPE GUAM GUATEMALA GUINEA GUINEA-BISSAU GUYANA HAITI HEARD ISLAND AND MCDONALD ISLANDS HOLY SEE (VATICAN CITY STATE) HONDURAS HONG KONG HUNGARY ICELAND INDIA INDONESIA IRAN, ISLAMIC REPUBLIC OF Alpha-2_Code CG CD CK CR CI HR CU CY CZ DK DJ DM DO EC EG SV GQ ER EE ET FK FO FJ FI FR GF PF TF GA GM GE DE GH GI GR GL GD GP GU GT GN GW GY HT HM VA HN HK HU IS IN ID IR 79 / 82

80 ISO_3166-1_Country_name IRAQ IRELAND ISRAEL ITALY JAMAICA JAPAN JORDAN KAZAKHSTAN KENYA KIRIBATI KOREA, DEMOCRATIC PEOPLE'S REPUBLIC OF KOREA, REPUBLIC OF KUWAIT KYRGYZSTAN LAO PEOPLE'S DEMOCRATIC REPUBLIC LATVIA LEBANON LESOTHO LIBERIA LIBYAN ARAB JAMAHIRIYA LIECHTENSTEIN LITHUANIA LUXEMBOURG MACAO MACEDONIA, THE FORMER YUGOSLAV REPUBLIC OF MADAGASCAR MALAWI MALAYSIA MALDIVES MALI MALTA MARSHALL ISLANDS MARTINIQUE MAURITANIA MAURITIUS MAYOTTE MEXICO MICRONESIA, FEDERATED STATES OF MOLDOVA, REPUBLIC OF MONACO MONGOLIA MONTSERRAT MOROCCO MOZAMBIQUE MYANMAR NAMIBIA NAURU NEPAL NETHERLANDS NETHERLANDS ANTILLES NEW CALEDONIA NEW ZEALAND NICARAGUA Alpha-2_Code IQ IE IL IT JM JP JO KZ KE KI KP KR KW KG LA LV LB LS LR LY LI LT LU MO MK MG MW MY MV ML MT MH MQ MR MU YT MX FM MD MC MN MS MA MZ MM NA NR NP NL AN NC NZ NI 80 / 82

81 ISO_3166-1_Country_name NIGER NIGERIA NIUE NORFOLK ISLAND NORTHERN MARIANA ISLANDS NORWAY OMAN PAKISTAN PALAU PALESTINIAN TERRITORY, OCCUPIED PANAMA PAPUA NEW GUINEA PARAGUAY PERU PHILIPPINES PITCAIRN POLAND PORTUGAL PUERTO RICO QATAR REUNION ROMANIA RUSSIAN FEDERATION RWANDA SAINT HELENA SAINT KITTS AND NEVIS SAINT LUCIA SAINT PIERRE AND MIQUELON SAINT VINCENT AND THE GRENADINES SAMOA SAN MARINO SAO TOME AND PRINCIPE SAUDI ARABIA SENEGAL SERBIA AND MONTENEGRO SEYCHELLES SIERRA LEONE SINGAPORE SLOVAKIA SLOVENIA SOLOMON ISLANDS SOMALIA SOUTH AFRICA SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS SPAIN SRI LANKA SUDAN SURINAME SVALBARD AND JAN MAYEN SWAZILAND SWEDEN SWITZERLAND SYRIAN ARAB REPUBLIC Alpha-2_Code NE NG NU NF MP NO OM PK PW PS PA PG PY PE PH PN PL PT PR QA RE RO RU RW SH KN LC PM VC WS SM ST SA SN CS SC SL SG SK SI SB SO ZA GS ES LK SD SR SJ SZ SE CH SY 81 / 82

82 ISO_3166-1_Country_name TAIWAN, PROVINCE OF CHINA TAJIKISTAN TANZANIA, UNITED REPUBLIC OF THAILAND TIMOR-LESTE TOGO TOKELAU TONGA TRINIDAD AND TOBAGO TUNISIA TURKEY TURKMENISTAN TURKS AND CAICOS ISLANDS TUVALU UGANDA UKRAINE UNITED ARAB EMIRATES UNITED KINGDOM UNITED STATES UNITED STATES MINOR OUTLYING ISLANDS URUGUAY UZBEKISTAN VANUATU VENEZUELA VIET NAM VIRGIN ISLANDS, BRITISH VIRGIN ISLANDS, U.S. WALLIS AND FUTUNA WESTERN SAHARA YEMEN ZAMBIA ZIMBABWE Alpha-2_Code TW TJ TZ TH TL TG TK TO TT TN TR TM TC TV UG UA AE GB US UM UY UZ VU VE VN VG VI WF EH YE ZM ZW 82 / 82