Expense Reports
From PikaDocs
One of the first additional features we added here was a rudimentary replacement for the paper forms and WordPerfect templates we used to use. The problem with paper was mainly:
- Bad Handwriting
- Computational errors
The problem with WP forms was out of date versions with wrong milage rates circulating around.
The original version of this feature solved all of that pretty well, as it was designed to be a single accessible form, that simply mimicked the way the others worked - you filled them out and submitted them, the math was done for you, the content was legible, and the formula was the same everywhere. The problem is, people were used to "batching up" expenses and then submitting a bunch at a time. This makes a lot of sense if most of your expenses are small (milage to courthouse, parking, etc.) but frequent. This form, as it was made really no provision to save up small charges for later submission. The model wasn't working. Another minor annoyance, was that the milage rate was "hard coded" in the php code of the file and to change rates, someone had to edit the file (me). It also wasn't a "graceful" transition, one day it'd be one rate, then it'd be different, if expenses hadn't been turned in (on the old rate) then staff would have to resort to paper.
This version, adds a table to Pika for expenses (and a "menu" table to hold milage rates). All data is stored, and can be changed at any time by the user until the time that they report it. Once an expense is marked as having been reported, it disappears from the "normal" display unless a user checks the "Display Reported Expenses" filter option. A user can select which items they want to report on, and leave others for later reporting. Once an item has been reported, it is no longer accessible for editing, since presumably it's been finished with.
This version also solves the milage rate problem in several ways:
- Since it is stored as a "menu" within the Pika system, it is editable by anyone with "Admin" rights to the Pika system, so that it doesn't take a programmer to change anything.
- Also, since it is a menu (and thus an array) it is possible to have multiple milage rates based on the year.
- Because of the multiple milage rates, the program figures out the rate based on the year the expense was incurred, so staff can submit reports with mixed years (handy in January).
The report also improves quite a bit on the original, since it provides breakdowns based on funding, PAI, Milage, Per-diem and "Other", which our previous forms didn't do.
So, far the main interface/training challenge, is people not understanding the selection mechanism.
