Electronic proposal preparation system for selling computer equipment and copy machines5625776Abstract An electronic system for creating customized product proposals stores a plurality of pictures and text segments to be used as building blocks in creating the proposal. The pictures may include various products, environments in which the products may be used, and available product options. The text segments may include textual descriptions of the product, environments in which the product may be used, and its performance specifications. The system queries a user to determine a customer's needs and interests. Based upon the answers to the queries, the system selects the appropriate picture and text building blocks to fill in proposal templates. The system can print the completed proposal templates to provide the user with a customized, printed proposal that describes features and benefits of a product, in a particular environment, that are of interest to the customer who is to receive the proposal. Claims What is claimed is: Description FIELD OF THE INVENTION
TABLE 1
______________________________________
Type of Form
Information Object Class Class
______________________________________
trade-in product
TradeForm Object 292
361 340
product price
QuotationForm object 294
362 340
quotation
financing a product
FinanceForm object 296
364 340
product life cycle
LifeCycleForm object 298
366 340
cost
personalized letter
LetterForm object 288
358 340
product ProductForm object 290
360 340
customer CustomerForm object 286
356 340
table of contents
TableOfContentsForm
354 340
object 284
salesperson ListOfSalesPersonsForm
352 340
object 310
to save a proposal
SaveProposalForm 350 340
object 308
to recall a stored
RecallProposalForm
348 340
proposal object 306
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
QuotationData object 144
382 320
quotation
financing a product
FinanceData object 146
384 320
product life cycle
LifeCycleData object 148
386 320
cost
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
368 320
object 130
salesperson SalesPersonData 370 320
object 134
______________________________________
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
Information
Data Object Data Class Class
______________________________________
dealer DealerData object 156
390 330
salesperson
ListOfSalesPersonsData
392 330
object 158
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 & 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'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'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 any one 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 130, 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 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 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 101, as shown by step 20-1 in FIG. 20. In response, the selection device 101 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 a 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'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'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 ba 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'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 database, only the employer'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'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'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 164 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'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'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'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 131 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 275 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 formal 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'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'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'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 fox 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 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 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'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 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'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'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 240, 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 240. 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 database 106, as shown by step 21-1 in FIG. 21. When the particular formatting specification in the page layout 120 requires the customer'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 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'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'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 produc | ||||||