GB2404049A - Stock ordering and reconciliation system - Google Patents

Abstract

A stock ordering and reconciliation system having a central server 105 and a plurality of remote servers (110a,110b,110c,110d), the central server 105 including: a first data store 115, which stores a catalogue of commodities, and a second data store 125, which stores order details for all remote servers; the remote servers each have a first data store (130a, 130b,130c,130d) which stores a catalogue of commodities and a second data store (135a, 135b,135c,135d) for storing order details specific to that remote server, wherein at each remote server only commodities which can be ordered there are accessible, and the first data store at each remote server is updated by transfer of data from the first data store of the central server. In one embodiment the central server has a third data store 120 which contains details on which parts of the first data store 115 of the central server should be transferred to each remote servers, alternatively a filter is used at each remote server to restrict access. Preferably there is a filter at each remote server which also presents only the cheapest possibly supplier of each item.

Description

1 2404049 Title A stock ordering and reconciliation system

Field of the Invention

The present invention relates to a stock ordering and reconciliation system and specifically to a system adapted to enable two or more remote sites or users to avail of the type of ordering typically achievable using larger corporate entities, yet personalized to the specific profiles of each of the remote sites. This invention is specifically directed towards the technical problem of controlling data flow between remote servers within a network configuration so as to enable the creation of a networked infrastructure.

Background to the Invention

It is well known in the art to provide computer implemented stock ordering and reconciliation systems. Typically, a user (a retailer or distributor) interfaces with a database of available products provided by a manufacturer or wholesaler and by selecting one or more of the products can then generate an order that is dispatched to that user. On receiving the requested goods or services, the user can then reconcile the invoice provided with the delivery docket with the requested goods, and then effect payment for the specific delivered goods.

It is also well known that the prices or terms provided by retailers differ according to the nature or definition of the user or customer requesting the goods. Such differences can arise from a number of circumstances, such as for example, the volume of goods ordered by the user, the delivery time requested and the location of the warehouse from which the goods are dispatched vis a vis the location of the customer. It is further known that users may be offered at different times special offers or conditions to those available normally. In such circumstances it is often difficult- especially if there is a delay between the order and delivery to confirm that the price that the goods were ordered at equates to the price on the delivery docket.

It will be further appreciated that in most circumstances, the best offers or conditions that are available are provided to users that regularly purchase a large number of products and therefore can avail of a preferential rate from the supplier. Within the art, this has been utilised by a number of un-connected or independent customers to block order their specific requested goods and thereby artificially inflate the size of the order so as to avail of discounts. In such circumstances the retailer typically requires the order to be delivered to a single location, which is often a central depot from which they can be distributed as required. This is a complex arrangement requiring a dual delivery system.

Technically, it is also difficult to implement as there is a need to accurately correlate the orders made by each of the disparate users within the group with the deliveries so as to effect delivery and also so as to determine which user is responsible for which portion of the invoice. Furthermore, in computer implemented systems it is difficult in a single package to ensure that each user is not presented with information that is redundant to that user- for example where they are presented with the opportunity to order goods or services from suppliers that have policies of not delivering to that user. Over a small number of entities this problem can be obviated by manually tailoring each of the available user interfaces to the specific user, but this is difficult to implement where the number of user interfacing with the system increases and furthermore where there is a requirement to regularly update the system to reflect changes in prices or structures.

There is a further difficulty where the multiple users all belong to a central group- for example in circumstances where two or more regional offices or outlets each want to be able to order goods, yet the final payment is effected through a central or regional office. In such circumstances, where the ordering and the reconciliation are effected by different parties, it is technically difficult to ensure that the payment that is effected corresponds to the terms and conditions of the goods ordered, and also of the goods delivered.

There is therefore a need to overcome the technical limitations of existing stock ordering and reconciliation systems.

Summary Of The Invention

Accordingly, the present invention provides a system that provides a networked architecture comprising a central server adapted to interface with one or more remote servers which are in turn adapted to interface with users locally at the server locations, and wherein each of the remote servers are configured to provide functionality specific to users interfacing with that server at that location, the combination of the remote and central servers providing a complete stock ordering and reconciliation system In a first embodiment, the system provides a networked architecture comprising a central server and a plurality of remote servers; the central server including: a first data store of commodities that may be ordered through the system, the commodities being associated with specific terms and conditions, each of the commodities and their associated terms and conditions being editable by a user interfacing with the system, a second data store including details of each of the remote servers, the details including a rule structure that is configured to define specific commodities that may be ordered by each of the remote servers, a third data store including information specific to each of the remote servers concerning commodities ordered and received by each of the servers, the third data store providing a record of all commodities ordered and received by each of the remote servers, including the terms and conditions at which they were ordered and at which they were delivered, and wherein each of the remote servers includes: a first data store of commodities that may be ordered locally through that server, the first data store at each of the remote servers being a sub-set of the first data store of the central server, and a second data store including order information relating to specific commodities that were ordered locally through that remote server, the terms and conditions on which the order was made, and details of the commodities that were delivered in fulfillment of the order including the terms and conditions associated with the delivery of same, and wherein the first and second data stores of the central server are updated locally by a user at that central server, the first data store of each of the remote servers is updated at regular intervals by the distribution of information to each of the remote servers by the central server in accordance with the rules defined for each of the remote servers in the second data store of the central server, the second data store of each of the remote servers is updated locally by users at each of the remote servers, and the third data store of the central server is updated by the returning of information from each of the second data stores of the remote servers to the central server.

Desirably, the first data stores of each of the remote servers include a mirror of the complete list of commodities that are stored on the first data store of the central server, the first data stores of each of the remote servers further including a filter, specific to each of the remote servers, which is adapted to restrict access to the complete list, to those items within the list that can be ordered from that remote server.

The architecture is preferably further adapted to enable communication between individual remote servers, so as to provide for the transfer of commodities between individual remote servers.

The invention further provides a method of providing a networked stock ordering and reconciliation procedure over a distributed network comprising the following steps: a) providing a central server having an inventory of available commodities that can be obtained through the system, the inventory being a product of a number of different suppliers, each of which are associated with specific parameters defining their behaviour, b) providing one or more remote servers, distant from the central server, and adapted to be in electronic communication with the central server, c) enabling the transfer of an inventory from the central server to each of the remote servers, d) restricting the access by a user at a remote server to items within the inventory that may be ordered by that user for delivery to the location of that remote server, e) maintaining a record of items ordered and received at the remote server and communicating said information to the central server so as to provide a reconciliation between items ordered and received at each of the remote servers, and wherein the items that may be ordered at each of the remote servers are filtered such that a user at a remote server is presented only with the possibility to order items having the lowest possible price for items associated with the location of that server.

These and other features of the present invention will be better understood with reference to the following drawings.

Brief Description Of The Drawings

Figure 1 is a schematic of a networked architecture according to the present invention, Figure 2 is a screenshot showing a products table according to an exemplary embodiment of the present invention, Figure 3 is a flow sequence outlining an example of an update arrangement that is implemented according to the present invention, Figure 4 is a screenshot showing an example of a file that is sent from the central server to a remote server and which is used to populate the fields of the first data store of the remote server, Figure 5 is a screen shot of a graphical user interface that may be provided to a user on placing an order at a remote server, Figure 6 shows an example of a screen that is presented to a user, requesting the user to enter the name of the person placing the order, Figure 7 shows a screen shot of completed yet unfilled purchase requests which are maintained at the remote server, Figure 8 is an example of a screen that is presented to user prompting the update of a purchase request on delivery of the order, Figure 9 is an example of a screen that will be presented to a user to enable him to return certain goods to the supplier, Figure 10 shows a locked delivery docket, and Figure 11 is an example of a returned file from the second data store of a remote server to populate the third data store of the central server.

Detailed Description Of The Drawings

Figure 1 is a schematic of a network architecture 100 according to the present invention. The network includes a central server 105 adapted to be in network communication with one or more remote servers 1 1 Oa, 11 Ob, 11 Oc, 1 1 Od. The central server is provided with a first 115, 120, 125 data stores respectively.

Each of the data stores will be described in more detail below. Each of the remote servers includes first 130 and second 135 data stores.

Using the stock ordering and reconciliation system of the present invention, it is possible for a disparate group of related entities to act as a single unit thereby ensuring that the goods that are ordered are done on a set or parameters ensuring that the cheapest price for products based on parameters such as a long term agreement (LTA's) settlement discounts and quantity discounts at each of the remote sites is achieved. The architecture is set up such that each remote site or cost centre is provided with a remote server, the remote server being adapted to interface with a central server maintained at a group headquarters. It also ensures the price that is agreed with the suppliers is the price that is paid and is the same for all our cost centres.

This system of the present invention enables managers to exercise far more control over stock purchasing for their cost centre. It provides managers with accurate up to date information of stock prices to help them in negotiating prices for the group. It is also beneficial in that it enables the provision of accurate order records that may be standardised across the group. Furthermore, it may be adapted to provide an audit trail for stock taking purposes, linking deliveries, to who took the stock in and who entered it on the system and who placed the order. By interfacing the ordering and reconciliation system with an accounts or billing package, the system of the present invention may be extended to make sure that what was delivered was what originally invoiced for and to effect an automatic update of the accounting package.

In a further embodiment, the system may be configured to keep track of the amount of returnable bottles or other goods that may be taken into each of the cost centres and which are normally returned to the wholesaler or other distributor at a later date.

It will be appreciated, therefore, that the system of the invention requires an efficient interface between the entities that are not colocated. As a large amount of data is required to effect a large ordering system, it is necessary to ensure that this data is structured or organised efficiently so as to achieve data transfer between servers is effected in an efficient manner, that the amount of up-time on the communications network between the individual sites is reduced and yet ensures that the correct and most up-to- date data is always available at each of the sites.

As detailed above, the central server may be considered as having a first, second and third data store. Each of the data stores are adapted to include specific information, and therefore it will be appreciated that although they are shown as distinct entities in Figure 1, that in accordance with standard implementations that the functionality of the individual data stores may be provided by a single or shared data structure. It will be further understood that individual data stores may be subdivided into specific sub-data stores or tables, depending on the organization that is required for a specific implementation.

The first data store 115 is typically adapted to include information on the commodities that may be ordered by any entity connected to the networked architecture. By the term "commodity" within the present specification will be understood any product or service that is typically provided by a manufacturer or wholesaler to retailers or distributors. The list of commodities that may be stored within the first data store of the central server is a comprehensive listing of all possible products that may be provided through the stock ordering system of the invention, together with specific terms and conditions. In accordance with well known principles each of the individual items within the first data store may be separately searched and updated by a user interfacing with the system.

The second data store 120 includes details on each of the remote servers, including such administrative details as their location, contact persons, contact details and also more specific details such as which product supplier may be used to supply that location. Such individualization of the type or source of product that may be ordered by and delivered to that venue is typically achieved using a rules structure that may be configured to define specific commodities that may be ordered by each of the remote servers.

The functionality of the first and second data stores may be combined by effecting the generation of mirrored copies of the first data stores of each of the remote servers locally at the central server. Each of these mirrored data stores will include sub-sets of the data that is stored in the first data store of the central server, the sub-set being defined by the rules associated with that remote server and stored in the second data store of the central server.

The third data store 125 is adapted to include information specific to each of the, remote servers concerning commodities ordered and received by each of the l servers. The functionality of the third data store provides a record of all commodities ordered and received by each of the remote servers, including the terms and conditions at which they were ordered and on which they were delivered.

A typical implementation of the data stores provided at the central server will now be described with reference to an implementation of the stock ordering system within a retail drinks group. As shown in Figure 2, a products table - which may be considered a component of the first data store 115, includes a number of editable data-fields including Name, Size, Buy units, Sell Unit, Number of Sell Units in Buy Unit, VAT Code, N.L. Code etc. A further component of the first data store is a prices table, where each record relates to a single product price from a supplier. The following examples are typical fields that are editable in such a prices table: Current List Price and Effective to Date Future List Price and Effective to Date Supplier ID and Supplier Product Reference All Discountsfrom this Supplier Any deals e.g. 1 Free with 10 Buy Price - This is a calculated field based on all the above. It is this field which is sorted on when it comes to determining which is the best Buy/Supplier.

This table, it will be appreciated, may be scaled in size to cope with increases in I number of prices, products and suppliers. The records in this table are either edited in the case of an existing supplier price change or a new one added in the event of a new supplier entering the market. This can be updated by manual input or alternatively can be updated using a query linking on a supplier price reference.

Using the prices table component of the first data store, it is possible to evaluate a "best price" for each product which may be ordered at each of the remote servers on a regular time-frame. Figure 3 shows in schematic form a flow sequence that may be effected at the central server to ascertain whether specific ones of the remotes servers need to be updated with a new pricing schedule. This query routine may be provided individually for each of the remote servers or may be implemented globally for all servers within the architecture. Furthermore, queries may be run automatically, for example at specific time intervals or can be initiated manually. In Step 300 a specific query is initiated to start the process run. The date of the query is then checked against an internal parameter to ascertain the time interval between when the last query was run and this query. Using the example of the evaluation of a new lowest price arrangement for a specific remote server, if there is a difference between the date at which the remote server in question was last updated and the current date, then a copy of the last dispatched price information data store for that remote server is copied and re- named Old lowest prices. The query then runs a procedure to check for any expiring/activating prices or deals. This procedure typically involves interrogation of specific components of the first data store of the central server such as for example the PRICES TABLE using the DEALS TABLE to identify which deal within the prices table are activating/expiring. Each price in the Old lowest vices table is then checked against a corresponding current price for commodities that may be provided to that remote site, and the lowest buy price record available for each product is then written to a table called Lowest Prices. (Step 305) A copy of this Table is saved under the pertinent branch or remote server name for comparison purposes (Step 310). If there is a difference between this (which is re-named Old Lowest Prices) and Lowest Prices (the most up to date prices selection for this branch) - the specific remote server, which has the same table (OLD LOWEST PRICES - named LOWEST PRICES on that remote server), is flagged to receive an update (Step 320). The update may be sent in a number of manners, for example a triggered e-mail may be sent containing a database file. Upon receipt of this e-mail at the remote server branch the operator double clicks the attachment, which automatically installs the update in a predetermined location. In an alternative embodiment, this update may be streamed automatically to the remote server where it is uploaded and replaces the equivalent locally stored file automatically.

It will be understood that this file is self-consistent, i.e. that all information that is required for a user at the remote server to complete an order is included in this file and as such it contains all information relating to prices, suppliers account information, VAT etc. An example of such the contents of such a file are shown in Figure 4, which shows tables and their relationships within an exemplary prices updates file.

Using a centralised updated arrangement that is then disseminated, where appropriate, to one or more remote servers, the present invention provides and enables remote users to locally update orders using centrally implemented data.

The following examples illustrate the type of graphical interfaces that may be provided to a local user to enable them to complete an order.

Placing an order To open the purchase ordering system, the user accesses the locally installed application on their server, for example one of servers 11 Oa, 1 OOb, 11 Oc or 11 Od and by using the conventional double click arrangement that will be familiar to those using the Microsoft_ Windows_ Operating System launches the application. This launching of the application effective the generation of a graphical user interface main screen similar to that shown in Figure 5 Here on the main order screen, the system displays a list of all orders that have been placed but not yet delivered. To place a new order, the user clicks on the NEW ORDER button and is asked whether they want to place a new order. To confirm, they click "YES".

Automatically, and as shown in Figure 6, the system then prompts the user to provide the name of the person who is placing the order, before a selection of orders may be initiated. Once everything is ordered, the system is adapted to automatically choose the cheapest supplier and therefore price for these products and will generate a purchase order on the system to go to the cheapest supplier of these products. This selection of the cheapest price is determined by effecting an interrogation of the first data store 130 stored locally at the remote server, i.e. the data store that was compiled at the central server and then dispatched to the remote server. These purchase orders and can now be seen on the main screen as undelivered orders, Figure 7.

If at this stage amendment is required, the purchase order can be selected and amended as required.

On receipt of goods at remote location Once a delivery is received, the system may be interrogated so as to update the status of all orders. As shown in Figure 8, this may be achieved by identifying the purchase order associated with the delivery docket. The entry of the delivery date in a provided delivery date field effects the generation of a prompted message informing the user that the order will be permanently locked.

In this specific example, the system is adapted to enable a user to update with regard to whether any returns are being provided. In such an example, at this stage, the user is prompted to enter any empty bottles or cases that are being sent back with the delivery (Figure 9). The user is then prompted to enter the delivery docket number, and the name of the person signing in the deliver, and in a similar fashion, the name of the person who entered the details on the system. This Delivery docket is now locked with all the information that has been entered and cannot be changed (Figure 10). This information is then stored in the second data store 135 of the specific remote server and will be maintained there until it is uploaded to the central server.

Correlation of orders with central server Once a predetermined number of orders have been effected or at a specific predetermined time intervals, each of the remote servers are adapted to communicate the orders/deliveries that have been generated at their site to the central server where they may be reconciled for accounting purposes. To effect this communication of data, the present invention provides for the creation of a data file with specific information pertinent to the transaction. Figure 11 shows an example of such a data file that is transferred from the second data store 135 of each of the remote servers to the third data store 125 of the central server. On receipt at the central server, the file is uploaded or read into the third data store of the central server for reconciliation. Typical records contained in this data transmission include details from the purchase request such as the order identification, the products ordered and at what price, the quantity that was provided and any discount that was applied.

Reconciliation Process: Subsequent to the uploading process, one or more stock batches may be reconciled for accounting purposes. The reconciliation process involves a correlation between the invoiced cost from the supplier and the initially generated purchase order request. Any difference between the two can then be accounted for in accounts generated for each supplier and stored locally at the central server. Having reconciled deliveries in a batch, an export file can then be generated to be sent to an accounts package for standard accounting and payment.

It will be appreciated that the present invention provides for a sharing of information across a distributed network so as to ensure that individual components of the network are provided with the most up-todate information which is pertinent to their site. The information for distribution needs only to be compiled once, centrally at the central server, and is then distributed as appropriate to each of the remote server making up the network. Users, locally, at the remote servers then interrogate and use a locally stored system to effect the day to day use of the system. As this interaction is achieved locally there is no requirement for a constant up-link between the remote and central servers, S and as such the speed and efficiency of processing orders locally at each of the remote servers is increased. Further advantages arise in that the security aspects of the networked configuration are high. As there is no constant up-link between the individual components of the system, the risk of attack by hackers or other persons of unscrupulous nature is reduced.

On completion of orders, the details of the completed order/delivery routine is then transferred back to the central server for administrative and accounting purposes. The advantages are many; locally it appears to each user that they have a fully stand-alone, functional and tailored package: yet the data that is required to provide this across a network is entered once centrally and then distributed as appropriate. Available commodities to each user locally are specific to that location, yet the remote sites are availing of terms and conditions that are negotiated centrally, typically for a larger entity than each of the individual sites represent.

It will be appreciated that the population of the data fields within the respective first data stores of the remote servers can be effected in one of a number of different manners. For example, the data sent from the central server may be filtered for each remote server at the central server, removing any stock item that is not relevant to that specific remote server. In an alternative, preferred, embodiment, the central server sends a complete inventory of all available products to each of the remote servers. In such an embodiment, the central server also sends a remote server specific price table which will determine which items from the complete inventory may be ordered from that central server. In this specific example the user interface to the complete inventory stored in the first data store of each of the remote servers is limited to that which corresponds to the lowest price within the price table associated with the inventory.

Although described heretofore with regard to the ordering/reconciliationof stock from a third party, the system and methodology of the present invention may be adapted to enable inter-transfers between related parties. For example, two or more users at unique but related remote sites may wish to transfer goods between their respective sites. In such an example, a user at a first site may effect an order at their site. This order is marked as an inter-group order by effecting a flag or other identifier on the order. Similarly to that described previously, a copy of the order will be dispatched from the second data store of the remote server associated with the ordering party to the third data store of the central server. In addition, a reciprocal of the order will be sent to an identified other remote server. When that is received at the second remote server, they can then fulfil their order, thereby decrementing the stock table at their remote server by an amount equivalent to the order being fulfilled. Such an interface or application enables a seamless, yet controlled transfer of goods (as determined by the requirements of each of a number of related yet remote sites) between different parties within the same group.

In yet a further modification, a graphical user interface may be presented to an administrator at the central server informing him of the status of accounting batches not yet fulfilled within the third data store of that central server. This is in a similar fashion to that described above with regard to an analysis at each of the remote servers or items ordered but not yet delivered. In this specific example, the overview provides an analysis of items delivered but not yet run through an accounting procedure.

In yet a further modification the system and method of the invention may be adapted to enable a control element or feature to be incorporated so as to facilitate the differentiation between different types of commodity. For example, certain products may require a higher level of authorization to enable them to be ordered. The present invention may be adapted to enable this level of control to be introduced. One way of achieving this is association of certain products in the inventory being dispatched from the central server to the remote servers with a hidden integer or indicia. Such indicia are typically a random number that is generated and stored at the central server for that product item. When the inventory or commodity file is being dispatched from the central server to the remote servers, this generated identifier is associated as a hidden or encrypted parameter with that stock item. When a user at the remote server attempts to select that product item from the first data store of the remote server, they are prompted to enter a release indicia- which corresponds to the number or parameter associated with that product. They must effect a request for that identifier at the central server, which then provides them with the parameter which is equal to that previously sent from the central server to the remote servers. The entry of the number received from the central server is then compared against that previously stored against that product and if a match is determined then the product is marked as selectable and may be added to the purchase order. It will be appreciated that the requirement to receive the release parameter from the central server effects the generation of an audit trail which can then be used subsequently to determine which user made which order requests.

The use of such release parameters that are generated at the central server and then used to control the ordering of goods at the remote servers can also be used in other applications. One such application is where the a remote server is obliged to upload latest information that is sent to them from the central server prior to be able to create a purchase request. As the information updates are typically pushed to the remote servers, as opposed to pulled from the central server, there is a possibility that one or more users at a remote server may decide not to upload the information as regularly as it is pushed to them. This possibility can be obviated by effecting a time check on the data store that is being accessed during the purchase order creation and only enabling purchase order generation when the update of the data store is within a specific predetermined time frame, for example within the latest week or day.

If the data store update is within the time period, then the purchase order request can be generated, otherwise the user is locked out until an update is effected. To enable a user to override this update restriction, the user may be prompted, in certain embodiments, to effect an input of a random number or control code that is generated at the central server for that data store. The user will then have to contact the central server to ascertain that number and then input it to un-lock the data stores at the remote server to enable the creation of a purchase request.

What has been described herein is a preferred embodiment of a stock ordering and reconciliation system. It will be appreciated that it is not intended to limit the present invention to any one exemplary embodiment and that the present invention should not be limited in any way except as may be deemed necessary in the light of the appended claims.

Furthermore, it will be understood that the words "comprises", "comprising" etc., when used in this specification are taken to specify the presence of stated integers, features, steps or components but does not preclude the presence or addition of one or more other features, integers, components or groups thereof.

Claims (5)

1. Claims 1) A networked architecture comprising a central server and a

   plurality of remote servers; the central server including: a first data store of commodities that may be ordered through the system, the commodities being associated with specific terms and conditions, each of the commodities and their associated terms and conditions being editable by a user interfacing with the system, a second data store including details on each of the remote servers, the details including a rule structure that is configured to define specific commodities that may be ordered by each of the remote servers, a third data store including information specific to each of the remote servers concerning commodities ordered and received by each of the servers, the third data store providing a record of all commodities ordered and received by each of the remote servers, including the terms and conditions at which they were ordered and at which they were delivered, and wherein each of the remote servers include: a first data store of commodities that may be ordered locally through that server, the first data store at each of the remote servers being a sub-set of the first data store of the central server, and a second data store including order information relating to specific commodities that were ordered locally through that remote server, the terms and conditions on which the order was made, and details of the commodities that were delivered in fulfilment of the order including the terms and conditions associated with the delivery of same, and wherein the first and second data stores of the central server are updated locally by a user at that central server, the first data store of each of the remote servers is updated at regular intervals by the distribution of information to each of the remote servers by the central server in accordance with the rules defined for each of the remote servers in the second data store of the central server, the second data store of each of the remote servers is updated locally by users at each of the remote servers, and the third data store of the central server is updated by the returning of information from each of the second data stores of the remote servers to the central server.
2. 2. The architecture of claim 1, wherein the first data stores of each of the remote servers include a mirror of the complete list of commodities that are stored on the first data store of the central server, the first data stores of each of the remote servers further including a filter, specific to each of the remote servers, which is adapted to restrict access to the complete list, to those items within the list that can be ordered from that remote server.
3. 3. The architecture of any preceding claim further adapted to enable communication between individual remote servers, so as to provide for the transfer of commodities between individual remote servers.
4. 4. A method of providing a networked stock ordering and reconciliation procedure over a distributed network comprising the following steps: f) providing a central server having an inventory of available commodities that can be obtained through the system, the inventory being a product of a number of different suppliers, each of which are associated with specific parameters defining their behaviour, 9) providing one or more remote servers, distant from the central server, and adapted to be in electronic communication with the central server, h) enabling the transfer of an inventory from the central server to each of the remote servers, i) restricting the access by a user at a remote server to items within the inventory that may be ordered by that user for delivery to the location of that remote server, I) maintaining a record of items ordered and received at the remote server and communicating said information to the central server so as to provide a reconciliation between items ordered and received at each of the remote servers, and wherein the items that may be ordered at each of the remote servers are filtered such that a user at a remote server is presented only with the possibility to order items having the lowest possible price for items associated with the location of that server.
5. 5. A system substantially as hereinbefore described with reference to and/or as illustrated in the accompanying figures.