WO1999033016A9

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

Info

Publication number: WO1999033016A9
Application number: PCT/US1998/027496
Authority: WO
Inventors: Charles Wong
Original assignee: Charles Wong
Priority date: 1997-12-22
Filing date: 1998-12-22
Publication date: 1999-11-04
Also published as: EP1055185A1; US6343275B1; WO1999033016A1; KR20010033456A; AU2205799A; JP2001527248A; US6115690A

Abstract

The present invention, generally speaking, provides software that enables end-to-end, business-to-business Web commerce (Web business, or e-business) and that automates to the greatest degree possible, in a unified and synergistic fashion and using best proven business practices, the various aspects of running a successful and profitable business. Web business and business automation are both greatly facilitated using a computing model based on a single integrated database management system (DBMS) with intrinsic data synchronization that is either Web-enabled or provided with a Web front-end. The Web provides a window into a 'seamless' end-to-end internal business process. The effect of such integration on the business cycle is profound, allowing the sale of virtually anything in a transactional context (goods, services, insurance, subscriptions, etc.) to be drastically streamlined.

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 business-to-business Web commerc * and to business automation systems

2. State of the Art

Web commerce may be defined as the use of a computer network, such as the Internet, to do business, such as buy and sell products or services Although Web commerce is still in its infancy, relatively speaking, Web commerce is predicted by some to soon become the dominant mode of business practice Web commerce allows business to move much more quickly, without the burden and cost of paperwork

Despite the promise of Web commerce current Web commerce software is typically of very limited capability Most Web commerce is consumer-oriented rather than business-oriented The tacit assumption is that the purpose of the Internet should be to enrich people's personal lives more than to enable business to move at light speed Furthermore, typically each transaction is treated in isolation No on-going course of business is assumed or facilitated

Material management functions such as procurement represent a substantial expense and burden for medium and large businesses Purchases are typically subject to approval at multiple levels In the case of the purchase of a computer, for example, an employee might submit a purchase request to the employee s supervisor, who might approve the request and forward it to the MIS (Management Information Systems) department, which might approve the request and forward it to accounting for budgetary approval The real cost of such a process is estimated to be as much as $ 100 per purchase request Furthermore, the time required for such a process to be completed may be weeks or months In the meantime, productivity may suffer Purchasing, moreover is only part of the larger problem of material management Once materials have been procured, typically they must be tagged, tracked and accounted for, both physically and in accounting terms such as depreciation, etc The latter activities may either be conducted in an organized fashion, often at considerable expense, or haphazardly, with marginal effectiveness

Existing Web commerce software is likewise fraught with problems for the selling company When an order s placed through the Web, it typically results in a fax or email, information from which must be manually entered into an internal sales system that mav or may not be linked to other closed systems such as accounting, human resources, purchasing, assembly, etc Even if these various systems are linked in some fashion such linking is fixed, not responsive to change Hence, once an entry is made depe idmg on the degree of automation, additional manual intervention may be required to achieve the desired final result e g ship a product to a customer The purchaser is typically unable to determine the status of an order without placing a call or sending an email Moreover, order fulfillment is again only a part of the larger problem of total customer satisfaction (which is in turn only a part of the larger problem of running a successful profitable business) Returns are bound to occur and must typically be handled manually tvpicallv by a Return Merchandise Authorization (RMA) or traffic department A.lso borne fraction of shipments are bound to be lost, damaged or mis-shipped Related insurance claims typically must also be handled manually both by the traffic and accounting departments Even though the foregoing activities are closely related functionally, the mechanisms for handling these activities whether manual or automated, are often ad hoc. because of the unanticipated, non-routine, but inevitable nature of such events

On a business-wide scale, the same is largely true the various activities of the business, while they may be separately automated, are not automated in a unified, synergistic fashion Automation is typically performed by automating, testing and implementing fixed, linear work flows for a fixed 'efiWonment, resulting in systems that are not adaptable to the real, changing business environment Most often, different departments each have separate database systems with the departments being linked by a local- or wide-area network A person in one department obtains information from a different department by sending an email and requesting a report Referring more particularly to Figure 1, in accordance with a typica' model of business automation, vaπou departments (e g , sales, sales support, customer service, accounting, purchasing, receiving, engineering, assembly shipping) are separately automated but linked together by a computer network (e g LAN. WAN) Each department interfaces to multiple different departments in an essentially manual fashion but using modern electronic communications tools — phone, fax, email, computer hardcopy, etc Comparison of the resulting overall business process to a Rube Goldberg invention is apt, if mildly exaggerated The process entails repeated transmission of duplicate information to different depaπments and repeated transmission of additional information and instructions to different departments on an as-needed basis The party transmitting the information controls the amount and quality of information conveyed The party receiving the information has no control over the information or the quality of the instructions received but rather is entirely dependent on the party transmitting the information Duplication occurs both within departments and between departments An external influence to the system (a call from a customer or endor a new customer account, a ruffled employee) can and often does cause a flurry of activities, but often produces less-than-commensurate positive results because of the inherent inefficiency of the system The process, because it is ill-defined, is not easily reversible when an error has been made In most systems, mistakes must be propagated to the end of a work flow before reversal can occur

The foregoing model results in the fragmentation of information — ^"the right hand does not know what the left hand is doing " Information is transported from one place to another, either in hardcopy form, necessitating re-entry, or in such electronic form as to require substantial massaging, and with substantial latency such that by the time the information is to be used it is already outdated A business executive, for lack of readily-available, accurate, verifiable information in usable form, must then rely heavily on subordinates to obtain a picture (hopefully accurate) of what is happening inside the company Considerably employee time may be spent gatheπng

data to satisfy the need for management information The same factors that hamper management performance may also cause performance at lower levels within the company to suffer Employees may lack timely information regarding critical tasks that need to be performed For lack of timely information regarding returns, for example, or some other aspects of operations, accounting personnel may pay invoices that should in fact not be paid

The lack of readily-available, verifiable information in usable form is most pronounced in relation to financial information In the case of a sales company doing a substantial volume of business, for example, preparation of a state sales tax return may take ten man-days or more An audit may take a similar amount of preparation Closing the books on an accounting period is itself an arduous task The time requirements and challenges posed by month-end and year-end closings are all-too-familiar to virtually all m-house accountants Despite these heroics, the inherent latency of the process diminishes the value of the results A finalized June statement for example, might be received at the end of July or the beginning of August, hampering the ability to react quickly to changing business conditions A real-time financial statement is non-existent

For lack of readily-available, verifiable information in usable form, employee evaluation is often performed more on the basis of perception than objective reality The appearance of performance then becomes at least as important as real performance Employee performance and employee morale may suffer as a result Numerous "high-power" database application software packages exist in the marketplace, from such industry leaders as SAP, Peoplesoft, BAAN and Oracle The solutions of each of these vendors have strengths and weaknesses SAP, for example, although strong in the area of fixed asset management and financials, does not provide flexible shipping and receiving functions To automate these functions requires the use of separate software Furthermore, Web integration is pioblemati BAAN is strong in the a eas of shipping/receiving, manufacture and assembly, but is limited in the areas of fixed asset management and material handling In particular, BAAN, SAP, etc are bound by conventional notions of real inventory — an item must physically be in stock before it can be ordered (as contrasted with the concept of virtual inventory, explained more fully hereinafter) Peo_^ lesoft offers strong human relation, functions but is not strong in ' back-end" functions Software packages from Peoplesoft and BAAN are therefore often linked together to provided a more complete solution Similarly, software from SAP may be linked to software from BAAN Oracle offers discrete modules for almost all of the functions offered by the other software packages The modules must be linked together in a laborious process, however, ith substantial duplication of data in all modules None of these software packages have a Web-centπc design, nor has any been used to successfully implement an automatic ene-to-end business process, even in large corporations having no lack of resources

Web-centric e-business solutions" are offered by Pandesic (Intel and SAP), Actra (Netscape) and other (typically early-stage) companies In the case of Pandesic, early promotional materials indicate a distinct consumer orientation as opposed to business-to-business A conventional real inventory model is followed in which product must be warehoused and on-hand in order to allow the product to be ordered Furthermore, Web operations are segregated from non-Web operations, necessitating duplication In the case of Actra, a portfolio of commerce software, including legacy application integration modules, are designed to "bridge gaps between enterprises and applications," enabling business-to-business transactions, buyer-side and seller-side procurement, consumer on-line Internet storefronts, and commercial Internet publishing. This "gap-bridging^" approach likewise entails substantial duplication.

Dell and Cisco each sells computer and networking equipment directly to consumers over the Web using configuration and order software developed by outside third parties. Business-to-business features, such as invoices, RMAs (particularly automatic "instant" RMAs) are lacking. The software does not provide an end-to-end Web-business solution.

The need for more powerful business solutions is especially apparent in the area of supply-chain management. Currently, demand information is forecast- based and propagates slowly through a supply chain through manual processes. The result is frequent oversupply and undersupply. The power of the Web has not yet been brought to bear on the supply-chain management problem.

A need therefore exists for software that enables end-to-end, business-to- business Web commerce and that automates to the greatest degree possible, in a unified and synergistic fashion, the various aspects of running a successful and profitable business. The present invention addresses this need.

SUMMARY OF THE INVENTION

The present invention, generally speaking, provides software that enables end-to-end, business-to-business Web commerce (Web business, or e-business) and that automates to the greatest degree possible, in a unified and synergistic fashion and using best proven business practices, the various aspects of running a successful and profitable business. Web business and business automation are both greatly facilitated using a computing model based on a single integrated database management system (DBMS) with intrinsic data synchronization that is either Web-enabled or provided with a Web front-end. The Web provides a window into a "seamless^" end-to-end internal business process. The effect of such integration on the business cycle is profound, allowing the sale of virtually anything in a transactional context (goods, services, insurance, subscπptions, etc ) to be drastically streamlined In accordance with one aspect of the invention, business-to-business transaction processing using a database and a database management system is performed by receiving user demand information (or a user "wish list" or expression of interest interest in selected products) electronically, at least partially in response to receiving the user demand informa _on electronically, automatically storing an order record in the database and maintaining the order record in the database throughout a life cycle of the order, and during the life cycle of the order multiple users each accessing the order record and processing the order to accomplish a respective one of multiple business functions, and creating records related to the order The life cycle of the order includes an expected period for at least one of reversal, service, and parts order, where reversal includes customer returns, cann- cellation and correction of improperly fulfilled or mistaken orders, including employee mistakes The business software provides a Web-based, business-to- business electronic commerce framework that uses the Web as a medium for all parties involved in a transaction (customer, supplier, manufacturer, etc within multiple supply-chain tiers to receive up-to-the minute synchronized transaction information relating to any and all facets of the transaction Information may be disseminated by push (Web broadcast) or pull methods, with a business user exercising information access control

In the case of a just-in-time product reseller, for example, the business software operates as follows A comprehensive product list is updated electronically in real time or at regular intervals from various sources (e g , by file download, over the Web, or from CD or floppy distributions or other media or even anual input) A graphical Web interface allows a user to obtain a quote based on the product list The quote is assigned a quote number and saved in the DBMS and may be retπeved and viewed at a later date Based on the quote, a user with appropπate Web-veπfiable authority may place an order on behalf of a company in accordance with a pre-existing Web-enforceable agreement with the company An employee of the seller, using the same DBMS, purchases product to fill the order When the product is received, information regarding receipt of the product is entered into the DBMS Orders are assembled, shipped and billed, all using the same DBMS Customers can retrieve previous quote records and view order and shipment status via the Web Customer invoices are automatically generated upon shipment but may be modified if necessary by a supervisory user having the requisite authonty When a customer payment is received, details concerning the payment are entered into the DBMS Vendor invoices and payments are also handled using the DBMS, and both customers and vendors can view payment status — invoice, credit (from retu^rns), etc — via the Web, allowing paper invoice copies to be dispensed with if desired Returns are provided for and may be return of an entire piece of equipment or replacement of a warranted component part, and replacements may be electronically tracked Parts tracking saves employee time that would otherwise be spent responding to customer inquiries, and also contributes to customer satisfaction through the convenient availability of timely information

Throughout the foregoing process, a period (e g , off-peak or nightly) update process is performed in which consistency checks are performed and in which accounting information (including sales tax information) is collected, journal entries made, and general-ledger entries posted When records are edited, they are flagged to be checked during the period update so that adjusting entries may be made if necessary At any time, the update process may be run and an accounting period closed Real-time, audit-ready financial information accurate up to the day or up to the hour is available within minutes at the touch of a button without the need for a highly-trained accountant A novice can facilitate the systematic performance of many functions typically performed by accountants, with periodic review and supervision by an accountant Because the DBMS is Web-enabled, given the appropπate privileges, a complete up-to-the-minute view of every aspect of a business is available from anywhere in the world Telecommuting is greatly facilitated, with its attendant cost savings Furthermore, factual evaluation of employee performance, whether of a telecommuting employee or an office-based employee, is greatly facilitated by statistical analysis of accumulated histoπcal performance data (tasks, projects, assignments, reports)

Driven by the goals of enabling widespread telecommuting and global cyberspace trading, the single database business process software provides parallel synchronized data access to all users Users have access to all information given the proper access authority The system provides built-in assurance of prioritized dynamic workflow and best business practice (the optimum known way that a business process should flow) based on self-correcting business knowledge algorithms The system draws upon a knowledge base to prevent mistakes anticipated by the software designer as well as mistakes that have occurred in the past and have been corrected for by adding to the knowledge base, which is continually accumulating The dynamic workflow assures that whatever mistakes mav occur are discovered at various stages The system lists and prioritizes uncompleted work that needs to be followed up All user activities are tracked, and users are held accountable Every activity performed by users are tracked statistically Problem sources may therefore be identified Precision training and factual performance review are made possible, significantly empowering users in their assignments

The software provides for business scalability (as opposed to mere data processing scalability), minimizing the growing pains experienced by rapidly growing companies In growing companies, as the responsibility for a process becomes divided among more and more people, becoming more and more diffuse, communication between group members becomes more and more difficult and the process becomes increasing difficult to manage The present invention witn dynamic workflow, makes workflow and work quality substantially immune to changes in the number of employees and the experience level of employees Work discipline and organization is enforced by, and teamwork and communication between users facilitated by, the database The ease of use of the database system arising from dynamic workflow and the knowledge base incorporated within the system minimizes the need for extensive employee training and allows for flexible employee roles Business scalability also entails dramatically increased productivity through automated computer assistance allowing business growth to greatly outstrip personnel growth One example of business scalability is in the area of purchasing Orders are grouped for purposes of purchasing such that the number of purchase orders to vendors does not increase as the number of orders received

Conceptually, the invention allows for the integration and time-scale compression of what have heretofore been largely independent, human-dependent business processes Business processes have typically been organized into separate business domains, chiefly including a products domain (e g , engineering, manufacturing, purchasing, shipping, receiving, returns), a payments domain (e g , accounts receivable, accounts payable) a financial Derformance domain (e g, general ledger, financial statements, tax returns) and a personnel domain (e g employee evaluation) In accordance with one aspect of the invention, files for the automation of these various business domains are integrated as part of a single database schema within a single database management svstem run on one or multiple servers There results a very tight integration of the foregoing activities and other derivatives of those activities such as product forecasting and cash-flow analysis In particular, a universal financial report and trend report generator pro- vides for general single or multiple General Ledger (GL) account code analysis including sales, cash flow and material

Time-scale compression of the resulting integrated business automation process is achieved in two ways First, the single database management system is Web-enabled, providing access anytime, anywhere Second, triggers within the single database management system propagate activity from one business domain to a succeeding business domain (e g , from shipping in the products domain to accounts payable in the payments domain) without duplication of human efforts Data can only be entered once and is not ordinarily allowed to be changed or re- entered Data entry is guided by a bi llt-in best-practice knowledge base

The integrated business automation process may be easily modularized if desired by restricting access to only files belonging to selected business domains Hence, unlike conventional business automation suites that provide separate software modules that may be acquired separately and linked together (with sustantial data duplication), in the case of the present integrated business automation process, a customer receives everything but may only pay for be given access to a subset of files — e g AP/AR files Later the customer may decide to pay for added capabilities Such a change in capabilities may be readily administered remotely through the Web In this manner, the customer is able to "pick and choose" the capabilities that the customer wants to use

An outside Web user may also pick and choose the capabilities that the user wants to use For example, orders may be placed by phone or fax but tracked via the Web Or a user may use the Web only to check the amount owed on open invoices Others user may use the Web from start to finish, to order products, track orders, track payments, etc

Extensive measures are taken to ensure that the integrated business process is, to the greatest extent possible, error-free Only a limited number of controlled entry points to the system are provided At each entry point, entry validation is performed at the time of entry Because the business process is integrated, \ a dation may be more extensive and hence more effective than in typical systems A periodic update process is also performed is which checks are made, including cross- checks between records of files belonging to different business domains The system is in effect a closed system where all entries must balance appropriately The nightly update is able to catch and flag errors (or possible errors) that may have occurred despite entry validation, including hardware or system errors, software bugs, and human errors As errors become apparent that have escaped detection by the system, the foregoing mechanisms may be readily revised to prevent future such occurrences Programmed process intelligence therefore continually increases as errors are detected, flagged, and trouble-shoo.ed so as to add to the wealth of the knowledge base and improve the process methodology At the same time, dynamic workflow makes possible the re-navigation of existing workflow components

The integrated processes also automates returns and credits both on the customer side and the vendor side Returns and credits mav be necessitated by user errors that go undetected by the system, by overcharges for freight, or numerous other circumstances Returns are only one important example of what is more generally a reversal process, or catch-all, for mistakes during work-in-progress and for post-sale activity Return requests, Return Merchandise Authorizations credit memos and accounting adjustments may all be handled electronically

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-busi- ness 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 o* a screen display allowing the user to search for products by manufacture*-,

Figure 1 1 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

,

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 displav

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 displav 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 displav 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 displav

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 showing 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 displav

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 displav

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 1 10 is an illustration of a screen display used for trend report definition, Figure 1 1 1 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 H 3 is an illustration of a trend report graph screen display,

Figure 1 14 is a block diagram of a human resource infrastructure for a virtual organization performance evaluation model,

Figure 1 15 is an illustration showing in greater detail portions of the human resource infrastructure of Figure 1 14,

Figure 1 16 is an illustration of a file structure used to track all performance metrics of interest,

Figure 1 17 is an illustration showing in greater detail the Factual Measurement Review process of Figure 1 15,

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

Figure 1 19 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 displav of Figure 1 19,

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 tvpe as that of Figure 121,

Figure 124 is a partial illustration of a pop-up menu of options a ailable 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, and

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

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 repre-

SUBST1TUTE SHEET (RULE 26) sented bv 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 avadable

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 c cle repeats Meanwhile, users suffer Furthermore, because different users hav e 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 dav-to-dav real-world needs

In the present system, navigation of the workflow is soley determined byt he 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, Pur- cnasing, 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 lim- ited 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 duπng 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 — hich 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, 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 generically herein to refer to items sold and mav 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 vinous 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 directlv 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 anv 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 pnnter 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 ιt_.m 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 1 1 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 1 1 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 svstem 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 mav 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 mav also return to the last search results of the Products List

PEDs 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, pnce 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 bv 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 mε_^ je 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 of this information, the user may search for sales orders by manufacturer, part number, and/or date range Figure 31, for example, shows the result of searching 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 vanous 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 gener- ating 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 dunng 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 m?y 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 likhhood 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 likhhood of quotes being converted to orders The communication may be Web-based and may, for example, take the form a promotional offer As mav 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 unsophisticated user, any of various bits or pieces of information may be used to retneve 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 0 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 busiήess-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 fashion. 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 authonty

External Web authonty 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 pnce 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 varv 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 secunty 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 authonty 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 customers 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 p-esent system is that a single data^base, oescnbed 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

Base Table (Options)

Ven Pmnt Regs Quick invoice lookup Quick credit lookup

Get register

Get not approved

Get approved ^'„ at not paid

Approve Disapprove

Change payment date

Pay

Get regs with credit balances Vendors with credit balances

Close register Open register

VenCollection Quick memo lookup

Quick invoice lookup

Quick payment register lookup

Get not used

Get excess/not distributed

Get distributions

Get expected memos Reconcile expected memo

Get not pre-approved Pre-approve

Get pre-approved Approve

Get approved Schedule

Reset status back 1

Cancel credit memo

VenMultiCred 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 Proces — 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 Purchasmg/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 lnforma-

SUBST1TUTE SHEET (RULE 26) tion directly from a user, 1 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 — 1 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 con)unctιon 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 Tne RMA module communicates with the GL module so that appropnate 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, oruers are each assigned a MWS numb' r 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 svstem prompts the user at ever/ 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 bv the "Go Prod" button The Products file is then displayed, as shown in Figure 62 The Products file mav 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 offenng 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 w henever the quote or MWS is displayed If a quote is created on the Web, a separat ¹ 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 concerted 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 occurnng

PRIS (Purchasing, Receh ing, 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 tht 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 . nd 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 displav/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 I e 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) ma¹ 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 displav Undes- lred inventory is therefore avoided Otherwise, an item might be ordered and received onlv 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 vVeb Orders may either be placed directly or posted for bid by interested vendors Furthermore, in accoi dance 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 svstem marks the ordered items as ready to receiving, 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 svstem that ensure accountability

Business rules implemented by the purchasing process include the follow¬

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 use-* 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 displav 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 svstem 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, namelv 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 mav 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 shippn g, notes conveying instructions regardi g specific items may be displayed by double-clicking an item to cr.use 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 displavs, 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), Lpπce/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 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, buraing-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 displayed 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 bv 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 displav 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 kMAs 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 virtual inventory model (RMAs eliminate, or at least minimize, the hazard of accumulating obsolete inventory as a result of returns ) In an exemplary embodiment, a senes 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 ic 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 communicated 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 "ancel 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 pnnter 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-nch 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 of this design philosophy are found in the options described previously (Table 1 and Figure 124 through Figure 128) and the expenential constraints alluded to previously and descnbed in greater detail hereinafter Referring to Figure 129, a knowledge base is initially created based on svstem 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 svstem anal- sis 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 svstem 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 "endor 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 pnnt 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, 1 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 mav 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 Refernng 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 entnes 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, l 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 * "parent 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 nanels 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 information 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 assunng a stable cash flow

A vendor invoice screen display is shown in Figure 89 When vendor 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, l 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, rrior 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 entrv 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 vanous 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 sum- manes) Furthermore, the items may be single items or groups of items (e g , master worksheets)

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

The items may be customer invoices and the business task mav 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 mav 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

Nightl or Periodic Sjstem 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

General Ledger and Real-time Financiais

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 onlv 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 appeanng on the financial statements is gathered in an account An account exist for each asset, liability, revenue, expense and category of owner s equitv of a company More particularly, the classic accounting process involves the following steps

1 Analyzing business and financial transaction to determine if thev 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 entnes 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 lournal, or general ledger (GL) The process of transferring the information from the journal entry to the accounts is cal'ed 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 mav be required to assure that revenues are reported in the period thev 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 sys- tem, 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 GAAP format Furthermore, instead of a limi ^ed 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 entrv 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 (1 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 Whereas 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 incr^ease 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 )ournal 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 Figure 100 results in a disp'ay such as that of Figure 101 The date of each transaction contributing to the balance is shown, togetner 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 displav 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 displav 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, 1 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, mav be a trend analysis report Trend analysis provides a powerful tool for understanding interrelationships between various aspects of a business Referring to Figure 1 10, 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 4\ 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 1 1 1 , a trend frequency is then selected In the example of Figure 1 1 1, the trend frequencv has been set to daily The trend analysis is then run and the raw data displayed as shown in Figure 1 12 Referring to Figure 1 13, 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 penod, 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 la^rge, present-day wo'-k 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 mav 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 1 14, 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 categones 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 bv 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 1 15, 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 process) 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-onented 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 mav be accurately derived

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

Referring to Figure 1 16 e aluation of human performance is made possible by collecting an assemblage of activity data to which analvsis 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 expenence with the system is gained) RMAs affect all assignments and are therefore tracked in relation to each assignment For example, quotes made during a penod 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 1 17, for each individual employee to be evaluated, vanous 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 bv 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 Measunng Algonthm 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 "^rl ort list" of departments for performance review Different layers of management, for example, mav 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 narrowlv 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 1 18, Figure 1 19 and Figure 120, respectively Selection of an employee is accomplished as illustrated in Figure 1 18 Refernng to Figure 1 19, 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, performance results for various performance metrics in different categones 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 tim ness (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 Lo -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 svstem 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, installation 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 s a result of this first-level percolation, certain orders mav 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- abhty, 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 leseller 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 onlv 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 m 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- mstallation, 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-mateπal 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 coi responding 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 (1 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 delav In the case of channel assembly, when component parts are received, they are assembled into items for shipment to the customer

There lesults 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 Unn ersal 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 mformation-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 Lniveral Business Engagement Rules ')

In a preferred embodiment, WUBER not only provides for the specification of business engagement rules, WUBER also provides for the enfoi cement 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 earner

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 wntten 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 Wrthin 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 displav 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 mav 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 (usually 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 ma farther 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 mav 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, v anous 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 deli ery 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 pnvate 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 corresponding 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 descnption. 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 descnbed 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 vou on that " "Getting back to you" will usually take days and may even take weeks, or may simply not happen at all Current 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

Referring 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 mav 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 \ forecast can also be compiled based not only on current 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 mav 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 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 o^f 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 Svstems

In contrast with known workflow systems the present svstem, sometimes referred 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 bv 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 svstems, the background of conventional workflow svstems will be briefly descnbed

Arguably the origins of workflow are as ancient as the origins of industry In modern 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 of this dvnamic 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 is capable of enforcing GAAP and APICS standards in accounting and manufacturing But wherever possible the ICE system gι\ es the user a choice even as it automates routine procedures And when it comes to exception handling, the Dynamic Workflow environment in the ICE svstem 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 pi operly 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 t^^α 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 thev were designed for This is because in conventional application svstems 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-apphcations that are built from components at a coarser level of granulanty 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-app cation 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, anv changes made by one method to the "solid-state" database, are simultaneously, instantaneously, and synchronously virtually "posted" to all other methods, in the ICE svstem

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 anv 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 apphcation-to-apphcation 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 svstem has the option of invoking whatever necessary relevant application is required, with the assurance that data integrity, data consistency, and in most cases, business rules 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 of this "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 rules 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 authonty

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 svstem often requiπng 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 procedures 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 applica- tion 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 npple 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 jsiness 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 integnty and consistency rules

In practice much of the work of creating workflows in standard workflow environments consists of analyzing and controlling npple 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 kevs 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 corresponding 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 svstem 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 aophcation 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 rules are enforced bv 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 rules Business rules are guided (not enforced) by a combination of application logic and workflow

ICE can be and is coded to enforce certain business rules 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 anv 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 svstem 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 definec 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 svstem 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 svstem typically cannot make anv changes to the data that thev access through the manually invoked applications, without potentially violating one or more business rules In anv 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 modern graphical 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 sys- . tems. The rest of the table lists some of the consequences and spinoffs of this architecture

111

112

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 essen tial 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: MegaNetworkNightly report (12/18/98 10:45 PM)

Sent: 12/19 6:39 AM

Received: 12/18 10:44 PM

From: MeαaNiαhtlv@meαanetwork.com

To: charles ® meaanetwork.com john @ meaanetwork.com kennv @ meaanetwork.com kirn @ meaanetwork.com wendv® meaanetwork.com won ©meaanetwork.com

No reminders today

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 OF 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

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 fuond.

The following RMAs have been received from custome-s 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 the last 30 days that need replacement MWS attention.

All customer invoices that have been printed have been issued.

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

^* 17803 Customer UNION BANK OF CALIFORNIA 12/8/98 Paid 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

M 98-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 @ meαanetwork com Structure for Mega3.5.4

Structure for Mega3.5.4

Structure for Mega354

Structure for Mega3.5.4

Structure for Mega3.5.4

venRetFlt Dtl

Fault

Fault Detail sort

venRetFault

Fault _sort

_AutoGen_code Claim

Claims

_ClalmSeq L

_RMASeq L

ClalmNo A

Against A

Contact A

Phone A

Fax A

Address T

CaseNo A

TrackingNo A

AmountClaimeα R

A ountRcvα R

Closed B

ClaimDate D

Structure for Mega3.5.4

Structure for Mega3.5.4

_EmployPurch qMemoryL

CustSeq Svstems_^l

EmployeeName MemoryUC

_UnlquelD _ EmployeβS io To Contact_F

BIIIToSeq EmplyeeUnique _NextOSo

'rodSoecs EmployeeNumber ShlpToSeq _NextMSc artNum ShlpToSeq Purcn_Coι irtNum AuthPurchaser Backup N< )_Spec PurchaseLimit SalesSui ation UserPassword SupComm g LastWebAct TotalComr acturer First Name TolalSupC

Last Name Receivei

PassWordChanged _ShipCI>rg

Requester _Z.pCodθ

EndUser _qUPSSp(

Telephone qMandling

Fax _-reιqtCo:

PictSrjecs Email rrgtlnsure

AcctAuthoπzed Freιghi_S|

Specs

RMAAuthonzed No_Paπιal

CompPPLAccess Handlιng_l

PersPPLAulh _UPSSpe<

PIDAccess Shιp_hndl MWS_Ty _CostAdjT ShipComπ _trtToDatι Paπiallnst

_ShιpGroups CostAdius

MWS_Seq L _Allocat

Group A qlnstall_C

IDSeq L ιnsιall_Co

Rcvd B Cancel Ie Ordered¹ Custorr Urgent "PostedTi i S h i p p e _i ' lcancel_R< Keywords _RMATem BackOrd _ATSLor PID

RMA_Nu ManualCo FriCoslTol Invoiced POCustCc Temporary PurchCh _SRSeq GrossMa Creator ShlpHo

RhinHnlriR Structure for Mega3.5.4

Structure for Mega3.5.4

Structure for Mega3 5 4

Structure for Mega3.5.4

cusBuyerFAX_x cusUserName_x cusUserTel_x cusUserFAX_x

AplyToPayDate_x venCrdVouchNo_ venCallTagNo_x

NotResellable_x cusRstkPerc_x venRstkPerc_x cusCallTag_x ltemDescπp_x

VenNA

_ReplSeq_x

ExpectedCredit

FaxedToCust

VendorCosts

CustCredTodate

CredltRMA_Rcvd

_NextCustCredSq

VenRMAShpd

Keywords

CustCredStatus

Custlnvoice

CustlnvoiceAmnt

.Updated

ReplReleased

Keywords

CrossShip

Word

VenCrβC-Zero

CusRcvDateNA

VenShlpDateNA

VenRcvDateNA

CusShlpDateNA

KeyComment

Printed

CredNotExpected

CredDifReason

VenProposedCred

PropCredDifReas

VenFrtCredNum

VendorFrtCrβdit

CustCallTagReq

VenPackingSlip

DateApproved

OpenCustNotes

WebRMA

Weblnltlator

WebNotes

DeleteMe

WebLocked Structure for Mega3.5.4

Structure for Mega3.5 4

Structure for Mega3.5.4

Structure for Mega3.5.4

Structure for Mega3.5.4

Structure for Mega3.5.4

OtherType DlscountReg B

MemoNumber

Approved DiscounlTotal R

Amount

Cancelled Vendor A

MemoDate

ReieasedAmount Payee A

3rd A RcvdDate

Payee Cancelled B

CredltType

MultllnvSeq PrePaymentReg B

Payee

PreApproved ReceiptsReg B

UnReconciledAmt

Scheduled Collectiontotal R

_Sequence

CredilToCost VeπDebitArrays P

Reconciled

MultiCreditSort Closed B

Vendor

Receipts GL-EntrylD L

_LastReclD

ManualReconcile Disbursements

Cancelled

AutoRecRMA

_UniqueKey

CreditLeft

OtherType

CashRcvdSeq

EntryDate

PaymentReg

CreditToCost

ChkDbReconciied

Receipts

TotalChkChgs

DistribCount

ChckCharges

_APRegSeq

GLEntrylD

AP_Reqιsters

DeposltSeq

Register harqes CheckBanklD DepositDate InvoiceTotal

_n A

InvoiceCount

R DepositTi e

CreditTotal

DepositBankSeq

CreditCount

APSubLSeq CheckMe Posted GLPostedAmnt PeiodStart

PeriodEnd

GLPostState ResetLog PostDate

Locked Comments

NβtTotal

RegDate

ReglsterType

Structure for Mega3.5.4

Structure for Mega3.5.4

_πActsCustAsq

Account

Description

CustomerSeq

ShortStock

MfgPartNum

Stock

SSDate

MegaWaitmg

Structure tor Mega3.5.4

Structure for Mega3.5.4

Details

_ShiDlDBoxLιnl<

ShipSeq

IDSeq

BoxSeq

Shιp_ID_Key

DSSeq

_RcvlDBoxLιnk InvolceNum

RcvSeq RMANum

ISeq IDSeq RMACus1Ven2 eq BoxSeq RMAIDSeq

RcvJD_Key Freight

PackingSllp _ARSubLSeq.lnv

From

Receivinq

RMACus1Ven2

RMAIDSeq _Sequence L

PackSllpStrlpd RcvdDate D

_ARSubLSeq_lnv Carrier A

Tracking No A

No Posted B 5eq Rcvd Boxes Shipment From A

-Sequence L Weight R

From A BoxCount I

Trackιng_No1 A PalletCount I

Trackιng_No2 A HundredWl

ItemslnBoxCount i ShipSeq

Pallet I PlckUpNum

_Seq Box I FrtCharge

Overpack B

DeclaredValue

InsuranceChrg

Total

VenlnvSeq xxx Structure for Mega3.5.4

Structure for Mega3.5.4

RMA

CredltMemo

CheckCredϋnk

CMVoucher

ChildSeq CreditAmnt

Pa re nt Seq Claim

ChileDistrAmnt Paid_ ToDate

ChildNumber PayScheduled

ParentNumber EntryDate

ParentA ount PrePaid

PareπtDescπpto RecDate

ChildDescriptor PreApproved

ApprDate

PaidDAte

LastPayDate

Closed

ClosedDate

Disbursements

Hold

_8ankActSeq L

HoldDate

Ref CheckNum A

VenRMANum

Amount R

DiscPercent

Payee A

VenStatus

ChβckDaie D

LastRcvDate

Payable To T

MWS

Verified B

Pay βntRβgs

_ChckRegSeq L

LastPayment

_SplιtPayNum 1

LastRelerence

QuickCheck B

DiscountsTaken

OCPayee A

DiscountsLost

OCPayableTo A

DiscountAvail

DiscountDale

D ueDate

Custlnvoices

VerilyStatus

VouchersSub

VouchersSub TempNotes

MegaVoucherNo A DropShip Payment Date D UnderBilled

Payment R RecurrlngExp

ReadyToRevlew

Reviewed

ReviθwθdBy

ReviθwDate

ReviθwStatus

Tracking

Tracking Notes

AllernatePS

InvNoStrlpd

FrelghtBIII

_APReglβter

APSubLSeq nv

GL_APseq

_GLVenlnv_Splιl GL_NatSeq City_District

Venln vSequence GL_TaxSeq

G L_AccountSeq C ity A

GL_FrtSeq

Debit TaxRate R

,GL_MιscSeq

Credit SpecialZip A

GLJntSβq All-Cities B Structure for Mega3.5.4

Structure for Mega3.5.4

Structure for Mega3 5 4

Structure for Mega3.5.4

Structure for Mega3.5.4

Cusijnvoiceε

InvoiceNum

IπvoiceDate

Customer

InvoiceType

MWSNum

SalesMan

ShipVia

Terms

Sale Amount

Misc Charges

Freight

Tax

Installation

Credits

Total

DropShipments Issued

I DSSeq CustomerPO

'To TaxRate

|Tracking_No1 A CustComments iMWSNum A InternalCommen:

I Freight R Keywords

(Invoice L PaidlnFull

IHemCount CostAdiusl

'DropShipDate Cosl

ShipDockel

CommissionRl

Commission

SalesSupRep

SupCommRate

Shippmq SupCom ission

Ship Tracking

.Sequence L FreighiCosl

.Sequence L

ShlpDate D TtlCost

To A

Carrier A TtlPπce

Trackiπg.No 1 A

PickupNumber A CustomerSeq

Trackιng_No2 A

Posted B AR_Bal_Posted emslnBoxCount I

Shipment To A EDI

Pallet I

Shipment Weight R EDIQty

Box A

Shipment Value R RMAHistory

ComputedWeight R

Actual Weight B .NextCrdMemoSeq Actual Weight R

Wgt Calculated R RMATtl FreightPaid R

Wgt Actual R BIIITθ-Seq Insurance R

MnfTtlGrsChroe R T PayStatus Structure for Mega3.5.4

Structure for Moga3.5.4

Structure for Mega3.5.4

: axes GLPst Tax R junty.Descπp BadDebt R

GLPst Frt R

ResoldlntUse R ly.District GLPst Labor R

Returnedltems R ixRate GLPst Msc R lectiveDate Discounts R

GLCheckMe B

Freight R

_de GLPoslSlate 1

OutOfStatTxPaid R

'ate .GLPst.ARSeq L

PrePayRβgister L

^■c ial.Zips .GL.ARSeq L

Adjustment B

.pirationDate .GLPst.SalesSeq L

Paid B i.Counties .GL.SaiesSeq L

OutolState R

)mments .GLPst.TaxSeq L

WillCall B

.GL.TaxSeq L

PnceCredit R

CountyTaxes .GLPst. FrtSeq L

FreightCredit R

SalesTaxSeq L .GL.FrtSeq L

LaborCredit R

County A .GLPst. LaborSeq L

OutOfStateAdi R

CountyTaxabfeTl R .GL.LaborSeq L

TaxCredit R

CntyDescrlption A .GLPst. scSeq L

GovernmentAdius R

CityDescrlption A .GL.MscSeq L

ResalθAd|ust R

DlstrSequence L

FoodAd|ust R

NonTaxableTtls R

Hold B

Creditslssue R

Cancelled B

NotTxbleCreds R

.Sequence L

CountyTax R

TotalCountyTax R

IntUseTrans B

TaxReqisler

Register Financiais

Prepayment .Sequence

StartPeriod Report.Name Fina

EndPeπod StartDate .Se.

Paid Row^'

EndDate

PaidDate ColumnCount Rθw<

State Row

Portrait

Comments ColDefunitions ActB

AmountDue DefFont vPeriodStart DefFontSize

LastUpdate DelFontSTvle

DueDate ColDelnntions

ProcName Fin

.RegText Column TrendReport Col

.StoredSets Width Typ

AternateCalc Header Con

Pay entMade UseHβader Bat,

Version Bal.

GLEntrylD Cal Can Cell

Links Cel

Oiscriptors CelllD A Cell

Version SourceCelllD A Cell LmeNotes Value A Bal; QRInstr ValueSet B

SrcFmName A

FinName A Structure for Mega3.5.4

I I

Structure for Mega3.5.4

Structure f or Mega3.5.4

LastUpdate 1

FLDebug B

VlnvRecCheckOff B

BULoglntTicks L

RβmoteUpdatθOn B

4DBackupOn B

4DBULocatιon T

MidDayBUTime H

PrsMmSize L

PrsStdSize L

PrsOptSize L

PrsMaxSize L

VenVerSets P

DailyVenVarOff B

VendorArraysOk B

AutoConvMonOn B

Monitorlnterval L

VendorLock B

MldDayLag 1

WrngPrd.Lead A

DefProd.lead A

DefParts.Lead A

ShippmgUser A

SuppliesCust A

InternalUseCust A

InventoryCusl A

ScheduledCust A

DefSchβdLead A

ExpNotOrdArrays P

ExpNotRcvArrays P

ExpNotShpArrays P

ExpDφShpArrays P

CollectionBndl P

ReplSalesRep A

PreLaunchPrs B

CostAdi R

CredCardCostAd| R

RMAFaxText T

VenlnvVer2 P

VenlnvPaidOff B

HTMLTextblob P

SaleTaxModuleON B

MWSFaxON B

MWSFaxNum A

MWSEmail T

Com EMail T

EMailToDesigner B

DesignerEmail A

SRLockOn B

APRegOn B

ARRegOn B

LastlntCheckSeq L

O hanMFGs P

FlushCount L

ImportScπpts •

4DHTMLPath T ImportScπpts Structure for Mega3.5.4

Structure for Mega3.5.4

LastCoreMWSSeq L

OnSiteServDef R CustPav enis

GL.Rebatβ.Def L Check.Ref

GL.Divid.Def L RcptCredDate

ScreenPWNotRβq B PayAmount

LogmCopyRight T InternalNotes

CheckingOn B Customer Entry.Dale Type.

-CustPavDistr TotalDisbursec .Sequence

InvoiceNum L PayBalance

DistDate D ReconToCash

Amount R CredDebitlssueo

Reference L InvTotalDisb

InvNotUpdated B CMTotalOiso

.DetlD L Reconciled .DetUnique A Posted

.ARSubLSeq L CreatedBy

GL.PstAmnt R Approved xxxxxx T AR.Voucher

_^xxxxxxx T

.CustPayDetals Approved.Dale

_xxxxxxxx T

Seq Post.Date

Type. .CustomerSeq

StubAmount .LastOetlD

Reconciled StubDistrAleπ

StubRef .DepositSeq

AppliedAmnt .ARRegister

AppliedRef PoslBalance

.DβtaillD StubBalance

.DetUnique GLEntrylD

Relatedlnv GL.CashAct.Seq

CuslCredDist ReconToCash GL.CheckME

MemoNumber IssuedCrβdDeb GL.PstAmnt

DistDate _ARSubLSeq_.CC .NewGLMelh

Amount GLEntrylD.Log

Reference CheckBanklD

CMNotUpdated DepositDate

.DetlD DepositTime

.DetUnique DepositBankSeq

Issue

.ARSubLSeq

GL.PstAmnt

CollectionProbs

Probs Resolved

ContactLoq

ContactType CurrentDate

Comments .current time ActivityDatθ Structure for Mega3.5.4

CollectionTickl

Tickler Action Date Coments

Keywords

AR. Registers

Register lnv.Check.Ttl

Inv.Check.Count

Cred.Distr.Ttl

Credit.Count AP SubLθdoer

Posted GL.EntryRef

PeriodStart Entry.Date

PenodEnd Partner. Code

PostDate Journal.Entry

Comments Debit

Net.Excess.Tll Credit

RegDate PaπnerBalance

ReglsterType Agιng_30

Agιng.60

Aging.90

Invoice. Num

.Sequence

Aging.0

FinanceCodes

FinancialCode Decscπption

ChartOfAccnts AR SubLedαer

Aecount.Code GL.EntryRef

Account Entry.Date

Account.type Customer. Seq

Debit.Account Journal. Entn,

COASeq Debit

Balance Credit

ContraRθlActSeq CustomerBalance

ContraAct Agιng_30

FinancialCode Aging.60

BankAcct Agιng_90

CreditCardAcct Invoice.Num

.BeginnmgBal .Sequence

.GLOpened CredltMemo

.GLLIne

COARelatedlndx Agmg.O

COASeq Gen Journal IndexName CashRecots Re Structure for Mega3.5.4 ijL.tntryHet

IndexFieldNum L Entry.Date D FullyDeposited

ProcName A .COASeq L .GL.LIne

DisplayFldNumt L Journal. Entry A Amount

DisplayFldNamel A Debit R BankSeq

DιsplayFldNum2 L Credit R Remainiπα

DιsplayFldName2 A DistrAcctBalanc R

DιsplayFidNum3 L JournalEntry B

DιsplayFldName3 A Sort L .CashDιsb_Req

DιsplayFldNum4 L BalAfterClose R

DιsplayFldName4 A .Sequence

DιsplayFldNum5 L FullyDlsbursed

DisplayFldNameS A .GL.Line

Sort 1 Amount

IndexFileNum L BankSeq

Remaining

FmancialRo s cialSeq

quence

Type

;OAS alCol

RowCOAs

COASeq L

_F.nancιaιCeils CelHD A GLBackup ancialRo Seq ARSβq L GIEntrylD

APPartCode A Event

TransAmnt tenls Balance iπceDate APReg.Seq iπce ARReg.Seq clD BankReg.Seq

-Assignments Cust_lnv.CC.Seq

Styiθ Ven.CrdC.Seq

IID COA.Seq

Font CuslPay ent.Seq

FontSize VenPayment.Seq inceTyøe ItemDelail.Seq

Custlnv.Seq

Veπlnv.Seq

MalnKey.Seq Structure for Mega3.5.4

CaicAssiαnments

CalclD ulip er

Structure for Mega3.54

Structure for Mβga3.5.4 u i soiαM i u

Sequences

PnceMTD R FileAdmin Seque n c e 1

PπceYTD R

Name A NextNumber L

MaxPriceYTD R

Procedure T SequenceName A

MinPnceYTD R

AdminFile A ReuseMe

AvαPnceYTD R

Info T

OtySoldYTD 1 _r

Warn B

LastSaleDate D

Parent A

CurrentMoπth 1

Folder B

CurrentYear 1

Access. A

QtylnStock 1

StockAvail 1

Structure for Mega3.5 4

Structure for Mega3.5.4

OverUnderPay

Customer A

Amount R

Reason T

.PaymentSeq L

ToCash R

CredDeblssued R

Closed B

AmountFrmCPmnt R

BadDebt R

GLEntrylD. og

GLEntrylD

Structure for Mega3.5.4

Structure for Mega3.5.4

Structure for Mega3.5.4 u π u m υ n i q u e _ιvιn_.πaμdCϋ_:

Balance R _MICRSpace3 1

DepositAmnt R UsePictCheck B

TransactionTime H AmuntCharPad A

DepositDate D Sig . line A

DepositTime H DepLogo T

DepVerifyDate D _Pos4 A

DepVenfyTime H _Pos4Type 1

PayableTo T _P0S4Lβad A

Ca sh RecptSeq L _Pos4Traιl A

Ca s hDisbSeq L _Pos5 A

_Pos5Type 1

_Pos5Lead A

_Pos5Traιl A

_MICRSpace4 1

_MICRSpace5 1

NextDepNum L

DepNu LeadOs 1

PπntDepHor B

Structure f or Mega3.5.4

Letters

A

T

A e R

T

^:ont A

5ιze R

T ont A

R

.tPage B

1

Style 1

1

Mignmeni A iignment A ignmen; A

A

P

Structure for Mega3.5.4

ReuseMe

NexiNumDer

Structure for Mega3.5.4

GLBankRq.Split

BankRegSequence L

GL.AccountSeq L

Debit R

Credit R

Son. 1

ActType A

GL.Account A

Editable B

CashRcptSeq L

Explanation A

CashDisbSeq L

Claims

What is claimed is

1 A method of business-to-business transaction processing using a database and a database management system comprising receiving user demand information electronically at least partially in response to reiving the user demand information electronically, automatically storing an order record in the database and maintaining the order record in the database throughout a life cycle of the order, and during the life cycle of the order multiple users each accessing the order record and processing the order to accomplish a respective one of multiple business functions and creating records related to the order

2 The method of Claim 1 wherein the life cycle of the order includes an expected period for at least one of reversal service and pans order

3 The method of Claim 2 wherein reversal includes customer returns and correction of improperly fulfilled or mistaken orders

4 The method of Claim 1 or Claim 2 or Claim 3 further comprising providing within the database management sv stem at least one ot a table switch function and a related table switch function wherein the table switch function enables a user to treelv v leu records of any of various tables except as otherwise prohibited

access authority defined by a supervisory user the related table switch function enables a user to f reels view records of any of various tables related to a selected record except as otherwise prohibited by access authority defined by a supervisory user 5 The method of Claim 4, wherein the related sw itch function is used to display information to a user via the Web

6 The method of any of the preceding claims further comprising defining automated workflow processes for a plurality of business function using the database and the database management system, wherein the workflow processes constrain user inputs and actions but allow use of at least one of the table switch function and the related table switch function

7 The method of Claim 6, further comprising allowing a user w ith proper authority to access all tables containing transaction-relevant information

8 The method of any of the preceding claims further comprising pro- v iding a central table supporting multiple business functions w herebs changes made by one user performing one business function can be \ lewed immediateK thereafter by other users performing other business functions

The method of Claim 8 wherein the central table is an item detail table

10 The method of Claim 8, further comprising users, in response to business events entering information af fecting financials into the database, and posting general ledger entries in the database such that latencs between entry of said information and posting of a corresponding general ledger entry is either negligible or not greater than a predetermined small time period 1 1 The method of Claim 10, wherein the predetermined small time period is one day, allowing for the preparation of substantially real-time financial reports

12 The method of any of the preceding claims, further comprising processing information stored within the database to provide functionality within a majority of the following categories enterprise resource planning, sales force automation, supply chain management, purchasing automation and electronic commerce

13 The method of any of the preceding claims, further comprising in response to receiving the user demand information electronically, automatically storing a quote record in the database receiving further user demand information electronical U in response to receiving the further user demand i nformation electronically, automatically converting a quote record to an order record

14 The method of anv of the preceding claims w herein the database management system is Web-enabled, and at least one of said user demand information and said further user demand information is received \ id the V\ eb

1 5 The method of any of the preceding claims, further comprising a user retrieving a quote record that has not yet been convened into an order record modifying the quote record, and updating the quote record

16 The method of any of the preceding claims, further comprising a user retrieving an order or quote record duplicating the order record as a quote record, modifying the quote record, and saving the quote record as a new quote record 17 The method of any of the preceding claims further comprising allowing a supervisor to view quotes created by subordinates of that supervisor

1 8 The method of any of the preceding claims further comprising, for each of a plui ality of users, storing within the database management svstem a plurality of favorite quotes of that user for ready duplication

19 The method of Claim 1 8, further comprising allowing a user to change that user's favorite quotes and effecting the changes on-the-fl\ in real tune

20 The method of any of the preceding claims further comprising eliciting user demand information by displaying to a user products approved for purchase by that user

2 1 The method of any of the preceding claims, further comprising el iciting user demand information by displaying to a user a summary of products frequently purchased or recently purchased by that user

22 The method of any of the preceding claims w herein the user demand information includes at least one of installation instructions and shipping instructions

23 The method of Claim 22, further comprising automatical enforcing dependencies based on at least one of ship group and installation group

24 The method of any of the preceding claims f urther comprising automatically identifying quote records less likely to be converted into order records, and communicating with users so as to increase the likhhood of the quote records being converted into order records 25 The method of Claim 24, wherein communicating with users comprises automatically communicating with users via the Web

26 The method of Claim 25, further comprising automatically communicating a promotional offer

27 The method of any of the preceding claims, further comprising processing via the Web a post-sale transaction relating to a product previously sold, comprising the steps of a user communicating a request via the Web, causing a related record related to an existing order record to be stored, and processing the request using an automated workflow process

28 The method of Claim 27, wherein the post-sale transaction is one of the following return, service, and parts order

29 The method of any of the preceding claims, wherein the existence of an open return request is automatically taken into account within a plurality of workflow processes

30 The method of any of the preceding claims, further comprising automatically approving a return request in accordance with stored criteria and communicating approval to a user electronically

3 1 The method of Claim 30, wherein the stored criteria are modified by a user having authority to do so

32 The method of any of the previous claims, further comprising electronically communicating status information to a user 33 The method of Claim 32, wherein the status information pertains to an order

34 The method of Claim 32, wherein the status information is com.ru nicated upon receiving an electronic request at the time of request

35 The method of Claim 32, wherein the status information is communicated upon the occurrence of a status change based upon a previous request

36 The method of Claim 32, wherein the status information pertains to a post-sale transaction request

37 The method of Claim 32 wherein the status information is detailed status information concerning payment or non-payment

38 The method of any of the preceding claims further comprising automatically classifying records of a given type into multiple classifications for workflow processing, one or more users interacting with the relational database s\ stem to take a prescribed action with respect to multiple records

ing a particular classification

39 The method of Claim 38 wherein the records of a giv en t\ pe are classified into multiple classifications based on experiential criteria

40 The method of Claim 38, wherein a record mav belong to a plurality of categories, the method further comprising sorting records in accordance with a hierarchy of categories such that a record belong to both a categon, higher in the hierarchy and a category lower in the hierarchy is sorted into a group of records belonging to the higher category 4 1 The method of Claim 40, further comprising a user rearranging classifications within a hierarchy to effect a business purpose

42 The method of Claim 38, further comprising the relational database system not allowing the one or more users to take at least some actions other than the prescribed action with respect to the records.

43 The method of Claim 42, further comprising a user with requisite authority to take an action not allowed for other users not having the requisite authority

44. The method of Claim 38, further comprising a user interacting with the relational database system to change information within a record; and automatically reclassifying the record

45 The method of any one of Claims 26-35 wherein the records of a given type are of one of the following types customer invoices, v endor inv oices, item sold and return merchandise authorization requests

46 The method of Claim 45, further comprising classifying item sold records, forming a group of particular item sold records, and creating a vendor order including a vendor order item corresponding to the group of particular item sold records and representing one or more units

47 The method of Claim 46, wherein forming a group comprises grouping and regrouping item sold records as many times as desired 48 The method of Claim 46, wherein each vendor order item is related to at least one item sold record created in response to receiving directly from a user user demand information

49 The method of Claim 48, wherein an item sold record represents one or more units, and an item detail record related to the item sold record is cre

50 The method of Claim 49, further comprising receiving one or more units of a vendor order item, and for each unit, changing an item detail record to indicate receipt of that unit

5 1 The method of Claim 50, further comprising phvsicallv manipulating a unit in accordance with a workflow process defined within the database and changing an item detail record of the unit to reflect the physical manipulation

52 The method of Claim 5 1 wherein physically manipulating the unit comprises installing the unit within a larger assembly

53 The method of anv of Claims 26-43 wherein classif v ing comprises identifying critical path items for fulfilling an order

54 The method of any of Claims 26-44 wherein classify ing is performed on the basis of at least a plurality of the following item, availability, installation instructions, and shipping instructions

55 The method of any of C'aims 26-45 further comprising breaking down items into multiple tiers, each successive tier including component pans for items of a previous tier, and creating a record for each component part 56 The method of Claim 55, wherein classifying is performed on the basis of availability within multiple tiers

57 The method of Claim 56, wherein availability information within multiple tiers is obtained via the Web

58 The method of Claim 56, further comprising communicating availability information to a customer and, if the customer desires, changing at least one of installation instructions and shipping instructions

59 The method of Claim 55, further comprising ordering component parts from a vendor, receiving the component parts, and assemblying the component parts into an item

60 The method of Claim ^~ 5, further comprising identifying suppl iers for the component parts of at least one tier

61 The method of Claim 60, further comprising ordering an item from a vendor and automatically communicating demand information to at least one other supplier of a component part of the item via the Web

62 The method of Claim 6 1 , wherein communicating ia the Web is accomplished by one of Web push methods and Web pull methods

63 The method of any of the preceding claims further comprising using the data in the database to perform systematic quantitative evaluation of at least one of employee performance, vendor performance and customer performance 64 The method of Claim 63, further comprising at least one of an employee, a vendor and a customer remotely accessing the database and viewing its own quantitative performance data

65 The method of Claim 63, wherein said evaluation is based e.itirely upon data in the database

66 The method of Claim 63, wherein said evaluation takes into account reversals of orders

67 The method of any of the preceding claims, whei ein the user demand information includes, at least implicitly, vendor identification information, further comprising automatically transmitting corresponding order informa tion to a designated vendor for fulfillment of the order

68 The method of Claim 67, further comprising automatically transmitting N-tier order information to multiple corresponding vendors

69 The method of Claim 1 , further comprising displaying to a Web user multiple electronic commerce course-of- dealing options including at least one option relating to products and at least one option relating to payments the Web user setting at least one electronic commerce course-ot- dealing option in accordance with a choice of the user and the electronic commerce system effectuating the choice of the Web user for each of multiple subsequent electronic commerce transactions

70 The method of Claim 69 further comprising effectuating the choice of the Web user on-the-fly in real time

71 The method of Claim 69, w herein displaying comprises displaying a multiplicity of electronic commerce course-of-dealing options in tabular torm

72 The method of Claim 69, wherein course-of-dealing information is read during transaction processing of an electronic commerce transaction

73 The method of Claim 69, further comprising setting authorities of multiple Web users, and allowing a Web user to set an electronic commerce course-of-deal- mg option only if the Web user is authorized to do so 74 The method of Claim 73, further comprising effectuating the set tings on-the-fly in real time

75 The method of any of claims 61-64, wherein a second working- level electror ic commerce course-of-dealing option relates to the authority of a Web user to perform a predetermined action authorized in accordance with a first, enterpπse-level electronic commerce course-of-dealing option

76 The method of any of the foregoing claims, further comprising making remotely accessible to a user status information pertaining to each of a majority of the following product life cycle stages purchasing, receiving, shipping, installation/assembly, billing, and returns/service

77 The method of any of the foregoing claims, further comprising a user executing a dynamic workflow process not explicitly provided for

78 The method of any of the foregoing claims, further comprising an external user remotely setting or changing authority of one or more users

79 The method of Claim 78, further comprising the system immediately effecting the changes in authority