2009 2-D Standards Revision Call March 26, 2009

Jonathan commenced the call and took roll. The following participants were present during the teleconference:

States

Oregon

Virginia

Louisiana

Idaho

Kentucky

New York

Indiana

Michigan

New Hampshire

South Carolina

Arizona

New Jersey

Tennessee

Industry

CSI

TaxSlayer

H&R Block

STF Services

Drake

Petz Enterprises

CCH/ATX

FTA

Jonathan Lyon

Donna Muccilli

The floor was opened for suggestions on standards revisions.

1. NACTP suggested strengthening the language contained in Section 5.a.1. First, to use the word “should “ rather than “may” relative to agencies basing their test cases off the PATS testing scenarios, and enforcing the use of prior year scenarios if current ones are not yet available. Discussion ensued – some EF scenarios are not on the forms, some states have stopped using PATS and are using alternative methods, etc.

Second, certain companies, as forms library providers, need transcription of PATS testing scenarios onto the agency’s forms, and this needs to be taken into account. STF agreed to work with Oregon on the specific issues they have, and more broadly, Zeke representing NACTP agreed to come up with specific text revisions for Section 5.a.1 and submit them before the next call so that they can be considered.

2. A continuing issue has been an inconsistency between field lengths and formats between efile and 2D/Form modes. Some of this may be due to state implementation of business taxes that may have different requirements,, as well as possible lack of communication between the EF and 2D responsible parties and resulting divergence.

David from TaxSlayer indicated that he could supply some state examples prior to the next meeting to better illustrate the issue and help direct the discussion, and NACTP will propose some language to address this.

3. A change was proposed to Section 6.1 relating to adding a “change” column to their 2D specification indicating that there has been a modification to a particular field. A text revision was submitted by Kenny from Petz for our consideration.

4. Nelson from H&R Block brought up the issue of multiple state forms capturing essentially the same data, and Oregon’s adopted practice of placing the same data in the same location across forms. (Ed. – I hope I captured this correctly.) The suggestion is to encourage the incorporation of that into additional states’ practices. It is unclear whether, if determined to be desirable, this would be part of the standards, or a Best Practice, listed in the accompanying 2D Guidance document. Susie from Oregon offered to supply more information.

2009 2-D Standards Revision Proposals

ITEM 1

EF PATS and 2D Submissions – industry would like to encourage states to use the same test cases for 2D and e-file approval.

Background

One issue may be that PATS test cases for e-file may ask for information that is not on the form and therefore would not be in the 2D. Another issue is the timing of test cases, e.g. AL released 2D test cases six weeks ahead of PATS – in cases like this we suggest having 2D use prior year PATS.

We want to ensure test case data is presented on forms for library products.

We also encourage states to have forms/2D staff talk to e-file staff to make sure field lengths, format, etc are consistent between forms/2D and e-file.

To summarize:

Strengthen the standards with language encouraging states to use the same test cases for 2D and efile.

Proposed language for basing 2D test cases on PATS scenarios – changes from the language in Section 5.a.1 appear in blue:

Agencies should base their test cases off the PATS testing scenarios. If the current year's PATS test cases haven't been released, agencies can use the prior year's test cases, if applicable. Additionally, for the benefit of software libraries, agencies should transcribe PATS testing scenarios onto the agency’s forms.

ITEM 2

Inconsistency between field lengths and formats for efile and 2D/Form; the issue is the difference in field lengths in regard to 2-d versus ELF.

Background

Here are a few examples illustrating #2:

AL:

1. Form 40 - Primary last name - ELF length is 32 but the 2-d length is 30

2. Form 40 - Primary first name - ELF length is 16 but the 2-d length is 15.

3. Form 40 - Primary middle initial - ELF length is 1 but the 2-d length is 15.

4. Same with spouse

VA:

1. Form 760CG - Primary first name - ELF length is 16 but the 2-d length is 12

2. Form 760CG - Primary last name - ELF length is 20 but the 2-d length is 15.

3. Same with spouse

4. Form 760CG - Address line 1 and line 2 - ELF length is 35 but the 2-d length is 34.

5. Form 760CG - Paid preparer name - ELF length is 31 but the 2-d length is 36

MO:

1. MO 1040 - Primary first name - ELF length is 16 but the 2-d length is 14.

2. MO 1040 - Primary last name - ELF length is 32 but the 2-d length is 20.

3. Same with spouse

4. MO 1040 - City, Town or PO Box - ELF length is 22 but the 2-d length is 23.

Proposed language for field consistency between paper filings, electronic filing and 2D barcodes:

Currently, at the bottom of section 4.a, the standards state:

(Note: Depending on how the fields are generated by the different software companies, fields for Paper Filings, 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.)

Because this language implies consistency between the three in a somewhat roundabout way, we propose more direct language to replace the language above. Here is the proposal:

Note: Field widths and types must be consistent between Paper Filings, Electronic Filing and 2D barcodes. Example: If a taxpayer name field is limited to 35 characters on the printed form, then the related ELF field and 2D barcode field should be also set to a maximum of 35 characters.

=============

ITEM 3

Here are proposed revisions for Section 6 related to a Change column being included in the 2D barcode specifications.

Current Text:

6. Barcode Specifications and Version Control Process

1. Any document an agency issues to developers should be numbered in sequence, dated, and should include revision marks to indicate changes.

Modified Text:

1. Any document an agency issues to developers should be numbered in sequence, dated, and should include revision marks to indicate changes. It is highly recommended that the agency include a “Change” column in their 2D barcode specification indicating that there has been a modification to a particular field. This column will have “New” for a new field, “chg” for a changed field, and “Del” for a field that has been deleted or removed.

===============

ITEM 4

Below is a summary of how Oregon created our 2-D barcode specification for Form 40N and 40P when we implemented these form types for TY08.

As Nelson mentioned from H & R Block during 2-D Conference call, when Oregon implemented Form 40N and 40P for TY08 we tried to mirror our existing return header formats from other form types so all the return header indexes stayed the same between all form types to minimize the impact.

Nelson from H & R Block suggested during our 2-D Conference call that we should look at adding some language to 2-D Standards that encourage states to add static fields that never change year to year, e.g. that header data, name and address info, preparer data, W-2 data, schedules etc. be added to the first part of the specifications; and yearly changeable fields, e.g. dollar amount fields, state return and federal return data should be added after the static data. This way the static indexes would stay the same year to year and only the indexes that are impacted by form changes year to year would have to change.

For TY09 Oregon is looking at moving other static information in our specs below our Return Header information since the indexes do not change every year to year, e.g. Practitioner information, Amended Schedule, Form 10 etc.