University Retail Food Service Vendor Account Payable System
Prepared by Harold W. Webb
BACKGROUND
A major university, in an effort to improve the quality of life for its students, has contracted with
several commercial vendors to operate on campus. This arrangement basically allows this university to
operate several well-known food franchises in multiple locations on campus. The university has
arrangements with vendors such as Blimpie, Chick-Fil-A, Pizza Hut, and Cappuccinos. To support these
operations, the university provides staff and administrative support. Part of this support is centered on
paying authorized vendors for purchases of food and associated products used in these name-brand stores.
The payments to the vendors are handled by a small group of people working for University
Finance and Accounting. Currently the Retail Food Service Vendor Account Payable System (VAPS) is
primarily a manual process with limited computerized support that requires an excessive amount of time to
complete. The timely processing of invoices has become a problem, as is evidenced by (a) the complaints
of several vendors regarding late payments, (b) the increase in late payment fees charged to the university,
and (c) the loss of vendor discounts for early payment of invoices. The generation of reports to aid in the
management of the system is also troublesome, as staff often must work overtime to compile the data
needed for the reports. Moreover, these staff positions historically have experienced very high turnover
rates, which have compounded the problem.
ORGANIZATION
The organization of University Finance and Accounting consists of the comptroller (Barbara), the
accounts payable supervisor (Van), the accounts receivable supervisor (Maria), and other general accounting
functions. The organization chart is shown in the following figure. Javier has recently been hired to the retail
vendor accounts position, a position that has experienced unusually high turnover.
BUSINESS OPERATIONS
Barbara has overall responsibility for financial operations for the university. She has been charged
with reducing costs across the university both within her area of responsibility and across all colleges and
administrative units. Given recent university-wide budget cuts, which are driven by a downturn in the
economy, there is great pressure to justify all new spending. A business case must be made for all new
procurements. In addition, identifying inefficient operations across the university and recommending
actions to reduce these inefficiencies has become a priority of the administration.
Van, the accounts payable supervisor, recognizes the problems within the retail vendor accounts
section, and he believes that installing new computing systems can help solve these problems. However, he
is unsure of what the system requirements should be, and he therefore has not yet made a business case for
a new system. Both Van and Barbara are keenly aware that negative relationships can develop between
their organization and other university units if new computer equipment is purchased for finance and
accounting without full justification, particularly in a time of budget reductions.
Javier is an accountant for the university who is responsible for handling the transactions between
the vendors and the franchisees at the University Center on campus. His major responsibility is handling
1
retail vendor accounts payable, which primarily supports the on-campus food franchises. Currently the
university operates five franchises. Franchisers provide the university with a list of approved vendors.
These are the vendors that provide each store with approved products.
Each store submits requests for supplies to vendors as required. Many invoices are for perishable
items and are submitted several times per month for each store based on demand. Each store submits
between 10 and 25 invoices per month, with the average being 20. The average invoice amount is $1,250.
The vendors that the university deals with offer terms of 2/10 net 30, which provides the university with
the opportunity to receive a 2% discount for early payment.
In the current system, a clerk receives an approved invoice for food or an associated item (e.g.,
vendor-specific paper products or food items from a local bakery) from the University Center. The major
activity of the retail vendor accounts office is to create an issuance request and a payment report that will
be sent to the university check issuance office for payment. The issuance request is needed because the
accounts payable section does not produce the checks, an internal control procedure specified by the
university to prevent fraud.
The payment process begins with the submission of an invoice from the University Center to the
accounts payable office. Invoices are either received when goods are delivered or sent separately by mail,
depending on the vendor. The first step after the invoice is received is to separate the invoices by vendor
name. This is done because it is very common for the university franchisees to receive three or four
shipments each week from the same vendor. Vendors may submit many invoices. Although a vendor may
supply many franchises, all vendors are required to submit a separate invoice for each franchise. Accounts
payable consolidates invoices each week so that the university can submit one check to the vendor instead
of the multiple checks often produced to cover multiple invoices. Information maintained separately about
each franchisee includes franchise name, address, and phone number.
A university accounting code must be assigned to each product type on every invoice (e.g., food
item, paper product, or marketing material). Once all product types have been assigned an accounting
code, data from the invoices are keyed into a template on an Excel spreadsheet. These data include invoice
number, date received, total dollar amount, tax, vendor name, and franchise name, plus the following for
each item: product number, product description, product price, account code, and product quantity. The
spreadsheet calculates the total cost of the products shipped from the vendor. Then two copies of the
payment report are printed. One copy is kept in the accounts payable files, and the other copy is sent to the
university check issuance office. In the current system, the spreadsheet program calculates only one report
at a time, and no electronic copy of the spreadsheet is maintained. Only the paper copy of this document is
available for future reference and report generation purposes.
The next activity required in order to pay invoices is the creation of the request issuance form.
This form has been in place for some time. Supporting this process is a stand-alone computer program that
allows the user to input information so that it can be printed out on the standard request issuance form in
the approved format. The request issuance form includes the following information: request issuance
number, amount, vendor number, scheduled payment date, date approved for payment, and description of
products listed on invoice. The current process presents a problem because the accounts payable clerks
must use two different computer applications; Excel and the program that generates the request issuance
form. Moreover, much of the information on the request issuance is the same as that on the payment
report, which particularly frustrates the clerks. Additionally, although most of these forms are for the same
small set of vendors, the supporting computer applications have not been designed to store information
such as vendor name, address, phone number, and vendor code in memory. As a result, clerks routinely
key in the same data repetitively every day.
Once the payment report and the request issuance have been created, they are forwarded to the
university check issuance office so that a check can be generated. After the request issuance has been
processed by the check issuance office, it is returned to the accounts payable section with the check
number, the amount on the check, and the date it was paid. The original invoice and a copy of the payment
report must be retrieved from the paper files in the accounts payable office. These documents are matched
with the copy of the processed request issuance, so that the payment information can be noted on the
invoice. The documents are then re-filed in their respective files.
2
There are many repetitive tasks and operations in this process. The clerk must retrieve all of the
necessary documents, match them, and re-file them. This is a time-consuming and monotonous task with
virtually no utilization of modern information technology. Current business problems associated with this
system include duplication of payments; multiple entry of data (occasionally with errors); inefficient use of
information systems; inability to rapidly assess the status of accounts payable; and inability to rapidly
generate reports on the number of invoices by vendor, account type, or time period.
Although vendors offer terms of 2/10 net 30, the university has been unable to take advantage of
these terms, a deficiency that costs the university 2% of the total invoice amount every month. In fact, the
number of late invoices (more than 30 days) has been averaging about 15% of all invoices processed. The
vendors assess a late fee of 2% of the invoice total.
The situation is compounded by the high turnover of employees assigned to paying vendors.
(between two and three per year). Common complaints of employees leaving these positions center on
monotony in routine processing and the stress associated with (a) requests for summary information
concerning the status of accounts payable and (b) the creation of summary reports. The university is
incurring excessive hiring costs (an average of $2,500 per person hired) and training costs ($500 on
average) for this position. The lack of trained clerks has also caused invoices to be late in processing,
causing the university to incur late charges on purchases despite routine use of overtime (10 hours per
month at an average of $17.50 per hour).
EXISTING SYSTEMS
The university currently has supplied the accounts payable clerks who are assigned to this task
older, 133-MHz Pentium-based machines to run both Excel and the application program that generates the
stand-alone forms. This configuration supports the existing system, but it is unlikely to support newer
applications. The computer equipment is obsolete and needs to be replaced. The facility does have a local
area network and Internet connectivity, which allows full network capability at minimal cost. However, the
network is not used for the accounts payable system. Secure server space is also available for a new
application to support accounts payable. However, the university will support the replacement of the
existing hardware as part of the development of a new system only if the cost is justified by an economic
return on investment.
OPPORTUNITIES FOR IMPROVEMENT
The new system, according to Van, should have the following capabilities:
• enable clerks to enter invoices daily as received
• provide for weekly generation of request issuances
• eliminate duplicate data entry by storing information on vendors, franchises, and product types
• provide tracking for request issuances sent to the check issuance office
• match completed request issuances with outstanding request issuances
• generate monthly reports of accounts payable:
o total paid out by each franchise
o franchise total broken down by university account
o university detail and summary by university account
o vendor totals
o total for each account
• provide an ad hoc query facility to support unanticipated management report requests
• produce savings that exceed system costs.
3
Supporting Documents:
Request Issuance
Request issuance number:
Vendor Name:
Scheduled Payment Date:
Date Payment approved:
/
/
/
/
Description
Amount
Department
Mail Stop
Building
Room
Phone
4
Check Number
University Invoice Template
Invoice number:
Franchisee Name:
Franchisee Address:
address:
Franchisee City, St:
address:
Vendor Name:
Vendor Address:
address:
Vendor City, St:
address:
Date Received:
Total dollar amount:
Tax:
Account
Code
/
$
.
$
Product
Number
/
.
Description
Quantity
5
Price
Project – Requirements
Create a System Proposal for this case. The System Proposal (Fig. 4-14 & 4-17) should include:
A.
B.
C.
D.
E.
F.
Table of Contents
Executive Summary
System Request (Fig. 2-2 & 2-13)
Feasibility Analysis (Figs. 2-3, 2-7, 2-14, & 2-15)
Project Charter (Fig. 3-24)
Workplan: including a Work Breakdown Structure (Fig. 3-6), Gantt Chart (Fig. 3-7), PERT Chart
(Fig. 3-8), Risk Assessment (Fig. 3-20), and a Use Case Point Estimate (Fig. 5-13 & 5-20).
G. Requirements Definition (Figs. 4-2 & 4-15): including a concept map requirements model (Figs.
4-12 & 4-16).
H. Functional Model: The functional model should be comprised of an activity diagram, a use case
diagram, and a set of detail use case descriptions for each use case. Any assumptions that you
make must be made explicit and approved by me.
I. Structural Model: The structural model should be comprised of a class diagram. Each class in the
class diagram must include all relevant attributes and operations.
J. Behavioral Models: The behavioral models should include both sequence and communication
diagrams (one for each of the use cases in the use case diagram), a behavioral state machine for
each problem domain class, and one CRUD matrix for the entire system.
At this point in the evolving design of the system, the analysis of the requirements is fairly complete.
However, you may still uncover additional requirements as you work through the design. Therefore, you
may need to modify the analysis models. (Note: Be sure to “balance” the various models.)
K. As a first step toward developing a design of the system, you should evolve the analysis models
into design models by creating a Package Diagram for the problem domain layer. The Package
Diagram can serve as a mechanism to identify potential patterns and/or components. Also, be sure
to perform the verification and validation processes to all models.
L. For each problem domain class, you need to include a set of invariants for the attributes and
relationships and add them to the class description. Finally, for each non constructor, get-, or setmethod, you should create a contract and a method specification. If the “algorithm” for the
method is simple, use Structured English for the algorithm specification. On the other hand, if
the algorithm is complex, you should use an activity diagram to specify it.
M. Appendices:
Meeting Reports
Progress Report Cover Sheets
Assumptions
Other
6