Daniel Johnson, Jr.

One hour ago I got an e-mail from a payroll specialist, telling me that a client with 107 active employees had added a column to their payroll file and asking if I could fix their bridge application to allow for the new payroll item.

I opened the code, and after I made the changes needed in a few class modules, we were good to go. I tested it out on my machine and then put it out on the network for the payroll specialist to use.

I was able to get this done so quickly because there were only a few places to add some more code. Having the system set up like this was very efficient.

When I was initially developing the bridge application a couple years ago, I had set up the Close button on several forms to be the Cancel button. That way a user can just hit the Esc button to close the form, if they prefer to use the keyboard.

As the applications for various clients have been used, this feature had become more of a bane than a benefit. It turns out that users hit the Esc key to Undo what they have typed, but the application would close the file. This results in some records being incomplete, causing errors when the application is processing.

While you can try to anticipate the user’s experience as much as possible beforehand, some bugs still show up.

No big deal. I just removed that functionality from every bridge application we have in use so that program behaves in a way that users expect it to behave.

When I was developing the bridge applications, I had set the code up to recognize a “test” environment and a “production” environment through hard-coded filenames. It became cumbersome to change the filenames in code every time I moved the application to each environment. We also realized we needed to set up a “standalone” environment for the applications.

…hence, the need for the application to be made “drive-independent”.

I wound up setting a property in one of the main VBA classes to “auto-discover” its environment as the application launched. That made it possible to move copies of the application easily among the test/development, production, and standalone environments.

While we’re on that topic, every week we need to backup the copies of the bridge applications from the production environment to the other two. The reason for this is because there are certain changes made to some self-correcting features while payroll specialists run the applications each week. (I’ll have to discuss these features in a separate post.)

For a few weeks I would manually navigate to each folder that contains a bridge application and copy the application file over to the other environments. That’s okay for a couple of files, but as we started implementing this for several clients, it became very cumbersome.

The solution: batch files. I created batch files that copy all the files from the production environment to the development/test and standalone environments. What used to take 45 minutes now takes 1 minute. Way cool.

As you may have read before, I’ve written the bridge applications that prepare clients’ payroll for a program we use to batch load into our payroll management system. Whenever I and now my coworker, whom I’m mentoring, finish one of these bridge applications, we update a master list of all the clients we’ve set up and email it to the other people in the organization that need it.

The person who normally runs the batch-loading program wasn’t available today, because she’s printing W-2′s for all of our client employees. So, the payroll specialist contacted me, and I ran it for seven of our clients. I estimate that it pulled payroll transactions for about 525 employees.

I love being able to help out in a pinch!

In an earlier post I described some changes to a client’s payroll journal. In this one I’ll share how I worked those changes into the corresponding bridge application we use to automate the payroll entry.

You will recall that I made two significant changes:

1. Added a new payroll item and
2. Removed totals columns

I will discuss each of these in turn, along with some other things I’ve discovered while working on this application.

New Payroll Item

The client wanted to be able to track Training, so I added it to their payroll journals. In the bridge application, I added the payroll item in the respective classes to recognize it.

Totals Columns

The client tracks both weeks of their pay period individually, and the payroll journal was originally set up to provide totals for each week and for both weeks. The totals columns for Week 1 were set up immediately after Week 1′s payroll items. The totals columns for Week 2 and for both weeks were set up after Week 2′s payroll items.

When I removed the totals columns, I moved all of Week 2′s payroll items. The bridge application contains a VBA class where I’ve mapped the payroll item columns on the spreadsheet to elements of a tab-delimited array. I revised the code to make sure the each element is mapped appropriately.

Pitfalls while working off a network

Early Friday afternoon the network where I develop the applications became frozen, and I had to shut down the application from the Task Manager. Knowing this corrupts the application file, when I came in this morning, I started over again, but this time off a local copy, in case something would happen to the network again. Since I’d made the changes one time already, it didn’t take long to do.

Testing it like the user would

When I tested the application to make sure the changes worked, the output looked odd. I contacted the payroll specialist and found out that she runs the bridge application for one location at a time, and after testing the application that way, everything worked out fine.