Page Comparison

Die Anfrage ist ein Element The request constitutes a vco:CreateOrderRequest, die Antwort ist ein Element element, the response a vco:OrderResponse element. Das Element The vco:CreateOrderRequest erweitert den Typ element extends vct:RequestType um das Element with the vco:OrderRequestLine, welches mindestens einmal vorkommen muss. Dieses besitzt die folgenden Elemente element which must occur at least once. It comprises the following elements:

...

Rule: CreateOrderRequest

Ein veloconnect-konformer Client vehält sich wie folgt: Für die Zwecke der Transaktion Order wird davon ausgegangen, dass die Bestellung normalisiert ist, d.h. je zwei verschiedene Zeilen der Bestellung beziehen sich auf verschiedene Artikelkennzeichnungen des Verkäufers (kurz: Bestellnummer). Zu jeder Zeile dieser Bestellung wird ein Element OrderRequestLine wie folgt angelegt:

...

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. Das Element SellersItemIdentifcation enthält die Bestellnummer.

2. Das Element Quantity enthält die Bestellmenge (vgl. Absatz The SellersItemIdentifcation element contains the order number.

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

4. Das optionale Element BuyersItemIdentification kann für die Angabe der Artikelnummer des Käufers verwendet werden.

5. Das optionale Element DeliveryDate wird nur verwendet, wenn vom Benutzer explizit eine Lieferung zu einem späteren Zeitpunkt gewünscht wird. Das Programm muss diese Eingabemöglichkeit nicht vorsehen. Falls es dies doch tut, ist dafür Sorge zu tragen, dass die Eingabe des Benutzers möglichen Einschränkungen des Servers genügt. Insbesondere ist diese Eingabemöglichkeit nicht anzubieten, wenn der Server die Angabe eines Liefertermins nicht unterstützt. Ferner darf das Datum nicht in der Vergangenheit liegen.

6. Es wird davon ausgegangen, dass zwischen Käufer und Verkäufer eine Verreinbarung herrscht, ob nicht lieferbare Artikel üblicherweise nachzuliefern sind oder nicht. Das Element BacklogIndicator ist nur zu verwenden, wenn der Benutzer eine explizite Abweichung von dieser Regel wünscht. Dem Benutzer kann diese Möglichkeit eröffnet werden, muss aber nicht.

...

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

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

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

Ein veloconnect-konformer Server darf die Transaktion Order in der URL- oder URL-S-Bindung nur dann implementieren, wenn gewährleistet ist:

1. Jeder Artikel ist durch eine Artikelnummer eindeutig gekennzeichnet, d.h. zur Kennzeichnung von Gegenständen wird nur das ID-Element in Elementen cac:SellersItemIdentification benötigt.

2. Es werden keine Artikelnummern verwendet, in denen das Zeichen = vorkommt.

Das Element vco:OrderResponse erweitert den Typ vct:TransactionResponseType um die Elemente 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:RequestReplacementRequestRepla cement, vco:ItemUnknown, die jeweils beliebig oft vorkommen können.Das Element vco:OrderResponseLine ist aus folgenden Elementen aufgebauteach of which can occur as often as necessary.

The element vco:OrderResponseLine comprises the following elements:

...

The element vco:RequestReplacement besteht aus zwei Elementencomprises two elements:

...

The type cac:ItemReplacementType erweitert den Type extends cac:ItemIdentificationType um ein verbindliches Element with a mandatory element cac:ReplacementCode vom Typ of type cac:ReplacementCodeType sowie ein optionales Element , as well as an optional element cbc:Description. Der Typ The type cac:ReplacementCodeType kann nur folgende Zeichenketten als Inhalt habencan only have the following character strings as content:

• identical

• package

• recommended

Das Element The element vco:ItemUnknown enthält ein Element contains one element cac:SellersItemIdentification..

vco:AvailabilityType

Der Typ The type vco:AvailabilityType besteht aus folgenden Elementencomprises the following elements:

...

Rule: CreateOrder

Ein veloconnect-konformer Server reagiert auf ein Anfrage CreateOrderRequest wie folgt:

1. Falls in der Anfrage keine TransactionID übermitttelt wird, wird eine neue Transaktionsinstanz erzeugt. Falls dies nicht möglich ist, wird der ResponseCode 421 zurückgeliefert.

2. Falls in der Anfrage eine TransactionID übermittelt wird, wird überprüft, ob hierzu schon eine Transaktionsinstanz existiert. Falls eine solche existiert und sich diese weder im Startzustand noch im Endzustand befindet, wird die Bearbeitung der Anfrage abgebrochen und der ResponseCode 430 zurückgeliefert. Ansonsten wird der Transaktionskontext gelöscht und die Transaktionsinstanz in den Zustand 1 versetzt.

3. Mit jedem Element OrderRequestLine wird gemäß der Regel OrderRequestLine(Server) verfahren. Hierbei werden im Transaktionskontext Elemente OrderResponseLine angelegt, sowie eventuelle Elemente RequestReplacement erzeugt.

4. Aus dem Transaktionskontext werden die Elemente OrderResponseLine in die Antwort eingefügt, sowie die im vorherigen Schritt erzeugten Elemente RequestReplacement. Die Antwort wird mit ResponseCode 200 an den Client ausgeliefert und die Transaktionsinstanz wechselt in den Zustand 2 (Updatezustand)

Regel: OrderRequestLine(Server)

Es sei ein Element OrderRequestLine gegeben. Der Transaktionskontext wird wie folgt modifiziert:

1. Es wird überprüft, ob SellersItemIdentification eine gültige Artikelkennzeichnung ist. Falls dies nicht der Fall ist und Regel: RequestReplacement anwendbar ist, wird gemäß dieser Regel ein RequestReplacement-Element erzeugt, ansonsten wird die übergebene SellersItemIdentification in ein ItemUnknown-Element verpackt.

2. Falls SellersItemIdentification eine gültige Artikelkennzeichnung ist, wird ein Element OrderResponseLine erzeugt. Die Elemente Quantity, DeliveryDate, BacklogIndicator werden übernommen, wobei folgende Modifikationen möglich sind:

   1. Falls für die Bestellmenge nur gewisse Werte zulässig sind, kann die Menge auf den nächsten gültigen Wert angepasst werden. (Beispiel: Als Einheit wird Stück verwendet, die Abgabe erfolgt aber nur in Packungen zu 100 Stück.)

   2. Falls das gewünschte Lieferdatum nicht eingehalten werden kann, kann das Datum auf einen anderen Wert gesetzt werden. Dieser sollte möglichst nahe beim gewünschten Termin liegen.

   3. Falls der Server nicht in der Lage ist, Angaben zum Liefertermin zu verarbeiten oder nur unter Einschränkungen, müssen diese Enschränkungen im veloconnect-Profil in der Eigenschaft Order.DeliveryDate angegeben werden.

   4. Sofern das gewünschte Nachlieferungsverhalten nicht realisiert werden kann, ist das Element BacklogIndicator entsprechend zu setzen.

3. Das Element BuyersItemIdentfication sollte übernommen werden, muss aber nicht, falls das System nicht in der Lage ist, diese Information im Transaktionskontext zu speichern.

4. Aus dem Warenwirtschaftssystem werden die Stammdaten des identifizierten Artikels ermittelt und im Element Item abgelegt.

5. Der Nettoeinzelpreis des Artikels ist im Element UnitPrice abzulegen. Dieser Einzelpreis bezieht sich auf die in Quantity angegebenen Einheit. Der Gesamtpreis eines Posten ergibt sich also durch Multiplikation des Einzelpreises (UnitPrice) mit der Anzahl (Quantity).

6. Die Verfügbarkeit des Artikels wird aus aktuell verfügbaren Daten des Warenwirtschaftssystems ermittelt werden und gemäß Regel: Availability im Element Availability abgelegt werden. Falls der Server diese Information nicht zur Verfügung stellt, muss dies im veloconnect-Profil mittels der Eigenschaft Order.Availability angegeben werden.

7. Das erzeugte Element OrderResponseLine wird im Transaktionskontext gespeichert und ersetzt dort ein eventuell schon vorhandenes Element mit der gleichen Artikelkennzeichnung. Falls die angegebene Menge den Wert 0 hat, so wird das Element aus dem Transaktionskontext entfernt.

Regel: RequestReplacement

Erhält der Server vom Client eine Artikelkennzeichnung, die nicht mehr zum aktuellen Sortiment gehört, aber dennoch soweit vom Server interpretiert werden kann, dass er einen oder mehrere Ersatzvorschläge unterbreiten will, so wird dies mit dem Element vco:RequestReplacement mitgeteilt. Das Kind-Element vco:SellersItemIdentification wird unverändert aus der Anfrage übernommen, für jeden Ersatzartikel wird ein Element cac:ItemReplacement gemäß nachfolgender Regel gebildet.

Regel: ItemReplacement

Ersatzartikel werden durch ein Element cac:ItemReplacement mitgeteilt. Das Kind-Element cac:ReplacementCode vom Typ cac:ReplacementCodeType qualifiziert den Vorschlag wie folgt:

Regel: Availability

Die Verfügbarkeit eines Artikels wird in einem Element vom Typ vco:AvailabilityType mitgeteilt. Die Inhalte seiner Kind-Elemente einer veloconnect-konformen Implementierung genügen den folgenden Regeln.

1. Im Element vco:Code wird die Verfügbarkeit wie folgt kodifiziert:
   - available: Der Artikel ist in der gewünschten Menge lieferbar
   - partially_available: Der Artikel ist nur in einer Teilmenge lieferbar
   - expecting_delivery: Der Artikel ist nicht in der gewünschten Menge lieferbar, eine Lieferung wird aber durch den Käufer in absehbarer Zeit erwartet
   - not_available: Der Artikel ist nicht lieferbar. Weitere Angaben sind nicht möglich.

2. Im Element AvailableQuantity wird die lieferbare Menge angegeben. Eine Angabe erfolgt nur, wenn der Code partially_availlable oder expecting_delivery verwendet wird. Falls der Code partially_available verwendet wird, muss die lieferbare Menge angegeben werden.

3. Im Element cbc:ExpectedDeliveryDate wird mitgeteilt, wann der Verkäufer voraussichtlich die angeforderte Menge liefern kann. Dieses Element ist nur dann zu verwenden, wenn der Code expecting_delivery verwendet wird. Wenn in diesem Falle dieses Element nicht ausgefüllt wird, muss der Server in seinem veloconnect-Profil mit der Eigenschaft Order.expectingDelivery angeben, in welchem Zeitraum mit der Lieferung zu rechnen wird.

4. Falls der Verkäufer einen oder mehrere Ersatzartikel angeben möchte, kann dies mit dem Element ItemReplacement gemäß Regel: ItemReplacement geschehen.

...

In Webshops wird zur Kennzeichnung der Verfügbarkeit von Artikeln zumeist ein Ampelsystem mit den Farben grün, gelb und rot verwendet. In der veloconnect Terminologie haben wir folgende Entsprechung:

• available: grün

• partially_available: gelb

• expecting_delivery: gelb

• not_available: rot

Bei Ampelfarbe gelb können mit veloconnect zusätzliche Informationen übermittelt werden. Die übermittelten Angaben zur Verfügbarkeit sollen den Einzelhändler in die Lage versetzen, zu entscheiden, ob und wann mit einer Lieferung zu rechnen ist, um ggf. auch nach Alternativen zu suchen.

Es ist dazu nicht erforderlich, die exakten Lagerdaten per veloconnect nach aussen zu geben. Folgende Massnahmen bei der Implementierung sind also völlig legitim und konform zur Spezifikation:

• ist der Lagerbestand ausreichend, wird immer available übermittelt, auch wenn die angefragte Menge den Lagerbestand überschreitet

• bei partially_available oder expecting_delivery kann als lieferbare Menge durchaus auch die angefragte Menge anstelle der tatsächlich lieferbaren Menge angegeben werden

Es liegt in der Verantwortung des Lieferanten zu entscheiden, wie aktuell die Daten sind, aufgrund deren die Verfügbarkeit ermittelt wird. Es ist dabei völlig legitim, abhängig vom Kontext mit unterschiedlichen Datengrundlagen zu arbeiten. Z.B. beim Download aller Artikeldaten per TextSearch oder bei massenhaften Artikelabfragen per GetItemDetailsList sind die Anforderungen an die Aktualität nicht so hoch wie im Kontext einer Bestellung oder bei Abfrage einzelner Artikel per GetItemDetails.

Umgekehrt daraus ergibt sich für Clients:

• Verfügbarkeiten sollten im Bestellkontext immer direkt vom veloconnect Server geholt werden

• massenweise Abfrage von Verfügbarkeit hat keinen Sinnn

Regel: OrderResponse(Client)

Ein veloconnect-konformer Client ordnet jedem der zurückgelieferten Elemente OrderResponseLine und RequestReplacement eine Zeile der normalisierten Bestellung mittels der Bestellnummer (SellersItemIdentification) zu, und überprüft für jede Zeile der normalisierten Bestellung, ob einer der folgenden Fälle vorliegt. Jedes Vorkommnis eines solchen Falles ist dem Benutzer mit allen relevanten Information mitzuteilen. Dieser hat daraufhin die Möglichkeit, die Bestellung abzuändern und den Bestellvorgang fortzusetzen oder abzubrechen. Alternativ besteht auch die Möglichkeit, Regeln festzulegen, wie in jedem dieser Fälle die Bestellung modifiziert werden soll und unter welchen Bedingungen mit der modifizierten Bestellunge fortgefahren wird oder diese abgebrochen wird. Für jeden einzelnen Posten der Bestellung ist jeder der folgenden Fälle zu berücksichtigen:

...

Die Zeile ist einem Element ItemUnknown zugeordnet worden. Es ist davon auszugehen, dass die Bestellnummer falsch ist.

...

Die Zeile ist einem Element RequestReplacement zugeordnet worden. Es ist davon auszugehen, dass die Bestellnummer veraltet ist.

...

Der Artikel ist nicht oder nicht vollständig lieferbar. (Für diesen und die folgenden Fälle ist vorausgesetzt, dass der Zeile ein Element OrderResponseLine zugeordnet wurde.)

...

Die jeweiligen Mengenangabe sind verschieden.

...

In der Bestellung ist ein Lieferdatum explizit angegeben und dieses weicht ab von der Angabe in OrderResponseLine.

...

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.