Module: Receipt

From version 1.3, Veloconnect's receipt module offers the possibility of conveying electronic business documents as part of document management.

 It does not matter here whether the document is related to an order via Veloconnect. Accordingly, delivery notes, order confirmations and invoice details which originated in phone, written or online orders are also submitted to the trader's merchandise management system. For the trader, this fills a gap which has so far entailed considerable manual effort.

 The following documents are currently available:

1. Offer

2. OrderConfirmation

3. DeliveryNote

4. InvoiceInformation

The structure and use of the individual document types always follow the same pattern. For every document type X, there is an XQuery operation consisting of XQueryRequest and XQueryResponse, as well as an XDetails operation consisting of XDetailsRequest and XDetailsResponse. As usual, the request and response elements are derived from vct:RequestType and vct.ResponseType.

 A Veloconnect server which supports document type X must therefore implement the two operations XQuery and XDetails, and publish them accordingly in its profile.

 Provided below is a scheme showing the sequence of the individual steps on the client and server during querying of documents.

Open

However, it is not mandatory for a QueryResponse to be evaluated beforehand for a DetalsRequest. For example, if the data of a DetailsResponse contain references to other documents, they can then be used directly to request the corresponding details of these linked documents

1. QueryRequest

 The Veloconnect client uses the QueryRequest element to retrieve header data for the respective document type. A date range (DateRangeType) consisting of FromDate and ThruDate is always available as a search parameter. This search parameter always refers to the document date (IssueDate) of the related document type. Specifying this search parameter selects all documents whose date is later than or equal to FromDate, and earlier than or equal to ThruDate. Because FromDate and ThruDate are optional parameters, the document date is only compared if the corresponding element exists. Cases in which neither FromDate nor ThruDate is present are to be handled just like cases in which no DateRange has been specified.

 In the case of the URL(-S) binding, the two elements FromDate and ThruDate of DateRange are serialized as FromDate and ThruDate QueryParameters.

 Depending on the document type, there are further specific search parameters, each comprising IDs of linked documents. These search parameters are to be understood as a means of full text searches in the corresponding document fields.

 Each QueryRequest thus submits a - possibly empty - list of search parameters.

 Example: Via the OfferQueryRequest element, the Veloconnect client retrieves all offers provided by the Veloconnect server for the authorized client.

2. QueryResponse:

Via the QueryResponse element, the Veloconnect server supplies all header data concerning documents of the respective type, to which at least one of the search parameters conveyed in the query applies.

The server may limit the list of returned header data. If limitation takes place, the server's QueryResponse must communicate a date range and ensure that the search result based on the search parameters is complete for the specified DateRange in the response.

The DateRange in the response must be included in the query if it has specified a range, otherwise the range must extend to the current date.

Unless necessitated otherwise by important reasons, the limit must be such that the time range is at least 3 months, or the header data comprise at least 200 elements.

 Example: Via the OfferQueryResponse element, the server provides all available offers to the authorized client in response to its OfferQueryRequest element.

3. DetailsRequest:

The Veloconnect client uses the document IDs provided by the server from the QueryResponse operation to retrieve details related to these document IDs.

Example: Via the OfferDetailsRequest element, the client issues an ID to retrieve related details concerning an offer.Der Veloconnect-Client nutzt die durch den Server bereitgestellten IDs von Belegen aus der Operation QueryResponse, um die Detailwerte zu diesen Beleg-IDs abzufrufen.

4. DetailsResponse:

Via the DetailsResponse element, the Veloconnect server provides all the details about the list of IDs submitted in the DetailsRequest. The server can limit the returned list, if the list in the request contains more than 200 elements.

 Example: The server provides all the details of a single offer via the OfferDetailsResponse element.QueryRequest