Operation: CreateOrder

The request constitutes a vco:CreateOrderRequest element, the response a vco:OrderResponse element. The vco:CreateOrderRequest element extends vct:RequestType with the vco:OrderRequestLine element which must occur at least once. It comprises the following elements:

Rule: CreateOrderRequest

A Veloconnect-compliant client behaves as follows: For the purposes of the transaction order, the order is assumed to be normalized, i.e. two different lines of an order in each case refer to different article identifiers of the seller (short: order number). For each line of the order, an OrderRequestLine element is created as follows:

Rule: OrderRequestLine(Client)

1. The SellersItemIdentifcation element contains the order number.

2. The Quantity element contains the ordered quantity (refer to the section on cbc:QuantityType).

3. The optional BuyersItemIdentification element can be used to specify the buyer's article number.

4. The optional DeliveryDate element is only employed if the user explicitly wants delivery at a later time. The program does not have to provide this input option. If it nonetheless does, it is necessary to make sure that the user's input complies with any server constraints.  In particular, this input option is not to be offered if the server does not support specification of delivery dates. Furthermore, the date must not lie in the past.

5. The buyer and seller are assumed to agree as to whether or not unavailable articles should usually be delivered subsequently. The BacklogIndicator element is to be employed only if the user wants an explicit deviation from this rule. This option can, but need not be, offered to the user.

If the URL or URL-S binding is used, each of these elements must be translated into a sequence of parameters. This is done as follows: Suppose X is the content of an ID element of SellersItemIdentification. The names and values of the parameters used for serialization are then as follows:

Rule: Serialization of vco:OrderRequestLine

A Veloconnect-compliant server may implement the order transaction in the URL or URL-S binding only if the following is ensured:

1. Each item is uniquely identified by an item number, i.e. only the ID element in cac:SellersItemIdentification elements is required to identify items.

2. Item numbers containing the character = are not used.

The element vco:OrderResponse extends vct:TransactionResponseType with the elements vco:OrderResponseLine, vco:RequestRepla cement, vco:ItemUnknown, each of which can occur as often as necessary.

The element vco:OrderResponseLine comprises the following elements:

The element vco:RequestReplacement comprises two elements:

The type cac:ItemReplacementType extends cac:ItemIdentificationType with a mandatory element cac:ReplacementCode of type cac:ReplacementCodeType, as well as an optional element cbc:Description. The type cac:ReplacementCodeType can only have the following character strings as content:

• identical

• package

• recommended

The element vco:ItemUnknown contains one element cac:SellersItemIdentification..

vco:AvailabilityType

The type vco:AvailabilityType comprises the following elements:

Rule: CreateOrder

A Veloconnect-compliant server responds to a CreateOrderRequest as follows:

1. If no TransactionID is conveyed in the request, a new transaction instance is created. If this is not possible, ResponseCode 421 is returned.

2. If a TransactionID is conveyed in the request, a check is made as to whether a related transaction instance already exists. If it does, and it is not in the initial or final state, processing of the request is aborted and ResponseCode 430 is returned. Otherwise the transaction context is deleted and the transaction instance switched to state 1.

3. Each OrderRequestLine element is handled according to the OrderRequestLine (server) rule. In this process, OrderResponseLine elements are created in the transaction context, and RequestReplacement elements are created where necessary.

4. Inserted into the response are the OrderResponseLine elements from the transaction context, as well as the RequestReplacement elements created in the previous step. The response is delivered with ResponseCode 200 to the client, and the transaction instance is switched to state 2 (updated).

Rule: OrderRequestLine(server)

If an OrderRequestLine element is given, then the transaction context is modified as follows:

1. A check is made as to whether SellersItemIdentification is a valid item identifier. If not, and Rule: RequestReplacement is applicable, it is used as a basis for generating a RequestReplacement element, otherwise the conveyed SellersItemIdentification is packed into an ItemUnknown element.

2. If SellersItemIdentification is a valid item identifier, an OrderResponseLine element is created. The elements comprising Quantity, DeliveryDate and BacklogIndicator are taken over, the following modifications being possible here:

   1. If only certain values are permissible for the ordered quantity, it can be adjusted to the nearest valid value (example: piece is used as the unit, but delivery takes place only in packages of 100 pieces each).

   2. If the desired delivery date cannot be met, the date can be set to a different value which should be as close as possible to the desired date.

   3. If the server cannot process details concerning the delivery date, or only do so under constraints, these constraints must be specified in the Order.DeliveryDate property of the Veloconnect profile.

   4. If subsequent delivery is not possible in the desired manner, the BacklogIndicator element must be set accordingly.

3. The BuyersItemIdentfication element should be applied, but does not have to be if the system is unable to store this information in the transaction context.

4. The master data of the identified item are determined from the merchandise management system and stored in the Item element.

5. The item's net unit price must be stored in the UnitPrice element. This unit price refers to the unit specified in Quantity. The total price of an item is thus determined by multiplying the unit price (UnitPrice) by the number (Quantity).

6. The item's availability is determined from the data currently existent in the merchandise management system, and stored as per Rule: Availability in the Availability Element. If the server does not provide this information, it must be specified by the Order.Availability attribute in the Veloconnect profile.

7. The created OrderResponseLine element is stored in the transaction context, where it replaces any existent element possessing the same item identifier. If the specified quantity is 0, the element is removed from the transaction context.

Rule: RequestReplacement

If the server receives, from the client, an item identifier which is no longer part of the current assortment, but can still be interpreted by the server in the context of a plan to make one or more proposals for replacement, this is communicated with the vco:RequestReplacement element. The child element vco:SellersItemIdentification is taken over unchanged from the request; for each replacement item, a cac:ItemReplacement element is formed according to the rule described next.

Rule: ItemReplacement

A replacement item is communicated by a cac:ItemReplacement element. The child element cac:ReplacementCode of type cac:ReplacementCodeType qualifies the proposal as follows:

Rule: Availability

An item's availability is communicated in an element of type vco:AvailabilityType. The contents of its child elements in a Veloconnect-compliant implementation are governed by the rules mentioned next.

1. In the vco:Code element, availability is coded as follows:
   - available: The item is available in the desired quantity.
   - partially_available: The item is available only in a partial quantity.
   - expecting_delivery: The item is not available in the desired quantity, but delivery in the foreseeable future is expected by the buyer.
   - not_available: The item is not available. Further details cannot be provided.

2. The available quantity is specified in the AvailableQuantity element. This detail is specified only if the partially_availlable or expecting_delivery code is used. If the partially_available code is used, the available quantity must be specified.

3. The cbc:ExpectedDeliveryDate element indicates when the seller is expected to be able to deliver the requested quantity. This element should be used only if the expecting_delivery code is used. If this element is not specified in such cases, the Order.expectingDelivery attribute in the server's Veloconnect profile must specify the time period in which delivery can be expected.

4. If the seller wants to specify one or more replacement items, this can be done with the ItemReplacement element according to the Rule: ItemReplacement.

Rule: OrderResponse(client)

A Veloconnect-compliant client assigns each of the returned elements comprising OrderResponseLine and RequestReplacement a line of the normalized order via the order number (SellersItemIdentification) and checks, for each line of the normalized order, whether one of the cases mentioned next exists. Every occurrence of such a case is to be communicated with all the relevant information to the user, who then has the option to change the order and continue the process, or cancel ordering. Alternatively, it is possible to specify rules about how orders are to be modified in each of these cases, and the conditions under which the modified orders are to be processed further or cancelled. For each individual item of an order, each of the following cases must be taken into account:

1.  The line is assigned an ItemUnknown element. The order number is presumably incorrect.

2. The line is assigned a RequestReplacement element. The order number is presumably outdated.

3. The article is fully or partly unavailable. For this and the following cases, the line is assumed to have been assigned an OrderResponseLine element.

4. The quantity indications differ.

5. The order explicitly specifies a delivery date differing from the specification in OrderResponseLine.

6. The order explicitly specifies subsequent delivery procedures differing from the specification in OrderResponseLine.