Difference between revisions of "05 late refiling entry methods"

© 2019 - State of Utah - Department of Technology Services
Jump to navigation Jump to search
 
m (Text replacement - "[[start" to "[[EXPO_Documentation")
 
(One intermediate revision by one other user not shown)
Line 34: Line 34:
 
* [[05_earf_refiling_file_establishment_list|EARF - Refiling File Establishment List]]
 
* [[05_earf_refiling_file_establishment_list|EARF - Refiling File Establishment List]]
 
* [[05_cics_screens|CICS Screens Table of Contents]]
 
* [[05_cics_screens|CICS Screens Table of Contents]]
* [[start|EXPO/EARS Documentation Home]]
+
* [[EXPO_Documentation|EXPO/EARS Documentation Home]]

Latest revision as of 16:39, 11 July 2019

Late Refiling Entry Methods

The refiling cycle works on an annual basis, beginning in approximately October and wrapping up around August. Nevertheless, some employers will send in their refiling forms late in the cycle, or even after it has “officially” come to an end. There are two basic methods for handling late refiling forms. Which method you use will generally depend upon whether the next refiling cycle has begun.


If the next fiscal year’s Refiling File has not yet been created, you can still use the EARC screen to process the form. Even though you can still enter any code changes directly, it is important for late-reported code changes to be passed on immediately to the Micro File. You cannot be certain that another 013D job (for EARS-to-Micro File data copying) will take place after the refiling cycle is considered closed. To guarantee that code changes will be reflected immediately in micro data, the Lookup File’s “Update Micro Codes from EARS” switch must be set to “Y”. This switch is found in the State-specific constants, which can be updated either from ES2L or EARL. It is listed as item #15 in the list of constants, like the example below:


Earc - 15 - update micro codes from ears.png


If the switch is set to “N”, as in the example above, no code changes will be copied to the Micro File, unless processed by batch (Job 013D or Job 242D). Once the switch has been set correctly, all of the last-minute returned-forms entries can processed on EARC. When refiling forms are returned very late (i.e., after the new refiling cycle has begun through the submission of Job 100A – building the new year’s Refiling File), then the previous year’s late refiling forms need to be processed directly into the Micro File instead. Such updates should be performed on the ES2C screens. Two screens are employed to enact these changes – the “Wage” Screen and the Codes Screen.


The Wage Screen (as described in the ES2C program) is reached from the Front ES2C screen by pressing the F11 key. It shows refiling-related data in the upper right-hand portion of the screen. Normally, new codes could be entered in the “Refiling New-Code” column, highlighted in the sample below (only the refiling portion of the ES2C Wage Screen is shown). After a new year’s Refiling File has been created, however, the new codes must not be entered into the refiling column. Such entries would be sent directly to the next year’s refiling data, which could cause significant problems.


Earc - refiling new code.png


The only fields that should be entered on the ES2C Wage screen are the Verify year, Refile year, and response code. Each of these fields will be stored on the Micro File, so will not interfere with new refiling activities. However, all of the fields are updatable, and can be entered here. Of course, the response code entry will depend upon whether there would be any code changes discovered on the late-returned form. If there are changes, the response code should be set to ‘46’; otherwise, in most cases, the response code will be ‘41’, validating the existing codes. In such cases, these are the only micro entries that need to be made.


When code changes result from the returned form, the Wage Screen entries are only part of the requirements for very late returned forms processing. The other part is to transfer to the ES2C Codes Screen (which is reached from any other 2C screen via the F12 key). Enter any new county, NAICS, township, etc., codes on this screen, beginning with first calendar quarter and working forward from there. Most often, the quarters displayed on ES2C will be third calendar quarter as future, second quarter as current, and first calendar quarter as the prior quarter. Unfortunately, the screen does not assume that any county, NAICS, etc., code change entered in the first calendar quarter (i.e., in the third occurrence) should be copied forward to subsequent quarters. Therefore, you will need to type the same entry in each of the three quarter lines for the affected field.


Transfers to the EXPO side, as already mentioned, are handled by the F4 key. This passes control to the ES2C Front Screen, carrying the current U-I account number in tow. The only return paths to EARS are through the ES2C-EARC connection (using the F4 key again), via the ES2A and EARB menus, and by pressing a “C” in front of an account’s listing in the ES2S alpha locator display screen.


Although it is usually possible to update data on EARC as long as the individual has update-level access granted, this process can be short-circuited by the EARI transaction, which will be described later. EARI controls a switch that enables a complete lock of the Refiling File to on-line updates. Updates enabled by the F10, F11, or F12 key in EARC become inoperative. However, there is one exception. Anyone with administrator-level access (noted in the ES2M screen) can still make updates to EARC fields even when the data are otherwise locked. This circumvention of the locks is necessary in case a late-comer data entry error had been made to refiling data, and a last-minute correction needs to be applied. Sidestepping the lock avoids the companion problem of additional miskeyed entries that could appear if the file were temporarily unlocked.


Related Links