3.24.159 SCRS SC Edits

Manual Transmittal

December 27, 2022

Purpose

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

Material Changes

(1) IRM 3.24.159.1.4 Update to correct IRM title. IPU 21U0827 issued 06-10-2021.

(2) IRM 3.24.159.1.7 Update to correct IRM title. IPU 21U0827 issued 06-10-2021.

(3) Exhibit 3.24.159-5 Update to verbiage. IPU 21U0827 issued 06-10-2021.

(4) Exhibit 3.24.159-5 Update to verbiage. IPU 21U0827 issued 06-10-2021.

(5) Editorial changes made throughout this IRM to update titles, grammar, and punctuation.

Effect on Other Documents

IRM 3.24.159, dated October 6, 2015 (effective January 1, 2018) is superseded. IPU 21U0827 issued 06-10-2021, IPU 21U0936 issued 07-14-2021.

Audience

Wage and Investment Submission Processing Integrated Submission and Remittance Processing operators

Effective Date

(01-01-2023)


James L. Fish
Director, Submission Processing
Wage and Investment Division

Program Scope and Objectives

  1. Purpose: The Integrated Submission and Remittance Processing System (ISRP) is used to process forms and remittances. Data is entered, processed and fed to other IRS systems. This chapter provided instructions for the Original Entry, Key Verification, and Block Edit of tax returns and related data through ISRP.

    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 and Validation (DED) are also used by ISRP (Common Services).

  2. Audience: The primary users of this IRM are Submission Processing employees; ISRP clerks and managers.

  3. Policy Owner: The Director of Submission Processing.

  4. Program Owner: Paper Processing Branch, Mail Management / Data Conversion Section.

  5. Primary Stakeholder: Management officials who rely on accurate data gathered by the ISRP Program.

Background

  1. The Integrated Submission and Remittance Processing (ISRP) System transcribes and formats data from paper returns/documents/vouchers for input into the Generalized Mainline Framework (GMF) and other systems by key entry operators. It also captures check images for archiving. Transaction Management System (TMS) is a COTS product that is an integral part of ISRP.

Authority

  1. The following provides authority for the instructions in this IRM to be performed in support of completing compliance functions to make credits or refunds of any internal revenue tax, processing of non-revenue forms, and administrative support forms.

    1. Title 26 of the United States Code (USC) or more commonly known as the Internal Revenue Code (IRC).

    2. All Policy Statements for Submission Processing are contained in IRM 1.2.1.4, Servicewide Policies and Authorities, Policy Statements for Submission Processing Activities:

    • Code sections which provide the IRS with the authority to issue levies.

    • Congressional Acts which outline additional authorities and responsibilities like the Travel and Transportation Reform Act of 1998 or the Tax Reform Act of 1986.

    • Policy Statements that provide authority for the work being done.

Responsibilities

  1. The Operations manager is responsible for securing, assigning and providing training for the staff needed to perform the task required throughout this instruction.

  2. The Planning and Analysis Staff is responsible for providing feedback and support to local management to achieve and effectively monitor scheduled goals.

  3. The team manager is responsible for assigning, monitoring and controlling the work flow to accomplish timely completion of the tasks required throughout this IRM.

  4. The employee is responsible for applying the instruction present to the assigned task on the ISRP system to accurately convert paper data to electronic data record for proper posting for use by the Service.

Program Management and Review

  1. Program Reports: Below are a list of reports to use to show receipts, production and inventory for the paper return to electronic data conversion process. These reports will be utilized to report and monitor daily and weekly status of the program to completeness.

    • PCC 6040, SC WP&C Performance and Cost Report

    • PCC 6240, SC WP&C Program Analysis Report

  2. Program Effectiveness: Goals will be measured utilizing standard managerial reports by documents processed per hour and completion of each function compared to the established schedule for completion each week. Each function is expected to retain or exceed schedule prior to the program completion date stated in IRM 3.30.123, Processing Timeliness: Cycles, Criteria, and Critical Dates. Quality reviews are expected to be conducted and monitored by local management and corrective action taken to ensure quality products are released to the next function.

  3. Annual Review: Review the processes included in this manual annually to ensure accuracy and promote consistent tax administration. This may be included under responsibilities for a manager.

Program Controls

  1. The reports for the Control Data Analysis, Project PCD, are on the Control-D/Web Access server, which has a login program control.

Terms, Definitions/Acronyms

  1. The following terms or acronyms are utilized throughout this IRM:

    Term Definition
    Key Verification (KV) The operators perform quality review on payments through an electronic method called Key Verification.
    Original Entry (OE) The operators manually key enter data from both scanned images and paper documents.

Related Resources

  1. IRM 3.24.37, ISRP System - General Instructions.

  2. IRM 3.30.123, Processing Timeliness: Cycles, Criteria, and Critical Dates.

Introduction

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

  2. IRM deviations must be submitted in writing following instructions from IRM 1.11.2.2, Internal Management Documents System - Internal Revenue Manual (IRM) Process, IRM Standards, and elevated through appropriate channels for executive approval.

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

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.

Input to the Data Edit and Validation (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.3.2, Operator Class

    2. Format Code - See IRM 3.24.159.3.3, Format Code

    3. Service Center (SC) Block Control Number - See IRM 3.24.159.3.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.

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.

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.

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:IT:AD:SP:PPB.

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.

Output from the Data Edit and Validation (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.5, 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

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

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 Part 1, Subpart 2, SC Data Edit Prep.

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

Parameters

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

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.6.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 cannot 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.

Documents

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

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.3.2.
    E2 Format Code Must always be present and must be delimited by the special character ">" . See IRM 3.24.159.3.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.

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

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

    Note:

    Enter the date in YYYYMMDD format.

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 fields per section can be output from the Edit System. Field parameters must follow the associated section parameters in their sequential order of occurrence.

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.

    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 six fields, each 10 characters long, defined as "NUME" with no mixed field checks.

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.5.3.1, Section Parameters.

Analyst Responsibility

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

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: Information Technology: Applications Development: Submission Processing: Paper Processing Branch (OS:IT:AD:SP:PPB), the responsible section.

  2. Analysts must ensure that the OS:IT:AD:SP:PPB responsible section has received the parameters for each project.

  3. Parameters must be received by OS:IT:AD:SP:PPB 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:IT:AD:SP:PPB 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.

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.

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: Information Technology: Applications Development: Submission Processing: Paper Processing Branch (OS:IT:AD:SP:PPB) 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 affect 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.

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.

Document Parameters

  • See also: IRM 3.24.159.5.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.3.2.
2 Format Code 999 See IRM 3.24.159.3.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)

Section Parameters

  • See also: IRM 3.24.159.5.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)

Field Parameters

  • See also: IRM 3.24.159.5.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.5.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.5.3.1(2), Section Parameters. The Special Section "99" is then followed by the parameters completed indicator shown below where ★ = parameters are optional:

Record Element Number (En) Record Element name Format Valid Range and Meaning
Parameters Completed X [ (UNISYS Terminal)

Example of Use of Parameters

See also: IRM 3.24.159.7, Examples of the Use of Parameters, in the preparation of parameters for a mainline document.

Reminder:

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

Edited Output for Form XYZ-A

Element Picture Clause
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 ([)
 
PARAMETER PARAMETER TYPE
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:IT:AD:SP:PPB-99>07102001@[ Final Entry

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.

Example of Parameters Transmittal

A memo to the Chief, OS:IT:AD:SP:PPB Section from the Chief of the responsible analyst 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/2015
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: