Over the past month, I have been working on a project to automate payroll entry for a client that has close to 300 employees and is growing. Naturally, it is the company’s best interest to get this payroll automated as much as possible.

To do this I’ve been developing an application to bridge the payroll info to Microsoft Great Plains Integration Manager.

One of the criteria I’ve used to evaluate a client’s payroll is a consistent layout in a good format, so that I can tell the program where to map regular hours, overtime, cash reimbursements, etc. In some cases I’m able to tweak the payroll to make it into a layout that is consistent enough for me to automate.

This particular client is a construction company, and the only electronic version of the payroll is a text file that is not delimited. The file is basically a report from the client’s system, and it has page headers and department footers, as well has breakdowns of withholding, etc. Most of that I can ignore in the program.

My colleague was able to import it into Microsoft Excel, using spaces as the delimiter. From there I saved the file as tab-delimited text, the format used in the other bridge applications I’ve developed.

The big problem is the inconsistent layout, which has come from using spaces to delimit the text, depending largely on how much detail is on a particular line of text. Look at the following 3 lines of text:

• E 22 Per Diem – C AZ 3 99
• E 22 Per Diem – C AZ 3 XYZ111 99
• E 22 Per Diem – C 99

In each of these lines, the payroll item is Per Deim, and the amount is 99. When you space-delimit the lines the amounts are in different columns.

This is just one major aspect of complexity that has come from my attempt to automate the payroll. After talking it over with my boss, we realize that we’ve come to the point of diminishing returns.

I’m off this project until there is another way to parse the payroll information and am able to move on to another project that’s in the queue.

Related tags: microsoft+great+plains integration+manager payroll+automation microsoft+access vba programming application+design peo daniel+johnson+jr

I was on the phone with a Payroll Specialist about 30 minutes ago. One of the company’s biggest clients is a trucking company. We set them up back in January with a bridge application to facilitate payroll entry. The client emails their payroll in a spreadsheet with a consistent layout that I and my coworker mapped with the program, and their payroll needs to be done early Monday morning for a Tuesday check date.

Last week, the client left the first column blank for one of their employees, and the payroll specialist didn’t find out he wasn’t paid until the day after the payroll went out. She called me this morning to have me check to see if the program would do that again. In less than 10 minutes, I was able to diagnose and fix the problem so that it won’t happen again.

The code looked for something in that first column before mapping the columns into specific payroll items. In this case, the data in the first column isn’t as important as that in, say, the third column. I changed the code that does the test to check the third column instead.

I’m pleased that my knowledge of how this program works lets me respond so quickly and adeptly to a problem like this.

The company uses a version of Microsoft Great Plains (GP) that’s been customized for the PEO industry. One piece of that is Integration Manager (IM). I’ve talked about the bridge application a number of times before. With an Excel file from a client and, with some sophisticated programming, we create a tab-delimited text transaction file for Integration Manager. We’ve set up some profiles in Integration Manager to upload payroll transactions into a batch in the Great Plains system, saving a lot of time and money. In some cases we’ve seen a 91% drop in the amount of time it takes to run a payroll.

Over the next few weeks or so, I’ll be running Integration Manager for the Payroll department. Here are some numbers for today:

1002 transactions, for 530 employees of 10 clients.

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.

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.

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.