Patent Publication Number: US-8121904-B2

Title: Electronic proposal preparation system

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of U.S. application Ser. No. 09/566,029 filed May 8, 2000 (patented as U.S. Pat. No. 7,606,739), which is a continuation of U.S. application Ser. No. 08/823,534 filed Mar. 24, 1997 (abandoned), which is a continuation of U.S. application Ser. No. 08/596,575 filed Feb. 5, 1996 (patented as U.S. Pat. No. 5,615,342), which is a continuation of U.S. application Ser. No. 07/878,602 filed May 5, 1992 (patented as U.S. Pat. No. 5,493,490). The disclosure of all of these applications is expressly incorporated herein by specific reference thereto. 
    
    
     FIELD OF THE INVENTION 
     The present invention relates to a system for creating a customized proposal by linking together product pictures, environment pictures showing environments in which the product may be used, and text related to the product. The system includes means for linking together predetermined product pictures, environment pictures, and text based upon a potential customer&#39;s answers to predetermined queries. 
     BACKGROUND AND SUMMARY OF THE INVENTION 
     Many products, such as cars, are illustrated to customers by preprinted brochures. Car dealerships, for example, have glossy brochures that show pictures of cars and generic textual descriptions of the cars. A customer may test drive and actually inspect a particular car of interest. The dealership will also furnish the customer with one of the preprinted brochures of the car. The brochure documents and contains information about the car. The customer may refer to the brochure and potentially be quite influenced by it in making a decision regarding whether to purchase the car. 
     The generic nature of these preprinted brochures, however, may have a negative impact on the customer&#39;s ultimate decision of whether to purchase and thus are often not persuasive. Traditionally, only one brochure is available for each car, for example, and every potential purchaser of that car receives the same brochure. These brochures contain glossy photographs of the car in a variety of settings, which may include, for example, a country setting, city environment, golf course, and marina. Next to the photographs, the brochures usually contain generic textual descriptions of the car or potential uses of the car. Finally, the brochures typically contain standard lists of options for the car along with complex pricing charts from which one may calculate a price based on a matrix of options and prices. 
     The preprinted brochures contain all of these different settings for the car and generic information in an attempt to appeal to any potential purchaser. For example, one customer may enjoy golfing, and the brochure contains a photograph of the car at a golf course to appeal to that customer and influence that customer in his or her decision to purchase the car. Another customer may want to use the car to take long trips which pass through the country, and the photograph in the brochure of the car in a country setting is designed to appeal to that customer. 
     The brochures also contain standard pricing charts. Since every brochure is generic to any customer, however, it must contain complex pricing charts that include a matrix of options and prices. Furthermore, since prices of the car or options often change, the information in the brochure can easily be out of date. Also, much of the pricing information is not of interest to a particular customer, since the customer will typically be interested in the price for a single, or relatively few, combinations of options for the car. 
     In containing all of this varied and generic information in an attempt to be “all things to every customer,” the preprinted brochures actually are of limited value to any particular customer. The brochures are not customer specific and, therefore, are not particularly appealing or persuasive for any customer. The typical brochure contains much information that is of no value or interest to a particular customer due to the varied and generic nature of the product pictures and textual descriptions. Furthermore, these preprinted brochures are expensive to produce because of the glossy photographs and may be quickly out of date, meaning that either a dealership must discard the brochures or provide customers with “old” brochures. 
     The present invention solves these problems by utilizing a computer-based system to dynamically create customized, printed proposals for potential purchasers of a product. The system queries a customer to determine his or her interests and desired options. The interests may include a “use” desired by the customer, such as a marina or golf course. The interests may also include the type of information, such as technical, that the customer would like in the proposal. The desired options may include the various features of interest to the customer, such as the type of engine desired. 
     Based upon the customer&#39;s answers to the queries, the system links product pictures, environment pictures, and textual descriptions together in a customized proposal. The system also has the capability to link together other aspects in the proposal, which may include environment text describing the product in a particular setting or environment. The customized proposal, therefore, contains pictures, textual descriptions, and pricing information that is all of interest to and relevant to a specific customer, since all of the pictures and text were linked together based upon the customer&#39;s answers. 
     Since each proposal is customized for a particular customer, each proposal will have a much more persuasive effect in selling the product. Also, if any information about the product changes, such as prices of options, the system information stored in a data base may be simply changed in order to accommodate the new information. Additional textual descriptions or pictures may also be added to the system data base to be used in linking together information for a proposal. 
     The quality of the pictures produced in these customized, printed proposals can be made comparable in quality to the glossy photographs in prior art proposals due to recent advances in computer printers. Printers such as the Canon CLC-300 produce color computer print-outs that resemble color photographs. These customized proposals, therefore, need not be inferior to prior art proposals in terms of the quality of available pictures for the proposals. 
     This system for producing customized, high-quality proposals has many potential applications, such as in the car industry. A customized proposal generated by the present invention will have a great appeal to each individual customer and will be an asset in selling the product. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1A  is a block diagram illustrating conceptually picture and text databases of the computerized proposal system. 
         FIG. 1B  is a diagram illustrating conceptually an electronic proposal template of the computerized proposal system. 
         FIG. 2  is a block diagram showing the preferred system. 
         FIG. 3  is an object diagram showing an active database. 
         FIG. 4  is a class diagram showing a detailed depiction of the classes in a preferred proposal data class. 
         FIG. 5  is an object diagram showing a detailed depiction of a preferred table of contents object. 
         FIG. 6  is a class diagram showing a detailed depiction of the classes in a preferred customized data class. 
         FIG. 7  is an object diagram showing a user interface. 
         FIG. 8  is a class diagram showing a detailed depiction of the classes in a preferred form class. 
         FIG. 9  is a block diagram showing the contents of a static database. 
         FIG. 10  is a block diagram showing a detailed depiction of the elements in a preferred report generator. 
         FIG. 11  is a block diagram showing a detailed depiction of the elements in a preferred selection device. 
         FIG. 12  is a detailed depiction of the elements in a preferred main menu. 
         FIG. 13  is a detailed depiction of the elements within the “Contents” selection of the preferred main menu. 
         FIG. 14  is a block diagram showing the contents of a difference database. 
         FIG. 15  is a block diagram showing the contents of a report database. 
         FIG. 16  is an object diagram showing a detailed depiction of the elements in a preferred user interface. 
         FIG. 17  is an object diagram showing a detailed depiction of the elements in an active database. 
         FIG. 18  is an object diagram illustrating a preferred flow of control involved when selecting pages to print. 
         FIG. 19  is an object diagram illustrating a preferred flow of control involved when generating a cover sheet. 
         FIG. 20  is an object diagram illustrating a preferred flow of control involved when entering customer identification data. 
         FIG. 21  is an object diagram illustrating a preferred flow of control involved when generating customer identification data. 
         FIG. 22  is an object diagram illustrating a preferred flow of control involved when entering salesperson identification data. 
         FIG. 23  is an object diagram illustrating a preferred flow of control involved when generating salesperson identification data. 
         FIG. 24  is an object diagram illustrating a preferred flow of control involved when entering letter information. 
         FIG. 25  is an object diagram illustrating a preferred flow of control involved when generating a personalized letter. 
         FIG. 26  is an object diagram illustrating a preferred flow of control involved when selecting product descriptions. 
         FIG. 27  is an object diagram illustrating a preferred flow of control involved when generating product description pages. 
         FIG. 28  is an object diagram illustrating a preferred flow of control involved when entering product specification information. 
         FIG. 29  is an object diagram illustrating a preferred flow of control involved when generating product specification pages. 
         FIG. 30  is an object diagram illustrating a preferred flow of control involved when generating performance specification pages. 
         FIG. 31  is an object diagram illustrating a preferred flow of control involved when entering trade-in product information. 
         FIG. 32  is an object diagram illustrating a preferred flow of control involved when generating trade-in product pages. 
         FIG. 33  is an object diagram illustrating a preferred flow of control involved when entering product price quotation information. 
         FIG. 34  is an object diagram illustrating a preferred flow of control involved when generating product price quotation pages. 
         FIG. 35  is an object diagram illustrating a preferred flow of control involved when entering product financing information. 
         FIG. 36  is an object diagram illustrating a preferred flow of control involved when entering product financing pages. 
         FIG. 37  is an object diagram illustrating a preferred flow of control involved when entering life cycle cost information. 
         FIG. 38  is an object diagram illustrating a preferred flow of control involved when generating life cycle cost pages. 
         FIG. 39  is an object diagram illustrating a preferred flow of control involved when generating a table of contents page. 
         FIG. 40  is an object diagram illustrating a preferred flow of control involved when printing a trademark. 
         FIG. 41  is an object diagram illustrating a preferred flow of control involved when choosing a language. 
         FIG. 42  is an object diagram illustrating a preferred flow of control involved when generating a signature page. 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
     The present computer system is preferably implemented using Object Oriented Design (OOD). Because OOD is a fairly new programming method, a brief explanation of OOD design concepts will be offered here in order to ensure a better understanding. 
     The resource used for preparing this explanation is: Grady Booch, “Object Oriented Design with Applications,” 1991, published by The Benjamin/Cummings Publishing Company, Inc. 
     According to Booch, the Object Oriented Design methodology views the “world” as a set of autonomous agents that collaborate to perform higher level behavior. The OOD agents are called objects. Objects can have a state, behavior and identity. A set of objects that share a common structure and common behavior are called a class. A set of objects working together to provide, a behavior that satisfies some requirement of a problem is called a mechanism. 
     The design described herein is an object-oriented design. This design is described using object diagrams which show the interaction of the objects that make up the application. In addition, class diagrams are used to present the architecture of the system. 
     Unless otherwise stated, all classes making up the architecture of the system preferably are derived from a common base class named CWCObject. Where this is not the case, class diagrams are used. 
     INTRODUCTION 
       FIGS. 1A and 1B  illustrate conceptually a primary feature of the computerized proposal system. The system allows a user to dynamically customize and create a proposal for individual customers. The customized proposal may contain specific items for a particular customer, depending upon the customer&#39;s needs and desires. 
       FIG. 1A  shows conceptually a database  50  that electronically stores a plurality of pictures. The pictures may include environment pictures  51 - 55 , product pictures  56 , and pictures for various parts  57  and  58 . A textual descriptions database  59  may store a plurality of text segments that correspond to various pictures in the picture database  50 . 
       FIG. 1B  illustrates conceptually an electronic template for creating a page in a customized proposal. The system may query a user to determine a particular customer&#39;s needs and interests. Based upon the answers to the queries, the system may “fill in” the template  60  to customize a proposal for the customer. For example, if the customer has an interest in sailing or boating, the system may choose a picture of a marina environment  51  to use as the background or environment  62  in picture  61  of template  60 . Likewise, if the customer has an interest in golfing, the system may choose a golf course environment  52 . Within the environment  62 , the system places a product  63  by selecting one of the plurality of product picture  56  based upon the customer&#39;s answers. 
     Each product  63  typically has several options available to the customer, such as the type of engine and wheels. Based upon the customers answers, which indicate the customer&#39;s desired options, the system may select parts from the picture database  50  for parts  64  and  65  on product  63  in the template. The system may also select one of the plurality of text segments  59  to fill in text frame  66 . The text in the text frame  66  would typically correspond to picture  61  and, for example, provide a description of the product or its performance specifications. 
     Accordingly, the system uses the stored pictures in the picture database  50  as building blocks for filling in the template. The system establishes a customer profile based on the customer&#39;s answers to queries. The system then uses the profile to “build” the empty frames, such as picture  61 , in template  60 . 
     The approach of using picture building blocks provides for much versatility and the capability to customize a proposal. Products may be shown in anyone of a variety of environments by simply selecting the appropriate picture building blocks. Likewise, any combination of options may be shown on a particular product by selecting the appropriate part picture building blocks. Each combination of pictures for a finished template need not be pre-stored, since the system dynamically builds a template. Also, the system provides further advantages by allowing easy change of options. For example, if a particular type of wheel is no longer available on a truck, a user may simply change the stored picture for that wheel. Options may easily be changed by loading and storing new part pictures in the picture database. The system, therefore, provides for customized proposals that are up-to-date and may accommodate changes in available options. For simplicity, the system has been conceptually shown with a product in an environment. One skilled in the art will recognize that the system is capable of creating different types of templates or proposals based on different picture building blocks or different combinations of the building blocks. 
     Overview 
     Referring now to  FIG. 2 , a computer system  100  is shown. Preferred computer system  100  incorporates an active database  103 , a static database  105 , a report database  106 , a user interface  102 , a selection device  101 , and a report generator  104 . The computer system  100  may also incorporate a difference database  107 . The selection device  101  is operatively interconnected to the active database  103 , to the report database  106 , to the report generator  104 , and to the user interface  102 . The active database  103 , the report database  106 , the static database  105 , and the difference database  107  are operatively interconnected to the report generator  104 . Referring now to  FIG. 2  in combination with  FIG. 3  and  FIG. 4 , the active database  103  may electronically store proposal related customer information in the proposal object  110 . A proposal object  110  is an instance of the proposal class which is itself derived from the CWCObject class. The active database  103  may contain a plurality of proposal objects  110 . Each proposal object  110  may contain a plurality of ProposalData objects  112 . The ProposalData objects  112  may store customer-related information collected by the user. ProposalData objects  112  are instances of the ProposalData class  320  which is derived from the CWCObject class. 
     Customer-related information may be entered interactively via the user interface  102  typically beginning at the time the program is first started, and may continue to be entered intermittently throughout the time the program is running. Referring now to  FIG. 7 , in combination with  FIG. 3 ,  FIG. 16 , and  FIG. 17 , the user-entered information may be gathered on one or more of the various Form objects  118 , and then stored in one or more of the various ProposalData objects  112  in the proposal  110  in the active database  103 . 
     Table 1 shows how information is stored in a preferred embodiment: the first column indicates the type of information stored; the second column indicates the corresponding object by which a user may enter the information; the third column indicates the corresponding class of which the object is an instance; and the fourth column indicates the corresponding form class from which the class in the third column is derived. The classes are identified in the table by reference numerals and preferably have the same identifying label as the objects to which they correspond. For example, reference numeral  361  in table 1 refers to the TradeForm class  361 . 
     
       
         
           
               
               
               
               
             
               
                 TABLE 1 
               
               
                   
               
               
                 Type of 
                   
                   
                 Form 
               
               
                 Information 
                 Object 
                 Class 
                 Class 
               
               
                   
               
             
            
               
                 trade-in product 
                 TradeForm Object 292 
                 361 
                 340 
               
               
                 product price quotation 
                 QuotationForm object 294 
                 362 
                 340 
               
               
                 financing a product 
                 FinanceForm object 296 
                 364 
                 340 
               
               
                 product life cycle cost 
                 LifeCycleForm object 298 
                 366 
                 340 
               
               
                 personalized letter 
                 LetterForm object 288 
                 358 
                 340 
               
               
                 product 
                 ProductForm object 290 
                 360 
                 340 
               
               
                 customer 
                 CustomerForm object 286 
                 356 
                 340 
               
               
                 table of contents 
                 TableOfContentsForm object 284 
                 354 
                 340 
               
               
                 salesperson 
                 ListOfSalesPersonsForm object 
                 352 
                 340 
               
               
                   
                 310 
               
               
                 to save a proposal 
                 SaveProposalForm object 308 
                 350 
                 340 
               
               
                 to recall a stored 
                 RecallProposalForm object 306 
                 348 
                 340 
               
               
                 proposal 
               
               
                 language 
                 LanguageForm object 304 
                 346 
                 340 
               
               
                 dealer 
                 DealerForm object 302 
                 344 
                 340 
               
               
                 password 
                 PasswordForm object 300 
                 342 
                 340 
               
               
                   
               
            
           
         
       
     
     Objects of classes derived from a common base class can be referred to as if they were objects of the common base class due to the principle of polymorphism. The TradeForm object  292  can therefore be treated generically as a Form object  118 . The user interface  102  typically comprises a collection of such Form objects  118 , each of which can be made to load itself into a window on the computer screen. 
     Table 2 shows how information gathered by the various objects described above may be stored as data objects in a preferred embodiment: the first column indicates the type of information stored; the second column indicates the corresponding data object in which the information may be stored; the third column indicates the corresponding data class of which the data object is an instance; and the fourth column indicates the corresponding class from which the data class in the third column is derived. The data classes are identified in the table by reference numerals and preferably have the same identifying label as the data objects to which they correspond. For example, reference numeral  380  in Table 2 refers to the TradeData class  380 . Each of the listed data objects in Table 2 may preferably be treated generically as a ProposalData object  112  and stored as one of the various ProposalData objects  112  in the proposal object  110 . 
     
       
         
           
               
               
               
               
             
               
                 TABLE 2 
               
               
                   
               
               
                 Type of 
                   
                 Data 
                   
               
               
                 Information 
                 Data Object 
                 Class 
                 Class 
               
               
                   
               
             
            
               
                 trade-in product 
                 TradeData Object 142 
                 380 
                 320 
               
               
                 product price quotation 
                 QuotationData object 144 
                 382 
                 320 
               
               
                 financing a product 
                 FinanceData object 146 
                 384 
                 320 
               
               
                 product life cycle cost 
                 LifeCycleData object 148 
                 386 
                 320 
               
               
                 personalized letter 
                 LetterData object 138 
                 376 
                 320 
               
               
                 product 
                 ProductData object 140 
                 378 
                 320 
               
               
                 customer 
                 CustomerData object 136 
                 374 
                 320 
               
               
                 cover sheet 
                 CoverSheetData object 132 
                 372 
                 320 
               
               
                 table of contents 
                 TableOfContentsData object 130 
                 368 
                 320 
               
               
                 salesperson 
                 SalesPersonData object 134 
                 370 
                 320 
               
               
                   
               
            
           
         
       
     
     Referring now to  FIG. 2  in combination with  FIG. 3 ,  FIG. 6 ,  FIG. 16 , and  FIG. 17 , the active database  103  may electronically store dealer, salesperson, and language information in the customized database  114 . A customized database  114  is an instance of the CustomizeDataBase class which is itself derived from the CWCObject class. The active database  103  may contain a plurality of customized database  114 . Each customized database  114  may contain a plurality of CustomizeData objects  116 . The CustomizeData objects  116  typically store dealer, salesperson, and language information. 
     Table 3 shows how information gathered by the various objects described above may be stored as data objects in a preferred embodiment: the first column indicates the type of information stored; the second column indicates the corresponding data object in which the information may be stored; the third column indicates the corresponding data class of which the data object is an instance; and the fourth column indicates the corresponding class from which the data class in the third column is derived. The data classes are identified in the table by reference numerals and preferably have the same identifying label as the data objects to which they correspond, For example, reference numeral  390  in Table 3 refers to the DealerData class  390 . 
     Each of the listed data objects in Table 3 may preferably be treated generically as a CustomizeData object  116  and stored as one of the various CustomizeData objects  116  in the customized database  114 . 
                                 TABLE 3               Type of       Data           Information   Data Object   Class   Class                  dealer   DealerData object 156   390   330       salesperson   ListOfSalesPersonsData object 158   392   330       language   LanguageData object 160   394   330       password   PasswordData object 164   396   330                    
The dealer, salesperson and language information may be restricted using a password entry system.
 
     Referring now to  FIG. 2  in combination with  FIG. 9 , the static database  105  may electronically store the following: a plurality of environment pictures  122 , and a plurality of environment text  124 , both of which are related to the environment in which the product may be used; a plurality of product pictures  126 , and a plurality of product text  128 , both of which are related to features and benefits of the product; a plurality of product specifications  121  which relate to the technical details of the product; a plurality of price specifications  125  which determine the price of the product; a plurality of performance specifications  123  which represent the performance of the product; a plurality of trademark pictures  127  which identify the product; a plurality of product descriptions  131  which describe the various products; and a plurality of life cycle specifications  129  which determine the projected cost involved in owning the product. The static database  105  may be stored on optical media. The contents of the static database  105  preferably cannot be altered by the user of this application. Changes to the static database  105  may be distributed to some or all of the users of this application on either optical or magnetic media. 
     Referring now to  FIG. 2 , in combination with  FIG. 14 , the difference database  107  may electronically store the updates to the static database  105 . If the static database  105  is stored on optical media, a difference database  107 , stored on magnetic media, may be used to store information that reflects net changes to the contents of the static database  105 . In the event that updates are required for the computer system, these updates are typically stored on magnetic media and sent to all the various owners of the system who will want to update the contents of the static database  105 . The difference database  107  may be used to store the updates to the following: the plurality of environment pictures  122 ; the plurality of environment text  124 : the plurality of product pictures  126 ; the plurality of product text  128 : the plurality of product specifications  121 ; the plurality of price specifications  125 : the plurality of performance specifications  123 ; the plurality of trademark pictures  127 ; the plurality of product descriptions  131 ; and the plurality of life cycle specifications  129 . 
     Referring now to  FIG. 2 , in combination with  FIG. 15 , the report database  106  may electronically store a plurality of page layouts  120  which are used to format and produce the various pages of information available for inclusion in the printed proposal. 
     Referring now to  FIG. 2 , when the user begins a deal with a customer, the user will typically want to gather specific customer and product information regarding this individual customer and the product this customer is interested in purchasing. The user interface  102  is the means by which the user may interactively input predetermined answers to predetermined queries, the predetermined answers corresponding to the individual customer who is to receive the proposal. 
     Referring now to  FIG. 2  in combination with  FIG. 7  and  FIG. 16 , the user interface  102  typically comprises a collection of Form objects  118  which present a series of predetermined queries related to the varying interests of the different potential customers. The proposal-related information entered interactively by the user on the various Form objects  118  preferably can be altered at any time by the user. 
     Referring now to  FIG. 2 , in combination with  FIG. 7 ,  FIG. 8 , and  FIG. 11 , the user interface  102  may also control operation of the selection device  101  via the main menu  170  of the selection device. The main menu  170  would typically include choices that prompt the selection device  101  to send a message to a particular Form object  118  requesting that it display itself. 
     Referring now to  FIG. 12 , when the user is first beginning to deal with a customer, the user will typically need to start a new proposal. The user may select “File”  172  from the main menu  170 . Note that labels identifying menu choices may be altered in customized versions of this application designed for different users. The “File” menu  172  contains the option “New Proposal”  186 , which the user selects when beginning to deal with a new customer. After the user has begun a new proposal, the information for this new proposal may be stored by selecting “Save Proposal . . . ”  190  from the “File” menu  172 . After a proposal has been stored, the user can modify the stored proposal by selecting the option “Recall proposal . . . ”  188  from the “File” menu  172 . 
     Referring now to  FIG. 11  in combination with  FIG. 8  and  FIG. 12 , the user may select “Customer Information”  176  from the main menu  170 , which opens a window with choices pertinent to customer and product information. These pertinent choices correspond to the various Form objects  118 , upon which the user enters information pertaining to this particular customer and the product the customer is interested in purchasing. 
     Referring now to  FIG. 12  in combination with  FIG. 3 ,  FIG. 4 ,  FIG. 7 , and  FIG. 8 , the user may select “Customer Information”  176  from main menu  170 , then further select “Customer . . . ”  198 , which opens the CustomerForm object  286 . The user may enter customer information via the CustomerForm object  286 , which is then preferably stored in the CustomerData object  136  which is one of the ProposalData objects  112  in the proposal object  110  in the active database  103 . The user may select “Letter . . . ”  202  from “Customer Information”  176  and then enter information via the LetterForm object  288 , which is then preferably stored in a LetterData object  138  as one of the ProposalData objects  112  in the proposal object  110 . In this same fashion, the user may select “Standard and Optional Equipment . . . ”  204  from “Customer Information”  176 , and then enter information via the ProductForm object  290 , which is then preferably stored in a ProductData object  140  as one of the ProposalData objects  112  in the proposal object  110 . The user may select “Trade . . . ”  206  from “Customer Information”  176 , and then enter information via the TradeForm object  292 , which is then preferably stored in a TradeData object  142  as one of the various ProposalData objects  112  in the proposal object  110 . In a similar fashion, the user may select “Quotation . . . ”  208  from “Customer Information”  176 , and then enter information via the QuotationForm object  294 , which is then preferably stored in a QuotationData object  144  as one of the various ProposalData objects  112  in the proposal object  110 . The user may select “Payment Schedule &amp; Terms . . . ”  210  from “Customer Information”  176 , and then enter information via the FinanceForm object  296 , which is then preferably stored in a FinanceData object  146  as one of the ProposalDatas objects  112  in the proposal object  110 . The user may select “Economics . . . ”  212  from “Customer Information”  176 , and then enter information via the LifeCycleForm object  298 , which is then preferably stored in a LifeCycleData object  148  as one of the various ProposalData objects  112  in the proposal object  110 . 
     Referring now to  FIG. 12  in combination with  FIG. 3 ,  FIG. 6 ,  FIG. 7 , and  FIG. 8 , the owner of the dealership, for example, may select the “Customize” menu  177  from main menu  170 , then further select “Passwords . . . ”  224 , which opens the PasswordForm object  300 . The owner enters dealer and salesperson password information via the PasswordForm object  300 , which is then stored in a PassWordData object  164  as one of the various CustomizeData objects  116  in the customized database  114  in the active database  103 . The owner may select “Dealer Name . . . ”  226  from the customized menu selection  177  and then enter information via the DealerForm object  302 , which is then preferably stored in a DealerData object  156  which is one of the CustomizeData objects  116  in the CustomizeDataBase  114 . The user may select “Dealer Information . . . ”  228  from the customized menu selection  177  and then enter salesperson information via the ListOfSalesPersonsForm object  310 , which is then preferably stored in a ListOfSalesPersonsData object  158  which is one of the CustomizeData objects  116  in the CustomizeDataBase  114 . In this same fashion, the user may select “International”  234  from the customized menu selection  177 , and then choose a language on the LanguageForm object  304 , which is then preferably stored in a LanguageData object  160  which is one of the CustomizeData objects  116  in the customized database  114 . 
     Computer system  100  may further be enhanced by the addition of a report generator  104 . 
     Referring now to  FIG. 2 , in combination with  FIG. 10 , the report generator  104  includes mechanism  262  which comprises means for processing and generating the customized, printed proposal. The report generator  104  may be operatively interconnected to the active database  103 , to the static database  105 , to the report database  106 , to the selection device  101 , and to the user interface mechanism  102 . 
     The user may decide to generate a customized, printed proposal to an individual customer relating to the individual customer&#39;s interest in a product, the product being characterized by a variety of distinctive features. The customized, printed proposal may include one or more pages comprising the information collected during the process of dealing on the purchase of the product. 
     Referring now to  FIG. 2 , in combination with  FIG. 10 , and  FIG. 11 , the user may want to generate a printed proposal. In order to do so, the user will typically first need to design a table of contents for the proposal, which entails selecting the individual pages that will be included. Using selection device  101 , the user may select “Contents . . . ”  174  from the main menu  170 . In response, the selection device  101  preferably sends a load message to the TableOfContentsForm object  284 , as shown in  FIG. 7 , in combination with  FIG. 16 . On receipt of the load message, the TableOfContentsForm object  284  displays itself within the main window of the selection device  101 , as shown in  FIG. 13 . 
     Referring now to  FIG. 16 , in combination with  FIG. 7 ,  FIG. 3 , and  FIG. 17 , upon loading itself, the TableOfContentsForm object  284  may obtain a pointer to the proposal object  110 , from which the TableOfContentsForm object  284  then obtains a pointer to the TableOfContentsData object  130 . 
     Referring now to  FIG. 13 , the user selects the desired proposal pages, referred to as the current publication  260 , from a list of pages, referred to on screen as “Table of Contents”  196 , that are available for inclusion in the printed proposal. As the user selects the desired pages from “Table of Contents”  196 , these pages then preferably list themselves on-screen under the heading “Current Publication.” The selected pages, “Current Publication”  260 , may be stored as PageDescription records  314  in the TableOfContentsData object  130 , as shown in  FIG. 5 . (The contents of the pages to be printed are typically not stored; only the page description records describing the pages to be printed are stored.) 
     Referring now to  FIG. 13 , in combination with  FIG. 15 , and  FIG. 5 , the PageDescription records  314  may each include a field that contains an identifier that indicates which page layout  120  may be used to format each page in the current publication  260 . The page layout  120  determines the content and appearance of the final printed page. 
     Referring now to  FIG. 10 , in combination with  FIG. 15 , and  FIG. 5 , the report generator  104  includes a mechanism  268  for reading the page description records  314 . The report generator  104  typically includes a mechanism  270  for reading the page layout identifiers. The page layout identifiers may indicate which page layouts  120  are to be used to format the particular pages. The page layout identifiers may specify which particular data is required, and also specify where that particular data will appear on the printed page. The report generator  104  provides a mechanism  285  for linking the page layout identifiers with the particular data that is to appear on the printed page. The report generator  104  typically includes a mechanism  276  for placing the retrieved data in the appropriate locations on the page as described in the page layout. 
     Referring now to  FIG. 2 , in combination with  FIG. 12 , the user may decide to print the customized proposal for an individual customer. The user preferably selects “Print”  178  from the “File” menu  172 , and further selects “Proposal”  218 . The selection device  101  then sends a print request to the report generator  104 . 
     Referring now to  FIG. 10 , in combination with  FIG. 2 ,  FIG. 3 , and  FIG. 9 , the report generator  104  may include a mechanism  264 , which queries the active database  103 . The report generator  104  may include a mechanism  272  for locating and retrieving data from the active database  103 . This active data typically includes the customer and product information entered by the user via the user interface  102 , the information which comprises the predetermined answers to predetermined questions, the predetermined answers corresponding to the individual customer who is to receive the proposal. The report generator  104  preferably provides a mechanism  285  for linking these predetermined answers (active data) with the predetermined product pictures and text (static data) related to the individual features, benefits and environments that are of particular interest to the individual customer. These predetermined pictures and text may be obtained from the static database  105 . The report generator  104  preferably includes the following mechanisms: mechanism  266 , which queries the static database  105 ; mechanism  274  for locating and retrieving data from the static database  105 ; a dealer personalization mechanism  280  for generating a printed proposal automatically customized for a particular dealer; a customer personalization mechanism  282  for generating a printed proposal automatically personalized for a particular customer; and mechanism  278  for generating a printed proposal in a plurality of colors. For example, a generated printed proposal includes high-resolution graphics printed in real-life, photographic-quality colors, producing a printed picture of a superior nature that enhances the readability as well as the overall appearance of the printed proposal. 
     The following is a description of a preferred embodiment of the computerized system for generating a customized, printed proposal for an individual customer&#39;s purchase of a product. The system as generally described in  FIG. 2  through  FIG. 17  will further be detailed in the following discussion and  FIG. 18  through  FIG. 42 . In the preferred embodiment discussion that follows, the user may select from several generic types of pages to include in the printed proposal. The types of pages typically include cover sheets, personalized letters, product description pages, product specification pages, performance specification pages, trade-in specification pages, product Price Quotation pages, Finance plan pages, Life Cycle evaluation pages, Table of Contents pages, and a Signature page. In the preferred embodiment, a Trademark may be printed on any of the pages of the proposal, and the proposal may be printed in anyone of a plurality of languages. 
     Proposal: Cover Sheet 
     The user may decide to generate a customized, printed proposal that includes a cover sheet  250 . To include this cover sheet  250 , the user may select “Contents”  174  from the main menu  170  of the selection device  101 , as shown by step  18 - 1  of  FIG. 18 . In response, the selection device  101  preferably sends a load message to the TableOfContentsForm object, as shown by step  18 - 2  of  FIG. 18 . On receipt of the load message, the TableOfContentsForm object displays itself within the main window of the selection device  101 . Upon loading itself, the TableOfContentsForm object may obtain a pointer to the proposal object  110 , as shown by step  18 - 3  of  FIG. 18 . The TableOfContentsForm object then obtains a pointer from the proposal object  110  to the TableOfContentsData object  1 - 30 , as shown by step  18 - 4  of  FIG. 18 . The user may then select the desired “Cover Page”  250  from a list of pages that are available for inclusion in the printed proposal, as shown by step  18 - 5  of  FIG. 18 . The selected page may be stored as a PageDescription record in the TableOfContentsData object  130 , as shown by step  18 - 6  of  FIG. 18 . This PageDescription record may include a field that contains an identifier that indicates which page layout  120  may be used to format the cover sheet  250 . The page layout  120  determines the content and appearance of the final printed page. The page layouts  120  may be stored in the report database  106 . 
     To initiate the printing of the pages of the cover sheet  250 , the user may select “Print”  178  from the main menu  170  of the selection device  101 , as shown by step  19 - 1  of  FIG. 19 . In response, the selection device  101  preferably sends a print request to the report generator  104 , as shown by step  19 - 2  of  FIG. 19 . The report generator  104  typically queries the active database  103  for successive page description records that describe the pages of the printed proposal, as shown by step  19 - 3  of  FIG. 19 . The active database  103  processes the request by searching the TableOfContentsData object  130  located in the current proposal. If the proposal is to include one or more cover sheet  250  pages comprising predetermined pictures and text related to features, benefits and environments of interest to the customer, the active database  103  preferably queries the TableOfContentsData object  13 Q for the applicable PageDescriptionRecord  314 . The TableOfContentsData object  130  returns the relevant PageDescription Record  314  to the active database  103 . The active database  103  may then send the relevant PageDescriptionRecord  314  to the report generator  104 , as shown by step  19 - 4  in  FIG. 19 . These PageDescriptionRecord  314  may include a field that contains an identifier that indicates which page layouts  120  may be used to format these particular cover sheet  250  pages. The report generator  104  preferably queries the report database  106  for the applicable page layouts  120 , as shown by step  19 - 5  in  FIG. 19 . The report database  106  may return the relevant page layouts  120  to the report generator  104 , as shown by step  19 - 6  in  FIG. 19 . 
     Each page layout  120  typically contains formatting specifications that indicate where specific cover sheet  250  information may appear on the printed page. The report generator  104  reads each format specification to determine the data required at that location on the page. 
     The report generator  104  retrieves the text and pictures relating to features, benefits and environments of particular interest to the customer from the static database  105  object, as shown by step  19 - 9  in  FIG. 19 . The static database  105  will preferably return this information to the report generator  104 , as shown by step  19 - 10  in  FIG. 19 . The report generator  104  typically repeats this process for each format specification on the page layout  120 , which builds a cover sheet  250  page that may then be sent to the printer, as shown by step  19 - 11  in  FIG. 19 . In this fashion, the Report Generator  104  may print one or more customized and individualized cover sheet  250  pages. 
     The user interface  102  provides means for inputting the customer identification data of the individual customer who is to receive the proposal. The user may select “Customer Information”  176  from the main menu  170  of the selection device  1001 , as shown by step  20 - 1  in  FIG. 20 . In response, the selection device  1001  preferably sends a load message to the CustomerForm object  286 , as shown by step  20 - 2  in  FIG. 20 . On receipt of the load message, the CustomerForm object  286  displays itself in a window within the main window of the selection device  101 . The CustomerForm object  286  may request a pointer to the current proposal, as shown by step  20 - 3  in  FIG. 20 . The CustomerForm object  286  typically requests from the current proposal pointer to the CustomerData object  136  for this proposal, as shown by step  20 - 4  in  FIG. 20 . 
     The CustomerForm object  286  presents a user interface  102  typically comprising text entry fields and predetermined questions for the user. The text entry fields allow the user to input the name, address, telephone number and other identification data of the individual customer who is to receive the proposal, as shown by step  20 - 5  in  FIG. 20 . The predetermined questions allow the user to select one of a list of predetermined answers that correspond to the individual customer who is to receive the proposal. The customer information gathered by the CustomerForm object  286  may be stored in a CustomerData object  136  within the current proposal, as shown by step  20 - 6  in  FIG. 20 . 
     The cover sheet  250  page layout  120  may specify that the name, address and telephone number or other identification data of the customer appear on the cover sheet  250 . The customer information may be stored in the CustomerData object  136  attached to the proposal. 
     The report generator  104  preferably reads format specifications from the page layout  120  via the report database  106 , as shown by step  21 - 1  in  FIG. 21 . When the particular formatting specification in the page layout  120  requires the customer&#39;s name, address, or telephone number or other identification data to be included on a printed page, the report generator  104  preferably sends a request to the active database  103  for the specified customer information, as shown by step  21 - 2  in  FIG. 21 . The active database  103  obtains the specified customer information from the CustomerData object  136  stored within the current proposal object  110 . The active database  103  then returns this information to the report generator  104 , as shown by step  21 - 3  in  FIG. 21 . The report generator  104  preferably builds the page using this information and sends it to the printer, as shown by step  21 - 4  in  FIG. 21 . 
     The user interface  102  may also provide means for inputting the salesperson identification data of the salesperson who is dealing with the individual customer. When a salesperson first accesses the selection device  101  to begin a proposal for a customer, a PasswordForm object is preferably displayed automatically. The salesperson may enter his/her name and password using the PasswordForm object  300 , as shown by step  22 - 1  in  FIG. 22 . The PasswordForm object  300  typically requests from the selection device  101  a pointer to the ListOfSalesPersonsData object  158  in the customized database  114 , as shown by step  22 - 2  in  FIG. 22 . The PasswordForm object  300 , using this salesperson&#39;s password may locate the name, address, and telephone number of the salesperson, which is stored in the customized database  114 , in a ListOfSalesPersons object, as shown by step  22 - 3  in  FIG. 22 . 
     If the salesperson exists in the ListOfSalesPersons object, the selection device  101  will preferably create a new proposal, which will be the current proposal, as shown by step  22 - 4  in  FIG. 22 . The PasswordForm object  300  may then obtain a pointer to the SalesPersonData object  134  in the proposal, as shown by step  22 - 5  in  FIG. 22 . The salesperson information may be stored in the SalesPersonData object  134  as a part of the current proposal, as shown by step  22 - 6  in  FIG. 22 . 
     Salesperson information for all the employees is preferably stored in the customized database  114  in a ListOfSalesPersons object. The employer may create an individual SalesPerson object for each employee. The ListOfSalesPersons object is a data structure containing a list of SalesPerson objects. 
     Dealership information may also be stored in the customized database  114  in the DealerName object. The SalesPerson object and DealerName object can be created by the employer when the system is first purchased. The employer may choose to secure these two databases so that only the employer&#39;s master password will allow access. These data structures may be modified by the employer via the customized menu selection  177  in the selection device  101 . 
     The user may choose to modify the name, address, and telephone number of the salesperson who is dealing with the individual customer, if the salesperson information is not as it should appear in the printed proposal. To modify the salesperson information, the user may select the appropriate customized menu selection  177  in the main menu  170  of the selection device  101 . However, access to the customized menu selection  177  that allows modification of salesperson information and passwords may be restricted. If the employer has secured this data base, only the employer&#39;s master password should allow access to the salesperson information. 
     The cover sheet  250  page layouts  120  may specify that the name, address and telephone number of the salesperson appear on the cover sheet  250 . The salesperson information is typically initially entered by the employer in the ListOfSalesPersonsData object  158  and is stored in the individual salesperson&#39;s SalesPersonData object  134  attached to the proposal. (See  FIG. 22 ). 
     The report generator  104  reads format specifications from the page layout  120  via the report database  106 , as shown by step  1 - 23  in  FIG. 23 . When the particular format specifiers require the salesperson&#39;s name, address and telephone number to be included on a page format, the report generator  104  preferably sends a request to the active database  103  for the specified salesperson information, as shown by step  2 - 23  in  FIG. 23 . The active database  103  may obtain this salesperson information from the SalesPersonData object  134  in the proposal and returns this salesperson information to the report generator  104 , as shown by step  3 - 23  in  FIG. 23 . The report generator  104  preferably builds the page using this salesperson information and sends the page to the printer, as shown by step  4 - 23  in  FIG. 23 . 
     Proposal: Personalized Letter 
     When the user begins a deal with a customer, the user may want to include a personalized letter  254  in the customized, printed proposal that will be prepared for the customer. 
     The user interface  102  provides means for presenting a series of predetermined queries related to writing a letter  254  of interest to different potential customers who may purchase a product. The user interface  102  also provides means for inputting individualized answers to the predetermined queries, the individualized answers comprising a personalized letter  254  relating to product configurations that are of particular interest to the individual customer who is to receive the proposal. 
     The user may select “Customer Information”  176  from the main menu  170  of the selection device  101 , as shown by step  24 - 1  in  FIG. 24 . The user further selects “Letter”  202  from the “Customer Information” menu  176 . In response, the selection device  101  preferably sends a load message to the LetterForm object  288 , as shown by step  24 - 2  in  FIG. 24 . On receipt of the load message, the LetterForm object  288  displays itself in a window within the main window of the selection device  101 . Upon loading itself, the LetterForm object  288  may obtain a pointer to a proposal object  110 , as shown by step  24 - 3  in  FIG. 24 . The LetterForm object  288  then obtains a pointer from the proposal object  110  to a LetterData object  138 , as shown by step  24 - 4  in  FIG. 24 . 
     The LetterForm object  288  preferably presents a user interface  102  to the user comprising text entry fields and predetermined questions for the user, as shown by step  24 - 5  in  FIG. 24 . This user interface  102  is a means for inputting individualized answers to the predetermined queries, the individualized answers relating to writing a personalized letter  254  regarding a product configuration that is of particular interest to the individual customer who is to receive the proposal. The predetermined questions allow the user to fill in the text entry fields with predetermined answers that correspond to the customer who is to receive the proposal. The personalized letter  254  information gathered by the LetterForm object  288  may then be stored in the LetterData object  138  which is attached to the current proposal object  110 , as shown by step  24 - 6  in  FIG. 24 . 
     The user may decide to generate a customized, printed proposal that includes one or more pages comprising the personalized letter  254 . To include these personalized letter  254  pages, the user may select “Contents”  174  from the main menu  170  of the selection device  101 , as shown by step  18 - 1  of  FIG. 18 . In response, the selection device  101  preferably sends a load message to the TableOfContentsForm object  284 , as shown by step  18 - 2  of  FIG. 18 . On receipt of the load message, the TableOfContentsForm object  284  may display itself within the main window of the selection device  101 . Upon loading itself, the TableOfContentsForm object  284  obtains a pointer to the proposal object  110 , as shown by step  18 - 3  of  FIG. 18 . The TableOfContentsForm object  284  then obtains a pointer from the proposal object  110  to the TableOfContentsData object  130 , as shown by step  18 - 4  of  FIG. 18 . The user may then select the desired Personalized letter  254  page from a list of pages that are available for inclusion in the printed proposal, as shown by step  18 - 5  of  FIG. 18 . The selected pages may be stored as PageDescriptionRecord  314  in a TableOfContentsData object  130 , as shown by step  18 - 6  of  FIG. 18 . These PageDescriptionRecord  314  include a field that contains an identifier that indicates which page layout  120  may be used to format each personalized letter  254  page. The page layout  120  typically determines the content and appearance of the final printed page. The page layouts  120  may be stored in the report database  106 . 
     To initiate the printing of the personalized letter, the user may select “Print”  178  from the main menu  170  of the selection device  101 , as shown by step  25 - 1  of  FIG. 25 . In response, the selection device  101  preferably sends a print request to the report generator  104 , as shown by step  25 - 2  of  FIG. 25 . The report generator  104  queries the active database  103  for successive page description records that describe the pages of the printed proposal, as shown by step  25 - 3  of  FIG. 25 . The active database  103  typically processes the request by searching the TableOfContentsData object  130  located in the current proposal. If the proposal is to include one or more pages comprising the personalized letter  254 , the active database  103  typically queries the TableOfContentsData object  130  for the applicable PageDescriptionRecord  314 . The TableOfContentsData object  130  returns the relevant PageDescriptionRecord  314  to the active database  103 . The Active Database  103  may then send the relevant PageDescriptionRecord  314  to the report generator  104 , as shown by step  25 - 4  in  FIG. 25 . These PageDescriptionRecord  314  may include a field that contains an identifier that indicates which page layouts  120  may be used to format these particular letter  254  pages. The report generator  104  queries the report database  106  for the applicable page layouts  120 , as shown by step  25 - 5  in  FIG. 25 . The report database  106  returns the relevant page layouts  120  to the report generator  104 , as shown by step  25 - 6  in  FIG. 25 . 
     Each page layout  120  contains formatting specifications that indicate where specific Personalized letter  254  information may appear on the printed page. The report generator  104  typically reads each format specification to determine the data required at that location on the page. 
     If the format specifications require data relating to the personalized letter  254 , the report generator  104  preferably queries the active database  103 , as shown by step  25 - 7  in  FIG. 25 . The active database  103  queries the LetterData object  138 , locates and retrieves the applicable personalized letter  254  information from the LetterData object  138 , and returns this personalized letter  254  information to the report generator  104 , as shown by step  25 - 8  in  FIG. 25 . 
     If the format specifications require static pictures or text segments, then the report generator  104  preferably retrieves the applicable information from the static database  105  object, as shown by step  25 - 9  in  FIG. 25 . The static database  105  returns this information to the report generator  104  as shown in step  25 - 10  in  FIG. 25 . The report generator  104  typically repeats this process for each format specification on the page layout  120 , which builds a personalized letter  254  page that is then sent to the printer, as shown by step  25 - 11  in  FIG. 25 . In this fashion, the report generator  104  may print one or more customized and individualized letter  254  pages, along with the predetermined text segments and pictures that correspond with the personalized letter  254  information related to a particular product configuration. 
     The personalized letter  254  page layouts  120  may specify that the name, address and telephone number or other identification data of the customer appear on the letter  254  pages. The customer information may be initially entered via the CustomerForm object  286 . (See  FIG. 20 ). The customer information may be stored in the CustomerData object  136  attached to the proposal. 
     The report generator  104  preferably reads format specifications from the page layout  120  via the report database  106 , as shown by step  21 - 1  in  FIG. 21 . When the particular formatting specification in the page layout  120  requires the customer&#39;s name, address, or telephone number or other identification data to be included on a printed page, the report generator  104  preferably sends a request to the active database  103  for the specified customer information, as shown by step  21 - 2  in  FIG. 21 . The active database  103  may obtain the specified customer information from the CustomerData object  136  stored within the current proposal object  110 . The active database  103  then returns this information to the report generator  104 , as shown by step  21 - 3  in  FIG. 21 . The report generator  104  typically builds the page using this information and sends it to the printer, as shown by step  21 - 4  in  FIG. 21 . 
     The letter  254  page layouts  120  may specify that the name, address and telephone number of the salesperson appear on the letter  254  pages. The salesperson information may be initially entered by the employer in the ListOfSalesPersonsData object  158  and is stored in the individual salesperson&#39;s SalesPersonData object  134  attached to the proposal. (See  FIG. 22 ). The report generator  104  may read format specifications from the page layout  120  via the report database  106 , as shown by step  23 - 1  in  FIG. 23 . When the particular format specifiers require the salesperson&#39;s name, address and telephone number to be included on a page format, the report generator  104  preferably sends a request to the active database  103  for the specified salesperson information, as shown by step  23 - 2  in  FIG. 23 . The active database  103  obtains this salesperson information from the SalesPersonData object  134  in the proposal and returns this salesperson information to the report generator  104 , as shown by step  23 - 3  in  FIG. 23 . The report generator  104  preferably builds the page using this salesperson information and sends the page to the printer, as shown by step  23 - 4  in  FIG. 23 . 
     Proposal: Product Description Pages 
     When the user begins a deal with a customer, the user may want to include in the customized, printed proposal one or more product description pages each comprising predetermined pictures and text relating to features, benefits and environments of interest to the customer. 
     The user interface  102  provides a means for presenting a series of predetermined queries related to features, benefits and environments of particular items of standard and optional equipment that may be included in the product. This product description information may be of interest to different potential customers who may purchase the product. The user interface  102  is also a means for selecting particular items of standard and optional equipment about which product description information should appear in the printed proposal. 
     The user may select “Customer Information”  176  from the main menu  170  of the selection device  101 , as shown by step  26 - 1  in  FIG. 26 . The user further selects “Standard and Optional Equipment” from the “Customer Information”  176  menu. In response, the selection device  101  preferably sends a load message to the ProductForm object  290 , as shown by step  26 - 2  in  FIG. 26 . On receipt of the load message, the ProductForm object  290  may display itself in a window within the main window of the selection device  101 . Upon loading itself, the ProductForm object  290  obtains a pointer to a proposal object  110 , as shown by step  26 - 3  in  FIG. 26 . The ProductForm object  290  may then obtain a pointer from the proposal object  110  to a ProductData object  140 , as shown by step  26 - 4  in  FIG. 26 . 
     The ProductForm object  290  presents a user interface  102  to the user typically comprising text entry fields and predetermined questions for the user, as shown by step  26 - 5  in  FIG. 26 . The predetermined questions allow the user to specify those items of standard and optional equipment about which features and benefits information is of particular interest to the customer who is to receive the proposal. The product description information gathered by the ProductForm object  290  may then be stored in the ProductData object  140  which is attached to the current proposal object  110 , as shown by step  26 - 6  in  FIG. 26 . 
     The user may decide to generate a customized, printed proposal that includes one or more product description pages. To include these product description pages, the user may select “Contents”  174  from the main menu  170  of the selection device  101 , as shown by step  18 - 1  of  FIG. 18 . In response, the selection device  101  preferably sends a load message to the TableOfContentsForm object  284 , as shown by step  18 - 2  of  FIG. 18 . On receipt of the load message, the TableOfContentsForm object  284  may display itself within the main window of the selection device  101 . Upon loading itself, the TableOfContentsForm object  284  obtains a pointer to the proposal object  110 , as shown by step  18 - 3  of  FIG. 18 . The TableOfContentsForm object  284  then obtains a pointer from the proposal object  110  to the TableOfContentsData object  123 , as shown by step  18 - 4  of  FIG. 18 . The user may then select the desired product description pages from a list of pages that are available for inclusion in the printed proposal, as shown by step  18 - 5  of  FIG. 18 . The selected pages may be stored as PageDescriptionRecord  314  in a TableOfContentsData object  123 , as shown by step  18 - 6  of  FIG. 18 . These PageDescriptionRecord  314  typically include a field that contains an identifier that indicates which page layout  120  may be used to format each product description page. The page layout  120  preferably determines the content and appearance of the final printed page. The page layouts  120  are stored in the report database  106 . 
     To initiate the printing of the product description pages, the user may select “Print”  178  from the main menu  170  of the selection device  101 , as shown by step  27 - 1  of  FIG. 27 . In response, the selection device  101  preferably sends a print request to the report generator  104 , as shown by step  27 - 2  of  FIG. 27 . The report generator  104  may query the active database  103  for successive page description records that describe the pages of the printed proposal, as shown by step  27 - 3  of  FIG. 27 . The active database  103  typically processes the request by searching the TableOfContentsData object  130  located in the current proposal. If the proposal is to include one or more product description pages comprising predetermined pictures and text related to features, benefits and environments of interest to the customer, the active database  103  preferably queries the TableOfContentsData object  130  for the applicable PageDescriptionRecord  314 . The TableOfContentsData object  130  returns the relevant PageDescriptionRecord  314  to the active database  103 . The active database  103  may then send the relevant PageDescriptionRecord  314  to the report generator  104 , as shown by step  27 - 4  in  FIG. 27 . These PageDescriptionRecord  314  may include a field that contains an identifier that indicates which page layouts  120  may be used to format these particular product description pages. The report generator  104  queries the report database  106  for the applicable page layouts  120 , as shown by step  27 - 5  in  FIG. 27 . The report database  106  returns the relevant page layouts  120  to the report generator  104 , as shown by step  27 - 6  in  FIG. 27 . 
     Each page layout  120  preferably contains formatting specifications that indicate where specific product description information may appear on the printed page. The report generator  104  reads each format specification to determine the data required at that location on the page. 
     If the format specifications require data relating to the features, benefits and environments of interest to a customer, the report generator  104  preferably queries the active database  103  for the standard and optional equipment product description information, as shown by step  27 - 7  in  FIG. 27 . The active database  103  queries the ProductData object  140 , locates and retrieves the selected items of standard and optional equipment from the ProductData object  140 , and returns this information to the report generator  104 , as shown by step  27 - 8  in  FIG. 27 . 
     The report generator  104  typically retrieves the text and pictures relating to features, benefits and environments for items of standard and optional equipment selected for inclusion in the printed proposal from the static database  105  object, as shown by step  27 - 9  in  FIG. 27 . The static database  105  may return this information to the report generator  104 , as shown by step  27 - 10  in  FIG. 27 . The report generator  104  preferably repeats this process for each format specification on the page layout  120 , which builds a product description page that is then sent to the printer, as shown by step  27 - 11  in  FIG. 27 . In this fashion, the Report Generator  104  may print one or more customized and individualized product description pages. The product description page layout  120  may specify that the name, address and telephone number or other identification data of the customer appear on the product description pages. The customer information may be initially entered via the CustomerForm object  286 . (See  FIG. 20 ). The customer information may be stored in the CustomerData object  136  attached to the proposal. 
     The report generator  104  reads format specifications from the page layout  120  via the report database  106 , as shown by step  21 - 1  in  FIG. 21 . When the particular formatting specification in the page layout  120  requires the customer&#39;s name, address, or telephone number or other identification data to be included on a printed page, the report generator  104  preferably sends a request to the active database  103  for the specified customer information, as shown by step  21 - 2  in  FIG. 21 . The active database  103  may obtain the specified customer information from the CustomerData object  136  stored within the current proposal object  110 . The active database  103  then returns this information to the report generator  104 , as shown by step  21 - 3  in  FIG. 21 . The report generator  104  typically builds the page using this information and sends it to the printer, as shown by step  21 - 4  in  FIG. 21 . 
     The product description page layout  120  may specify that the name, address and telephone number of the salesperson appear on the product description pages. The salesperson information may be initially entered by the employer, for example, in the ListOfSalesPersonsData object  158  and may be stored in the individual salesperson&#39;s SalesPersonData object  134  attached to the proposal. (See  FIG. 22 ). The report generator  104  reads format specifications from the page layout  120  via the report database  106 , as shown by step  23 - 1  in  FIG. 23 . When the particular format specifiers require the salesperson&#39;s name, address and telephone number to be included on a page format, the report generator  104  preferably sends a request to the active database  103  for the specified salesperson information, as shown by step  23 - 2  in  FIG. 23 . The active database  103  obtains this salesperson information from the SalesPersonData object  134  in the proposal and returns this salesperson information to the report generator  104 , as shown by step  23 - 3  in  FIG. 23 . The report generator  104  typically builds the page using this salesperson information and sends the page to the printer, as shown by step  23 - 4  in  FIG. 23 . 
     Proposal: Product Specification Pages 
     When the user begins a deal with a customer, the user may want to include in the customized, printed proposal one or more individualized pages comprising the product specification which is of particular interest to the customer who is to receive the proposal. The user interface  102  provides a means for presenting a series of predetermined queries related to the particular items of standard and optional equipment that may be included in the product specification of particular interest to a customer. The user interface  102  also provides a means for selecting particular items of standard and optional equipment to be included in the product specification of a particular product. 
     The user may select “Customer Information”  176  from the main menu  170  of the selection device  101 , as shown by step  28 - 1  in  FIG. 28 . The user may further select “Standard and Optional Equipment” from the “Customer Information”  176  menu. In response, the selection device  101  preferably sends a load message to the ProductForm object  290 , as shown by step  28 - 2  in  FIG. 28 . On receipt of the load message, the ProductForm object  290  may display itself in a window within the main window of the selection device  101 . Upon loading, itself, the ProductForm object  290  obtains a pointer to a proposal object  110 , as shown by step  28 - 3  in  FIG. 28 . The ProductForm object  290  then obtains a pointer from the proposal object  110  to a ProductData object  140 , as shown by step  28 - 4  in  FIG. 28 . 
     The ProductForm object  290  presents a user interface  102  to the user typically comprising text entry fields and predetermined questions for the user, as shown by step  28 - 5  in  FIG. 28 , The predetermined questions allow the user to specify those items of standard and optional equipment to be included in the product specification of particular interest to the customer who is to receive the proposal. The product specification gathered by the ProductForm object  290  may then be stored in the ProductData object  140  which is attached to the current proposal object  110 , as shown by step  28 - 6  in  FIG. 28 . 
     The user may decide to generate a customized, printed proposal that includes one or more product specification pages. To include these product specification pages, the user may select “Contents”  174  from the main menu  170  of the selection device  101 , as shown by step  18 - 1  of  FIG. 18 . In response, the selection device  1001  preferably sends a load message to the TableOfContentsForm object  284 , as shown by step  18 - 2  of  FIG. 18 . On receipt of the load message, the TableOfContentsForm object  284  may display itself within the main window of the selection device  101 . Upon loading itself, the TableOfContentsForm object  284  obtains a pointer to the proposal object  110 , as shown by step  18 - 3  of  FIG. 18 . The TableOfContentsForm object  284  then obtains a pointer from the proposal object  110  to the TableOfContentsData object  130 , as shown by step  18 - 4  of  FIG. 18 . The user may then select the desired product specification pages from a list of pages that are available for inclusion in the printed proposal, as shown by step  18 - 5  of  FIG. 18 . The selected pages may be stored as PageDescriptionRecord  314  in a TableOfContentsData object  130 , as shown by step  18 - 6  of  FIG. 18 . These PageDescriptionRecord  314  typically include a field that contains an identifier that indicates which page layout  120  may be used to format each product specification page. The page layout  120  preferably determines the content and appearance of the final printed page. The page layout  120  may be stored in the report database  106 . 
     To initiate the printing of the product specification pages, the user may select “Print”  178  from the main menu  170  of the selection device  101 , as shown by step  29 - 1  of  FIG. 29 . In response, the selection device  101  preferably sends a print request to the report generator  104 , as shown by step  29 - 2  of  FIG. 29 . The report generator  104  may query the Active Database  103  for successive page description records that describe the pages of the printed proposal, as shown by step  29 - 3  of  FIG. 29 . The active database  103  preferably processes the request by searching the TableOfContentsData object  130  located in the current proposal. If the proposal is to include one or more product specification pages, the active database  103  queries the TableOfContentsData object  130  for the applicable PageDescriptionRecord  314 . The TableOfContentsData object  130  returns the relevant PageDescriptionRecord  314  to the active database  103 . The active database  103  then sends the relevant PageDescriptionRecord  314  to the report generator  104 , as shown by step  29 - 4  in  FIG. 29 . These PageDescriptionRecord  314  may include a field that contains an identifier that indicates which page layout  120  may be used to format these particular product specification pages. The report generator  104  queries the report database  106  for the applicable page layout  120 , as shown by step  29 - 5  in  FIG. 29 . The report database  106  returns the relevant page layout  120  to the report generator  104 , as shown by step  29 - 6  in  FIG. 29 . 
     Each page layout  120  preferably contains formatting specifications that indicate where specific product specification information may appear on the printed page. The report generator  104  reads each format specification to determine the data required at that location on the page. 
     If the format specifications require data relating to the product specification of interest to a customer, the report generator  104  queries the active database  103  for the product specification information, as shown by step  29 - 7  in  FIG. 29 . The active database  103  queries the ProductData object  140 , locates and retrieves the product specification information from the ProductData object  140 , and returns this information to the report generator  104 , as shown by step  29 - 8  in  FIG. 29 . 
     The product specification information stored in the active database  103  may be linked to additional product specification information stored in the static database  105 . 
     The additional product specification information may include weights and prices of the individual items of standard and optional equipment included in the product of interest to the customer. 
     The report generator  104  retrieves the additional product specification information for items of standard and optional equipment selected for inclusion in the printed proposal from the static database  105 , as shown by step  29 - 9  in  FIG. 29 . The static database  105  may return this information to the report generator  104 , as shown by step  29 - 10  in  FIG. 29 . The report generator  104  preferably repeats this process for each format specification on the page layout  120 , which builds a product specification page that is then sent to the printer, as shown by step  29 - 11  in FIG.  29 . In this fashion, the report generator  104  may print one or more customized and individualized product specification pages. 
     The product specification page layout  120  may specify that the name, address and telephone number or other identification data of the customer appear on the product specification pages. The customer information may be initially entered via the CustomerForm object  286 . (See  FIG. 20 ). The Customer information may be stored in the CustomerData object  136  attached to the proposal. 
     The report generator  104  may read format specifications from the page layout  120  via the report database  106 , as shown by step  21 - 1  in  FIG. 21 . When the particular formatting specification in the page layout  120  requires the customer&#39;s name, address, or telephone number or other identification data to be included on a printed page, the report generator  104  preferably sends a request to the active database  103  for the specified customer information, as shown by step  21 - 2  in  FIG. 21 . The active database  103  obtains the specified customer information from the CustomerData object  136  stored within the current proposal object. The active database  103  then returns this information to the report generator  104 , as shown by step  21 - 3  in  FIG. 21 . The report generator  104  typically builds the page using this information and sends it to the printer, as shown by step  21 - 4  in  FIG. 21 . 
     The product specification page layout  120  may specify that the name, address and telephone number of the salesperson appear on the product specification pages. The salesperson information may be initially entered by the employer, for example, in the ListOfSalesPersonsData object  158  and may be stored in the individual salesperson&#39;s SalesPersonData object  134  attached to the proposal. (See  FIG. 22 ). The report generator  104  reads format specifications from the page layout  120  via the report database  106 , as shown by step  23 - 1  in  FIG. 23 . When the particular format specifiers require the salesperson&#39;s name, address and telephone number to be included on a page format, the report generator  104  preferably sends a request to the active database  103  for the specified salesperson information, as shown by step  23 - 2  in  FIG. 23 . The active database  103  obtains this salesperson information from the SalesPersonData object  134  in the proposal and returns this salesperson information to the report generator  104 , as shown by step  23 - 3  in  FIG. 23 . The report generator  104  typically builds the page using this salesperson information and sends the page to the printer, as shown by step  23 - 4  in  FIG. 23 . 
     Proposal: Performance Specification Pages 
     When the user begins a deal with a customer, the user may want to include in the customized, printed proposal one or more individualized pages comprising the performance specifications that are of particular interest to the customer who is to receive the proposal. 
     The user may decide to generate a customized, printed proposal that includes one or more performance specification pages  240 . To include these performance specification pages  240 , the user may select “Contents”  174  from the main menu  170  of the selection device  101 , as shown by step  18 - 1  of  FIG. 18 . In response, the selection device  101  preferably sends a load message to the TableOfContentsForm object  284 , as shown by step  18 - 2  of  FIG. 18 . On receipt of the load message, the TableOfContentsForm object  284  may display itself within the main window of the selection device  101 . Upon loading itself, the TableOfContentsForm object  284  obtains a pointer to the proposal object  110 , as shown by step  18 - 3  of  FIG. 18 . The TableOfContentsForm object  284  then obtains a pointer from the proposal object  110  to the TableOfContentsData object  130 , as shown by step  18 - 4  of  FIG. 18 . The user then selects the desired performance specification pages  240  from a list of pages that are available for inclusion in the printed proposal, as shown by step  18 - 5  of  FIG. 18 . The selected pages are stored as PageDescriptionRecord  314  in a TableOfContentsData object  130 , as shown by step  18 - 6  of  FIG. 18 . These PageDescriptionRecord  314  include a field that contains an identifier that indicates which page layout  120  may be used to format each performance specification page  240 . The page layout  120  preferably determines the content and appearance of the final printed page. The page layout  120  may be stored in the report database  106 . 
     To initiate the printing of the performance specification pages  240 , the user may select “Print”  178  from the main menu  170  of the selection device  101 , as shown by step  30 - 1  of  FIG. 30 . In response, the selection device  101  preferably sends a print request to the report generator  104 , as shown by step  30 - 2  of  FIG. 30 . The report generator  104  queries the active database  103 , for successive page description records that describe the pages of the printed proposal, as shown by step  30 - 3  of  FIG. 30 . The active database  103  processes the request by searching the TableOfContentsData object  130  located in the current proposal. If the proposal is to include one or more performance specification pages Z 40 , the active database  103  queries the TableOfContentsData object  130  for the applicable PageDescriptionRecord  314 . The TableOfContentsData object  130  returns the relevant PageDescriptionRecord  314  to the active database  103 . The active database  103  then sends the relevant PageDescriptionRecord  314  to the report generator  104 , as shown by step  30 - 4  in  FIG. 30 . These PageDescriptionRecord  314  may include a field that contains an identifier that indicates which page layout  120  may be used to format these particular performance specification pages  240 . The report generator  104  queries the report database  106  for the applicable page layout  120 , as shown by step  30 - 5  in  FIG. 30 . The report database  106  returns the relevant page layout  120  to the report generator  104 , as shown by step  30 - 6  in  FIG. 30 . 
     Each page layout  120  typically contains formatting specifications that indicate where specific performance specification information may appear on the printed page. The report generator  104  may read each format specification to determine the data required at that location on the page. 
     If the format specifications require data relating to the performance specification of interest to a customer, the report generator  104  queries the active database  103  for the performance specification information, as shown by step  30 - 7  in  FIG. 30 . The active database  103  will preferably handle the process of calculating the desired performance specification information based on the product specification stored within itself and additional performance information linked to this product information  238  and stored in the static database  105 . The active database  103  may return this information to the report generator  104 , as shown by step  30 - 8  in  FIG. 30 . 
     If the format specifications require static pictures or text segments, then the report generator  104  typically retrieves the applicable information from the static database  105  object, as shown by step  30 - 9  in  FIG. 30 . The report generator  104  may repeat this process for each format specification on the page layout, which builds a performance specification page  240  that is then sent to the printer, as shown by step  30 - 11  in  FIG. 30 . In this fashion, the report generator  104  may print one or more customized and individualized performance specification pages  240 . 
     The performance specification page layout  120  may specify that the name, address and telephone number or other identification data of the customer appear on the performance specification pages  24 . The customer information may be initially entered via the CustomerForm object  286 . (See  FIG. 20 ). The customer information may be stored in the CustomerData object  136  attached to the proposal. 
     The report generator  104  typically reads format specifications from the page layout  120  via the report data base  106 , as shown by step  21 - 1  in  FIG. 21 . When the particular formatting specification in the page layout  120  requires the customer&#39;s name, address, or telephone number or other identification data to be included on a printed page, the report generator  104  preferably sends a request to the active database  103  for the specified customer information, as shown by step  21 - 2  in  FIG. 21 . The active database  103  obtains the specified customer information from the customer data object  136  stored within the current proposal object  110 . The active database  103  then returns this information to the report generator  104 , as shown by step  21 - 3  in  FIG. 21 . The report generator  104  may then build the page using this information and sends it to the printer, as shown by step  21 - 4  in  FIG. 21 . 
     The performance specification page layout  120  may specify that the name, address and telephone number of the salesperson appear on the performance specification pages  240 . The salesperson information may be initially entered by the employer in the ListOfSalesPersonsData object  158  and is stored in the individual salesperson&#39;s SalesPersonData object  134  attached to the proposal. (See  FIG. 22 ). The report generator  104  reads format specifications from the page layout via the report database  106 , as shown by step  23 - 1  in  FIG. 23 . When the particular format specifiers require the salesperson&#39;s name, address and telephone number to be included on a page format, the report generator  104  preferably sends a request to the active database  103  for the specified salesperson information, as shown by step  23 - 2  in  FIG. 23 . The active database  103  obtains this salesperson information from the SalesPersonData object  134  in the proposal and returns this salesperson information to the report generator  104 , as shown by step  23 - 3  in FIG.  23 . The report generator  104  typically builds the page using this salesperson information and sends the page to the printer, as shown by step  23 - 4  in  FIG. 23 . 
     Proposal: Trade-in Pages 
     When the user begins a deal with a customer, the customer may want to trade in a product, in which case, the user will typically want to include individualized trade-in product information pages  242  in the customized, printed proposal that will be prepared for the customer. 
     The user interface  102  provides means for presenting a series of predetermined queries related to the description and appraised value of a trade-in product to be traded in by the individual customer who is to receive the proposal. The user interface  102  also provides means for inputting individualized answers to the predetermined queries, the individualized answers relating to the description and appraised value of a trade-in product to be traded in by the individual customer who is to receive the proposal. 
     The user may select “Customer Information”  176  from the main menu  170  of the selection device  101 , as shown by step  31 - 1  in  FIG. 31 . The user further selects “Trade”  206  from the customer information menu. In response, the selection device  101  preferably sends a load message to the TradeForm object  292 , as shown by step  31 - 2  in  FIG. 31 . On receipt of the load message, the TradeForm object  292  may display itself in a window within the main window of the selection device  101 . Upon loading itself, the TradeForm object  292  obtains a pointer to a proposal object  110 , as shown by step  31 - 3  in  FIG. 31 . The TradeForm object  292  then obtains a pointer from the proposal object  110  to a TradeData object  142 , as shown by step  31 - 4  in  FIG. 31 . 
     The TradeForm object  292  presents a user interface  102  to the user typically comprising text entry fields and predetermined questions for the user, as shown by step  31 - 5  in  FIG. 31 . This user interface  102  allows the user to enter information regarding a trade-in product to be traded in by the individual customer who is to receive the proposal. The user may fill in various data fields with information comprising a description and appraised value for the trade-in product. The predetermined questions allow the user to select one of a list of predetermined answers that correspond to the trade-in product of the customer who is to receive the proposal. The trade-in information gathered by the TradeForm object  292  may be stored in the TradeData object  142  which is attached to the current proposal object  110 , as shown by step  31 - 6  in  FIG. 31 . 
     The user may decide to generate a customized, printed proposal that includes one or more pages comprising the description and appraised value of a trade-in product. To include these trade-in pages, the user may select “Contents”  174  from the main menu  170  of the selection service  101 , as shown by step  18 - 1  of  FIG. 18 . In response, the selection device  101  preferably sends a load message to the TableOfContentsForm object  284 , as shown by step  18 - 2  of  FIG. 18 . On receipt of the load message, the TableOfContentsForm object  284  may display itself within the main window of the selection device  101 . Upon loading itself, the TableOfContentsForm object  284  obtains a pointer to the proposal object  110 , as shown by step  18 - 3  of  FIG. 18 . The TableOfContentsForm object  284  then obtains a pointer from the proposal object  110  to the TableOfContentsData object  130 , as shown by step  18 - 4  of  FIG. 18 . The user may then select the desired trade-in pages from a list of pages that are available for inclusion in the printed proposal, as shown by step  18 - 5  of  FIG. 18 . The selected pages may be stored as PageDescriptionRecord  314  in TableOfContentsData object  130 , as shown by step  18 - 6  of  FIG. 18 . These PageDescriptionRecord  314  include a field that contains an identifier that indicates which page layout  120  may be used to format each trade-in page  242 . The page layout  120  preferably determines the content and appearance of the final printed page. The page layouts  120  may be stored in the report database  106 . 
     To initiate the printing of the trade-in pages  242  comprising the description and appraised value of die trade-in product, the user may select “Print”  178  from the main menu  170  of the selection device  101 , as shown by step  32 - 1  of  FIG. 32 . In response, the selection device  101  preferably sends a print request to the report generator  104 , as shown by step  32 - 2  of  FIG. 32 . The report generator  104  queries the active database  103  for successive page description records that describe the pages of the printed proposal, as shown by step  32 - 3  of  FIG. 32 . The active database  103  typically processes the request by searching the TableOfContentsData object  130  located in the current proposal. If the proposal is to include one or more pages comprising the description and appraised value of a trade-in product, the active database  103  queries the TableOfContentsData object  130  for the applicable PageDescriptionRecord  314 . The TableOfContentsData object  130  returns the relevant PageDescriptionRecord  314  to the active database  103 . The active database  103  then sends the relevant PageDescriptionRecord  314  to the report generator  104 , as shown by step  32 - 4  in  FIG. 32 . These PageDescriptionRecord  314  may include a field that contains an identifier that indicates which page layout may be used to format these particular trade-in pages  242 . The report generator  104  queries the report database  106  for the applicable page layout, as shown by step  32 - 5  in  FIG. 32 . The report database  106  returns the relevant page layout to the report generator  104 , as shown by step  32 - 6  in  FIG. 32 . 
     Each page layout may contain formatting specifications that indicate where specific information regarding the description and appraised value of the trade-in product may appear on the printed page. The report generator  104  may read each format specification to determine the data required at that location on the page. 
     If the format specifications require data relating to the description and appraised value of the trade-in product, the report generator  104  preferably queries the active database  103 , as shown by step  32 - 7  in  FIG. 32 . The active database  103  queries the TradeData object  142 , locates and retrieves the applicable description and appraised value information from the TradeData object  142 , and returns this trade-in information to the report generator  104 , as shown by step  32 - 8  in  FIG. 32 . 
     If the format specifications require static pictures or text segments, then the report generator  104  may retrieve the applicable information from the static database  105  object, as shown by step  32 - 9  in  FIG. 32 . The static database  105  may return this information to the report generator  104 , as shown by step  32 - 10  in  FIG. 32 . The report generator  104  typically repeats this process for each format specification on the page layout, which builds a trade-in page  242  that may then be sent to the printer, as shown by step  32 - 11  in  FIG. 32 . 
     In this fashion, the report generator  104  may print one or more customized and individualized trade-in product pages  242  which comprise the description and appraised value of a trade-in product, along with the predetermined text segments and pictures that correspond with this specified trade-in product. 
     The trade-in page layout  120  may specify that the name, address and telephone number or other identification data of the customer appear on the trade-in pages. The customer information may be initially entered via the CustomerForm object  286 . (See  FIG. 20 ). The customer information may be stored in the CustomerData object  136  attached to the proposal. 
     The report generator  104  may read format specifications from the page layout via the report database  106 , as shown by step  21 - 1  in  FIG. 21 . When the particular formatting specification in the page layout requires the customer&#39;s name, address, or telephone number or other identification data to be included on a printed page, the report generator  104  preferably sends a request to the active database  103  for the specified customer information, as shown by step  21 - 2  in  FIG. 21 . The active database  103  obtains the specified customer information from the CustomerData object  136  stored within the current proposal object  110 . The active database  103  then returns this information to the report generator  104 , as shown by step  21 - 3  in  FIG. 21 . The report generator  104  typically builds the page using this information and sends it to the printer, as shown by step  21 - 4  in  FIG. 21 . 
     The trade-in page layout may specify that the name, address and telephone number of the salesperson appear on the trade-in pages. The salesperson information may be initially entered by the employer in the ListOfSalesPersonsData object  158  and may be stored in the individual salesperson&#39;s SalesPersonData object  134  attached to the proposal. (See  FIG. 22 ). The report generator  104  may read format specifications from the page layout via the report database  106 , as shown by step  23 - 1  in  FIG. 23 . When the particular format specifiers require the salesperson&#39;s name, address and telephone number to be included on a page format, the report generator  104  preferably sends a request to the active database  103  for the specified salesperson information, as shown by step  23 - 2  in  FIG. 23 . The active database  103  obtains this salesperson information from the SalesPersonData object  134  in the proposal and returns this salesperson information to the report generator  104 , as shown by step  23 - 3  in  FIG. 23 . The report generator  104  typically builds the page using this salesperson information and sends the page to the printer, as shown by step  23 - 4  in  FIG. 23 . 
     Proposal: Product Price Quotation Pages 
     The user interface  102  provides means for presenting a series of predetermined queries related to the product price quotation for a product of interest to a potential customer. The user interface  102  also provides means for inputting individualized answers to the predetermined queries, the individualized answers relating to the product price quotation of a particular product configuration that is of particular interest to the individual customer who is to receive the proposal. 
     The user may select “Customer Information”  176  from the main menu  170  of the selection device  101 , as shown by step  33 - 1  in  FIG. 33 . The user may further select “Quotation” from the “Customer Information”  176  menu. In response, the selection device  101  preferably sends a load message to the QuotationForm object  294 , as shown by step  33 - 2  in  FIG. 33 . On receipt of the load message, the QuotationForm object  294  may display itself in a window within the main window of the selection device  101 . 
     Upon loading itself, the QuotationForm object  294  obtains a pointer to a proposal object  110 , as shown by step  33 - 3  in  FIG. 33 . The QuotationForm object  294  then obtains a pointer from the proposal object  110  to a QuotationData object  144 , as shown by step  33 - 4  in  FIG. 33 . 
     The QuotationForm object  294  presents a user interface  102  to the user typically comprising text entry fields and predetermined questions for the user, as shown by step  33 - 5  in  FIG. 33 . The user interface  102  provides means for inputting individualized answers to the predetermined queries, the individualized answers relating to the price quotation for a product configuration that is of particular interest to the individual customer who is to receive the proposal. The predetermined questions may allow the user to modify the price quotation for to a product configuration that is of particular interest to the customer who is to receive the proposal. The price quotation information gathered by the QuotationForm object  294  may then be stored in the QuotationData object  144  which is attached to the current proposal object  110 , as shown by step  33 - 6  in  FIG. 33 . The user may wish to compare the product price quotations of different product configurations. This comparison may be accomplished by repeating the process described above and in  FIG. 33  to create multiple QuotationData objects  144 . 
     When the user begins a deal with a customer, the user may want to include in the proposal one or more individualized pages comprising the product price quotation which is of particular interest to the customer who is to receive the proposal. To include the product price quotation pages, the user may select “Contents”  174  from the main menu  170  of the selection device  101 , as shown by step  18 - 1  of  FIG. 18 . In response, the selection device  101  preferably sends a load message to the TableOfContentsForm object  284 , as shown by step  18 - 2  of  FIG. 18 . On receipt of the load message, the TableOfContentsForm object  284  may display itself within the main window of the selection device  101 . Upon loading itself, the TableOfContentsForm object  284  obtains a pointer to the proposal object  110 , as shown by step  18 - 3  of  FIG. 18 . The TableOfContentsForm object  284  then obtains a pointer from the proposal object  110  to the TableOfContentsData object  130 , as shown by step  18 - 4  of  FIG. 18 . The user may then select the desired price quotation pages from a list of pages that are available for inclusion in the printed proposal, as shown by step  18 - 5  of  FIG. 18 . The selected pages may be stored as PageDescriptionRecord  314  in a TableOfContentsData object  130 , as shown by step  18 - 6  of  FIG. 18 . These PageDescriptionRecord  314  typically include a field that contains an identifier that indicates which page layout may be used to format each price quotation page. The page layout may determine the content and appearance of the final printed page. The page layout may be stored in the report database  106 . 
     To initiate the printing of the product price quotation pages, the user may select “Print”  178  from the main menu  170  of the selection device  101 , as shown by step  34 - 1  of  FIG. 34 . In response, the selection device  101  preferably sends a print request to the report generator  101 , as shown by step  34 - 2  of  FIG. 34 . The report generator  104  queries the active database  103  for successive page description records that describe the pages of the printed proposal, as shown by step  34 - 3  of  FIG. 34 . The active database  103  typically processes the request by searching the TableOfContentsData object  130  located in the current proposal. If the proposal is to include one or more product price quotation pages, the active database  103  queries the TableOfContentsData object  130  for the applicable PageDescriptionRecord  314 . The TableOfContentsData object  130  returns the relevant PageDescriptionRecord  314  to the active database  103 . The active database  103  then sends the relevant PageDescriptionRecord  314  to the report generator  104 , as shown by step  34 - 4  in  FIG. 34 . These PageDescriptionRecord  314  may include a field that contains an identifier that indicates which page layout may be used to format these particular product price quotation pages. The report generator  104  queries the report database  106  for the applicable page layout, as shown by step  34 - 5  in  FIG. 34 . The report database  106  returns the relevant page layout to the report generator  104 , as shown by step  34 - 6  in  FIG. 34 . 
     Each page layout preferably contains formatting specifications that indicate where specific product price quotation information may appear on the printed page. The report generator  104  may read each format specification to determine the data required at that location on the page. 
     If the format specifications require data relating to the product price quotation of interest to a customer, the report generator  104  queries the active database  103  for the product price quotation information, as shown by step  34 - 7  in  FIG. 34 . The active database  103  will preferably handle the process of calculating the desired product price quotation based on the product specification stored within itself and on additional price information stored in the static database  105  and linked to this product information  238 . The active database  103  may return this information to the report generator  104 , as shown by step  34 - 8  in  FIG. 34 . 
     If the format specifications require static pictures or text segments, then the report generator  104  preferably retrieves the applicable information from the static database  105  object, as shown by step  34 - 9  in  FIG. 34 . The static database  105  may return this information to the report generator  104 , as shown by step  34 - 10  in  FIG. 34 . The report generator  104  typically repeats this process for each format specification on the page layout, which builds a product price quotation page that is then sent to the printer, as shown by step  34 - 11  in  FIG. 34 . In this fashion, the report generator  104  may print one or more customized and individualized product price quotation pages. The product price quotation page layout may specify that the name, address and telephone number or other identification data of the customer appear on the product price quotation pages. The customer information was initially entered via the CustomerForm object  286 . (See  FIG. 20 ). The customer information may be stored in the CustomerData object  136  attached to the proposal. 
     The report generator  104  reads format specifications from the page layout via the report database  106 , as shown by step  21 - 1  in  FIG. 21 . When the particular formatting specification in the page layout requires the customer&#39;s name, address, or telephone number or other identification data to be included on a printed page, the report generator  104  preferably sends a request to the active database  103  for the specified customer information, as shown by step  21 - 2  in  FIG. 21 . The active database  103  obtains the specified customer information from the CustomerData object  136  stored within the current proposal object. The active database  103  then returns this information to the report generator  104 , as shown by step  21 - 3  in  FIG. 21 . The report generator  104  typically builds the page using this information and sends it to the printer, as shown by step  21 - 4  in  FIG. 21 . 
     The product price quotation page layout may specify that the name, address and telephone number of the salesperson appear on the product price quotation pages. The salesperson information may be initially entered by the employer in the ListOfSalesPersonsData object  158  and is stored in the individual salesperson&#39;s SalesPersonData object  134  attached to the proposal. (See  FIG. 22 ). The report generator  104  reads format specifications from the product price quotation page layout via the report database  106 , as shown by step  23 - 1  in  FIG. 23 . When the particular format specifiers require the salesperson&#39;s name, address and telephone number to be included on a page format, the report generator  104  preferably sends a request to the active database  103  for the specified salesperson information, as shown by step  23 - 2  in  FIG. 23 . The active database  103  obtains this salesperson information from the SalesPersonData object  134  in the proposal and returns this salesperson information to the report generator  104 , as shown by step  23 - 3  in  FIG. 23 . The report generator  104  typically builds the page using this salesperson information and sends the page to the printer, as shown by step  23 - 4  in  FIG. 23 . 
     Proposal: Finance Pages 
     When the user begins a deal with a customer, the user may want to include one or more individualized pages which comprise the financing information to be included in the customized, printed proposal that will be prepared for the customer. The user interface  102  provides means for presenting a series of predetermined queries related to financing a product of interest to different potential customers who may purchase the product. The user interface  102  also provides means for inputting individualized answers to the predetermined queries, the individualized answers relating to the finance cost of product configurations that are of particular interest to the individual customer who is to receive the proposal. 
     The user may select “Customer Information”  176  from the main menu  170  of the selection device  101 , as shown by step  35 - 1  in  FIG. 5 . The user may further select “Payment Schedule &amp; Terms” from the “Customer Information”  176  menu. In response, the selection device  101  preferably sends a load message to the FinanceForm object  296 , as shown by step  35 - 2  in  FIG. 35 . On receipt of the load message, the FinanceForm object  296  may display itself in a window within the main window of the selection device  101 . Upon displaying itself, the FinanceForm object  296  obtains a pointer to a proposal object  110 , as shown by step  35 - 3  in  FIG. 35 . The FinanceForm object  296  then obtains a pointer from the proposal object  110  to a FinanceData object  146 , as shown by step  35 - 4  in  FIG. 35 . 
     The FinanceForm object  296  presents a user interface  102  to the user typically comprising text entry fields and predetermined questions for the user, as shown by step  35 - 5  in  FIG. 35 . This user interface  102  provides means for inputting individualized answers to the predetermined queries, the individualized answers relating to financing a product configuration that is of particular interest to the individual customer who is to receive the proposal. The predetermined questions allow the user to select one of a list of predetermined answers that correspond to the financing of a product configuration that is of particular interest to the customer who is to receive the proposal. The finance cost information gathered by the FinanceForm object  296  is then stored in the FinanceData object  146  which is attached to the current proposal object  110 , as shown by step  35 - 6  in  FIG. 35 . The user may wish to compare the finance cost of different finance plans. This comparison may be accomplished by repeating the process described above and in  FIG. 35  to create multiple FinanceData objects  146 . 
     The user may decide to generate a customized, printed proposal that includes one or more pages comprising the financing information. To include these finance pages, the user may select “Contents”  174  from the main menu  170  of the selection device  101 , as shown by step  18 - 1  of  FIG. 18 . In response, the selection device  101  preferably sends a load message to the TableOfContentsForm object  284 , as shown by step  18 - 2  of  FIG. 18 . On receipt of the load message, the TableOfContentsForm object  284  may display itself within the main window of the selection device  101 . Upon loading itself, the TableOfContentsForm object  284  obtains a pointer to the proposal object  110 , as shown by step  18 - 3  of  FIG. 18 . The TableOfContentsForm object  284  then obtains a pointer from the proposal object  110  to the TableOfContentsData object  130 , as shown by step  18 - 4  of  FIG. 18 . The user may then select the desired finance pages from a list of pages that are available for inclusion in the printed proposal, as shown by step  18 - 5  of  FIG. 8 . The selected pages may be stored as PageDescriptionRecord  314  in a TableOfContentsData object  130 , as shown by step  18 - 6  of  FIG. 18 . These PageDescriptionRecord  314  include a field that contains an identifier that indicates which page layout may be used to format each finance page. The page layout may determine the content and appearance of the final printed page. The page layout may be stored in the report database  106 . 
     To initiate the printing of the Finance pages, the user may select “Print”  178  from the main menu  170  of the selection device  101 , as shown by step  36 - 1  of  FIG. 36 . In response, the selection device  101  preferably sends a print request to the report generator  104 , as shown by step  36 - 2  of  FIG. 36 . The report generator  104  queries the active database  103  for successive page description records that describe the pages of the printed proposal, as shown by step  36 - 3  of  FIG. 36 . The active database  103  typically processes the request by searching the TableOfContentsData object  130  located in the current proposal. If the proposal is to include one or more pages comprising the financing information of a product configuration, the active database  103  may query the TableOfContentsData object  130  for the applicable PageDescriptionRecord  314 . The TableOfContentsData object  130  returns the relevant PageDescriptionRecord  314  to the active database  103 . The active database  103  then sends the relevant PageDescriptionRecord  314  to the report generator  104 , as shown by step  36 - 4  in  FIG. 36 . These PageDescriptionRecord  314  may include a field that contains an identifier that indicates which page layout may be used to format these particular finance pages. The report generator  104  queries the report database  106  for the applicable page layouts  120 , as shown by step  36 - 5  in  FIG. 36 . The report database  106  returns the relevant page layouts  120  to the report generator  104 , as shown by step  36 - 6  in  FIG. 36 . Each page layout preferably contains formatting specifications that indicate where specific finance information may appear on the printed page. The report generator  104  reads each format specification to determine the data required at that location on the page. 
     If the format specifications require data relating to the financing of a product configuration, the report generator  104  queries the active database  103 , as shown by step  36 - 7  in  FIG. 36 . The active database  103  queries the FinanceData object  146  locates and retrieves the applicable financing information from the FinanceData object  146 , and returns this financing information to the report generator  104 , as shown by step  36 - 8  in  FIG. 36 . If the format specifications require static pictures or text segments, then the report generator  104  preferably retrieves the applicable information from the static database  105  object, as shown by step  36 - 9  in  FIG. 36 . The static database  105  will typically return this information to the report generator  104 , as shown by step  36 - 10  in  FIG. 36 . The report generator  104  preferably repeats this process for each format specification on the page layout, which builds a finance page that is then sent to the printer, as shown by step  36 - 11  in  FIG. 36 . 
     In this fashion, the report generator  104  may print one or more customized and individualized finance pages, along with the predetermined text segments and pictures that correspond with the financing information related to a particular product configuration. 
     The finance page layouts  120  may specify that the name, address and telephone number or other identification data of the customer appear on the finance pages. The customer information may be initially entered via the CustomerForm object  286 . (See  FIG. 20 ). The customer information may be stored in the CustomerData object  136  attached to the proposal. 
     The report generator  104  reads format specifications from the page layout via the report database  106 , as shown by step  21 - 1  in  FIG. 21 . When the particular formatting specification in the page layout requires the customer&#39;s name, address, or telephone number or other identification data to be included on a printed page, the report generator  104  preferably sends a request to the active database  103  for the specified customer information, as shown by step  21 - 2  in  FIG. 21 . The active database  103  obtains the specified customer information from the CustomerData object  136  stored within the current proposal object  110 . The active database  103  then returns this information to the report generator  104 , as shown by step  21 - 3  in  FIG. 21 . The report generator  104  typically builds the page using this information and sends it to the printer, as shown by step  21 - 4  in  FIG. 21 . 
     The finance page layouts  120  may specify that the name, address and telephone number of the salesperson appear on the finance pages. The salesperson information may be initially entered by the employer in the ListOfSalesPersonsData object  158  and may be stored in the individual salesperson&#39;s SalesPersonData object  134  attached to the proposal. (See  FIG. 22 ). The report generator  104  reads format specifications from the page layout via the report database  106 , as shown by step  23 - 1  in  FIG. 23 . When the particular format specifiers require the salesperson&#39;s name, address and telephone number to be included on a page format, the report generator  104  preferably sends a request to the active database  103  for the specified salesperson information, as shown by step  23 - 2  in  FIG. 23 . The active database  103  obtains this salesperson information from the SalesPersonData object  134  in the proposal and returns this salesperson information to the report generator  104 , as shown by step  23 - 3  in  FIG. 23 . The report generator  104  typically builds the page using this salesperson information and sends the page to the printer, as shown by step  23 - 4  ion  FIG. 23 . 
     Proposal: Life Cycle Pages 
     When the user begins a deal with a customer, the user may want to include one or more individualized Economics pages  248  which comprise the life cycle cost information to be included in the customized, printed proposal that will be prepared for the customer. 
     The user interface  102  provides means for presenting a series of predetermined queries related to the life cycle cost of product configurations that are of interest to different potential customers who may purchase the product. The user interface  102  also provides means for inputting individualized answers to the predetermined queries, the individualized answers relating to the life cycle cost of product configurations that are of particular interest to the individual customer who is to receive the proposal. 
     The user may select “Customer Information”  176  from the main menu  170  of the selection device  101 , as shown by step  37 - 1  in  FIG. 37 . The user may further select “Economics”  212  from the “Customer Information”  176  menu. In response, the selection device  101  preferably sends a load message to the LifeCycleForm object  298 , as shown by step  37 - 2  in  FIG. 37 . On receipt of the load message, the LifeCycleForm object  298  may display itself in a window within the main window of the selection device  101 . 
     Upon loading itself, the LifeCycleForm object  298  obtains a pointer to a proposal object  110 , as shown by step  37 - 3  in  FIG. 37 . The LifeCycleForm object  298  then obtains a pointer from the proposal object  110  to a LifeCycleData object  148 , as shown by step  37 - 4  in  FIG. 37 . 
     The LifeCycleForm object  298  presents a user interface  102  to the user typically comprising text entry fields and predetermined questions for the user, as shown by step  37 - 5  in  FIG. 37 . This user interface  102  provides means for inputting individualized answers to the predetermined queries, the individualized answers relating to the life cycle cost of a product configuration that is of particular interest to the individual customer who is to receive the proposal. The predetermined questions allow the user to select one of a list of predetermined answers that correspond to the life cycle cost relating to a product configuration that is of particular interest to the customer who is to receive the proposal. The life cycle cost information gathered by the LifeCycleForm object  298  is then stored in the LifeCycleData object  148  which is attached to the current proposal object  110 , as shown by step  37 - 6  in  FIG. 37 . The user may wish to compare the life cycle costs of different product configurations. This comparison may be accomplished by repeating the process described above and in  FIG. 37  to create multiple LifeCycleData objects  148 . 
     The user may decide to generate a customized, printed proposal that includes one or more Economics pages  248  comprising the life cycle cost. To include these life cycle Economics pages  248 , the user may select “Contents”  174  from the main menu  170  of the selection device  101 , as shown by step  18 - 1  of  FIG. 18 . In response, the selection device  101  preferably sends a load message to the TableOfContentsForm object  284 , as shown by step  18 - 2  of  FIG. 18 . On receipt of the load message, the TableOfContentsForm object  284  may display itself within the main window of the selection device  101 . Upon loading itself, the TableOfContentsForm object  284  obtains a pointer to the proposal object  110 , as shown by step  18 - 3  of  FIG. 18 . The TableOfContentsForm object  284  then obtains a pointer from the proposal object  110  to the TableOfContentsData object  130 , as shown by step  18 - 4  of  FIG. 18 . The user then selects the desired life cycle pages, Economics  248 , from a list of pages that are available for inclusion in the printed proposal, as shown by step  18 - 5  of  FIG. 18 . The selected pages may be stored as PageDescriptionRecord  314  in a TableOfContentsData object  130 , as shown by step  18 - 6  of  FIG. 18 . These PageDescriptionRecord  314  typically include a field that contains an identifier that indicates which page layout may be used to format each Economics  248  page. The page layout may determine the content and appearance of the final printed page. The page layouts  120  may be stored in the report database  106 . 
     To initiate the printing of the life cycle economics pages  248 , the user may select “Print”  178  from the main menu  170  of the selection device  101 , as shown by step  38 - 1  of  FIG. 38 . In response, the selection device  1011  preferably sends a print request to the report generator  104 , as shown by step  38 - 2  of  FIG. 38 . The report generator  104  queries the active database  103  for successive page description records that describe the pages of the printed proposal, as shown by step  38 - 3  of  FIG. 38 . The active database  103  typically processes the request by searching the TableOfContentsData object  130  located in the current proposal. If the proposal is to include one or more pages comprising the life cycle cost of a product configuration, the active database  103  queries the TableOfContentsData object  130  for the applicable PageDescriptionRecord  314 . The TableOfContentsData object  130  returns the relevant PageDescriptionRecord  314  to the active database  103 . The active database  103  then sends the relevant PageDescriptionRecord  314  to the report generator  104 , as shown by step  38 - 4  in  FIG. 38 . These PageDescriptionRecord  314  may include a field that contains an identifier that indicates which page layouts  120  may be used to format these particular life cycle pages. The report generator  104  queries the report database  106  for the applicable page layouts  120 , as shown by step  38 - 5  in  FIG. 38 . The report database  106  returns the relevant page layouts  120  to the report generator  104 , as shown by step  38 - 6  in  FIG. 38 . 
     Each page layout preferably contains formatting specifications that indicate where specific life cycle information may appear on the printed page. The report generator  104  may read each format specification to determine the data required at that location on the page. 
     If the format specifications require data relating to the life cycle of a product configuration, the report generator  104  preferably queries the active database  103 , as shown by step  38 - 1  in  FIG. 38 . The active database  103  queries the LifeCycleData object  148  locates and retrieves the applicable life cycle information from the LifeCycleData object  148 , and returns this life cycle information to the report generator  104 , as shown by step  38 - 8  in  FIG. 38 . 
     If the format specifications require static pictures or text segments, then the report generator  104  preferably retrieves the applicable information from the static database  105  object, as shown by step  38 - 9  in  FIG. 38 . The static database  105  may return this information to the report generator  104 , as shown by step  38 - 10  in  FIG. 38 . The report generator  104  typically repeats this process for each format specification on the page layout, which builds a life cycle page that is then sent to the printer, as shown by step  38 - 11  in  FIG. 38 . 
     In this fashion, the report generator  104  may print one or more customized and individualized life cycle pages, along with the predetermined text segments and pictures that correspond with this specified life cycle cost of a product configuration. 
     The life cycle page layouts  120  may specify that the name, address and telephone number or other identification data of the customer appear on the life cycle pages. The customer information may be initially entered via the CustomerForm object  286 . (See  FIG. 20 ). The customer information may be stored in the CustomerData object  136  attached to the proposal. The report generator  104  reads format specifications from the page layouts  120  via the report database  106 , as shown by step  21 - 1  in  FIG. 21 . When the particular formatting specification in the page layout requires the customer&#39;s name, address, or telephone number or other identification data to be included on a printed page, the report generator  104  preferably sends a request to the active database  103  for the specified customer information, as shown by step  21 - 2  in  FIG. 21 . The active database  103  obtains the specified customer information from the CustomerData object  136  stored within the current proposal object  110 . The active database  103  then returns this information to the report generator  104 , as shown by step  21 - 3  in  FIG. 21 . The report generator  104  typically builds the page using this information and sends it to the printer, as shown by step  21 - 4  in  FIG. 21 . 
     The life cycle page layouts  120  may specify that the name, address and telephone number of the salesperson appear on the life cycle pages. The salesperson information may be initially entered by the employer in the ListOfSalesPersonsData object  158  and may be stored in the individual salesperson&#39;s SalesPersonData object  134  attached to the proposal. (See  FIG. 22 ). The report generator  104  reads format specifications from the page layout via the report database  106 , as shown by step  23 - 1  in  FIG. 23 . When the particular format specifiers require the salesperson&#39;s name, address and telephone number to be included on a page format, the report generator  104  preferably sends a request to the active database  103  for the specified salesperson information, as shown by step  23 - 2  in  FIG. 23 . The active database  103  obtains this salesperson information from the SalesPersonData object  134  in the proposal and returns this salesperson information to the report generator  104 , as shown by step  23 - 3  in  FIG. 23 . The report generator  104  typically builds the page using this salesperson information and sends the page to the printer, as shown by step  23 - 4  in  FIG. 23 . 
     Proposal: Table of Contents Page 
     When the user begins a deal with a customer, the user may want to include in the proposal a Table of Contents  252  page as part of the proposal. To include the Table of Contents  252  page, the user may select Contents  174  from the main menu  170  of the selection device  101 , as shown by step  18 - 1  of  FIG. 18 . In response, the selection device  101  preferably sends a load message to the TableOfContentsForm object  284 , as shown by step  18 - 2  of  FIG. 18 . On receipt of the load message, the TableOfContentsForm object  284  may display itself within the main window of the selection device  101 . Upon loading itself, the TableOfContentsForm object  284  obtains a pointer to the proposal object  110 , as shown by step  18 - 3  of  FIG. 18 . The TableOfContentsForm object  284  then obtains a pointer from the proposal object  110  to the TableOfContentsData object  139 , as shown by step  18 - 4  of  FIG. 18 . The user may then select the “Table of Contents” page from a list of pages that are available for inclusion in the printed proposal, as shown by step  18 - 5  of  FIG. 18 . The selected page may be stored as a PageDescriptionRecord  314  in a TableOfContentsData object  130 , as shown by step  18 - 6  of  FIG. 18 . In other words, the PageDescription record for the “Table Of Contents” page is stored in the TableOfContentsData object  130 , as it is one of the pages to be printed in the proposal. These PageDescriptionRecord  314  typically include a field that contains an identifier that indicates which page layout may be used to format each price quotation page. The page layout may determine the content and appearance of the final printed page. The page layout may be stored in the report database  106 . 
     To initiate the printing of the Table of Contents  252  page, the user may select “Print”  178  from the main menu  170  of the selection device  101 , as shown by step  39 - 1  of  FIG. 39 . In response, the selection device  101  preferably sends a print request to the report generator  104 , as shown by step  39 - 2  of  FIG. 39 . The report generator  104  queries the active database  103  for successive page description records that describe the pages of the printed proposal, as shown by step  39 - 3  of  FIG. 39 . The active database  103  processes the request by searching the TableOfContentsData object  130  located in the current proposal. If the proposal is to include a Table of Contents  252  page, the active database  103  queries the TableOfContentsData object  130  for the applicable PageDescriptionRecord  314 . The TableOfContentsData object  130  returns the relevant PageDescriptionRecord  314  to the active database  103 . The active database  103  then sends the relevant PageDescriptionRecord  314  to the report generator  104 , as shown by step  39 - 4  in  FIG. 39 . These PageDescriptionRecord  314  may include a field that contains an identifier that indicates which page layout may be used to format the Table of Contents  252  page. The report generator  104  queries the report database  106  for the applicable page layouts  120 , as shown by step  39 - 5  in  FIG. 39 . The report database  106  returns the relevant page layouts  120  to the report generator  104 , as shown by step  39 - 6  in  FIG. 39 . 
     Each page layout preferably contains formatting specifications that indicate where specific Table of Contents  252  information may appear on the printed page. The report generator  104  reads each format specification to determine the data required at that location on the page. If the format specifications require data relating to the Table of Contents  196  of the proposal, the report generator  104  queries the active database  103  for the Table of Contents  196  information, as shown by step  39 - 7  in  FIG. 39 . The active database  103  preferably retrieves the Table of Contents  196  information from the TableOfContentsData object  130  and return this information to the report generator  104 , as shown by step  39 - 8  in  FIG. 39 . 
     If the format specifications require static pictures or text segments, then the report generator  104  preferably retrieves the applicable information from the static database  105  object, as shown by step  39 - 9  in  FIG. 39 . The static database  105  may return this information to the report generator  104 , as shown by step  39 - 10  in  FIG. 39 . The report generator  104  typically repeats this process for each format specification on the page layout  120 , which builds a Table of Contents  252  page that is then sent to the printer, as shown by step  39 - 11  in  FIG. 39 . In this fashion, the report generator  104  may print one or more customized and individualized Table of Contents  252  pages. 
     The Table of Content  252  page layouts  120  may specify that the name, address and telephone number or other identification data of the customer appear on the Table of Contents  252  pages. The customer information may be initially entered via the CustomerForm object  286 . (See  FIG. 20 ). The customer information may be stored in the CustomerData object  136  attached to the proposal. 
     The report generator  104  reads format specifications from the page layout  120  via the report database  106 , as shown by step  21 - 1  in  FIG. 21 . When the particular formatting specification in the page layout  120  requires the customer&#39;s name, address, or telephone number or other identification data to be included on a printed page, the report generator  104  preferably sends a request to the active database  103  for the specified customer information, as shown by step  21 - 2  in  FIG. 21 . The active database  103  obtains the specified customer information from the CustomerData object  136  stored within the current proposal object  110 . The active database  103  then returns this information to the report generator  104 , as shown by step  21 - 3  in  FIG. 21 . The report generator  104  typically builds the page using this information and sends it to the printer, as shown by step  21 - 4  in  FIG. 21 . 
     The Table of Contents  252  page layouts may specify that the name, address and telephone number of the salesperson appear on the Table of Contents  252  pages. The salesperson information may be initially entered by the employer in the ListOfSalesPersonsData object J 58  and stored in the individual salesperson&#39;s SalesPersonData object  134  attached to the proposal. (See  FIG. 22 ). The report generator  104  reads format specifications from the Table of Contents  252  page layout  120  via the report database  106 , as shown by step  23 - 1  in  FIG. 23 . When the particular format specifiers require the salesperson&#39;s name, address and telephone number to be included on a page format, the report generator  104  preferably sends a request to the active database  103  for the specified salesperson information, as shown by step  23 - 2  in  FIG. 23 . The active database  103  obtains this salesperson information from the SalesPersonData object  134  in the proposal and returns this salesperson information to the report generator  104 , as shown by step  23 - 3  in  FIG. 23 . The report generator  104  typically builds the page using this salesperson information and sends the page to the printer, as shown by step  23 - 4  in  FIG. 23 . 
     Proposal: Trademark 
     The system may also print a trademark identifying the product on at least one of the pages of the customized printed proposal. If a trademark is to appear on a page, the page layout  120  for that page will preferably contain a format specification that specifies the trademark and its location on the page. The report generator  104  queries the report database  106  for each page layout  120 , as shown by step  40 - 1  in  FIG. 40 . 
     The report database  106  returns each page layout  120 , as shown by step  40 - 2  in  FIG. 40 . If the page layout  120  contains a format specification requiring a trademark picture, then the report generator  104  may retrieve the trademark picture from the static database  105  object, as shown by step  40 - 3  in  FIG. 40 . The static database  105  may return this picture to the report generator  104 , as shown by step  40 - 4  in  FIG. 40 . The report generator  104  may include the trademark picture when it builds the page to be printed. The report generator  104  typically builds the page using this information and sends it to the printer, as shown by step  40 - 5  in  FIG. 40 . 
     Proposal: Printing Language 
     The user interface  102  provides means for presenting a series of predetermined queries related to the language in which the user interface  102  should be presented. In addition, the user interface  102  provides means for presenting a series of predetermined queries related to the language in which the proposal should be printed. The user interface  102  is also a means for inputting individualized answers to the predetermined queries, the individualized answers relating to the language of choice for the user interface  102  presentation and for the printed proposal. 
     The user may select customized menu selection  177  from the main menu  170  of the selection device  101 , as shown by step  41 - 1  in  FIG. 41 . The user may further select “International” from the customized menu selection  177 . In response, the selection device  101  preferably sends a load message to the LanguageForm object  304 , as shown by step  41 - 2  in FIG.  41 . On receipt of the load message, the LanguageForm object  304  may display itself in a window within the main window of the selection device  101 . 
     Upon loading itself, the LanguageForm object  304  obtains a pointer to a customized database  114 , as shown by step  41 - 3  in  FIG. 41 . The LanguageForm object  304  then obtains a pointer from the customized database  114  to a LanguageData object  160 , as shown by step  41 - 4  in  FIG. 41 . 
     The LanguageForm object  304  presents a user interface  102  to the user typically comprising text entry fields and predetermined questions for the user, as shown by step  41 - 5  in  FIG. 41 . This user interface  102  provides means for inputting individualized answers to the predetermined queries, the individualized answers relating to the language for presenting the user interface  102  and the language for printing the proposal. The language information gathered by the LanguageForm object  304  may then be stored in the LanguageData object  160  which is attached to the customized database  114 , as shown by step  41 - 6  in  FIG. 41 . 
     The user interface  102  max further comprise means for displaying forms in anyone of a plurality of languages. Upon receiving a load message, a form may query the LanguageData object  160  in the customized database  114  in the active database  103  to determine the language in which it should display itself. The form may then display itself in the specified language. 
     The system may also generate the printed proposal in anyone of a plurality of languages. Upon receiving a print message, the report generator  104  may query the LanguageData object  160  in the customized database  114  in the active database  103  to determine the language in which it should print the proposal. The report generator  104  will then preferably query the static database  105  for pictures and text that are in the appropriate language. The report generator  104  typically builds each page using pictures and text in the specified language and sends it to the printer. 
     Proposal: Signature Page 
     The user may decide to generate a customized, printed proposal that includes a Signature page as part of the proposal. To include this Signature page, the user may select “Contents”  174  from the main menu  170  of the selection device  101 , as shown by step  18 - 1  of  FIG. 18 . In response, the selection device  101  preferably sends a load message to the TableOfContentsForm object  284 , as shown by step  18 - 2  of  FIG. 18 . On receipt of the load message, the TableOfContentsForm object  284  may display itself within the main window of the selection device  101 . Upon loading itself, the TableOfContentsForm object  284  obtains a pointer to the proposal object  110 , as shown by step  18 - 3  of  FIG. 18 . The TableOfContentsForm object  284  then obtains a pointer from the proposal object  110  to the TableOfContentsData object  130 , as shown by step  18 - 4  of  FIG. 18 . The user may then select the desired Signature page from a list of pages that are available for inclusion in the printed proposal, as shown by step  18 - 5  of  FIG. 18 . The selected page may be stored as a PageDescription record in TableOfContentsData object  130 , as shown by step  18 - 6  of  FIG. 18 . This PageDescription record preferably includes a field that contains an identifier that indicates which page layout  120  may be used to format the Signature page. The page layout  120  may determine the content and appearance of the final printed page. The page layouts  120  may be stored in the StaticData object, accessible through the report database  106 . 
     To initiate the printing of the Signature page, the user may select “Print”  178  from the main menu  170  of the selection device  1001 , as shown by step  42 - 1  of  FIG. 42 . In response, the selection device  101  preferably sends a print request to the report generator  104 , as shown by step  42 - 2  of  FIG. 42 . The report generator  104  queries the active database  103  for successive page description records that describe the pages of the printed proposal, as shown by step  42 - 3  of  FIG. 42 . The active database  103  processes the request by searching the TableOfContentsData object  130  located in the current proposal. 
     If the proposal is to include a Signature page, the active database  103  queries the TableOfContentsData object  130  for the applicable PageDescription record. The TableOfContentsData object  130  returns the relevant PageDescription record to the active database  103 . The active database  103  then sends the relevant PageDescription record to the report generator  104 , as shown by step  42 - 4  in  FIG. 42 . 
     This PageDescription record may include a field that contains an identifier that indicates which page layout  120  may be used to format this particular Signature page. The report generator  104  queries the report database  106  for the applicable page layout  120 , as shown by step  42 - 5  in  FIG. 42 . The report database  106  returns the relevant page layout  120  to the report generator  104 , as shown by step  42 - 6  in  FIG. 42 . The page layout  120  preferably contains formatting specifications that indicate where specific information may appear on the printed page. The report generator  104  reads each format specification to determine the data required at that location on the page. The report generator  104  typically repeats this process for each format specification in the page layout  120 . 
     The Signature page layout  120  may specify that the customer&#39;s name, address, telephone number or other identification data is to appear on the Signature page. If the format specification in the page layout  120  requires the customer&#39;s name, address, telephone number or other identification data, the report generator  104  sends a request to the active database  103  for the specified customer information, as shown by step  42 - 7  in  FIG. 42 . The active database  103  obtains the specified customer information from the CustomerData object  136  stored within the current proposal object  110 . The active database  103  then returns this information to the report generator  104 , as shown by step  42 - 8  in  FIG. 42 . 
     The Signature page layout  120  may specify that the name, address and telephone number or other identification data of the salesperson is to appear on the Signature page. If the format specification specifies the salesperson&#39;s name, address and telephone number, or other identification data, the report generator  104  sends a request to the active database  103  for the specified salesperson information, as shown by step  42 - 9  in  FIG. 42 . The active database  103  obtains this salesperson information from the SalesPersonData object  134  in the proposal and returns this salesperson information to the report generator  104 , as shown by step  42 - 10  in  FIG. 42 . 
     If the format specifications require static pictures or text segments, then the report generator  104  preferably requests the applicable information from the static database  105 , as shown by step  42 - 11  in  FIG. 42 . The static database  105  returns the requested information to the report generator  104 , as shown in step  42 - 12  in  FIG. 42 . The report generator  104  repeats this process for each format specification on the page layout  120 , which builds a signature page that is then sent to the printer, as shown by step  42 - 13  in  FIG. 42 . 
     In this fashion, the report generator  104  may print a customized and individualized signature page, along with any predetermined text segments and pictures that may relate to the product configuration that is of particular interest to the customer who is to receive the proposal. 
     While the present invention has been described in connection with the preferred embodiment thereof, it will be understood that many modifications will be readily apparent to those skilled in the art, and this application is intended to cover any adaptations or variations thereof. It is manifestly intended that this invention be limited only by the claims and equivalents thereof.