University Retail Food Service Vendor Account Payable System Prepared by Harold W. Webb

Transcription

1 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

2 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

3 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

4 Supporting Documents: Request Issuance Request issuance number: Vendor Name: Scheduled Payment Date: / / Date Payment approved: / / Description Amount Check Number Department Mail Stop Building Room Phone 4

5 University Invoice Template Invoice number: Franchisee Name: Franchisee Address: Franchisee City, St: Vendor Name: Vendor Address: Vendor City, St: Date Received: / / Total dollar amount: $. Tax: $. Account Code Product Number Description Quantity Price 5

6 Project Requirements Create a System Proposal for this case. The System Proposal (Fig & 4-17) should include: A. Table of Contents B. Executive Summary C. System Request (Fig. 2-2 & 2-13) D. Feasibility Analysis (Figs. 2-3, 2-7, 2-14, & 2-15) E. Project Charter (Fig. 3-24) F. 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-20). G. Requirements Definition (Figs. 4-2 & 4-15): including a concept map requirements model (Figs & 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