Tuesday, August 28, 2007

Where Is My GPS Now That I’m In A/R?

Software developers have NEVER expended any effort in designing a good Accounts Receivable.  Maybe it’s stupidity on their part, or maybe it’s because they’re just plain lazy.  I don’t know the reason, but I do know their design results are a load of horse pucky!

Examples: 

1. Developers never consider “employee” receivables.  There is no capability of passing of data from Payroll to A/R.  There is no way to identify a customer as an employee.  What you wind up doing is reserving a series customer numbers for employees, and all postings are done by hand from a spreadsheet.  Right?  Some only allow you identify a customer as “active” or “inactive,” and that’s it.

2. “Customer numbers” are another problem.  They’re not an instinctive way to reference a customer.  If you have several hundred or thousands of customers it’s a real challenge to find the customer that you’re dealing with.  A/R needs better methods to access customer records than the limited methods that now exist.  Expanding use of search fields, more effective wildcard searches, filters, and consolidated screens would be a good start.

3. Lastly (at least for this rant), the navigation through the plethora of screens is anything but intuitive!  You almost need a GPS to get around.  The result is that time is lost, mistakes are made, and training takes much longer.  You’ll be doing a lot of training, as terrible software is frustrating and stressful to use.  The result of these faults is high staff turnover!

Of all the applications within a financial system A/R is probably the most poorly designed and the most neglected by developers.  Why is this?  Upper management has no clue as to what is needed by the accounting department, and they are the ones who make the decision as to what system to buy. They are wined and dined by software salesmen and are promised that their problems will be solved.  Yeah, right!  As long as companies keep buying useless software there is no incentive for developers to spend time and money to make things right. 

Saturday, August 25, 2007

Accounts Receivable, Ignored Once Again!

Accounts Receivable (A/R) is the most ignored application by software developers.  It has been superseded by other applications with fancy acronyms.  A/R is still there but pushed to the background.

A/R is the cash register for your company.  EVERYTHING your company sells must pass through A/R.  It is instrumental on how this information is posted to your G/L.  If it weren’t for poorly designed software, A/R could provide you with useful tools to help manage this revenue!

Typically, developers follow the folly of summarizing monthly activity into the arcane design based on “Buckets.” Yes, once again they took the easy way out and eliminated all chances of having meaningful analysis data!  Did anyone ever explain to them that “Buckets” are subject to errors?  Evidently they did, as they all seem to include elaborate methods of reconciling “Bucket” totals once reports don’t cross-foot.

Speaking of reports, those supplied with the system are extremely limited in their ability to provide useful information.  For example, aging reports can’t be modified at run time.  Even worse, Balance-Forward customers can only be reported as to what amounts are current or non-current.

Reporting periods have to be closed before charge and payment amounts for a new period can be posted.  Timing of closing a period, especially at year-end, becomes a CRITICAL!  Your company’s cash position hangs in the balance until your position is current!

There are many more issues to address than what I have mentioned.  It’s the same old story.  Developers are lazy, and their sales staff should be selling used cars or doing Infomercials for cheap jewelry on some shopping network!

In this day of tight money your company’s cash analysis is extremely important.  Can you count on your A/R, or does it leave you hanging in the balance?

Tuesday, August 21, 2007

Time & Attendance Nightmares!

I have been ranting about current payroll package nightmares.  I have barely scratched the surface!  Here are some additional points to ponder:

It’s hard to believe that there are some payroll applications where overtime is hard-coded for only a 40-hour week!  That’s it, just a 40 hour a week limit!  What are they thinking?  Overtime calculations vary with state regulations, occupation, union contracts, etc.  As an example, some California employee wage orders say overtime is anything over 8 hours a day, 40 in a week, and the first 8 hours if the employee works on the seventh day.  Agricultural and Hospital workers have different regulations.  Then there are double-time considerations!  If you have a union, all bets are off because the labor contract often contains minutia that supersedes everything else.  Employees under different wage orders don’t mix, as the system can’t determine proper overtime calculation methods for different types of employment.

Rarely do payroll applications provide a means to import payroll hours from a Time & Attendance (T&A) system.  Because of this, interfaces must be written in-house, or, heaven forbid, by the application developer or a VAR.  Even then it is never seamless. 

Communications between Payroll and T&A must go both ways.  I am sick and tired of entering the same information in both systems.  After a new employee is created in Payroll the T&A must be updated with his/her name, employee #, supervisor, etc.  T&A then determines regular hours, overtime, etc. at the end of each pay period and transfers this into Payroll.  In this day-and-age it should be mandatory that payroll applications have tools that will allow users to manipulate data to and from T&A without cumbersome interfaces.

I could go on and on about the current state of payroll applications, but I don’t have the time.  If you’re involved with your company’s payroll YOU know what the problems are.  It’s time to rise up and demand developers get off their collective tushes!

Thursday, August 16, 2007

Payroll Nightmares

I have recently been ranting about faulty G/L packages.  Now it’s time to turn my attention again to the sorry situation with Payroll packages.  Of all the financial packages Payroll is perhaps where the most improvement is needed. 

Here are some payroll points to ponder:

Can you believe that some payroll packages don’t distinguish the different status classifications that an employee may have?  Magically, they are either Active or Terminated!  What about on L.W.O.P., COBRA, Family Leave, Part-Time, Full-Time Exempt, Full-Time Non-Exempt, etc.?  Without this distinction certain benefits cannot be offered, leave balances may not be computed correctly, pay cannot be correctly computed, and the list goes on.  Without proper status codes the payroll application cannot process employees without manual intervention.

In addition, most payroll applications can’t handle multiple state income tax calculations within the same dataset!  If you are processing payroll for offices that are in different states, the payroll application software and data files will have to be duplicated in another dataset for each different state.  That means separate runs for each occurrence!  Another example is what professional sport teams have to deal with when they play away-games in another state.  Reporting these earnings to state and federal agencies becomes an even bigger nightmare!

Another pain in the backside is the inability to “post date” tax tables and pay rates.  In other words, you need to have the ability to set up new tax tables or a pay rate increase in advance and have it become effective on a given date.  We also need an “obsolescence date” to disable a table or rate when no longer active.

Now you have to remember to make table and rate changes between payrolls.  What happens if you have to re-issue a check that was originally issued with the old rates?  Tax tables and pay rates must be date driven!

Most current payroll applications are so terrible they shouldn’t be on the market.  Frustration with this situation just keeps building because developers don’t care! 

Stay tuned.

Thursday, August 09, 2007

Bean Counters’ Lament!

Most General Ledger applications are worthless as a financial management tool.  They report only historical “dollar” information, usually in a time frame that has nothing to do with your company’s business cycle.  I have alluded to this problem in past rants.  Here are some of the specific problems:

Typical G/L reporting is a P&L, Balance Sheet, and a summary Financial Statement.  This may satisfy the bank, but it does NOTHING for TIMELY information on the efficacy of your company!  What good does it do to sell a lot of Widgets if you are losing money on every one that you sell? 

Dollars alone are not a good measure of performance.  The value of money fluctuates over time, and comparative statistical data is required to evaluate a true picture of performance.  Few, if any, financial packages offer broad statistical information “within” the G/L, and those that do only have limited capabilities.  Every G/L account should have the capability of being supported by at least one statistical account.

Another requirement for an effective financial management tool is flexible reporting periods.  I have ranted on this subject before in, “Can the Buckets.” Does your business cycle revolve around the month-end reporting?  Would a weekly position report be more useful?  How about comparing last week to the same week a year ago?  What about a five-year comparison?  Why lose the detail information after the current year?

To perform effective analysis, interface data from ancillary systems (A/P, A/R, Inventory, and Payroll) must be timely and not tied to a laborious batch process that can only be run on a dictated schedule from the application developer.  This would have to include statistical.  Information will not be timely if it can only be updated on a weekly or monthly schedule.

Most accounting packages don’t provide this capability or even a decent report writer to work with.  Instead, the accounting staff is required to spend an inordinate amount of time preparing spreadsheet reports for management because their antiquated, poorly-designed, piece-of-trash financial package can’t get the job done!  I can’t believe that bean counters aren’t pitching a fit about this!