WO2001002927A2

WO2001002927A2 - Integrated business-to-business web commerce and business automation system

Info

Publication number: WO2001002927A2
Application number: PCT/US2000/016739
Authority: WO
Inventors: Charles Wong
Original assignee: Charles Wong
Priority date: 1999-06-17
Filing date: 2000-06-16
Publication date: 2001-01-11
Also published as: WO2001002927A3; AU5621300A

Abstract

The present invention, generally speaking, provides within a self-sufficient single application a general business solution (figure 2B) for end-to-end, continuous-flow, business-to-business electronic commerce, enabling the virtual enterprise in which the entire business can be run via a web browser (figure 3). The self-sufficient single application (figure 2B) provides flexibility, affordability and business scalability. Flexibility is achieved using a unitary 'solid-state' web enabled database (figure 3) having a 'lowest-common-denominator' item record, or central item table, that serves as the fundamental building block of the system. (The level of granularity of the item record is that used in common commercial exchange--e.g., boxes, pounds, gross, hours, etc.--depending on the nature of the item. The measure may be physically measure or a measure of time, or any other appropriate measure. That is, if a good or service can be measured, then the present system may be used to deal in that good or service.) Each item record (figure 3) contains business domain-specific fields pertaining to some and preferably all of the following business domains: products (figure 3), payments (figure 3), performance (figure 3) and personnel (figure 3).

Description

INTEGRATED BUSINESS-TO-BUSINESS WEB COMMERCE AND BUSINESS AUTOMATION SYSTEM

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to database systems for business-to-business electronic commerce.

2. State of the Art

Just as the industrial revolution resulted in the automation of man power, the information revolution centers around the automation of brain power. As business becomes increasingly automated, particularly among small and medium size businesses, three "abilities" become key: flexibility, affordability and scalability. Existing business automation software is complex and expensive but largely unable to deliver these three abilities at the same time.

In one aspect, flexibility results from having all of the data and processes a business needs, encompassing all relevant domains, in one place. Existing Enterprise Resource Planning (ERP) software from such vendors as Baan, Oracle, Peo- plesoft, J.D. Edwards, etc., are based on this premise. Although all of the relevant data may be housed in one place, the mechanism for processing data, however, must be laboriously "plumbed" during the course of an often lengthy and often painful implementation process. Changing the way data is processed across domains is not easy. The net result is substantial inflexibility. Such ERP software typically does not provide for electronic commerce (the new business domain for the information age). Further system integration is required to provide electronic commerce capabilities. Because conventional ERP systems are proprietary closed systems, typically running UNIX, complex interfaces are required to interface to other similarly built software in different various domains.

ERP software and ERP implementation are exorbitantly expensive. Scalability in conventional ERP systems suffers in two respects. First, although conventional ERP systems scale up well to meet the needs of massive enterprises, they do not scale down well below a certain scale and therefore are not well-suited to small and medium size businesses, which are by nature required to be more flexible and quick to respond than large businesses, which are more rigid. Software designed for large business therefore is naturally less flexible and cannot easily be configured for flexible, quick response. Second, scalability is typically achieved through a strategy of modularity. Modularity, however, necessitates wnct on / compartmentalization and duplication of data, resulting in data synchrony and data integrity problems.

Likewise, available e-commerce software is largely unable to deliver the three abilities of flexibility, affordability and scalability at the same time. Typically, a business establishing and hosting its own web site the user is required to anticipate eventual demand and build commensurate infrastructure from the outset to avoid painful and costly expansion/conversion (e.g., from PCs to Unix). Flexibility is hampered by not having all of the data a business needs in one place, except as the e-commerce software may be linked to ERP software. Such linking is often fraught with difficulty.

In the conventional e-commerce system scalability approach, the existing business size is not a constant and is determined by outside influences beyond the control of the business executive. Data is stored at a single data center as exemplified in Figure 162, because replicating and mirroring of data is limited by physical distance and latency. The cost of entry for such a business is very high. Furthermore, success comes at a high price— namely, the need to build a new, expensive data center to accommodate demand, even incremental demand exceeding current capacity. Failure to deliver capacity as needed can result in interruptions in service, an inability to accept new members, etc.

SUMMARY OF THE INVENTION The present invention, generally speaking, provides within a self-sufficient single application a general business solution for end-to-end, continuous-flow, business-to-business electronic commerce, enabling the virtual enterprise in which the entire business can be run via a web browser. The self-sufficient single application provides flexibility, affordability and business scalability. Flexibility is achieved using a unitary "solid-state" web-enabled database having a "lowest- common-denominator" item record, or central item table, that serves as the fundamental building block of the system. (The level of granularity of the item record is that used in common commercial exchange— e.g., boxes, pounds, gross, hours, etc.— depending on the nature of the item. The measure may be a physical measure or a measure of time, or any other appropriate measure. That is, if a good or service can be measured, then the present system may be used to deal in that good or service.) Each item record contains business domain-specific fields pertaining to some and preferably all of the following business domains: products, payments, performance and personnel. These business domains encompass customers, partners, finance, logistics, services, etc. The database application software reads item records, organizes selected relevant information from the item records, and presents the selected relevant information as domain-specific displays. Functionality to be added to the system can be readily supported by adding appropriate fields to the item record. For example, an "XYZ" domain may be added to the database by adding fields X, Y and Z to the item record. The basic structure of the database does not change, only the way data is arranged and viewed. The design is therefore very flexible and accommodates changes very easily. This organization allows the database to at the same time be all-inclusive, on the one hand, and provide ready data access with high data integrity, on the other hand. Affordability is achieved using inexpensive hardware, i.e., low-cost, mass-market commodity hardware such as PCs. Business scalability, made possible due to the inherently self-sufficient structure, is achieved by aggregating PCs within a computer network such that, given a universe of business functions and a universe of business partners, data required for implementing the universe of business functions is stored on each PC for different subsets of business partners. Similarly, the universe of business functions may be split and implemented on different machines, providing business scalability. Requests from business partners are routed to the appropriate PCs based on the identity of the requestor. Data is drawn from the various PCs as required for purposes of overall business reporting. This scenario is the reverse of having all data of a business in one single database.

Business scalability (scaling a business to the right size) is a virtual and incremental software approach. The right size is a constant that can be controlled by the business executive within the constraints of the relevant technology platform (low-cost, mass-market, commodity machines). The power of such machines is continually advancing, with the result that constraints are pushed farther and farther back. Data can be distributed throughout the world. Business scalability is very different from conventional system scalability (scaling the computer system to the existing business size), which represents a physical, discrete hardware approach.

The present system allows the typical small to medium size business to "break the hourglass" and eliminate the pinch point between supply and demand, which is the ability of the business to match supply and demand, to facilitate and complete transactions. By automating the entire business and placing it on the web, the pinch point is eliminated. If the Internet is viewed as a sea of demand and supply, then the present system can be described as sorting, matching and managing supply and demand. Coupled with the ability to scale to demand, this characteristic allows for virtually unlimited growth.

BRIEF DESCRIPTION OF THE DRAWING The present invention may be further understood from the following description in conjunction with the appended drawing. In the drawing:

Figure 1 is a block diagram illustrating conceptually a conventional business process; Figure 2 is a block diagram illustrating conceptually an automated business process in accordance with the present invention;

Figure 3 is a generalized block diagram of a system for business-to-business Web commerce in accordance with an exemplary embodiment of the invention;

Figure 4 is an illustration of a starting Web screen display;

Figure 5 is an illustration of a first product categories screen display;

Figure 6 is an illustration of a further product categories screen display;

Figure 7 is an illustration of still a further product categories screen display;

Figure 8 is an illustration of a screen display displaying printer cables;

Figure 9 is an illustration of a shopping basket screen display;

Figure 10 is an illustration of a screen display allowing the user to search for products by manufacturer;

Figure 11 is an illustration of a multi-search screen display;

Figure 12 is an illustration of a core products search screen display;

Figure 13 is an illustration of a core products search results screen display;

Figure 14 is an illustration of a Products Search /PID screen display;

Figure 15 is an illustration of a PID search results screen display;

Figure 16 is an illustration of a PID screen display;

Figure 17 is an illustration of a Products Search/APL screen display;

Figure 18 is an illustration of a Products Search/Previous Quotes screen display;

Figure 19 is an illustration of a quotes search results screen display;

Figure 20 is an illustration of a quote screen display;

Figure 21 is an illustration of a PID maintenance screen display;

Figure 22 is an illustration of an active PIDs screen display;

Figure 23 is an illustration of an APL maintenance screen display;

Figure 24 is a company APL maintenance screen display; Figure 25 is an illustration of a return request screen display;

Figure 26 is an illustration of an RMA multi-search screen display;

Figure 27 is an illustration of an RMA search results screen display;

Figure 28 is an illustration of an RMA record screen display;

Figure 29 is an illustration of a tracking screen display;

Figure 30 is an illustration of a sales order status screen display;

Figure 31 is an illustration of a sales order search results screen display;;

Figure 32 is an illustration of a Tracking — Return Product and Service Part Status screen display;

Figure 33 is an RMA status search results screen display;

Figure 34 is an illustration of a more detailed RMA status screen display;

Figure 35 is an illustration of a Tracking — Product Purchase History screen display;

Figure 36 is an illustration of a Tracking — Product Return History screen display;

Figure 37 is an illustration of a return history search results screen display displaying search results;

Figure 38 is an illustration of a Reports screen display;

Figure 39 is an illustration of a Back Order Reports screen display;

Figure 40 is an illustration of a Monthly Sales Reports screen display;

Figure 41 is an illustration of a resulting search results screen display;

Figure 42 is an illustration of a Packing Slips screen display;

Figure 43 is an illustration of a resulting search results screen display;

Figure 44 is an illustration of a packing slip screen display displaying a selected packing slip;

Figure 45 is an illustration detailing the authority of various internal users with respect to security parameters in accordance with an exemplary embodiment;

Figure 46 is a diagram of a typical lineage (authority) tree; Figure 47 is an illustration of a database customer screen display;

Figure 48 is an illustration of a company price list screen display;

Figure 49 is an illustration of one of a series of dialogs used to set Web authority for an employee of a customer;

Figure 50 is an illustration of another of a series of dialogs used to set Web authority for an employee of a customer;

Figure 51 is an illustration of another of a series of dialogs used to set Web authority for an employee of a customer;

Figure 52 is an illustration of another of a series of dialogs used to set Web authority for an employee of a customer;

Figure 53 is an illustration of another of a series of dialogs used to set Web authority for an employee of a customer;

Figure 54 is an illustration of a dialog used to confirm employee information at the conclusion of Web authorization;

Figure 55 is an illustration of the corresponding screen display as shown in Figure 48, following Web authorization;

Figure 56 is a block diagram of a conventional Web commerce computer architecture in which different functions are automated on different computing platforms, necessitating multiple interfaces;

Figure 57 is a block diagram of the present Web commerce computer architecture in which all functions are automated on a single Web-enabled database, necessitating only a single interface;

Figure 58 is an illustration of a partial database schema of one implementation of the system of Figure 3, showing primary files and relationships;

Figure 59 is a block diagram illustrating an automated business process in accordance with an exemplary embodiment of the invention;

Figure 60 is an illustration of a Sales-MWS screen display;

Figure 61 is an illustration of a Quote screen display;

Figure 62 is an illustration of a Products screen display;

Figure 63 is an illustration of a MWS screen display;

Figure 64 is an illustration of a Purchasing view of a PRIS (Purchasing/ Shipping/Receiving/Installation) screen display; Figure 65 is an illustration of a Receiving view of the PRIS screen display;

Figure 66 is an illustration of an Installation view of the PRIS screen display;

Figure 67 is an illustration of a Shipping view of the PRIS screen display;

Figure 68 is an illustration of a PRIS Item Detail screen display;

Figure 69 is an illustration of an Expedite view of the PRIS screen display;

Figure 70 is an illustration of an Ordered Not Received screen display;

Figure 71 is an illustration of a Received Not Shipped screen display;

Figure 72 is an illustration of an Expedite pop-up, allowing expedite status to be set from a MWS screen display;

Figure 73 is an illustration of an RMA screen display;

Figure 74 is an illustration of an Add RMA screen display used to initially create an RMA;

Figure 75 is an illustration of an RMA add records screen display used to add information to an RMA;

Figure 76 is an illustration of an RMA Automatic Request Completion file;

Figure 77 is an illustration of an RMA Automatic Approval Limit file;

Figure 78 is an illustration of a Customer RMA Automatic Approval file;

Figure 79 is an illustration of a Vendor RMA Automatic Approval file;

Figure 80 is an illustration of a Manufacturer RMA Automatic Approval file;

Figure 81 is an illustration of a Web page used to automatically provide a customer with an RMA number in accordance with the foregoing automatic approval process;

Figure 82 is an illustration of a Sales Tax Register screen display, including formulas used to calculate figures to be entered within each line of a sales tax return;

Figure 83 is an illustration of a Customer Invoices screen display;

Figure 84 is an illustration of the Customer Invoices screen display showing collections information within a pop-up window;

Figure 85 is an illustration of the Customer Invoices screen display show- ing collections information by customer within a pop-up window;

Figure 86 is an illustration of a Customer Payments screen display;

Figure 87 is an illustration of an OverUnderPay screen display;

Figure 88 is an illustration of an OverUnderPay details screen display;

Figure 89 is an illustration of a Vendor Invoices screen display;

Figure 90 is an illustration of an AP Add Invoices screen display;

Figure 91 is an illustration of a Vendor Invoice display;

Figure 92 is an illustration of a Daily Vendor Verification screen display;

Figure 93 is an illustration of a Vendor Payment Register screen display;

Figure 94 is an illustration of an Add Invoices screen display having superimposed thereon a dialog window used to enter the period for a freight bill;

Figure 95 is an illustration of an Accounting Setup defaults screen display;

Figure 96 is an illustration of a display screen used to add an account to a Chart of Accounts file;

Figure 97 is an illustration of a Chart of Accounts screen display;

Figure 98 is an illustration of a Chart of Accounts — Account Detail screen display;

Figure 99 is an illustration of an Accounts Receivable Customer Setup screen display;

Figure 100 is an illustration of an Accounts Receivable screen display;

Figure 101 is an illustration of an Accounts Receivable — Account Detail screen display;

Figure 102 is an illustration of an Accounts Payable Partner Setup screen display;

Figure 103 is an illustration of an Accounts Payable screen display;

Figure 104 is an illustration of an Accounts Payable — Account Detail screen display;

Figure 105 is an illustration of an account distribution pop-up screen used to allocate an invoice amount between different accounts;

Figure 106 is an illustration of a General Journal output screen display; Figure 107 is an illustration of General Journal input screen display;

Figure 108 is an illustration of a screen display used for financial report definition;

Figure 109 is an illustration of a resulting financial report;

Figure 110 is an illustration of a screen display used for trend report definition;

Figure 111 is an illustration of screen display including a dialog used to select trend frequency;

Figure 1 12 is an illustration of screen display including a window in which trend report data are displayed;

Figure 113 is an illustration of a trend report graph screen display;

Figure 114 is a block diagram of a human resource infrastructure for a virtual organization performance evaluation model;

Figure 115 is an illustration showing in greater detail portions of the human resource infrastructure of Figure 114;

Figure 116 is an illustration of a file structure used to track all performance metrics of interest;

Figure 117 is an illustration showing in greater detail the Factual Measurement Review process of Figure 115;

Figure 118 is an illustration of a seris of selection menus used to select an employee for whom a factual employee evaluation report is to be displayed;

Figure 119 is an illustration of screen displays used to display factual performance analysis results in accordance with an exemplary embodiment of the invention;

Figure 120 is an expanded view of the multiple period screen display of Figure 119;

Figure 121 is an illustration of a dialog displayed as a result of qualification of user inputs during the course of adding invoices;

Figure 122 is an illustration of a further dialog of a similar type as that of Figure 121;

Figure 123 is an illustration of yet a further dialog of a similar type as that of Figure 121; Figure 124 is a partial illustration of a pop-up menu of options available during vendor invoice display;

Figure 125 is a partial illustration of a pop-up menu of options available during vendor invoice display, showing options not shown in Figure 124;

Figure 126 is an illustration of a pop-up menu of options available during customer invoice display;

Figure 127 is an illustration of a pop-up menu of options available during display of items sold;

Figure 128 is an illustration of a pop-up menu of options available during display of sales records;

Figure 129 is a block diagram illustrating a knowledge base, the expression of the knowledge base in screen displays of the present system, and a manner in which the knowledge base is increased;

Figure 130 is an illustration of an RMA Reports screen display;

Figure 131 is an illustration of an RMAs pending approval screen display;

Figure 132 is an illustration of an open RMAs screen display;

Figure 133 is an illustration of a Shipping Reports screen display;

Figure 134 is an illustration of a summary shipping report screen display;

Figure 135 is an illustration of a detailed shipping report screen display;

Figure 136 is an illustration of a POD screen display;

Figure 137 is an illustration of an Accounting Reports screen display;

Figure 138 is an illustration of a date-range-limited accounting report screen display;

Figure 139 is an illustration of an invoice screen display;

Figure 140 is an illustration of a multiple invoice search screen display;

Figure 141 is an illustration of a customer collections screen display, showing a Get Problems dialog;

Figure 142 is an illustration of the customer collections screen display showing a Searches pick box;

Figure 143 is an illustration of the customer collections screen display showing a Select Problem dialog; Figure 144 is an illustration of the customer collections screen display showing a Select Tickler dialog;

Figure 145 is an illustration of a purchasing output screen display;

Figure 146 is an illustration of an expediting output screen display;

Figure 147 is an illustration of a receiving output screen display;

Figure 148 is an illustration of an installation output screen display;

Figure 149 is an illustration of a shipping output screen display;

Figure 150 is a flow diagram illustrating a percolation process for purchasing;

Figure 151 is a flow diagram illustrating a percolation process for receiving;

Figure 152 is a flow diagram illustrating a percolation process for shipping;

Figure 153 is a flow diagram illustrating a percolation process for installation/assembly;

Figure 154 is a flow diagram illustrating supply chain integration/management features of the present invention;

Figure 155 is a diagram of a first electronic template for specifying a customized business relationship;

Figure 156 is a diagram of a second electronic template for specifying a customized business relationship;

Figure 157 is a block diagram of a client/server business automation system in which a common database supports both end-to-end business process automation and sales force automation;

Figure 158 is a more detailed representation of sales force automation capabilities of the the system of Figure 157;

Figure 159 is a detailed listing of RMA types and sub-types;

Figure 160 is an illustration of a screen display showing customer-specific automatic RMA approval criteria;

Figure 161 is an illustration of a Sales Force Automation screen display;

Figure 162 is a block diagram of a conventional monolithic single-location data center; Figure 163 is a table that places in context the present continuous, end-to- end, business-to-business, web-based electronic commerce system;

Figure 164 is a block diagram of a continuous, end-to-end, business-to- business, web-based electronic commerce system in accordance with an exemplary embodiment of the invention;

Figure 165 is a more detailed block diagram of the system of Figure 164;

Figure 166, including Figures 166A, 166B and 166C, is a diagram of a global web-business operations model;

Figure 167 is a diagram illustrating how universal demand documents are created and used;

Figure 168 is a diagram illustrating budget control and automatic invoice payment using universal demand documents;

Figure 169 is a diagram illustrating on-demand supply chain management;

Figure 170 is a block diagram of an Internet-intrinsic, distributed business transaction data cluster;

Figure 171 is a block diagram of another example of an Internet-intrinsic, distributed business transaction data cluster;

Figure 172 is a block diagram showing redundant Internet-intrinsic, distributed business transaction data clusters;

Figure 173 is a block diagram illustrating business scalability in the case of product update;

Figure 174 is another block diagram illustrating scalability using "automaton" PCs;

Figure 175 is a diagram showing the present system acting as a back-end business operation data engine;

Figure 176 is a diagram showing the present system acting as a front-end web business interface;

Figure 177 is a diagram showing the present system acting as an integrated end-to-end business solution;

Figure 178 is a flow diagram illustrating Goal and Task Automation;

Figure 179 is a block diagram illustrating existing supporting infrastructure with which the e-CPU of the present invention may be used;

Figure 180 is a block diagram of an example of an e-CPU-based vertical market/niche market Internet commerce portal;

Figure 181 is a block diagram of a further example of a e-CPU-based vertical market/niche market Internet commerce portal;

Figure 182 is an example of a "Process Flow" menu used for computer- assisted training;

Figure 183 is a chart illustrating criteria for web-based automatic bidding and awarding bids;

Figure 184 is a flowchart illustrating operation of an on-line user manual; and

Figure 185 is a chart illustrating computer-assisted budget preparation.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Architecture

Referring now to Figure 2, the present automated business process may be imagined as a kind of information assembly line. A first system user, or "information worker," having for example a Sales assignment or activity focus, initiates an automated, end-to-end business process by entering information into a client/ server single relational database, which forms a common hub of the automated business process. The user's entry is qualified, or "quality checked," as represented by a checkvalve. Such qualification is "experiential," i.e., derived from actual business experience, and differs qualitatively from the type of data validation typically performed in database systems. If the user's entry fails scrutiny by the system, it cannot be committed to the database. Similarly, the business process cannot continue to the next user. As a result in part of such experiential qualification, verifiable and usable management and enterprise information may be made readily available.

In the case of conventional systems, by contrast, a team of software engineers write an application based on input from groups of users from different departments to produce a definitive, linear workflow. The users, however, cannot anticipate the need for various features prior to using the software. Furthermore, the conception of the programmers may often differ significantly from that of the users. The result often leaves much to be desired. In SAP, BAAN, and other database systems, exceptions to the workflow must all be programmed. Updates are delayed until the next version of the software, at which point the same cycle repeats. Meanwhile, users suffer. Furthermore, because different users have different concerns, little consideration is given to the up-stream and down-stream effects of different user's actions. There results a "disconnect" between the behavior of the system and day-to-day real-world needs.

In the present system, navigation of the workflow is soley determined by me access authority of the user. Workflow components are all pre-existing and preprogrammed. User inputs to the system, however, do undergo a qualification process. Qualification of user inputs has multiple facets. First, each user is accorded limited access privileges. An authority check is therefore performed to ensure that the user is authorized to make the entry being attempted. Second, the entry is checked in accordance with business rules that embody best practice as determined from an analysis of expected parameters and how various values of those parameters affect possible outcomes downstream. Thirdly, entries, even after then are committed to the database, are subjected to intelligent consistency checks in order to detect discrepancies and provide feedback to allow for correction. If input qualification is successful, then succeeding events in the sequential business process are triggered.

Each worker in turn builds upon the information base established by preceding workers, and each workers entries are rigorously qualified. For example, following sales, process flow may continue to Sales Support, Accounting, Purchasing, Receiving, Assembly, and Shipping.

During the process external influences occur. An external influence may be a communication from a customer or vendor, for example, to either convey information or to view information stored in the central database. An example of an external influence might be a vendor special rebate. Information may be conveyed by electronic means (e.g., Internet, intranet, EDI, satellite, remote terminal direct- dial), human-mediated telecommunications (e.g., email, phone, fax), or by physical means (letter, visit, etc.).

As compared with the conventional business process of Figure 1, the circular automated business process of Figure 2 revolves around a single integrated database that accumulates information regarding every important activity of every user and defines a non-repetitive process. Furthermore, as compared to the essentially non-reversible process of Figure 1, the process of Figure 2 is reversible. As seen in Figure 2, following Shipping is a Return/RMA (Return Merchandise Authorization) activity, or, more generally, a reversal activity. This activity enables the forward process to be reversed, or backed out of step-by-step, as part of the overall automated business process.

The cumulative nature of the database of Figure 2 and the sequential nature of the business process enables incisive factual analysis in the areas of employee/ vendor performance and customer satisfaction, promoting fairness and personal responsibility. Whereas a human supervisor may effectively supervise only a limited number of employees, the database-implemented business methodology of Figure 2 provides for each employee what may be regarded as a "virtual mentor:" the user is guided during use of the system to prevent common mistakes (in fact, all mistakes made collectively by the all of the user's predecessors functioning in the same assignment), and the user's performance is continuously tracked and made accessible. Strengths and weaknesses in the employees performance may recommend certain changes in assignments — which changes may be made relatively easily by the employee because of the intuitiveness and intelligence of the system. An important aspect of virtual mentoring is an "open-book" information access policy: users, although they may limited access to input information, typically have few if any limits on access to information. The virtual mentoring pro- cess, described in greater detail hereinafter, promises to make the virtual office and telecommuting, with all its attendant advantages, a practical reality for a much wider segment of the workforce.

Referring now to Figure 3, a block diagram is shown of a computing environment in which the present invention may be used. A Web-enabled, client/server relational database management system (DBMS) is provided storing a database including files belonging to different business domains, e.g. a products domain, a payments domain, a financial performance domain and a personnel domain. (The term "product" is used genetically herein to refer to items sold and may be tangible goods, financial products, subscriptions — anything that may be bought and sold in a discrete transaction.) Also provided are code modules pertaining to each of the different domains. Customers and vendors may obtain access to the database through the Internet or the like. The physical location of the database therefore becomes irrelevant — the database can be everywhere in the world, either through wired communications or wireless communications. A firewall (or other security scheme, such as encryption, implemented in either hardware or software) may be provided between the Internet and the Web interface of the DBMS. Internal clients may be connected to the DBMS through a local area network (LAN) or through an intranet, using the Web interface.

Web User Interface

The Web interface to the database, particularly as seen by the customer, will presently be described in greater detail.

Referring now to Figure 4, within a principal navigation path a Web user is presented with buttons representing various options. In an exemplary embodiment, these options relate to, respectively, products, returns/repair, tracking, reports, accounting and log off. Two further options are also presented, PID maintenance and APL maintenance, the functions of which will be made clear hereafter.

In the example of Figure 4, the Products button is assumed to have been selected, resulting in the display of various search options. In the illustrated embodiment, Options 1-4 draw from an electronic products catalog directly. A product listing may be obtained by product category, all manufacturers (Option 1) or a single manufacturer (Option 2), or by manufacturer, description or part number (Options 3 and 4). Options 5-8 do not draw from the electronics products catalog directly but instead allow ordering to be performed without interacting directly with an electronic products catalog as described hereafter.

Selecting Option 1 causes a screen such as that of Figure 5 to be displayed, in which various product categories are displayed next to corresponding buttons. When the "Accessories & Supplies" button is selected, a screen such as that of Figure 6 is displayed, in which various sub-categories of products are displayed next to corresponding buttons. This division and sub-division may have any number of levels. In the illustrated embodiment, selection of the "Cables & Connectors" button causes a screen such as that of Figure 7 to be displayed, showing still a further level of sub-division. When the "Printer" button is selected, a screen such as that of Figure 8 is displayed, showing printer cables from the electronic product catalog. The user may check items of interest and click on "Show Selected Items," whereupon only the checked items are displayed. The user may search within the selection, reset (causing all of the items to again be displayed) or initiate a new search by clicking on corresponding buttons at the bottom of the page. For example, if the user checks the first item and clicks "Show Selected Items," a "shopping basket" screen such as that of Figure 9 is displayed. The user may return to the previous products list, search for more items, create a quote with the displayed items by entering a quantity for each item, or empty the shopping basket.

Selecting Option 2 from the product search page (Figure 4) causes a screen such as that of Figure 10 to be displayed. The user inputs a manufacturer's name, or clicks on a letter of the alphabet to choose from a list of manufacturers whose names begin with that letter. Selecting Option 3 from the product search page (Figure 4) causes a screen such as that of Figure 11 to be displayed. The user inputs one or more of the following items of information: manufacturer, item description and manufacturer part number. Multiple part numbers may be entered and search simultaneously by clicking the "Search multiple products" button.

Selecting Option 4 from the product search page (Figure 4) causes a screen substantially similar to that of Figure 10 to be displayed.

Selecting Option 5 from the product search page (Figure 4) causes a screen such as that of Figure 12 to be displayed. This screen is similar to that of Figure 11. However, instead of merely searching the electronic catalog, the search identifies products that meet the criteria specified and that have previously been purchased on the user's account ("core products"). The search may be date limited. Alternatively, the user may choose to display all core products by clicking the corresponding button. Figure 13, for example, shows a list of core products resulting from the search criterion "Compaq."

Selecting Option 6 from the product search page (Figure 4) causes a screen such as that of Figure 14 to be displayed. Rather than purchase. products item by item, the present system allows the user to store groups of items that work together as pre-configured products, each identified by a user-assigned Product group ID (PID). The user may search for a specific PID or multiple specific PIDs, or the user may show all PIDs. An example of a screen display that results when the user clicks "Show all PIDs" is shown in Figure 15. PIDs may be regarded as a "favorite quotes" list that may be repeated reused by the user. An example of a PID is shown in Figure 16.

Selecting Option 7 from the product search page (Figure 4) causes a screen such as that of Figure 17 to be displayed. In addition to PIDs, the present system allows Approved Product Lists (APLs) to be stored, including both a company APL and a personal APL. The user may search an APL or show an APL in its entirety.

Selecting Option 8 from the product search page (Figure 4) causes a screen such as that of Figure 18 to be displayed. This option allows previous quotes to be found and displayed. The user may specify a particular quote by quote number or may display the quotes for the current day or the current week. The quote or quotes that are found are displayed within a screen display such as that of Figure 19. Selecting a quote and clicking "Show selected Quote" causes a screen such as that of Figure 20 to be displayed. Various actions may be taken with respect to the quote including: add/change/remove products; arrange the order of quote items; save the quote for future reference; place an order based on the quote; and duplicate the quote into a new quote. The user may also return to the last search results of the Products List.

PIDs and APLs may be maintained on-line by the user. Clicking on the PID Maintenance button within the screen of Figure 4 causes a screen such as that of Figure 21 to be displayed. The user may create a new PID or review existing PIDs. For example, clicking on the "Show PIDs currently Active" causes a screen such as that of Figure 22 to be displayed. The user may click on a PID number to view the PID in detail.

Clicking on the APL Maintenance button within the screen of Figure 4 causes a screen such as that of Figure 23 to be displayed. The user then chooses between company APL and personal APL. Clicking on "Company APL," for example, causes a screen such as that of Figure 24 to be displayed. The user may add or delete an item to or from the APL by manufacturer part number or take any of various action with respect to the APL, including: search for products to add to the APL; delete items from the APL; end APL maintenance; and sort APL items by part number, manufacturer, price or description.

Clicking on the Returns/Repair button within the screen of Figure 4 causes a screen such as that of Figure 25 to be displayed. This screen allows a user to identify, in any of various ways, a product to be returned or repaired. For example, the product may be identified specifically by serial number, asset tag number, or the order to which the product belongs can be identified by customer purchase order number, customer invoice number, customer Purchase Requisition Number (PRN), or customer Request For Quote (RFQ) number. Clicking on the "More Search Options" button causes a screen such as that of Figure 26 to be displayed. From this screen, the user can search for a product to be returned by manufacturer name, part number and/or purchase date. The user may also look up Return Merchandise Authorization (RMA) records by date. Figure 27, for example, shows RMAs created between 6/2/98 and 7/1/98. Clicking on the RMA number causes the corresponding RMA record to be displayed as shown, for example, in Figure 28.

Clicking on the Tracking button within the screen of Figure 4 causes a screen such as that of Figure 29 to be displayed. The user selects the type of tracking information desired: sale order status, return product and service part status, product purchase history, or return and service history. If other status information is desired, the user may describe the desired information and submit a an email request. In essence, the present system allows remote users, including customers, vendors, manufacturers, etc., to view relevant status information pertaining to most or all of the product life cycle stages: purchasing, receiving, shipping, installation/assembly, billing, return/service, etc.

Clicking on "Sales Order Status" (Figure 29) causes a screen such as that of Figure 30 to be displayed. A sales order may be identified by customer purchase order number, customer invoice number, customer Purchase Requisition Number (PRN), or customer Request For Quote (RFQ) number or by identifying an item belonging to the order, by serial number or asset tag number. If the user does not have any ofthis information, the user may search for sales orders by manufacturer, part number, and/or date range. Figure 31, for example, shows the result of search- ing for sales orders by manufacturer (Compaq).

Clicking on "Return Product & Service Part Status" (Figure 29) causes a screen such as that of Figure 32 to be displayed. RMAs may be identified by RMA number, temporary case number, quote number, or by any of the various pieces of information referred to in previously (PO number, etc.). Figure 33, for example, shows RMAs identified by PO number. The user checks one or more RMAs of interest and then selects an action to take, e.g., "Get Freight Carrier & Tracking #" or "Ship to Address." Selecting "Get Freight Carrier & Tracking #" causes a screen such as that of Figure 34 to be displayed.

By clicking on "Product Purchase History" (Figure 29), the user may display by date range items previously purchased. Figure 35, for example, displays items purchased from Oct. 4, 1998 to Oct. 5, 1998. Similarly, clicking on "Product Return History" causes a screen such as that of Figure 36 to be displayed. Figure 37 displays items returned from Apr. 1, 1998 to May 1, 1998.

Clicking on the Reports button within the screen of Figure 4 causes a screen such as that of Figure 38 to be displayed. The reports may include such reports as the following: Back Order Reports, Monthly Sales Reports, Packing Slips, RMA Reports, Shipping Reports, etc.

Clicking on "Back Order Reports" (Figure 38) causes a screen such as that of Figure 39 to be displayed. Some units of an item may have been shipped but not all. If so, the 1st Ship and Last Ship fields indicate when the first unit of that item was shipped and when the last unit was shipped.

Clicking on "Monthly Sales Reports" (Figure 38) causes a screen such as that of Figure 40 to be displayed. The user selects a date range or a month and clicks "Take Action." A display such as that of Figure 41 results, listing each item sold on the user'.s account during the period, including total quantity, total cost, average unit cost and number of times ordered. Also displayed is the status of each purchase order for the period, the grand total of all purchases for the period, and the number of orders.

Clicking on "Packing Slips" (Figure 38) causes a screen such as that of Figure 42 to be displayed. Packing slips may be searched by providing a piece of identifying information in similar manner as described previously or may be identified by month. Figure 43, for example, shows packing slips for the month of Oct., 1998. Clicking on the packing slip number causes the packing slip to be displayed, as shown in Figure 44.

Clicking on "RMA Reports" (Figure 38) causes a screen such as that of Figure 130 to be displayed. The user is presented with various options, for example, show approved RMAs, show pending RMAs, show all open RMAs, etc. Clicking on Option 1 causes a screen such as that of Figure 131 to be displayed. By clicking on an RMA number, details of the RMA may be displayed. Clicking on Option 2 causes a similar screen to be displayed, showing only RMAs that have been approved. Clicking on Option 3 causes a screen such that of Figure 132 to be displayed, showing all open RMAs.

Clicking on "Shipping Reports" (Figure 38) causes a screen such as that of Figure 133 to be displayed. The user is prompted to specify a date range for generating a shipping report. Clicking on "Submit" causes a screen such as that of Figure 134 to be displayed, summarizing the number of shipping records found. Clicking on "Show All Details" causes a screen such as that of Figure 135 to be displayed. Items shipped during the specified period are displayed by PO number. Clicking on "POD" for a particular item causes Proof of Delivery information for that item to be displayed as shown, for example, in Figure 136. In addition, the user may request email status updates for an order by clicking the corresponding link. As the order status changes, the user will then be automatically informed by email.

Clicking on the Accounting button within the screen of Figure 4 causes a screen such as that of Figure 137 to be displayed. The user can retrieve particular invoices and credit memos by supplying any of various pieces of identifying information, or can retrieve invoices and credit memos by date range. Retrieving by date range causes a screen such as that of Figure 138 to be displayed. By clicking on the appropriate button, the user can display a selected invoice, purchase order, or packing slip. Clicking an invoice button, for example, causes a screen such as that of Figure 139 to be displayed.

The user can also enter a list of invoice numbers to be retrieved. More particularly, selecting Option 8 within the screen of Figure 137 causes a screen such as that of Figure 140 to be displayed. The user can then enter as many invoice numbers as desired.

A user may create one or more quotes but not act on the quotes for a considerable period of time. The quotes serve as an expression of interest on the part of the user. As time passes, however, the liklihood of a quote becoming an order decreases. In accordance with one aspect of the invention, such quotes are automatically identified, and communication with the users is undertaken so as to increase the liklihood of quotes being converted to orders. The communication may be Web-based and may, for example, take the form a promotional offer.

As may be appreciated from the foregoing description, the system provides for "information-rich" invoice payment status tracking and display. The simple knowledge that an invoice is open (has not been paid) is of little value. The more pressing question is why a customer invoice should be paid (e.g, has a return question been resolved?) or why vendor invoice has not been paid (e.g., was sales tax incorrectly charged?). The present system is designed to track such invoice payment status information. Because the database is Web-enabled, the same information may be readily displayed to customers and vendors, avoiding the need for telephone calls, "telephone tag," etc.

The present Web user interface is designed to accomodate a wide range of users, ranging from unsophisticated to sophisticated. To accomodate the unsophis- ticated user, any of various bits or pieces of information may be used to retrieve a record, for example the approximate purchase date. To accomodate the sophisticated user, multiple identifiers may be entered at a time in order to retrieve multiple records at a time, e.g., multiple part numbers, invoice numbers, RMA numbers (Return Merchandise Authorization numbers, described more fully hereafter), etc. This feature allows a user to quickly access a collection of desired information quickly with a single click. This feature is especially powerful in connection with RMAs. Instead of selecting items one at a time in order to create return requests, a user may enter several or many identifiers of a particular type (e.g., P.O. numbers, invoice numbers, asset tag numbers, etc.) and create a corresponding number of return requests.

Preferably, this same multiple-entry feature is provided in an internal client user interface in addition to the Web user interface.

Web Security

Doing business electronically poses various security risks. In the case of consumer-oriented Web commerce, much attention has been focused on secure transmission of credit card numbers and various security mechanism have been made available. In the case of business-to-business Web commerce of the type described, payment is usually not by credit card except for very small transactions. Instead, security risks involve potential abuse of the system by external parties or even internal parties. The present invention implements various security mechanisms to eliminate or minimize the potential for such abuse. Fundamentally, the security mechanisms are based on concepts of authority and lineage. A simple example is that the ship-to address for an order cannot be changed on-line. This prevents someone from ordering products and having them sent to their home or elsewhere.

Lineage relates authority to organizational hierarchy. The organizational hierarchy of Web users for a particular customer may be represented in tree fash- ion. A user at the leaf level may be given authority to get quotes but not to place orders. A user at a next-higher level may be given authority to view the quotes of users within a limited sub-tree and may be given limited authority to place orders. A user at the root of the tree may be given unlimited authority, from the standpoint of the customer, to view quotes of any user and place orders in any amount.

Referring generally to Figure 46, in the case of a typical company, various end users will be given different levels of authority, e.g., to create quotes but not purchase, to track orders, to perform returns, to view order information via the Web, or, in the most limited case, to have no access to Web purchasing information. To initiate the purchase process, an end user makes a quote request to his or her supervisor, who must approve the request. The request may require multiple further approvals, for example of an MIS department, an accounting department, a material management department, etc. In a typical scenario, the material management department will forward an approved request to a purchasing department. Authorized persons within the purchasing department may then send an order via the Web. In every instance, when Web access is attempted (and in fact every time a TCP packet is received), a user's authority is checked and that user's interaction via the Web is limited to the scope of that authority.

External Web authority information is stored for each customer in a customer file. An example of a customer record is shown in Figure 47. From the customer file, a company price list record such as that of Figure 48 may be displayed. For each customer, a price basis may be agreed upon for items that the customer buys regularly. External Web authority information is stored as part of the customer price list.

The manner in which a external Web user's authority is specified is illustrated in a series of figures beginning with Figure 49. First, the user's name is entered, first name (Figure 49) then last name (Figure 50). An employee number may then be entered (Figure 51), absent which an arbitrary employee number is generated automatically. A dialog then asks whether the user is authorized to make Web purchases (Figure 52). If the user is authorized to make Web purchases, then a further dialog calls for a purchase limit, if any, to be specified (Figure 53). A confirmation dialog is then displayed (Figure 54). The customer price list record following addition of the Web user with specified authority is shown in Figure 55.

The specific limits placed on a user's purchase authority may vary. Other examples of limits that may be desired by some companies are a limit on the number of purchase orders per day, a limit on the total amount of purchase orders per day, a time-of-day limitation as to when orders may be placed, etc. Various other security parameters may be added. Such limits may be set and changed remotely via the Web and given immediate effect within the system.

Limits are also placed on internal users access to security parameters so as to provide customer assurance that there exists no potential for internal abuse of the system (e.g, authorizing a crony to make illicit purchases on a customer account). A user may have authority to use (view) but not approve changes to certain security parameters, and may have authority to use and approve changes to other security parameters. In an exemplary embodiment, the authority of various users is set as illustrated in Figure 45.

Catalog Management

In the case of a company based on the conventional model of real inventory, Web catalog management is relatively straightforward. In the case of a company based on the model of virtual inventory, "the world is your warehouse." Intelligent catalog management is therefore of vital importance. Intelligent catalog management, in an exemplary embodiment, is based on a concept of "baseline." A baseline is a collection of products that functions as a standard of comparison. In an exemplary embodiment, there is both a vendor baseline and a customer baseline. Using the baseline concept, a product list without duplicates may be displayed. Furthermore, there may be displayed to the customer only products that there is some reasonable likelihood of the customer buying.

On the vendor side, one vendor is selected to serve as the baseline vendor. The baseline vendor will typically be a vendor found to have the most comprehensive inventory, the most useful categorization scheme, etc., and may be varied as often as desired. To create an update baseline, product listings of vendors are compared with the current baseline. If a product is already part of the baseline, as determined by manufacturer part number, then the product is grouped under the same baseline listing. For example, the same computer may be available through multiple different vendors. Rather than creating multiple product listings for the same product, these multiple product listing are consolidated under a single baseline product listing. If a product is not in the baseline, it may be added to a "supplemental baseline." If the baseline vendor does not carry a particular product but one or more alternate vendors carry the product, then the product will be listed in the supplemental baseline, again without duplicates.

After an updated baseline has been compiled, it is compared with the previous baseline. A product listing may be found: 1) in the old baseline only; 2) in the new baseline only; or 3) in both. Product listings in categories 1 and 2 are flagged as discontinued products and new products, respectively.

During the foregoing process, product cost and customer pricing information is updated. Also updated are URLs to vendor and manufacturer Web sites. These URLs may be used to refer Web users to these sites for product information. Product list updating may occur continuously or at regular intervals using "pull" technology, "push" technology, some combination of the two, or some other information retrieval technology or combination of technologies.

On the customer side, a customer baseline is formed by combining: 1) customer APLs (Approved Product Lists) for all customers or some subset of customers; and 2) historical purchase information, taking into account such factors as purchase date, volume, etc. There results a non-duplicative list of products custom- ers have bought or are presently approved to buy. Products in the vendor baseline may be flagged as belonging or not belonging to the customer baseline.

As a result of the baseline concept and the power of the DBMS, great flexibility is provided in the manner in which products may be displayed. A user may search the product file and request to see new products, discontinued products, vendor baseline products, without duplicates, vendor baseline products expanded to show duplicates, customer baseline products, customer-specific APL products, etc. In this manner, the seeming chaos that would otherwise result from the "infinitude" of products embraced by the notion of virtual inventory is tamed and made manageable.

Much of the difficulty of successfully implementing a cohesive business- to-business Web commerce solution has resulted from different aspects of a company's business being automated on different computing platforms. As illustrated in Figure 56, for example, a product catalog may be implemented on one platform, shipping implemented on another platform, accounting implemented on still another platform, etc. To interface all of these different functions to the Web requires multiple interfaces.

By using a single Web-enabled database and providing for all necessary functions within a single database schema, the present Web commerce solution avoids the daunting complexity characteristic of the prior art. Referring to Figure 57, a single universal interface may be used to place the entire contents of the database, or as much of those contents as desired, on the Web.

Database Schema

An important feature of the present system is that a single database, described by a single database schema, is used to automate an overall business process, end-to-end. To do so, the schema must, understandably, be quite complex. A general outline of the schema is shown in Figure 58. The complete schema, or structure diagram, is set forth as Appendix A. Referring to Figure 58, the manner in which various automation processes relate on an inter-domain basis may be appreciated. The products domain is represented in approximately the upper third of Figure 58 and includes sales functions (5801) and shipping/receiving functions (5803). Purchasing and installation functions, now shown in Figure 58, are shown in the microfiche appendix. The payments domain is represented in approximately the middle third of Figure 58 and includes AP functions (5805), AR functions (5807) and return functions (5809). The financial performance domain is represented in approximately the lower third of Figure 58 and has financial information automatically posted to it from the payments domain, as described more fully hereinafter. The personnel domain is not shown in Figure 58 but draws upon information from the other domains in a manner described more fully hereinafter.

In an exemplary embodiment, the relational database management system provides both a "Quick Switch" option whereby any base table may be viewed or a "Related Switch" option (described in greater detail hereinafter) whereby a base table may be selected from which is then displayed a row related to a selected row in a current table. Various user options may be provided programmatically. Table 1 is a list of most of the base tables and corresponding options in an exemplary embodiment of the invention.

Table 1

Table 1

Table 1

Table 1

Table 1

Table 1

Table 1

Table 1

Table 1

Table 1

Table 1

Various screen displays showing the options pop-up menu for that screen display are shown in Figure 124 through Figure 128.

Business Process — Overview

An overview of the present automated business process is shown in Figure

59. In an illustrated embodiment, the automated business process has nine entry points, designated E1-E9, at which users enter information into the system. Interaction with the system is carefully controlled and user inputs carefully qualified to ensure, to the greatest degree possible, error- free operation.

The business process is customer-driven. The first entry point El in the business process is Sales/RMAs. In response to a customer request, a user having responsibility for El enters information about the customer request into the database. If the request regards sales, the information is checked and converted to a Master Worksheet (MWS). At an entry point E2, the responsible user groups MWSs for purchasing and places orders. Information is assembled for later use in receiving (E3), installation (E4), and shipping (E5). Respective users at these entry points make entries into the database which as confirmed against the assembled Purchasing/Shipping/Receiving/Installation (PRIS) information to verify correctness.

Unlike prior art systems, the present system provides the option of carrying inventory or operating under the concept of virtual inventory. In accordance with the concept of virtual inventory, all of the goods available for purchase in all of the warehouses throughout the world are regarded as available inventory. Because the Web allows business to take place at light speed, the difference between physical inventory and no physical inventory can be merely the click of a button on a computer screen. As goods are received and shipped, these events are tracked by a virtual inventory process in which all items are presold. In one aspect of the invention, virtual inventory is defined as each vendor order item being related to at least one item sold record created in response to receiving user demand informa- tion directly from a user; i.e., the system is "demand driven."

Virtual inventory may be more fully understood in relation to the data processing concept of pipelining. Some delay occurs as the data pipeline is initially filled. Thereafter, results are produced at every cycle. The initial delay is the time required to perform a data operation on the data inputs. Similarly in the case of goods. An initial inventory of goods may be required to satisfy demand during a time period from when a demand is received until that demand can be filled — i.e., the manufacturing cycle. Thereafter, supply and demand should be exactly balanced. As demand increases and decreases, the rate of manufacture is varied accordingly such that supply and demand remain exactly balanced. In the case of a reseller, the manufacturing cycle is zero. The requirements for real inventory are therefore zero, enabling pure virtual inventory. In other businesses with non-zero manufacturing cycles (from days to weeks, months or years), the foregoing concept of virtual inventory may still be applied such that, in the "steady- state" condition, supply and demand remain exactly balanced.

Where physical inventory is required or desirable, it may be treated simply as an internal demand as opposed to a customer demand. In both cases, the demand is represented by an MWS. In the case of internal demand, however, the customer is the business itself.

Referring still to Figure 59, entry points E6 and E7 relates to customer and vendor payments, respectively. Assembled information is input to A P and A/R modules. Customer payments are received and entered in conjunction with the A/P module. Vendor payments are made in conjunction with the A/R module.

A general ledger (GL) module tracks transactions and their financial implications in real time. It therefore receives information from the A/P, A/R and virtual inventory modules as well and entry points E6 and E7. Bank statement information is also input to the general ledger module at entry point E8.

The customer request, instead of being for sales, may be an RMA request. Information is then input from El to an RMA module. A reverse process in then executed, begun by an RMA number being communicated to the customer. In the typical case, the customer then returns merchandise authorized for return. The returned merchandise is received (entry point E3) in conjunction with the RMA module and receiving information portion of the assembled information. The RMA module communicates with the GL module so that appropriate accounting entries may be made.

The effect of the overall business process is two-fold. First, a response to the customer's input is produced and communicated back to the customer. Second, during the course of the business transaction, a wealth of historical data are accumulated that may then be subjected to factual analysis for purposes of ensuring customer satisfaction, evaluating employee performance, and evaluating vendor performance.

In the following description, the course of an order will be described within each of the domains identified in Figure 3, as follows: in the product domain, from quote to shipment, as well as return (although rather atypical, returns are nevertheless a common occurrence); in the payments domain, from invoice to payment (both customer and vendor); in the financial performance domain, from cashflow to financial statements; and finally, in the factual performance domain, from parameters such as time, quantity and dollar volume to individual and group employee performance.

Sales

As may be appreciated from the foregoing description, an order may be preceded by a quote. Quotes may be requested and orders may be placed in writing (e.g., by fax), verbally (e.g., by phone), or electronically via the Web. More generally, order information may be conveyed by electronic means (e.g., Internet, intranet, EDI, satellite, remote terminal direct-dial), human-mediated telecommunications (e.g., email, phone, fax), or by physical means (letter, visit, etc.). Regardless of the origin of the quote or order, the quote or order becomes a sales record.

A screen display that may be used to view sales records is shown in Figure 60. Quotes are each assigned a Quote number having a "Q" prefix. Orders are tracked via records referred to as "Master Work Sheets" (MWS). A Master Worksheet contains all of the vital information related to an order. As seen in Figure 60, orders are each assigned a MWS number having a MWS prefix. The screen display of Figure 60 includes a status column in which the status of each quote and order is indicated, e.g., WebSubmit, WebQuote, Purchasing, etc. The status of each record can therefore be readily ascertained and tracked.

Referring to Figure 61, the input layout of a quote is shown. During record input, the system prompts the user at every opportunity. For example, when the cursor is placed within the customer field, a list of previous customers is displayed. Assuming the customer is a repeat customer, the user can select the customer from the list. Various fields are then completed from information previously stored for that customer.

To add an item to a quote, the user clicks the "+" icon, followed by the "Go Prod" button. The Products file is then displayed, as shown in Figure 62. The Products file may contain hundred of thousands or even millions of product records of products from different vendors. When the user selects a product, the all of the relevant information for that product is transferred to the quote. To facilitate selection, the product file may be searched in various ways, e.g. by vendor, product category, etc. By searching the products file by manufacturer part number, the vendor offering the best price for a particular product may be identified.

When all items have been added, the user is asked to specify partial shipment status. The partial shipment status specifies what items, if any, can be shipped separately and what items, if any, are required to be shipped together. The user is further prompted to enter installation information and to ensure that all required cables, brackets, etc. have been ordered. In the case of computer equipment, for example, installation may involve installing a card or installing memory within a computer, loading software, etc. If installation is specified, installation charges are automatically added to the quote.

During the foregoing process, the user may enter notes within a screen 6101. This screen is displayed whenever the quote or MWS is displayed. If a quote is created on the Web, a separate notes screen is provided for customer notes. A corresponding notes screen for internal use only is provided for all quotes.

When the quote is satisfactory, the user may then save the quote by pressing the post to purchasing button.

To ensure that a quote is correct, one or more additional review stages may be required before the quote is converted to an MWS for purchasing. For example, the quote may be reviewed by "inside sales" to make sure that any compatibility requirements have been met and that, from a technical viewpoint, there are no errors in the quote. In a further review stage, the quote may be compared to a paper purchase order, if one exists, to make sure there are no discrepancies. When the quote has passed whatever level of review is required, it is then marked reviewed and converted to an MWS. The format of an MWS is shown in Figure 63.

Note that, during the foregoing process, different people may have different limited privileges. Also, throughout the foregoing process and throughout the system generally, at each information entry point, the user's input is checked for accuracy in order to prevent common mistakes from occurring.

PRIS (Purchasing, Receiving, Installation, Shipping)

Purchasing, receiving, installation and shipping functions are closely interrelated. For this reason, preferably the output display/user interface presented during these different processes preserve a common look and feel.

Purchasing may be based on a real inventory model, a virtual inventory model, or a combination of the two. In the case of the virtual inventory model, automating purchasing functions in such as manner as to 1) scrupulously avoid physical inventory; and 2) achieve business scalability, becomes a challenge. The following description assumes that purchasing is based at least in part on a virtual inventory model.

A simplistic approach to purchasing is to treat each customer purchase order separately. Under this approach, however, the amount of work involved in purchasing is proportional to the number of customer purchase orders; business cannot achieve 100, 200 or 1000% growth in a short period of time without causing severe growing pains.

Instead, the purchasing module of the present system is designed for business scalability and maximum automation, allowing for dramatic growth without a dramatic increase in human effort and with little or no pain. Scalability is achieved by "commingling" customer orders in such as way that what appears to an outside vendor as a single large order is tracked within the system as a multitude of smaller orders.

Referring to Figure 64, purchase order sales actions result in MWS records, each MWS record including all of the relevant information required for purchasing. In an exemplary embodiment, this information includes internal MWS number, customer P.O. number, sales cost, sales price, vendor, part number, manufacturer, manufacturer part number, installation grouping (within a particular MWS), shipping instructions, and stock/inventory status. Each MWS is assigned a unique MWS number which is used throughout the life of a transaction to differentiate distinct purchase orders. Any unique identifier may server the same purpose, including, for example, a material code number, a purchase requisition number, etc.

The design of a purchasing output display/user interface greatly simplifies the purchasing process. For each item to be purchased, a record is displayed including each of the foregoing pieces of information. Preferably, all of the head- ing allow for sorting on that heading. Furthermore, all items are selectable and may be expanded (by doubling clicking) into item details.

The user interface allows a variety of actions to be performed, including grouping items within the display, removing items from the display, cancelling or changing various aspects of an order, holding an item or splitting an item (e.g., in order to hold less than all of the items details belonging to an item), etc. In an exemplary embodiment, items may be grouped by stock status (B/O, short stock), by shipping instructions (partial shipment OK, no partial shipment), by vendor, by manufacturer, by MWSs including addendums, etc. Groups of items may be removed from the display, including any of the aforementioned grouping and install groups. An item sold (one or multiple physical items) may be removed or an item detail (a single physical item) may be removed. Cancellations and changes may be made to an item sold, an MWS, shipping method, and freight charges.

In accordance with the virtual inventory concept, items within a group (an installation group or a ship group, for example) are acted upon as a group. For example, if one of the items is removed from the purchasing screen (purchase of the item is delayed), all items in the group are removed from the display. Undesired inventory is therefore avoided. Otherwise, an item might be ordered and received only to find that it must be installed with or ship with an item that is back ordered. Valuable cash is then tied up in inventory waiting for the back-ordered item. The present system avoids such unwanted inventory.

In a typical scenario, a purchaser's work might proceed in the following manner.

1. Get all unfinished and new work (all items having no order date).

2. Select a subset of items to work and remove all other items from the output display.

3. Get all back ordered items and purchase them first. Eliminate related "no partial" items from the output display until the corresponding back- ordered item has been received.

4. Group items from different orders and possibly change vendor on some items to obtain quantity discounts, if possible.

5. Place order and repeat.

In a preferred embodiment, at least the latter two steps are performed via the Web or with information obtained via the Web. Orders may either be placed directly or posted for bid by interested vendors. Furthermore, in accordance with supply-chain management functions described more fully hereafter, a single purchase may be "broadcast" via the Web to all relevant vendors and manfacturers within a supply chain for that product.

Various user interface buttons relate to the actual placing of a purchase order. In a telephonic transaction, purchase cost (Pcost) on an item might be negotiated downward below the sales cost (Scost). By selecting an item and clicking on the button, the purchase cost may be input in the course of placing the order. A sales confirmation number may also be input by clicking on the corresponding button. An automatically generated PO number may be assigned by clicking on button. By clicking on the button, the output display is refreshed to remove from the display items that have been ordered. Simultaneously, the system marks the ordered items as ready to receive, thus preparing the items for receiving.

More preferably, purchase orders, instead of being placed manually, are placed electronically by linking to the seller's network of vendors. Automated purchasing may occur continuously or at regular intervals using "pull" technology, "push" technology, some combination of the two, or some other information retrieval technology or combination of technologies.

Business rules guide the user to follow a pre-established routine for easily accomplishing complex business tasks including purchasing. Note, however, that dynamic workflow allows an experienced user with the requisite access authority to override business rules in order to handle new business requirements. This authority is in turn counter-balanced by various consistency checks throughout the system that ensure accountability.

Business rules implemented by the purchasing process include the following:

1. Items cannot be ordered before a quote is converted to a MWS.

2. Duplicate orders are not allowed by item or MWS.

3. Items can only be ordered from approved vendors.

4. Purchasing can only be done by authorized personnel.

5. Purchasing notes can only be viewed by authorized personnel.

6. Purchase costs can only be viewed by authorized personnel. Referring to Figure 65, purchasing information, derived from MWSs, is used in the receiving process. (An item must have been purchased to be received.) Returns (RMA) information, also derived from MWSs, is also used in the receiving process. (Return items must be received in order to give credit.)

When the receiving process is begun, only items sold having an order date but no receive date are displayed. Double clicking on a item causes specific receiving instructions for that item to be displayed, as described more fully hereinafter. The display format is very similar to that of the purchasing process. The possible actions that may be initiated, however, are particular to receiving. Those actions include 1) input actions; and 2) display actions.

Information input during receiving includes packing slip number, serial number (each physical item, where applicable), carrier, quantity, payment terms, number of boxes, condition upon receipt, etc. Batch input for all packing slips and items. The system automatically matches input with items that exist in the system such that the same item cannot be received twice, the wrong item cannot be received, a cancelled order cannot be received, etc.

Expected to receive will exclude refusal items. For example, a customer may change his or her mind after an order has been placed but before the item has been received. In this instance, a refuse instruction may be placed on the item to prevent it from being received.

As in the case of purchasing, in the case of receiving also, great benefit is obtained from allowing vendor access via the Web to see what products order from that vendor have been received. The vendor then obtains the information it requires to be truly responsive to its customer's needs.

Referring to Figure 66, installation is based on the same type of output display. However, only installation groups are shown. Items requiring no installation are not displayed. Furthermore, the user has the option to show all items requiring installation or to show only items requiring installation that have been received. The possible actions that may be initiated include 1) actions used to track installation in various different stages of completion; and 2) input actions, namely input of serial number and asset tag number. (Asset tag numbers may be affixed by prear- rangement with the customer and retained in the system indefinitely to assist the customer in accounting for equipment.)

An installation, once begun, may have several possible outcomes. In the typical case, the installation will be completed successfully and the installation group may be released for shipment. In other instances, installation may be only partially completed — e.g., manufacturer technical support may be required, additional parts may be required to complete installation, or additional installation may be required for some other reason. In some instances, the appropriate action may be disinstallation, for RMA purposes or for some other reason. All of these different stages of completion are tracked within the system.

Referring to Figure 67, the shipping process, like receiving, uses both purchase information and RMA information. The output display displays only items sold having a received date but no ship date. Double clicking on a item causes specific shipping instructions for that item to be displayed, as described more fully hereinafter. Input actions that may be initiated include inputting a shipping track- ing number, serial number (if not previously entered), customer specific number or asset tag number, claim value, carrier (or will call, which causes a local sales tax rate to be applied), payment terms, boxes, etc. Provision is also made to display only those items expected to ship, excluding refusal items, hold items and items with COD/cash terms.

Referring to Figure 68, throughout the foregoing processes, and in particular receiving, installation and shipping, notes conveying instructions regarding specific items may be displayed by double-clicking an item to cause a item detail display to appear. Included within the item detail display are several notes boxes, including boxes for unique installation notes, standard default notes from the customer file, unique shipping notes, standard default shipping notes from the vendor file (for RMA), RMA installation notes, receiving notes, etc.

The PRIS output display also includes an "Expedite" view, shown in Figure 69. The expedite function is to minimize delay in receipt of ordered products. Expedite actions include entering the Estimated Time of Arrival (ETA) of a product based on contact with the vendor and/or shipper and marking items in accordance with various expedite categories, as well as entering notes if necessary concerning the problem and expected solution.

In accordance with one embodiment of the invention, expedite information may be brought up from the MWS screen, as shown in Figure 70. In Figure 70, a radio button has been clicked to cause a Not Received Report to be displayed. This report shows percentage of order completion in terms of ordering, receiving and shipping, as well as the age of the order in days. Various filtering options are provided. Expedite status for each item may be entered by clicking on one of a large number of status buttons, e.g., "Urgent," "Wrong Product," etc. A Not Shipped report screen display is shown in Figure 71.

Expedite status may also be set using a more abbreviated expedite pop-up, shown in Figure 72. Figure 145 through Figure 149 show different output displays tailored for purchasing, receiving, installation and shipping in accordance with another embodiment of the invention. These output displays are different views of the same underlying data stored in the Item Detail records — the basis "currency" of the system.

Figure 145 shows a purchasing output display. Various columns are common to all of the PRIS output displays, e.g., MWS number and date, internal PO number, customer name and PO number, item description, etc. Columns of particular interest for purposes of purchasing are Scost/Pcost (expected cost at time of sale and actual purchasing cost), Vendor/Conf#, Mfr./Vendor part number (PN), Lprice/Lcost (the last sales price and purchasing cost for this item), Rebate, Special, and Pcomments, or purchasing comments.

Figure 146 shows an Expedite output display. Of particular interest for purposes of expediting are Order/ETA (expected time of arrival at the time of order), Epd ETA/Status (latest ETA, reason for delay, etc.) and Epd Condition.

Figure 147 shows a Receiving output display. Of particular interest for purposes of receiving is Receive Condition.

Figure 148 shows an Installation output display. Of particular interest for purposes of installation are Install/Date and Install Group. Items within a same install group are to be installed together to form a single functional product or assembly.

Figure 149 shows a Shipping output display. Of particular interest for purposes of shipping are Order/Reed and Ship Group. Items within a same ship group are to be shipped together.

As with both purchasing and receiving, preferably vendors are given access via the Web to expedite information relating to that vendor.

The PRIS module is guided by the principle of "virtual inventory" and allows for the drastic reduction of inventory. One impediment to virtual inventory is backorders. Assume, for example, that three different orders are placed each having five items, some of the items being the same between orders. Also assume that the orders must be shipped complete. In conventional practice, one item might be missing from one order, preventing it from shipping, two items might be missing from a second order, preventing it from shipping, and three items might be missing from a third order, preventing it from shipping. It might happen that the item missing from the first order was received for the third order, for example, such that this item could be reallocated from the third order to the first order, allowing the first order to ship and reducing inventory. Conventionally, however, such a circumstance would be detected and acted upon only through painstaking, conscientous effort.

Contrary to conventional wisdom, which is that an order is not ready to ship until it is complete, the present PRIS module assumes that all items are ready to ship unless they are stopped by the system. Instead of inflexibly reserving a particular item for a particular order, all items are assumed to be interchangable between orders. Backorder delays are therefore minimized.

The foregoing principles explained in relation to PRIS may be adapted to other businesses in which, instead of installation, any type of transformation may be performed. In channel assembly, for example, parts are assembled into a product mere days or even hours before the product is shipped to a customer. The transformation may therefore be assembly instead of installation. In other businesses, the transformation may be quite different, e.g., testing, burning-in, mixing, aging, curing, machining, etc. The transformation may be a single-step transformation or a multiple-step transformation in which intermediate products are produced. Whatever the nature of the transformation, information concerning what materials have been transformed, various stages of transformation, etc., are tracked in the database. The purchasing, shipping and receiving functions described previously therefore become part of a comprehensive materials management system. RMAs

Normally, the order will be successfully shipped to and received by the customer, who would then begin to use the products. In some instances, however, the product may not work as intended, the product may be lost or damaged in shipping, duplicate products may be shipped, or the customer may change his or her mind, necessitating that a product be returned. Returns are provided for through a Return Merchandise Authorization (RMA) mechanism. The same mechanism may be used for other account adjustments other than actual returns, for example freight adjustments, etc. In fact, in some sense, the RMA mechanism may be regarded as a garbage can of sorts — any action that is later found to be incorrect, for any reason, can be reversed through the RMA mechanism. Furthermore, the existence of an RMA has immediate effect throughout the system, on purchasing, receiving, installation, shipping, accounts payable, and accounts receivable. For example, if an RMA is received and the corresponding vendor invoice has not yet been paid, the vendor invoice will not be paid until the return product is received and shipped back to the vendor and a credit received from the vendor. The immediacy of the effect of creating an RMA is achieved through the use of a central underlying table — item detail — that functions as the building block upon which other tables depend. In essence, most data is viewed within the system simply as a "window" into the item detail table.

An RMA may also be used for warranty replacement parts. This feature, coupled with Web access, allows customer's to track replacement parts themselves without contacting a technician or service representative. A customer may request an RMA in any of the ways previously described for obtaining a quote or placing an order. When an RMA request is received, an RMA record is created. An RMA screen display is shown in Figure 73.

Referring again to Figure 63, a MWS display includes an RMA button. When this button is clicked, the user is prompted to select an item from the dis- played MWS for return. An Add RMA Record screen display such as that of Figure 74 is then used to specify return type, reason, etc. A typical RMA has two "sides," the customer side and the vendor side. When the item to be returned is selected, preferably both the customer side and the vendor side are filled out by the system. Any changes may be made from a screen display such as that of Figure 75. By clicking a button, the screen display of Figure 75 allows for display of the customer side only, the vendor side only, or both sides of the transaction, as well as claims information.

A return may be made for any of a number of different reasons. Different return types are therefore defined. Depending on the return type, some RMA fields will not be applicable. Preferably, the system is provided with sufficient intelligence to automatically fill in these fields as "N/A."

As shown in Figure 76, a lookup table may be used complete various fields of an RMA record based on the selected return type. If a return is for credit, for example, then return type 1 is the corresponding return type. Depending on whether payment was by check, credit card or credit memo, different fields may be applicable. In the present example, however, the mode of payment does not affect the manner in which the RMA is completed. As noted previously, an RMA has both a customer side and a vendor side. In Figure 76 therefore, each table cell has an upper half corresponding to the vendor side (V) and a lower half corresponding to the customer side (C). To take a few example fields, in the case of a return for credit, no replacement product is called for, hence the Repl MWS column is marked N, for no. Since no replacement product is expected, then on the vendor side, the Rec'd column is N/A, and on the customer side, the Ship column is N/A. Similar logic dictates the way in which the remainder of the table is completed.

Similar logic tables may be used to automatically approve RMAs^' and provide an RMA number instantaneously for most RMA requests. Again, approval has a customer side and a vendor or manufacturer side, at least in the case of a vir- tual inventory model. (RMAs eliminate, or at least minimize, the hazard of accumulating obsolete inventory as a result of returns.) In an exemplary embodiment, a series of limit checks are performed on an RMA request. Referring to Figure 77, a limit file is shown, having a customer portion, a vendor portion and a manufacturer portion. Assume once again that the return type is return for credit, and assume further that the payment mode was check. The first column has a Y value, indicating that automatic approval of RMAs of this return type are allowed. The next three columns relate to the manufacturer and contain the values Y, Y and N, respectively, indicating that for the RMA to be approved the manufacturer must allow returns, that the manufacturer must further allow open box returns, and that the time to RMA cannot exceed the manufacturer's allowed maximum time duration. For a particular manufacturer, the manufacturer's specific return policies are stored in a table such as that shown in Figure 78.

Referring again to Figure 77, the next two columns relate to vendor and contain the values N and N/A, respectively, indicating that the time to RMA cannot exceed the vendor's allowed maximum time duration and that the vendor's restocking fee policies are not applicable for this type of return. For a particular vendor, the vendor's specific return policies are stored in a table such as that shown in Figure 79.

Referring again to Figure 77, the next four columns relate to customer and contain the values N, N, N and N/A, respectively, indicating that the time to RMA cannot exceed the maximum time duration allowed for this customer, that there must be no restocking fee, that the sales price cannot exceed the maximum allowed for this customer, and that customer service fee policies are not applicable for this type of return. For a particular customer, specific return policies for that customer are stored in a table such as that shown in Figure 80.

If an RMA request meet all of the applicable automatic approval criteria, then it may be automatically approved, instantly, and an RMA number communi- cated to the customer as shown, for example, in Figure 81. «

A more detailed listing of RMA types, subtypes and conditions is provided in Figure 159.

Business rules implemented by the RMA module include the following:

1. RMAs can only be created for items shipped to customer.

2. One item per RMA (quantities are OK).

3. Replacement Quotes are created by the user specifying the appropriate replacement product.

4. Generation of printed/faxed RMAs with Return packing slips for customer use.

5. Receiving can only receive items from customers with valid RMA issued.

6. Wrong or defective products automatically create RMAs.

7. Replacement MWSs can only be shipped after being released by purchasing.

8. Vendor RMAs must have vendor RMA numbers before shipping.

9. Complete control of RMA module by executive group.

One characteristic feature of the present system perhaps most evident in relation to RMAs is the display of information in a very complete way and in such a manner as to allow ready interaction. In conventional database applications, information is presented in simple row format within an output display. Multiple levels of "drill-down" may be required to display a particular detail. Furthermore, entry or manipulation of information can typically only be performed from a separate input screen.

In the case of the present system, by contrast, as exemplified by the RMA display of Figure 73, records are presented in a very information-rich format. Entry or manipulation of information is enabled within the same screen display. In the case of RMAs, for example, a user with the proper authority is able to approve or cancel an RMA, change an RMA to a different type, release a replacement shipment, etc.

A further important feature also greatly facilitates convenient navigation and ease of use. In most systems, to display related records, a search editor is used to enter a search. In the present system, by contrast, a "related-switch" menu bar is provided within most displays. Using this related switch feature, a user may select one or more records within the output display and select a related file from a popup of related files. The system then searches in the related file for records related to the selected records and displays the related records in the output display format of the related file. In the case of RMAs, for example, the related switch capability may be used to switch to related customer invoices, vendor invoices, credit memos, etc. One file may be related to another file but only indirectly, through a third file. In this instance, an intermediate search is required, the results of which are not displayed. Of course, the number of intermediate files may be more than one.

Preferably, vendors are given access via the Web to RMA information pertaining to them. A vendor may then immediately provide an RMA number without requiring any human intervention.

With vendor access to purchasing information, receiving information, expedite information and RMA information pertaining to that vendor, a truly integrated supply chain results. Such an arrangment makes global commerce just as convenient as local commerce. For example, a seller may have ten or hundreds of vendors worldwide, many in locations where the time difference would ordinarily make doing business difficult and tedious. Such difficulty is removed in the case of the present system, because all of the intelligence needed to do business resides in the system and is readily accessible at each party's convenience wherever in the world that party may be. As previously described in relation to PRIS, the present single-database system contains information about installation and product configuration. This information may be used to advantage to avoid a common problem encountered in relation to RMAs. When a product is returned that has other add-on products installed, the user may forget to remove these add-on products before shipping the product to be returned. For example, a printer may have installed a memory upgrade and a network card. If the printer is returned to the vendor with the memory upgrade and the network card installed, there is some likelihood of the memory upgrade and network card being removed during service and not re-installed. These add-on products may then become lost.

To avoid this problem, when an RMA is requested for a product that has had one or more add-on products installed, a dialog is displayed to the user reminding the user to remove the add-in products prior to shipping back the product. The same reminder may instead, or in addition, be sent by e-mail, fax, etc.

The PRIS capabilities described previously may also be used to advantage to track RMA status and display status information via the Web. The stages of an RMA typically include some or all of the following: 1) shipped from customer to reseller; 2) received by reseller; 3) shipped by reseller to vendor; 4) received by vendor; 5) shipped by vendor; 6) received by reseller from vendor; and 7) shipped from reseller back to customer. With the possible exception of number 5, status information with respect to each of the foregoing stages is available within the database or, in the case of number 4, through conventional electronic tracking services offered by carriers such as UPS, Federal Express, etc.

Design Philosophy: Self-Correcting Knowledge-Based System

The information-rich action-oriented displays previously mentioned are a manifestation of a design philosophy in which a system knowledge base is continuously expanded with user assistance and reflected in the manner in which users interact with the system. Other manifestations ofthis design philosophy are found in the options described previously (Table 1 and Figure 124 through Figure 128) and the experiential constraints alluded to previously and described in greater detail hereinafter. Referring to Figure 129, a knowledge base is initially created based on system analysis and design considerations, considering the range of possible outcomes at each stage of the business process, and considering further the goal of total automation, phones free and paper and pencil free. These system analysis and design consideration will necessarily be incomplete — hence the need for dynamic workflow. No pretense is made that a single predetermined workflow definition will prove adequate in practice.

The knowledge base affects user interaction with the system through two different kinds of displays, a data input display and a process display. The data input display is used to actually enter data into the system. During the course of data entry at entry points E1-E9 (Figure 59), rigorous entry qualification occurs to eliminate errors. In the case of PRIS, for example, during receiving, only ordered items are allowed to be received. To cite a further example, during vendor invoice entry, described hereinafter in relation to Figure 121 through Figure 123, the system detects an attempt to enter a duplicate invoice number and prevents the duplicate from being entered. The process display is used to act on the data within the system to move an item to the next stage, and in the course of such action has the effect of changing the status of records acted upon. In the case of RMAs, for example, the user may easily, with the click of a button, approve or cancel an RMA, issue a customer credit memo, change the N/A settings of the RMA, etc. In the case of expedite, the user may easily, with the click of a button, record the reason that a product has not been received. To cite further examples, in the case of vendor invoices and customer invoices, described hereinafter, the user may easily, with a click of a botton, mark a vendor invoice for approval or cause an aging report window to be displayed for customer invoices.

The knowledge base and the application of it to data input and user actions is what makes an automated, end-to-end, sequential business process possible. Depending on the skill level of the user, the user is given some level of authority ranging from minimum authority to maximum authority. For users with minimum authority, the system ensures that work gets done in a prescribed, correct manner. For users with greater authority, dynamic workflow provides myriad additional possibilities while maintaining accountability.

During use of the system, unanticipated circumstances are bound to arise in which the user cannot accomplish his or her task (or accomplish it as well) in a phones free, paper and pencil free manner using the current features of the system. In this event, the knowledge base of the system is then added to to solves the user's problem. In some instances, the user may be able to add to the knowledge base directly. For example, the user may wish to add a further return type by adding an entry to the table of Figure 75. Similarly, in the case of factual performance evaluation, described hereinafter, the user may choose different performance metrics or combinations of metrics to be tracked and displayed. In other instances, adding to the knowledge base may require administrative intervention. In the case of the options of Table 1 and Figure 124 through Figure 128, adding further options may require the efforts of a programmer.

Having described for an order the course of events in the product domain, the course of events in the payments domain will now be described, first in relation to sales tax and sales commissions, then in relation to customer payments and finally in relation to vendor payments.

Sales Tax and Sales Commissions

Sales tax and sales commissions are automatically computed and stored in the system based on applicable tax rates and commission rates.

In the case of sales tax, a sales tax table contains state tax rates and local tax rates. For a particular sale, the applicable tax rate is determined based on the ship-to address. Typically, preliminary tax payments are made each month and a final tax payment is made each quarter. Sales tax records are automatically added to a sales tax register (first prepayment, second prepayment, or final quarterly payment) for the appropriate period. As shown in Figure 82, the sales tax module automatically calculates the figures to be entered on each line of a sales tax return, or may be programmed to print out the actual return.

In the case of commissions, commission rates are stored within a Sales Rep file and a Sales Support file. Because each order is worked on by both outside sales and inside sales, each order will typically have two commissions. Commission records are created at the time a customer invoice is issued. Commissions are then approved and scheduled to a commission register for payment in a similar manner as accounts payable, described hereinafter. Multiple levels of commissions are provided for. A simple example of multiple commissions is where an outside salesperson responsible for customer interface is supported by an inside salesperson that reviews orders for correctness and troubleshoots the order, if necessary, during the fulfillment process. In more complex organization structures (e.g., multi-level marketing), the number of commissions may be greater than two.

Accounts Receivable

When an order is shipped, a customer invoice is automatically issued, i.e., entered into the computer system. If paper invoices are required, then at regular intervals (each day, for example) an accounts payable clerk prints out, checks and mails customer invoices issued during the preceding interval. (Alternatively, the printing and mailing of customer invoices may also be automated.) In an exemplary embodiment, invoices are issued using the "Issue invoices" option within the customer invoice file. A customer invoice screen display is shown in Figure 83. With the passage of time from the invoice date, invoices pass from one category to another, e.g., 30 days, 60 days, 90 days, etc. At any time, the accounts payable clerk may view invoices within different categories. Also, as is the case with other output screen displays, the user is able to manipulate information and interact with the system, e.g., to analyze an account, add a comment or note, etc., all without paper and pencil.

Referring more particularly to Figure 84, from a MWS output screen display, the user can select a group of invoices and click on a collections button to cause a collections summary to appear. By further clicking on a By Customer button, the selected invoices are broken down by customer as shown in Figure 85.

When a customer payment is received, a payables clerk clicks an add record button to add a customer payment record. The clerk is then presented with a pick list of customers. The clerk selects the customer from which the payment has been received. The customer is then prompted in turn to enter the mode of payment (check, cash, etc.) and the payment date. A customer payment record such as that shown in Figure 86 is created. A payment may correspond to multiple invoices. The clerk enters from the check stub reference numbers and invoice numbers, as well as the respective amounts, for each invoice (or credit) to which the check purportedly applies. Referring to Figure 86, for example, the check #429069, as indicated on the check stub, pertains to five different items, or reference numbers, the first three of which are invoices and the last two of which (DM32890/4829 and DM32889/4695) are credits.

After the reference and invoice numbers have been entered from the check stub, the system attempts to match the entries to the corresponding invoices within the system. The clerk is prompted to enter the type of each item (e.g., invoice or credit) and the amount indicated on the check stub. The system then checks to see if the amounts indicated coincide with the expected amounts stored within the system and indicates each item as being reconciled or not reconciled. The clerk then saves the record, which may then be approved and posted by supervisory personnel.

Discrepancies may occur between payment amounts and invoice amounts, i.e., both overpayment and underpayment may occur. An OverUnderPay file is used to track and resolve such discrepancies. An OverUnderPay screen display is shown in Figure 87. A corresponding record detail screen display is shown in Figure 88. OverUnderPay is an example of dynamic workflow and allows for the application of user discretion in handling overpay and underpay situations given the requisite authority.

Business rules implemented by the A/R module include the following:

1. Invoices will be automatically created on shipment of products to customers.

2. Items can only be invoiced once.

3. Invoices must be issued by accounting before they are valid.

4. EDI invoices are provided for. EDI invoices will automatically be sent via EDI.

5. EDI invoices PID numbers must match PO PID numbers in the EDI file.

6. Customer invoice numbers indicated on the check stub must match with existing customer invoice numbers in the system. The amounts must correspond, else an overpay/underpay records is created as described above.

Customer Collections

An important object of the present system is to allow routine operation of an entire business without paper and pencil. In the course of performing a business function, a person will typically gather information from various sources and jot down the information for reference while performing the business function. This reliance on paper and pencil is perhaps most apparent in the area of customer collections. Every invoice to be collected presents a different situation, as does every customer. Previous contacts with the customer may need to be followed up on, or, conversely, the customer may become annoyed at too frequent contact.

The present system overcomes these problems by providing a highly- usable customer collections "environment." Referring more particularly to Figure 141, the customer collections environment is shown within the bottom portion of the screen. Within the top portion of the screen is displayed a Customer Invoice output display showing selected invoices of a particular customer.

The customer collections environment within the bottom portion of the screen is composed of various different panels. A "Get" panel presents aged A/R information and allows the user to retrieve invoices within the different age categories. Pressing "Get" for a particular category causes the corresponding invoices to be listed within the Invoice panel to the left, from which the user can select a particular invoice for display.

The "Get" panels also provides a get Problem/Tickler option. Each invoice may be marked with one or more problems and/or one or more ticklers. When an invoice is selected, problem codes representing problems associated with that invoice are displayed within a Problems list box. Similarly, ticklers associated with that invoice are displayed within a Tickler Log. The user can add and remove problems and ticklers to and from an invoice as appropriate.

A Contact Log is used to record contacts and attempted contacts with the customer. For example, if the customer says "Please don't call again for six weeks," this information can be recorded in the Contact Log. Below the Tickler Log is located a financial summary of the current selected invoice. Below the Contact Log is located payment details of the current invoice. Below the financial summary panel are located text box for invoice-specific notes and invoice-specific keywords. The ability to assign keywords to record and retrieve records using those keywords is provided for the user's convenience. Below the payment details panel is located customer contact information, and to the right of the customer contact information is located a text box for customer-specific notes.

In Figure 141, the user has selected a Get Problems option. As shown in Figure 143, a text box is then displayed listing various possible problems. To mark an invoice as having a particular problem, the user selects that problem and clicks OK. If instead the user selects Get Tickler, a text box as shown in Figure 144 is displayed listing various ticklers. To mark an invoice with a particular tickler, the user selects that tickler and clicks OK.

Referring to Figure 142, the user may also search for invoices within particular categories, regardless of whether a particular invoice has been marked as having a problem or not. The categories (e.g., "With addendums," "Replacements without credit memo," etc.) will typically have implications that affect collection. Dealing with categories of invoices in this manner increases efficiency.

Because all of the relevant infoπnation needed to perform collection, including client contact information, is captured in the database and displayed in a readily-accessible and usable fashion, the collections function can be performed by a relatively unskilled worker following a minimum amount of training. Furthermore, the collections function may be performed by one person one day and another person the next day without confusion or loss of effectiveness, minimizing the effect of sickness and/or employee turnover.

Accounts Payable

The accounts payable module is designed to ensure that invoices are timely paid but to prevent double payment, overpayment, etc., and to systematically resolve problems with invoices so that they may be paid. The payment policy may be more or less aggressive. On the aggressive side, for example, the system may provide that a vendor invoice is paid only after a corresponding customer payment has been received, thereby assuring a stable cash flow.

A vendor invoice screen display is shown in Figure 89. When vendor invoices are received, they are entered within a grid such as that of Figure 90. The invoice number and PO number are entered manually from the invoice. The payee and vendor are preferably selected from pick lists. The invoice date, total billed, tax and freight are entered manually from the invoice. For each entry within the Add Invoices screen, a vendor invoice such as that of Figure 91 is created. Based on the PO number, the system displays items sold from the MWS (with or without addendum, or possibly even multiple addendums) to which the invoice pertains.

The vendor payment process begins by an accounts payable clerk invoking a Daily Vendor Verification option. Referring to Figure 92, this option identifies all of the open vendor invoices and runs them through a "sieve" to determine which invoices are "clean," i.e., fully reconciled, and which invoices are not clean, i.e., have discrepancies. Within each the categories clean and not clean, there are numerous sub-categories arranged in order from most important to least important. A given clean invoice may in fact fall within several sub-categories, but is categorized at any given time into the highest sub-category to which it belongs. Similarly, a given invoice that is not clean is categorized at any given time into the highest sub-category to which it belongs. By double clicking on a particular category, invoices belonging to that category are displayed. Typically, the payables clerk will pre-approve clean invoices for approval by supervisory personnel having authority to approve payment. Invoices that have been approved are then scheduled by the payables clerk to a payment register, an example of which is shown in Figure 93, for payment in accordance with their respective due dates.

For invoices that are not clean, the payables clerk displays invoices from the highest sub-category, investigates each invoice and attempts to fix the particular discrepancy involved with that sub-category. The same approach is followed with the invoices of each sub-category in turn. The verification is then re-run. Some invoices may have become clean, whereas other invoices may have passed to a next-lower sub-category but may still not be clean.

Referring again to Figure 90, prior to entering invoices, the user is prompted as to which type of invoices to be entered, including as one possibility freight bills. When a freight bill is entered, the user enters the invoice number, PO number, and payee (the latter from a pick list), and instead of a vendor list, picks a carrier from a carrier list. The user is then prompted to enter a date range specifying a period to which the freight bill pertains (Figure 94). Shipping records are then searched, and freight charges for shipments with the specified carrier during the specified period are totalled. Invoice entry is then completed in the usual manner. If the invoice amount entered from the invoice equals the expected total charges, then the resulting invoice record is marked reconciled. If not, then the invoice record is marked not reconciled.

Qualification of user inputs, previously described, occurs at each entry point E1-E9 of Figure 59 but is most readily illustrated with respect to invoice entry. Figure 121, Figure 122 and Figure 123, respectively, illustrate various warning dialogs used to prevent entry of erroneous data. If entry of a duplicate invoice number is attempted, for example, a dialog such as that of Figure 121 is displayed, and the system refuses to permit the duplicate entry. If an attempt is made to enter the same invoice twice during an entry session, then a dialog such as that of Figure 122 is displayed. If the system detects that the same invoice number has been used previously but with respect to an apparently different vendor, then the user is notified (Figure 123) and may choose whether or not to proceed.

Note that each item can have only one active customer invoice and one active vendor invoice. This feature prevents may common AR/AP errors. For example, if duplicate vendor invoices are received in relation to a single item, only one of those invoices will be matched with the item record representing the physical item. The other vendor invoice finds no place in the system.

Business rules implemented by the AP module include the following:

1. Items can only be billed once by a vendor.

2. Vendor invoices must reconcile with purchasing costs and terms (freight, tax, payment dates, etc.).

3. No duplicate vendor invoices are allowed. A vendor invoice is identified by a combination of vendor invoice number and MWS number. Hence, the same vendor invoice number may be billed against different MWS numbers (since some vendor's numbering systems may generate duplicate numbers), but not against the same MWS number.

Vendor verification is merely exemplary of a more general methodology for accomplishing a business task. This more general methodology allows a user to perform a business task without the need to refer to different sources of information. In an exemplary embodiment, it involves the following steps:

1. A classification scheme is specified, consistent with common business practice and terminology.

2. An algorithm is applied whereby items are classified, marked and displayed according to category.

3. Within a single display screen, the categorized items are displayed along with one or more user interface controls for taking action with respect to an item.

The items may be items within any of the foregoing domains — products (e.g., computer equipment), payments (e.g., vendor invoices, customer invoices, payment registers), performance (e.g., accounts), or personnel (e.g., activity summaries). Furthermore, the items may be single items or groups of items (e.g., master worksheets).

Other exemplary uses of the foregoing methodology will be briefly described. Still others will be apparent to those of ordinary skill in the art.

The items may be customer invoices and the business task may be collections. The invoices may be classified into various classifications according to the reason for non-payment, e.g, never received, return requested, price discrepancy, etc. The items may be order items and the business task may be an expedite task. The items may be classified into various classifications, e.g., vendor lost order, (re)seller lost item, item damaged, wrong item, empty box, etc. The items may be master worksheets and the task may be purchasing. The master worksheets may be classified into various classifications, e.g., replacement MWS, addendum, internal use, etc. The items may be payment registers and the business task may be reporting. The payment registers may be classified into various classifications according to payee, e.g., vendor, federal government, state government, local government, service providers, etc.

Nightly or Periodic System Update

In addition to the foregoing business rules, or experiential constraints, implemented within each of the individual modules, recall that cross-checks between various domains are performed at intervals. Such cross-checks may be performed nightly or at other periods of low system activity. When performed nightly, the cross-check routine may be referred to as a nightly update. As a result of the nightly update, a nightly update report is generated, all or selected portions of which are automatically emailed to responsible individuals for receipt the following morning. An example of a nightly update report is provided as Appendix A.

General Ledger and Real-time Financials

Having described for an order the course of events in the payments domain, the course of events in the financial performance domain will now be described.

The most "tasking task" for most small- and medium-sized business is accounting. Accounting packages typically come in one of two flavors, packages for non-accountants that mask the complexity of generally-accepted accounting principles (GAAP) but do not provide information in "accountant-ready" form, and packages for accountants that are not readily understood or used by non- accountants. The need for real accounting documents coupled with the difficulty of producing them has necessitated considerable reliance on accountants, either outside accountants or full-time paid staff. If an outside accountant is used, the accountant brings the books up-to-date only at intervals. Even in the case of full- time paid staff accountants, the books are typically brought up to date only monthly, or at most weekly, because of the arduousness of the process. Typically, invoices are reviewed and confirmed, then manually posted, then a trial balance is run, adjustments are made, etc.

Accounting information is presented in the form of financial statements. Information about each item appearing on the financial statements is gathered in an account. An account exist for each asset, liability, revenue, expense, and category of owner's equity of a company. More particularly, the classic accounting process involves the following steps:

1. Analyzing business and financial transaction to determine if they affect accounts;

2. Journalizing transactions affecting the accounts;

3. Posting journal entries to accounts;

4. Determining the balance in each account using incoming bank statements;

5. Preparing a total of all the account balances, called a trial balance;

6. Determining whether any adjusting entries are necessary and journalizing and posting such adjusting entries;

7. Preparing financial statements;

8. Closing income statement accounts and establishing ending balances for use in the next accounting cycle.

In classic accounting practice, the effects of a transaction are not recorded directly into the accounts. Rather, they are recorded in a journal entry in a general journal, or general ledger (GL). The process of transferring the information from the journal entry to the accounts is called posting. At the end of the fiscal period, before making any adjusting entries, an accountant prepares a schedule listing all the individual account titles and their respective debit or credit balances. Following the trial balance, various adjusting entries may be required to assure that reve- nues are reported in the period they were realized and that all expenses are matched with the revenues they produced. An adjusted trial balance is then produced. Financial statements are generally prepared on worksheets from the adjusted trial balance. Whereas balance sheet accounts are permanent (or real) accounts, income statement accounts are temporary (or nominal) accounts. Because the data collected in an income statement account is only for the current fiscal period, the balance is not carried forward but is eliminated at the end of each fiscal period. The process of eliminating the balance in each of the revenue and expense accounts (by transferring the balance to a different permanent account) is called closing the accounts.

As a result of the cumbersomeness of the foregoing process, management processes accommodate the limited availability of accounting-derived management information. In reality, however, the need for management information is constant and ongoing, and cannot be expected to synchronize itself to the availability of accounting information without sacrificing performance.

The present software takes a different approach to financial performance activity. In contrast to typical practice in which an accountant gathers data from all departments and performs accounting functions after the fact, in the present system, accounting functions are performed concommitant with data entry. Instead of manual posting of accounting entries, posting is automatic, either continuous or at user-specified intervals (e.g., nightly). For non-accountants, the complexities of accounting are hidden completely — users simply go about their usual activities of running the business. The automatic posting process, however, generates entries in a convenient format that may be used by those skilled in financial reporting to generate accepted reports, e.g., reports conforming to current GAAP standards. (Because GAAP standards frequently change, are subject to inteφretation, and may vary from country to country, generating entries in a convenient format that may be used to generate reports conforming to GAAP preserves flexibility. For example, the software need not decide when revenue is to be recognized but only needs to record the relevant events which may then be further processed under the direction of skilled accountants to derive a definitive revenue figure.) Furthermore, instead of a limited number of "canned" reports, a GUI-based report- writer is provided that allows any kind of report to readily generated, either on command or on schedule. At any time, a user may simply press a button and obtain a real-time, accurate financial report.

Because posting is automatic, posted entries are not guaranteed to be correct. (Because of the stringent qualification of user entries, however, errors are greatly minimized.) Therefore, unlike conventional accounting packages, entries are allowed to be modified. In the case of invoices, for example, invoices are allowed to be modified up until the time they are paid. As invoices and other records are viewed and modified, they are flagged to be checked by a centralized GL module to determine if the modification requires an adjusting entry. If so, the adjusting entry is made automatically alongside the original entry.

Although in an exemplary embodiment the GL module is a centralized module, the functionality of the GL module may be distributed among the various modules so as to operate continuously. For example, an AR portion of the GL functionality would make general ledger entries immediately to reflect payment information as it is input, a purchasing portion would make general ledger entries immediately to reflect obligations as incurred through purchase orders, etc.

To use the real-time financial capabilities of the present system, the user sets up accounts, then assigns accounts to different line items of records within the system. More than one account may be assigned to a line item. If only one account (i.e., a single default account) is assigned to a line item and an automatic posting option is selected, then the line item is automatically posted to that account. Default accounts are set up for various different files, such as AP, AR, cash, credit card transactions, commissions, payroll, etc., as shown in Figure 95. The manner in which these defaults are established will be described.

Accounts are set up within a chart of accounts. The chart of accounts keeps a record of each account including the name of the account, type of account, account code, etc. To add an account, the user enters information about the account within an entry screen such as that of Figure 96. W ereas debits and credits are intelligible primarily to accountants, increasing and decreasing a balance are concepts easily understood by non-accountants. Hence, when an account is first established, a button is selected designating whether the account balance is increased by a debit or by a credit. Thereafter, user may use the more familiar concepts of increase and decrease. An exemplary chart of accounts display is shown in Figure 97. Doubling clicking on a particular account results in a display such as that of Figure 98. The date of each transaction contributing to the balance is shown, together with an explanation, the journal reference number, and the amount. This screen display may be used to modify account information as necessary.

For accounts receivable, a correspondence between line items on a customer invoice and specific accounts is set up through a customer setup display, shown in Figure 99. Generally speaking, each of the different list boxes corresponds to an amount that is (or is derivable from) a line item (or multiple line items) on the customer invoice or other record. The account or possible accounts to which the amount is to be or may be posted are specified by clicking the "+" button and selecting from a pop-up list of accounts of the appropriate type. If multiple accounts are selected, one may be selected as a default account, the effect of which is explained hereinafter. If for each list box only a single account is selected and is designated as the default account (using the Set Def button), then posting is automatic and is performed on a continuous basis or at regular intervals (e.g., daily). As a result, a truly up-to-date financial report can be run at any time.

Referring to Figure 100, an accounts receivable display is shown in accordance with an exemplary embodiment of the invention. For each customer account, there is shown the GL account to which balances are posted, the current account balance, and amounts 30, 60, and 90 days overdue, respectively. By double-clicking on a balance field, transactions records relating to that balance field are displayed. For example, double-clicking on the current balance of $2,712.75 shown in Figure 100 results in a display such as that of Figure 101. The date of each transaction contributing to the balance is shown, together with an explanation, the journal reference number, and the amount.

Corresponding screen displays for accounts payable as those of Figure 99, Figure 100 and Figure 101 for accounts receivable are shown in Figure 102, Figure 103 and Figure 104, respectively.

If the setup of accounts indicates that an amount may be posted to more than one account, then manual account distribution is required. Referring to Figure 105, a pop-up screen display used for this purpose is shown. The assigned accounts are displayed, and the user enters debits or credits for the accounts as appropriate. The effect of a debit or credit (increase or decrease in the account) is displayed as an aid to the novice user.

Referring to Figure 106, a general journal display is shown in accordance with an exemplary embodiment of the invention. For each transaction there is displayed a journal reference number, account titles and explanation, and posting reference to the account codes of the accounts debited or credited as result of the transaction. Doubling-clicking on a particular account results in a display such as that of Figure 107. The date of each transaction contributing to the balance is shown, together with an explanation, the journal reference number, and the amount.

As a result of the continuous, automatic posting activity described, once a financial report has been defined, it may be run at any time (or at scheduled times) and is assured to be up-to-date. Moreover, it is verifiable, i.e., every supporting transaction may be readily retrieved and viewed. In an exemplary embodiment, a financial report is defined using a display screen such as that of Figure 108. The display follows a familiar spread-sheet-like format. For each line of the report, a line item description is entered. Then, in the appropriate column, the user enters either an account (by selecting from the chart of accounts pop-up), a calculation formula, or even the result of another report. When a report is run that requires the result of another report, that other report is run first. An actual report generated using the report definition of Figure 108 is shown in Figure 109.

A report, instead of being the line-time type of Figure 109, may be a trend analysis report. Trend analysis provides a powerful tool for understanding interrelationships between various aspects of a business. Referring to Figure 110, a trend analysis report is defined in similar manner as an ordinary financial report. A cell is selected and the user is prompted as to whether the cell contents is to be a local balance, a linked field (from another report), or a calculated field. In the illustrated example, local balance is selected, and the user selects an account from the chart of accounts pop-up, in this instance Cash in Bank #1. To investigate the inter-relation of different accounts, a further account would then be selected, say Trade Accounts Payable. Plot labels may be entered by the user that differ from the actual names of the accounts themselves. Referring to Figure 111, a trend frequency is then selected. In the example of Figure 111, the trend frequency has been set to daily. The trend analysis is then run and the raw data displayed as shown in Figure 112. Referring to Figure 113, various graphing options are provided. In the illustrated example, the data is presented in the form of line graphs.

Trend reports, aside from comparing one account to another over the identical period, may also compare the same account over different periods. Hence, in the case of both financial reports and trend analyses, an important feature is that the date range of the report is arbitrary. Historical data for all past periods (or at least a considerable number of past periods) is stored in the database, enabling reports to be run for any period of time, not just the current period. Human, Group and Organization Performance

Having described for an order the course of events in the financial performance domain, the course of events in the personnel domain will now be described.

By and large, present-day work activities are based on the model of an 8- hour work day, 40-hour work week. What is tracked quantitatively is time and attendance. Actual performance, by and large, is tracked qualitatively. Although such a model may have been adequate for the industrial revolution, it is inadequate and without basis for purposes of the information revolution. Instead, the present system allows performance to be quantitatively tracked.

Referring to Figure 114, there is shown a human resource infrastructure for a virtual organization performance evaluation model. All company personnel are linked to a digital "HR backbone," including operational management (V.P.s, managers), engineering, strategic management (president), financial and legal personnel (CPA, lawyer), and staff within various departments (customer service, shipping/receiving, technical, accounting, purchasing, etc.). In concept, the HR backbone could be any information conduit. In an exemplary embodiment, the HR backbone is realized by the same integrated, Web-enabled, client/server database as described heretofore. Various functional blocks manipulate data stored within the database and form a personnel module.

Two functional blocks in particular from the basis for performance evaluation, a Measurement Factors block and a Score Keeper block. For each individual whose performance is to be tracked, a list of tasks performed by the individual is compiled, together with an estimate of what percentage of the individual's overall assignment each particular task constitutes. Using this information, the individual participates in the setting of realistic goals within various categories. These goals are stored so as to readily accessible to the individual for frequent review. The goals in turn dictate measurement factors/parameters tracked by the "descriptive" Measurement Factors block. These factors/parameters form the answer to the question "What is the pertinent data within the database upon which to evaluate the performance of the individual?," both individually and as a team player. Suggestions received from within the organization may influence the pertinent measurement factors/parameters.

The question, "How should the data be viewed?" is answered by a group of "normative" functional blocks. These blocks generate outputs to the Score Keeper block, which measures the degree of success or failure with respect to each goal. The same outputs are input to a "presentation" block that serves to educate employees as to the effects of various normative performance measures on financial performance and on factors affecting customer satisfaction, to help employees identify trends, etc.

Customer feedback (both commendations and complaints) are preferably also be received by and input to the system. A firewall provides security for internal data and allows limited access by customers to provide feedback. Customer feedback, although not strictly objective like the other factual measures of performance tracked by the database, can be an important indicator of performance.

Referring to Figure 115, a more detailed view is shown of the kinds of data stored in the human resources portion of the database. With the exception of data relating to performance measurement factual review, the data represented in Figure 115 is static or semi-static data that changes relatively infrequently or not at all. The top portion of the figure relates to candidate data, whereas the bottom portion of the figure relates to employee data.

For candidates, data stored in the database includes personal data, previous employment data, and previous performance data. The data is obtained from the candidate and from other outside sources, and may also be made available to the candidate, e.g., through the Web. During the hiring process, employment documents are scanned (or input directly by the candidate during the application pro- cess) into the database. For employees, data stored in the database also includes personal data, employment data and performance data. In addition, for employees, data regarding achievements and special recognition is stored.

Performance measurement factual review is dynamic in nature and may be performed in a manner illustrated in Figure 116. Depending on the organizational level, performance measurement is either financial-oriented or assignment oriented. For branches, divisions, subsidiary companies and their parent company, for example, performance measurement is financial-oriented and uses financial analysis algorithms. In particular, using the universal financial report generator described previously, any desired financial ratio may be tracked, as well as any arbitrary combination of account codes in order to discover relationships. Cash flow statements and budget analyses may also be generated. Based on this information financial performance goals may be set and contributing goals may be accurately derived.

At the department, group and employee level, performance measurement is assignment oriented.

Referring to Figure 116, evaluation of human performance is made possible by collecting an assemblage of activity data to which analysis algorithms may be applied. This assemblage of activity data is referred to as Algorithm of Activity Data. For each different assignment (e.g, Quotes, MWSs, Customer Invoices, etc.), activity is tracked in three principal ways: quantity per period, dollar volume by period, and time between stages of completion (e.g., time from posting of quote to conversion to MWS). The relevant period is preferably user-selectable. In addition, the responsible department and the upstream and downstream departments that affect and are affected by the assignment are identified (and refined, if necessary, as experience with the system is gained). RMAs affect all assignments and are therefore tracked in relation to each assignment. For example, quotes made during a period may total one million dollars but may have ultimately resulted in half a million dollars of RMAs.

The Algorithm of Activity Data serves as a foundation for human performance evaluation. Referring to Figure 117, for each individual employee to be evaluated, various metrics from the Algorithm of Activity Data are chosen and tracked for that employee, resulting in Employee Specific Task/Assignment Activity Data. Different aspects (e.g, quantity, dollar volume, completion times) of an assignment (e.g, Quotes, MWSs, Customer Invoices) may be chosen as metric for evaluation for a particular employee.

The Factual Performance Analysis Measurement process performs calculation on the Employee Specific Task/Assignment Activity Data, for example calculating time "deltas" between different stages of completion of an assignment. Resulting data is supplied to at least three destinations: a Measuring Algorithm, a Historical Data Comparison Algorithm, and an output display structure, indicated by dashed lines. The Measuring Algorithm compares actual performance to desired performance established by goals. Preferably, goals are set by employees in consultation with management. In an exemplary embodiment, the Measuring Algorithm compares actual performance to desired performance in three different categories: routine assignments (daily, on-going), scheduled tasks (not on-going) and special projects (typically short-lived). In addition, unique date-independent measurements may programmed, for example as alerts. For example, the user may program the Measuring Algorithm to alert the user whenever the time delta between creation of a quote and posting of the quote is seven days or greater. Various priorities may be established in accordance with corresponding parameters. For example, a particular order may be marked as critical, causing an alert to be displayed if there is any slippage in schedule.

The Historical Data Comparison Algorithm archives the daily output of the Factual Performance Analysis Measurement and the Measuring Algorithm blocks and allows for comparison of performance data for different dates. Within the output display structure, a hierarchy of views is presented. A first view is a complete list, based on the Algorithm of Activity Data, of departments and the tasks and projects for which they are responsible. From this complete list, the user may create the users own "short list" of departments for performance review. Different layers of management, for example, may have different departments within their scope of review.

To display performance data, the user selects a department, causing performance data to be displayed for the department as a whole. The user may further select a specific individual within that department, in which case a Dynamic Personal Tracking view is displayed. The Dynamic Personal Tracking view displays all of the chosen metrics for the selected employee. From the Dynamic Personal Tracking view, the user may transition to a Factual Performance Display. The Factual Performance Display is a subset of the Dynamic Personal Tracking view and focuses on those metrics presently deemed by the user to be most important (e.g., metrics related to sales growth, metrics related to customer service, etc.)

The Factual Performance Display highlights strengths and weaknesses of the employee and is linked, either automatically or manually, to static human resources "personal growth guides." Based on the Factual Performance Display, it may be evident, for example, that the employee in question needs training in a certain area. In this manner, the system allows training efforts to be narrowly targeted where they will obtain greatest benefit. A career path may be charted for each employee that is calculated to maximize that employee's potential.

Screen displays used for factual performance evaluation in accordance with an exemplary embodiment of the invention are shown in Figure 118, Figure 119 and Figure 120, respectively. Selection of an employee is accomplished as illustrated in Figure 118. Referring to Figure 119, performance results may be viewed for a single period or multiple periods, with the period being user selectable (a day, a week, a month, a quarter, etc.). In the case of the single period display, perfor- mance results for various performance metrics in different categories and sub-categories are displayed, for example: Productivity (A), including quantity per period (Al), dollar volume per period (A2) and percent profit per period (A3); Quality (B), including timliness (Bl) and customer credit memos (B2); and Profitability (C). In the case of the multi -period display, the same information is viewable for multiple periods but, because of display contraints, not all of the information at the same time. Rather the user selects the categories and sub-categories of interest for viewing at any particular time. For example, if sub-category A2 is selected, then dollar volume per period is displayed for all of the periods (e.g., six).

Percolation — Automated Low-Level Decision-Making

In order to automate a small-to-medium size business, relatively complex tasks must be automated so as to be accomplished with a few clicks of the mouse. The present system accomplishes such automation using a technique referred to herein as "percolation." Percolation involves automatically classifying records of a given type into multiple classifications for workflow processing. One or more users interact with the relational database system to take a prescribed action with respect to multiple records having a particular classification. The records of a given type are classified into multiple classifications based on "experiential" criteria having real-world business significance based on past business experience. A record may belong to a multiple categories. Records are sorted in accordance with a hierarchy of categories such that a record belonging to both a category higher in the hierarchy and a category lower in the hierarchy is sorted into a group of records belonging to the higher category. The relational database system does not allow users to take at least some actions other than the prescribed action with respect to the records. Users interact with the relational database system to change information within records, whereupon the records are automatically reclassified.

Percolation may be applied to any business function, but has found to be particularly effective as applied to PRIS (purchasing, shipping, receiving, installa- tion and assembly), vendor invoice verification, customer collections and processing of returns. Percolation may be single-level or multi-level.

Percolation as applied to vendor invoice verification has been described previously. As was previously observed, the hierarchy of classifications is important in order to obtain the desired results. To take advantage of dynamic workflow, however, it is desirable that a user having the requisite authority be provided with the ability to change hierarchies (specify a new order of classification), both within a single level and on multiple levels. There results a very powerful ability to "slice and dice" data records stored within the database, which in turn provides for dynamic response to outside influences.

Referring to Figure 150, percolation as it applies to purchasing will be described. Sales orders resulting from quotes undergo a first level of percolation to identify sales orders on credit hold, sales orders exceeding credit limits, sales orders with customer invoices 60 days or more past due, sales orders with freight problems, sales orders with installation, sales orders with installation and/or shipping problems, sales orders with a ship group, sales orders with partial ship, etc. As a result ofthis first- level percolation, certain orders may be placed on hold, or corrections may be made to the order as required.

There follows a second-level percolation at the item level preparatory to placing vendor orders. Items undergo percolation to identify items with higher sales cost than sales price, items with higher purchasing cost that sales cost, items on back order with groups (install/ship), rush items, items with back order received in a "no partial" sales order, items with promotion or rebate, etc. In accordance with one aspect of the invention, such percolation in effect identifies "critical path" items for fulfilling an order, items that will take the longest to fill based on avail- ablity, installation instructions, shipping instructions, etc.

Corrections may be made and reclassification performed until such point as the user is ready to order. The user then prepares a purchase order request, either using a default vendor determined at the time the order was placed (lowest cost vendor) or selecting a different vendor. The vendor order may then be placed by posting via the Web, or the vendor order may be posted on the Web for bid. In the latter instance, bid results are received via the Web, and the vendor order is then placed based on the bid results. The order is filled by the vendor and shipped to the reseller or drop shipped to the customer.

Note that purchasing may or may not involve vendor selection. At the time a quote is created, a default vendor is selected based on lowest advertised price. Order information may, if desired, be automatically transmitted to the default vendor. In fact, N-tier order information may be automatically transmitted to multiple corresponding vendors as described more fully hereafter in relation to supply chain management.

Referring to Figure 151, percolation as it applies to receiving will be described. Sales orders for which vendor orders have been place and that need to be received undergo a first level of percolation to identify receiving sales orders to be refused or cancelled (because of RMA, for example), COD sales orders, express delivery, sales orders marked for special tracking (e.g., call upon receipt), replacement sales orders, no partial or restricted partial sales orders with only one item, sales orders expecting back order items, sales orders with installation, sales orders without installation, inventory sales orders, supply sales orders, RMA returns expected from customer, RMA returns expected from vendor, RMA returns requiring install/de-install, etc.

There follows a second-level percolation at the item level preparatory to actually receiving items. Items undergo percolation to identify items cancelled, items to be refused, items with COD, items with express delivery, items for replacement orders, items marked back order, items in an auto-tracked sales order, items holding up installation, items holding up ship group, RMA items needing deinstall, etc. Corrections may be made and reclassification performed until such point as the user is ready to receive. The user then starts the receiving process and, optionally, receiving status is posted via the Web or via email to selected customers and/or vendors.

Shipping percolation is in large part analogous to receiving percolation, previously described, and is illustrated in Figure 152.

Installation percolation is illustrated in Figure 153. Installation percolation may be single-level, identifying sales orders with a large quantity of installation, sales orders ready for software network integration, sales orders ready for assembling, sales orders missing one last item, sales orders with a defective component for RMA processing, sales orders with RMA waiting for vendor shipment, sales orders with RMA needing de-installation, sales orders with RMA needing re- installation, sales orders with RMA for warranty repair (off-site, on-site), sales orders with RMA for out of warranty repair, etc.

Supply Chain Integration/Management

The present software program provides for Web access by various business partners to all of the information relevant to the business. The software may therefore be described as Web-enabled Enterprise Resource Planning (WERP) software. The present WERP software allows for an unprecedented degree of supply chain integration/management. Referring to Figure 154, a left-hand side of the figure illustrates a sell/demand chain, and a right-hand side of the figure illustrates a supply/assembly chain. User demand information is gathered by a user following a URL link from a customer Web site. The link accesses the present WERP software. Using the software, the user creates a quote. Assuming the ordered item is not discontinued, the quote may be converted into an order. The item may be sold complete with no component assembly required, or may be sold with component assembly required. In the former instance, the order is posted to purchasing, and the item is ordered, e.g., by communicating order information to a vendor Web site and a manufacturer Web site. In the latter instance (component assembly is required), a component file is accessed to retrieve a unique set of components for a specific item SKU. Given the order quantity, a total component requirement is determined. Within PRIS, component grouping is performed, e.g, such that multiple "child" MWSs each contain (in bill-of-material fashion) all of the components required to assembly a single one of the ordered items, and a "parent" MWS of the children MWSs contains the corresponding number of complete items. The components are ordered by, as in the previous instance, communicating order information to a vendor Web site and a manufacturer Web site.

Note that, if an item is discontinued or not available (i.e., backordered), if the items component parts are still available, the item may still be sold, the component parts ordered and assembled, and the item shipped. Equivalent components may be substituted where necessary or convenient. Also, order information may be conveyed to a hierarchy of suppliers. In the case of a computer, for example, the vendor may be Ingram and the manufacturer may be Compaq. Compaq's suppliers may include makers of microprocessors, memories, disk drives, etc., whose suppliers may include in turn wafer manufacturers, platter companies, plastic companies, etc.

One key to the type of supply chain management described is breaking down items into multiple "tiers," each successive tier including component parts for items of a previous tier, and creating a record for each component part. Supplier relationships from one tier to the next may be identified based on information that is automatically updated on a frequent or substantially continuous basis. Percolation of the type previously described may then be performed on component parts, with classification being performed on the basis of availability within multiple tiers. Availability information within multiple tiers may be obtained via the Web. If customer specified installation and/or shipping instructions are likely to cause substantial delay in filling an order given availability information, the customer may be contacted to see if the customer desires to change instructions in order to minimize delay. In the case of channel assembly, when component parts are received, they are assembled into items for shipment to the customer.

There results a virtual inventory system with no backorders in which the order cycle time for the entire supply chain is compressed to that of a single order (single stage of a typical supply chain).

Web Universal Business Engagement Rules (WUBER)

Various customer-specific customizations of the behavior of the present

WERP software have been described. Information representing desired customizations for a particular customer are stored in a customer file of that customer. During operation of the software, whenever customizable operations are performed, the software checks the customer file to determine how to proceed.

Such customization may be extended to embrace virtually all of the "business engagement rules," both general and industry-specific, commonly negotiated between business partners. Such business rules serve as an electronic template for specifying a customized business relationship. By providing Web access to a comprehensive ("universal") set of relevant business engagement rules, the creation and management of information-age business relationships is greatly simplified. The feature of providing Web access to a comprehensive set of relevant business engagement rules is referred to herein as WUBER ("Web Univeral Business Engagement Rules").

In a preferred embodiment, WUBER not only provides for the specification of business engagement rules, WUBER also provides for the enforcement of the business engagement rules during the course of business operations. For example, during the course of a business relationship, the customer may decide that all shipments are to be made via a specific carrier. Once that carrier has been specified for that customer within WUBER, the software will not permit shipments to be made via a different carrier.

The extent to which a customer may freely change that customer's business engagement rules may vary by customer. For some WUBER fields, all customer's may freely select any available menu choice. For other fields, bounds may be set within which the field may be changed. These bounds may vary from customer to customer. Hence, whereas an acceptable return period for one customer may be up to 90 days, an acceptable return period for another customer may be up to 180 days, for example.

New business engagement rules may be easily added to WUBER. Presently, as new business engagement rules are added, enforcement code must be manually written and added to the software program. In the future, such enforcement code may be automatically generated.

A specific example of a WUBER electronic template in table form is shown in Figure 155. Within the header row of the table are listed various customizable program tasks. Each column of the table lists various options pertaining to a particular task. Various fields of the template will be briefly described.

Various options in the Price Update column govern how products are priced and display for a particular customer. If an Activate flag is set, the options selected within the column will be enforced during operations of the software. If the Activate flag is not set, program defaults will be applied instead. Pricing may be fixed price or cost plus. The frequency with which prices are updated is selectable, e.g., daily, weekly, monthly. If a customer has obtained a quote but not yet placed an order, for example, the customer may want the quote price to not change (even if in the customer's favor) for a specified period of time. Furthermore, a price minimum update amount may be specified; for example, price changes less than a dollor (or, say, less than 1% of the previous price) might be ignored. Various other options relate to the manner in which products are displayed, for example all products, new products, discount products, products of a specific manufacturer, etc. A Personal Product List (PPL) is a user-specific list of frequently-purchased products. A Product ID (PID) is a collection of products (usu- ally related) saved under a single identifier.

In the Quotes column, the customer may specify which system users may create quotes, which may save/retrieve quotes, which may modify quotes, and which may submit quotes. The customer may further specify various limits, e.g., a per-quote dollar limit, a per-day quantity limit, a limit on the number of quotes made per day, etc. Similar options are provided in relation to Orders and RMAs. Note, however, that an important option in relation to RMAs is automatic RMA approval.

In the Service & Repair column, various options may be specified, including service contract length and service response time, whether service to occur on- site or off-site, various service charges, etc. In the Shipping column, various delivery options are specified. In the Tracking column, various options are specified regarding how customer order information is to be tracked, e.g., whether tracking by serial number is desired, as well as various tracking thresholds by dollar amount, how recent the transaction is, quantity, etc.

In the Invoice column, various options relating to invoice delivery are presented. In addition, the customer may specify a billing frequency and whether credits are to be applied to invoices, whether replacement invoices are to be issued, etc. In the Credit Memo column, the customer may specify whether credit memos are to be issued to the customer (external) or whether an internal credit is to be issued, etc.

In the Payment column, various payment options are specified, including whether the ability to retrieve payment information is desired, credit card limits (credit card purchase dollar limit and frequency limit), check information, and EFT (Electronic Funds Transfer) limits.

In the Security column, various security options are specified, including for example, encryption, SET (Secure Electronic Transactions), security certificate, VPN (virtual private network), etc. Security may be handled by the customer on its own behalf or may be handled by the vendor. The present WERP software may in some instances be installed within the customer's firewall such that it becomes in essence part of the company.

The Access Group column is used to specify the access rights of different users. In the case of viewing quotes, for example, access may range from access only to one's own quotes (individual access), access to one's own quotes and those of user's whom one supervises (supervisory access), or universal access (in the case of a high-ranking executive, for example).

The Business Activities column is used by the customer to request that certain information about its business activities be tracked and made accessible. Such information may include, for example, the busiest order period (week, month) the slowest order period (week, month), etc.

The electronic template of Figure 155 is for the customer side of a business relationship. A conesponding template may also be provided for the vendor side of a business relationship. That is, from the point of view of a reseller, the template of Figure 155 expresses demands of the reseller's customers on the reseller. The template of Figure 156 expresses the demands of the reseller on the reseller's vendors.

A further example of WUBER is shown in Figure 160, showing a customer file screen display. Within the right-hand portion of the display, the customer is able to, via the Web, set customer-specific criteria for automatic RMA approval.

Virtual Intelligent Guide (VIG)

As should be apparent from the foregoing description, the present WERP software is designed to minimize the impact of personnel changes. To achieve this goal, the WERP software incorporates a Virtual Intelligent Guide (VIG). The VIG: 1) defines a task path for accomplishing each functional task by interacting with the system; and 2) captures and applies employee knowledge to refine each task path and disallow errors. The result is to enable relatively unskilled personnel to quickly become proficient at performing complex functional tasks in a simple manner using the software. An example of VIG was described previously in relation to accounts payable. The same model may be applied to accounts receivable, RMAs, sales, PRIS, etc.

Tracking Prospective Customers and Vendors

Customer and vendor files may be provided not only for existing customers and vendors but also for prospective customers and vendors. In the case of vendors, prospective vendor files provide a mechanism for capturing the knowledge of buyers in purchasing and of minimizing the impact of personnel changes. In the case of customers, prospective customer files facilitate sales force automation as will be presently described.

Sales Force Automation

During sales calls, a salesman will often be asked various question about particulars of various business transactions. If the salesman happens to know the answer, the salesman can answer immediately. More typically, the salesman doesn't know the answer and is forced to reply "I'll have to get back to you on that." "Getting back to you" will usually take days and may even take weeks, or may simply not happen at all. Cunent sales force automation software does little to address this situation.

The present WERP software provides the ultimate sales force automation tool. Instead of "I'll have to bet back to you on that," the salesman can instead say "Let's check on that." The salesman may then immediately use the Web to access the information needed to answer the customer's question. Web access may be through a desktop or laptop computer, either wired or unwired, or may be wireless through a handheld or palmtop computer. Alternatively, connection to the Web may be made prior to a sales call to download for a particular customer — all of the records, the most recent records, or some other subset of particular interest.

In addition to the foregoing functionality, various features of existing sales force automation tools may be added to the present WERP software, including such features as contact management (contact profile, contact history), account management (account information, outstanding and historical activities, order entry, order history, lead tracking, sales cycle analysis), sales force management (expense reporting, territory assignment, activity reporting, special events tracking), time management (calendar, single and multi-user scheduling, to-do lists, ticklers, notes, timestamps), telemarketing (call list assembly, call recording, call planning, call reporting), customer service (request assignment, tracking and reporting, order status and tracking), etc. All of these functions can be performed "on-the-fly," in real-time with up-to-the-minute information. This real-time operation is made possible because the underlying data is the same item sold/item detail data used throughout the system, simply viewed from an SFA perspective.

Figure 157 is a block diagram of a client/server business automation system in which a common database supports both end-to-end business process automation and sales force automation.

Refening to Figure 158, the sales force automation capabilities of the system of Figure 157 are represented in greater detail. A sales force automation module combines known sales force automation functions with additional functions made possible only by the end-to-end business process knowledge base stored in the single database described previously.

Known sales force automation functions include, for example, activity logging (actual time and data of daily activites by customer), intelligent notes (sort- able and editable), and triggers (reminders) for follow-up calls, major opportunities, etc. The functions are supported by a summary display (drawn from the customer file) used to display contact information for customers by department and title. Various other functions may also be provided.

An expense reporting function is also provided. Unlike conventional sales force automation tools, however, expense information is combined with compensation information stored in the database in order to gain a complete picture of the profitability of a saleman. Based on profitability, a rewards structure may adjust the compensation of the salesman and provide performance feedback to the salesman through the sales force automation module.

Forecasting information may also be displayed to the salesman through the sales force automation module. Because the database stores complete historical transaction information, a sales forecast can be readily compiled based on the historical base. Other types of forecasts can also be compiled. For example, market projection information may be entered into the database (downloaded or entered manually), and based on this information, a forecast can be compiled. A forecast can also be compiled based not only on cunent customers but based on prospective customers. Such a forecast provides additional motivation for a salesman to convert prospective customers into actual customers.

Information from WUBER may also be displayed to the salesman through the sales force automation module. When a new salesman succeeds a departing salesman, the new salesman, by consulting WUBER, can readily learn the established business engagement rules for a particular customer.

Information from the human performance module may also be displayed to the salesman in the form of an activity summary display. In an exemplary embodiment, activities in various categories (columns) are quantified (rows) in dollars where applicable (for both sales and purchase orders), in quantity where applicable and in duration where applicable. For example, dollars sales, dollars purchase orders, and unit volume (quantity) are displayed for the previous year, the present year, and for the previous month, as well as for the peak month (max.) and the low month (min.). In other categories, e.g., ship-to-date and payment history, an average time in days is displayed, between the time an order is placed and shipped and the time an invoice is sent and paid, respectively.

An example of a screen display for Sales Force Automation is shown in Figure 161. Purchase Requisition Budget Forecast

Orders, represented by MWSs, may be for resale or for internal use. A field within the MSW record distinguishes the type of MWS, including whether it is for internal use. Just as historical analysis and forecasting may be applied to customer sales, these same techniques may be applied to internal sales. The cycles of pinch/ spend that often aflict corporate departments may therefore be avoided. Managerial personnel are able to determine easily in real time how much of a budgeted amount has been spent and how much remains to be spent.

Comparison With Known Workflow Systems

In contrast with known workflow systems, the present system, sometimes refened to hereinafter as the ICE™ (Internet Commerce Equalizer) system, represents a purpose-built application suite where all applications are both physically implemented and logically rational source or target applications in a Dynamic Workflow™ Environment

The ICE system may be described as a broad-spectrum suite of Internet- optimized business applications, that are designed and built to permit the implementation and execution of workflows without the mandatory parameter setting, software switch setting, customization and workflow preparation common to all other workflow environments. This is made possible by several, simultaneous development and runtime environment characteristics and by several carefully considered simultaneous application design and development practices.

To appreciate the difference between the ICE system and conventional workflow systems, the background of conventional workflow systems will be briefly described.

Arguably the origins of workflow are as ancient as the origins of industry. In modem industry, workflow has taken the form (under different names) of the assembly lines of Henry Ford, or as the doctrines of time and motion as formalized by industrial theorists like Taylor and Gilbraith. Very recently, (the 1980s) workflow has appeared in computing and office automation in the form of task-based menus and wizards. Most recently, (the mid- 1990s) workflows have taken the form of environments that tie ordinary business applications together into larger, structured super-applications that consist of applications tied together in a workflow definition environment driven by workflow "engines."

These environments have the capability of performing state-transition or branching logic in contrast to the more mundane task-based menus. And unlike wizards which are normally used for intelligent installation procedures, workflows are usually used to support the structured execution of routine business applications.

Examples of such environments could include SAP's workflow operating in the Dr. Schier™ graphical workflow environment or Baan's Dynamic Enterprise Modeling running in the COSA™ environment. And, these environments have one common heritage with workflow of the past. Notwithstanding words like "dynamic" in their names, these environments are inherently static.

Static is used to mean that once a workflow has been built and implemented in any of these workflow environments, it stands as a defined super-application. To execute a workflow in any of today's existing workflow environments that has not been previously defined, prepared, and implemented is not possible. A user attempting to do so would find himself in the same position as a factory worker who attempted to execute an assembly procedure off the assembly line. He would find himself without resources or the means to execute any procedure for which a physical infrastructure had not yet been created.

The ICE system has a true dynamic workflow environment. This means that the users of the ICE system can go places with the application even when the metaphorical steel rails of an assembly line have not yet been built there.

In order for this to happen, the ICE environment must be fundamentally different from competing pre-defined, structured workflow environments. The basis ofthis dynamic flexibility and the goal of all recent design efforts is the enabling of all ICE applications as potential sources or targets in a workflow.

This potential must be inherent, and not the result of extensive preparation, switch setting, or parameter setting of older-generation applications. It does not even matter if this preparation is largely automated in a separate (static) definition and development environment, because such relative ease of building workflow scaffolding is qualitatively different than not requiring scaffolding for workflow mobility in the first place.

Real- world business users of older-generation enterprise applications have made comments like, "it's like taking off handcuffs," to navigate and solve business problems in the ICE system. Dynamic Workflow means that the user is not bound to one pre-defined way of doing a business procedure or of solving a problem.

Of course, the ICE system can enforce business procedures (in fact most routine business procedures in the ICE system are completely automated) and of course the ICE system allows for conformance to GAAP and APICS standards in accounting and manufacturing. But wherever possible, the ICE system gives the user a choice even as it automates routine procedures. And when it comes to exception handling, the Dynamic Workflow environment in the ICE system saves significant time and effort.

In ordinary ERP and business systems, sequences of applications known as workflows are built up using specialized development environments. As with any other application, workflow or subsystem that is built up from either lines of code or from higher level components or applications, nothing exists that has not been previously defined and built.

In other words, to execute a particular workflow, someone must first implement it. The implementation system must follow strict rules and in many cases perform complex re-configurations of the workflow applications so that they are properly enabled as "source" or "target" applications. The workflow environment starts out either as a template of other pre-existing workflows, or simply as a blank slate on which to build the workflows that are to eventually be executed.

In the ICE system, by contrast, it is possible to navigate a comprehensive "web" of applications in any way needed by the user, with each and every application already a potential source or target application to every member of the navigation web.

A unique feature of the ICE system is its capability to support Dynamic Workflow. Dynamic Workflow may be described as follows:

• Conventional workflow starts with a blank slate and then builds up the workflow from individual applications or components. Even when workflow templates are used those templates simply specify which components are added by default to the blank slate.

• In conventional workflow systems, applications must be carefully conditioned, parameterized, and otherwise programmed to work together in a specific workflow, because they must often pass messages, passed parameters, or transactions between them. Those transactions must be data-type and business-rule-logic compatible.

The applications that comprise a workflow will rarely work outside of the specific work flows they were designed for. This is because in conventional application systems the applications work more or less independently and are typically constructed around one or more specific (and independent) data files.

• This means that work flows must be constructed just like applications. Nothing is executable unless it has already been defined and implemented. The only difference is that applications are built up from routines and workflows are built up from applications. Workflows are simply hyper-applications that are built from components at a coarser level of granularity and a higher level of abstraction than the individual applications that make up the workflows.

• Even the most sophisticated and flexible of the existing workflow systems require active developer, designer, analyst and system-support intervention before the workflow can be implemented. • Conventional workflow works as a "start with nothing and build" method. No application-to-application pathway exists unless and until it is actively implemented.

The ICE system has a number of architectural characteristics that when combined, produce a unique Dynamic Workflow execution environment:

• It is a characteristic of the ICE architecture that all applications are object-based methods that interface with a unified, synchronous, "solid-state" database.

These methods are written in such a way that most of them can be safely invoked in any order. Because these methods are actually only different logical views of the same "solid-state" database, any changes made by one method to the "solid-state" database, are simultaneously, instantaneously, and synchronously virtually "posted" to all other methods, in the ICE system.

• It should be noted that this posting is strictly virtual. No physical parameter passing is done and none is required, because there is only one database operating under strict rules of commit control. All database updates are accomplished synchronously, and under the protection of internal database commit control such that any data update is instantaneously and simultaneously propagated through any view that sees that data.

• In contrast to workflow systems where business objects are placed on a blank slate, and where no workflow exists that has not been previously defined, the ICE system is a web of business functions (methods). Potential connectivity and application-to-application workflow are universally present.

• This permits a "start with everything and set guidelines" workflow model.

• Normally, in the routine user interaction with the ICE system, routine, pre-defined business workflows are followed, and these are documented and programmed into the system as user guidelines, task-based menus, wizards, or procedures. Workflows may also be defined with state-transition intelligence, such that a particular data entry value will result in changing the next application along the application path.

At end-user security levels, these procedures can be defined so that any change from a normal business procedure requires supervisor approval. User roles, rights and authorities can be comprehensively managed.

• However, if an exception condition arises, the user of the system has the option of invoking whatever necessary relevant application is required, with the assurance that data integrity, data consistency, and in most cases, business mles will not be violated.

• Occasionally, management or supervisors will want to change business rules on purpose, and this can be done at a high enough level of supervisory system authority.

• Furthermore, all workflows in the system and the applications that comprise those workflows are structured in such a way that the workflows can readily be reversed at any time. An example would be when a sales situation turns into an RMA. In such a situation, the same workflow can be changed into a reverse workflow at any stage by simply reversing navigation.

It should be noted, that whenever necessary, rational business rules can be overlaid on top ofthis "universal navigation Web" as would be the case if the invocation of a method results of posting the general ledger.

• In such a case, business mles dictate that the original posting general ledger must remain intact, and the corresponding opposite entry must be made. Even when such exception conditions are defined, universal navigation of the system is still possible if the user has a high enough level of authority.

• By creating a workflow environment where nearly any business method invocation sequence can be followed without violating system integrity, the ICE system has achieved a new level of system flexibility and the ability to respond to business contingencies.

Even in the most flexible conventional workflow systems, situations arise where new methods need to be inserted into a workflow sequence, or other methods need to be removed, or an alternate method substituted for the original method. In a conventional workflow system, the new procedure must be defined, the applications properly prepared, through the setting of parameters and switches, and then the workflow must be tested.

• In such a situation, both application logic and database changes can have a negative "ripple effect" throughout the system often requiring extensive impact analyses.

• Obviously, this process is time-consuming, and is not practical for response in a contingency or exception situation. In the ICE system predefined workflows are set out as guidelines for normal business pro- cedures such as order entry. At the same time, the user is able to override these guidelines whenever necessary. It means that the system can respond dynamically to changing business conditions.

While it should be emphasized that the system does not create apphcation functionality or business methods were none existed previously, it should also be emphasized that the system is capable of dynamically adapting business workflows to ever-changing conditions. This allows the ICE system to respond dynamically to business impacts.

• Even where new methods are required to support previously undefined and non-implemented business method functions, the developer workload to create such new functions is greatly reduced in the ICE architecture because of its natural immunity to ripple effect. A new business method has zero impact on all existing business or future new business methods, and any additions to the database have zero impact on all existing or future new business methods..

• Even in the rare instance of a change to the database, automated data type declaration and synchronization in the ICE development environment allows the rapid, comprehensive and automated update of all the business methods in the system. This is an extremely powerful feature, and a necessary one because in order to be intrinsically workflow- enabled, all ICE applications must conform to the same data integrity and consistency mles.

• In practice much of the work of creating workflows in standard workflow environments consists of analyzing and controlling ripple effect, achieving project scope control, and conditioning the existing applications to work in the workflows that the designer wishes to implement. The ICE system eliminates these traditional bottlenecks to workflow development.

The foregoing discussion has focussed on the background, rationale and benefits of Dynamic Workflow. The following discussion will focus on keys to Dynamic Workflow in the ICE sytem.

• Eliminate the need to pass physical transactions or parameters between applications

An important purpose is served by eliminating the requirement to pass physical transactions or parameters between applications. Much of the conditioning and preparation of conventional workflow systems involves detailed data type checking and transaction matching from a source object to a target object. This is true whether the source object is a "pure" object or a hybrid object consisting of a more conventional database table and conesponding application.

If all the applications in an application system are actually methods that act on a unified "solid-state" database, and if all data type checking is done centrally, then one major source of potential application incompatibility is eliminated. This is exactly what is done in the ICE system. The ICE sytem is developed using a RAD environment (e.g., 4D from ACI, Inc.) that is capable of performing automated, centralized data type checking and declaration.

In fact, in the ICE system, data or parameters cannot be passed to any ICE application because once any data in the ICE system are updated, they are already in any and every method or view in the system. While this architecture could conceivably create currency problems and scalability limits in very large implementations, presently, no single ICE instance is designed to support more than a hundred or so users. Thus, ICE can operate on a "solid-state" instance of persistent data.

In this environment, data integrity mles are enforced by conventional RDBMS mechanisms. In fact, the ICE data model can be deployed as an Oracle database for example. Data consistency cannot be violated either because of all ICE applications share identical data consistency mles. Business mles are guided (not enforced) by a combination of application logic and workflow.

ICE can be and is coded to enforce certain business mles without exception. These would include things like double entry bookkeeping transactions. In all other cases however, the user with a high enough level of authority can invoke applications in what ever order suits the business case.

• ICE applications are coded to "open navigation Web" standards.

Every ICE application is written as if it could be invoked by any other application in the ICE system, and contains the navigation infrastructure and user enabling to support the invocation of any other application in the ICE system. With very rare exceptions, which are only made to conform to certain accounting or business restrictions, this is the actual case.

For the purpose of facilitating the execution of routine business processes, task-based, conventional workflow, and automated procedures or agents can be used. The big difference comes in when it becomes necessary to override an established procedure, or possibly even create, on-the-fly as it were, new procedures or exception-handling workflows.

One metaphor that describes the ICE system workflow in contrast to conventional workflow is that conventional workflow presents the implementation staff with a blank slate on which all workflow constructs must be implemented before they can be used. The ICE system presents the users with an open white board of potential navigation paths that are typically defined by navigation guidelines.

Regardless of which ICE application a user happens to be in, a direct navigation path exists to any other ICE application. When the user gets there, the user can almost always perform meaningful create, read, update, or delete operations on the data that they see through the new "window" that they have chosen.

Furthermore, each ICE application is written at a much broader level of granularity than the typical application in a conventional system. Each view in the ICE system encompasses what would normally be two or three levels of drill down in a conventional system.

Even the "fast path" user in a conventional system typically cannot make any changes to the data that they access through the manually invoked applications, without potentially violating one or more business mles. In any case, the user of a conventional system is looking at data that were designed to be stored either as unit records or as the rows of data in a relational database designed to be displayed on one 80 column by 24 line screen.

This is true even in systems that have been retrofitted with modem graphi- cal user interfaces. In such systems, the graphical user interface is an aesthetically pleasing overlay on top of applications and data definitions that were designed to completely different standards.

The following table first lists in bold some of the primary architectural characteristics that distinguish the ICE system from conventional workflow systems. The rest of the table lists some of the consequences and spinoffs ofthis architecture.

Referring to Figure 163, present enterprise application software may be categorized according to function and company size. Presently, different functions are performed by different software packages, including such functions as e-commerce, supply chain management (SCM), enterprise resource planning (ERP), sales force automation (SFA), purchasing automation (PAS), customer service automation (CSA), marketing automation (MAS), customer relationship management (CRM), vendor relationship management (VRM), etc. Company size ranges from Fortune 1000 companies using information technologies base predominantly on Unix platforms, large companies using PCs, Unix machines or a combination of both, medium-size, PC-based businesses and small home businesses, also PC- based. The present enterprise application software is PC-based and is especially targeted toward medium and large businesses (i.e., businesses currently using PC technology), but is adaptable to any size business. A service-bureau model may be used to provide business processing services to businesses otherwise unable to afford or support an in-house system. Unlike existing single-function enterprise application software packages, the present application software extends across a broad range of functions, including e-commerce, SCM, ERP, SFA, PAS, and CMA and may be readily extended to MAS and other functions, as it is highly flexible.

In a preferred embodiment, the present end-to-end, business-to-business, web-based electronic commerce system is composed of one or more unitary, "solid-state" database applications based on a web-enabled relational database management system (RDBMS), each running on a separate server platform. The database application is unitary in that the database is organized around a central table, an item table containing item records which serve as the basic building block of the system. Each item record contains business domain-specific fields pertaining to some and preferably all relevant business domains, e.g., products, payments, performance, personnel, etc. The database application software reads item records, organizes selected relevant information from the item records, and presents the selected relevant information as domain-specific, work-relevant displays. Since the item record is the building block of the database application, system functionality can be readily expanded as necessary by adding fields to the item record. For example, an "XYZ" domain may be added to the database by adding fields X, Y and Z to the item record. The basic structure of the database does not change, only the way data is arranged and viewed. The design is therefore very flexible and accommodates changes very easily, including the addition of new domains are required.

Once item information has been input and committed, it is immediately available for viewing by a multiplicity of information workers, different information workers having responsibility for different ones of the business domains and are presented with different screen displays of relevant information to do their work. Information stored within a field of an item record is the only instance of that information within the entire database. As a result, data is "touched" only once, maximizing data integrity, and data is always "in sync," defining characteristics of a solid-state database. Because of the solid-state nature of the database, the present system avoids problems of data integrity and synchronization common in large, modular enterprise software systems in which there occurs substantial duplication of data, necessitating data propagation.

Each copy of the database application is "self-sufficient" in that there are stored within the database, in accordance with a single database schema, all current records required to perform a full spectrum of existing known business functions throughout the life cycle of product items, where product items may be goods or services. Such extreme integration is made possible by limiting the number of business partners for which current records are stored within the database. Scalability is achieved by adding additional copies of the database application or commerce engine (scalability through "cloning"), each running on its own server platform. One or more additional servers may be used to direct requests to the appropriate server and to consolidate corresponding relevant information from the various servers, enabling multiple smaller solid-state databases to create the appearance and functionality of a single larger solid-state database. An example of a suitable web-enabled RDBMS is the Fourth Dimension database by ACI US Corporation using the 4-D Open API plug-in.

Referring now to Figure 164, there is shown a block diagram of a continuous end-to-end, business-to-business, web-based electronic commerce system in accordance with an exemplary embodiment of the invention. Maximum advantage is taken of the integration of the solid-state database and the integration made possible by the web in order to tie together a far-flung network of partners, all of which enjoy immediacy of relevant information and the activities of which can be seamlessly coordinated to realize an end-to-end business process. In an exemplary embodiment, these partners include distributors, manufacturers, system integrators and service providers. The basic business model involves users, manufacturers, suppliers and service organizations.

Buyers and users access the system, shown in bold outline, via the web. The web-based technology block of the RDBMS makes possible access to all of the data within the database via the web. Business users may include corporations, SMBs (small and medium-size businesses), buying groups, etc. Access to the system may be direct or through various alliances, e.g., with portals, Internet Service Providers (ISPs), complementary web sites, etc.

The system is illustrated in simplified manner so as to draw attention to certain principal functions, namely purchasing, tracking, billing, supply chain management, system integration and post-sale services (including returns). Information to carry out these various functions flows via the web.

At the outset of a transaction, information flow is via a purchasing path, shown in bold. Demand information is received from web buyers and users and acted upon by a purchasing function. The purchasing function is followed by an SCM (Supply Chain Management) function in which relevant, filtered demand information is broadcast to different tier distributors and/or manufacturers. In the case of a computer, for example, demand information might be broadcast to, on the manufacturer side, a computer maker, a disk drive maker, a power supply maker, a mother board maker, various chip makers, etc., for synchronized effort by multiple tiers of suppliers to satisfy a single demand in which tier suppliers provide components to a manufacturer or distributor. Goods are shipped delivered from the dis- tributor or manufacturer to the web buyers and users (or in the case of services, services are provided).

A multi-tier distribution model may be followed to achieve "just-in-time" distribution, akin to just-in-time manufacturing. Items are "stratified" in tiers according to sales volume and consequent inventory turns. Items that experience many inventory turns are distributed by specialized secondary tier distributor. Items that experience fewer turns and hence do not attract specialized secondary tier distributors are aggregated and handled by a generalized primary tier distributor.

Activities within the purchasing function trigger billing activities. Tracking information is made available to web buyers and users throughout the business process. Note that the system can be tied to other specialty web sites that safeguard credit card or EFT activities via the web.

Web buyers and users may purchase equipment that requires system integration. Appropriate instructions may be captured, again via the web, distilled or percolated, and delivered via the web to a national system integrator (or to one of many regional system integrators). The system integrator then provides system integration services to the user.

An important advantage of the present system is the automation of post- sale services (returns, exchanges, claims, repair, parts order, etc.) with real-time, percolated relevant information flow via the web. When a user requests service, the user first identifies within the database a product record corresponding to the product for which service is being requested. Throughout the life cycle of a product, service requests in relation to that product are received via the web and matched to the corresponding product record stored in the database. For some (or all) of the service requests (especially service requests requiring field service), service request information, together with service and purchase history, may be transmitted real-time to a national service provider (or to one of many regional service providers). The service provider provides the requested service to the user, reducing unproductive human interactions (telephone tag, visits, etc.).

A more detailed block diagram of the system of Figure 164 is shown in Figure 165. Referring now to Figure 165, the appearance of a single larger solid- state database is created using multiple smaller solid-state databases, i.e., multiple copies of the database application, each running on its own server platform. One additional server acting as a "traffic director" and load balancer is used to direct requests to the appropriate server and a further additional server is used to consolidate corresponding relevant information from the various servers, creating the appearance and functionality of a single larger solid-state database. Increases in demand may be met by simply adding additional copies of the database application, each running on its own server platform. Because each copy of the database application is self-sufficient and implements a full complement of end-to-end business functions, there is no need for the different copies of the database application to intercommunicate (i.e., be mirrored), since each serve a separate and distinct demand-side or supply-side business partner that bears no demand relation to other business partners. As a result the latency problem characteristic of the prior art is solved, with "infrastructure on demand" being provided simply and cleanly. As demand approaches the capacity of a single unit, an additional unit is added. In conventional systems, by contrast, because of the lack of a solution that provides infrastructure on demand, the user is required to anticipate eventual demand and build commensurate infrastructure from the outset to avoid painful and costly expansion/conversion (e.g., from PCs to Unix), and adding one additional user is just as laborious (from the standpoint of Information Systems structure) as adding 1000 users.

That is, whereas conventional "big iron" architectures emphasize system scalability and centralized, enterprise-wide data access, the present infrastructure on demand architecture emphasizes business scalability and the ability to access relevant information on an as-needed (on-demand) basis. To use a metaphor, the two different approaches may be contrasted as the conventional "information reservoir" approach versus the present "information water cooler" approach. Conventional architectures focus on building a huge tank, as large as any foreseeable or forecast need. The expense entailed is viewed as unavoidable, the price of entry into "the big leagues." Whereas the data is all together, user interaction is compartmentalized by function, e.g., accounting, HR, sales, etc., such that the overall business process is segmented and discontinuous. In the present architecture, rather, the business (customer base) is compartmentalized along natural lines, but user interaction is wide-ranging, part of a smooth, continuous process. This business compartmentalization/functional continuity is analogous to using a multitude of small, inexpensive water coolers (PCs) linked by a pipe (local network or Internet). Just as a person can only drink one cup of water at a time, a computer user can only reasonably view and process one screen of relevant information at a time. So long as the PC that stores a desired item of relevant information can be readily identified, the user's need for relevant information can be satisfied. Hence, instead of focusing in the abstract on the need for data access, the present architecture focuses on satisfying the user's need for relevant information. In other words, the limiting factor in a business-to-business solution is not data but rather the ability of the user to process information. As described hereinafter, the ability is provided to consolidate relevant information from independent servers according to requirements, e.g., for purposes of G/L, purchasing (PSRI), etc., for purposes of reporting the over-all performance of a business enterprise.

Figure 165 shows in some detail the structure and function of a single "on demand" solid-state database application unit. In Figure 165, the single-letter abbreviations C, V, I, SP and GOV. are used for Customer, Vendor, Internal User, Service Provider and Government, respectively. Interaction with the system is typically interactive, via the web, but may also be through the exchange of data files, such as ASCII files, as indicated in dashed lines in various places within Figure 165.

Depending on the nature of the underlying business, the database may store an electronic catalog, created and maintained, preferably, by accessing vendor information via the web. Further details concerning the electronic catalog in accordance with an exemplary embodiment of the invention are presented hereinafter. The electronic catalog preferably includes both "systems" and components, as in the case of computer reseller, for example. An electronic catalog may also include service items, explicitly quantified as line items in like manner as product items. The user can then search for service items just like product items instead of using keyword searching. In other businesses, an electronic catalog may not be required.

A transaction commences by receiving from a user (C, V, I, SP, GOV., etc.) demand/offer information. In the case of a customer, for example, the demand information may be for one or more products selected from an electronic catalog. Or, the demand information may be from an internal user within a virtual organization for one or more products for purposes of inventory or internal use. In the case of a vendor or service provider, the information may be offer information, e.g., an offer to provide a specified service for a specified price. Hence, two types of demand may be distinguished, demands upon the business and demands by the business, the latter being satisfied by way of offers from vendors or service providers. Demands upon the business may include demands by governmental or other bodies, for example a demand for tax payment. The generality of the constructs and mechanisms of the database application allows for virtually any type of demand to be handled in like manner using a single common record, or document. For example, vendor demand may represent a contract payment for services. Internal demand may represent a budget listing items and budgeted dollar amounts.

Receipt of demand information in relation to an item results in the creation of an item record if the item is from a new demand. As previously described, the item record is the building block of the database application. In general, system functionality is expanded as necessary by adding fields to the item record. Per-item (Items Sold) and per-count (Item Detail) records are created and maintained. A one-to-many relationship therefore exists between an Items Sold record and Item Detail records. An item record includes fields pertaining to some or all of the following business domains: products, payments, performance and personnel. That is, the cross-domain nature of the database application is reflected in the fundamental record, the item record.

If an item is new, a quote record is created that refers to the item record. A quote may be regarded as a "demand preparation" record, or document. A quote may be used for various purposes, including budget purposes, convenience in produces other quotes, etc. New quotes may be derived from existing quotes. An existing quote may be a list of favorite items, for example, or a wish list. The different purposes of different quotes may be furthered by "tagging" different types of quotes with identifying tags. Whereas a typical quote will be converted into a purchase order, represented by a Master Worksheet (MWS), some quotes may never be converted. Quotes may be named by the user in accordance with whatever scheme the user wishes. Quotes can be a subset or detail of another item on a different quote.

Hence, unforeseen demand creates a new MWS and its relationship with other MWSs. Different demands creates different types of quotes and MWSs. Items, quotes and MWSs may be manipulated by the application of classification, relationships, hierarchy, experiential constraints, marking, tracking, etc. Such manipulation gives rise to an infinitude of type of demand. Such manipulation also allows for compression of the solid-state database, since the underlying mechanism and record structure is "one size fits all" and never changes.

As previously stated, quotes represent demand preparation. Demand preparation may, of course, be affected by changes in supply information. Hence, if the database include an electronic catalog, as the electronic catalog is updated, if supply information has changed, appropriate alerts may be posted, allowing the user to perform their own updates and changes on the web as desired.

If the received demand information relates to an existing item (i.e., if the item is old), then a post-sale service record is created. Within the database, the post-sale service record is related to the MWSs to which the item belongs. Post- sale service records enable customer service to be quantified and verified, resulting in quantitative customer service, above and beyond conventional notions of qualitative customer service. For convenience, a post-sale service record is referred to as an RMA (Return Merchandise Authorization) record. However, as in the case of quotes, an RMA may be used for various purposes (e.g., returns, exchanges, claims, repair, parts order, etc.), with different types of RMAs being distinguished using appropriate tags. An RMA may trigger multiple actions for the same items. For example, a "lost shipment" RMA creates claims for insurance (e.g., UPS and commercial), credits the user, enables the vendor invoice to be processed correctly, etc.

A user completes demand preparation and finalizes demand by "submitting" a quote. The quote may have just been created during a present user session (either "from scratch" or from another quote) or may have been created during a previous session and retrieved. Submitting a quote causes it to be converted to a purchase order, represented by a Master Worksheet (MWS). A purchasing function and related functions within the products domain are based on MWSs. As with quotes and RMAs, new MWSs may be derived from existing MWSs, or items within a MWS can be related to other items within the same or different MWS. These relationships form the basis of Supply Chain Management (SCM). Suppliers within a supply chain occupy different tiers, e.g., tier 1, tier 2, tier 3, etc. The difficulty in conventional systems arises at least in large part from the fact that information is propagated serially, from tier 1 down to tier n, with attendant delays and lack of synchronization. Because of lack of synchronization, current supply-chain operations are largely forecast-based, not instantaneous demand-based. Substantial resources are expended on producing forecasts and improving forecasting techniques. The present system enables supply-chain operations to be instantaneous demand-based. Percolated relevant demand information is broadcast simultaneously throughout the supply chain. The broadcast of real-time demand information enables real-time response.

Because MWSs are in essence "views" of underlying item records, demand information may be massaged and manipulated ("percolated") in any desired fashion, while retaining the identity of the original demand information, by setting appropriate fields within the item record. For example, at any given time, MWSs for which the purchasing function is to be performed may include many different MWSs all including the identical item. A purchase order may be created containing all of the identical items. These items would all have different customer-specific identifiers, distinguishing them as pertaining to multiple original demands, but have the same vendor-specific identifier, linking them together as part of a derivative "super demand." In this manner, information from multiple MWSs may be consolidated to form a single derivative purchase order. To take the opposite example, a business may engage in channel assembly. An order for a computer system (a single item constituting the original demand) may result in the creating of multiple derivative items (case, power supply, mother board, disk drive, etc.). The derivative items would all have the same "tier 1" identifier, linking them together as part of the original demand, but have different "tier 2" identifiers, distinguishing them as separate items to be order from different suppliers. In this manner, a single MWS may be "broken out" into multiple MWSs for multiple sub- tier suppliers with relevant items to relevant suppliers.

A MWS can function as an inventory checklist. An item being processed for order fulfillment is compared to inventory items on the MWS. Item detail records corresponding to a line item are marked as available or allocated. If the item is found on the MWS and a corresponding item detail is available, it is marked as allocated. When the quantity available for a particular item falls to zero or below a prescribed level (i.e., all items are marked "used"), a new MWS may be created for the purpose of replenishing inventory. Such inventory processing is one example of a relationship between an item and a MWS, and a relationship between one MWS and another MWS. That is, inventory is reduced to a status, or a set of properties, of an item, e.g, allocated, order, bought, used, return, re-allocated, special allocation, other custom specific allocation, etc. The same principle is applicable to a wide variety of business processes that heretofore have been separately automated.

Because the item records that underlie the quote, MWS and RMA records are "cross-domain," the quote, MWS and RMA records are also cross-domain. These records are therefore used to perform business processes in multiple domains, including, for example, the products domain, the payments domain, the performance domain, and the partners domain. The products domain may include such functions as purchasing, shipping, receiving and installation (PSRI). The payments domain may include such functions as A/R and A/P. The performance domain may include such functions as General Ledger (GL) and financial reporting. The partners domain may include human resource functions, goal and task management, employee evaluation, customer/vendor evaluation, etc. Because of the solid-state nature of the database, all of the functions within all of the domains can be performed in real time. Traditional batch processing, which permeates conventional systems, disappears.

Furthermore, because the RDBMS is web-enabled, as much of the information stored within the database as business management desires can be shared with partners, again in real time, via the web using pull technology, push technology, or some other distinct or hybrid web delivery technology. Information sharing with vendors assumes particular importance and is therefore illustrated separately. Conclusion of the purchasing function is marked by the exchange of order information with vendors, via the web (push, pull, etc.). Different tiers of vendors are shown, representing the simultaneously broadcast of order information throughout as much (or as little) of the supply chain as desired. Rather than placing an order directly with a vendor, bids may be solicited from multiple vendors, with the order being placed with a particular vendor after evaluation of multiple bids. There results a qualified-party auction system in which both customers and vendors are qualified by the business. Participating customers and vendors can be changed day by day and transaction by transaction at will by the user clicking a button. In other existing web auction systems, because customers and vendors are not qualified (screened), a substantial risk factor is introduced when dealing with unfamiliar parties.

In the referenced applications, automatic RMA approval is described, based on stored criteria. A similar mechanism may be applied to bid awards in order to automatically identify the best acceptable bid and create a corresponding purchase order (PO), squeezing out the delay that occurs in conventional systems. Zero delay is made possible in that bidding and POs are both part of the same continuous business process. Referring to Figure 183, a chart is shown exemplary of a method for evaluating and awarding bids. The column headings represent bid criteria, e.g., all items priced, all items in stock, etc. Other criteria can be added as needed. A first row is used to turn the criteria on or off for a particular bid. For one bid event, all of the criteria may be turned on. For another bid event, one or more criteria may be turned off. For example, in the case of a particular bid event, ship method may not be a decisive factor. A second row represents status information for each of the bids received during the bid event.

Typically, the bid will be awarded to the lowest bidder, all else being equal. The lowest bid, however, may be so low as to raise suspicion as to whether the bid is mistaken. Awarding the bid to the lowest bidder in such an instance might engender a dispute. The last two criteria in Figure 183 take this factor into account. If on a percentage basis or amount basis a bid is unreasonably low as compared to the next, the bid may be disqualified.

As may be appreciated from the description thus far, the collection of all relevant transactional information within a single database has profound implications. Just as important as "raw" information, however, is meaningful information access. The present system provides meaningful information access in the form of a user interface that exemplifies "Open Navigation." Open Navigation allows any piece of information the user desires to be accessed with a few clicks, across all domains. User access to information is limited only by authority, not by the underlying technology. Accordingly, a user with unlimited authority, such as the president of the company, can readily access meaningful information about any and all aspects of the business, from anywhere in the world, via the web. Other users can be given more restricted access. Customers, vendors and service providers can be given access to relevant orders, invoices, etc. Governmental and other bodies can be given access to relevant information. For example, the IRS or other tax authority could be given access to all records required to conduct a full audit, via the web.

Meaningful access to information is furthered by a "related switch" feature. To use the related switch feature, a user selects one or more records within a current display and then selects a "switch-to" table of records the record of which contains the particular information that the user wishes to view. The system then identifies records of the switch-to table related to the records initially selected and displays the identified records. For example, a user may relate-switch from a sales record to a related RMA record to a related credit record for purposes of re-invoicing.

The extraordinary information access afforded by the present system makes possible and practical widespread telecommuting and, by extension, the truly virtual enterprise. "Internal Users" may be either local or remote and enjoy the full capabilities and benefits of Open Navigation, including "at-a-glance" workscope/workflow, business-function-specific screens, described hereinafter. Given these tools, an information worker may readily perform his or her job from anywhere in the world. Operations within the performance domain ensure realtime accountability.

More particularly, open navigation breaks down department barriers and creates cyber departments. With open navigation, employees are no longer bound by physical location or department. Cooperation between users, such as joint creations of quotes, is easily achieved, with the result that numerous meetings required in the case of physical departments are no longer needed. Quantitative, data-based interaction complements existing qualitative interaction. There results a truly virtual corporation.

Other features of the system automate, to a great extent, routine business functions, ensure data integrity, and capture the knowledge of information workers so as to mitigate the impact of employee turnover. Referring still to Figure 165, a computer-assisted methodology is provided for accomplishing routine business functions, characterized by classifying records in accordance with a hierarchy of classifications. The information worker then takes action with respect to a group of records having a common classification. The records are then reclassified, and the process repeats. This methodology, referred to generally as "percolation" and described in greater detail hereinafter, may be used applied to varied business functions, e.g., purchasing, A/P, A/R, etc.

The cross-domain nature of the database facilitates thorough consistency checking of the database. A battery of cross-domain consistency checks is performed continuously or at intervals (e.g., during periods of low system load). Inconsistencies are reported, e.g.via email, to responsible personnel. This feature, in combination with the fact that data is only touched once, results in a very high level of data integrity. New checks can be added as requirements arise.

The system enforces a discipline on users in which users must use the system to accomplish their jobs. With few exceptions (e.g, the entry of amounts), the system is menu driven. Whenever possibilities are known or can be anticipated, menu choices are presented to the user. In some instances, manual entry is required where the data to be entered is beyond the control of the system, for example vendor invoice number and amount. In these instances, manual entry is permitted but with checks for duplicate entries. In addition to periodic consistency checks, data entries are qualified at the time of entry to ensure consistency and prevent errors. Data entry is therefore tightly controlled, as compared to data viewing which is liberally allowed. Because of the rich and varied nature of business practised in such a manner that the "customer is king," unforeseen circumstances arise in which the information worker is "stuck"— unable, given the options currently provided for in the system, to do his or her job. (Because of the "at-a-glance" workscope/workflow nature of the screen displays of the database application, the information worker will in all likelihood truly be stuck, not just lost as is often the case in conventional systems.) When such an instance occurs, the only way to continue the forward progress of the information worker's work is to make an addition to the database application program to handle the unanticipated event. Such additions may take the form of the user adding a searchable and classifiable text entry that accounts for the unanticipated event, or may require the intervention of a programmer to make code additions or code changes to the system. (Programming changes may be distributed via the web using a continuous releases strategy described hereafter.) The item-centric architecture of the database application program allows such changes to be made quickly and easily, in contrast to conventional systems. As a result of such program changes, both those made by the users themselves and those made by programmers, the intelligence of the system continually increases as the relevant knowledge and experience of information workers is captured. Hence, when a worker departs, his relevant domain-specific knowledge is retained. Knowledge retention is focused, quantitative and process/domain-specific. For example, as a person doing vendor payment gains knowledge and improves, the vendor payment process intelligence of the system is improved. Likewise, as a person doing RMAs gains knowledge and improves, the RMA process intelligence of the system is improved. Knowledge is embedded, obviating the need to familiarize and train other workers concerning improvements as they are adopted and implemented. Systemic learning— without training— results. Knowledge retention is trackable, e.g., by creating a log of program changes, both those made by the users themselves and those made by programmers.

Another representation of the present system is shown in Figure 166, including Figure 166 A, Figure 166B and Figure 166C. Referring first to Figure 166B, the present automated business process may be imagined as a kind of information assembly line. A first system user, or "information worker," having for example a Sales assignment or activity focus, initiates an automated, end-to-end business process by entering information into a client/server single relational database, which forms a common hub of the automated business process. In particular, Item Sold and Item Detail records of the database constitute central tables about which substantially all activity revolves. The item is the "atomic unit" that forms the basis of a substantial portion of all of the other records within the database.

As a user makes an entry, the user's entry is qualified, or "quality checked," as represented by a checkvalve. Such qualification is "experiential," i.e., derived from actual business experience, and differs qualitatively from the type of data validation typically performed in database systems. If the user's entry fails scrutiny by the system, it cannot be committed to the database. Similarly, the business process cannot continue to the next user. As a result in part of such experiential qualification, verifiable and usable management and enterprise information may be made readily available. Such a discipline at the outset may be very hard but becomes increasingly easy as experience is gained and knowledge becomes embedded in the system.

More particularly, the evolution of the system is guided by three salient principles: first, everything is viewed as a manifestation of demand or supply; second, the user interface is arranged so that the system cannot be bypassed; third, new domains and new processes are added "from the roots" by examining and modifying as necessary the structure of based records, i.e., Items Sold/Item Detail records. At the outset, the system is in its "infancy." It may incorporate the static, abstract knowledge of conventional business systems but nothing more. By strictly adhering to the foregoing process, the embedded experiential intelligence of the system gradually increases as structure and process are added. As the system matures, a transitional phase is encountered in which the nascent capabilities of the system become more apparent. At full maturity, the power of the system and its ability to handle with relative ease what would otherwise be complicated problems is fully evident. It will be appreciated that such a system cannot be invented in the abstract, separate and apart from daily application.

In the present system, navigation of the workflow is solely determined by the access authority of the user. Workflow components are all pre-existing and pre-programmed. User inputs to the system, however, do undergo a qualification process. Qualification of user inputs has multiple facets. First, each user is accorded limited access privileges. An authority check is therefore performed to ensure that the user is authorized to make the entry being attempted. Second, the entry is checked in accordance with business rules that embody best practice as determined from an analysis of expected parameters and how various values of those parameters affect possible outcomes downstream. Thirdly, entries, even after then are committed to the database, are subjected to intelligent consistency checks in order to detect discrepancies and provide feedback to allow for correction. If input qualification is successful, then succeeding events in the sequential business process are triggered.

Each worker in turn builds upon the information base established by preceding workers, and each workers entries are rigorously qualified. For example, following sales, process flow may continue to Demand Support, Accounting, Purchasing, Receiving, Assembly, and Shipping.

During the process external influences occur. An external influence (change in demand or supply) may be a communication from a customer or vendor, for example, to either convey information or to view information stored in the central database. An example of an external influence might be a vendor special rebate. Information may be conveyed by electronic means (e.g., Internet, intranet, EDI, satellite, remote terminal direct-dial), human-mediated telecommunications (e.g., email, phone, fax), or by physical means (letter, visit, etc.).

As compared with the conventional business process, the circular automated business process of Figure 166B revolves around a single integrated database that accumulates information regarding every important activity of every user and defines a non-repetitive process. Furthermore, as compared to the conventional business process which is essentially non-reversible, the process of Figure 166 is reversible. As seen in Figure 166B, following Shipping is a Post Sales/RMA (Return Merchandise Authorization) activity, or, more generally, a reversal activity. This activity enables the forward process to be reversed, or backed out of step- by-step, as part of the overall automated business process.

Following Post Sales/RMA are an Employee/Vendor Performance activity and a Customer Satisfaction activity. New activities, or new business domains, can be easily added by adding to the item record as previously described.

The cumulative nature of the database of Figure 166B and the sequential nature of the business process enables incisive factual analysis in the areas of employee/vendor performance and customer satisfaction, promoting fairness and personal responsibility. Whereas a human supervisor may effectively supervise only a limited number of employees, the database-implemented business methodology of Figure 166B provides for each employee what may be regarded as a "virtual mentor:" the user is guided during use of the system to prevent common mistakes (in fact, all mistakes made collectively by the all of the user's predecessors functioning in the same assignment), and the user's performance is continuously tracked and made accessible. Strengths and weaknesses in the employees performance may recommend certain changes in assignments — which changes may be made relatively easily by the employee because of the intuitiveness and intelligence of the system. An important aspect of virtual mentoring is an "open- book" information access policy: users, although they may limited access to input information, typically have few if any limits on access to information. The virtual mentoring process promises to make the virtual office and telecommuting, with all its attendant advantages, a practical reality for a much wider segment of the workforce.

Referring still to Figure 166B, Internet transactions are represented within the system using universal demand documents, i.e., the MWS (Quote, PO, etc.) document. In an exemplary embodiment, MWSs are used to represent the following types of transactions:

Table 2

Universal Demand Documents

Goods for customers

Services

Inventory

Supplies

Budgets

Internal use (capital)

External use (expense)

Vendor contracts

Partner agreement

Others on demand

Similarly, the mechanism for Internet fulfillment takes the form of a universal supply document. In an exemplary embodiment, universal supply documents are used for Internet fulfillment in the following types of transactions:

Table 3

Universal Supply Documents

Bids/Quotes

Life cycle tracking

Confirmation

Warranty service

Post sales support

Returns

Others on demand Because the database is web-enabled, and because the database is self-contained and self-sufficient, a wide variety reporting functions and tracking, status- ing and other business process functions involving a wide variety of parties can be easily realized by granting appropriate access to information. Examples of such functions (Figure 166A and Figure 166C) are summarized below:

Table 4 : Reporting

KJ

Table 5 : Business Process

Table 5 : Business Process

Hence, Figure 166 represents a basic, universal business process. The basic flow is one of matching supply and demand in such a way as to make a profit: obtain demand, convert it to a form suppliers can understand, the suppliers acting upon the demand information, and settling payments. Mechanisms are built in for buying, ordering, receiving, making, shipping, handling credits, returns, inventory, etc. Figure 166B illustrates the matching of supply and demand, Figure 166C illustrates mechanisms (i.e., a "pipeline") for fulfilling demand, and Figure 166A illustrates third-party interactions, separate from any specific demand.

Rapid deployment of a virtual enterprise is made possible by, when a new unforeseen requirement is encountered, fitting it to the same basic process flow, the same demand/supply pipeline, instead of developing a new custom solution. The "one-size-fits-all" nature of the system is illustrated in its application to three specific, disparate industries, computers (Figure 164, described previously), agriculture (Figure 180, described hereafter), and convenience stores (Figure 181, described hereafter).

The ability to interface electronically through the web to regulatory agencies (Figure 166 A) is particularly advantageous. In the case of a reseller, for example, sales tax reporting is often a major manpower consumer. Automated preparation of a sales tax return has been described in the referenced applications. Instead of filing a paper return that has been electronically prepared, however, the return can be filed electronically via the web. Furthermore, the return can be audited, if required, via the web. To perform such an audit, a telephone conference is arranged with the auditing authority, who is provided with access to the database through the web. Using the database, every transaction and supporting documentation can be readily traced and verified.

As will be appreciated hereinafter, by viewing virtually every aspect of a business as a facet of supply or demand, and by using a common demand document to represent demand and a common supply document to represent supply, a remarkable simplification and unification of business processes results. Engineers, including software engineers, because they are able to deal with complexity quite readily and take some justifiable pride in doing so, in many instances have a natural tendency toward complexity. Witness the often mind-boggling complexity of much of today's enterprise software. The owner of a small or medium size business, on the other hand, regardless of whether he or she is able to deal with complexity, cannot afford to deal with complexity. Here, the adage "Keep It Simple, Silly" becomes an imperative, as it will in time for large businesses also.

In the case of the present system, complexity is avoided and simplicity promoted as follows. A fundamental axiom on which the presents system is based is that supply and demand must be matched. If supply outstrips demand, then the result is idle inventory, i.e., cash tied up in unproductive assets. If demand outstrips supply, then the result is a lost money-making opportunity, i.e., lost business. In essence, at every turn, business process "engineering" (simplification) occurs by asking the fundamental question, "Is this supply or demand?" If demand, it is represented using the common demand document. If supply, it is represented using common supply document. Supply and demand documents must be matched; otherwise, either demand will go unfulfilled or supply will go unverified. In instances where supply or demand documents would otherwise not be matched, matching documents are created internally, or a classification is applied to allow for payment absent a supply document. For example, in the case of tax payments, the typical purchase order/invoice situation does not exist. (That is, the government does not send a purchase order for taxes and does not send an invoice upon payment.) However, quarterly tax payments fit the classification of demand, a demand for payment. Timely payment can be assured by creating a tax payment MWS with individual items corresponding to the required payments and by scheduling automatic payment. Because no invoice is expected, an invoice is internally created, allowing the process to logically flow through to completion. During auto- matic A/P processing, payment will therefore be scheduled to a payment register even though no matching external invoice has been received. The payment is scheduled to the next payment register created following the recorded payment date. Hence, for a payment due on the first of the month, for example, the recorded payment date might be the 25th of the previous month. Even though payment is scheduled to a payment register, the user retains discretion whether or not to pay. If payment is not made, the payment is added to the next payment register. The computer does not automatically spit out a check without the exercise of any intelligence, as in some systems that provide for automatic payment. The intelligence of the present system also prevent inadvertent double payment, e.g., automatic payment and duplicate manual payment. Each scheduled payment corresponds to an item that, when the payment is made, is marked paid. Once paid, the system will not allow the same payment to be made again.

Numerous other examples of such business process streamlining in which the same business processing engine is applied to disparate business situations are described hereinafter.

Having described the present system generally, various features of the system will be described in greater detail.

Inter and Intra Table Record Relationships— Richness of Possibilities

The resulting richness of possibilities is exemplified in Figure 167. Referring to Figure 167, demand information of various different types is received from various different parties, resulting in the creation of Quotes during a demand preparation phase. Despite the disparateness of the various demands, the flexibility of the Quote/MWS record enables a common document and mechanism to be used.

In the example of Figure 167, a common demand document (Quote/MWS) is used to receive demand information from various parties including partners, customers, and internal users, as well as demand information for purposes of inven- tory and for puφoses of making fixed payments (i.e., where the demand arises out of contract or obligations).

Normally, a Quote is converted to a MWS to initiate demand fulfillment. In the case of budgets, however, since budgets are often partner/vendor-specific, a budget is created as a "dummy" purchase order. An initial budget amount is entered before any expenditure is actually approved. As expenditures are approved, a "committed" amount is increased by the amount of the approved expenditure. A corresponding MWS is then created. Purchasing functions— PSRI— may be performed based on the MWSs. Non-purchasing functions are also performed based on the MWSs, e.g., tax payment, preparation of financial statements, etc.

Following purchasing, when a vendor invoices are received, they are processed using a vendor invoice percolation process, and using information from the MWSs and from PSRI, to determine when a particular vendor invoice is ready for payment.

Multi- vendor budgets allow for budget tracking and enforcement with respect to a category of related expenditures where the vendors to be used are undetermined until the time of purchase. A non-specific, or universal, partner is created for this puφose. Again, a budget is created by creating a dummy PO. When funds are committed, a MWS is created. As purchases are made, actual POs are created from the MWS on an item-by-item basis. In the case of office supplies, for example, one item might be paper and another item might be coffee. These items may come from the same budget but be ordered from different vendors. The creation of POs by item, together with budget tracking by MWS, allows this flexibility.

Budgets

In present common business practice, budgets and budget enforcement are largely hit and miss. The mechanism of a common demand document makes on- demand budget control and automatic invoice payment simple and easy to implement. In particular, budgets become tied into the more rigid discipline of purchase orders and vendor payments. That is, the present system provides real-time budget control and statusing instead of requiring budget reconciliation.

The implementation of budgets provides a concrete example of the extensibility of the present system. In an exemplary embodiment, the implementation of budgets uses existing structures and processes for at least the following: Chart of Accounts (COA), Partners, Customers, MWS, Items Sold, Item Detail, Vendor Invoice, Purchase Order (PO). In this manner, existing mechanism for processing Cost of Goods (COG) items are adapted for processing expense (budget) items. In accordance with this approach, a Customer file may represent a COG customer or an expense "customer," e.g., "Rent Expense."

In the present system, budgeting is done largely by partner or vendor. Because a budget is usually vendor-specific, it is much more concrete (much more real) than the typical departmental budget, which is often more guesswork than anything else. In particular, a Partner file has two principal views, a standard view and an accounting view that takes advantage of the related switch feature. Within the accounting view, a budget page is provided. Within the database structure, a hidden table (a partner-specific "dummy PO") holds budget information.

The budget process may be more clearly understood with reference to Figure 168. As seen therein, budgets may be set based on a variety of information including budget expense history (including overbudget or underbudget amounts by account within a Chart of Accounts, or COA), current partner proposals, and internal estimates. "Partner" is used here broadly to mean someone to whom money is paid. Partners may include vendors, manufacturers, employees, banks, accountants, lawyers, etc. By adopting a broad, inclusive definition of partner, no special treament is required for employees, sales expenses, etc. Current partner proposals (external proposals) are stored in respective budget files. Internal estimates (internal proposals) not specific to any partner are stored in a "TBD" partner file, or "universal partner holding tank." The foregoing information constitutes a baseline reference for arriving at a COA-specific budget. The baseline reference is adjusted experientially to arrive at a budget by COA.

Typically, to prepare a budget, historical amounts spent on each partner and each chart of accounts are reviewed and a determination is made whether to budget roughly the same amount, increase the amount or decrease the amount. A budget line is then assigned for that partner or COA. Once a budget has been set, the various people responsible for expenditures undertake a basic budgeting exercise in which they create budget items by projecting a schedule of payments up to the budget cap. Budget items can be broken down into greater detail (in much the same fashion as Items Sold/Item Detail) and distributed to different CO As.

Budget items are categorized by key. Budget keys are used to link partners, customers and MWSs. When a key is created, the user selects one or more expense partners that belongs to that key, e.g., rent, software development, office supplies. Keys enable related expenditures to be viewed together. By selecting a key from a pop-up menu, all expected payments under that key can be viewed.

Before any expenditure can be made, a corresponding budget item must be approved by a supervisory user such as a department head, CFO, etc. A user selects one or more budget items within a partner file and clicks Submit. The selected budget items are then submitted for approval.

Budget item approval can be performed by partner or by COA. An approval window shows CO As with dollar amounts submitted. Selecting a COA shows partners for which budget items have been submitted. Selecting a partner displays actual payments submitted for approval. Preferably, an "electronic documents book" is also provided for storing online relevant documentation such as contracts, proposals, etc. To approve a budget item, a supervisory user selects spe- cific payments or selects all payments and clicks Approve. The system will not allow budgets items to be approved that would cause the cap for a particular partner to be exceeded. Similarly, a warning is displayed when approval of a budget item would cause a COA cap to be exceeded.

Each budget line item is quantified and represented as an item in much the same fashion as if it were a physical item, except that a budget line item has associated with it an account. Budget line items having the same expected partner are associated together in the form of a partner-specific dummy PO. Budget line items having different expected partners may also associated together in the form of a multi-vendor dummy PO.

Approval makes funds available for commitment, but funds are not yet committed, meaning that an invoice cannot be paid without overriding the system. Commitment controls payment. A budget item is committed by selecting that line and clicking Commit. As a result, an item (Item Sold, used here for budget purposes) is added to a MWS for the appropriate budget key. Budget MWSs are kept by key; e.g., a software design MWS would contain all expected payments for the current budget year as created by users. As with a COG item, once a budget item is present on a MWS, it is available to create a PO. All of the COG infrastructure applicable to items may then be applied and brought to bear on budget items.

A MWS item may be further broken down, by adding under an item items from a quote or from the product file, or by the user inputting relevant item information. A PO may then be created, which readies the system to receive the specified items.

A PO can be set for automatic confirmation, automatic validation, automatic invoicing, and/or automatic payment. Automatic confirmation means that no actual PO will be sent. Automatic confirmation would apply, for example, when making a purchase from a store. Automatic validation marks an item as having been received and means that no work is outstanding, as in the case of rent, for example. Automatic invoicing creates an internal invoice immediately. The invoice then goes through the same payment steps as COG invoices, namely review, pre-approval, approval, and scheduling to a vendor payment register. In the case of automatic payment, review, pre-approval, and approval are set as having been completed. The payment is automatically scheduled to a payment register some number of "buffer payment days" in advance of the payment date (e.g., 5). The number of buffer payment days may be set by partner. In an exemplary embodiment, the Nitely Update (NUD) routine checks unpaid invoices and either schedules payment in an open payment register (non-COG register) or opens a new register. The day following action by NUD will be the first buffer payment day. Hence, in the case of automatic payment, payment is scheduled and automatic, thereby avoiding the possibility of missing a crucial payment and incurring a penalty, as with tax payments, rent, etc.

Budget enforcement is automatic. As illustrated in Figure 168, if an item come in over budget, it cannot be paid through the normal flow of vendor invoice verification. Rather, CFO approval is required to add additional monies to the budget, which will most often come from another budget account that affects the user. To avoid the need for budget realignment, an incentive exists for the user and the partner to cooperate to ensure budget compliance. Budget revisions are tracked within the system for puφoses of employee evaluation. Numerous revisions may be indicative of a problem employee, a problem vendor, lax approval, etc.

Referring still to Figure 168, if an item is within budget, this allows for eventual payment in accordance with an expense item verification process. The purchase cost of an item is recorded in the MWS. When a vendor invoice is received for the item, a vendor invoice record is created. Also, if a vendor credit memo is created for the item, a vendor credit memo is created. A vendor invoice verification process uses these records to reconcile the purchase cost (Pcost) and the actual (invoiced) cost. If Pcost/ Actual cost reconciles, payment of the vendor ^■ invoice is allowed. If not, payment is not allowed.

The foregoing budget process provides a real-time snapshot, enabling management to view by budget key what payments are expected to be made during the current month and for the rest of the budget year.

Budget preparation may be automated in accordance with the following example. Assume that on January 1 the CFO begins budget preparation. Budget preparation begins by displaying within a single screen based historic records a summary of prior-year expenditures based on the principles of classification, filtering, and hierarchy. Referring to Figure 185, a horizontal bar graph is used to indicate sources of operating funds, including, for example, loan commitments, retained earnings, and gross margin revenue. Any combination of these sources may be selected to be including in budget preparation, and a bar graph representing total available operating funds is displayed. In the illustrated example, sources B, C and D are selected, such that the total B + C + D is available for budget purposes. An "Additional Funding" bar represents any additional funding required given the current state of the budget. In a Partners area of the screen display, for each vendor, there is displayed in bar graph form the historical proposed budget and amounts assigned (submitted), approved, and committed on that vendor. The proposed budget may be adjusted by the user for current budget preparation by clicking and dragging as illustrated with respect to Partner A. The bar graphs of the other amounts increase during the budget year as funds are assigned, approved and committed. At any given time, however, the assigned amount cannot exceed the proposed budget, the approved amount cannot exceed the assigned amount, and the committed amount cannot exceed the approved amount.

As a starting point, the CFO clicks Copy (not shown) to copy last years expenditures into this years projected budget. At a click of a button, the budgets for all of the vendors are then automatically updated. In some instances, the CFO will know that the budget for Vendor A, for example, will need to be increased for the coming year, whereas the budget for Vendor B can be decreased. In other instances, a vendor may be discontinued entirely and replaced by an as-yet unknown vendor using the universal vendor as a temporary proxy. As these adjustments are made, the additional funding bar graph shows the net additional cash outlay (or cash savings) as compared to the previous year.

In many instances, the CFO may not have sufficient detail to make an intelligent adjustment. In these instances, a check box is checked to mark the vendor as one for which a confirmed budget is required. Another user then, at the direction of the CFO, searches for those vendors and requests from each vendor a budget proposal. As budget proposals are received, the vendors are marked accordingly and the budget proposals are scanned in. The CFO searches for vendors for which budget proposals have been received and makes budget adjustments accordingly. Some vendor proposals will exceed amounts spent the previous year, while others will fall below. Again, the additional funding bar graph summarizes the budget position as compared to that of the previous year.

After a period of weeks, all of the budget proposals will have been received and processed. Assume that the additional funding bar graph shows an overage of $100,000 as compared to the previous year. Assume further that total expenditures are not to exceed those of the previous year. Then, a filter is used to display those high- volume vendors that account for the "lion's share" of the expenditures. Negotiations are then undertaken with those vendors to trim their respective budgets by a percentage calculated to bring the total budget in line with the previous year's expenditures. As revised budget proposals are received, they are processed and the effect on the need for additional funding is observed. Finally, the additional funding amount is driven to zero. At that point, the budget is approved, and users can commit to specific expenditures.

Alternatively, a company may decide to seek additional financing to finance operations. Instead of budget trimming to drive the additional funding amount to zero, the underlying data may be used to substantiate the need for additional funds as they are sought from any of various funding sources. Just as the referenced applications described system traceability of sales commissions, so also funding requirements are system-traceable, back to specific expected payments to specific vendors.

Assume instead a company just starting operations. Obviously, no historical budget data exists. A projected budget amount is then allocated to the universal vendor. As specific vendors are identified, budget amounts are shifted from the universal vendor to specific vendors.

Automation of the budgeting process provides a critical piece in addressing the problem of asset tracking. Oftentimes an organization will purchase significant amounts of equipment, justifiably, but without any mechanism for tracking where the equipment goes and how it is used. Accountability is lacking.

In the present system, accountability is created by linking the budgeting process and the performance evaluation (human resources, personnel) process. Furthermore, the logistics capabilities of the system (receiving, shipping, returns), routinely used for customer purchases, are applied to internal purchases. There results a life cycle asset tracking capability, from budget to disposal.

Life cycle asset tracking, like other capabilities of the system, are driven by Item and Item Detail records. At the Item Detail level, the Item Detail record records who made the initial budget request for an item, who approved the budget request, who received the item, and to whom the item was "shipped," internally, as well as the dates when these various events took place. During the life cycle of an asset, it may be moved around within the organization. For tracking puφoses, moving an asset is treated as a return, in like manner as a customer return. The item is then "received" and "shipped" to a different location. Reporting capabilities may be used to report, at any time, detailed and meaningful information about assets, including different categories of assets, assets by age, etc. Reliable informa- tion replaces good intentions.

The adaptability of the common demand mechanism to accommodate budgets illustrates how the present system can add new, unforeseeable domains easily. New unforeseen demand or supply can simply be fit into the existing mechanism. This ability allows massive, inexpensive, flexible e-commerce infrastructure across industries.

Linking the budgeting process and the performance evaluation (human resources, personnel) process also enables budgeting functions by cyber-depart- ment, since users are assigned to virtual departments. During budget request approval, for example, a review may be made of expenditures (committed funds year-to-date) within the requestors department, historical expenditures within that department, departmental budget targets, etc. If desired, budget enforcement by department may be made automatic in the same manner that budget enforcement by vendor is automatic. The versatility of the program allows it to accommodate almost any desired system of budget control.

Budget and asset tracking are just examples of the almost unlimited extensibility of the system. Such extensibility is vital in order to accommodate rapidly changing needs of the continuously evolving business. In general, extensibility involves the following process. First, a need is identified that is not currently met by the system. The need is identified as being more closely allied with either supply or demand. The base record structure (i.e., Items Sold) is then examined to determine whether it contains the necessary fields to support the identified need. The base record structure is analogous to the roots of the system. If the necessary fields are not present, they are added to the base record structure in appropriate relation to the existing fields. Code is then added to create the desired functionality to satisfy user demand. The "roots" (base records) give rise to branches (derived records and views) and fruits (processes) in various relationships with one another. For example, from Items Sold are created MWSs, based on relationships. Relation- ships between MWSs give rise to customer-specific catalogs (APL, PID), supply- chain management, etc.

Supply Chain Management

The mechanism of a common demand document makes on-demand Supply Chain Management simple and easy to implement. Referring to Figure 169, two MWSs are shown, one for items A, B and C and another for items X, Y and Z, resulting from respective purchase orders. The purchase orders may derive from specialty Quotes (e.g., PID, APL, etc. as previously described) or may result directly from a customer's interaction with a product file. The purchase orders represent a first level, Level 1 , within a Supply Chain Management hierarchy. The items A, B, C and X, Y, Z may include both stock items and make-to-order items. In the example of Figure 169, item C is assumed to be a make-to-order item. Item C may be composed of items Cl, C2, C3. A Level 2 purchase order is therefore created containing Cl, C2, C3. Item C3 may in turn be composed of items C3x, C3y, C3z. A Level 3 purchase order is therefore created containing C3x, C3y, C3z. (Note that all of the purchase orders corresponding to all of the items are not shown in Figure 169.) Together, a PSRI function and a Supply Chain Management function operate to communicate demand information to suppliers. For stock items, the PSRI function consolidates demand information from multiple parties and communicates the consolidated demand information in the form of a purchase order to a distributor of stock items. The distributor fulfills the demand by shipping the items to customers. For made-to-order items, the Supply Chain Management function "parcels out" appropriate demand information to each of Level 1 (manufacturer), Level 2 and Level 3 suppliers (or any number of levels of suppliers). The Level 3 supplier ships to either the Level 2 supplier or the Level 1 supplier. The Level 2 supplier ships to the Level 1 supplier. The Level 1 supplier manufactures the desired end items and ships to customers, making possible an integrated supply chain directly controlled by real-time demand.

The foregoing model of SCM provides an alternative to the traditional MRP system, by linking all items and retaining each items status relationship to demand users, supply users, etc.

The foregoing "extensibility model" explained in relation to budgets and asset tracking may be seen reflected in SCM. SCM, the functionality to be added, relates closely to demand. SCM is by nature tiered. Prior to SCM, the Item Sold record structure did not have any field indicative of tier. Therefore, a "level" field was added in appropriate relation to other fields. When products are ordered and a corresponding MWS created, the system examines for each product whether the product is designated (e.g., within the product file) for channel assembly. If no product is designated for channel assembly, then the existing MWS will suffice. If a product is designated for channel assembly, then a related Level 2 MWS is created. The Level 2 MWS is populated with component items for the product. The component items may be drawn, for example, from a Quote stored for a "Channel Assembly" customer, the quote name being indicative of the product (e.g., containing the part number of the product). Any number of levels may be supported in the same fashion. In terms of roots, branches and fruits, the Item Sold records represent the roots, MWSs of different levels and Quotes represent the branches, and the relationships between the MWSs and Quotes represent the fruits, which ultimately enable the customer demand to be satisfied.

Virtual, Demand-Driven Infrastructure

Every web business has to start somewhere. Every web business would also like to end up the next Amazon.com. The present invention allows a web business to start with a single PC and scale up incrementally to hundreds or thousands of PCs. Starting with a single PC just sufficient to run the business, if business were to double every quarter (not uncommon in cyberspace), at the end of three years, the business would require upward of two thousand computers. In the last quarter of the three year period, the business would be adding more than 10 PCs per day. However, those PCs might be distributed throughout the world in numerous different locations. The total cost of the PCs, at today's prices, would be in the vicinity of one million dollars total, but the expenditure curve tracks the business growth curve (200,000% growth in three years). Using conventional technology, on the other hand, one million dollars may be considered the minimum "entry fee" and would be insufficient to purchase a system that would accommodate the growth described, which would be impossible to do without a single, huge mainframe-based datacenter.

If one considers that the computing power of PCs doubles about every 18 months, the total number of computers required in the foregoing example would be reduced to about 500. Conceivably, a very large business might have tens of thousands of such computers, upgraded continuously in accordance with an update schedule.

Referring to Figure 170, a block diagram is shown of an Internet-intrinsic, distributed business transaction data cluster. As explained previously, separate instances of the unitary database application software, running on separate PC servers, are provided for different business segments (e.g., different customers, accounts, groups of customers). These PC servers are shown within a server block. Business scalability is achieved by adding additional units. In addition to the server block, there is provided a web block including multiple web client machines (PCs), a Director block including multiple gateway machines (PCs), an Internal User block including multiple office client machines, and a Process block including multiple business process "automatons" (PCs).

A network block provides Internet and intranet connectivity and includes a router, behind the router a firewall, and behind the firewall a switch connected to the web block, the Server block, the Internal User block and the Process block, and to a Local Router. The Local Router is connected to the Director block. The switch allows each PC within each of the web block, Internal User block and Process block to communicate with each PC in the Server block as required. PC servers within the server block are not required to communicate with each other.

In the example of Figure 170, the cluster of PCs is accessed via one incoming IP address. When a request is received, a Consolidated Process Cluster functions as a traffic controller to direct the request through the Local Router to an available gateway. Each of the gateways is identical and performs authentication of the requestor (e.g., by user ID and password) and causes the requestor to be connected to a pre-assigned web client. The web clients preferably are not identical but are customized for each business segment, hence the pre-assignment. The pre- assigned web client in turn accesses the corresponding pending server within the Server block. On the corresponding pending server resides all of the transaction data for that business segment.

Internal users access the servers via the office clients. Each of the office clients may be configured to access all of the servers, a subset of the servers, or a single one of the servers, for example in the case where one or more internal users work exclusively with one business segment.

The automaton machines within the Process block may be regarded as automated office clients. That is, instead of an internal user interacting with an office client to cause a business process to be performed with respect to data of a particular server, an automaton may be programmed to perform the same work automatically. In an exemplary embodiment, such automatons perform PO/MWS Conversion, a PSRI process, a Vendor Product Pricing process, a Customer Pricing Update process, a Vendor Confirmation process, etc.

A consolidated process cluster is coupled to the network block so as to access all of the server machines. The function of the consolidated process cluster is to consolidate like information from a group of server machines or all of the server machines in order to present a picture of the overall enteφrise. In an exemplary embodiment, the consolidated process cluster allows for consolidation of information in relation to some or all of the following business processes: P/O conversion, PSRI, price/product, vendor invoice verification, G/L and accounting, sales tax/recurring process, reports for customers, and reports for partners. The consolidated process cluster may also perform the functions of traffic control and open file sharing.

Referring to Figure 171, a similar configuration is shown as in Figure 170. However, instead of the cluster being accessed via one incoming IP address, the cluster is accessed via multiple incoming IP addresses, one for each business segment. The Local Director and the Director block of Figure 169 are therefore unnecessary.

Referring to Figure 172, to minimize or avoid potential interruptions in service, clusters may be paired, each pair consisting of a work cluster (#1, #2, #3, etc.) and a redundant cluster (#1R, #2R, #3R, etc.). Preferably, RAID storage arrays are used, since RAID storage arrays are substantially fail-safe. The servers themselves are not fail-safe and therefore are provided in pairs, the servers within each pair being co-located. Within each such computer pair, one is idle, the other is in production, working on RAIDs, which store all of the software. If a computer goes down, it is replaced by simply plugging in the idle computer in its place, like a spare tire on a car. Down time is therefore minimized. Furthermore, the down time does not affect all customers but only a subset of customers serviced by the down machine. In conventional systems, down time is likely to affect all customers.

An example of the scalability of the architecture of Figure 170 and Figure 171 is shown in Figure 173, relating to product update. A product catalog may contain hundreds of thousands of product entries that must be continuously updated via the Internet. Updating involves comparing new product information to existing product information to identify new products, discontinued products, price changes, etc. Updating also involves flagging affected customer-specific catalog records, including APLs (Approved Product List) and PIDs (Product IDs, or repeat-purchase bundles) or updating APLs/PIDs in accordance with customer- specific policies. Clearly, the processing burden of daily product update can be substantial.

The present business scalability architecture enables business functions, such as product update, to be scaled independently of core data servers. Referring to Figure 173, stand alone machines are provided, each of which performs catalog processing for a respective one of multiple vendors, e.g., Vendor A, Vendor B, Vendor C, etc. Stored on each stand alone machine is a local copy of the catalog structure and data for that vendor. Each stand alone machine imports product information for a particular vendor and creates upload files. Updated and deleted products for each vendor are uploaded to an import client designated for importing products. The import client in turn uploads changes to a catalog product server, storing structure and data for the entire catalog. The product server is accessed by various clients, e.g., Client A, Client B, Client C, etc., as users access the catalog.

The stand alone machines of Figure 173 may function in conjunction with "automatons," i.e., business-task-specific PCs that n continuously, or nearly so, in the background to accomplish a particular business task. Referring to Figure 174, the nature of such automatons may be more clearly understood. Respective "Internet-facing" stand alone machines function as load relievers, relieving data servers of the burden associated with peripheral business functions. Using information gathered and prepared by the stand alone machines, various automaton machines process the data. As shown in Figure 174, one automaton might perform price update and PO processing, another automaton might handle vendor invoice verification, another automaton might handle some additional process, etc. Each automaton is associated with a dedicated client machine, and each group of autom- aton machines and dedicated client machines is associated with a corresponding server as explained previously.

Consolidator machines are back-end machines having access to all of the servers. The function of a consolidator machine is to provide relevant information to a requestor. A requestor may be, for example, the CEO, CFO or other management, coφorate accounting personnel, coφorate marketing personnel, a member of a reporting team or some additional team, etc. Each consolidator machine provides tightly focused access to information relating to a specific business function, e.g., G/L, financial statements, sales tax, purchase orders, vendor invoice verification, vendor payment, reports, etc. In this manner, business information is channeled in a highly structured manner— as opposed to being collected in a vast reservoir of commonly-held information, all processed in the same fashion without differentiation. From the standpoint of the relevant information requestor, the structure is analogous to that of the web itself, with the consolidator machines performing a function similar to that of Yahoo, Excite, etc., and the servers being analogous to servers connected to the web. Hence the designation "Internet intrinsic."

Consolidator machines may be web-accessible, enabling enteφrise management from anywhere in the world. Again, returning to the water cooler analogy, just as an executive can only drink one glass of water at a time, similarly, an executive can only digest and interact with relevant infoπnation one screenful at a time. What is important, therefore, is not that an executive enjoy instant access, at his or her whim, to every piece of information enteφrise-wide (i.e., every drop of water), but that the executive enjoy defined access to relevant, consolidated information for decision-making puφoses. Instead of drowning in information, the information need (the user's thirst for relevant information) is satisfied. Self-Help Configuration via web

Despite the powerful advantages of the present system, a phased implementation path must be provided for transition from legacy systems to the present system.

Because of the unitary nature of the database application, it cannot be modularized without compromising the advantages achieved by having such a unitary database application. Nevertheless, the need remains for a party acquiring rights to use the software to be able to customize the software according to the party's particular needs. The acquiring party may not want the full range of functionality offered by the software. Alternatively, the acquiring party may want but not be able to afford the full range of functionality offered by the software (although the cost may be an order of magnitude less than that of conventional ERP packages).

Customization is therefore achieved by providing within the software a "switch panel" that is used to turn user-visible aspects of identified business functions on or off. That, because different domain views are just a different window to the same item sold records, a user can close a "module" simply by closing the view of the module. (The "undergirding" of the system, or core functionality, such a Items, Item Detail and MWSs, however, cannot be hidden.) Unlike conventional database applications, in which modules are serially linked and closing a module severely disrupts data flow, in the present application, there is no data flow. Behind the scenes, the software continues to function as if all of the switches are turned on. When a party later wants or can afford additional functions that were previously turned off, no loading of historical data is required. The software, with the additional functions newly-activated, gives the appearance that the newly-activated functions have been working all along, because in fact they have.

Although such customization is possible using conventional packaged software distribution methods, customization is greatly facilitated using the web and electronic software distribution (ESD). In order for a party to gauge the need for various features, the party may try the software, operating on trial data, via the web, thus becoming familiar with the various functions of the software. Preferably, the party then identifies functions that the party does not want. Coπesponding switch panel settings for that party are saved. When the software is downloaded, it is downloaded with the appropriate switch panel settings for that party. In this manner, the software can be customized via the web by the user. There results massive web-based deployment to meet the needs of many diverse users by allowing users to close view in a "self-help" manner.

Instead of programmatic customization at the level of the back-end database, customization may be performed at the web level, i.e., the HTML level. Changing HTML to achieve a desired look and feel on the web is readily accomplished and can be performed independently by partners at frequent intervals- daily or even more often if desired. Backend database code may remain the same. Of course, the GUI look-and-feel presented to internal users is not affected by such web-level changes. However, there is no reason that "internal" users could not just as easily be web users instead.

Referring to Figure 175, any "cell" (Sales Request, Sales Order, etc.) can be closed and replaced by linking to a legacy system that allows for generic data transfer, e.g., via ASCII files. Unlike existing systems, such linking is in the nature of asynchronous handshake.

In existing systems, software integration is problematic, in large part because software is business-segment specific (not end-to-end). For example, one software package performs SFA, another accounting, etc. In real business, the live business entity requires interacting with multiple domains at the same time. Such interaction has historically been accomplished manually, by human processes aided by electronic human-to-human communication (phone, fax, email, etc.). To automate such interaction using conventional software, two alternatives are presented. One is to buy multiple software packages for multiple respective domains and operate those software packages at the same time, e.g., logging off SFA and logging onto accounting, etc. Another is to programmatically link the two programs to paper over, to some degree, the fact that the programs are separate and distinct. In either case, without real-time synchronous communication between the software packages, data will not be in sync between the packages. This situation may be characterized as a latency problem.

In the present system, on the other hand, everything is together in one place (at least for a particular customer). To interoperate with a legacy accounting system, for example, all of the accounting-relevant data is dumped to an accounting file for processing. Similarly, accounting results are dumped, some time later, into an import file and imported into the system. This assumes that the interaction is not time-critical. In other words, the end-to-end business process can, if required, be , broken up into levels that do not require synchronous communications between them (hence avoiding the plaguing problems of linking different systems). If interaction is time-critical, either the processes whose intercommunication is time critical must reside in the same place or be linked in the same fashion as the prior art. In many instances, however, real-time synchronous communications is not required.

In the product configuration of Figure 175, for example, the unified database application serves as a back-end data retrieval solution to an existing web front end. Hence, in the instance where a company has no back-end viable tracking and operational system, existing web input is applied to the system, which acts as a back-end business operation data engine. In Figure 176, the situation is reversed. That is, a company has an existing legacy system at the back end but needs a front- end web business solution. Here, the unified database application serves as a web- business front-end solution to an existing back end. Customer/vendor requests are input to the system, which acts as a front-end web business interface. The flexibility of the system facilitates an organized migration from legacy systems. In other words, the present system can be used to provide only a portion of an enteφrise business solution, just as in conventional practice in which segment- specific software packages are linked. The open design of the software facilitates this manner of operation. However, when used in this manner, the business process flow is broken and the database is no longer unitary. Although the software can be used in this manner, much of the instrinsic power and consequent advantage over conventional systems is lost, and the software becomes less distinctive as compared to existing software.

In Figure 177, legacy system dependence has been broken, and the unified database application serves as an integrated end-to-end business solution for the 21st century, enabling a business operation paradigm shift.

The time compression achieved by the web can also be applied to the time that normally elapses between releases of a software product, during which users must forego desirable features. A continuous release strategy is enabled by coupling web download of the software with web upload of bug reports and text entries where the system did not provide a suitable menu selection. Technology for performing such web uploads is known.

As previously explained, the present system is largely menu-driven. However, because of the inability to anticipate every possible contingency, throughout the user interface, the user is afforded the ability to make a text entry where none of the menu selections suits the user's situation. The necessity of making a text entry signals the occuπence of an unanticipated event. Although text-searchable, text entries, because their meaning is known only to users and not to the system, hamper the versatility of the system. Practice may prove that a particular situation, previous unanticipated, occurs with some regularity. When this occurs, the program is revised to provide a menu selection for this situation. For example, whereas normally it would be a mistake to send an invoice before an order has been shipped, in some instances, for example at the approach of the end of a fiscal year, a customer may make such a request. Or, a customer may request multiple partial invoices for a single item. Or a customer may request an usual payment or delivery aπangement. Conventional systems, because they do not impose a discipline, allow for such "outliers" to be handled ad hoc. Other users besides the one forcing the transaction through the system have no way of knowing what was done. This characteristic of conventional systems ensures that the intelligence of the system will never be increased, or will be increased at a glacial pace. The present system takes a different approach. Since the system enforces a discipline and cannot be bypassed, outliers that occur with some frequency are accommodated by making appropriate changes to the program. The program therefore becomes "evergreen." Training is embedded in that possibilities are brought to the attention of users as they observe various options within the system. In this manner, a subsequent user following in the tracks of a previous user whose knowledge has been captured within the system.

An outlier (circumstance that cannot cuπently be handled conveniently using the system) is signalled by a user selecting "Other" and making a text entry. In accordance with the continuous release strategy, such text entries of all users, world-wide, are uploaded via the web. A bug report facility may also be provided, with bug reports being uploaded via the web. Where a bug is discover, or a text entry occurs with some frequency, a coπesponding program revision is made by a cadre of programmers having this responsibility. Revised versions of the program can be posted at short intervals (e.g., days or weeks instead of months or years), together with a description of the revisions. Users are then free to download the revised version as their needs dictate. (Installing a new version of the software may require conversion of existing records).

A continuous release strategy avoids product obsolescence, which, in Internet time, can occur very rapidly. The advantage of downloading the software in the case of continuous release is not only time savings and convenience. Rather, if the software is delivered any other way, it is months old before it enters use. In Internet time, obsolescence may breed within days or weeks. The only way to obtain the latest, best product version, in the case of continuous release, is via the web. By web delivery, the user is assured the latest product as of the download date. In this light, web delivery becomes much more than a convenience— it becomes a necessity.

Furthermore, a continuous release strategy avoids the need for retraining, since changes are incremental rather than monumental. The system is programmed to redirect user actions appropriately in view of program changes. In conventional systems, by contrast, a great deal of time typically elapses between releases such that a subsequent version of a program may be barely recognizable as compared to the previous version. Old documentation is thrown out, new documentation is distributed, and arduous retraining begins. Although such retraining is necessary in the case of conventional systems, it cannot guarantee results. The present system eliminates retraining. Because new intelligence is embedded within the system, the desired results are guaranteed to follow— the business process cannot be performed any other way— with minimum user discomfort.

Targeted Bidding

Presently, most web sites that provide for bidding (notably eBay) are consumer-oriented. The web site functions in essence as a bulletin board. All participants are welcome, and the motto is caveat emptor (buyer beware). Sellers also may have cause to be wary. Bad actors surface all too often. Any policing efforts are (inevitably) quite perfunctory.

The present invention, on the other hand, provides for targeted bidding in a business-to-business context in which participants (business partners) are pre-qual- ified. There are no bad actors. Moreover, if a problem with a business partner were to occur, that business partner can simply be terminated, i.e., denied further access to the system. More importantly, bidding occurs with respect to presold items. The process may be viewed as analogous to a general contractor, having been awarded a bid, soliciting bids from subcontractors. One bidder will ultimately be successful. In many existing automated bidding aπangements, there is no guarantee that any bidder will be successful. In the case of one technology vendor, for example, bidding precedes the placement of any order. Depending on whether a satisfactory bid is received, an order may or may not result.

Furthermore, existing bidding systems are not integrated with back-end functions. The bid results still has to be tied into other segment-specific (not end- to-end) software, manually or through software interface. In the case of the present system, bidding is part of an integrated, automated process in which items are purchased from the successful bidder via the web. At the completion of bidding, back- end processing follows immediately and seamlessly, without the need for information transfer from computer to computer. Moreover, automatic approval intelligence may be applied to bidding. (Preferably, automatic process intelligence is applied elsewhere throughout the system, as in the case of automatic updates or alerts for customer-specific product collections— APLs— in conjunction with routine price update.) Just as in automatic RMA approval (described in the referenced application), in which submission of an RMA request is immediately approved if it meets certain stored criteria, a bid may be immediately accepted if it meets certain stored criteria (e.g., minimum number of bids received, price criteria, etc.). When the bid is automatically accepted, a coπesponding PO or the like is automatically created, immediately. The vendor that won the bid can begin working without delay, complete the work, send a bill, and get paid without delay, oftentimes before a bid would even be awarded in a conventional system.

In a very real sense, bidding capabilities merely represent the addition of a further domain as illustrated in Figure 5B. All of the system "tools" previously described (classification, hierarchy, experiential criteria, relationships, etc.) can all be brought to bear on processing within the new domain, and matching of supply and demand can be performed with human manual intervention or automatically by computer.

In an exemplary embodiment, bidding functionality is realized by taking advantage of the richness of possibilities created by inter and intra table record relationships as described previously. Assume, for example, that the receipt of demand information via the web has resulted in one or more MWSs being created, which are to be "bid out." For simplicity, assume that a single MWS it to be bid out. Within an appropriate field, the MWS is designated as a bid document, e.g., MWS/Bid. Selected bidders are identified, and multiple copies of MWS/Bid are made, one for each bidder, or vendor, e.g., MWS/Bid/Vl, MWS/Bid/V2, etc. In an exemplary embodiment, bids are invited by email. Bidders are then allowed to access MWS/Bid/Vl, MWS/Bid/V2, etc., or portions thereof, in order to complete the bid documents and thus submit bids. The bid may or may not be time-delimited and may be open or closed. In the case of time-delimited bid, access to the bid documents is not allowed, either before an advertised opening time, after an advertised closing time, or both. In the case of a closed bid (sealed bid), each vendor enjoys access only to that vendor's own bid document. In the case of an open bid, all vendor's enjoy access to all bid documents. A bid document may be provided with fields identifying a cuπent leading bid and the coπesponding bid document. After the close of bidding, the leading bid is identified automatically by the system. The coπesponding bid document is then converted to a purchase order, e.g., MWS/PO/ V4. The purchase order is then communicated to the coπesponding vendor, e.g., by email notification.

Hence, whereas cuπent web technology focuses on consumers buying products, the present technology minors buy side to sell side, on the web. There is a direct relationship of orders to bidding, and purchasing is a continuation of the process flow, which is SELL, BID, PURCHASE. Note that equivalent functionality can be achieved in many different ways using different Internet/web communications technologies, e.g., pull, push, etc., and possibly even pre-web technologies such as EDI, etc.

Goal and Task Automation

The aforementioned co-pending applications describe application of the unitary database application to sales force automation. However, the same type of productivity-enhancing, factual feedback tools can and should be made available to the rank and file regardless of the business function performed. Excellence in shipping, for example, is just as important to overall success as excellence in sales, or some other area. Such productivity-enhancement, supported by the full power of the unitary database application, are refeπed to herein as Goal and Task Automation (GTA). GTA forms the basis of factual performance analysis— the quantitative evaluation of individual, group, and company performance.

GTA is based on the concept of cyberspace departments as previously described. In an exemplary embodiment, cyberspace departments include the following:

Table 6

Table 6

Activities of all of the cyberspace departments are classified in accordance with a common activity classification scheme such as the following:

Table 7

Referring to Figure 178, when a user logs on the system, the system uses the user ID to look up both the present department/assignment of the user and the historical department/assignment of the user. If there has been no change, the system displays the previous relevant GTM display. If there has been a change, the system displays the new relevant GTM display. When a change occurs, the previous GTM history is saved for factual analysis. When a selected one of multiple function-specific GTM display formats is presented to the user, the display format is validated by user. For example, if the cuπent task/assignment of the user is shipping, a shipping GTM display format is displayed to the user, a confirmation dialog is displayed to the user. If the display format is confirmed, the user then proceeds to use the system to carry out the user's assignment.

Process Switch

The Open Navigation capabilities of the present system center around data- base "switches," including a "quick switch" feature and a "related switch" feature, both of which are described in the referenced related applications. When the quick switch command is activated, a menu of types of records is displayed. The user selects records of a desired type, all of which are then displayed within an output grid. To use the related switch feature, the user first selects one or more records within an output grid, then activates the related switch command. Again, a menu of types of records is displayed, and the user selects records of a desired type. In this instance, only those records related to the originally selected record(s) are displayed.

Despite the "at-a-glance, workscope/workflow" organization of displays, new users with little or no exposure to business may still experience some difficulty interacting with the system, knowing where to begin and how to proceed. A design goal of the present system is to, with little or no person-to-person training, transform such a person into a skilled information worker, as efficiently and painlessly as possible. This goal is accomplished using, in addition to the switch and related switch features, a "process switch." An example of a process switch menu is shown in Figure 182.

The process switch menu is organized logically by process flow and hierarchically. In the illustrated example, the process flow menu has a first level and a second level, but any number of level may be provided. The use of only two levels, however, promotes the objective of a simple, clean, easy-to-navigate user interface. In the illustrated embodiment, first and second levels are used to simplify the first level by grouping together multiple related menu items in the second level.

Menu items are organized sequentially according to business process. In the illustrated embodiment, the business process begins with Sales Force Automation (SFA). The result of SFA is a customer. Fulfilling customer demand requires a partner, or vendor. A sale to the customer may be subject to sales tax. Hence, entries 1, 2, 3 and 4 within the first level menu are SFA, Customer, Partner and Tax Table, respectively. The second level menu displays all of the types of records in the database under the first level category. For example, under the Customer category, the types of records included in the database include Customer, Customer Invoice, Customer Credit Memo, and Customer Payment. When one of these is selected, the relevant portion of the appropriate version of the online manual is displayed.

While other software packages may display sequences of steps used to perform business processes, because of the complexity of the software, an adequate description requires listing steps upon steps, ad nauseum. The process switch of Figure 182, on the other hand, is very simple. It presents screens in sequence and in relation to one another, together with a concise explanation of puφose and use.

If quick switch and related switch are compared to a car and a jet plane, respectively, process switch may be compared to railroad tracks. Whatever process switch menu item a user selects (i.e., at whatever "stop" the user boards the train), the next menu item selected from the process switch menu must be the next menu item, representing the next sequential portion of the business process (i.e., the train must stop at each and every stop). For example, if a user selects #8 from process switch, he or she can from there select #9 but cannot select #7 or # 10. In this manner, a user is systematically guided step by step through the business process. A user may be free to use quick switch or process switch to navigate freely throughout the database (i.e., drive or take a plane). As long as the user uses only process switch (i.e., takes the train), he or she must follow the prescribed path through the database.

At each step, the user can click on a help button, which causes the relevant portion of a user-type-specific manual to be displayed. For example, clicking on help within the Customer display presents a description of what the customer table is and how it is used. Similarly, clicking on help within the Partner display presents a description of what the partner table is and how it is used. In an exemplary embodiment, color coding is used to provide additional visual cues to the user. In particular, color coding is used to highlight record types that are principally related to the selected record type, as well as record types affecting (upstream) and record types affected by (downstream) the selected record type. For example, red may be used to indicate principally related record types, blue may be used to indicate upstream record types, and brown may be used to indicated downstream record types.

This collection of features facilitates guided exploration and learning, much more effectively than written materials, since the program itself is guaranteed to be up to date, whereas written materials may not be.

Any number of targeted versions of an on-line manual may be provided. In the illustrated embodiment, separate targeted versions of the on-line manual are provided for users, supervisors, management, training, engineers, programmers and consultants. Refeπing to Figure 21, number 21, a targeted version of the online manual is accessed by selecting Online Manual, then selecting the desired version.

Preferably, users are enabled to create their own customized versions of the standard online manuals. In an exemplary embodiment, side-by-side frames are provided, one frame in which the online manual is displayed and another frame where the user can cut, paste and edit text from the online manual to create the user's own customized, annotated version. Referring to Figure 184, in an exemplary embodiment, for each screen that the user visits, preferably four different versions user-type-specific online manual exceφts are provided. The first is in summary form, providing, for example, field descriptions, shop abbreviations or acronyms, the significance of color coding within the screen display, the logical aπangement and flow of the screen as it relates to process flow, options available to the user, etc. The second is more detailed, expanding on the information presented in summary form in the first. Neither the first nor the second is user-edit- able. The third and fourth versions are user-editable versions. The third version is for summary notes and is add-only. That is, user entries are cumulative and cannot be deleted. The fourth is for more detailed notes and can be freely edited. The user can cut and paste from the read-only versions into the editable versions, and can freely import or export material between the editable versions and an outside program, e.g., Microsoft Office. Authorized users, e.g., system programmers with the appropriate password, are allowed to make changes to the non-user-editable versions.

The self-training made possible by process switch and the online manual becomes especially important in the context of self-configuration and massive Internet distribution as described previously. Using the process switch, a person can familiarize him or herself with the software, its structure, and its capabilities (i.e., "kick the tires"). Such a person is also apprised of configuration options, since all of the functions up to and including a desired function are required to provide the desired function. That is, a person can select downward within the process flow represented by the process switch, but not upward. For example, to obtain the function of Customer Invoices (#11), functions 1-10 are required, but function #12, Commissions, is not.

The intelligence of the system allows for sophisticated help capabilities (one-to-one contextual teaching) to be achieved, the effect of which may be likened to a "virtual instructor" sitting right next to the user, always available. When the user is working in the program and desires help, clicking on a help button causes help content coπesponding to the portion of the program in which the user was working to be instantly displayed. The help facility may incoφorate different levels of granularity. For example, if the user requests help during the initial stages of a task, then more general information regarding that task may be displayed. If the user is well into the task and request help at a particular field, then more specific information regarding that field may be displayed. This manner of help become particularly powerful as applied through the web. As a result, workers need not be highly skilled in order to leam to use the system effectively. Time, money and user frustration are all saved as compared to conventional help-desk systems in which the user is required to articulate the problem.

More particularly, two qualitatively different kinds of help may be distinguished, "episodic help" and "sustained, nurturing help.

Episodic help attempts to solve the problem at hand with the greatest efficiency. Conventional help methods (e.g., help desks) fall into the category of episodic help. In one aspect of the invention, the efficiency of episodic help is increased by presenting precisely-targeted information to the user as previously described.

In accordance with another aspect of the invention, sustained, nurturing help is achieved by, for each individual user, compiling an electronic history of questions or help incidents by that user. Over a period of time, the system therefore enables the user to determine, for example, the topics that presented the greatest difficulty for that user (i.e., required repeated help) during that period as well as the topics that presented the least difficulty. The user is able to retrieve and review this information at the user's convenience.

This type of sustained, nurturing help has at least three important implications. First, the user is able to track the user's own progress. Intead of using a formal test to determine the user's degree of mastery, with the associated anxiety, cramming, etc., mastery is guaged continuously during use. The user need not worry about topics that the user has demonstrated mastery of. However, the system will reveal topics that the user has shown difficulty with. For example, of a total of 50 help queries by a new user, 40 might relate to a common topic, while the other 10 all relate to different topics, hence pinpointing the user's weakness in the former topic. As time progresses, the number of help queries may decrease, indicating increased mastery. The system therefore provides an objective record of the user's historic performance level.

A second implication is that the ability of users to readily transition between different responsibilities and functions is greatly increased. When a new user is to succeed a seasoned user in a particular responsibility, the seasoned user can share his or her learning experience, as recorded by the system, with the new user, since the problems encountered by the new user will probably be the same problems previously encountered by the seasoned user. By leveraging the experience of the seasoned user, the new user is able to ramp up to a proficient level of performance in a shorter period, say, two weeks instead of three months.

A third implication pertains to the software provider. In a prefeπed embodiment, a large number of users are web users. Therefore, the software provider can accumulate and "mine" a large body of data relating to user mastery. Using this data, the software provider can find out which topics generate the most questions. A topic may generate many questions because it is inherently difficult or because it is poorly presented or explained. To address the latter possibility, the software provider can provide revised help materials on a subject, making them available through the web, and observe the results. If the number of questions on that topic drop substantially, then the software provider is given some assurance that hte revision was effective.

Web-based help, instead of entirely supplanting local help embedded in a copy of the software mnning on a local user machine or network, may complement local help. That is, user questions may ordinarily be tracked on the user's local system, and the user may interact with a help manual embedded in the local system. An ability is provided, however, to seek hep at the software provider's web site, where the manual may be continuously updated. The user may simply obtain the necessary help and leave the software provider's web site. Alternatively, the user may elect to download the latest version of the help manual or a portion thereof to the user's local system. Vertical Market/Niche Market Internet Commerce Portals— Rapid Development

Present Internet "portals" such as AOL, Yahoo, Excite, etc., are general- interest, consumer-oriented sites. These sites aim to be the most frequently visited sites for the largest possible number of people. Hits per day average in the tens of millions. The estimated cost of establishing a competitive portal from scratch is in the billions of dollars. Such portals may be described as "monolithic gatekeepers," where revenue is by advertising dollars.

The concept of a business-to-business electronic commerce portal is much different. Revenue is by transactions. The function of such a portal is to provide an efficient electronic marketplace. Efficiency implies specialization. Like cells, commerce portals subdivide to grow and are never monolithic. That is, if a portal becomes too busy, it is subdivided, promoting further specialization and efficiency. In accordance with this concept, the vertical market/niche market business- to-business electronic commerce portal is a site that enables customers within a particular vertical market segment or niche market to transact business efficiently and conveniently with a variety of vendors within that market. Examples of vertical markets and niche markets include computers and electronics, food/agriculture, convenience stores, paper and office products, petrochemicals, construction, consumer goods, industrial equipment, aerospace, logistics/warehousing, etc. Unlike present monolithic gatekeeper portals, commerce portals break down the gate in order to create economic communities.

Two characteristics of vertical market/niche market business-to-business electronic commerce portals are: 1) they be established by a single vendor and in fact are more easily established by a party that is not a vendor within the relevant vertical market/niche market; 2) they typically cannot bear the cost that would be associated with establishing a portal the likes of AOL, etc.

The present invention, in one aspect, provides a turnkey solution for vertical market/niche market business-to-business electronic commerce portals. Because complete end-to-end business functionality is provided within a unitary solid-state database application, that application can be readily customized for any vertical market/niche market. This ease of customization enables rapid deployment in accordance with a "cookie-cutter" model, thus keeping pace with "Internet time." Because the unitary solid-state database is PC-based and follows a model of infrastructure on demand, start-up costs can be very low— tens of thousands of dollars instead of millions. In this context, the unitary solid-state database application is analogous to a computer's CPU in the sense that it provides a general-puφose, inexpensive, mass-market "engine" for business-to-business electronic commerce portals. In the description that follows therefore, reference is made to an electronic Commerce Portal Unit (i.e., unitary database application), or e-CPU. The e-CPU is used within the context of the existing e-commerce infrastructure to provide desktop business portal capabilities. Referring to Figure 179, such infrastructure may include, for example, e-mail, fax, business software such as Microsoft Exchange and Microsoft Office, complementary business portals, web marketing/traffic analysis, web metering, search engines (e.g., Yahoo, Excite, etc.), web content enrichment, browsers (Netscape, Microsoft), secured transaction technology (credit cards, EFT), ISP access, security (encryption/firewall), etc.

As illustrated in Figure 179, the present system functions as the "glue" that unites what are cuπently various fragmented pieces of web infrastructure to provide an overall, end-to-end business solution. The cuπent fragmentation of web infrastructure is similar to the fragmentation of enteφrise software— myriad vendors each addressing a bite-size piece of the overall problem. The present eCPU unites these various infrastructure pieces into a cohesive, powerful business framework.

Web delivery of the present software has been previously described. Such web delivery may be extended to enable a customer to select and have delivered via the web all of the software pieces required to open for web business, from the same web site or from conveniently linked web sites. Agreements may be struck with suppliers of web infrastructure software and services for this puφose. The download package is tailored and configured according to the selections and needs of the customer. One customer may require browser software, another customer may not. One customer may require SSL (Secure Socket Layer) and public key encryption, another customer may not, etc. One-stop shopping for all of the software required to open and operate a web portal makes the vision of massive, inexpensive deployment of web portals possible.

The system of Figure 164, previously described, illustrates a computer reseller portal. Particulars of a few additional commerce portals will be described. Referring to Figure 180, an example of an agriculture commerce portal is shown. The agriculture commerce portal serves an agriculture product buying group, selected members of which are shown, including, for example, an IGA (Independent Grocers Association) member, a BIG (Bureau of Independent Grocers) member, and another member. Suppliers of agricultural products include, for example, U.S. farmers and international farmers.

The underlying unitary database application software may be the same as previously described in relation to Figure 164. Users interact with the system via the web to order agricultural products and obtain reporting, tracking and billing information. Interaction of suppliers and other parties with the system may be via system-to-system interface. For example, a freight carrier receives logistics information. Historical information may be sold or provided to interested parties, e.g., a fertilizer supplier, government agencies (USD A), etc.

Interestingly, U.S. farmers and international farmers often enter into transactions in which used farm equipment from the United States is sold to international farmers or bartered in exchange for agricultural products. The system can also be used to automate such transactions.

Referring to Figure 181, an example of a convenience store commerce por- tal is shown. The convenience store commerce portal serves a franchise buying group, selected store members of which are shown.Users interact with the system via the web to order products and obtain reporting, tracking and billing information. Again, the underlying unitary database application software may be the same as previously described. Supply Chain Management is used to coordinate activities of distributors and manufacturers. A significant component of the convenience store business is equipment (e.g., vending equipment, food preparation equipment, etc.). Equipment orders are placed and are filled by the appropriate equipment suppliers. Post sale service requests are received and processed, with repairs and maintenance being performed by the appropriate repair/maintenance service.

It will be appreciated by those of ordinary skill in the art that the invention can be embodied in other specific forms without departing from the spirit or essential character thereof. The presently disclosed embodiments are therefore considered in all respects to be illustrative and not restrictive. The scope of the invention is indicated by the appended claims rather than the foregoing description, and all changes which come within the meaning and range of equivalents thereof are intended to be embraced therein.

APPENDIX A: NIGHTLY UPDATE REPORT

Subject: βgaNetworkNightly report (12/18/98 10:45 PM)

Sent: 12/19 6:39 AM

Received: 12 18 10:44 PM

From: MeqaNiαhtlv®meσanetwork com

To: charies ® meαanetwork.com iohn ® meαanetworiccom kennv@meqanetwork.com kirn ® meaanetwork.com wendv@meqanetwork.com won @ meaanetwork.com

No reminders toda .

Nightly Update Reports Follow

All MWS numbers are in sequence.

No MWS cancellation problems were found

The following sales records had ord/rcv/shp date problems which were repaired succesfully. No other date problems found.

M98-28538 11/5/98

No MWSs with unit X qty price/cost problems were found.

The following sales records have items that are received and not shipped.

M98-28619 12 7/98 NoPartial UNION BANK OF CALIFORNIA M98-28632 12/9/98 NoPartial UNION BANK OF CALIFORNIA M98-28633 12/9/98 NoPartial UNION BANK OF CALIFORNIA M98-28639 12/11/98 NoPartial UNION BANK OF CALIFORNIA M98-28640 12/11/98 NoPartial UNION BANK OF CALIFORNIA M98-28657 12/17/98 NoPartial UNION BANK OF CALIFORNIA M98-28658 12/17/98 NoPartial UNION BANK OF CALIFORNIA M98-28659 12/17/98 NoPartial UNION BANK OF CALIFORNIA M98-28660 12/17/98 NoPartial UNION BANK OF CALIFORNIA M98-28662 12 17/98 NoPartial UNION BANK OJ?. CALIFORNIA

The following shipping records shipped in the last 7 days have defualt manifest frt totals.

11/23/98 UPS Pickup*: 99076868

11/24/98 CALL TAG Pickup*: 502960111

12/1/98 CALL TAG Pickup*: 504632811 J

12/4/98 0306-243219- Pickup*:

12/11/98 UPS Pickup*: 200 monitor

12/14/98 UPS Pickup*: 990768

12/14/98 SECURITYEXP Pickup*: F71649

12/14/98 SECURITYEXP Pickup*: F71650

12/15/98 SECURITYEXP Pickup*: F71651

12/15/98 SECURITYEXP Pickup*: F71652

12/15/98 UPS Pickup*: 990768

12/16/98 SECURITYEXP Pickup*: F71653

12/16/98 SECURITYEXP Pickup*: F71654

12/16/98 UPS Pickup*: 990768

12/17/98 UPS Pickup*: 990768

12/18/98 UPS Pickup*: 990768

The following RMAs have date or qty problems and were NOT fixed.

R-272186CR 7/24/97 R-274615XDM 8/12/97 R-292761CR 12/22/97

No RMA credit problems were f uond.

The following RMAs have been received from customers in the last 30 days and need credit memos.

R-321917CR Invoice: 12/1/98 R-322083CR Invoice: 12/15/98 R-322118CR Invoice: 12/16/98 R-322267CR Invoice: 12/15/98

No RMAs have been received from customers in tjge last 30 days that need replacement MWS attention.

All customer invoices that have been printed have been issued.

The following customer invoices are issued and not printed. ^*=Old

^*17803 Customer UNION BANK OF CALIFORNIA 128/98 Pafd in full "17827 Addendum UNION BANK OF CALIFORNIA 12/14/98 Paid in full ^*17828 Addendum UNION BANK OF CALIFORNIA 12/14/98 Paid in full ^*17829 Addendum UNION BANK OF CALIFORNIA 12/14/98 Paid in full ^*17845 Customer SOUTHERN CALIFORNIA EDISON 12/16/98 "17857 Customer SOUTHERN CALIFORNIA EDISON 12/18/98

17858 Customer UNION BANK OF CALIFORNIA 12/18/98

17859 Customer UNION BANK OF CALIFORNIA 12/18/98

17860 Customer UNION BANK OF CALIFORNIA 12/18/98

17861 Customer UNION BANK OF CALIFORNIA 12/18/98

17862 Customer SOUTHERN CALIFORNIA EDISON 12/18/98

All items shipped in the last 30 days have been invoiced.

The following customer invoices were found to have commission problems:

M97-25714 10/15/97 for Charles commission & invoice GMs are different.

17843 M98-28645 12/16/98 for VERNON commission & invoice GMs are different. 17843 M98-28645 12/16/98 for KIM SEALE commission & invoice GMs are different.

Commission dates were all found to be valid.

All customer invoices issued in the last 90 days have 2 commissions.

No duplicate vendor invoices were encountered. All vendor invoice billed amounts equal payment register totals.

All items received in the last 30 days have been fully shipped.

The following MWSs have in house items that need to be ordered and or received.

M98-28657 12/17/98

M98-28658 12/17/98

M98-28659 12/17/98

M98-28660 12/17/98

M98-28662 12/17/98

M98-28663 12/18/98

All items on hold or cancelled are not on a payment register.

All Vendor Payment Register payment amounts match Ven Invoice payments.

All Vendor Payment Register credit amounts match Ven Collection amounts.

All Vendor Payment Register Credits have been issued properly.

No PrePaid Vendor Invoices were found on Non PrePay Vendor Payment Registers.

The following vendor credits have possible duplicate expected credits.

Exp-4478 00/00/00 Invoice:

Exp-5185 00/00/00 Invoice: 50-10686-21

All expected credits have an invoice assigned.

All Vendor Invoices have payment schedules that match the Invoice total.

All Ven Invoices are assigned to an AP Invoice Register.

All Ven Collection records are assigned to an AP register.

All Paid Ven Invoices are assigned to an AP Payment register. All used Vendor Credits are assigned to an AP Payment register

The following MWSs have shipped in the last 30.days but are NOT fully or over invoiced, or not printed.

^•= New

^•M98-28573 Customer SOUTHERN CALIFORNIA EDISON Unprinted invoices

^•M98-28647 Customer SOUTHERN CALIFORNIA EDISON Unprinted invoices

^•M98-28649 Customer UNION BANK OF CALIFORNIA Unprinted invoices

^•M98-28651 Customer UNION BANK OF CALIFORNIA Unprinted invoices

'M98-28652 Customer UNION BANK OF CALIFORNIA Unprinted invoices

^•M98-28653 Customer UNION BANK OF CALIFORNIA Unprinted invoices

No customer invoice tax problems were found.

All unissued customer invoices were successfully issued.

The following Customer Credits have no tax and are taxable.

CM-10432-2-10 5/15/97 Restock

Won Choi

Mega Network, Inc.

Phone:(408)730-9138 x839

Fax:(408)720-1293 won ® meoanetwork.com Structure lor Mega3.5.4

Structure lor Mega3.5-.4

Structure for Mega3.5.τt

Structure lor Mega3.5.4

Structure lor Mega3.5.4

Structure for Mβga3.5.4

Structure lor Mega3.$.4

Structure lor Mega3.5_4

Structure lor Mega3.5.4

Structure lor Mega3.5.4

Structure for Mega3.5<4

Structure for Mega3.5r.4

Structure lor Mega3.5„4

cusβuyerFAX.x A cusUsβrName.x A ^'* cusUserTel.x A cusUserFAX.x A

AplyToPayOate_x D ven Crd Vouch No.x A venCallTagNo.x A

NolResellable.x B cusRstkPerc.x R venRstkPerc.x R - cusCallTag_x A

ItemDescrip.x A

VenNA B .ReplSeq.x L £

ExpectedCredit R i

FaxedToCust B

VendorCosts R

CustCredTodate R

CredltRMA.Rcvd B

.NextCustCredSq 1

VenRMAShpd B Keywords

CustCredStalus 1

Custlnvoice A

CustlnvoiceAmnt R

.Updated B

ReplReleaaed B

Keywords

CrossShip B

VenCredZero B Word A

CusRcvDateNA B

VenShlpDatβNA B VβnRcvDateNA B

CusShlpDateNA B

KeyComment A

Printed B

CredNot Expected B

CredDilReason A

VenProposedCred R

PropCredDlfReas A

VenFrtCredNum A

VendorFrtCredil R

CustCallTagReq B

VenPackingSlip A

DateApproved D

OpenCustNotes T

WebRMA B

Weblnltlator

WβbNotes T

DeleteMe B

WebLocked B Structure lor Mega3.5;4

Structure lor Mega3.5.4

Structure lor Mega3.S.4

.AppleSlatus

PartN um ber A

Status A

Date. D

Description A

ExpDate 0

VenComments T

Structure for Mega3.-5.4

Structure lor Mega3.5.4

Structure lor Mega3.5_<4

OtherType DiscountReg B

MemoNumber έ<* A

Approved DiscountTotal R

Amount R Vendor A

Keywords Cancelled

MemoDate D

ReleasedAmount Payee A

3rd RcvdDate D

Payee Cancelled B

CredltType A

MultllnvSeq PrβPaymentReg B

Payee A

PreApproved ReceiptsReg B

UnReconciledAmt R

Scheduled Collectiontotal R

.Sequence L

CrβditToCost VenDebitArrays P

Reconciled B

MultiCreditSort Closed B

Vendor A

Receipts GL.EntrylD L

.LastReclO 1

ManualReconclle Disbursements

Cancelled B

AutoRecRMA .UnlquβKey A

CredilLelt OtherType A

CashRcvdSeq

EntryDate 0

PaymβntReg CredilToCost A

ChkDbReconciled

Receipts B

TotalChkChgs DlstribCount 1

ChckCharges

APRegSeq GLEntrylD

AP.Re isters

DeposltSeq harges Register CheckBanklD DβpositDate InvoiceTotal OβpositTime InvolceCount

OeposltBankSβq CredilTotal .APSubLSeq CredltCount CheckMe Posted QLPoslβdAmnt PeriodStart

GLPostState PeriodEnd ResetLog PostDale .Locked Comments

NetTotal

RβgOate

ReglstβrType

Structure lor Mega3.5,4

Structure lor Mega3.5_A

Structure lor Mega3.$.4

_ActsCustAsq

Account

Descnption

CustomerSeq

ShortStock

MfgPartNum Stock SSDate MegaWaiting

Structure lor Mβga3.5<4

Structure lor Mega3.5.-4

Details

.ShiplOBoxLink

ShipSeq

IDSeq

BoxSeq

Ship.ID.Key

DSSeq

Ate .RcvlOBoxLink IπvolceNum

RcvSeq RMANum

ISeq IDSeq RMACustVen2 eq BoxSeq RMAIDSeq

Rcv.lD.Key Freight

PacklngSllp .ARSubLSeq.lnv

From

INo RMACus1Ven2 Receivinq ^•βr RMAIDSeq .Sequence L lo PackSllpStrlpd RcvdDate D

.ARSubLSeq.lnv Carrier A

Tracking No A

Ho Poated B Seq Rcvd Boxes Shipment From A

.Sequence Weight R

From BoxCount I

Tracklng_No1 PallβlCount 1

Tracking_No2 HundredWt

ItemslnBoxCount ShipSeq

Pallet PlckUpNum j.S βq Box FrlCharge

Overpack OeclaredValue

InsuranceChrg

Total

Jheck VenlnvSeq xxx Structure lor Mega3.5.4

Structure for Mega3.5.4~

RMA i

CrβdltMβmo

CheckCredUnk

CMVoucher

ChlldSeq CrβdltAmnt ParβπtSβq Claim

ChlleOistrAmπl Paid.ToDate

ChildNumber PaySchedulβd

ParentNumber EntryDate

ParentAmount PrePaid

ParentDescrlpto RecPate

ChildDescriptor PrβApproved

ApprOate

PaidDAtβ

LaslPayDate

Closed

ClosedDate

Disbursements

Hold

.BankActSβq L HoidOate

Ref.CheckNum A VenRMANum

Amount R DlscPercent

Payee A VeπStatu!

CheckDate D LastRcvDate

Payable To T MWS

Venfied B PaymentRβgs

.ChekRegSeq L LastPayment

.SplitPayNum 1 LaslRefβrence

QuickCheck B

DiscountsTaken

QCPayee A

DlscountsLost

QCPayableTo ^'. A DlscountAvail

DiscountOate

DuβData

Custlnvoices

VerlfyStatus

VouchersSub

VouchersSub TempNotes

MegaVouchβrNo DropShip

PaymentDate UnderBllled

Payment RecurrlngExp

RβadyToRevlew

Reviewed

ReviewedBy

RevlewOatβ

RevlewSlatus

Tracking

Tracking Notes

AlternatβPS

InvNoStrlpd

FreightBIM

.APReglster

.APSubLSeq.lnv

.GL.APseq

_GLVenlnv_Splil _GL_NetSeq

VenlnvSequβncβ _GL_TaxSeq GL.AccountSβq _GL_FrtSeq

Debit _GL_MlscSeq Credit _GL_lntSeq

Structure for Mega3.5.4-

Structure for Mega3.5r4

Structure lor Mega3.5.4.

Contacts Fife' CntctComments

CuatomerSeq .Seq Partner.Code ContDate _Sβq ContTi e

Telephone Comment Teiephone2 CommentFoπnai Fax CalSeq Title Thread

Department Short.Note Comments First Name Kβy2_LastNamβ .UnlquβKey Keyl.Aflllatlon Address .areacode FAX Grouping FAX Grouping .FaxGrpSβq "- I- Personal

Owner.Crβaler Keywords MyContacts

Threads

Thread Owner.Creater

Keywords

Word

FAX Templates .FaxGroups

Template Name FaxGrpSeq

FaxDalβ FaxGroup

PageCount

Company

Name

Phone

FAX

Subject

From Name

From Depl

From Phone

From FAX

Message.

_XX

UseFaxGroup

_FaxGroup Structure for Mega3.5.4.

Structure for Mega3.5.4

Structure for Mega3.5.4

Freight npul R 0

Value -*. R LastPayDate

ReconclledFrt B AR. Voucher A

.(.asfWegή/ R

OeclaredValue R CollectlonStat A

MWSNum A

BoxCount 1 Paid.To.Dalβ R

PacklngSllp L

PallβtCount 1 PostedAR B

Invoice L

MnlstlnsCh.Act R _NextSalesAd| 1

OverPack B

MnftFrt.Act R FrtManual B

.VenlnvSeq L

100WITotal_act R CredCardType A

Declarei Value R

MπfstTotalChrge R _CrβdNumbβr A

TlHOOFrt R CrβdExpDate D

TtMOOOecl R CredlnfoValid 8

Packing Slips ttMOOiπsChrg R CredConfirmNum A

PSNu L

Total lOOCharge R CredBatchNum A

ShlpDate D

MnfstModllled B Settlement 1

Comments T

.CheckMe B CredC-ate D

Intemal Commen T

.GLFryPosted R CredName A

ShlpTo A DropShip B

PalletCount 1 Deleted B

BoxCount 1 NoTax Reason A

ItemCount 1 Age 1

Value R Age306090 1

Insurance R .SRCommlssued B

ComputedWeight R .SupCommlssued B

ActualWeight R Printed B

Freιght_Ttl R SplltJolnOrlgln L

OvβφackCount 1 .AR R eglster L

-ZZZ A .ARSubLSeq L

_xxxx R

.GLC heckMe B

.GL.ARSeq L

.GL.SalesSeq L

.GL.TaxSeq L

.GL.FrtSeq L

.GL.LaborSeq L

.GL.MscSeq L

.GLPst.ARSeq L

.GLPst.AR R

.GLPst.SalesSeq L

.GLPst.Sales R

.GLPst.TaxSeq L

.GLPst.Tax R

Commissions

.GLPst.FrtSeq L

Sales_Suppon SalesRep.Code A .GLPst.Frt R

SupRep.Code A Sales.Rep A .GLPst.LaborSeq L

SalesSup.Rep A CommissionRatβ R .GLPst.Labor R

CommissionRatβ R EntryTypβ A .GLPst.MscSβq L

.User A Rel.lnvolce L .GLPst.Msc R

Active B Rel.Crβdlt A .CCPo stβdC Pey 8

WebPassword A CustomerPO A _GLEntryl D.CC L

MegaEMail T MWS A ColiectionPro&s '

Distributed 8 Contact Log

CommReglster L HasCollectProbs B

Pay Date D CollectionTickl "

Commission R

Sales_Reps xxlnvoiceNum L

Comment T xxCusto erPO A

SalesRep.Code Approved B xxInvαicβDate D Sales.Rep Hold B Structure for Mega3.5.4

Structure lor Mega3.5.4

Structure lor Mβga3.5.4.

Structure lor Mega3.5.4-

Structure lor Mega3.5.4^'

LaslUpdate 1

FLDebug B

VlnvRecChβckOff 8

BULoglntTlcks L

RemαteUpdateOn B

4DBackupθn B

4DBULocation T

MidDayBUTimβ H

PrsMinSlze _ L

PrsSldSize - L

PrsOptSizβ L

PrsMaxSlzβ L

VenVerSets P

DailyVenVerOlf B

VendorArraysOk B

AutoConvMonOn B

Monitorlntβrval L

VendorLock B

MldDayLag 1

WrngPrd.Lead A

DelProd.lβad A

DefParts.Lead A

ShipplngUser A

SuppliesCust A

IπtemalUseCust A

InvβntoryCust A

ScheduledCust A

DelSchedLβad A

ExpNotOrdArrays P

ExpNolRcvArrays P

ExpNotShpArrays P

ExpD ShpArrays P

CollectlonBndl P

ReplSelβsRβp A

PreLaunchPrs B

CostAdj R

CredCardCostAdj R

RMAFaxTβxt T

VenlnvVer2 P

VeπlnvPaidOlf B

HTMLTextblob P

SaleTaxModuieON 8

MWSFaxON B

MWSFaxNum A

MWSEmail T

CommEMail T

EMailToDβsignβr B

DesignerEmail A

SRLockOn B

APRegOn B

ARRegOn B

LastlntCheckSeq L

OrphanMFGs P

FlushCount L

ImportScrlpts •

4DHTMLPalh T ImportScripts I Structure lor Mega3.5."_l venαor Script

lickCheckArray Structure lor Mega3.5.'<t

LastCoreMWSSeq L

OnSileSeivDef R CustPayments

GL.Rebale.Del L Chβck.Ret

GL_Divld_Oel L RcptCredOate

ScreenPWNotReq B PayAmount

LoginCopyRlght T InternalNotes

ChecklngOπ 8 Customer

Entry.Oate

Type.

TotalOisbursed

.CustPayDistr

.Sequence

InvolceNum L

Payθalance

DistDate D

ReconToCash

Amount R

CredDebillssued

Reference L

InvTotalDisb

InvNotUpdated B

CMTotalDisb

.DβtID L

Reconciled .DetUnlque A

Posted

.ARSubLSeq L

CreatedBy

GL.PstAmnt R

Approved

_xxxxxx T AR.Voucher

_xxxxxxx T .CustPayOetails Approvad.Date

_xxxxxxxx T

Seq Post.Date

Type. .CustomerSeq

StubAmount .LastDetlO

Reconciled SlubDistrAlert

StubRsl .DβpositSeq

AppliβdAmnt ARRegister

AppliβdRef PoslBalance

.DetaillD StubBalance

.DetUnlque G LEntrylD

Relatedlnv GL.CashAct.Seq

CustCredOist ReconToCash GL.CheckME

MemoNumber IssuedCredDeb GL.PstAmnl

DistDate .ARSubLSeq.CC NβwGLMeth

Amount GLEntiylD.Log

Ref erence CheckBanklD

CMNotUpdated DeposilDate

.OetlD DβpositTime

.DetUnlque .OepositBankSeq

Issue

.ARSubLSeq

GL.PstAmnt

CollectionProbs

Probe Resolved

ConlactLoq

ContactType A

CurrentDate D

Comments A

.current time H

ActivityDate D Structure for Mega3.5.4

Structure for Mega3.5.4"

Structure lor Mega3.5.4.

CalcAssiqnments

CalclO L

Mutlplier I

Structure lor Mega3.S.4

Structure lor Mega3.5.4 ui ϊsoraMiu 1 Sequences

PnceMTO R _FHδAdmιn Sequence I

PrlceYTD R Name A NextNumber L

MaxPriceYTD H Procedure T SequenceName A

MinPnceYTD R AdminFile A ReuseMe *

AvgPriceYTD R Info T

QtySoldYTD 1 Warn B

LastSaleDale D Parent A

CurrentMonth 1 Folder 8

CurrenlYβar 1 Access. A

QtylnSlock 1

SlockAvail 1

Structure lor Mega3.5.4-

Structure lor Mega3.5.4.

OverUnderPay

Customer

Amount

Reason

.PaymβntSeq

ToCash

CredDeblssued

Closed

AmountFπnCPmnl

BadDebt

GLEntrylD_Loq

GLEntrylO

Structure for Mega3.5

Structure for Mega3.5.4

Structure for Mega3.5.4.

Structure tor Mega3.5.4-

.Letters

A

T it A e R

T

^:ont A

Size R

T oni A

R it Page B le 1

Style 1

;tyle 1

Mignment A

Jignmβnt A ignment A

.BadVendors

B

Structure for Mega3.5.4

Structure lor Mega3.5.4

Structure lor Mega3.5.4.

Structure lor Mega3.5.4

.GLBankRq Split

JankRegSequence L ϊL.AccountSeq L

)ebιt R edιl R ion. 1 kctType A ϊL.Account A ditable B ϊashRcptSβq L xplanadon A iashOlsbSβq L

L A R L 0 A A

Claims

What is claimed is:

1. A method of providing a rapid-deployment, scalable, virtual-business data processing system using a web-enabled relational database management system running on a server platform, comprising: a single vendor providing within a single database application core business functions within each of multiple business domains, the combination of the multiple business domains defining an end-to-end business process; and enabling a full spectrum of business functions to be performed remotely via the web.

2. The method of Claim 1, further comprising, for different business partners or groups of business partners, providing separate hardware and separate instances of the single database application.

3. The method of Claim 2, further comprising accessing separate instances of the single database application to derive aggregate data.

4. The method of Claim 1 , wherein the single database application is a web-enabled unitary database application including an item table comprising item records and software for reading item records, organizing selected information from the item records, and presenting the selected information as domain-specific displays, each item record containing business domain-specific fields pertaining to a plurality of the following business domains: products, payments, performance and personnel, further comprising: integrating with the web-enabled unitary database screen displays customized for a particular vertical market/niche market.

5. The method of Claim 4, wherein, once item information has been input and committed, it is immediately available for viewing by a multiplicity of information workers, different information workers having responsibility for different ones of said domains.

6. The method of Claim 1 , further comprising: for at least one business partner, storing within the database, in accordance with a single database schema, all current records required to perform a full spectrum of business functions throughout a life cycle of each product item; and limiting a number of business partners for which current records are stored within the database.

7. The method of Claim 6, further comprising: . providing an additional server platform running the web-enabled relational database management system; for at least one additional business partner, storing within a further database on the additional server platform, in accordance with a single database schema, all current records required to perform a full spectrum of business functions throughout a life cycle of each product item; and limiting a number of business partners for which current records are stored within the further database; whereby business scalability is achieved.

8. The method of Claim 1, wherein the single database application comprises end-to-end, business-to-business, e-commerce business automation software for automation business functions across multiple business domains, further comprising: identifying multiple capabilities of the software; and via web administration, a user visiting a web site and selecting one or more capabilities to be enabled or disabled, producing a custom software configuration.

9. The method of Claim 8, wherein the software produces a work- scope/workflow structured display of complex database records each comprising multiple lines of text and pertaining to both a first party to a business transaction and a second party to the business transaction, the structured display constituting an integrated decision-making environment for a particular business function.

10. The method of Claim 8, wherein only user interaction with respect to a selected capability is disabled, further comprising: while user interaction with respect to a selected capability is disabled, performing data processing with respect to the selected capability; a user requesting the selected capability to be re-enabled; re-enabling the selected capability; and displaying information resulting at least in part from data processing performed when user interaction with respect to the selected capability was disabled.

11. The method of Claim 10, wherein at least one of requesting the selected capability to be re-enabled and re-enabling the selected capability is performed via the web.

12. The method of Claim 8, further comprising: providing an active display organized sequentially in order of process flow of a business process; a user selecting an active area within the display; and displaying to the user information about a subject of the menu item.

13. The method of Claim 12, further comprising: a user making an improper configuration selection; notifying the user of the improper selection; and displaying to the user the display organized sequentially in order of process flow.

14. The method of Claim 8, further comprising: from said web site or a related web site, a user making a selection of web infrastructure products or services to be used in conjunction with the end-to-end, business-to-business, e-commerce business automation software; and communicating the selection to a business partner.

15. The method of Claim 14, wherein the selection is communicated electronically.

16. The method of Claim 14, further comprising delivering one or more web infrastructure products electronically.

17. The method of Claim 14, further comprising activating a web infrastructure service electronically.

18. The method of Claim 14, wherein said web infrastructure products or services include at least one of the following: browser software, Internet service, security, search engine service, business intelligence, office productivity software, payment technology, intranet content, web-delivered content, complementary relationships, and new types of web sites.

19. The method of Claim 1 , further comprising: the single database application receiving demand information from multiple sources via a global computer network; performing at least one of: a) consolidating demand information received from multiple different sources, producing consolidated demand information; and b) distributing demand information, producing distributed demand information; retaining a distinct record of individual demand information received from each of the multiple different sources; electronically communicating at least one of the consolidated demand information and the distributed demand information to a pool of multiple pre-qualified bidders; and electronically receiving one or more bids from the pool of pre-qualified bidders.

20. The method of Claim 1, further comprising: defining a common demand document; defining multiple sub-types of the common demand document; the single database application receiving demand information from multiple sources via a global computer network; producing a common demand document record using at least a portion of said demand information; and deriving at least in part from the common demand document record a separate common demand document record of one of said sub-types.

21. The method of Claim 1 , wherein automated processing of demand rmed for both stock items and build-to-order items, further comprising: receiving demand information via the web including demand information for stock items and demand information for build-to-order items; for a stock item, creating a common demand record; for a build-to-order item, creating multiple related common demand records classified by different levels, an item of one related common demand record to form part of an item of another related common demand record; using the common demand record for the stock item, communicating demand information to a vendor or manufacturer; and using the multiple related common demand records, communicating demand information to multiple vendors or manufacturers within a supply chain for the build-to-order item.

22. The method of Claim 21 , further comprising: creating and storing a single product file containing records for both finished goods and component parts; and users accessing the single product file for purposes of demand preparation for both stock items and build-to-order items.

23. The method of Claim 22, further comprising: storing a user demand record specifying one or more items; determining that an item collection of component parts is stored for a particular item; and modifying a demand record to include said component parts.

24. The method of Claim 23, further comprising designating items as belonging to different levels according to whether an item is a primary product, a secondary item that is a component part of a primary product, a ternary item that is a component part of a secondary item, etc.

25. The method of Claim 1 , further comprising: the single database application receiving via the web demand information relating to tangible goods; creating one common demand record using the demand informa- tion; creating another common demand record based on other demand infoπnation relating to intangibles having an associated monetary amount; and using, at least in part, the same business process logic to process both the one common demand record and the other common demand record.

26. The method of Claim 1 , wherein budget preparation and control is performed, further comprising: within a partner file, creating a budget record for that partner; during a demand preparation process, specifying a partner and an expense amount; based on a budget record for the specified partner, performing a budget compliance check; and if the expense amount is not within budget, preventing the demand preparation process from completing.

27. The method of Claim 26, comprising the further steps of an authorized user making a budget adjustment to allow the demand preparation process to complete.

28. The method of Claim 26, further comprising specifying an account from a chart of accounts to which the expense amount is to be posted.

29. The method of Claim 28, further comprising displaying real-time budget information for at least one of a partner or group of partners and an account or group of accounts.

30. The method of Claim 1 , wherein a business function is added to a common automated process flow, further comprising: identifying a first aspect of the business function as being more closely identified with one of supply and demand; adding to a base record a field related to the business function; creating a first record based on base records, the first record being one of a supply record and a demand record according to whether the first aspect of the business function was identified as being more closely identified with supply or demand; creating a second record, the second record being an opposite one of a supply record and a demand record than the first record; and during the course of the automated process flow, reconciling the first record and the second record.

31. The method of Claim 1 , further comprising: for each of a multiplicity of business needs, representing the business need as one of a common demand document and a common supply document, common demand documents and common supply documents being based on instances of a common base record; for demand documents, creating counterpart supply documents, and vice versa; and during the course of the automated process flow, reconciling counterpart demand and supply documents.

32. The method of Claim 1, further comprising performing asset tracking over a life cycle of an asset, comprising: creating a budget request record for the asset; obtaining necessary budget approvals; tracking, by personnel, budget requests and budget approvals; receiving the asset using an automated receiving process; and shipping the asset to an internal destination using an automated shipping process.

33. The method of Claim 32, further comprising transferring the asset to a different location using an automated returns process and the shipping process.

34. The method of Claim 1, wherein information about the system is organized and presented, further comprising: providing a menu organized sequentially in order of process flow of a business process; a user selecting a menu item; and displaying to the user information about a subject of the menu item.

35. The method of Claim 34, wherein the menu is organized into a first level menu and a second level menu, with multiple record types being displayed within a second menu level in response to a selection within the first level.

36. The method of Claim 35, further comprising color coding menu items to identify at least one of record types related to a selected record type, record types affecting the selected record type, and record types affected by the selected record type.

37. The method of Claim 35, further comprising displaying information from one of multiple targeted online manuals in accordance with at least one of responsibilities of a user and a selection of the user.

38. The method of Claim 37, further comprising a user causing one of multiple targeted online manuals to be displayed by selecting Online Manual from a first menu level and, within a second menu level, selecting from among different categories of users.

39. The method of Claim 35, wherein the information is an excerpt from an online manual.

40. The method of Claim 1, wherein an adaptable business processing mechanism is realized, further comprising: creating an item container record for holding one or more items from a common demand source; adding to the item container record at least one item record describing something that has an associated cost and that is, or is anticipated to be, the subject of a demand; performing demand fulfillment processing of the item container record; receiving a request for payment, including a payment amount, and making a corresponding entry in the database; and reconciling the payment amount and corresponding item costs and any associated costs.

41. The method of Claim 40, wherein the item is one of the following: a customer item, a budget item, an item for internal use, a service item, an inventory item, and an item stemming from legal or contractual obligation.

42. The method of Claim 40, including a multiplicity of item container records, wherein items include at least two of the following: a customer item, a budget item, an item for internal use, a service item, an inventory item, an item stemming from legal or contractual obligation, and other item.

43. The method of Claim 40, wherein the common demand source is one of the following: customer, vendor, internal user, governmental entity, consultant, and financial institution.

44. The method of Claim 40, including a multiplicity of item container records, wherein common demand sources include at least two of the following: customer, vendor, internal user, governmental entity, consultant, financial institution, and other demand source.

45. The method of Claim 1 , wherein tax reporting is automated, further comprising: creating sales records, each sales record including a ship-to address; automatically retrieving an applicable sales tax rate based on the ship-to address and generating a sales tax record; and from a multiplicity of sales tax records pertaining to a tax reporting period, automatically generating a tax return.

46. The method of Claim 45, further comprising filing the tax return via the web.

47. The method of Claim 45, further comprising auditing the tax return via the web.

48. The method of Claim 1, where extensibility is achieved, further comprising: storing in the database item-level base records, demand records derived at least in part from the item-level base records, and supply records, a supply record representing a call for payment; identifying a new function as relating more closely to one of supply and demand, the new function ultimately affecting payments; performing at least one of: identifying within the structure of a base record one or more fields supporting the new function; and adding to the structure of a base record one or more fields supporting the new function; adding program logic that uses said one or more fields to produce a modified view of at least one of demand records and supply records, corresponding to said one of supply and demand, the modified view providing user interface support for the new function; and performing an automatic reconciliation process in which corresponding supply records and demand records are compared and at least some supply records are cleared for payment.

49. The method of Claim 48, further comprising relating different views of at least one of supply and demand records.

50. The method of Claim 1 , further comprising: the single database application receiving demand information from multiple sources via a global computer network; electronically communicating demand information to multiple bidders; and electronically receiving one or more bids from the bidders and automatically evaluating the bids in accordance with stored criteria; and if a best bid is identified in accordance with the stored criteria, automatically creating a purchase order, and communicating the purchase order to a corresponding bidder.

51. The method of Claim 1 , further comprising: establishing an operations and payment mechanism; establishing a budget mechanism linked to at least one of the operations and payment mechanisms; and performing real-time budget reconciliation and statusing to display current budget compliance information.

52. The method of Claim 1 , wherein life cycle asset tracking is performed, comprising: using a receiving and shipping mechanism used for satisfying external demand, receiving an asset for internal use and transferring the asset to an internal user; and providing an asset view whereby assets are viewed by at least one of internal user and department.

53. The method of Claim 52, further comprising: using a service mechanism used for satisfying external demand, an internal user relinquishing an asset; and using the receiving and shipping mechanism, transferring the asset to a different internal user.

54. The method of Claim 1 , wherein user training is automated, further comprising: updating the system to newly require a specified sequence of user actions to enable a transaction to proceed; and producing a prompt redirecting user actions not in accordance with the specified sequence, to assist the user in achieving the specified sequence of user actions.

55. The method of Claim 1, further comprising: tracking user focus within a user interface of the database application; and in response to a user request for help, displaying to the user targeted information in accordance with the user focus.

56. The method of Claim 55, wherein a level of detail of the targeted information is varied in accorandance with the user focus.

57. The method of Claim 55, wherein the user interface is a web user interface.

58. The method of Claim 1, further comprising: receiving order information for multiple customer orders, at least some of the customer orders having multiple items; place one or more vendor orders corresponding to the multiple customer orders, and receiving items from the vendor orders; and automatically allocating items from the vendor orders to customer orders so as to minimize backorders.

59. The method of Claim 1, further comprising: tracking over time help queries on a per-user basis; and displaying help history information to a user upon request by that user.

60. The method of Claim 59, further comprising: tracking over time help queries on an aggregate basis; revising on-line help materials; and tracking variation over time in the number of help queries.

61. A scalable internet transaction processing system comprising: multiple server machines that serve data for respective non-overlapping portions of a customer base; and means for directing a customer's internet request to a corresponding server machine; wherein, when an expanded customer base exceeds the capacity of the multiple server machines, a further server machine is added such that the multiple server machines and the further server machine serve data for respective non-overlapping portions of the expanded customer base, achieving business scalability.

62. The apparatus of Claim 61 , wherein the multiple server machines and the further server machine are low-cost, mass-market commodity machines.

63. The apparatus of Claim 61, wherein the means for directing comprises a machine operating as a network traffic controller and a machine operating as a pre-assigned web client.

64. The apparatus of Claim 61 , wherein the means for directing comprises multiple pre-assigned web client machines, responsive to respective distinct internet addresses.

65. The apparatus of Claim 61, wherein each of the multiple server machines runs a separate instance of a unified end-to-end, business-to-business, e- commerce business automation database application.

66. The apparatus of Claim 61 , further comprising a machine having access to more than one of the multiple server machines for consolidating from them like data for at least a larger portion of the customer base.