05 edit reconciliation notes
Edit Reconciliation Notes
As changes are made within ES2E, or when records are bypassed (or “skipped”, mentioned previously and described in more detail later), the person making the change is noted in the last-update fields (date (“LAST UPDATE:”) and user-ID (“BY”)). This uses the analyst’s CICS logon ID to specify who is making the corrections. Such identification can be helpful for documentation, so that a supervisor can ensure accurate work by the junior analysts. Another distinct advantage occurs in the division of workload. States will have various methods of dividing the work of micro edit review among the available employees. Not all of these will have clear and distinct boundaries (such as a range of counties or industry codes). It is therefore possible, especially in a strictly on-line editing environment (where no edit reports are printed) that the reviewers could pass from their own work into the next person’s, potentially duplicating efforts. By noting the presence of updating user identification, however, it can quickly become clear when the boundary has been passed.
Prior to displaying the record on the screen, the micro edits are conducted on-line. As micro data fields are changed, some or all of the edit conditions will no longer be a problem (though others may appear due to miskeyed entries as well). Here is an example of how edits can be quickly reconciled. Below is a portion of the original sample record display. The problem here is that the employment and wage fields were entered incorrectly; the first and second months of employment (11 and 10, respectively) were fused together, shifting the remaining fields to the left. The third month’s employment (16) appears as the second month, total wages ($20,188) appear as the third month employment, the $16,757 taxable wages appear instead as the total wages, and the contributions were placed in the taxable wages. Then the system used the tax rate to calculate the contribution amount from the $209 supposed taxable wages:
The most outlandish change from this shift is the wages-to-employment switch. With an indicated leap of over 20,000 in employment, the magnitude of the error is considered quite outlandish (with a score of about 30 – the significance of score values will be discussed later). In addition to these employment and wage errors, there were also two erroneous code changes present. By re-entering the employment and wage data into the appropriate fields, and by reversing the erroneous code changes, the rerun edits can find that all of the previously listed edit conditions no longer exist. When that happens, the Micro Edit File record is deleted, and the message “All Errors have been Reconciled” appears in the message field in the lower, left-hand portion of the screen. At the same time, all of the fields turn to turquoise color, since they are no longer updateable (once the edits are resolved). Finally, the bookmark is removed at this point, since there is no longer an edit record for the bookmark to reference. The screen image below shows what that reconciled condition looks like. At this point, the record is removed from the Micro Edit File, and processing can continue with the next record, as soon as either the F8 key is pressed to advance.
Due to screen space limitations, not all error codes will necessarily be displayed in the “ERROR CODES” block. Up to ten administrative codes can be flagged for an establishment and up to eight error codes can be assigned for each of the two quarters (current and prior). The first five codes from each grouping are listed. On the other hand, all fields that are related to an edit exception’s flagging are highlighted, by being colored red, even if that particular error code cannot fit on the screen. It should be noted, however, that the condition is very rare that the error code would be in the second five of last three codes for an account.
As micro fields are modified to remove error codes, other codes may appear in their place. The cursor is positioned at the first red-flagged field for user examination and correction. If the red coloring and error code numbers are not enough to let the user recognize what the problem is, an error description can be displayed by moving the cursor to the error code field in question and pressing Enter. The pointing action can either be performed with the arrow keys of the keyboard, or with a mouse click; the error codes are non-updateable fields, so they cannot be tabbed to directly. The verbal description appears in the message field in the lower, left-hand area of the screen. Other fields can receive description displays as well. Clicking on a county code, a NAICS or NAICS12 code, or a comment code will send its description to the message line near the bottom of the screen.
Because there are few restrictions on what kinds of data can be entered on the “E” screen (since edits are conducted and displayed immediately), there can be some severe conditions entered accidentally. If the analyst were to skip on to the next account without scrutinizing the entries, the data may continue on through all the way to the EQUI. To help curtail some of the extreme entry possibilities, there is a confirm-entry operation present for very large changes to the employment and total wage fields (complying with BLS standards for these entry changes). This verification step is the same as that found on the ES2C screen. Like ES2C, the F2 key is used as the confirming keystroke. This could seem confusing, since we also use this key for the “bypass” function; however, it carries a similar function, permitting the entered data to be accepted by the system. Please note, though, that the F2 key is specifically requested by the program for the large employment/wage shift. So it will not bypass the record, but only permit the current change to remain.
Name and address information on the screen is error-dependent. The name fields are not flagged as erroneous unless both are blank. However, the selection of the name field depends on which names are present. If the trade (DBA) name is available, it is used as the first choice; otherwise the legal name will be displayed. That means that if the no-name-present error exists, the legal name appears to be the prime suspect. Only one address block is displayed. This too depends upon the errors present. The priority scheme uses the following order: erroneous physical location address; erroneous mailing/other address; erroneous U-I tax address; clean physical location address (worksites and singles). Masters will use a clean mailing/other address instead of the P/L address. If this is unavailable, the last resort for the master account is a clean U-I tax address. The type of address is displayed in yellow in the label preceding the first street address line. If the MOA or U-I address is used, the address type code is also included within the address block.
Three narrative lines are displayed and updateable. These are the perennial narrative note, the current quarter narrative comment and the prior quarter narrative comment. As with all narratives, they are stored, added, or modified in the Narrative Comment File. Three sections of error codes are present in the Micro Edit record. They are listed along the right-hand side of the screen, so that current quarter and prior quarter edit exceptions align with the current and prior quarter codes to the left; this leaves the administrative edits listed last, aligned with the refiling fields line. When Refiling System code changes have been introduced for the first calendar quarter, but the new codes have not yet been transferred to the Micro File, those changed fields (e.g., the county or NAICS) appear in pink.
A frequently seen type of edit exception is a sudden increase or decrease of employment and wages. These can often be associated with a predecessor/successor transfer, which may or may not be represented in the predecessor/successor account numbers displayed for the edited establishment. If wage record data have been processed into the Predecessor Successor Potential (PSP) File, then the 085 (potential predecessor based on wage record data) and 086 (potential successor based on wage records) codes can point to likely candidates. These are reviewed with the ES2G screen, which serves as an invaluable tool for reconciling such transitions. The PSP File uses employee migration based on inter-quarter wage record totals to depict potential ownership changes of companies. However, the PSP File is not available for all States. If there is a need to transfer to the ES2G screen from ES2E, the quickest way is to type “G” in the next account (‘ACCT:’) field.
Related Links
