2.9.1  Integrated Data Retrieval System (Cont. 1)

2.9.1.13 
IDRS Module Retention Criteria for the TIF

2.9.1.13.1  (01-01-2004)
General Principles of Retention Analysis

  1. Retention on the TIF is governed by the principle that a module should be retained as long as any one of a specified set of criteria is met. If a module is being kept on the file because of one of these reasons and a time is reached when that reason no longer applies, the module is then analyzed to see if any of the other specified criteria apply. If one of the criteria does apply, the module is retained. Whenever the module does not meet any retention criteria whatsoever, it is dropped from the file and a generated TC 901 is sent to ECC, , Enterprise Computing Center to inform the Master File that the module is no longer on the TIF.

2.9.1.13.2  (01-01-2005)
Specific Retention Criteria (TIF)

  1. A module is part of an account that is in process of resequencing or merging at the Master File. (The module will stay on until the resequence or merge is completed or until the Master File reports a no-merge condition.)

  2. One of the freeze conditions or hold conditions that cause extraction from the Master File is present in the module. (The module will stay on until the freeze or hold is released at the Master File.)

  3. A tax module is in debit balance and has no settled return. (The module will stay on until the balance is non-debit or a return settles, or for 7 cycles, whichever is shorter.) (IMF, BMF only).

  4. A tax module is in Master File status 13, 14, 19, 20, 21 and there is a Service Center status. (The module will stay on until the status changes at the Master File, or the module goes to IDRS status 23 or 53. (IMF, BMF only.)

  5. A tax module is in Master File status 22, 24, 26, 54, 56, 58 or 60. (The module will stay on until the Master file status changes.)

  6. One of the following conditions is met. These tax modules will remain on the TIF for one cycle (IMF and BMF only).

    1. A tax module is in MF status 23 with debit balance including accruals over minimum balance extraction amount.

    2. A tax module is 53'd with closing code 09 and debit balance including accruals over Minimum balance extraction amount.

    3. A tax module is in MF status 12 with accruals over minimum balance extraction amount and there is another tax module in TDA status or to which a debit balance transaction posted this cycle that made balance plus accruals debit over minimum balance extraction amount.

  7. A tax module contains a settled return and a credit balance (IMF-Lefthand V freeze also) or the module contains a Lefthand S or Right-hand A freeze. (The module will stay on until the balance becomes zero or debit or for 30 cycles, whichever is shorter.) (IMF, BMF only.)

  8. A tax module was extracted because the following transaction posted: TC's 28X, 70X, 73X, 75X, 79X, 82X (except 826), certain 846, certain 85X (except 856), 87X, 89X. The module will stay on the TIF for four weeks.

  9. Extraction of the module was requested by a TC902 from TIF Daily processing or TIF Recovery program (UTL95). (The module will stay on for one week).

  10. A module was extracted because a transaction unposted. (The module will stay on for one week. If the unpostable transaction appends to the IDRS module, which it should, the module will stay on until the transaction posts or is deleted from processing.) (IMF, BMF, EPMF only.)

  11. A module was extracted because of the issuance of one of the notices specified above under Master File Extraction Criteria and the module is not in a Master File notice status. (The module will stay on three weeks (IMF) and 8 weeks (BMF)).

  12. An account is established within the last 30 cycles and the ERAS-NOTICE-CD is A, B, J, K, L, M, P or T. (BMF/EPMF)

  13. A tax module is in IDRS status 53 and there is another non-53'd tax module being retained. The tax module will be retained on IDRS until the other modules drop or its own status changes.

  14. Extraction of the module was requested by a TC 902 from IDRS terminal input. Includes, but not limited to, inputs from MFREQ(D) or downloads from CFOL with MFREQ(C) or RECON. (Early analysis possible. The module will stay on for one to three weeks.)

  15. A tax module is in credit balance with no return and another module has an unpostable 05. (The module will stay on for five weeks.) (BMF only.)

  16. A tax module at the Master File has an unreversed TC 914 or 916 appended or entity has unreversed TC 918, or taxpayer has been determined to be ‘potentially dangerous’.

  17. A CP 71 or CP 71A has been issued on the module. (The module will stay on until there is activity in the account or until 6 weeks after the notice was issued.) (IMF only)

  18. A tax module is in IDRS status 23 and a TC 670 has appended. (The module will stay on 2 weeks after the cycle the last TC 670 appended.)

  19. A tax module has changed to IDRS status 12 from an IDRS status greater than 12. (The module will stay on for 2 weeks after the change to status 12). (IMF/BMF)

  20. A tax module is in IDRS status 19, 20, 21, 22, 24, 26, 41–44, 46–51, 54, 56, 58, 60, 61, 63, 64, 71, 72, 76, 77, or 89. The module will stay on until the status changes to a status not in the list.

  21. A tax module has an open TDI, pending TDI, TDI temporarily suspended, or is in an open TDI Notice Status (The module will stay on until the TDI is closed.)

  22. A tax module is in Master File Status 23 and has an open TDI. The module has not gone to the Queue.

  23. A tax module in TDI status is closed by a TC 598. The module will stay on 64 weeks from closure cycle.)

  24. A tax module in TDI status has been transferred to another Campus less than 4 weeks ago.

  25. A TDI module has closed. (IMF modules will stay on 10 weeks from closure cycle. All other files, only three weeks.)

  26. A tax module contains a recall DI TC 590 for the secondary SSN account from an IMF TC 150 that was processed more than 150 days past the due date or that contained condition code F or T. (The module will remain 20 weeks from the transaction cycle.)

  27. A module is a dummy module. (It will stay on for three weeks after it was established.)

  28. A module is a memo module. (It will stay on for three weeks after the cycle it became a memo.)

  29. A TC904 appends to the entity or tax module in the last three cycles.

  30. The entity contains a TDA/TDI assignment that has been updated in the last week. (The entity will stay on for one week.)

  31. Entity or tax module contains a transaction in pending status.

  32. Entity or tax module contains an open control base, or a control base closed within last 3 weeks.

  33. Entity module, created by "IAPND" , containing a significant PENDING-IAGRE-CD.

  34. Tax module contains an INNOCENT-SPOUSE-TRACKING-REC.

  35. Tax module contains a COLLECTION-DUE-TRACKING-REC.

    Note:

    The time specifications shown in parentheses approximate how long a module will normally remain on the file for the reason shown. Early analysis of certain type modules is allowed. If other criteria are met the module will be retained.

2.9.1.13.3  (01-01-2000)
Examples of IDRS Retention Criteria

  1. A module is extracted for IDRS because of a freeze condition. As long as the freeze condition exists the module will not be further analyzed on IDRS. When the freeze condition is released on the Master File, and Master File analysis determines that the module no longer meets any condition for which it is automatically extracted, the Master File will re-extract the module indicating this condition. When the module is updated on IDRS in this situation, IDRS analysis looks for other criteria such as pending transactions or open control bases. If IDRS analysis finds that there is an open control base in the module, it will retain the module until the control base is closed then re-analyze for other IDRS criteria. If none is found, the module is dropped.

  2. A module is extracted for IDRS because a transaction attempting to post to it went unpostable this cycle. IDRS will analyze this module every week until the unpostable is no longer on IDRS. When the unpostable is no longer on IDRS, analysis looks for criteria to retain the module. One criterion which it is likely to meet in this case is a corrected unpostable pending transaction. When the corrected unpostable transaction becomes a posted transaction, IDRS will reanalyze for other IDRS criteria. If none is found, the module is dropped.

  3. A module is extracted because it was requested from a Campus. The requester has three weeks to do something to hold the module, e.g. establish an open control base. After three weeks, the module will be analyzed for IDRS criteria and dropped if none is found.

2.9.1.13.4  (01-01-2000)
Entity Added by Command Code ESIGN

  1. An entity added to the TIF by Command Code ESIGN will be retained until either the entity is established on a Master file or meets aging criteria. When an entity meets the aging criteria, it is removed from the TIF and placed on an age listing during the weekly EKIF analysis. The aging factor for ERAS-NOTICE-CD A, B, J, K, L, M, P, or T is 30 cycles.

2.9.1.14  (01-01-2002)
IDRS Case Control

  1. This section will provide information on the following items.

    1. General case control

    2. IDRS Case Control Inventory Reports and Overage Listings

    3. Case assignee number

    4. IDRS Multiple Case Control Report

    5. New and Inactive Category Codes

2.9.1.14.1  (01-01-2004)
General Case Control

  1. Cases may be controlled on IDRS in several ways. Under IDRS, any type of case may be controlled. Therefore a separate adjustment control file is not necessary, except for use in special projects such as Civil Service Retirement Claims.

  2. Adjustment Control Records (ACR's) are produced for certain Master File recognized adjustment cases; for example, CP 36 and CP 193 cases. The ACR control number is used as the activity code of the control base when a new control is being established.

  3. Examiners may control a case by entering the CC ACTON or DOALL into IDRS. See IRM 2.3 for specific details.

  4. A refund deletion made through IDRS always generates an open control base regardless of the presence or status of any existing control bases.

  5. A DP Adjustment, credit transfer, CHK64 (Release of Undelivered Refund Check) or IDRS generated refunds (by CC RFUND) made through IDRS generates a closed control base if none of the following conditions exists.

    1. A closed base is present with today's action date and the terminal operator's assignee number.

    2. Open control base(s) assigned to the terminal operator in Status S, A, B, or M; or open control base assigned to another employee in S, A, or M Status.

    3. For ADJ54 and a 2 sided Credit Transfer Command Code (DRT24, DRT48, FRM34), no open base exists on the module for that employee, and a status other than C is input with the command code.

  6. Examiners may control a case by entering the control information after inputting a letter through IDRS; see the Correspondence Section in IRM 2.3.

  7. Use CC ACTON to establish an open control base in the following situations.

    1. Any case where resolution action cannot be taken immediately.

    2. Any case where multiple actions are to be performed such as adjustments, credit transfers, IDRS generated refunds, release of undelivered refund checks, or refund deletions. After all transactions have been entered, use CC ACTON to put the case in its proper status, if applicable. Any case which is non-workable but must be monitored, use Status Code B. This case control does not prohibit other examiners from on-line input.

  8. The concept of one taxpayer's account being worked on by one examiner should be followed in IDRS. Whenever an examiner wants to control a case and control to another employee already exists in the module or account, contact must be made with the other employee (Command code FIEMP may be used to find an employee). If CC TXMOD or SUMRY indicates ENTITY case control, the entire account is controlled. These cases would then normally be associated and controlled to one of the examiners. Cases indicating an unreversed TC 420 will be worked in accordance with IRM 21.7. The exception to this concept is case control with Status Code B which allows more than one examiner to have open case controls.

  9. An open control will cause a module to remain on IDRS indefinitely. After the control is closed, if no other criteria exists for retaining a module, it will drop off IDRS within three weeks.

  10. Reopen and work to resolution cases not passing quality review. Re-establish the case with ACTON using a "C#" , activity code "CnERRCLSD" , status "A" , plus the original IRS received date, assignee number, and category. Also use activity code "CnERRCLSD" for any other occasion when a case control must be reactivated.

2.9.1.14.2  (01-01-2004)
IDRS Case Control Inventory Reports and Overage Listings

  1. Up to 1225 inventory reports and 1225 overage listings can be produced upon request each week. These requested reports may be tailored for specific needs.

    1. Parameters which can be controlled on requested inventory reports are employee number range, column aging factors, combining several categories unto one, and MFT by category.

    2. Parameters which can be controlled on overage listings are employee number range, category range, specific aging factor by category, and minimum age for inclusion of case on listing by category.

  2. Since many areas in the Campus can put cases under control, monitor inventory reports to assure that IDRS control capabilities are being used properly. Utilize overage listings for this purpose as necessary but be selective, especially in requesting overage listings which consume considerable print time during weekend processing.

  3. For many Campuses, reports and listings are requested through the Campus Liaison for MITS. See IDRS Related COH for CCA32, for request input information.

2.9.1.14.3  (01-01-2002)
Case Assignee Number

  1. To re-assign an open control base from one assignee number using CC ACTON or CCASG (CCASG for cases opened by Master file Case Control File). Key in the 10-digit assignee number as explained in IRM 2.3. [see IDRS Related COH for CCA32].

  2. Some assignee numbers identify functional areas, units, holding files—thus representing workflow designations rather than individual employees. These non-employee assignee numbers are frequently distinguished by zeros in the last five digits of the employee number; however, numerics other than zero may also be used. Lists of such numbers appear from time to time in either Campus IDRS bulletins or the IDRS MESSG file.

2.9.1.14.4  (01-01-2000)
IDRS Multiple Case Control Report

  1. This section will provide information on the following items.

    1. General information on IDRS Multiple Case Control Report

    2. Procedures for IDRS Multiple Case Control Report

2.9.1.14.4.1  (01-01-2003)
General Information on Multiple Case Control Report

  1. As stated above, only one tax examiner should normally be working a given taxpayer's account. For that reason, the control section of every TIF entity and tax module is analyzed during weekend processing to determine if multiple open control bases are present. If more than one control base is open on a single module, a listing on the IDRS Multiple Case Control Report is generated for each of the open bases.

  2. The IDRS Multiple Case Control Report will be identified as Report Number 99 (output from CCA42). The report will be automatically produced weekly and will be broken down into assignee number order. The report will be produced on two-part paper; one part should go to the employee whose assignee number is on the upper left corner of the report and the second part to the employee's supervisor. There is space provided for up to three control bases; a plus sign is present in the last column when more than three open bases exist on the module. A different control base appears first in each line of the report.

2.9.1.14.4.2  (01-01-2000)
Procedure for IDRS Multiple Case Control Report

  1. When the IDRS Multiple Case Control Report indicates that you and another employee—or other employees—are "sharing" a module, immediately contact the employee or their functional area. The contact may be between examiners or may be between the first-line supervisors. The multiple control should be resolved within the week by having one employee handle that particular module, if applicable.

  2. Determine by the contact which area is to complete a case resolution. This is not applicable for cases controlled in Status B, but the contact should be made to determine what the Status B case involves if it is not explained by the case control.

    1. Generally, the technical function has first priority; the statute function has second. Others follow after.

    2. Multiple control bases occasionally are not related and thus should not be consolidated, but, except for cases in Status B, these instances are rare.

  3. Consolidate cases to the designated examiner.

    1. Use activity code "CASETOCv" (v-the control base number of the case to which the cases are being consolidated), on the base(s) being closed.

    2. If the open control base does not reflect the earliest IRS received date of all cases being consolidated, update the IRS received date to the earliest received date of the cases combined. This change is to be input by the examiner working the consolidated case.

    3. Transfer the relevant case material by expediting per local procedures. However, it is not necessary to transfer information duplicating what the transferee already has.

2.9.1.14.5  (01-01-2000)
New and Inactive Category Codes

  1. This section will provide information on the following items.

    1. New Category Codes

    2. Inactive Category Codes

2.9.1.14.5.1  (01-01-2000)
New Category Codes

  1. If a new Category Code is needed for control purposes, a Procedures/Systems Change Request, Form 5391, must be sent to the Headquarters. It should include:

    1. The requested Category Code.

    2. What the Category Code will be used for.

    3. The anticipated annual volume.

    4. The length of time that each case is expected to remain on IDRS.

    5. The sensitivity of the case.

    6. The Recap Code that the new Category Code will be listed under on the weekly Inventory Report.

    7. Any other pertinent data that will assist in determining whether the requested code should be added to the IDRS system.

2.9.1.14.5.2  (01-01-2000)
Inactive Category Codes

  1. If a Category Code is no longer being used, it may be removed from IDRS by submitting a Systems Change Request, Form 3548, to Headquarters. If the request is approved, the Category Code will be removed as a valid tape, or terminal input and update as soon as possible; then, approximately six months later any control bases still open will be automatically closed and dropped from the system. It is therefore imperative that, once a Category Code is removed from input capability, every effort be made to conclude all actions on the cases within six months. If a case cannot be resolved in that time, then the examiner controlling the case will have to change the Category Code to one which will remain on the system.

2.9.1.15  (01-01-2002)
IDRS Transaction Input

  1. This section will provide information on the following items.

    1. General IDRS Transaction Input

    2. Cycling of IDRS Transactions

    3. Examples of IDRS Transactions to reduce cycling.

2.9.1.15.1  (01-01-2002)
General IDRS Transaction Input

  1. Many transactions are input directly through IDRS.

  2. These include delinquency investigation transactions—DLN doc. codes 14 and 49; Area Office payments—doc. codes 18 and 28; credit transfers—doc. codes 24, 34, and 48; D.P. adjustments—doc. code 54; entity changes—doc. codes 04, 15, 50, 53, 63, 80 and 81; miscellaneous transactions—doc. codes 77 and 78; release of undelivered refund checks—doc. code 64; IDRS generated refund doc. code 45.

  3. When a transaction is input to IDRS, it appears immediately as a "pending" transaction and remains "pending" until after it posts to a Master File. It will then show as a posted transaction. The type of pending transaction is further defined by the Transaction Status Code, see IRM 2.3 and IRM 2.4 for specifics.

    1. Area Office Payments, and various transactions batch uploaded from Integrated Collection System (ICS) and Inventory Delivery System (IDS) will not appear as pending transactions until the day following input. They are appended if the TIN is present on the TIF.

    2. ESIGN data will be added to the Taxpayer Information File (TIF), Name Search Facility (NSF), and Key Index File (KIF). TC 000 will be generated for BMF, and EPMF and TC 474 and 590 for BMF during the daily analysis of ESIGN input data and sent directly to the TIF.

  4. If an employee is not subject to Quality Review on IDRS transactions, the transactions will be processed, and be ready for inclusion on a tape for posting to the TIF at end of day.

  5. If an employee is subject to Quality Review on IDRS transactions, the transactions will be processed at the end of the day in which the review took place, or at the end of the second day following the day of input if no review is made.

  6. Transactions subject to quality review on IDRS are those with document codes 04, 15, 24, 34, 47, 48, 50, 53, 54, 63, 64, 77, 78, 80, 81, and IDRS Check Claims (CC CHKCL). Unidentified Remittance, Dishonored Check or IDRS Generated Refund (CC RFUND) applications are not subject to IDRS quality review, but should be reviewed as currently specified.

  7. For specifics on inputting and reviewing transactions on IDRS, see IRM 2.3 and IRM 2.4.

  8. Source Document Folders—Do not send anything to files unless it must be retained as a backup or source document. For source documents which must be preserved and which relate to IDRS-input transactions, set up daily source document folders by employee:

    1. Cases, including related source documents, that result in document codes 45, 47, 53 (certain TC09X only), 54, 63 (TC070 only), 64 or 78.

    2. Cases, including related source documents, that result in an application from the Unidentified Remittance File (URF) — CC URAPL.

    3. Cases, including related source documents, that result in document code 78 input.

    4. All others.

  9. The different types of work should be retained in separate uniform folders as prescribed for the files [see IRM 1.15.2]. The type of work, the employee number and the input date should be noted in the left margin cut-out on each folder using the appropriate color of ink for the year as described in IRM 3.10.72.

    Note:

    for document codes 45, 47, 53 (certain TC09X only), 54, 63, (TC070 only) 64 or 78 transactions, this information will be entered on the front of the folder with any color ink since these folders are not retained in the files.

    1. For document codes 45, 54 and 64 transactions, the input sequence number must be noted on each case.

    2. For URAPL transactions, the UR control number, UR name and original UR amount should be noted on each case.

    3. Additional information that may be desirable to note or underline on each case would be TIN, name control, MFT, module period and—for source documents in the "all other" folder—doc. code of the input transaction.

    4. As it is necessary for files to know input date and employee number for all document codes 45, 47, 54, 64 and 78 transactions that are input through IDRS, it may be necessary to put that information on each case rather than just on the folder.

  10. URAPL cases should be forwarded to the Unidentified Remittance Unit through quality review. Document Code 45 cases (CC RFUND) should be retained in the functional area until the list of refunds has been certified. Once certified, send original (yellow) copy of Form 5792, Request for IGR, to Files Management for association with Form 5147, IDRS Transaction Record, and filing. NMF Document Code 45 Forms 5147 with associated case files should be forwarded for input to RACS. The source documents should be kept in sequence number order within employee number order. There is no sequence number for Document Code 78.

  11. Transactions that are input through IDRS will receive a complete DLN and be printed out after any quality review processing has taken place. Source documents will be associated with Document Codes 45, 54, 64, and 78 transactions. For other transactions they will be maintained in files in their employee input folders as provided in IRM 3.5.61.

  12. The "remarks" section of the input formats for DP adjustments, FRM77/CRMNL, entity changes and credit transfers, must be used to clearly describe the action taken. If terminal operator (e.g., RTO) is not the originator, enter the originator's employee no. Include " SD" (source document) or "NSD" (no source document) in the remarks section. ADJ54 screen now has required input. " Source Document Attached?" Valid responses are "Y" , "N" or "R" . The notations have two uses:

    1. To aid research if a subsequent problem develops.

    2. To assist Files Management in associating any source documents with doc. codes 45, 47, 54, 64 and 78 transaction records.

2.9.1.15.2  (01-01-2000)
Cycling of IDRS Transactions

  1. The need for cycling of transactions may be reduced through IDRS. Most transactions post to the Master File in transaction code order. Exceptions are: all entity addressing transactions including TC's 91X post before tax module transactions; TC 150 on BMF posts last. In those instances where cycling was done solely to be sure that a lower numbered transaction code be at the Master File in the same cycle or earlier than a later numbered transaction code, the transactions may be input to IDRS at the same time.

2.9.1.15.3  (01-01-2000)
Examples of IDRS Transactions to Reduce Cycling

  1. An address change (TC 014) and a reduction in tax (TC 291) need to be input.

  2. A reduction in tax (TC 291) and then a transfer of that credit, e.g., (TC 820–700) need to be input.

  3. A payment, e.g., (TC 670) or a credit, e.g., (TC 700/820) need to be applied, and then an increase in tax (TC 290) is to be made.

  4. A consolidation of accounts such as from a "no merge" situation, results in needing to zero out the "FROM" module with TC 291, transfer credits to the "TO" module, and assessing tax with TC 290 on the "TO" module. These transactions may all be input to the module(s) involved through IDRS in the same cycle. Care should be taken through analysis of the module(s) on IDRS that the transactions will indeed post to the Master File and not create an unpostable. Use of TC 570 for freeze purposes, where applicable, may be used especially when the actual module is not on IDRS. Multiple TC's may come in on a single doc code 54 transaction. These will all post to the Master File as a group in input order and they will be sorted as coming in under a TC 290 even if the input TC was not a TC 290. Where cycling is still required, or where there is some doubt whether to cycle or not, the transactions may be cycled with the posting delay code. In this way, all actions on a case may be completed by the examiner at the same time.

2.9.1.16  (01-01-2002)
Special NMF Considerations

  1. The use of IDRS for NMF modules and accounts is substantially limited compared to IMF or BMF purposes.

    1. The TIF will only contain module information for those modules that are in TDA or TDI status.

    2. In addition, case control may be established for all NMF cases.

  2. NMF cases are established with CC NMFTM and TDIRQ. Several transactions that may be input to IDRS may be input to NMF modules by their appropriate command code. Exceptions to this are credit transfers and DP adjustments, document codes 24, 48, 54 and 64 which are input with NMFST. Because of the file limitations on NMF modules mentioned above, most transactions affecting IDRS are limited to those addressing TDA or TDI modules. NMF modules must be present.

  3. For NMF Area Office Payments (doc. code 28) and NMF doc. code 77 TC's to be posted to the Automated Non-Master File (ANMF) account, the IDRS Transaction Record, Form 5147, is routed to the Accounting function as a posting document.

  4. NMF entity changes may be input for those accounts which are present on IDRS. Instructions for the use of Command Code BNCHG, some of which are unique for NMF, are included in IRM 2.4. NMF entity change information from IDRS will appear on various outputs to be received weekly in the NMF Accounting function. Each output has a different prescribed function.

    1. NMF Entity Change List—This list contains a record of IDRS entity changes other than account number changes. The data on the listing is to be used by the Accounting function to update the ANMF account entity information.

    2. NMF Account Number Change List— The data on this list is to be used to change the account number on the ANMF account.

    3. NMF Account Number Change Transcript (TYPE A)—This is a full account transcript which is to be used to reinput the account into IDRS under the new account number.

    4. NMF Unprocessable Entity Change List—This is a listing of entity changes which could not be used to create IDRS updates because KIF (Key Index File) data is missing or has been lost prior to update creation processing. These entity changes must be reinput through IDRS and the original pending transaction must be deleted. If an ENMOD response indicates that IDRS still does not have data, it will be necessary to determine if KIF data needs to be established. If so, the KIF establishment will include the change attempted and the old transaction should be deleted. If KIF data cannot or will not be established, delete the entity change transaction from IDRS.

2.9.1.17  (01-01-2004)
Command Code Aborts

  1. If you receive a Command Code abort message, follow the prompts on the screen and retain a screen print of the data. If necessary, open a help-desk ticket.

2.9.1.18  (01-01-2004)
Diagnostic Transcripts

  1. This section will provide information on the following items.

    1. General Information on Diagnostic Transcripts

    2. DIAG-P Transcripts

    3. DIAG-Q Transcripts

2.9.1.18.1  (07-01-2011)
General Information on Diagnostic Transcripts

  1. Run TRS04W generates Diagnostic transcripts from data extracted by the Diagnostic Analysis portion of WTU29/49/69. While the capability to suppress this analysis exists, it is strongly recommended that this not be done. If local management or operations staffs intend to override this recommendation, they should contact Headquarters.

  2. Diagnostic transcripts are produced weekly for those entity or tax modules containing pre-determined criteria which might indicate incorrect processing. Their primary purpose is to identify systemic, programming or computer operations problems. Secondarily, they may disclose operational problems in other functional areas.

  3. The IDRS User Support Staff must analyze these transcripts and sort them according to problem areas revealed and by functional areas responsible for resolving the problems identified. User Support Staff analyzing these transcripts must be alert to procedural or systemic problems revealed. After appropriate review, research and documentation, these problems, or suspected problems, should be forwarded to the office responsible for their resolution (local CSA staff, operational function or Headquarters IDRS computer specialists, etc.).

  4. After analysis by the IDRS User Support Staff, referrals should be made to proper functional areas for corrective action (as described in 2.9.1.19.2). In some instances this action may be handled on a case-by-case basis whereas others may be processed as a "batch" operation. An example of the latter would be a block of TP transactions that did not follow expected procedures. Pending transactions can affect the module balance, so it is extremely critical that these transactions be corrected promptly.

  5. Diagnostic transcript controls from run TRS04W should be maintained by cycle of issuance. A record of volume and action taken should be maintained with the controls whenever new problems are detected and the volume of such problems is significant, or when the problem is of a continuing nature. As an example, 75 TP transactions in one cycle would be a sufficiently significant volume to warrant recordation. Likewise, a similar problem occurring on 10 tax modules each week would warrant recordation at the point the problem is identified as a continuing problem condition.

  6. DIAG-Q types 1-9, C, D, E, and S that meet specific TDA or TDI criteria are now routed to the WTU2923 file instead of the WTU2913 file that is processed by TRS04W. The WTU2923 file is sent to a Desktop Integration (DI) process. The DI process sends DIAG-Q types 1-9 with –Y Freeze-CD’s to Memphis and Brookhaven campuses only, for further research. If the taxpayer's state is equal to "AK, AR, AL ,AZ, CO, FL, GA, HI, ID, KY, LA, MS, MT, NC, NV, NM, OK, OR, SC, TN,TX, UT, WA, WI OR WY" route the transcripts to MSC else route the transcripts to BSC.The DI process sends also the TDA transcripts to the Atlanta campus for further research and the TDI transcripts to the Fresno campus for further research.

2.9.1.18.2  (01-01-2004)
DIAG-P Transcripts

  1. This section will provide information on the following items.

    1. General information on DIAG-P Transcripts

    2. Selection criteria for DIAG-P Transcripts

    3. Procedures for disposition of DIAG-P Transcripts

2.9.1.18.2.1  (01-01-2000)
General Information on DIAG-P Transcripts

  1. Transcripts are issued weekly for entity or tax modules with transactions that have been in a pending status for an abnormal length of time, indicating that these transactions were not processed as expected. For current cycle DIAG-P types RJ, PN, Rnnn, and CU (entity and tax module), a TC 902 is generated requesting Master File extraction.

2.9.1.18.2.2  (01-01-2000)
Selection Criteria for DIAG-P Transcripts

  1. The following selection criteria are used for the various types of pending transactions. A transcript is produced for each tax module or entity that has a qualifying transaction. The transcript is based only on the first condition encountered (FSP 1.05.30.07).

    1. The transaction is appended as AP or EP and one cycle has elapsed since it was appended with that pending transaction status.

    2. The transaction is appended as TP and three cycles have elapsed since it was appended with that pending transaction status.

    3. The transaction is appended as DI and one cycle has elapsed since it was appended, and the DI transaction does not have a complete DLN.

    4. The transaction (exclude NMF transactions) is appended as CU (except TC 011), PN (except PN TC's 011, 013, 014, 018, 040, 041), or RJ and one cycle has elapsed since it was appended with that pending transaction status.

    5. The transaction (exclude NMF transactions) is a TC 011, 013, 014, 018, 040, 041, it is appended as a PN; and three cycles have elapsed since it was appended with that pending transaction status.

    6. The transaction is appended to an NMF entity, it is appended as a PN, and three cycles have elapsed since it appended with that pending transaction status.

    7. The transaction (exclude TC 904 and TC 011) is appended as Rnnn and two cycles have elapsed since it was appended with that pending status.

    8. The transaction is appended as Unnn (excluding unpostable code 305) or NU and 11 cycles have elapsed since it was appended with that pending transaction status, or "X" cycles have elapsed, where " X" is a number of cycles determined by the Campus and input via card to the Diagnostic Analysis portion of WTU29, WTU49, and WTU69.

    9. The transaction is appended as Unnn with unpostable code 305 and 11 cycles have elapsed since it was appended with that pending transaction status, or "X" cycles have elapsed, where "X" is a number of cycles to be determined by the Campus and input via card to the diagnostic analysis portion of WTU29, WTU49, and WTU69.

    10. Rnnn or CU TC011 is appended and three cycles have elapsed since it was appended in that status.

2.9.1.18.2.3  (01-01-2003)
Procedures for Disposition of DIAG-P Transcripts

  1. Diagnostic transcripts sharing identical values in one or more of these data elements could show a trend. These similarities may indicate a recognizable problem(s). In some instances, this gives an immediate answer. In other instances, it focuses on a research point.

  2. When looking at the transcripts, it is beneficial to pay particular attention to the:

    1. TRANS-STATUS-CD (AP, PN, etc.)

    2. TRANS-CD

    3. TRANS-CYC

    4. TRANS-DT

    5. DLN

  3. Diagnostic-P transcripts are issued only for entity and tax modules that meet the criteria in the current cycle. The computer program controls from run TRS04W reflect the number of modules that have met the selection criteria in the past 2, 3, 4 and 5 or more cycles. Options are available to print selected transactions from these previous cycles by input of control cards into run TRS04W. Information necessary for these control cards are the CYCLES, TRANS-STATUS-CD's and file indicators. Book IV, section 6 of the CPB (Computer Program Book), gives more precise details on these control cards.

  4. If there is no condition in the module that justifies retaining the module on IDRS the transaction should be deleted. First sort transcripts according to problem and then analyze to determine if any programming or systemic deficiency exists. If either exists, take the necessary steps to correct the situation. The problem may have to be referred to Headquarters.

  5. RJ—Rejected Transactions — Check Command Code ERINV and SCFTR to determine what action may have been taken by the Reject Function. If the transaction posted to Master File (via IMFOL or BMFOL), input MFREQC to update IDRS. If it has not posted, monitor for up to two cycles. If it has not, open a help-desk ticket. RJ TC 150's, when closed, have a "C" inserted in front of the Reject Sequence Number, and the cycle is incremented by 6. The closed record is retained until the week following the transaction cycle. A DIAG-P transcript for an RJ transaction would indicate problems with the weekend update runs. Check Command Code ERINV and SCFTR to determine what action may have been taken by the Reject Function. If the transaction posted to Master File (via IMFOL or BMFOL), input MFREQC to update IDRS. If it has not posted , monitor for up to two cycles. Open a Help Desk ticket if the transaction has not posted after monitoring for two weeks.

  6. AP/EP—Account Pending/Entity Pending — Transaction has appended to an entity or a tax module through End-Of-Day Processing and has failed to update to PN status and has an incomplete DLN.

    1. Research EOD0140, 1040, 1440 on EONS to determine if it is the result of dropped records. If transaction was a credit transfer, check to see if both sides have pended (if not, this could cause an out-of-balance in the Data Control area of Accounting). If so, contact should be made to RACS to notify them of the condition.

    2. If transaction went to ECC, Enterprise Computing Center, monitor until the posted transaction comes down, then delete the AP/EP transaction.

    3. If the transaction did not go on the tape to ECC, Enterprise Computing Center, delete and refer to appropriate area for re-input.

  7. TP—SCRIPTS Payment Pending — Transaction has failed to update from TP to PN status. If research indicates the payment has posted elsewhere on the same account and a notice should not be issued on the module in question, use CC STAUP to interrupt the notice routine. Please note, interruption of notice routine via CC STAUP should only be used when necessary.

  8. PN—Pending Transaction — The transaction has passed all IDRS checks and is being sent to ECC, Enterprise Computing Center,for posting.

    1. Determine through CC MFTRA or SCFTR or a CFOL CC if the transaction has posted. If so input CC MFREQ to download from CFOL when only a dummy module exists, or input CC:RECONto update the account when it is present on the local TIF. Search the weekly update tape from ECC, , Enterprise Computing Center (IMF — 78090SC, BMF — 78030SC, EPMF, see FSP 1.05.22.99 for record formats) to determine if the posted transaction was sent down. If so, determine which run failed to update the transaction to posted status and notify IDRS Programming if a program problem is indicated.

    2. Check to see if the transaction went unpostable and was not updated properly. Determine why and take corrective action as necessary.

    3. Check to see if Accounting deleted the transaction from the TEP. If so, delete from IDRS.

  9. Rnnn—Resequence Transactions — The posting of the transaction has been delayed beyond the scheduled cycle. The transaction is placed on a resequence tape at ECC, Enterprise Computing Center and an attempt will be made to post it next cycle. IDRS daily update runs will update the transaction cycle when the resequence transaction is received. Research to determine if one of the following may have occurred.

    1. Resequence tapes were not input timely. Monitor for one cycle.

    2. ECC, Enterprise Computing Centerdid not send back a transaction after posting. Use CC MFTRA or a CFOL CC to verify that transaction posted and use CC MFREQ to download from CFOL when only a dummy module exists, or input CC:RECON to update the account when it is present on the local TIF to re-extract.

    3. The transaction is unpostable and was not updated properly. Determine why and take corrective action as necessary.

    4. If transaction is neither posted nor unposted check the weekly resequence tape from ECC, Enterprise Computing Center, (ITIF — 78083, BTIF — 78014, ZTIF — 66093) to determine if an Rnnn transaction was received. If not received, open a Help Desk ticket for a missing transaction indicating it is 6 cycles old or older and is not on the re-sequencing tape.

  10. Unnn—Unpostable Transactions — For unpostable transactions:

    1. Check Command Code UPDIS to determine if it is a valid unpostable and has not been resolved.

    2. If the transaction is valid open unpostable, destroy transcript. If the unpostable is closed, research Master File based on the closing action. This may require monitoring for one or two cycles.

    3. Input CC MFREQ to download from CFOL only when a dummy module exists or input CC:RECON to update the account when it is present on the TIF or delete as necessary.

    4. Attempt to research Corrected Unpostable File to determine why the closed transaction did not update properly.

  11. CU—Corrected Unpostables — There are several reasons corrected unpostables would not update in two cycles to a posted transaction:

    1. ECC, Enterprise Computing Centerdid not send the transaction back after posting. MFREQ the account and monitor it.

    2. Check CC SCFTR to see if DLN went to good tape. If so, monitor for one cycle. If not, report to Headquarters Programmer.

    3. Input CC MFREQ to download from CFOL/EMFOL when only a dummy module exists, or input CC:RECON to update the account when it is present on the local TIF or delete transaction as necessary.

    4. Report any suspected program problems to Headquarters programmer.

  12. NU—Nullified Unpostables — These generate as DIAG-P transcripts when 11 cycles have elapsed and the NU has not updated. There are several reasons for this occurring:

    1. Files input from the Error Resolution System (ERS) or from GMF Rejects were not input to IDRS.

    2. Check CC SCFTR to see if DLN went to good tape. If not, monitor for one cycle. If re-input to another module or account, delete the DLN. If it is still in ERS (CC ERINV) or Rejects, consider resolved.

    3. If the transaction is not present on ERS or GMF Rejects delete from IDRS.

2.9.1.18.3  (01-01-2002)
DIAG-Q Transcripts

  1. This section will provide information on the following items.

    1. General information on DIAG-Q Transcripts

    2. Type definitions of DIAG-Q Transcripts

    3. Procedures for disposition of DIAG-Q Transcripts

2.9.1.18.3.1  (07-01-2010)
General Information on DIAG-Q Transcripts

  1. These transcripts are issued weekly to identify possible problem modules on the MRS data base, and to offer a random review of the IDRS file's contents. These diagnostic transcripts provide a means to identify and remove unnecessary accounts from the IDRS files.

  2. The DIAG-Q transcripts will be identified by a one character type code: M, D, E, O, F, R, 1–9, A, S, G or C in that priority order. The type code is printed in the transcript heading, and each type is sorted so that it prints together, except types F, O and M which are sorted by assignee employee number. The controls will show a count by type.

  3. All DIAG-Q transcripts will be suppressed if the tax module contains a -S freeze code.

  4. All DIAG-Q transcripts will be suppressed if the tax module contains a -V, -W or -Y freeze code unless there is also a -L freeze code. If the -L freeze code is present the DIAG-Q transcript will be routed to Exam for further research.

  5. All DIAG-Q transcripts will be suppressed if the tax module contains a -L freeze code.

2.9.1.18.3.2  (07-01-2012)
Type Definition of DIAG-Q Transcripts

  1. Type M identifies memo modules containing open control bases. The open control bases should be closed. A new control base may be established if needed. The new control base will automatically remove the memo record and replace it with a dummy record. Do not generate if reason code is C2, I2 or KK.

  2. Type F identifies modules with Rnnn–904s and open control bases. These transcripts will be produced once every seventeen cycles until the control base is closed. They should be routed to the employee responsible for the open control base. Do not generate if reason code is C2, I2 or KK.

  3. Types D, E, O and R transcripts—These transcripts are produced for those modules removed to the IMF Retention Register or level 3 of the BMF. These transcripts will be produced only when TC 904's, generated from an IMF Retention Register cycle or from a BMF level 3 update cycle, are appended to the module. Do not generate if reason code is C2, I2 or KK.

    1. Type O contains an open control base. Referral should be made to the person controlling the module. Unless further case control is necessary because of known future action on the case, the control base should be closed in order to allow the module to drop from the file.

    2. Type D has a TDI-MOD-STATUS-CD of 1 or 9. Route to Campus Collection Branch. They should research the TIF to determine if a return delinquency is actually open in the Campus' area of responsibility. If not, the module should be removed from the TIF.

    3. Type E is in IDRS Status 20 through 89 (except 23, 29, 53). These should be routed to the Campus Collection Branch for review to see if the module should be retained because the IDRS status indicates the module is actually "in-process" of one sort or another. If so, appropriate action should be taken to retain and re-establish. However, in most instances, this should not be the case and the module should be allowed to drop from the file, which it should do since IDRS status is not retention criteria for modules with appended TC 904's.

    4. Type R transcripts will be produced for Master File removed modules that do not have any of the conditions listed under type D, E, or O Transcripts. At least a cursory review should be made to determine if there are any unusual cases or potential problems. If there are, they should be routed to the responsible functional area. These modules should drop from the files in three weeks.

    5. If action has been taken to reestablish a module at Master File, Command Code MFREQ should be used so that the account will be marked for that module at the Master File. This will cause the module to be extracted to the Campus when it is reactivated. This applies to modules on Type D, E, O and R Transcripts.

  4. Types 1–9 transcripts are produced for modules that have been on the TIF for one, two, three years, etc. The number for the particular transcript identifies the number of years. These transcripts will be issued when all of the following conditions are met:

    1. The Master File Extraction/Aging Cycle in a tax module exactly equals the current cycle minus an integral number of years.

    2. There are no open control bases.

    3. The IDRS status is not 22, 24 or 26.

    4. If the TDI-MOD-STATUS-CD is 1 or 9 the TDI-CD can not be 1.

    5. There is no posted transaction in the module with a posting cycle greater than the current cycle minus 52 cycles.

    6. There is no Z freeze code present.

    7. If the reason code is 33, the module must not be an IMF module containing freeze code R and control DLN document code 33.

    8. If the reason code is 55, 6I, 6N, or 6T, there must be a SC-STATUS-HIST-REC present, and the current STATUS-CD must be other than 60, 61, or 63.

    9. If a TC520 is present with Closing Codes 80, 81, 83, or 85–89, and a right hand W or V freeze is not present (non-NMF accounts).

    10. If there is an ENT-CASE-ASSIGNMENT-REC present, the ASSIGNMENT-NUM is equal to 0000, 7000 or 8000, and there is not a right hand W or V freeze present.

    11. The reason code is not FF, 88, C2, I2 or KK.

    12. There is no left hand S freeze present in the module.

    13. There is no non-deleted status pending transaction (other than DI) in the module with a pending transaction cycle greater than or equal to the current cycle.

    14. If a right hand W freeze code is present and the module closing code is 72 or 74, and it has been on the TIF for 3 or more years.

    15. There is not a payment on the account within the last 5 cycles.

    16. There is no right hand H freeze present in the module.

  5. Type A indicates that the Campus has input an option card for DIAG-Q selection. Extraction of transcripts under this option uses the same criteria as those for Type 1–9, except the Master File Extraction/Aging Cycle in the tax module is compared to a cycle range on the option card.

  6. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    1. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    2. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    3. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    4. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    5. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    6. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    7. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

    8. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

  7. Type C detects modules that have an expired CSED with both of the following conditions shown below. Ordinarily these DIAG-Q's will come out in the cycle that the CSED expires. In some cases where modules with reason code 55 are brought on IDRS for the first time the CSED may have already expired. Most of these will age off in one week. Those with an IDRS status should be immediately referred to the Campus Collection Branch. Those transcripts with reason code PA, PB, PC or PD should drop from the file in the next weekend update. Those with reason code 55 represent erroneous processing of some kind. The IDRS User Support Staff should review these transcripts immediately upon receipt of them to see if programming or systemic deficiencies exist. If a problem is found, it should be referred to the local CSA staff or the Headquarters IDRS computer specialists depending on the type of problem. The module analysis is accomplished by a thorough review of the module history and a determination of the current condition on the module. The reviewer should identify the Reason Code—IDRS criteria and the Status code-collection condition and the ASED—assessment statute expiration date and the CSED—Collection statute expiration date and the Freeze Codes—controlling conditions.

    1. Reason Code of 55, 6I, 6T, 6N, PA, PB, PC or PD.

    2. IDRS status 19 through 89 (except 23, 27–40, 45, 52–55, 59, 62, 65–70, 74–88).

  8. Type G is produced for Large Complex Corporation modules in Campus status 21, 22, 24, 26, 56 or 58 for 55 cycles. Follow-up transcripts are produced every 10 cycles. They should be routed to the area responsible for working Large Complex Corporation accounts.

2.9.1.18.3.3  (01-01-2006)
Procedures for Disposition of DIAG-Q Transcripts

  1. The IDRS User Support Staff will analyze and separate the transcripts by Reason Code, Freeze Code, Debit or Credit Balance, and by IMF, BMF, and EPMF. The transcripts will then be forwarded to the appropriate functions for resolution of the problem. The transcripts which do not meet criteria for referral to other functions will be analyzed to determine if any procedural or systemic deficiencies exist. If a deficiency exists, the IDRS User Support Staff will take the necessary corrective action.

  2. If the review as described above does not disclose systemic, programming, or computer operation problems, it should be extended to look for possible problems in some other functional area. If normal processing would resolve the condition the DIAG-Q can be destroyed. The following are some of the conditions that ordinarily should not require further actions in resolving the DIAG-Q transcript.

    1. Modules which contain a pending transaction which will change the status or reason codes and subsequently resolve the module.

    2. Modules which reflect a current notice issuance to a functional organization.

    3. Modules in a properly monitored installment agreement.

    4. Modules with an invalid SSN, posted return credit balance, no freezes and a review of CC ENMOD display reflects a timely CP 54 issuance for the tax period.

    5. Modules with an "-S" Freeze code.

    6. Modules with an "FF" reason code.

    Note:

    if the CSED or ASED is expired or will expire within 180 days, do not discard.

  3. Those transcripts not resolved as specified under the heading DIAG-Q Transcripts should be referred to the functional area responsible for resolution of the condition in the module. Local management should establish procedures for the distribution and control of these transcripts to ensure timely review and appropriate disposal action. The IDRS User Support Staff should perform an analytical review of the transcripts and distribute them to the appropriate function.

  4. The following table shows the various conditions and the function normally responsible for the resolution of the condition.

    Note:

    If the module would drop from IDRS before follow-up action can be taken and the Campus Collection Branch is not the responsible function, a control base should be established to hold it on IDRS.

    Condition Responsible Function
    Expired or imminent Assessment Statute Expiration Date Campus Statute function
    Expired or imminent Collection Statute Expiration Date Collection function depending on conditions in module
    Scrambled SSN Indicator Scrambled function
    Freeze codes indicate Controlling conditions on the module. Local management determines the distribution and control of these transcripts. The "Freeze Code Chart" is meant to be only a guideline.

  5. Reason Codes indicate the criteria used to extract the module and are beneficial in determining the action required to resolve the outstanding condition. The following table shows the Reason Code, Additional Criteria, and Responsible Functional Area.

    Reason Code Additional
    Criteria
    Responsible Functional Area
    33   Refer to the area responsible for releasing the freeze or hold condition.
    55
    6I
    6N
    6T
    (with freeze code -A, X-, -X, O-, -J, or -V) Refer to the area responsible for releasing the freeze condition.
    55
    6I
    6N
    6T
    (all others) Refer to Campus Collection Function.
    EE   Refer to Campus Collection Function.
    KK   ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡
    PA
    PB
    PC
    PD
      Refer to Campus Collection Function.
    QQ   Refer to Campus Collection Function.
    RF   Refer to Campus Collection Function.
    SS   Refer to Campus Collection Function.
    T1
    T2
    T3
    T4
    T5
      Refer to Campus Collection Function.
    UA
    UB
    UM
    US
    (memo records)
      Refer to assignee.

  6. Review of the Type 1–9 DIAG-Q transcripts may indicate that follow-up on this type is not effective. If so, a clean-up extraction using the option for extraction of Type A DIAG-Q transcripts may be useful. A clean-up using this option should be coordinated with the Computer Branch as the volume of transcripts generated may affect processing time.

2.9.1.19  (01-01-2002)
Reason Codes General Processing Information

  1. A reason code having an aging factor specified as ‘MFEXCL’ (MF Exclusion) is never analyzed or aged in TIF processing.

  2. Unless specified under ‘TIF Criteria’, a reason code that can be set during TIF processing can be set for all files (IMF, BMF, EPMF, NMF).

  3. The SC-REASON-CD on the TIF module reflects the current reason that a module is being retained on the TIF. For original and prior reason codes, refer to the REASON-CD-HIST-REC.

  4. See Exhibit 2.9.1–1 for a list of reason codes. The reason codes included are for informational purposes only. The exhibit summarizes all reason codes which may appear on the TIF describing TIF and MF criteria (as applicable) for each. For complete criteria for MF extraction refer to PRPs 760–04.02 (BMF), 760–45.02 (IMF), and 260–10.02 (EPMF).

Exhibit 2.9.1-1 
Reason Codes

Reason Codes Module Type Aging Factor In Cycles MF Extraction/TIF Retention Criteria
bb E & T None MF: The entity or tax module does not meet any MF extraction criteria but there was MF activity this cycle and the TIF indicator at MF shows that the module is present on the TIF. (IMF/BMF/EPMF)
TIF: N/A
00 E None MF: Entity module is being extracted only because tax modules are being extracted (valid for entities associated with a tax module under AIMS control only). (IMF/BMF/EPMF)
TIF: No other TIF criteria applies. This reason code should not be present for tax modules retained on the TIF.
22 E & T None MF: The account is a resequenced account or contains an EPMF account or plan merge in the current cycle and does not meet criteria for any other reason code. (IMF/BMF/EPMF)
TIF: N/A
32 T MFEXCL (Master File Exclusive reason code, module will remain on TIF until MF extracts module with a different reason code) MF: Bits 1 and 2 of the STEX Freeze are set and the TC 150 posted this cycle. Credit balance (entirely from with-holding and/or Earned Income Credit) will be transferred to Excess Collections File via TC 820, per this reason code.
(IMF)
TIF: N/A
33 E & T MFEXCL MF:
For entities:
One of the following must apply:
—Temporary TIN or Account TIN changed current cycle.
(IMF/BMF)
—TC 130 with Blocking Series 200 posts.
(IMF)
For tax modules:
A freeze or hold condition is present on the module.
(IMF/BMF)
TIF: Tax module is in Service Center Status 53 and the COLL-CLOSING-CD is equal to 90 or 93 (valid for tax module only)
51 T 104 or until a TC300 DOC-CD 51 posts to the module. MF:N/ATIF: Tax module contains a TIF-71 with an entry that has an Activity-Cd value of HOLD4DOC51 and Tax module does not contain a TC300 DOC-CD 51 transaction with a TRANS-DT later than the date in the Action-Hist-Rec item.
55 T None MF: All of the following must apply:
—Module contains a settled return and is in MF Status 18, 19, 20, 21, 13 (BMF Form 1120 only), or 14.
—CSED is not expired.
—Module is not 53'd.
—Closing code is not 01–39.
(IMF/BMF)
TIF: All of the following must apply:
—MF Status is 13, 14, 19, 20, 21.
—COLL-CLOSING-CD is 00.
—Service Center Status (SC-STATUS HIST-REC is a required record) is not 23, OR the TAX-MOD-ACTIVITY-IND is on.
—CSED has not expired.
—Service Center Status is not 53.
(IMF/BMF)
6I T None MF: All of the following must apply:
—Tax module contains a Settled return and is in MF Status 60.
—Module is not 53'd.
—CSED is not expired.
(IMF/BMF)
TIF: All of the following must apply:
—MF Status is 60.
—COLL-CLOSING-CD is 00.
—CSED has not expired.
—MOD-MEMO-CD is not 1.
—Service Center Status is not 53.
(IMF/BMF)
6N T None MF: All of the following must apply:
—Tax module contains a settled return and is in MF Status 54, 56 or 58.
—Module is not 53'd.
—CSED is not expired.
(IMF/BMF)
TIF: All of the following must apply:
—MF Status is 54, 56 or 58.
—COLL-CLOSING-CD is 00.
—CSED has not expired.
—MOD-MEMO-CD is not 1.
—(Service Center Status is not = 53).
(IMF/BMF)
6T T None MF: All of the following must apply:
—Tax module contains a settled return and is in MF Status 22, 24, 26.
—Module is not 53'd.
—CSED is not expired.
(IMF/BMF)
TIF:
(1) All of the following must apply:
—SC Status is 26.
—COLL-CLOSING-CD is 00.
—CSED-EXPIRED-IND is 0 or 1.
—CSED has expired.
—MOD-MEMO-CD is not 1.
(NMF)
(2) All of the following must apply:
—MF Status is 22, 24, or 26.
—COLL-CLOSING-CD is 00.
—CSED has not expired.
—MOD-MEMO-CD is not 1.
—(Service Center Status is not 53).
(IMF/BMF)
77 T None MF: One of the following must apply:
—Tax module is in MF status 23 with debit balance plus accruals over minimum MF extraction criteria amount.
—Tax module is 53'd with closing code 09 and debit balance plus accruals are over minimum MF extraction criteria amount.
—Tax module is in MF status 12 with accruals over minimum MF extraction criteria amount and another tax module was extracted which is in MF status 22, 24, 26, 54, 56, 58 or 60 or to which a debit balance transaction posted in the current cycle that made the balance including accruals debit over minimum MF extraction criteria amount and there is at least one tax module with an unexpired CSED.
(IMF/BMF)
TIF: N/A
88 T 30 MF: One of the following must apply:
Tax module contains a settled return, has a credit balance and a V-freeze (HHS TC130) is present.
(IMF)
Tax module is created for a TC 150 with an invalid SSN (IMF only).
Module contains a S- freeze.
Module contains -A freeze.
(IMF/BMF)
TIF: N/A
A1 E & T None MF: N/A
TIF: AIMS dummy module (Skeletal, module present before an AIMS Opening Record has been received).
A2 T None MF: MF activity present in the module this cycle and a TC 420 or 424 is present. (AIMS Opening Records and subsequent updates)
(IMF/BMF/EPMF)
TIF: N/A
A3 T None For ZTIF

4 for BMF
MF: AIMS EO tax modules.
(BMF)
TIF: AIMS ‘Dummy’ TIN cases (TIN-TYPE = 3) on the ZTIF.
AA T 4 MF: A TC 28X, 70X, 73X, 75X, 79X, 82X (except 826), certain 846s, 85X (except 856), 87X or 89X posted to the tax module this cycle.
(IMF/BMF)
TIF: N/A
BB E & T 1 MF: For entities:
TDI switch is set and COLLECTION-LOC-CD, SB-AO-CD or AREA-OFFICE-CD changed this cycle.
(IMF/BMF/EPMF) For tax modules:
Module was in status 02 or 03 and a status of 06 or higher is set in current cycle.
(IMF/BMF/EPMF)
TIF: The last ENT-CASE-ASSIGNMENT-GROUP contains a significant ACTION-EMPLEE-NUM and ASSIGNMENT-ACTION-DT greater than the current date minus 7 (valid for entity only).
BD E & T 1 MF: Entity or tax module was requested by a TC 902 generated by TIF Daily Processing or TIF recovery program (UTL95).
(IMF/BMF/EPMF)
TIF: N/A
BU E & T 1 MF: A transaction went unpostable from the module this cycle.
(IMF/BMF/EPMF)
TIF: N/A
C1 T 15 MF: CP207 notice issued to taxpayer.
(BMF)
TIF: N/A
C2 T None MF: N/A
TIF: TIF-73 record must be present.
CC E & T 8 for BMF

3 for IMF
MF: One of the following must apply:
—Notice issued to taxpayer.
(IMF/BMF/EPMF)
—TC 011 or 04X posts this cycle.
(IMF/BMF)
TIF: N/A
DD E 8 MF: N/A
TIF: Action History Item added within the last 8 weeks due to taxpayer correspondence. Full entity data will not always be present.
E1 E 10 MF: Active account newly established within the last 30 cycles and no other criteria applies.
(BMF/EPMF)
TIF: Account established within last 30 cycles and the ERAS-NOTICE-CD is A, B, J, K, L, M, P or T.
(BMF/EPMF)
EA T None MF: N/A
TIF: ERAS entity module established by realtime (prior to MF update).
(BMF/EPMF)
EB T 26 MF: A credit balance tax module is in MF status 02–2 and was previously in status 02–B and there is not another module in MF status 03 in the account.
TIF: N/A
EE T MFEXCL MF:
For IMF and BMF:
One of the following must apply:
—Tax module is in TDI Status.
—Module is in TDI notice status with a credit balance.
—Module is in TDI notice status and another module in the account is in TDI Status.
—Module is in TDI fourth notice status.
For EPMF:
—Module is in TDI or TDI notice status.
TIF: N/A
FF T None MF: All of the following must apply:
—Tax module has been 53'd with a closing code other than 09.
—Another module in the account is being extracted this cycle with a reason code other than FF.
—CSED is not expired.
(IMF/BMF)
TIF: All of the following must apply:
—Service Center Status is 53.
—CSED is not expired.
—Another non 53'd module is being retained.
HH E & T 3 MF: The entity or tax module has been requested by a TC 902 originated by TIF realtime processing. (IMF/BMF/EPMF)
TIF: N/A
I2 T None MF: N/A
TIF: TIF-72 record must be present.
JA T None MF: An FTD tax module (MFT 01 tax period 000000) is in credit balance with another tax module on the account in balance due.
(BMF )
TIF: N/A
JC T 20 MF: N/A
TIF: Tax module contains an unreversed TC971 AC 043. Unreveresed means no TC972 AC 043 or TC971 AC 063 with a date the same or later than the TC971 AC 043.
JJ T 5 MF: Tax module is in credit balance with no return posted and a balance due notice with a discrepancy error has been issued this cycle. (BMF)
TIF: N/A
KC T 26 MF: Both the module is updated to status 02 and the FERDI indicator is set in the current cycle. (The FERDI indicator will be a 9 in the cycle that it is set.)
TIF: N/A
KK E & T MFEXCL MF: One of the following must apply:
—Tax module has an unreversed TC 914 or 916 posted.
—Entity has an unreversed TC 918 posted, or taxpayer has been determined to be ‘potentially dangerous’. (IMF/BMF)
TIF: N/A
MM T 2 MF: N/A
TIF: All of the following must apply:
—Tax module is in Service Center Status 23.
—There is a posted or pending TC 670 in the module with current cycle minus transaction cycle is not greater than 1.
(IMF/BMF/NMF)
NN T 2 for IMF
BMF

4 for NMF
MF: N/A
TIF:
(1) All of the following must apply:
—Tax module is in Service Center Status 12 with the preceding status being greater than 12.
—Current cycle minus the status 12 cycle is not greater than 2.
(IMF/BMF)
(2) All of the following must apply:
—Tax module is in Service Center Status 12 or 53.
—Current cycle minus the status 12 or 53 cycle is not greater than 4.
(NMF)
OO T 6 MF: Tax module is in status 29.
(IMF/BMF)
TIF: N/A
PA T None MF: N/A
TIF: All of the following must apply:
—Tax module has a MF Status greater than 06.
—Current Service Center status is in the range of 19, 20, 21, 54, 55, 56, 57, 58.
—CSED has not expired or there has been activity on the module within the last cycle.
(IMF/BMF/NMF)
PB T None MF: N/A
TIF:
(1) NMF tax modules in TDA status are established on the TIF as reason code PB.
(2) All of the following must apply:
—Tax module has an MF Status greater than 06.
—Current Service Center status is in the range of 22 or 24 or 26.
—CSED has not expired or there has been activity on the module within the last cycle.
(IMF/BMF/NMF)
PC T None MF: N/A
TIF: All of the following must apply:
—Tax module has an MF Status greater than 06.
—Current Service Center status is in the range of 60–64.
—CSED has not expired or there has been activity on the module within the last cycle.
(IMF/BMF/NMF)
PD   None MF: N/A
TIF:
(1) Tax module DEFERRED-ACTION-IND is on.
—or—
(2) All of the following must apply:
—Tax module has a MF Status greater than 06.
—Current Service Center status is 41–44 or 47–51 or 71, 72, 80–89.
—CSED has not expired or there has been activity on the module within the last cycle.
(IMF/BMF/NMF)
QQ E & T 12 for entity MF: N/A
TIF:
For entities:
CURRENT-CYC minus the CLOSURE-CYC of the ENT-TDI-COMPLIANCE-REC is less than 12.
For tax modules: (Contains TDI-MOD-STATUS-CD) equal to 1, 4, 5, 6, 7 or 9) or (DELAY-TDI-CD equal to 2, TDI-MOD-STATUS-CD = 0, and MF STATUS less then 6).
RF T MFEXCL MF: The module is frozen due to a TDI Refund Freeze.
TIF:
N/A
RG T 3 MF: A TDI Refund Freeze was released in the module.
TIF:
N/A
SS T 5 MF: N/A
TIF: All of the following must apply:
—Tax module contains TDI-MOD-STATUS-CD of 0.
—No TC 150 is present in the module.
—Module contains a pending or posted TC 474.
—Current cycle minus the TC 474 cycle is less than 5.
—There is no subsequent TC 590, 591, or 593–599 (if posted and pending transactions have the same cycle, consider the posted ‘Subsequent’ to the pending).
TR E & T None MF: N/A
TIF: AIMS or TDI account transferred from another Campus (prior to MF update). Or, the PDC-ID-CD is set to a value greater than zero.
T1 T None MF: N/A
TIF: All of the following must apply:
—Current Master File Status is 23.
—TDI-CD not equal to 0, 2, 8, 9, T, X, Y, or space.
—RWMS-QUEUE is 0 or 1.
(IMF/BMF/NMF)
T2 T 64
(from MOD-STATUS-CYC of TIF–50)
MF: N/A
TIF: Tax module TDI-CLOSURE-TYPE is equal to 8 and the TDI-CD is equal to 1, 2, or 8.
(IMF/BMF/EPMF/NMF)
T3 T 4
(from TRANSFER-CYC Of TIF–32)
MF: N/A
TIF: Account TDI-CD is equal to T (transfer) and the module TDI-MOD-STATUS-CD is significant (not equal to 0 or b).
(IMF/BMF/EPMF/NMF)
T4 T 3 (BMF, EPMF, NMF)
10 (IMF)
(from MOD-STATUS-CYC of TIF–50)
MF: N/A
TIF: Module TDI-MOD-STATUS-CD is equal to 2 or 8 and the Account TDI-CD is significant.
(IMF/BMF/EPMF/NMF)
T5 T 26 MF: N/A
TIF: Current cycle pending transaction ‘DI’ 590 with closing code 20 or 75 (recall trans). (IMF)
UA E & T None MF: N/A
TIF: Module contains an open CONTROL-BASE with CASE-STATUS-CD equal to A.
UB E & T None MF: N/A
TIF: Module contains an open CONTROL-BASE with CASE-STATUS-CD equal to B.
UM E & T None MF: N/A
TIF: Module contains an open CONTROL-BASE with CASE-STATUS-CD equal to M.
US E & T None MF: N/A
TIF: Module contains an open CONTROL-BASE with CASE-STATUS-CD equal to S.
VV E & T 3 MF: N/A
TIF: Module contains a CONTROL-BASE that was closed within the last 3 weeks (current date minus ACTION-DT). Can be changed to 1 or 2 weeks by using early aging cards.
WA E & T None MF: N/A
TIF: For IMF/BMF/EPMF:
Module contains an AP or PN pending transaction. For NMF:
Module contains a AP pending transaction.
WO E & T None MF: N/A
TIF: Module retained on IDRS because it has a transaction with pending status other than AP, PN, NU, or Unnn.
(IMF/BMF/EPMF)
WR   None MF: N/A
TIF: Account contains an entity pending
reject transaction.
(IMF/BMF/EPMF)
WU E & T None MF: N/A
TIF: Module contains a NU or Unnn
pending transaction.
(IMF/BMF/EPMF)
XX E & T 2 MF: N/A
TIF: ENTITY: Module contains a DI transaction (other than TC 004 or 008) and either—Current cycle minus the transaction cycle (of DI transaction) is not greater than 1 or—DI transaction contains a partial DLN (non-NMF accounts)
MODULE: Module contains a DI Transaction and either
—Current cycle minus the transaction cycle (of DI transaction) is not greater than 1 or
—CTRL-DAY is less than 400 and DOC-CD is 49.
YC E & T 3 MF: N/A
TIF: Module is a dummy established on the TIF, within the last 3 cycles, by card input to IDRS Daily Update Program.
YD E & T 3 MF: N/A
TIF: Module is a dummy established on the TIF, within the last 3 cycles, by IDRS Daily TIF Update Program.
YO E & T 3 MF: N/A
TIF: Module is a dummy established within the last three cycles by means other than those used to create modules with reason codes YC, YD, and YY.
YY E & T


E
3


Until PENDING-IAGRE-CD is spaces
MF: N/A
TIF: Module is a dummy established on the TIF, within the last 3 cycles, by IDRS realtime transaction.—or—Dummy module created by Command Code "IAPND" .
ZZ E & T 3 MF: N/A
TIF: Memo entity or tax module established on the TIF within the last 3 cycles.
$$ E & T 3 MF: N/A
TIF: A TC 904 appends to the entity or tax module in Last 3 cycle.
** T 6 MF: A CP71 or 71A has been issued.
(IMF)
TIF: N/A
Additional Information:     If the PENDING-IAGRE-CD in the TIF–00 (BASIC-ENT-REC) is significant, the entity will be retained even if no other criteria applies.

More Internal Revenue Manual