3.24.159  SCRS SC Edits

Manual Transmittal

November 22, 2013

Purpose

(1) This transmits revised IRM 3.24.159, ISRP System, SCRS SC Edits.

Material Changes

(1) Various editorial changes were made throughout IRM 3.24.159.

Effect on Other Documents

IRM 3.24.159, dated October 26, 2012 (effective January 1, 2013) is superseded.

Audience

Programmers receiving transcribed data from Integrated Submission Remittance Processing and other sources will use this IRM.

Effective Date

(01-01-2014)


Paul J. Mamo
Director, Submission Processing
Wage and Investment Division

3.24.159.1  (01-01-2014)
Introduction

  1. This section describes the way data from Integrated Submission and Remittance Processing System (ISRP), lockbox, mag tape, and the Service Center Recognition Image Processing System (SCRIPS) is validated and edited. It provides detailed information for the preparation of edit parameters; and designates responsibility for the initial implementation as well as periodic updating of the Edit System. Parameters for the Data Edit Validation (DED) are also used by ISRP (Common Services).

  2. This IRM does not provide instructions for data entry.

3.24.159.1.1  (01-01-2012)
Internal Controls

  1. The Federal Managers' Financial Integrity Act (FMFIA) of 1982 requires each executive agency to conduct annual evaluations of its systems of control using guidelines set by the Office of Management and Budget (OMB).

  2. In December 2004, OMB issued a revision of Circular Number A-123, Management's Responsibility for Internal Control, to provide guidance to federal managers on improving the accountability and effectiveness of federal programs and operations by establishing, assessing, correcting, and reporting on internal control.

  3. For specific guidelines and responsibilities, refer to the Circular A-123, and to IRM 1.4.1, Management Roles and Responsibilities, and IRM 1.4.2, Monitoring and Improving Internal Accounting and Administrative Controls.

3.24.159.2  (01-01-2012)
Service Center (SC) Edits

  1. The Service Center Replacement System (SCRS) eliminated the need for customized edits. A multipurpose program has been developed which performs a generalized edit function for all projects. This program is driven by parameters which must be supplied by the analyst assigned to each individual project.

  2. SCRIPS data is input to the multipurpose program for validation/reject processing, but it does not undergo further edit processing as it is already in edited format.

3.24.159.2.1  (01-01-2012)
Input to the DED System and ISRP (Common Services)

  1. Input to the Data Edit and Validation (DED) System and ISRP is through ISRP Data Entry, Lockbox, SCRIPS, and magnetic tape. Coordination of data entry instructions is the responsibility of the ISRP analyst, and the analyst assigned to each individual project. These instructions will govern the format of the input into the Edits Processing system. Fields will be edited and output in the same order in which they are entered.

  2. Since the systems are designed so that input can be in a variety of formats, the general requirements for input are minimal and correspond to the format requirements for ISRP.

  3. Each block must contain a block header which consists of:

    1. Operator Class - See IRM 3.24.159.2.2, Operator Class

    2. Format Code - See IRM 3.24.159.2.3, Format Code

    3. Service Center (SC) Block Control Number - See IRM 3.24.159.2.4, Service Center Block Control Number

  4. Each block must contain at least one document with a document breaker ([).

  5. Each block must contain at least one section with a section breaker (@).

  6. Each block must contain at least one field per section.

  7. Each block must contain an end of block indicator (EOB).

  8. When preparing parameters for an input document, comments can be placed on each parameter entry line by separating the end of the parameter and the beginning of the comment with at least three spaces.

3.24.159.2.2  (01-01-2012)
Operator Class

  1. The operator class is a one digit field which may provide additional information on the type of document being entered. Operator class assignment for a given document is obtained from the ISRP analyst along with the Format Code. Generally, the Operator Class is assigned as follows:

    1. Operator Class "0" - used for Individual Master File (IMF) and Business Master File (BMF) mainline documents.

    2. Operator Class "1" - used for Employee Plan/Management Information System (EP/MIS).

    3. Operator Class "2" - used for General Purpose Program (GPP).

    4. Operator Class "5" - used for Information Return Program (IRP) documents read by SCRIPS.

3.24.159.2.3  (01-01-2012)
Format Code

  1. A three digit Format Code must be assigned by the ISRP analyst to each type of input document. While the sections within a document may have various formats on both input and output, all documents entered under one Format Code must have like formats.

3.24.159.2.3.1  (01-01-2012)
Format Code Format

  1. The Format Code is a three digit number ranging from 001 to 999. More than one type of document (Format Code) can be processed simultaneously through the edit system.

  2. The same Format Code may be assigned to more than one type of input document if the input documents have the same identical formats.

  3. For assignment of Operator Class/Format Codes, contact the ISRP analyst, OS:CTO:AD:SP:IP:EI.

3.24.159.2.4  (01-01-2012)
Service Center (SC) Block Control Number

  1. The SC Block Control Number (formerly ABC) is a three digit/character Submission Processing Site generated code assigned to each block of documents for control purposes.

3.24.159.3  (01-01-2012)
Output from the DED System

  1. Output from the DED System and ISRP Common Services is governed by the parameters supplied for each document. IRM 3.24.159.4, Parameters, provides a detailed description of these parameters. In preparing parameters for a document, data sizing limitations are as follows:

    Data Type Maximum Size
    Alpha Field 200 Characters
    Numeric Field 80 Characters
    Section 750 Characters
    Document 16,000 Characters

3.24.159.3.1  (01-01-2012)
Problem Codes

  1. Four problem code fields (one character each) are established by the edits program for every section, immediately in front of the section number. They are in order of occurrence:

    1. ISRP

    2. MIXED-DATA

    3. SECTION

    4. FIELD

  2. These fields will be zero filled if the problem code checks are successfully passed. More information on problem code checks may be found in Functional Specification Package (FSP) documentation (1.35.00 Part 1, Subpart 2, SC Data Edit Prep).

3.24.159.3.2  (01-01-2012)
Reject Processing

  1. The Data Edit and Validation (DED) System also performs certain validation checks to ensure logical processing integrity of all input data blocks. Failure of any of these checks will result in the subject block being dropped from further processing. At the same time a line entry will appear on the EDIT REJECT LIST with identifying information, including the block Document Locator Number (DLN) for machine data. For further information on the EDIT REJECT LIST, check FSP 1.35.00.00 Part 1, Subpart 2, SC Data Edit Prep.

3.24.159.3.3  (01-01-2012)
Non-Pipeline Files

  1. The documentation of user Non-Pipeline programs (programs that receive data from Generalized Main Frame (GMF) 02) must include a File Identification starting with other than GMF in their parameters. All Non-Pipeline output will be in interchange format, odd parity, 6250 Bits per Inch (BPI) and have American National Standards Institute (ANSI) labels.

  2. The first field, (four (4) numerics), of each output record will always be a record length character count (not including the field itself). The receiving program File Description (FD) must have the following:

    1. RECORD CONTAINS (greater than or equal to) 5 to 9995.

    2. RECORDING MODE is "D" for UNISYS and " V" for IBM.

  3. Multiple Format Codes will be placed on the same Non-Pipeline output file when:

    1. The File Identifications are identical, and

    2. The Operator Class/Format Codes are consecutive (no breaks), as:

    File ID Operator Class/Format Code
    XYZ0101 2998
    XYZ0101 2999

3.24.159.4  (01-01-2012)
Parameters

  1. The following define types of parameters, and their use.

3.24.159.4.1  (01-01-2012)
Types of Parameters

  1. There are three types of parameters:

    1. Document

    2. Section

    3. Field

  2. Parameters must be entered on the UNISYS system and stored as a symbolic element in a shared program file. See IRM 3.24.159.5.1, Initial Transmittals, for transmittal instructions.

  3. As many parameters and types of parameters as desired can be included in the shared program file.

  4. Parameters can not be split between line entries. Entry is limited to 80 characters.

  5. Three consecutive blanks will cause the remainder of the parameter entry to be treated as a comment.

  6. The character "@" can never be the first character of an entry.

  7. Only requirement parameters need be entered.

  8. If a parameter is not required to be present and no entry has been made for that parameter, in general, the default value generated will produce record formatting in GMF format.

3.24.159.4.2  (01-01-2012)
Documents

  1. One set (and one set only) of document parameters must be prepared for each Format Code.

3.24.159.4.2.1  (01-01-2012)
Document Parameters

  1. Exhibit 3.24.159-1, Document Parameters, shows the format and specifications for the document parameters. The following is a description of the various elements and options.

    Element Name Instructions
    E1 Operator Class Must always be present and must be delimited by the special character ">" . See IRM 3.24.159.2.2.
    E2 Format Code Must always be present and must be delimited by the special character ">" . See IRM 3.24.159.2.3.
    E3 File Identification Value not needed for Mainline Data Files, as file ID "GMF0101" will be generated automatically from the default option. Blanks need not be entered, but the delimiter special character ">" must be present.

    Exception:


    a) IRP documents must have the first five characters coded as "GMF07 " .
    b) For Non-Pipeline data, this is a 12 character value used in the "FILE-ID IS..." clause of the user program's FD statement. The name entered in this parameter will be expanded to 12 positions with filling zeros to the right (EX: EXM0101 will become EXM010100000). Program SELECT statements and ECL,@,ASG statements should be changed to match this file name.

    E4 Document Breaker Suppressor Must be present if a document breaker ([) is not desired between documents. If present, must be delimited by the special character ">" .
    E5 Serial Number Suppressor Must be present if the input document serial numbers are to be suppressed on output. If present, must be delimited by the special character ">" .
    E6 Problem Code Suppressor Must be present if the edit problem codes are to be suppressed. If present, must be delimited by the special character ">" .
    E7 Section Breaker Suppressor Must be present if a section breaker "@" is not desired between sections. If present, must be delimited by the special character ">" .
    E8 Section Number Suppressor Must be present if the input section numbers are to be suppressed on output. If present, must be delimited by the special character ">" .
    E9 Field Breaker Suppressor Must be present if a field breaker (+) is desired between fields. If present, must be delimited by the special character ">" .
    E10 FRMT/SC Block Control Number Generator Must be present if the header Operator Class/Format Code and SC Block Control Number are to be generated into each document. This parameter option applies only to Non-Pipeline data. If present, must be delimited by the special character ">" . The Operator Class/Format Code and SC Block Control Number, when generated, will follow positions 1 through 4 (character count) of each document of a block and each block header when the Non-Pipeline Block Header option is selected.
    E11 Non-Pipeline Block Header Must be present if a Non-Pipeline Block Header is to be output. If present, must be delimited by the special character ">" .
    E12 Filler Sections Must be present to generate sections (when otherwise not required) for sections missing from document input, but only to the last section received or to any subsequent user required sections generated by the edits program. If present, must be delimited by the special character ">" .
    E13 Document Parameters Completed Once all desired parameters have been specified, the special character "\" must be present. This indicates that all the parameters for a document have been entered.

3.24.159.4.3  (01-01-2012)
Sections

  1. For initial transmittal, at least one set of parameters for a section must be prepared for each document. As many as ninety-six (96) document specific sections can be present. Each section must be followed by as many sets of parameters for fields as are necessary for that section. Sets of parameters for sections and fields should be in sequential, ascending order.

3.24.159.4.3.1  (01-01-2012)
Section Parameters

  1. Exhibit 3.24.159-2, Section Parameters, shows the format and specifications for each section of a document that can be input. The following is a description of the various elements and options.

    Element Name Instructions
    E1 Section Number Must always be present (01–96) and must be delimited by the special character ">" .
    E2 Section Required Must be present if section is required. A "dummy" section will be generated for this section any time it is missing from an input document. This will be a section containing blanks for alphanumeric fields and zeros for numeric (Field Type parameters of NUME or LSGN) fields. Field breakers will not be present unless Parameter E9 of the Document Parameters has been set to generate breakers. If present, must be delimited by the special character "< " .
    E3 Section Parameters Once all desired parameters for a particular section have been specified, the special character "@" must be present. This indicates that the parameters for a section have been entered.
  2. After all document specific section and field parameters have been completed, parameter information for additional Special Section "99" is required. Information to be provided and maximum field size limitations (n) are:
    99 Operator Class (1)>Format Code (3)>Document Title (25)> Responsible Analyst (15)>Phone Number (8) >Organization Code (15)> Date (8)>@(Enter the date in YYYYMMDD format).

3.24.159.4.4  (01-01-2012)
Fields

  1. For initial transmittal, at least one set of parameters for a field must be prepared for each section. The Edit System requires a set of field parameters for every field on input. As many as sixty (60) fields per section can be output from the Edit System. Field parameters must follow the associated section parameters in their sequential order of occurrence.

3.24.159.4.4.1  (01-01-2012)
Field Parameters

  1. Exhibit 3.24.159-3, Field Parameters, shows the format and specifications for each field of a section. The following is a description of the various elements and options.

    Element Name Instructions
    E1 Number of Characters Must be present for the first field in a section. If present, must be delimited by a special character ">" .

    Note:

    An alphanumeric field cannot exceed 200 characters, and a numeric (field type "NUME" or "LSGN" ) cannot exceed 80 characters.

    E2 Field Type 1) The default parameter is "NUME" , which indicates that the field as entered will be numeric and not signed. Other values are:
    a) "ALPH" - alphanumeric
    b) "LSGN" - leading (separate character) signed numeric.
    2) If present, must be delimited by the special character ">" .
    3) The data entry program prior to the edits program will zero or blank fill fields and perform any field justification required.
    4) The edits program uses the above field type information to perform a problem code check for the presence of alpha or special characters in numeric fields and to assign the leading sign over-punched data in the case of the "LSGN" option.
    E3 Mixed Field Check 1) Must be present if a check for a mixed field is desired. If present, must be delimited by the special character ">" .
    2) If a mixed data check is desired, the parameter MIXn appears where "n" is a number from 1 to 7.
    3) Each iteration of "n" will allow up to four fields (same section) in the previous document for the occurrence of mixed data. For example, if the social security number (SSN) and tax period both need to be checked in one section, and a remittance field also needs to be checked in a second section, the mixed data field parameters would be as follows:
    SSN would be MIX1
    Tax Period would be MIX1
    Remittance would be MIX2
    E4 Field Parameters Completed The special character "+" must be present once all the parameters for a given field have been entered. To replicate field parameters for additional fields, the "+" should be followed by "n" representing the number of additional fields, followed by another "+" .

    Example:

    "10+5+" would account for 6 fields, each 10 characters long, defined as "NUME" with no mixed field checks.

3.24.159.4.4.2  (01-01-2012)
Parameters Completed

  1. Once all the desired parameters for a document have been specified, the special character "[" must be present. It must be present once for each format code. It immediately follows the special section "99" entry shown above in IRM 3.24.159.4.3.1 Section Parameters.

3.24.159.5  (01-01-2012)
Analyst Responsibility

  1. This section defines the responsibilities of analysts in preparing format parameters.

3.24.159.5.1  (01-01-2012)
Initial Transmittals

  1. Each format code requires a set of parameters. These parameters must be prepared by the analyst assigned to the project which processes the documents associated with that format code. A file of parameters for all format codes will be maintained by the Operation Support: Chief Technology Officer: Applications Development: Submission Processing: Input Processing: Electronic Input (OS:CTO:AD:SP:IP:EI) responsible section.

  2. Analysts must ensure that the OS:CTO:AD:SP:IP:EI responsible section has received the parameters for each project.

  3. Parameters must be received by OS:CTO:AD:SP:IP:EI with enough lead time for implementation prior to System Acceptability Testing (SAT) and production transmittal dates.

  4. Normally transmittals will be made no more than once a week, on Wednesday.

  5. Analysts should provide a memorandum to the OS:CTO:AD:SP:IP:EI responsible section listing the following:

    1. Project name(s)

    2. Project number(s)

    3. Operator Class/Format Code(s)

    4. SAT Library version name (e.g., S407)

    5. SAT required dates

    6. SAT sites

    7. Production required dates

    8. Production sites

    9. Name of responsible analyst

    10. Organization symbols

    11. Telephone extensions

  6. The detailed name of the UNYSIS program file, including all qualifiers, read/write keys, etc. must also be included. Element name(s) to be used will be the Operator Class/Format Code(s) of the parameter set(s) contained in the element(s). See Exhibit 3.24.159-5, Example of Parameters Transmittal.

3.24.159.5.2  (01-01-2012)
Updating Parameters

  1. When updating any of the parameters for a particular document, it is necessary to resubmit the entire set of parameters (document, section, and field) as the complete set of parameters for the identified Operator Class/Format Code to be replaced on the on-line parameter file. Project analysts are responsible for reviewing the correctness of all updates as well as initial transmittals.

3.24.159.5.3  (01-01-2012)
Deleting Parameters

  1. Project analysts are responsible for timely deletion of parameters for obsolete documents. Deletions are accomplished by parameter input as follows:
    Operator Class Format Code DELETE>\.

  2. The Operation Support: Chief Technology Officer: Applications Development: Submission Processing: Input Processing: Electronic Input (OS:CTO:AD:SP:IP:EI) section responsible for maintaining the SC Edits parameter file should be notified via memorandum when a set of parameters for a document is to be deleted, including the date of obsolescence. Section personnel maintaining the parameter file will effect the necessary deletion.

  3. The DELETE capability should not be used when updating existing parameters. If updating parameters with the same Operator Class/Format Code, the update will overlay the old parameters and deleting is not necessary.

3.24.159.6  (01-01-2012)
Examples of the Use of Parameters

  1. The following exhibits are for use as examples of parameter value only. They are not intended to describe any actual IRS document. Exhibit 3.24.159-4, Example of Use of Parameters, provides an example of the values which may be used in parameters. A description of the expected output is listed first. The parameter values are listed next.

Exhibit 3.24.159-1 
Document Parameters

Document Parameters
Reference Text: IRM 3.24.159.4.2.1, Document Parameters
★ = These parameters are optional.
★★★ = Trailing blanks need not be present.
Record Element Number (En) Record Element Name Format Valid Range and Meaning
1 Operator Class 9 0–9
See IRM 3.24.159.2.2.
2 Format Code 999 See IRM 3.24.159.2.3.
3 ★★★ File Identification X(17) File to Number
4 ★ Document Breaker Suppressor XXXX NDBR – No Document Breakers
SDBR – Std. Breakers
Default = SDBR
5 ★ Serial Number Suppressor XXXX SSRN – Suppress Serial Number
DSRN – Do not suppress
Default = DSRN
6 ★ Problem Code Suppressor XXXX SSPC – Suppress Problem Code
DSPC – Do not suppress
Default = DSPC
7 ★ Section Breaker Suppressor XXXX NSBR – No Section breaker
STBR – Std. Breakers
Default = STBR
8 ★ Section Number Suppressor XXXX SSCN – Suppress Section Number
DSCN – Do not suppress
Default = DSCN
9 ★ Field Breaker Generator XXXX NFBR – No Field Breakers
SFBR – Field breakers
Default = NFBR
10 ★ FRMT/ABC Generator (Non-Pipeline only) XXXX GHDR – Generate Data
SHDR – Do not generate
Default = SHDR
11 ★ Non-Pipeline Block Header (Non-Pipeline only) XXXX DHDP – DIS Header to be passed
NDHD – No DIS header
Default = NDHD
12 ★ Filler Sections X FILL – Generate filler sections
NFIL – Do not generate
Default = NFIL
13 Document Parameters Completed X \(UNISYS Terminal)

Exhibit 3.24.159-2 
Section Parameters

16*Section Parameters
Reference Text: IRM 3.24.159.4.3.1, Section Parameters
★ = These parameters are optional.
★★ = Leading zeros need not be entered.
Record Element Number (En) Record Element Name Format Valid Range and Meaning
1 Section Number 99 ★★ Numeric
2 ★ Section Required XXXX REQS – Required Section
NREQ – Not required
Default = NREQ
6 Section Parameters Completed X @ (UNISYS Terminal)

Exhibit 3.24.159-3 
Field Parameters

Field Parameters
Reference Text: IRM 3.24.159.4.4.1, Field Parameters
★ = These parameters are optional.
★★ = Leading zeros need not be entered.
Record Element Number (En) Record Element Name Format Valid Range and Meaning
1 Number of Characters 999 ★★ Three digit numeric
2 ★ Field Type XXXX NUME – See IRM 3.24.159.4.4.1.
ALPH
LSGN
Default = NUME
3 ★ Mixed Field Check XXX9 MIXn – Mixed field check
NMIX – No mixed field check
Default – NMIX
4 Field Parameters Completed X + (UNISYS Terminal)

After the last field parameter for the last section of the document has been completed, the Special Section "99" must be included per IRM 3.24.159.4.3.1(2) Section Parameters. The Special Section "99" is then followed by the parameters completed indicator shown below:

Record Element Number (En) Record Element name Format Valid Range and Meaning
★ = These parameters are optional.
★★ = Leading zeros need not be entered.
Parameters Completed X [ (UNISYS Terminal)

Exhibit 3.24.159-4 
Example of Use of Parameters

Edited Output for Form XYZ-A
Reference Text: IRM 3.24.159.6, Examples of the Use of Parameters, in the preparation of parameters for a mainline document

Reminder:

Note defaults as previously described for each parameter type (document, section, and field).

PARAMETERS
Initial GMF-Mainline_Doc Set-Data Pic X(17)
Problem Codes Pic X(4)
Section Number Pic 9(2) (01)
EIN Pic 9(9)
YR Pic 9(6)
Net Profit/Loss Pic S9(11) Sign Leading Separate
Section Breaker Pic X (@)
Problem Codes Pic X(4)
Section Number Pic 9(2) (02)
Business Code Pic X(4)
Depreciation Pic 9(10)
Loophole Deductions Pic 9(10)
Golden Parachute Fund Pic 9(10)
Section Breaker Pic X (@)
Problem Codes Pic X(4)
Section Number Pic 9(2) (03)
Swiss Accounts Pic 9(20)
Import/Export Credit Pic S9(11) Sign Leading Separate
Section Breaker Pic X (@)
Document Breaker Pic X ([)
 
0>999>\ Document Parameters
01>REQS>@ Section Parameters
9>MIX1>+ Field Parameters
2>MIX1>+ Field Parameters
10>LSGN>+ Field Parameters
02>@ Section Parameters
4>ALPH>+ Field Parameters
10>+2+ Field Parameters
03>@ Section Parameters
20>+ Field Parameters
10>LSGN>MIX2>+ Field Parameters
99>0>999>FICTITIOUS DOC>R2D2–G.I.>927–99>OS:CTO:AD:SP:IP:EI-99>07102001@[

LSGN conversion will add an additional character to field size output after edits processing. Also, Non-Pipeline projects wishing to suppress any mainline standard data such as serial numbers, document breakers, etc., must code the appropriate suppression parameters accordingly.

Exhibit 3.24.159-5 
Example of Parameters Transmittal

A memo to the Chief, OS:CTO:AD:SP:IP:EI Section from the Section Chief of the responsible analyst's Section is required to transmit parameters. The subject of the memo should be "Transmitting SC Edits Parameters " .

Project No. and Name Operator Class/Format Code Responsible Analyst Name Symbols Extension
Transmittal to SAT Required:
Transmittal to Production Required:
QRZ 0/999 J. Doe M:I:X:X 283–xxxx
SAT Library Version Name: S407
SAT Required Date: 05/15/2012
SAT Sites: CIRSC
UNISYS shared program file name with qualifier: IM555*QRZEDPARAM
Element(s) to be transmitted: 0999
Read/Write Key: None
Production Site/Start Date: CIRSC 01/01/2013
All Submission Processing Sites 01/01/2013
Data Type: Mainline Document
Other Pertinent Information:  

More Internal Revenue Manual