Addendum 1 -Tournament Tracking Module

The primary purpose of this module is to allow us to identify events to be held and track the rating reports for all events as they are received and rated. Additionally, minimal financial data will be entered for accounting and financial tracking purposes.

The USCF does not require pre-registration of events. Approximately 1/4 to 1/3 of our organizers advertise their events in Chess Life as Tournament Life Announcements (TLA) and this is normally the first notice we have that a tournament will be held. Tournament Tracking is not computerized at the present time. Although more information may be useful, the following minimum information is needed to track events by the ratings department. It should also provide information for already rated events. The information will be found in or provided by several tables including the TLA, membership, report edit, and crosstable tables.

1. Ending Date (TLA or enter)

2. Received Date (enter)

3. Event Name (TLA or enter)

4. Event State (TLA or enter)

5. TLA (yes/no) (default no unless TLA provides data.)

6. Grand Prix (yes/no) (default no unless TLA exists and is GP event)

7. Entered Date ( date event and section headers created - from edit files)

8. Rated Date (by section, see note #1 below - from edit files)

9. # of Sections (from edit files)

10. Affiliate ID (TLA or edit files)

11. Affiliate Name (look up ID and retrieve from membership files)

12. TD ID (TLA or edit files)

13. TD name. (look up ID and retrieve from membership files)

14. Report Type (p, d, w (paper, disk, web) with default of p (from edit files)

15. Status Code - operator set code to indicate problems outside the office have caused a problem that has delayed the rating of an event. Default is null, codes are I for incomplete report or missing disk, H for help requested from TD, and O for other. Should be a two character field so sub-codes can be created and used

16. Reported Rating Fee (enter)

17. Confirmation requested fee (null or $0.50 - default null) (enter)

18. Reported Crosstable Fee (enter)

19. Reported PHBF Included (enter)

20. Amount paid (enter)

21. TLA ID # (if exists, may be a needed link)

22. Event ID - A unique number assigned by the computer either when a TLA is created or when the log entry is created. Consists of the ending date plus 3 extra digits in the format YYMMDDXXX where the XXX is a sequential number assigned after verifying the event ID has not already been assigned. Note that the Event ID provided on a disk is not kept. A new number is generated internally. In our current system, this number is used as the relational link for the files. This is at programmer discretion.

23. Validation status (from edit files)

When the clerk is in the log update mode, the normally selected filter will be to display only events not yet completely rated and removed from the edit files. However, sometimes the clerk will want to verify an event is not a duplicate submission. Provision should be provided to also include events rated or ending over a specified range if desired.

Initial information for items 1, 3, 4, 5, 6, and 10 will be initialized from the TLA files if a TLA was submitted. The TLA program is now being written and information will be provided as soon as available.

The processing of disk and paper reports will differ slightly. Paper and disk reports are both processed on a batch basis by received date. When the clerk selects the Receive and Log Report module, a screen asking for the received date should appear. The entered value from this screen should be used as the default value for field 2. If the operator changes this value while in this module, the changed value will be used as the new default. The clerk will then select entering paper or disk reports.

paper report - The log will be searched for the submitted event. If the event is not found, a new event screen will be opened and items 1, 2, 3, and 4 will be entered by the data entry clerk. An event ID will be generated at this time. Fields 5 and 6 do not need to be viewed and just assigned the default no. For all events, found or not, the clerk will then enter fields 16 through 20. If $0.50 is entered for field 18, the TD ID number must also be requested so a confirmation can be sent. The remaining fields will be taken/updated from the other modules as data is entered or actions occur and should not be displayed in the update screen. The clerk will then process the next report or exit the module.

Disk reports - The data entry and Tracking Log update will be handled as one single procedure if possible. The clerk will select receive disk reports. The received date will be requested. The first disk will then be inserted, checked for viruses, and disinfected if required. The header data will then be read off the disk. The log will be searched using the TLA ID# if provided by the disk. If an exact match is not found, the closest match will be displayed in table format filtering the table based on state and sorted by ending date. When trying to decide of an exact match is found when the TLA # is not provided, the Affiliate ID, and State should be an exact match. The name is frequently different and occasional ending date errors also exist. If an exact match is not found, the clerk will then search the log and either select an existing entry or select append new entry. Based on electronic submission format, all log information needed will be read off the disk and the fields updated. The entered data will be reviewed by the clerk and either accepted or modified. The clerk will then either continue logging/entering disks or exit module. The same procedure for changing and using the new value for received date used for paper reports should be programmed.

One problem that causes us trouble is the occasional error in dates on the disk. The program needs to include the ability to modify the ending date if the operator wants. The current program creates the event ID based on the ending date and uses this to append records to the edit file. To change this date, we now have to take the disk, edit the date using dbase III and reenter the disk. We also have to then delete the original event entered under the incorrect ending date. The use of a temporary file or other method to hold the data until after the clerk approves the ending date is requested.

If the disk is either completely or partially unreadable, the clerk needs the ability to search and create an entry so the report can be shown as received and the status set automatically set to "I".

Web Reports - The logging of web submitted reports will work much the same except that the data will already exist in the our files on the web server. When the data is uploaded into our database on the web, the user should be prompted to indicate if a TLA was submitted and provide the TLA ID number so the log can be updated without the clerks need to do his.

Confirmation fee - This is a $0.50 fee a TD can pay to receive a postcard notifying them that the event has been received for rating. Provision should be made to print a postcard addressed to the TD either printed as the report is received or as a batch file at the clerks discretion. The postcard will have the TD's address printed on the front and the Event name, ending date, and received date printed on the back.

Reports:

Except where obviously not required such as screen versions of form letters, reports should be available as output either to screen or hard copy.

Overdue rating reports - a screen or hardcopy display of events considered overdue (not received). The query should use a default of 21 days past event ending date but it should be user modifiable for different periods. This report is for management purposes.

Tournament report status - a screen or hardcopy display of all events by section for management of department work accomplishment. Should display by section as a table. Table should display a summary and user can then select display entire record for a selected event. Should display the following fields for only unrated events (at least one section not rated):

Event ID, Date Received, Date Entered, Validation Code.

The option should be provided to display either actual data or the validation report for a selected event. Sort and filter capability should be provided for user convenience. Normally viewed on screen but a printout of current screen function should be available. Normally this would be done in the edit mode but when someone calls and asks why an event has not been rated, it is very useful to be able to look while in the log module.

Overdue form letter and associated report - A form letter to the affiliate of an event notifying them that the rating report for a scheduled event has not been received. User will specify the # of days overdue and a default value of 21 days will be used. A log of letters sent will be kept and provision for follow-up letters made. A management report listing who was contacted and the date(s) contacted for missing reports should also be available. This may be duplicated in or replaced by the TD maintenance module. An option should be provided to send to either affiliate or CTD but default should be CTD as first choice unless invalid or null.

Contact and tracking:

It often happens that we have to contact a TD or organizer if an event has not been received or if there is some sort of problem with the event. As part of the tracking module, the contacts need to be logged and retrievable. They also have to be associated with given events. When looking at an event that has not been rated, we need to know that specific people have been contacted and why. When mail is used as the method of contact, the program should provide a variety of form letters and automatic retrieval of address information for the letters. Please see addendum 6 for one method of logging contact information.