WO2003027914A1

WO2003027914A1 - System for facilitating the supply of goods

Info

Publication number: WO2003027914A1
Application number: PCT/AU2002/001333
Authority: WO
Inventors: Neil Spragg; Neil Glen Eddy; Paul William Damian Keogh
Original assignee: Sands Solutions Group Pty Ltd
Priority date: 2001-09-27
Filing date: 2002-09-27
Publication date: 2003-04-03
Also published as: AUPR794701A0

Abstract

A system for receiving and processing orders for products, the system including means for receiving or obtaining an electronic request for supply of products from an external source and processing means for processing the electronic request for supply of products whereby the processing means is operable to determine the format of the electronic request, to construct an object containing data represented in the electronic request and to process the data to fulfil the request. The system is further operable to produce a formatted document from the constructed object's data for forwarding to an external party. The formatted document may be forwarded to the external source in response to the request.

Description

"SYSTEM FOR FACILITATING THE SUPPLY OF GOODS"

Field of the Invention

The present invention relates to a system for supplying goods and/or services to customers, particularly using computers and the Internet.

Throughout the specification, unless the context requires otherwise, the word "comprise" or variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.

Background Art

Figure 1 illustrates the type of transactions that typically occur on both the 'buy side', i.e. the customer procurement transaction, 2 and the 'supply side', i.e. the supplier transaction, 3 of the procurement/supply process, shown by reference number 1.

The procurement/supply process 1 generally commences at step 4 in which a customer identifies a suitable supplier source for the product/s, or good/s, the customer is seeking to procure. In the next step 5, a request is raised for the product/s to be procured and this is followed by step 6 in which the request is approved. Following approval of the request, the next step 7 is to send the product order to the supplier. These steps 4 to 7, shown in Figure 1 as forming the initial steps in the procurement/supply process 1 , occur on the buy side 2. The next steps occur on the supply side 3.

The supplier receives the product order from the customer at step 8. The sales order is then entered into the supplier's system, indicated by step 9, and a picking slip is then generated which forms step 10 in the process. The next step 11 is for the supplier to fill the sales order. Once this has been done, the supplier despatches the product s to the customer, shown as step 12. The supplier also sends an invoice for the products to the customer as shown at step 13. These steps 8 to 13 that occur on the supply side 3 of the procurement/supply process 1 complete the order fulfilment required on the part of the supplier. The next steps then occur on the buy side 2 of the procurement/supply process 1.

The customer receives and checks the product/s, despatched to it by the supplier, shown as step 14. Once the product/s have been received and checked, the next step is to match the product/s received with the product/s ordered, shown as step 15. The invoice sent by the supplier to the customer at step 13 is received by the customer at step 16. Following receipt of the invoice, the customer matches the invoice to the product/s received, shown as step 17. Following this, the invoice received from the supplier is entered into the accounts payable of the customer, which forms step 18. The customer then makes a payment to the supplier, at step 19, as payment of the invoice received for the product/s. That payment is then received by the supplier at step 20 who also makes a record of receipt of the payment from the customer to thereby conclude the procurement/supply process 1.

There are a number of steps in this procurement/supply process 1 that are costly, time consuming and sometimes unnecessary.

A major factor limiting the use and spread of e-business is the participation level of suppliers of all sizes across all industries. Buyers are deterred by the lack of available suppliers they can buy from and conversely, suppliers are deterred by the lack of buyers they can sell to. The issue of supplier participation in e- business is often referred to as supplier enablement.

Today, it is more likely that a supplier's larger, more sophisticated customers will use e-commerce for some or all of their purchases. Research would indicate that, for most suppliers, they might only be able to trade in a completely electronic manner with approximately 5% of their customers.

Many customers continue to deal with their suppliers in the same way they have for many years, as many customers don't have access to e-procurement systems and/or the Internet. These customers continue to place orders using the telephone and order forms via facsimile or e-mail.

These methods of accepting customers' orders, while all-important, are expensive as they are labour intensive and are prone to errors.

Increasingly, suppliers are being asked by their larger customers, in both the Public and Private sectors to trade with them electronically.

Unfortunately for the suppliers, there are many different types of e-procurement and e-marketplaces being used by these customers, with different cataloguing, order and other trading document standards.

The primary objective of many of these customer driven e-business initiatives is to lower the customers total buying costs. They often have little empathy for the e- business capabilities of their suppliers and totally underestimate the importance of supplier enablement to the success of their own e-business initiatives.

Disclosure of the Invention

According to one aspect of the present invention, there is provided a system for receiving and processing orders for products, the system including:

means for receiving or obtaining an electronic request for supply of products from an external source; and

processing means for processing the electronic request for supply of products

whereby the processing means is operable to determine the format of the electronic request, to construct an object containing data represented in the electronic request and to process the data to fulfil the request.

Preferably, the means for receiving or obtaining an electronic request is adapted to receive requests in e-mail and/or short messaging system format. Additionally or alternatively, the means for receiving or obtaining an electronic request is adapted to obtain an electronic request from a predetermined location, the predetermined location being at least one of the following: a website; a drop directory; an FTP site; or a GE mailbox.

Preferably, the processing means is further operable to produce a formatted document from the constructed object's data for forwarding to an external party.

More preferably, the formatted document may be forwarded to the external source in response to the request.

More preferably, the external source is an accounting system or enterprise resource planning program.

Preferably, the means for receiving or obtaining an electronic request executes instructions contained in at least one script to receive or obtain the electronic request.

Preferably, the determination of the document's format, the construction of the object or the production of the formatted document is achieved by executing instructions contained in at least one script.

More preferably, the scripts are stored in a script library.

Preferably, the electronic request is created with reference to an product information collated into an electronic catalogue.

Preferably, the product information includes at least one of the following: product code; pricing information; lead time to supply; stock availability; current stock level.

Preferably, product information can be searched according to the UNSPSC or E- CLASS standard. Preferably, the electronic catalogue includes only such product information as is relevant to the customer.

In accordance with another aspect of the present invention, there is provided a method for transmitting electronic requests for supply of products from a customer to a supplier, including the steps of:

receiving an electronic request from a customer;

determining the format of the electronic request;

removing data from the electronic request;

processing said data to determine the products, if any, to be supplied; and

supplying the determined products.

Preferably, the steps of removing data from the electronic request; processing said data to determine the products, if any, to be supplied; and supplying the determined products are performed only if a set of business rules associated with the customer who sent the electronic request record that the format of the electronic request is of a format that requires actioning.

Preferably, the step of determining the format of the electronic request includes the sub-steps of:

opening a file associated with the electronic request;

reading information contained from a predetermined component of the file; and

determining the document format based on the information read from the predetermined component of the file.

Preferably, the method further includes the steps of: generating further documentation in response to the electronic request in a format agreed to by the customer and the supplier; and

forwarding the further documentation electronically to the customer.

More preferably, the further documentation is a shipping notice, invoice or acknowledgment of the electronic request.

Preferably, the method further includes the step of forwarding the data to another system in a format required by the other system.

More preferably, the other system is an accounting system or system running an enterprise resource planning program.

Brief Description of the Drawings

The invention will now be described, by way of example only, with reference to the following Figures, of which:

Figure 1 is a schematic illustration of the purchase and supply process of the prior art;

Figure 2 is a schematic illustration of an embodiment of the system of the present invention illustrating its connections to customers;

Figure 3 is a further schematic illustration of an embodiment of the system of the present invention;

Figure 4 is a schematic illustration of an embodiment of the method of parsing a document as carried out by the Document Mapping and Translation Engine of the system of the invention;

Figures 5A and 5B are schematic illustrations of an embodiment of the polling process carried out by the Document Mapping and Translation Engine of the system of the invention; Best Mode(s) for Carrying Out the Invention

With reference to Figure 2, the supplier system 21 of the present invention is provided by a computer system 22 comprising a server 23 and an associated database 24. The server 23 and database 24 can be any suitable type. The supplier server 23 will be arranged to receive data from external sources, as will be discussed in more detail below.

A supplier of goods operates the supplier system 21 , and customers of the supplier will be able to connect to the server 23, using systems 25, such as personal computers, or other servers, for example, via the Internet or other suitable data transfer means. The use of the Internet, and other data transfer communications, such as point-to-point communication, are well known to persons skilled in the art, and in so far as they are not relevant to the present invention, need not be described in any further detail herein.

In the embodiment described herein, the system is used with regard to the supply of products. However, it will be readily understood that this could also apply to services, and, as such, the terms "goods" and "products" should be construed to include the term "services" as well.

The supplier server 23 operates to receive, process and transmit data from and to customers as will be described below. The functions carried out and further described, are, in the embodiment described herein, carried out on a single server. However, it will be easily understood that several servers could be used to provide the same functionality. The system 21 will also include a user interface including, for example, a mouse 26, keyboard 27, and visual display 28, which can be used by the user of the system 21 to input data, and to view data in appropriate formats.

Figure 3 provides a schematic representation of the present system as configured for use. As shown, customer system 100 is linked to the supplier server 105 (referred to by reference numeral 23 in Figure 2) which is in turn linked to an accounting system 110. The supplier server 105 includes a gateway 115. The gateway 115 includes a Database Mapping Transaction Engine ("DMTE") 120.

The customer system 100 can be a personal computer or may be a more sophisticated server arrangement. The customer system 100 may be linked to the supplier server 105 via the Internet or any other suitable communication means, such as a direct dial-up connection.

In alternative configurations the accounting system 110 may be replaced with an Enterprise Resource Planning ("ERP") system.

The gateway 115 is operable to receive, process and transmit data from and to the customer system 100. The gateway 115 maintains the link between the supplier server 105 and the accounting system or ERP system 110.

The DMTE 120 and other components of the supplier system 105 will now be described in detail in the context of the processing of an order placed by a customer 125.

Turning to Figure 4, the customer 125 creates an order 130 using the customer system 100. The format of the order 130 must correspond with at least one format agreed on between the customer 125 and the administrator of the supplier system 105. The order 130 must also include certain mandatory information. '

The format or formats agreed on between the customer 125 and the administrator of the supplier system 105 is set by the customer 125 and, typically, coincides with the format or formats of an order 130 generated by the customer system 100.

Upon generation of an order 130, the order 130 is either deposited at a prearranged location 51 or forwarded direct to the supplier system 105. In the former arrangement, the prearranged location 51 may be a website, a drop directory, an FTP site or a GE mailbox (where the customer uses an EDI Van). In the latter arrangement, the means of forwarding the order 130 direct to the supplier system 105 may be by e-mail or SMS. The DMTE 120 then operates to locate the order 130 and extract relevant order details therefrom.

As shown in Figures 4 and 5A, the DMTE 120 commences, with step 122, where a script 135 is loaded from a script library 140. The script 135 is then executed, at step 124, by the DMTE 120. The DMTE 120 may execute multiple scripts 135 by organising the scripts 135 into a "daisy-chain" arrangement.

If the order 130 is deposited with a prearranged location 151 , some of the instructions that form the script 135 direct the DMTE 120 to the prearranged location 151.

The instructions that form the script 135 then operate to instruct the DMTE 120 to conduct a scan of the prearranged location 151 , or "in-box" 150 for forwarded orders, such as an e-mail in-box or an SMS in-box.

The scan of the prearranged location 151 or in-box 150 involves reading a predetermined component of the files stored therein. Typically, the predetermined component is the subject line of the file.

Based on the information contained in the predetermined component, and the address recorded in the file, the DMTE 120 determines the customer and document format of each file scanned. This information, along with the name of the file scanned, is then inserted into an Object Collection Array 155 at step 126. This process repeats until all files stored at the prearranged location 151 or in the in-box 150 have been scanned.

At step 128, the Object Collection Array 155 is forwarded to a calling function 132 for further processing.

The calling function 132 commences with step 134 and is shown schematically at Figure 5B. On the first iteration of step 134, the first record in the Object Collection Array 155 is processed. In subsequent iterations of step 134, the next record in the Object Collection Array 155 is processed. In this manner, all records in the Object Collection Array 155 are ultimately processed.

Step 134 determines whether the file 160 associated with the record being processed requires actioning. This is determined with reference to the business rules of the customer 125 identified for that file (see below). If the record being processed requires actioning, processing continues to step 136. Otherwise step 134 is again processed, this time with respect to the next record in the Object Collection Array 155.

Step 136 sees the DMTE 120 load a transform script 145 from the script library 140. The transform script 145 loaded by the DMTE 120 is determined by the document format (as recorded in the Object Collection Array 155). The transform script 145 is executed at step 138.

Execution of the transform script 145 creates an object 165. Object 165 stores all the mandatory details about order 130 in a format suitable for processing by supplier system 105. Object 165 is itself stored in a local database.

When execution of the transform script 145 is completed, the file associated with the record processed is designated as processed by moving the document to the processed queue (as shown at step 142).

Processing then returns to step 132 where the next record in the Object Collection Array 155 is processed.

The DMTE 120 executes the procedures described above on a periodic basis. The period between executions is initially set by the supplier but can be modified to suit the needs of the customer 125.

Because of the plurality of accounting systems and ERP programs 110 that a supplier may used, the DMTE 120' is utilised to send the requisite details of the order 130 (ie. those stored by object 165) to the accounting system or ERP program 110. The DMTE 120', in this situation, reverses the functionality of scripts 135, 145 such that the order 130 is converted into a prearranged format for processing by the accounting system or ERP program 110. This may also involve depositing the order 130, in prearranged format, at a predetermined location.

A script editor (not shown) is provided to allow the supplier to edit scripts 135, 145. In this manner, the supplier can tailor scripts to suit individual customers 125.

As mentioned above, the identity of the customer 125 must be determined so that the appropriate business rules can be used in determining what files are relevant.

Customer data is stored in the database 24. Customers 125 can be identified by searching the database 24 on the basis of a customer code or part or all of a customer's name. Furthermore, a list of customers can be displayed upon selection of a customer group.,

In addition to the customer's business rules, details kept in respect of each customer may include:

β Contact details. Namely, the customer's phone, fax and/or e-mail details and the person to contact in respect of an order or orders;

• A list of allowed delivery addresses. This prevents delivery fraud by ensuring that the delivery of any product or service is to a registered address. One address can be flagged and used as the address for delivery of the product or service in the event that no delivery information is provided;

• Credit limits. A series of credit limits may be maintained for some customers 125 so that they do not have to transfer such information over the Internet or other communications means. Further, customers 125 who are given a credit limit with the supplier can have the system check that this facility is not exceeded when an order 130 is placed; • Order limits. The supplier can define order limits that apply to a customer 125 on a per-order or per-period basis.

• How the customer's electronic commerce messages should be translated and communicated (i.e. which scripts 135, 145 to obtain from the script library 140); and

• Pricing information.

A customer's business rules can also be stored in database 24. The business rules describe the expected or allowed behaviour for the customer 125 in their electronic commerce environment. For example, if the price on a customer's sales order is wrong, the supplier system 105 could flag it for manual review with an alert, or re-price it if it is within a given tolerance range. Another example is indicating which workflows a customer 125 allows for delivery and invoicing (see below).

Customer details can be obtained automatically or manually entered into database 24. Modification of customer details is also possible, but dependent on the supplier's particular implementation.

Customers 125 may also be grouped together where members of the group share business rules or pricing information. Customers 125 may also be members of more than one group. Grouping together customers 125 assists in the management of the translation and communication procedures.

If a customer 125 is to be removed from the supplier system 105, a two-step process is executed. Initially, the customer 125 is marked as inactive in the database 24. This allows the customer 125 to be shut down while still enabling reporting against the customer 125 and recognition of late electronic documents from the customer 125. Once the time allocated for reporting or recognition of late documents has expired, the customer 125 is then marked as inactive in the database 42. Once an order 130 has been received from a customer 125, and processed according to the procedure set out above, if the customer's business rules indicate that an acknowledgement of the order 130 should be sent, such an acknowledgement is sent. As examples, the acknowledgement may take the form of an SMS message or an e-mail. At this time, checks may also be performed to ensure that the order 130 designates an allowed delivery address for the product(s) or service(s).

The customer's business rules may also require some other form of electronic documentation to be produced, such as an invoice or an advanced shipping notice ("ASN").

If the customer's business rules require an electronic invoice to be issued, the prices of each product or service must be calculated.

Each product and service offered by the supplier has a default price recorded against it. This is the standard price that a customer 125 will be charged if no other price can be determined.

As mentioned above, customers 125 may have pricing information recorded against them. This is referred to as a "contract".

Each contract has a commencement date and an expiry date. The prices set within the contract for each product or service mentioned thereon only apply during the life of the contract (ie. the period between the commencement date and the expiry date). Contracts may be allocated to any number of customers 125 or to groups of customers 125, such as those that share the same business rules.

Each line of the contract will refer to either a specific product or service or a group of products or services. The line will indicate the minimum quantity, if any, that the customer 125 must purchase to be eligible for the contract price. This allows different volume breaks to be specified. The price of the product(s) or service(s) specified by the line can be recorded as a fixed dollar amount, percentage discount below retail or a percentage mark-up above cost. This may also require details of item costs to be maintained in database 24 (using either a last, true or average cost model).

This information can then be used to calculate whether the order total will exceed the credit limit values, if any, set against the customer 125.

Once the pricing information for the invoice has been determined, an appropriate electronic invoice can be generated by the suppler server 105. Processing of the invoice will be determined according to one of the following workflows:

Ship & Bill: The supplier sends out products that can be supplied while waiting for products that have to be manufactured or back-ordered. The remaining products are sent out as they become available. The customer 125 is invoiced for products as they are sent out.

Bill when complete: Products are dispatched as per the "Ship & Bill" workflow, but the customer 125 receives one invoice once the sales order has been completed.

Ship when complete: The products are dispatched only when the whole sales order can be supplied. The shipping document and invoice are both for the entire order.

Typically, the invoice will be sent utilising the DMTE 120 to reverse the function of scripts 135, 145 such that the invoice is converted into a prearranged format for processing by the customer system. This may also involve depositing the invoice, in prearranged format, at a predetermined location (which may or may not be the same location as that used for scanning orders).

Details of invoices are stored in the database 24. To find invoices, either a supplier or customer reference number can be used. Alternatively, the activity of a given customer 125 can be viewed for a given date range or it can be tracked based on all activity related to an order 130. The system will allow the invoice to be viewed on the screen, printed as an original or printed as a copy. However, once generated from completed shipping documents, invoices are finalised and cannot be modified. Invoices can be cancelled, in which case, the supplier system 105 either generates a credit note to be sent to the customer 125 or does not send out the invoice (if possible).

Where customers 125 need to make late changes to an order 130, or if the supplier (after consultation with the customer 125) needs to substitute products or services, the supplier system 105 provides functionality to modify orders 130. Orders 130 can be cancelled using a similar process.

If the supplier system 105 is not required to provide an electronic invoice, in accordance with the customer's business rules, the accounting system or ERP program 110 will then generate the requisite invoice.

The reason for this arrangement is that there is no two way communication facility between the accounting system or ERP program 110 and the supplier server 105. This prevents the accounting system or ERP program 110 from providing an electronic invoice to the supplier server 105 for forwarding to the customer 125.

To facilitate the order process, the supplier system 105 may, optionally, provide a catalogue of products and/or services provided by the supplier. In such a situation, the supplier system 105 provides catalogue content in the format required by the customer's procurement/marketplace systems. Example formats include the GIF 3 and BMECAT formats.

Details as to the products and/or services provided by the supplier are stored in the database 24, such as pricing information. Other information stored may include graphics of the product or service on offer. Each product/service stored in the database 24 has a unique identifier. Other product codes may be allocated to a product/service and also stored in the database 24.

When incorporated as part of the process of generating a catalogue, products and services stored in the database 24 are referred to as "catalogue entries". Catalogue entries can be manually created in the database 24 and this includes the ability to create non-standardised product and services. To assist in creating large volumes of similar items, a user of the supplier system 105 will be able to create a new item based on an existing item. This will default the initial data for the newly created item from the existing item, which the user can then adjust prior to committing the entry to the database 24.

Depending on the supplier's implementation of the supplier server 105, users may be able to modify catalogue items. Even if enabled, modification may be restricted to certain users depending on their job role.

Removing catalogue items from inclusion in future catalogues is a two-step process. Initially the catalogue item is marked as removed in database 24 meaning that it will not be included in any future catalogues. In this manner, the catalogue item can still be validated against any incoming sales orders from customers 125 that are not using up-to-date catalogues. The supplier system 100 can then either allow the purchase or send back notification to the customer 125 indicating that the stock is no longer available.

Alternatively or additionally, suppliers may wish to record a list of substitute replacement items for each catalogue item. This means if a customer orders an catalogue item that is out-of-stock, the supplier can potentially provide an alternative that is in stock. Doing so, however, would depend on the business rules associated with the customer 125 who ordered the out-of-stock catalogue item.

Once all reference to the catalogue item is no longer required, the catalogue item can then be flagged as deleted and is marked as inactive in the database 24.

Products/services stored in the database 24 can be searched according to the UNSPSC categorisation. This categorisation consists of an 8 digit number wherein:

It should be noted that the UNSPSC standard changes over time. Thus, it is possible that different customers 125 may wish to search for products/services based on different versions of the UNSPSC and the database should be flexible enough to allow searches to be performed based on differing versions of the UNSPSC.

In an alternative arrangement, products/services can be searched according to the E-CLASS standard.

Catalogue items can also be located in the catalogue by searching for either the primary item code, the item description (part of all) of any of the other product codes. In addition the customer 125 can select a product group and be presented with a list of all the catalogue items in that group.

From this information, a catalogue can be produced. The catalogue may be customised by allowing the supplier to indicate catalogue items that are to form part of promotions, such as 'product of the month'. In essence, the ability to utilise data will be limited by the functionality supported in the customer's electronic commerce environment.

To assist the customer 125 in making their purchasing decision the catalogue viewed by the customer 125 may show any of the following information on availability of the catalogue item of concern:

1. Stock availability (in a "YesTNo" format) 2. Approximate stock levels (which will be shown as a range, eg. 40-60)

3. Actual stock levels

4. Lead time to supply

5. Whether the catalogue item should include the description "a delay in delivering this item may occur..

Alternatively, no indication as to the availability of the catalogue item may be given.

The catalogue may be further customised by filtering catalogue items in accordance with the customer 125 to whom the catalogue will be provided. For instance, meat sellers may wish to provide details of only kosher products to Jewish customers. Furthermore, if a particular catalogue item cannot be ordered, it should either be excluded from the catalogue generated or flagged as not available through electronic ordering.

Catalogues for a retail only supplier will only need to contain the standard list process. In a similar manner, catalogues for specific suppliers (such as those used internally) will only need their actual price presented as a list price.

Catalogues produced for multiple client environments that require client specific pricing will need to pass the pricing content in a form that can be interpreted by the software used by the customers to view the catalogue.

It should be appreciated by the person skilled in the art that the present invention is not limited to the features described above and that alternatives within the capabilities of the skilled addressee are to be considered part of the invention. Furthermore, it should be noted that the supplier system 105 may incorporate functions associated with an accounting system or ERP program 110 other than those already described.

Claims

The Claims Defining the Invention are as Follows

1. A system for receiving and processing orders for products, the system including:

processing means for processing the electronic request for supply of products

2. A system for receiving and processing orders for products according to claim 1 where the means for receiving or obtaining an electronic request is adapted to receive requests in e-mail and/or short messaging system format.

3. A system for receiving and processing orders for products according to any of the preceding claims where the means for receiving or obtaining an electronic request is adapted to obtain an electronic request from a predetermined location, the predetermined location being at least one of the following: a website; a drop directory; an FTP site; or a GE mailbox.

4. A system for receiving and processing orders for products according to any one of the preceding claims where the processing means is further operable to produce a formatted document from the constructed object's data for forwarding to an external party.

5. A system for receiving and processing orders for products according to claim 4 where the formatted document may be forwarded to the external source in response to the request.

6. A system for receiving and processing orders for products according to either claim 4 or claim 5 where the external source is an accounting system or enterprise resource planning program.

7. A system for receiving and processing orders for products according to any of the preceding claims where the means for receiving or obtaining an electronic request executes instructions contained in at least one script to receive or obtain the electronic request.

8. A system for receiving and processing orders for products according to any of the preceding claims where the determination of the document's format, the construction of the object or the production of the formatted document is achieved by executing instructions contained in at least one script.

9. A system for receiving and processing orders for products according to either claim 7 or claim 8 where the scripts are stored in a script library.

10. A system for receiving and processing orders for products according to any of the preceding claims where the electronic request is created with reference to an product information collated into an electronic catalogue.

11. A system for receiving and processing orders for products according to claim 10 where the product information includes at least one of the following: product code; pricing information; lead time to supply; stock availability; current stock level.

12. A system for receiving and processing orders for products according to any one of claims 10 to 11 where product information can be searched according to the UNSPSC or E-CLASS standard.

13. A system for receiving and processing orders for products according to any one of claims 10 to 12 where the electronic catalogue includes only such product information as is relevant to the customer.

14. A method for transmitting electronic requests for supply of products from a customer to a supplier, including the steps of:

receiving an electronic request from a customer;

determining the format of the electronic request;

removing data from the electronic request;

processing said data to determine the products, if any, to be supplied; and

supplying the determined products.

15. A method for transmitting electronic requests for supply of products from a customer to a supplier according to claim 14 where the steps of removing data from the electronic request; processing said data to determine the products, if any, to be supplied; and supplying the determined products are performed only if a set of business rules associated with the customer who sent the electronic request record that the format of the electronic request is of a format that requires actioning.

16. A method for transmitting electronic requests for supply of products from a customer to a supplier according to claim 14 or claim 15, where the step of determining the format of the electronic request includes the sub-steps of:

opening a file associated with the electronic request;

reading information contained from a predetermined component of the file; and

17. A method for transmitting electronic requests for supply of products from a customer to a supplier according to any one of claims 14 to 16, further including the steps of:

generating further documentation in response to the electronic request in a format agreed to by the customer and the supplier; and

forwarding the further documentation electronically to the customer.

18. A method for transmitting electronic requests for supply of products from a customer to a supplier according to claim 15 where the further documentation is a shipping notice, invoice or acknowledgment of the electronic request.

19. A method for transmitting electronic requests for supply of products from a customer to a supplier according to any one of claims 14 to 18, further including the step of forwarding the data to another system in a format required by the other system.

20. A method for transmitting electronic requests for, supply of products from a customer to a supplier according to claim 19, where the other system is an accounting system or system running an enterprise resource planning program.

21. A system for receiving and processing orders for products substantially as described herein with reference to Figures 2 to 5B.

22. A method for transmitting electronic requests for supply of products from a customer to a supplier substantially as described herein with reference to Figures 2 to 5B.