US 20040015367 A1
A system for defining and managing an asset which includes a data store for virtual area data provided on a host computer coupled to a network. The system includes a data input and supplement toolset including and including at least one of an item procurement system, a cost management system, a project management system, and an information collection system. Each system includes a database interface allowing the system to retrieve, use and modify data subject to permissions granted by project managers.
1. A system for defining and managing an asset, comprising:
a data store for virtual area data provided on a computer coupled to a network; and
a data input and supplement toolset linking virtual area data to business objects.
2. The system of
3. The system of
4. The system of
at least one attribute value;
at least one component value; and
at least one allocation value.
5. The system of
6. The system of
7. The system of
8. The system of
9. The system of
10. The system of
11. The system of
12. The system of
13. The system of
14. The system of
15. The system of
16. The system of
17. The system of
18. The system of
19. The system of
20. The system of
21. The system of
22. The system of
23. The system of
24. The system of
25. A system for defining and managing a physical asset requiring a plurality of items and components, comprising:
a data store for virtual area data, including item attributes, for objects incorporated into or consumed during the creation of the asset;
at least one data creation toolset for virtual area data into the data store; and
at least one item procurement system, the procurement system including a data store interface allowing supplementation of virtual area data.
26. The system of
27. The system of
28. The system of
29. The system of
30. The system of
31. The system of
32. The system of
33. The system of
34. The system of
35. The system of
36. The system of
37. The system of
38. The system of
39. A system for defining and managing a physical asset requiring a plurality of items and components, comprising:
a data store for virtual area data, including item attributes, for objects incorporated into or consumed during the creation of the asset;
at least one data creation system for virtual area data into the data store; and
a cost management system including a data store interface allowing supplementing of virtual area data.
40. The system of
41. The system of
42. The system of
43. The system of
44. The system of
45. The system of
46. The system of
47. The system of
48. The system of
49. The system of
50. The system of
51. The system of
52. The system of
53. The system of
54. The system of
55. The system of
56. A system for defining and managing a physical asset requiring a plurality of items and components, comprising:
a data store for virtual area data, including item attributes, for objects incorporated into or consumed during the creation of the asset;
at least one data creation system for virtual area data into the data store; and
a teamwork system including a data store interface.
57. The system of
58. The system of
59. The system of
60. A system for defining and managing a physical asset requiring a plurality of items and components, comprising:
at least one data creation system for virtual area data into the data store; and
a project management system including a data store interface allowing supplement to virtual area data.
61. The system of
62. The system of
63. The system of
64. The system of
65. The system of
66. A method for constructing data concerning item specifications of an asset, comprising:
providing a user data entry interface;
receiving a plurality of data values, each into a data field of the interface, wherein the plurality of data fields comprise a specification for the item and each data field of the specification describes an attribute of the item, and
associating the specification with a virtual area.
67. The method of
68. The method of
69. The method of
70. A system for project management, comprising:
a component virtual area data store including component object data;
a project management application server including a virtual area input system, having a virtual area definition tool
71. The system of
72. The system of
73. The system of
a data input tool;
an virtual area system;
a procurement system;
a cost management system;
a project management system.
74. The system of
75. The system of
76. The system of
77. The system of
78. The system of
79. The system of
 This application relates to application Ser. No. 09/557,641 (attorney docket TRIRG-08330US0) filed on Apr. 25, 2000, entitled “Agent Based Purchasing System” and naming Thomas A. Wucherer as inventor, the application being incorporated herein by reference in its entirety.
 This application relates to application Ser. No. 09/519,935 (attorney docket TRIRG-08331US0) filed on Mar. 7, 2000, entitled “Integrated Business System for the Design, Execution and Management of Projects” and naming Cherisse M. Nicastro, Thomas A. Wucherer, Todd Nisbet and Anthony A. Marnell II as inventors, the application being incorporated herein by reference in its entirety.
 This application relates to U.S. Pat No. ______ (attorney docket TRIRG-08851US00) filed on Oct. 30, 2001, entitled “Intelligent Object Builder” and naming Thomas A. Wucherer, Cherisse M. Nicastro, Anthony A. Marnell II and Anthony A. Marnell III as inventors, the application being incorporated herein by reference in its entirety.
 This application relates to application Ser. No. ______ (attorney docket TRIRG-01000US0) filed on Oct. 30, 2001, entitled “Business Asset Management System” and naming Cherisse M. Nicastro, Thomas A. Wucherer, Todd Nisbet, Anthony A. Marnell II, Anthony A. Marnell III, and Herman Spencer Jr. as inventors, the application being incorporated herein by reference in its entirety.
 This application relates to application Ser. No. ______ (attorney docket TRIRG-01001US0) filed on Oct. 30, 2001, entitled “Item Specification Object Management System” and naming Cherisse M. Nicastro, Thomas A. Wucherer, Todd Nisbet, Anthony A. Marnell II, and Anthony A. Marnell III as inventors, the application being incorporated herein by reference in its entirety.
 This application claims the benefit of U.S. Provisional Application Serial No. 60/244,492, entitled “Intelligent CAD Objects Technology”, filed Oct. 30, 2000.
 This application also claims the benefit of U.S. Provisional Application Serial No. 60/246,275, entitled “Intelligent CAD Objects”, filed Nov. 6, 2000.
 This application claims the benefit of U.S. Provisional Application Serial No. 60/244,457, entitled “Item Data Integration System And Method”, filed Oct. 30, 2000.
 This application also claims the benefit of U.S. Provisional Application Serial No. 60/246,276, entitled “Item Data Integration System And Method”, filed Nov. 6, 2000.
 This application claims the benefit of U.S. Provisional Application Serial No. 60/244,493, entitled “Tracking Modules For Specified Objects”, filed Oct. 30, 2000.
 This application claims the benefit of U.S. Provisional Application Serial No. 60/244,485, entitled “Module For Publishing Reports On Intelligent Object”, filed Oct. 30, 2000.
 A portion of the disclosure of this patent document contains material to which the claim of copyright protection is made. The copyright owner has no objection to the facsimile reproduction by any person of the patent document or the patent disclosure, as it appears in the U.S. Patent and Trademark Office file or records, but reserves all other rights whatsoever.
 1. Field of the Invention
 The present invention relates to a system for designing, constructing and managing the a physical asset such as a building, property, aircraft, or the like.
 2. Description of the Related Art
 Many industries employ a team of players to design and execute a project. For example, the construction industry employs a team of players to design and construct a building, such as an office building, a hotel/casino, or a manufacturing facility. Typically, the project team includes architects who prepare architectural drawings and specifications of the project according to a developer's direction. The team also includes engineers who are responsible for building systems such as structural, power, heating, cooling, plumbing systems, etc., and interior designers who are responsible for specifications relevant to interior design such as the selection and placement of furniture, paint selection, wall coverings, fixtures, office equipment, etc. The team's contractor implements the designs of the architects, engineers, and interior designers, and is generally responsible for the purchase of materials, electrical systems, mechanical systems, life safety systems, furniture, fixtures, etc., and for the management of any or all subcontractors who implement the design drawings and specifications. Other project participants may include a purchasing agent or purchasing department that is responsible for purchasing items (e.g., furniture, fixtures and equipment, etc.) for integration into the project. Contractors and subcontractors who actually build the project according to the architectural drawings. A project superintendent may manage the participants, such as by approving some or all changes to the project requested by the participants. Additionally, the project owner may participate to ensure that the project meets his or her requirements from initial conception through completion. Finally, project accountants are responsible for payment of goods and services.
 In the past, the design and construction of an asset involved the transfer of a substantial amount of paper between the various team members. For example, the architect may prepare conceptual paper specifications and drawings for a building project. These paper specifications and drawings, in turn, may be provided to one or more additional architectural engineers for modification or approval. The chief architect must provide his paper design specifications and drawings, typically via overnight delivery, to one or more of the collaborating firms. These additional team members typically add components or make modifications to the initial architectural drawings and specifications. Once revisions are completed, the collaborating firms return the revised architectural specification and drawings to the architect so that he may compile a master set of building specifications and drawings. Several different, further revisions may occur between the architect and the other project team engineers before the final set of master architectural specifications and drawings is created.
 The architectural specifications and drawings, once completed, are also provided to interior designers for input with respect to interior design features such as furniture, wall coverings, paint selection, office equipment, etc. In that each item added to a construction project, including furniture, fixtures, and equipment, typically generates more paper specifications, the interior designers additionally generate a substantial amount of paper that must be properly cataloged and distributed to other project team members. At any point during the project, revisions to the original architectural design specifications and drawings may occur which, in turn, may require other revision of the specifications of the interior designers and/or collaborating engineers.
 Ultimately, the interior design specifications along with the architectural and engineering design specifications and/or drawings are provided to a contractor who, in accordance with the specifications and drawings, coordinates subcontractors, purchasing agents, etc., to purchase the raw materials, electrical systems, mechanical systems, life safety systems, building equipment, labor fixtures, etc. and facilitates construction management of the project. Construction management or finance team members are responsible for maintaining the budget of the construction project, and must have current, accurate information relating to costs of materials, fixtures, labor, etc. Additionally, accountants pay project invoices and track the project's accounting commitments. At any point, an owner, architect, engineer, interior designer, or contractor may propose modifications to the project that necessitate further, hurried paper transfer amongst the team members to insure that all are working with the same information.
 Computer implemented systems have streamlined many project processes. In the architecture, engineering, and construction industry, software systems have been developed which aid each team member (specific to each team member's position) in the development of a construction project. For example, computer aided design tools have been developed which enable an architect or interior designer to model an asset and store that model in a database. These computer aided design tools allow more efficient modifications to an existing design than the prior art method of employing drawings in which changes were made by hand. Accounting systems are also available which enable the paperless financial management of a construction project. Additionally, software systems are available to contractors to facilitate the necessary purchases, scheduling and management of a construction project.
 While these existing architecture, engineering and construction software systems aid individual project team members, communication between the various team members remains as inefficient as in the past. In other words, an architect can make revisions to the architectural specifications of a asset by accessing and modifying an existing database model of that asset. The architect has no need to generate a hard-copy of the architectural drawings and manually revise each drawing. However, the architect must still communicate with the interior designer, contractor, finance team members, etc., via the old method of printing out and hastily distributing (usually numerous) architectural drawings. This is especially true when project team members wish to modify item specifications.
 A project typically involves many phases including design and build. These phases often overlap and each is highly dynamic. The design phase usually starts with one or more designers creating conceptual drawings of the project according to a developer's direction. The drawings generally include perimeter lines representing specific areas (e.g., restaurants, rooms, lobbies, offices, etc.) within the project. The drawings may also include graphical representations of items within the specified areas. For example, an architect may create a drawing of a restaurant area of a hotel/casino project. The restaurant drawing may include graphical representations of furniture, fixtures, and equipment (FF&E) such as tables, windows, ovens, refrigerators, a backup power generator, etc.
 The initial drawings, once completed, are provided to several other project participants involved in the design and build process. For example, the restaurant drawing example above may be provided to one or more structural engineers, mechanical engineers, electrical engineers and interior designers for their review, modification, and/or supplementation. These project participants may add further graphical representations of items to the initial set of drawings. An interior designer of the project may wish to add graphical representations of additional items such as chairs or art work to a dining room sub-area of the example restaurant drawing above. A structural engineer may also seek to add graphical representations of items to the restaurant drawing such as a platform on which the backup power generator (graphically represented in the drawing) rests. When project participants (e.g., engineers, interior designers, etc.) receive initial drawings of the project, the drawings give very little information about the items graphically represented. Typically, the drawings simply identify the items by title or type (e.g., “a table,” “a window,” “a backup power generator”). The engineers, interior designers, and other project participants further define or specify the characteristics or attributes of items originally contained in the drawings or items added to the drawings.
 The engineers or designers sometimes annotate specification information on the drawings, but usually the engineer or designer creates a separate specification sheet for each item graphically represented on the drawing. For example, an interior designer may create a separate specification sheet for each type of chair graphically represented in the restaurant drawing. Each specification sheet contains descriptive information (size, as size, material and finish, etc.) regarding a type of chair, and may reference other specifications such as fabric. Likewise, an electrical engineer may, for example, create a separate specification sheet for the graphically represented backup power generator describing, for example, the generator's size, power generation capacity, weight, and other attributes.
 In addition to providing specifications for items contained on drawings, there are times when drawings are not created or items are not contained on a drawing which is created, but there are still specifications for items required. For instance, in the above restaurant example is remodeled, specifications for new furnishings may be created without a drawing. Alternately the designer may provide an item schedule which list many like items and their distinguishing characteristics or referenced items.
FIG. 1 includes an example of an item specification to be included as part of a construction project. An interior designer developed this specification sheet for an entertainment center to be included in the living room of a suite of a hotel project. Portion 110 of the specification sheet includes general information about the specification, such as a specification number, and the area and project into which the item will be incorporated. Portion 120 includes manufacturer information, distributor information, a description of the item, the dimensions of the item, manufacturer catalog information and the manufacturer catalog description. Portion 130 describes the quantity of the item to be ordered, price information, and budget information for the item. Portion 140 indicates information about receiving a sample of the item, and portion 150 includes information about the finish for the item. Portion 150 also includes notes about the finish, notes about the interior dimensions, and a note that the specification was issued to the purchasing department on May 26, 1998. Portion 160 includes an image of the entertainment center. Portion 170 shows information about other specifications providing information about the entertainment center. Not all portions 110 through 160 are included as part of every specification, and specifications may have portions describing other information not shown.
 Other item specifications may contain different data or sections of information. For instance, portion 120 may list the color, weave, repeat, and pattern for a fabric. The details required are identified by the type of item (e.g., hard furniture, upholstered furniture, fabric, oven, sink, faucet, chiller, etc.). Each of these types will have different characteristics or attributes to be described to differentiate like items. The type of item also may require references to other specifications required for an assembly. For example, furniture may reference fabric and paint while chillers may reference piping and pumps. Attributes and required references must be defined in templates for each type of item specification.
 Engineers and designers normally employ software applications for generating specification sheets for project items for which they have responsibility. These software applications generate electronic versions of specification sheets into which engineers or interior designers enter descriptive information. Engineers or designers usually enter a reference to a graphical representation in a drawing into the appropriate specification sheet so that the specification sheet can be associated with an item represented on the drawing. The electronic specification sheets may be organized as flat files, spreadsheets, or word-processing documents.
 Once the engineers or designers finish writing an item specification, the specification is ready to be provided or “published” to other project participants for review, modification, supplementation, and/or approval. The engineer or designer can send the specification as e-mail attachments if the recipient has a computer system with appropriate software applications for accessing the attachments. Alternatively, copies of the specification may be printed and distributed. The author saves one copy as the original specification sheet in electronic version form, hard copy form, or both, for archiving purposes. Except for the graphical reference in the specification sheet, specification sheets are forwarded to other project participants disassociated from their corresponding drawings.
 One or more revisions to each item specification may occur throughout the process. Indeed, revisions to an item specification can occur even after the corresponding item is purchased. In this latter case, the purchased item would normally be located and returned to its manufacturer, and the purchase price may be refunded, in whole or in part.
 Specification revisions may occur for a variety of reasons by a variety of project participants. For example, the project owner, upon receipt of a specification for one of the restaurant chairs, may desire the chair color to be different than originally specified or determine that the chair as originally specified is too expensive. Another interior designer for the project, upon receipt of the same specification for the restaurant chair, may notice that the originally specified fabric did not include fire treatment in accordance with local fire codes. The structural engineer, upon receipt of the specification for the backup power generator, may notice that his platform may not support the weight of the backup generator specified by the electrical engineer. Each reason for revision is communicated to the original author who, in response, revises the specification accordingly. Once revised, the specification is re-distributed to other project participants for further review, modification, supplementation, and/or approval. The author of the original specification sheet has the responsibility for maintaining a history of all revisions to the specification sheet. The author also has the responsibility to ensure that all necessary project participants have the most recent version of the specification sheet.
 Once a specification sheet for an item has been approved by all the necessary project participants, it may be submitted to the project's purchasing agent. The purchasing agent, in turn, may create a purchase order for the item using information from the specification sheet. An example of a purchase order for several items, including the entertainment center of FIG. 1, is shown in FIG. 2. Page 1 of the purchase order shows the entertainment center of FIG. 1 as item 1, page 2 shows orders for other items 2-5, and page 3 shows general notes for the purchase order.
 The purchasing agent, like the project engineers and interior designers, may employ a computer system executing specialized software for generating a purchase order. Typically, the purchasing agent manually transfers specification sheet information into the purchase order, as shown in FIG. 2. The purchasing agent subsequently sends the purchase order to manufacturers via hard copy or e-mail attachment. The purchasing agent also sends a copy of the purchase order to the project's accountant.
 Coordinating communication of information regarding items in a construction project becomes more complex as the scale of the project increases. Collaboration and the exchange of information, including drawings and item specifications, between design and build participants also increase the complexity of each project. Effective and efficient collaboration is often the single most important key to bringing a project to fruition in a quality, timely and cost effective manner. However, as more fully exemplified above, collaboration and information exchange between participants, is typically a paper-based and chaotic process. Furthermore, it is difficult to determine the history of an item based upon the papers residing at different project participants.
 Managing change throughout the life cycle is also difficult in a paper-based or disparate application-based process. Decisions are not always based on all information available, for instance, an owner may choose not change the color of a fabric if the owner had known that the fabric had already been purchased and that a restocking fee would apply.
 What is needed is an item data integration system that will integrate data from different applications about an item throughout the item's lifecycle. Data from the separate applications should be presented as an integrated whole to users of the item data integration system. An item data integration system that is capable of providing budgeting, design specification, CAD drawings, purchasing, bid processing, receiving, invoicing, location, and maintenance data, or other processes in the item's lifecycle, about an item is desirable.
 Integrated data allows change management throughout the process. For example, designers may wish to be notified if they are deleting an item from a drawing that has already been purchased; Specifiers may wish to be notified if they are exceeding the approved budget for an item; Purchasing Agents may wait to purchase items if they know there is a revision in progress; Maintenance personnel may want to know when preventative maintenance is required or a warrantee for an item is expired; etc. The rules for managing these changes and notifications should be configured by project participants.
 The present invention, roughly described, pertains to a system and method allowing comprehensive management of an asset from design through building and management. Multiple implementations of the method and system are disclosed herein.
 In one aspect the invention is a system for defining and managing an asset which includes a data store for virtual area data provided on a host computer coupled to a network, and a data input and supplement toolset linking virtual area data to business objects. In a further embodiment, the system manages physical assets requiring a plurality of items and components. In this embodiment, the system a data store for virtual area data, including item attributes, for objects incorporated into or consumed during the creation of the asset. The system also includes at least one data creation system for virtual area data in the data store, and at least one of: a teamwork system, a project management system, a cost management system, or an item procurement system, each including a data store interface allowing supplementation of virtual area data.
 In another aspect, the invention may provide a change management notification to team members notifying them when specific actions occur as defined by user set business rules. Furthermore, The invention may also route system business objects for approval and publishing to project team members and track the history of changes to system business objects.
 In yet anther embodiment, the invention comprises a method for constructing data concerning item specifications of an asset. The method may include the steps of providing a user data entry interface; receiving a plurality of data values, each into a data field of the interface, wherein the plurality of data fields comprise a specification for the item and each data field of the specification describes an attribute of the item, and associating the specification with a virtual area.
 The present invention can be accomplished using hardware, software, or a combination of both hardware and software. The software used for the present invention is stored on one or more processor readable storage media including hard disk drives, CD-ROMs, DVDs, optical disks, floppy disks, tape drives, RAM, ROM or other suitable storage devices.
 These and other objects and advantages of the present invention will appear more clearly from the following description in which the preferred embodiment of the invention has been set forth in conjunction with the drawings.
 The invention will be described with respect to the particular embodiments thereof. Other objects, features, and advantages of the invention will become apparent with reference to the specification and drawings in which:
FIG. 1 depicts a prior art item specification document used in a project.
FIG. 2 depicts a prior art purchase order for the items in the specification document shown in FIG. 1.
FIG. 3A is a block diagram showing an overview of one embodiment of the system of the present invention.
FIG. 3B is a representation of a user Home Page in accordance with the present invention.
FIG. 3C is a representation of a Project Home Page in accordance with the present invention.
FIG. 4 is a block diagram showing the data flow for an item throughout several stages of an item's lifestyle.
FIG. 5 shows an example of a specification as a configurable data object.
FIG. 6 shows an example of a configuration window allowing a user to define a configurable data object such as a specification.
FIG. 7A is a flowchart of programmably linked browser display pages which illustrates the collaboration system used in the system of the present invention.
FIG. 7B is a depiction of an exemplary Message Center screen used in conjunction with the collaboration process.
FIG. 8 is a flowchart of programmably linked browser pages illustrating a project set up used in the system of the present invention.
FIG. 9A is a flowchart of programmably linked browser pages illustrating the creation of a virtual area in accordance with the system of the present invention.
FIG. 9B is a graphical depiction of a virtual area.
FIG. 9C illustrates a specification list.
FIG. 10 is a flowchart illustrating the interaction of various system tools and how such tools modify data in the database to manage an asset in accordance with the present invention.
FIG. 11 is a flowchart illustrating the lifecycle of an Item Specification in the system of the present invention.
FIG. 12 is a flowchart illustrating the process of specifying an item in accordance with the Item Specification Wizard tool used in the system of the present invention.
 FIGS. 13A-13M are screen shots of page types used in the process shown in FIG. 12.
FIG. 14 is a flowchart illustrating an request for quotation process flow in accordance with the system of the present invention.
FIG. 15 is a flowchart illustrating a RFQ response process flow in accordance with the system of the present invention.
FIG. 16 is a flowchart illustrating an RFQ review process flow in accordance with the system of the present invention.
FIG. 17 is a flowchart illustrating a Bid Request Wizard process flow in accordance with the system of the present invention.
FIG. 18 is a flowchart illustrating a Bid Response Wizard process flow in accordance with the system of the present invention.
FIG. 19 is a flowchart illustrating a Bid Review Wizard process flow in accordance with the system of the present invention.
FIG. 20 is a flowchart illustrating a Purchase Order process flow in accordance with the system of the present invention.
FIG. 21 is a screenshot illustrating a purchase order process page in accordance with the system of the present invention.
FIG. 22 is a flowchart illustrating a shipping process flow in accordance with the system of the present invention.
 The system described herein presents a complete design—build—management solution to the tasks involved in overseeing and managing construction, manufacturing, and maintaining assets such as buildings, ships, airplanes and the like. In one aspect, the system an enterprise system, Application Service Providers (ASP) platform, and open architecture system which provides application toolsets that allow multiple participants in projects, automation of bidding and estimating processes, accuracy and efficiency in purchasing, integration with existing applications, and simple but secure access over the Internet or a private network. The system captures and manages information throughout the design, build, and manage phases of the resulting asset.
 In a further unique feature of the invention, all data is available in real-time providing consistent information throughout a project's lifecycle. Even after an asset has been built, an owner or property manager can access the system to derive specific information within a few seconds. This system can be applied to any number of design and build industries, including: Hospitality, Civil and Electrical Infrastructure; Telecom; Commercial, Residential, and Government Buildings; Manufacturing; Aerospace and Nautical applications; and Automobile, Railways, and Public Transportation projects.
 The system provides a single, logical solution to gathering and manipulating information concerning assets. In performing this function, the system provides an efficiency of cost not heretofore known in prior art systems. Design data is stored and manipulated by the system throughout construction/manufacturing and, later, the management process for any type of asset. While the system will be described herein with respect to construction of a building, it will be readily recognized that the system is applicable to any type of asset. The system allows management of the designing and construction from beginning to end, and information is gathered and updated from multiple sources throughout the project. The system is also flexible enough to accommodate many different types of businesses and projects.
 The system provides this solution to users in real time, so that all information modified by users is instantly available to other users in the system, creating even greater efficiency.
 The following terms will be used throughout the specification and are defined as follows:
 Attribute: A quality of characteristic inherent in or ascribed to an item specification.
 Business Object: An article used in the conducting of business, such as a schedule of items, a letter, an email, a purchase order, a request for quotation, and the like.
 CAD: Acronym for “Computer-aided design.” Computer-aided design software is used by architects, engineers, drafters, artists and others to create precision drawings or technical illustrations. CAD software can be used to create two-dimensional (2-D) drawings or three-dimensional (3-D) models.
 Classification: The system of the present invention recognizes classifications as a category or class of item types. The classification tree displays the classes in a hierarchal fashion.
 Company: An organization or group that performs services or provides products within the system. A business enterprise; a firm. Individual company defaults and standards revolve around a company.
 Company Administrator: The first user for any company. This user is responsible for setting up licensing, company information, company defaults, users, vendors, and so forth.
 Component: The system supports components as a part of an Item Specification. A component is an existing Item Specification associated to another item specification; together, they make up a whole item or an assembly. An Item Specification can have multiple components.
 Document Set: A special type of folder in the Collaboration tool. A document set allows a user to group together any number of files into a common set. The actual files are stored in separate folders organized in whatever manner suits the user. The contents of the document set folder are merely shortcuts, or pointers, to the actual files. Only one copy of any given file needs to be maintained.
 Item Specification: The detail information about objects involved in building the parts and components of something. An example of an item would be a desk; an example of the item specification would be the description of the desk (height, width, depth, color, material, and so forth), its manufacturer(s), costs, delivery options, catalog numbers, and so forth.
 Item Type: A template for creating item specifications for broad categories of items. For example: a user might have an item type of “office furniture,” this item type forms a template a user would use to create the many item specifications for various desks required.
 Project : A plan or proposal; a scheme or undertaking requiring concerted effort. The system of the present invention allows any plan with more than one task to be considered as a project.
 Project Partners: Project Partners can include suppliers, vendors, contractors, designers, and consultants who have different levels of access to specifications and receive information about, and respond to information on, the Property or Project.
 Property: The base organizational point for the activities of a Company within the present system. The property is the larges hierarchal space in one or more virtual areas. The “Property” label may be customized using the Nomenclature options in Company Defaults.
 Qualification: The Qualification process is the act of ensuring that a company is suitable to perform work or provide materials for a specific project. The system provides the ability to qualify vendors and/or services before bidding and purchasing. Qualification is an information gathering process that can be used for screening purposes.
 Schedule: A schedule is a list of specified items, a reference number, a version number and the item status information. The system provides the ability to generate schedules, either by type or instance, for the entire project or specific virtual areas.
 The foregoing terminology is used herein for convenience in understanding the present invention. It should be understood that the aforementioned definitions are not intended as limiting the scope of the present invention to the particular terms which are defined. Other nomenclature may be used to represent the concepts and substance of the foregoing definitions.
FIG. 3A is an overview of the system 1000 of the present invention. As shown therein, the system includes an application server providing application toolsets to one or more client computers. The server and computers are coupled by a network, which may be a public network, a private network, or a combination of public and private networks such as the Internet. The toolsets are designed to facilitate the project creation and management by manipulating data describing basic elements of the project stored in at least one database on the application server or a separate database server. FIG. 3A shows the six general types of application toolsets accessible by a client device. Each of the applications support project data entry and modification, while two are support system management and utilities. The specific functions of each of these groups of applications are set forth below.
 Each client device may comprise a personal computer, a thin client or any other type of processing device capable of supporting applications described herein, and the system may be accessed by different types of client devices—such devices need not be personal computers but do need to support the applications provided in the applications toolsets. Applications server 1020 also includes at last one database for property item data managed by the system of the present invention. In FIG. 3A, the databases are organized by property, but such organization is exemplary and not meant as limiting on the system of the present invention. Organization of the databases into one or more other data structures or classifications is contemplated as being within the scope of the present invention.
 The application toolsets provided in the system include: a Design Toolset 1100, a Procurement Toolset, a Cost Management Toolset, and a Project Teamwork Toolset. In the following description, although the aforementioned tool sets comprise one embodiment of the present invention, it should be understood that additional tool sets may be provided without departing from the scope of the invention.
 The Design Toolset allows users of the system to input into the system 1000. The Procurement Toolset 1200 includes a Bid/RFQ tool and a Purchase tool. The Cost Management Toolset 1400 provides an Cost Estimate tool, Budgeting tool, a Contract tool, a Payment tool, and an Invoicing tool. Finally, a Project Teamwork Toolset 1600 includes a Collaboration Tool, a Request for Information tool and Meeting Minutes tool. Two other sets of applications are provided—an administration tool set 1300 and a utilities tool set 1400.
 The system will be described herein in the context of its implementation in an Application Service Provider (ASP) model. As used herein, the ASP model includes providing applications from an application server including databases organized by project or property to a client computer. In this context, an ASP is used to refer to an application server providing applications to a client device, as opposed to those applications which are installed in non-volatile memory on the client device. In one embodiment, the application toolsets may be implemented as a set of applications configured to run in another interpretive application, such as in Internet Browser.
 The application server 1020 is a server program in a computer in a distributed network that provides the business logic for an application program run on the client computer 1050. The application server 1020 may comprise a portion of the system which may further include a graphical user interface (GUI) server, an application (business logic) server, and a database and transaction server. In one embodiment, the application server combines or works with a Web (Hypertext Transfer Protocol) server and is called a Web application server. The Web server provides several different ways to forward a request to an application server and to forward back a modified or new Web page to the user. These approaches include the Common Gateway Interface (CGI), FastCGI, Microsoft's Active Server Page, and the Java Server Page. In some cases, the Web application servers also support request “brokering” interfaces such as CORBA Internet Inter-ORB Protocol (IIOP), and Enterprise Java Beans.
 In general, a request, such as an HTTP request, from the client device is made to the application server via the network. If the request is for a particular application, the application will be transmitted to the client, loaded and run by the client by presenting a graphical input/output page to a user.
 The system is configured to have a “Home Page” and “Project Page” for each user. Representations of exemplary pages are shown in FIGS. 3B and 3C. The project page may be customized to provide any number of the tools, or a subset of the available tools, to the user depending on the permissions granted to the user by the Company Administrator. The project page will contain links to the applications which are accessible to the user, and the data supplying those applications and the applications themselves are provided by the applications server. In addition, security level access to the data is controlled by the application server.
 In general, design data is created in the database by the design toolset applications, but such data can be further supplemented and/or modified by nearly all other components of the system. An object linking application links design drawings (created in a CAD system or specification builder) to specification data that describes the “real world” object. The result is an “intelligent object.” When actions (budgeting, purchasing, delivering, maintenance scheduling) occur to that object, by any system user, the “intelligence” of the object is updated with this information.
 An example of the data which may be used in the system of the present invention is set forth in co-pending U.S. patent application Ser. No. ______ filed ______ entitled INTELLIGENT OBJECT BUILDER (TRIG8851) by Thomas A. Wucherer, M. Cherisse Nicastro, Anthony A. Marnell II and Anthony A. Marnell III (hereby fully incorporated by reference herein).
 The data may be stored in a database in any of a number of object, relational or distributed database structures. In one embodiment, the data is organized in a series of name value pairs and relationship tables accessible via XML or SQL. In another embodiment, the data is provided in a relational database with each object represented by a single row of generic columns of attribute data, along with an attribute definition row. In yet another embodiment, the data is organized into object classes and subclasses in an object database.
 In accordance with the invention, the Application server may be supplied by a System Administrator. The Administrator may host the applications databases, and provide assistance to users of the system at all levels in using the application. In this embodiment, the system administrator enables the application server for internet access such that the client computers may be positioned at remote sites, such as the physical location of each of the members of the design team, purchasers, contractors and the like, allowing all users to communicate data to the application server via a secure protocol. The administrator may offer access to the application server, store data and customer service as a service for which the System Administrator collects a fee. Types of fees charged by the System Administrator are described herein.
 In understanding the comprehensiveness of the system of the present invention, it is helpful to understand how conventional data flows in a project. FIG. 4 shows an example data flow for an item through several stages of an item's lifecycle in a construction project of a building. A project participant 312 originally provides a budget 330 for the project. From the budget 330, different project participants produce specifications such as specification 332 for items to be purchased. The purchasing department 316 optionally may produce a bid package 334 from the specification to obtain bids for an item to be purchased. Subcontractors and vendors, among others, such as subcontractor 314, submit bid responses such as bid response 336 to the purchasing department 316. Purchasing department 316 decides to which subcontractor or vendor a contract 337 or purchase order to provide the item should be awarded. Contract 337 is communicated to project accountant 310 and project manager 320. Each of project account 310 and project manager 320 may use respective computer system(s) (not shown) for managing different types of data associated with an item.
 Upon awarding contract 337 or directly upon receiving specification 332, purchasing department 316 may produce a purchase order 338 or contract for ordering the item from a seller 318. The vendor 318 sends the item 340 to the receiving department 322 and an invoice 342 to project accountant 310. Receiving department 322 sends a receiving list 344 to project accountant 310 and project manager 320. Receiving department 322 also places item 340 in storage. Storage manager 324 optionally sends item 340 to a warehouse and provides location data 348 to the project manager 320. From the warehouse, warehouse manager 326 distributes item 340 to the construction site and provides location data 348 to the project manager 320. Location data 348 regarding the current location of item 324 is provided by warehouse manager 326 to project manager 320. Alternatively, storage manager 324 may send item 340 directly to the construction site and provide current location data 348 to project manager 320. Project superintendent 328 then places the item in the appropriate location within the project.
 The stages of the lifecycle depicted in FIG. 4 include only those stages through the delivery of the item to the site and payment for the item. An item has a life beyond the stages depicted; for example, after being delivered to the site, the item is placed into a location within the project and often used for many years. The scope of the invention includes managing these maintenance stages of the lifecycle of the item. The stages shown in FIG. 4 are one example and used for illustration purposes only.
 As shown in FIG. 4, many types of data flow to many project participants during the lifecycle of an item used in a project. The term “item data” is used herein to describe collectively these many types of data associated with the lifecycle of the item. Each of the project participants may use one or more application programs to track the different types of item data that he or she receives and/or generates. Often project participants use application programs that are not used by other project participants, so that data is sent via paper from one project participant to another. In such a paper-based system, each project participant manually enters the data into one or more respective application programs.
 Item data are described herein as objects of an object-oriented framework, although the scope of the invention includes other organizations of item data. For those unfamiliar with object-oriented frameworks, a brief summary is presented here. The building block of an object-oriented framework is an object. An object is defined through its state and behavior. The state of an object is set forth via attributes of the object, which are included as data fields in the object. The behavior of the object is set forth by methods of the object. Each object is an instance of a class, which provides a template for the object. A class defines zero or more data fields to store attributes of an object and zero or more methods.
 Each data field contains attribute information defining a portion of the state of an object. Objects that are instances of the same class have the same data fields, but the particular attribute values contained within the data fields may vary from object to object. Each data field can contain information that is direct, such as an integer value, or indirect, such as a reference or pointer to another object.
 Design System Toolset
 The Design system tools include a CAD intelligence plug-in, specification tool and a schedule tool. Each of these tools provide project designers with the ability to enter data into the system in a manner which the designer would be normally accustomed to.
 CAD Intelligence Plug-in
 The CAD Intelligence plug-in adds functionality to AutoCAD or MicroStation/J or other computer aided design software. It can connect to the application server database, select item specifications, assign those specifications to drawn items in the CAD drawing, assign the drawing to a virtual area in the project and upload the “intelligent objects” in the drawing to the database. The CAD Intelligence plug-in is available for download to a local PC from a designated home Page. Once installed, the plug-in automatically updates itself as necessary when the System Administrator updates the functionality or design of the plug-in.
 The CAD Intelligence plug-in adds a menu and/or toolbar to an existing CAD application. Its main function is to connect drawing objects with detailed specifications associated to the project. The architect or engineer can also create new specifications while drawing. From within CAD Intelligence, a user can: login to the system database, add data fields to the cells/elements in a drawing (making them “intelligent”), associate drawing elements to an area, associate drawing elements to an item specification in the database, edit and view the attributes of intelligent elements, associate a mark in the drawing to an item specification, generate marks for the entire drawing and upload intelligent elements from a CAD drawing to the database. The CAD intelligence plug-in such as that described in co-pending U.S. patent application Ser. No. ______ filed ______ entitled INTELLIGENT OBJECT BUILDER by Nicastro, Wucherer, Nisbet, Marnell II, Marnell III (hereby fully incorporated by reference herein) is suitable for use in the present system.
 Item Specification Tool
 The Item Specification Tool is an independent application for creating intelligent objects without using a CAD system. The Specification Tool is fully described in co-pending application Ser. No. ______. Item Types are templates for creating item specifications for broad categories of items. The use of Item Types enables a user to display all the item types for a selected classification. The system recognizes classifications as a category or class of disciplines and trades. The classification tree displays disciplines and trades in a hierarchal fashion. Classifications are used to organize item types and control access to them. This function allows a user to open and display all details of a selected item type. The manager also allows a user to copy the attributes of a selected item type to create a new item type with the ability to edit the existing attributes. This process also provides the ability to delete an existing item type that has not yet been used to define an item specification. A user may create a new item type for a selected classification by accessing the Item Type Wizard.
FIG. 5 shows an example of the item specification as a configurable data object. Three items are shown, including a chair 510, a drapery 520 and a fabric 530. Specifications 512, 522 and 532 are associated with the three items. Fabric 530 is a sub-item of chair 510 and has its own specification 532. The drapery is made from the same fabric as the chair and fabric 530 is also a sub-item of drapery 520. All of these items are specified as part of the guest room furnishings group for the Palazzo Suites area of the project.
 While each of the specifications 512, 522 and 532 provides a specification for an item, each has different attributes. For example, the specification object 512 for chair 510 has a finish attribute, which in the example shown has a value of “dark cherry.” In contrast, specification object 522 for drapery 520 has a style attribute with a value of “Roman blinds” and specification object 532 for fabric 530 has a color attribute with a value of “red.” The ability of different specifications to have different attributes provides great flexibility to a user of the item data integration system 400. Standard specifications can be defined when information is to be tracked for many items of a particular type, but a new specification can be defined whenever additional information is needed for an item. Item data integration system 400 performs operations on all specifications in the same way even though specifications for different types of items are defined differently.
FIG. 6 is an example of a configuration window that allows a user to define a configurable data object such as a specification. Data field Group field 610 allows the user to choose a group into which the configurable data object will be placed. Select Object button 612 allows the user to select an item object with which the configurable data object is associated. For example, the user may link a specification to a graphical object in the architectural drawing or to another item object. Space field 620 allows the user to indicate the space, or location, to which the configurable data object pertains and Select Space button 622 allows the user to select a location in the construction project where the item will be placed. Mark field 630 allows the user to specify a mark and Place Mark button 632 allows the user to place the mark on a graphical drawing.
 Spec field 640 allows the user to select an existing specification for the item and New Spec button 642 allows the user to create a new specification. Apply button 644 allows the user to link a configurable data object with an item object, Reset button 647 allows the user to reset fields of the configurable data object to default values, and Details button 648 allows the user to view the details of the configurable data object as shown in windows 650, 660 and 690. When apply button 644 is used to link a configurable data object with an item object, a relationship between the configurable data object and the item object is created. In one embodiment of the invention, an integrated data object containing pointers to the configurable data object and the item object is created.
 New Spec button 642 will bring up windows such as windows 650, 660, and 690 and buttons such as buttons 662 through 669. For a new configurable data object, the attributes list shown in Attributes tab 670 is empty and the user can define attributes using Add Attributes button 692. Numeric attributes would have Unit of Measure buttons such as buttons 673, 675 and 677.
 Status area field 650 shows a status of the configurable data object. Window 660 shows a hierarchy in which the configurable data object resides. The user would highlight the level of the hierarchy into which the new configurable data object should be placed.
 In the example of FIG. 6, the user has selected a specification configurable data object and may use one of the buttons 662 through 669 to modify the specification. Add SubSpec button 662 allows the user to add a sub-specification to the specification and Add Instance button 664 allows the user to add a new instance of the specification (an item associated with the specification). Remove button 666 allows the user to delete a specification, Edit Instance button 668 allows the user to edit an instance of the specification (an item), and Edit Spec button 669 allows the user to edit the existing specification.
 The user has selected an existing specification so that fields are shown in the Attributes tab 670 of the specification. Height data field 672, width data field 674, depth data field 676 have associated unit of measure buttons 673, 675, and 677, respectively. Finish data field 677, fire rating data field 678 and other data field 679 are non-numeric fields for character data. The user may add a new attribute to the specification using Add Attribute button 692 and remove an attribute using Remove Attribute button 694. The user may specify status information using Status tab 680, quantity information using Quantities tab 682, and cost information using Cost tab 684. Each of these tabs has its own corresponding data fields that the user may define and/or from which the user may select.
 An Item Type Wizard may be provided to define the general properties of the item type, including the type of attributes and components that will need to be specified in the item specification. Attributes are characteristics of the item type that are necessary to define the item specification. Components link item(s) required for the assembly or completion of a particular item specification. The system supports components as a part of an item specification. A component is an existing item specification associated to a new item specification that makeup a whole item.
 For example, a door may require hardware, such as hinges, for completion. The hinge item type is a component of the door item type. Existing item types can be located through a search feature and added as components. This tool allows the user to create rules for the item type that define how a waste factor is calculated for the item, which CAD mark is associated with the item type, whether component cost should be calculated as an associated cost or rolled up into the cost of the original item, and so forth. The preferences defined apply to all item specifications that are created with this item type.
 Additional functions which may be added to the item type include but are not limited to the following: definition of reporting preferences including the selection of layout per attribute and specification data type; definition of a purchasing plug-in's ability to modify the requirements of a specification; etc.
 Item Specification Manager
 Item Specifications contain detail information about objects within a physical space. An example of an item would be a desk; the item specification for the desk would include descriptions of its height, width, depth, color, material, manufacturer(s), costs, delivery options, catalog numbers, and so forth. Item Specifications are a central feature of system 1000. They are used in several Tools such as Purchasing, Bids, RFQs, Publishing, and Schedules.
 The Item Specification Manager enables a user to display all the item specifications for a selected classification and item type. A general outline of the functions of the Item Specification Manager are shown in FIG. 4. This function allows a user to open and display all details of a selected item specification. The manager also allows a user to copy the attributes of a selected item specification to create a new item and provides the ability to edit the existing attributes. This process also provides the ability to delete an existing item specification that has not yet been published. A user may create a new item specification for a selected classification by accessing the Item Specification Wizard. The Item Specification Wizard is explained with respect to FIG. 12 and in co-pending U.S. application Ser. No. entitled Item Data Management System (TRIRG-01001US0).
 Item Specification Wizard
 The Item Specification Wizard enables a user to assign general properties to the item specification, such as: item specification number, name, physical classification, and item type. After a user has created the item specification, the user can define other general properties such as the base cost and budget code. A user may also define which users for this property can view the item.
 Additional functions which may be added to the item costs page include but are not limited to the following: definition billing data from the specifier to their customer; designed quantities for areas to be used in conjunction with the multiplier to assist in defining a specified quantity and cost for an area; etc.
 The Item Specification Wizard allows a user to define specific attributes and associate available components relating to the item specification. Components link item(s) required for the assembly or completion of a particular item specification. This tool also enables a user to provide a vendor with written notes about the item specification, such as delivery requirements, special instructions, vendor terms or any other information that needs to be communicated to the vendor. This feature also enables a user to preview the item specification information and prepare a report for printing. This Item Specification Wizard also provides the ability to calculate the total estimated cost, including component items, automatically. Costs are used for budgeting, bidding, and purchasing items. A history of the item specification is tracked by system 1000 to allow users the capability to view the historical status and specification changes for the item specification and its components over time, or view previous versions of the item specification. It should be further recognized that item specifications need not only be linked to other item specifications, but may also be linked to business objects which do not include item specifications. For example, a Request for Information may simply comprise an email asking a question without reference to an item specification. This object may be linked to other item specifications.
 Additional functions which may be added to the item specification include but are not limited to the following: definition of critical time frames for completing tasks relating to the item specifications; documentation of warranty and maintenance requirements of an item; link of an item to a real-time building automation system's status of that item; etc.
 Schedule Tool
 A Schedule is a list of specified items, a reference number, a version number and the item status information. System 1000 provides the ability to schedule item specifications either by type or instance for the entire project or specific virtual areas. A user can create custom schedules for specific items, such as doors, fixtures or finishes. The schedule can then be used as are porting tool and report item specifications based on their classification and associated virtual area.
 Item Spec Schedule Builder
 A schedule builder tool is provided to allow users to create two different types of item specification schedules (a list in tabular form). The Schedule Builder tool enables a user to schedule each instance in which the item specification occurs throughout the entire project and allows a user to define an instance schedule report. The Schedule Builder tool also enables a user to create reports based on item specifications and virtual area. It reports the quantities of item specifications in this project and allows a user to define an item schedule report.
 Additional functions which may be added to the item schedule tool include but are not limited to the following: item schedule editor which allows project participant to edit specification in a the schedule grid; links to publishing tool including selection of a publications purpose which may defines whether or not the items are ready for purchase; exporting of schedule to other interfaces such as a CAD tool; etc.
 Item Spec Schedule Report Tool
 A Schedule Report tool is provided to allow a user to run existing instance or item schedules for a specific virtual area or the entire property. These reports display on screen, an output of computer 1050, such as a display, and allow a user to print each schedule or save the schedule locally in a common format, such as Microsoft Corporation's Excel® spreadsheet program.
 Publish Tool
 A publishing tool allows the item specification to be published and allows the system to track any and all changes by renumbering each published version of an item specification. Publishing an official version of the items specification provides one form of version control. In one embodiment, the system prevents users from altering any information for that item specification without creating a new revision. Revisions are particular form or variation of an earlier or original item. System 1000 maintains a numerical format of versions for tracking history. Publishing also allows a user to create an Item Specification Book. A unique feature of the online Item Specification Book is the ability for it to be shared as different media. The Item Specification Book may be viewed online, printed, or saved to the user's personal computer or laptop for later use.
 Additional functions which may be added to the publish tool include but are not limited to the following: selection of a publications purpose which may define whether or not the items are ready for purchase; routing of the publication for approval; selection of specific project participants to publish the items to; etc.
 Cost Management Tool Set
 The Cost Management Tools offer a comprehensive electronic process to monitor, manage and control cost from a central location, track and forecast all estimates, costs, commitments, revenue, transactional events, and associated project information from the design to the construction and management of the resulting asset.
 Estimate Tool
 The Estimate Tool enables a user to create a detailed budget estimate for a project. A user can import a classification list, virtual area structure, or specification book as the basis of the estimate. This tool imports transaction information and data structure into the Budget Tool to create a budget for the project. An estimate can be imported into the budget as the baseline, or preliminary budget. The individual items imported become rows in the estimate table. Each estimate has a unique name and description, and is assigned a unique ID number by the system. This advantage allows a user to quickly track and identify each estimate and transfer the values into the budget in a logical format. All calculations and data manipulations occur locally and are not shared until a user chooses to save the data to the database 1025. An Estimate Wizard is provided in a manner which resembles spreadsheets such as Microsoft® Excel or Lotus 123®. Default columns calculate the values automatically and maintain a running total for the entire estimate. The Estimate Wizard allows a user to customize an estimate in order to suit the methods in which a company conducts business. A user can enter estimate values and add any additional columns to suit particular business needs. A user can group rows and subtotal within a user-defined hierarchy. The estimate can be sorted by any of the columns. User-defined formulas can be entered into fields and columns. Columns can be hidden from view at any time.
 Additional functions which may be added to the estimate include but are not limited to the following: consolidation of sub-bid responses for submittal of an overall bid response; enterprise cost planning across multiple projects; etc.
 Budget Tool
 The Budget Tool provides the ability to track and display all cost related transactions within the system 1000 on a project-by-project basis. The budget transactions are managed and stored as a consecutive set of events, with associated values and sources. All cost related items within the system allow the allocation of a budget code and the application of the cost related information to be accumulated as transactions. The Budget Tool uses budget codes that can be defined at either the Company or Project level. The requirements or structure of a budget code number can be defined by the user. Budget codes can be tied to item specifications in the Item Specification Tool. This tool generates budget entries automatically from a number of system 1000 processes, such as purchase orders. These system-generated budget entries are created when the appropriate user in the purchase order approval chain approves a given purchase order. Manual entry is allowed for the following transaction types: original budget entry, revised budget entry, pending budget entry, commitment entry, revised commitment entry, pending commitment entry, actual cost entry, committed revenue entry, pending revenue entry, and revenue entry. A user can also create an “estimate to complete” entry and transfer funds from one budget code to another.
 The Budget Tool allows a user to customize the budget by hiding or viewing columns as needed, as well as sorting by any column heading. The display follows a familiar rows and columns format, similar to that of a spreadsheet. One advantage of this tool is the ability to generate totals and subtotals for budget entries automatically, based upon a user-defined budget structure. The tool allows the appropriate users to access any value and display the detailed history for that transaction. The Budget report may be printed to a local or network printer and allows a user to export to common file formats. This tool allows a user to lock the budget to prevent further changes to the original. After locking the budget, transactions apply to the corresponding revised columns only.
 Additional functions which may be added to the budget include but are not limited to the following: enterprise-wide budget control and spending constraints across multiple projects; etc.
 Contract Tool
 A contract is a legal agreement between the buyer and the vendor defining a scope of work. A contract may contain billing, terms, items, cost, shipping, terms and conditions, notes, and payment information. The contract tool can generate a contract as a standalone process or can be initiated automatically from the Bid processes; the Bid process feeds into Contracts. The Contract tool may automate a collection of the boilerplate legal text and other variables, such as name of the buyer, the name of the vendor, the items to be built or delivered, the terms of the contract, the costs of the items, the conditions of payment, and so forth, into a single electronic document.
 Change Orders to contracts are also legal agreements between the buyer and the vendor detailing the change to a scope of work. Change events leading to change orders such as revisions to item specifications, requests for information, etc. may be consolidated to create a change order to a contract.
 Application for Payment Tool
 The Application For Payment Tool generates payment request documentation. The contract's schedule of values provides the line item details of the application for payment, ensuring consistent data entry. The user can link and include change orders for timely billing and payment processing. It links application requests to the Budget Tool for accurate cost and revenue management and reporting.
 Invoice Tool
 The Invoice Tool generates and submits an online invoice to initiate the payment process and notify users of current requests. The tool set provides tracking and management capabilities. The purchase order provides the line item detail for the invoice, ensuring consistent data entry. The user can link and include change orders for timely billing and payment processing. This tool also links invoices to the Budget Tool for accurate cost and revenue management and reporting.
 Procurement Toolset
 The system Procurement Solution offers a complete and centralized electronic process to organize, send, receive and analyze procurement documents and processes. Users in the supply chain can define procurement needs, review and award bids, issue and track contracts and purchase orders, and track the procured goods and services utilizing real-time project information all through one system 1000. The Procurement Tools automate bidding, purchasing, shipping and receiving, while facilitating process efficiencies.
 Bidding Tool
 A bid is a formal request sent to vendors requesting that they review the project requirements and submit responses indicating how much they would charge to work on the project or supply materials. The Bidding Tool is composed of the following functions: Qualifications (including the Qualification Request Wizard, the Qualification Response Wizard, and the Qualification Review Wizard), Bids (including the Bid Package Wizard, the Bid Response Wizard, and the Bid Review Wizard), and Request for Quote (including the RFQS Request Wizard, the RFQ Response Wizard, and the RFQ Review Wizard).
 A detailed description of the Bidding and RFQ tools is provided below. As will be understood from these descriptions, the Qualification toolset—Request, Response and Review—operates in a similar manner.
 Additional functions which may be added to the bidding and RFQ tools include but are not limited to the following: consolidation of sub-bid responses linked via an estimate for submittal of an overall bid response; enterprise-wide bidding consolidating procurement across multiple projects; etc.
 The Qualification process is the act of ensuring that a company is suitable to perform work or provide materials for your project. The system of the present invention provides the ability to qualify vendors and/or services before bidding and purchasing. Qualification is an information gathering process that can be used for screening purposes. Before sending out bids, a user can qualify vendors to ensure they have the credentials required to perform the work in the bidding process, saving both time and money y. Credentials are evidence or testimonials concerning right to credit, confidence, or authority. When a user sends out the bid, one of the options is to send the bid only to pre-qualified vendors.
 Qualification Request Wizard
 A Qualification Request is a request that is sent to prospective bidders to determine their qualifications prior to entering the bid process. The Qualification Request Wizard allows a user to create and issue qualification requests to prospective vendors. This wizard allows a user to indicate the type of credentials a user wants the vendors to provide for this qualification as well as create a user's own questions for vendors to answer, including attached reference documents, if desired. A unique advantage to this process allows a user to select which vendors will receive the qualification request from either the customized company vendor list or the entire database of available vendors. Optionally, the list of vendors can be published, so that each vendor sees who else was included in this qualification, or this information may remain private. Once the Qualification Request is complete it may be published with the attachments, questions, and comments. Vendors have the option of accepting the qualification request and providing the requested information, or declining the request within the designated time frame.
 Qualification Response Wizard
 A Qualification Response Wizard allows vendors to provide a response to the credentials, requirements and questions contained in the qualification. The Qualification Response Wizard displays a summary of the credentials and requirements the vendor must supply and any questions the vendor has to answer. This process then allows the vendor to send the completed qualification response back to the original requestor electronically.
 Qualification Review Wizard
 A Qualification Review Wizard allows the originator of the request to review and compare the qualification responses, and select the qualified vendors. This step in the process displays the qualification request description, vendor list, requirements the vendors are required to match and questions the vendors are required to answer. One advantage to this process is the unique ability to allow the originator of the request to view the credentials and the answers to questions for all bidders as a side-by-side comparison. This process allows the originator to then identify selected vendors as being qualified, based on the comparison.
 Bid Package Wizard
 The Bid Package Wizard is a step by step process that assists in the creation of a bid request. Often bidders source materials or request bids from sub-contractors to create their response to a particular bid request. The Bid Package Wizard has a feature to import items from another bid request, which one can then edit and incorporate into their bid requests. This is a shortcut way of entering the sub-bid items without having to re-enter them manually.
 Each bid can have attached drawings, specification documents, item specifications (from the Item Specification Tool), and file attachments. Some advantages to using the Bid Package Wizard include the ability to provide bidders with special instructions, schedule meetings for bidders to attend, and import a list of existing item specifications or manually create a bill of materials forth bid package. A benefit to using this wizard is the ability to create one or more alternative options for the bid; each alternate has its own set of drawings, specifications, item lists and attachments.
 An advantage that saves time and effort is the ability to select bidders manually, or automatically include previously qualified vendors from a Qualification Request. A company can choose to publish its vendor list to allow bidders to know who else has received the bid package.
 When the bid is issued to prospective bidders, it contains the issue date, due date, and anticipated award date. This process even allows changes to be made to an issued bid by creating an addendum in the Bid Review Wizard. An addendum is document describing an addition, change, correction, or modification to contract documents. An addendum is issued by a the author of the bid package during the bidding period or prior to the award of contract, and is the primary method of informing bidders of modifications to the work during the bidding process. Addenda become part of the contract documents.
 The bidders can either decline to participate or they can accept. If they accept, they review the materials attached to the bid and prepare a response.
 Bid Response Wizard
 A bid is a complete and duly signed proposal to perform work (or a designated portion thereof) for a stipulated sum. A bid is submitted in accordance with the bidding documents. The Bid Response Wizard is the mechanism through which bidders respond to the bid package. This wizard parallels the Bid Package Wizard. Any information specified in the Bid Package Wizard can be viewed by the bidder in the Response Wizard.
 The bidder can view drawings, specification documents, attachments, and item specifications, as well as any alternates. The list of bidders is not available unless the company has chosen to publish the vendor list.
 The Bid Response Wizard allows the bidders to enter a response for each breakdown on the bid package and review the addenda for each bid. The review includes descriptions, drawings, specifications, items list, attachments, alternates and cost from any previous addenda and the original bid.
 This wizard allows the bidders to generate requests for information (RFI) messages. These are messages to various users that request some type of information a vendor feels is necessary in order to respond to the bid. This feature also displays any RFIs that need to be answered.
 Bid Review Wizard
 The Bid Review Wizard allows a user to review bid responses, including the description, drawings, specifications, item list and attachments from the Bid Response Wizard.
 This review process allows a user to issue an addendum to make changes to the original bid package. An addendum can specify the same attributes as the original bid: for example, drawings, specifications, item lists, attachments, cost forms and so forth.
 Just as the bidders may issue an RFI, the same ability is provided to the reviewer in order to respond to the bidder or gather more information.
 The advantage to using this wizard is the ability to view the bidders' responses side-by-side to facilitate comparisons and award the bid from the comparison screen. This review can be used to compare the Quantity, Unit Cost, Units, Labor Rate, Hours, or Lump sum breakdowns between vendors for any specific bid/RFQ item.
 Request for Quotation
 Request for Quotation (RFQ) is a simplified Bid Package. A similar process of issuing the request, communicating with bidders, and reviewing responses is followed. For RFQs, a user has the option of simply awarding the RFQ, or awarding and automatically generating a purchase order.
 Purchasing Tools
 The Purchasing Tools provide a complete means for requesting, responding to, and reviewing purchase orders which integrates with the Procurement Tools. A user can track and management purchases electronically with project partners and vendors who are part of the system, as well as those who are not a part of the system.
 Additional functions which may be added to the purchasing tools include but are not limited to the following: consolidation of requisitions into purchase orders to the appropriate vendor(s); enterprise-wide procurement across multiple projects; etc.
 Purchase Order Request
 The Purchasing Tool electronically creates, issues, receives and tracks the history of purchase orders (POs). Some system processes, such as Requests for Quote, can automatically generate purchase orders upon issue. The Purchasing Tool directly relates to the Shipping and Receiving functions of the Order Fulfillment Tool.
 Detailed item specifications and other project related information found within system 1000 can be attached to the purchase order, according to the individual line item or as a file attachment. The unit cost, tax, and total cost are automatically calculated to allow for accurate budgeting. All of the information is sent to the vendor as an itemized list for fulfillment.
 The Purchase Order Tool allows a user to select a vendor from the company's vendors list or locate a vendor in the system and indicate the Bill To and Ship To addresses for the company. A user can also identify a contact person at the vendor company to approve the order.
 This process also allows a user to select stored “prefabricated” notes or comments. This saves time by not insisting that a user type a new note for every purchase order. A user can select the access level for each note; a private note can only be viewed by its creator, a company note can be viewed by anyone in the company with access to the purchase order process, and public notes are available to anyone with access to the purchase order.
 The history of the purchase order displays any change orders created and the notification log, which tracks and identifies anyone who has created, changed, or modified this purchase order.
 This tool provides the ability to generate Requests For Information (RFI). The request, as well as “carbon copies”, can be sent to one or more users.
 One of the greatest advantages is the ability to include user definable standard legal terms and conditions that are available to the vendor when they review the purchase order.
 This process then allows a user to issue the purchase order to the vendor electronically if the vendor is a licensed member of the system 1000 as defined by the company administrator or a user may print the purchase order and manually contact the vendor.
 Purchase Order Response
 Once the licensed vendor receives the purchase order request notification, they have the opportunity to review the request in detail before committing to approving or declining the request.
 The purchase order displays in a preview format providing the opportunity to print the purchase order or save the file in common format.
 The history of the purchase order is available to the vendor to ensure they are reviewing the most recent version, in the event that a change order may have been issued.
 The vendor also has the option of issuing an Request for Information (RFI) to the buyer, ensuring open and accurate communication between both parties.
 Once the vendor has determined to accept or decline the purchase order request, the system provides the ability to attach comments regarding the decision about the purchase order.
 This information is sent to the buyer with an e-mail that confirms the acceptance or decline of the purchase order request.
 Purchase Order Review
 Upon vendor approval, the Purchase Order Tool automatically updates the budget with the committed costs. The vendor sends notification informing the buyer of the acceptance of the purchase order request.
 The review process allows a user to preview the response from the buyer, which includes the printable version, any requests for information and an updated history of events for that purchase order. In addition to all of these capabilities, a user may also change any information on this purchase order and re-issue the order. This change creates a new tracked and numbered version of the purchase order and notifies the vendor automatically.
 Order Fulfillment Tool
 The Order Fulfillment tool allows users to track shipping and receiving of items electronically via an Internet based interface, or via email, or via the Teamwork Toolset.
 Additional functions which may be added to the order fulfillment tool include but are not limited to the following: staging and routing of items required for the project; expediting of items required for the project; inventory control and work orders; etc.
 A user can use this function to notify the buyer, via e-mail to the company contact's message center, of the items which is being shipped.
 This process requires an approved purchase order that contains the items which are being prepared to ship. The Shipping Tool provides the flexibility of shipping all of the items at once or sending a partial shipment with comments to the buyer.
 This process also tracks the status of purchase order items. The history log is a tracking mechanism for the shipments completed for this purchase order. The item number (item specification number), the quantity that has been shipped, and the date that shipment was recorded, appear in the history log.
 The receiving tool enables a user to electronically flag the date of the received items. This tool also allows a user to notify the vendor that the items were received at the job location. A user may use this process to access the tracking history of the items once they have been received as well as authorizing payment.
 Additional functions relating to asset management which may be incorporated into the system include but are not limited to the following: bar coding of items; tracking of maintenance, replacement, and/or retirement of items including planned and actual occurrences of such events; tracking of aging and/or depreciation schedules of items; tracking of inventory and allocation of items; tracking work orders and/or requisitions for repair, replacement, and/or acquisition of items; forecasting of replacement or repair costs; forecasting of contract renewal requirements and costs; assignment of cost for use of items; and the like.
 Additional functions relating to business partner management which may be incorporated into the system include but are not limited to the following: tracking of distributors, suppliers, and/or manufacturers (i.e., supply chain) of items; tracking of item assembly and components through the supply chain; links to inventory availability from supply chain; links to customer items and purchasing including revenue and/or inventory requirement forecasting; and the like.
 Project Teamwork Tools
 The Project Teamwork Tools offer users a complete electronic process to manage and control asset and lifecycle cost from a central point. Intelligent documentation begins in design as noted above and is compiled throughout the asset creation process. This provides a complete, integrated, referenced and searchable project record.
 All specifications, drawings, documents, and costs are generated and maintained within the database ensuring that all project history and legacy data is readily available. This unique combination of tools provides an online management solution and a new dimension in continuity and efficiency for designers, builders and owners.
 Collaboration Tool
 The Collaboration Tool allows the members of a project team to coordinate their activities and share information. This module allows file sharing, messaging, comments, and discussions for each project.
 A flowchart of the general processes available in the collaboration tool is shown in FIG. 7A. In FIG. 7A each box represents a programmably linked page or function selection from a menu item on, for example, a web page displayed in a browser.
 The collaboration tool is generally access from a toolbar link 702 on a main page provided by the application server to the client computer 1050. This presents a collaboration page 704 to the user from which the user can select any number of pop-up menu commands to perform collaboration functions. The collaboration page 704 includes a collaboration tree showing uploaded files 710 that a user wishes to share with others on the project and allows a user to view 718, upload 708, download 730, discuss 760, and comment 726 on each of the files. The Collaboration Tree is composed of folders and files, similar to standard software file systems. New folders can be created as needed. The user can create new folders 712 in the tree and manipulate files within folders.
 Files that are uploaded into the Collaboration Tool are accessible from several other parts of the system. The files uploaded here can be used as attachments on bids and RFQs, as pictures for item specifications and so forth. One file or multiple files can be uploaded at one time.
 One unique feature of the Collaboration Tool is the ability to create document sets 714. A document set is does not contain files, but rather contains “shortcuts” or “pointers” to files another folders. Document sets can be used to collect files that relate to a given task without maintaining duplicate copies of the files. One copy of each file is stored in a folder somewhere in the Collaboration Tree, then a shortcut in a document set points to that file. Multiple shortcuts can point to any single document. This ensures that everyone can access the most updated information while only one user is maintaining the file.
 Another unique feature is the available history and status 738. A user can view the current status of any file in the Collaboration Tree, including the revisions, the name of the person(s)accessing the file, and the date and time it was accessed. A file log review function is also provided 740.
 The greatest advantage to this tool is the ability to share information with only specific users. The Collaboration Tree allows a user to assign access and permissions to a “Share Group” 750.
 A Share Group 750 is a named set of users who can access the portions of the Collaboration Tree with a specific set of permissions. The Project Administrator defines sharing options for collaboration groups. Any user assigned to the project can be assigned to a collaboration group. A user might create a number of collaboration groups for different management purposes.
 Users can perform share group searches 752 and review group lists 754, as well as create new groups 758.
 The collaboration page 704 includes links to a file viewer 728 as well as a library function allowing the user to checkout 734 and check in 736 files.
 An online discussion forum 760 is also provided. Users can generate on-line messages, view messages from others and reply to others' messages in a familiar on-line chat format.
 Additional functions which may be added to the collaboration fulfillment tools include but are not limited to the following: document logs tracking revisions and publication of documents; document type tracking and attribute assignment; document links to virtual areas; etc.
 Request for Information (RFI) Tool
 A standalone, Request for Information tool is a more extensive version of the functionality available within the Bid, RFQ, and Purchase Order Tools. This is a focused tool that allows a user to create a message requesting information. The added functionality allows a user to title the RFI, request a date for a response, indicate the cost or time impact of the requestor the project and attach any files to the request. This tool also allows a user to search for and track the history of all RFIs. A graphic depiction of the collaboration process is shown in FIG. 7.
 Additional functions which may be added to the RFI tool include but are not limited to the following: routing and approval of RFIs and their responses; linking of RFIs to change events; etc.
 Meeting Minutes Tool
 The Meeting Minutes Tool allows a user to manage, schedule, record and share meeting information. A Meeting Minutes Manager allows a user to create meetings, organize them by type, create and edit meeting minutes and schedule future meetings.
 A Meeting Minutes Wizard is provided to allow a user to determine how the meeting information will be carried forward to future meetings or what previous meeting information will be included in the current meeting minutes. Once the type of the meeting is selected and the user has determined which information will carry forward into the meeting minutes, the user may set up the meeting(date, time and location), create an agenda and invite attendees to the meeting.
 The meeting agenda is interactive and allows users to flag agenda items as they are addressed. The system automatically transfers any agenda items that are not addressed to the next scheduled meeting. This process serves as a reminder to cover items that may not have been covered in previous meetings and assists in organizing and completing tasks. This tool also allows a user to import information from one meeting to another in the case of recurring items or topic continuation from meeting to meeting. This feature prevents the user from re-defining any repeating information between meetings.
 This tool can also be used to take meeting minutes, share the information and address action items. Action items function similar to the agenda items, but allow a user to assign individuals and completion dates to tasks. A user may create a distribution list for meeting information. Any changes to upcoming meetings, meeting minutes, attachments, or action items maybe distributed to the members involved in the meeting.
 Additional functions may be added to the project management tools of which, include, but are not limited to the following: submittals for items; tasks and calendar items linked to business objects in the system; as-builts for items; and the like.
 Administrative Toolset
 The following functions are used in the system 1000 to manage projects.
 User Licenses allows a user to use the functionality suites of the system 1000. Several licensing packages are available: Core, Design Suite, Procurement Suite, Supplier Suite and the Management Suite. Each licensing package allows a user to use specific sets of functionality for the system 1000. A user may purchase one package, a combination, or all of the packages depending on the company's needs.
 The Company Administrator agrees to the system terms of service and specifies licenses for their company employees.
 The Company Administrator is the first user for any company and is responsible for setting up licensing, company information, company defaults, subsequent users, vendors, and so forth. The Company Administrator does not have access toady projects or “work”; this is solely an administrative role. The licenses specified in User Licenses correspond to the Design, Cost Management, Procurement, and Manage Solutions.
 A User Profile is a collection of information specifically relating to a user. This information is mainly used for contact purposes. The user profile contains information such as: Company Name, Full Name, Nickname, Employee Number, Department, Primary Function (Role), Manager's Name, Assistant's Name, Primary E-Mail, Primary Address, Business, Fax, Cell Phone Numbers and so forth. When a user accesses the system for the first time, they need to create a user profiles well as change their user name and password. Over time, any changes to name, telephone, address, position, company, and so forth, will need to be maintained using this process.
 This profile information is used in the company contact processes as well as the user search process. This process assists other users in locating contact information.
 Company Wizard
 A Company (Setup) Wizard is provided to allow a user to create a profile for an entire company. This function also allows a user to setup specific information regarding business processes. A company is an organization, group, business enterprise or firm that performs services or provides products within the system.
 This company information is stored in the database and if Company Administrator so chooses, general information will be available to other companies within system 1000.
 The benefit to having a company visible to other companies in the system is the ability to generate new business for the displaying company.
 Any profile information for a company will remain private and can only be used to qualify that company for bids or RFQs (Requests for Quote) if the company chooses to be involved in those processes.
 The information that a user may define to create a company profile includes the company logo, departments, employees, branch offices or alternate addresses, company contacts and the roles they assume for contact, as well as various professional licensing, bonding, and other qualification information.
 One additional feature of this wizard is the notification function. This function notifies a user if a company has already been entered into the system.
 A contractor is a person or company that agrees to furnish materials or perform services at a specified price, especially for construction work. When a contractor joins the system 1000, it can notify those members that the company is now ready to do business through system 1000.
 A company administrator can set up a number of different types of addresses, such as Headquarters, Accounts Payable, Accounts Receivable, Remit To, Job Site and more. If a billing address is set up here, purchase orders created for the company will automatically refer to that billing address. The headquarters address will display as the default address every time the company name appears in search results.
 The benefit of the employee list is that a user only need to include this information once, as opposed to every time the user needs to associate employees with a new project.
 Creating contact information in the Company Wizard saves the effort of entering the information repeatedly and reduces the risk of data entry errors. A user may set up employees with relationships to indicate which of the company's employees may have special responsibilities. For example, if all purchase orders for a company within the system were to be e-mailed to Ellen Smith, you would create a relationship between purchase orders and Ellen Smith.
 The Company Wizard allows provides the ability to record company credentials, such as licenses, minority business qualifications, bond and insurance information, and some other general credentials. This information is used to compare the company's qualifications against bid parameters when someone is searching for qualified vendors or subcontractors.
 Prefabricated Notes are blocks of standardized text for use in various situations within the system. For example, if a company always places a reminder about billing terms on purchase orders, the appropriate text of this reminder can be stored in the system and used as needed. Storing text in this fashion saves the time and trouble of typing the information repeatedly and reduces the possibility of errors.
 The system also includes a set of Project Defaults. Project defaults are similar to company defaults, but they apply only to the specific project for which they are defined. Project defaults override company defaults. Defaults can be set at the project level for project related functions, including the following: Meeting Minute Types, Item Specifications, Purchasing, Bids, Requests for Quotes, and Budget Codes, as well as other areas of the system.
 In addition, general company defaults can be customized at the project level. For example, currency and time zone may be modified.
 A set of Company Defaults is also provided. The Company Defaults process allows customization of the functionality of the system of the present invention in order to meet the needs of a company and how a company conducts business. General information may be defined by the user. For example, currency, time zone, and nomenclature may be customized throughout the system. Nomenclature is a way of organizing categories of work for each company. The default major category is a “property”, and the default sub-category is a “project”. This default nomenclature may be changed to any terms that suit a company's needs.
 Disciplines (Plumbing, Electrical, Architectural, and so forth) are used in later processes to categorize files, item types, item specifications, and to grant or restrict access to information. A set of default disciplines is provided, but may be customized. Disciplines may be added, edited, or deleted to suit a company's needs. The disciplines created or edited in this process become defaults for any future projects created by that company.
 In one embodiment, the system may include a number of predefined attributes. In FIG. 11, these attributes are divided into two exemplary categories: General and Vendor. Companies may choose to work with one of a number of the industry standard codes available from any number of agencies, including the Construction Specifications Institute (CSI) Masterformat codes and in one embodiment, the default classification tree may be based on these codes.
 The roles and permissions may be defined, as well as security access for each role throughout the system. The system supplies a list of default roles. The default roles may be added, edited or deleted as necessary to suit a company's needs. The company can then set the permissions and access to disciplines for each role. The main benefit of this process (associating roles to permissions to discipline access) is the ability to provide users with the information they need and restrict users from information from which the company determines they should be restricted. A discipline is a broad area of operation with a project. A set of default disciplines is provided with the application, but the user can add as many as necessary to suit the needs of their project. Disciplines a reused to group item specifications. Users can be assigned permission to a role to perform tasks within specific disciplines.
 The Company Defaults process allows the company to set up the default numbering scheme for relevant processes, including: Item Specs, Purchase Orders, Bids and RFQ packages, and Budget Codes An additional utility is the Project Association Tool. Employees in a company may work on multiple projects at once. The Project Association process may be used to assign employees to specific projects, or remove users from the project.
 Property Creation Tool
 Yet another utility is the Property Create Tool. This tool is used to create a new property and its default project. Property is something tangible or intangible to which its owner has legal title. A property is considered the largest hierarchal space in a virtual area. Property is the generic terminology for a design/build entity; depending on the nomenclature defined in Company Defaults, this term can be changed to “Asset”, or a user-defined term or phrase.
 This process only creates the property and project and associates them to each other. The setup tool is then used to set up detailed information for the property and project.
 Vendor Reference Tool
 Another administrative tool is the Vendor Reference Tool. The Vendor Reference List allows a company administrator to maintain a list of two different types of vendors. Vendors who have joined as members of system 1000 are called licensed vendors. Those vendors who have not joined are called non-licensed. Information about licensed vendors is available in the system and is maintained by that vendor. However, each company must maintain its own non-licensed vendor list. The company can maintain a set of addresses for each non-licensed vendor, much as a user can maintain a set of that user's own company addresses.
 This process enables a user to send an invitation to a specific contact at a vendor company to join the system 1000. The contact selected receives the invitation to the system and becomes the Company Administrator when that company joins.
 There are two types of contact lists available. The first list displays a list of vendor contacts. These contacts are employees of the vendor which a user company may use to contact and conduct business with this vendor. If this is a licensed vendor these contacts were defined by this vendor. If this is a non-licensed vendor, the user must maintain these contacts. The second contact list allows a user to associate contacts from the user's company to each vendor. A company may have specific employees that handle business with certain vendors. These contacts are maintained by the company regardless of the type of vendor.
 Once a property is created, the Project Create Tool allows a user to create a new project for the existing property. A Project is a sub-category of work below the Property. The system allows a user to have an infinite number of projects and subprojects created for the property. This process differs from the Property Create process because a new property is not created.
 Terminology Customization
 In a further unique feature of the present invention, while the term “Project” is the default terminology for a design/build project; depending on the nomenclature defined in Company Defaults, this term can be changed to “Asset”, or a user-defined term or phrase. This can be performed by the company administrator to allow users familiar with the particular company's default terminology ease of use in the system. Moreover, each screen can be further “skinned” with a custom set-up for a particular user. In a basic fashion, this can involve simply placing the colors and logo of the company on all screens. Further enhancements can comprise reordering columns and page setups to accommodate users.
 Access Control—Project Admin
 The user that creates the project becomes the default “Project Administrator,” regardless of the name entered for the Project Manager. The Project Administrator is the only person allowed initial access into the Collaboration Tree for this project. The Project Administrator must create a share group and assign other project users access to the Collaboration Tree.
 Project Setup Tool
 Once the project is created, a Project Setup Tool is used to add all relevant data to the project. A flowchart of the project set up process is shown in FIG. 8. In the Project Setup process, a user can maintain and update the project name, description, and Project Manager contact information. The user can also assign a budget code number to this project and upload a project picture to display on the Project page.
 As in other processes, a user may either accept the company contact list or create an additional contact list specifically for this project. The list of project contacts acts as a directory of the people other than employees and vendors associated with the project.
 Certain steps in a Project Setup are required: filling in project information 804, setting up a virtual area 808, setting up roles for users in the system 822, setting up users 834 and setting up the purchasing approval chain 838. Again, each box in FIG. 8 represents a programmably connected display page allowing user interaction with the data on a property—project—user basis.
 The first step in the project setup process is adding project information at step 804. A file search may be used to provide image information for the project from uploaded files in the system.
 Next, optionally, contracts may be added via a contact page 806. The contacts page 806 allows adding or viewing of contact information 810 on a project or system-wide basis.
 The user is next required to set up a virtual area 808. Each project has a virtual area. The “Virtual Area” is a concept for organizing and representing a three-dimensional physical space as a two-dimensional hierarchical structure. It refers to the physical breakdown of a property or designed object. Virtual Areas are used throughout the system to organize a project and assign security permissions, specification counts, budgeting, and other functions. A virtual area is the hierarchy showing the structure of the project. The virtual area can be organized to any level required for a project. The Virtual area setup is discussed below. A company's users (employees) and vendors (sub-contractors/suppliers) will only view and be responsible for certain sub-set physical areas as defined by the virtual areas to which they have access.
 Next, optionally, disciplines may be set up at 812. An add/edit discipline page is provided for adding disciplines to the project. This process allows a user to maintain the list of disciplines (trades) for the project. The list defaults to the list defined in the Company Defaults. A user can create disciplines as necessary for the project.
 Next, classifications may be added at 818, 820. This process allows a user to view, add, and delete items on the classification tree used for this project. The default tree consists of classifications defined in the Company Defaults. A user can create project-specific classifications. Similar to the Company Defaults process, a user may also set up roles, permissions and disciplines. This information only needs to be set up for the project if the user does not want to use the information defined in the Company Defaults process for a specific project.
 The user is next required to set up roles at 822. A Role is a function or position that can be assigned to a user. A default set of roles is provided, but any number of roles can be added in order to customize each (Project). The actions available to each user in the system are dictated by the role assigned, as well as by the discipline access. The access level is also dependent upon the license granted to that user. Hence, the page includes a discipline setup page 826 as well.
 Project Partners may next be set up at step 828. A company search 830 allows users to quickly add company information to the project partners setup. In addition, role associations can be viewed at 832. The Project Partner Setup feature in this process allows a user to assign a specific partner (vendor/supplier) to a specific role for a each Virtual Area. When a user accesses this function, the user may view the partners already assigned role(s) for this project. After a user assigns a partner a role, the system generates an e-mail invitation to the primary contact of that company.
 The user is next required to set up users 834, whose information may be retrieved from the system using a user search 839. A role association view 840 is provided for the user setup page. The User Setup feature allows a user to assign specific roles to individual users (employees) for a specific virtual area within the Project. This is similar to the process a user goes through for contractors. After a user assigns a role, the system generates an e-mail to that user informing them of the role assignment.
 A final required step is the setup of the purchasing approval chain 838. The system allows users to add individuals to the purchasing approval chain 839, change levels of users 842, or edit approvers 844. This is a unique feature of the Project Setup process. The approval chain is defined as the departments in a company through which the purchase order “paperwork” flows for approval. Using the system of the present invention, this is an electronic workflow. Set up the approval chain in the order the approval must occur. Then, set up specific dollar value limits on approval levels and specify which specific company users assigned to the project have the approval authority for these levels. Virtual areas can also be graphically defined in the CAD system.
 The user may then proceed to a vendor setup, if desired, or return to the project page.
 Virtual Area
FIG. 9A shows the process for setting up a virtual area. As noted above, the concept of a virtual area is a further unique feature of the present invention. By organizing and representing a three-dimensional physical space as a two-dimensional hierarchical structure, it provides system users with a unique way to physically breakdown a property or object to perform any number of functions, outlined throughout the system to organize a project and assign security permissions, specification counts, budgeting, and other functions.
 As shown in FIG. 9A, each virtual area may comprise a tree 902, the top-most item of which is the largest area that may be referred to in the project. This virtual area is created by default when the property and project are created. Virtual areas may be viewed in a CAD program visually and the CAD Intelligence plug-in allows users to select virtual areas and “hover” a mouse over the area to provide a pop-up menu providing the functionality shown in FIG. 9A. Subsequent levels in a virtual area are all created with the Virtual Area Setup feature.
 The virtual area hierarchy can extend down many levels, depending upon a user's needs. For simple jobs, there may only be one or a few virtual areas. For large commercial construction projects, there may be hundreds or even thousands of nested virtual areas. The virtual area tree can be expanded and collapsed as needed to view specific levels of the project. New virtual areas can be added with a mouse click.
 As shown in FIG. 9A the virtual area may be edited directly at 906. The Virtual area will provide an item specification list 908 base on the definition of the virtual area. The virtual area may then export reports 910, allow an edit filter 912, and provide a link to editing items in the Item Spec Wizard, set forth below with respect to FIG. 12. In the item specification for the virtual area, data for each item in the item specification is arranged in rows and columns, as illustrated in FIG. 9C, allowing the user to click on a Quantity purchased 918, quantity pending purchase 920, quantity bid 924, quantity required as components 926, quantity shipped 928, quantity received, 930, quantity specified 932 or quantity drawn 934.
 As illustrated in FIG. 9B, the virtual area may be defined graphically in a CAD application as well. Shown in FIG. 9B is a partial floor plan of a building with a first virtual area definition 980 and a second virtual area definition 982. These definitions are created by clicking and dragging with the appropriate tool in a CAD program and selecting a “define virtual area” selection from a pop-up menu.
 Additional functions pertaining to workflow in the system include but are not limited to the following: sequential and/or parallel routing, tiered, linear, parallel, and/or data driven approval, and based on users, groups, and/or roles including delegation and permission to deviate for each type of business object; selection of workflow for a project with defaults for each company; workflow control including date limitations and/or exception requirements; task lists and responsible parties according to work flow; required fields and/or permitted per workflow step; deviation and/or exception handling per instance of a business object; and the like.
 Utility Toolset
 The following tools are available in all the aforementioned tool sets.
 Reports: Throughout the system processes generate printable reports. These reports display in each applicable process for preview. A command bar at the top of each display page allows a user to navigate through the pages of the report, download the report to the user's computer's local drive, or refresh the report to view any recent changes.
 An export function may be supported to allow users the ability to export the displayed report in several different formats; this includes Adobe PDF or Portable Document Format.
 Report Manager
 In addition to the ability to access these reports in their respective processes, a user may also create, run, and define reports within a Report Manager Tool. This tool allows a user to access one area for all of the available reports within the system.
 A user may also navigate through the pages of the report, download the report to the user's computer's local drive, or refresh the report to view any recent changes within the manager.
 Search Tools
 Search Tools provide list of searches is available from a search menu and is limited by roles, permissions, and licenses. A user may not see all of the items available on this menu, nor be able to access all of the searches. Each search has optional filter mechanisms to limit the number of results returned by the search.
 A Bid Search allows a user to locate and access previously created bids. This search also allows a user to delete unpublished bids/RFQs.
 A Documents Search allows a user to locate and attach files that have been previously uploaded to the system using the Collaboration Tool.
 An Estimate Search allows a user to locate and access previously created estimates.
 An Item Specs with Virtual Area Search allows a user to search for Item Specifications associated with a virtual area.
 An Item Spec Search allows a user to locate item specifications relating to a project. This search returns only those item specifications which the user has permission to view.
 An Item Type Search allows a user to locate and view existing item types, including descriptions and classifications.
 A Property Item Spec Search allows a user to locate and view the virtual area association, occurrences, and total quantity of the item specification. This search provides the option to only select specific areas in which the item specification occurs.
 A Property Spec Book Search allows a user to view published item specification books.
 A Purchase Orders Search allows a user to search and display purchase orders (PO).
 A Qualification Search allows a user to locate and display qualifications.
 A RFQ Search allows a user to locate and access requests for quotation. This search also allows the user to delete unpublished RFQs.
 A Users Search allows a user to locate and contact users in the system.
 A Vendor Search allows a user to search for vendors and contacts. The Vendor Search allows for complex search criteria beyond the vendor name.
 A Request for Information Search allows a user to locate existing requests for information.
 A Virtual Area Specification List is used to view the items along with their associated specifications and counts within a given virtual area.
 Optionally, the list can be filtered using criteria such as classification and discipline. An Item Spec List can be sorted by item number or item name. From this list, a user can see the quantity of a given item specification for each stage in a project. A Virtual Area Specification List can generate an Item Cost Report or export information in a variety of formats, including Excel, Rich Text Format (RTF), Comma Separated Values (CAVE), HTML and XML.
 An Item Spec Filter is also provided, since virtual areas might include any number of subsidiary virtual areas and any number of item specifications.
 Announcements are a type of electronic bulletin board where a user can post messages for others to see. There are two different sets of announcements in the system: company announcements and project announcements.
 Announcements include the text of the announcement and its priority. It may also include a picture and one or more Internet URL links.
 Message Center
 A message center is an e-mail system for sending and receiving messages electronically over a computer network, as between personal computers or through the Internet. This Message Tool is similar to many other messaging or e-mail functions. A major difference in the system messaging tool is the ability to communicate within the system as well as with external addresses. An exemplary screenshot of a message center screen is shown in FIG. 7B
 Other unique features include the ability to require responses from recipients, create action item messages and RFI messages.
 Just as in any other messaging tool, a user may create, view, send, reply and attach files to messages. There is also an address book function available that a user may create individual users as well as groups of users for mail distribution
 System Operation
FIG. 10 shows a general relationship of the system tools and how they interact to modify data in the database. FIGS. 11-22 provide a item specification workflow example, and illustrate how parties use the system of the present invention to design, manage and build assets.
 The interaction of the purchasing system and the life of data in the system may be understood with reference to FIG. 10. Shown in FIG. 10 is a general representation of the how data is modified during use of the system by respective tools used in the system. As shown therein, the CAD intelligence plug-in 1010 and the specification build tool 1012 generally create, edit and delete data at the design phase of the project. Data from these tools is stored in the property specifications database. The data from the property specifications database can be used by the cost estimate tool 1032, budgeting tool 1034, contracting tool 1036, payment tool 1038 and invoice tool 1040 to generate reports, contracts, payments and invoices, and such tools can be used to also modify data and return the modifications to the property specifications database. The Publish tool 1060 is used when data is ready for output to vendors, contractors and other bidders. Once published, a log of the state of the data is taken, and added to a history file which is viewable in many of the tools of the system. The output of the publish tool is provided to the bid/RFQ tools 1062, the purchasing tools 1064 and the shipping and receiving tools 1066, each of which can return data which may be modified in the property database only when a reviewing user with authority approves of such modification.
 FIGS. 11-22 are flowcharts and screen shots showing how components of the system interact to use an item specification.
FIG. 11 is an overview diagram of the life of an item specification used in the system of the present invention. An item is any definable (in this case, drawn) object that is associated with a virtual area (physical space) and can be purchased. The purpose of this approach is to allow items to be defined, accounted for within a budget, and purchased through the system. Item Specs are objects that have detailed (or specified) requirements within a project. These are objects that are defined, budgeted, purchased, and then delivered to the project site.
 The example of an item specification used herein is an office chair, which is defined by attributes associated with that chair, such as the design, size, color, manufacturer and occasionally the cost. Item specifications can have components or attributes that further define the item specification.
 The fabric can be a component of the chair, but it is also a separate item spec. When creating item specs, the attributes need to be defined along with any components that need to be associated with that item spec. Components may be included in the CAD drawing, or can be specified independently.
 The lifecycle of an item specification begins with the drawing being uploaded to the system with the components previously defined. The defined item specification and its components can be defined and associated using the CAD Intelligence plug in. The item specification can then flow through the rest of the lifecycle processes. The flowchart below provides a high level description of the lifecycle of the item spec.
 The first step in the Item Spec Lifecycle can be to upload the drawing containing the item specification and its components to a virtual area (physical space) through the CAD Intelligence Interface at 1110. Note that Specs can also be defined by the specification tool.
 Next, at 1112, the Virtual Area Spec List page displays the items drawn and the status of each item. When the drawing is uploaded the Item Spec List displays the number of specs in each status.
 Next, at step 1114, the item is specified. This is accomplished through the Item Spec Wizard, which may, for example, be accessed through a hyperlink to an item number displayed in an html page showing a specification list.
 After accessing the item number the Item Spec Wizard allows the item to be specified or revised. Any information that was defined for this item specification using the CAD Intelligence Interface or the Item Specification Tool displays in the Item Spec Wizard.
 The Item Spec Wizard process flow is shown in FIG. 12. The Item Specs Wizard contains a general information page 1216 which allows the drawn item specification to be associated with an item in an online catalog created by the company and assigns this item to a budget code.
 One option of the general properties page allows the user to assign a budget code to the item specification to track the cost and status of the item specification via a Budget Code Search page and search for the existing budget code for that item.
 Once the system has returned the appropriate budget code it may be assigned to the item spec by user action. This action returns the user to the Item Spec Wizard-General Properties page. An example of this page is shown in FIG. 13. Pages shown in FIGS. 13A-13O generally correspond to each box in FIG. 12. Each page is designed to lead a user sequentially through the item set up process in the wizard. This sequence is presented in FIG. 12. The user then needs to navigate to the next step in the process, which is defining the item specification's attributes.
 On attributes page 1218 (FIG. 13A) allows Attributes to be defined to specify an item. Attributes include color, size, shape, distributor, vendors, contacts, etc. Defining these attributes ensures the correct item specification is bid, purchased and ordered for the project.
 Searches for users 1220, companies 1222, and vendors 1224 may be used in entering attributes for the components. Vendors may be added 1226 at this stage as well, and vendor information for existing vendors retrieved for added vendors 1228.
 Components 1230 (FIG. 13C) are child item specifications and associated with a parent item specification. In this case, the component is the fabric for the office chair. The components may be associated with the item specification in this process. Components must already exist in the system in order to associate them to an item specification. The user must also have the appropriate access to locate and view these item specifications.
 Because the drawing listed the fabric as a component this information displays on the Components page. This process allows you to add more than one component that may have been previously specified but not included on the drawing.
 If the user determines another fabric component needs to be added to the chair, the Items Search page 1232 (FIG. 13D) is accessed to locate other components of fabric for selection.
 After the component(s) have been searched, selected and accepted the Item Spec Wizard displays the newly added component(s) and allows the user to edit, remove or save the information (FIG. 13F).
 Next vendor notes 1240 (FIG. 13G) may be optionally added. These include any notes to the vendor(s) about the item specification. These are not required in order to specify the item, but are available as a matter of convenience.
 The user may locate and select prefabricated notes for this process. The company creating the item specification defines these notes in another process. The user may also type and format the notes to the vendor.
 Next user notes 1250 (FIG. 13H) may be provided in order to accommodate and support internal processes for the company creating the item specification. The user may include internal notes that are not available to anyone without the designated permissions to access these notes.
 The cost definition 1260 (FIG. 13I) is a required process of the system. The next required step is defining the virtual area association and the cost of the item. This information is required for RFQ (requesting quotes), Bids, and Purchase Orders. As shown therein, items may be added 1260-2, deleted 1260-3, and transferred 1260-4 to the project budget.
 Once this information is defined, the system transfers, tracks, and calculates the appropriate cost of each item and its component(s). This process allows the user to choose whether to calculate the cost of the component as one rolled up cost 1260-1 or as a separate item.
 Typically, if the item and the component are purchased together, such as the chair being sold with its component fabric already installed, then the component should be calculated as a rolled up cost. If the item and its component are purchased separately, such as when the fabric is not being installed on the chair by the vendor, then the item costs should be calculated as separate items.
 Another available feature of this page is the association of the item specification to the virtual area. The user may specify the quantity of item specifications for each virtual area. The user may access the virtual area page (FIG. 13J) to specify the quantities for each area of the property or project.
 If the quantity of this item specification is increased or decreased, the system recalculates the costs and displays the appropriate amount.
 Any calculated costs can then be transferred into the budget 1260-4 and calculated as pending cost or revenue. The Costs page also has a unique function allowing the user to view the details of each item specification per virtual area as shown in FIG. 13A.
 Next, a user can display the history of the Item Spec at 1270 (FIG. 13L). The history in this example is non-existent because the item specification has not yet been published. The history of an item specification does not begin until its first publication. Until that time, any changes made to the item specification are considered “Work In Progress”.
 After the item specification has been published, any changes then become an official revision and are tracked and available for display. This page will be revisited later in this document to show the history of an item specification after the publication.
 The next step in the Item Spec Wizard is defining preferences 1274 (FIG. 13M). Defining preferences allows users to determine the behavior of the item specification and the method of calculations for future processes within the item specification lifecycle. The preferences default to the calculation of the quantity of item specifications specified in the system minus the quantity of item specifications purchased. This provides the proper calculations of item specifications that do not include the quantity of item specifications included within a drawing.
 The user does have the option of specifying whether they would prefer the quantity of item specifications calculated by the quantity displayed in the drawing multiplied by the designated virtual area multiplier (usually 1) minus the quantity of item specifications purchased.
 The other information that may be defined in this step of the process is the waste factor. The waste factor is the quantity of the item specification that should be included in the cost, quoting, bidding and purchasing processes due to a certain amount of loss that may occur during the assemble or installation of the item specification.
 For example, if the user orders a chair with fabric as the component, the user may need to calculate a specific or percentage of that fabric that will go to waste when assembling the chair. In this case it was calculated that 10% of this item specification will go to waste and should be calculated into the cost and quantity of the item specification.
 The Spec Wizard also provides a report view 1276 (FIG. 13N). This page is a view of the item specification report that summarizes all of the specifications defined for this item specification. This is available for the user to review before publishing or finishing the item specification.
 Finally, an attachments process 1280 (FIG. 13O) allows the user to attach any images or documents to the item specification. These attachments are available for any user that accesses the item specification, such as through a RFQ (Request for Quote), bid, or purchase order.
 This process allows you to either search the system for previously uploaded images and documents or to attach files from the user's local drive (personal computer or local network). This page also allows users to upload images or documents from their local drive to attach to the item specification. Once the files have been attached to the item specification, the specifying step is complete. The Item Spec List shows that the item specification has not only been drawn but is also specified in the system.
 Returning to FIG. 11, once the specification wizard is completed, at step 1116, the item specification is then published. Publishing an item specification allows the item specification to be quoted, qualified, bid and purchased. This status indicates the item is no longer a draft (Work In Progress) version. To accomplish publishing, a user screen allows the user to select one or more specifications to be published and initiate publishing by selecting a “publish” button.
 If the item specification has components associated, then the components need to be published as well. To locate the item specifications that have a status of “Work In Progress” the user may use an accompanying search tool. Publishing of more than one item specification creates a specification book for the project. A specification book is a counted list of all published specifications.
 The publishing process requires a publishing date, which defaults to the current date, and a publishing number, which allows users to locate all of the item specifications published at this time and is used for tracking purposes.
 If the user determines that some of the item specifications selected for this publication are not ready, they may be removed from the publishing process before the user publishes.
 A confirmation message displays, confirming the item specifications have been successfully published and the specification book is created.
 After the item specifications have been published, they may be revised to change the attributes or define further details for the item. This status is referred to as a revision. Revisions are tracked to ensure the most recent version of the item is used and allows the ability to revert to a previous version, if applicable.
 Once the item specifications have been published, the specification book may be accessed and viewed from a report viewer page.
 Returning to FIG. 11, following publishing, the users may either request quotation (RFQ) or Bid Items to vendors. A “Request for Quote” (RFQ) is a solicitation for vendors to submit proposed costs for a project to the requestor in a competitive process. Requesting quotes is a common business practice as a means of evaluating suppliers of goods. The process described here illustrates the automation of the RFQ request, RFQ response, RFQ review, and RFQ award activities for an item specification.
 The RFQ request activity is initiated with the RFQ Package Wizard. This is a set of programmatically connected pages, which: create the RFQ data structure in the computer system; indicate the date the quote is due from the quoting vendors; select which vendors to which it will be sent; define the item specifications to be quoted; and allow attachments to be associated with the RFQ. These documents provide information to the quoting vendors about the item specifications they will be pricing.
 The RFQ process is comprised of a Request, Review and Response. A request is initiated by a company user responsible for procurement, while review and responses may be completed by vendors and contractors. FIGS. 14-17 show the Request, Review and Response proven flows. The actual page displays of the Request, Review and Response are configured in a manner similar to those set forth above with respect to the Item Spec Wizard. Like the Wizard each page is a series of steps to be sequentially taken by a user to complete the task. These steps are set forth in the figures.
 As shown in FIG. 14, the Request Wizard begins by importing the RFQ from the publisher. The RFQ Description step 1410 provides the user with the means to create the RFQ request. The user provides the RFQ name, description, and a contact name.
 The RFQ Description page 1410 also contains a unique RFQ number. This is assigned by the system and is a sequentially incremented compound number. The number can be composed of several different components, such as the project number, or the company number, or other user-defined attributes.
 The RFQ Description page 1410 also provides the user with the ability to create a sub-RFQ. If the user is a sub-contractor and wants to contract all or a portion of the RFQ to another entity, they can import the contents of another RFQ into the new RFQ they are creating. They can then add, change, or remove items from the sub-RFQ. This is quicker and easier than having to manually re-enter all of the items from the original contractor's RFQ. The contact list for the RFQ is provided to the RFQ description.
 The RFQ Items List is used to attach a list of item specifications to the RFQ package. Item specifications are typically the list of materials you require in the project, along with the criteria for which specific items will suit the project requirements. For example: instead of simply indicating a need for chairs, the user might specify a particular type of chair, from a specific manufacturer, made of a specific type of material, and so forth. The item specification outlines all of these requirements and the quantity of the item required. The Item Specifications within a virtual area 1416 are fed to the item list 1414.
 The RFQ Attachments step 1418 allows the user to attach files to the RFQ. To use attachments on this page, the file has to already be uploaded to the system. A file search process 1420 is provided to provide uploaded files to be selected.
 The RFQ Cost Form page 1422 is used to attach a list of anticipated cost items to the RFQ. The user can import a bill of materials from the Item List or manually add items to this page, or a combination of the two methods. For each item indicated on this page, the user indicates which breakdown type(s) they require for the item specification. The information for each item is arranged in a set of rows and columns, similar to a spreadsheet.
 Next, the user selects Vendors to indicate which vendors will receive the RFQ package at 1424. Vendors can be selected manually via a search 1428, or automatically included from previous qualifications 1426.
 The user may flag whether the vendor list will be published. If the list is published, each vendor will know which vendors received the RFQ. If not, the vendors will not know what other vendors also were solicited to quote and will be unaware of their competition.
 Finally, RFQ “issue invitation” page allows the user to issue the RFQ package to the prospective vendors. Before doing so, the issue date, the date responses are due, and anticipated award date are indicated in this step.
 The ability to access a report from the RFQ Package Wizard is available in this process. The report function may be used on the RFQ Issue Invitation page since all the information for the RFQ has been entered and the RFQ package would be considered complete at this point. The report can be printed or saved to an Adobe Acrobat PDF file formation for future use. A confirmation displays to inform the user that the RFQ Package Request has been issued and published to the indicated vendors.
FIG. 15 shows the steps performed by a vendor who is a member of the system in performing an RFQ response.
 The RFQ response activity is initiated when the RFQ package is issued. When the RFQ package is issued, the selected quoting vendors receive a message the next time they log into the system. This message contains a hypertext link to the RFQ Response Wizard.
 Once the link is selected, the description page 1510 gives the quoting vendor an overview of the RFQ package and allows them to either accept 1512 or decline 1514 the invitation to participate in this RFQ.
 If the vendor decides to decline the RFQ invitation, there are no further steps necessary within the RFQ Response Wizard. A message returns to the RFQ package originator indicating this and the vendor is no longer considered for the RFQ.
 If the vendor decides to accept the RFQ invitation and participate, they will use the rest of the RFQ Response Wizard to review the RFQ requirements and form their response.
 The RFQ Response Items List 1520 page is used to review the Item List attached to the RFQ package. Each item specification listed on this page may be viewed in detail by accessing the item Name link on the Item List Page. The page allows generation of reports 1522 in a PDF file format 1524.
 Next, an RFQ Response Attachments page 1530 allows the vendor access to the files attached to the RFQ. They can either download the files for use in their own systems, or they can simply view and print them with the built-in file viewer.
 A RFQ response cost form 1534 is the first interactive page accessible to the user.
 Up to this point, all the pages in the RFQ Response Wizard have basically been “view-only” pages. The RFQ Response Cost Form is a page where the quoting vendor actually enters their proposed cost for each item of the RFQ package. For each of the breakdown categories of each item, the vendor types in their response in the Qty, Units, Unit Cost, Labor Rate, Hours, and Lump Sum columns.
 An optional request for information generator 1540 is provided. In the course of responding to the RFQ, the vendor may have questions. A vendor can use the RFQ Response RFI (Request for Information) page to generate messages 1542 to various users in the system. These are messages to various users that request some type of information necessary to respond to the RFQ. For example, the vendor may have questions to the RFQ originator to clarify certain points about the RFQ. Or the vendor may have questions for their suppliers or associates.
 This page lists all requests for information relating to the RFQ. The vendor can create new messages 1542, view existing messages 1546, and reply to existing messages 1548. The Request for Information page works in accordance with standard e-mail application paradigms.
 Finally, RFQ Response Issue page 1550 allows the vendor to issue their response to the RFQ request. The response information is sent back to the user that originated the RFQ request.
 A RFQ Confirmation may be displayed to notify the user that the RFQ Package Response has been published.
 The process for reviewing an RFQ once received by the originating user is shown in FIG. 16. The RFQ review activity is initiated with the RFQ Package Review Wizard. This is a set of programmatically connected pages, which: receive the responses from each responding vendor; compare the item breakdown from each responding vendor in a side-by-side manner; select one or more vendors to whom to award the RFQ; award the RFQ to the selected vendor(s); and optionally create the purchase order for the items quoted.
 The RFQ Package Review Wizard can be accessed from a link 1605 in the RFQ Response message from one of the responding vendors, or from the RFQ Search page 1612.
 When a vendor issues their response to the RFQ, a message comes back to the originator of the RFQ package. This message contains a link in it that can be used to see the vendor's response.
 A RFQ Package Review Wizard Summary 1610 is the first step in the review process and summarizes the RFQ package. Addenda and bulletins 1614 from the originator of the RFQ may be provided at 1614 and are added to the Bid Package Wizard 1618 (described below).
 An RFI 1620, similar to the Response RFI, allows originators reviewing the RFQ response to ask questions of the Quoting vendors. The user can issue requests for information (RFI) from this page.
 Page 1620 lists all requests for information relating to the RFQ. The vendor can create new messages 1622, view existing messages 1626, and reply to existing messages 1628. The Request for Information page works like standard e-mail applications.
 A RFQ Package Review Cost Analysis page 1630 allows the user to review the quoting vendors' responses and compare them. This page is also where the RFQ may be awarded. The RFQ can be awarded to a single vendor, or it can be split among two or more vendors. A purchase order can also be automatically generated for the quoted materials.
 This page shows a table of the vendors who have provided responses. The table lists the breakdown items in the first column and information from each of the vendors in the subsequent columns.
 The individual breakdown of each item can be viewed in more detail by selecting a hyperlink of the item name 1636. The RFQ Package Wizard Review window displays for the selected breakdown item. This window shows the breakdown values for each of the vendors for side-by-side comparison. To review the detail of each item, the user can access the price link under a specific vendor. The RFQ Analysis Item Detail window displays for the selected item. A RFQ Package Review Comments page 1634 is used to view the RFQ response comments from the vendor.
 To award the RFQ, the user finishes reviewing the vendors' responses, decides on which vendor to accept, then clicks the checkbox under the selected vendor. Or, the user can split the award and select individual items from different vendors. Then, they award the RFQ to the selected vendor(s).
 The Award Preview Screen page 1640 displays and allows the user to determine whether to simply award the quote or to award it and automatically generate PO(s) (purchase orders).
 When the RFQ is awarded, the award confirmation 1642 displays.
 The vendor(s) awarded the RFQ receives a message 1644 informing them that they have been awarded specific items for the RFQ and states the cost and quantity of each item.
 After the RFQ is awarded to one or more vendors, the information from the original RFQ request and the vendors' responses feed into the Purchase Order process. The last tab on the RFQ Review Wizard is “Purchase Order”; this page is the same as the first page of the Purchase Order module.
 Returning to FIG. 11, the alternative to an RFQ is a bid request. A “bid” is a solicitation for vendors to submit proposed costs for a project to the requestor in a competitive process. Bidding is a common business practice in the design-build industries.
 The Bid process shown in FIGS. 17-19 illustrates the automation of the bid request, bid response, bid review, and bid award activities.
 The bid request activity is initiated with a Bid Package Wizard shown in FIG. 17. Again, the wizard is a set of programmatically connected pages, which: create the bid data structure in the computer system; indicate the date it is due from the bidding vendors; select which vendors it will be sent to; define the items to be bid; and allow drawings, specifications, and attachments to be associated with the bid. These documents provide information to the bidding vendors about the items they will be pricing.
 The Bid Request begins with a bid report 1702. A Bid Description page 1710 provides the user with the means to create the bid request. The user provides a bid name, description, contract type, and estimated bid price. The user also indicates the bidder selection type and what type of bid. The user may indicate that the bid is a “sealed” bid. A sealed bid is basically the same as a regular open bid, except it cannot be reviewed until after the due date. This prevents the reviewer from seeing early responses and possibly tainting the competitive bidding process with this advance knowledge.
 The Bid Description page 1710 also contains a unique bid number. This is assigned by the system and is a sequentially incremented compound number. The number can be composed of several different components, such as the project number, or the company number, or other user-defined attributes.
 The Bid Description page 1710 also provides the user with the ability to create a sub-bid. If the user is a sub-contractor and wants to contract all or a portion of the bid to another entity, they can import the contents of another bid into the new bid they are creating. They can then add, change, or remove items from the sub-bid. This is quicker and easier than having to manually re-enter all of the items from the original contractor's bid. The contact person or list 1714 for the bid is imported into the bid description.
 A Special Bid Instructions page 1712 provides the user with the ability to communicate special instructions to the bidders via a text message. This page is also the entry point into a meeting scheduler that can be used to schedule various meetings between the requestor and the invited bidder vendors.
 A Meeting Information page 1718 displays in a separate program window. It provides the means to enter the information for a specific meeting. The page allows the user to give the meeting a name, assign a date and time to the meeting, and indicate the location of the meeting. The meeting can also be designated as mandatory, optional, or suggested. Company address information may be imported into meeting information 1716.
 Next, a Bid Drawings page 1720 allows the user to attach computer-aided drafting (CAD) drawing files to the bid. The items being bid could be as small as a single component part or as large as a ship or building or aircraft. For the vendor to adequately bid on the item(s), they need as much information as possible about the item(s). Having access to the CAD drawings with the original bid request is a large logistical and planning advantage.
 The fact that the drawings can be attached to the request and sent to all the bidders at once simplifies the bid process and reduces mailing costs.
 A Bid Specifications page 1730 allows the user to attach word processing files to the bid. These files are intended to contain specifications for the items to be bid. The items being bid could be as small as a single component part or as large as a ship or building or aircraft. For the vendor to adequately bid on the item(s), they need as much information as possible about the item(s). Having access to the specifications documents with the original bid request is a large logistical and planning advantage.
 The fact that the specifications can be attached to the request and sent to all the bidders at once simplifies the bid process and reduces mailing costs.
 Next, a Bid Item List 1732 is used to attach a list of items to the bid package. These are items that already exist in the system and which have been defined in the Item Specification process. Item specifications are typically the list of materials you require in the project, along with the criteria for what specific items will suit the project requirements.
 For example: instead of indicating a need for chairs, the user might specify a particular type of chair, from a specific manufacturer, made of a specific type of material, etc. The item spec outlines all of these requirements and the quantity of the item required. The item list can be generated from Items specifications using a virtual area search 1734.
 Next, a Bid Attachments page 1740 allows the user to attach files to the bid. These files are intended to be miscellaneous files not covered in the Bid Drawing and Bid Specifications pages.
 A Bid Alternates page 1750 allows the user to create one or more uniquely named and numbered alternates to the base bid. Each alternate has its own set of drawings 1746, specifications 1748, item lists 1756, and attachments 1764. Attaching these to an alternate is similar to attaching them to the base bid (including a virtual area search 1758), except separate program pages are used.
 This page is only used when there are alternate requirements. This page is optional—a bid package does not have to have alternates defined.
 An alternate might be indicated when the project design is not finalized and the user wishes to consider two or more designs. They define one design with the base bid and the other design(s) with bid alternates. The bidding vendors can then provide their bids for each of the alternates as well as the base bid.
 A Bid Cost Form 1750 is used to attach a list of anticipated cost items to the bid. The user can import a bill of materials from the Item List page specified earlier or manually add items to this page, or a combination of the two methods. For each item indicated on this page, the user indicates what breakdown type(s) they require for the item.
 The user may import the item specifications from the Items List or manually add blank lines and fill in the item information. The information for each item is arranged in a set of rows and columns, similar to a spreadsheet.
 A separate, Choose Breakdown Type page (not shown in FIG. 12) may be used to select which breakdown types to specify for the bid. This page is accessed in a separate window when the user imports the item specifications on the Bid Cost Form. These are the six possible values the bidders may have to provide for the bid items.
 Selecting Vendors is accomplished using Invite Vendors page 1760, wherein the user can indicate which vendors will receive this bid package. Vendors can be selected manually 1734, or automatically 1752 included from previous qualifications. The user may indicate whether the vendor list will be published. If the list is published, each vendor will know who received the bid. If not, the vendors will not know the other vendors solicited to bid and will be unaware of their competition.
 Finally, the user issues a Bid Issue Invitation 1765 before the bid package is issued to the prospective bidders, the issue date, the date responses are due, and anticipated award date are indicated on this page. This is a Report function available from each of the pages in the Bid Package Wizard. The report function will most likely be used on the Bid Issue Invitation page since all the information for the bid has been entered and the bid package would be considered complete at this point. The report can be printed or it can be saved to an Adobe Acrobat PDF file formation for future use. If the bid is a sealed bid, it will not be able to be reviewed until after the bid due date and time indicated on this page. An invitation goes out to the vendor 1770 and a confirmation displays indicating that a Bid Package Request has been issued and published to the indicated vendors.
 Once the Bid Invitation goes out, a bid response activity is initiated. The Bid Response is shown in FIG. 18. After the bid package is issued, there is no way to make changes to it without issuing an addendum. The selected bidding vendors receive a message the next time they log into the system. This message contains a link 1802 to the Bid Response Wizard.
 A Bid Response Description page 1810 gives the bidding vendors an overview of the bid package and allows them to either accept or decline the invitation to participate in this bid.
 If the vendor decides to decline the bid invitation 1814, there is no further work done with the Bid Response Wizard. A message returns to the bid package originator indicating the decline and the vendor is no longer considered for the bid.
 If the vendor accepts the bid invitation 1812 and participates they will use the rest of the Bid Response Wizard to review the bid requirements and form their response.
 A Response to Bid Drawings page 1820 allows the vendor access to the drawings attached to the bid. They can either download the drawings for use in their own CAD systems, or they can simply view and print them with the built-in file viewer 1832.
 Next, a Bid Response Specifications page 1822 allows the vendor access to the specification documents attached to the bid. Vendors can either download the document files for use in their own systems, or they can simply view and print them with the built-in file viewer 1832.
 A Bid Response Items List page 1824 allows the user to review the Item List attached to the bid package.
 Each item specification listed may be viewed in detail by selecting the item Name hyperlink. The detailed specifications for each item then displays.
 A Bid Response Attachments page 1830 allows the vendor access to the files attached to the bid. They can either download the file for use in their own systems, or they can simply view and print them with the built-in file viewer 1832.
 A Bid Response Alternates page 1840 is used to view any alternates attached to the bid package. If there are no alternates on the bid package, this page is blank. There can be one or more alternates on a bid. If so, they are listed sequentially on this page.
 For each of the possible alternates, the bidding vendor can review the drawings, specifications, bill of materials, and attachments by accessing the links to view or download each.
 Next, a Bid Response Cost Form 1850 is the first interactive page for the vendor. Up to this point, all the pages in the Bid Response Wizard have basically been “view-only” pages. The Bid Response Cost Form is a page where the bidding vendor enters their proposed cost for each item of the bid package.
 For each of the breakdown categories of each item, the vendor types in their response in the Qty, Units, Unit Cost, Labor Rate, Hours, and Lump Sum columns.
 Next, a Bid Response Review Addenda page 1852 is used to display previous versions of the bid, if applicable. Once a bid has been issued, the only way the issuing user can make changes to it is to issue an “addenda.” The addenda looks just like the base bid and responding to the addenda is identical to responding to the base bid.
 If an addendum has been issued for a bid, this page allows the vendor to see the previous versions of the bid for reference purposes.
 Each bid can have one or more addenda. Addenda are listed sequentially here by Change number. The initial bid is always listed as Change number 0 (zero). To view a previous version of the bid, the vendor accesses the desired Change number.
 Like the RFQ process, in the course of responding to a bid, the vendor may have questions. Use the Bid Response RFI (Request for Information) page 1860 to generate messages to various users in the system. These are messages to various users that request some type of information necessary to respond to the bid. For example, the vendor may have questions to the bid originator to clarify certain points about the bid. Or the vendor may have questions for their suppliers or associates.
 This page lists all requests for information relating to the bid. The vendor can create new messages, view existing messages, and reply to existing messages. The Request for Information page works like standard e-mail applications. To create a new message, the user may “Generate New RFI” from this page.
 A Bid Response Issue page 1870 allows the user to issue the response to the bid request. The response information is sent back to the user that originated the bid request.
 A Bid Confirmation page displays confirming a Bid Package Response has been published.
 Like the RFQ process, the final step of the Bid Process is selecting and awarding a bid-characterized by a Bid Review process.
 The bid review activity is initiated with the Bid Package Review Wizard. Shown in FIG. 19, this is a set of programmatically connected pages, which: receive the responses from each responding vendor; compare the item breakdown from each responding vendor in a side-by-side manner; select one or more vendors to whom to award the bid; and award the bid to the selected vendor(s).
 The Bid Package Review Wizard can be accessed from a link 1902 in a Bid Response message from one of the responding vendors, or from the Bid Search page 1912.
 When a vendor issues their response to the bid, a message comes back to the originator of the bid package. This message contains a link in it that can be used to see the vendor's response. If the bid is a sealed bid, the bid cannot be reviewed until after the date and time indicated as the Bid Due Date and Time on the original Bid Request Wizard Issue Invitation page.
 A Bid Package Review Wizard Summary page summarizes the information in the bid package.
 Next, any Response Review Addenda pages may be reviewed. Although not shown in FIG. 19, these steps are similar to those set forth above in FIG. 16 with respect to the RFQ.
 A page is used to issue changes (addenda) to the original bid package. To issue an addendum, the user enters a type of change description and then adds the addenda to the bid. The same process is used to create the bid addenda as was used to create the initial bid. When the bid addenda is issued, this page redisplays with the addenda listed as a change. Each subsequent addendum is assigned a separate change number. The vendors listed on the bid will receive a message telling them that the addendum has been issued. This message has “Bid Addendum” as the subject.
 Next, Bid Review RFI is allowed using an RFI page 1920. The user can issue requests for information (RFI) from this page which lists all requests for information relating to the bid. The vendor can create new messages, view existing messages, and reply to existing messages. The Request for Information page works like standard e-mail applications.
 Next, a Bid Package Review Cost Analysis 1930 allows the user to review the bidding vendors' responses and create a comparison. The user may also award the bid. A bid can be awarded to a single vendor, or it can be split between two or more vendors.
 A Bid Package Review Comments page 1932 is used to view the bid response comments from the vendor.
 This page shows a table of the vendors who have provided responses. The table lists the breakdown items in the first column and information from each of the vendors in the subsequent columns. The individual breakdown of each item specification can be viewed in more detail by clicking on the item name hyperlink. This window shows the breakdown values for each of the bidders for side-by-side comparison.
 To review the detail of each item, the user may access the price link under a specific bidder. The Bid Analysis Item Detail window displays for the selected item specification.
 To award the bid, the user completes the reviewing process and determines which vendor to accept. When the user awards the bid to the selected vendor(s), the Award Preview Screen 1940 displays. A confirmation displays acknowledging the bid package has been awarded.
 The vendor(s) awarded the bid receive a notification in their message center 1946. The message informs them that they have been awarded specific item specifications for the bid and states the cost and quantity of each item.
 Referring again to FIG. 11, the RFQ or Bid generates a need for a Purchase Order. A purchase order is a financial agreement between the buyer and the vendor to purchase specified items. The purchase order contains billing, terms, items, cost, shipping, legalese, notes, and payment information. This purchase order can be created as a standalone process or be initiated automatically from the RFQ (Request for Quote) or Bid processes.
 A purchase order process flow is shown in FIG. 20. A General Purchase Order Information page 2002 (illustrated in FIG. 21) allows the user to specify some general information for the purchase order. The vendor that was awarded the RFQ (Request for Quote) or Bid is the vendor that displays below. The company's billing and shipping address information will be sent to that vendor. Other information available for clarification would be the (billing) Terms, Term notes, and special shipping notes or instructions.
 A Line Items page 2004 allows the user to include the item specification(s) that need to be purchased. The system allows the user to select one or multiple item specifications for this purchase order. The system automatically calculates the cost of the item specifications (calculations transferred from the Item Spec Wizard), and includes the cost of shipping and any applicable tax (defined in this process). There are several ways in which to include item specifications into a purchase order: multiple item specifications may be added at one time, each item specification may be added manually, or item specifications may be added one at a time while defining the details for each item. For this example, the multiple item specification search will be used and then defining the details will follow. The user may search item specifications based on the Item Number, Item Name, Classification, and Spec Book Publish Date.
 After the item specifications are selected and accepted, the Line Items page calculates the cost and allows the user to define the details of each item specification, if necessary.
 A Line Item Details page 2044 may define the details of each item specification. This process is accessed through the line item number link and typically used only if the details are different between item specifications. The purchase order process allows a user to issue the purchase order after the item specifications have been included. The rest of the steps discussed from this point until the purchase order is issued are optional.
 Once the Line Items Details page is accessed, the user may define any details that are specific to this item specification. This includes any associations to virtual areas, the quantity ordered, tax, shipping and adding any attachments for the vendor individually related to only the item specification.
 This process allows a user to save the details of each item specification and return to the Line Items page or add the next new item specification to the purchase order and define the details.
 An Attachments page 2006 allows attachment manipulation. After the item specifications have been included and defined in the purchase order, the user may want to include attachments for the vendor. These attachments will be available for the vendor to view upon receipt of this purchase order. These attachments must have been previously uploaded to the system in order to attach them to the purchase order. The user accesses the File Search tool 2014 to locate files within the system's database.
 Once the files are selected and accepted, the files display on the Attachments page exactly as they will appear to the vendor. The file name is a link to a viewer for the vendor to view the attached files.
 A Notes to Vendor page 2008 allows the user to include any legal terms, billing information or special instructions 2016 for the vendor. The user also has the option of selecting a prefabricated 2018 (previously defined by the company) note for the purchase order.
 A “Legalese” page 2010 allows the user to include standard terms and conditions that will display to the vendor when they receive the purchase order. This information will be available to the vendor when they review the purchase order to approve or decline the purchase request. The legal term displayed below was automatically transferred to display on this page. The company previously defined the legal term for the purchase order process. The company may also determine whether the purchasing agent should have the ability to add any additional information or if this page should be display only.
 A User Notes page 2012 is an internal process page, meaning the vendor does not receive this portion when the purchase order is issued. The user may determine which internal users will be able to view the user note during its creation. Public notes can be viewed by anyone with access to the purchase order (this is the default value). A Private note can only be viewed by its creator. Company notes can be seen by anyone in the user's company. After the note is added it will be available to the designated users with access to this purchase order.
 The last step in the purchase order process is issuing the purchase order. Depending upon the user's approval and purchasing authority, the purchase order is either issued to the next user with a higher level of purchasing authority or directly to the vendor.
 This example will assume the user had the purchasing authority and the purchase order is issued to the vendor. The purchase order displays in a report format for the user to review the information sent to the vendor.
 A Purchase Order Review page 2052 is only available to the buyer or user that created the purchase order. This view allows the user to save the purchase order in a file on their local drive to use for their record or for printing purposes.
 A History page 2056 allows the user to track the history or status of the purchase order. A User Notes pate 2054 allows the user to review any notes that were created for this purchase order. These notes are not included with the issued purchase order. A RFI (Request for Information) page 2058 allows the buyer to send an RFI to the vendor. The vendor usually initiates this process.
 Once issued, the vendor has the ability to approve the Purchase Order, as part of the item specification lifecycle performed by the vendor. The vendor receives the purchase order request through the Messaging tool in the system. When the vendor accesses their message center, the notification message for the purchase order displays. This notification displays a link for the vendor to access their version of the purchase order for review and acceptance.
 This process is similar to many of the aforementioned processes and again comprises a set of programmable linked pages, hereinafter described. A purchase orders Approval Preview page allows the vendor to view and print the purchase order request. This process allows the vendor to review the entire purchase order request to determine whether they should approve or decline the order. In this case, the vendor approves the order after reviewing the entire purchase order.
 A Purchase Order History page allows the vendor to view the history of the purchase order to ensure they have the most recent order for approval. This history also provides the contact name of the user that created the purchase order, in the event the vendor may have any questions. Once the vendor approves or declines the purchase order, this action and status is also logged in the history. This function prevents the vendor from approving or declining the order more than once and improves the efficiency of the process. The History page is view only. The vendor cannot alter any information on this page.
 A Purchase Order Buyer Attachments page allows the vendor to access the attachments process allowing them to download or view any attachments to the purchase order. These attachments may contain specifications, requirements, images, etc.
 Again, a Purchase Order RFI process is provided to allow the vendor to contact other users within the system to request information or communicate directly to the buyer.
 The vendor accesses the User Search page to locate a user within the system database to whom to send the RFI. The vendor may also select users to send a carbon copy of this message. The vendor may search for users with any, or all of the following: first name, last name, e-mail address, phone number or company.
 Once the users have been selected the vendor may add a subject to the message and then type or paste text into the body of the message, as in the example below. When the message is completed, the vendor sends the message to all of the users selected.
 A history of any RFIs sent from the vendor is captured, as well as any responses received from the buyer. After the history of the RFI is captured, the vendor may view the details of that RFI through the RFI# link.
 The RFI number link displays a details page for each RFI selected. This details page is displayed below.
 When the vendor has completed reviewing all of the purchase order information and has received responses to their RFIs, (if applicable) then the vendor may accept the purchase order.
 All of these steps are optional. The vendor may accept or decline the purchase order at any point in this process.
 Next, the vendor must approve the Purchase Order. Again, as the process is similar to those illustrated above, it will be described below. To accept the purchase order the vendor must access a Purchase Orders Approval page allows the vendor to accept or decline the purchase order.
 An Accepted Purchase Order Note page allows comment insertion by a vendor. After the purchase order has been accepted, the Approval Note page displays. This step allows the vendor to comment or add notes to the notification of approval to the buyer. These notes appear in the message center for the buyer with the notification of the status of the purchase order.
 The buyer then receives a notification in the message center regarding the status of the purchase order. In this case the purchase order has been approved and the buyer may review it for any necessary changes or answer any RFIs sent from the vendor. Generally, this is performed via the system Message Center. The buyer may review the status of the purchase order in the message center. Typically the message received appear as an email message including the purchase order number, vendor's name, amount and the status of the order. This information may be used to search for the purchase order for review.
 If the buyer would like to review the purchase order for the item specifications, the next step in this process is to search for the purchase order. A Purchase Order Search page allows the buyer to search for purchase orders with any or all of the information provided within the notification message. The purchase order may be accessed through the PO Number link.
 A Purchase Order Print Preview process is also provided. The buyer may create a change order for the purchase order at this time. A change order is a revision to the original purchase order. The buyer may determine that additional information or new item specifications should be added to the order or changes need to be made to existing information. This decision results in a change order. The system allows the buyer to access the change order process from this page.
 A Purchase Order History page may be displayed in reviewing the purchase order. The history displays the status changes that have occurred to this order since its creation. This step also allows the buyer to access the change order process. The example below displays the status of the purchase order, showing a decline as well as an acceptance.
 A Purchase Order User Notes page allows the buyer to review any user notes from this process. A user can access the details of existing user notes through the Read Note link.
 Also provided is a Purchase Order RFI page allowing the buyer to contact other users within the system to request information or communicate directly to the vendor. The buyer accesses the User Search page to locate a user within the system database to whom to send the RFI. The buyer may also select users to send a carbon copy of this message. The buyer may search for users with any, or all of the following: first name, last name, e-mail address, phone number or company. Once the users have been selected the buyer may add a subject to the message and then type or paste text into the body of the message, as in the example below. When the message is completed, the buyer sends the message to all of the users selected.
 Again, the history of any RFIs sent from the vendor and any responses received from the buyer is captured and displayed. After the history of the RFI is captured, the buyer may view the details of that RFI through the RFI number link. The RFI number Link displays a details page for each RFI selected. This details page is displayed below.
 All of these steps are optional. The buyer may determine to create a change order or end the review of the purchase order at any point in this process.
 A Virtual Area—Item Spec List page displays the purchased status for the item specifications when this process is completed.
FIG. 22 shows the Shipping pages displayed to follow the shipping flow of purchased items.
 After the vendor fulfills the purchase order 2210, the shipping notification process begins. The user in charge of shipping for that vendor may send the buyer a shipping notification. This process has several advantages.
 The purchase order is located automatically unless there is more than one order from the same buyer. If there is more than one order, the user has the option of selecting from just the orders from that buyer. If there is only one purchase order from that buyer, then the order is displayed automatically.
 A Shipping Information Search page 2230 provides the ability to select a purchase order if the vendor has received more than one purchase order from the specified company. The vendor then selects the purchase order containing the item specifications that are being shipped.
 A Shipment History Log page shows shipping history status. Once the purchase order is selected, the item specifications for that order display individually, allowing the vendor to send a partial or complete shipment. The item Name link allows the vendor to view a shipment log for that item. The Shipment History Log tracks the quantity of the items shipped and the date they were shipped to the buyer. This is essential information if the vendor has sent only a partial shipment.
 Once the vendor has completed the shipping form, the system confirms that the shipment notification was successful.
 Once shipped, a Buyer's Notification is sent. The buyer receives a message in their message center notifying them that the item specifications on the purchase order have been shipped with the date and quantity of items included. The buyer may also verify the item specifications have been shipped by displaying the Item Spec List. The shipped status displays for the quantity of items shipped.
 A further process is provided for sending the Receiving Notification. After the vendor ships the item specifications to the buyer, the buyer may make create a notification of receipt when the item specifications are received. This process occurs only after the item specifications are received at the buyer's designated destination.
 The buyer may access the receiving tool from the project page. This process is very similar to the shipping notification process. The buyer must locate the purchase order with the shipped items before processing the receiving notification.
 If more than one purchase order has been accepted the Receiving Information Search page displays allowing the buyer to select the purchase order with the items received.
 A Receiving History Log is also provided. Then the buyer may indicate how many of each item were received or if the entire shipment was received. If a partial shipment was received or if the buyer would like to view the history of each item specification, the item specification Name is a link to the Receiving History Log. This log displays the quantity of items recorded as received and the date.
 The system confirms the receiving notification has been sent and the items have been tracked.
 The item specification list now reflects that the item specifications have been received at their destination and the item specification lifecycle is complete.
 Finally, the vendor receives the notification of the item specifications received, via the message center. An example of the receipt notification is shown below.
 Industrial Application
 The system of the present invention provides a unique, comprehensive project management system. In one embodiment, the system includes an enterprise system, Application Service Providers (ASP) platform, and open architecture provides business-efficient toolsets that: allows multiple companies worldwide to participate in projects, automates and streamlines bidding and estimating processes, increases the accuracy and efficiency of purchasing, facilitates integration with existing applications, provides simple but secure access over the Internet, and eliminates duplicate data entries. The system captures and manages information throughout the design, build, and manage phases of the resulting asset. In a further unique feature of the invention, all data is available in real-time and precise information throughout a project's lifecycle. Even after an asset has been built, an owner or property manager can access the system to derive specific information within a few seconds. This system can be applied to any number of design and build industries, including: Civil and Electrical Infrastructure; Telecom; Commercial, Residential, and Government Buildings; Manufacturing; Aerospace and Nautical applications; and Automobile, Railways, and Public Transportation projects.
 The foregoing detailed description of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. The described embodiments were chosen in order to best explain the principles of the invention and its practical application to thereby enable others skilled in the art to best utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims appended hereto.