DRAFT - NOTES

December 3, 2001 - ANSI ASC X12 Technical Assessment Committee Meeting -- Consideration of Tax Jurisdiction Sourcing Transaction Set 158

During their regularly scheduled X12 work review session, the ANSI ASC X12 Technical Assessment Subcommittee (TAS) considered the FTA and MTC-proposed Tax Jurisdiction Sourcing transaction set (TS), designated TS 158 by ANSI.

Terry Garber of South Carolina DOR and Jonathan Lyon of FTA represented the Wireless Task Group (WTG), and two other members of TIGERS from the Oklahoma Tax Commission were in attendance. Ms. Garber also serves as Chair of X12 Task Group 2/TIGERS, the ANSI subgroup responsible for shepherding the Tax Jurisdiction Sourcing transaction set (TS) through the X12 approval process, and presented the transaction set on its behalf.

She described the business background of the effort to provide a simple and uniform method of determining the tax jurisdiction(s) applicable to the situs of a wireless call for billing purposes (and thus for imposition of tax). She explained that the federal law called for the approval by X12 of a database format, and that X12, as a technical matter, did not "approve" database formats. X12 approves "business data interchange" formats.

Thus, a TS was fashioned to enable an inquiry/response - that is, a wireless provider might send a single address or address range (or a batch of same) to a state agency, and the agency could then respond with information relating to the tax jurisdiction(s) that the address (or range) was encompassed by. The agency might also then develop a database format with the same elements that are in the TS for query purposes, and make this available over the Web or in another manner.

Ms. Garber explained that the TS had segments in the beginning to contain Sender and Receiver, followed by a "loop" (repeating information) holding the inquired-upon time period, along with repeating elements containing the address(es) inquired about by the Sender. With an accompanying trailer segment, this would complete an Inquiry transaction.

A Response would repeat these elements, and have in addition a PPA (Property Location) segment to provide the FIPS-55 Named Populated Places standard codes applicable to the address (with additional optional elements for Latitude and Longitude if desired), as well as a TA (Tax Authority) segment to identify all special taxing districts applicable to the address (or address range).

TAS requested that it be made explicit through a transaction set note that the PPA and TA segments are only to be used in the response transaction, and not in the inquiry. A TS note is technically part of the TS and enforceable by standards.

Ms. Garber explained that an X12 Implementation Convention (explanation of use) would be needed for the proposed Tax Jurisdiction Sourcing TS, since there may be some intracies in "matching up" an inquiry and the resulting response in practice.

A second recommendation suggested a correction to the examples, where one data element was omitted accidentally from the date/time segment. (While this seems trivial, the examples are considered critical to the voters' understanding of the proposed standard, and an error in the examples can be cause for disapproval.)

The TAS inquired as to the possibility of placing the information in the proposed Tax Jurisdiction Sourcing TS into the same functional group (envelope) as other already-existing tax-related X12 transactions sets, for example TS 826 (Tax Information Exchange). Ms. Garber explained a different functional group envelope would be needed, since the sending parties and information contents were very different between the two transaction sets: the 826 carries confidential information relating to a tax return, between authorized parties, while the 158 carries public information between any vendor or interested party and the holder of the database.

The TAS asked, what happens when there is no information available regarding a particular named address? What response is made? This was admitted to be an issue; possibly a "no information found" code could be supplied in the response; a solution will be researched and included in the voting submission in February 2002.

The structures for Street Number Odd/Even Indicator were discussed, and TAS members said that the X12 Name data segment used was not being employed for its intended purpose, and another solution would have to be found (although admitting that the proposed approach, while not meeting X12 design rules, "would be simpler and cleaner to implement").

The code for Odd/Even indicator will be replaced with codes that actually refer to address components, such as "Low Even Address Range" "High Even Address Range" "Low Odd Address Range", etc. Eight codes in all will be needed. This will cause an extra step when the TS is used because the codes will have to be converted to the Odd/Even indicator to match against a database.

The solution devised involving the use of additional code designators was acceptable to the Technical Assessment Subcommittee and will be proposed and included in the voting submission in February 2002.

The TAS had no further comments or questions. The TS will be moved forward through the X12 approval process during the February 4-7 Trimester meeting at the Sheraton Seattle in Seattle, Washington. It is expected that TS 158 will be circulated for approval by the X12 membership during a 45-day ballot period following the February meeting.