Simple ways to determine if you are Y2K-ready

Focus on key date changes

You may think your computer and data systems are Y2K-ready — but do you know for sure?

Here are some simple questions developed by the U.S. Small Business Administration to quickly evaluate if your office has been Y2K bug-proofed.

If you cannot answer yes or do not know the answers to all these questions, you may wake up with more than a headache to worry about next New Year’s Day.

- Can the system perform projections through time? For example, can it calculate interest or payments or make inventory projections?

- Does the system allow for entering dates? If yes, is the year two digits or four? What happens if you enter "00" or "01?"

- Will the system operate differently depending on the day of the week? Will it operate differently at month-end, quarter-end, or year-end?

- Can the system put things in order by date?

- Does the system allow you to retrieve data by date?

- Can the system perform date-based calculations?

- Does the system have a security feature that includes date checking?

Here is a list of critical dates that you should take for a test-drive on your computer as soon as possible to see what happens when they appear in the system. For simplicity’s sake, use the ones that best match your business needs and ignore those that are not appropriate.

1. Test the changed system with dates before the year 2000 to ensure that it is working properly.

2. Test that the changed system rolls over from 12/31/1999 to 1/1/2000.

3. Validate the first business day of the year 2000 (1/1/2000, 1/2/2000, or 1/3/2000, depending on your business needs).

4. Validate that the system operates correctly at end-of-month (1/31/2000 and will roll over to 2/1/2000 properly).

5. Test that the system rolls over from 2/28/2000 to 2/29/2000 properly, operates correctly on 2/29/ 2000, and then rolls over and operates properly on 3/1/2000.

6. Test 3/31/2000 and 4/1/2000 to show that end-of-quarter processing operates correctly.

7. Test 1/7/2000 and 1/10/2000 to ensure that the system operates correctly on the first Friday of the new century, and on the Monday after the first Friday.

8. Validate year display fields, including data entry.

9. Validate the year in reports.

10. Test that the system sorts in correct order.

11. Validate correct calculation of dates.

12. Validate the correct acceptance of dates from the operating systems.

13. Validate calculated resultant values from dates.

14. Test that ages are calculated correctly.

15. Validate interest and other time-based financial calculations.

16. Verify that billing calculations are correct.

17. Validate cycle processing, including day-of-week and/or first business day of the month.

18. Test forward processing — process dates after the year 2000 (2001, 2002, etc.).

19. Validate backward processing — process dates prior to 2000.

20. Verify historical or archival date processing.

21. Validate that the system purges the correct records.

22. Validate date and data error handling routines.

23. Validate windowing, if used, both within the system and between interfacing systems.

24. Validate proper handling of special values in dates — 99/99/9999, 88/88/8888, 00/00/0000.

25. Validate that there are 366 days in the year 2000, and 365 days in the year 2001.

Some additional dates that could have an impact on your business operations:

• 10/01/1999 — start of federal government’s fiscal year 2000.

• 02/15/2000 — W-2 forms due.

• 04/15/2000 — tax day.

• 04/30/2000 — first month ending on a weekend.

• 05/01/2000 — tax withholding report due, unemployment tax due.

• 09/30/2000 — federal government’s end of fiscal year 2000.

• 10/10/2000 — first 6-digit date for systems storing date as MDDYY.

• 12/31/2000 (Sunday) — first year-end; check that the year contains 366 days.

• 01/01/2001 — test that the system has been instructed to roll over to 2001.

• 02/29/2001 — invalid date.

• 12/31/2001 — second year-end; check that the year had 365 days.