What’s New In Version 3 of the Roundtable Software Advantage Accounting System

PROBLEM  The most visible problem with Armor’s version 2.5 is that none of the ranges on reports, updates, purges, etc. have been updated. Their default values are still 00/00/00 through 12/31/99. Once we get into the year 2000 you would have to manually key in a proper ending date. If you occasionally forget to do this you will likely throw off your accounting.

SOLUTION  A simple problem with a simple solution. Roundtable Software’s version 3.0 has proper ranges that take into account Y2K—00/00/00 through 12.31.99 (2099).
 

PROBLEM  Armor’s version 2.5 did not address the fact that it is very inconvenient, and likely fraught with problems, for your accounting personnel to remember that 2000+ dates must be entered with periods rather than slashes (for example, January 21, 2000 should be entered as 01.21.00). What may seem like a minor inconvenience can easily blow up into a major problem. For instance, typing 01/21/00 as a GL posting date or AR invoice date can cause some major headaches.

SOLUTION  We at Roundtable Software have put a lot of thought into this problem and have come to the conclusion that there really is no truly ideal answer. The approach we are taking, however, will minimize the problem as much as possible. Our solution allows you to ‘switch’ the meaning of the slash and period whenever you like. Thus, once you arrive at January 1, 2000 (or any date of your choosing), you can tell the system to swap the meanings of the two date separators. In other words, once you ‘flip the switch’, the Roundtable Software Advantage Accounting System will recognize dates with slashes as being in the 21st century and dates with periods as being from the 20th century. This is not an ‘all or nothing’ switch--you can switch it now and give it a test run, then switch back for the remainder of 1999 and switch again in 2000, if you like.
 

PROBLEM  We’ve saved the worst for last. There has been a bug in the Armor Advantage Supreme Accounting System (and all earlier Armor packages, for that matter) for many years. The original programmers at Armor thought that the year 2000 was not a leap year when in fact it is. When those programmers wrote the code to handle dates they thought the next day after February 28, 2000 was March 1st. This may seem like a minor problem, and it was until Armor tried to fix it in their version 2.5 upgrade. Their fix for the problem is to treat February 29, 2000 as a special date. There is now special code in the Armor version of the software devoted to handling that one single date unlike any other dates in the system. Unfortunately this special code doesn’t work correctly and creates some major problems.

To explain further we have to get a bit technical. Armor stores dates not in their normal form but as a number that equals the number of days since January 1, 1900. Thus 1/1/1900 is stored as 1, 1/2/1900 is 2 and so on. Before Armor’s version 2.5, the year 2000 leap year problem manifested itself this way:
 

	DATE	ARMOR STORES AS
	2/28/2000	36,583
	2/29/2000	36,584
	3/1/2000	36,584
	3/2/2000	36,585

As you can see, Armor could see no difference between 2/29/2000 and 3/1/2000. If you haven’t purchased Armor's latest update yet you can easily see this in Armor by typing 02.29.00 at a date prompt—the system will automatically change it to 03.01.00.

Armor’s version 2.5 tries to address this problem by assigning 2/29/2000 a ‘special’ number. Now Armor stores dates as follows:
 

	DATE	ARMOR STORES AS
	2/28/2000	36,583
	2/29/2000	80,060
	3/1/2000	36,584
	3/2/2000	36,585

This is bad in so many ways it’s hard to know where to start, but here’s an incomplete list:

• Anything dated 2/29/2000 will never print on reports with date ranges (it falls outside of the range of allowable dates)

 
• Anything dated 2/29/2000 will never update, purge or clear (same reason)

 
• General Ledger would not update properly when any transactions are dated 2/29/2000 or if a period spans that date

 
• When any date arithmetic is performed (such as pay period dates, due and discount dates, etc.) if the dates include 2/29/00 the calculations will be incorrect.

 
• Any report that sorts by date will put transactions dated 2/29/2000 as the last thing on the report (unless there is a date range in which case they’ll never print at all)

 
• The File Maintenance and File Fixer modules both think 2/29/2000 is a bad date and ‘fix’ it to be 00/00/1900.

SOLUTION  Roundtable Software has implemented a solution for the problem that involves no jury–rigging, no special code and no special handling of 2/29/2000. This solution is simple and avoids all possible problems with date ranges, sorts and all the rest. Not only that, but version 3.0 will even automatically handle any ‘special’ dates that may have already gotten into your files from Armor’s Y2K release. We’d tell you more about our elegant and simple solution, but you can understand that we don’t really want to pass it along for others to try to duplicate.
 
 

Roundtable Software Home | Add-On Products | Custom Programming | Support Services | Power Utilities | Partners | What's New| Site Map

		Roundtable Software • 30831 Cove Road • Tavares, FL 32778-5164 (352) 253-9779 • FAX: (815) 572-5446 All contents copyright © 2000-2008 Roundtable Software. All rights reserved.