Welcome to my online portfolio, the complement/substitute for my resume. The opinions included herein are my own and do not reflect those of any client or employer, past or present. Please check out the new site: http://danieljohnsonjr.com

Showing posts with label financial reporting application. Show all posts
Showing posts with label financial reporting application. Show all posts

Sunday, June 3, 2007

Helping company take advantage of a tax credit

I found out last year from the Accounting department at my current company that employers with tipped employees can get a tax credit based on how employees have reported their tips. I guess it's the IRS's way to encourage employers to get their employees to report tips so that they can get the tax from it.

The PEO model is one of co-employment: the client employs someone to do the work while the PEO employs the worker from an HR perspective. If the client doesn't take the tipped employee tax credit (or whatever it's actually called), then the PEO can take it.

For me it has meant developing yet another report from the SQL Server database. The business, of course, wants the report as soon as they can get it, and I and my boss help them understand that it cannot always happen overnight or even in a week.

The report, as many of these I develop lately, involves looking at the transaction history on employees' paychecks to identify reported tips. It sounds simple, and it really is, as long as you know where to look.

Over the past year or so, I've gotten better as I've come to understand where the types of information are stored - the database and the front-end are a modified version of Microsoft Great Plains, and the tables are not always intuitively-named.

I probably should push this application out to the Accounting department, since all I did was run it for last year and the current year. The upper management was certainly surprised at fast I'd turned their request around.

Tuesday, April 10, 2007

The output is only as good as the input

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:

Monday, February 19, 2007

Lesson learned while on a mission critical conversion project

Here's a project I worked on where I learned an important lesson.

The client was a global consumer products company, and the project was to convert an Access 2.0 application to Access 95, which was a conversion from a 16-bit environment to a 32-bit environment. I'm not even going to claim that I understand what all that means, except to say that there were a lot of procedure calls to the Windows Application Programming Interface (API) that needed to be changed over. This application was used to facilitate preparing the company's profit/loss and balance sheets for all of their business units around the world. Hereafter, I'll call it the "financial reporting application".

Where I went wrong was that I didn't test portions of the program as I converted the code. It demonstrated a skill in programming that I needed to learn, and I learned that lesson the hard way because, once the program was "converted", i.e., all the code compiled correctly with no errors, there were other application errors that began popping up all over.

I created a tool to help me keep track of all the errors and the steps taken to resolve them and provided the client with daily progress reports.

As I think back on it, I would have done much better if I had taken more time to understand how the program worked in its prior environment and tested the program incrementally as I revised the code.