4.7.10. AIMS/ERCS Staff

(1) The A/E staff is an integral part of the ERCS support team. They serve as the liaison between the ERCS users and the SB/SE, LB&I and IT employees responsible for the daily operation and support of the ERCS system. These employees include the Headquarters (HQ) AIMS, ERCS and Summary Exam Time Transmittal System (SETTS) analysts, ERCS system and database administrators and the ERCS development staff.

(2) The A/E staff must be familiar with AIMS and ERCS and have knowledge of controlling examinations in SB/SE, Specialty, and LB&I groups, Planning and Special Programs (PSP), Centralized Case Processing (CCP), and Technical Services (TS).

(1) The A/E manager decides who should perform tasks based upon the employee’s position and grade. Responsibilities of A/E managers include, but are not limited to:

• Assigning duties.

• Monitoring the accuracy of the database.

• Creating, maintaining and generating Tableau reports.

• Distributing 4.1 Statute Tables.

• Approving work input on ERCS by the A/E analysts and assistants.

(2) Responsibilities of A/E analysts include, but are not limited to:

• Adding new ERCS employee records and work schedule profiles (WSP).

• Processing Business Entitlement Access Request System (BEARS) requests and adding ERCS permission records.

• Preparing procedural guidelines and job aids.

• Providing formal and informal training.

• Advising of ERCS and AIMS program changes and downtime.

• Assisting with ERCS login, password and printer issues.

• Aiding in the installation of new ERCS session files.

• Elevating unresolved issues to the HQ ERCS analysts.

• Maintaining and monitoring the accuracy of the database.

• Maintaining the ERCS Address Table.

• Updating local files.

• Reviewing audit trails.

• Assisting with reorganizations.

• Conducting face-to-face or virtual operational reviews.

• Conducting assistance visits.

• Monitoring for timely input of time charges by the end of the SETTS cycle.

• Processing SETTS each cycle.

• Conducting the annual 100% Inventory Validation.

• Processing ERCS to AIMS uploads.

• Processing ESTAB and Special Search requests.

• Requesting and monitoring database transfers.

• Creating, maintaining and generating Tableau reports.

• Generating 4.0 Statute Tables for PSP, CCP and TS through the Statistical Sampling Inventory Validation Listing (SSIVL) database.

• Distributing 4.1 and 4.0 Statute Tables.

• Mentoring A/E assistants and new A/E analysts.

(3) Responsibilities of A/E assistants include, but are not limited to:

• Adding new ERCS employee records and WSPs.

• Processing ERCS to AIMS uploads.

• Processing ESTAB and Special Search requests.

• Generating the 4.0 Statute Tables for PSP, CCP and TS through SSIVL.

• Distributing 4.1 and 4.0 Statute Tables.

• Assisting new users.

• Generating Tableau reports.

• Maintaining and monitoring the accuracy of the database.

• Assisting in preparation for Operational Reviews and Assistance Visits.

• Accompanying A/E analysts on face-to-face Operational Review and Assistance Visits.

• Providing support and assistance to the A/E analysts.

(1) ERCS creates audit trails for selected changes to returns, employee records, and permission records. A special audit trail is also created when users enter a taxpayer identification number (TIN) or a taxpayer name on ERCS. See IRM 4.7.2, Security, for more information. IRM 4.7.2.3.4, Audit Trails, has a list of the changes in ERCS that produce an audit trail.

(2) There are security checks within ERCS to ensure unauthorized users do not access programs and authorized users are kept within the boundaries of their permissions. These checks are performed automatically and silently each time a user attempts to access ERCS. The user has no ability to prevent the checks. For more information about permissions in ERCS, see IRM 4.7.2.3.2, Permissions.

(1) See Exhibit 4.7.10-1, Acronyms and Definitions, for acronyms used in this IRM.

(1) The instructions for the A/E staff for navigating and support of the ERCS programs can be found in the ERCS Technical Reference Manual (TRM).

(2) In additional to this section, the ERCS IRM includes the following sections:

• IRM 4.7.1, Overview

• IRM 4.7.2, Security

• IRM 4.7.3, Statute of Limitations

• IRM 4.7.4, Planning and Special Programs (PSP)

• IRM 4.7.5, Group and Territory

• IRM 4.7.6, Reports

• IRM 4.7.7, Technical Services

• IRM 4.7.8, Centralized Case Processing

(3) The A/E staff should also be familiar with the:

• IRM 4.4, AIMS Processing.

• IRM 4.9, Examination Technical Time Reporting System.

(4) The ERCS book in the Virtual Library contains helpful information to resolve problems and answer questions. The following types of information is available:

• Manual and Handbooks - this section contains the ERCS user handbooks and the ERCS TRM. The manuals describe the menu options, screens, reports and other relevant information.

• Troubleshooting - this section has information on current issues such as installing the ERCS session file and the Invalid SEID error message.

• Contacts - this section contains contact information for AIMS/ERCS Staff, Area and Campus Programs, Employee Group Codes, LB&I Contacts, and other helpful contact information.

(1) This request type is for an employee who may or may not have an active ERCS employee record, but does not have user access.

(2) Verify the application being requested is the correct application for the employee. If incorrect, deny the request and indicate the reason for the denial and the correct application, if known, in the comments box.

(3) Ensure the following information is included in the Special Instructions box of the request:

• The employee’s position, and for shared support associates, the business unit they belong to if outside of SB/SE Exam or LB&I Exam.

• The business reason the user needs access to ERCS. The business reason should include the tasks being performed in ERCS and if permissions are being requested across Areas.

• The AAC or AACs the user needs permissions for.

• Permission records needed - read, write, first level approval or second level approval.

• User Type - Group, PSP, CCP, Review, Territory, Sample Review, Direct of Field Operations (DFO), Area, Limited or Admin.

• Length of Access - The user should state if permanent access is needed. If only temporary access is needed start and ending dates of the assignment must be included.

Note: Users who require AMSOC disposal codes must list the disposal codes needed in the BEARS request. These users are typically PSP and LB&I support staff and A/E staff who are responsible for non-examined closures or out of Area transfers. Additional information on disposal code permissions can be found in IRM 4.7.2.3.2.1, Recommended Permissions.

(4) A BEARS request should be denied if the business reason does not justify having ERCS access. If the ERCS approver doubts whether a user's access is justified, the HQ ERCS analysts should be consulted.

(5) If required information is not included the ERCS approver has the option to deny the request. Comments must be entered to indicate required information was not provided and advise the employee to submit a new BEARS request with the required information.

(6) Alternatively, if required information is not included the ERCS approver may choose to enter comments indicating the employee or employee’s manager is being contacted for required information to complete processing.

• Send an email to the employee or employee’s manager to get the required information.

• Once the requested information is received the ERCS approver must enter the information in BEARS Comments box.

• If the required information cannot be timely obtained from the employee or the employee’s manager, generally within three business days, the request should be denied. Comments must be entered to indicate required information was not provided and advise employee to submit a new BEARS request with the required information.

(7) If required information is included in the Special Instructions box or once the information has been received and entered in the Comments box, the ERCS approver must check the ERCS employee history by SEID to see if the employee already has an ERCS employee record.

• If the employee has an inactive employee record the ERCS approver will coordinate with the employee’s manager to reactivate the record to reflect the current AAC and effective date, additional fields will be updated by the user’s group.

• If the inactive employee record is in another Area, after coordinating with the employee’s manager, the ERCS approver will contact the A/E staff in that Area to have the record reactivated and transferred.

(8) If the employee does not have an ERCS employee record one needs to be created, along with a WSP for technical employees, before access can be granted. For instructions on creating employee records and WSPs refer to IRM 4.7.5, Group and Territory.

• If the user is in SB/SE or LB&I exam, the group must create the employee record.

• If the user is a shared support associate from Collections the ERCS approver will need to create the employee record under the PSP AAC XXX-87700-XXXX. It is recommended that Employee Group Code (EGC) 1805 be used to setup all employee records for shared support associates from outside of Examination, including Collections and TE/GE.

• If the user is a shared support associate from TE/GE the ERCS approver must contact the employee or employee’s manager to obtain the employee’s SSN. A secure email with the employee’s SSN and SEID must be sent to the HQ ERCS analysts to add the employee to the ERCS SEID table. Once the employee is added the ERCS approver will need to create the employee record under the PSP AAC XXX-87700-XXXX.

(9) Once the employee has an active employee record the ERCS approver must enter the user’s login in the login field prior to adding permission records.

(10) Permission records should be added before the BEARS request is approved.

(1) Permissions records may be added, updated or deleted for any Area or LB&I as long as the ERCS approver has Admin permission for the Primary Business Code (PBC) of the employee’s permission record.

(2) Permission records are added and removed through the "Utilities/Permission Programs" menu option "Add Users".

(3) All users are given permanent read permission for their home group AAC, including those requesting temporary access. An employee with an active BEARS application must have a permission record on ERCS. When access is no longer needed users must submit a "Remove Access" BEARS request to have their permission records removed.

(4) In general, administrative support employees are given write permission, managers are given first level approval permission and territory managers (TM) are given second level approval permission. Managers may be given write permission, temporary is preferable, with TM approval. Additional information can be found in IRM 4.7.2.3.2.1, Recommended Permissions.

(5) The user type determines the menu options available to the user, therefore, it is important that permission records are added under the correct user type. The user types available are listed below.

(6) Following the guidance in IRM 4.7.2.3.2.1, Recommended Permissions, and the information from the Special Instructions and/or Comments box of the BEARS request, add, update or remove permission records under all applicable user types. All permission records must be deleted when processing a "Remove Access" BEARS request or Manual Interaction.

(7) Once all actions are complete approve the BEARS request.

(1) This request type is for an employee who has an active ERCS employee record and user access, but needs to change permission records.

(2) Ensure the following information is included in the request:

• The employee’s position.

• The business reason a change is needed in permission records, include the tasks being performed in ERCS.

• The AAC or AACs the user needs added or removed.

• Permission records needed to be added or removed - read, write, first level approval or second level approval.

• User Type - Group, PSP, CCP, Review, Territory, Sample Review, DFO, Area, Limited or Admin.

• Length of Access - On a Modify Access request, if the user only needs temporary access, not to exceed 180 days, the end date should be noted in the Special Instructions box on the BEARS request.

(3) If required information is not included in the BEARS request follow the procedures in IRM 4.7.10.4.1 (5) or IRM 4.7.10.4.1 (6) to request the information.

(4) Remove permission records that are no longer needed.

(5) Follow the guidance in IRM 4.7.10.4.2, User Permissions Records if new permission records are requested.

(6) Once all actions are complete approve the BEARS request.

(1) This request type is for employees who already have an ERCS employee record and user access, but need to have their user access removed.

(2) Remove Access requests can be submitted by an employee either directly or by the employee’s manager.

(3) Remove Access requests cannot be denied and must be processed.

(4) The ERCS approver should remind the group to inactivate ERCS employee records when an employee transfers to a position outside of ERCS and is not expected to return for a year or more, or to a permanent position.

(5) Remove permission records that are no longer needed.

(6) Once all actions are complete approve the BEARS request.

(1) When an employee’s status is changed to disabled due to a separation event BEARS systemically generates a request for manual interaction.

(2) Security requirements are for separated employees to be removed from IRS systems within three business days.

(3) The BEARS approver must verify the employee’s ERCS employee record has been inactivated and all permission records have been deleted.

(4) Once all ERCS actions are complete mark the BEARS request as "Complete".

(1) The ERCS local files contain information unique to each area. A/E managers and analysts have the ability to control validation of codes such as project codes and action codes used only in their area.

(2) Local files can also be used to alert users of messages like upcoming changes, the end of the reporting cycle, or contact information. These messages appear on the screen prior to the ERCS Main Menu screen.

(3) Once an input has been made to a local file, the change is immediately available for use by the ERCS programs. For this reason, the local files should be updated as soon as changes are known. It is imperative the contents of the files be entered correctly.

(4) The local files are updated via a menu option on the AIMS/ERCS Analyst Menu. In order to make changes to a local file, the user must be proficient in the use of the visual (vi) text editor. New analysts should be trained by experienced A/E analysts in the area. Refer to the vi help document in the National Information folder under the AES Resources folder on the AIMS/ERCS/SETTS SharePoint for basic tips for running the vi text editor. Refer to the Local and National Files chapter of the ERCS TRM for information about the local files. Refer to the Login Menu chapter of the ERCS TRM for information about the menu option to update the local files.

(1) Selected changes made by users on ERCS are sent to AIMS each time the Requisitions and Updates program is run to completion. In order to run this program, the user must have access to the Requisitions and Updates program (ERCS download application) and to the Generalized Integrated Data Retrieval System (IDRS) Interface (GII) server. Both of these accesses are granted through BEARS requests.

(2) Access to the ERCS download application is requested through the "PROD ANALYST AIMS-ERCS STAFF" BEARS application. The Special Instructions box should include the ERCS application being requested and list the PBCs needed.

(3) GII related files are required and must be installed in order to connect to the GII server for processing.

• Windows 10 users will need to download the files from the COE Common Operating Functionality for Enterprise Emulation (COFFEE) Software Ordering Site.

• Search for the Product Name: PP0001

• Select Download on the following product: PP0001- MITS GII EITCRA BCC

• A dialog box should appear at the bottom of the screen with the options, Run, Save, Cancel. Select "Run".

• A window will open indicating that the COFFEE package is being installed, when installation is complete the window will close

(4) Access to the GII server is requested through the PROD USER MEG ERCS (EITCRA GENERALIZED IDRS INTERFACE - MEG) BEARS application, include the applicable PBCs in the Special Instructions box.

(5) The employee must be an active IDRS user before requesting access to the GII server.

(6) A/E staff responsible for running ERCS to AIMS uploads must have the following command codes in their profile, as well as in the employee’s work unit to which they are assigned. If the user does not have a command code that’s included in the uploading file, processing will abort during the initial GII interface.

• AM424

• AMNON

• AMSTU

• AMAXU

• AMSOC

• AMBLK

• AMCLS

(7) There are several steps involved in running the Requisitions and Updates program. In general the steps include running the following options:

1. Create Reports - This option extracts the latest requisitions, updates, short closures and transfers into a file in the format required by IDRS

2. Reset - This option marks all the changes extracted in the last run of Create Reports so they will not be extracted again

3. Send AIMS Upload to IDRS - This option zips the file and transfers it to the GII server

4. Once the file is on the GII server, the user must login to IDRS, go to "View/Select Keyboard Map", select keyboard map "PP0001_idrs_gii" and press <ctrl 0> to launch the GII program. Once completed, the results from the session are zipped

5. Retrieve Results from IDRS - This option brings the zipped file from the GII server back to the ERCS server, unzips the file, and creates results files for each AAC (requisitions and updates) or user (short closures and transfers)

(8) It is highly recommended that the Uploading Program be completed at least twice daily to maintain the accuracy of the AIMS database. During times when more ERCS changes are created, such as reorganizations or mass updates, it is advisable to run it more often to reduce upload processing time.

(9) The local file, "upload_control", is read by the Create Reports program and can be used to block specific command codes from being sent to the GII server. Refer to the Local and National Files chapter of the ERCS TRM for more information about this file.

(10) Refer to the Requisitions and Updates chapter of the ERCS TRM for more information about uploading.

(1) A group may submit a request for an original paper return, ESTAB, to the A/E staff for multiple reasons. Those reasons include but are not limited to:

• The group requested an original paper return when the requisition was input and 60 days has passed without receiving the return or the charge-out was received without the return. The administrative support staff input an AMRET, follow-up return request, and 45 days has passed without receiving the return or the charge-out was received without the return, and the return is still needed.

• The return was received without the Schedule K-1.

• The original paper return is needed for a Fraud case.

(2) To request an original return the group will submit Form 4844 , Request for Terminal Action to the A/E staff following the guidance below.

1. The "Remarks" section must include the reason an original return is needed and the Document Locator Number (DLN) of the return.

2. The requester and manager must both sign the form.

3. A current TXMODA should be included.

4. Also include a copy of the charge-out if received without a return.

(3) When the ESTAB request is received it will be reviewed to verify the type of information associated with the requested DLN. If the DLN is for an electronically filed return or isn’t for a return, the request should be denied and returned to the group. Refer to Chapter 4, Document Locator Number of Document 6209, IRS Processing Codes and Information, for the definition of the DLN.

(4) Once it has been determined that an ESTAB is warranted, the Command Code ESTAB should be input into IDRS. If the request is for a Schedule K-1, include a "Y" in Record Element 20 on the ESTAB request. For more information on the ESTAB command code refer to IRM 2.3.17, Command Code (CC) ESTABD.

(5) If the return has not been received within 30 days of the ESTAB input the group may request a special search be initiated, using Form 2275, Records Request, Charge, and Recharge.

(6) When requesting Form 706, U.S. Estate Tax Return or Form 709, United States Gift (and Generation - Skipping Transfer) Tax Return using Form 2275, include in Section 18, Remarks, "ALL HISTORICAL FILES."

(7) The ESTAB process may be skipped and Form 2275 may be used to expedite the search for the original return if the case meets one of the following criteria:

• Court cases

• Appellate cases

• Prompt audits

• Short statute

(8) The Form 2275 may be submitted by the group or by the A/E staff depending on local procedures.

(1) A database transfer request is initiated when ERCS and/or AIMS control is needed for a return controlled in another Area or Campus.

(2) The group will submit Form 5348, AIMS/ERCS Update, to the A/E staff by email to request the transfer and AMSTUR if the record is in Status Code 90 and needs to be reopened prior to the transfer.

(3) If a request is received for a return in LB&I or a LIN Link, return the request to the group and advise them to follow the procedures on the LB&I AIMS Database/LIN Link Requests page.

(4) If the group has established the return on ERCS but AIMS is in a Campus PBC, 190-194, 295-297 or 299, the following applies.

1. The A/E staff sends the request to the AIMS coordinator at the Campus.

2. If AIMS is in Status Code 90 the AIMS coordinator will input an AMSTUR to reopen AIMS.

3. The AIMS coordinator transfers the AIMS database to one of the Area transfer-in EGCs, 1998 or 2998.

4. Once transferred to the Area the A/E staff will update AIMS to the group AAC in the appropriate status code.

(5) If the request is for a return in another Area, the request is sent to the A/E staff in that Area to coordinate the transfer.

(6) If the request is for a return "claimed" by a group from the local Area Campus, the A/E staff will forward the request to the Campus exam A/E coordinator to transfer the AIMS record to the group. A claimed return may appear on an AAC Difference Report but will drop after the weekly AIMS to ERCS batch processing following the transfer.

(1) SB/SE and LB&I technical employees are required to account for their time in ERCS for each day worked in a cycle. At the end of each reporting cycle the time is extracted from ERCS, validated, and transmitted to the Martinsburg Computing Center (MCC). At MCC, the data goes through a second validation, and is subsequently used in the creation of reports and tables. The term "SETTS" is often used to refer to the entire process from ensuring the time has been input through the receipt of validation results from MCC.

(2) The data sent to MCC is used for planning and monitoring activities by technical employees in SB/SE and LB&I. If the time charges on ERCS are corrected after the data has been transmitted to MCC, the corrections are not sent forward and have no impact on the reports and tables that have already been extracted. Everyone, including the examiner applying time, the administrative support staff inputting or verifying imported time, the manager approving requisitions with time charges, and the A/E personnel extracting the time, plays a vital role in ensuring the SETTS data is accurate and timely.

(3) AIMS/ERCS staff are responsible for monitoring time input for all groups supported, including LB&I and Specialty, and ensuring all time is complete by the last day of the reporting cycle.

(4) At the end of each reporting cycle on the designated day of SETTS transmission, a member of the A/E staff is responsible for:

1. Running "Check Employees with Uncharged Time".

2. Running "Finished for the Month".

3. Creating the SETTS file.

4. Appending employee time charges from the previous cycle.

5. Merging the SETTS file with forms.txt.

6. Validating the data.

7. Correcting validation error.

8. Re-validating the data if corrections were input.

9. Transmitting the data to MCC.

10. Checking the results of the MCC SETTS validation.

11. Completing the steps to correct and retransmit data, if there are MCC validation errors.

(5) Since SETTS cycles can be at four, five, or six week intervals, users may not always be aware when the end of the reporting cycle is near. One way to remind users is by inserting a message in the "Message of the Day" local file, named "motd". The last day of each reporting cycle and the corresponding transmission dates are listed in Document 6036, Examination Division Reporting Codes Booklet.

(6) Managers and administrative support staff should be encouraged to run the ERCS "Check Employees with Uncharged Time" report periodically within each cycle to ensure all time for their employees has been entered no later than the close of business on the last day of the cycle.

(7) The "Check Employees with Uncharged Time" report must be run by the A/E employee running SETTS prior to the creation of the SETTS file. Employees listed on this report with uncharged time for the cycle will be excluded from the SETTS file. If an employee is listed on the report with an In Lieu of Holiday (ILOH) error, it means the employee was not scheduled to work on the holiday and the employee does not have holiday time input on the alternate date the program expected the holiday time to be charged. These errors should be researched to see if holiday time was charged on another day. Errors should be corrected. If this is the only error for the employee on the report, the employee's time will still be included in the SETTS file.

(8) It only takes one day of unreported time or one validation error, either on ERCS or at MCC, to exclude all of the employee's time charges for the cycle. If there is an issue or an error that cannot be resolved by the final MCC validation, it is possible to append the employee's time to the SETTS file the following cycle. There is one exception, time charges from a prior fiscal year cannot be appended, which means time charges missing from September cannot be appended to October. Refer to the SETTS chapter of the ERCS TRM for information about appending time charges from a prior cycle.

(9) "Finished for the Month" should be run prior to the option to "Create the SETTS_FILE". This option saves the validated data from the previous cycle to a file named "valid.YYYYMM" where YYYYMM is the cycle date. The option also removes the "forms.txt" file.

(10) During the process of creating, validating and transmitting the time data, several files are created. It is important to note that corrections are written to intermediate files and only the file created by the validation is transmitted to MCC. The following files are created during the process:

• The SETTS_FILE is created when the "Create the SETTS_FILE" option is run and the user selects the option "Initial Run". If the "Initial Run" option is not chosen, new data is appended to any data already in the file.

• The forms.txt file is created when the option "Merge SETTS_FILE with forms.txt" is run. If the forms.txt file already exists when the option "Merge SETTS_FILE with forms.txt" is run, the data from the SETTS_FILE is appended to any data already in this file. The forms.txt file is deleted when the option "Finished for the Month" is run. Data can be updated in this file when either of the options "Display Error File" or "Edit Forms" is run.

• The error.txt file is created when the "Validate Forms" option is run. Validation errors are written to this file. This is the file displayed when the option "Display Error File" is run. However, when errors are corrected this file is not updated. The user must re-run "Validate Forms" to update this file.

• The valid.txt file is created when the "Validate Forms" option is run. Data for employees with no errors is written to this file. This is the file transmitted to MCC when the option "Transmit Valid SETTS File" is run.

(11) When the option is run to transmit the SETTS file, a copy of the validated SETTS file, "valid.txt", is renamed and placed in a dedicated location on the ERCS server where files are picked up every 15 minutes (e.g. 02:00, 02:15, 02:30, 02:45, etc.). The files are transmitted to MCC where a second validation is run.

(12) The validation times at MCC and the times when the validations results are sent back to the ERCS server are in the table below listed in Eastern Time (ET):

(13) The results file should be checked by running the option "Display/Print Most Recent Validation Results" to verify there are no MCC errors. If errors are present, they must be corrected using the "Edit Forms" option. Once the errors are corrected, the options "Validate Forms" and "Transmit Valid SETTS File" must be re-run.

(14) See the SETTS folder on the AIMS/ERCS/SETTS SharePoint for SETTS training materials for the A/E staff. Refer to the SETTS and National Office SETTS Menu chapters of the ERCS TRM for more information about running the SETTS programs.

(15) An unusual error or an increase in errors during the validation process should be reported to the HQ SETTS and the HQ ERCS analysts. Refer to AIMS, ERCS, SETTS, SSIVL and Tableau - Headquarters for contact information.

(1) The SSIVL program enables a field office or a campus operation to extract AIMS data from the ERCS server and load the data into a Microsoft Access database for further analysis. The data may be used to generate reports of potential errors, Statute Tables 4.0 and to generate Inventory Validation Listings (IVLs) of AIMS data. Use of SSIVL is required to validate AIMS inventory. Refer to IRM 4.4.16, Inventory Control, for more information concerning the responsibilities of the A/E staff in conducting the annual 100% IVL validation.

(2) The SSIVL data can be automatically transferred to an area server via Electronic File Transfer Utility (EFTU) or an A/E staff employee with SSIVL and Secure File Transfer Protocol (SFTP) permissions can run an ERCS menu option to extract data from the ERCS server and transfer it to a local area server.

(3) Access to the ERCS server for SSIVL purposes is granted via a BEARS request. There are several SSIVL applications. Refer to Exhibit 4.7.10-2 for determining which application to select and information to include on the BEARS request. Employees with a business need for SSIVL access should contact their local A/E staff or their Campus AIMS coordinator to get approval prior to completing a BEARS request.

(4) Once approval is granted, the user should follow the instructions on the SSIVL SharePoint on how to download and install the SSIVL Access database (ssivl.mdb) file.

(5) As New SSIVL users are approved and access added, users are added to the Outlook email group "&IT ACIOAD-C-SSIVL COORD". This email distribution group is used to alert users of system downtime, SSIVL issues, and new releases.

(6) Refer to the SSIVL and SSIVL-PC chapters of the ERCS TRM for more information about the program and the available data.

(1) Special programs are available to the A/E analysts to move employee records, employee permission records and inventory records between employees, groups, territories, areas, industries and Business Operating Divisions. There are also programs to reassign returns from one TS employee to another TS employee. The steps for moving a group to another AAC are listed below:

• Coordinate with the A/E staff in all impacted areas

• Coordinate with the group and impacted functions

• Validate the new AAC

• Run inventory reports, employee reports, and permission reports

• Check for returns with updates pending managerial approval

• Check for errors in AIMS to ERCS batch processing or recent uploading rejects

• Resolve issues that would prevent returns from transferring

• Lock out the users (optional)

• Transfer the returns, employees and permissions to the new group

• Run inventory reports, employee reports, and permission reports

• Make the old AAC obsolete

• Unlock the users

• Alert the group the transfer is complete

• Run the ERCS to AIMS uploading programs

(2) The Group Transfer - All Returns option allows the user to transfer returns from one group to another within the same Area or Practice Area. The user is prompted with the following questions:

• "Transfer returns from old AAC to new AAC?" If entries are correct answer "Y".

• "Do you want to update these address records with the new AAC?" The number of temporary and permanent address records for the old AAC is displayed, answer "N" .

• "Include returns closed from group?" This question is referring to returns in PSP suspense, TS and CCP. If the old AAC will no longer be in use after the reorganization, the user should answer "Y". If PSP, TS, or CCP sends a case back to the group, this will prevent returns being sent back to an obsolete AAC.

• "Include returns closed from group" and "Include Status 90 returns?" Including closed returns, both closed from the group of Status Code 90, will ensure if CCP returns the case to the group or the case is reopened it will go to the correct group where the examiner who worked the return is located, users should answer "Y" to both questions.

(3) The Group Transfer - One Employee option is run to transfer one employee's inventory to another group within the same Area or Practice Area. The user is prompted with the following questions:

• "Include returns closed from the group if status is less than 80?" The user should answer “Y” to this question. Including returns closed from the group will ensure if CCP returns the case to the group it will go to the correct group where the examiner who worked the return is located.

• "Transfer Time Applied records (TAPP) for employee?" The user should answer "N" to this question. Time records should match the employee’s AAC and not the return’s AAC. This program should not be used to move TAPP records. "Transfer Employees to Another AAC" should be used to move time charges, this will keep the employee record and time charge records in sync.

(4) The Transfer Returns to Another PBC option is run to transfer returns to another Area or Practice Area. The PBC Transfer Listing should be generated prior to transferring the returns. The listing includes issues that may cause the transfer to be blocked on ERCS or may cause the AMSOC to reject on IDRS. Many of these issues can be worked prior to the transfer. The user is given the following options when transferring returns to another PBC:

• Whether to include returns in PSP suspense, TS, or CCP

• Whether to transfer all the eligible returns or to select returns to be transferred one at a time

(5) For information about locking users out of the system, see the Login Menu chapter of the ERCS TRM. For more information about running the transfer programs, see the Utility Reorganization Programs chapter of the ERCS TRM.

(6) Documents with detailed instructions for reorganizations across PBCs and within the Area are located in the National Information folder under the AES Resources folder on the AIMS/ERCS/SETTS SharePoint site.

(1) Tableau is a server application used to create views, workbooks and dashboards from information in the ERCS database.

(2) To gain access to Tableau two BEARS applications are required, one to access the Tableau server and one to access ERCS data through the Tableau server.

(3) There are two BEARS applications for the ERCS database, one for SB/SE employees and one for LB&I employees.

• ERCS TABLEAU SBSE (ERCS TABLEAU DATABASE ACCESS ONLY)

• ERCS TABLEAU LBI (ERCS TABLEAU DATABASE ACCESS ONLY)

(4) When requesting access to the ERCS database the BEARS request must include the employee’s position, the business reason access is needed and the PBCs the user needs access to.

(5) There are two BEARS applications for the Tableau server, only one is to be submitted based upon your user type.

• Regular users run reports from workbooks created by other users. Regular users will submit a BEARS request for "PROD USER ERCS TEV (TABLEAU ENTERPRISE VISUALIZATION-ERCS TEV)".

• Elevated users create and modify workbooks, but can also run reports created by other users. Elevated users will submit a BEARS request for "PROD ELEV ERCS TEV (TABLEAU ENTERPRISE VISUALIZATION-ERCS TEV)".

(6) When requesting access to the Tableau server the BEARS request must include the employee’s position, the business reason access is needed and the Tableau project folder the user needs access to.

(7) Some of the uses for Tableau are listed below:

• Generating reports to monitor permission records

• Generating reports to monitor new initiatives or special projects or programs

• Generating reports that are not available through ERCS

• Generating reports comparing AIMS and ERCS data

• Generating area-wide reports or reports across multiple Areas or Practice Areas

• Generating reports of potential errors such as the Related Returns Report (RRR)

(8) Access to each Tableau workbook is controlled by the owner of the workbook. Users in the same project folder typically have read access to workbooks in the folder, unless the owner has restricted access, but cannot save changes to workbooks they do not own.

(9) Users should make sure their reports are available to other A/E staff in their area in the event the owner is out of the office for an extended period.

(10) The ERCS database contains ERCS and AIMS data. The AIMS data is updated each weekend during the AIMS to ERCS batch processing.

(11) Tableau users are encouraged to utilize the ERCS Tableau SharePoint to share issues, resolutions, ideas, etc. The best resources for report issues are other Tableau users.

(12) When Tableau BEARS requests are processed, new users are added to the Outlook group, "&SBSE ERCS Oracle Discoverer". This distribution list is used to alert users of system downtime, Tableau issues, and new releases.

(1) Knowing the basic group operations enables the analyst to understand the dynamics of the group.

(2) The basic group operations include the characteristics of the group and the division of responsibilities between the manager, administrative support and technical employees in the group.

(3) The characteristics can include items such as the type of cases being worked (e.g., trust, fraud, general programs, etc.), the type of group (e.g. general program, Special Enforcement Program, training, etc.), the make-up of the group (e.g., trainees, seasoned examiners, new manager, etc.), and if there are any special issues affecting the group.

(4) The division of responsibilities in the group can include items such as who runs ERCS inventory reports, inputs technical time, and generates Form 895, Notice of Statute Expiration.

(1) The ERCS database consists of multiple programs and tables, each of these plays a part in maintaining overall accuracy. During an Operational Review it’s recommended review and analysis of the following be included:

• ERCS employee records and WSPs

• Pending and overage requisitions (Forms 5345-D)

• Form 3210 reports

• Current ERCS Overage IVL, AIMS SSIVL and RRR

• Unassigned Inventory report

• AIMS Error Reports

• Uploading Rejects Reports

• In Transit reports

• Returns in Status Code 12 with no time applied

• Inactive Case report

• Closed Case report

• Status Code 13 report

• Source Code 45 report

• Overage Purge report (TCO groups)

• Form 895 report and 895 Log file

• Pending Statute report

• Statute Tables 4.1

(2) As part of the review the A/E staff should ensure the group is aware of reference materials available including the ERCS book in Exam Systems knowledge base of the Virtual Library, the 6209 Code Retriever, Document 6209, IRS Processing Codes and Information, Document 6036, Examination Division Reporting Codes Booklet.

(3) Additional information on Operational Reviews can be found in the 2008 AIMS ERCS SETTS CPE Phoenix, AZ folder under National CPEs folder on the AIMS/ERCS/SETTS SharePoint site.