Universal Business Language Version 2.1

The terms Core Component (CC), Basic Core Component (BCC), Aggregate Core Component (ACC), Association Core Component (ASCC), Business Information Entity (BIE), Basic Business Information Entity (BBIE), and Aggregate Business Information Entity (ABIE) are used in this specification with the meanings given in [CCTS].

The terms Object Class, Property Term, Representation Term, and Qualifier are used in this specification with the meanings given in [ISO11179].

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].

One of the following identifiers may be used to identify each Item (for example, a product):

The Item may be further distinguished by the specification of Measurement(s) or Physical Attribute(s). This enables specification of the following kinds of item:

Certain Items may be identified and ordered as individual, unique objects—for example, a specific car rather than a make and model of a car. This form of identification may also be needed for product tracing (e.g., perishable goods) or because of the nature of the commodity (e.g., used, collectible, specialized, or rare).

In data modeling terms, an Item Instance is an extension of an Item.

For any given Item, price ranges by amount, quantity, location, etc., are specified by the Seller during the sourcing stage. They are not repeated back to the Seller during Ordering; only the active price is specified.

In some cases, the Buyer may not know the Item Price, in which case it is not specified. This makes a detailed response from the Seller necessary; see Order Response.

Although ordered items may include Hazardous items, it is not necessary to specify information related to Hazardous status at the order stage. The Buyer may not be aware of the nature of the Item. Indication of the Hazardous nature of the Item, and any relevant information, would be indicated in the Despatch Advice and Transportation documents.

In UBL, a party is defined as an individual, a group, or a body having a role in a business function. Dependent on the business process, a Party may play various roles in the document exchange. For a list of UBL parties and their roles, see Section 2.19, “Party Roles”.

Some textual components, such as Notes and Description, may be specified in several languages. Each should be a separate occurrence of the component, using the language attribute to define its presentation. However, multiple occurrences of the same textual components should not be in the same language.

The Tendering process optionally begins with publication of a Prior Information Notice prepared by a Contracting Authority to declare the intention to buy goods, services, or works during a specified period. The purpose of this step (if implemented) is to reduce preparation time when an actual Contract Notice is published (see Section 2.3.2, “Contract Information Notification”).

Figure 3. Contract Information Preparation

The process of Notification includes the publication by the Contracting Authority of a Contract Notice to announce the project to buy goods, services, or works. The details shown here are specific to the EU, which requires contracts over a certain amount (Harmonized contracts) to be published in the Official Journal of the EU. Other tendering contexts will differ in their publication requirements.

Figure 4. Contract Information Notification

In some procedures, the Contracting Authority invites economic operators to participate in a contest by sending them an invitation to tender using a Call for Tenders to define the procurement project to buy goods, services, or works during a specified period. The Call For Tenders may be sent jointly with an unstructured letter of invitation to tender.

Figure 5. Invitation to Tender

The economic operator sends a Tenderer Qualification to the Contracting Authority to define its own situation or status relating to the requirements of the Contracting Authority for a specific tendering process. The Contracting Authority uses the Tenderer Qualification Response to notify the Tenderer of its admission to or exclusion from the tendering process.

Figure 6. Submission of Qualification Information

A Tenderer submits one or more Tender documents that offer a tender to the Contracting Authority for bid. The Contracting Authority responds with a Tender Receipt to notify the reception of the tender for a tendering process. The date and time of the Tender Receipt are significant, because tendering procedures usually have tight deadlines for tender presentation.

Figure 7. Submission of Tenders

The awarding of tenders takes place in three phases.

First, the Contracting Authority notifies each tenderer of its success or failure in winning the contract, using the Awarded Notification document to communicate the contract award to the winning tenderer or the Unawarded Notification document to communicate that the contract has been awarded to another tenderer.

Figure 8. Award Notification

Second, the Contracting Authority causes a Contract Award Notice to be published to announce the awarding of a procurement project.

Figure 9. Award Publication

Finally, the Tenderer sends a Guarantee Certificate to notify the deposit of a guarantee.

Figure 10. Guarantee Deposit

Catalogue provision is the case where a Provider sends information regarding items available for purchase to a Receiver. This may be on request or unsolicited. Because they are only potential purchasers, a Receiver may never become a Customer Party.

2.4.2.1. Create Catalogue

The process of creating a Catalogue is shown in the following diagram.

Figure 11. Create Catalogue Process

2.4.2.2. Update Catalogue Item Specification

The process of updating a Catalogue Item Specification is shown in the following diagram.

Figure 12. Update Item Specification Process

2.4.2.3. Update Catalogue Pricing

The process of updating Catalogue pricing is shown in the following diagram.

Figure 13. Update Catalogue Pricing Process

2.4.2.4. Delete Catalogue

Deletion of a Catalogue is shown in the following diagram.

Figure 14. Delete Catalogue Process

2.4.2.5. Punchout

Punchout is a technological innovation whereby an Originator is able to directly access a Seller’s application from within their own procurement application.

Figure 15. Punchout Sourcing Process

The Originators leave (“punch out” from) their system and interact with the Seller’s catalogue to locate and order products, while their application transparently gathers pertinent information.

While conceptually the punchout request is a form of Request for Quote, the exchange transaction is tightly coupled to the specific catalogue application and is considered outside the scope of UBL.

The Order Response Simple is the means by which the Seller confirms receipt of the Order from the Buyer, indicating either commitment to fulfil without change or that the Order has been rejected.

Proposed changes to an Order by the Seller are accomplished through the full Order Response document.

The Order Response proposes to replace the original Order. It reflects the entire new state of an order transaction.

It also is the means by which the Seller confirms or supplies Order-related details to the Buyer that were not available to, or specified by, the Buyer at the time of ordering. These may include:

The Seller may advise on replacements, substitutes, or other necessary changes using the Order Response.

The Buyer may change an established Order in two ways, subject to the legal contract or trading partner agreement: first, by sending an Order Change, or second, by sending an Order Cancellation (see Section 2.6.5, “Order Cancellation”) followed by a new, complete replacement Order.

An Order Change reflects the entire current state of an order transaction.

Buyers may initiate a change to a previously accepted order for various reasons, such as changing ordered items, quantity, delivery date, ship-to address, etc. Suppliers may accept or reject the Order Change using either Order Response or Order Response Simple.

At any point of the process, a Buyer may cancel an established order transaction using the Order Cancellation document. Legal contracts, trading partner agreements, and business rules will determine the point at which an Order Cancellation will be ignored (e.g., at the point of manufacture or the initiation of the delivery process). Given the agreements and rules, an Order Cancellation may or may not be an automated business transaction. The terms and conditions of contract formation for business commitments will dictate which, if any, of these restrictions or guidelines will apply.

The Despatch Advice is sent by the Despatch Party to the Delivery Party to confirm shipment of items.

The Despatch Advice provides for two situations:

Additionally, in either case, the Despatch Advice may advise:

Despatch Lines of the Despatch Advice need not correspond one-to-one with Order Lines, and are linked by a reference. The information structure of the Despatch Advice may result in multiple Despatch Lines from one Order Line. Equally, partial despatch may result in some Order Lines not being matched by any Line in a Despatch Advice.

Within a Despatch Advice, an Item may also indicate the Country of Origin and the Hazardous nature of the Item.

The Receipt Advice is sent by the Delivery Party to the Despatch Party to confirm receipt of items and is capable of reporting shortages or damaged items.

Figure 19. Fulfilment with Receipt Advice Process

The Receipt Advice provides for two situations. For ease of processing claimed receipt against claimed delivery, it must be organised in the same way as the corresponding Despatch Advice:

The Receipt Advice allows the Delivery Party to state any shortages from the claimed despatch quantity and to state any quantities rejected for a given reason.

The Invoice is normally issued on the basis of one despatch event triggering one invoice. An Invoice may also be issued for pre-payment on a whole or partial basis. The possibilities are:

The Invoice only contains the information that is necessary for invoicing purposes. It does not reiterate any information already established in the Order, Order Change, Order Response, Despatch Advice, or Receipt Advice that is not necessary when invoicing. If necessary, the Invoice refers to the Order, Despatch Advice, or Receipt Advice by a Reference for those documents.

Taxation on the Invoice allows for compound taxes, the sequence of calculation being implied by the sequence of information repeated in the data stream (e.g., Energy tax, with VAT—Value Added Tax—superimposed).

Charges may be specified either as a lump sum or by percentage applied to the whole Invoice value prior to calculation of taxes. Such charges cover:

Each Invoice Line refers to any related Order Line(s) and may also refer to the Despatch Line and/or Receipt Line.

Traditional billing is where the supplier invoices the customer when the goods are delivered or the services provided. In this case, the invoice may be created at the time of despatch or when the Delivery Party acknowledges that the goods have been received (using a Receipt Advice).

When there are discrepancies between the Despatch Advice, Receipt Advice, and/or the Invoice and the goods actually received, or the goods are rejected for quality reasons, the customer may send an Application Response or a Debit Note to the supplier. The supplier may then issue a Credit Note or another Invoice as required.

A Credit Note or Debit Note may also be issued in the case of retrospective price change.

Credit Notes or Debit Notes may be also issued after the Billing collaboration (as part of the Payment collaboration).

2.8.2.1. Billing Using Credit Notes

Billing using Credit Notes is shown in the following diagram.

Figure 20. Billing with Credit Note Process

When using Credit Notes, the Supplier (in their Accounting role) is responsible for specifying the tax requirements.

2.8.2.2. Billing Using Debit Notes

Billing using Debit Notes is shown in the following diagram.

Figure 21. Billing with Debit Note Process

When using Debit Notes, both the Supplier (in their Accounting role) and the Customer (in their Accounting role) are responsible for providing taxation information.

A self billing process is where a Customer “invoices” itself, in the name and on behalf of the Supplier, and provides the Supplier with a copy of the self billed invoice.

2.8.3.1. Self Billing Using Credit Notes

Self Billing using Credit Notes is shown in the following diagram.

Figure 22. Self Billing with Credit Note Process

If the Supplier finds that the Self Billed Invoice is incorrect, e.g., wrong quantities or wrong prices, or if the goods have not been invoiced at all, it may send an Application Response or a Credit Note to the Customer. The customer may then verify whether the adjustment is acceptable or not and consequently issue another Self Billed Invoice or a Self Billed Credit Note.

2.8.3.2. Self Billing Using Self Billed Credit Notes

Self Billing using Self Billed Credit Notes is shown in the following diagram.

Figure 23. Self Billing with Self Billed Credit Note Process

When using Self Billed Credit Notes, the Customer is raising the Self Billed Credit Note in the name and on behalf of the Supplier. Therefore the Supplier and the Customer are still both responsible for providing taxation information.

A Reminder may be used to notify the Customer of accounts due to be paid.

Figure 24. Reminder for Payment Process

A Statement of Account may be used to notify the Accounting Customer of the status of the billing.

Figure 28. Statement Process

The Collaboration Arrangement is the preparatory step that defines the scope of the project, assigns roles, establishes procedures for data interchange, and issues identification and resolution. The following actions are performed through meetings and agreements:

Figure 30. CPFR Steps 1 and 2

The first step of the CPFR Process continues with the exchange of messages containing purchase conditions. (In this initial OASIS public review build, these are assumed to be generic purchase condition messages. A UBL document type for Purchase Conditions is planned for addition in the second public review cycle.) Afterwards, for determining the exception criteria that should be monitored and handled during the execution, Exception Criteria messages are exchanged. Exchange of Exception Criteria Revision messages continues until the criteria are accepted by both sides.

Figure 31. Establish Collaborative Relationships

In CPFR Step 2 (the Joint Business Planning phase) there are two messages that should be exchanged and agreed upon: Retail Event and Trade Item Location Profile. The revisions are exchanged until an agreement is achieved.

Figure 32. Create Joint Business Plan

CPFR Step 2 helps the buyer and seller agree to the event details and calendar that meet their joint business and collaboration objectives. The objective of the event calendar is to ensure that events are planned to achieve the optimal results and to enable both parties to plan the execution of the event more accurately, from the preparation of advertising and displays to the production and delivery of the promotional stock.

In CPFR Step 3, the Sales Forecast is generated. Following Option A, Conventional Order Management, from the CPFR implementation scenarios (see [CPFRoverview], Table 3), the responsible partner for the generation of Sales Forecast is the Seller. Having Event Calendar information and the Delivery Plan already in their system, there are two more kinds of information that the Seller needs for an effective Sales Forecast: POS Data and DC Data. As shown in Figure 25, both of these pieces of information are sent within a Product Activity Message. This time there is no revision of the messages because these messages contain statistical and historical information collected previously by the Buyer.

Figure 33. CPFR Steps 3, 4, and 5

Based on the event details (dates, products, tactics, etc.) and using the available data source(s), a volume estimate/forecast is created for each product/store combination included in the scope of the event by the Seller. During the calculation, sales forecasting algorithms make use of the coefficients for causal factors based on the event history. Once the Sales Forecast suggestion is generated and sent to the Buyer, the Buyer revises it and might recommend some changes on the Forecast. The Forecast Revision message exchange continues until the forecast is agreed by both sides.

Figure 34. Create Sales Forecast

On average, six weeks elapse between Sales Forecast Generation and Order Generation. During this period, both sides observe changes to the conditions. If one of the partners detects an exception invalidating the exception criteria defined in CPFR Step 1, it sends an Exception Notification message to the other party. Exceptional circumstances that may be communicated between trading partners include deviations between planned impacts (either between buyer and seller, or between subsequent generations of planned impacts from the same trading partner), as well as deviations between planned and actual impacts. It should be noted that both sides might detect an exception, and therefore both sides should be capable of sending and receiving exceptions. Of course, for specific implementations if the collaborating parties want to change this behaviour, they can customize the process so that one partner will be responsible for the generation of the exception notifications.

CPFR Step 4 is solely composed of the exception generation and receiving activity. CPFR Step 5, on the other hand, is the resolution of the Exceptions.

Figure 35. Exception Handling

If there is no Exception Notification Message within the defined period, the process continues with Order Forecast Generation (CPFR Step 6).

In the supply chain process, it is important for sales forecasts that are created to be converted into the shipment (order) forecasts that can then be used in the production planning processes at the manufacturing locations and be incorporated into the ordering processes at the retailer. As shown in Figure 28, the responsibility for creating Order Forecast belongs to the Seller per Option A of the CPFR implementation scenarios (see [CPFRoverview], Table 3). Sales forecasts can be transformed into order forecasts by incorporating inventory status information, possible retail event plans, and current point of sale data. Therefore, Buyer sends the updated versions of the Retail Event, Inventory Status, and POS Data to the Seller.

Figure 36. CPFR Steps 6, 7, 8 and 9

After the Seller creates the Order Forecast using the obtained data, it sends the forecast to the Buyer. The Buyer checks the order forecast and sends back a revision document which includes update requests if necessary. The exchange of Order Forecast Revisions continues until there are no further update requests and the Order Forecast is agreed by both sides.

Figure 37. Create Order Forecast

After the Order Forecast is frozen, the process continues with the exception detection activity (CPFR Step 7). The exception detection process that follows Order Forecast is similar to process described earlier for exeption detection following Sales Forecast (see Section 2.12.2, “Sales Forecast Generation and Exception Handling”). The only difference between the Order Forecast and Sales Forecast exceptions is the content of the exceptions.

CPFR Step 8, Order Forecast Exception Resolution activity, is handled similarly to Sales Forecast Exception Resolution.

Figure 38. Identifying and Resolving Exceptions for Order Forecast

Figure 39. Exception Monitor During Execution

If there is no exception during a period of time, the process continues with the Order Generation Step.

From the technical point of view, the exception monitoring and its resolution are exactly same as in the case of Order Forecast Exception Handling and Sales Forecast Exception Handling. The difference is in the content of the exceptions. The actual events and orders are compared to the Forecasted Sales and Forecasted Orders. When there is a situation violating the normal exception criteria, one of the sides might generate an exception notification. Besides comparison of forecasts, other information gathered during the execution is observed (e.g., event dates, POS data, etc.). The resolution of the exceptions is the same as the process carried out for Sales Forecast Exception resolution.

During this exception monitoring time, Buyer also waits for a possible Termination message indicating the end of the collaboration. The Termination message is not mentioned by the CPFR guidelines but is included in UBL to indicate the successful termination of the CPFR collaboration. Since the CPFR Planning Process is supposed to be an iterative process, most of the time there will not be a termination message and the process will continue from CPFR Step 2 with a new cycle of forecast generation and order execution.

In the classic VMI scenario, a shop-within-a-shop area or an entire store is managed completely by the producer. The logistic concept of VMI can be combined with consignment/concession as well as with charge-on-delivery as the financial model. Mostly it is combined with consignment.

2.13.1.1. Initial Stocking of the Area by Producer

At the beginning of the cooperation, the area is stocked by the producer. The retailer receives item and delivery information and reports back the goods actually received.

Figure 40. Initial Stocking of the Area by Producer

2.13.1.2. Report of Sales and Inventory Movement

The sales and inventory movement information is transferred from the retailer to the producer.

Figure 41. Report of Sales and Inventory Movement

2.13.1.3. Permanent Replenishment

Based on sales and inventory movement, the producer periodically makes a new delivery of goods accompanied by a Despatch Advice. If the delivery contains an item not previously stocked, an updated catalogue is also sent so that the retailer can add the item to its product database. Upon delivery of the goods, the retailer reports back the items received using a Receipt Advice.

Figure 42. Permanent Replenishment

2.13.1.4. Invoicing for Vendor Managed Inventory

An invoice is sent either on a delivery or a sales basis. In a charge-on-delivery model, the data for the invoice is prepared from the delivery, and in a consignment/concession model from the sales reports.

Figure 43. Invoicing for Vendor Managed Inventory

2.13.1.5. Returns Initiated by the Producer

If sales do not meet expectations, items are reallocated by the producer. Because the producer cannot request a retailer to send the products to a competitor, the producer requests a return and handles the goods afterwards by itself.

Figure 44. Returns Initiated by the Producer

2.13.1.6. Price Adjustments

In the event of a price change, an updated price list (in the form of a new catalogue containing the change) is sent from producer to retailer.

Figure 45. Price Adjustments

A variant of VMI is the Cyclic Replenishment Program (CRP). In this process, the producer establishes a catalogue of NOS (Never Out of Stock) or seasonal NOS items, and the retailer chooses items for cyclic (weekly) replenishment. The logistic scenario can be combined with the charge-on-delivery as well as with a consignment/concession model. At the end of every sales period, a report of sales and inventory movement at all retail locations is sent to the producer.

CRP differs from the third VMI variant, Replenishment on Customer Demand (below), in that the producer cannot change the terms of the order.

2.13.2.1. Transfer of Base Item Catalogue

The producer publishes the catalogue of its NOS and seasonal NOS items to the retailer.

Figure 46. Transfer of Base Item Catalogue

2.13.2.2. Initial Stocking of the Area by Retailer

At the beginning of the cooperative relationship—or the beginning of a season, if seasonal NOS products are the focus—the retailer orders its base stock, and the products are delivered.

Figure 47. Initial Stocking of the Area by Retailer

2.13.2.4. Report of Sales and Inventory Movements

At the end of each sales day, a report of all sales and inventory movement at all retail locations is sent from the retailer to the producer.

Figure 48. Report of Sales and Inventory Movements

2.13.2.5. Cyclic Replenishment Program Invoicing

An invoice is sent either on a delivery or a sales basis.

Figure 49. Invoicing for Cyclic Replenishment Program

2.13.2.6. Synchronizing of Stock Information

Information about the actual stock is synchronised periodically (for example, every one to three months). This is combined at least once a year with a physical inventory.

The retailer sends an inventory report containing the information about the quantities currently in stock.

Figure 50. Synchronizing Stock Information

2.13.2.7. Changes to the Item Catalogue

In the event of a change, either inside an item belonging to the CRP catalogue or the relationship of an item to the CRP catalogue, information about the change is sent to the retailer.

Figure 51. Changes to the Item Catalogue

Another variant of VMI is Replenishment On Customer Demand. In this process, the producer selects a subset of its products for a specific retailer and sends out the related article catalogue. Then the producer periodically sends information about the availability of items so that the retailer can form the best ordering plan. The replenishment periodically happens on retailer (customer) demand, and unlike the case with CRP (above), the producer is allowed to propose changes to the orders. Also, because of the requirement to update item availability information, an additional document type (Stock Availability Report) is added to the process.

The processes of sales and inventory reporting, invoicing, stock synchronization, and changing the catalogue are identical to the same processes in CRP. As with CRP, a report of sales and inventory movement at all retail locations is sent to the producer at the end of every sales period. Invoicing and logistics are normally charge-on-delivery but can also be based on a consignment/concession model.

2.13.3.1. Transfer of Base Article Catalogue

The producer publishes a catalogue of its products to the retailer. The catalogue can include basic articles, never-out-of-stock (NOS) articles, seasonal articles, short-season-collection articles, or seasonal NOS articles.

Figure 52. Transfer of Base Article Catalogue

2.13.3.2. Periodic Transfer of Article Availability Information

The producer sends out information about availability of goods (quantities on hand, quantities incoming, articles out of stock).

Figure 53. Periodic Transfer of Article Availability Information

2.13.3.3. Initial Stocking of the Area by Producer and Retailer

At the beginning of the business cooperation —or perhaps at the beginning of a season, if seasonal NOS (never out of stock) products are the focus—the retailer orders its base stock and the products are delivered. Note that the producer is allowed to propose changes to the order (compare this figure with Figure 47, “Initial Stocking of the Area by Retailer”).

Figure 54. Initial Stocking of the Area by Producer and Retailer

Forwarding Instructions are normally used by any party who gives instructions for the transportation services required for a consignment of goods (the Transport Service Buyer) to any party who is contracted to provide the transportation services (called the Transport Service Provider). Forwarding Instructions may also be used by any party who requests a booking of shipment space to be made for the transportation services required for a consignment of goods to any party who will provide the underlying transportation services. The parties who issue this document are commonly referred to as the shipper, consignee, or consignor, while the parties who receive this document are forwarders, carriers, shipping agents, etc.

Forwarding Instructions may also be issued by a freight forwarder or shipping agent in their capacity as a Transport Service Buyer. This document may be used to arrange for the transportation:

A Packing List is normally issued by the Consignor. It states the distribution of goods in individual packages.

Based on this detail, the party who provides the logistic services will make arrangement for the transportation of the goods.

A Bill of Lading is issued by the party who provides the physical transportation services (e.g., carrier) to the party who gives instructions for the transportation services (shipper, consignor, etc.) stating the details of the transportation, charges, and terms and conditions under which the transportation service is provided.

A Bill of Lading may also be issued by the party who acts as an agent for the carrier or other agents to the party who gives instructions for the transportation services (shipper, consignor, etc.) stating the details of the transportation, charges, and terms and conditions under which the transportation service is provided, but who does not provide the physical transportation service.

A Bill of Lading corresponds to the information on the Forwarding Instructions. It is used for ocean or river modes 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, 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 Waybill is issued by the party who provides the physical transportation services to the party who gives instructions for the transportation services (shipper, consignor, etc.). It states the details of the transportation, charges, and terms and conditions under which the transportation service is provided.

Unlike a Bill of Lading, a Waybill is not negotiable and cannot be assigned to a third party. It is issued as a cargo receipt and is not required to be surrendered at the destination in order to pick up the cargo. This simplifies the documentation procedures between a Transport Service Buyer and a Transport Service Provider.

The Transport Service Description (TSD) document is used to publish information about a transport service. A transport service can be the physical transport of cargo between an origin and a destination, and it can also refer to other transport related services such as terminal services, warehousing services, handling services, or document handling services.

Figure 58. Transport Service Description

The Transport Execution Plan (TEP) is a plan established between a Transport User and a Transport Service Provider. The process of establishing a TEP can be carried out after many interactions between the two roles, from the quotation stage up to the final agreement of the TEP.

The following diagram shows the transactions involved in a basic scenario where the TEP is used to book and confirm a transport service and to send notification of a completed transport service. The GII (see Section 2.15.3, “Goods Item Itinerary”) is sent from the Transport Service Provider to the Transport User after the TEP is confirmed by both parties. This document contains route and schedule information for all segments involved in a transport service (including segments where parts of the transport service have been outsourced to other Transport Service Providers). If there are changes to the execution of the transport service, the GII is updated and re-sent to the Transport User.

Figure 59. Transport Execution Plan

The Goods item Itinerary (GII) specifies the route and time schedule for a transport item and is issued from the Transport Service Provider to the Transport User. It may contain one or more transport segments with different TEPs with different Transport Service Providers. One transport service (one TEP) may be responsible for more than one segment (leg).

In addition to providing an overview of the initial route and time schedule, the GII is used to record the actual progress in the form of new estimated times for departure and/or arrival and the actual departure and arrival times. The GII therefore contains information that may be used for analyzing the performance (in time) of transport services and for tracing the progress of cargo, if such analysis is required.

Figure 60. Goods Item Itinerary

The Transport Execution Status (TES) provides the status of the execution of a Transport Execution Plan (TEP). The TES must always refer to the TEP identifier and will return both the progress status of the transport execution and the condition status of the goods items being transported.

The TES may be sent from the Transport Service Provider as a response to a request, or it may be sent as a push operation based on trigger events.

Figure 61. Transport Execution Status Process

The Transport Progress Status (TPS) collects and reports information about the status of the transport means. The Transport Service Provider requests the Transportation Network Manager to provide status information related to a specific transport vehicle, using the vehicle identification number. The Transportation Network Manager then provides information about the location and time schedule status to the Transport Service Provider. The most typical use of TPS is to ask assistance from the Transportation Network Manager when estimated times of arrival are established. Reporting on the status of the goods themselves is covered by the Transport Execution Status process (Section 2.15.4, “Transport Execution Status”) and Freight Status Reporting process (Section 2.16, “Freight Status Reporting”).

Figure 62. Transport Progress Status Process

UBL extensions enable the validation of user-defined additions to the standard schemas, which are sometimes needed to satisfy legal requirements and can perform other useful functions as well. UBL 2.1 schemas are supplied with a predefined standard extension that supports advanced digital signatures; see Section 5, “UBL Extension for XML Digital Signatures” and Section 3.3, “Schema Dependencies”. For further information regarding the UBL extension mechanism, see [Customization].

See Section 5, “UBL Extension for XML Digital Signatures” for further information regarding the UBL extension supporting digital signatures such as XAdES.