Description of objects

The element type cac:ItemType is used to describe objects. The following elements are used here:

Rule: ItemType

The following rules apply to Veloconnect-compliant implementations:

1. The element cbc:Description must be filled with a text which allows the knowledgeable reader to recognize the item being described.

2. The element cac:SellersItemIdentification contains the seller's identification of the item, and must not be empty unless it signifies an item within a position in the receipt modul (document management).

3. The element cac:BuyersItemIdentification may contain the seller's internal identification of the item.

4. If an EAN code is known for the item, it must be communicated by the element cac:StandardItemIdentfication. This has to be done regardless of whether one of the other two item identifiers is already an EAN code.

5. If no EAN code is known, but the manufacturer's article number is, it must be communicated by the element cac:ManufacturersItemIdentfication. The manufacturer must be specified via this element's child cac:IssuerParty. This is done either via an ID in the PartyIdentification child element, where the manufacturer can be identified via a public database (e.g. ILN/GLN), or via the name in the PartyName child element.

6. If quantity indicators for the item are used in the package unit, either the PackQuantity element must indicate which quantity corresponds to a package in another unit, or the PackSizeNumeric element must specify how many pieces a package contains. No more than one of these two elements may be used. In particular, a use of

   <PackSizeNumeric>x</PackSizeNumeric>

   is equivalent to a use of

   <PackQuantity quantityUnitCode="EA">x</PackQuantity>.

   (x represents any number).

7. At least one cac:BasePrice element is present.

8. The prices specified in the cac:BasePrice elements are always net prices, and all have the same unit of quantity.

9. If the unit of cac:BasePrice elements is package, conversion into another discrete unit or physical unit must be specified in the element cbc:PackQuantity or cbc:PackSizeNumeric.

10. The price function is defined by the cac:BasePrice elements for all quantity indications with positive values whose unit is comparable to the unit of the cac:BasePrice elements.

11. The price specified in RecommendedRetailPrice is gross, unless the server's Veloconnect profile property RecommendedRetailPrice.Netto indicates that net prices are being used. Also used is a quantity unit comparable to the unit of the BasePrice elements.

12. The optional element ItemInformation should be used according to Rule: ItemInformation.

13. If different turnover tax rates are applicable, the tax rate valid for the concerned item can be communicated using the optional TaxCategory element.  Here, the FULL ID is used for the full tax rate, and the REDUCED ID is used for the reduced tax rate.  VAT is used as the ID of the TaxScheme element. For clarity, more complex tax rates can be communicated using the percent element.

From the requirements so far, it follows that at least one unit is always explicitly indicated for an item. If the package unit is included, conversion into another discrete unit or physical unit of measure is also given.

 Which units a seller uses for their articles is ultimately their decision, and also depends on whether their merchandise management system is able to handle units.  It is therefore quite possible for an article to be considered as a single piece, even though a different unit would be more appropriate. Retailers' merchandise management systems are generally able to deal with this situation: The user must ultimately specify a conversion factor per article, in order to harmonize the units used for sale with the units used for the purchase order. Of course, this is a source of mistakes and misunderstandings.

The correct unit for each article is assumed to be clear for the experts involved. Describing objects by means of elements of type cac:ItemType makes it possible to explicitly communicate this information so as to allow automatic conversion of units. A lack of this information can ultimately only be due to the fact that the information is not available in the merchandise management system.

Rule: Use of units.

• A Veloconnect-compliant server must fulfil exactly one of the following requirements:

  1. The correct units are used for all articles, a differentiation between piece, pair and set being dispensable, and piece and package being permissible for exclusive use as discrete units. Which unit is correct must be decided on the basis of the catalogues and documents usually available to customers. If an article is to be ordered only in certain multiples of the base unit, then package must be defined as the unit, otherwise package must be dispensed with.verzichten.

  2. Piece is used as a unit for all articles, and the server communicates this limitation in its Veloconnect Profile via the attribute quantityUnitCode.EA.

• If the client submits a quantity for an object which uses a unit not comparable to the units used in the description of the object, the server replaces the unit as follows:

To illustrate the advantage of handling units correctly, here are two popular examples from the bicycle industry:

The manufacturer packs spokes in cartons of 72 pieces each and sells these as units. The retailer buys the spokes in these units and then sells them individually to end customers. The wholesaler accordingly uses package as a unit for indicating quantities and declares by means of <PacksizeNumeric>72</PacksizeNumeric>, for example, that a package corresponds to 72 pieces. Under such conditions, a customer could order 1440 spokes and receive an order confirmation for 20 packs of spokes, without this "correction" requiring human intervention. Of course, this is not possible if the package size is mentioned simply in the article description, and the wholesaler's merchandise management system treats a package of 72 spokes as one unit.

A wholesaler sells gearshift cables each configured as a roll 30 metres long. The retailer processes and sells the cables in the required length. Accordingly, a wholesaler uses package as a unit for the gearshift cable and declares via

<PackageQuantity quantityUnitCode="MTR">30</PackageQuantity>

that a package corresponds to a length of 30 metres. Under these conditions, the retailer can therefore order 180 metres of gearshift cable, and receives an order confirmation for 6 rolls of such cable, the purchase price being specified here per roll, and the recommended selling price being specified per meter, for example.

Provided next is a further example to avoid misunderstandings: A wholesaler sells brake cables. These are furnished with a nipple at one end, and available in lengths of 2 metres and 4 metres. These brake cables are sold in packages of 50 pieces each. The length of 2 or 4 meters should not lead to the conclusion that the package comprises a quantity of 100 or 200 meters respectively! A package still comprises 50 pieces, length being a characteristic of the article, and registered generally through a use of different article numbers. 

Existent in practice are online ordering interfaces which enable the following: An order confirmation line essentially indicates the ordered quantity (in numeric format), the article number, and a unit price (also in just numeric format). It is possible for the concerned article to comprise a package of 100 pieces, for the quantity to indicate the number of packages, and for the unit price to be actually the price of a piece, and not the price of a package. For other packaged articles, however, the unit price is actually the price of a package. That is obviously impractical, simply insufficient information is conveyed, and the implemented interface is unable to replace the missing information through compliance with a general rule, such as the unit price always referring to the same quantity as the number.