Saturday, March 31, 2007
Green Tie and Purple Socks!
Back in the Stone Age, when I was taking a programming class, my instructor handed out a 2-page dialog on how to compute overtime. It started out, “If an employee comes to work wearing a green tie and purple socks, parts his hair on the right side, and the barometric pressure is 29.05 and rising, and it’s the 3rd Thursday of the 11th month, and . . . . .” This went on for almost 2 full pages. The last sentence went on, “This employee will receive double time, UNLESS . . . .”
While amusing, this dialog does point out the difficulty in computing an employee’s earnings. Over the years, with the influence of government mandates, union negotiations, and well meaning but misguided Human Resource Directors, payroll systems have become very convoluted.
What have the financial software providers done to alleviate the problem? Nothing! They let payroll departments do the difficult record keeping and computations by hand. Of all the general accounting packages, payroll has to be the most difficult system to design. That’s why most of today’s payroll packages fall short mark. It takes a lot of effort, talent, and experience to design a payroll system, something most software houses lack!
Example: How do you handle multiple payroll attachments? Let’s say Crowdad Dwarski has been less than an ideal father; i.e., he’s a dead-beat dad with a couple of children, a tax lien from the Feds, and another from the State for back taxes. Which lien takes precedence? How much goes to each lien holder? How much is left for Crowdad to live on?
Another Example: A union contract that states if an employee shows up for work on time for an entire month (wow, what a concept!) he gets a bonus of $.05 for every hour that he worked to be included on his 1st payroll check in the following month. Additionally, if he’s not tardy for an entire quarter, he receives an additional $1.00 for each day he worked to be paid in a separate check the first Friday following the end of the quarter. On top of that, if he makes it through the entire year without being late he receives $100.00 or .005% of his normal annual earnings, which ever is greater to be paid on the first Friday on January of the following year.
Can you believe this? These are not unusual situations. They’re everyday challenges for payroll departments. You just can’t make this stuff up. It takes the confused mind of a government official or some union lackey to dream up this kind of B%& S^*& !
Name me one payroll application that can solve these problems!
Posted by S.C.R.A.H. on 03/31 at 01:43 PM
Payroll/Human Resources •
(0)
Comments •
Permalink
Saturday, March 24, 2007
Stop the Short-Cutter!
I continue to be amazed at the number of Financial Systems out there that are designed with the stupid idea that users NEVER make a mistake. The software developers assume that users will always post invoices, payments, etc. correctly. Really I-G-N-O-R-A-N-T !
How can I say this? Don’t these developers provide recovery procedures or methods to correct mistakes? Well, yes, but clever users find ways to take shortcuts and circumvent the “safeguards.”
For example: Let’s say someone incorrectly posted an invoice to the wrong general ledger account and then updated the G/L with this incorrect account number. The standard method to correct the problem would be to go back to the A/P system, void the invoice (creating a negative posting to the G/L for the incorrect account), and re-post the invoice with the correct account. However, in a crunch, or if just a tad on the lazy side the “short-cutter” will just make changes in the G/L, leaving the A/P alone. Auditors just love this!
Wouldn’t it be great if the System protected the integrity of the data and would not allow such “corrections?” It would be nice if software developers would provide tools to make corrections easier and be less time consuming for those overworked accounting types. They stress out so easily.
Agree?
Posted by S.C.R.A.H. on 03/24 at 09:04 AM
System Design •
(0)
Comments •
Permalink
Friday, March 16, 2007
Keep Your Pants Up!
What really gets to me is when Management doesn’t give a rip about security until it’s too late – what idiots! The greatest danger is from “within” but Management remains oblivious to this danger. Usually Management wants everything done NOW, and that applies to bringing new staff members up to speed on the applications they will be using. That can lead to disaster. Embezzlement can happen quicker than you ever thought possible!
Case in point: A new Assistant Controller is hired, and Management says, “Get him trained on the financials this week. He’s going to be managing the Payables section next week. Give him whatever access he needs to do the job.” The IT Department explains that “everything” means having the ability to post invoices, payments, and to add and modify the Vendor’s master file which is a security risk. Management responds, “We don’t care, just do it!” Oh, did I mention that these geniuses gave this individual check signing privileges as well?
The Assistant Controller they hired was a smart one. Within a week this individual had the A/P system figured out. He could modify an existing vendor name to his name, post a couple of false invoices, cut a check made out to himself, and change the master record back to the original vendor name. Of course, he picked a vendor with high activity, so it wasn’t questioned because the A/P system reported these payments under the original vendor name. Nobody was the wiser until the employee failed to show up for work after taking the company for thousands of dollars! Management got caught with their collective pants down, and they had no one to blame but themselves.
We need to protect ourselves from incidents such as these! We can’t do anything about Management. Stupid is, as stupid does. Ideally, we would separate the duties, so that staff who create the master records (vendors, customers, and employees) aren’t the same people that post checks or payments.
We also need do something about Systems. Systems need a way of tracking additions, changes, and deletes to all records. Changes need to record a before and after image. Additionally, there needs to be a time-stamp and operator ID as part of this record. Most importantly, there needs to be a means to monitor and report this information, possibly with an alarm mechanism to an IT security person and/or to the Controller. At least this way it’s faster to discover and easier to prosecute!
What’s your horror story?
Posted by S.C.R.A.H. on 03/16 at 09:30 PM
System Design •
(0)
Comments •
Permalink
Page 1 of 1 pages