MXPA99009968A - Operating resource management system - Google Patents

Abstract

A software system efficiently procures operating resources within an enterprise. A requisition record generating module generates a requisition record for a requisition. The requisition record indicates at least an operating resource that a requestor desires to purchase. The requisition record generating module generates the requisition record responsive to a combination of input by a requestor and operating resource information in an operating resource information database. An approval path determining module, responsive to the requisition record and to approval rules in an approval rules database, determines an approval path for the requisition record, among various ones of a plurality of possible approvers, required to approve the requisition record. An approval path handling module guides the requisition record along the determined approval path, and the approval path handling module generates a global approval indication in response to the requisition record successfully traversing the approval path.

Description

SYSTEM OF ADMINISTRATION OF OPERATING RESOURCES TECHNICAL FIELD The present invention is a software system for procuring operating resources, and more particularly, it is a software system that automates the cycle of acquiring operating resources. BACKGROUND Currently, operating resources account for a third of a dollar sold in the typical Fortune 1000 company. Nearly 95 percent of all goods and services acquired by corporations are made through document-based processes . The predominant use of document-based shopping is the evidence that legacy business-to-business electronic business systems do not provide a solution to the volume of corporate purchasing processes. The research indicates that a cost saving of 5 percent in the cost of goods and services from operating resources will commonly result in a 28 percent increase in a company's profits. Traditionally, -the methods of purchasing sources of operation (eg, industrial supplies, office supplies, and other non-production supplies) are extremely fragmented, and therefore inefficient. What is desired is an integrated solution for the entire company.

SUMMARY With the present invention, electronic automation, consolidation, and leveraged purchase through operations resource management (ORM), present a significant opportunity for companies to lower costs, and thus dramatically improve the bottom line. The management of operating resources replaces the traditional fragmented methods of acquiring operating resources. Through the new technology - in one modality, namely intranets, extranets, and Java MR the administration of operating resources replaces decades of inefficiency with a consolidated corporate electronic business system, to completely capture the economics of supplier relationships to scale and leverage. The operation resource management system of the present invention provides at least three key benefits: • automation of the entire acquisition cycle by incorporating all the functions that make up the purchase process, from the request to the payment. • Reduced operating resource costs through economies of scale and facilitation of a change in the roles of purchasing professionals, from tactical transaction processing to strategic supply chain management.

• Leverage of business systems and existing electronic business systems, through an easy link with existing data sources, as well as with electronic commercial systems of suppliers. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 shows the design architecture of an embodiment of the invention. Figure 2 shows the extensibility architecture of an embodiment of the invention. Figure 3 shows the flow of the procuring process of an embodiment of the invention. Figure 4 shows the description of product features of a modality of the invention. Figure 5 shows the characteristics of the user's environment of an embodiment of the invention. Figure 6 shows the environmental characteristics of the system of one embodiment of the invention. Figure 7 shows the commercial modules included in one embodiment of the invention. Figure 8 shows the adapters of the system of one embodiment of the invention. Figure 9 shows the installation and implementation comprised in one embodiment of the invention. DETAILED DESCRIPTION OF THE PREFERRED MODALITY In one embodiment, the operating resource management system according to the invention is a set of software modules that automates the purchase of goods and services within a corporation. Preferably, some of the modules operate on a server computer of a network, and others of the modules operate with the system of the present invention, and a company can reduce the cost of the transactions and increase the overall productivity, with a direct benefit to the bottom line. Some key features of the system are: • Inferred from the User to Approach Any Company Desk - The user interface makes the product accessible to employees with little or no training, assistance, and guidance to the employee through the requisition process. The use of the system does not need to be limited to a selected purchasing group. • Access to Information in a Ubiquitous and Easy Way for All Employees - Applicants and approvers can also view the current status of any requisitions at any time, and therefore, always stay in the cycle when something about their request changes . • Flow of Authenticated Approval - The system enforces the commercial rules of the corporation, and validates the requisitions, ensuring accurate and complete data. • Adapters to Integrate with the Company - The system provides adapters to integrate the system into legacy business data sources, such as ERPs, Human Resource Management Systems (HRMSs), email systems, and directory services. • Extensibility and flexibility - The system provides complete flexibility in describing the data fields and business rules of each individual company. Referring to Figure 1, in the modality 100 shown therein, a key module is a Business Commerce Server 102, which includes an Intranet application server software, preferably described in Java. A set of associated software applications on the client side are also preferably written in Java. The Java 112 client software preferably runs in a Web browser (or in an alternative way, is accessible through the Web browser), from each desktop computer (shown in Figure 1 as "Mac", "Win95", "WinNT", and "Unix"), and provides the user interface to create and approve requisitions. The Java 102 server software is preferably run on a single shared machine, and provides "back end" services. Complementing Enterprise Business Server 102, there are a number of Adapters 122, which integrate System 100 into legacy business data sources, such as ERPs, HRMSs, email systems, and directory services. The design of the system is modular, allowing any number of adapters to be connected without requiring revisions to the Enterprise Commercial Server software 102. In practice, the system according to the invention is easy to use. The system is accessible both to infrequent users, people who buy something only once or twice a year, as well as frequent users, purchasing agents, administrators, and others who use the system almost daily. Most users of the system will be requisitioned: employees who need to buy something. Most of these requisitioners are casual users who will introduce requisitions, through the client software 112, using a requisition magician. Figure 2 is a system diagram showing in general the manner in which the functionality is distributed (particularly the functionality that can be extracted for a particular implementation) in a system mode. Reference numeral 202 designates the request magician module. Figure 3 is a flowchart that shows how a requisition is processed in a typical mode, from the creation of the requisition to the approval, and until the receipt of the requested goods / services, and even reconciliation. In Figure 3, reference numeral 302 designates the process steps associated with the creation of a requisition. Figure 4 is a description of higher-level "product features" of one embodiment of the invention, while Figures 5 to 9 are diagrams showing the characteristics of the product at a more detailed level. As can be seen in Figure 5, the wizard software is within the "requisitions" portion 502 of the user's environment 500. The wizard 202, 302"routes" an employee through a number of questions to guide him or her through the process of making a purchase. For example: • What do you want to buy today? In general, the first question is "What do you want to buy today?". Wizard 202, 302 offers several ways to find the answer, always encouraging employees to select from approved items. Perhaps the employee will only select an item from a list of their own frequently ordered personal favorite items 304. 0 maybe you can find an appropriate article by searching through the product information database 306. 0 maybe you will find the Article searching through a number of approved online catalogs 308. (In one mode, the system supports online catalogs, but does not include catalog authoring tools).

Preferably, only as a last resort, the magician will ask the employee to explicitly type in the name of a provider and part (310). The introduction of such ad-hoc articles, items that are not on the list of approved articles, will usually trigger new approval rules. For example, the approval rules of many companies will cause the Purchasing Department to go through the approval cycle at this point, to require a Purchasing Agent to decide whether to approve the new item. Because the ad-hoc introduction usually involves additional surplus, the magician guides the employee through the process, in such a way that avoids the ad-hoc introduction whenever possible. Who will pay for this article? Another important part of the requisition is the accounting information: who will pay for the item. The accounting structure normally varies from company to company, be it Division, Department, Account, or Project.

The magician can be set up to display and ask for different accounting fields for the company, helping to ensure that relevant and appropriate choices are always presented to the employee. The magician continues in this line, asking questions and gathering other information about payment, billing, boarding, and the like. Throughout the process, the emphasis is on search and selection, instead of typing, channeling the employee towards standard answers, and generating requests without errors. Any employee who handles a requisition, either the applicant or the approver, can add comments or attach documents to the requisition. The ability to document and explain can go a long way toward maintaining alignment, making requisitions that can be understood by approvers, allowing approvers to provide feedback to applicants, and helping approvers make a decision about whether they approve request. After a request is submitted, another piece of user interface software 500 comes into play: Organizer 504 (Figure 5). In a preferred embodiment, the Organizer 504 software provides a folder style view of the existing requisitions, designed to help group and organize large collections of requisitions. When a request is submitted, the approval software (approval machine 110 in Figure 1, step 322 in Figure 3, approval flow software 602 of the system environment 404, in Figure 6) inspects the approval rules of the company, decides who needs to approve the request, and notifies the first approvers required, preferably by email, that there is a requisition awaiting your attention. In one embodiment, the email notification message includes a URL hyperlink pointing the approver directly to the 504 Organizer software through its browser, to display the requisitions that await the approval of this person. The approver can approve or deny, and make comments, asking for more information or clarification. Whenever there is a change of state in a requisition, the notification software 120 sends an e-mail message, notifying the requester and any other interested parties. The system uses notification emails throughout the approval process to keep users informed about the current status of a requisition. Applicants can also use the Organizer 504 software to check the status of an application at any time, to keep informed of who has approved it or not, when it was fully approved, and so on. Using the 504 Organizer and the comment mechanism, all those who are in the approval process (eg approvers, requisitioners, and Agents) Shopping) can ask each other questions, see the status of a requisition, or make comments about the requisition, reducing confusion and improving communication. After a requisition is completely approved, the supplier interface software 330 communicates with the suppliers to give them the order. The system can communicate with provider systems through conventional elements, such as fax and email. When a requisition is completed, the system will verify the requisition to determine which suppliers are involved, determine the preferred method for ordering those suppliers, and use that method to transmit the requisition to the supplier. The parts of the system used to transfer orders to be satisfied are known as the ordering modules 130 (Figure 1) (see also Figure 7). There are three modules for ordering 702 (see Figure 7): a Purchase Card module, a Direct Order module, and a Purchase Order module. Eventually, the requisition will be approved, submitted, and satisfied. As described above, the system can communicate the orders to the supplier through conventional elements (fax and e-mail). But once the article is shipped, and arrives at the requisitioner's door, the receipt of the item must be acknowledged before the payment is made. The system includes a user interface for receipt acknowledgment, which allows employees to acknowledge that different items have been received. These desk receipts are all stored in the system, and do not integrate with the ERP. In addition to the requisicionaría population - applicants and approvers - there is another class of users: members of the Purchasing Department. Purchasing Agents are responsible for the company's purchasing practices, ensuring that the company is doing business with the most appropriate suppliers, and making sure that employees are buying the most appropriate items. It is desirable to take the Purchasing Department out of the cycle of the requisition process. However, it is also desirable that they retain control over the process. The system balances these desires by involving the Purchasing Department only when there is something unusual about a particular requisition. For example, a Purchasing Agent will normally be involved when someone tries to buy an item from an unapproved vendor, or when someone specifies an unusual shipping address. The Purchasing Department, through the Administrative Tools 506 software (Figure 5), defines which products and suppliers are "approved". The Purchasing Department also manages in an implicit and explicit manner the product information database, which describes the collection of approved products and services. The Administrative Tools 506 software provides Purchasing Agents with the ability to add or remove items from the Product Information Database, or remove items when a relationship with a supplier changes, or an item is otherwise obsolete. Another piece of the user environment 500 of the system is the Reporting and Graphics 508 software (Figure 5), which allows a company to summarize, group, and understand its purchasing history. The system of preference provides the software to generate a collection of predefined reports that can be executed at any time, giving purchasing agents and system administrators the information they can use to refine their purchase process and maximize profit from of automation. This information can be a valuable tool to gain understanding and use that understanding to make improvements, such as modifying the approval processes or changing suppliers or updating the purchasing history, to encourage different buying patterns of end users in the future. The environment of the 404 system is the "back end", the parts of the system that do not directly interact with users. Flexibility and configurability are important for design, because each company wants to keep data slightly different, and enforce slightly different business rules. To support the goal of flexibility, a system modality is designed to allow companies to tailor the set of data fields, recognizing that each company has a slightly different set of information that must be maintained. These "expandable fields" are defined by the client, in a configuration file of the entire system, and are available both through the user interface software and through the commercial rules. Throughout this patent application, examples of the way in which such fields can be used are presented. For example, a company may wish to extend the set of data fields to describe its own accounting policies and categories. The approval rules are the conditions that a company uses to decide which approvers are required for a particular requisition. The preference system provides a mechanism to describe the approval rules, which is flexible enough to model the existing process in any company. Each company will have its own set of rules, although there are often basic similarities, and many rules can be copied from simple examples. For example, an approval rule can be expressed as a set of conditional expressions, such as "If the amount of this purchase is greater than $ 25,000 and is for software, then the Information Systems Department must approve the purchase." There are at least two things to observe about the approval rules. First, the approval rules can be based on any field of a requisition, including the fields that are added during the implementation process. So, in addition to the standard approvals based on the quantities of requisition or line items, for example, the Service Manager may need to approve any furniture purchase, or the IS department may have to approve any purchase of the purchase system. computing. In addition, an approval designation does not have to be given to a particular individual in the company. Rather, a particular role can be designated in an approval rule as an approver. A role of example is the role "CFO": At any given time, this paper is made by a single individual of the company, but if a new CFO is hired, then all the requisitions that are awaiting approval by the CFO, can be approved by the new CFO when he enters the board, without any maintenance of the system. When the individual who is the new CFO is designated in the system as CFO, he will be notified of all the requisitions pending approval for the role of CFO. Papers can also describe a group of people. For example, there is the role of Purchasing Agent.

There could be any number of Purchasing Agents in the company, but if the role of Purchasing Agent is assigned to a requisition, then all individuals designated by the Purchasing Agent role seek it for approval. In a modality, if any of them approves it, the requisition for that paper is approved. The adapters 122 (Figure 1) and 800 (Figure 8) are software modules that link the system with the rest of the company. The system obtains and stores all data through an adapter layer that integrates the system with existing services, using data that already exists in these legacy systems. This helps avoid duplication of information inside the company. If there is no adapter for particular data, then the system will store the information internally, but if data exists elsewhere in the company, then the system will use the data through an adapter. The significant adapters are the 804 adapters for the company's ERP system. These adapters can be custom-made to interconnect with each ERP (for example, Oracle 10.4, 10.5, 10.6, SAP, Baan, D &B, PeopleSoft, etc.). ERP adapters can obtain simple ERP information such as units of measurement, accounting information, etc., as well as article templates, vendor information, approval matrices, and other relatively static information. They are also able to store all requisitions approved back in the ERP. Another source of information in a company is the description of all its employees, including names, organization information, contact information, and so on. Often this information comes from an HRMS system. In one embodiment, an HRMS 806 adapter is provided (eg for PeopleSoft, Version 5.0). There are also 808 adapters for user authentication systems. User authentication information is commonly stored in external directory services such as LDAP, Microsoft Exchange, or Unix NTS. Now that one modality has been widely described. of the system in general, portions of the modality will be described in greater detail. User Environment This section describes the parts of the system that employees see: the user interfaces and the associated help and magician systems. When reading this section, you should keep in mind the design of the extensible fields. That is, each instantiation of the system may have a slightly different user interface, tailored to present the appropriate information for that particular company. This document contains a number of tables describing data fields. Each table differentiates two kinds of data: • an intrinsic field is a field that the system expects to find. • an extrinsic field is an additional custom field, usually added during installation. There can be any number of extrinsic fields, depending on what a particular company wants. The system will store and display the information in these fields, but in a preferred mode, it will not depend on having the information there. This document contains a number of examples of extrinsic fields, to illustrate how they can be used. Requisitions This section describes the basic functionality of the system: the way in which employees are asking about something by creating a requisition. 1. Start of New Requisitions The user interface to create requisitions should be appropriate for both novice users - people who can use the system only once or twice a year - and expert users, who can use the system almost daily. The system allows users to create new requisitions in at least the following ways: a. with the requisition Wizard, which guides the employee through a series of questions at each step, providing navigation aids to keep track of the big picture, and present lists of choices whenever possible, instead of asking the employee to type things. b. By cloning the existing requisitions. 2. Filling Requisitions A requisition can contain any number of line items that the employee would like to order. In one mode, there are some parts of a requisition that are shared between all the line items, and others that are specific to individual line items. To initialize the information that applies to the entire requisition, the system: a. fill the requisition fields from the employee's personal profile, as available. For example, the shipping information and the department will obviously be initialized from the personal profile. The employee may change any of these fields for obvious reasons for a particular request. b. It will generate unique numerical alpha identifiers for each requisition. The format of the numbers can include a prefix string, defined as part of the company's configuration. c. It will allow the employee to give titles to the requisitions, more mnemonic than the requisition identifier. d. It will provide a way for an employee to prepare a requisition and submit it to someone else. That is, it will allow the creator and the presenter to be different people. If the applicant and the presenter are different, then the standard approval rules will place the applicant as the first approver. and. It will allow the employee to specify a holding date on a requisition. The support date is a date on which the employee would like the Purchase requisition to actually be submitted. If the requisition is completely approved before the maintenance date, the system will hold the requisition until the maintenance date. If there is no support date, then the system will submit the requisition as soon as it is fully approved. In one mode, sustainability is a feature of the entire company, and can be disabled in the system profile for an entire company, if that company does not choose to allow sustaining functionality. F. It will allow the employee to specify the reporting currency of a requisition, and display the total for the requisition in those currencies. The reporting currency of a requisition is obviously taken out of the reporting currency by the employee's obviousness. The system will display each currency with the appropriate precision. g. It will stamp the time of each requisition, with the time in which the employee initiated the requisition. The following table 1 summarizes the fields of a requisition record.

Table 1: Fields of Requisition 3. Adding Line Items After creating a requisition, the employee can add any number of products and services to it, such as line items of the requisition. The system guides employees towards the choice of articles from approved sources, instead of asking them to type the information manually: the interface emphasizes copying and selecting, and de-emphasizes typing. The system provides the following ways in which an employee can create a line item in a requisition: a. Through the search through a Product Information Database. The Product Information Database for a company is the collection of all items that have been approved for purchase. The user can navigate in the tree in a hierarchical way, that is, through navigation through elections such as Office Supplies, Computer Peripherals, Industrial Equipment, etc., and then from Computer Peripherals to Network Adapter, Disk Unit, Moni tor, et cetera. The user can also search the Database of Product Information with a "contains" search, in the following fields: Item Description, Supplier Part Identification, Manufacturing Part Identification, Manufacturing Name, and Comfort Code. b. By choosing from a list of personal favorites. In one mode, a Favorites list is a "flat" list of up to 25 items that the employee has chosen and marked as Favorites. c. By manual input, by typing or using the copy function to request an item that is not available either from the Product Information Database, or from any Web catalog. When an article is introduced from the beginning, the applicant can suggest a supplier (by selecting the supplier from a quick list, or typing it directly), or leave it out, to be chosen by the Purchasing Agent. Requests for items that are not from approved sources usually trigger special approval rules, such as requiring a Purchasing Agent to approve the new item and supplier. The system provides ease for each company to define its own rules for handling these requests. 4. Filling Line Items After adding a line item, the employee can modify any of the information about that line item, as appropriate. Quick selections are provided for all fields, in order to maximize accuracy. In particular, the employee can: a. Specify the amount that will be requested. b. Specify shipping and delivery directions. c. Modify the carrier or the method of transportation, if the provider's obvious options are not appropriate. For example, the employee may wish to order something to embark faster than the provider's usual practice. d. Specify a need date, to inform the supplier of the date on which the item needs to arrive to be useful. The fields of a line item in a requisition record, in one mode, are described in Table 2 below.

Table 2: Fields of a Line Game . Comments and Attachments Any employee who handles a requisition, be it the applicant or the approver, can add comments or attach documents to the requisition, helping all who see it to better understand the requisition. The ability to comment and explain can go a long way in making requisitions understood by approvers, allowing them to provide feedback to applicants, and helping them make a decision about whether to approve the request. The comment mechanism: a. It allows users to add textual comments to any requisition or line item, using "spinning" to maintain the context. b. Allows users to specify the audience for a comment, which can be either Approvers. Applicants, Suppliers. Shopping, or Everyone. Comments are visible only to the specified audience. c. It allows users to attach electronic documents to comments. To ensure independence of the platform, this preference feature is implemented using a mail-sender sending facility. If employees can send attachments from their mail, then they can attach documents to a requisition. 6. Submitting completed Requisitions When an employee has finished filling out a requisition, and has requested to submit it, the system will perform the following verifications before actually submitting the requisition for approval: a. Find all required fields (distinguished from the optional), and ensure they have values. If there are missing values, then the requisition is returned to the user for further editing. b. For each field that has a value, verify the data in that field to ensure that the values are valid for the field involved, as well as validate that combinations of accounts (for example, Account, department, etc.) are valid. If there are validation procedures for any of the extrinsic fields (custom-made for this company), then execute those validation procedures as well. If there are invalid fields, then return the requisition to the user for further editing. c. Verify each line item, and assign a suggested buyer for that line item. The company can parameterize the rules to assign buyers to line items, based on any fields of the requisition. If there is a direct order contract with this supplier, the suggested buyer will be the agreed buyer in the supplier's profile. (The supplier profile specifies whether there is a direct order contract in effect). d. Add the billing information, using the data for obviousness of the system profile. and. Stamp the requisition time with the current date and time, such as the requisition submission date. F. Determine the approval path for this requisition, using the approval rules defined in the business rules for the company, and allow the employee to preview the approval route. Allow the employee to confirm the presentation, or cancel it and return the requisition to edit. The Organizer The user interface software to categorize and classify the requisitions is known as the Organizer 504 (Figure 5). Approvers use the Organizer software to approve or deny requisitions, and applicants use it to verify status and history. When a request is submitted, the system checks the company's approval rules, decides which users need to approve the request, and in what order, and then notifies the first approver that there is a requisition waiting for attention. Each approver sees the new requisitions in an entry requisition folder, and will need to take action on the requisition to move it to a different folder. 1. Approval or Denial of Requisitions When an approver goes to the Organizer's interface, be it from a notification message, a bookmark, or some other hyperlink, the Organizer displays the requisitions of entry for that approver, showing the information in Table 3 , next, for each requisition: Table 3: Fields of an Approval Request Whenever an approver acts on a requisition, the system seals the time of the requisition with the name of the approver and the time of the action. If an approval is marked as required, the approver may take any of the following measures on the requisition: a. Approve the requisition. An approval will trigger any notifications specified in the business rules for this company, mark the request as approved for this approver, and add the request to the input folder for the next approver in the approval chain. After approving a request, the approver can move it to some other folder, or leave it in the input folder. b. Deny the requisition. When an approver denies a requisition, the system sends an email notification to the requestor, and stops any other approval requests in this serial approval chain. If the applicant does nothing in response to a denial notice, the request will eventually lapse. If the applicant modifies the application and resubmits it, the system starts the approval process again, as described in step 5) below. c. Add an additional approver to the approval chain, either before, or after this approval.

For example, an approver might want to say "Please ask Ed if he approves, and then come back with me." d. Add comments and. Modify the requisition. Not all approvers can change all fields; however: a Purchasing Agent can modify any field of a requisition; other approvers can modify only a limited set of fields in the requisition. The definition of which fields the approvers can modify is part of the configuration of the company's data fields, and is normally established during installation. When an approver modifies any field of a requisition, the system recalculates the required approvals, and invalidates any existing approvals for that line item (if it was a line item that changed), or for the entire requisition (if the requisition itself changed). Consequently, the modification of a field can trigger reapprovals from users who have already approved the requisition, or trigger the addition of new approvers in the chain, depending on the approval rules. If the approver is marked as Optional, then this approver is an Observer, and not a true approver. Observers are spectators: they see the requisition, but approval is not required. Observers can take any of the following actions on the requisition: • Add an additional approver to the approval chain, either before or after this approval. • Add comments. 2. Approval in Lieu of Others The system maintains the notion of the chain of command derived from the information of the "immediate supervisor" in the personal profile of each employee. Using that information, the system allows certain approved approvers to approve instead of another approver: a. The system allows approvers to obtain a list of requisitions that are awaiting approval from a lower level approver (as defined by the business rules), and approve them directly. A high-level approver can approve explicitly in place of any lower-level approver, if the two approvers are in the same chain of command. 3. Removal of Requisitions or Approvals a. An applicant may withdraw his own requisitions at any point during the approval process, until the requisition is fully approved.

A withdrawn request returns to the Unrepresented state, and any approvals that have been registered up to then will be removed. b. An employee who has the role of Purchasing Agent can remove approvals for any requisition. 4. Organization of Requisitions The Organizer helps employees organize groups of requisitions. Allows employees: a. Sort the requisitions by any of the fields that are displayed in the illustrated view. That is, if there is a column heading for a field, then the employee can sort on that field. b. Filter the requisitions by any of the fields that are displayed in the illustrated view. That is, if there is a column heading for a field, then the employee can use the value of that field to restrict the display of the information. c. View the details of any requisition, including all line items, approvals, and comments. d. Put the results of a search in a folder. For example, a purchasing agent may wish to examine all pending requisitions for items from a particular vendor. and. Print any requisition on letter size paper. F. Send any request by fax, on platforms with integrated fax support.

Now, the administration of the system is described, in the sense of making changes that are not part of the configuration of the server itself. 1. Maintenance of Personal Profiles A personal profile of an employee is described in a configuration file that establishes values for a user of the system. There are two kinds of information in a personal profile: Human Resources data fields and specific data fields. The Human Resources data fields are preferably initialized from the HRMS adapter, if there is one on the site, and are also updated regularly from the HRMS adapter. The specific data fields are created and maintained entirely within the system. The system: a. It allows employees to view and edit the specified fields of their own personal profiles, in a manner consistent with the rest of the Ul. b. Submit all changes to personal profiles for approvals, as described in the company's approval rules. c. Allows employees to see the Human Resources data fields that are passed through the HRMS adapter. d. Allows employees to add or remove items from their favorites list. The following table 4 lists the specific data fields of a personal profile. Table 4: Personal Profile Fields 2. System Profile Maintenance The system profile contains configuration values for an instance of the system. The system profile (an example of which is shown in Table 5) is created when the system is installed. It is primarily intended to establish the values for obviousness that will be used when creating profiles for new employees. The system: a. It allows the administrator to change the fields of the system profile, using a simple text editor or a spreadsheet.

Table 5: Fields of a System Profile 3. Maintenance of the Product Information Database The Product Information Database of a company is the collection of item templates, for items that are approved for purchase within the company. Article templates are maintained entirely in the system. An example article template is illustrated in Table 6. The Purchasing Department of a company is normally responsible for maintaining the Product Information Database, helping to make it a precise and valuable resource. The system allows purchasing agents to create, edit, and remove item templates. This functionality is available only to purchasing agents. It allows them: a. Create new article templates The need to create new article templates occurs more frequently when there is a requisition for an item that is not in the Product Information Database. If the Purchasing Agent decides to approve the article, will create a new article template for it, and decide if you add it to the Product Information Database. b. Edit templates of existing articles. A purchasing agent can modify an existing article template (eg, update supplier information or price). c. Remove templates from existing articles. A purchasing agent can deactivate an item from the Product Information Database, if the purchasing agent decides that the item is invalid or is no longer recommended. This can happen for any number of reasons, such as when the relationship with a provider changes, or when a particular item is no longer available with the provider. When a purchasing agent makes such a change, he can use the Organizer's view to verify all pending requisitions, in order to see if there are any that are impacted by the change. d. Read the text files of the suppliers, with the SIC code [WHAT IS SIC?], Map these SIC codes into the internal comfort codes, and then add the relevant articles to the Product Information Database. and. Build and maintain a hierarchical view of the Product Information Database, so that users can find things by navigating through the categories.

Table 6: Article Template • 46 • 47 The system provides a reporting facility to help companies that buy, summarize, analyze, understand, and improve their purchase process. The system comes with a number of predefined reports, which are from purchase patterns (eg, are we buying too much of something, or too little?), Even reports on the process itself (eg, who is not approving in a timely manner). This information can help the company refine its practices, that is, by modifying the approval processes, or by changing the suppliers. 1 • Definition of Reports The system provides a variety of reports to categorize and group the information contained in the system. The reporting mechanism allows employees to parameterize reports and execute them, but not to define ad-hoc reports. Employees can: a. Save the results of any report generated in a file. There are two output formats: one that can be read through spreadsheets, and one that is plain text, for human consumption. b. Print any of the generated reports. c. Define the reporting period for any report. The period of a report can be described as. { All, This Day / Week / Month / Year / Quarter, Last Day / Week / Month / Year / Quarter, Other (where you can specify a specific start and end date)} . The definition of Trimester is stipulated based on the profile of the system. 2. Standard Reports for all Employees The following Table 7 shows standard reports that are available to all employees. Table 7: Standard Reports for All Employees 3. Standard Reports Available for Purchasing Agents Provide the standard reports as shown in Table 8, available to any employee who has the role of purchasing agent. • 50 Table 8: Standard Reports for Purchasing Agents System Environment Approval Flow Each company has its own approval process in general to define who has to approve each requisition. The system models this process with a set of approval rules, which each company can parameterize and extend. The approval rules are defined as part of the installation process, but can be modified by the client's system administrator at any time. Preference approval rules are stored in text files, which can be edited with any text file editor. 1. Parameterization of Approval Rules The simplest form of approval rules is a tabular file format, which describes the values to be used in the rules. This file format allows the client to: a. Parameterize the approval rules by editing the values in the tabular file. For example, a company can change the dollar amounts that will be associated with approval by different administrative levels, without changing the approval rule itself. b. Change the parameters while the system is running. The system will read the new parameters without lost time. 2. Approval Rules To describe the approval rules, the system provides a simple writing language, generally flexible enough to describe any condition or set of conditions for the approval of the file. In one modality, each rule has: a. A justification field, to be used as an explanation for the reason why the rule was invoked. b. A predicate, which determines when the rule is applied. The predicate can be based on any field of the requisition, such as convenience, currency, purchase amount, shipping address, or even the custom-made (ie, extensible) fields that this particular company has added. c. A consequent, for when the predicate is applied. The consequent designates which paper or papers need to approve the requisition. For example, a company could write a rule that requires employees with the role of purchasing agent to approve any requests that are for amounts greater than $ 200, and that have a shipping address that is different from the shipping address because of obviousness. The particular amount, $ 200, will be specified in the tabular file; the predicate-consequent will be in the rules file. d. One way to describe which approvals can be done in series, and which can be done in parallel. For example, an organization may want the approvals of the administration chain to go serially, but other approvals (such as Facilities and IS) go in parallel. 3. Buyer Allocation Rules Each line item in a requisition has an assigned Purchasing Agent. The system establishes the assigned Purchasing Agent before submitting the request for approval. Each company can define its own rules for the way buyers are assigned, using the same mechanism used to define the approval rules. For example, a company might want the buyer's allocation to depend on the type of convenience as well as the amount of the purchase. 4. Escalation and Time Out The system provides the ability to scale an approval, either manually or automatically, for times when an approver has not responded to an approval request. Escalation of an approval request moves it up the management chain, to the immediate supervisor of the approver. The system provides the following features for escalation: a. An applicant can scale an application manually. b. If an approver has not responded to an approval request within the escalation time period defined in the system profile, the system will scale the approval request automatically. Escalation will continue up the chain as necessary, until someone takes action, or until there is an employee without a supervisor. c. If a requisition has not been approved within a period of time, as specified in the system profile, the requisition will be time-out. That is, any request that has been submitted but has not yet been approved within the specified time frame will be escalated to the administrator. d. Once an approval request has escalated, the original designated approver can no longer take action on that request. 5. Delegation of Authority The delegation of authority (DOA) is a substitution of one approver by another in a specified period of time, that is, when an approver is on vacation. In one modality, the system supports the delegation of authority in the following ways: a. Any employee may delegate his authority to another employee for some period of time. The DOA includes a start date, a final date, and a comment field that explains why the DOA is in effect. The DOA is stored in the employee's personal profile: as all changes to personal profiles, the delegations of authority are subject to the rules of approval of the company. An employee may not delegate more than one person at a time, or divide the DOA between more than one designee. b. If there is a delegation of authority for an employee, and the date for delegation has not expired, then the system will allow the delegate to approve instead of the employee. c. Register all authority delegations as part of the audit trail. Shared Services 1. Authentication and User Rights All employees must register and authenticate in order to use the system. There are three classes of users in the system: Purchasing Agents, Administrators, and Employees. Purchasing Agents and Administrators are allowed to do some operations that Employees do not have permission to do. Table 9 below lists the operations that are restricted to certain classes of users: Table 9: Rights of Users that Require Authentication 2. Events v Notification The system provides a notification mechanism, designed to help keep all interested parties informed about what is happening with a particular request. The system defines a set of events, which are the triggers to notify employees, and the recipients of notifications. In a modality, the set of events is not made to measure. The system: a. It will provide an email notification for each of the defined events, which are summarized in the following Table 10. The preference notification message includes a hypertext link with the Organizer, b. It will allow employees to tailor the frequency of notifications per event. The frequency of notifications can be specified as Never, Immediate, or Intervals, where the interval is an integer number of Seconds, Minutes, Hours, or Days. The decision as to whether employees are allowed to specify is never preferably part of the system profile - that is, the choice of whether it is possible to deactivate the notification entirely, is a decision made on a company-by-company basis.

Table 10: Events that Require Notification 7. Expiration time for Notifying the applicant that delivery is required: if the date of a reception is passed Need, and an acknowledgment of receipt has not been sent. 8. The requisition has been escalated Notify the current approver and 1 approver to the approver of the next activated, and to the level applicant. 9. The requisition is going to scale Notify the approver soon.

. The requisition will take time to notify the applicant outside soon. 11. The requisition has time to notify the applicant outside. 3. Database Support The system uses a database to store all internal data, and to record all transactions between the clients and the Server of the Company. In one modality, this database resides in an Oracle Database Server. 4. Customer Support and Feedback There is an interest in feedback from customer sites, to understand how customers are using the system, and how they would like to use the system. To encourage this feedback, the system: a. Provides a simple feedback command, to allow customers to make suggestions in email. b. Provide a newsgroup or support website. Send serious system errors as they are presented. d. Send line item account statistics monthly, by email, at the end of each month. 5. Email Integration The system integrates with the email programs that are already in place (eg SMTP), so that the system can send notifications to employees via email. Commercial Modules Commercial modules are separable parts of the system. Sorting Modules A sorting module is the piece of the system that takes a completely approved requisition, and presents it to satisfy itself. When a requisition has been fully approved, the system will: • Seal the time in it with the date and time of the final approval. • Verify the requisition to determine which suppliers are involved, and choose a provider site if there is more than one site for the specified provider. • Choose the preferred ordering module for each of these providers, and use it to transmit the order. The three ordering modules are a Purchase Card Module, Direct Order Module, and a Purchase Order Module. 1. Purchase Card Module The Purchase Card order module supports the use of purchase cards as a payment mechanism. Shopping cards (c-cards) can be associated with employees or private providers, but they are maintained by an administrator, who makes sure that the cards are valid and are being used in an appropriate manner. Purchase card transactions are reconciled on some regular basis with the bank that issued the purchase card. The system maintains the following data associated with each purchase card, as shown in Table 11 below. Table 11: Data Associated with a Purchase Card The shopping card module: a. It allows managers to assign cards to employees, and modify the expiration date or authorization limits on shopping cards. b. For each fully approved requisition, verify if a purchase card can be used for this purchase: • Make sure the supplier accepts the purchase cards. If not, choose a different ordering module. • Choose a shopping card number: if the provider has a phantom shopping card number, then that is the preferred shopping card number. Otherwise, if the employee has a purchase card number, he uses it. Otherwise, choose another ordering module. • Verify the amount of the purchase. If you exceed the limit per transaction on the purchase card, then choose another ordering module. c. For each transaction that uses a shopping card, the system records the data as shown in Table 12. The data is reconciled with the banks on a monthly basis, using a printed report of the transactions. The reports used for reconciliation show a "permitted variation", because the values (ie, the total order of the purchase card) do not include taxes and shipments, but the bank values do.

Table 12: Data in a Transaction dß Purchase Card dß Reports When a company buys this module, there are additional standard reports available. Reports are provided as described later in Tables 13 and 14.

Table 13: Reports for Employees Report Name Priority Statement of account for the employee for the 1 (High) period of the credit card. List each transaction.

Table 14: Reports for Purchases 1. Direct Orders (DO) The direct order module is a sorting module that supports the communication of orders directly between the buyer and the supplier, without storing the requisition in an ERP system. There are usually no limitations on orders under direct billing contracts. The direct order agreement includes terms and conditions, and specifies the frequency of billing. If there is a direct order contract with a supplier, then the system: a. Verify that the transfer method for direct order has been designated in the article template. If the purchase order (PO) or the DO order module has not been designated in the article template, then the supplier profile for the transfer method will be verified. If the provider's profile indicates direct order, then that is the method. Otherwise, it is treated as a PO. b. Send the requisition directly to the provider by fax or email, as specified in the provider's profile. All requisitions transmitted to the supplier are recorded in the audit trail database. The reception of recognition information is maintained only in the system. c. Provides a report of transactions from the system to help the Purchasing Department reconcile with the supplier's master report. The frequency of the report will mirror the frequency of the report from the provider. 2. Purchase Orders The purchase order module is an ordering module whose case results in a purchase requisition in the ERP system. The system transmits the requisition to the ERP adapter, as an ERP requisition. Once the requisition is in the ERP, the Purchasing Agent can manipulate it with standard ERP operations to complete the process. For example, the agent usually auto-creates a purchase order from the requisition, prints it, and sends it to the supplier for your satisfaction. Reception After an order is approved and presented and transferred to the supplier, eventually the supplier will ship the item, and the applicant will receive it. When an article is received, the applicant must acknowledge receipt of the article; The receptions are the final acknowledgment to trigger the payment. The system includes a user interface for recognition reception, which allows employees to register that different items have been received. The receptions will be stored in the system, and there will be no interaction with the underlying ERP, if there is an ERP present. A level lever of the system that can be set during the implementation activates the reception module. 1. Acknowledgment of Receipt of an Article The system provides a simple form (whose fields are shown later in Table 15) for the employee to indicate that he has physically received an item. This reception interface: a. It allows an employee to recognize the reception of an ordered item, and to record the number of items received, showing the information in the following table. The employee can recognize either a single line item, or a complete requisition. b. Allows an employee to reject an entire requisition, or an individual line item. When an employee chooses to reject something, the system will request a free comment, describing the nature of the rejection. There are no partial rejections on quantity, although the employee can transmit that information in a comment.

Table 15: Fields for Reception Recognition Approvals and Notifications If the employee rejects an item, the system notifies Purchases, and records the rejection. Reports The reports shown in Tables 16 and 17 can be added to the report core list included with the core system.

Table 16: Reports for Employees Table 17: Reports for Purchases System Adapters The preference system uses adapters whenever possible, thus avoiding duplicating any information that is already available. But the system does not depend on -the presence of any of these adapters, and can run independently when a company does not have a particular service, or there is no adapter available for it. Directory Service Adapters The system preferably uses the user name and password information from a directory service within the company, if this service exists in the company, and if the company has the appropriate adapter. If the company does not have an authentication service, the system itself stores the employee's name and password information, allowing appropriately authorized system administrators to create new users. 1. LDAP Authentication Adapter A directory service adapter for LDAP is provided. LDAP (Lightweight Directory Access Protocol) is a protocol that provides a conventional method for Internet clients, applications and WWW servers, to access directory information over the Internet. The LDAP adapter: a. It uses the LDAP protocol to access the passwords of the entire corporation, and use those passwords to authenticate employees. b. It provides users with real-time authentication, if the client's LDAP server is fast enough to support it.

Adapters of the Human Resources Management System HRMS systems are used to maintain employee information, such as names, emails, and structure in the organization. If there is no HRMS adapter available, the system supports basic employee management, storing employee data in its own database, and allowing appropriately authorized system administrators to Add / Delete / Modify employees. 1. PeopleSoft HRMS adapter An HRMS adapter is provided for the PeopleSoft system, Version 5. The PeopleSoft adapter: a. It extracts employee information from the PeopleSoft database on a regular basis, and updates the system with any new employees that have been created. When updates of new employees arrive, the system fills the fields from the HRMS when they are available. Other additional fields are initialized with the values by obviousness from their immediate supervisor, or from the system profile, if the administrator is not in the system or can not be located. b. Extract the fields shown in the following Table 18.

Table 18: Human Resources data ERP adapters ERP adapters are pieces that integrate the system with an ERP system of the company. The adapters are custom-made for each ERP (eg, Oracle 10.4, 10.5, 10.6, SAP, Baan, D &B, etc.). One system mode provides adapters for Oracle ERP Versions 10.4, 10.5, and 10.6. 1. Requisition Adapter The requisition adapter is the basic part that is integrated with the ERP. It pushes the requisitions completely approved towards the ERP, where they become Purchase Orders in the ERP System. The adapter can pull back the purchase order numbers for those requisitions, and store the purchase order numbers as extrinsic data fields associated with each line item. The adapter pushes the following data for each line item: Description Comments Name of the applicant, if the applicant exists in the ERP. If there is no such username in the ERP, then there will be a standard user who receives everything. Approvals Quantity Unit price Unit of measure Shipping and delivery addresses Part number Part description Accounting information Shipping details - carrier and method of transport Provider 2. Measurement Units Adapter The system pulls the set of Units of Measure from the ERP, and uses them in the user interface. The system pulls the following data: Name Abbreviation Base unit of measure Conversion to the base unit of measure 3. Accounting Information Adapter The system pulls accounting information from the ERP, with any accounting details defined for the company. For example, the accounting fields could be: Company name Commercial unit of the company Department Account Project information . Comfort Code Adapter The system pulls the comfort code information from the ERP. The exact structure of the codes of comfort depends on the company. For example: Comfort name Accounting information for convenience . Currency Rate Table Adapter The system pulls the currency rate tables from the ERP, using the rate tables whenever a currency conversion is required. The adapter pulls a currency table and conversion rates for each one, pulling the following information: Currency name Currency rate Date when the specified rate is valid List of valid currencies 6- Provider Profile Adapter The system pulls the provider information from the ERP, on a periodic basis, and stores that supplier information in supplier profiles. This adapter: a. Pull the newly created providers from the ERP. Purchasing Agents need to create new supplier profiles when someone requests a new item. That is, when a requisition includes an ad-hoc line item, the Purchasing Agent locates an appropriate supplier, and adds a profile for that supplier in the ERP. Then the changes back to the system are pulled. The profile of the supplier in the system has the fields shown below in Table 19. Table 19: Supplier Profile Data Characteristics of a Modality: System Requirements 1. Scalability a. Provides a system that supports at least 10,000 requisitions per month. b. Provides a system that supports at least 20,000 suppliers. c. Provides a system that supports at least 35,000 employees. d. Provides architecture support for multiple instances of the system at a single site. Each instance of the server supports only one ERP instance. There are no "scrolling" capabilities between multiple server instances. 2. Supported client platforms A Java client that runs inside a Web browser, with Java support. It is tested on the following platforms and systems: • Microsoft * Internet Explorer * 3.01 and later, in Windows NT 4.0. Microsoft * Internet Explorer * 3.01 and later, running on Windows 95. Microsoft * Internet Explorer * 3.01 and later, running on Apple Macintosh *. Netscape * Navigator * 3.01 and later, running on Windows NT *. Netscape * Navigator * 3.01 and later, running in Windows 95 *. • Netscape * Navigator * 3.01 and later, running on Apple Macintosh *. Netscape * Navigator * 3.01 and later, running on Sun Solaris. Netscape * Navigator * 3.01 and later, running on HP-UX (HP Unix). 3. Server Supported Platforms a. Provides a server implementation that runs on a dedicated Intel * Pentium Pro system running Microsoft * Windows NT * 4.0.

Supports the following minimum server configuration: Processor - Intel * Pentium Pro or equivalent, 200 MHz or greater. Cache memory - 256 KB cache or greater. • Memory - 128 MB RAM or greater. Storage - 4 GB hard disk or higher, depending on the size of the database. b. It provides a server implementation that runs on a Sun Machine running Solaris 2.5.1, Oracle RDBMS 7.3.2.3, and Netscape Enterprise Server 2.0.1. 4. Configuration a. Provide a template to gather basic information about the site before installation: Central DBMS, operating system, versions of ERP and HRMS interfaces, e-mail interfaces, accounting and purchasing procedures, supplier data, client hardware and software, supported search engines, network configuration, and business rules. b. Configure the extensible fields and the approval rules, using a text file editor. 5. Sowing the Database For compatibility during the transition period, the system provides the ability to seed the database with requisitions that were approved manually, outside the system. This functionality is intended as a convenience to help a company make the transition from paper requisitions to electronic ones. The system allows an administrator to enter a completed paper requisition in the system, without routing for signature. The requisitions introduced in this manner will appear in the reports, but will not generate approval requests or notifications, and will not be part of the Product Information Database without the explicit intervention of a Purchasing Agent. 6. Independent Systems This section describes the system features that are available only to provide basic functionality when the system is independent: when there is no ERP adapter present. to. It provides the ability to print purchase orders and transmit them to the supplier. Printed purchase orders include standard promissory notes (such as the provider's terms and conditions), and a purchase order number. This is the only time that the system generates a purchase order. b. Allows Purchasing Agents to modify the generated purchase order before sending it to the supplier. c. Provides a user interface to add providers, providing a simple version of the provider adapter functionality. It should be understood that different alternatives to the embodiments of the invention described herein can be employed in the practice of the invention. It is intended that the following claims define the scope of the invention, and that the methods and apparatus within the scope of these claims, and their equivalents, be covered by the same.

Claims (34)

1. NOVELTY OF THE INVENTION Having described the foregoing invention, it is considered as a novelty, and therefore, property is claimed as contained in the following: CLAIMS 1. A software system for efficient procurement of operating resources within a company, which comprises: an element generating requisition records to generate a requisition record for a requisition, indicating the requisition record at least one operation resource that an applicant wishes to purchase, generating the item generating requisition records, the requisition record in response to a combination of: an introduction by an applicant; and operation resource information in a database of operation resource information; a determining element of the approval route, which responds to the requisition record and the approval rules in a database of approval rules, to determine an approval route for the requisition record, among several of a plurality of possible approvers , required to approve the requisition record; a handler element of the approval path, to guide the requisition record along the determined approval path, where the handler element of the approval path generates a global approval indication in response to the requisition record running through successfully the approval route. The system according to claim 1, characterized in that it further comprises: an order generating element for generating an order record for a provider of the desired operation resource, and for communicating the order to the supplier. 3. The system according to claim 2, characterized in that the requisition record includes an indication of the provider. The system according to claim 2, characterized in that the order generating element includes an element for determining a method for communicating the order to the supplier, in response to a supplier database. 5. The system according to claim 1, characterized in that the determining element of the management element of the approval route determines the approval route for the requisition record at least in part in response to an amount field of purchase in the requisition record. 6. The system according to claim 1, characterized in that the element generating the requisition record includes an element to retrieve information about the requester, from a database of personal profile associated with the applicant. 7. The system according to claim 6, characterized in that the information retrieved from the personal profile includes address information representing a destination to which it is desired to send the operation resource, and a department where the applicant works. 8. The system according to claim 6, characterized in that it also includes an element for the applicant to annul information about the applicant, retrieved from the personal profile database associated with the applicant. 9. The system in accordance with claim 1, characterized in that the item generating requisition records includes an element to assign a unique identifier to the requisition. The system according to claim 1, characterized in that the requisite register generating element includes an element for receiving a unique identifier assigned to the requisition by the user through a user input element. The system according to claim 1, characterized in that the requisite register generating element includes: an element for receiving an indication of a holding time from the user by means of a user input element; where the handler element of the approval route begins to guide the requisition along the approval path when the holding time is presented. 12. The system according to the one claimed in claim 1, characterized in that it also includes: an element for presenting a requisition in response to the indication of global approval; wherein the requisite register generating element includes: an element for receiving an indication of a hold time from the user by a user input element; where the requisition submitting element submits the requisition only when the holding time is presented. 13. The system according to claim 1, characterized in that the requisite registration generating element includes: an element to receive the entry from the requester, specifying a currency unit, and an item to report a purchase amount for the operation facility in units of the currency unit specified. The software system according to claim 1, characterized in that it further comprises: an adapter element for recovering the data from a legacy database program; wherein the requisite register generating element fills the fields of the requisition record using the data retrieved from the legacy database program; whereby duplication of already available data is avoided. The software system according to claim 14, characterized in that the adapter element includes a directory service adapter, for interconnecting with a company directory service. 16. The software system according to claim 15, characterized in that the adapter element is a human resource management system adapter for interconnecting with a human resources management system of the company. The software system as claimed in claim 16, characterized in that the adapter element includes an element for interacting with the legacy database program on a periodic basis. 18. The software system according to claim 14, characterized in that the adapter element includes an element that responds to the indication of global approval, to transfer the requisition to an ERP system of the company. 19. The software system according to claim 18, characterized in that the adapter element also includes an element to recover, from the company's ERP system, a purchase order number corresponding to the requisition. 20. The software system according to claim 18, characterized in that the adapter element also includes an element for retrieving the information from the provider from the company's ERP system. The software system according to claim 20, characterized in that it also comprises: an element for creating a supplier profile based on the information of the provider recovered from the company's ERP system. 22. The software system according to claim 1, characterized in that: the approval rules include each one, a predicate and a consequence; and the approval path determining element determines whether a particular rule of the approval rules is applied, by applying the predicate to at least one field of the requisition record; and when the approval route determining element determines that a particular rule of approval rule applies, the approval route determining element determines the approval route with respect to that approval rule, by applying the consequence of the approval rule. 23. The software system according to claim 1, characterized in that: the database of approval rules includes a definition of the order from which, in its case, the required approvers must approve the requisition in series, and that, where appropriate, can approve the requisition in parallel; and the approval route handler element operates in response to the order definition. 24. The system according to claim 1, characterized in that the approval route handler element includes: a notification element, which responds to a position of the requisition record along the approval path, to notify to any approver who is in that position, who is required to take some action on the requisition. 25. The software system according to claim 24, characterized in that the approval path handler element includes: a state change recognition element, which recognizes a change in the requisition status, as a result of the action taken by an approver, and a notification element, wherein the notification element operates in response to the status change recognition element, to notify the requester of the status change. 26. The software system according to claim 1, characterized in that: the measure taken by the approver in a particular position in the approval path includes one of: approving the requisition; and deny the requisition; and the approval route handler element moves the requisition to a next position in the approval path, in response to the approver in the particular position approving the requisition. 27. The software system according to claim 26, characterized in that: the approval route handler element includes an unresponsive handler element, which responds to a quantity of time during which the requisition is in a particular position in the approval path, without any action being taken by the approver in that position, to move the requisition to another approver that has a predetermined relationship with the approver who did not take the measurement. 28. The software system according to claim 27, characterized in that: the predetermined relation is indicated by a chain of command data defined in an ERP database, and the system also includes an ERP adapter to access to the chain of command data from the ERP database. 29. The system according to claim 26, characterized in that it also comprises: a notification element, wherein, in response to the move of the requisition to the next position in the approval path, the notification element notifies To the approver in that next position, that approver is required to take a measure on the requisition. 30. The software system according to claim 26, characterized in that: the measure taken by the approver at the particular location in the approval path further includes: modifying at least a portion of the requisition record; and the approval handler element includes a response element to the modification, which operates in response to an approver modifying a requisition, to cause the approval path determining element to determine a replacement approval path, in response to the requisition modified. 31. The system according to claim 1, characterized in that the approval path handler element includes an unresponsive handler element, which responds to a request from the requester, to move the requisition from a first approver that has not taken measurements, until a second approver has a predetermined relationship with the approver who did not take action. 32. The system according to claim 31, characterized in that, in response to moving the request from the first approver, the approval path handler element prevents the first approver from taking action on the requisition. 33. The system according to claim 31, characterized in that the predetermined relationship is at least partially defined in the approval rules. 34. The system according to claim 1, characterized in that it also includes: a delegation element of authority to receive a request from a first approver, to delegate the authority of the first approver to a second approver, by configuring the approval path handler element, in order to modify the approval path, in such a way that the approval path includes the second approver instead of the first approver.