Tax Notes logo

4.7.10. AIMS/ERCS Staff

4.7.10 AIMS/ERCS Staff

Manual Transmittal

June 27, 2022

Purpose

(1) This transmits a revised IRM 4.7.10, Examination Returns Control System (ERCS), AIMS/ERCS Staff.

Material Changes

(1) Due to the move of the ERCS server from Solaris to Linux logins based on the user names are no longer used. The login is now the user’s Standard Employee Identifier (SEID) in lower case letters. References to verifying a login have been removed.

(2) Due to the move to Linux access to ERCS is through Active Directory and passwords are no longer used. References to passwords have been removed throughout this IRM.

(3) The IRS replaced the Online 5081 (OL5081) system with the Business Entitlement Access Request System (BEARS). References to OL5081 have been replaced with BEARS throughout this IRM.

(4) References to OL5081 Steps 1-3 and removal of access after a specific number of days have been removed.

(5) Due to the move to Linux new BEARS applications for ERCS were created following the BEARS naming conventions. Application names have been updated throughout the IRM.

(6) Content from the AIMS/ERCS website was required to be moved to the Virtual Library. ERCS content was moved to the ERCS book under the Exam Systems Knowledge Base. References to the AIMS/ERCS website have been replaced with the ERCS book throughout this IRM.

(7) Significant changes to this IRM are reflected in the table below:

Reference

New Reference

Description

4.7.10.1.2 (2)

4.7.10.1.2 (2)

"Responsibilities" of the A/E analysts: removed logging KISAM tickets and added monitoring for timely input of time charges by the end of the SETTS cycle.

N/A

4.7.10.1.5 (4)

"Related Resources": added new paragraph to include the ERCS book in the Virtual Library and three sections of the book; Manual and Handbooks, Troubleshooting and Contacts.

4.7.10.2 (4)

4.7.10.2 (6)

"Security": renumbered paragraph

N/A

4.7.10.2 (4)

"Security": added new (4), users must be aware of the potential for Unauthorized Access of Taxpayer Accounts violations from the use of ERCS data. Added link to IRM 10.5.5, IRS Unauthorized Access, Attempted Access or Inspection of Taxpayer Records (UNAX) Program Policy, Guidance, and Requirements.

N/A

4.7.10.2 (5)

"Security": added new paragraph, per IRS security requirements, IT employees are not permitted to have access to taxpayer data.

4.7.10.4

4.7.10.4

Renamed to: "Processing BEARS Requests and Adding Permissions Records". Added clarification that login and permission records must now be added before approving the BEARS request.

4.7.10.4 (3)

N/A

Removed (3): OL5081 steps no longer apply.

4.7.10.4.1

4.7.10.4.1

Renamed to: "Add Access BEARS Request".

4.7.10.4.2

4.7.10.4.3

Renamed to: "Modify Access BEARS Request".

4.7.10.4.3

4.7.10.4.4

Renamed to: "Remove Access BEARS Request".

4.7.10.4.4

N/A

"Password Reset OL5081" removed.

4.7.10.4.5

4.7.10.4.2

"Employee Records and User Permissions" moved and renamed to "User Permission Records".

4.7.10.4.3

4.7.10.4.5

Added new section five: "BEARS Manual Interactions". Moved content as BEARS processes separation actions as manual requests instead of removals.

4.7.10.5.1 (1)

4.7.10.5.1 (1)

"Maintaining ERCS Local Files": added Note: It is imperative that local files are kept up-to-date and should not contain employee PII or taxpayer TINs. Local tracking codes follow the same guidelines.

4.7.10.5.1 (1)

4.7.10.5.1 (1)

"Maintaining ERCS Local Files": added Caution: If local project or tracking codes contain the name of the taxpayer for Return Preparer Projects or any other program, the taxpayer’s name must be sanitized on all reports generated and shared outside of PSP. It is recommended that PSP keep a spreadsheet of local codes with taxpayer specific information and not include taxpayer PII in the ERCS local files.

N/A

4.7.10.5.5 (3)

Added new (3) and renumber remaining paragraphs. Added: 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.7.10.5.6 (5)

4.7.10.5.6 (5)

Updated to reflect SSIVL users will be added to the email distribution list when the BEARS request is processed and access added. Removed the "Note" as it no longer applies.

4.7.10.5.7 (2), 4.7.10.5.7 (3)

4.7.10.5.7 (2), 4.7.10.5.7 (3)

"Assisting in Reorganizations": updated to remove obsolete information and clarified how to answer the prompted questions.

N/A

4.7.10.5.7 (6)

"Assisting in Reorganizations": added (6), documents with detailed instructions for reorganizations across PBCs and within the Area are located on the AIMS/ERCS SETTS SharePoint site, and provided a link.

N/A

4.7.10-2

"BEARS SSIVL Applications", added exhibit of new SSIVL BEARS applications with descriptions.

(8) Minor editorial changes have been made throughout this IRM. Some items were reworded for clarity. Also, website addresses and IRM references were reviewed and updated, as necessary.

Effect on Other Documents

IRM 4.7.10 dated May 14, 2020 is superseded.

Audience

Small Business and Self Employed (SB/SE) and Large Business and International (LB&I) Audit Information Management System (AIMS) / Examination Returns Control System (ERCS) staff.

Effective Date

(06-27-2022)

Lori L. Roberts
Director, Technology Solutions
Small Business/Self Employed

Program Scope

(1) This IRM section contains information and procedures for the Audit Information Management System (AIMS) / Examination Returns Control System (ERCS) staff in operation and support of ERCS..

(2) Purpose: To provide guidance needed by the AIMS/ERCS (A/E) staff for consistency across the business units.

(3) Audience: A/E staff in SB/SE, LB&I, including Withholding Exchange and International Individual Compliance (WEIIC), and Return Preparer Office (RPO). Employees include managers, analysts and assistants.

(4) Policy Owner: The SB/SE Deputy Director, Examination, who is under the SB/SE Director, Examination.

(5) Program Owner: SB/SE Director, Technology Solutions.

(6) Primary Stakeholders: LB&I.

Background

(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).

Responsibilities

(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.

Program Controls

(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.

Acronyms

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

Related Resources

(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:

(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.

Security

(1) Users are granted access to ERCS via a BEARS request. Refer to IRM 4.7.2, Security, for detailed information regarding security requirements and assistance in determining the appropriate BEARS application needed for ERCS access.

(2) The A/E analyst is given read and write permission as an administrator (Admin) user for their assigned Area. Admin is a type of ERCS user reserved for the A/E staff. Admin users may run programs as any type of user (e.g., PSP, group, etc.). Admin permission enables the analyst to research and resolve program, data, or input issues for ERCS users.

(3) A/E staff must have an approved BEARS request for their local Area prior to requesting ERCS applications. Access to ERCS applications is requested through the "PROD ANALYST AIMS ERCS STAFF" application on BEARS.

Note: ERCS applications enable access to additional options on the Login Menu. The "coordinator" application allows access to the AIMS/ERCS Analyst Menu, the "download" application grants access to the AIMS Download menu and the "SETTS" application provides access to the SETTS menu. The “assistant” application gives the user access to selected options under the AIMS/ERCS Analyst menu.

(4) Users must be aware of the potential for Unauthorized Access of Taxpayer Accounts (UNAX) violations from the use of ERCS. Data from ERCS should be accessed only for IRS business purposes. Users should promptly retrieve ERCS reports from printers or fax machines in order to prevent unintentional disclosure. Audit trails are created and subject to review for all user accesses of taxpayer data. For more information about UNAX, see IRM 10.5.5, IRS Unauthorized Access, Attempted Access or Inspection of Taxpayer Records (UNAX) Program Policy, Guidance, and Requirements.

(5) Per IRS security requirements, IT employees are not permitted to have access to taxpayer data. No IT employee should be approved for ERCS access and any user transferred or detailed to an IT position must submit a Remove Access request to have all permission records removed.

(6) For security issues concerning ERCS, including access to employee returns, and UNAX violations, refer to IRM 4.7.2, Security.

A/E Group Meetings and Conference Calls

(1) A/E group meetings are a means to plan, advise and coordinate work efforts, clarify guidelines, and share information on systemic or procedural changes. These meetings also provide opportunities to build relationships and foster respect within the group.

(2) The national conference calls provide an opportunity for networking, exchanging ideas and sharing knowledge and insights with peers across the country.

(3) A/E managers and staff participate in events which include but are not limited to the following:

  • Area A/E group meetings

  • Monthly national A/E staff conference calls

  • Ad hoc meetings initiated by HQ ERCS or AIMS analysts

Processing BEARS Requests and Adding Permission Records

(1) At least two members of the A/E staff (managers or analysts) must be on the approval path for the ERCS BEARS requests for each area and CCP campus. The A/E managers in each area will decide how many employees are needed on the approval path. For the purposes of this section the A/E staff responsible for processing ERCS BEARS requests will be referred to as the "ERCS approver".

(2) The ERCS approver must have coordinator access and Admin permission before they can add permission records.

(3) Requests to Add Access, Modify Access, and Remove Access require actions to be taken on both the BEARS and ERCS systems.

(4) The BEARS request serves as the official record of the user's approved level of access and must include required information prior to approval.

(5) Topics covered in this section include:

  • Add Access BEARS Requests

  • User Permission Records

  • Modify Access BEARS Requests

  • Remove Access BEARS Requests

  • BEARS Manual Interactions

Add Access BEARS Request

(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.

Example: If an administrative support employee in Area 201 inputs a BEARS request for "PROD USER SBSE AREA 201-NORTH ATLANTIC" but is requesting permission for an LB&I AIMS Assignee Code (AAC), the request should be denied and the user advised to submit a BEARS request for "PROD USER LBI Area 201-NORTH ATLANTIC"

(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.

Example: Shared support associate in TE/GE, will be closing cases and inputting time for AAC 324-XXXXX-XXXX. Employee needs read and write permissions as a Group user. This is a temporary assignment ending on mm/dd/yyyy.

Example: Tech Services employee in Area 202, will be assigning incoming returns from Area 204. Employee needs permanent read and write permissions as a Review user.

Example: Shared support associate in Area 205, will be providing admin support to AAC 217-XXXXX-XXXX. Employee needs permanent read and write permissions as a Group user.

Example: Examiner in SB/SE field exam, will be inputting 4502 time. Employee needs permanent read and write permissions as a Limited user for AAC 203-XXXXX-XXXX.

(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.

Note: If the Add Access request is not for the user’s initial application, the login should already be entered in the employee record and permission records can be added.

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

User Permission Records

(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.

Example: An RA in Group A is going to be detailed to Group B as an acting manager for 120 days. The A/E analyst will add permanent read permission for Group A and temporary read and first level approval permission for Group B. This will allow the RA to keep their login active after the detail ends in the event they are needed for another acting assignment. If access is no longer needed the RA must submit a "Remove Access" BEARS request at the end of their detail.

(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.

Note: PBCs and Secondary Business Codes (SBC) for Limited users must be activated in a national file by the HQ ERCS analysts. The ERCS approver must contact the HQ ERCS analysts for approval of Limited users prior to processing a BEARS request or adding permission records.

(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.

User Type

Users

CCP

Employees in SBC 897XX

Review

TS employees including Joint Committee Review

Sample Review

Managers and administrative support employees in Sample Review

PSP

Employees in SBC 87700

Group

Managers, technical employees and administrative support employees

Territory

TMs and administrative support employees

DFO

LB&I Practice Area directors and administrative support employees

Area

HQ analysts, Area analysts (read access only)

Admin

A/E staff only

Limited

Technical employees electing to input their own 4502 time charges (AAC must match the AAC on the ERCS employee record)

(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.

Modify Access 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.

Example: Examiner in SB/SE field exam completed detail as acting manager. Remove Group level, first level approval permission for AAC 207-XXXXX-XXXX.

Example: PSP tax examiner in Area 202 will be assisting group 202-XXXXX-XXXX with time input for 120 days. Add temporary, Group level, read and write permission until mm/dd/yyyy.

(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.

Remove Access 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.

Note: If a user loses ERCS access due to inactivity the A/E staff should advise the employee to submit a "Remove Access" BEARS request, after which, the employee can submit an "Add Access" BEARS request if access is still needed.

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

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

BEARS Manual Interactions

(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".

Performing ERCS Tasks

(1) The following tasks must be completed by a member of the A/E staff:

  • Maintaining ERCS local files

  • Processing ERCS to AIMS uploads

  • Processing ESTAB and Special Search requests

  • Processing and monitoring database transfer requests

  • Processing the SETTS data

  • Processing the SSIVL data

  • Assisting in reorganizations

  • Creating, maintaining, and running Tableau reports

Maintaining ERCS Local Files

(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.

Note: It is imperative that local files are kept up-to-date and should not contain employee personally identifiable information (PII) or taxpayer TINs. Local tracking codes follow the same guidelines.

Caution: If local project or tracking codes contain the name of the taxpayer for Return Preparer Projects or any other program, the taxpayer’s name must be sanitized on all reports generated and shared outside of PSP. It is recommended that PSP keep a spreadsheet of local codes with taxpayer specific information and not include taxpayer PII in the ERCS local files.

(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.

Note: Typos, extra lines at the end of a file, or spaces at the end of a line have been known to cause unexpected results in the ERCS programs.

(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.

Processing ERCS to AIMS Uploads

(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

Note: In addition to the command codes needed for the Requisitions and Updates program, the A/E staff must also have numerous command codes in their profiles for problem resolution.

(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.

Processing ESTAB and Special Search Requests

(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.

Note: A charge-out can be either Form 4251, Return Charge-Out or Form 5546, Examination Return Charge-Out Sheet.

(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.

Processing and Monitoring Database Transfer Requests

(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.

Note: To "claim" a return in ERCS a user may update the SBC and EGC if the return is in a local Campus or PSP AAC, and in a status code less than 09.

Processing the SETTS Data

(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.

Example: If a holiday falls on a Tuesday, but it is the employee's scheduled day off, the program expects the employee to charge holiday time for Monday. If the employee does not charge holiday time on the Monday, an ILOH error will appear on the report.

(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):

Validation Times (ET)

Results Returned Times (ET)

1:30 PM

2:00 PM

2:30 PM

3:00 PM

3:30 PM

4:00 PM

4:30 PM

5:00 PM

5:30 PM

6:00 PM

7:00 PM

7:30 PM

8:00 PM

8:30 PM

10:00 PM

10:30 PM

(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.

Processing the SSIVL Data

(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.

Reminder: Statute Tables 4.1 are generated at the Campus and emailed to the Areas for distribution. However, Statute Tables 4.0 must be generated through SSIVL and distributed monthly for TS, PSP and CCP.

(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.

Note: The preferred method to transfer the SSIVL data to a local server is EFTU. Special permission from the HQ SSIVL analyst is needed if more than two persons per area or campus need SFTP permission for SSIVL.

Note: SB/SE Areas do not need to submit BEARS requests for SSIVL applications as their files are available on the EFTU 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.

Assisting in Reorganizations

(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.

Creating, Maintaining and Running Tableau Reports

(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.

Example: User is an A/E analyst in Area 202, and will need to pull miscellaneous reports for groups supported. PBCs 202, 212-214, 320, 321 and 323-328.

(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.

Example: User is an A/E assistant in Area 203 who will be generating reports from workbooks already on Tableau. Need access to the Area 203 project folder.

(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.

Conducting Operational Reviews and Assistance Visits

(1) Operational Reviews and Assistance Visits are conducted by A/E analysts. Operational Reviews can either be virtual or face-to-face, as where Assistance Visits are face-to-face.

(2) The purpose of an Operational Review is to analyze operations and advise groups on inventory controls, case processing, and basic group operations. Typically Assistance Visits are scheduled to address specific needs of the group.

(3) When scheduling an Operational Review an official memo should be drafted and sent to the group manager with a copy to the territory manager at least 30 days in advance. The memo should include the date of the review, whether it will be face-to-face or virtual, and list the items that will be reviewed.

(4) Once the memo has been issued the "Operational Review Questionnaire" should be sent to the group manager and administrative support assistant with a response due date of at least a week prior to the review. This allows the analyst time to incorporate the answers received into their preparation for the review.

Note: When planning a face-to-face Operational Review the A/E analyst must take into consideration that the administrative support assistant/associate may be in a POD other than that of the manager. Also, the manager may be sharing a support employee and the A/E analyst will need to verify where the group records are being maintained.

(5) The A/E analyst will provide written feedback of an Operational Review within a reasonable time frame. The suggested time frame is two weeks, but should be no later than 30 days.

Note: The following sections pertain to conducting an Operational Review of a field or office audit group, however, Operational Reviews are also conducted on PSP groups.

Basic Group Operations

(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.

Example: Limited users in the group are responsible to input their own technical time and the administrative support assistant inputs any remaining technical time. The group manager is responsible for advising the administrative support assistant of changes needed in employee grades and work schedules so employee records and WSPs are updated timely.

ERCS Database Accuracy

(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.

Maintaining and Monitoring the Accuracy of the Database

(1) ERCS contains a vast amount of data for returns under examination in SB/SE and LB&I. Data is transferred to and from ERCS through a number of interface programs including AIMS. Data is also manually input directly into ERCS by users. ERCS data is used to generate reports from the group level to the national level. Therefore, every ERCS user is responsible for ensuring data input into ERCS is input accurately and timely.

(2) The A/E staff plays a vital role in ensuring the integrity of the ERCS database is maintained. In addition to the items checked during an Operational Review or Assistance Visit, there are other data issues that need to be monitored as well as periodic data clean-up initiatives where assistance is needed from the A/E staff. There are a number of ERCS reports and programs available to the A/E staff to assist in resolving database issues. These reports and programs include, but are not limited to the following:

  • AIMS Error Reports

  • Uploading Reject Reports

  • Audit Trails

  • Utility Edit Record and Utility View Record programs

  • Database Error Report

  • Maintain Address Table program

  • Overage Approval Report

(3) The AIMS Error Reports are a collection of reports generated when AIMS and ERCS data is compared during AIMS to ERCS batch processing. Reports are only created if there is an issue to report. Although some of these reports are available at the end-user level, the A/E analyst can generate them for a particular group, territory, industry, or for the entire area. These reports should be monitored weekly. For information about reports available to end-users and how to work the AIMS Error Reports, refer to the "AIMS Error Reports" and "Miscellaneous AIMS/ERCS Analysts Reports" sections of the IRM 4.7.6, Reports.

(4) Uploading Reject Reports should be worked by the group or function initiating the requests, updates, transfers or closures. Once the rejects have been resolved, the reports should be deleted by the group or function. Uploading Reject Reports that remain on the system for more than a few days may be an indication the reports are not being worked or deleted timely or that the users are having problems working the reject. The A/E staff should monitor the reports to ensure the groups or functions are working them timely.

Note: Check AIMS Results for AMSOC transfers and closures are only displayed to the user who input the transfer or closure on ERCS. It’s recommended that AMSOC rejects be brought to the attention of the A/E manager as they occur to insure they are promptly resolved.

(5) The ERCS audit trails are an invaluable tool that can be used in conjunction with ERCS reports to resolve issues with particular returns. The audit trails are historical records of when returns were added or updated on ERCS, the type of update or change, and the user or program that initiated the action. Refer to the Utility Miscellaneous Programs chapter of the ERCS TRM for information about running the Read Audit Trail program and for details about the ERCS audit trails.

(6) The Utility Correcting programs enable the A/E staff to correct data on returns that may not be correctable using the end-user menus. It is an option that should be used with extreme caution because the programs do not perform the ERCS consistency checks when data is changed. Refer to the Utility Correcting Programs chapter of the ERCS TRM for information about this program.

(7) The Utility Miscellaneous programs enable the A/E staff to research data on returns that may not be displayed on end-user screens or reports. In addition to the information about the return, the program also displays information about the history record, time charges, recent updates, closing information, pending managerial approval records, and AAC differences between AIMS and ERCS. Refer to the Utility Miscellaneous Programs chapter of the ERCS TRM for information about this program.

(8) The Database Error Report is used to identify potential errors in the data or in the code lists used to validate the data. It should be run by the A/E staff prior to the end of each cycle to identify potential SETTS errors. It can be run weekly to identify errors introduced after AIMS to ERCS processing or to ensure no new inventory is moved into old AACs after a reorganization. If the user suspects that a code may be incorrectly listed as invalid, the HQ SETTS or HQ ERCS analysts should be contacted. Refer to the "Miscellaneous AIMS/ERCS Analysts Reports" section of the IRM 4.7.6, Reports, for information about running and working this report.

(9) The Address Table contains addresses used in the generation of Form 3210 and in the generation of the Sample Selection sheets. The Maintain Address Table option is accessed from the AIMS/ERCS Analysts Menu. It enables the A/E staff to add, update, and delete addresses, and to save temporary addresses created by end-users to permanent status. When a Form 3210 is generated through ERCS, the corresponding addresses for the sending and receiving groups are displayed on the user's screen for selection. Eliminating duplicate addresses and incorrect or obsolete addresses will facilitate getting the correct address on the documents. Refer to the Login Menu chapter of the ERCS TRM for information about running this option.

(10) The Overage Approval Report, located on the Utilities Menu, Miscellaneous Programs, is used to monitor updates pending managerial approval. This report is similar to the Work Awaiting Approval report available to users, except this report can only be run by PBC and the data on the report is slightly different. If the report is run by 0 days it lists all returns pending managerial approval. It can also be run by entering a number of days to obtain a list of overage returns pending approval. Refer to the "Miscellaneous AIMS/ERCS Analysts Reports" section of the IRM 4.7.6, Reports, for information about running and working this report.

(11) The A/E staff works with the HQ ERCS staff to oversee and assist in data clean-up efforts in their area that are initiated at the national level.

(12) A/E managers and analysts may be requested by upper management in the local area to conduct management studies and provide feedback.

Acronyms and Definitions

Acronym

Definition

AAC

AIMS Assignee Code

AIMS

Audit Information Management System

A/E

AIMS/ERCS

BEARS

Business Entitlement Access Request System

CCP

Centralized Case Processing

COFFEE

Common Operating Functionality for Enterprise Emulation

DFO

Director of Field Operations

DLN

Document Locator Number

EFTU

Electronic File Transfer Utility

EGC

Employee Group Code

ERCS

Examination Returns Control System

ET

Eastern Time (includes Standard and Daylight)

GII

Generalized IDRS Interface

HQ

Headquarters

IDRS

Integrated Data Retrieval System

ILOH

In Lieu of Holiday

IVL

Inventory Validation Listing

LB&I

Large Business and International

MCC

Martinsburg Computing Center

PBC

Primary Business Code

PII

Personally Identifiable Information

PSP

Planning and Special Programs

RRR

Related Returns Report

SBC

Secondary Business Code

SB/SE

Small Business and Self Employed

SETTS

Summary Exam Time Transmittal System

SFTP

Secure File Transfer Protocol

SSIVL

Statistical Sampling Inventory Validation Listing

SSN

Social Security Number

TAPP

Time Applied

TE/GE

Tax Exempt & Government Entities

TIN

Taxpayer Identification Number

TM

Territory Manager

TRM

Technical Reference Manual

TS

Technical Services

WEIIC

Withholding Exchange and International Individual Compliance

WSP

Work Schedule Profile

BEARS SSIVL Applications

(1) Employees requesting access to SSIVL applications must include the business reason access is needed in the Special Instructions box of the BEARS request.

BEARS SSIVL applications

Description

PROD USER SSIVL-190

Used to request SSIVL access for PBC 190 Campus Exam employees

PROD USER SSIVL-191

Used to request SSIVL access for PBC 191 Campus Exam employees

PROD USER SSIVL-192

Used to request SSIVL access for PBC 192 Campus Exam employees

PROD USER SSIVL-193

Used to request SSIVL access for PBC 193 Campus Exam employees

PROD USER SSIVL-194

Used to request SSIVL access for PBC 194 Campus Exam employees

PROD USER SSIVL-201

Used to request SSIVL access for Area 201 PSP employees (should rarely be used)

PROD USER SSIVL-202

Used to request SSIVL access for Area 202 PSP employees (should rarely be used)

PROD USER SSIVL-203

Used to request SSIVL access for Area 203 PSP employees (should rarely be used)

PROD USER SSIVL-204

Used to request SSIVL access for Area 204 PSP employees (should rarely be used)

PROD USER SSIVL-205

Used to request SSIVL access for Area 205 PSP employees (should rarely be used)

PROD USER SSIVL-206

Used to request SSIVL access for Area 206 PSP employees (should rarely be used)

PROD USER SSIVL-207

Used to request SSIVL access for Area 207 PSP employees (should rarely be used)

PROD USER SSIVL-212

Used to request SSIVL access for Area 212 PSP employees (should rarely be used)

PROD USER SSIVL-213

Used to request SSIVL access for Area 213 PSP employees (should rarely be used)

PROD USER SSIVL-214

Used to request SSIVL access for Area 214 PSP employees (should rarely be used)

PROD USER SSIVL-295

Used to request SSIVL access for PBC 295 Campus Exam employees

PROD USER SSIVL-296

Used to request SSIVL access for PBC 296 Campus Exam employees

PROD USER SSIVL-297

Used to request SSIVL access for PBC 297 Campus Exam employees

PROD USER SSIVL-298

Used to request SSIVL access for PBC 298 Campus Exam employees

PROD USER SSIVL-299

Used to request SSIVL access for PBC 299 Campus Exam employees

PROD USER SSIVL-LBI

Used to request SSIVL access for LBI employees

PROD USER SSIVL-WEIIC

Used to request SSIVL access for WEIIC employees

PROD USER SSIVL-TEGE

Used to request SSIVL access for TE/GE employees

PROD USER SSIVL-CINCY CCP

Used to request SSIVL access for Cincinnati CCP employees

PROD USER SSIVL-MEMPHIS CCP

Used to request SSIVL access for Memphis CCP employees

PROD USER SSIVL-OGDEN CCP

Used to request SSIVL access for Ogden CCP employees

PROD COORD SSIVL

Used to request SSIVL Coordinator access in order to add and remove AACs. (Must have SSIVL access to the requested PBC before access can be granted.)

This data was captured by Tax Analysts from the IRS website on December 03, 2023.
Copy RID