Internal Revenue Manual - 2.3.32 Command Code MFTRA

Part 2. Information Technology
Chapter 3. IDRS Terminal Responses
Section 32. Command Code MFTRA

2.3.32.1 (01-01-2003)
Introduction to IDRS Command Code MFTRA

IDRS Command Code MFTRA is used to request taxpayer information in the form of hardcopy transcripts. These requests are forwarded to the MF at MCC. After the information is extracted from the MF it is passed to the Service Campuses where the Transcript Research System (TRS) processes the data and formats the transcripts. These transcripts are then printed at the Service Campus or the Remote Office of the requestor. MFTRD/ACTRA display functionality was removed in January 2003.

2.3.32.2 (07-01-2008)
Overview of Master File Extraction Process - Obsolete Effective 07/2008

Transcript requests are fulfilled by several systems. The Microfilm Replacement System (MRS) is an automated research system that replaces most of the microfilm research for tax data in the Service Campuses and Remote Offices. MRS replaces the Taxpayer Name Directories with the Key Index File. The IMF and BMF Accounts Registers and IMF Spouse SSN Directory are replaced by parts of the Transcript Research System (TRS) which provide for requesting, extracting and editing MF transcript data. Retention Registers are produced for entity and tax modules removed from the Master Files. Requests for modules on Retention will be submitted using the current procedures. For example, all IMF accounts that have gone to Retention will continue to be found by researching the IMF Retention Register Microfilm with the appropriate District Office and year. Similarly, almost all BMF accounts that have gone to Retention will be located on the BMF Retention Register Microfilm. Some of the BMF MFT's that have gone to Retention in cycle 197901 or earlier can be found by searching the Residual Master File Retention Register microfilm. The partnership Name Directory and the national EO and EP Alpha Registers are produced on microfilm. Microfilm operations, which utilize document images (for example: FTD and WIRS) are not affected by MRS. WIRS data can be requested via Command Code MFTRA. FTD microfilm cannot be requested via MFTRA.

2.3.32.3 (01-01-2000)
Special Search Conditions on Master File

MF Search by TIN — Account Found Requests are researched at the MF via the input TIN. In the event the primary SSN is unknown, a request may be input with the Spouse's SSN and a Spouse SSN Indicator. This will cause a search of the MCC Spouse SSN XREF File using the input SSN. If a primary SSN is found, an attempt will be made to extract data from the MF for that TIN. The Primary SSN will become the account TIN on the hardcopy transcript.
MF Search by TIN — Account Not Found — If data is not found on the MF for a TIN, a search will be made of the TIN Change File at MCC. If a new TIN is found the requestor will be notified and the request itself will be held at MCC until the next night when an attempt will be made to extract tax account data under the new TIN.

2.3.32.4 (01-01-2003)
MF Search Order

Command Code MFTRA requests will be run against the various files at MCC in the following order:
1. Spouse's SSN Cross Reference File — If request indicates this search is necessary, this file is searched. It contains Spouse SSN references to Primary SSN for the current IMF Name lines.
2. Active Entities or Tax Modules are searched.
3. Inactive Entities or Tax Modules are searched.
4. Lower Levels — Normally, all extracted data will be extracted and returned to the user overnight. However, in unusual circumstances, data for older tax years which reside on the IMF and BMF Level 3 files at MCC will be delayed another day.
5. TIN Change X-Ref File — If the requested module is not on the Master File at all, the request will be passed against this file. If a TIN is found on this file, the requestor is notified and the request is automatically input in the next night's extract under the New TIN (exception: the request is a Spouse SSN request). The TIN Change X-Ref File contains a record of all TIN changes made at the MF from January 1978 to the present. TIN changes, which took place prior to this date, must be researched on the old microfilm.
6. DROPPED/DELETED Entity File — The DDEF is searched to see if an account has also been aged off or deliberately deleted under the same TIN even if the TIN is not on the Active Master File.

2.3.32.5 (01-01-2005)
Delivery Time Frames for Master File Transcripts

MCC transcripts obtained from the IMF and BMF files at MCC via IDRS Command Codes MFTRA are usually returned to the user within 24 hours if input prior to the cutoff time (4:00 p.m. EST).
Requestor should NOT ask for the same data twice in the same day. Duplicate requests tie up system resources. Potential abuse can be traced via a batch program (TRS91). MCC can only process a total of 100 requests for the same TIN per night. All requests over 100 will not be processed.
All requests are sent through a data communications link between MCC and each Service Campus on a daily basis. If the request is input prior to a specified cutoff time in the afternoon most requested data will be extracted from the Master Files that night and returned to the user the following day.
NUMIDENT transcripts will be returned in approximately three days. Hardcopy transcripts will be manually distributed at Service Campuses. Remote Office receive their requests via local printers. TIGTA transcript files are sent electronically by KCSC.

2.3.32.6 (01-01-2002)
Alternative Method of Requesting Master File Transcripts

For those users who have limited access to an IDRS terminal, requests may also be entered via other information systems. These requests are processed through a batch program (TRS90) before going to MF. Other IDRS Command Codes may have the capability of generating a transcript request but are not part of the TRS.

2.3.32.7 (01-01-2003)
Formats for Transcripts

Command Code TFTRA - Eliminated 01/2005.

2.3.32.8 (07-01-2008)
MFTRA Request Types

Various Request Types may be input with Command Code MFTRA. The request type determines the kind of data desired by the requestor and the extent MF sequence search described above. If the request is valid, and no entity for the TIN is found on the IMF or BMF, there will be an attempt to extract the same data from the Invalid Segment using the same SSN, on the following day. A request for a specific type will result in the most extensive search. This search will continue through the sequence, including the lower levels until the requested data is located (provided the account is present on one of the files). Request Types C, B, +, -, A, D, Y, Z, # and T will not physically search the lower levels but will generally provide a list of modules available on the lower levels and a separate list of modules removed to the Retention Register. The following table describes the type of data returned for the various Request Types is as follows:

C	Complete — The complete entity module (including posted transactions) and all non-low-level tax modules followed by a list of all low-level modules. Do not use the " C" Request Type except in the rare instance where none of the other Request Types listed below are adequate. The overzealous use of " Completes" can jeopardize the 24-hour turnaround standard for all users.
M	MFT (BMF and IMF) — The entity module (except posted entity transactions), and all non-low-level modules for input MFT.
E	Entity — The complete entity module (includes posted transactions)
T	Transaction Code — The entity module (except posted entity transactions) and all non-low-level modules containing requested transaction code.
A	Transaction Amount — The entity module (except posted entity transactions) and all non-low-level tax modules which have a posted transaction with a money (debit/credit) amount matching the input Transaction Amount. If the transaction amount desired is a credit, input a minus (-) after the amount.
D	Transaction Date — The entity module (except posted entity transactions), and all non-low-level tax modules with a posted transaction carrying the same Transaction Date as the input Transaction Date.
B	Open Balance — The entity module (except posted entity transactions) and all non-low-level tax modules that meet offset criteria. If no modules meet offset criteria, only Entity information will be supplied.
+	Debit Balance — The entity module (except posted entity transactions), and all non-low-level tax modules which meet offset criteria. If no modules meet offset criteria, only Entity information will be supplied.
–	Credit Balance — The entity module (except posted entity transactions), and all non-low-level tax modules with a credit module balance.
P	Plan Names and Plan Data — Eliminated 01/2004. Use EMFOL.
Y	All BMF Tax Modules for One year — The entity module (except entity posted transactions) and all of the non-low level BMF Tax Modules for the requested one year period.
X	BMF or IMF hardcopy literal transcripts are designed primarily for taxpayer and/or taxpayer representative use. Request Type "X" is unlike most Request Types, since it will search for and extract data for a Tax Module which has been inactivated to the Lower Level File.
L	Lower Level MFT (BMF and IMF) — The entity module (except posted entity transactions) and all lower-level modules for the MFT input (hardcopy only). The Lower Level Files contain dormant modules which are not yet old enough to go to Retention.
Z	Request for a Specific Tax Module from the Annual Temporary Retention Register Backup File — The entity module (except posted entity transactions) from the Active Master File and the Specific Tax Module that has just gone to Retention in cycle 01 (hardcopy only), from the Annual Temporary Retention Register Backup File. Only the current year is held on the ATRR Backup File. It is updated weekly on Fridays.
G	Debtor Master File Transcript — Eliminated 01/2005.
W	Wage Information Retrieval System - Eliminated 07/2008.
#	Document Locator Number — The entity module (except posted entity transactions), and all non-low-level tax modules which have a transaction with the DLN matching the input DLN.
K	Yearly BMF Literal transcript for all MFTs.
U	NUMIDENT Transcript — Contains entity information from the Social Security Administration (SSA).
	If none of these Request Types are input, a specific tax module request will automatically be generated. It will provide the entity module (except posted entity transactions), and the requested tax module from whatever level it is on. A list of Retention Register information will be provided only if the module is not on the MF and is old enough to be on the retention register, and the entity module exists on the active MF.
J	Form 4340, Certificate of Assessments, Payments, Other Matters was implemented 07/02/2001 for specific work units.

2.3.32.9 (01-01-2003)
MFTRA Request Format

CC MFTRA subsequent line(s) will display the TIN, MFT and Tax Period. To request complete the request(s), input the Start of Message Indicator (=) in the position preceding "MFTRA" and drop down to the subsequent line(s) to include desired displayed data in the input. If additional input data is required it must be manually input. See Exhibit 2.3.32-6.

2.3.32.10 (01-01-2003)
Terminal Messages and Responses

The following table displays the message returned and the possible corrective action.

MSG	PLEASE CORRECT INVALID/INCONSISTENT FIELD(s)
*	If data is invalid, or invalid and inconsistent, an asterisk will appear to right of the field(s).
?	If input data is inconsistent only, a question mark will appear to the right of the field(s).
RESP	Correct data and re-enter.
Note	To facilitate the correction of the screen for re-entry, the cursor will be moved to position one on the first line that has within it at least one invalid/inconsistent entry.
Note	If the TIN field is identified as invalid (*) and the correction results in a valid SSN, change the asterisk (indicating the invalidity) to a comma, to eliminate any possibility of the SSN being validated as an invalid-segment SSN.
Note	If a TIN is entered on both line 1 and line 2, then the TIN on line 2 will be marked as invalid (*).

MSG	LINE 24 CANNOT BE USED FOR INPUT
RESP	Remove information from line 24 entry and reenter.
Note	If data was input on Line 24 of the screen, lines 1 through 23 will be redisplayed with this message.

MSG	INPUT IGNORED — PREVIOUS REQUEST COMPLETED SCREEN HAS BEEN ERRONEOUSLY RE-INPUT
RESP	To use part of a previous screen, the "RC" or "IG" literals must be removed on lines that are altered.
Note	Lines having an " RC" or an "IG" literal are ignored on subsequent entries.

MSG	REQUESTS FOR MFTRD INVALID as of 01/17/2003
RESP	None.

MSG	REQUEST COMPLETED EMP# XXXXXXXXXX MMDDYY HH: MM
RESP	None
Note	Valid Response. Indicates that the request(s) is valid and consistent, and has been accepted.
Note	If there is only one request on the screen, and it has been accepted as valid and consistent, the cursor will be moved to the first position of the first line.
Note	If more than one request on screen, and at least one is accepted as valid and consistent, the cursor will be moved to the first position of the first line where the next batch entry would begin. Screen remains intact, to facilitate further requests.
Note	Only request lines without "RC" or "IG" in position 75 thru 76 are validated and accepted.
Note	Leftover screens with the REQUEST COMPLETED message on line 24 can be reused, but only entry lines without the "RC" or the "IG" literals will be processed.
Note	The "IG" literal replaces the "RC" literal when a line is retransmitted without removing the "RC" literal.