Many accounting packages still suffer from the Year 2000 problem, according to a systems consultant's survey at Windows World earlier this month
IF you're an accountant, you should have heard of the "Year 2000" problem by now. But many ordinary accountancy packages for PCs currently on sale in Ireland still suffer from the problem, according to a straw poll at a recent computer show.
But first a bit of background. The Year 2000 problem (also dubbed "Y2K" or the "millennium bug") is the unexpected and unfortunate byproduct of software that lasted too long.
It was created by the programmers of yesteryear, who reckoned that instead of saving all four digits of a year, using just the final two digits of a year would cut down on storage space.
The technique was enormously cost effective at the time. According to a Wall Street Journal article earlier this month, boiling years down to just two digits saved the typical organisation over $1 million per gigabyte of total storage in the 30 year period from 1963-1992. If that money had been wisely invested, it says, the savings could have yielded $15 million per gigabyte over the period!
So the two digit system worked fine in the past, but now we have to live with its consequences. The end of this century is now only 949 days away, and after December 31st, 1999, the "99" in the two digit date will go back to zero, and the software "clocks" will register the year 1900 instead of the year 2000.
The problem obviously affects much software from the earlier age of mainframe computers. But what about modem software the everyday accounting packages currently on sale for today's PCs? Surprisingly, many of them are not "Year 2000 compliant" - they still have the two digit problem.
Systems consultant Patrick O'Beirne conducted a quick test of nine "everyday" accounting packages at the Windows World Show in the RDS in Dublin earlier this month. All the vendors claimed "Year 2000 compliance when first asked, but while two thirds of the titles passed the first test and allowed 2000 date entry, only three of the packages were then able to demonstrate correct printed reports.
The test
The test was: "Enter three Sales Orders for today's date with required delivery dates of 31/12/1999, 01/01/2000 and 29/02/2000."
To get slightly technical for a moment, Patrick O'Beirne says: "This is testing a non key value, in order to get around the usual validations that transactions cannot be entered so far ahead of time. I am not changing the system date, as that could upset any Windows 95 agents they might have running, such as Norton or time organisers. Obviously, that would be part of a complete test they could simulate in their offices, away from the pressures of a show environment."
The results
The following were the results:
Access Accounting: "accepted the dates fine, demonstrator could not find a report on delivery dates. Regrettably, I didn't have time to get back to them." The product is marketed as "Guaranteed Year 2000 compliant".
Exact Accounts: accepts only two digit dates.
Great Plains Dynamics: accepts all four digits when the international date formal is set to "dd/MM/yyyy", and reported correctly. "Microsoft don't provide a four-y format in the Control panel, so the demonstrator had to type it in."
Kernel Software: Foxpro based product. In its two digit year format, it accepted "00" as a year - but interpreted it as 1900, and subsequently rejected this "29/02/00" as an invalid date.
The producers would not change the software on display, but said all systems shipped to clients would have "SET CENTURY ON", which allows Fox to accept and display four digit years."
Pegasus Opera: "I missed (their) stand. I have seen version 2.04 which uses two digit dates only, and it is a Foxpro product. You can set CENTURY=ON in the CONFIG.FP if you like, and that accepts 2000 dates OK, but some displays and all printed dates show `31/12/19' or `29/02/20', i.e. they truncate the 10 digit date display `31/12/1999' to 8, losing the last two digits of the year."
Sage Accounts 4.00: accepted the dates, but the final report showed the year 2000 dates as "01/01/100" and "29/02/100". "Close, but no cigar, as they say.
Scala: wouldn't give a demonstration, but "we can give a demo in your offices if you wish".
Sybiz Vision: accepts all dates, reports fine. "Shows date as `01/01/0', i.e. a leading space in the year. Not a problem for me."
Take Five: passed all tests. "The demonstrator said she had not been asked to do this before."
In summary, then, fewer than half the products passed both tests. And this doesn't even take account of another looming issue: the question of how software copes with the transition to the euro in 1999-2002.
But that (as they say) is another day's work.