xCBL 4.0

Order Management 
Recommended Use

Version 1.0
March 27, 2003

Table of Contents
Purpose
Order
Specifying Details of an Item
Line Item Identification
Part Numbers
Dimensions of the Item
References for the Item
Specifying Sub Lines
Identification of Line Item Type
Referencing a Parent Item
Recommended Best Practices
Specifying Quantities
Total Quantity
Delivery Quantities
Other Quantities
Specifying Delivery Information
Delivery Dates
Delivery Location
Specifying Pricing
Simple Pricing
Price Basis Quantity
Tiered Pricing
Taxes, Allowances and Charges
Recommended Best Practices
Specifying Packaging and Transport
ChangeOrder
Referencing the Original Order
Header Level Changes
Detail Level Changes
OrderResponse
Referencing the Original Order or ChangeOrder
Accepting or Rejecting an Entire Order or ChangeOrder
Accepting or Rejecting Individual Items
Accepting or Rejecting with Changes
OrderStatus
Overall Order Status
Individual Item Status

Purpose

The purpose of this document is to provide details about the recommended use of the Order, ChangeOrder, OrderResponse, and OrderStatus documents for xCBL 4.0.  This does not cover the use of every single element, nor does it explicitly state all the mandatory elements for a given scenario.  It is merely meant to give a general guideline for the use of the xCBL 4.0 Order Management documents.

Order

The Order is a dynamic document that can be used to order items ranging from a simple to a complex level.  The document can specify single, common delivery information for all items on the Order, or delivery information can be specified in a more complex manner item by item.  It can specify simple pricing for an item, or complex tiered pricing for an item.  The following section will outline the key points of an Order and recommend use in the xCBL 4.0 Order document.

Specifying Details of an Item

The first thing to know about an item is how to specify its details.  For instance, what part numbers are associated with the item, what are the dimensions of the item, and what other reference information pertains to this line item?  All of this information is specified in the Order/OrderDetail/ListOfItemDetail/ItemDetail/BaseItemDetail element.

Line Item Identification
The first thing to know about a line item is how to uniquely identify it within the Order document.  This is done with the //BaseItemDetail/LineItemNum element.  In most cases, only the BuyerLineItemNum will be supplied in an Order, although a unique line item number for the seller can also be supplied.  This element should be unique for each line item, as it is used to detail sub line item relationships (covered in the next section).

Part Numbers
The //BaseItemDetail/ItemIdentifiers element is used to provide the identification of the item being ordered.  Typically, the //ItemIdentifiers/PartNumbers/SellerPartNumber should be sufficient to identify what is being ordered, although other identifiers of the item can also be specified.  If substitute items are allowed for this item, they should be identified in the //ItemIdentifiers/PartNumbers/SubstitutePartNumbers element.  It is also important to note that //ItemIdentifiers/Service should be set to “true” if the item being ordered is a service item.

Dimensions of the Item
An item’s dimensions should be specified using the //BaseItemDetail/ListOfDimension element.  Although a part number may imply the dimensions of the item being ordered, in some cases it may be necessary to specify the dimensions of the item being ordered.  For instance, if an item such as paint is being ordered in a number of containers, you may also wish to specify the volume of the containers.  //BaseItemDetail/ListOfDimension would be used for this purpose.

References for the Item
It may be necessary to provide references for an item being ordered.   The two main cases for this would be a reference to a catalog, or a reference to a contract.  To reference a catalog, the //BaseItemDetail/BaseItemReferences/OffCatalogFlag should be set to “false”, to indicate that this item did come from a ProductCatalog.  Next, the //BaseItemDetail/BaseItemReferences/CatalogReference element should be populated with the appropriate information from the catalog.  To reference a contract, the //BaseItemDetail/BaseItemReferences /ItemContractReferences should be populated with the appropriate contract information.  All other references necessary for the item can be included in the //BaseItemDetail/BaseItemReferences/ListOfItemReferences element.

Specifying Sub Lines

Sub line items are handled in the xCBL 4.0 Order by specifying parent / child relationships.  Sub line items are typically used for grouping the components of an item, but these could also be used for other grouping purposes, such as the grouping of a collection of services.  Sub line items should not be used to break down delivery detail, as different delivery information can be specified elsewhere in the Order document (see the Specifying Delivery Information section of this document).  There are three main areas to consider when using sub line items in the xCBL 4.0 Order document.  The first is the identification of the type of line item, the second is the referencing of the parent items, and the final are the recommended “best practices” of using sub line items.

Identification of Line Item Type
The type of line item is specified by the //BaseItemDetail/LineItemType/LineItemTypeCoded element.  There are three possible line items.  The first type of line item to note is a textual item (LineItemTypeCoded = “TextItem”).  Although this does not necessarily apply to sub line items, it is important to note that this is a possible type of line item.  These line items are used to communicate textual information, and should not have any pricing, quantity, or delivery information associated with them, although these text items may be associated with actual items.  The next type of line item is a component group item (LineItemTypeCoded = “ComponentGroup”).  These items are made up of other items, i.e. they are parent items.  The final line item type is a regular line item.  These are typical line items that are not made up of other items, although they may be components of another item.

Referencing a Parent Item
If an item has components, it is noted with the line item type of “ComponentGroup”.  The components of this line item reference the parent using the //BaseItemDetail/ParentItemNumber element.  For instance, if a computer is being ordered, and its components (such as the CPU, keyboard, and monitor) are also to be specified in the Order, then the components would contain the computer’s line item number in their respective //ParentItemNumber elements.  It is important to note that these components all have unique line item numbers, and would have line item types of “Item”, unless of course these items too were made up of other items.

Recommended Best Practices
When specifying components of an item, the following practices should be kept in mind.  If a price is specified at both the component group, and the individual component level, the sum of the individual components should equal the total price of the component group.  The following scenario provides an example of this:

4 sets of silverware are being ordered at $30 per set (for a total of $120). Each set is made up of 4 knives, 4 spoons, and 4 forks, then the prices of the components might be $2.50 each.  That is to say that $2.50/fork x 4 forks + $2.50/spoon x 4 spoons + $2.50/knife x 4 knives = $30/set x 4 sets = $120 total.  

Also important to keep in mind is the delivery information of the components of an item.  If a component group is made up of other parts, but it does not make sense to ship them separately, then the delivery information should only be specified for the component group.  On the other hand, in the case of a collection of services, they may be delivered on different dates.  In this case, the delivery information should be specified at the component level.  The typical rule of thumb to follow in this case is that any delivery information specified at the component group level applies to all components, unless different information at the component level overrides it.  
Finally, quantities should be multiplied down from the parent item, to determine the actual amount of the componet that has been ordered.  For instance, in the silverware example above, 16 forks, 16 spoons, and 16 knives are being ordered (that is to say 4 sets x 4 forks / set = 16 forks, and so on).

Specifying Quantities

Probably the most important point apart from identifying what you are ordering, is specifying how much of it you are ordering.  The xCBL 4.0 Order allows different quantities to be specified for a given item, including the total quantity of an item ordered, the quantity of an item to be delivered on a specific date or to a specific location, and any other quantities that may be relevant.

Total Quantity
The total quantity of the item being ordered is specified in the //BaseItemDetail/TotalQuantity element.  Total quantity means the actual amount of an item, regardless of delivery date, location, or anything else, being ordered.  For information regarding the handling of quantities of sub line items, please see the Specifying Sub Line Items section above.  It is important to note that it is recommended that the units of measure for this quantity and the units of measure for the unit price be the same, although it is not absolutely necessary.

Delivery Quantities
The amount of an item to be delivered on a specific date, or to a specific location is handled in the delivery detail section of the item detail (which will be outlined in the next section, Specifying Delivery Information).  It is important to note that the sum of the items to be delivered should add up to the total amount of the item ordered.

Other Quantities
It may be necessary to communicate other quantities associated with an item, the most common of which is the maximum allowed back order quantity.  This can be expressed in the //BaseItemDetail/MaxBackOrderQuantity element.  Any other quantities can be expressed in the //BaseItemDetail/ListOfQuantityCoded element.

Specifying Delivery Information

Delivery information for an order can be specified at either the header or the detail level.  The header level information is assumed to apply to all items in the order, although if delivery information is also specified for a particular line item, the line item information should override the header level delivery information.  There are two key points to note about the delivery information in the xCBL 4.0 Order; How to specify the date and the amount of goods to be delivered, and how to specify the location to which the goods are to be delivered.

Delivery Dates
The easiest way to specify a delivery date is by specifying a delivery date for an entire order.  This is done by using the Order/OrderHeader/OrderDates element.  The //OrderDates/RequestedShipDate and //OrderDates/RequestedDeliverByDate are the main dates that should be used, although other specific dates can be communicated in the //OrderDates/ListOfDateCoded element.  These dates apply to all items on the order, although they can be overridden by individual line items.  If all, or most of the items on an order are to be delivered at the same time, this is the recommended means of communicating the delivery dates.  
If however, items are to be delivered on different dates, or an item itself is to be delivered in multiple shipments, the delivery information must be specified at the line item level.  This is done by using the Order/OrderDetail/ListOfItemDetail/ItemDetail/DeliveryDetail element.  The //ItemDetail/DeliveryDetail element can be used to specify all delivery information for a particular item.  The specific dates for delivery are specified in the //DeliveryDetail/ListOfScheduleLine element.  This element can be used to specify either the shipment date for the entire item being ordered, and/or a collection of shipment dates for partial quantities of the item ordered.  
To specify the delivery of the entire item, only one //ListOfScheduleLine/ScheduleLine element should be used.  Within this element the requested delivery date can be specified by the //ScheduleLine/RequestedDeliveryDate element, and/or other dates can be specified using the //ScheduleLine/ListOfOtherDeliveryDate element.  It is important to note that the //ScheduleLine/Quantity must equal the //BaseItemDetail/TotalQuantity for the item.
To specify multiple deliveries of an item, more than one //ListOfScheduleLine/ScheduleLine element can be used.  The dates for the delivery are specified in the same manner as the delivery for an entire item, but in this case the //ScheduleLine/Quantity is the quantity of the item to be delivered on that particular date.  In this case, the sum of all //ScheduleLine/Quantity elements for the line item must equal the //BaseItemDetail/TotalQuantity.

Delivery Location
Delivery location can be expressed at various levels in the xCBL 4.0 Order document.  The most basic way is to assume that the delivery location is the address of the buyer party (specified by the Order/OrderHeader/OrderParty/BuyerParty element).  However, if the delivery location is specified in any other manner, this overrides that assumption.  The next manner (in terms of simplicity), is to specify a ship to party by using the //OrderParty/ShipToParty element.  Specifying the delivery location by either of these methods applies the location to all items on the order, but as with the delivery dates, this can be overridden at the line item level.
At the item level, a delivery location can be specified for either the entire delivery of an item, or for multiple sub locations on a given delivery date.  Commonly, only a location for the entire shipment (regardless of date) is necessary, although multiple locations may be used, but only in the case of mail stop deliveries. 
To specify the delivery location for an entire shipment of an item (if it differs from the location specified at the header), the Order/OrderDetail/ListOfItemDetail/ItemDetail/DeliveryDetail/ShipToLocation element is used.  Again, this location applies to all shipments of the item, regardless of the date.
If items are to be delivered to multiple locations on a given delivery date, the //DeliveryDetail/ListOfScheduleLine/ScheduleLine/ListOfShipToSubInformation/ShipToSubInformation element should be used.  Within the ShipToSubInformation element, the location, and the quantity to be delivered to that location, can be specified by the //ShipToSubInformation/ShipToSubLocation and //ShipToSubInformation/ShipToSubQuantity elements, respectively.  Again, the use of this is limited to mail stop deliveries, and the sum of the quantities delivered to each mail stop should equal the total quantity delivered on the given date.

Specifying Pricing

Pricing information within the xCBL 4.0 Order can range from very simple, to more complex pricing schemes such as tiered pricing.  Although default-pricing information for all items on an order can be specified at the header level, it is highly recommended that only the pricing at the item level be used.  This is done by using the Order/OrderDetail/ListOfItemDetail/ItemDetail/PricingDetail element.

Simple Pricing
To simply specify a basic price for an item, only one //PricingDetail/ListOfPrice/Price element should be used.  Within this element, the price is specified in the //Price/UnitPrice/UnitPriceValue element.  The units of measure that the price applies to are specified by the //UnitPrice/UnitOfMeasurement element.  An example of this would be to say that the unit price for an item is $3 per item where: 

//UnitPrice/UnitPriceValue = 3
//UnitPrice/UnitOfMeasurement/UOMCoded = “EA”  

Note that the currency of the unit price is optional, but should be specified if it differs from the default currency set at the header level of the document.

Price Basis Quantity
In some cases, the pricing may be expressed in terms other than per 1 unit of measure.  For instance, one might want to say that the unit price for paint is $5 per 2 gallons.  In this case, the monetary amount of the price is still specified using the //Price/UnitPrice/UnitPriceValue element, but now, the number of units and the units of measure are expressed using the //Price/PriceBasisQuantity element.  In this case:
//PriceBasisQuantity /QuantityValue = 2 //PriceBasisQuantity/UnitOfMeasurement/UOMCoded = “A76” (gallon)

Tiered Pricing
Either of the pricing schemes above may apply to a range of quantities for the product ordered.  For instance, the paint may be $5 per 2 gallons for the first 100 gallons ordered, but the price may drop of to $4 per 2 gallons for anything over 100 gallons.  In this case, multiple //PricingDetail/ListOfPrice/Price elements should be used, one for each pricing level.  The first level would be expressed the same as the Price Basis Quantity example, only now, the //Price/PriceQuantityRange element would also be used.  In this case: 
//PriceQuantityRange /QuantityValue = 100 
//PriceQuantityRange/QuantityValue@SignificanceCoded = “LessThanOrEqualTo” //PriceQuantityRange/UnitOfMeasurement/UOMCoded = “A76”

For the next level, the price would be expressed the same way, only with:

//Price/UnitPrice/UnitPriceValue = 4
//PriceQuantityRange/QuantityValue = 100
//PriceQuantityRange/QuantityValue@SignificanceCoded = “GreaterThan”

Taxes, Allowances and Charges
Taxes that apply to the pricing of an item are specified in the //PricingDetail/Tax element.  Allowances or charges for the item should be expressed in the //PricingDetail/ItemAllowancesOrCharges element.  Finally, the total price for an item, that is for the entire quantity ordered, including all taxes, allowances, and charges, can be specified in the //PricingDetail/LineItemTotal element.

Recommended Best Practices
Only one unit of measure should be specified for a given price.  That is to say, that when a price basis quantity is specified, the units of measure in the UnitPrice element should not be used.  When specifying units of measure for a unit price, or for a price basis quantity, it is strongly recommended that this be done in the same units of measure that the item is being ordered in.  This allows for straightforward calculation of total prices.  However, if this is not possible, the //Price/CalculatedPriceBasisQuantity element should be used to express the price in terms of the units of measure that the line item is being ordered in.  The following example shows how the CalcualtedPriceBasisQuantity element would be used:

Paint is being ordered in cans (each).  
The //BaseItemDetail/ListOfDimension element should specify the volume of the can (4 gallons for this example).  
If the price is specified as $5 / 2 gallons;

//Price/UnitPrice/UnitPriceValue = 5
//PriceBasisQuantity/QuantityValue = 2 //PriceBasisQuantity/UnitOfMeasurement/UOMCoded = “A76” (gallon)

then the calculated price basis quantity would be 0.5 cans (each):

(4 gallons / can) x (1 / 2 gallons) = (2 / cans) = 0.5 cans

This would be represented by:

//Price/UnitPrice/UnitPriceValue = 5
//Price/CalculatedPriceBasisQuantity/QuantityValue = 0.5
//Price/CalculatedPriceBasisQuantity/UnitOfMeasurement/UOMCoded = “EA” (each)

Thus the unit price can be calculated as $5 / 0.5 can or $10 / can.  This price when multiplied by the total quantity ordered would yield the total price for the line item.

Specifying Packaging and Transport

Packing and transportation information for an order is complex, and only applicable in certain types of ordering.  For more information on how packing and transportation information should be specified, refer to the Transport Packaging Summary document.

ChangeOrder

The xCBL 4.0 ChangeOrder document is a buyer-initiated document that can be used to change an existing Order already received and responded to by a seller.  The document can be used to make changes to header level information, change line items, cancel line items or entire orders, add line items, etc.  Note that if an OrderResponse has not been received for a given Order, a ChangeOrder is not necessary (an Order with a purpose of “Replace” should be used).  Similarly, if an entire order is to be cancelled  and an OrderResponse has not been received an Order with a purpose of “Cancellation” can be used.  However, if an OrderResponse has been received, a ChangeOrder with a ChangeOrder/CahngeOrderHeader/CahngeType/ChangeTypeCoded = “Cancel” should be used to cancel the entire Order (Note: this is a change from what was recommended in xCBL 3.5).  The following section will outline the common uses of the ChangeOrder document.

Referencing the Original Order

For a ChangeOrder to be processed, the original Order document it is changing needs to referenced correctly.  The original Order is referenced by the ChangeOrder/ChangeOrderHeader/OrderReference element, where //OrderReference/RefNum = the original order number assigned by the buyer and //OrderReference/RefDate = the issue date of the original order.  This is the only reliable means of referencing the original order.  Furthermore, the type of change being made by the ChangeOrder document must be specified in the ChangeOrder/ChangeOrderHeader/ChangeType element.	

Header Level Changes

Changes to the header level of an order should be made using the ChangeOrder/ChangeOrderHeader/OriginalOrderHeaderWithChanges element.  If a change is to be made, it is recommended that the entire header section be populated completely as it existed, with the exception of the changes to be made.  As the name of this element implies, it can also be used to merely echo back the original OrderHeader in the case that no changes are to be made.  Finally, the use of this element as a means of identifying the original order is not acceptable.  The ChangeOrder/ChangeOrderHeader/OrderReference is the only accepted means of identifying the Order which is being changed.

Detail Level Changes

Although the detail section of the ChangeOrder document is optional, it is recommended that even if items are not being changed, they are included with the appropriate change code of  “NoAction”.  Simillaryly, if only some items are being changed, it is still recommended that all the items are included, with those not being change denoted by a change code of “NoAction” (Note: this is a change from what was recommend in xCBL 3.5).  If items are being added, these items should be placed at the end of the detail section, with the line item numbers start from where the original order left off.  It is important that the line item number from the original order remain the same, so that the changes to be made are clear.  Changes to a line item are made using the ChangeOrder/ChangeOrderDetail/ListOfChangeOrderItemDetail/ChangeOrderItemDetail element.  For each item being changed, the type of change needs to be specified using the //ChangeOrderItemDetail/ItemDetailChangeCoded element.  Regardless of whether an item is being changed, added, deleted, or left unchanged, the details of the item must be specified in the //ChangeOrderItemDetail/OriginalOrderHeaderWithChanges element.  This is the only means of identifying the line item.  Again, as the name implies, this element should include all of the original information, with the exception of any information being changed.

OrderResponse

The xCBL 4.0 OrderResponse document can be used to respond to either an Order or a ChangeOrder document.  It can be used to merely accept or reject an order or change order, or if allowed by the parties involved, can be used to make changes to an order.  The following section will describe the common uses of the OrderResponse document.

Referencing the Original Order or ChangeOrder

The OrderResponse must correctly reference the original order, and if applicable, the change order it is responding to.  This is done using the OrderResponse/OrderResponseHeader/OrderReference and the //OrderResponseHeader/ChangeOrderReference elements, respectively.  In both cases the //OrderReference/RefNum or //ChangeOrderReference/RefNum is the number of the document being referenced and the //OrderReference/RefDate or //ChangeOrderReference/RefDate is the issue date of the document being referenced.  This is the only acceptable means of referencing the document(s) that the OrderResponse is responding to.

Accepting or Rejecting an Entire Order or ChangeOrder

At the simplest level, an OrderResponse can be used to simply reject or accept an entire order.  To do this, the response must be specified using the //OrderResponseHeader/ResponseType element.  To accept the entire order “as is”, //ResponseType/ResponseTypeCoded should be set to “Accepted”.  To reject the entire order, //ResponseType/ResponseTypeCoded should be set to “NotAccepted”.  No other information, outside of the other required elements, is necessary.

Accepting or Rejecting Individual Items

If it is necessary to specify individual items for acceptance or rejection, then this needs to be done at the item level.  Before the line item responses can be specified, a header level response needs to be specified.  It is suggested that this be set to “AcceptedWithAmmendmentInDetailSection”.  This code should state that although the order may be accepted; some line items may not be accepted.  At the line item level, an item must be accepted or rejected using the OrderResponse/OrderResponseDetail/ListOfOrderResponseItemDetail/OrderResponseItemDetail element.  To accept an item, //OrderResponseItemDetail/ItemDetailResponseCoded should be set to “ItemAccepted”.   To reject and item, //OrderResponseItemDetail/ItemDetailResponseCoded should be set to “ItemRejected”.  To identify the line item that is being responded to, the //OrderResponseItemDetail/OriginalItemDetailWithChanges element should be used.  This element should be populated with the original information from the Order.  This is the only acceptable means of referencing the line item, and although a section is provided to repeat the original line item detail, its use is discouraged.

Accepting or Rejecting with Changes

At both the header and detail levels, the seller can make changes.  If a change is made at either level, the appropriate response code should be used.  If only changes to the header section are made then //OrderResponseHeader/ResponseType/OrderResponseTypeCoded should be set to “AcceptedWithAmendmentInHeadingSection”.  If only changes to the detail section are made then //OrderResponseHeader/ResponseType/OrderResponseTypeCoded should be set to “AcceptedWithAmendmentInDetailSection”, and the items that have changed should have //OrderResponseItemDetail/ItemDetailResponseCoded set to “AcceptedWithAmendment” (or a more detailed code such as “ItemAcceptedPriceChanged”, if this level of detail is necessary).  If both header and detail sections are changed, it is recommended that //OrderResponseHeader/ResponseType/OrderResponseTypeCoded be set to “AcceptedWithAmendment”, and the detail section be flagged as specified above.  These all of course assume that the order would be accepted with the changes.  If this is not the case, then “RejectWithDetail” should be used at both levels.
Finally, if at the detail level, only part of the total quantity of the item is to be accepted, //OrderResponseItemDetail/OriginalItemDetailWithChanges/BaseItemDetail/ResponseQuantity should be used to specify the amount accepted.  It is also recommended that in this case the //OrderResponseItemDetail/ItemDetailResponseCoded be set to “ItemAcceptedQuantityChanged”.  In this case, the buyer should assume that the difference between the total quantity ordered, specified in //OrderResponseItemDetail/OriginalItemDetailWithChanges/BaseItemDetail/OrderedQuantity, and the ResponseQuantity is rejected.
XCBL 4.0 also allows for specification of split quantities in the OrderResponse.  By split quantities, it is meant partial acceptence of the quantity ordered, split out by shipment statuses.  For instance, if 12 pieces of an item are ordered, 4 can be accepted and shipped as requested, 4 can be back ordered, and 4 can be rejected.  To do this, the //OrderResponseItemDetail/OriginalItemDetailWithChanges/BaseItemDetail/ResponseQuantity should still be set to the quantity accepted (including back orders).  The detail of this quantity can be provided in //OrderResponseItemDetail/OriginalItemDetailWithChanges/DeliveryDetail/ListOfSplitQuantity.  For each individual break out of the accepted quantity a //ListOfSplitQuantity/SplitQuantity element should be specified.  Each SplitQuantity element must speicify a shipment status in //SplitQuantity/ShipmentStatusEventCoded.  For instance, this shipment status may be “BackOrdered”, “NotYetShipped”, or “ShipmentComplete”.  Furthermore, any dates related to this quantity can be specified such as ActualShipDate or EstimatedShipDate, to name a few.  The sum of the //ListOfSplitQuantity/SplitQuantity elements should equal the //OrderResponseItemDetail/OriginalItemDetailWithChanges/BaseItemDetail/ResponseQuantity.

OrderStatus

The most common method for updating the status of an order is by the synchronous order status process.  In this process, the buyer sends an OrderStatusRequest document to the seller, requesting the status of one or more orders.  In turn, the seller responds with an OrderStatusResult document.  The following section will outline how the OrderStatusResult document should be used to communicate the status of an order.

Overall Order Status

The status of an order is given by the OrderStatusResult/ListOfOrderStatusResultDetail/OrderStatusDetailResult/OrderStatusResultReference element.  Within the OrderStatusResultReference element, the order that the status is being given for is identified by the //OrderStatusResultReference/BuyerReferenceNumber and the //OrderStatusResultReference/OrderDate.  The status of the entire order can be given by the following elements:

•	//OrderStatusResultReference/OrderStatus/StatusEvent – used to communicate the status of the entire order in terms of processing (such as processing, complete, etc.)
•	//OrderStatusResultReference/ShipmentStatusEvent – used to communicate the shipment status of the entire order
•	//OrderStatusResultReference/PaymentStatusEvent/StatusEvent – used to communicate the payment status of the entire order.

Individual Item Status

If the status of individual line items within the order is necessary, then the //OrderStatusResultReference/ListOfOrderStatusResultItem/OrderStatusResultItem element can be used.  The item is identified by the //OrderStatusResultItem/LineItemNum element.  For each item, //OrderStatusResultItem/QuantityLeftToRecieve must be specified.  Multiple item statuses can be given for a given line item, each with an associated quantity.  The same status elements available for the entire order are available for a line item, with the exception of //OrderStatus/Status, which is replaced by //ItemStatusEvent/Status – which is always given.  Note that a quantity must be specified for each ItemStatus, and thus the statuses given must apply to that quantity.  That being the case, it is not necessary that the sum of the quantities given in the item statuses for a line item equal the total quantity of the line item.  It is necessary however, that for a given status (with the exception of item status), the quantities associated with it do not exceed the total quantity of the item ordered.  For instance, a total quantity of 10 pieces of an item is ordered, the status may be given as follows:

•	Item status 1:  Quantity = 10, Item status =  “Accepted”, Payment status = “PaymentRecieved”
•	Item status 2:  Quantity = 5, Item status = “Accepted”, Shipment status = “Delivered”
•	Item status 3:  Quantity = 5, Item status = “Accepted”, Shipment status = “InTransit”

As you can see, the quantities of all of the item status do not equal the total quantity ordered, but the quantities of the payment and shipment statuses do equal the total quantity ordered.