Accessibility Skip to Top Navigation Skip to Main Content Home  |  Change Text Size  |  Contact IRS  |  About IRS  |  Site Map  |  Español  |  Help  

3.17.30  SC Data Controls (Cont. 3)

3.17.30.9 
SCCF Posting Controls

3.17.30.9.4 
Error and Reject Balancing

3.17.30.9.4.9  (01-01-2009)
Pending Adjustments and Deletes

  1. It may be expedient to maintain controls on both the pending adjustments and the pending deletes, keying off from the Adjustment CRL (SCF 11–41) or from the Action Codes 660 (ERS 05–40) and from invalid BPR's (from-to code 4–0) for SCRS (SCF 07–43).

    1. Pending SCCF adjustments represent items which are included in the work inventory but are not reflected in the appropriate count on the SCCF Summaries (SCF 07–42).

    2. Pending deletions from work inventory represent items which have adjusted the appropriate SCCF balances but have not been deleted from ERS, error or reject inventories.

    3. If a large imbalance is identified, report the problem immediately to the CSA as records may have been dropped, omitted, or loaded twice on the files.

    4. Because of differences in individual Submission Processing Campus scheduling, it will be necessary to consider cut-off times for GUF, ERS, etc., adhered to by your campus and to consider these as possible variables to the above procedures.

3.17.30.9.5  (01-01-2009)
Overflow Blocks on the SCCF

  1. The Service Center Control File is limited to 150 control records per SCCF module.

3.17.30.9.5.1  (01-01-2009)
Action for amounts Greater than 150

  1. Whenever the 150th control record attempts to post in batch processing, the block is printed on the Invalid Transcript, SCF–07–43, with Transcript Code MX.

    1. Enter an 8–2 SCFAJ adjustment as the 150th control record to delete the block in the next posting run. (See figure 3.17.30-116)

      Figure 3.17.30-116

      This image is too large to be displayed in the current screen. Please click the link to view the image.

    2. The block will then be deleted from the SCCF and printed on the next Invalid Transcript with Transcript Code 82. (See figure 3.17.30-117)

      Figure 3.17.30-117

      This image is too large to be displayed in the current screen. Please click the link to view the image.

    3. If an on-line SCCF adjustment attempts to post the 150th record with other than From-To Code 8–2, the control record will display as an Invalid Transcript with code MX. Any on-line adjustment with From-To Code 8–2 posts to the SCCF immediately and deletes the module from the SCCF during the next SCF–05 posting run for printing on SCF 07–43 as invalid with Transcript Code (TC) 82.

  2. Any module that has been deleted from the SCCF because of the overflow condition should be manually consolidated and reestablished on the SCCF with Command Code SCFAJ.

    1. Combine any control records with the same From Code, To Code, Posting Date, and cross-reference DLN (if any). Add the document count and money amount of these records to form single control records. If this does not sufficiently reduce the number of records, other consolidations may be necessary.

    2. Reestablish the record on the SCCF using Command Code SCFAJ. Enter each control record, providing as much documentation as possible in the Remarks field, including cross-reference DLNs and the cycles of the original postings. (See figure 3.17.30-118)

    Figure 3.17.30-118

    This image is too large to be displayed in the current screen. Please click the link to view the image.

3.17.30.9.6  (01-01-2009)
End of Year Balancing

  1. End of Year procedures are issued annually on the Submission Processing Website and/or by memorandum. These procedures should be followed to insure that all purged records from GMF, ERS, and GUF are properly accounted for and controlled on the SCCF. Access to EOY Documents, Checklists, and Schedules and reference documents are identified below.

    • http://scmcinfo.mcc.irs.gov/history/startup/index05.asp

    • EOY Document - Mainline Volume 2 - Error Resolution System (ERS Batch) section contains a list of forms that will require actions through the ERS00 conversion process.

    • GMF/SCF EOY Purge/Reformat Conversion Handout - contains a complete list of forms that will require actions through either GMF00 or ERS00 conversion processing.

  2. The EOY Conversion occurs in three phases.

    1. Phase 1 - Final GMF/ERS/SCF in Current Processing Year

    2. Phase 2 - Conversion/Purge Processing GMF/ERS/SCF/GUF

    3. Phase 3 - Start-up Processing - First Mainline in New Processing Year

3.17.30.9.7  (01-01-2009)
EOY Conversion - Phase 1

  1. This Phase represents final GMF/ERS/SCF in the current processing year. Special emphasis should be placed on decreasing and maintaining minimal inventory volumes prior to the end of the processing year.

  2. To prepare for the EOY the following is recommended:

    • Remove ERS lag early in December

    • Encourage Input Correction to order GMF loop register on a shortened turnaround time to ensure closures

    • Emphasis should be placed on reducing on resolving SCCF aged cases in all inventories

  3. In addition to the normal reports that are necessary for balancing the final SCF string of the current year, additional reports should also be utilized for use in balancing and verifying the conversion output. It is strongly recommended that Data Control maintain these final reports and registers with their conversion reports since they are in current year format and cannot be worked by Input Correction.

    • GMF0903 - GMF0944/0945/0946

    • GMF0940 Run Control

    • GMF1001 - GMF - 1041/042/1043 (IMF)

    • GMF1002 - GMF - 1041/1042/1043 (Non-IMF)

    • GMF1040 Run Control

    • GMF1101 - GMF1143/1147/1141/1148/1149

    • GMF1140 Run Control

  4. For the GMF Register, all loops should be requested in the GMF1080 for the final running of GMF and again for conversion processing. See special instructions for preparing the GMF1180 in the GMF/SCF EOY Purge/Reformat Conversion Handout.

  5. Final ERS will run as an abbreviated string that will include only jobs that are required to update suspense activities and good tape records that affect the SCCF database. The specific instructions for the mainframe processing requirements can be found in the ERS section of the EOY Mainline Document Volume.

    1. The balancing of Error and Reject inventories to SCCF will include volumes from all reports except ERS1747. ERS1747 will not be available until after conversion processing is completed.

    2. Complete a partial balance of the Error/Reject inventories to SCCF prior to requesting final GMF15 TEP. This abbreviated string includes ERS05/ERS06/ERS08/ERS83/ERS71/ERS75/ERS77/ERS93/ERS96. For specifics concerning these runs and ERS01 and ERS03, refer to the EOY Mainline document.

  6. For the Final GUF, verify that the purge indicator was set for all master-files in the final running of the year for GUF5149. Review GUF5149 for unmatched records. Balance the output as normal for TEP release.

  7. The Final SCFshould be balanced as normal and file/tape input verification is imperative to ensure that all transactional records contained on outstanding files and/or tapes from the current processing year are processed through GMF successfully.

    1. Verify the master control record files/tapes in GMF0440 and the good block proof record files/tapes in GMF0140.

    2. Balance all SCCF run controls and verify inputs to SCF01.

    3. Ensure GUF files (GUF5201 to GMF01 and GUF5104 to SCF01) are processed in the final SCF runstream.

  8. It is imperative that Data Control Units and their respective Enterprise Computing Centers partner in identifying all outstanding tapes/files prior to final mainline.

3.17.30.9.8  (01-01-2009)
Conversion/Purge Processing - Phase 2

  1. At the end of each processing year, special GMF, ERS, and GUF programs are generated to purge and/or reformat end-of-year inventories in BOBs, ERS Errors and Rejects, GMF Errors and Rejects, and Unpostables. There are several terms associated with Conversion/Purge processing.

    • Reformat - Format change required to the sub-program to allow processing in the new year

    • No reformat - No change required to the sub-program, record remains in current format

    • Purge - Record must be removed from the inventory where it currently resides and then reinput, except IRP, it is deleted and not reinput

  2. End-of-Year programs are always run at the end of the calendar year but can also run at other times during the year, when major changes occur in certain processing programs.

  3. The exact scheduling of end-of-year runs is determined by the Enterprise Computing Centers. Often a series of purge runs must be completed within a specific time frame, such as over a holiday weekend, requiring Accounting support outside their normal tour of duty.

  4. The ERS00 Conversion program executes the necessary reformatting and purging of ERS records for compatibility with the programming updates scheduled for the upcoming year. The ERS00 provides a list of actual records processed through conversion and the ERS0049 reports the actual volumes input and output. Listed below are the ERS Run Controls.

    • ERS0040 - ERS Conversion Record List

    • ERS0049 - ERS Conversion Run Control

    • ERS0149 - ERS Run Control Report

    • ERS0649 - ERS Transaction File

    • ERS0749 - ERS Unworkable File Run Control

    • ERS1349 - ERS Workable File Run Control

  5. Identified below are the ERS conversion verifications/validation requirements:

    1. ERS0040 - verify that any program records that were scheduled for the purge have the "P" in the purge indicator column of the ERS0040.

    2. Purged items - Verify status on SCCF database once the SCF Purge runs are completed, locate the documents and reinput.

  6. ERS0049, Input Controls Validation as part of the ERS conversion are listed below:

    1. ERS0049 total count for ERR-REC-UNWK-OLD-FILE (IN) plus (+) ERR-REC-WORK-OLD-FILE (IN) equals (=)the total count listed on the last running of ERS1349 under ERS-CTRL-REC-WORK-FILE WORKABLE CONTROL RECORDS minus (-)the total count on the last running of ERS0649 under the Output Controls and listed as ERS-TRANS-FILE TRANSACTION RECORDS.

    2. ERS0049 total count for ERS-UNWK-FILE (IN) equals (=) the total count for ERS-UNWK-FILE UNWORKABLE SUSPENSE RECORDS on the last running of ERS0749.

    3. Verify the ERS0049 input control totals match the output control totals (minus purged items if applicable).

  7. Following verification/validation of the ERS00 by Data Control, the computing center will complete the remaining ERS jobs under the new year's programs, including the database runs and ERS17. Output totals from the ERS1747 run control will be used to complete the ERROR/Reject balance that was started when the final GMF/ERS/SCF was generated. This ERS Error and Reject inventory balance must be completed to verify that the ERS conversion was successful and that all databases are accurate.

  8. For balancing discrepancies between Error/Reject Inventories and SCCF, the following information may help with the reconciliation:

    1. Identify the forms categorized as reformat, no reformat, and purge within the inventories that require conversion processing (ERS error and reject inventories). Refer to the EOY Document Mainline Volume 2 - Error Resolution System (ERS Batch) section which contains a list of forms that will require actions through the ERS00 conversion process.

    2. There will be variances in counts if records were purged for reinput because the updates (from and to codes 3-0) have not yet been processed to SCCF. The ERS1701 from the ERS conversion processing will be input to SCF01 during the SCCF Purge processing. This input file will update the inventories in the database and will account for the activities on the SCF-11-41 Adjustment List.

    3. There may be variances in the counts associated with suspense activities (items moving to suspense). This variance will occur when ERS items have specific reject condition codes that automatically move the documents through Error to Rejects.

  9. The GMF00 CONVERSION program executes the necessary reformatting and purging of GMF records (GMF10 errors, GMF11 rejects, GMF09 BOBs) for compatibility with the programming updates scheduled for the upcoming year. GMF0040 reports the volume processed through conversion and also lists the activity volume (reformat, no reformat, purge). Identified below are the GMF Run Controls:

    • GMF0040 - GMF Conversion Run Control

    • GMF0940 - BOB File Documents in BOB Blocks

    • GMF1040 - Error Doc File Error Documents

    • GMF1140 - Reject Master File Reject Documents

  10. Refer to the Purge/Reformat Conversion Handout to identify the forms that are being reformatted, not reformatted, and purged in GMF.

  11. Identified below are the GMF conversion verification/validation requirements.

  12. Balance and validate the GMF0040 Conversion Run Control to the final year end reports for GMF0940/GMF1040/GMF1140.

    1. Validate correct files were input for conversion. The counts in the section labeled "Input Control Counts Balancing" and the column labeled "Counts Generated in Display Run" for each of the GMF0940, GMF1040, and GMF1140 should equal (=) counts reported on the GMF0040 in the section labeled "Input Control Counts Balancing" and the column labeled "Counts Generated in Prior Run" .

    2. If these counts differ, immediately notify the designated Enterprise Computing Center and request Operations to verify the input file.

  13. Balance and validate the GMF0040 input/output counts as follows:

    1. The counts in the section labeled "Input Control Count Balancing Section" under the column labeled "Counts Generated in Prior Run" should equal (=) the column labeled "Counts Generated in This Display Run."

    2. This balancing validates the output file as correct and ensures inventories are correctly formatted under the new programming.

  14. Verify the GMF0040 counts to the conversion output for GMF0940/GMF1040/GMF1140.

    1. THE GMF0040 counts in the section labeled "Input Control Count Section" and the column labeled "Counts Generated in Prior Run" should equal (=) the counts generated in the section labeled "Input Control Counts Balancing" and column "Counts Generated in Display Run" column of each of the conversion run control reports for GMF0940/1040/1140.

    2. This balancing verifies that the GMF09/10/11 runs were processed with the correct input file from GMF00 conversion.

  15. Validate Reformat, No Reformat, and Purge counts.

    1. Validate the number of Reformat, No Reformat, and Purge documents according to the form and program list in the GMF/SCF Purge/Reformat Conversion Handout.

    2. IF forms were scheduled to be purged that were in the inventory at the time of conversion, verify the purged counts to the GMF1043/1143 by actual program number.

  16. Verify GMF0040 Output control counts.

    1. Compare output totals and verify that all disposition (purged) records sent an adjustment to the SCCF.

    2. The error disposition records should equal (=)the count listed for MNLN SCCF CTL FILE: SCCF RECORDS.

  17. In GMF0040-IRP, verify all IRP is listed in the Purge column.

  18. If there are discrepancies in count balances encountered during the GMF conversion verification/validation, from 3.17.30.9.8 (12) through (17) above, research by specific program in the GMF10 and 11 summary reports to identify the variance.

    1. Report discrepancies that may be processing problem related to the Enterprise Computing Center.

    2. On rare occasions records may be dropped from processing during conversion, not attributable to computing center operational error.

    3. Data Control is responsible for the identification, research, recovery, and resolution of these records.

  19. Balancing the SCF Purge string is similar to daily balancing routine, verify worksheet totals and inventory balances; also verify all from and to dates and cycle information.

  20. Schedule the ERS1701 (from conversion) to be processed through the SCF Purge string. If the ERS1701 was not processed it may still be processed during the first running of SCF programs in the new processing year.

  21. The following purged inventory from and to codes will be listed on the SCF11-41, Adjustment List:

    • Items purged in GMF00

    • Items purged in ERS00

    • Items automatically move to ERS Suspense (from and to code 3-4 to Rejects)

  22. SCCF Database activity during conversion is described in this tridoc. GMF conversion processing moves error and reject records to manual status (3-0 and/or 4-0) and deletes IRP errors on the SCCF database (3-2). Occasionally, a non-remittance program may be purged without subsequent processing with a (from-to code) to code of 2.

    1. The purged records are on the SCCF 11-41, Adjustment CRL, with From-To codes of 3-0 and 4-0 and require reinput processing. IRP error deletes are reflected in the From-To Codes 3-2.

    2. The Intermediate Error File-Total Documents on page 8 of GMF 08-40 plus the Raw Documents to GMF Error Status on page 5 of GMF 07-40, and the SCF 07-42, Control File Summaries, should decrease by the count reflected on the SCF 11-41.

    3. The Intermediate Reject Files-Total Documents on page 9 of GMF 08-40 plus the Raw Documents to Reject Status on page 5 of GMF 07-40 and the SC Reject balances on the SCF 07-42, Control File Summaries, should decrease by the count reflected on the SCF 11-41.

    4. The manual SCCF balances on the SCF 07-42, Summaries, are increased by the count of the From-To Codes 3-0 and 4-0 records on the SCF 11-41.

  23. The majority of GUF Conversion is completed systemically. Verify the output controls to validate the purge process and to ensure no records were dropped or removed from the database during conversion processing. Manual balancing will also identify when system error messages were mistakenly overridden during mainframe processing. Refer to EOY Document Volume II which provides information concerning the specific conversion routines. Listed below are the GUF Controls:

    • GUF0049 = Conversion Run Control

    • GUF8649 = Conversion Run Control

    • GUF8749 = Conversion Run Control

    • GUF8849 = Conversion Run Control

    • GUF5140 = List of Unmatched Database and Transaction File Records

    • GUF5149 = Extract Run Control Report

    • GUF1349 = GUF Run Control

    • GUF1549 = GUF Run Control

  24. Listed below are GUF conversion verification/validation requirements.

    1. GUF0049 to GUF1549 - Input Section - Validate the Data Records Read by GUF00 and Database Records Per GUF15 match and equal the Output Section labeled Records Written to GUF1501 File on the last running of GUF1549.

    2. GUF0049 to GUF1349 - Input Section - Validate the Data Records Read by GUF00 and Data Records per GUF13 match and equal the total reported in the Output Files Section labeled Cumulative-RPS-610-FIle-Out on the last running of GUF1349.

  25. Listed below is the verification/balancing of the GUF86-RUN-CONTROL-REPORT.

    1. Compare the GUF5101 UPDATED-SC-UP-TRANS-FILE output control count (from the final running of GUF-51-49 RUN-CONTROL-REPORT) should equal the GUF5101 INPUT RECORD COUNT which is listed under the Control Counts Total column of GUF-86-49 in the record count and amounts. The GUF5101 OUTPUT RECORD COUNT (GUF-86-49 listing should equal the GUF5101 INPUT RECORD COUNT, less the total of Dropped Cases and their amounts (GUF-86-49 listing).

    2. All record counts and PJ amounts on the GUF8649 should be zero except under the "CAWR" heading, since records for the other master files should have been purged by GUF51.

    3. The LIST OF DROPPED CASES on the GUF-86-49 should be used to reinput a deleted document as raw data, unless the case has already been closed (refer to GUF-57-40 CLOSED-UNPOSTABLE-REGISTER listing), using the TIN as the identifying key.

  26. The GUF-86-49 does not always display the list of dropped records. If there are dropped record counts and/or amounts on the GUF-86-49, but nothing specific listed on the dropped cases list, request a filecracker extract from the computing center to identify the taxpayer and transaction information for reinput processing.

  27. Review the GUF-86-49 to identify any dropped records that will require reinput processing. If the dropped record count is excessive, contact the enterprise computing center to initiate research to identify why the records were dropped.

  28. The GUF8749 verification/balancing is presented below.

    1. Verify the GUF5301 Input and Output record counts and amounts are the same.

    2. If they differ, the difference will be listed in the deleted section by masterfile, The specific taxpayer data will be listed in the dropped records section if any records are deleted.

    3. Verify that the total masterfile document counts on the GUF8749 equal the count listed on the final GUF5149 in the section labeled, Output Control Counts (GUF5102) as Transaction Records Purged.

  29. To perform GUF8849 verification/balancing, the Database Records Extracted from GUF-Area listed in the Input Section of the GUF8849 should equal the Records Initialized with Purge Ind on the final GUF5149 in the section labeled GUF-Area SC-Unpostable-Rec Control Counts.

3.17.30.9.9  (01-01-2009)
Start-up Processing-Phase 3

  1. Start-up processing is scheduled by the computing centers and a HUB site is designated to balance the initial mainline of the new year with updated programming. All tapes and/or files that have been held awaiting mainframe programming changes are scheduled and processed during the first mainline of the new year. Depending on the calendar dates and the cut-off period, multiple files/tapes may be included in the first running. For example, there are generally multiple tapes/files for Lockbox and ISRP RPS due to ongoing deposit processing. It is crucial that all sites are aware of outstanding tapes/files and verify inputs to GMF01, GMF04, and SCF01, to ensure all data is processed timely.

  2. Report anomalies associated with programming updates to prevent recurrences and negative downstream impact. The following actions are recommended to ensure programming deficiencies are identified and reported quickly:

    • Verify all outstanding tapes/files are processed through the first GMF/SCF mainline.

    • Be aware of all programming changes that directly impact mainline processing.

    • Review and analyze all SCF error codes that could be associated with EOY programming changes.

    • Review and analyze all SCF Invalid Transcripts that could be associated with EOY programming changes.

    • Report all anomalies immediately to ECC via the Help Desk.

3.17.30.10  (01-01-2009)
Delete Operations

  1. Delete operations are outlined in the following procedures.

3.17.30.10.1  (01-01-2009)
Types of Deletes

  1. When a block of documents on the transaction tape is in error, the block is identified for possible deletion by the Tape Edit Processing (TEP) run, GMF–15. Records can be deleted in TEP three different ways.

    1. If the SCCF identifies an inconsistency between the transaction Good Block Proof Record and the existing SCCF file, a delete record is generated onto the on-line delete file, where Data Controls will determine if the block should be deleted. A printed Block Delete Request List, SCF–03–41, may be used in conjunction with the SCFDL file to control the SCCF deletes. (See figure 3.17.30-119)

      Figure 3.17.30-119

      This image is too large to be displayed in the current screen. Please click the link to view the image.

    2. If Data Controls identifies a block that should not be allowed to post, a record is added manually to the on-line delete file.

    3. The TEP program may identify and delete a block due to incorrect tape record length, format, or record balance. These records are deleted without being processed through the on-line delete file.

  2. The Delete Source Code identifies the method of deletion and determines the effect the delete will have on the SCCF.

    1. TEP generated deletes, not created from the delete file, are coded with Delete Source Code C.

    2. Delete records created by the SCCF by an Invalid Transcript contain Delete Source Code S. These records are worked by Data Controls, who will determine whether the block should actually be deleted.

    3. Any other block that is determined to be invalid or incorrect may be deleted by adding the record to the on-line delete file. This record contains Delete Source Code M or S, depending on whether the Good Block Proof Record should be automatically reversed on the SCCF.

3.17.30.10.1.1  (01-01-2009)
Trans Deletion Control Record

  1. Every TEP deletion will generate a Trans Deletion Control Record for the SCCF.

  2. This record will turn on the Action Delete Status Indicator (ADSI) which prevents Block Proof Records from posting. The ADSI is turned off and Block Proof records can again post only after:

    1. The error and reject balances on the SCCF have been reduced to zero, or

    2. A SCCF adjustment with From-To Code 8–7 has posted to turn off the ADSI.

  3. Each Trans Deletion Control Record with a Delete Source Code of "C" or "M" will also post a SCCF adjustment with a From-To Code 5–0.

    1. This will reverse the Good Block Proof Record and place the count and amount back into a suspense balance.

    2. If the Delete Source Code is "S" , no from-to code will post with the Trans Deletion Control Record. If an adjustment is required, input Command Code SCFAJ.

3.17.30.10.1.2  (01-01-2009)
Blocks Deleted at ECC

  1. A block can still be deleted after the media is transmitted to ECC for processing. There are two types of ECC deletes.

    • ECC-generated deletes detected by computer analysis

    • Requested by ECC

  2. Both TEP and ECC deletions may leave pending transactions affecting module balances on IDRS. These pending transactions should be deleted from IDRS by Data Control or by User Support function, according to local agreement.

3.17.30.10.2  (01-01-2009)
Command Code SCFDL

  1. Each Good Block Proof Record that fails to post to the SCCF in SCF–03 is listed on the Block Delete Request List (SCF–03–41) and placed on the on-line delete file.

  2. Enter Command Code SCFDL to access the delete file. (See figure 3.17.30-120) The response to SCFDL is a display of the daily delete records on the file.

    Figure 3.17.30-120

    This image is too large to be displayed in the current screen. Please click the link to view the image.

3.17.30.10.2.1  (01-01-2009)
Delete File Process

  1. Only one delete request file can be processed at a time. After each running of SCF–03, a delete file is created and a listing printed. This file must be worked promptly and released for the running of SCF–15, which downloads the delete request file and formats the deletes for processing to the TEP, GMF–15.

  2. SCF–15 must be run to download the daily delete file before running the next SCF string so that the delete file will be empty and will accept deletes from the next SCF 03.

  3. If the previous delete file is still on-line (SCF 15 has not been run) when a new SCF 03 is completed, the delete file will not accept deletes from the new SCF 03.

    1. When the previous delete file has been released by the running of SCF 15, any blocks to be deleted in TEP from the new SCF runs must then be added manually to the delete file using SCFDLA.

    2. If there is a large volume of deletes to be added to the delete file because the previous delete file was not downloaded on time, it may be appropriate to rerun SCF 03 to create the proper delete file.

  4. SCF 15 must be run to download the previous delete file even if that file contained no delete records. Also, be sure to run SCF 15 (without GMF–15) whenever SCF 03 is to be re-run.

3.17.30.10.2.2  (01-01-2009)
SCFDL

  1. As each Invalid GBP Transcript is worked, use Command Code SCFDL to access the delete file. Enter the appropriate Action Code in the Action column to update records on the file:

    1. Code R—Remove a record from the delete file. If an error coded Good Block Proof Record should not be deleted in TEP, Code R will code the record for removal from the delete file. If the record was coded for removal by mistake, overlay the R with a D to indicate that the record should be deleted.

    2. Code D—This code is used to indicate that the record should be deleted in TEP. This is for information only, since every record on the delete file not marked with an "R" is passed against the transaction file in TEP, whether coded with A or D or not coded at all. If Code D is present, this merely indicates that the record has been worked.

  2. After all coding is complete to remove or delete each record, the screen must be transmitted. Proper movement in this screen is critical, especially when there are multiple pages.

    1. To transmit the SCFDL screen use the down arrow key to get to the bottom line of the screen (line that contains employee and page number) and thentab twice to move to the bottom far right corner of the screen before transmitting.

    2. Terminal response will be Request Completed . It is recommended that the user access SCFDL after transmitting and receiving the Request Completed message, to ensure the coding input by the user was maintained in the screen.

      Note:

      Failure to navigate within the SCFDL screen (when pages are involved) as instructed above will cause records to be dropped from the display and/or duplicated from one page to a subsequent page. Although the TIP50 file that contains the records is not affected, the display will not be accurate for additional coding.

3.17.30.10.2.3  (01-01-2009)
SCFDLA

  1. To add a record to the delete file, enter Command Code SCFDL with definer A. The response to SCFDLA is a twelve line, X-filled screen. (See figure 3.17.30-121)

    Figure 3.17.30-121

    This image is too large to be displayed in the current screen. Please click the link to view the image.

  2. Complete the record by overlaying the X's in the format provided. Figure 3.17.30-122 shows the completed record.

    1. MFC is the master file code (1 = IMF, 2 = BMF, 3 = EPMF, 5 = IRP, 6 = NMF).

    2. Enter the block DLN with year digit (no hyphens).

    3. Enter the Delete Source Code (DSC). Enter code M if a 5–0 control record should post to the SCCF, or code S if the SCCF status should not be updated.

    4. Enter the 14–numeric tape sequence number from the Tape Control Record List (SCF–11–51). Not applicable for NMF.

    5. The Alpha Block Control (ABC) is optional.

    Figure 3.17.30-122

    This image is too large to be displayed in the current screen. Please click the link to view the image.

  3. Up to 12 delete records may be added on one screen at a time. When all delete records have been entered, use the down arrow key to get to the bottom line of the screen and immediately transmit. If all records have been entered in the proper format, they are added to the delete file in DLN sequence by master file. (See Figure 3.17.30-123)

    1. If more than 12 deletion records need to be added, then a new SCFDLA screen request must be entered. The SCFDLA program does not have multiple pages.

    2. Terminal response will be Request Completed. It is recommended that the user access SCFDL after transmitting and receiving the Request Completed message, to ensure the coding was maintained in the screen.

      Note:

      Failure to transmit from the correct position at the bottom of the SCFDLA screen as instructed above may result in a loss of the data that was entered.

    Figure 3.17.30-123

    This image is too large to be displayed in the current screen. Please click the link to view the image.

  4. If any added record has not been entered in the correct format, an error message is displayed, with the invalid field highlighted.

    1. The entire screen is retained until the error is corrected or the invalid record blanked out and the screen has been successfully transmitted.

    2. The action code, master file code, block DLN, delete source code, and tape sequence number are validity checked.

  5. If the format was valid but a mistake was made in entering a record, either because the block should not be deleted or because a field was transcribed incorrectly, overlay the generated "A" with an "R" and the delete request will not be processed. Then use SCFDLA to re-enter any record that should be deleted.

  6. Until the file is released for processing to the Tape Edit Processing (TEP), any code may be overlaid with another code or changed to a blank.

3.17.30.10.2.4  (01-01-2009)
NMF Records

  1. The generated delete file cannot include Non-Master File records because NMF good block proof records are input through SCFAJ.

    1. Use of the alternate method (Form 4028 through ISRP) will result in invalid records appearance on the daily delete file with blank tape sequence number. These should be worked in the normal manner on the Invalid Transcripts, SCF 07–43.

    2. NMF records may be added to the delete file using SCFDLA. Leave the tape sequence number blank. SCF–15 will create a file which is passed through SCF–01 to correct NMF revenue receipts in SCF–13. No NMF records are passed to the TEP, GMF–15.

3.17.30.10.2.5  (01-01-2009)
Worked Records

  1. As soon as all records on the delete file for the day being worked are coded, notify the Computer Center that SCF–15 and GMF–15 should be run. The printed list may also be annotated to indicate that each record has been worked.

  2. Command Code SCFDL may be up while most other real time commands are down. However, if the TEP must be run while real time is down, and Data Controls has not had a chance to access the delete file, all of the records on the Block Delete Request List would normally be deleted. The only alternative, other than to delay the run until the delete file can be accessed, is to advise the Computer Branch to run the TEP without the delete file, thus allowing all transactions to be processed to the master file.

3.17.30.10.3  (01-01-2009)
Generated TEP Deletes

  1. Any block that is identified by the TEP programs as invalid or inconsistent will be deleted automatically by the TEP.

  2. These generated deletes carry a source code C, which is printed on the Deleted Records List and the Adjustment CRL.

  3. See 3.17.30.11.5 for an description of the two-alpha delete codes, which explain the reason for the generated delete.

  4. TEP deletes may be generated from corrected unpostables from the GUF.

  5. For corrected unpostables, no special procedures are required, unless the Deleted Records List fails to show all of the required information. If unable to identify the records being deleted, contact a Computer System Analyst (CSA) to obtain a complete copy of the deleted record from the transaction tape.

3.17.30.10.4  (01-01-2009)
ECC Deletes and Rejects

  1. A deletion is the removal by ECC of an entire block of data from a Transaction Tape. After a transaction is under ECC Control it is either "Posted" , "Deleted" or sent "Unpostable" . Control is maintained under the original DLN module on the SCCF and the prejournalized amounts must be added to SC suspense accounts and subtracted from the ECC Suspense accounts. Requests for ECC-MTB deletes from the Submission Processing Campuses will not be honored under the CADE processing environment.

  2. Deletions from TEPs which are transmitted electronically must be promptly identified and telephonically requested prior to input of the transaction tape at ECC. Once ECC has input a transaction tape, blocks can no longer be deleted unless authorized by the ECC Operations Branch Chief.

  3. When a determination is made in the Submission Processing Campus that a block should be deleted from a good tape file at ECC, the following procedures will be taken:

    1. If the block requiring deletion is on a TEP that was sent to ECC via electronic data transfer (EDT), immediately call ECC Production Control, FTS 304–264–7500, to expedite deletion prior to input of the tape.

    2. Deletions from the regular TEP may be requested by calling ECC as in (a) above. In either case, record the time, date, and the name of the person called, in addition to the required information on the blocks to be deleted.

    3. If the requested delete is an ELF block, inscribe the DLN on the GMF 15–45, Trans Release Summary, ELF Total Summary, under caption "Blocks to be Deleted at ECC." Enter the data requested in the headings of the caption.

    4. If the block is a regular block, inscribe the DLN on the GMF 15–45, Trans Release Summary, Other Total Summary, as in (c) above.

3.17.30.10.4.1  (01-01-2009)
Document Perfection Procedures

  1. If appropriate, notify Input Correction Operation to have error registers rejected and reject registers deleted, in accordance with local procedures. Reject registers are coded 2–R and ERS records are cleared with Command Code RJECT, action code 660. Requests for ECC deletes from the Submission Processing Campuses will not be honored under the CADE processing environment.

3.17.30.10.4.2  (01-01-2009)
SCCF Control

  1. For SCCF control, turn the ADSI on with From-To Code 7–7 to ensure deletion of documents which might be worked by Input Correction Operation.

  2. Do not adjust the RRCS or the TEP Summaries.

3.17.30.10.4.3  (01-01-2009)
ECC Acceptance Voucher Summaries

  1. On a weekly basis the ECC-MTB Trans Release File Acceptance Voucher Summaries, Run 793-01, will be available on EONS/Control-D. Verify the totals against that cycle's SCF11-51, TCRL, and GMF15-45, TEP, totals. (See figure 3.17.30-124)

    Figure 3.17.30-124

    This image is too large to be displayed in the current screen. Please click the link to view the image.

  2. On a daily basis, Accountability Acceptance Vouchers (AAV) for CADE (CAD-BP-15), IMF(CAD-BP-16), and a CADE and IMF summary (CAD-BP-17) will be available for verification on EONS/Control-D. (See figure 3.17.30-125)

    Figure 3.17.30-125

    This image is too large to be displayed in the current screen. Please click the link to view the image.

  3. On a weekly basis, AAV for CADE (CAD-BO-15), IMF (CAD-BO-16), and a CADE and IMF summary (CAD-BO-17) will be available for verification on EONS/Control-D.

  4. All AAVs will be available on EONS/Control-D for viewing, ECC will no longer mail the AAVs to the SPCs. The weekly summary report will reflect all cycle deletes by reel and Work Group Number.

    1. Adjust the CRL in green if SPC requested, blue when ECC initiated, and/or attach a copy according to local procedures.

    2. Forward the voucher to IRACS for adjusting journal entry.

    3. If needed, prepare Form 2275 to get the documents for input from Perfection Branch or Files.

    4. Input SCFAJ with From-To Code 5–0 and Source Code D to place the deleted block back into suspense if the documents will be reinput with Form 3893.

    5. For NPJ IDRS records, no SCCF adjustment is necessary. Route a copy of the listing to the IDRS coordinator, who will determine if reinput is necessary.

    6. An attachment to the acceptance voucher also lists any Submission Processing Campus cartridge that may have been returned as unprocessable.

    7. Whenever the acceptance voucher indicates that a cartridge has not been processed, contact the Help Desk to ensure that a recovery effort has been initiated. The initial contact from ECC may have been received by telephone.

    8. If any returned cartridges have not been resubmitted and processed within three cycles, be sure to notify the Computer Site contact with the date of the original transmission and any details that are available.

3.17.30.10.4.4  (01-01-2009)
Revenue Receipt Summary Reports

  1. Reconcile the weekly revenue receipts summary reports to the ECC Accountability Acceptance Vouchers. If the reports do not reconcile to a voucher, notify the Information Systems Division Chief immediately.

3.17.30.10.4.5  (01-01-2009)
Documents Deleted or Rejected

  1. Any documents deleted or rejected at ECC that must be reinput should be considered at the earliest possible time for IDRS action to suppress erroneous balance due and delinquency notices.

    1. At Submission Processing Campus option, every document deleted for reinput may be referred to Collection for determination and input of action to suppress erroneous notices.

    2. If the action is to be input by Accounting, every BMF return that is more than ten weeks past the due date or IMF return more than six months past the due date requires prompt input of Command Code FRM49 with Transaction Code 599, closing code 18.

    3. Every document code 17, 18, or 19 payment transaction requires input of Command Code STAUP for six cycles.

    4. Be sure to annotate "599–18" or "STAUP–6" and the date on each document.

3.17.30.10.5  (01-01-2009)
IDRS Deletes

  1. IDRS deletes are handled much the same way as regular TEP deletes except that many deleted IDRS transactions must be reinput through IDRS. The documents are obtained from Files through the IDRS transaction records.

  2. Determine which transactions can be input through mainline (ISRP). The following transactions may be input only through IDRS, regardless of the method of original input:

    1. Entity Changes for the IMF, BMF, and EPMF (Doc Codes 50, 53, 63, 80, 81).

      Exception:

      EPMF Module Change Form 2363B

    2. Dual Debit/Credit Transfer for IMF and BMF (Doc. Code 34)

    3. Delinquent Accounts and Returns for BMF (Doc. Codes 14 and 49)

    4. Document Codes 78

      Exception:

      IRP

  3. Document Codes 77 except the following:

    1. T/C 460 extension of time for filing

    2. Transaction Codes 023, 024, 053, and 120.

3.17.30.10.5.1  (01-01-2009)
F3893 For Reinput Documents

  1. Reinput the documents which can be processed through mainline. Prepare Form 3893. It is completed the same way as for other tape deletes except as below: (See figure 3.17.30-126)

    Figure 3.17.30-126

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    1. Box 1—Blank

    2. Box 3—Blank

    3. After preparing Form 3893, attach it to the first document and route to Data Conversion to be reinput, or leave boxes 1 and 3 blank and route to Batching.

    4. Edit the documents for proper input. The documents normally will not go to Returns Analysis.

    5. Route the documents which cannot be reinput through mainline to the IDRS Control Staff, the originating function, or an area designated by the Control Staff.

3.17.30.10.5.2  (01-01-2009)
Read Fail Documents

  1. Forward Deleted Records List to IDRS Control Staff for read fails on document code 79, TC 902.

    1. For read failed documents not to be reinput through Data Conversion Branch, prepare a SCCF adjustment with From-To Code 0–2 and CR Source Code D.

    2. Document Code 64 deleted documents should be routed to the Refund Inquiry Group, Taxpayer Relations function.

    3. Data Control should provide User Support function with list of deleted records for IDRS transactions deleted in TEP. Annotate the list with the method of resolution for the deleted records, e.g., reinput through IDRS, reinput through mainline processing, etc.

3.17.30.10.6  (01-01-2009)
RRPS Deletes

  1. Receipt and Control will provide a listing of manual adjustments made to the ISR 05–51, Deposit Summary Report. (See figure 3.17.30-127)

  2. Confirm the manual adjustments made to the RPS Remittance Recap. and the Form 215–A.

    1. If the adjusted monies are not on the RPS Remittance Recap, the block(s) will need to be deleted from TEP.

    2. Research the DLN(s) through CC: SCFTR to determine if the block(s) were processed through GMF and SCCF.

    3. If the DLN(s) have gone to good tape on SCCF, the block(s) will need to be deleted from TEP.

    Figure 3.17.30-127

    This image is too large to be displayed in the current screen. Please click the link to view the image.

3.17.30.10.6.1  (01-01-2009)
RRPS Reinputs

  1. Occasionally a RPS payment must be reinput after the return has posted. Delete the payment DLN from the SCCF database and prepare form 3244 with transaction code 610 to apply the money to the correct account. Renumber the 3244 to a document code 17. Annotate RTR with the new DLN using the "Add Notes" function. Instead of preparing form 3244, the RPS form 813 may be used as the source document for reinput. The form 813 can be printed from RTR. Be sure to coordinate carefully with the Batching and Data Conversion functions when this procedure is used.

  2. RRPS Subsequent Payments may also have to be reinput without the original source document. Receipt and Control will research for taxpayer data on the ISRP Archive System.

    1. Prepare Form 3244 for each item from the Archive Research with a primary TC 670 and a secondary TC 570.

    2. Route to Batching for reinput.

3.17.30.10.7  (01-01-2009)
Resolution of TEP Deletes

  1. Instructions for reading the Deleted Records List are included in 3.17.30.11.5.

  2. Each block that is deleted in TEP generates a control record for the SCCF. If this control record is not error coded on the CRL or appearing on the invalid transcripts, the SCCF module will have been affected in two ways.

    1. The Action Delete Status Indicator is turned on, thus preventing any new Block Proof Records from posting.

    2. If the Delete Source Code (lower right corner) is C or M, the control record will include a From-To Code 5–0, placing the deleted documents back into manual status.

    3. See IRM 3.17.30.11.5 for instructions on reading the Deleted Records List.

3.17.30.10.7.1  (01-01-2009)
Deleted Blocks

  1. If the entire block must be voided, reinput, or renumbered, notify Input Correction to take the necessary action for any documents still in error or reject status.

  2. Pull the required documents according to local procedures

    1. If the documents still being processed are valid and need not be deleted, input Command Code SCFAJ with From-To Code 8–7 to turn off the ADSI. Then pull only the documents that have been deleted and reinput with Form 3893. (See figure 3.17.30-128)

    2. If the block should be voided, input an SCFAJ adjustment for the documents on the Deleted Records list using To Code 2. The From Code will match the current status on the SCCF.

  3. If the block must be renumbered, assign the new DLN according to local procedures,

    1. Notify Input Correction to delete the items still open in the Error or Reject inventory. If ERS code 640 is used, a From-To code of 3–0 or 4–0 will post to the SCCF database.

    2. For ERS, Action Code 660 is entered with Command Code RJECT. At Submission Processing Campus option ERS deletes may be entered on the terminal by Data Controls personnel. When all documents have been deleted from rejects, adjust the SCCF as necessary and establish the new DLN with From-To Code 0–0.

    Figure 3.17.30-128

    This image is too large to be displayed in the current screen. Please click the link to view the image.

3.17.30.10.7.2  (01-01-2009)
Deleted Records List

  1. If the block must be reinput, prepare Form 3893 for the documents on the Deleted Records List and reinput.

    1. Documents on error or reject registers from the same block may be returned to Document Perfection for normal resolution.

    2. No SCCF adjustment is needed if the deletes had source code C or M, other than the From-To Code 8–7 to turn off the ADSI. If source code S, also prepare an adjustment with To Code 0.

    3. The ADSI will prevent erroneous records from posting.

3.17.30.10.7.3  (01-01-2009)
Resolution of Deleted Blocks

  1. All deleted blocks should be reinput or otherwise resolved within two weeks.

3.17.30.10.8  (01-01-2009)
Doc Prep for Form 3893

  1. When it is determined that any documents are to be re-entered into the system, prepare a Form 3893, Re-Entry Document Control.

    1. Any editing on the document must be done with a red pencil. Be sure that the first document in the block contains the proper received date.

    2. Attach the Form 3893 to the first document of the block to be used as a header document.

    3. Route to the Batching function. Receipt and Control Branch for processing.

    4. For certain priority documents, such as PRP, Congressional, and some subsequent payments, hand carry the block to Data Conversion Branch for Transcription.

3.17.30.10.8.1  (01-01-2009)
F3893 Instructions

  1. Only one Form 3893 should be prepared when several documents are being re-entered from the same block, unless the documents are reprocessable.

  2. One Form 3893 should be prepared for each return re-entered as reprocessable.

  3. From 3893 is prepared as follows, (See Figure 3.17.30-129)

    Figure 3.17.30-129

    This image is too large to be displayed in the current screen. Please click the link to view the image.

    1. Box 1—Alpha/Numeric Block Control Number—Leave blank if routing to Batching in the Receipt and Control Branch. If routing directly to Data Conversion, enter the designated alpha.

    2. Box 2—Document Locator Number—Enter the eleven digit block DLN. The complete DLN may be entered, but only eleven digits are transcribed into the block header.

    3. Box 3—Enter the batch number if routed directly to Data Conversion.

    4. Box 4—Document Count—Enter the number of documents attached to Form 3893.

    5. Box 5—Credit Amount—Enter the amount of the credit transaction. If more than one document, enter the sum of the credit amounts. Amounts may be from payment transactions, transfer documents, or adjustments.

    6. Box 6—Debit Amount—Enter the total amount of the debits. This box must be blank if a credit amount is present. Debit amounts may be present only with document code 24, 45, 48, 51, 54, 58, and 87.

  4. Box 7—Transaction code

    1. Enter only when block header transaction code is required.

    2. For IRP, enter the Account Type Code, followed by the Record Identification Code (F or G) followed by the Payer Count. See 3.10.80 for details.


    Document Code
    Transaction Code
    on Document
    Transaction Code
    in block Header
    45 840 840
    53 090–092 090
    51, 52 Transfer in 370
    30 984, 986 984, 986
    80 000, 012, 013, 014, 016 000, 010
    81 000, 016  

  5. Box 8—Trans Date

    1. Always enter the received date for Forms 1040ES and 1040C.

    2. Enter received date for returns received after the tax period due date.

  6. Box 9—Header MFT Code—Enter only when required.

    Document Code Document MFT Header MFT
    17, 18, 19, 24, 34, 45, 47, 48, 51, 52, 54, 58, 87 05, 06, 15 05, 06, 15
    IMF tax class 4 29 29
    Form W–3G 32, 98 32, 98
    Form 1096 69 69
    RRPS Payments Various Same as document
    IRP 74 74 74

  7. Box 10—Secondary Amount—Enter the secondary transaction amount when required. If you fail to enter a secondary amount on Form 3893 when the amount is present on the document, a block-out-of-balance condition will be created.

  8. Box 11—Re-entry Source Code—Mark one box as indicated.

    1. Mark "R" for Reprocessable if the return has already posted to the master file. Also complete box 19.

    2. Mark "N" for Nullified if the reinput document was previously an unpostable. Also complete box 18.

    3. Mark "4" for Reinput if the reinput block/document has neither posted nor unposted at the master file. The "4" should always be used when issuing and processing a new DLN. Also complete box 18. When processing a new DLN, mark "Other" in box 18 and write "New DLN."

  9. Box 12—DLN Year digit—This box must be entered.

    1. Enter the 14th digit of the DLN from the source document.

    2. If the year digit is not shown on the document, determine the correct year from the DLN color or from other information on the document.

    DLN Color Year Digit
    Green 0 or 5
    Purple 1 or 6
    Red 2 or 7
    Black or brown 3 or 8
    Blue 4 or 9

  10. Box 13—RRPS Return Indicator—This box should be marked only when a matching RRPS payment has already posted, with the same DLN except for the incremented julian date, to the same TIN, MFT, and tax period. Never mark this box for reprocessables.

  11. Box 14—Remarks—Enter any additional information needed to clarify the reason for re-entry or to preserve a proper audit trail. For deletes, enter the cycle of the delete action.

  12. Box 15—Process as Remittance or Non-Remittance—Mark the Remittance box if the document or block contains money. Payment vouchers and accounting transactions with doc codes 24, 45, 48, 51, 58, and 87 are Remittance documents. Green-rocker the payment originally input as RRPS if the payment is now being processed with the document and mark Remittance. Returns with green-rockered payments are Remittance unless the payment has already posted to the taxpayer's account; if the green-rockered payment has already posted or if the payment has been removed for separate processing, edit out the "green" money with red pencil and mark the Non-Remittance box. Adjustment documents are Non-Remittance even though header amounts may be present in box 5, 6, or 10. Reprocessable returns are always Non-Remittance.

  13. Box 16—Serial Number—Enter the DLN serial number(s) of the documents being re-entered. For an entire block or multiple documents, enter the range of serial numbers, such as 00–49 or the specific serial numbers.

  14. Box 17—Preparer information—Enter your name and phone number and the current date. Also mark the appropriate originating organization.

  15. Box 18—Reinput document—If box 11 is "N" or "4" , mark the appropriate box.

  16. Box 19—Reprocessable return—If R is marked on item 11, enter the reason that the posted return is being reprocessed.

3.17.30.10.8.2  (01-01-2009)
Edited Documents for Re-entry

  1. Be sure the documents are properly edited for re-entry. Some revenue receipt documents must be edited with the received date if only the first document in a block had been date stamped on initial input.

  2. Form 3893 is prepared by several Submission Processing Campus functions for re-entry of reinput and reprocessable documents. Depending on local procedures, these forms may be reviewed by the Data Control function before being routed to Batching.

3.17.30.11  (01-01-2009)
ECC Tape Releases

  1. Procedures to follow for ECC tape release.

3.17.30.11.1  (01-01-2009)
TEP Controls

  1. Tape Edit Processing (TEP) is the last computer function performed by the Computing Sites and balanced by the Submission Processing Campus before transactions are released to the Enterprise Computing Center.

  2. Consolidation of mainframe operations to the computing centers has resulted in Submission Processing Standards. The Submission Processing Standards timeliness are identified for ERS/GUF, TEP, Feeder Systems, etc., in the 3.30.123, Processing Timeliness IRM.

  3. The GMF TEP should be requested by 11:00 a.m. and received in the Accounting Branch no later than 1:00 p.m. The GMF TEP should be released to the computing center no later than 3:00 p.m. Monday —Friday.

  4. The GUF TEP should be received in the Accounting Branch by 7:00 a.m. on Friday and released to the computing center by 3:00 p.m.

  5. The computing center should be contacted if these timelines can not be met.

  6. The TEP performs the following functions:

    1. Reformats data to be compatible with ECC processing.

    2. Deletes transactions identified as invalid by manual or computer processes.

    3. Adds or removes records from the transaction tape as required by individual programs.

    4. For ELF processing centers and at that Submission Processing Campus' option, the TEP will separate ELF good transactions to create a separate tape file, GMF 15–06.

  7. Confirm ECC receipt of transmissions:

    1. Confirm ECC receipt of the prior day's GMF transmissions through the Automated Tracking Report (ATR), via EONS/Control-D.

    2. If the GMF run(s) are not on the ATR or listed more than once, notify the Automated Help Desk. In addition, notify the ECC PVS (ECC Data Control) contact.

3.17.30.11.1.1  (01-01-2009)
TEP Transmission

  1. After authorizing release of TEP, retain a copy of the following Summaries for the retention period specified in the Records Disposition Handbook, 1.15.2:

    1. GMF 15–45, Trans Release Summary for each file containing data, e.g., Mainline, IDRS, Unpostables Auto-LIEN, etc.

    2. GMF 15–45, Trans Release Summary, Other Total Summary, annotated by Releasing Officer. (See figure 3.17.30-130)

      Figure 3.17.30-130

      This image is too large to be displayed in the current screen. Please click the link to view the image.

    3. For Submission Processing Campuses processing and exercising the option to separate ELF in TEP, GMF 15–45, Trans Release Summary, ELF Total Summary, annotated by Releasing Officer. Be sure the reel number is annotated on the ELF Total Summary. (See figure 3.17.30-131)

      Figure 3.17.30-131

      This image is too large to be displayed in the current screen. Please click the link to view the image.

    4. The GMF 15–45, Grand Total Summary, should be annotated by the releasing officer since it reflects the total of all records included in the TEP. Additional records shown on the Grand Total Summary which are not shown on either the Other Total Summary or the Elf Total Summary are "generated records added" as indicated on the GMF 15–43, Transaction Release Adjustment Report.

    5. SCF 13–40, RRCS (daily, plus weekly at close of cycle)

    6. GUF 53–40, Unpostable Control Report

    7. GUF 53–42, GUF RRCS—Nullified Unpostables

3.17.30.11.1.2  (01-01-2009)
ELF TEP

  1. For ELF centers, ensure that "SCCF Released" on the Trans Release Grand Total Summary includes both the "ELF TEP Released" and the "Other TEP Released" from IMF Mainline.

3.17.30.11.1.3  (01-01-2009)
Release Summary

  1. Tape File GMF1545MCCPR contains an IBM compatible quartet print file containing the Release Summary, GMF–15–45. The GMF1545MCCPR tape should be retained by the computing center for 30 days to be printed if requested by Accounting, in the event of a problem in balancing tape release data to ECC or to the SCCF. This print tape is no longer shipped to ECC.

3.17.30.11.1.4  (01-01-2009)
IRACS TEP Instructions

  1. The GMF 15 outputs a tape, GMF 15–05, which has interface capability with IRACS for automatic journalization of mainline, IDRS, and unpostable transactions on the TEP.

    1. Promptly coordinate with IRACS on any GMF 15, TEP, that is re-run and/or not released for shipment to ECC.

    2. GMF 15–45 paper documentation should be sent to IRACS for confirmation and comparison with the Daily Posting Summary.

3.17.30.11.1.5  (01-01-2009)
TEP Retention

  1. File one copy of each TEP listing with the CRL.

    1. Deleted Records List, GMF–15–42.

    2. Transaction Release Adjustment Report.

    3. Trans Release Summary.

    4. Unmatched Deletes List, GMF–15–41.

3.17.30.11.2  (01-01-2009)
Release of Non-TEP Transactions

  1. Every tape transmission to ECC must contain summary count and amount information, even for transactions that are not processed by the TEP.

3.17.30.11.3  (01-01-2009)
Invalid Deletes List

  1. After the delete file (SCFDL) is released for processing to the TEP, the SCF–15 is run first to download the daily on-line delete file. The deletes are validity checked in the GMF–15 run; any deletes failing to meet the validity checks are printed on the Invalid Deletes List and output to Data Controls with the other GMF–15 runs for the TEP. (See figure 3.17.30-132)

    Figure 3.17.30-132

    This image is too large to be displayed in the current screen. Please click the link to view the image.

  2. As all delete requests have already been validated by SCFDL, any record appearing on the Invalid Deletes List should be reported as a problem with either SCFDL or GMF–15.

3.17.30.11.3.1  (01-01-2009)
Invalid Delete Request Codes

  1. The Invalid Delete Request Code identifies the field that caused the problem.

    1. Code 1 indicates that the block DLN contains other than 12 numerics.

    2. Code 2 indicates that the Trans Tape Sequence Number is invalid. The number must contain 14 numerics and be greater than the prior number.

    3. Code 3 indicates that the Delete Source code is other than S or M.

    4. Code 4, indicating a Record Type ID Code other than D, and Code 5, indicating an invalid master file literal, should no longer be possible.

3.17.30.11.4  (01-01-2009)
Unmatched Deletes List

  1. Each validity checked delete record is matched against the transaction tape during TEP processing.

  2. If the TEP fails to find a matching transaction record, the delete information is printed on the Unmatched Deletes List. (See figure 3.17.30-133)

    Figure 3.17.30-133

    This image is too large to be displayed in the current screen. Please click the link to view the image.

  3. Compare each item on the list with the source document to determine the error.

    1. Locate the block on the Trans Release List.

    2. If the block still must be deleted, annotate the transaction information on the Release List Summary for deletion at ECC.

3.17.30.11.5  (01-01-2009)
Deleted Records List

  1. Each deleted document will print on the Deleted Records List. (See Figure 3.17.30-134)

    Figure 3.17.30-134

    This image is too large to be displayed in the current screen. Please click the link to view the image.

  2. The File ID consists of a numeric identifying the master file plus an alpha to indicate the source of input.

  3. The numeric code has the same meaning as the Master File System ID code which appears on many listings.

    • 1 = IMF

    • 2 = BMF

    • 3 = EPMF

    • 5 = IRP

  4. The second position has the following alpha code:

    • M = mainline

    • I = IDRS

    • U = unpostable

  5. In the Delete Code column, C, M, or S is the Delete Source Code. The C (computer generated) deletes will also include a two-alpha code indicating the reason for the delete.

    1. Code CT indicates that the record count is not numeric or not greater than zero.

    2. Code IC indicates that the transaction record contains invalid characters. This code also identifies transactions that are deleted because the File Location Code in the DLN is invalid for your Submission Processing Campus.

    3. Code IL indicates that the transaction record contains an invalid length.

    4. Code NB indicates that a block of documents contained no balance record. The balance record should be at the end of the record for each block and match the sum of the count and amount for the documents in the transaction block.

    5. Code NT indicates that the block contained no transaction records.

    6. Code OB indicates that the transaction record is out of balance with the balance record in either count or amount.

    7. Code RF is a read fail of either a transaction record or a balance record.

3.17.30.11.5.1  (01-01-2009)
Balancing Counts and Amounts

  1. Immediately under the balance record on the Deleted Records List, a separate set of balancing counts and amounts show the actual totals from the deleted documents. These amounts should always be the same, except when Delete Code OB is presents.

  2. At the end of the Deleted Records List, a summary lists the count and amount of deleted records for each master file and input system. (See figure 3.17.30-135)

    Figure 3.17.30-135

    This image is too large to be displayed in the current screen. Please click the link to view the image.

  3. A Grand Total Summary contains the total count and amount of deleted records.

  4. Check to make sure that all deletes were processed. If any blocks that should have been deleted are still on the Trans Release List, enter the required data at the bottom of the Trans Release Summary for deletion at ECC.

  5. See 3.17.30.10.7 for instructions on the resolution of TEP deletes.

  6. At local option, one copy of the Deleted Records List may be routed to Collection.

    1. Delayed re-entry may cause erroneous balance due and delinquency notices to be generated.

    2. If re-entry is delayed, erroneous notices should be suppressed.

    3. Line out and note "duplicate" for any transactions on the Deleted Records List which were deleted because of duplicate processing.

3.17.30.11.6  (01-01-2009)
Transaction Release Adjustment Report

  1. The Transaction Release Adjustment Report is a summary of records added and dropped by normal TEP processing. (See figure 3.17.30-136) This report is used to reconcile the Release Adjustments count on the Trans Release Summary.

    Figure 3.17.30-136

    This image is too large to be displayed in the current screen. Please click the link to view the image.

  2. This Adjustment Report shows the number of records generated by the TEP and the number of records extracted from TEP for a special file which are not intended for ECC.

  3. The "Generated Records Added" less the "Trans Records Deleted" will equal the "Released Adjustments" count on the summary. No money amount adjustment should ever be present on the release summary. Do not release the tape if any invalid or unexplained adjustments are present.

3.17.30.11.7  (01-01-2009)
Trans Release List

  1. Every block on the transaction tape for ECC is listed on the Trans Release List. (See figure 3.17.30-137)

    Figure 3.17.30-137

    This image is too large to be displayed in the current screen. Please click the link to view the image.

  2. The Trans Release List is printed only upon request. The listing is maintained on tape file GMF1545MCCPR and is retained in the Submission Processing Campus for thirty days.

  3. Request a print of the Trans Release List if unable to balance the Release Summary to the Tape Control Record List, the Unpostable Control Report, or the Trans Release File Acceptance Voucher.

3.17.30.11.8  (01-01-2009)
Trans Release Summary Balancing

  1. The Trans Release Summaries (Other Total Summary and ELF Total Summary, if applicable) are annotated for each tape transmission to ECC. All GMF tapes are processed through router run 793–01 at ECC where separation is made by master file.

  2. In addition to the Other and the ELF Total Summaries, the following Trans Release Summaries are produced:

    • Grand Total Summary (annotation not required) includes the totals of the Other Total Summary and the ELF Total Summary. If the ELF Only TEP BAL62 programs are executed, the ELF Total Summary in the consolidated TEP will contain only those ELF records corrected in ERS. Refer to 3.17.30.11.8.1 (c) for detailed information concerning the IMF ELF Only TEP and automated ELF BAL62.

    • Mainline Summaries for IMF, BMF, EPMF, and IRP.

    • Summaries for IMF, BMF, EPMF.

    • AUTO–UNDERRPT Summaries for IMF.

    • AUTO–LIEN–FILE Summaries for IMF and BMF.

    • Unpostable Summaries for IMF, BMF, EPMF, IRP, and CAWR.

3.17.30.11.8.1  (01-01-2009)
Mainline Trans. Release

  1. The mainline Tape CRL for each master file is balanced to the Mainline Trans Release Summary for the corresponding master file.

    1. Subtract any Mainline deletes listed on the Deleted Records List, GMF 15–42, from the totals on the Tape CRL and annotate the resulting totals.

    2. Balance the annotated good tape record count, document count, total debits, and total credits from the Tape CRL to the "SCCF Released" totals on the appropriate Trans Release Summary. (See figure 3.17.30-138)

      Figure 3.17.30-138

      This image is too large to be displayed in the current screen. Please click the link to view the image.

    3. IMF ELF Submission Processing Centers-When the computing centers are running the automated BAL62 and a separate TEP (GMF25) for a "clean" error free ELF (passed all GMF27 validity checks and ready for Good Tape), verify the BAL62 completed successfully and is available for viewing and retention on Control/D. This verification process must be completed and verified as correct prior to requesting the regular daily consolidated TEP (GMF15). The BAL62 will compare the Released Document Totals on the ELF Total Summary, Grand Total Summary, and IMF Mainline back to the BAL6140 total that read the input from GMF27 (ELF Docs to Good Status). The BAL62 will also scan for GMF25 TEP deletes. There is a zero tolerance for GMF25 TEP deletes, if the scan program identifies a DLN is present on any of the GMF25 TEP Delete reports (GMF 2540, 2541 or 2542), the job will abort and will have to be completed manually by the computing center. Any discrepancies with the BAL62 and the ELF Only GMF25 TEP must be reported immediately to the assigned computing center Computer System Analyst (CSA)staff.

3.17.30.11.8.2  (01-01-2009)
IDRS Trans. Release

  1. The IDRS Tape CRL for each master file is balanced to the IDRS Trans Release Summary for the corresponding master file.

  2. Subtract any IDRS deletes listed on the Deleted Records List, GMF 15–42, from the totals on the IDRS Tape CRL and annotate the resulting totals.

  3. Balance the annotated good tape record count, document count, total debits, and total credits from the Tape CRL to the "SCCF Released" totals on the IDRS Trans Release Summary. (See 4 below when IDRS data is separated in TEP for AUTO—UNDERREPORTER and/or AUTO LIEN.)

  4. When IDRS data for IMF and BMF is released through TEP and SCCF on the AUTO—UNDERRPT (Trans Source Code B) and/or AUTO—LIEN—FILE (Trans Source Code L) Trans Release Summaries, the total of the record counts and documents counts from these Summaries plus the record and document counts from the IDRS Trans Release Summary will balance to the IDRS Tape CRL for the appropriate master file.

    1. Neither the AUTO—UNDERRPT nor the AUTO—LIEN—FILE Trans Release Summary will have money amounts, but will have record and document counts only.

    2. IDRS deletes in TEP with Trans Source Codes B and L can not be perfected and reinput through mainline processing.

3.17.30.11.8.3  (01-01-2009)
Unpostable Trans Release

  1. The Unpostable Summaries for each master file are balanced to the corresponding GUF 53–40, Unpostable Control Report, for each master file.

    1. From the GUF 53–40, the Total Corrected, the Reclassified the Total Nullified, and the Purged Unpostables should balance with the corresponding category on the Trans Release Summary for Unpostables for record counts, PJ credit and debit, and net PJ amounts.

    2. Subtract any TEP deletes from the appropriate category (e.g., corrected, reclassified, etc.) on the GUF 53–40.

    3. Add the record counts, PJ credit and PJ debit amounts of the Corrected, Reclassified, Nullified, and Purged Unpostables (minus any TEP deletes) on the GUF 53–40.

    4. The result should equal the "SCCF Released" totals on the Unpostable Trans Release Summary. (See figure 3.17.30-139)

      Figure 3.17.30-139

      This image is too large to be displayed in the current screen. Please click the link to view the image.

    5. If unable to reconcile an imbalance, do not release the transaction tape. Notify the Computer Branch of a possible read fail and request a rerun of the TEP.

3.17.30.12  (01-01-2009)
Unpostable Controls

  1. Procedures relating to Unpostable controls follow.


More Internal Revenue Manual