AU2013100335A4 - Stock management system - Google Patents

Abstract

H:\spm\Inievtoven\NRPortbl\DCC\SPM\$O02158 L.doc-19/03/2013 A system for stock management for at least one customer who uses stock including: a management component for an ordering system configured to: receive stock requirements data representing required stock levels of a plurality of products at a plurality of sites serviced by the customer, and receive delivery frequency data representing delivery frequencies for the sites; and an ordering component for the ordering system configured to: access customer account data representing invoicing details for the customer, generate order data, representing an order for each site, based on the required stock levels and the delivery frequencies of the sites, and generate invoice data representing an invoice for each order based on each order and the invoicing details in the customer account data. Cd~c1 5'~o~ 0C +J c rn A

Description

H:\spn\Intenvoven\NRPortbl\DCC\SPM\5002158_I.doc-19/03/2013 STOCK MANAGEMENT SYSTEM TECHNICAL FIELD [01] The present invention relates to systems, processes and computer-readable media with computer-readable instructions for stock management, e.g, for re-stocking multiple products computer-readable media with (e.g, consumable products such as cleaning products) at multiple sites for customers of a single supplier (e.g., of the consumable cleaning products). BACKGROUND [02] In various industries, companies and organisations need to maintain stocks of various products at many different sites. For example, in the cleaning industry, a cleaning company can have many different sites where cleaning products are used and stored. [03] Ordering and re-ordering these products from one or a few suppliers can be more efficient than ordering each type of product from a separate supplier. Nevertheless, it can be difficult, using existing stock management systems, to maintain a sufficient level of each stock at each location in a timely manner (including in relation to any budgets) because: the usage rate of each product can be very different (e.g, gloves compared to mops), the usage rates of products can change over time (e.g., more cleaning fluid may be required if a commercial office starts to use more plates and cups each day), and the people using and replacing the stock can change for each site (e.g, different cleaners may operate at each site). [04] Existing systems for managing stock in these industries are labour intensive, and fail to provide functions for controlling and/or monitoring for stock levels and/or spending in sufficient detail and in a timely manner. [05] For example, existing systems may allow stock to run out unless the stock levels are monitored closely, which can be labour intensive for a cleaning company with many sites and varied products. [06] It is desired to address or ameliorate one or more disadvantages or limitations associated with the prior art, or to at least provide a useful alternative.

H:\spm\Intenvoven\NRPortbl\DCC\SPM\5002158 L.doc-19/03/2013 -2 SUMMARY [07] In accordance with the present invention, there is provided a system for stock management for at least one customer who uses stock including: a management component for an ordering system configured to: receive stock requirements data representing required stock levels of a plurality of products at a plurality of sites serviced by the customer, and receive delivery frequency data representing delivery frequencies for the sites; and an ordering component for the ordering system configured to: access customer account data representing invoicing details for the customer, generate order data, representing an order for each site, based on the required stock levels and the delivery frequencies of the sites, and generate invoice data representing an invoice for each order based on each order and the invoicing details in the customer account data. [08] In embodiments, the management component can be configured to determine a usage rate for at least one of the plurality of products based on received stocktake data representing on hand numbers of the products at one or more stocktake times. The order data can represent a number of each product in the order which can be determined based on the determined usage rate, the on-hand value of the product at the site, and the delivery frequency. [09] The management component can be configured to determine if a product is a one-off order based on a user selection, and to remove the one-off order product from the required stock levels after the order has been generated. [10] The management component can be configured to store transaction data representing the orders, and to generate reports representing usage data for each site based on the transaction data, including stock on-hand values generated by the management component based on the usage rate, the order amounts and the delivery dates/times of the products. The management component can be configured to generate a report including selected transaction data relating to products identified as rechargeable products using a rechargeable indicator in the product data. [11] The management component can be configured to: generate alert data representing an approval alert based on the received stock requirements data and/or delivery frequency data; and H:\spn\1ntcnv oven\NRPortbI\DCC\SPM\5002158_ Ldoc-19/03/2013 -3 receive approval data representing approval of the received stock levels and/or delivery frequencies. [12] The management component can be configured to: access budget data representing current budgets for the sites; access pricing data representing pricing details of the products; determine site spends based on the pricing details of the products in the orders; and generate alert data representing at least one budget alert if one of the site spends is above a selected threshold associated with a corresponding one of the site budgets. [13] The present invention also provides a process for stock management for at least one customer who uses stock including the steps of: receiving stock requirements data representing required stock levels of a plurality of products at a plurality of sites serviced by the customer; receiving delivery frequency data representing delivery frequencies for the sites; accessing customer account data representing invoicing details for the customer; generating order data, representing an order for each site, based on the required stock levels and the delivery frequencies of the sites, and generating invoice data representing an invoice for each order based on each order and the invoicing details in the customer account data. [14] The process can include the step of determining a usage rate for at least one of the plurality of products based on received stocktake data representing on-hand numbers of the products at one or more stocktake times. [15] The order data can represent a number of each product in the order which is determined based on the determined usage rate, the on-hand value of the product at the site, and the delivery frequency. [16] The process can include the steps of: determining if a product is a one-off order based on a user selection; and removing the one-off order product from the required stock levels after the order has been generated. [17] The process can include the steps of: storing transaction data representing the orders; and H:\spn\Intemvoven\NRPortbl\DCC\SPM\5002158_ Ldoc-19/03/2013 -4 generating reports representing usage data for each site based on the transaction data, including stock on-hand values generated based on the usage rate, the order amounts and the delivery dates/times of the products. [18] The process can include the step of generating a report including selected transaction data relating to products identified as rechargeable products using a rechargeable indicator in the product data. [19] The process can include the steps of: generating alert data representing an approval alert based on the received stock requirements data and/or delivery frequency data; and receiving approval data representing approval of the received stock levels and/or delivery frequencies. [20] The process can include the steps of: accessing budget data representing current budgets for the sites; accessing pricing data representing pricing details of the products; determining site spends based on the pricing details of the products in the orders; and generating alert data representing at least one budget alert if one of the site spends is above a selected threshold associated with a corresponding one of the site budgets. [21] The present invention also provides computer-readable media storing computer readable instructions configured to control one or more computer processors to perform the above processes. [22] A stock management system can include an ordering system, a shipping system, an invoicing system and/or a distribution system. BRIEF DESCRIPTION OF THE DRAWINGS [23] Preferred embodiments of the present invention are hereinafter further described, by way of example only, with reference to the accompanying drawings, in which: [24] Figure 1 is a block diagram of a distribution system; [25] Figure 2 is a block diagram of data records in orders data of the distribution system; [26] Figure 3A is a flowchart of a stock management process performed by the distribution system; H:\spm\Jntcnovcn\NRPortbl\DCC\SPM\5002158_ L.doc-19103/2013 -5 [27] Figure 3B is a flowchart of an order generation process performed by the distribution system; [28] Figure 4A is a screen shot of an example site list generated by the stock management process; [29] Figure 4B is a screen shot of an example site requirements user interface (UI) generated by the stock management process; [30] Figure 4C is a screen shot of an example stock (or product) list Ul generated by the stock management process; [31] Figure 4D is a screen shot of an example stocktake UI generated by the stock management process; [32] Figure 4E is a screen shot of an example rechargeables report generated by the stock management process; [33] Figure 4F is a screen shot of an expenditure report generated by the stock management process; [34] Figure 4G is a screen shot of an example budget comparison report generated by the stock management process; [35] Figure 4H is a screen shot of an example on-hand report generated by the stock management process; [36] Figure 41 is a screen shot of an example usage report generated by the stock management process; and [37] Figure 5 is a block diagram of an example ordering system configured to implement at least portions of the stock management process and the order generation process in the distribution system. DETAILED DESCRIPTION [38] A distribution system 100, as shown in Figure 1, includes an ordering system 102 that receives stock requirements from customers each using a client system 106, and generates order data representing orders and invoice data representing invoices for the customers using a shipping and invoicing system 104 connected to the ordering system 102. Each client system 106 H:\spm\Intenvoven\NRPorlbl\DCC\SPM\5002158_ I.doc-19103/2013 -6 communicates electronically with the ordering system 102 using a data communications network 108, e.g., the internet. [39] Each customer using the client system 106 typically has many locations or sites, and each site typically has many products that are consumed on a regular basis, e.g., every few days, weeks, months, etc. A customer can use the client system 106 to send data to the ordering system 102 representing the product requirements for each site, and the ordering system 102 can then generate the orders and the invoices automatically to maintain the stock levels at the sites based on the respective site requirements. [40] The ordering system 102 can provide reports data representing reports to a user, e.g., by transmitting data to the client system 106, and the reports can be generated to represent both inventory and budgetary/financial information for the customer for each of their sites and for groups of sites. [41] The distribution system 100 can allow a customer to maintain stock levels at their sites without having to fill out orders manually and maintain internal stocking and spending records separately. The ordering system 102 can receive stocktake information in data from the client system 106 and automatically update data representing site requirements for the sites based on actual product usage represented in the stocktake data. [42] The site requirements can include whether a product is rechargeable by the customer, i.e., that the cost for the product can be passed on to a third party associated with the site, e.g, the owner of the site or a business owner on the site (e.g., the party who contacts a cleaning company to clean their site). Example rechargeable products can be pre-defined based on agreements between the customer and the third party, e.g., products for use by the third party (e.g., a floor mat) or products that are used in varying amounts (e.g, toilet paper, hand towels, hand soap, etc.). The ordering system 102 can generate reports distinguishing rechargeable items on a regular basis to allow the customer to invoice the third party appropriately. [43] The ordering system 102 can generate alerts data representing alerts, e.g, in the form of emails for designated contacts of the customer if the ordering system 102 detects that spending for a site (or group of sites) approaches or exceeds a pre-selected budget for the site, or if a stocktake is due, or when an order is placed, or if site requirements entered via the client system 106 by one user (e.g., an area manager) need to be approved by another user (e.g, a senior manager).

H:\spm\Intenvoven\NRPortb\DCC\SPM\5002158_ Ldoc-19103/2013 -7 [44] The distribution system 100 can allow the customer to order one-off items for each site, e.g., a vacuum cleaner, a mop / broom, etc without disrupting the regular ordering. [45] The shipping and invoicing system 104 includes commercially available computer hardware with a commercially available operating system (e.g., Microsoft's Windows), and software modules written in a commercially available code language (e.g., C#) and compiled into functional components based on a commercially available framework (e.g., the .NET framework). The components, which are also referred to as modules, in the shipping and invoicing system 104 include shipping components 1 l0which generate shipping data representing items to be shipped in the distribution system 100 (e.g., including shipping manifests etc). The shipping and invoicing system 104 includes billing components 112, which generate invoicing data for customers based on the orders placed and the customer's details in accounts data. The accounts data is stored in accounts data storage 114, e.g., commercially available computer-readable storage, such as hard drives or cloud storage, in the shipping and invoicing system 104. [46] As shown in Figure 1, the ordering system 102 includes a server component 116 configured to communicate with a client component 118 of the client system 106. The server component 116 can be a web server (e.g., based on .NET framework), communicating with a web browser that generates the client component 118 in the client system 106. The client system 106 can include a commercially available computing device-e.g., a personal computer (PC), a laptop computer, a notebook computer, a tablet computer and/or a mobile computing device such as a smart phone-with a commercially available operating system, internet-connection components, and a commercially available internet browser or customised application (e.g., an iPhone app) for hosting the client component 118. The client component 118 can be stored on computer-readable media in the client system 106, e.g., on a hard drive or in random access memory. [47] The server component 116 is in communication with a management component 120 of the ordering system 102. The management component 120 receives user input data from the client component 118 via the server component 116, and generates user interface (UI) and report data for sending to the client component 118 via the server component 116. The management component 120 also processes data received from the client component 118 according to pre defined rules, routines and/or scripts in computer-readable instructions in the management HAspm\Intcn ovcn\NRPorlbl\DCC\SPM\5002l58_ l.doc-19/03/2013 -8 component 120, and based on data accessed in orders data storage 122 in the ordering system 102. The management component 120 accesses an accounts component 124 of the ordering system 102 to authenticate communication with the client component 118 based on authentication data from the user (e.g., a username and password combination). [48] The management component 120 communicates with a UI and reporting component 126 of the ordering system 102 to generate the UI in the client component 118 and to provide the reports for the client component 118. [49] The management component 120 receives data representing site requirements from the client component 118 and records the site requirements and budget requirements in the orders data in the orders data storage 122. [50] The ordering system 102 includes scheduled task components 125 that operate according to a schedule and independently of the timing of input from the client component 118. The scheduled task components 125 include an ordering component 128 and an alerting component 130. The ordering component 128 operates to generate orders for the shipping and invoicing system 104 based on the schedule and the stored orders data. The alerting component 130 operates according to the schedule to generate alerts for contacts of the customer recorded in the accounts data. The alerts can include order alerts, generated when an order is made, shipping alerts, generated when an order is shipped, budget alerts, generated when spending approaches or exceeds a budget, and approval alerts generated when approval is required for a stock request made in relation to a site. [51] The orders data in the orders data storage 122 includes a plurality of data records 200 for each customer. The data records 200 are associated with customer account data in the accounts data and are generated by the management component 120 based on accounts data and input data from the client component 118. [52] The various data storages described herein can include a relational database and a structured query language (SQL) interface for accessing the stored data. The various components and modules described herein stored as files with computer-readable instructions on computer-readable media (e.g., hard drives or optical discs). [53] As shown in Figure 2, the data records 200 include a customer record 202 for each customer. The customer record 202 includes a customer identifier (ID) 204, invoicing details 206 H:\spn\lnteroven\NRPortbl\DCC\SPM\5002158I .doc-19/03/2013 -9 for each customer (linked to data in the accounts data), at least one senior management ID 208 for the customer, at least one administration (admin) manager ID 210 for the customer, and a sites list 212 listing the sites of the customer. The sites list 212 can include a list of site identifiers (IDs) and each listed site ID is associated with a site record 214 for the site. The site record 214 includes its quasi-unique site ID 216, at least one area manager ID 218, shipping details 220 for the site (e.g., 120 Smith St, Sydney, NSW), a next delivery date 221 for the site, stocktake timing details 222 (e.g., including a last stocktake date, and a stocktake due date), a delivery frequency 224 for the site, a budget 226 for the site, an approval indicator 228 for the site (indicating that details in the site record 214 have been approved by a more senior manager, e.g., a senior manager or an admin. manager), and a products list 230 listing product IDs for the site. Each product ID in the products list 230 is associated with a product record 232 in the data records 200. As shown in Figure 2, each product record 232 includes a product description 234 (e.g., a written description of the product for use in the UI and in the reports), a product code 236 (e.g., a quasi-unique code in the form of the product ID), a minimum (min.) value 238 of the product required at the site, a maximum (max.) value 240 of the product required at the site, an estimated usage rate 242 of the product at the site (either generated based on input from the client component 118 and/or automatically determined by the management component 120), a rechargeable indicator 244 indicating whether the product is rechargeable, a one-off indicator 246 indicating if the product is required only once for the site, a stock on-hand value 248 indicating the number of the stock on hand (e.g., based on user input data following a stocktake, or automatically generated/updated/maintained by the ordering component 128 when orders are placed, thus retaining a record of the expected current stock level), and a last stocktake value 250 indicating the number of stock on hand at the last stocktake. The usage rate 242 can be based on a selected period, e.g., the daily usage rate. [54] To generate and maintain the orders data, and to generate data representing the reports, the distribution system 100 performs a stock management process 3 OA which includes data communication between the ordering system 102, the shipping and invoicing system 104 and the client system 106, as shown in Figure 3A. [55] The stock management process 300A starts, as shown in Figure 3A, by the client component 118 connecting to the server component 116 via the network 108, requesting access to the ordering system 102 and requesting authentication of the user operating the client component 118 (step 302). The ordering system 102 receives an authentication request from the H:\spn\lnterwoven\NRPoribl\DCC\SPM\5002158_I.doc-19/03/2013 - 10 client system 106, and performs an authentication process (step 304) using customer details accessed in the accounts data in the shipping invoicing system 104 (step 306). The authentication processing step 304 can be based on username data and password data entered through the client component 118 in step 302. In the authentication process of step 304, the user details submitted from the client component 118 are used to determine a level of access for the user. Different access levels allow for different data to be entered in the site record 214 and products records 232 for each site. For example, an area manager access level allows viewing of the site record 214 and editing of product amounts in the product record 232, but not access to the budget 226 for the site record 214; an admin. manager access level allows viewing of the budget 226 but not editing of the budget 226. A senior management access level allows editing of all of the site records 214; and an administrator access level allows an administrator (e.g., a computer system administrator, or sys. admin.) operating the distribution system 100, and specifically the ordering system 102 and the shipping and invoicing system 104, to edit the site records 214 and product records 232 as necessary for administration of the distribution system 100. [56] Following authentication in step 304, the management component 120 accesses the site records 214 in the orders data storage 122, and selects the site records 214 corresponding to the authenticated user: e.g, the authenticated user may be identified using an area manager ID corresponding to the area manager ID 218 in one or more site records 214. Details of the selected sites are sent to the client component 118 (step 308). The client component 118 receives the sent site details and generates a site list 400A (e.g., as shown in Figure 4A) for the user (step 310). [57] Using the site list 400A in the user interface (UI) generated by the client component 118, the user selects one of the sites, and the client component 118 displays data from the site record 214 in a site requirements UI 400B, e.g., as shown in Figure 4B, representing data in the site record 214 (step 312) based on data in the site record 214 of the selected site accessed in the orders data by the management component 120 (step 314). Using the site requirements UI 400B, a user can edit portions of the site record 214 (e.g., by amending the delivery frequency 224, the budget 226 and/or the next delivery date 221, which can be the initial despatch date), depending on the authenticated access level of the user (step 316). Any changes to the site record 214 are sent from the client component 118 to the management component 120 which amends the site record 214 in the orders data (step 318). The management component 120 controls access to and editing of data in the site record 214 in step 316 based on the determined authenticated access levels. For example, the area manager level may be unable to view the budget 226, the admin.

H:\spm\Intenvoven\NRPortbl\DCC\SPM\500215_ I.doc-19/03/2013 - 11 manager may be able to view but not edit the budget 226, and the senior manager may be able to view and edit the budget 226. [58] In the stock management process 300A the users (including the user and an approval manager) can access, edit and approve data in the product record 232 for the selected site using a managed stock list UI 400C, e.g., as shown in Figure 4C (step 320). To access and edit the data in the selected site record 214, the client component 118 receives and sends data from/to the management component 120 which accesses the site record 214 and stores data edits from the client component 118 in the site record 214 (step 322). In step 322, the management component 120 can determine, using edit rules or criteria in the management component 120 and/or the orders data, whether approval is required based on the access level of the user and generates data for an approval alert. The management component 120 can determine whether any budgetary alert is required based on the edits to the site record 214 and the edit rules, and generate data for a budget alert in the orders data if required (step 324). The management component 120, or alternatively the alerting component 130, generates and sends alerts to the designated admin. manager and/or senior manager in the corresponding customer record 202 for the site based on contact details accessed in the accounts data. The management component 120 is configured to receive approval data from the designated admin. manager and/or senior manager to approve the editing of the product details in step 320. If this approval process is performed by the management component 120, there can be a substantial delay in step 320, and it may be necessary for the users to log out and log in again (using the authentication step 302). [59] In the product record editing process of step 320, the client component 118 can access and edit the products list 230 for the site by adding or removing products, the min. value 238, max. value 240 and estimated usage rate 242 of each product, as well as the rechargeable indicator 244, and one-off indicator 246, e.g., as shown in the example stock list UI of 400C of Figure 4C. [60] During the editing and approval process of step 322, the management component 120 uses validation rules to validate the data from the client component 118. The rules include: (i) determining that the maximum stock level (max. val.) minus the minimum stock level (min. val.) is greater than (or equal to) the usage rate (e.g., usage per day) multiplied by the delivery frequency (i.e., max. val. >= usage rate * delivery frequency + min. val.); and (ii) determining that the maximum stock level is a multiple of 1, i.e., not a fraction or decimal. These validation H:spm\Intenvocn\NRPortb\DCC\SPM\5002158_ .doc-19/03/2013 - 12 rules can be used to automatically re-calculate valid values, and/or to require corrected input in the example stock list UI 400C. [61] When editing the site record 214 and the plurality of product records 232, the user can request an estimate of the next delivery date (step 326), and this can be generated by the management component 120 based on the next delivery date 221 and the delivery frequency 224 of the site record 214 (step 328). [62] Following editing and approval of the site record 214 and the product records 232, the ordering system 102 can generate alerts and orders using the scheduled task components 125 accessing the orders data, e.g., as described below in the order generation process 300B. [63] In the stock management process 300A, the client component 118 can be used to input stocktake product levels and dates when stocktakes have occurred (step 330), and the management component 120 can receive the stocktake data through the server component 116, and store the stocktake data in the orders data (step 332). In the stocktaking input process of step 330, the client component 118 can generate a stocktake UI, e.g., as shown in Figure 4D, which receives data for the last stocktake value 250 in the product record 232 for each product in the site, and the last stocktake date in the stocktake timing details 222 for the site. [64] The stocktake storage step 332 includes updating the usage rate 242 of products represented in the stocktake data. The usage rate 242 of a particular stock item is updated using a relationship between the stock on hand at date of last stocktake (in stock on-hand value 248), the stock supplied to the site since last stocktake (determined from the stored orders data), the stock on hand (in the received stocktake data) at the date of the new stocktake, and the time between the new stocktake (in the received stocktake data and stored in the stocktake timing details 222) and last stocktake (in the stocktake timing details 222). The relationship can be: new usage rate = ("stock on hand at date of last stocktake" + "stock supplied to the site since last stocktake" - "stock on hand at date of new stocktake") / time between new stocktake and last stocktake. [65] The stocktake storage step 332 can include updating the min. and max. values 238,240 after the stocktake based on relationships between the min. and max. values 238,240, the new usage rate 242 and the delivery frequency 224. This can reduce the risk of running out of product at a site when the usage level has changed. If a multiple of the new usage rate 242, (e.g, multiplied by two or a selected multiple greater than 1, e.g., between 1 and 3), determined in step H:\spm\Intenvoven\NRPorob1\DCC\SPM\5002158_ .doc-19/03/2013 - 13 332 as described above, is greater than the min. value 238, then the new min. value 238 is set to a new level which can be based on the multiple and optionally the delivery frequency 224 (e.g., increased to twice the new usage rate 242). The max. value 240 can be updated based on the new usage rate 242, the delivery frequency 224 and the min. value 238 (which can be the new min. value) according to a relationship, e.g.: new max. value 240 = new usage rate 242 (e.g., per day) x duration (or period) of the delivery cycle (e.g., the number of days between deliveries, i.e., the inverse of the delivery frequency 224) + new min. value 238. [66] To generate reports in the stock management process 300A, the client component 118 can request one or more selected reports (step 334), and the management component can generate site reports (step 336) based on the orders data and spending data accessed in the shipping and invoicing system 104 (step 338). Example reports are described hereinafter with reference to Figures 4E, 4F, 4G, 4H and 41. [67] At the end of the stock management process 300A, the user logs out using the client component 118, thus ending the authenticated session (step 340). In alternatives, the distribution system 100 only performs portions of the stock management process 300A, or the steps can be performed in a different order. For example, the authentication steps 302, 304, 306 can be followed by the stock-taking steps 330 and 332 (if only a stocktake is required), or the reporting steps 334, 336, 338 (if only report generation is required), without editing or viewing the site and product details. [68] The order generation process 300B is performed according to a selected schedule by the ordering component 128. The order generation process 300A can be performed regularly, e.g., every day or every night, or every working day or every working night, or twice weekly or once weekly, etc. [69] In the order generation process 300B, the ordering component 128 accesses the next date using an internal or external clock or calendar (step 352). The ordering component 128 then accesses the site records 214 to determine which sites require delivery, e.g., based on the next delivery date 221 and the site record 214, or based on the last recorded delivery date and the delivery frequency 224 in the site record 214 (step 354). [70] The ordering component 128 then determines the quantity of each product in the products list 230 for each site that are to be delivered based on the products details, i.e., H:\spm\ntenvoen\NRPortb\DC\SPM\5002158_ Ldoc-19/03/20 13 - 14 including the min. value 238, max. value 240, and the stock on hand value 248 (step 356). If the current stock on hand value 248 is greater than or equal to the max. value 240 (e.g., because a recent stocktake has shown that there is excess stock at the site), the delivery value for that product is zero. If the on hand value 248 is less than the max. value 240, the delivery amount for each stock item is determined based on a relationship between the current stock on hand value 248 and the max. value 240, e.g.: delivery amount = max. level - current on hand amount (rounded up to the nearest whole number). Other relationships may also be used. [71] Once the order data for each site is generated in step 356, the product quantities for the ordered products are updated, i.e., the stock on hand value 248 is incremented by the order value, i.e., number of ordered products (step 358). In the update product quantities step 358, any product records 232 with a one-off indicator 246 set to positive (indicating that the order is a once off), are removed from the products list 230, or are at least deactivated in the products list 230, so that the product is not ordered again automatically. [72] Once the order data is generated, the ordering component 128 sends the order data for each site to the shipping and invoicing system 104. The shipping components 110 generate a shipping manifest for each order (step 360). The billing components 112 generate an invoice for each order (step 362). The shipping and invoicing system 104 also updates the spend for each site in the accounts data for that customer (step 364). [73] The alerting component 130 monitors the spend data for each site in the accounts data, and compares it to the budget 226 for each site in each site record 214, and generates alerting data if the spend approaches the budget 226 or if it equals or exceeds the budget 226, or a selected threshold associated with the budget (e.g., a fraction of the budget or a multiple of the budget, such as 50% of the budget, 75%, 80%, 90%, 100%, 110%, 120%, 150%, 200%, etc.). The threshold can be selected by the system administrator, or one of the selected managers. The budget alerts can be messages to a selected manager for the customer, e.g., the admin. manager or the senior manager in the customer record 202, and the alerts can be sent as emails or text messages, etc. Example Client Component (UI) [74] As shown in Figure 4A, the example site list 400A can include a list of site identifiers 402 (e.g., site names) for the sites of the customer. Each site is shown including a site name and address 404 accessed from the accounts data (or optionally from the site record 214), an user H:\spm\lntenvoven\NRPortbl\DCC\SPM\5002158_ Ldoc-19/03/2013 - 15 identifier 406 (e.g., a name) corresponding to the area manager ID 218 for each site record 214, a stock-list indication 408 as to whether a products list 230 (which can be referred to as a "managed stock list", or "MSL") exists for that site, a site status 410 (e.g., "normal", "pending" or "suspended"), and an edit control 412 selected by the user to edit the products list 230 for each site with a site record 214. The site status 410 can represent whether approval is required in the order approval steps 320,322 (e.g., status "pending"), or it can represent that no orders can be made (e.g., status "suspended"). The "suspended" status can be selected by the user to stop / suspend generation of the orders, e.g., if a site closed down temporarily or permanently. The site list 400A can include a new site list control 414 for generating a new site record and products list for an existing site. [75] The example site requirements UI 400B, as shown in Figure 4B, include a site description control 422 for identifying or selecting a site record 214, a frequency control 424 for viewing and selecting the delivery frequency 224, a budget control 426 for viewing and selecting the budget 226 (e.g., a quarterly budget), which may be available depending on the authenticated access level, and an initial despatch control 428, for reviewing and/or amending the next delivery date 221. [76] An example stock list UI 400C, as shown in Figure 4C, accesses the data from the product records 232 in the products list 230, and provides controls for the user to edit selected ones of the data values in each product record 232 for each product. The stock list UI 400C displays the product code 236 and the description 234 in a code and description indicator 432. The stock list UI 400C provides a new-product control 434 which generates a new product record 232 in the products list 230. For each product record 232 in the stock list UI 400C there is: a one-off control 436 to edit the one-off indicator 246; a min. level control 440 to access and edit the min. value 238; a max. level control 442 to view/edit the max. value 240; a usage rate control 444 to access/edit the usage rate 242 (per a pre-selected delivery period); a recharge control 446 to access /edit the rechargeable indicator 244; and a delete control 448 to delete a selected one product from the products list 230. The values in the product record 232 are updated based on input from the client component 118 and the validation rules of the management component 120 used in step 322. [77] The example stocktake UI 400D, as shown in Figure 4D, includes: a site selector control 452 to select and access one of the sites from the sites list 212 for the authenticated user; H:\spn\Intenvoven\NRPortb\DCC\SPM\5002158 _.doc-19/03/2013 - 16 a stocktake skip control 454 to skip the current stocktake, and thus retain the existing stock on hand value 248 for the product records 232 in the selected site; a stocktake date control 456 to access and submit data representing the date of the stocktake; a product list 458 displaying the product codes 236 and descriptions 234 of the products in the products list 230 for the site; a stocktake value control 460 for receiving values/numbers of items in the products list 458, and a data entry control 462 for submitting the values in the values control 460 to the management component 120 which then performs the stock-taking process (in step 332) to amend the stock on hand values 248 of the products for each value to be entered in the values control 460. In the stock-taking process the management component 120 then updates the orders data to automatically determine a new usage rate 242 of each product record 232 for which the stock on hand value 248 has been updated, e.g., using the relationships described above in step 332. [78] An example rechargeables report 400E, as shown in Figure 4E, can include a list of rechargeable items for each site in the sites list 212, listed using the site details associated with the site ID 216 and the costs of the rechargeable items, i.e., each item with a positive rechargeable indicator 244 in the product record 232 for its site record 214 of the authenticated user. [79] The unit price for each item is represented by unit price data stored in pricing details 252 of the customer record 202. The pricing details 252 are selected by the administrator or the ordering system 102 based on set prices, supplier prices, or negotiations with the corresponding customer. The pricing details 252 include the current item prices for that customer. The transaction details for each customer are represented by transaction data stored in a transaction details field 254 of the customer record 202. The transaction details 254 include all relevant transactions for that customer, including the orders placed, prices, quantities, dates, etc. The pricing details 252 and the transaction details 254 can be data fields, data tables, and/or references to related tables / records of the relevant data. [80] An example expenditure report 400F, as shown in Figure 4F, can show the budget 226 for each site in comparison with the spend for each site accessed in the accounts data. The budget and spend for each site can be determined by the management component 120 when generating the expenditure report based on a selected period, e.g., quarterly, annually, by financial year, etc. The spend for each site is represented in the transaction details 254 which is accessed by the management component 120 when generating the expenditure report 400F.

H:\spn\Interw oven\NRPortbl\DCC\SPM\5002158 Ldoc-19/03/2013 - 17 [81] An example budget comparison report 400G, as shown in Figure 4G, can include an indication of each site record 214 associated with the authenticated user, e.g., based on the area manager ID 218 of the site record 214, and an indication as to whether the site is currently over budget or under budget based on the budget 226 for the site and the spending data and accounts data. The budget comparison report 400G can be used for an authenticated area manager who does not have access to the exact budget 226 for the site. [82] An example on-hand report 400H, as shown in Figure 4H, can include lists of products for each site associated with the authenticated user and the corresponding stock on hand values 248 for the products, optionally with an on-hand value determined based on the stock on hand value 248 and the price of each stock item accessed in the pricing details 252. [83] An example usage report 4001 can include a list of sites and corresponding products for the authenticated user showing the usage rates 242 of each product, and an estimated cost of the usage rate determined by the management component 120 multiplying the usage rate 242 by the price of the product accessed in the pricing details 252. Example Ordering System [84] In an example implementation, the ordering system 102 can include a commercially available computer server, e.g., a ASUS Z8PE-D12 server with a quad core XEONX556 processor, 12GB of memory, and a Hitachi terabyte hard-drive. The operating system can be a Windows operating system, and the various components described herein can be implemented using SQL server 2008 modules, and the orders data storage 122 can be an SQL database. An example ordering system 500 can include a standard computer based on a 32-bit or a 64-bit Intel architecture and the processes and methods performed by the example ordering system 500, including the stock management process 300A and the order generation process 300B, are implemented in the form of computer-readable programming instructions of the one or more software components or modules, which together with the components of the ordering system 102, form computer-readable modules stored in non-volatile (e.g., hard-disk) computer-readable storage 504 of the example ordering system 500, as shown in Figure 5. [85] The system 500 includes at least one or more of the following standard, commercially available, computer components, all interconnected by a bus 516: random access memory (RAM) 506, at least one computer processor 508 (e.g., microprocessors), and external computer interfaces. The external computer interfaces include: universal serial bus (USB) interfaces 510 H:\spm\ntenvoven\NRPorlbl\DCC\SPM\500258_ Ldoc-1910312013 - 18 (at least one of which is connected to one or more user-interface devices, such as a keyboard, and a pointing device, e.g., a mouse 518 or touchpad); a network interface connector (NIC) 512 which connects the system 500 to data communications networks, and thus to an example of the shipping and invoicing system 104 and the network 108; and a display adapter 514, which is connected to a display device 522 such as a liquid-crystal display (LCD) panel device. [86] The system 500 includes a plurality of standard software modules, including: the operating system (OS) 524 (e.g., Linux or Microsoft Windows); web server software 526 (e.g., Apache, available at http://www.apache.org); scripting language modules 528 (e.g., personal home page or PHP, available at http://www.php.net, or Microsoft ASP) for serving an example of the client component 118; and the structured query language (SQL) modules 530. The example SQL database 532 includes examples of the data records 200 stored in non-transitory computer-readable data records. [87] Together, the web server 526, scripting language 528, and SQL modules 530 provide the system 500 with the general ability to allow examples of the client system 106 on the internet 520 with standard computing devices equipped with standard web browser software to access the system 500 and in particular to provide data to and receive data from the database 532 via the server and client components. The specific functionality of the system 500 is provided by the web server 526, the modules 502, and other scripts and supporting data 534, including markup language (e.g., HTML, XML) scripts, PHP (or ASP), and/or CGI scripts, image files, style sheets, etc. [88] The boundaries between the modules and components in the modules 502 are exemplary, and alternative embodiments may merge modules or impose an alternative decomposition of functionality of modules. For example, the modules discussed herein may be decomposed into submodules to be executed as multiple computer processes, and, optionally, on multiple computers. Moreover, alternative embodiments may combine multiple instances of a particular module or submodule. Furthermore, the operations of the modules may be combined or the functionality of the operations may be distributed in additional operations. Alternatively, the modules may be embodied in the structure of circuitry that implements such functionality, such as the micro-code of a complex instruction set computer (CISC), firmware programmed into programmable or erasable/programmable devices, the configuration of a field- H:\spm\1ntenvovcn\NRPortbl\DCC\SPM\502 _ I.doc-19103/2013 - 19 programmable gate array (FPGA), the design of a gate array or full-custom application-specific integrated circuit (ASIC), or the like. [89] Each of the blocks of the flow diagrams of the processes of the system 500 may be executed by a module (of software modules 502) or a portion of a module. The processes may be embodied in a machine-readable and/or computer-readable medium for configuring a computer system to execute the method. The software modules may be stored within and/or transmitted to a computer system memory to configure the computer system to perform the functions of the module. Interpretation [90] Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention. [91] The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that the prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates.

H:\spn\Interwovcn\NRPortbl\DCC\SPM\5002158_.doc- 19/03/2013 - 20 REFERENCE SIGNS LIST 221 next delivery date Reference Term 222 stocktake timing details 100 distribution system 224 delivery frequency 102 ordering system 226 budget 104 shipping and invoicing system 228 approval indicator 106 client system 230 products list 108 network 232 product record 110 shipping components 234 product description 112 billing components 236 product code 114 accounts data storage 238 minimum (min.) value 116 server component 240 maximum (max.) value 118 client component 242 usage rate 120 management component 244 rechargeable indicator 122 orders data storage 246 one-off indicator 124 accounts component 248 stock on hand value 125 scheduled task components 250 last stock-take value 126 UI and reporting component 252 pricing details 128 ordering component 254 transaction details 130 alerting component 402 site identifiers 200 data records 404 site name and address 202 customer record 406 user identifier 204 customer identifier (ID) 408 stock-list indication 206 invoicing details 410 approval status 208 senior management ID 412 edit control 210 administration (admin) manager 414 new site list control ID 422 site description control 212 sites list 424 frequency control 214 site record 426 budget control 216 site ID 428 initial despatch control 218 area manager ID 432 code and description indicator 220 shipping details 434 new-product control H:\spmi\!ntcnovcn\NRPortb\DCC\SPM\5002158_ L.doc-19/03/2013 -21 436 one-off control 440 min. level control 442 max. level control 444 usage rate control 446 recharge control 448 delete control 452 site selector control 454 stock-take skip control 456 stock-take date control 458 product list 460 stock-take value control 462 data entry control 500 example ordering system 502 one or more software components or modules 506 random access memory (RAM) 510 interfaces 512 network interface connector (NIC) 514 display adapter 516 bus 518 UI devices 524 operating system (OS) 526 web server 528 scripting language 530 structured query language (SQL) modules 532 SQL database 534 other scripts and supporting data

Claims (17)

1. A system for stock management for at least one customer who uses stock including: a management component for an ordering system configured to: receive stock requirements data representing required stock levels of a plurality of products at a plurality of sites serviced by the customer, and receive delivery frequency data representing delivery frequencies for the sites; and an ordering component for the ordering system configured to: access customer account data representing invoicing details for the customer, generate order data, representing an order for each site, based on the required stock levels and the delivery frequencies of the sites, and generate invoice data representing an invoice for each order based on each order and the invoicing details in the customer account data.

2. The system of claim 1, wherein the management component is configured to determine a usage rate for at least one of the plurality of products based on received stocktake data representing on-hand numbers of the products at one or more stocktake times.

3. The system of claim 2, wherein the order data represents a number of each product in the order which is determined based on the determined usage rate, the on-hand value of the product at the site, and the delivery frequency.

4. The system of any preceding claim, wherein the management component is configured to determine if a product is a one-off order based on a user selection, and to remove the one-off order product from the required stock levels after the order has been generated.

5. The system of any preceding claim, wherein the management component is configured to store transaction data representing the orders, and to generate reports representing usage data for each site based on the transaction data, including stock on-hand values generated by the management component based on the usage rate, the order amounts and the delivery dates/times of the products.

6. The system of any preceding claim, wherein the management component is configured to generate a report including selected transaction data relating to products identified as rechargeable products using a rechargeable indicator in the product data. H:\spn\Intenmoven\NRPortbl\DCC\SPM\5002158 I.doc-19/03/2013 - 23

7. The system of any preceding claim, wherein the management component is configured to: generate alert data representing an approval alert based on the received stock requirements data and/or delivery frequency data; and receive approval data representing approval of the received stock levels and/or delivery frequencies.

8. The system of any preceding claim, wherein the management component is configured to: access budget data representing current budgets for the sites; access pricing data representing pricing details of the products; determine site spends based on the pricing details of the products in the orders; and generate alert data representing at least one budget alert if one of the site spends is above a selected threshold associated with a corresponding one of the site budgets.

9. A process for stock management for at least one customer who uses stock including the steps of: receiving stock requirements data representing required stock levels of a plurality of products at a plurality of sites serviced by the customer; receiving delivery frequency data representing delivery frequencies for the sites; accessing customer account data representing invoicing details for the customer; generating order data, representing an order for each site, based on the required stock levels and the delivery frequencies of the sites, and generating invoice data representing an invoice for each order based on each order and the invoicing details in the customer account data.

10. The process of claim 9, including the step of determining a usage rate for at least one of the plurality of products based on received stocktake data representing on-hand numbers of the products at one or more stocktake times.

11. The process of claim 10, wherein the order data represents a number of each product in the order which is determined based on the determined usage rate, the on-hand value of the product at the site, and the delivery frequency.

12. The process of any one of claims 9-11, including the steps of: determining if a product is a one-off order based on a user selection; and H:\spnIntcnoven\NRPortbl\DCC\SPM\5002158_ I.doc-19/03/2013 - 24 removing the one-off order product from the required stock levels after the order has been generated.

13. The process of any one of claims 9-12, including the steps of: storing transaction data representing the orders; and generating reports representing usage data for each site based on the transaction data, including stock on-hand values generated based on the usage rate, the order amounts and the delivery dates/times of the products.

14. The process of any one of claims 9-13, including the step of generating a report including selected transaction data relating to products identified as rechargeable products using a rechargeable indicator in the product data.

15. The process of any one of claims 9-14, including the steps of: generating alert data representing an approval alert based on the received stock requirements data and/or delivery frequency data; and receiving approval data representing approval of the received stock levels and/or delivery frequencies.

16. The process of any one of claims 9-14, including the steps of: accessing budget data representing current budgets for the sites; accessing pricing data representing pricing details of the products; determining site spends based on the pricing details of the products in the orders; and generating alert data representing at least one budget alert if one of the site spends is above a selected threshold associated with a corresponding one of the site budgets.

17. Computer-readable media storing computer-readable instructions configured to control one or more computer processors to perform the process of any one of claims 9 to 16.