[Accessibility conventions are described at the bottom of the page]

2. Parties, document types and profiles
[> 3.][< 1.4.2][^^^]
2.0 Participants and document flows
[> 2.1][> 3.][< 2.][^^][^^^]
Typically two or more trading partners agree to engage in a business transaction
[[1] - the initial UBL 2 scope is in two areas
[[2] - procurement of goods or services
 [2] - transport of goods
]]
A given business transaction may involve a number of participants (parties)
[[1] - individual, a group, or a body having a role in a business function
 [1] - a single party may play a number of different roles in a given business transaction
 [1] - all of the roles in the UBL scenarios are representative and need not actually be realized as real people or parties
]
Contexts defined for 21 roles involved in 31 document types being exchanged
[[1] - most document exchanges involve two parties
 [1] - some document exchanges involve multiple parties
 [1] - some roles are not involved in sending and receiving documents
]
Documentary scenario use case diagram outlines the roles of the many participants:
[[1] - the following image is a compressed version of the image found in the specification
[[2] - under "UBL 2.0 Context of Use" ([4.]); view it directly to see the detail
]]
[Figure 2.1: Use case diagram of all participants
The image is copied verbatim from the image in section [4.] of the specification.
23 stick figures with various labels of their roles in the process are connected with lines to 20 ovals labeled with business processes such as "sourcing", "fulfillment", "billing", etc.
The diagram overviews the prose and content found in section [4.] of the specification.
]
A given business transaction may involve a number of document exchanges
[[1] - exchanges are choreographed in a UBL scenario as only an example exchange of documents for documentary purposes to illustrate their use
 [1] - UBL does not require trading partners to engage in any particular exchange of documents
 [1] - communities and users of UBL can create their own scenarios using documents of the various document types
 [1] - communicating and negotiating the requirements for document exchanges are not part of UBL
[[2] - e.g. could be implemented by ebCPP/A partner agreements
]]
Communities of users are creating "profiles" of choreography of documents for different scenarios
[[1] - a scenario describes the objective of the interchange of documents
 [1] - the profile fulfills the scenario by describing a particular choreography of a subset of documents
 [1] - the same document can be used differently in different profiles
 [1] - the community could also customize a UBL document in different ways for each of the profiles they define
[[2] - different constructs have applicability in different scenarios
][1] - a hierarchy of profile identity:
[[2] - UBLVersionID - version of UBL
[[3] - e.g. "2.0", "2.1", etc.
][2] - CustomizationID - customization of a particular UBL version
[[3] - e.g. community
][2] - ProfileID - profile within a particular customization
[[3] - e.g. business process
][2] - each specific document type is customized for the profile
[[3] - there may be different document type customizations for different profiles within the same customization
]]]
Benefits can be realized by implementing only a single document
[[1] - e.g. Denmark realized millions of euros in savings implementing (and legislating) only Invoice and no other document types
[[2] - the Danish government already moving to support (and legislate) other document types
]]
Each document exchange is documented in the specification with sample workflows using activity diagrams:
[[1] - the vertical "columns" of activity diagrams are colloquially referred to as "swim lanes"
 [1] - document types are depicted in square-cornered boxes with underscored labels
 [1] - actions are depicted in round-cornered boxes
 [1] - the start of the process is the solid-filled circle
 [1] - the end of the process is the hollow-filled circle
]
Example workflow activity diagram for quotations excerpted from UBL documentation:
[[1] - excerpted from the specification section [4.3.2.]
]
[Figure 2.2: Sample workflow
The activity diagram shows the start of flow under "Originator or Buyer Party" swim lane, performing the "Send request for quotation" activity. This transfers the "Request for Quotation" document to the "Receive request for quotation" in the "Seller Party" swim lane. The flow continues in that lane to the "Send quotation" activity which transfers the "Quotation" document back to the "Receive quotation" activity in the "Originator or Buyer Party" lane, at which point the flow ends.
]
Find all diagrams in the UBL main documentation file under section [4.]
2.1 UBL parties
[> 2.2][< 2.0][^^][^^^]
2.1.1 Parties in sourcing-to-payment procurement cycle
[> 2.2][> 3.][< 2.0][^^][^^^]
The UBL committee characterizes a number of different parties each with possible roles:
[[1] - documented in the specification in section [4.2.1.]
 [1] - customer party
[[2] - originator role
[[3] - initiating the need for the procurement transaction
 [3] - contact point for queries
 [3] - e.g. the person needing a box of pencils
][2] - buyer role
[[3] - purchases the goods or services on behalf of the originator
 [3] - e.g. the person buying a box of pencils
][2] - delivery role
[[3] - to whom the goods or services should be delivered
 [3] - e.g. the person receiving the delivered box of pencils
][2] - debtor / accounting customer role
[[3] - responsible for payment and billing issue resolution
 [3] - e.g. the person paying for the box of pencils
]][1] - supplier party
[[2] - seller role
[[3] - responsible for handling originator and buyer services
 [3] - legally responsible for providing the goods or services
 [3] - e.g. the person selling boxes of pencils
][2] - despatch role
[[3] - from whom goods or services are to be collected
 [3] - e.g. the person delivering the box of pencils
][2] - creditor / accounting supplier role
[[3] - responsible for claims payment, billing issue resolution and settlement arrangement
 [3] - e.g. the person receiving the payment for the box of pencils
][2] - payee role
[[3] - to whom the invoice is paid
 [3] - e.g. the person receiving the money for the box of pencils
]]]
Parties (cont.)
[[1] - other party
[[2] - catalogue managing role
[[3] - party receiving a catalogue (not the originator or buyer if nothing ordered)
 [3] - e.g. a person considering buying a box of pencils
][2] - information content owner role
[[3] - responsible for integrity of information provided about an item
 [3] - e.g. the person responsible for a catalogue containing the box of pencils
][2] - receiver role
[[3] - party receiving a document
 [3] - e.g. the software receiving an application response
][2] - sender role
[[3] - party sending a document
 [3] - e.g. the software sending an application response
][2] - consignor role
[[3] - (procurement) party where goods are to be collected from
 [3] - (transport) receiver of invoice and payer of transportation service
][2] - consignee role
[[3] - receiver of goods as stipulated in the transport contract
][2] - freight forwarder role
[[3] - (procurement) arranger of the carriage of goods on behalf of consignor or consignee
 [3] - (transport) creator of invoice who bills consignor for a transportation service
][2] - carrier role
[[3] - provider of physical transport services
][2] - exporter role
[[3] - supplier of goods through an international purchase
][2] - endorser role
[[3] - government appointee with right to certify a certificate of origin
][2] - importer role
[[3] - receiver of goods through international purchase
]]]
2.2 UBL document types
[> 2.3][< 2.1.1][^^][^^^]
2.2.1 Document types in UBL
[> 2.2.2][> 2.3][> 3.][< 2.1.1][^^][^^^]
A "document type" represents a class of documents with the same logical structure
[[1] - actual documents are instances of the document type
 [1] - UBL identifies each document type by a contraction
[[2] - e.g. CatalogueItemSpecificationUpdate
]]
Each document exchange involves a transmission and reception of an XML instance
[[1] - the instance validates against the formalism declaring the structure of the class of documents defined by the document type
 [1] - the sender of the instance generates the XML instance according to the document type using the information that needs to be transmitted
 [1] - the recipient of the instance extracts the received information from within the XML instance that has been validated to be properly structured
[[2] - this may require other validation such as code list value validation and negotiated business rule validation
]]
UBL does not define how the transmission and reception of an XML instance happens
[[1] - could be by any electronic means whatsoever
 [1] - e.g. could be implemented by formal ebMS message services
 [1] - e.g. could be implemented by informal services: email, FTP, HTTP REST (Representational State Transfer), etc.
 [1] - responsibility of lower layers (see [Figure 1.2])
]
Separate document types for different business actions
[[1] - e.g. for ordering there are separate document types order, order change, order cancel, etc.
 [1] - e.g. for catalogue there are separate document types request, create, update, etc.
 [1] - this is unlike "function codes" in an EDI message where the code indicates the action of the message
]
Summary of UBL 2.0 Document Types (section [4.11.])
[[1] - the specification summarizes a description of each document, the processes involved and the roles involved
]
2.2.2 Document types for sourcing
[> 2.2.3][> 2.3][> 3.][< 2.2.1][^][^^][^^^]
Catalogue provision
[[1] - a catalogue is a document that describes items and prices
 [1] - a seller sends information regarding items available for purchase to a potential customer
 [1] - role that receives a catalogue is a catalogue managing party because of the potential (not guarantee) of a subsequent purchasing request
 [1] - request a catalogue ([4.3.1.2.], [4.3.1.3.], [4.3.1.4.])
[[2] -
CatalogueRequest
 [2] - "A document to request a Catalogue from a seller. May be either an entire new Catalogue or an update (at the discretion of the Seller)."
 [2] - processes: create catalogue, update item specification, update pricing
 [2] - submitter role: contracting party
 [2] - receiver role: seller
][1] - create a catalogue ([4.3.1.2.])
[[2] -
Catalogue
 [2] - "A document produced by a party in the procurement chain that describes items and prices. The document typically enables the transmission of information regarding pricing and catalogue details for goods and services offered by a seller to a buyer."
 [2] - process: create catalogue
 [2] - submitter role: seller
 [2] - receiver role: contracting party
][1] - update a catalogue item specification ([4.3.1.3.])
[[2] -
CatalogueItemSpecificationUpdate
 [2] - "A document to update information about Items in an existing Catalogue."
 [2] - process: update catalogue item specification
 [2] - submitter role: seller
 [2] - receiver role: contracting party
][1] - update catalogue pricing ([4.3.1.4.])
[[2] -
CataloguePricingUpdate
 [2] - "A document to update information about Prices in an existing Catalogue."
 [2] - process: update catalogue pricing
 [2] - submitter role: seller
 [2] - receiver role: contracting party
][1] - delete catalogue ([4.3.1.5.])
[[2] -
CatalogueDeletion
 [2] - "A document to cancel an entire Catalogue. All previous Catalogue information becomes obsolete."
 [2] - process: delete catalogue
 [2] - submitter role: seller
 [2] - receiver role: contracting party
]]
Customer-initiated sourcing and punchout
[[1] - the originator may explicitly request a quotation (customer-initiated) or may directly accesses a seller's application by some mechanism outside the scope of UBL (punchout), both returning a quotation
 [1] - request a quotation ([4.3.2.])
[[2] -
RequestForQuotation
 [2] - "A document to request pricing and availability information about goods or services. The document may requesting a quote on specified goods or services."
 [2] - process: customer initiated sourcing
 [2] - submitter role: originator
 [2] - receiver role: seller
][1] - deliver a quotation ([4.3.2.], [4.3.3.])
[[2] -
Quotation
 [2] - "A document to specify pricing and availability information about goods or services. The document which, with a view to concluding a contract, sets out the conditions under which the goods are offered."
 [2] - processes: customer initiated sourcing, sourcing punchout
 [2] - submitter role: seller
 [2] - receiver role: originator
]]
2.2.3 Document types for ordering
[> 2.2.4][> 2.3][> 3.][< 2.2.2][^][^^][^^^]
Ordering
[[1] - buyer places an order to the seller ([4.4.])
[[2] -
Order
 [2] - " A document that contains information directly relating to the economic event of ordering products. The document by means of which a customer initiates a transaction with a supplier for the supply of goods or services as specified, according to conditions set out in an offer, or otherwise known to the customer."
 [2] - process: ordering
 [2] - submitter role: buyer
 [2] - receiver role: seller
][1] - seller confirms receipt with either commitment to fulfill or with rejection ([4.4.])
[[2] -
OrderResponseSimple
 [2] - "A document responding to the customer to indicate simple acceptance or rejection of an entire order. The document acknowledging an undertaking to fulfill an order and confirming conditions or acceptance of conditions."
 [2] - process: ordering
 [2] - submitter role: seller
 [2] - receiver role: buyer
][1] - seller proposes changes to an order ([4.4.])
[[2] -
OrderResponse
 [2] - "A document responding to the customer to indicate detailed responses against a single order already received."
 [2] - process: ordering
 [2] - submitter role: seller
 [2] - receiver role: buyer
][1] - buyer initiates a change to an established order ([4.4.], [4.5.2.])
[[2] -
OrderChange
 [2] - "A document that contains information directly relating to the economic event of changing an order already sent."
 [2] - processes: ordering, fulfillment with receipt advice
 [2] - submitter role: buyer
 [2] - receiver role: seller
][1] - buyer cancels an established order ([4.4.], [4.5.2.])
[[2] -
OrderCancellation
 [2] - "A document that advises either party of the cancellation of an Order."
 [2] - processes: ordering, , fulfillment with receipt advice
 [2] - submitter role: buyer
 [2] - receiver role: seller
]]
2.2.4 Document types for fulfillment
[> 2.2.5][> 2.3][> 3.][< 2.2.3][^][^^][^^^]
Fulfillment
[[1] - despatch party confirms to delivery party the shipment of items ([4.5.])
[[2] -
DespatchAdvice
 [2] - "A document that describes the content of goods shipped. Document/message by means of which the seller or consignor informs the consignee about the despatch of goods."
 [2] - process: fulfillment
 [2] - submitter role: despatch
 [2] - receiver role: delivery
][1] - delivery party confirms to despatch party the receipt of items ([4.5.], [4.5.2.])
[[2] -
ReceiptAdvice
 [2] - "A document that advises the goods received and accepted by the buyer. The document acknowledges the receipt of goods and in addition may indicate receiving conditions."
 [2] - processes: fulfillment, fulfillment with receipt advice
 [2] - submitter role: delivery
 [2] - receiver role: despatch
]]
2.2.5 Document types for billing
[> 2.2.6][> 2.3][> 3.][< 2.2.4][^][^^][^^^]
Traditional billing
[[1] - raise an invoice
 [1] - supplier (creditor) invoices customer (debtor) when goods or services are delivered or provided, ([4.6.2.1.], [4.6.2.2.])
[[2] -
Invoice
 [2] - "A document claiming payment for goods or services supplied under conditions agreed between the supplier and the customer. In most cases this document describes the actual financial commitment of goods or services ordered from the supplier."
 [2] - processes: billing using credit notes, billing using debit notes
 [2] - submitter role: supplier accounting party
 [2] - receiver role: customer accounting party
]]
Credit note
[[1] - issue a credit note
 [1] - seller (creditor) indicates to customer (debtor) that an invoice is incorrect ([4.6.2.1.], [4.6.3.1.])
[[2] -
CreditNote
 [2] - "A document for a supplier to specify a reduced payment. The document for providing credit information to the relevant party."
 [2] - processes: billing using credit notes, self billing using debit notes
 [2] - submitter role: supplier accounting party
 [2] - receiver role: customer accounting party
]]
Debit note
[[1] - issue a debit note
 [1] - customer (debtor) indicates to seller (creditor) that an invoice is incorrect([4.6.2.2.])
[[2] -
DebitNote
 [2] - "A document for a customer to specify a reduced payment. The document for providing debit information to the relevant party."
 [2] - process: billing using debit notes
 [2] - submitter role: customer accounting party
 [2] - receiver role: supplier accounting party
]]
Self-billing (a.k.a. "billing on receipt")
[[1] - no change in roles, only in the initiation of the invoice document itself
 [1] - customer (debtor) raises an invoice in the name and on behalf of the supplier (creditor) ([4.6.3.1.], [4.6.3.2.])
[[2] -
SelfBilledInvoice
 [2] - "A document provided by a customer, in the name and on behalf of the supplier, describing the claim for payment for goods or services supplied under conditions agreed between the supplier and the customer."
 [2] - processes: self billing using credit notes, self billing using self billed credit notes
 [2] - submitter role: customer accounting party
 [2] - receiver role: supplier accounting party
][1] - customer (debtor) raises an credit note in the name and on behalf of the supplier (creditor) ([4.6.3.2.])
[[2] -
SelfBilledCreditNote
 [2] - "A document for a customer to specify a reduced payment in a Self Billing environment. The document indicates that the customer is claiming credit in a self billing environment."
 [2] - process: self billing using self billed credit notes
 [2] - submitter role: customer accounting party
 [2] - receiver role: supplier accounting
][1] - the process may instead involve a regular credit note rather than a self-billed credit note
]
Freight billing
[[1] - freight forwarder initiates the billing of the consignor for logistic services ([4.6.4.])
[[2] -
FreightInvoice
 [2] - "A document issued by a transport operation specifying freight costs and charges incurred for a transport operation and stating conditions of payment."
 [2] - process: freight billing
 [2] - submitter role: freight forwarder
 [2] - receiver role: consignor or consignee
]]
2.2.6 Document types for payment
[> 2.2.7][> 2.3][> 3.][< 2.2.5][^][^^][^^^]
Account Payment (remittance)
[[1] - notify a remittance (funds transfer)
 [1] - payee (usually creditor) is notified of funds transferred against the account of the debtor ([4.7.])
[[2] -
RemittanceAdvice
 [2] - "A document to specify that funds have been transferred from the customer to the supplier. The document advising of the remittance of payment."
 [2] - process: payment
 [2] - submitter role: customer accounting party and/or payee
 [2] - receiver role: supplier accounting party and/or payee
]]
Account Statement
[[1] - notify the account status
 [1] - debtor is notified of the status of billing ([4.7.1.])
[[2] -
Statement
 [2] - "A document to list the financial transactions between customer and supplier and notify of their status. This is a Statement of Account and not intended as a summary Invoice."
 [2] - process: report state of accounts
 [2] - submitter role: supplier accounting party
 [2] - receiver role: customer accounting party
]]
Account Reminder
[[1] - notify the continued need for a payment
 [1] - debtor is reminded of the need for a payment ([4.6.5.])
[[2] -
Reminder
 [2] - "A document used to request payment."
 [2] - process: reminder for payment
 [2] - submitter role: supplier accounting party and/or payee
 [2] - receiver role: customer accounting party and/or payee
]]
2.2.7 Document types for transport services
[> 2.2.8][> 2.3][> 3.][< 2.2.6][^][^^][^^^]
Transport
[[1] - ordering of logistical services for international trade
]
Forwarding
[[1] - instructions for the transportation services
 [1] - consignor (shipper) requests services of forwarder, carrier, shipping agent, etc. ([4.8.])
[[2] -
ForwardingInstruction
 [2] - "The document used by any party who gives instructions for the transportation services required for a consignment of goods to any party who is contracted to provide the transportation services. The parties who issue this document are commonly referred to as the shipper or consignor while the parties who receive this document are forwarders, carriers, shipping agents, etc. Note that this document may also be issued by a forwarder or shipping agent in their capacity as a Transport Service Buyer. This document may be used to arrange for the transportation (1) of different types of goods or cargoes; (2) whether containerized or non-containerized; (3) through different modes of transport including multi-modal, and (4) from any origin to any destination. The document issued to a freight forwarder, giving instructions regarding the action to be taken by the forwarder for the forwarding of goods described therein."
 [2] - process: initiate transport services
 [2] - submitter role: consignor (or consignee), freight forwarder
 [2] - receiver role: freight forwarder, carrier
]]
Status
[[1] - status information for the transportation services
 [1] - forwarder, carrier, shipping agent, etc. indicates status of transportation ([4.8.], [4.10.])
[[2] -
TransportationStatus
 [2] - "A message to report the transport status and/or change in the transportation status (i.e. event) between agreed parties."
 [2] - processes: initiate transport services, report status of goods
 [2] - submitter role: freight forwarder
 [2] - receiver role: consignee, consignor
]]
Bill of lading
[[1] - details of transportation, charges, terms and conditions of service
 [1] - physical transportation provider (carrier) instructs services requestor (shipper, consignor, etc) ([4.8.])
[[2] -
BillOfLading
 [2] - "A document issued by the party who acts as an agent for the carrier or other agents, to the party who gives instructions for the transportation services (shipper, consignor, etc.) stating the details of the transportation, charges, and terms and conditions under which the transportation service is provided. The party issuing this document does not necessarily provide the physical transportation service. It corresponds to the information on the Forwarding Instructions. It is used for any mode of transport. A Bill of Lading may serve as a contractual document between the parties for the transportation service. The document evidences a contract of carriage by sea and the acceptance of responsibility for the goods by the carrier, and by which the carrier undertakes to deliver the goods against surrender of the document. A provision in the document that the goods are to be delivered to the order of a named person, or to order, or to bearer, constitutes such an undertaking. A negotiable document that evidences a contract of carriage by sea and the taking over or loading of goods by carrier, and by which carrier undertakes to deliver goods against surrender of the document."
 [2] - process: initiate transport services
 [2] - submitter role: freight forwarder, carrier
 [2] - receiver role: consignor (or consignee), freight forwarder
][1] - almost identical to waybill but the bill of lading has legal status
[[2] - a bill of lading carries title and travels with the goods
 [2] - whoever holds the bills owns the goods
]]
Waybill
[[1] - non-negotiable and un-assignable details of transportation, charges, terms and conditions used as a cargo receipt
[[2] - not required to be surrendered at destination in order to pick up the cargo
][1] - physical transportation provider (carrier) informs services requestor (shipper, consignor, etc) ([4.8.])
[[2] -
Waybill
 [2] - "A document issued by the party who acts as an agent for the carrier or other agents to the party who gives instructions for the transportation services (shipper, consignor, etc.) stating the details of the transportation, charges, and terms and conditions under which the transportation service is provided. The party issuing this document may not provide the physical transportation service. It corresponds to the information on the Forwarding Instructions. It is used for all modes of transport. It may serve as a contractual document between the parties for the transportation service. A Waybill is a non-negotiable document evidencing the contract for the transport of cargo. It provides information similar to Bill of Lading but is not negotiable and cannot be assigned to a third party."
 [2] - process: initiate transport services
 [2] - submitter role: freight forwarder, carrier
 [2] - receiver role: consignor (or consignee), freight forwarder
][1] - almost identical to bill of lading but the waybill is just information and has no legal status
[[2] - waybill documents arrive well ahead of the goods and carry no title
]]
Packing list
[[1] - state the distribution of goods in individual packages ([4.8.])
[[2] -
PackingList
 [2] - "A document stating the detail of how goods are packed. The document specifies the distribution of goods in individual packages (in trade environment the despatch advice message is used for the packing list)."
 [2] - process: initiate transport service
 [2] - submitter role: consignor
 [2] - receiver role: freight forwarder
]]
2.2.8 Document types for origin certification
[> 2.2.9][> 2.3][> 3.][< 2.2.7][^][^^][^^^]
Certification of origin of goods
[[1] - a Certificate of Origin (CoO) is required by governments declaring that goods in a particular international shipment are of a certain origin
 [1] - exporter signs CoO and applies it to authority
 [1] - endorser (issuer of CoO) verifies claims of origin
 [1] - importer received CoO
 [1] - certify the origin of goods ([4.9.])
[[2] -
CertificateOfOrigin
 [2] - "A document required by governments, declaring that goods in a particular international shipment are of a certain origin. Customs offices will use this document to determine whether or not a preferential duty rate applies on the products being imported and whether a shipment may be legally imported during a specific quota period. The document identifies which authority or body authorized to issue it certifies expressly that the goods to which the certificate relates originate in a specific country. The word 'country' may include a group of countries, a region, or a part of a country. This certificate may also include a declaration by the manufacturer, producer, supplier, exporter, or other competent person."
 [2] - processes: certification of origin of goods
 [2] - submitter role: exporter, issuer
 [2] - receiver role: issuer, importer
]]
2.2.9 Document types for exchange support
[> 2.3][> 3.][< 2.2.8][^][^^][^^^]
Inquiry detail
[[1] - wrap an arbitrary attachment in a UBL document while referencing the UBL document to which the attachment applies
[[2] -
AttachedDocument
 [2] - "In effect a 'wrapper' UBL envelope that may contain anything. This allows a referenced document to be included in the package of documents being exchanged."
 [2] - processes: all
 [2] - submitter role: sender
 [2] - receiver role: receiver
]]
Response detail
[[1] - indicate an application's response to a transaction
[[2] -
ApplicationResponse
 [2] - "A document to indicate the application's response to a transaction at the business application level concerning the processing of a document."
 [2] - processes: all
 [2] - submitter role: sender
 [2] - receiver role: receiver
]]
2.3 Customizations and profiles of UBL
[> 3.][< 2.2.9][^^][^^^]
2.3.1 Customizations and profiles of UBL
[> 2.3.2][> 3.][< 2.2.9][^^][^^^]
A customization of UBL for a community is a collection of profiles
[[1] - a hierarchy of profile identity:
[[2] - UBLVersionID - version of UBL
[[3] - e.g. "2.0", "2.1", etc.
][2] - CustomizationID - customization of a particular UBL version
[[3] - e.g. community
][2] - ProfileID - profile within a particular customization
[[3] - e.g. business process
][2] - each specific document type is customized for the profile
[[3] - there may be different document type customizations for different profiles within the same customization
]]]
Profile typically includes a prescribed message exchange choreography
[[1] - which documents are sent in which order in response to other documents
]
Should include prescribed code list conformance criteria
[[1] - an itemized list of all codes and identifiers agreed upon by the community
 [1] - may be restricted by trading partners to stay within the community definition
 [1] - may be extended by trading partners to stay
]
As small as a single document type
[[1] - a single company can create a single profile for use by any of their customers to submit to the company
]
As big as a government initiative
[[1] - e.g. the OIOUBL legislation in Denmark for public procurement
 [1] - recall [The Danish UBL experience - Section 1.3.3]
 [1] - example of a migration from simple to complex requirements
[[2] - OIOXML implements only a single document type (invoice)
 [2] - OIOUBL implements 15-20 document types
]]
As major as a concerted pan-European effort for government procurement
[[1] - e.g. the PEPPOL initiative to prototype BII requirements to meet European 2010 requirements for government electronic commerce
 [1] - recall [Government procurement - Section 1.3.4]
]
Layered approach to the library specification
[[1] - not all UBL document types are included in the NES specification
 [1] - the NES common library is a derivation of the UBL common library
 [1] - the NES document libraries are derivations of the UBL document libraries
 [1] - an NES document type has constructs from the NES common library and from the NES document library
]
Profiles of different definitions of the same document types
[[1] - different profiles of transactions, each with business rules and a set of document types
[[2] - e.g. "invoice only" contains only the invoice document type
 [2] - e.g. "basic billing" contains both invoice and credit note document types
 [2] - the two invoice document types are different in each profile because of the demands of information exchange in the business flows
][1] - ISO/IEC 19757-3 Schematron is layered on top of schemas for contextually limiting the document contents based on the profile
[[2] - the Schematron schema asserts that for a given profile, an NES construct allowed in the document in other profiles is disallowed in the given profile's version of the document
]]
[Figure 2.3: NES Definitions
Boxes representing the UBL definitions for the common library and each of the document types are shown across the top of the diagram.
Below some of these are NES generic definitions for those documents supported by the committee.
Below that are groupings of documents, grouped by profile (the two shown are "Invoice Only" and "Billing") in which different collections of documents make reference to the generic definitions.
]
2.3.2 NES/BII customizations and profiles
[> 3.][< 2.3.1][^][^^][^^^]
North European Subset (NES)
[[1] - [http://www.nesubl.eu/]
 [1] - governments of Denmark, Finland, Sweden, Norway, Iceland and England
 [1] - work products stopped being produced mid-2007
 [1] - all NES work is being migrated to the BII project
]
Profile 1: Catalogue Only
[[1] - Catalogue
 [1] - Application Response
]
Profile 2: Catalogue with Updates
[[1] - Catalogue
 [1] - Catalogue Item Specification Update
 [1] - Catalogue Pricing Update
 [1] - Application Response
]
Profile 3: Basic Order Only
[[1] - Order (basic)
]
Profile 4: Basic Invoice Only
[[1] - Invoice (basic)
]
Profile 5: Basic Billing
[[1] - Invoice (basic)
 [1] - Credit Note (basic) to match the transaction.
]
Profile 6: Basic Procurement
[[1] - Order (basic)
 [1] - Order Response Simple
 [1] - Invoice (basic)
 [1] - Credit Note (basic)
]
Profile 7: Simple Procurement
[[1] - Order (library level)
 [1] - Order Response Simple
 [1] - Invoice (library level)
 [1] - Credit Note (library level)
 [1] - Application Response
]
Profile 8: Basic Billing with Dispute Response
[[1] - Invoice (basic)
 [1] - Credit Note (basic)
 [1] - Application Response
]
Business Interoperability Interfaces on public procurement in Europe (WS/BII)
[[1] - [http://www.en.ds.dk/bii]
 [1] - includes work from Spain CODICE project to cover pre-award processes and documents
 [1] - includes work of North European Subset to cover post-award processes and documents
]
Defined profiles with document types:
[[1] - each profile specifies the message flow (choreography)
 [1] - each profile specifies the requirements for the message content
]
Pre-award profiles
[[1] - Tender Notification Basic (BII14)
 [1] - Tender Notification Advanced (BII10)
 [1] - Pre-qualification and Tender Invitation (BII11)
 [1] - Tendering Simple (BII12)
]
Post-award profiles
[[1] - Catalogue only (BII01)
 [1] - Catalogue with update (BII02)
 [1] - Basic Order only (BII03)
 [1] - Basic Invoice only (BII04)
 [1] - Basic billing (BII05)
 [1] - Basic procurement (BII06)
 [1] - Simple procurement (BII07)
 [1] - Basic billing with dispute (BII08)
 [1] - Advanced Procurement with dispatch (BII13)
 [1] - Customs Bill (BII09)
 [1] - Scanned Invoice (BII15)
 [1] - Catalogue Deletion (BII16)
 [1] - Multi-Party Catalogue (BII17)
 [1] - Punch-out (BII18)
 [1] - Advanced Procurement (BII19)
 [1] - Quote request (BII20)
 [1] - Statement (BII21)
]
The above list is excerpted from the CEN WS-BII-WG1 phase 2 report - Report 1, Version 2.0 (undated).


This is an accessible version of Crane's commercial training material. The content has been specifically designed to assist screen reader software in viewing the entire textual content. Figures are replaced with text narratives.

Navigation hints are in square brackets:
[Tx.x] and [Fx.x] are textual representations of the applicability icons;
[digit] indicates list depth for nested lists;
[link [URL]] indicates the URL of a hyperlink if different than link;
[EXAMPLE] indicates an example listing of code;
[FIGURE] indicates the presence of a figure replaced by its description;
[>] jumps forward;
[<] jumps backward;
[^] jumps to start of the section;
[^^] jumps to the start of the chapter;
[^^^] jumps to the table of contents.
Suggestions for improvement are welcome: [info@CraneSoftwrights.com]
Book sales: [http://www.CraneSoftwrights.com/links/trn-acc.htm]
Information: [http://www.CraneSoftwrights.com/links/info-acc.htm]
This content is protected by copyright and, as there are no means to protect this accessible version from plagiarism, please do not make any commercial edition available to others.

+//ISBN 1-894049::CSL::Presentation::UBL//DOCUMENT Practical Universal Business Language Deployment 2009-02-12 13:50UTC//EN
Practical Universal Business Language Deployment
Third Edition - 2009-02-12
ISBN 978-1-894049-23-8
Copyright © Crane Softwrights Ltd.