This post is one of the more esoteric ones where I delve into the geeky details of some of my programming work. I know – it’s really sexy, isn’t it?

I have mentioned the bridge application I developed that helps make payrolls run faster, helping client employees get paid faster, and so forth, using Microsoft Access 2003 with VBA, ADO, Excel, Office, etc.

Some members of the company are starting to migrate to Office 2007, and we can see the entire organization moving there soon. A few weeks ago, I tried opening and running one of the bridge applications in Access 2007, and it bombed horribly, specifically in how I’ve written it to use the Office 11 FileSearch object.

I just found a couple of few documents on MSDN and TechNet that I hope will help understand what is involved in the migration:

• Transitioning Your Existing Access Applications to Access 2007
• Migration Considerations for Access 2007
• Changes in Access 2007
• Office 2007 Object Model Reference
• Migrating a VBA Solution to a Visual Studio Tools for Office Add-In

Okay, to be honest, I picked that last item because it sounds interesting.

Part of what I do in my current work is produce ad hoc reports. I often am asked about the information in them because it doesn’t appear to match what decision makers had assumed.

The information on the reports is only as good as the raw data that exists in the system, I tell them. If the company no longer do business with a client, for example, and yet the client is still marked active in the system, then the client still gets counted as an active client. The same goes for employees. Active employee count may appear high, but when it comes down to the actual numbers of employees getting paid, the number is much smaller in some cases.

Helping managers and other decision makers understand these truths is one thing that I appreciate doing in my work.

Tags: reports management database daniel+johnson+jr liaison

Clients email the company their payroll files, and the columns on the payroll indicate Regular Hours, Overtime, Vacation, and so forth. To make the bridge application work, I and the other developer map the program that assigns payroll items based on this layout. It only works, however, when the layout is consistent. Whenever a client changes it by adding or deleting a column, the program generates an error.

One thing I have found so helpful in resolving errors is the Error Handler function. I use the Err object in Visual Basic, but I also add additional information such as the module name and procedure name where the error occurred. The user gets a message box, which is helpful for them, but I also wrote the program to create a log file with the same information so that I can go back and see errors that have occurred.

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.

The company didn’t have a process in place to make sure that this one client receives their 401(k) information on a regular basis. I had developed an application last fall for this specific client to produce the information, but there was no one set up specifically to run the application on a regular basis.

I was contacted earlier today to set up this application on several people’s computers. Interestingly enough, everyone could get to the application, since it exists on a networked drive, but, to make things as easily accessible as possible, I prefer to put a shortcut to the application on users’ desktops.

After I finished that, I sent an email to everyone affected, letting them know about the application, and letting them know how to get the report.

About 15 minutes later, I was summoned to a user’s computer because there was a problem with the report details. She was running the report for last week, but the Last Pay Date for several employees was for this week.

As I looked into the program, I realized that all the other details were correct except for this Last Pay Date, which gets updated whenever a payroll is run. I began brainstorming other ways to get the correct date.

One option was to look at the last pay check date for the date range specified, which is from the first of the month to the date the user selects on a form. That would make sure that date for employees who are getting paid this week is the date the user selected.

As I thought about that, I realized I was not finished. What if we run this report a month from now, and an employee had been terminated this month? The client would still want that employee to show up on the list.

I continued brainstorming, and wrote some mock VBA code on my marker board. Satisfied with that, I created a function, tested it out with various scenarios, and eventually came to a solution that will either use the last pay date for the reporting range OR the Last Pay Date field from the other data table.

I generated the report and sent it off to the client service representative, who will then forward it on to the client.

Whew! It’s been a busy day. I spent some of my morning interviewing payroll specialists about potential client candidates for a bridge application. Over the next month or so, we’ll be adding several new clients, so anything the IT group can do to better facilitate payroll entry has been greatly appreciated.

Some clients use the web-based system to enter their payroll, which automagically shows up in the system. Other clients, however, fax a timesheet, either handwritten or otherwise. We may want to look at some way to use OCR for some of these payrolls.

But there were a few good candidates, and I’ll be working on the bridge applications for them in the next week.

Most of my day today has spent diagnosing the application my coworker and I were developing yesterday and building a similar one for another client. The clients are trucking companies, and they have close to 200 active employees, most of which have been manually entered up to now.

One client is organized in such a way that they only have drivers. It turned out that, for the bridge application we were working on yesterday, we’d done everything but assign the number values to the individual payroll items. After adding code to do that, it worked fine.

The other client is similar to the first one, but they also have hourly employees that they report on via a separate file. The challenge here was to be able to set the program up with the flexibility and sophistication to know which file it was looking at, and subsequently, which layout to use.

Setting that up was a bit more of a challenge and required more customization than I’ve had to do in awhile, but I figured out what needed to be done, and, after testing it on the development and production side, everything worked.

Whenever I’ve set one of these bridge applications up, I always sent out an email to the relevant people to let them know. They all have gone home for the weekend, so it will hopefully be a very welcoming message they receive when they return!

Little things. We ran the new bridge application I mentioned earlier this week for the client’s payroll. When our integration manager program got a hold of the results, it returned warnings that were not at first easy to understand.

When I talked about it with the payroll specialist, she mentioned that two people were set up with a particular transaction code in the system, but the integration program didn’t recognize it. There were also two warnings in the report stating that the transaction code was “truncated at 6″.

I looked at the transaction file that the bridge application generated. Sure enough, the particular transaction code was 7 characters long. I mentioned that to the payroll specialist, who then looked up the correct transaction code and gave it to me.

She had already hand-keyed these three particular transactions and she told me the entire process of doing the payroll has gone from three hours down to just one hour. She’s fired up!