The system will be under the authority of the distribution manager whose task will include the coordination of the entire delivery system. Operators, working under the manager, can be easily trained to efficiently and effectively use the system. The system will make seemingly routine tasks easier by methodically organizing the all important aspects, from adding a new customer to printing summary reports. Once in place, the amount of time needed to perform tasks and update the data base in the delivery system will be reduced, requiring only a few mouse clicks and key strokes to accomplish most tasks.
The system consists of six main sections. They are described briefly here to provide an overview as to their function. A more detailed description can be found in the latter pages of this document. There are six main sections:
Since no hardware platform was specified in the informal specifications, we recommend, following current industry trends, that each system be run on an IBM compatible workstation. The system will require a minimum of a Pentium microprocessor, 100MHz or higher, 16MB of RAM, 17" SVGA color monitor, a minimum of 200MB of free disk space and access to two printers, a line printer to cheaply print route information for the carriers and a high speed laser printer for quality summary reports. Further we strongly recommend the use of a secondary backup medium such as a tape drive or read/write optical disk to ensure maximum information safety. As Graphical User Interface environments are becoming more popular, we will be designing the system to function with Microsoft Windows 3.1 (or greater) operating system.
Our goal is to develop a system that will function efficiently while maintaining simplicity. Our interface will be very simple, to address all user skill levels from beginner to expert.
Documentation will be thorough and complete. Training of the users will be made available by the developers of the system to ensure a complete understanding of its operations. It is expected that the system will greatly simplify the publication delivery service by reducing the overall amount of time required for setup and maintenance, as well as facilitate the day-to-day operations of the business.
Adding a customer
The data mentioned above will be entered into fields on the computer screen. If any data fields are left blank, except the notes information, (there will be a not applicable default for the notes field), or the incorrect format of information is entered, the system will prompt the user to enter data for all fields or correctly reenter the data in the proper format. The user will not be allowed to continue until all record fields are complete. An example of the transaction “adding a customer,” and the format for the data to be entered is shown below.
1) the user selects the add a customer function 2) enter the customer name E.g., Doe, John (last name, first name) 3) enter the customer’s address E.g., 123, Main Street (street name) Calgary, AB (city, province) T5W 3K3 (Canadian postal code) 4) enter the user phone number E.g., (403) 555-1234 ((area code) phone number with dash) 5) select the users publications from a list of publications offered by the company 6) fill in special data for notes E.g., be sure to put paper in mail box not on the step 7) enter the status of delivery E.g., suspended indefinitely, suspended for a specific time period, or regular deliveryNOTE: If any mistakes are made in entering the data they can be corrected using the modify function described below.
Deleting a customer
A user selecting this function would enter a unique customer reference number, or the customers name. The system would search for this customer in the data base, and the customers information would be displayed to the screen. The user could now choose to remove the customer information from the database at this time, or exit from this function and do nothing.
We require clarification about what will become of information with regards to customers owing money to the company. Would this information be printed out to be acted upon and the customer deleted from the system? Or would this information be flagged showing money owing until all accounts were settled?
NOTE: The unique customer key data for searches has not been determined. It has been assumed that a customer number would be given to each subscriber to make the search key unique.
Modifications to customer information
In this function the user enters a customer’s key, after which the system would search for the customer record and display it to the screen. At this point all data fields could be accessed by tabbing to them, and re-entering the correct, or new customer information via the keyboard. This data would then be saved in the data base.
NOTE: Specific security measures were not mentioned so it has been assumed that all fields of a customer record can be changed at any time by any person with access to the system.
Suspend Delivery to a customer
If a customer does not require delivery for a period of time, they could contact the delivery service and request a suspension of delivery. The user would search for the customer in the database by the customers unique key and the data field for status would be set for delivery suspension. It is assumed that delivery charges are suspended at this time, and the account charges, or credits will carry over to when the suspension is discontinued.
The suspension would be ended by entering data as above except the status data field would be set for delivery continuation and charges/credits would be reinstated.
Query of customer records
A search on the name, the customer number, or the postal code field of a customer record will bring up and display customer information, including the route the customer is on, as well as all the subscriptions to be received on the current day.
1) Name 2) Publisher 3) Supplier Name 4) Supplier Phone Number 5) Subscription Rate 6) Type of Publication (i.e., Newspaper/Magazine) 7) Frequency of Delivery (i.e., Daily/Weekly/Monthly) 8) General Description of the Publication 9) Total Number of Subscribers is set to zero
NOTE: Any mistakes that are not corrected here can be addressed by the modify function described below.
Delete publication
The user has to enter the name of a publication that is to be deleted. The system returns an error if the publication does not exist. Otherwise, it responds by displaying all information of the publication. The user confirms the delete action. All subscribers of the publication should be notified and their accounts should be updated.
Modify publication information
Any information of a publication can be changed. The user enters the name of the publication. The system returns an error if the publication does not exist. Otherwise, it responds by displaying all information of the publication. The user then can make modification in the appropriate field(s). When adjustment is made in price, the new price only applies to new subscribers, it does not affect existing subscriptions.
Query
All information of a publication can be listed on the screen by entering the publication name. The system returns an error if the publication does not exist. Information displayed here is for view only and it cannot be modified.
Adding a carrier
The user selects the function, and enters the data via the keyboard as shown in the script below (similar to the add household described above).
1) the user selects the add a carrier function 2) enters the carrier’s name E.g., Doe, John 3) enters the carrier’s address E.g., 456 Center Street (street) Calgary, AB (city, province) T8W 4E5 (Canadian postal code) 4) enters the carrier’s phone number. E.g., (403) 555-1234 5) enters the routes the carrier delivers to E.g., R1 R4 R6 (route #1 route #2 route #3)
NOTE: If any mistakes are made in entering the data they can be corrected using the modify function described below.
Deleting a carrier
In this function the user enters the carrier’s name and performs a search to display it to the screen. The user will then print the carrier routes for reassignment to other or new carriers, their routes are deleted, and finally the carrier can be removed from the data base.
NOTE: If routes are still assigned to the carrier then the carrier cannot be removed until their routes have been printed out.
Modifications to carrier information
In this function the user carriers name. After which the system would search for the carrier record and display it to the screen. At this point all data fields could be accessed by tabbing to them, and reentering the correct, or new carrier information via the keyboard. This data would then be saved in the data base.
Delete route
A route can only be removed if there is no household in that route, i.e., the number of households is zero.
Display route information
When a valid route name is entered, the user has the option of viewing either all household belonging to the route or the total number of deliveries for each product on the current day. An error message will be displayed if the route name is invalid.
Generate Printout
A printout which contains route name, carrier name, carrier address, carrier phone number, route household addresses and status, and the publication(s) received by each household is generated and given to the carrier before he or she makes the deliveries. The user can print either a single route or the entire set of routes.
If the user selects generate bills the system prints off a bill for each household which has an outstanding balance and returns the user to the main screen. Each bill is formatted in the following way:
If the user selects an individual household, they will be asked for a household's identifier, the phone number or name of the household or subscriber. If the system is unable to find a household matching the identifier, it will return a message stating the problem, and ask for the identifier to be re-entered. Once a household is matched, the user will be able to view and modify the household's billing information (i.e., update their record of outstanding balance for a payment received). They can then print this household's bill out if they choose.
1) A list of total balance outstanding and number of subscribers, listed by publication, with grand totals at the bottom 2) A daily report for each publication, with the number of subscription sales and their value, listed by route, with totals at the bottom 3) A daily report with the number of subscription sales and their value, listed by publication, with totals at the bottom
Households
* Unique Customer Number (recommended addition) - 7 digits * Name (surname, first name) - 20 Characters last name, 15 characters first name * Address (street, house number, apartment number and postal code) - 15 characters street, 7 characters house number, 6 digits postal code * Phone number - 10 character phone number (XXX) XXX-XXXX * Status - Whether the household is suspended or not - suspension for an extended period, for a specific time period, or delivery as usual check boxes, with a field that is activated if the specific time period is to be entered with the form (DD/MM to DD/MM) * What newspapers or magazines the household is currently subscribed to - Name of magazine to a maximum of 5 entries, selected from a menu or check boxes * Present credit on the household account. A negative balance will imply a prepayment on the account, while a positive balance implies an amount owed - Account balance - $XXXX.XX approx. 8 characters to a maximum value of $9999.99 * A notes section to help the delivery people be aware of any special instructions indicated by the household. - special notes 'n' rows of 30 characters apiece * A route name to identify which route the household is related to. This should be automatically related to the household based on their postal code and the predefined routes already entered into the system - unique route number approx. 5-15 characters
* Name, Publisher, Supplier Name, Supplier Phone Number - 30 characters name, 30 characters publisher, 30 characters supplier name, 10 digits phone number * Price Scheme - Price per issue/Weekly/Monthly deals (e.g. 2 year subscription for 50% off, etc.) - $xxx.xx per issue/x issues * Type - magazine or newspaper - one char for magazine or newspaper * Frequency of Delivery - ?? * General Description - A brief summary of the publication, originally entered by the user - special notes 'n' rows of 30 characters apiece * Total Number of people that are subscribed to the publication, calculated automatically. - XXXXXXX number of people subscribed (9999999 maximum)
* Name (Surname, first name) - 20 Characters last name, 15 characters first name * Address (Street, House Number, Apartment number and Postal Code) - 15 characters street, 7 characters house number,6 digits postal code * Phone number - 10 character phone number (XXX) XXX-XXXX * Routes they deliver to - unique route identifier X 'n' rows
* Name - name of route, 20 characters * A list of postal codes that are in the route - 'xxx-xxx' X 'n' postal codes in route * How many households are in the route - XXXX number of households in route * Which carrier is assigned to this route unique carrier name
* All household information and our company letterhead should be produced at the top of the bill * Name (surname, first name) - 20 Characters last name 15 characters first name * Address (street, house number, apartment number and postal code) - 15 characters street, 7 characters house number, 6 digits postal code * Phone number - 10 character phone number (XXX) XXX-XXXX * All of the households subscriptions should be on the same bill, with a bottom line total of the amount owed - Name of magazine/paper, 20 characters, to a maximum or 5 entries - with expiration date of subscription - Day/month/year e.g. 00/00/00 - Account owed - $XXXX.XX approx. 8 characters, to a maximum value of $9999.99 - late charges if applicable $XXX.XX * Any late charges and expiration date for each subscription should be listed as well * All of the transactions since the last time a bill was printed for this household should be listed (e.g. payments received, new subscriptions, etc.) - previous balance - $XXXX.XX - list of transactions - date (00/00/00) type of transaction amount - new balance $XXXX.XX
* A summary sheet should be produced on request with total money owed and total number of subscribers by publication: - Publication Name - # of subscribers - Total money owed $XXXXXXX.XX maximum $9999999.99 * Ability to generate daily summary information showing how many copies of each publication were sold that day. The number of copies sold and the total monetary value should be included.
Add - will permit the addition of any new "entity" such as a customer or a publication - corresponds only to the desired fields pertaining to that section Delete - will permit the deletion of any existing "entity" such as a customer or a publication - corresponds only to the desired fields pertaining to a section Modify - will permit the modification of any existing "entity" such as a customer or a publication - corresponds only to the desired fields pertaining to a section Query - will perform a query corresponding to the search keys provided by the user - queries will differ by section, as per described in the functional specifications
Households will be linked to carriers through routes, which will list items such as the name of the route and the number of households on that route. Through the routes, the system will allow the user to view the total number of deliveries per day to each individual route, as well as show all the households on a route. It will also be able to make print-outs per route or for an entire set of routes.
Billing households will also be a part of the Publication Home Delivery System. It will list all the subscriptions, with totals and late charges and any transactions since the last bill was printed. Any household's bill can be generated at request. When payments are received, it will update the outstanding balance of a customer. A summary sheet will also be available that will list the total money owed and the total number of subscriptions. Daily reports will also be available that will show the number of copies of each publication sold and their total monetary value.
There are many different implementation options for a database system of this nature. In this case, the type of implementation is assumed to be synonymous with the computer architecture required to run the system, and the software used to create the database. Firstly, we must know whether the current hardware possessed is satisfactory to run a database system of this size, or are upgrades required or already planned for. If this is the case, how much money is available for upgrades. Secondly, what level of user knowledge should be required to use the database efficiently. For example, is the system meant for a computer novice or an expert. Once this is known, a better assessment can be made of possible implementations. Regardless, here are a couple of suggestions.
Our favored choice is an IBM compatible personal computer with the following minimum requirements: 486DX processor, 16 megabytes of memory, an SVGA monitor, 200 megabytes of free hard drive space, a tape drive for backup, a line printer, and a commercial quality laser printer. It also must have at least MS-DOS 6.0 and Microsoft Windows 3.1 installed. The database program will be programmed using Microsoft Access or a similar language such as Oracle. This options seems to make the most sense since many organizations already posses some or all of this hardware and have other uses for it such as running modern word processors, spreadsheets, etc. In addition, upgrades could be made relatively cheap and quickly.
If such hardware is not possessed nor is it wanted, a package might be able to be designed for a different system. This would require much more time though, and therefore would come at a greater cost. In this case, the specific software used would be dependent of the type of computers. If an older IBM compatible is the target, something such as Lotus 1-2-3 may be practical. If the machines are UNIX compatible with a graphical operating system (i.e.. X-Windows) something such as SYBASE and TCL could be used, again at greater cost. The user's knowledge of computers becomes relevant in this case, since the result of the later options would most likely require a greater level of comprehension of databases.
We would like to point out that a few assumptions have been made with regard to some missing information. Our assumptions are based on suggestions that would make the programming easier, in the case of missing fields, to making the system conform to current industry, such as the recommendation of the hardware and software platforms. As not all the assumptions are flagged, please be sure to review the functional specifications thoroughly and decide if our proposed system meets or even exceeds your requirements.
Interface : Sean O'Rourke, Ian Mayhood, Henry Wong, Mike Ksenak Documentation : Blair Whitford, Janice Webster, Guy Gravel Programming : Dave Neufeld, Steve Thompson, Andy Lum, Michael Boonstra (4GL) Presentations : Blair Whitford, Dave Neufeld, Janice Webster
To manage and coordinate the different needs of the teams a Product Manager was appointed and in order for there to be enough communication throughout the teams, a representative from each team was chosen. Meeting would be held with the team representatives and the product manager in order to make certain that: everyone is keeping up to the schedule, there are no misunderstanding ambiguities with the project, and to make sure that any concerns and problems conceding the entire project are dealt with and solved. The selections for these positions is as follows:
Product Manager : Mike Boonstra Interface : Ian Mayhood Documentation : Blair Whitford Programming : Steve Thompson
Everyone of the team members will be involved with some aspect of the testing. Which aspect they will be involved in will be determined by the individuals strengths but not necessarily by which sub-team they are in.
There are also more specific functions. A user will be able to suspend a customers account for a specific time period or indefinitely. There will also be a function that will create a print out of the days deliveries as was specified previously.
Due to perceived time constraints this proposed system will not contain a billing system. After much discussion it was determined that the billing system was too complex to be created as scheduled. An enhancement that may be added in the future is to add a partial billing system. This would not include anything as specific as a list of payments for a particular invoice, but more likely would include enough functionality for it to work along side a separated billing system. Some the functions covered in this system would include summary showing total Money owed and total number of subscribers by publication, daily summary information showing how many copies of each publication were sold that day, ability to generate bills for households, and ability to update balances when a payment for an invoice is received.
We believe good programming techniques, and meticulous attention to data base manipulation will make our system both efficient, and reliable so everyone can meet their goals, and get their jobs done.
Back to the Title Page.
Back to the INFO SYSTEMS Inc. Homepage.
Page maintained by Ian Mayhood - Last Updated: January 25, 1996