Tips Learned By a Rookie |
Perhaps you are like us, you get back from the great PDS Conference and you are filled with all kinds of exciting ideas to provide new and improved processes for the Payroll/HR departments. We have a saying here at Lee County Clerk of Circuit Court that HR needs to ‘put their pen down’ because they come back with too many wonderful ideas! After some discussion your team decides to create the eRPA (Electronic Report of Personnel Actions) in Vista and have it use the workflow functionality. The left side of the form will be populated with current Vista data and the right side will have drop down/check boxes where the user will be able to select ‘new’ information. Having NEVER written any aspx/vb code it was a challenge that I willingly accepted. Sure, I have added some custom code to the application but never created any from scratch. My first thought was where do I begin? Then I looked at the conference session materials for the “Development in Vista–Part 1” and “Development in Vista–Part 2” sessions, which are priceless presentations!
I took the paper version of our form and started to figure out ‘id’ names, columns and the size of each column. Realizing that I needed a custom table I created a spreadsheet of the columns that I needed and sat down with our DBA who incorporated it into Vista. After finalizing the new database table, I utilized the Vista Source Generator that created source code based on my new database table definition for use in web pages, database scripts, data classes, and views. I used this code as my starting point and adapted my changes by modeling an example of a multiple tabbed page design. I picked the ‘Employment Information’ page since it had been enhanced in the release last summer. I copied the new code into a custom folder and started to transform the page into our eRPA. The more I did (and saw that it actually was working) the more comfortable I became in creating the screen pages. One of the best moments was when I hit the ‘submit for approval’ button and the custom table was actually populated with data!
Once I was able to get the data populated into a simple workflow, (it consisted of only a start, autou, approval and done step) I realized that the column names within the workflow were not being displayed as expected. After some research I realized that I could add the new column names to the edit.vb code in the stored procedure call. Since we also wanted to have drop down boxes and check boxes available to the flow participants, I also needed to add custom field definitions (System Administration -> Field Definitions). We were aiming to have the functionality of the workflow mirror the same functions that were in the aspx coded screens. By this time, I decided that we needed another custom ‘cd’ table in order to populate drop downs for data that were not currently being stored in the Vista application. Examples include ‘lunch duration’, ‘other employee action’ and ‘other position action’ reasons. Our goal was to allow HR to modify this new custom cd table in the future without any intervention from IT. So, it was back to our DBA who graciously created another table. After quite a few table revisions to both custom tables we finally had our final version!
During our weekly meetings with HR and Payroll it was decided that when the user entered a pay grade code, only those positions that have that pay grade should be displayed plus automatically show the min and max for that pay grade. I thought to myself ‘How in the world am I going to be able to do that!?!’ Oh, and let’s have the user enter the biweekly hours and the weekly pay rate and have the ‘system’ calculate the annual and hourly rates. And one more thing, if only the biweekly hours are entered and not the weekly pay rate (or vice versa) display an error message. Really? I decided the best way to tackle this was to find something similar to what I needed that was already in the Vista application. After some searching, I found exactly what I was looking for on the Pay Rates screen. So, I went through those programs and cut, pasted and changed the code to what I needed. After some sleepless nights or waking up in the middle of the night with the old, ‘that is how I need to code it’, I finally got it to work!
Click the image to view the various steps within the eRPA
Error checking was added on each tab in order to cut down on the number of incomplete eRPA’s. For example, if a user selects a check box that has a reason code and they did not select a reason an error message will pop up. This message will display which reason code they missed and will automatically redirect them to the page where the error occurred.
Although I learned a great deal and I have the pages working exactly like I (and HR/Payroll) wanted them to, there were parts that I did not understand. Sure, they were working, but why? (Besides luck!) After a conference call to PDS with Marco I have a better understanding as to why and how things are working in both the screens and the workflow.
Overall, we have created two custom tables, new security options, and numerous custom PDS field definitions, a new stored procedure, a new workflow, a new Crystal Report and a new folder that contains all of our aspx/vb code. Although we are not in production yet, we are making great strides towards that goal.
Oh, and by the way – one of our remote agencies, the Lee County Port Authority, heard about this project and they would like their own custom eRPA to be built into Vista too. No problem. I can do that!
By Barbara Cobb
Applications Analyst
Lee County Clerk Of Circuit Court
BCobb@leeclerk.org