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) select a route from pop-up list and systems suggested route
8) enter the status of delivery
E.g., suspended indefinitely, suspended for a specific time period, or regular delivery
NOTE: 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 the Query of Customer Records interface described below.{edit out}
The system would return the data from the 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? When a customer has a balance other than zero, a warning should be issued and confirmation asked for. The confirmation proccess should offer the option of removing the customer information, remove the customer information and print an invoice or to exit. Once a customer is removed, the route and products data-bases should be updated.
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. The unique search key should be the last two digits of the year they joined-up followed by the first two letters of thier route name, followed by a 3 digit number that is unique within the route. A change in the route of a customer should trigger a change in their reference number.
Modifications to customer information
In this function the user uses the Query on Customer Records interface as described below, 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 are not required {snip} 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 standard query on customer records {snip}and the data field for status would be set for delivery suspension or the data field would be set for delivery suspension and the data field for the date of delivery continuation filled in (This could be replaced with a time interval for which delivery is to be suspended, instead of entering a date). 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
The user starts a query using route number, route name, customer name, phone number, postal code, address or reference number. The query finds any unique match or gives the user a list of multiple matches to select form. The list will be formatted to have one customer per line, and any data on a customer not displayed will be accesible via a button click. Once a single customer is selected, all their information is displayed on screen.{edit}
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 10)Key words(ie. Automotive, trucks, tractor-pull)
NOTE: Any mistakes that are not corrected here can be addressed by the modify function described below.
Delete publication
The user has to select from a list or enter the name of a publication that is to be deleted.{snip} Otherwise, it responds by displaying all information of the publication. The user confirms the delete action. All subscribers of the publication should be notified, but this is not required by the system, however their accounts should be updated.
Modify publication information
Any information of a publication can be changed. The user selects from a list or 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 selecting or 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 or selects from a list 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 enters or selects from a list the 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
Entering or selecting a route will remove it, but 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 or selected from a list, 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 or a subset of routes may be selected from a list.
This system will allow the user to display,print or update billing information for a household or all households with a balance outstanding for subscriptions. When the billing system is started, it will ask the user if they want to generate a new set of bills for all households with an outstanding balance or find an individual household's bill , and either display or generate it.
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 through the Query of Customer Records interface,{cut original query description}. Once a household is selected, 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)
- {snip} last 2 digits of the year the customer signed up, first 2 letters of the route name
the customer belongs to, and a 3 digit number unique to the route.
* 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 {edit out--to a maximum of 5 entries}, selected from a menu
or check boxes. The number of subscriptions will be unlimited.
* 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 and the route name.
* Name, Publisher, Supplier Name, Supplier Phone Number
- 30 characters name, 30 characters publisher, 30 characters
supplier name, 10 digits phone number
* Selection of(ie. home weekend, home daily, coporate rate for doctors offices or coffee shops) 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
- ?? Daily delivery, able to specify which days.(eg. Fri,Sat,Sun or Mon and Sat)
Weekly delivery, able to specify which day
Bi-weekly delivery, able to specify which day or dates
Monthly delivery, able to specify date of delivery
Irregular, able to specify a number of specific dates
* General Description - A brief summary of the publication, originally
entered by the user
- special notes 'n' rows of 30 characters apiece
* Key Descriptors - (eg. Automotiv, trucks, tractor pull)
* 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
* Unique route identifier X 'n' rows
* 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
* Lists of households in route
* 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 and be defined by a list of postal codes (even though a household may be placed on a route though its postal code is not on that list). 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 or a sub-set of selected 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 left owing {edit out -- 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. *** Previously stated in this document was that the system would be designed for any level of user. This is an interface requirement of the system.
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.
The system needs to handle access by management, accounting, mail-room supervisors, region managers, distributor supervisors. And may be ported to affiliates in large urban centers(eg. New York). Perhaps a file server, some workstation, some terminals and some network software could be added in for the final deliverable. Also a most plausible enhancement in the future would be multi-level access, so that accountants are not deleting carriers for example.
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.
The missed requirements have been noted and updated within this document. Most contradictions in your specifications have been corrected, but by the nature of the document, please be careful not to overlook required specifications only because they do not appear in a certain section of this document but are found elsewhere.
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 INFO SYSTEMS Inc. Homepage.
last modified by Darrell Nash Last Updated: January 30, 1996