Tax Forms Processing
2-D Barcoding Standards

Revision 2004v2
July 26, 2004

NOTE - For any filing for previous years, the appropriate annual-release standards version should be used.

Uniform Practices/Standards

By agreement of all market participants, use of these 2-D Standards (including Appendix 1) is designated mandatory. Our procedure is to continue to discuss appropriate issues as warranted and, where possible, come to agreement on what ought to be raised to the level of a mandatory Standard, based on group consensus.

1. General
One agency point of contact should be established to assist with questions and issues in implementation of 2-D barcoding.

There should also be a second point of contact as a backup for the primary person. 2-D specifications should include a phone, fax, e-mail and physical address for these individuals.

In some situations, an agency will have separate personnel that handle the 2-D approval process for vendor data output submitted, and for vendor substitute forms. Each should be listed, along with information for backups.

2. Forms Design
Agencies should examine their candidate tax form(s) carefully to determine whether 2-D can be used effectively. The tax agency should design the 2-D enabled tax form; this cannot be the responsibility of a vendor.

Form design should change as little as possible:

1. Regarding capture of tax data for forms where one barcode is insufficient: A "barcode data sheet" approach, or alternatively a barcode per schedule approach, has now been successfully used that permits the capture of greater government-required return data volumes. This approach can be designed for Individual and Business tax returns. See the 2-D Guidance document for descriptions of experience with these approaches. The 2-D government and industry partners have chosen NOT to establish standard(s) for the use of multiple barcodes on tax forms at this point in time, since additional experience is needed to determine best standards practice.
2. Tax agencies should design a maximum of two versions of the form. One version will be printed in the official tax booklet. Since filers of this version will not be using software, a 2-D bar code will not be printed on this version. The second version will be used by software developers to incorporate a 2-D bar code. This version will comply with the computerized industry standards (http://www.nactp.org/Standards.pdf). If a software developer does not support 2-D bar codes, the area reserved for the bar code would be left blank. Therefore, a tax agency may not require a form ID or 1-D bar code in the same space reserved for the 2-D bar code. See illustrations below:
   
   

   Tax Form PDF Example - Handprint (Official Tax Booklet Version)

   Tax Form PDF Example - computer generated (with 2-D Barcode) (Computerized Version - may or may not contain a 2-D barcode)

3. Tax agencies should designate a place on the form for the 4-digit vendor ID listed in Appendix 1 to be printed in addition to being in the 2-D bar code. This will help tax agencies to identify the software developer responsible for creating the form and data, or data only, for troubleshooting purposes. It is preferred that the software developer be contacted first by the tax agency if an issue arises rather than contacting the preparer or taxpayer.
4. There are cases where the company producing the form is different from the company creating the data and 2-D bar code on the form. It is recommended that in these cases an additional space on the form be reserved for the 4-digit vendor ID listed in Appendix 1 for those companies only responsible for creating the form.
5. If feasible, a tax agency can choose to only use one design for both the official form and the software developer version as long as the design complies with computer industry standards.
6. Agencies may desire to employ a separate address for quicker processing. In consideration of those companies who support more than one software program with the same graphic image, tax agencies are asked to keep the following guidelines in mind:
7. Tax agencies that intend to establish a separate address to receive returns containing 2-D barcodes should do so by June 15. This will enable companies to allow for the new address in their planning processes for the upcoming tax season.
8. If the form has a "where to mail your return" area, all applicable addresses for both 2-D and non 2-D returns should be included on the computer generated version of the form. Both 2-D and non 2-D addresses should be included because the same computer generated form will be used by all companies regardless of whether or not they support 2-D.
9. If the addresses are printed on the return, the tax agency should provide some "educational" language describing use of a 2-D bar code to gain greater compliance among tax practitioners and taxpayers.
   
   An example of how to handle multiple mailing addresses can be found on Delaware's Form 200-01, which reads in part,

   "If a 2-D barcode (black and white shaded box) appears in the upper right corner of page 1 of this form, send the return to one of the following addresses" and "If a 2-D barcode (black and white shaded box) DOES NOT appear in the upper right corner of page 1 of this form, send the return to one of the following addresses"
   
   each of which is followed by a listing of pertinent addresses.

10. If the tax agency chooses not to include all addresses for 2-D and non 2-D returns, or space limitations do not allow all addresses to be printed on the return, the software developer may print only the address that is applicable on the return. Example: If a software developer is implementing 2-D barcodes for a tax agency, it may print just the 2-D barcode address on the return. If a software developer is not implementing 2-D barcodes for a tax agency, it may print just the non 2-D barcode address on the return.
    
    NOTE: If a tax agency chooses to print only the applicable addresses on the return, the tax agency must provide an alternative option for software developers that cannot comply with this standard. The alternative option must be one of the other options in the standards: printing all addresses on the form with educational language included; or not printing any addresses on the form but rather printing a statement referring the taxpayer to the instructions.
    
11. If the tax agency chooses not to put all addresses on the forms, it is recommended that any specific 2-D only address be included along with the existing address in the printed instructions (preferably in bold print) under the "where to mail your return" area. If there is no "mailing of return" area on the form itself, a reference to the tax form instructions for mailing should be noted:
    
    Please follow the mailing instructions provided by your tax preparer or tax software package.
    
    
12. All mailing addresses should be printed in the instructions, preferably with the 2-D barcode address(es) in bold.
13. The National Association of Computerized Tax Processors has established Tax Forms Design Guidelines . These Guidelines should be reviewed well prior to 2-D implementation. Click here to access this information.

This bulleted list contains basic design standards for substitute full-page forms, and vouchers and coupons.

2.a. Paper and Ink

1. paper size = 8-1/2 inches x 11 inches
2. paper printing = single-sided
3. paper weight = 15- to 20-pound bond (20-lb. bond is minimum paper weight for scannable forms)
4. paper color = white
5. ink = black

2.b. Form Text Design

1. page orientation = portrait
2. lines per vertical inch = 6 (1/6 inch) vertically
3. characters per horizontal inch = 10 (1/10 inch) horizontally
4. margin = 1/2-inch margin on all sides
5. vertical printable area:
6. first line = row 4 for first page and row 5 for subsequent pages (based on 6 lines per vertical inch)
7. last line = row 63 (based on 6 lines per vertical inch)
8. horizontal printable area:
9. first printable space = column 6
10. last printable space = column 80
11. box size = minimum 1/10-inch wide by 1/6-inch high (to print a single "X" or single character inside a box)
12. avoid shading or screens in text areas
13. cannot reproduce reverse letters and numbers (white characters with a black background)
14. cannot reproduce rotated text (no landscape font available)
15. recommended that unique logos and tax agency seals not be used, as many software developers are unable to support bitmap images on their printed forms

2.c. Requirements for Vouchers and Coupons

Size:

1. height = 3-2/3 inches to 5-1/2 inches maximum
2. width = 8-1/2 inches (to avoid vertical cut lines)
3. margins = 1/2 inch around each voucher (even if more than one voucher is on a page, a 1/2 inch margin around each voucher must be maintained)

For more, See NACTP's established guidelines (Tax Forms Design Guidelines) at www.nactp.org.

3. 2-D Barcode Technical Matters

A uniform dynamic link library (DLL) that has application across all tax agencies and forms is available from tax agencies that are implementing 2-D barcoding for tax forms. A PDF-417 testing tool and instructions on how to obtain a CD-ROM with additional information on 2-D barcoding are also available. Software developers should contact the tax agency for which they are developing 2-D capable software for further information.

1. PDF 417 has error detection and correction capabilities. The more error correction is used, the less data can be communicated in the barcode. With respect to data capture, you either get 100% or nothing. Complete barcode read failures are very uncommon. The tax Application Programming Interface (taxAPI) sets parameters for correction/detection. These parameters should be observed and not altered.
2. Based on the experience of previous filing seasons of 2-D barcode use, and due to the low level of deterioration of tax returns (compared to high media-abuse environments) the error correction level in the current market-provided DLL is set to level 4.
3. A general rule that can be used to determine if a printer is capable of producing a 2-D barcode is if the printer can produce a graphic such as a tax agency seal or business logo, then the printer should be capable of producing a 2-D barcode that can be scanned.
4. Pixel shaving is a technique that produces higher-quality barcodes when printed on lower-quality equipment like inkjet printers. Pixel shaving will result in improved read rates. In the DLL, pixel shaving will always be turned on.
5. Increasing the x (horizontal) dimension of the barcode elements from the minimum of 7.5 mils to the maximum of 25 mils will produce the most readable barcodes, especially on low quality ink/bubble jet printers. Whenever possible, software vendors will create a barcode that uses the largest possible x element value for the given space.
6. Users are advised that stretching or scaling the barcode (via copying the paper media or the like) changes its integrity and worsens readability; it should not be employed.
7. 2-D barcodes should never be rotated. Rotating a 2-D barcode increases processing difficulty and introduces the risk of errors. Since PDF-417 barcodes are read in both the x (horizontal) and y (vertical) directions on a portrait page, rotating them from their natural position can render the barcode unscannable.

3.a. Barcode Size and Placement on the Form

Each tax agency must define the area of the form in which the 2-D barcode is to be placed. Tax agencies must specify the maximum rectangular dimensions that will enclose the barcode and the location of that rectangle on the form. Software vendors will generate an appropriate 2-D barcode within the space defined. The rectangle can be of any size. However, software vendors recommend a rectangle that has a 2:1 ratio, that is the width is twice the height, as this allows for the creation of an optimal barcode and therefore will provide the best read rates for the tax agencies. If an area that has a different width to height ratio is specified, the software vendor will generate a 2-D barcode within the space allotted, however read rates may be reduced.

3.b. Barcode Layout

The data contained in a 2-D barcode can be broken down into three general sections.

1. Header Information

2. State Specific Data

3. Trailer

Each section is discussed separately below.

3.b.1. Header Information

There is information generic to all barcodes that should be placed first in the barcode data stream. The first two fields in the barcode comprise the header. The fields in the header are variable length and therefore can contain as much or as little data as is necessary. Each field in the barcode is delimited by a single carriage return. This separates each piece of data so it may be efficiently processed. The header information must be consistent among all barcodes and is defined below.

(Note: The symbol <CR> is used to represent a single carriage return character.)

3.b.2. Header Field Definition and Order

Header Version Number - The version number will be incremented each time the standards group alters the physical structure of the 2-D barcode header. This allows intelligence to be applied to processing 2-D barcodes that were created using multiple header formats. By using version numbers, software can correctly interpret 2-D barcode headers whose format has changed across fiscal years or within fiscal years. This field is static for all barcodes and is currently "T1".

Developer Code - A four-digit code used to identify the Software Developer whose application produced the bar code. The purpose of this field is to allow forms to be traced to the vendor producing the 2-D barcode. Software Developer codes are assigned through the NACTP. If you are a company interested in developing a 2-D based tax product offering, contact NACTP at the address listed in Appendix 1 to request an ID. Also see Appendix 1 for a current list of Company IDs.

3.b.3. State Specific Data
[These fields are optional -- they can be included by tax agencies in their specifications, if desired.]

The State Specific Data section immediately follows the Header Section. This is where the state places all the data and or fields it wishes to capture from a form. It is suggested that the following fields be added to the state’s field layout before adding taxpayer data to the barcode data stream. These fields may be useful for your backend process. Include them only if your system requires them.

The following fields are NOT required. Do not include them if your backend process does not use them.

Jurisdiction - An alphanumeric identifier indicating the taxing jurisdiction. Use US Postal Service's official state abbreviations. All Federal tax forms should use the code "US". This field should always be upper case.

Description - An alphanumeric identifier used to describe the form being processed. The identifier can be used to route the barcode information to the correct system for further processing. If no special routing or identification information is needed, the field should be blank. In situations where tax agencies are processing different forms with the same equipment, it is important to be able to uniquely identify the form before further processing of the barcode information can occur. As tax agencies add 2-D barcodes to more of their forms, this field will become increasingly important. Remember to always assign a unique value to this field for each form or form set you are processing.

Specification Version - A number that identifies the version of the specifications used to produce the form barcode. These specifications are provided by the jurisdiction processing the form and describe the data layout in the barcode. Draft versions of the specifications are not assigned version numbers. The final version shall be "0", revision thereafter will increase numerically.

Software/Form Version - A vendor defined version number that reflects the software and form revision used to produce this barcode. This field can be used to track users that are submitting returns using old software. This indicator should be set once the barcode has been approved and incremented each time there is a change made to either the barcode itself or any fields contained in the barcode. This item will only be incremented when there are changes made that would affect the content of the barcode; it will reflect the current bar code release - it will not necessarily indicate the version number of the software release of the general tax product. 

3.b.4. Trailer

The last field in the barcode data stream is the trailer. The trailer is used to indicate the end of data has been reached. A static string of "*EOD*" is used as the trailer value. Checking for the trailer gives the tax agencies an accurate method for determining if all the data supplied by the vendor was received by the tax agency. If the trailer value is not the last field in the barcode this indicates a data overflow condition has occurred. The tax agencies need to process forms where there is more data on the form than will fit in the barcode by other means. How to process forms that overflow the capacity of the 2-D barcode is beyond the scope of this standards document and is left up to tax authorities to determine.

3.b.5. Examples - 2-D barcode data streams

EXAMPLE 1

T1<CR> Header Version Number

1111<CR> Developer Code

IN<CR> State Specific Data

IT40<CR> State Specific Data

0<CR> State Specific Data

.

.

.

*EOD* <CR>

EXAMPLE 2

T1<CR> Header Version Number

9999<CR> Developer Code

CA<CR> State Specific Data

540_2001<CR> State Specific Data

1<CR> State Specific Data

.

.

.

*EOD* <CR>

Additional technical guidance on PDF417 can be obtained from the Association for Information Management at www.aimusa.org.

4. File Format
Data Flow

The barcode can contain any taxpayer-entered data that appears on the printed return. The printed return refers to the return as it would ordinarily be submitted to the revenue agency.

1. Tax agencies should make their 2-D specifications follow as closely as possible their print form specifications, and make the field formats consistent with them.
2. However, keep any field lengths designed to contain any captured federal data consistent with E-filing specifications.
3. Taxpayer-entered data that does not appear on the printed return should not be included in the barcode. Examples of this would be (1) Direct Deposit information that does not appear on the printed form; and (2) pennies, which are entered by taxpayers but not included on the printed form.
4. Data that is necessary for machine processing and is not taxpayer-entered, such as a form separator, may be included in the barcode. This data would be the same for all taxpayers and will be hard-coded in the barcode record.
5. Late tax form changes - in addition, any changes late in the software development season -that is, after October 1 - to a 2-D enabled form specification should be added at the end of the data layout, to simplify the software industry developer's task in coping with them. Then, during the development period prior to the next filing season, data fields can be re-ordered according to the form layout.
6. Federal return data, other than 1099 and W-2 information, cannot be captured in a state tax return barcode. State tax agencies wishing to capture Federal information should include it on their own forms/schedules.
7. Tax agencies may optionally include calculated fields in the barcode, if desired, but they are not required to do so, as they can be re-calculated after the 2-D barcode has been read.
8. Supporting Statements - A supporting statement is an attachment to a tax return that is required by the tax agency but is created by the tax software without a specific form. Official forms and schedules supported and created by the tax agency, W2s and 1099s are not considered supporting statements . Because the data from supporting statements creates a risk of exceeding the data size limits of the barcodes, tax agencies that require them should not include data from those statements in their 2-D barcode specifications.
9. Example: An example of a supporting statement is a listing of dependents. If there are only four lines on the main tax return to enter dependent information, and the actual number of dependents is six, a separate list must be attached to the return and is considered a supporting statement.
   

4.a. FIELD FORMAT TABLE

This chart outlines the treatment of data fields for print vs. 2-D barcode formatting, and is included here for reference purposes. It is offered to illustrate the differences between print format and 2-D barcode data.

As a general rule the field lengths of 2-D barcode data should never exceed that of the printed form. Tax agencies need not make changes to their forms for 2-D data capture unless they specifically wish to alter the data captured from their printed forms.

In general, when developing specifications for the 2-D barcode, use the current printed form standards already in place for the form in question as pertaining to the physical appearance of the form.

The fields listed below are those that commonly appear on tax returns. NOTE: This list of common fields will be added to as additional tax applications are implemented by taxing jurisdictions.

Fields not appearing in the table, that are determined after discussion with the 2-D Standards group to be specific to a particular tax agency, should be defined in that tax agency's specifications.

Regarding the data that is captured for the barcode, all non-essential data, commas, whitespace, leading zeros, should be removed.

DESCRIPTION			PRINT FORMAT		2-D BARCODE FORMAT
Dollar Amounts	Individual Returns		999,999,999. -99,999,999. 12 positions		999999999 -99999999 (significant digits only) 9 positions
	Business Returns		99,999,999,999. -9,999,999,999. 15 positions		99999999999 -9999999999 (significant digits only) 11 positions
Dates	Date without Century		XX/XX/XX 8 positions		XXXXXX 6 positions
	Date with Century		XX/XX/XXXX 10 positions		XXXXXXXX 8 positions
Taxpayer Info	Taxpayer Name		35 positions		35 positions
	Spouse's Name		35 positions		35 positions
	In Care Of		35 positions		35 positions
	Address:		35 positions		35 positions
		Private Mailbox		7 positions		7 positions
		City		21 positions		21 positions
		State		3* positions		2 positions
		Zip		XXXXX-XXXX* 10 positions		XXXXXXXXX 9 positions
	Taxpayer SSN Taxpayer EIN		XXX-XX-XXXX 11 positions XX-XXXXXXX 10 positions		XXXXXXXXX 9 positions XXXXXXXXX 9 positions
	Spouse SSN		XXX-XX-XXXX 11 positions		XXXXXXXXX 9 positions
	Taxpayer Occupation		20 positions		20 positions
	Spouse Occupation		20 positions		20 positions
	County		25 positions		25 positions
	School District		25 positions		25 positions
	Telephone Number		XXX-XXX-XXXX* 12 positions		XXXXXXXXXX 10 positions
Preparer Info	Firm Name		35 positions		35 positions
	Firm Address:		35 positions		35 positions
		City		21 positions		21 positions
		State		3* positions		2 positions
		Zip		XXXXX-XXXX* 10 positions		XXXXXXXXX 9 positions
	FEIN		XX-XXXXXXX* 10 positions		XXXXXXXXX 9 positions
	PTIN		9 positions	XXXXXXXXX	9 positions	XXXXXXXXX

* = may be preceded by a space

(Note: Depending on how the fields are generated by the different software companies, fields for Paper Returns, Electronic Filing, and 2-D barcodes may be interrelated. The field that actually appears on the printed form, in many cases controls how much data can be entered into an ELF or 2-D Barcode Field.

Example: If there were space constraints on the printed form which limited the County Name field to 15 Characters, this may affect 2-D and ELF lengths. If the ELF field and 2-D Barcode field were set at an allowable 25 characters, due to the Printed Form limitation of 15, only 15 characters would ever print in the ELF or 2-D Barcode fields.)

4.b. Field Standards for the 2-D Barcode
General Guide:

NOTE: Do not Zero-fill fields.

1. For blank fields, use a carriage return
2. Date -- MMDDYYYY, MMYYYY, YYYY, MMDD
3. Check boxes should be rendered as printed; if blank, use a carriage return (example: if "Yes" box is checked, use an "X")
4. Fields should never be Zero filled. To zero fill means to fill up the entire allowable length of the field with zeros. If the printed form requests that the field always contain some value or, if no value, then a single zero can be passed to the barcode.
5. Ratios and Percentages - these should match the data requirements that are established for printing on the form.
6. Filing Status Responses: In the 2-D barcode, these should be treated as they would on their equivalent printed form - most commonly, several separate check boxes (one for each possible filing status) appear on the form with one field having a response of "X" and the others left blank; the other option is to create a line on the form for taxpayers to enter an alphanumeric response (i.e., a, b, c or 1, 2, 3) as defined on the printed form by the tax agency.
7. Treatment of Calculated Fields - inclusion of calculated fields is up to the tax agency - data volume for "fit" within the barcode is the only issue.

4.c. Field Standards for Printed Forms
Round numbers to the nearest whole dollar amount followed by decimal point (omit cents or cents line)

1. Dollar amount field size is based on 10 characters per inch:
   1. individual returns = 12 characters max. $ amt. 999,999,999.
   2. business returns = 15 characters max. $ amt. 99,999,999,999.
2. Data field delimiters programmed as:
   1. social security numbers: "-" delimiter XXX-XX-XXXX
   2. employer Identification numbers: "-" XX-XXXXXXX
   3. dates: "/" delimiter XX/XX/XX
   4. negative values: "-" floating minus sign - XXX
   5. telephone numbers: "-" delimiter XXX-XXX-XXXX
3. Data type description and minimum number of print positions required are: (Note: *characters may be preceded by a blank space.)
   1. taxpayer's name : 35
   2. spouse's name: 35
   3. in care of: 35
   4. address: [35]
      - city (if separate field): 21
      - state (if separate field): 3*
      - zip (if separate field): 11*
   5. taxpayer's social security number: 11
   6. taxpayer's employer identification number: 10
   7. spouse's social security number: 11
   8. taxpayer's occupation: 20
   9. spouse's occupation: 20
   10. county: 25
   11. school district: 25
   12. telephone number including area code: 13*

Preparer information section: (Note: *characters may be preceded by a blank space.)

1. Data type description and minimum number of print positions required are:
   1. firm name: 35
   2. firm address: [35]
      - city (if separate field): 21
      - state (if separate field): 3*
      - zip (if separate field): 11*
   3. federal identification number: 10

5. Testing/Approval Procedures

NACTP has issued guidance on recommended testing and approval processes. See www.nactp.org for additional specifics. As a general guideline, current software testing and forms approval timeframes and quality assurance practices should be followed in the implementation of 2-D barcoding.

a. Testing Processes

1. The taxing agency must supply substitute forms developers with the test data to be used for the 2-D barcode:
- It is recommended that E-file customers serve as the test client base for 2-D applications.
- Taxing agencies test scenarios must be provided on a copy of the taxing agency's form.
- Test scenarios must be accurate and complete.
- Testing scenarios should include all fields required for full testing of the 2-D barcode. This should include agencies required fields such as SSN, FEIN and county/school codes.
- Taxing agencies may base their test cases off the PATS testing scenarios. If the current year's PATS test cases haven't been released, taxing agencies can use the prior year's test cases.
- Testing scenarios should be made available upon release of the 2-D specifications to expedite the testing procedure.

In addition, taxing agencies can offer software vendors the opportunity to create their own test scenarios based on the agency's criteria. This allows software developers to forward forms earlier for approval when the test scenarios have been delayed.

2. Number of test scenarios
Up to six (6) sets of forms can be submitted for approval, to include:
- One set of blank forms
- A maximum of five test scenarios per form with either the same or different test scenarios.
- If an agency requires a full field test scenario, this test sample must be part of the five scenarios allowed.

b. Approval Procedures

The taxing agency should provide up-to-date contact information to software developers regarding forms acquisition and approval, including accurate email addresses and web site information.

1. Taxing agencies should update their primary contact information in the interactive members only section of the NACTP web site. Contact the [email protected] for instructions to update this information.
2. Taxing agencies must provide accurate backup contact information in case the primary contact is unavailable.
3. To facilitate forms approval, NACTP's preferred method of providing test scenarios for 2-D barcode testing is via PDF. Whenever possible, taxing agencies are encouraged to support and allow PDF submissions by those software developers that are able to do so.
4. Form content/format and the 2-D barcode data string should be approved separately and simultaneously, if possible, to facilitate vendor internal processing and expedite the approval process.
5. Software developers should provide a cover sheet/letter attached to the forms with a list of the forms submitted and an area for an approval signature.
6. Taxing agencies should notify software developers of the outcome of their review within 10 business days of receipt of the substitute forms.
7. Resubmissions: Software vendors should be notified within three (3) business days of receipt of substitute forms resubmitted.
8. Forms deemed "approved with corrections" should not require resubmission.
9. If the state agrees, early testing can be done by submitting returns for a "preliminary approval". The 2-D barcode approval will not be given until the state has ensured that all legislative changes have been included in the testing of the 2-D barcode.

6. Barcode Specifications and Version Control Process

1. Any document a tax agency issues to developers should be numbered in sequence, dated, and should include revision marks to indicate changes.
2. The preferred document file format is portable document format (pdf).
3. Remove password protection from form files, especially if they are in a protected area designed for posting preliminary forms or other documents.
4. Updates and new forms and specifications postings should be announced through broadcast e-mail notification to software developers, including to the NACTP at [email protected].

7. Conclusion

Tax agencies, software developers, symbology vendors, tax administration systems integrators, and others are asked to support 2-D standards in their implementation of this technology.

Regular, ongoing standards discussions and opportunities for input will be afforded to tax agencies and market participants by FTA and NACTP. Continue to access www.taxadmin.org or www.nactp.org for updated information.

APPENDIX 1

Vendor Codes

November 4, 2004

CLICK HERE for a list of Vendor Codes (pdf file)