and
National Association of Computerized Tax
Processors
www.nactp.org
Frequently Asked Questions (FAQs) - short answers to questions that persons investigating the use of 2-D barcoding in tax forms processing frequently have. It is recommended that you read this, and then explore the somewhat more detailed document below.
1. Introduction
3. Forms Design
5. File Format
6. Testing
7. Specifications/Version Control
8. Promotion of the Use of Barcoding
10. Alternative Modes of Capture
11. Capture of More than One Barcode
12. Sample State Project Timeline
13. Software Developer Implementation Checklist
14. Glossary
15. Helpful
Contacts
Standards and Participation
In accord with significant growth in the use of 2-D barcoding for tax
processing during the 1999-2000 personal income tax filing season, in
May 1999 the Federation of Tax Administrators (FTA) and its state
agency members decided to work with representatives of the National
Association of Computerized Tax Processors (NACTP) on a 2-D standards
initiative.
It is clear that companies joining with tax agencies in supplying tax preparation products to taxpayers desire 2-D standards and uniform practices. A partnership with industry suppliers is critical to the success of the development of standards and the willingness of software companies to support state efforts to employ 2-D in tax processing.
Support Organizations
Federation
of Tax Administrators
The Federation of Tax Administrators (FTA) was organized in
1937 with a mission to improve the quality of state tax
administration by providing services to state tax authorities and
administrators, including research and information exchange,
training, intergovernmental and interstate coordination, and
development of technology standards.
The principal tax collection agencies of the 50 states, the District of Columbia, and New York City are the members of the Federation of Tax Administrators. Special committees or task forces are regularly appointed to consider specific issues and problems.
National
Association of Computerized Tax
Processors
The National Association of Computerized Tax Processors
(NACTP) is a nonprofit association that represents tax processing
software and hardware developers, electronic filing processors, tax
form publishers, and tax processing service bureaus. The association
promotes standards in tax processing and works closely with the IRS
and state governments to promote efficient and effective tax
filing.
Background on Standards Efforts
State revenue agencies and software developers have a mutual
interest in ensuring that 2-D technology is implemented (1) in as
consistent a manner across states as possible, and (2) with the
greatest degree of "fit" with current tax administration and business
processing streams.
To facilitate progress on these two goals, in July 1999 a meeting was arranged between FTA staff, member agencies, and others. Industry was represented by members of the NACTP Board and partners of the original implementing revenue agency.
Business and technical issues were discussed aimed at creating feasible and implementable standards for 2-D use. It was agreed by all that observance of such standard methods and practices by state agencies, and by private sector companies wishing to provide 2-D based products and services, will benefit everyone in the marketplace.
Your Support
It is important that tax agencies, software developers, symbology
vendors, tax administration systems integrators, and others support
effective and responsive 2-D standards to ensure the success of all.
This document is a starting point; contacts are listed at the end to
provide an opportunity for your continuing input.
FTA and NACTP are committed to working together on 2-D uniform practices and standards and welcome your assistance in the development and maintenance process.
History
The development of modern bar code began in 1948. Bernard Silver, a
graduate student at Drexel Institute of Technology in Philadelphia
overheard the president of a local food chain asking one of the deans
to undertake research to develop a system to automatically read
product information during checkout. Silver told his friend Norman
Woodland about the food chain president's request. On October 20,
1949, Woodland and Silver filed a patent application titled
"Classifying Apparatus and Method." The inventors described their
invention as relating "to the art of article classification...through
the medium of identifying patterns".
Most bar code histories state that the Woodland and Silver bar code was a "bull's eye" symbol, a symbol made up of a series of concentric circles. While Woodland and Silver did outline such a symbol, the basic symbology was described as a straight line pattern quite similar to present day 1-D bar code.
The symbology was made up of a pattern of four white lines on a dark background. The first line was a datum line and the positions of the remaining three lines were fixed with respect to the first line. The information was coded by the presence or absence of one or more of the lines. This allowed 7 different classifications of articles. However, the inventors noted that if more lines were added, more classifications could be coded. With 10 lines, 1023 classifications could be coded.
Barcode was not commercialized until 1966. The National Association of Food Chains put out a call to equipment manufacturers for systems that would speed the checkout process. It was recognized that the industry would have to agree on a standard coding scheme and that all food producers and dealers would have to adopt it.
By 1970, Parts 1 and 2 of the Universal Grocery Products Identification Code (UGPIC) were developed, and the U.S. Supermarket Ad Hoc Committee on Universal Product Coding was formed. Three years later, the Committee recommended the adoption of the UPC symbol set still used in the USA today. In June 1974, one of the first UPC scanners was installed at a supermarket in Troy, Ohio.
The United States Department of Defense boosted
the industrial application of barcode on September 1, 1981 when it
adopted the use of Code 39 for marking all products sold to the
United States military.
2-D Symbology
At this time, there are a variety of different barcode languages
called symbologies. Different industries and markets have adopted
different barcodes. Each symbology has strengths and weaknesses. The
various types of barcodes are characterized by their unique pattern
of bars and spaces to represent characters. The start and stop bars
at both ends of the symbol are also unique.
PDF-417 is a two-dimensional barcode that can store up to 1,800 printable ASCII characters or 1,100 binary characters per symbol. However, for technical reasons, the expected number of characters for tax applications per symbol is approximately 1,200.
The symbol is rectangular; the shape of the symbol can be adjusted to some extent by setting a standard width and allowing the height to grow with the data. It is also possible to break large amounts of data into several PDF-417 symbols that are logically linked. There is no theoretical limit on the amount of data that can be stored in a group of PDF-417 symbols.
The capacity of PDF-417 can be helpful in
applications where the data must travel with the labeled item, where
a host database is not available for quick look-up. PDF-417 is used
for hazardous materials labeling; storing technical specifications
and calibration data on electronic instruments; encoding fingerprints
and photographs on the backs of drivers' licenses and other forms of
identification; and now tax return processing.
PDF-417 symbols require a 2-D scanner. A number of scanners are on
the market using both laser and CCD camera technologies. PDF-417
symbols can be printed using most printers on the market. However,
daisy wheel and some dot matrix printers will not be capable of
producing a 2-D barcode that can be scanned successfully.
2-D Barcode Application to Tax
Processing
The following graphic depicts steps in the production and
processing of 2-D barcoded tax returns.
The NACTP Government Liaison Committee (GLC) strives to establish consistency throughout the tax processing industry for computerized substitute tax forms. NACTP members follow basic standards when redesigning tax forms, making them compatible with hardware restrictions. These standards are reflected in the NACTP Tax Forms Design Guidelines manual, published annually to facilitate the creation of products that are compatible with government processing systems.
When the decision was made to create a standards document for 2-D barcoding, these forms design standards were carried over to that document. Given the need for agencies implementing 2-D to perform forms redesign as an integral part of the implementation process, it was important that agencies understand the standards and constraints that the computerized tax processing industry works with.
While most agencies start forms redesign with a version of the form to be prepared by hand, such designs rarely translate well to the computerized preparation environment, which accounts for as many as 75% of all forms received. Therefore, since the inception of the 2-D Barcoding Standards effort, industry and government agencies have worked together to share information and educate one another on their respective requirements for forms design. The language contained in the current Standards document is the result of that process.
The guideline here is that barcode-enabled tax form design should change as little as possible, including only two versions of a form; this means that burden is reduced on the forms software developer. The posted 2-D Standards provide examples of a form with a 2-D barcode, and of one without. The Forms Design provisions also cover use of vendor IDs,special return submission addresses, and other tax form design matters. [Note it has been determined that for Foreign Addresses, agencies should follow their own guidelines for how to print foreign addresses on the form itself rather than creating a new standard for 2-D.]
PDF417 Bar Code Reading
This will describe various methods of reading PDF417 bar codes.
Devices, concepts, usage, minimum requirements, and other items will
be covered.
Bar Code Scanners
The simplest way to read, or scan, a PDF417 bar code is with a
hand held bar code scanner capable of reading PDF417. There are many
of these devices. There are three types of hand held devices that can
read PDF417 barcodes.
Page Scanners / Imaging Systems
These systems are designed to process full pages of paper at a time, and
are primarily used for imaging type applications. Some of the systems can do
OCR / ICR (optical character recognition, intelligent character recognition).
All use some sort of camera to take a picture of the page. Most imaging systems
today have some bar code reading capability. Many can read and decode PDF417
barcodes.
The specific requirements for an imaging system to be able to read PDF417 barcodes are sufficient resolution, measured in dots per inch (dpi) and sufficient levels of gray scale. There is a relationship between bar code size and the required scanning dpi. The basic assumption is that images must be scanned at 3 times the printed resolution to properly scan a bar code. The following table shows the recommended scanner dpi to read bar codes printed in various sizes.
|
Character Count in Symbol API |
Bar code X Dimension (in mil) |
Minimum Printer Resolution |
Required Scanning DPI |
|
More than 200 characters |
10 |
200 |
300 |
|
100 - 200 characters |
15 |
100 |
200 |
|
Less than 100 characters |
20 |
100 |
100 |
The commonly used API will automatically adjust the x-dimension of a barcode based on the total character count. This maximizes the size of the barcode and increases readability.
The scanner dpi listed is for black and white images only. It is possible to use grayscale information to decrease the required resolutions. For example, a 200 dpi scanner, with 16 levels of gray, can read PDF417 barcodes very well. In this case, the imager will use the grayscale information to simulate increased dpi.
Of the imaging systems that can read and decode PDF417 barcodes, there are two methods used in decoding the barcode data:
Barcode Printing
To print a readable barcode,
a printer capable of 200 dots per inch (DPI) minimum is required [300 DPI is
recommended]. Higher DPI images will also work and will generally produce sharper
barcode images but bitmap size increases may adversely affect print time and
memory requirements.
The capability exists to provide the user the discretion to set the barcode print feature to "on" or "off". The tax agency may wish to include a requirement that it be set to "on" in its 2-D specifications to ensure that the barcode print capability is utilized.
The file format appropriate for 2-D barcoded data was the subject of much discussion during the time that the first version of the 2-D Standards were initially developed (1999-2000). Many states and software developers believed that employing the existing E-file format, used to process E-filed returns, would be the simplest and fastest to implement.
However, after exploring the 2-D process, it was realized that there were significant differences in the E-file format and that employed to print a paper tax return. Moreover, software developers, which committed to adding computer code to their products to create the ability for tax agencies to capture taxpayer data digitally (with no directly recoverable addition to their revenue stream), strongly favored going forward with the development and maintainance of two - and not three - basic methods of creation of tax data for submission.
Thus it was agreed that the barcode production process, involving printing a tax form with a barcode, was much more akin to the print production process. Tax agencies wishing to process barcode return data through an E-file system simply convert the barcode datastream into an E-file format once received.
The current 2-D Standards thus outlines
Because the companies that create software for substitute forms are the same companies that a tax agency will work with on 2-D barcoding capability, the standards created for testing the appropriate capture of tax form barcode data and processing through the tax authority system have been adapted from existing guidance, with certain changes. The current 2-D Standards version cover (1) appropriate points of contact for forms and output, (2) submission timeframes, (3) approval procedures.
1. The general purpose of the testing
process is to:
- Test the readability of the 2-D barcode
- Confirm that the data format and placement within the 2-D barcode matches
the tax agency's specifications
- Industry recommends to tax agencies that 2-D barcode testing not be used for
tax calculation testing.
2. In general, the 2-D barcode testing process should consist of:
- A scan test to ensure that the tax agency's production scanners can read the
2D barcode as generated by the software developer.
- A data comparison between what is printed on the paper form and what is captured
in the 2-D barcode.
As a general guide, the NACTP has issued guidance on recommended testing and approval processes. In addition to the 2-D Standards, see www.nactp.org for specifics.
The current 2-D Standards version cover (1) version control/revision designation (2) specifications release schedules, (3) developer-preferred file format, (4) notification procedures.
Troubleshooting: For troubleshooting purposes,
a state may request that each software vendor
print an ID code at the bottom of each form. (Example: 1000OL; “1000”
would represent their 4-digit NACTP company code, and “OL” would
represent their online product. Or, “1000PR” where “PR”
would represent a print only product.) This will help the state determine for
which type of product the form is being produced and enable improved problem
resolution.
Front Loading Fixed Size
Data Sets. This method
places data sets in the barcode that don't change year-to-year above data that
is likely to changes year-to-year. For example:
1. If W2 data is captured, the same W2 fields are captured in subsequent years,
and dropped into the same location in the barcode.
2. If paid tax preparer data is captured, the same pieces of data are captured
in subsequent years, and are again given roughly the same index location.
3. If data is captured from supplemental forms/schedules and the data set is
not likely to change in subsequent years, this too would be front loaded. Generally
a barcode data set captured from an underpayment penalty form will not change
in subsequent years.
These data sets would be placed in front (above) of the data sets that are likely
to change year-to-year (i.e. the body of a base tax form). Using the above examples,
the typical bar code layout is presented as:
Static data
Heading section of the form
Base form data
Paid preparer data
Other forms and schedules
W2 Data
NACTP Best practices recommends bar code layout to be presented as:
Static data
Heading section of the form
Paid preparer data
W2 Data
Other forms and schedules
Base form data
Mirror Data Indexes Across Base Forms. When barcodes are present
on more than one base form (1040, 1040-NR) the corresponding index location
should match as much as possible.
For example: If the taxpayer SSN is in index 7 on Form 1040, it should also
be in Index 7 on the 1040-NR.
These “best practices” benefit both tax agencies and Industry by
reducing annual maintenance, coding, and testing time due to tax regulatory
changes, which reduces overall cost.
Fewer changes to specification documents will reduce errors and increases testing
and processing turnaround time. It may also make reducing the number of test
scenarios possible. Since there are fewer changes to the software, it also results
in higher quality each year. It is also possible these standards will help reduce
duplication of program logic and duplicate data that needs to be manipulated
and stored.
A state can take a variety of steps to educate the taxpaying public and tax practitioners on the value of the use of 2-D barcoding in tax processing:
The following information is based on the experience of the integration service provider involved in the initial state agency implementation of 2-D barcode tax return processing, and is provided as an advisory to agencies planning to move forward with 2-D.
In order to begin processing the returns, the state must develop a system which will allow them to read the barcoded forms.
The system is not significantly different than those developed for other data capture methods. It likely will need to include:
In addition, you will need to consider:
The following discussion assumes the government agency intends to employ a 2-D barcode on a form or is planning a course of action to be followed if the contents of a 2-D barcode cannot be read, and has followed all standards.
Two situations may occur. First, some software developers may not be able to generate a 2-D barcode on a form. Second, the form may contain a 2-D barcode, but the contents of the barcode cannot be recognized during normal processing.
For the first condition, the government agency will usually segregate forms without 2-D barcodes from the ones that contain 2-D barcodes. The forms without 2-D barcodes must contain all the data needed for processing. The segregation can be accomplished manually through an in-house document preparation process, through software if the images of the form rather than the paper are processed, or by requesting forms without a 2-D barcode to be sent to a different address. After these forms are segregated, they are sent to an operation where the required data is captured.
Second, if data in the 2-D barcode cannot be recognized, the data must be obtained from other locations on the form, much as identified in the previous step. Data can be obtained in one of three ways:
1. Prior to the start of the production season, each approved software vendor will provide the government agency with a production sample of their form that does not contain taxpayer data and that will be used as a template when the 2-D barcode cannot be read. Each software developer can generate a 1-D barcode on the form at the time the form is created and place it in a position separate from the 2-D barcode. The 1-D barcode will contain static information defined by the government agency such as the form type, tax year, and the NACTP software vendor number that created the form The government agency will use the template to dropout text on "live" returns not relevant for tax processing. After dropout has been performed, the taxpayer data will be processed using Optical Character Recognition (OCR) to recognize required taxpayer data. This is the solution recommended by the NACTP. The advantage of this alternative is that all software developers support it. The disadvantage of this alternative is the requirement for the government agency to create and maintain separate templates of each vendor's production tax form to use to perform dropout of unnecessary text before recognition.
2. The required data can be keyed from its standard location on the underlying form. The obvious disadvantage of this alternative is the additional labor needed for data entry.
3. The required data can be stored on the form using absolute positioning in addition to the 2-D barcode. When the 2-D barcode is not recognized, OCR of the data stored in absolute positions can be employed for automated data recognition. If the OCR in the previous step fails, the data can be keyed from the absolute positions where it is stored. While this alternative minimizes the government agency's effort to capture the data, it has significant disadvantages. First, sufficient space must be allocated on the form so data in both formats can be stored; real estate on the form is usually scarce and if the design is not well considered, recognition could be reduced due to the poor design. In addition, if this approach causes the number of pages in the form to increase, additional scanning capacity may be necessary. Second, this approach increases the work required by software developers since they will have to provide the same data in two different formats. Some developers may be unable or unwilling to provide the data in both formats.
Although it is possible to break larger amounts of data into several PDF417 symbols that are logically linked, this practice has not been necessary to date for most tax applications. Currently, it has not been recommended since it would likely mean that existing third-party provided forms software would have to undergo substantial changes.
However, 2-D based tax processing is growing in popularity and is now being employed for applications like corporate income tax that may involve the capture of more data than can be contained in one barcode. This capture of more data than can be contained in one barcode leads to considerations regarding how to link the multiple-barcode data stream and how to design the print output (tax return) medium.
Linking Multiple Barcodes
A single PDF417 bar code can contain approximately 1200 ASCII
characters. If the amount of data to be encoded into a PDF417 bar
code exceeds that amount, Macro PDF can be used.
Macro PDF allows over 100 MB of data to be encoded into a series of PDF417 bar code symbols. The symbols differ from ordinary PDF417 symbols in that they contain additional control information in a macro PDF control block (MPCB).
The PDF417 encoder will automatically partition the data into the PDF417 symbols. The PDF417 scanner will automatically assemble the data from the symbols, and will transmit all the data at one time. The symbols can be scanned in any order, and duplicate scans of the same symbol are discarded.
The current version of the current vendor - provided TAXAPI (tax application programming interface) supports Macro PDF, so state agencies going forward with a 2-D barcode implementation will have the ability to implement Macro PDF should they have a need to do so.
Tax Form Design
Large data volume returns will likely require the use of more
barcode space than is available on the corner of a paper tax
return. Currently, the use of a "Barcode
Data Sheet" is being examined by tax authorities and undergoing
sample design and testing by vendors, and is the subject of
discussion by the 2-D Standards Group, with an eye to adding a
language relating to its use to the mandatory 2-D standards.
However, there is not sufficient experience at this time to require any specific treatment. In fact, there is likely more than one valid approach to the capture of multiple printed barcodes.
Extensive discussion on the topic has taken place, and the following scenarios and considerations have been developed:
Note that for the 2nd scenario - a barcode per page; and the 3rd - a barcode printed per X number of pages or form/schedule - the currently approved 2-D standards can be employed, since the data volume is unlikely to be great enough that the data will not fit into one barcode.
However, the possibility of using MacroPDF and its linking capability exists in the 2nd and 3rd scenarios also, at the tax agency's option. That is a decision that could be made based on how the authority wishes to process the captured data, as well as other considerations.
A return mock-up has been created as an example only, with entity information (name and address), summary data (taxable income and tax due), an open block of space for printing of the 2-D barcodes, and a space for a signature and date.
Some variation of this example is under discussion as a recommended approach to the "barcode data sheet" treatment of high-data volume/multiple barcode return situations.
Two states in 2003, Massachusetts and New York, employed a multiple barcode capture method. Massachusetts employed one barcode per schedule, while New York used a single barcode data sheet.
Click here for:
Again, there probably is no one correct approach. If you are facing this situation in your implementation, please contact FTA or NACTP and become involved in contributing to the body of knowledge on this area.
First, be sure to become very familiar with the 2-D Standards and 2-D Guidance posted on the FTA Web site, and the NACTP Forms Design Guidelines on their site.
June 15 - Determine mailing addresses for returns.
July 1 (or as soon as possible)-Look at your candidate forms and decide the fields you want to capture. Start developing your 2-D specifications for software developers.
September 1-If this is the first time for your agency to develop 2-D barcode specifications, seek input on your specifications from the NACTP.
October 1-Final 2-D barcode specifications must be submitted to software developers. This gives them sufficient time to develop the software and for testing.
October 15-Start receiving test returns. Scan returns, check for errors, etc.
November 30-Testing for 2-D barcode should be finished.
December 1-Post an approval listing on the web site for 2-D barcode developers.
April 1 to June 30-Participate in and contribute to 2-D barcode Standards conference calls and revision process.
Read the existing 2-D standards document and become familiar with the requirements. That document can be accessed at: http://www.taxadmin.org/fta/edi/rev2-d04.html
If interested, participate in on-going standards discussions with representatives of FTA, NACTP, and Government Agencies. To have your name or that of someone in your organization added to the mail list for notification of upcoming events, please contact Jonathan Lyon of FTA at [email protected] or (202) 624-5894.
Get in touch with the 2-D contact for each Government Agency that you intend to provide 2-D barcodes for. Ask to be added to their 2-D mailing list. (NOTE: The list of Governmental Agencies that have currently implemented 2-D barcodes, as well as those considering doing so, can be found at: http://www.taxadmin.org/fta/edi/2Dsurvey.html).
You have at least 3 choices in how to implement the technology in your product.
- Get the PDF417 barcode Data Link Library (DLL) from Symbol.
- Get the code from Symbol (contact information same as above) to build into your own engine. You might need to do this if you want to support 2-D on more than just a Windows platform.
- Write your own barcode software from scratch. The written specification for PDF417 can be purchased from AIM International (www.aimusa.org) for about $65.00. As with the alternative above, you might need to do this if you want to support 2-D on more than just a Windows platform.
Read specifications for any forms you choose to support and note any areas of non-conformity with the published standards (link listed above). Any such areas should be forwarded to the assigned NACTP Government Liaison Committee member responsible for that agency, who will compile all feedback, forward to the entire committee for review, then forward to the 2-D contact. The GLC state assignments can be accessed at:
Answer Sheet An answer sheet type of tax form
includes data only and no text describing the data. Only a
taxpayer's personal data, such as name and address, is
printed on the page. Bitmap The process by which characters are
described graphically as dots and white spaces. Broadcast A method of sending one e-mail message
to a group. The message is then internally sent to an
"address book" containing multiple e-mail
addresses. Computer- A form entirely prepared by the use of
a computer printer (such as laser or dot matrix) so that the
tax form format and the variable data are printed entirely
by the computer printer. Data Capture The process of retrieving information
from either an electronic picture (see "imaging") or the
paper document. Data Entry Any graphically defined area
designated on a form for the insertion of data such as
dollar amounts, quantities, responses, and check boxes.
(Also called a "variable data field".) Developer or Vendor Code A four-digit code used to identify the
Software Developer whose application produced the barcode.
The purpose of this field is to allow forms to be traced to
the vendor producing the 2-D barcode. See Appendix 1 for a
current list of codes. Dynamic Link A uniform dynamic link library (DLL)
that has application across all agencies and forms is
available from tax agencies that are implementing 2-D
barcoding for tax forms. Document Identification Code (Doc
ID) A document identification code, or doc
ID, is a string of characters place on a document in order
to identify a form for the capture of information on that
form. Drop-out Ink Ink that cannot be read by scanning
equipment, usually blue or red in color. Entity Area The designated area on a document that
contains taxpayer information such as name, address, and
social security number. (Also called the "label
area".) Error Correction Error correction is used in producing
PDF417 barcodes to enhance error detection and correction.
This is done by means of data duplication, with the
trade-off that higher levels of error correction will result
in less data being able to be contained in the barcode. The
error correction level in the current market-provided DLL is
set to level 4, based on the low level of deterioration of
tax returns (compared to high media-abuse
environments). Format The overall physical arrangement and
general layout of a tax form. Federation of Tax Administrators
(FTA) The Federation of Tax Administrators'
(FTA) mission is to improve the quality of state tax
administration by providing services to state tax
authorities and administrators. In this capacity, FTA serves
as a moderator for the on-going 2-D barcode standards
discussions. Graphics Those parts of a printed tax form that
are not variable data. Generally, these are line numbers,
captions, shading, instructions, special indicators, special
symbols, keypunch symbols, borders, rules and strokes
created by typesetting, photographics, or
photocomposition. Header Information The header is information generic to
all barcodes that should be placed first in the barcode data
stream. As defined by the current 2-D standards document,
the first two fields in the barcode comprise the
header. Imaging The process of sending a document
through a scanner to create an electronic picture for either
storage or further processing. Item Caption The textual portion of each line on a
tax form identifying the specific data elements
required. Line The line numbers, letters or
alphanumeric used to identify each captioned line on a tax
form. Macro PDF Macro PDF is a method of linking
separate barcodes that allows over 100 MB of data to be
encoded into a series of PDF417 barcode symbols. The symbols
differ from ordinary PDF417 symbols in that they contain
additional control information in a macro PDF control block
(MPCB). Manually- A printed tax form on which the
taxpayer's variable data is entered by an individual using a
pen, pencil, typewriter, or other non-automated
equipment. NACTP The National Association of
Computerized Tax Processors (NACTP) is a nonprofit
association that represents tax processing software and
hardware developers, electronic filing processors, tax form
publishers, and tax processing service bureaus. A joint goal
of the NACTP and government taxing agencies is to provide
the best possible service to taxpayers. The NACTP is
dedicated to achieving that goal by providing expertise in
and knowledge of software systems to assist government
agencies in implementing new technologies. It is in the
capacity that the NACTP participates in the on-going 2-D
standards discussions. OCR (Optical Character
Recognition) Machine recognition of data from
printed, typed, or imaged text. The most easily recognized
fonts are monospaced fonts such as Courier and
OCR-A. One-Dimensional Barcode The one-dimensional barcode is a
pattern of lines of varying density and space that the
scanner uses to identify, index, route, and track documents.
Data is coded based on the position of these lines and the
varying thicknesses of them and the spaces between them. Password Location on a web site that requires
access with a username and password. Such a location is
password protected. (See also "secured area or secure
site".) Patch A pattern of horizontal lines of
varying density and spa ce that the scanner uses to identify
the next set of documents. PCL (Printer Control
Language) A page-description language used to
send formatting instructions to printers. PCL consists of
command codes that tell the printer where and how to print
the characters on a page, what fonts and spacing to use, and
the size and orientation of the page. PDF (Portable Document
Format) An openly published file format used
to represent a document independent of the application
software, hardware, and operating system used to create it.
PDF files provide a way to distribute documents across
diverse hardware and software platforms. PDF417 PDF417 is a two-dimensional, multi-row
barcode symbology. PDF417 is used to encode data files with
hundreds or thousands of characters in a laser scannable
symbol. Pixel Shaving 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. PostScript A page-description language used to
send formatting instructions to printers. It consists of
command codes that tell the printer where and how to print
the characters and graphics on a page, what fonts and
spacing to use, and the size and orientation of the
page. Printer Driver A program that controls how a computer
and printer interact. Registration A dark mark printed on a document or
form to provide an accurate frame of reference for locating
fields. On tax forms, registration marks most often appear
at the four corners and look like the "crop marks" used for
alignment of camera-ready documents. Scanband The consolidated area on a document
that contains tax return information to be
processed. Scanline A line of characters in a specific
location that is scanned, such as an estimated tax voucher's
check digit line on the bottom of the coupon. This line is
generally produced in Courier or OCR-A font. Scanning The mechanical process that either
produces an electronic picture or reads the paper document
for data. (See also "data capture".) Secured Area Location on a web site that requires
access with a username and password. Such a location is
password protected. (See also "password
protected".) Substitute Tax A tax form that differs in any way
from the official government version. Supporting A document providing detailed
information to support an entry for a line(s) on an official
or substitute tax form filed with a tax return. This
document is produced and maintained by tax software, not a
taxing agency. Template A pre-defined pattern contained in a
file that is used as a guide in scanning tax forms
accurately. Trailer The trailer is the last field in the
barcode data stream. The trailer is used to indicate the end
of data has been reached. As defined by the current 2-D
standards document, a static string of "*EOD*" is used as
the trailer value. Two-Dimensional The two-dimensional barcode is a
matrix code. Data is coded based on the position of black
dots within a matrix. Each black element is the same
dimension, and the position of the element is what
determines the data that is coded. A two-dimensional barcode
stores data vertically as well as horizontally. Variable Data The information that is entered on a
tax form in the data entry fields.
e-mail
Generated
Substitute Form
Field
Library (DLL)
Level
References
Prepared
Form
One-dimensional barcodes are composed of static or
pre-defined, non user-specific data. Therefore, they can be
written directly into a program or "hardcoded" as part of
the graphics of the software program, possibly in multiple
places, where they cannot be easily modified.
Protected
Mark
(Reference Mark
or Target Mark)
or Secure Site
Form
Statement
(2-D) Barcode
FTA
Jonathan Lyon
Federation of Tax Administrators
[email protected]
www.taxadmin.org
NACTP
Zeke Gikas
National Association of Computerized Tax Processors
Creative Solutions
[email protected]
www.nactp.org
Other Helpful Contacts
Sue Gastons
President, NACTP
H&R Block
Linda Dollens
Indiana Dept. of Revenue
E-mail: [email protected]