The Browse/Form Scenario

The Browse/Form Scenario

Previous Top Next

Our applications use a methodology called "The Browse/Form Scenario" as a way of "standardizing" the data within and between the system's database files. It is important for the users of the applications to have a basic understanding of this methodology.

Using this method is necessary so that:

The application can easily find the correct data to "automate" business practices.

Read the data files reliably and produce meaningful management reports.

Relate the various files to each other where necessary with "lookups from related files". e.g. inventory lookups from Sales Forms, category lookups for inventory records from a standard list of categories, etc... Why?? Because inventory items are what gets sold and Sales Forms are used to "sell" them and inventory Item and Sales Form Item reports need to be made "by Category" is a good example.

Enter "standard flags or markers" in various database files to indicate something special about a particular record so meaningful lookups, browse lists and management reports are possible.

AN EXAMPLE OF THE BROWSE-FORM SCENARIO

Following is an example of how the Browse/Form Scenario works using the screens for the browse lists and the "related" browse lists and forms for making a Sales Form from the KwikSALES(tm) application.

After choosing which operation to do (making an Sales Form) from the Main Menu or clicking on the

icon the Sales Form Management Screen appears:

There are 3 browse lists embeded in this form:

Customer selection and management browse (a scrolling list at the top).

Sales Form selection and management browse list in the middle which also lists the Sales Forms depending on the tab selected for the selected Customer in the top browse. These Sales Forms can be viewed in the browse list according to the various "status" of the Sales Forms by selecting the appropriate tab in the browse list.

Line Item list at the bottom for the selected Sales Form in the Sales Form browse.

These browse lists are "related" in the system therefore the application database record making functions must be kept standardized with:

Flag fields in various records. e.g. Category, Item Number, etc...

Key Files for reports and lookups for flag fields.

Index Files for reports and lookups for flag fields.

Other Browse Lists for Queries and Viewing.

Various procedures for managing the database files themselves.

If the foregoing is confusing at first, don't worry about it. The application has been designed in such a way as to guide the user in exactly what to do and will generally "guide" the user in "doing it right".

Many browse list screens throughout this application have

buttons for:

Inserting or Adding another record to the file in the browse list.

Changing or Editing the highlighted record in the browse list.

Deleting the highlighted record in the browse.

An example of a complex form is the Sales Form window shown below.

This is actually a "form" with an embeded "scrolling browse list" for line items and it is the "heart" of the Sales Management portion of the system.

There are some "special lookup" or "select" buttons

in the top (header) portion of this Sales Form Screen. It is important in a system such as this to fill in the necessary fields by looking up the required field data from a "control file" using a releated browse list. e.g. this form needs specific data from a related "standardizing" control file so the system will know how to handle this Sales Form Record at some later time. The most common use is for printing reports.

We will use the Sold By field as an example. When the user presses the

button next to the Sold By field and you get the following Employee Selection Table:

from which you can

items "selected (highlighted)" from within the browse (scrolling list).

If a needed employee is not in the list the user can select

and the Adding an Employee Record Form will appear:

The user can enter the new employee into the form and press the

button and be returned back to the "previous" Employee Selection Table screen with the new record in it ready to select with the

button:

After the user has pressed the

button for the newly entered employee they will be returned back to the "previous" Sales Form Screen:

and the newly entered and "Selected" Employee code field in the Sales Form has been entered in an "organized" fashion.

All of the various "Buttons" on the Sales Form Screen are to perform the necessary functions to a Sales Form to accomodate the businesses sales and recordkeeping needs as well and the application standardization needs.

Another unique control file function worth mentioning is the

button. This function allows management to make various "standard" comments in a comment control file. These standard comments can then be appended (stuffed into the comments text box one after another) by pressing on this button and selecting a comment "segment" to use from the following browse/table/list:

Note that the operator can

items "selected (highlighted)" from within the "Message Selection Table" browse (scrolling list) or if the desired "standard" message is not in the list yet go ahead and insert a new one.

Since this Comments Text Box is part of the Sales Form Header and is also in the Sales Form Window, the user can also type in (or modify) comment text directly inside the text box if a unique comment is needed just for this one Sales Form. So standard and unique messages can be appended/modified to each other in any "mix-and-match fashion using this text box.

The Control File Overview section in the Introduction Chapter shows how to do a "single depth" browse/form operation for most of the control files.

Xplore For Browse Lists

[[[ENDKEEPN]]]