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 Section 2.6.3, “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.

UBL does not provide documents for tax reporting purposes. Instead, it provides structures to support the information on which taxes are based. These aim to be generic and not based on any specific tax regime.

Many of the UBL document types employ the concept of a “line” inherited from traditional paper documents such as purchase orders and invoices. As in these older realizations, a “line” is a substantial data object with a number of subfields, typically including a short description, quantity, unit name, unit price, extension, and so on. Often in UBL these data structures include an element named Item that describes more fully the item of sale being ordered, invoiced, shipped, etc. Item in the line context always refers to the generic item of sale, not a unique, trackable, individual instance of such an item.

In the case of line structures such as InvoiceLine and TenderLine, the relationship between the line and the Item it contains is unproblematic, but a person unfamiliar with traditional usage may easily be confused by the line element called LineItem. In traditional business processes, “line item” is a common name for the entire line structure in a purchase order or invoice, not just the item of sale contained in the line. Thus, despite the name, a LineItem is not an Item but rather a complex data structure that contains an Item along with quantity, price, and so on.

References to “shipment” and “consignment” appear in a number of places in the UBL data model relating to the transport of goods. For IT specialists unfamiliar with the way these terms are used in international trade, the structural relationships between the two can be puzzling. For example, a close look at the data model shows that shipments can comprise multiple consignments and consignments can comprise multiple shipments. This is not a design flaw but rather a reflection of the possible real-world relationships between the two concepts.

Shipment and consignment actually refer to two different ways of looking at the same (possibly very complex) situation. From the physical or logistical point of view, a consignment is the transportation of an identifiable collection of goods items from one party (the consignor) to another (the consignee) via one or more modes of transport. From the contractual or logical point of view, a shipment is the contractual arrangement whereby an identifiable collection of goods items is to be transported from one party (the shipper) to another party (the recipient). In UBL, the party originating the shipment is usually a supplier, and the party receiving the shipment is usually a buyer.

In the simplest fulfilment scenario, these distinctions are almost invisible; see Figure 2, “Simple Fulfilment” below (used, like the subsequent three, by permission of Document Engineering Services). In this case, the supplier of the contracted shipment is the consignor of the physical goods, and the buyer is the consignee.

Figure 2. Simple Fulfilment

Often, however, a single contractual shipment is split up into separate physical consignments that may be received on separate schedules, as shown in Figure 3, “Split Fulfilment”. The shipper may use multiple carriers, or the shipment may be so large that it must be transported in multiple vessels, becoming in effect multiple consignments. It is therefore often necessary for the UBL description of a shipment to contain descriptions of the consignments into which the goods have been divided.

Figure 3. Split Fulfilment

So far, the shipper (here a supplier) remains the only consignor and the recipient (here the buyer) the only consignee. But sometimes the division of a shipment into consigments takes place “behind the scenes” through the involvement of a freight forwarder, who becomes both a second consignee and a second consignor (Figure 4, “Intermediary Fulfilment”). The “shipment” in this case is the entire end-to-end organization of the transport of goods on behalf of the shipper.

Figure 4. Intermediary Fulfilment

Another layer of complexity is introduced when pieces of different, possibly unrelated shipments are consolidated into a single consignment to make the physical process more efficient (to share space in the same shipping container, for example, which optimizes transport by ensuring that the container is fully loaded and also provides a more competitive tariff). In Figure 5, “Consolidated Fulfilment”, goods from two completely unrelated business transactions between two buyers and their suppliers — two different shipments — are consolidated by a freight forwarder into a single consignment for part of their journey and then separated again by another freight forwarder farther on. This requires the UBL description of the consignment to contain descriptions of the shipments participating in the consolidation. Note that the transaction between the two freight forwarders is itself a shipment (a consolidated shipment), and its data structure must be able to describe the two shipments it is covering (Supplier A to Buyer A and Supplier B to Buyer B) so that the receiving forwarder knows how to deconsolidate the consignment.

Figure 5. Consolidated Fulfilment

Note that the word “consignment” in the context of transportation has a meaning different from that of “consignment” in sales and vendor-managed inventory (Section 2.14, “Vendor Managed Inventory”).

The terms “transport” and “transportation” both appear many times in the UBL data model. There is no semantic difference between these terms as used in UBL; in the context of freight management, they mean exactly the same thing: the conveyance of goods or persons.

“Transportation” is the oldest of the two forms, the noun “transportation” first appearing in written English about 70 years earlier than the noun “transport”. UBL 2.0 adopted “transportation” as the preferred form in terms such as “transportation service” and “transportation status”, but in the process of developing UBL 2.1, which features greatly expanded data representation capabilities for multimodal freight management, it became clear that “transport” is the form to be preferred, both because it is shorter and because it is the more commonly used of the two in international contexts. The decision to adopt “transport” for new usages while preserving backward compatibility with UBL 2.0 by retaining “transportation” in data items from the earlier release has resulted in the mixed terminology seen here.

UBL 2.1 has been enhanced to support the financial information required for downstream processing of Invoices within financial services. By aligning information models, business vocabularies such as UBL for eBusiness and ISO 20022 for eFinance enable Straight Through Processing (STP) and paperless trading along the entire Financial Supply Chain. For example, the UBL Invoice and Remittance Advice can be used together with financial messages to ensure end-to-end transport of reconciliation identifiers (invoicing party references). In particular, UBL provides a solution for advanced external remittance, where the UBL Remittance Advice is used to transmit the details of complex remittance information associated with the payment initiation process (see ISO 20022 guides for details).

UBL 2.1 is also designed to support basic trade financing practices (invoice financing, factoring, pre-shipment/order financing, Letter of Credit, etc.).

The structure and semantics of UBL 2.1 with respect to taxation information have been aligned with the OASIS Indirect Tax Reference Model Version 2.0 produced by the OASIS Tax XML TC supported by the OECD. The purpose of this reference model is to present a model of the tax related information contained within the messages exchanged between the participants involved in a business transaction, the primary purpose of which is not tax-related, but which may be subject to the imposition of an indirect tax. This model is intended to serve as a reference for any effort to analyze the related messages (documents) of an implementation to verify that the indirect tax implications are adequately addressed, and as input to any effort to define message-oriented specifications involving indirect taxation. It is based on a three party scenario, where parties in a commercial business process can conduct their transactions and provide taxation, customs or independently auditable information when required.

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 7. 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 8. 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 9. 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 10. 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 strict deadlines for tender presentation.

Figure 11. 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 12. Award Notification

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

Figure 13. Award Publication

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

Figure 14. 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. The UBL document types involved are Catalogue, Catalogue Request, and Application Response.

Figure 15. Create Catalogue Process

2.4.2.2 Update Catalogue Item Specification

The process of updating a Catalogue Item specification using Catalogue Item Specification Update is shown in the following diagram. The Catalogue Request and Application Response documents also participate.

Figure 16. Update Item Specification Process

2.4.2.3 Update Catalogue Pricing

The process of updating Catalogue pricing is shown in the following diagram. The UBL document types involved are Catalogue, Catalogue Request, Catalogue Pricing Update, and Application Response.

Figure 17. Update Catalogue Pricing Process

2.4.2.4 Delete Catalogue

Deletion of a Catalogue using Catalogue Deletion and Application Response is shown in the following diagram.

Figure 18. Delete Catalogue Process

2.4.2.5 Punchout

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

Figure 19. Punchout Sourcing Process

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

While conceptually the punchout request is a form of Request for Quotation (see Section 2.5, “Quotation”), the exchange transaction is tightly coupled to the specific catalogue application and is considered outside the scope of UBL; thus, the only UBL document type involved in this process is Quotation.

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 in 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.

Figure 22. Fulfilment with Despatch Advice Process

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. It also is capable of reporting shortages or damaged items.

Figure 23. 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.

In real life, the sender of a Despatch Advice or Receipt Advice sometimes needs to cancel the document after it has been sent. The Fulfilment Cancellation document is provided for this purpose.

For example, a Despatch Advice may later be cancelled by the Supplier when a problem with shipment prevents the delivery of goods, or the goods to be shipped are not available, or the order is cancelled; in these cases, the customer cancels receipt and adjusts the order accordingly (see Figure 22, “Fulfilment with Despatch Advice Process”).

Similarly, a Receipt Advice may later be cancelled by the customer (see Figure 23, “Fulfilment with Receipt Advice Process”) if the customer discovers an error in ordering (failure to follow formal contractual obligations, incorrect product identification, etc.) or a problem with a delivered item (malfunction, missing part, etc.). In this case, the billing and payment process may be put on hold.

An Invoice defines the financial consequences of a business transaction. 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.

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 are 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, or 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 Note is shown in the following diagram.

Figure 24. 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 Note is shown in the following diagram.

Figure 25. 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 Note is shown in the following diagram.

Figure 26. 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 Note is shown in the following diagram.

Figure 27. 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 28. Reminder for Payment 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 33. CPFR Steps 1 and 2

The first step of the CPFR Process continues with the exchange of messages containing purchase conditions. (UBL 2.1 does not standardize the format of such messages.) Afterwards, for determining the exception criteria that should be monitored and handled during the execution, Exception Criteria messages are exchanged. Exchange of revised Exception Criteria messages continues until the criteria are accepted by both sides.

Figure 34. 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. Revisions are exchanged until an agreement is achieved.

Figure 35. 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 36, “CPFR Steps 3, 4, and 5” and Figure 37, “Create Sales Forecast”, 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 36. 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 37. Create Sales Forecast

In many cases some time may 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 38. 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 39, “CPFR Steps 6, 7, 8 and 9”, 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 39. 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. Document types used in this process are Retail Event, Product Activity, Forecast, and Forecast Revision.

Figure 40. 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 exception detection following Sales Forecast (see Section 2.13.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 41. Identifying and Resolving Exceptions for Order Forecast

Figure 42. 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.

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.14.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. UBL document types used here are Catalogue, Despatch Advice, and Receipt Advice.

Figure 43. Initial Stocking of the Area by Producer

2.14.1.2 Report of Sales and Inventory Movement

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

Figure 44. Report of Sales and Inventory Movement

2.14.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 45. Permanent Replenishment

2.14.1.4 Invoicing for Vendor Managed Inventory

A UBL 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 46. Invoicing for Vendor Managed Inventory

2.14.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. Document types used here are Instruction for Returns, Despatch Advice, and Receipt Advice.

Figure 47. Returns Initiated by the Producer

2.14.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 48. 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.14.2.1 Transfer of Base Item Catalogue

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

Figure 49. Transfer of Base Item Catalogue

2.14.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. Order, Despatch Advice, and Receipt Advice are used in this process.

Figure 50. Initial Stocking of the Area by Retailer

2.14.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 using Product Activity.

Figure 51. Report of Sales and Inventory Movements

2.14.2.5 Cyclic Replenishment Program Invoicing

A UBL Invoice is sent either on a delivery or a sales basis.

Figure 52. Invoicing for Cyclic Replenishment Program

2.14.2.6 Synchronizing of Stock Information

Information about the actual stock is synchronised periodically (for example, every one to three months) using Inventory Report. 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 53. Synchronizing Stock Information

2.14.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 by sending an updated Catalogue document. Item change is indicated by an optional ActionCode field in each changed CatalogueLine.

Figure 54. 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.14.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 55. Transfer of Base Article Catalogue

2.14.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) using a Stock Availability Report.

Figure 56. Periodic Transfer of Article Availability Information

2.14.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 50, “Initial Stocking of the Area by Retailer”). Document types used in this process include Order, Order Change, Despatch Advice, and Receipt Advice.

Figure 57. 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.

A Bill of Lading is a transport document that is the evidence of a contractual agreement 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. It is in common use for ocean or inland waterways modes of transport. The Bill of Lading (B/L) may serve as a document of title. 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 Bill of Lading is normally issued by the party who provides the physical transportation services (e.g., the maritime carrier) to the party who gives instructions for the transportation services (shipper, consignor, etc.) as a receipt for the cargo and sometimes of instructions, 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. In such case a Bill of Lading is signed “as agent”.

Much of the information contained in the Bill of Lading corresponds to the information on the Forwarding Instructions.

A freight forwarder, who can be either a Transport Service Provider or a Transport Service User according to different circumstances and depending on the contractual interlocutor, can assume responsibility for the shipment with regards to the shipper and issue Bills of Lading as a common carrier, a contractual carrier, or as a Non Vessel Operating Common Carrier (NVOCC). In such case, when the transportation is multimodal, it can provide a multimodal Bill of Lading.

A Waybill is a transport document issued by the party who undertakes to provide transportation services, or undertakes to arrange for their provision, to the party who gives instructions for the transportation services (shipper, consignor, etc.). It states the instructions for the beneficiary and may contain 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 (endorsement). It may be issued as a cargo receipt and is not required to be surrendered at the destination in order to pick up the cargo. This may simplify the documentation procedures between a Transport Service Buyer and a Transport Service Provider, but using this document in combination with international payments (e.g., documentary credits) is not advisable.

A freight forwarder may decide to issue a waybill to communicate consignment, transport, and conveyance information to third parties, be they shippers, subcontractors, transport operators, or authorities.

The Transport Service Description is used to publish information about a transport service. A Transport Service Description Request is used to request such information. 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 63. Transport Service Description

The Transport Execution Plan is a plan established between a Transport User and a Transport Service Provider in order to collaborate and document the details surrounding the provision of a required transport service. Depending on the nature of the transport service and the business relationship between the Transport User and the Transport Service Provider, the process of establishing a Transport Execution Plan may be carried out by means of multiple interactions between the two roles, from the initial request from the Transport User up to the final agreement of the Transport Execution Plan among the parties involved.

The following diagram (Figure 64, “Transport Execution Plan”) shows the message exchange involved in a basic scenario. A Transport Execution Plan Request is sent from the Transport User in order to request a transport service. If the Transport Service Provider accepts the transport service request, he responds with a confirmed Transport Execution Plan. If the Transport Service Provider does not accept the transport service request, he responds with a rejected Transport Execution Plan.

The handling of a Transport Service Request will in many cases depend upon whether or not there is a pre-established agreement between the Transport User and the Transport Service Provider. If there is a pre-established agreement, the Transport Service Request can typically be considered a call-off from the agreement between the two parties. (An established framework agreement or contract usually defines terms and conditions and a total capacity limit, e.g., 100 container spaces on a vessel per year. A call-off occurs when the Transport User places an order against this agreement, for example a booking of 10 of the 100 container spaces.) The Transport User can confirm the Transport Execution Plan Request without the need to make a careful examination of the Transport Execution Plan submitted by the Transport Service Provider. The Transport User then sends a Transport Execution Plan with a status code indicating confirmation. Assuming acceptance by the Transport Service Provider, this scenario is considered a two-step choreography.

If a pre-established agreement does not exist (e.g., spot market services), the Transport User issues a Transport Execution Plan Request with a status code indicating that the Transport Execution Plan is not yet confirmed. The Transport User only confirms the Transport Execution Plan after a careful analysis of what has been submitted by the Transport Service Provider. This scenario is a three-step choreography where the Transport User confirms the Transport Execution Plan content in his second or subsequent response to the Transport Service Provider.

Updates to the Transport Execution Plan may be issued by either the Transport User or the Transport Service Provider. If the Transport User wants to update an existing Transport Execution Plan, a new instance of a Transport Execution Plan must be issued with reference to the original Transport Execution Plan. Similarly, if the Transport Service Provider wants to update an existing Transport Execution Plan, a new Transport Execution Plan replaces the original Transport Execution Plan with a reference to the original one. In either case, the Transport Execution Plan must include a document status code indicating that this is an update of the original content.

The cancellation of a Transport Execution Plan may be requested by either the Transport Service Provider or the Transport User. In either case, the Transport Execution Plan is sent with a document status code indicating that the Transport Execution Plan should be cancelled. For the cancellation to be effective, it must be accepted by the party receiving the cancellation request. Acceptance is signified by sending back a Transport Execution Plan with a status code indicating confirmation; rejection of the cancellation is signified by issuing a Transport Execution Plan with a status code indicating rejection.

Upon completion of the transport service covered by the Transport Execution Plan, a final Transport Execution Plan document is sent from the Transport Service Provider to the Transport User that includes a document status code indicating that the transport service is completed.

Figure 64. Transport Execution Plan

The Goods Item Itinerary specifies the route and time schedule for one or more transported items and is issued from the Transport Service Provider to the Transport User. The Goods Item Itinerary is initially issued from the Transport Service Provider to the Transport User after a Transport Execution Plan is confirmed by both parties. It may contain one or more transport segments with different Transport Execution Plans employing different Transport Service Providers. One transport service (one Transport Execution Plan) may cover more than one segment (leg).

In addition to providing an overview of the initial route and time schedule, the Goods Item Itinerary is used to document progress by recording new estimated times for departure or arrival and actual departure and arrival times. So when updates to the initial transport execution schedule occur, a new version of the Goods Item Itinerary is issued to the Transport User. A Goods Item Itinerary document thus contains information that may be used for analyzing the performance (in time) of transport services and for tracing the progress of cargo in transit if such analysis is required.

Figure 65. Goods Item Itinerary

The Transport Progress Status collects and reports information about the status of the transport means. The Transport Service Provider issues a Transport Progress Status Request to ask the Transportation Network Manager for 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. During a transport service, there might be a number of information providers taking on the Transportation Network Manager role, offering Transport Progress Statuses to the Transport Service Provider.

The most typical use of Transport Progress Status 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 Freight Status Reporting process (see Section 2.16, “Freight Status Reporting”).

Figure 66. Transport Progress Status

Description: A document to indicate the application’s response to a transaction. This may be a business response and/or a technical response, sent automatically by an application or initiated by a user.

Description: A UBL  wrapper  that allows a document of any kind to be packaged with the UBL document that references it.

Description: The document used to communicate a contract award to the winner.

Description: A document that conveys information about an instance of a transportation service and may under some circumstances serve as a contractual document for the service. See Section 2.15.3, “Bill of Lading” and compare with Section 2.15.4, “Waybill”.

Description: A document used by a Contracting Party to define a procurement project to buy goods, services, or works during a specified period.

Description: A document that describes items, prices, and price validity. See Section 2.4, “Catalogue”.

Description: A document used to cancel an entire Catalogue.

Description: A document used to update information (e.g., technical descriptions and properties) about Items in an existing Catalogue.

Description: A document used to update information about prices in an existing Catalogue.

Description: A document used to request a Catalogue.

Description: A document that describes the Certificate of Origin.

Description: A document published by a Contracting Party to announce the awarding of a procurement project.

Description: A document used by a Contracting Party to announce a project to buy goods, services or works.

Description: A document used to specify credits due to the Debtor from the Creditor.

Description: A document used to specify debts incurred by the Debtor.

Description: A document used to describe the despatch or delivery of goods and services.

Description: A document used to provide information about document status.

Description: A document used to request the status of another document.

Description: A document used to specify the thresholds for forecast variance, product activity, and performance history beyond which exceptions should be triggered.

Description: A document used to notify an exception in forecast variance, product activity, or performance history.

Description: A document used to forecast sales or orders.

Description: A document used to revise a Forecast.

Description: A document issued to a forwarder, giving instructions regarding the action to be taken for the forwarding of goods described therein. See Section 2.15.1, “Forwarding Instructions”.

Description: A document stating the charges incurred for a logistics service.

Description: A document used to cancel an entire Despatch Advice or Receipt Advice.

Description: A document providing details relating to a transport service, such as transport movement, identification of equipment and goods, subcontracted service providers, etc.

Description: A document to notify the deposit of a bid bond guarantee.

Description: A document used to initiate a return of goods. The producer is requesting the return of products that are not selling well, either to use in other places or to free up rack or shelf space.

Description: A report on the quantities of each item that are, or will be, in stock.

Description: A document used to request payment.

Description: A document used to request product activity, forecast, or performance data.

Description: A document used to order goods and services.

Description: A document used to cancel an entire Order.

Description: A document used to specify changes to an existing Order.

Description: A document used to indicate detailed acceptance or rejection of an Order or to make a counter-offer.

Description: A document used to indicate simple acceptance or rejection of an entire Order.

Description: A document describing how goods are packed.

Description: A document used by a contracting party to declare the intention to buy goods, services, or works during a specified period.

Description: A document reporting the movement of goods at specified retail locations for inventory tracking purposes.

Description: A document used to quote for the provision of goods and services.

Description: A document used to describe the receipt of goods and services.

Description: A document used to remind a customer of payments overdue.

Description: A document that specifies details of an actual payment.

Description: A document used to request a Quotation for goods and services from a seller.

Description: A document used to specify basic information about retail events (such as promotions, product introductions, and community or environmental events) that affect supply or demand.