Budget

The Budget application is a data entry and reporting application that is used intensively during a 2 week period at the end of the fiscal year. Budget officers from each department enter primarily salary adjustments for their staff and adjust accounting details regarding how those staff get paid. Once the data is entered there are reports and tools to ensure that each department has allocated funds according to their budget and the policies established by the central administration.

The Budget application is in its 3rd generation (4th if you count paper). It started as a mainframe application and was used that way for many years, spent two years as an Access/VB application, and has has been a web application for the past 6 years.

Features and Functionality

• Very user friendly data entry pages geared specific towards the types of records which are being updated (filled positions, general expense records, etc...)
• Tools to adjust salaries on an individual level and across groups of people.
• A very flexible filter system that allows users to manage sets of records in lots of different ways.
• A large set of very flexible reports.
• Balancing tools for the budget office to make sure that each organization and department only spend the money allocated to them.
• User administration tools you would expect for this type of application that the budget office can use to grant access to certain records based on organization and department.

Challenges and Lessons Learned

While the previous Access/VB app caused all kinds of support headaches (ODBC setup, do people have the current version, Access version X vs. Y, etc...), the users had been trained on it and where used to it. We had to develop a web application that provided a similar user experience, both from the interface and from a performance perspective. We kept the main data entry page looking very much like the main Access form the users were used to. We added a filter feature to match functionality that Access/VB provided for free. Lastly, we have found a good balance of caching to make the application perform well during the 2 week and the end of the fiscal year.

I pushed the Display Tag to its limits while generating reports for this application. A goal of mine was to make the reports as nice looking as possible both on the screen and when printed from the web browser. I used different CSS style sheets for the screen and page to create nicely formatted printed reports without using PDF.

Having an existing application greatly simplifies the development process (we decided early on we would be making pretty much a straight port). However, I didn't know VB or Access (not as big of a deal as I could read the code and figure out most things - although I did curse pivot tables once or twice). More of an issue for me was that I was not familiar with the business domain or the data. I work more on the student and enterprise side of things, and my lack of knowledge about MFK codes, control sheets, expenses and revenues made things more challenging.

I also discovered that the financial folks didn't have a sense of humor when I once described a 7 million dollar discrepancy in some report as a rounding error (I was kidding).