AU2010200918A1 - Information processing system for supply and procurement management - Google Patents

Description

P/00/01Il Regulation 3.2 AUSTRALIA Patents Act 1990 COMPLETE SPECIFICATION STANDARD PATENT Invention Title: Information processing system for supply and procurement management The following statement is a full description of this invention, including the best method of performing it known to us: 2 Information processing system for supply and procurement management Field of the invention The invention relates to the field of information processing systems, in particular 5 information processing systems for procurement management, resource management, enterprise administration, and/or account processing. Background of the invention Trading in goods, particularly business-to-business or government-to-business trading, typically involves the completion of many processes by both the seller and the buyer. 10 Within the supplier and buyer, these processes may be completed by different people. Viewing a transaction from an accounts payable perspective, the processes and information flow may typically be that shown in Figure 1 of the accompanying drawings. The buyer issues a document called Purchase Order addressed to the supplier stipulating, among other things, the description of goods/services to be purchased, the 15 quantity of the goods, unit price, Purchase Order number, order terms & conditions and total value of the Purchase Order. The Purchase Order is then sent by fax, post or email to the supplier. For physical goods, the supplier will generally deliver the goods (with an accompanying Delivery Docket/packing list) to the place specified by the buyer, for example a warehouse of the 20 buyer. At about the same time the supplier's accounts receivable department will create and send a Tax Invoice to the buyer's accounts payable department, which may be centralised. The buyers warehouse will check the goods received against the Delivery Docket and perhaps also check the goods received against the Purchase Order.

3 The buyer's accounts payable department will then match the Tax Invoice to both the Delivery Docket and the Purchase Order, and then if all documents match, they will pay the suppliers Tax Invoice in due course. A number of circumstances can arise, which add complexity to the aforementioned 5 process. These circumstances may include: 1) The buyer issues an incorrect Purchase Order to Supplier, for example one specifying an incorrect unit price. 2) The supplier does not receive, or misplaces, the buyer's Purchase Order. 3) The supplier's dispatch department misreads the buyers Purchase Order. 10 4) The goods received by the buyer do not match supplier's Delivery Docket, for example due to an error in completing the Delivery Docket. 5) The goods received by the buyer don't match the Purchase Order, for example due to the supplier supplying the wrong goods. 6) The goods are missing. 15 7) The goods are damaged or defective. 8) The buyer's warehouse is slow to advise the supplier's dispatch department of any of the circumstances listed in 5), 6) or 7) above, or omits to advise the supplier of these events. 9) The buyer advises the supplier's dispatch department of the circumstances listed 20 in 4), 5), 6), or 7) above, but the supplier's dispatch department fails to advise the supplier's accounts receivable department. Consequently, the supplier's accounts receivable department may chase payment from the buyer for goods that are damaged, missing or are of the wrong type. The Tax Invoice may then also be incorrect (unit price and/or unit quantity and/or goods error).

4 10) The supplier does not notice incorrect price data in buyer's Purchase Order until late in the transaction process (if at all). 11) The supplier's Tax Invoices has errors (price/unit quantity/goods description), for example caused through human error. 5 12) Delays or accuracy problems arising from the need for the supplier to create and send to the buyer a credit note for items missing from the delivery, damaged goods, defective goods, or goods of the wrong type. 13) Suppliers commonly have standard terms and conditions for sales transactions detailed in pre-prepared forms such as tax invoices and sales quotes. Similarly buyers 10 commonly have their own standard terms and conditions for purchase transactions detailed in pre-prepared forms such as Purchase Orders. Consequently, suppliers and buyers often dispute which terms and conditions should apply to purchase transactions. The documentation associated with a transaction is typically also important to comply with legislative requirements, which may include for example, the requirement for the 15 buyer to obtain and store Tax Invoices for every purchase transaction. Similar complexities may also arise with the provision of services. Both the supplier and the buyer will have processes, information systems and procedures governing the handing of information relating to a transaction. These will typically be formed dependent on the nature of the business, size of the business and 20 the volume of transactions, as well as other factors. The information systems may range from an information system fully implementing enterprise resource planning, through to comparatively simple computer systems. Ideally, the processes, information systems and procedures are designed to effectively accommodate for the various complexities that may arise in a transaction.

5 Summary of the invention According to one aspect of the invention, there is provided an information processing system, the information processing system configured to: receive and store information defining a purchase order from a buyer, the 5 information including a specified supplier; make the purchase order available to the supplier; receive a request for variation of the purchase order from the supplier; make the request for variation available to the buyer and receive data indicating either acceptance or rejection of the request for variation; 10 if the request for variation of the purchase order is indicated as accepted, store the varied purchase order information. According to another aspect of the invention, there is provided an information processing system, the information processing system configured to: receive from a buyer and store information defining a purchase order; 15 make the information defining the purchase order available to a supplier; receive and store from the buyer information defining acceptance and rejection of items listed in the purchase order; make the information defining acceptance and rejection of the items listed in the purchase order available to the supplier. 20 In one embodiment, the system is further configured to send a purchase order notification to the supplier in the form of an email, wherein the email has associated with it the ability for the supplier to respond by accepting, rejecting or requesting changes to the purchase order. The supplier's responses may then be made available to the buyer, and/or stored in the database. 25 In one embodiment, the information processing system is further configured to generate a statement for the buyer, detailing the transaction or transactions in a purchase order. The statement may be adjusted automatically depending on the information defining acceptance and rejection of the items listed in the purchase order.

6 In one embodiment, the information processing system enables the generation of recipient created tax invoices. In this embodiment, an electronic notification to the supplier with a purchase order enables the supplier to communicate to the information processing system acceptance of an RCTI from the buyer. 5 In one embodiment, a plurality of purchase orders for a supplier or plurality of suppliers, are aggregated into a statement generated by the information processing system. According to another aspect of the invention, there is provided an information processing system, the information processing system configured to maintain the status of payment of a transaction, or series of transactions, related to a purchase order, or 10 plurality of purchase orders, and generate a statement of the transaction(s) requiring payment and generate a report of statements that are pending for payment. According to another aspect of the invention, there is provided an information processing system including a network interface for communicating with third parties through a network, and an information processor, including: 15 a purchase order interface to receive information defining a purchase order; a supplier purchase order interface to receive details of a request to vary a purchase order defined using the purchase order interface; a delivery receipt interface to receive information defining, in relation to a said purchase order, the acceptance or rejection of goods/services received; 20 the processing system storing in a database in communication with the information processor the information defining a purchase order, including any requested variations to the purchase order and information defining the acceptance or rejection of goods/services received and making said stored information available through the network interface. 25 The information processing system described in the preceding paragraphs may be used with systems that can communicate with it to enable the buyer to create and approve a purchase order electronically. The invention extends to an information processing system as described above together with one or more systems of the buyer for creating and approving a purchase order electronically.

7 The invention also extends to computer-implemented methods relating to the receipt of purchase orders, purchase order variation requests, and/or delivery receipts and to methods for generating statements relating to purchase orders. The invention also extends to computer storage containing instructions that configure an 5 information processing system as described herein. Further aspects of the present invention and embodiments of the aforementioned aspects will become apparent from the following description, given by way of example and with reference to the accompanying drawings. Brief description of the drawings / figures 10 Figure 1 (prior art): shows the processes and information flow that may be typical of a transaction in goods. Figure 2: shows diagrammatically an information system in which the invention may be implemented. Figure 3: shows a flow diagram of information process steps to be performed by the 15 information system. Figure 4: shows an example of information that may be received at a purchase order interface of the information system. Figure 5: shows an example purchase order that may be generated by the information system. 20 Figure 6: shows an example of information that may be received at a delivery receipt interface of the information system. Figure 7: shows an example delivery exception report generated from information received at the delivery receipt interface.

8 Figure 8: shows a tax invoice that may be issued by a supplier. Figure 9: shows an example debit note generated by the information system. Figure 10: shows an example purchase order notification email directing the supplier to the supplier purchase order interface where the purchase order can be viewed. 5 Figure 11: shows an example viewable purchase order attached to a notification email. Figure 12: shows an example viewable purchase order embedded in the notification email. Figure 13: shows an example verification screen. 10 Figure 14: shows an example reconciliation statement. Figure 15: shows an example verification process. Detailed description of the embodiments The following description is given primarily with reference to the buying and selling of goods. However, the processes described may also be applied to the buying and selling 15 of services and implementations that include or are provided solely for the trading in services are intended to be within the scope of the invention. Trading system overview An overview of the trading system in which the invention may be utilised is given with reference to Figure 2. 20 The invention is implemented in an information system of a services provider 54. This information system may include a web server 56, to facilitate communications with a supplier 50 and a buyer 52 and one or more application servers 58, to execute applications to complete the processes of the invention. Other computational 9 components, including terminals to provide appropriate user interfaces and local area network components will form part of the information system of the services provider 54. These have been omitted from Figure 2. The web server 56 provides an interface to the information system of the services 5 provider 54 for the supplier 50 and the buyer 52. The web server 56 may for instance host a home page, where the supplier 50 and buyer 52 provide log-in details over a secured connection, for instance using an encrypted secure sockets layer (SSL) or Transport layer Security (TLS), and web interfaces 60-67, which provide a user interface to various functions, each of which is described in more detail below. The web 10 server 56 may also receive and send electronic files to and from the supplier 50 and buyer 52. The application servers 58 are responsible for running the application software provided to implement processes described below. The application software may include procurement management software 70 and accounts software 71. In addition, the 15 application servers 58 may include a data import/export engine 72, to manage the receipt, processing and storage of incoming data files and to manage the generation and output of data files. One or more databases, referred to herein as a database 80, stores a set of template definitions 73 and a chart of accounts 74. The supplier 50 will have its own processes, information systems and procedures, 20 which may include, for example, a manufacturing, a packaging, shipping and accounts receivable personnel and systems (as well as others). Various terminals and an information system may be used by the supplier 50, which includes functionality to access the web server 56 through the internet. Similarly, the buyer 52 will have its own processes, information systems and 25 procedures, which may include purchasing, warehouse and accounts payable personnel and systems (as well as others). The buyer 52 will have its own terminals and an information system and access to the internet to allow access to the web server 56.

10 The information systems of one or all of the supplier 50, the buyer 52 and the services provider 54 may include an enterprise resources planning (ERP) system, which may implement a plurality of functions of that entity. For example, procurement management, accounting and data import/export functions performed by the application servers 58 5 may be performed using appropriate an ERP system. Where references in this specification are made to a server, this is intended to be a reference to both a server process, of which one or more may be performed on a single computational system and to a physical server, on which one or more server processes may be run. Figure 2 shows a simplified system in which there is a single supplier 50 and a single 10 buyer 52. However, there may be many suppliers and many buyers, creating a many-to many relationship structure, in which suppliers provide to a plurality of buyers, who may purchase from a plurality of suppliers. Alternative structures, networks and communication methods exist, which may also be utilised to implement the invention. 15 The functions of the web server 56 and application server 58 are described below, with reference to the steps shown in the flow chart shown in Figure 3. Capturing and sending purchase orders - steps I and 2 For buyers that have ERP systems with a data generation and export capability, like the systems available from SAP, Oracle and JD Edwards, the buyer 52 may export a data 20 file containing a purchase order to the web server 56 for receipt and processing by the application servers 58 of the service provider 54. Accordingly, the buyer would generate a purchase order using its own template and its own information systems and communicate this as a data file to the web server 56. Alternatively, the buyer 52 may login to the web server 56, which provides a purchase 25 order interface 60. The purchase order interface 60 is the web interface to the procurement management software 70. The procurement management software 70 receives data entered at the purchase order interface 60 and generates a purchase order, after it has been approved by the relevant authorised officers of the buyer 52, 11 according to its policies and procedures. Relevant authorised officers of the buyer 52, as set up in the buyer preferences, are notified by the procurement management software 70 as and when authorisation is required by auto-email, which contains a web link. This web link is addressed to a web page/screen display in the purchase order 5 interface 60, which is accessed via the web server 56. The purchase order interface 60 may be configurable to suit the particular requirements of the buyer 52, for example by setting preferences. Using the information received at the purchase order interface 60 and communicated to the application server 58, the procurement management software 70 generates a 10 purchase order for the buyer 52. The buyer 52 has one or more individual template definitions 73 stored in a database 80 in communication with the application server 58. These template definitions 73 are used to form the purchase order interface 60 so as to comply with the buyer's specific requirements. For example, the template definition may contain the e-logo, address, ABN, delivery address and other details of the buyer 52. 15 A single buyer 52 may have a range of different templates. Different departments in the buyer 52 may have different login details, which result in the generation of different templates. The name of the department and the particular delivery address may, for example, differ between departments. Otherwise, a buyer 52 may choose a template or answer a question using an interface at a terminal, with the answer to the question 20 determining which template is used. In addition a chart of accounts 74, which includes the general ledger account codes, cost codes and job codes of the buyer may be maintained in the database 80. The general ledger codes are assigned by the application server 58 to each line item in the purchase order via look-up tables contained within the database 80. 25 A buyer 52 may be able to select terms and conditions to be associated with a purchase order. For example, the buyer 52 may be able to select a complete set of standard terms and conditions from a library of terms, which includes standard terms for different types of transactions. For example, the database 80 may store in the library of terms a 12 set of standard terms for a capital transaction and a separate set of standard terms for an expense transaction. In another example, the buyer 52 may be able to build a customised set of terms and conditions by starting with the applicable standard terms and then modifying thereby selecting specific clauses from a plurality of options which 5 may or may not be mixed with other clauses or parts of clauses composed or uploaded by the buyer 52. There may be default terms and conditions which apply in the absence of an explicit buyer 52 selection. The purchase order, which can include any associated terms and conditions, once generated and approved for release, is either then sent to the supplier 50, or the 10 supplier 50 is notified that a Purchase Order is ready for download from a specified URL address 81, for example by email to an address agreed between the supplier 50, the buyer 52 and the service provider 54 and stored in the database 80, for retrieval by the application server 58 as required. (a) Basic purchase order notification email 15 In one embodiment, a basic email 87 (see Figure 10) is automatically generated, such as by the procurement management software 70, to notify the supplier 50 when a purchase order becomes available. The basic email contains a URL 81, for example being a "point and click" hypertext link, directing the supplier 50 to the supplier purchase order interface 61 (the function of 20 which is described later). (b) Purchase order notification email with an attachment containing supplier response buttons In one embodiment the email may, instead of or in addition to the URL 81 in the basic email 87, attach a viewable purchase order 86 and its associated terms and conditions 25 (see Figure 11). The purchase order may, for example, be provided in pdf format. The viewable purchase order 86 may be restricted so that it cannot be saved or printed unless it is first accepted by the supplier 50. The viewable purchase order 86 may also 13 become unable to be viewed after an expiry date, which may be specified by the buyer 52 through the purchase order interface 60 and set when producing the purchase order 86 by the application server 58. The viewable purchase order 86 contains in-built "point and click" supplier purchase 5 order response buttons 85 corresponding to various responses, for example a proceed to acceptance process button 82 or alternatively an accept button, a reject button 83, a change request button 84 or alternatively a combined reject/change request button. Clicking of the supplier purchase order response buttons 85 causes the supplier's information system to communicate the supplier's response and any associated further 10 data to the web server 56, to be recorded in the database 80, with or without intervening steps at the supplier purchase order interface 61, such as a verification process 96 (see Figure 15). Clicking of the accept or proceed to acceptance process button 82 may for example: communicate an accept response to the database 80, cause an automatic acceptance 15 notification email to be sent to the buyer 52; or direct the supplier 50 to the supplier purchase order interface 61, which may include the verification process 96, before acceptance of the purchase order is confirmed, the response recorded in the database 80 and the notification email sent. The time and date of the order acceptance may be recorded in the database 80. The name or other identifier of the person who accepted 20 the order may also be recorded. The verification process 96 could be initiated with a verification screen 92 (see Figure 13) after a supplier 50 has selected the proceed to acceptance process button 82. The example verification screen 92 includes two steps: a supplier Goods and Services Tax (GST) and ABN confirmation step 93; and an acceptance of terms and final confirmation 25 step 94. The supplier 50 can, and may be explicitly notified of their ability to, request changes to any information displayed on the verification screen 92, on the purchase order or in the terms and conditions, before final confirmation of acceptance by supplementing or correcting any information in the supplier purchase order interface 61.

14 In the example verification screen 92 (see Figure 13), the supplier 50 can confirm their: registration for GST; ABN; and acceptance of associated terms and conditions before proceeding to acceptance. According to the verification process 96, of the supplier 50 does not confirm their GST registration and ABN, then they may be directed to correct 5 their ABN, if applicable, and or confirm their GST registration status. If the supplier 50 is not registered for GST, then this may initiate an automated process instructing the supplier 50 to await further instruction, alerting the buyer 52 and/or allowing the buyer 52 to revoke the purchase order. Code initiated by the clicking of the reject button 83 or the change request button 84 10 may for example notify the buyer 52 of the nature of the change request or rejection and/or direct the supplier 50 to the supplier purchase order interface 61 where further information can be entered to supplement or replace existing data. (c) Purchase order notification with in-email supplier response buttons, In one embodiment a viewable purchase order may be embedded in the body of the 15 notification email itself (see Figure 12), with or without buttons or links similar in function to the supplier purchase order response buttons 85.). This in email viewable purchase order 87 may contain in-built "point and click" supplier purchase order response buttons 88 corresponding to various responses, for example a proceed to acceptance process button 89 or alternatively an accept button, a reject button 90, a change request button 20 91 or alternatively a combined reject/change request button. Clicking of the supplier purchase order response buttons 88 initiates similar functions to those described above with respect to the attachable viewable purchase order 86. Similarly, other characteristics of the in-email viewable purchase order 87 may be similar to those described above with respect to the attachable viewable purchase order 25 86. For example, there may be intervening steps at the supplier purchase order interface 61 and view, print and download restrictions may be applied to purchase orders prior to acceptance by the supplier 50.

15 Verification of purchase orders - steps 3 to 7 Suppliers are also given secure web access to parts of the database 80, for example through a supplier self service web portal, created and managed by the service provider 54. This access is limited to access to buyer purchase order information relating to that 5 specific supplier. The identity of a specific supplier 50 or individual supplier employee may be authenticated by using for example, a unique usemame and password. The supplier 50, through the web server 56, accesses the supplier purchase order interface 61 to complete a "Purchase Order look-up" task in the application server 58 responsible for managing the database 80 (i.e. a database management server, which may be 10 separated into a separate tier in the information systems of the service provider 54). This task returns the purchase orders that satisfy the look up criteria, which may include status information, date/time information, responsible personnel information, specific purchase order reference information, and/or buyer name or location information. The supplier 50, through the supplier purchase order interface 61, may then view each 15 applicable purchase order, and its associated terms and conditions, received from the buyer 52 and either accept (after a verification process 96 if provided), reject or request a change for example by using buttons or links similar in function to the supplier purchase order response buttons 85 described above. A purchase order viewable through the supplier purchase order interface 61, for example in pdf format, may have 20 save, print and/or view date restrictions similar to those described above with respect to a viewable purchase order 86. The supplier's response(s) to each purchase order through supplier purchase order interface 61 may be recorded to the database 80 along with further data associated with the response such as: the identity of supplier 50 employee; comments including those 25 relating to specific question fields or parts of the purchase order; the time and date; and/or the IP address from where the response was made. The supplier's response may also be communicated to the buyer 52. Purchase order response information recorded in the database (80), and/or communicated to parties in each transaction, may help create an audit trail and/or avoid 30 disputes. For example, if the supplier 50 accepts the purchase order an automatic acceptance notification email may be sent to the buyer 52. A supplier 50 accept 16 response, for example received via a viewable purchase order 86 or the supplier purchase order interface 61, may help clarify that the buyer's purchase order terms and conditions apply to that specific purchase transaction. This may provide greater certainty and assist the buyer 52 if anyone attempted to assert that alternate terms, 5 such as those provided by the supplier 50 on the tax invoice/and or sales quote, apply. If rejecting the purchase order, the supplier 50 can for example provide comments including reason(s) for rejection such as disagreement with terms and conditions or withdrawal of requested goods/services from sale. Alternatively, if requesting a change to the purchase order the supplier 50 can for example make comments relating to a 10 specific part of the purchase order. For example the supplier 50 can note any discrepancies, such as the buyer 52 entering an incorrect purchase price, and enter the required changes on the purchase order. For example, if the supplier 50 has received a purchase order containing the wrong price, the supplier, prior to delivery of the goods, retrieves the detail of the specific purchase order from the database 80 and by "point & 15 click" highlights which line item entry in the purchase order is incorrect. The web server 56 may also provide, as part of the supplier purchase order interface 61, a selection of various types of error, one of which may be 'unit price error'. Through point and click process the supplier chooses the applicable type of error then in another "field" inputs the correct unit price. A field may be provided for the supplier 50 to enter 20 comments and/or input details of a type of error, which may not appear in the available selections. The information received from the supplier 50 is recorded in the database 80. The buyer 52 can access "Purchase Order error screens & reports" and may check for these on a periodic basis, for example daily. The procurement management software 25 70, which as mentioned earlier may be part of an ERP system, also prompts the designated authorized officer of the buyer 52, for example via an auto-email alert, to review the "Purchase Order Error screen/report" and continue to prompt the relevant officers authorized by the buyer 52 so long as there are purchase orders that require rectification. These reports are created as a result of the supplier indicating an error in a 30 purchase order.

17 The web server 56 displays a prompt to the buyer 52 to either approve or decline the change requested by the supplier 50. The approval of several of the buyer's authorizers may be required depending on the variance and the preferences of the buyer 52. These preferences may be entered when the profile of buyer 52 is first entered into the 5 application server 58 and the preferences will indicate the authorised person(s) who can change the preferences. If the buyer 52 wants to vary other aspects of the purchase order, the buyer 52 may select to cancel the existing purchase order and then issue another purchase order, or enter a variation order, to cover the required variations, using the purchase order 10 interface 60. At any time a purchase order remains unfilled (i.e. some or all of the goods relating to a purchase order have not been received & accepted by the buyer at that time) the relevant authorised person(s) of the buyer 52 can cancel or amend that purchase order via the purchase order interface 60. Variations to unfilled purchase orders may be required, for example, if the buyer 52 identifies an error in the purchase 15 order or the buyer 52 needs to make a change to the purchase order for any other reason (e.g. the purchase order is cancelled due to an economic downturn or the purchase order is cancelled due to poor quality of goods recently received from the same supplier). The purchase order interface may allow the buyer 52 to enter a reason for the purchase order variation/cancellation. In such cases, the procurement 20 management application 70 may automatically generate an email notice to the supplier advising the variation/cancellation to the purchase order. In one embodiment, the procurement management server 58 may 'lock' received purchase orders and require the supplier 50 to indicate that it has checked and accepted a purchase order before that purchase order is 'unlocked', with only unlocked 25 purchase orders being capable of entry into the queue for delivery (see below). This may assist in preventing delivery of goods in response to a purchase order unless the supplier has first agreed to the buyers intended terms of trade which are detailed in the buyers purchase order. The procurement management software 70 may auto-create reports highlighting those purchase orders that have not been checked and/or accepted 30 by the supplier 50 within a reasonable pre-determined time period. The procurement 18 management system 70 may auto-email alert the buyer 52 if purchase orders have not been checked and/or accepted by the supplier 50 within that relevant time period. If the purchase order is correct or any variations made and indicated as acceptable by both the supplier 50 and the buyer 52 through the purchase order interface and supplier 5 purchase order interface respectively, the supplier then downloads a copy of the purchase order from the database 80 in an e-file format (eg csv, pdf, txt, xmI, ASCII). If the supplier has an ERP system in its information systems, the supplier can import the purchase order into its ERP system, which can then create a delivery docket and tax invoice from the purchase order data. Alternatively, the supplier 50 may receive and 10 handle the purchase order in other ways, for example by the procurement management server 70 auto-emailing or auto-faxing the purchase order to the appropriate personnel of the supplier 50 and/or by printing the purchase order from the purchase order interface 60, for use by the appropriate personnel. The supplier 50 then attends to delivery of the goods to the buyer 52 together with the delivery docket. 15 Delivery of goods - steps 8 and 9 Upon receipt of the goods from the supplier 50, the buyer 52 checks the goods and provides delivery receipt data to the service provider 54, via the web server 56. This delivery receipt data is stored in the database 80 and made available for review by the supplier 50 (see below). 20 For buyers that have robust ERP systems like SAP, Oracle & JD Edwards the buyer 52 may export, on a periodic/frequent basis (e.g. hourly), e-files containing new "goods receipt" data. This will contain the relevant purchase order number and detail the goods received & accepted (i.e. goods not damaged or defective) by the buyer's warehouse for each delivery of goods received. 25 More particularly, on receipt of the goods, the buyer's warehouse (or other delivery receipt facility) will review the goods against the delivery docket and perhaps also the purchase order. If all goods are accepted, then this is entered at a terminal and stored in the information systems of the buyer 52. If some or all of the goods are not accepted, then this is entered at a terminal together with the reason(s) why the goods are not 19 accepted. Reasons for non-acceptance may include the wrong goods being delivered, the goods being damaged or defective, the quantity of the received goods does not match the purchase order. This information is used to generate the e-file of goods receipt data, which is received by the web server 56 and forwarded to the application 5 server 58 for storage in the database 80. Alternatively the buyer warehouse can login to the web server 56 and access the delivery receipt interface 63. The buyer can then enter a search query for the purchase order number, which is serviced by the procurement management software 70. The purchase order is displayed on the applicable terminal of the buyer 52 and the operator 10 of the terminal can then click on the items received. The buyer indicates any items listed in the delivery docket that were wrong, missing, damaged or defective and provides a brief description of the damage/defect and/or wrong delivery. This information is then received by the procurement management software 70 and stored in the database 80. In one embodiment, a data file containing a debit note and delivery exception report, is 15 automatically emailed by the procurement management server 70 to the supplier 50 providing the details of the goods that have been accepted and those that have been rejected, in which case the supplier 50 may use its own information systems to view and process this data. To reduce the amount of email traffic, the data file may be sent only if goods have been rejected and/or missing. 20 In another embodiment, the information is retained in the database 80 and made available to the supplier 50 through the supplier delivery receipt interface 63. The accounts receivable department of the supplier 50 can then, through this interface, look up the buyer purchase orders that relate to that supplier and review the data indicating if goods have been accepted or rejected by the buyer 52. 25 If goods have been rejected by the buyer 52, the supplier's accounts receivable department will see the reason entered by the buyer 52 for the rejection and make any required adjustments to their accounts receivable balance. Consequently, the supplier 50 may be less likely to chase the buyer 52 for payment on goods which are damaged/defective/wrong.

20 The procurement management software 70 also includes, suitably as part of the delivery report, the expected amount to be paid to the supplier 50 in relation to the purchase order and when payment is expected to be made. This information is obtained from the purchase order entered at step 2 and including any variations accepted in step 5 6. Consequently, the suppliers accounts receivable department will be able to see if the buyer's purchase order contains incorrect unit price data, enabling remedial action to be taken if appropriate. Statement and reminder generation - steps 10 to 13 Periodically, for example at the end of each calendar month, the accounts software 71 10 creates a statement for the buyer 52 from a combination of the following information stored in the database 80 due to the process described above: from the purchase order entered at step 2 and varied in step 6 - the goods and/or services description, unit price, supplier name & address, supplier ABN information, buyer purchase order number; and from the delivery receipt data captured in step 9 - the "unit quantity accepted" 15 information (i.e. goods not damaged, missing or defective). The monthly statement accordingly contains purchase values that match both the unit price information in the buyer's purchase order and the delivery receipt information provided by the buyer's warehouse. As a result, the buyer 52 may not need to wait for the supplier 50 to issue revised tax invoices or credit notes before the accounts payable 20 department of the buyer 52 can process payment. This may result in suppliers 50 being paid earlier for "goods received & accepted in good order". The monthly statement is downloadable from the web server 56, with the accounts software 71 formatting the statement in an e-file format (ie csv, txt, pdf, TIF etc) for storage by the buyer. The accounts software 71 may be able to provide the statement in 25 various formats, with the buyer 52 entering its preferred format in its preferences. The downloaded statement may then be able to be utilised by the ERP system of the buyer 52 to facilitate processing and any required record keeping. The service provider 54 may keep the statements in the database 80 for a period agreed with the buyer 52 and/or supplier 50, which may be dependent on any relevant legislative requirements. 30 The accounts software 71 monitors which monthly statements have been downloaded 21 by the buyer 52 and which have not, and provides auto-email alerts to the buyer 52 when the monthly statements have not been downloaded within a pre-specified time limit, for example seven days. The auto-email may contain a web link to the relevant page provided by the web server 56 where the statement can be downloaded. 5 For a buyer 52 that uses the procurement management software 70 to raise purchase orders, the accounts software 71 may provide periodic, for example daily transaction reports to the buyer 52, which detail the goods accepted by the buyer and the relevant general ledger codes, looked up from the chart of accounts 74 stored in the database 80, which then can be imported into the buyer's accounting system to capture that days 10 purchases. The reports may for example be in csv, txt or xml format and downloadable from the web server 56 and/or automatically exported from the web server 56 to the buyer 52 on a periodic basis such as hourly or daily. The accounts software 71 monitors which daily transaction reports have been downloaded by the buyer 52 and which have not, and provide auto-email alerts (containing a web link to the relevant down load page 15 in the web server 56) to the buyer 52 when the daily transaction reports have not been down loaded within a pre-specified time limit. The accounts software 71 may also generate "Statements Pending Payment" information on screen and/or via a report. This screen/report contains a listing of both newly created and any unpaid statements and may be accessed through the accounts 20 interface 66. The accounts interface 66 may include a web page that displays the month/year, total statement value and target payment date of each monthly Statement. The accounts software 71 is also programmed to auto-send an email reminder to the relevant authorized officer of the buyer 52, as entered in the preferences of the buyer 52 stored in the database 80, to remind him/her that there is a statement due to be paid on 25 a certain date. The email contains a web-link so that the officer of the buyer 52 need only "point & click" on the link to be taken to the "Statements Pending Payment" information described above. In one embodiment, the service provider 54 also arranges for payment for the transaction. For example, the buyer 52 upon receipt of a statement or the statements 22 pending payment information would then either (a) point & click to confirm that the payment for the relevant statement should proceed or (b) the buyer 52 would change the "payment date" for that relevant statement. Once payment is approved, the accounts software 71 auto-creates a bank EFT batch file from the monthly statement 5 data and account information in the preferences of the buyer 52 and transmits the EFT batch file to the bank of the buyer 52 for processing. Once payment has been confirmed as received by the accounts department of the service provider 54 and notified to the accounts software 71 using a terminal (not shown), then the accounts software 71 auto creates a bank EFT batch file to transfer the funds to the supplier 50. Alternatively, upon 10 approval by the buyer 52 of the monthly statement for payment, the accounts software 71 may auto-create a bank EFT file from the monthly statement data which, after transmission to the bank of the buyer 52, will debit the specified bank account of the buyer 52 for the gross value of the monthly statement and electronically credit the bank account of each relevant supplier 50 (thus avoiding the two-step process detailed 15 above) for the relevant amount owing to each supplier 50 as detailed in that relevant monthly statement. A transaction fee may be added to the amount to be paid by the buyer 52 and/or deducted from the amount paid to the supplier 50. The accounts software 71 may aggregate into a single monthly statement for a buyer 52 all transactions with each supplier. Similarly, the statements pending report may be an 20 aggregation across all suppliers. This may reduce the time and potential for errors in the buyer 52 dealing with separate statements from each supplier. Also, where the buyer 52 makes payment to the service provider 54, a single payment may be made based on the statements, with the service provider 54 arranging for payment to each of the suppliers referenced in the monthly statement. Alternatively, the accounts software 71 25 can be programmed such that the EFT batch files are auto-created in a manner that will result in the buyer 52 making direct payment to each supplier 50, rather than payments passing via the service provider 54. In the latter example, payment to all suppliers could be made on a common date for all suppliers or, alternatively, payments could be made to each individual supplier 50 on separate dates, for example a date mutually agreed 30 between the buyer 52 and each of the suppliers 50 transacting with the buyer 52.

23 In one embodiment the statement, for example a monthly statement, is a corporate card statement as defined by the Australian Taxation Office. In one embodiment the service provider 54 may give the buyer 52 the option to receive a statement in the form of a Recipient Created Tax Invoice (RCTI), for example as 5 defined by the Australian Taxation Office. The RCTI, in respect of the goods/services nominated by the buyer 52, can be generated on the date the goods/services are captured as received and accepted by the buyer in the delivery receipt interface 63. In embodiments that use a RCTI, the email notification of a purchase order to the supplier may further include a button or link to a site, which enables the supplier to 10 confirm that it is willing to receive RCTI's from the buyer (in lieu of the supplier sending a tax invoice to the buyer). The button may be provided in the same way and together with the supplier purchase order response buttons 85 described above. In this case the purchase order terms and conditions would contain an embedded RCTI agreement. The link may direct the supplier 50 to a website of the web server 56. In this latter 15 embodiment, the terms and conditions may be embedded in the purchaser order terms and conditions or instead or in addition provided at the website interface. By following the process above, the system provides for the electronic creation, notification and delivery of an RCTI Agreement to the supplier and enables the electronic acceptance (or rejection) of the RCTI Agreement by the supplier. In 20 combination with this, the email notification to the supplier, enabling acceptance, rejection or amendment to a purchase order by the supplier may assist to improve the accuracy of the purchase transaction data contained in the RCTI. Reconciliations In addition to, or instead of, periodic statements described above, the accounts software 25 71 may create reconciliations, for example a monthly reconciliation statement 95 (see Figure 14). Periodically, for example at the end of each calendar month, the reconciliation statement 95 may be automatically emailed to the relevant supplier 50 and/or made available to the supplier 50 for download from the database 80 via the 24 supplier self service web portal. The supplier 50 may access a reconciliation for a variety of purposes including, for example, to view, print or save and/or upload into ERP or accounting systems. Reconciliations may be in the form of an RCTI. Reconciliations may take into account all transactions between a particular buyer 52 5 and supplier 50 including purchases, retums and payments, for a given period and calculate net balances for that period such as beginning and ending balances and GST inclusive and exclusive amounts. Errors discovered after delivery In the event that the supplier 50 failed to notice a price error in the purchase order and 10 until after payment for the goods was received by the supplier 50 (i.e. the supplier 50 received a lower amount than expected), the procurement management software 70 may provide for the supplier 50 to request an "adjustment payment". This process would proceed similar to steps 4 to 6 shown in Figure 3. The supplier 50 logs in to the web server 56 and in the adjustment interface 67, search 15 for the relevant purchase order and point & click to the relevant line item in the purchase order that contains the incorrect unit price data. This line item would be "flagged" and the supplier 50 types in a "justification" field reasons why the buyer 52 should make an "adjustment payment". The adjustment interface 67, also requests the supplier to upload a copy of the relevant tax invoice, so that it can be viewed by the buyer 52. An 20 exceptions report is then generated from the received information and made available to or sent to the buyer 52. The buyer 52 may receive an auto-email alert from the procurement management software 70 advising that an 'adjustment payment request' requires the attention of the buyer 52. The email may contain a web-link back to the relevant purchase interface screen via the web server 56. The buyer 52 then 'points and 25 clicks' its acceptance or rejection of the adjustment. Should the adjustment payment be accepted, this adjustment is captured within the next available monthly Statement and EFT process.

25 Example data entry and generated forms Figure 4 shows an example of information that may be received at the purchase order interface 60 for use in generating a purchase order. Similar information will be contained in an e-file generated by an ERP system. 5 The information includes: The buyer's name, which in the example is ABC Company Pty Ltd. This may be automatically retrieved from the database 80 in response to the buyer's login details. The buyer's purchase order number. This may be entered manually and/or generated automatically (in sequential number order) by the procurement management 10 server 70. The supplier's details, which in this example includes the name, Supplier Co Pty Ltd, only. This may be typed in or alternatively, the procurement management server 70 may contain a list of supported suppliers, from which one is selected. The order details, including the goods description, delivery address, the relevant 15 part number of product code for each good ordered, the quantity of the goods ordered, the price per unit and total cost, required delivery date, the general ledger code, cost centre code, job code, project code and asset ID. The information may be entered manually. Alternatively, some may be based on a selection of a range of items. For example, the supplier may upload to the database 80 20 details of its product catalogue, including price details and the buyer may select the products required and quantity required, following which the price details may be automatically entered by the procurement management software 70. As discussed previously, the chart of accounts 74 may be used to automatically provide the general ledger (GL) code for each product ordered. The cost centre code may be dependent on 25 the login details of the buyer, with different cost centres in the buyer having different codes, which can then be automatically entered. Figure 5 shows an example of a purchase order generated using the purchase order information. The information is included in a template from the template definitions 73.

26 Figure 6 shows an example of information entered through the delivery receipt interface 63. Various fields are provided for entering the quantity received and any wrong deliveries or defective product. In addition, a debit note value is entered or may be calculated automatically by the application server 58 and this is used to auto-create and 5 email a debit note to the supplier 50, to offset the incorrect amount in the tax invoice that the supplier 50 issued. An example tax invoice is shown in Figure 8 and a corresponding example of a debit note generated by the accounts software 71 in response to the information in the goods receipt input screen, is shown in Figure 9. An example of a delivery exception report generated by the accounts software 71 in 10 response to the information in the goods receipt input screen, is shown in Figure 7. The debit note may be auto-emailed by the accounts software 71 to the accounts receivable department of the supplier 50. When the EFT batch file relating to a monthly statement has been transmitted to the bank of the buyer 52 and payment to the supplier 50 is made, as described above, the 15 accounts software 71 also auto-creates and emails to the accounts receivable department of the supplier 50 a remittance advice notifying the supplier 50 of the payment by the buyer 52. The remittance advice displays the purchase order numbers associated with the payment to assist the supplier 50 to reconcile its bank statement. The information contained in the database 80 may additionally be of use to the supplier 20 50 in managing its manufacturing facilities, for example if products are made to order, or if the supplier 50 implements a 'just in time' manufacturing system, may be of value in scheduling resources for packaging, shipping and related activities, for forecasting space requirements for storage of products and/or for monitoring and forecasting cash flow. The information contained in the database 80 may additionally be of use to the 25 buyer 52 for managing its warehouse, its distribution systems and its cash flow. Figure 10 shows an example of a purchase order notification sent by basic email 87. The email contains a URL 81, directing the supplier 50 to the supplier purchase order interface 61 where the purchase order itself can be viewed and then accepted, rejected or changes requested. In this example the buyer 52 is called Buyer Co Pty Ltd and the 30 supplier 50 is called Supplier Co Pty Ltd 27 Figure 11 shows an alternate example of a purchase order notification sent by email. The purchase order itself, shown in the figure, is attached to the email as a viewable purchase order 86 and may include save, print and view date restrictions. The viewable purchase order 86 contains in-built "point and click" buttons, to enable the supplier 50 to 5 accept, proceed to the acceptance process, reject or request a change to the purchase order. In this example the buyer 52 is called Buyer Co Pty Ltd and the supplier 50 is called Supplier Co Pty Ltd. Figure 12 shows an alternate example of a purchase order notification sent by email. The purchase order itself is embedded in the body of the email as a viewable purchase 10 order 87 and may include save, print and view date restrictions. The viewable purchase order 87 contains in-built "point and click" buttons, to enable the supplier 50 to accept, proceed to the acceptance process, reject or request a change to the purchase order. In this example the buyer 52 is called Buyer Co Pty Ltd and the supplier 50 is called Supplier Co Pty Ltd. 15 It will be understood that the invention disclosed and defined in this specification extends to all alternative combinations of two or more of the individual features mentioned or evident from the text or drawings. All of these different combinations constitute various alternative aspects of the invention.

Claims (8)

1. An information processing system, the information processing system configured to: receive and store information defining a purchase order from a buyer, the information including a specified supplier; 5 make the purchase order available to the supplier; receive a request for variation of the purchase order from the supplier; make the request for variation available to the buyer and receive data indicating either acceptance or rejection of the request for variation; if the request for variation of the purchase order is indicated as accepted, store 10 the varied purchase order information.

2. An information processing system, the information processing system configured to: receive from a buyer and store information defining a purchase order; make the information defining the purchase order available to a supplier; receive and store from the buyer information defining acceptance and rejection of 15 items listed in the purchase order; make the information defining acceptance and rejection of the items listed in the purchase order available to the supplier.

3. The information processing system of claim 1 or 2, wherein the system is further configured to send a purchase order notification to the supplier in the form of an email, 20 wherein the email has associated with it the ability for the supplier to respond by accepting, rejecting or requesting changes to the purchase order. The supplier's responses may then be made available to the buyer, and/or stored in the database.

4. The information processing system of any one of the preceding claims, wherein the system is further configured to generate a statement for the buyer, detailing the 25 transaction or transactions in a purchase order. The statement may be adjusted automatically depending on the information defining acceptance and rejection of the items listed in the purchase order.

5. The information processing system of any one of the preceding claims, wherein the system enables the generation of recipient created tax invoices and an electronic 29 notification to the supplier with a purchase order enables the supplier to communicate to the information processing system acceptance of an recipient created tax invoices from the buyer.

6. An information processing system, the information processing system configured to 5 maintain the status of payment of a transaction, or series of transactions, related to a purchase order, or plurality of purchase orders, and generate a statement of the transaction(s) requiring payment and generate a report of statements that are pending for payment.

7. The information processing system of any one of the preceding claims, wherein a 10 plurality of purchase orders for a supplier or plurality of suppliers, are aggregated into a statement generated by the information processing system.

8. An information processing system including a network interface for communicating with third parties through a network, and an information processor, including: a purchase order interface to receive information defining a purchase order; 15 a supplier purchase order interface to receive details of a request to vary a purchase order defined using the purchase order interface; a delivery receipt interface to receive information defining, in relation to a said purchase order, the acceptance or rejection of goods/services received; the processing system storing in a database in communication with the 20 information processor the information defining a purchase order, including any requested variations to the purchase order and information defining the acceptance or rejection of goods/services received and making said stored information available through the network interface.