05 earp refiling transaction data review
EARP - Refiling Transaction Data Review
| Program IDs: | EARPP01, EARPP02 |
|---|---|
| Mapsets: | EARPMS1, EARPMS2 |
| Input File: | Lookup File (ES2LKUP), Micro File (ES2MIC) |
| I/O Files: | Refiling Transactions File (EARRTRN), Refiling Master File (EARREF) |
This transaction parallels the actions of the EXPO ES2P transaction, but uses the Refiling Transaction File instead of the Administrative, MOA, and Quarterly Transaction Files, referencing updates to refiling data rather than micro data. There are two mapsets involved in the process, each of which is regulated by a controlling program.
The first screen (shown above) is a menu of transactions, essentially providing only a table of contents, showing the transaction type code ("A" for add, "C" for change, or "D" for a record deletion), the SESA ID, date and time of the transaction, and the composite user ID. This ID will show the CICS logon ID of the person making the change, plus a two-byte code showing which screen the individual used to apply the change. Usually these will be "RC" for the EARC transaction, or "RR" for EARR updates. When the changes have taken place through batch updates, however, the full program ID will appear instead. An "EARRF02" value in the USER-ID notes that the change took place in that program, which is called within Job 102D. Similarly, an "EARRF21" is called by Job 121D, etc.
One source of batch updates is not included in the Refiling Transaction records. The Input Refiling Transaction (IRT) records, processed by the 101D job, do not generate Refiling Transaction records. This parallels the IMT updates on the EXPO micro side, which also will produce few transactions (except for additions, dates and status changes) in the Administrative or Quarterly Transaction Files. The assumption in IRT processing would be that other sources would be used for replicating the updates as needed; so they are not tracked for audit trails, etc.
The screen layout differs slightly from the ES2P format, since four-digit (rather than two-digit) years are used everywhere except for the date-range prompts. The default date range, which shows up as '00' to '99' in the year, is actually using 2000 to 2099. To narrow the range, enter the beginning and/or ending date desired for the date range. The century is set to '20', since it is not possible for any transactions to have occurred before 2000. Similarly, there won't be any transactions in 2100 or beyond until long after this software been replaced by the QUEST system.
When an account number is entered into the "ACCT:" field, the menu display will start with that account, or the next one available thereafter. Specifying a CICS log-on ID in the "USER:" field will screen out all other individuals and batch programs, showing only the Refiling Transactions attributed to the designated individual. This entry matches use only the first six characters of the user ID, so it will accept all CICS transactions for the person's entries. An entry of "YBUABC" would recover the "YBUABCRC" and "YBUABCRR" transactions, since they all were entered by the same person.
To select a particular transaction for detailed viewing, tab to the hyphen that immediately precedes the record in question and press the Enter key. This transfers to the detail screen (which appears above). Unlike the ES2P screens, which closely mimic the format of each of the ES2C detail screens, refiling transaction data are quite limited in scope. Everything can appear on a single screen, including the before-change and after-change fields. As with ES2P, however, the changed fields appear in red, making it easy to spot the differences between the two halves of the screen. An "add" or "delete" transaction will only show fields in the "before" image (left-hand) side, except for the legal name on the top, which is drawn from the Micro File (as is the trade name to its left). As with EARC, micro data elements are shown with underscores; however, since the display is somewhat compressed to target the changes, there are very few micro-data fields displayed.
The red-highlighted fields shown above reveal both the before-and-after-change values on a single screen. For this sample account, both the "old" (pre-refiling) and "new" (post-refiling) NAICS codes were changed, as was the response code (from 00 to 41 (a non-change of codes response code)). Even though the updated-date and "updater" ID codes often change, they are not listed in red, since these changes don't affect the refiling-related field changes that are the emphasis of this screen. However, the "ID:" field will not be altered by a batch-based record change (such as "EARRF02"). The side-by-side listing allows a quick review of the changes, without requiring any additional function key usage to toggle between before-and-after-image values.
The only updateable field on this screen is the SESA ID (next to the "ACCT-NO:" prompt in the second line from the bottom). As with the menu screen, the entry of a SESA ID in this account number and reporting unit area will switch to that account or the next one thereafter. If there are multiple changes for the same establishment, the first one will be selected. However, once the Enter key has been pressed with the new account number in place, control will revert to the EARP menu screen, as though the F6 key was struck.
Speaking of the function keys, the F6 key is the normal method for returning to the transaction history menu. Normally, this will carry the last displayed transaction identifier to the top of the screen, with subsequent entries following it. Should the latest displayed account be near the end of the Refiling Transaction File, however, the display menu display will be reoriented so that the last record on file will appear at the bottom of the screen. The F1 (menu), F3 (exit/end), F7 (previous record), and F8 (next record) functions are the same as with most other CICS screens.
The F9 key is available to restore the contents of one of the Refiling Transaction records to the Refiling File. For an "add" or "delete" transaction, the content to restore is unambiguous, but the "change" transactions could be debated in terms of which side is to be restored. However, since the general intent of a restore function is to "undo" a change, the convention used in EXPO and EARS is to retrieve the before-change image as the restored value. No confirmation is required to restore a refiling record, however. Once the F9 key is pressed, the confirmation message, "****RESTORE OF REFILING RECORD SUCCEEDED ****" will be displayed. Should it be discovered that this restore was not desirable, the previous contents can be brought back, since EARP writes its own transaction (with before-and-after-change values), which can be drawn upon with the F9 key once more.
Unlike the three transaction files used on the EXPO side, the Refiling Transaction File does not get pruned each quarter. There is no job to purge records older than a specified date either, as there is with EXPO's Job 005D. Instead, the entire file contents are removed with the creation of the new fiscal year's Refiling File in Job 100A (which is generally run in the early part of October each year). Although this means that there is almost an entire year's accumulation of transactions, it is most likely that file size will not become a significant problem for refiling processing. It becomes more effective and informative to have the entire year's refiling changes available at once. Should it ever be necessary to produce an audit trail report, either for a date range or for a specific user, Job 116D can be run to produce this report. The parameters are entered on the EARN screen.
Related Links
