BACKGROUND OF THE INVENTION

THIS invention relates to management of resources. In particular, the invention relates to a financial budgeting system, to a method of allocating a financial budget, to a procurement system, to a resource ordering system, and to a delivery verification method.

In the management of an organisation where facilities, entities and/or resources are geographically remote from each other, it is sometimes difficult to perform management activities such as generating a budget for the organisation, allocating a budget to each of the facilities or entities, procuring resources for each facility or entity and distributing the resources to each facility or entity. Also, it may be difficult reliably to communicate with personnel located at each of the facilities or entities.

SUMMARY OF THE INVENTION

The invention provides a financial budgeting system which includes:

a database for storing description- and operational parameters of entities in an organisation, a financial budget available for allocation to the entities, and rules for the allocation of the financial budget to each of the entities in the organisation; and

a processor operable to access the database, and programmatically to calculate a budget allocation for each of the entities by applying the rules stored in the database relating to each of the description-, and the operational parameters of the entities.

For example, if the organisation is an educational organisation, the entities may include schools. The description of the entities may for example then include the location of the school, the type of school, the physical address of the school, the postal address of the school, a contact person at the school, contact details of the contact person at the school, or the like.

The operational parameters may for example include the district in which the school is located, the grades taught in the school, the language used in the school, the municipal services available at the school, the number of pupils in each grade, or the like.

The rules may then include a formula which uses as inputs the description and the operational parameters of each school to determine the budget allocation to each school.

The system may include an interface, for receiving descriptive information and operational parameters of entities. The interface may include a data transceiver operable to receive information from a remote location. The data transceiver may be a network interface, connectable to a computer network such as the Internet.

The system may be accessed remotely to upload the description-, or operational parameters of a entity, and to download the allocated budget to each entity. If a remote entity is connectable to a computer network, the system may be accessed from the entity. In the case where the computer network is the Internet, the system may be accessible from any location having access to the Internet.

The invention extends to a method of allocating a financial budget to entities in an organisation, which includes: recording in a database a description- and operational parameters of organizational entities together with a financial budget, available for allocation; and

programmatically applying a set of rules to determine a budget allocation for each entity based on the description- and operational parameters of the entity.

The set of rules may include a quintile factor in the form of a predetermined constant based on particulars pertaining to each entity.

The budget allocation may be divided into categories. For example in an educational organisation, the categories may include a budget for learner support material, textbooks, stationery, and other diverse items. The system may provide for transferring unallocated budgeted funds between different categories provided the required authority is obtained.

The set of rules may further include predetermined percentages to be allocated for different categories, e.g. 60% for materials, 28% for services and 12% for maintenance. These percentages may be varied from year to year.

The invention also provides a procurement system which includes:

a database for storing information of a requester, a supplier, and an authoriser;

a data interface for receiving and transmitting data from and to any one of the requester, the supplier, and the authorizer; and

a processor operable to receive a request for a particular resource via the data interface from a requester, and in response to send a notification via the data interface to any one or both of the authorizer -A-

and the supplier, thereby to initiate supply of the resource to the requester.

In addition, the database may store information of a distributor. The data interface may then be operable also to receive and transmit data from and to the distributor, and the processor may then be operable to send a notification to a distributor also.

The database may be arranged to store a catalogue of available resources. The catalogue may be accessible to suppliers to amend or add details of their products/services in a confidential manner, such as under password control.

In this specification the term requester is intended to refer to a party interested in obtaining a particular resource. The information of the requester stored on the database may include an allocated budget for resources, a delivery address, a contact person, contact details of a contact person, and the like.

The term supplier is intended to refer to a party who can supply a resource e.g. goods or services. The information of the supplier stored on the database may include a description of available resources, a unit price per resource, the availability of a particular resource, and the like.

The term authorizer is intended to refer to a party who is responsible for the authorization of the supply of the requested resource. The information of the authorizer stored on the database may include a contact address of the authorizer.

The term distributor is intended to refer to a party that distributes a resource in a particular geographic area. The information of the distributor stored on the database may include a geographical area in which resources can be distributed, the type of resources that can be distributed, or the like. The invention also provides a resource ordering system, which includes:

a database for storing a catalogue of resources, an allocated budget and a list of resource suppliers;

an interface for receiving a request for supply of a selected resource from the catalogue against the allocated budget; and

a processor for generating a purchase order for a resource supplier in response to receipt of the request.

The database may be arranged also to store a list of resource distributors. The processor may then generate a delivery order for a distributor in response to receipt of the request.

The invention extends to a delivery verification method, which includes:

recording documentary proof confirming receipt of an item by a recipient, the documentary proof being in the form of any one of an audio recording and an image recording depicting receipt of the item by the recipient; and

storing the recorded documentary proof in order to provide it to an interested party, when required.

The documentary proof may be in the form of a completed delivery note. The term documentary proof in this specification also refers to a digital- or photographic image of a delivery note.

The invention extends also to a resource management system, which includes any one of a financial budgeting system, a procurement system and a resource ordering system as hereinbefore described. BRIEF DESCRIPTION OF THE DRAWINGS

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

Figure 1 shows a schematic block diagram of components of a resource management system in . accordance with the invention;

Figure 2 shows a data flow diagram of certain data in a procurement application of the resource management system of Figure 1 ;

Figure 3 shows a process flow diagram of certain processes in a financial budgeting application of the resource management system of Figure 1 ; and

Figure 4 shows a data flow diagram of certain data in the resource management system of Figure 1

DESCRIPTION OF PREFERRED EMBODIMENTS

In Figure 1 , reference numeral 10 refers to a resource management system. The resource management system 10 in this example comprises a system developer 12 linked via a virtual private network 14 to a data host 16, a management agent 18 linked via a leased line 20 to the data host 16, a number of schools, a number of suppliers, a number of distributors, all of which only one is shown as 22, 24 and 26 respectively, linked via the Internet 30 to the data host 16, and a Provincial Department of Education 28 also linked via the Internet 30 to the data host 16.

The system developer 12, the data host 16, the management agent 18, the schools 22, the suppliers 24, the distributors 26 and the department of education 28 are all shown as computers linked to each other and the description that follows explain the interaction between the computers, which represents the interaction between the parties in the system.

The resource management system 10 illustrated in this example is configured for use in a public/private education system which includes the parties described above. The data host 16 is loaded with computer software which, when executed, provides functionality to the resource management system 10.

The software hosted on the data host 16 includes the following software modules: a System administrator module, a Masters module, a Budget module, a Catalogue module, a Requisition module, a Purchase order/Distribution order module, a Track and Trace module, an Invoice module, an Audit and Retrieval module, and a Management Information System (MIS) reports module.

The functionality provided by the software modules is set out in the following paragraphs.

SYSTEM ADMINISTRATOR MODULE This module, to which a system administrator has exclusive access, facilitates management of the system 10. Other utilities, which other users can access, are available to the system administrator also. The utilities include e-mail, task management facilities and a diary application.

This module includes the following screens/forms: Define Module This form is used by the System Administrator to view a list of modules in the system allowing the administrator to add a module or to modify an existing module. A module in this context is defined as a group of applications satisfying the functional requirements of a user or a set of users e.g. a "Requisition" module is used to create a new requisition, to modify an existing requisition or to enquire into the status of a requisition. A user uses the same module to acknowledge or approve the requisition or to view an existing requisition. This form provides a facility to add or delete a module thereby providing flexibility in customizing the system to specific requirements.

Define an Application This form is used by the System Administrator to add an application to the system. An application is a program that is used to perform a specific function, e.g. "Add a Module" application is a set of code that adds a module to the system. Once a new application is developed, it is added to the system referenced by a particular module. In use a user selects a module from a drop-box in the form and on selection a list of applications" under that module is displayed.

Codes Management This form is used by the System Administrator to add new codes into existing code templates.

User Management This form is used by the System Administrator for managing user registration by means of user identification management. By using this form, the System Administrator can create a new user or change the group or role of the existing user. Define Labels This is a form that can be used by a developer to create/define labels and by a customisation team to customise the labels in accordance with user requirements. Upon entering the form, a user is prompted to select a module. Upon, selection of the module, a dropdown list is displayed from which an application can be selected. Only applications that were previously added by means of the "Define Application" form will be displayed.

Define Roles This form is used by the administrator to define a functional relationship between the user group and a role that a user is to perform. Access to certain functionality in the system is dependent on the user group and the user role.

Application Role Relation This form is used by the System Administrator to associate an application to a defined role. Certain access rights can be defined in each application, which rights will be associated with a particular role.

Define Code Template This form is used to create a new code template or to update an existing code template according to the types of codes defined in a code master. Upon creation of a code template, certain codes can be added to the code template.

Change Password This form is accessible to all system users to change their system password.

Profile This form is accessible to all system users for editing their previously created user profiles. The form shows a current user profile with the details of a user's name and job title. It displays to the user the User group of which he is a member and the defined role in the system. The user can view and modify his physical and postal address.

Document Control This form is used by the System Administrator to view or modify an existing list of document types and to add new document types to the system. A document type identifies the type of transaction or activity in the system, e.g. "PO1" typically identifies a Purchase Order document in the system.

Password Session Initialization This form is used by the System Administrator to reset a user password to a user identification code in the event that a user has forgotten his password. For example, the session can be initialized if the user has accidentally closed the window instead of logging off from the system.

Task Management This form is available to all users to create and maintain a record of assigned tasks and the management of those tasks. This form will provide a facility for communicating with other user for example to follow-up on certain outstanding actions or to resolve outstanding actions with other users in this system.

Mail utility This form provides, a private e-mail facility to system users. Users in the system can use this facility to communicate to each other in a closed mail environment, such as on a virtual private network.

Diary Management This form provides a diary facility to system users together with the ability to synchronise their diaries.

MASTERS MODULE This module is used to define location details including the province, region, district and circuits in which suppliers, distributors, schools, and the management agent are located. Geographic details, contact details and other relevant contact information are stored for each party in the system.

EDU Details This screen is used to obtain relevant information of all system users. The form prompts a user to enter a company code, a province in which it is located, a company name, a company registration number, a tax registration number and a physical address. These details are used when printing documents and Management Information System (MIS) reports.

Locality Management This screen is used to define a new locality/location or update the details of the particular locality/location. The user can define a new locality which is a circuit / district / region / province.

School Management This screen is used to define a new school or update the details of the particular school. The grades offered at the school are also added in this module and is a prerequisite for allocation of a budget to the school.

Item Management This screen is provided to view, create, or modify items in the Item Master. The user is prompted to select an item such as textbooks, stationary or other items. When selected, the user is then prompted to provide additional search information relevant to the selected item. This information can then be used by the supplier to add items to the catalogue.

Supplier Management This screen is used to create a new supplier or to update details of an existing supplier. The supplier can be any one of a manufacturer, a printer, a publisher, or the like. Distributor Management This screen is used to create a new distributor or to update details of an existing distributor. The distributor can be of any size such as national distributors, local distributors, or small-,medium-,or micro-enterprises (SMME's).

BUDGET MODULE This module is used for entering an annual Resource Targeting Table (RTT), for entering budgets for schools and for the segmentation of the budget to the lowest level in accordance with guidelines from the provincial department of education. This module enables also the allocation of special budgets in accordance with the provincial department of education's guidelines. This module facilitates also the management of allocated funds during the procurement process.

Define Reckoner Header This screen is used to add a Budget Reckoner Header record to the system for a particular financial year. The user needs to provide percentages for learner teacher support material (LTSM), facility maintenance, other diverse items, learner support material (LSM) and teacher support material (TSM). The percentages for LTSM and maintenance and other diverse items should add up to 100%. Also the LSM and TSM should add up to 100 %.

Define Reckoner Detail This screen is used to add budget reckoner detail for a particular financial year. The user is required to provide the relative percentages for the items such as textbook, stationary and other diverse items, for each grade.

Normal Budget This screen is used to allocate a normal budget to each school in accordance with the guidelines from the provincial department of education. Once approved, the budget is allocated automatically to each grade in each school in accordance with the definition in the reckoner header and the reckoner detail. This allocated budget is then used to control the approval of requisitions per grade.

Special Budget This screen is provided to allocate a special budget to a particular school in accordance with the guidelines from the provincial department of education. The user is prompted to select a grade from the school to which a special budget has to be allocated. Once approved, the budget is automatically allocated to the grades in the school in accordance with the reckoner header and the reckoner detail. This allocated budget is then taken into account in the control and approval of requisitions per grade.

Budget Transfer This screen is used to transfer budget allocations, subject to certain transfer rules. The rules are set out below.

Case 1 : A normal budget allocation can be transferred between any of the grades for the same item type (LSM/TSM). Special budget allocations can be transferred between any of the grades for the same item type (LSM/TSM).

Case 2: Budget transfers between different special budget allocations have to be between same item type and same grade.

Case 3: Budget transfers between a special budget allocation and a normal budget allocation has to be between the same item types and the same grades.

Case 4: Normal budget allocations cannot be transferred to special budget allocations.

Budget Ledger Details This screen is used to view the budget allocated to schools in a particular financial year. CATALOGUE MODULE This module provides a listing of all educational material which can be procured by a school.

Create/Query Catalogue Items This screen enables authorized users to view, create or modify catalogue items. The user is prompted to provide a supplier identification code, and is then prompted to select one of the item types i.e. textbooks, stationary or other diverse items. The user can then add a new catalogue item or modify the existing one.

REQUISITION MODULE This module enables a school to generate requisitions. This module validates requisitions by authorizing them against approved allocated budgets. Items for use by more than one grade such as paper, is for example debited against the allocated budgets of more than one grade.

Requisition Generation This screen is used by the schools to generate a requisition. The information required for the generation of a requisition includes a school grade, a budget type i.e. normal budget / special budget, and an item type i.e. LSM / TSM. A school can either generate a requisition for a single grade by selecting any one of the grades, or can generate multiple grade requisitions by entering grade 13 in the selection box, in which case the cost will be debited across all the grades.

Requisition Approval This screen allows the management agent to approve or reject requisitions that were raised by schools. Once a requisition is approved, an authorized user may generate a purchase order against the requisition. Budget Re-In state This screen is used by the school to reverse an amount for which a requisition was approved to the allocated budget. This will reset the budget allocation of the school to what it was before the requisition was approved. All relevant details of a reversed requisition will be displayed to a user.

View Requisition Status This screen is used by the management agent and by schools to view the present status of a particular requisition i.e. whether the requisition is approved or rejected.

PURCHASE ORDER/DELIVERY ORDER MODULE This module enables the management agent to place purchase orders (PO's) on suppliers and simultaneously to place distribution orders (DO's) on distributors. This module also provides an acknowledgement facility, a facility to amendment orders and a facility to obtain the status of orders.

Purchase order/delivery order generation This screen is used by users to generate PO's and DO's against approved requisitions. All the requisitions raised by a particular school for a particular supplier can be displayed. Depending on the location of the school, the management agent is provided with the suppliers and distributors for the area. The user can then select a supplier/distributor for the PO/DO that is to be generated. If desired, requisitions can be processed in batches in this screen.

PO Acceptance This screen enables a supplier to view the list of PO's that is pending acceptance. The PO's are listed according to the schools in the area.

PO Amendment This screen enables the management agent to amend a PO prior to acceptance. DO Acceptance This screen enables a distributor to view the list of DO's that is pending. The DO's are listed according to the schools in the area.

DO Amendment This screen enables the management agent to amend the DO prior to acceptance.

PO Confirmation This screen enables the management agent to confirm a PO. The management agent can view the total cost and quantity of each requisition item. The management agent can then enter a discount percentage depending on the total value of the PO. The management agent is prompted to enter a required delivery date for the supplier and distributor and the management agent is required to select delivery terms and conditions before confirming the PO.

DO Confirmation This screen enables the management agent to confirm a DO. The management agent can view the total cost and quantity of each requisition item. The management agent can then enter a discount percentage depending on the total value of the DO. The management agent is prompted to enter a required delivery date for the supplier and distributor and the management agent is required to select delivery terms and conditions before confirming the DO.

View PO/DO Status This screen allows a user to determine the real-time status of a generated PO or DO. The user can keep a track of the PO/DO through the following stages: 1) PO's that are pending for acceptance from the supplier, 2) PO's that have been partially accepted by the supplier and that were returned to the management agent, 3) DO's that are pending for the distributor's acceptance, 4) DO's that have been partially accepted by the distributor and that have been returned to the management agent, 5) PO's and DO's accepted by suppliers arid distributors,

View PO Status This screen allows a supplier to determine the real-time status of a generated PO. The supplier can track the following stages through which the PO progresses: 1) Delivery note generated. 2) Approved PO's. 3) Supplier acceptance - Full. 4) Supplier acceptance - Partial. 5) Supplier acceptance - Pending.

View DO Status This screen allows a distributor to determine the real-time status of a generated DO. The distributor can track the following stages through which the DO progresses: 1) Approved DO's. 2) Distributor acceptance - Full. 3) Distributor acceptance - Partial. 4) Distributor acceptance - Pending.

TRACK AND TRACE MODULE This module is used to create delivery notes for suppliers and distributors and to generate proof of delivery documents for deliveries made between them.

Audio-Visual This capability enables the management agent of the provincial department of education to view and/or listen to the testimonials which confirm "Proof of Delivery" (POD), when a delivery of LTSM has been made to a school. The system provides for the upload/display of the static images (which show the material being handed over), video files (which show the material being handed over) and audio files (e.g. a script read by a LTSM coordinator or principal). These data files are captured when the material is actually delivered by the distributor.

Debit note Generation This screen is used by the supplier to create a delivery note against a purchase order.

Debit note Acceptance This screen is used by a distributor to accept and acknowledge a delivery note raised by the supplier.

Proof of delivery Generation This screen is used by the Distributor to create Proof of Delivery against a DN.

Proof of delivery Acceptance This screen is used by a school to accept the LTSM delivery reflected on the POD acceptance raised by the distributor. The school is required to sign and stamp two copies of the POD Acceptance. The school retains one copy and the distributor returns the other copy to the management agent for docketing and payment.

INVOICE MODULE This module is used to create and manage supplier- and distributor invoices.

Supplier Invoice This screen is used to create a new supplier invoice for a selected delivery note from a delivery note selection form. In this form all the header data such as tax invoice No, tax invoice date, bank name, bank account no, branch name, bank code need to be entered after which a delivery note for a Purchase Order is selected. In response the delivery note is used to create a new supplier tax invoice. Only delivery notes that have been accepted by the distributor are displayed on the screen and can be selected. Only one delivery note is selected to create an Invoice. After selecting a delivery note and clicking on the "Submit" button, the form passes the delivery note number to the Invoice Addition form, from where an invoice can be generated.

Distributor Invoice This screen is used to create a new distributor invoice for a POD selected from the POD selection form. In this form all the header level invoice data like tax invoice no, tax invoice date, bank name, bank account no, branch name, bank code need to be entered after which a POD is selected for the Purchase Order. This selection of the POD is made to create a new distributor tax invoice. Only POD's that have been accepted by the distributors are displayed on the form. Only one POD can be selected to create an Invoice. After selecting a POD and clicking on the "Submit" button, the form passes this POD to the Invoice Addition form, from where an invoice can be generated.

Invoice Approval/Rejection This screen is used by the management agent to approve or reject supplier or distributor invoices. A list of invoices is supplied when an identity code for a Supplier/Distributor is entered. The status of an invoice is indicated as either approved, rejected, or pending approval. An invoice pending approval can be approved or rejected by selecting the particular invoice. Details of invoices that have been approved are also displayed.

AUDIT AND RETRIEVAL MODULE This module is used for capturing audit data of schools in respect of the school and its expenditure of allocated funds. Audit Management This screen is used to add audit details of a particular school to the database. Once the audit details have been completed, the budget allocation details can also be completed.

School Retrieval Management This screen is used to create and update the school retrieval details.

MANAGEMENT INFORMATION SYSTEM(MIS) REPORTS This module includes definitions of pre-defined reports that can be generated.

Admin Reports This screen provides a list of all the System Administration reports defined in the system, which can be selected by a user.

Budget Reports This screen provides a list of all the Budget reports defined in the system, which can be selected by a user.

Master Reports This screen provides a list of all the Master reports defined in the system, which can be selected by a user.

PO/DO Reports This screen provides a list of all the PO/DO reports defined in the system, which can be selected by a user.

Track and Trace Reports This screen provides a list of all the Track and Trace reports defined in the system, which can be selected by a user. Invoice Reports This screen provides a list of all the Invoice reports defined in the system, which can be selected by a user.

School Audit Reports This screen provides a list of all the School Audit reports defined in the system, which can be selected by a user.

One of the applications implemented by the resource management system is a procurement system used for the procurement of material for schools which are geographically remote from each other, from the suppliers, the distributors, the management agent and the Department of Education. By being connected to the Internet 30 as shown in Figure 1, the procurement function can be managed from a central location but can be accessed remotely.

The procurement system illustrated in this example includes a database hosted on the data host 16 for storing information of a requester, which is as school 22 in this example, a supplier 24, an authoriser, which is a Provincial Department of Education (PDE) 28, in this example a distributor 26 and a management agent (MA) 18. The procurement system further includes a data interface in the form of the Internet 30 as illustrated in Figure 1 and a processor which is part of the data host 16, which is operable to receive a request for a particular resource/item via the data interface 30 from a requester 22, and in response to send a notification via the data interface 30 to any one or both of the authorizer 28 and the supplier 24, thereby to initiate supply of the resource to the requester 22.

The detailed operation of the procurement system is illustrated in Figure 2 which shows a data flow diagram illustrating the flow of certain data when the procurement system is used.

At 32, budget details are loaded by the Provincial Department of Education (PDE) 28 onto the data host (DH)16. A school 22 generates a requisition at 34, which is forwarded to the MA 18 via the DH 16 at 36. In response to the requisition and in accordance with the allocated budget, the MA 18 then generates a requisition approval/rejection at 38. When rejected, the school 22 is informed with a message at 39.

When approved, purchase order (PO) details are furnished to a supplier 24 at 40 and delivery order details are provided to a distributor 26 at 42. Acceptance of the PO is transmitted by the supplier 24 at 44 to the DH 16 and at 46 from the DH 16 to the MA 18.

When the items for which a requisition was generated are delivered from the supplier 24 to the distributor 26, a supplier delivery note is forwarded at 47 to the DH 16, and at 48 to the distributor 26.

The acceptance by the distributor 26 of the supplier delivery note is forwarded at 50 to the DH 16, at 52 to the supplier 24, and at 49 to the MA 18.

A supplier 24 then generates an invoice which is forwarded to the DH 16 at 54 and to the MA 18 at 55.

When the items are delivered to the school 22 by the distributor 26 a proof of delivery (POD) note is forwarded to the school 22 at 58 and the POD is accepted by the school 22 at 60. Also, the distributor 26 forwards a POD to the DH 16 at 56. The POD is forwarded to the MA 18 at 61 who uploads the data to DH 16 through the bar code.

The distributor 26 generates and forwards an invoice to the DH 16 at 62 and to the MA 18 at 63.

Lastly the school 22 issues proof of issue of the items at 64 to the DH 16.

As illustrated, the entire process from generating a requisition to the issue of the items for which the requisition was generated is closely monitored and well managed by the interaction of all the parties in the procurement chain, which may reduce mistakes and fraud.

Another application implemented by the resource management system 10 is a financial budgeting system used for the allocation of a financial budget to schools which are geographically remote from the management agent 18 and the Provincial Department of Education 28. By being connected to the Internet 30 as shown in Figure 1 , the budgeting function can be managed from a central location and can be accessed remotely.

The financial budgeting system illustrated in this example includes a database hosted on the data host 16 for storing a description of entities in an organisation, which in this instance are schools, illustrated by 22 together with operational parameters of the entities/schools 22, a financial budget available for allocation to the entities 22, and rules for the allocation of the financial budget to each of the entities 22 in the organisation. The financial budgeting system includes a processor, which is part of the data host 16 which is operable to access the database, and programmatically to calculate a budget allocation for each of the entities 22 by applying the rules stored in the database relating to each of the description-, and the operational parameters of the entities. This budget allocation is then available to the MA 18 by accessing the DH 16.

The detailed operation of the budgeting system is illustrated in Figure 3 which shows a process flow diagram. The process flow diagram illustrates the operation of the budgeting system when allocating a budget, which process is identified in Figure 3 with reference numeral 80.

At 82, the Provincial Department of Education (PDE) 28 is in possession of a total budget that has to be allocated. At 84 the budget can be allocated as a normal budget or as a special budget. Typically the normal budget refers to the yearly financial budget that is allocated to meet the general needs of the education system, and the special budget refers to a budget that is allocated to address specific needs in the system. The total budget is provided to the management agent 18 at 86, to enter a process of allocation at 88. As can be seen the process managed by the management agent 18 at 88 receives data from a database that was previously stored for each school, called a schoolmaster 90 and also from a database that was previously stored for each grade in each school, called a school grade 92.

At 94, a decision indicates if the allocation is to be made as a normal budget, or as a special budget. If the budget is to be allocated as a normal budget, a programmatic process 96 allocates the budget to categories called learner/teacher support material (LTSM), services, and maintenance. This programmatic allocation is performed using data stored in a database for the above allocations, called a budgetgroup-item table 98.

At 100, the LTSM is programmatically allocated to learner support material (LSM) and teacher support material (TSM). This process is also performed by using data from the budgetgroup-item table 98.

At 102, the LSM and TSM are programmatically allocated in schools by accessing a database in which is stored a percentage allocation per grade, the database being referred to as a budgetreckoner 104.

If the budget being allocated was a special budget selected at 94, the allocation process at 100 and 102 would be forced to allocate the budget not programmatically according to the data in the budgetgroup-item table 98 and the budgetreckoner 104, but according to the special budget being allocated.

The result of the budget allocation process is then stored in a database called an actual-budgetamount-allocator 106, which stores the monetary value in the budget being allocated down to grade level. As can be seen, the above process flow illustrates also a method of allocating a financial budget, which includes recording in a database a description- and operational parameters of organizational entities together with a financial budget available for allocation in the databases 90, 92, 98, and 104, and programmatically applying a set of rules also stored in the databases 90, 92, 98, and 104 to determine a budget allocation for each entity based on the description- and operational parameters of the entity, which budget allocation is then stored in the actual-budgetamount-allocator 106.

Referring to Figure 4, the resource management system 10 is implemented by the data host 16, which stores information and which performs certain processes. The data host 16 thus provides the database and processor described in the financial budgeting system, the procurement system, and the resource ordering system which are all part of the resource management system 10, in this example. The resource management system 10 facilitates a method of allocating a financial budget and a delivery verification method, which is described in the specification.

Figure 4 shows a data flow diagram on the highest level and can thus be used to explain the process flow in the resource management system 10.

In Figure 4, the parties in the management system 10 are indicated by reference numeral 120, the data stored in the data host 16 is indicated by reference numeral 122, and the processes, which are divided into modules in the system 10, are indicated by numeral 124.

As can be seen, the parties 120 include the management agent (MA) 18, a Provincial Department of Education (PDE) 28, schools 22, distributors 26, and suppliers 24. The repetition of numerals in Figure 4 refers to the same party, which is involved in more than one process 124.

The processes 124 shown include a master maintenance module (MM) 130, a budget maintenance module (BM) 132, a requisition process module (RP) 134, a purchase order/distribution order module (PO/DO) 136, an items delivery and receipt module (ID) 138, an invoice and payment module (IP) 140, a school inventory module (Sl) 142, a management information system report module (MIS) 144 and a standard reports module (SR) 146. For convenience, the modules will be referred to by their abbreviations.

The data 122 stored on the data host 16 includes databases as follows: master data 148, budget master 150, requisitions 152, purchase orders 154, delivery orders 156, supplier delivery note 158, distributor proof of delivery 160, supplier invoices 162, distributor invoices 164, supplier payments 166, distributor payments 168 and a school inventory 170.

As can be seen in Figure 4, at 180 and 182, the MA 18 and the PDE 28 enter master data into the MM 130, which is stored in the master data database 148, at 184.

At 186, the PDE 28 supply budget data to the BM 132, which is stored on the budget master database 150 at 188.

In the RP module 134, a school can enter a requisition at 190, budget details are received at 192 from the budget master database 150 and school master data is received at 200 from the master data database 148. The combination of the requisition details, budget details and school details is forwarded to the MA 18, at 194. The MA18 returns an approved or rejected message at 196, and when rejected a rejection is forwarded to the school 22 at 198.

If the requisition is approved, requisition note details are forwarded at 202, to the requisitions database 152. To view approved requisitions, data can be transferred at 204, to the RP module, and to amend requisitions, data can be transferred at 206 between the RP module 134 and the requisitions database 152. After approval of a requisition, a purchase order is generated be the MA 18 to the PO/DO module 136 at 208. Purchase order details are also received from the supplier 24 at 210. The purchase order details are stored in the purchase order database 154 at 212. A distribution order is send to the distributor 26 at 214, and the distribution order details are stored in the delivery order database 156 at 216.

The distributor 26 receives the items .ordered from the supplier against a supplier delivery note that was received at 218, and forwarded at 220 to the distributor 26. The delivery note is accepted and send to the ID module 138 at 222 and forwarded to the supplier 24 at 224.

Upon delivery of the items at the school, a proof of delivery is send by the distributor to the ID module 138, at 226. The proof of delivery details are forwarded to the school 22 at 228 and once approved, returned at 230. The supplier delivery note and distributor proof of delivery are forwarded to the supplier delivery note database 158 and the distributor proof of delivery database 160 at 232 and 234 respectively.

The supplier proof of delivery can be in the form of a signed form, a digitally scanned signed form, an electronically signed document and in particular an audio/visual recording of the delivery taking place. This method of verifying delivery of items is believed to be of particular use to minimise fraud in the system. The proof of delivery used is tailored according to facilities available and to the type of proof required. However, the management system 10 facilitates the use of any proof of delivery, which is advantageous in a large organisation.

The supplier invoice is received by the IP module 140 at 236, forwarded to the school at 238, and stored in the supplier invoice database 162, at 240. The distributor invoice is received from the distributor 26 at 242 and stored on the distributor invoice database 164 at 244. Both the supplier invoice and the distributor invoice are forwarded to the MA 18 at 246. Invoices are paid by the MA 18 and details are entered into the IP module at 248. Payment details are forwarded to the supplier payment database 166 and the distributor payment database 168 at 250 and 252 respectively.

The SI module 142 is used to perform audits on schools 22 in order to obtain inventory details from schools 22 to be entered at 254, and stored in the school inventory 170 at 255.

The MIS module 144 can be used to generate reports by receiving data from the respective databases at 256, and the reports are accessible to the MA 18 at 258.

Standard reports are generated by the SR module 146 by receiving data from the respective databases at 260 and the reports are accessible to the PDE 28 at 262.

The inventor believes that the invention, as illustrated provides a new resource management system, which includes a financial budgeting system, a procurement system and a resource ordering system. The invention also provides a new method of allocating a financial budget and a new delivery verification method. The inventor believes that it is advantageous to users and organisational entities that are located remote from each other, that the architecture of the system allows use f the system over the Internet.