GB2380275A

GB2380275A - Electronic procurement system

Info

Publication number: GB2380275A
Application number: GB0123318A
Authority: GB
Inventors: Andrew Holyoak; Peter Cartwright
Original assignee: Electrocomponents PLC
Current assignee: RS Group PLC
Priority date: 2001-09-28
Filing date: 2001-09-28
Publication date: 2003-04-02
Also published as: GB0123318D0

Abstract

A system (8) for use in electronic procurement for operatively interconnecting a customer eProcurement management systems (2a,2b,2c) and a supplier's electronic web site (10). The system (8) comprising an interface means which provides means (12) to identify a request to connect to the web site (10) received from the customer eProcurement system (2a,2b,2c), means (14) to determine key settings details, and a means (20) to open and configure a session on the supplier web site (10) using the determined settings and connect a customer user (3) on a remote customer computer system web site.

Description

ELECTRONIC PROCUREMENT SYSTEM

The present invention relates generally to electronic commerce (eCommerce) and in particular to electronic procurement (Procurement) systems and methods of electronically ordering items from suppliers. Specifically the present invention relates to a method and system for connecting, and transacting electronic purchasing between, a customers eProcurement/legacy/ERP (enterprise resource planning) systems and a supplier's Internet electronic web site computer system.

Electronic commerce (eCommerce) and electronic procurement (Procurement) is becoming an increasingly popular means by which customers purchase goods from suppliers, in both a business to business (B2B) and customer to business (B2C) arrangements. A key advantage of such systems is the reduced paperwork and costs associated with purchasing goods from suppliers. ECommerce also offers increased order speed, access to a greater range of up to date product information and can reduce manual order errors by controlling the ordering and procurement process. Such systems offer suppliers new means of selling goods (and services) to a wider customer base, and for customers offer access to a wider range of goods and suppliers. The development of the Internet, and global electronic communication networks is also linked to the increased development of eCommerce.

In a simple form of eCommerce, a supplier provides an Internet website containing an electronic catalogue of products. A customer logs onto the supplier website and selects the items to be purchased, placing an electronic order for the goods and specifying the delivery address, payment method (eg. account details, credit card details etc. ) and any other relevant information. The order is then processed and the goods are delivered to the customer. The

supplier web site may also include detailed product information and other supplier information. Examples of such systems are well known and increasingly common. Examples include the website offered by Amazon. com, and the rswww. com website of RSComponents Ltd amongst many others.

Whilst such systems provide many advantages, and are particularly suited to an individual consumer (B2C) purchasing of goods, for company or organisation customers (B2B), such systems have limitations. In particular with such systems there are limited purchasing controls, which are often required to prevent rogue ordering and monitor the organisation or companies purchasing. Such systems and the purchasing of goods through such channels are also difficult to integrate into the corporate/organisation purchasing systems common in such organisations.

Companies and organisations often have their own procedures and systems for managing purchasing of goods and controlling financial transactions. Various electronic computer systems, often referred to as Enterprise Resource Planning systems (ERP), are available and are used by companies to handle and manage the organisation. Examples of such systems are available from vendors such as Ariba, Oracle and SAP. In particular, and by way of illustrative example, a system from Ariba (Ariba ORMS (Operating Resource Management System) ) is described in International Patent application number PCT/US98/08407.

These systems are loaded onto a company's or organisation's main computer system and servers and are accessed by the company users from distributed terminals via an internal Intranet arrangement. Such systems typically include electronic purchasing modules, incorporating purchase controls, approval systems, order tracking and control functionality.

In one common configuration, using such organisation/company systems, a customer organization

obtains an electronic catalogue from a number of suppliers. These electronic catalogues are stored on the customer organisation's computer systems with the customer user selecting goods from the electronic catalogue. Once the required goods are selected, electronic orders can then be generated by the customers procurement system and submitted to the supplier either electronically (email, via Internet) or by conventional means (fax, printed purchase order). An examples of such a system is described in US patent number 5,319, 542, and in International Patent application number WO 98/49644. International Patent application WO 00/58948 describes a further improvement to the Ariba system disclosed in WO 98/49644 using a stored catalogue index.

Whilst such systems are well integrated into the customer organisation, and provide suitable controls and approval routines there are a number of problems with such systems. In particular the supplier catalogue held on the systems, and from which orders are placed, have to be maintained and kept up to date. This can be a considerable administrative burden on the customer organisation. For a supplier there is also a loss of control over what products are being offered to the customer organisation users, with there being a considerable chance that the catalogues does not include new products added, or includes discontinued products which are no longer available. In addition the catalogues included on the customer systems are required to be in a particular standardised format. This places a severe limitation on the suppliers.

Many suppliers are also desirous of building sophisticated catalogues with additional product information, and/or sophisticated methods of searching and selecting products with the suppliers own web site system providing such details. With the above systems the use of standardised catalogues and use of the customer procurement system to select products from these catalogues these

advantageous features are not available.

Furthermore each different customer system (for example an Oracle system, an Ariba system, etc) typically requires a different format of catalogue product information to be provided by the supplier. Consequently for a supplier dealing with a number of customers all using different systems there is a considerable burden upon providing suitable catalogues.

A development and alternate configuration for such systems that has recently been developed is known as'punchout'. Punch-out allows a customer user to connect to a supplier's website via the customer organisation's eProcurement system. The customer user then uses the functionality and information on the supplier's website to select items to be purchased (or simply browse the information, or interact in other ways) using the functionality and full features of the supplier's website.

Instead of processing an order on the supplier's website however, the supplier web site is configured to return the requested order (i. e. shopping basket) to the customer's eProcurement system for processing and actual order placement. Punch-out eProcurement systems are being offered by a number of vendors of eProcurement systems (for example Ariba, Oracle, SAP etc.).

Punch-out in effect, integrates the supplier's web site, and rich information and functionality provided on the web site, with the customer organisation's eProcurement system, and the procedures and controls (approval, budget setting etc. ). This tight integration provides an improved eProcurement tool and system which can reduce purchasing costs./ With the current punch-out systems, however, the supplier has to adapt and configure and tailor its web site to operate in a punch-out mode and to operate with the customer's eProcurement system. A single supplier will

however deal with a number of customer organisations and companies. Each of these customer companies may have a different eProcurement system (for example an Oracle system, an Ariba, an SAP system etc. ). These different procurement systems, supplied by different vendors whilst operating in principle in a similar manner, differ wildy in their specific implementation requirements to allow punch-out operation. These differences are also not simply related to the language protocol (which is briefly referred to in WO /58948) used to transfer data but are considerably more fundamental and relate to the format used, information included and organisation of information and details within the request as well as requirements for handling of the request. Indeed the differences are part of the differentiation between the procurement systems of the different vendors. Furthermore individual customer organisations may configure their different procurement systems differently for their own purposes.

Consequently, as a result of these differences a supplier has to specifically configure its website, or indeed provide separate tailored websites, for at least each of the different vendors eProcurement systems or each particular eProcurement system used by a customer. Otherwise the supplier will become tied to a particular vendor's eProcurement system, and/or will not be able to offer some customer organisations the punch-out ability. This different tailoring and/or separate websites may be in addition to possibly a separate website for direct, non punch-out connection and access by individual customer users.

As a result a considerable burden is placed upon a supplier in becoming punch-out enabled for its various different customers. The supplier is also to some extent beholding to the vendors of the eProcurement systems since they dictate the required changes need to the suppliers, own website to enable punch-out operation with the vendors

eProcurement system. Any changes made by the eProcurement system vendor's may also impact on the supplier requiring the supplier to make further changes to their website.

It is therefore desirable to provide an improved electronic procurement system, and/or method of electronically ordering items from suppliers, which a addresses the above described problems and/or which offers improvements generally.

In particular it would be desirable to provide an improved method and system to integrate, and operatively connect, a customer eProcurement system to a supplier web site. Such integration and interconnection arranged such that it can easily and straightforwardly operate with a wide range of eProcurement systems, whilst providing minimal impact to a suppliers conventionally configured order processing website.

According to the present invention there is provided a method and apparatus as described in the accompanying claims.

In an embodiment of the invention there is an electronic procurement system comprising a supplier computer system, a customer procurement system, and an interface module for establishing access between the customer computer system and supplier computer system. The supplier computer system comprising a product ordering and information module including an electronic catalogue of product details offered for sale and means to search, browse and select products from said catalogue. The customer procurement system on a customer computer system is adapted to handles and managing the procurement of products. The customer procurement system configured to issue a connection request for the customer computer system to access the product ordering and information module and electronic catalogue on the supplier computer. The interface module comprises: i) a means to identify the connection request

from the customer procurement system and determine the type of customer procurement system and format of the connection request ; ii) a settings determination means to, using details of the type of customer procurement system and format of the connection request, extract key details from the request and compile specific connection setting details in a supplier format ; and iii) a means to open and configure an access connection between the customer computer systems and the supplier computer based upon the connection settings details, allowing a customer user to access and interact with the electronic catalogue of supplier product details and select products to purchase.

Preferably the supplier computer system comprises a means to return details of selected products to be ordered to the interface module. The interface module further comprising : i) a means to generate a return product order request including the return details of the selected products. The means to generate the return request being selectively configured by the setting details compiled from the processing of the access request to generate a return product order request in the required format for the customer procurement system. And ii) a means to return the return product order request to the customer procurement system.

The supplier computer system may further comprise a database of settings details relating to a customer and customer procurement system. The setting determination means uses said extracted key details to identify the stored

settings details and compile the specific connection settings details using said stored settings details.

The interface module may further comprise an authentication module which is selectively operable in response to the specific connection setting details complied.

The interface module may specifically comprise a Java Servlet.

The interface module may comprise part of supplier computer system.

The product ordering and information module comprises a series of interlinked web pages. The communications between the customer and supplier computer systems are via the Internet.

In an embodiment of the invention there is also described a method of operationally interconnecting a customer procurement systems with a supplier computer systems comprising an electronic catalogue of product offered for sale by the supplier. The method comprising the following steps: i) identifying a connection request from the customer procurement system and determining the type of customer procurement system from the connection request ; i) extracting key details from the connection request, ii) compiling specific connection setting details in a common supplier format using said extracted key details ; and iii) opening and establishing a connection between the supplier computer system and customer computer system using said specific connection setting details.

There may be a means for a customer to select products form the electronic catalogue on said supplier computer

system. The method may then further comprise: iv) generating a supplier format product order request in a supplier format for customer selected products ; v) generating a customer format product order request, in the customer procurement system format, based upon the supplier format product order request and the setting details compiled from the access request ; vi) returning the customer format product order request to the customer procurement system.

In an embodiment of the invention there is described a system for use in electronic procurement for operatively interconnecting a customer eProcurement management systems and a supplier's electronic web site. The system comprising an interface means which provides means to identify a request to connect to the web site received from the customer eProcurement system, means to determine key settings details, and a means to open and configure a session on the supplier web site using the determined settings and connect a customer user on a remote customer computer system web site.

In such a system the interface means may further include a means to receive a details from the supplier web site of details of products to be ordered, a means to generate a return product order request, and a means to return the return product order request to the customer procurement system. The means to generate the return product order request may be selectively configured, by and using the determined settings details, to generate a return product order request in a required format for the customer procurement system.

The present invention will now be described by way of example only with reference to the following figures in

which: Figure 1 is a schematic illustration of the Electronic procurement system in accordance with the present invention; Figure 2 is a diagrammatic illustration of an embodiment of the present invention as integrated with a customer's Ariba ORMS eProcurement system showing the main information flows ; Figure 3 is a diagrammatic illustration of an embodiment of the present invention, similar to that of figure 2, but as integrated with a customer's Oracle eProcurement system showing the main information flows ; and Figure 3 is a diagrammatic illustration of an embodiment of the present invention, similar to that of figure 2, but as integrated with a customer's SAP eProcurement system showing the main information flows.

The present invention comprises an interface system 8, and method to, interconnect and interface between customer eProcurement systems 2a, 2b, 2c, and customer users using such systems to purchase products from suppliers, and a supplier web site 10 which is configured to provide details of the products for sale. A schematic overview of the main functionality and elements of an embodiment of the system is shown in Figure 1.

Referring to Figure 1, to handle and manage the purchasing of suppliers'goods various customer organisations have individual customer procurement systems 2a, 2b, 2c. Such customer procurement systems 2a, 2b, 2c are known and commercially available. Example systems include Ariba ORMS (Operating Resource Management System) from Ariba Technologies Inc of Sunnyvale-California. This system is described in International Patent application 98/49644. Other similar systems, with which the invention is applicable, include Oracle SSP, SAP Business Connector available from other vendors such as Oracle, SAP

respectively amongst others. Such commercial systems are commercially available and reference should be made to the detailed documentation on the particular systems available from the respective vendors.

Different customer organisations may each be using different such customer procurement systems 2a, 2b, 2c. For example a first customer organisation may have a first system 2a, for example an Ariba system, a second customer organisation may use an Oracle system 2b, and a third organisation may have, say, an SAP system 2c, etc.

The customer Procurement systems 2a, 2b, 2c are hosted locally on the customer organisations own computer systems, typically a server connected to and accessible by individual customer users and employees using distributed computer terminal over a customer computer network or Intranet. The individual customer users access their respective customer procurement systems 2a, 2b, 2c from individual computer terminals (PCs) using a standard browser (for example Microsoft Explorer, Netscape Navigator). The customer procurement systems 2a, 2b, 2c are configured to access/connect to the Internet 4, or other similar electronic communication system, through a firewall of the customer's computer system and connect/communicate with a supplier's computer system 6 and web site 10 hosted thereon.

Such accessing of a suppliers web site 10 via the Internet 4 from a customer procurement system 2a, 2b, 2c is known as 'Punch-out'. Punch-out is a known general technique which is supported and provided by most commercially available standard procurement systems 2a, 2b, 2c.

A supplier's computer system 6 hosts a suppliers web site 10 and a software module providing the interface functional module 8. The supplier's computer system 6, and interface module 8 and web site 10 are accessible to the Internet 4 and therethrough to the customer's procurement systems 2a, 2b, 2c and computer systems. The supplier's

website comprises a number of web pages and includes an electronic catalogue with details of the supplier products offered, and functionality to allow users using standard web browsers to search and select product items from the catalogue displayed. The web site 10 may also include other information and functionality to assist, or be of use to, a customer user in selecting and ordering product items or generally.

In the main embodiments of the invention an interface software module 8 comprises a Java Servlet which provides various functional processing routines/modules to process, and handle the interconnection, interfacing and communication between the customer procurement systems 2a, 2b, 2c and the suppliers web site 10. The functionality and operation embodied and provided by this interface module 8 will be described in more detail later with the module comprising computer coding to provide and embody this functionality.

The general operation and configuration will now be described. A customer user logs onto their customer procurement system 2a, 2b, 2c through a web browser. The customer user, within the customer procurement system 2a, 2b, 2c, selects to punch-out to a supplier's website 10 and create a punch out order for particular supplier's products. A URL for the particular supplier, and supplier computer system 8, to which a customer user can and is permitted to punch-out to and access is previously stored in the customer procurement system 2a, 2b, 2c. In response the customer procurement system 2a, 2b, 2c sends an HTTP connection request, via the Internet 4 to the supplier's computer system 8, and in particular to the interface module 8.

A first sub-module/routine 12 of the interface module 8 identifies the request received via the Internet 4 from the customer procurement system 2a, 2b, 2c. Punch-out requests

issued by customer procurement systems 2a, 2b, 2c vary in type, format and protocol. However the different connection requests generated by the different procurement systems 2a, 2b, 2c can be generally categorised as two different general forms.

The first form of request comprises the URL of the supplier computer system 6 with various additional parameters indicating specific details and additional information (variables). The identify subroutine 12 analyses the request and parameters and compares these with previously known formats and details of parameters which will be sent by different vendor eProcurement systems. In some cases an individual parameter may be sent in the request from a vendor eProcurement system identifying the vendor/type of system. In other cases the combination of parameters sent in the request has to be used to determine the type/vendor of the eProcurement system. In either case and in this way the type/vendor of eProcurement system issuing the request is identified and a unique parameter name (relating to the eProcurement system/vendor of the system sending the request; eg Ariba system, Oracle system) is assigned to identify the type/format of request. This identifier is associated with the request and used to flag to the remainder of the system the type/format of the request and eProcurement system issuing the request. This is then used by the system to determine the general subsequent manner in which the request should be handled and the syntax etc. of the request, all of which are dependent upon the eProcurement system issuing the request.

Alternatively the request is in the form of an XML (extensible Markup Language) document that is sent to the supplier computer system URL. In this case the identify request sub-module 12 calls up and uses a suitable XML parser to parse the XML document and extract the individual tags in the XML document. A suitable XML parser is Sun JAXP

from Sun Microsystems, although other suitable XML parsing software could be used. The identify request sub-module 12 then analyses the identified tags and compares these with previously stored details of known formats and tags which are be sent by different vendor eProcurement systems. In some cases an individual tag in the request from a vendor eProcurement system may identify the vendor/type of system.

In other cases the combination of tags sent in the request has to be used to determine the type/vendor of the eProcurement system. In this way the type/vendor of eProcurement system (eg Ariba, Oracle) issuing the request is identified and an identifier (relating to the eProcurement system/vendor of the system sending the request ; eg Ariba system, Oracle system) is assigned to identify the type/format of request. This identifier is associated with the request and used to flag to the remainder of the system the type/format of the request and eProcurement system issuing the request. This is then used by the system to determine the general subsequent manner in which the request should be handled and the syntax etc. of the request, all of which are dependent upon the eProcurement system issuing the request.

Once the request has been identified, a'Look up settings'routine 14 further analyses the request and its contents in more detail according to the form of request identified. The request from any eProcurement system 2a, 2b, 2c contains a variety of information details (indicated by the parameter, or in the individual tags from the parsed XML document) specific to the particular vendor customer procurement systems 2a, 2b, 2c (i. e. Ariba systems, Oracle system etc. ) and specific ! customer. All requests from any customer procurement system 2a, 2b, 2c (albeit in different formats and/or syntax configurations) however include the following key information indications: 1) Procurement system Vendor type (VENDOR)

- details indicating the particular type of vendor procurement systems (ie, Ariba ORMS systems, Oracle system, SAP system) ; 2) Customer Identification (CUSTOMER) - details indicating the customer organisation ; 3) Return Location (LOCATION) - details indicting the Internet location (URL address) of the customer computer/customer procurement system for return communications from the supplier computer system.

The'Look up settings'routine 14 extracts these key information indications from the request in accordance with predetermined subroutines stored in the interface module 8 for handling the different forms of requests, with the particular subroutine being selected automatically from the previous identification of the type (ie. vendor system) of the request.

A database stored on/accessible by the supplier computer system 6 contains predefined specific details settings relating to the different vendor procurement systems (i. e Ariba systems, Oracle system, SAP system etc.), the different registered customer organisations, and other parameters required by the particular customer or customer procurement system 2a, 2b, 2c. Using the key information details extracted from the request the relevant specific detailed settings are retrieved from the database for use in the subsequent steps and operation.

The retrieved settings are first used to determine whether, and how, the request needs to be authenticated.

Some vendor procurement systems (for example the Oracle SSP procurement system) require punch-out requests to be authenticated against an external computer server. If

external authentication is required then an authentication process 16 is carried out in accordance with the settings for the particular request. The exact authentication routine required is determined by the particular vendor procurement system from which the request originates. The particular settings retrieved from the database determine and set the routine that is carried out. In general though the authentication 16 process connects the supplier computer system 6 back, via the Internet 4, to a URL of a remote authentication computer with a ticket ID that was received in the original request and retrieves a further XML document from the remote authentication computer and URL. The authentication XML document contains a message which indicates whether the current session (and connection from the customer procurement system to the supplier computer system) is unauthorised and should not be allowed, or a valid response and further additional customer details relating to the particular customer and user. If no separate authentication is required, or is specified by the settings, then the authentication routine is bypassed as indicated by arrow 15.

Once a request has been identified, accepted and authenticated (if required) a'Save Request Details'routine 18 saves the details of the request settings retrieved (along with additional settings and details possibly obtained from the authentication routine 16) in a further database on the supplier computer system 6. A session ID reference is also generated and saved along with the settings details in the database.

The final part of the inbound punch-out connection request processing is to establish a connection to the actual supplier website 10. A'Connect to web site'routine 20 handles this and creates a blank HTML page containing no visible details but including an auto-submit Javascript code. This HTML page is returned to the customer procurement

system 2a, 2b, 2b, and to the customer user's browser, using the return URL details and settings previously determined from the initial connection request processing. The autosubmit Javascript in the returned HTML page is configured to automatically connect to and open a session on, the supplier main web site 10 with the session ID previously generated and stored. By connecting the to the web site 10 in this way, through the return of a blank HTML page, rather than directly connecting through the interface module 8 means that further exchanges between the customer web browser and the supplier web site 10 do not have to involve the interface module 8 as indicated by arrow 32.

To enable connection to, and open the session on, the supplier website 10 a unique user name is also required for each individual user from the different customer company using the system. This unique user ID is generated within the interface module 8, and specifically in the connect to web site routine 20, by converting the user name received in the initial request and prefixing it with the customer and vendor name details retrieved.

The session that is created on the supplier web site 10 has a flag set against it which indicates that the session is a punch-out session as opposed to a conventional session.

The customer user is automatically logged to the home page of the website 10 using the unique userid that was previously generated by the interface module 8 with the user by-passing the logon routines of the supplier website 10.

The supplier website 10 is of a typical a generally conventional format, arrangement, and functionality for Internet procurement of goods. The website 10 provides, through linked web pages standard functionality to search through an electronic catalogue of the supplier products and select products to order with the details of any selected products added to and stored on a session shopping cart.

The customer user accessing the website 10 in a punch-

out manner from the customer procurement systems 2a, 2b, 2c can use the full functionality of the suppliers web site 10 in the same way as any normal web site session. However for a user session flagged as a punch-out session the web site 10 functionality, and specifically the order processing functionality of the website 10 is slightly modified so that the order process is not allowed to proceed through to the actual order submission functionality generally provided and used on a website 10 and the provision of delivery and payment information. Instead once products to be ordered have been selected and added to the shopping cart and the user confirms that an order for these products is to be placed, the shopping cart and details of the products are returned to the interface module 8 for subsequent processing and return to the customer procurement system 2a, 2b, 2c.

Since the shopping cart is generated by the supplier's web site 10 it is always returned it the interface module in the same supplier defined format. A'Receive shopping cart' routine 22 of the interface module 8 can therefore easily process the returned shopping cart details and extracts the relevant details of the order and products selected. The particular details may include supplier product reference number, product description, quantity, unit price, VAT percentage, total value, currency, and importantly the session ID. These details are then stored within a internal data structure of the Java Servlet comprising the interface module 8.

A'Look up details'routine 24 next uses the extracted session ID to retrieve the previously stored settings stored during the processing of inbound punch-out connection request against that session ID These settings enable the interface module 8 to identify the format and requirements of the customer procurement system 2a, 2b, 2c for a return message as well as specific customer user details. The settings retrieved may also trigger further functionality

within the interface module 8 to add additional details to the shopping cart information specific to a particular customer. For example warning indicators against products listed as barred products for a particular customer may be added.

The combined details are then stored 26 for records and archive analysis purposes.

In order to process and handle an order the various different vendor procurement systems 2a, 2b, 2c all require different formats etc. for the return order request message.

Particular customers may also require specific tailored formats to process the order correctly. In general though the return message comprises an XML document with a header, detail and footer sections. The header section contains details about who is sending the message and who is to receive the message along with additional control information from the original punch-out request. The detail section is a set of repeating fields related to each line in the shopping cart. The footer section usually simply closes the XML document with the correct tags. The detailed format and configuration varies for the different vendor procurement systems.

A'Format message'routine 28 comprises a number of separate sub-programs for each vendor procurement system 2a, 2b, 2c to create the correct message format for order details contained in the stored shopping cart. The particular sub-program used, and so return order format for the XML document, is automatically determined from the setting details previously identified during the inbound processing of the initial punch-out connection request. The sub program also adds further details, as required, from the initial request. In particular the return URL location details extracted and stored from the inbound request are added and used in the sub-program in formatting and generating the response.

Finally a'Send response'routine 30 of the interface module 8 sends the correctly formatted return order message request with the shopping cart details of the products selected and to be ordered to the customer procurement system 2a, 2b, 2c.

There are two main ways in which this can be done, depending upon the preferences of the vendor procurement system 2a, 2b, 2c used by a customer. The'Send response routine'30 supports both such methods with the appropriate method being automatically selected dependent upon the settings identified and stored during the inbound processing of the original connection request.

The first method (used by Ariba and Infobank procurement systems for example) is the server to server method of transferring data. In this method a HTTP connection is made to the specified return URL of customers computer system and customer procurement system 2a, 2b, 2c. The send response routine 30 uses the details of the return URL (LOCATION) extracted and determined during the processing of the inbound punch-out connection request.

The second method is the server-browser-server method of transferring data. In this method the send response routine generates a HTML form that contains the XML document data as a hidden form variable. The'action'of the form (i. e. the URL it sends the data to) is set to the customers return URL previously determined from the in bound punch-out request. The form is returned to the customer users browser where it is set to automatically submit the form upon receipt in the browser and thence send the XML details from the customer user'terminal to the customer server and customer procurement system a, 2b, 2c. This method is preferred since the customer does not have to grant the supplier, and supplier computer system 6, access to the customer computer server.

The returned details, from the interface module 8,

which are in the correct format for the customer procurement system 2a, 2b, 2c can then be processed by the customer procurement system and the formal order for the goods submitted by the customer procurement system to the supplier.

The same single supplier website 10 can also be accessed 32 directly by other users 3 with a standard web browser in a conventional manner and without using the interface module 8. In such a case though the individual user has to use the logon facilities of the web site 10, which are not automatically completed as is the case when using the interface module to access the web site 10 in punch-out mode. The session for such a direct access user would also not, of course, be flagged as a punch-out session and so the order processing functionality of the website 10 would be enabled in the usual way to process and submit the order directly to the supplier from te web site. In such a case the shopping cart is not returned, but is processed further on the website 10 and supplier computer systems 6 in the conventional manner.

The interface module 8, as described above, provides a means to allow ready access and interfacing between a customer procurement system 2a, 2b, 2c and a substantially conventional supplier procurement web site 10. The arrangement and interface module 8 in effect converts the varied and different formats and standards of customer procurement systems 2a, 2b, 2c into a generic standardised supplier format. The interface module 8 extracting the various required key information. The generic standardised format is then used to open a session and allow access to the supplier's substantially standard procurement website 10. The details of selected items to order are returned to the interface module in a standard format and then converted to the customer procurement systems 2a, 2b, 2c format and protocols based upon the details previously extracted and

indicated from the initial connection request and/or previously stored and identified from the details in the connection request. This allows customer users using their own procurement systems 2a, 2b, 2c to access the wealth of information and functionality provided on a supplier's web site 10 and to better integrate with the supplier.

By integrating the supplier and customer such that the customers using different procurement systems 2a, 2b, 2c in this way such that they all use and access the same standardised web site 10 there is also no need for the customer to ensure and maintain the supplier catalogue details. This will be carried out by the supplier updating their own web site 10. Furthermore for a supplier only a single website 10 and electronic catalogue needs to be provided in the form of the web site 10 which is accessed by many different customer procurement systems 2a, 2b, 2c regardless of particular system used. The operational integration of the supplier web site 10 with the customer procurement systems 2a, 2b, 2c also combines the advantages of both systems. Namely the wide range of detailed product information available and maintained by the supplier on their website 10 (as well as any additional functionality and features offered), with the controls (ie. approval, budgeting etc) and arrangement functions of the customer procurement systems 2a, 2b, 2c.

By using a separate interface module 8 and generic format to allow access to and return order details from the website 10 the arrangement can be readily used with a wide range of procurement systems 2a, 2b, 2c supplied by different vendors without requiring substantial detailed modifications to the supplier's website 10 f-6r each vendor procurement system 2a, 2b, 2c. It is also more straightforward to modify the interface module 8, which in some respects is standalone, to respond to operate with different vendor procurement systems 2a, 2b, 2c and requirements, than having

to change the web site 10 as a whole as is conventionally the case with prior arrangements to allow punch-out operation. In particular with this arrangement a supplier can readily and easily become punch-out enabled for many different vendor procurement systems 2a, 2b, 2c, using a standard single system and web site 10. As such the supplier is not tied to a particular vendor procurement system or forced to provided multiple separate systems, with their added costs, for punch-out use with different vendor procurement systems 2a, 2b, 2c.

Figures 2 to 4 illustrate, by way of example and, in schematic form the information flows arising between supplier web site/the Java Servlet interface module 8 and different vendor procurement systems 2a, 2b, 2c. In each case the interface module 8 and supplier website 10 is the same with the different operation being generated by the particular settings for the different vendor systems 2a, 2b, 2c.

Figure 2 refers to the operation with an Ariba ORMS customer procurement system 2a. As indicated by arrows ARI-1 & ARI-2 a customer user logs onto their local Ariba ORMS system 100 using a local PC terminal la, via a web browser (the entire user interaction being handled through the web browser). The local Aria ORMS system 100 connects the user to an Ariba network 102, on a remote Ariba maintained hosted server, via the Internet 4, and through the customer organisations security firewall, as indicated by arrow AR-3. The user specifies from the Ariba Network system 102 the particular supplier listed in the Ariba Network system 102 to which a punch-out order request is to be made. The Ariba Network system 102 sends an XMLHTTP message to the supplier computer system 6 and interface module Java Servlet 8, again via the Internet 4. The connection request message includes an authentication request, ie a request that the particular user be allowed to punch-out to the supplier website 10, and

the user/customer details of the request are checked to determine if the user/customer is authorised. Session details and the request details are then set up in the database 9 on the supplier computer system 6. The supplier interface module Java Servlet 8 sends a response XML message ARI-5 to the Ariba Network 102 indicating that the user is authorised and including a URL of the supplier website 10 to allow the user to connect to the supplier web site 10. The Ariba Network 102 passes ARI-6 the XML message received back to the local customer Ariba ORMS system 100. The local Ariba ORMS system 100 sends a request ARI-7 to the users browser to request the document at the URL of the supplier website 10 supplied by the interface module Java Servlet 8 in ARI-5. This URL automatically logs the user into the supplier website 10 via the session 11 previously generated from the supplier database details in response to the initial request to the interface module Java Servlet 8. The session includes the user ID details and flag settings indicating punch-out mode operation which are used to control the functionality and operation of the supplier website 10. The user interacts with the supplier web site 10 to search and select product items collecting and adding details of the selected items to a session shopping cart stored against the session and user. Once the user is satisfied with the order and indicates through the website 10 (the order functionality of which has been modified by the punch-out session flag) the shopping cart details are returned ARI-9 & AR-10 to the interface module Java Servlet 8 via the user browser. The interface module Java Servlet 8 then reformats the shopping cart details, adding additional in accordance with the settings and details previously extracted and store on the database 9, and returns ARI-11 a form with the relevant details in the required format to the local Ariba ORMS system 100 using the URL of the Ariba ORMS system 100 previously determined from the initial request submitted and/or details in the

database 9. The local customer Ariba ORMS system 100 then process the returned order details in the usual manner to further process and submit the order to the supplier.

Figure 3 refers to the operation with an Oracle SSP customer procurement system 2b. The customer user logs on ORA-1 to the customer local Oracle SSP system 200 via a web browser from a local PC terminal Ib. The customer user selects from the Oracle SSP system to punch-out to a particular listed supplier in order to place an order. The Oracle SSP system 200 causes the users web browser to forward an HTTP request ORA-2 to the supplier's computer system 6 and interface module Java Servlet 8. This HTTP request contains parameters that the interface module Java Servlet 9 interprets as a authentication requirement, with user identification details. The interface module Java Servlet 8 connects ORA-3 to a remote Oracle Authentication Server 202 with the user identification details received in the authentication request ORA-2. The Oracle Server responds ORA-4 with an denial response which terminates the operation, or a confirmation that the user identified is authorised and provides additional details. The interface module Java Servlet 8 then sends a response ORA-5 to the users's web browser forwarding ORA-6 the browser to the supplier's web site URL ans session 11 previously opened from the session details in the database 9. The session details include the relevant logon details and set the punch-out flag for punch-out operation of the session on the supplier web site 10. The user then interacts with the web site 10 directly via the web browser. When the relevant products have been selected and added to the shopping cart and the user confirms that the order is to proceed the shopping cart details are submitted back ORA-7 & ORA-8 to the interface module Java Servlet 8 via the users web browser. The interface Java Servlet 8 then creates a form containing the shopping cart details in the correct format

with the relevant additional details and settings previously determined from the initial request and/or stored in the database 9. This form is then returned ORA-9 to the users web browser where it is automatically forwarded ORA-10 to the Oracle SSP system 200 using the URL details previously determined from the initial request which were added by the interface module Java Servlet 8. The order is then processed by the local customer Oracle SSP system 200.

Figure 4 refers to the operation with an SAP Business Connector customer procurement system 2c. The customer user logs on SAP-1, SAP-2 to the customer's local SAP Business Connector system 300 via a web browser from a local PC terminal lc. The customer user selects from the SAP Business Connector system 300 to punch-out to a particular listed supplier in order to place an order. The SAP Business Connector system 300 causes the users web browser to forward an HTTP request SAP-3 to the supplier's computer system 6 and interface module Java Servlet 8. This HTTP request SAP-3 contains parameters that are interpreted by the interface Java Servlet 8 as a request to access the supplier website 10, and identify the user. These details are checked by the interface module Java Servlet 8 against the records of users in the database 9 to authenticate the user. In this case authentication is carried out solely by the interface module Java Servlet 8 and supplier computer system 8. The interface module Java Servlet 8 confirms whether the details of the request are valid and forwards SAP-4 a request SAP-4 on to the user web browser to connect SAP-5 to the supplier web site 10 using a returned URL of the web site 10 and session 11 opened thereon form the details in the database 9 by the interface module 8 Java Servlet when the initial request SAP3 was submitted. This session automatically logs the user onto the website with a flag set indicating punch-out mode of operation and modifying the web site 10 functionality slightly. The user compiles an order by selecting products

and interacting with the web site 10 via their web browser. When the order is compiled, the relevant product details have been added to the shopping cart and the user confirms that the order is to proceed, the shopping basket details are sent SAP-6 & SAP-7 to the interface module Java Servlet 8 via the customer web browser. The interface module Java Servlet 8 processes the returned shopping basket details and generates an HTML form in the required SAP Business Connector format with additional details obtained and determined from the initial request SAP-3 and/or stored in the database 9. This form is then submitted SAP-8 back to the SAP Business Connector system 300 by the interface module 8 using the return URL details previously extracted from the initial request SAP-3, and/or determined from those stored on the database 9. The returned details are then processed by the SAP Business Connector system 300.

In a similar manner the interface module 8 can be used to provide an interface and interconnection between procurement systems 2a, 2b, 2c which are arranged for punchout operation but are supplied by further other vendors. The interface module 8 operates in essentially the same, similar, manner as described above by extracting the relevant details from the punch-out connection request from the procurement system, using such extracted details to open a session on a supplier's substantially conventional web site, automatically entering logging the user onto the web site using extracted user details/stored details reference from the extracted details, receiving selected product order details from the website, converting the received order details to the correct format based upon the previously extracted details and adding additional details form the previously extracted details from the initial request (and also other stored details referenced from the initial request), returning the order details to the procurement system for further onward order processing.

The preferred arrangement as described above is for the interface module 8 to be located on the supplier's computer systems 6 and/or network. Whilst the interface module 8 could be located on the same actual supplier server as the web site 10 itself, it is preferred that the interface module whilst located on the same supplier computer network is actually located on a different server. In alternative embodiments of the broadest aspects of the invention, however, the interface module 8 could for example be provided on a third party computer system. The third party thereby providing a gateway or portal service connection allowing different procurement systems 2a, 2b, 2c, provided by different vendors to connect to suppliers generally conventional websites 10. Indeed the interface module 8 could also be incorporated on the customer's computer systems and/or with the procurement systems 2a, 2b, 2c themselves.

Whilst the above descriptions and embodiment of the interface module 8 relate to connecting different procurement system 2a, 2b, 2b to a single specific web site 10, the interface module 8 can be used and added to a number of different web supplier sites. Indeed the same interface module 8 could be used to connect to a range of multiple supplier web sites 10. It being appreciated, as discussed above, that only minor modifications need to be made to the web site 10 with the interface module handling the main interconnections between the formats etc of the eProcurement systems 2a, 2b, 2c used.

Other modifications, and alternative embodiments, embodying the above described principles of the invention will also be apparent to those skilled in the art. Furthermore the detailed computer programming to provide the described functionality will be apparent to those skilled in the art in order to implement the invention from the required functionality described. As with all computer

programming, there are also multiple ways of providing the exact coding to provide the described functionality.

Claims

CLAIMS 1. An electronic procurement system comprising: a) a supplier computer system comprising a product ordering and information module including an electronic catalogue of product details offered for sale and means to search, browse and select products from said catalogue, b) a customer procurement system on a customer computer system for handling and managing the procurement of products, the customer procurement system configured to issue a connection request for the customer computer system to access the product ordering and information module and electronic catalogue on the supplier computer ; and c) an interface module for establishing access between the customer computer system and supplier computer system in response to said connection request from the customer procurement system ; wherein the interface module comprises:

i) a means to identify the connection request from the customer procurement system and determine the type of customer procurement system and format of the connection request ; ii) a settings determination means to, using details of the type of customer procurement system and format of the connection request, extract key details from the request and compile specific connection setting details in a supplier format ; and iii) a means to open and configure an access connection between the customer computer

<Desc/Clms Page number 31>

systems and the supplier computer based upon the connection settings details, allowing a customer user to access and interact with the electronic catalogue of supplier product details and select products to purchase.
2. An electronic procurement system as claimed in claim 1 in which the supplier computer system comprises a means to return details of selected products to be ordered to the interface module, and the interface module further comprising : i) a means to generate a return product order request including the return details of the selected products, the means to generate the return request being selectively configured by the setting details compiled from the processing of the access request to generate a return product order request in the required format for the customer procurement system; and ii) a means to return the return product order request to the customer procurement system.

3 An electronic procurement system as claimed in claim 1 or 2 in which the supplier computer system further comprises a database of settings details relating to a customer and customer procurement system, and the setting determination means using said extracted key details to identify the stored settings details and compile the specific connection settings details using said stored settings details.

4 An electronic procurement system as claimed in any preceding claim in which the interface module further comprises an authentication module which is selectively

<Desc/Clms Page number 32>

operable in response to the specific connection setting details complied.

5 An electronic procurement system as claimed in any preceding claim in which the interface module comprises a Java Servlet.

6 An electronic procurement system as claimed in any preceding claim in which the interface module comprises part of supplier computer system.

7 An electronic procurement system as claimed in any preceding claim in which the product ordering and information module comprises a series of interlinked web pages.

8 An electronic procurement system as claimed in any preceding claim in which the communications between the customer and supplier computer systems is via the Internet.

9 A method of operationally interconnecting a customer procurement systems with a supplier computer systems comprising an electronic catalogue of product offered for sale by the supplier, comprising i) identifying a connection request from the customer procurement system and determining the type of customer procurement system from the connection request ; i) extracting key details from the connection request,/ ii) compiling specific connection setting details in a common supplier format using said extracted key details ; and iii) opening and establishing a connection between

<Desc/Clms Page number 33>

the supplier computer system and customer computer system using said specific connection setting details.

11 A method as claimed in claim 10 further comprising: v) a means for a customer to select products form the electronic catalogue on said supplier computer system ; vi) generating a supplier format product order request in a supplier format for customer selected products ; vii) generating a customer format product order request, in the customer procurement system format, based upon the supplier format product order request and the setting details compiled from the access request; viii) returning the customer format product order request to the customer procurement system.

12 A system for use in electronic procurement for operatively interconnecting a customer eProcurement management systems and a supplier's electronic web site, the system comprising an interface means which provides means to identify a request to connect to the web site received from the customer eProcurement system, means to determine key settings details, and a means to open and configure a session on the supplier web site using the determined settings and connect a customer user on a remote customer computer system web site.

13 A system as claimed in claim 12 in which the interface means further includes means to receive a details from the supplier web site of details of products to be

<Desc/Clms Page number 34>

ordered, a means to generate a return product order request, and a means to return the return product order request to the customer procurement system ; the means to generate the return product order request being selectively configured, by and using the determined settings details, to generate a return product order request in a required format for the customer procurement system.

14 An electronic procurement system as hereinbefore described with reference to figures 1 to 4.

15 A method as hereinbefore described with reference to figures 1 to 4.