Management of E-Procurement

The following sections introduce classification systems for the identification of products and business partners. Subsequently, catalog formats for the exchange of this data will be discussed. Special attention is paid to the data transfer between the systems. At the end of this chapter, various e-procurement standard solutions will be described.

As mentioned above, we distinguish between product information (for catalogs) and business documents (for transactions).

This data is needed in two different transaction types:

  1. Exchange of product information
  2. exchange of business documents (for example order, confirmation, invoice)

Data transfer between the systems

While Round Trip and PunchOut represent procedures for accessing product data, EDI, SAP Business Connector and openTRANS are geared towards the transfer of business documents.

Round Trip (Commerce One)

The round trip is designed to combine the advantages of sell-side solutions with those of a buy-side solution. The logic of the procurement process lies with the buyer. During the ordering process, the supplier catalog of the sell-side system is accessed online. There, the shopping cart is put together and then handed over to the buy-side system. This allows the purchaser to tailor the software to his internal needs while still optimally selecting the supplier’s products. Access is via the Open Catalog Interface (OCI interface, see case study Bühler, p. 45 and UBS, p. The round trip does not trigger an order in the supplier’s shop. This is transmitted separately.

PunchOut (Ariba)

Similar to the Round Trip, Ariba uses the term PunchOut. If the rocurement process is handled with a punch-out, the catalog is kept by the supplier and is also maintained by him. The order logic is handled by the purchaser’s system. The “PunchOut Catalog” accepts the purchase requisition of a purchasing system and identifies the user. Depending on the user profile, it only displays the defined products and prices. The buyer can select the desired items online. At the end of the selection process, the system transfers the data in cXML format to the buy-side solution.


EDI (Electronic Data Interchange) is the term that has been used for many years to describe the electronic exchange of structured business documents between various business partners (for example, orders, invoices, delivery notes). These structured data are often documents that are needed repeatedly in a business process in the same form. These are brought
into a standardized format for the exchange, which is known to all involved partners. The goal is to record data once in electronic form and make it available to all participants for further processing without a new acquisition. Although EDI could stand for any form of data transfer, the three letters in Europe are linked to the document format UN / EDIFACT (United Nations / Electronic Data Interchange for Administration, Commerce and Transport). Over time, industry standards have developed (e.g., ODETTE for the automotive industry). In EDI transactions, an intermediary, a value added network (VAN), is usually involved as an intermediary between business partners.

E-procurement standard solutions

The range of e-procurement systems is large. In the case studies of this book, above all the Enterprise Buyer Professional from SAP and services of the company Conextrade (based on Commerce One) are presented.

SAP Enterprise Buyer Professional (EBP)

The Enterprise Buyer Professional (EBP) is the e-Procurement application of SAP. The shopping basket, approval and account assignment are created in SAP EBP. The order is created internally in the R / 3 back-end system and sent to the supplier as an XML file via the Business Connector. In the example of Bühler (p. 45), the purchasing company administers its own users. At the same time, the disadvantage of conventional buy-side solutions with a product catalog stored with the customer is avoided. The catalog is stored in the e-shop at the supplier and is constantly updated there. The purchaser maintains his own buy-side system and the supplier
maintains the catalog.

Commerce One

Conextrade’s “Purchase Management ASP” platform is based on the Enterprise Buyer Desktop 2.0 software from Commerce One. This product was originally a joint development of SAP Markets and Commerce One. It is examined in detail in the case study Nordostschweizerische Kraftwerke (p. 89). The case study Schindler describes the use of “Auction Services 4.1”, another solution from Commerce One.


Conextrade is a Swiss Procurement Service Provider. The company offers consulting and implementation, catalog management, transaction management and e-services. Conextrade AG is a wholly owned subsidiary of Swisscom. Since June 2000, Conextrade has been operating the leading electronic marketplace in Switzerland. The Conextrade platform connects procurement processes across companies. Buyers and suppliers benefit from one integrated electronic process support, which enables the exchange of data and documents of different origin.