Terry Garber (SC) introduced Bert Ortiz (IRS) and Tom Guinan (IBM/IRS) to present on the IRS candidate release for the 94x/1120 E-file Transport Packaging & Schema Design. To the extent possible, TIGERS would like to follow the IRS taxonomy and structure, and then maintain the taxonomies for the state withholding (WH) and unemployment insurance (UI) in parallel.
Where possible, the IRS adopted industry standards in developing the 94x/1120 structure. The schemas use SOAP 1.1 with attachment protocol. Further information on SOAP is located at the W3C web site located at www.w3.org/tr/soap. The IRS is planning to use the schemas and transport protocol for private connections. Additional changes will be needed once it moves to accepting transactions over the Internet. EBXML is one standard the IRS is considering, however the technology is not ready to adopt as a standard yet. The next release of SOAP, version 1.2, will also have enhancements that will be helpful.
Transmitters will use the same transmitter connections as are used today for the 94x/1120 schemas. The 94x schema is scheduled for testing in January 2003 and the 1120 schema is scheduled to be tested in January 2004. Eventually the 94x schema and all other XML schemas will be transitioned to the schema version developed for the 1120, hereafter referred to as v2 in these minutes.
One of the main differences in v2 from the first 94x candidate release is that certain data is moved from the SOAP envelope to the return data section of the transmission message. This data includes some return header information that, in v1, was originally located in the SOAP body along with the manifest. Version 1 required the transmitter software to hold this header information in memory while all the returns were constructed, and then to create the SOAP body later. In an extra step, the gateway, or receiving software system, would have to find the header information and link it to the return after parsing the returns. Another difference between v1 and v2 is that the structure of the acknowledgement looks more like the transmission.
The new structure of v2 will support sending multiple types of returns in the same transmission, However, for now, each type of return will be sent separately. The IRS is working on adding a tracking number similar to the document control number (DCN) used for the 1040s. This issue has not yet been resolved, but the IRS will likely give instructions to vendors to create and assign the tracking number at origination. At this time, payments will only be made with returns. At some point in the future, a project may develop for payments or deposits alone.
The IRS will use the existing transmitter connections to receive returns, and transmitters will receive an identification number for each transmission, in real time, when the transmission is received. Acknowledgments will be generated on a first-in-first-out basis with acknowledgments posting as soon as they are finished processing. The IRS has removed several bottle necks in the process. The acknowledgements are received by transmitters the next time they connect to the IRS systems. Basically, the 94x business rules will remain the same for the initial testing, with the main difference in the process being a change in data format to XML.
In v2, there will be a transmission acknowledgement for each transmission, and a status acknowledgement for each return. There will be an indicator for whether a payment was sent with the return. The return and payment will be accepted or rejected as a whole. If either the payment or return fails, both will be rejected and both will have to be re-filed.
The concept of an "electronic post mark" is not found in the 94x or 1120 schemas. There is a filing date, and timely returns will be defined in a different way than they have been in the past. The business rules for timely returns will be published with the production schema.
The error acknowledgement structure includes both an error code and text descriptions for each error found. This structure applies to errors in accepted, as well as rejected returns. The error message will include the reason a return was rejected, identifying: which document, document occurrence, element name, element occurrence, error code, and error message. The codes and messages are currently being defined.
The group defined and discussed the different roles involved in preparing a tax return, in order to better understand the structure of the 94x/1120 schemas. The Taxpayer provides the raw data; the Preparer organizes the data, calculates the return, and has liability, along with the Taxpayer, for the data in the return; the Originator formats the data in the return into an acceptable format to be received by the IRS and is identified by an (EFIN). Unlike Preparers, Originators do not have liability for the content of the return. The Transmitter connects to the IRS and transmits returns and is identified by an (ETIN). The same PIN provided in the Letter of Application (LOA) registration can be used with any transmitter.
The v2 schema structure makes it easier for Transmitters transmitting for several Originators because the EFIN, and all other information specific in a "return," is packaged together.
COTS SPEF Consortium Meeting
Wednesday, April 24, 2002, 5:00 - 7:00 PM
Beatrice Howell, the new COTS SPEF project manager from the IRS' Electronic Tax Administration (ETA), welcomed the consortium members and discussed the transition of the project to ETA. Beatrice's first task upon taking over the project was to assess whether or not there was true support for the project from the states and vendors. Beatrice contacted all of the vendors and state partners and found that most partners saw value in the project and thought that it should be seen through to completion. Beatrice reported this back to her management, who authorized the continuation of work on the project to complete a pilot test. However, Beatrice did point out that the COTS SPEF project is currently being managed by ETA, which is not an operating division. This may affect the project in the future as it may be completed within ETA, or it may be transitioned to an IRS operating division.
Georgia Marsh of Illinois (IL) provided the group with an update on its pilot test with Intuit, which is planned to begin in July. Ms. Marsh expressed disappointment that none of the vendors could meet Illinois' PKI specifications in the first release of their product. IL has reached an agreement with Intuit to provide a solution that uses PKI for communications between Intuit and IL, but for communications between the taxpayers and Intuit, a PIN and password will be used. IL believes there are a many benefits to a certificate-based system with digital signatures and hopes vendors will use PKI for taxpayers in future product releases. IL has also had discussions with Fileyourtaxes.com to provide a pilot solution for IL.
Ms. Marsh also expressed some frustration with the slow progress, and lack of IRS support, on the project. IL feels it was invited to partner with the IRS to participate in a project that would benefit business owners, the states, and the IRS, yet the IRS is not doing its part. IL received a response back to a letter sent by Governor Ryan to Commissioner Rossotti regarding the COTS SPEF project. The response indicated that the project lacked vendor support, and thus the IRS did not intend to pursue the project. Ms. Marsh countered the conclusion of the letter by pointing out that the COTS SPEF vendors have stepped up and are participating in pilot tests, and for this, they should be credited. Ms. Marsh reminded the group that the 13 states involved in the COTS SPEF project represent roughly 80% of the small business owners &endash; the target audience for this solution &endash; and that we need everyone to pull together to meet the needs of these business owners.
Intuit shared with the group that this is an important project for the company, and that its market research showed a far greater interest in a combined federal/state offering, than in a federal solution alone. This being the case, a combined solution is expected to result in increased electronic filing for both the IRS and the states.
Faye Shea, of Intuit updated the group on it's pilot test with IL. Intuit is proceeding with a combined federal/state offering, even though the IRS is not ready to accept the XML-based filing. For now, Intuit will collect the information and use the existing 941/940 solution; they will adopt the XML solution once it becomes available. It's current solution will require several connections, which hopefully can be reduced in the future. Currently, a complete solution requires connections with both IRS EFTPS providers, the IRS for the 941/940, the IL gateway, a separate bank for UI payments, and SSA for W-2 information. Intuit plans to be code complete for testing with IL, and other interested states, in July, and Intuit intends to release a solution by the end of the year.
Mary Thomas (IL) shared IL's progress in the development of its gateway and pilot test. IL will be using the 'SOAP with attachments' protocol. The IL development team has assigned its own set of XML tag names, but will adopt the TIGERS/COTS SPEF tag names and schemas once the information is available. IL is using IBM products for its gateway. It's pilot test will include the IL-941, with or without an embedded debit authorization using the IL-501 for estimated payments, the IL-340 (UI), and the W3. The UI payments will be sent from Intuit directly to the bank specified by IL. IL adopted the re-occurring liability/deposit schedule that Jim Rowland created based on the IRS Schedule B. It will provide a transmission acknowledgement similar to the IRS transmission receipt; and, after the file parses and is processed through the legacy system, a second acknowledgement will be sent.
The consortium agreed that there have been a lot of delays, and frustrations, and that the group floundered with new technologies early. However, the group also acknowledged the positive decisions and momentum occurring with the project. The group cited several key decisions, or breakthroughs, as successes, including: agreement on the use of XML technology, the adoption of the 'SOAP with attachments' protocol used by the IRS, and the decision to leverage the IRS' structure for development of the schemas. At this point, the consortium has draft schemas and a comprehensive data elements list; vendors have committed to providing COTS SPEF solutions; and the states are willing to build gateways-all of these commitments point to moving forward and finishing the solution.
Inclusion of Annual Reconciliation and State W-2/W-3 Schemas
It became apparent to the states and vendors, that in order to provide a complete solution for business owners, an annual reconciliation schema should be developed as well. The group also felt that an annual reconciliation schema could be adapted from the quarterly schemas without much trouble. Some states have already provided their annual reconciliation data elements, but some have not. The states agreed to provide their annual reconciliation data elements to VRI prior to the next TIGERS meeting in June.
The vendors and some states also expressed an interest in including the state and federal W-2s. The group agreed that including state W-2s/W-3s could be considered. This issue was discussed in more detail during Friday's meeting. However, it was decided that the federal W-2s are out of scope at this point in time. Terry Garber provided some background on the federal single point filing (SPF) of W-2s project. Several states participated in the pilot and wanted it to be implemented. However, the project never got beyond the pilot phase. The IRS never implemented the solution, and it has been waiting for over five years for funding. The consortium agreed that hopefully we can eventually develop a complete package that will include the federal W-2s. Additionally, on Tuesday during the FTA meeting, Margie Kinney, of the IRS' Small Business and Self Employed (SB/SE) Division, indicated that the SPF of W-2s project had been transferred to SBSE division, and that the next step for the project was to submit a decision paper to the Office of Management and Budget (OMB) that outlines implementation requirements, costs, barriers, and benefits to taxpayers and agencies. Beatrice agreed to check into the status for the SPF of W-2s and report back to the group.
IRS EFTPS payments, short and long term solutions
Beatrice Howell provided a handout created by Dan Swenson, of the IRS EFTPS Group, entitled, "Proposal for the Use of an EFTPS API to Support COTS SPEF Federal Tax Payments," which outlines short- and long-term plans for working with EFTPS for COTS SPEF solutions. For the short-term, vendors testing the COTS SPEF solution will need to establish connections to both EFTPS Financial Agents (FAs), Bank of America and Bank One. Vendors may use the FAs PC file format specifications to send payments. Vendors ready to develop a pilot solution should work through Beatrice Howell to obtain the PC file format specifications.
The IRS' long-term plan is to develop an API using input from the vendors. Beatrice Howell agreed to invite Dan Swenson, or another IRS representative to the June TIGERS meeting, to discuss plans for the API solution. For more information, please see the handout provided during the discussion, which has also been posted on the COTS SPEF POF under Payments. Additionally, the IRS is writing a white paper to address both the short- and long-term plans for working with EFTPS.
Faye Shea shared some of the issues and solutions identified in conference calls with the IRS payments group. Several business owners have already registered with EFTPS, but often they do not know which FA they have registered with. The FA is not easily identified based on state, ZIP code, or any other location information. The best short-term solution that could be identified to address this issue was to have users enter their EFTPS phone number. Vendors would be able to identify, from the phone number, which FA the user is registered with. Another struggle Intuit encountered is that currently, the PC file format is only available for dial-up connections. On the conference calls, the FAs and IRS agreed to consider looking into establishing a broadband connection.
Jo Ann Costa addressed the outstanding payments issue of what to do about short falls in payments, which was an issue originally raised during the November consortium meeting. The group agreed that the state payments schema will include an amount for UI and an amount for withholding. All payments will be accepted, even if full payment is not made. States will use state-defined business rules for allocating any payment short falls.
Review Master Data Element List for State UI and Withholding Filings
Thursday April 25, 2002, 8:30 am- 12:30 pm
Terry Garber introduced the topic of how TIGERS can build and maintain standard taxonomies for state employment filings. She reminded the group that TIGERS is a volunteer organization and that it will take the support of its members to continue to maintain the COTS SPEF schemas and materials. With the COTS SPEF POF eventually going away, Terry reminded the group that Greg Carson, of the IRS, had volunteered to identify a location to house the schemas. Terry then turned the session over to Jim Rowland to review the master data elements list and proposed XML tag names.
Jim Rowland led the group through a presentation entitled, "State Schema Issues and Considerations," which highlighted some of the considerations and issues identified in assigning XML tag names and developing the state schemas. Jim highlighted some of the benefits of mirroring the IRS schemas structure including: the flexibility for structuring a return, the use of industry standards, and the ability to create new building blocks which do not have to be sent in the same order. Another important benefit to using the IRS standards is that it will provide vendors a single technical solution, which addresses both the IRS and state filings. Jim tried to change as little as possible from the IRS structure when creating the state schemas. One of the issues that comes to bear, however, is the reuse of elements. Because each state may have different requirements for each element, the reuse of elements reduces the capability to validate data in the schema. Vendors must perform validation in the software, and states will need to perform validation in their backend systems, which is currently done today.
The group also discussed Derivation Extension and Restriction. Derivation by Extension allows the addition of attributes and elements for complex types. Derivation by Restriction redefines simple or complex types. Alternatives to derivation are the use of includes or substitution. The state schemas will use derivation with extension when needed.
Decisions identified while reviewing the master data elements list are summarized below:
1. Change the "StateEIN" to StateCentralRegistrationNumber in the return header and include two business account numbers, the UIAccountNumber and the WithholdingAccountNumber, at the return level.
2. A numeric field of type string, restricted to digits, will be used for dates in the format YYYY-MM-DD (example: <TaxPeriodEndDate>1967-08-13</TaxPeriodEndDate>), and for postal codes, phone numbers, the FEIN, and other areas restricted to digits.
3. The number of characters for data elements will be expanded to a reasonable maximum upper limit length. Truncating can cause trouble with mailing addresses, as the Post Office has restrictions for field lengths. If users are offered a shorter space, they might abbreviate. Vendors will limit input fields to a reasonable length.
4. There are multiple types of business names collected by different states. For example, some states use Legal Business name; others ask for Doing Business As (DBA). The group agreed to handle these kinds of data elements by defining one BusinessNameType, and then creating descriptive data elements such as LegalBusinessName and DoingBusinessAs that use the BusinessNameType.
5. The group defined the BusinessAddressType as described below:
BusinessName1 Alpha(A) 50 Characters
BusinessName2 A 50
AddressLine1 A 40
AddressLine2 A 40
City A 25
State A 2
PostalCode N 5
PostalCodeExtension N 5
6. The group defined IndividualNameType as described below:
Prefix A 10
Title A 20
FirstName A 15
MiddleName A 15
LastName A 25
Suffix A 25
FullName A 50
7. For several categories of elements, a generic "type" will be defined, and then elements with context descriptive names will be defined as being of "type_____." Some types are defined as a collection of components. Here are some examples of these groupings:
1) BusinessNameType
BusinessName1
BusinessName2
LegalBusinessName
DoingBusinessAs
2) BusinessAddressType
BusinessAddress
DeliveryAddress
LocationAddress
LegalAddress
3) IndividualNameType
ContactName
EmployerName
EmployeeName
PreparerName
4) QuarterType = 1,2,3,4 (1 character)
5) QuarterPeriodType
PeriodStartDate
PeriodEndDate
6) WagesType
GrossWages
UIWages
AdjustedGrossWages
7) RateType
UIContributionRate
WithholdingContributionRate
DisabilityContributionRate
8) TaxType
UITax
WithholdingTax
9) AccountNumberType
BankAccountNumber
StateRegistrationNumber
UIAccountNumber
WithholdingAccountNumber
EfileAccountNumber
10) DateType
FilingDate
RemittanceDate
11) AmountType
AmountDue
AmountSubjectToWithholding
WithholdingAmount
ContributionAmount
UIAmount
TotalAmount
12) PenaltyType
13) InterestType
8. Other miscellaneous data elements/attribute decisions identified include:
14) FormType = 10 characters
15) EmailType = 100 characters
16) CheckBoxType = Boolean
17) PINType = 25 characters
18) Added EmployerPlantNumber (PA)
19) Added DUNSNumber (CA)
20) Added StateControlNumber (MD)
Review of the State Employment Schema Structures
Thursday, April 25, 2002, 1:15 - 5:00 PM
Several schema structure decisions were addressed in conjunction with the review of data elements. A summary of these decisions, as they relate to the state employment schema structure, is listed below
1) Adopt the IRS data element types and XML tag names where possible.
2) The state employment schemas will be based on v2 of the IRS schemas.
3) Use the existing defined "Types" where possible for the combined schema by adding descriptive "combined" data elements.
4) The Liability Schedule will include a data element called LiabilityAmount, with an integer attribute for each day of the month similar to the IRS Schedule B, for all three months in the quarter. A DepositAmount data element will also be included for each day of the quarter.
5) For the payroll requirement, the schema will use a data element for PayrollEmployee = IndividualType in a payroll loop.
6) An item count loop will be added to the transmission acknowledgment to count the number of returns, payments, or returns with payments in a transmission.
7) DateOfFinalWagesPaid (last payroll) data element will be left as a separate data element. There was some discussion of whether this could be an attribute to Final Returns, but the group decided to leave it as separate data element.
Jim Rowland explained that we will include the IRS 94x types (efileTypes.xsd) as a base. Another file (efileStateTypes.xsd) will be added for state use.
The group tried to stay away from assigning attributes to the data elements, as the experience of some of those in the group indicated this was not a wise practice, except for special circumstances like the liability schedule.
The group held a lengthy discussion on how to define and create a unique id number to assign to each return. The group discussed several alternatives for how to define the id number type. The group also discussed the possibility of combining several data elements in the return to create a unique id number. Data elements considered for combination into the unique id number included: the TaxID, TransmitterID, OriginatorID, ReturnID, and DateTimeStamp. An action item was created to research and propose how to generate and deliver a unique tracking number, similar to the IRS' document control number (DCN), for each return. Possible solutions will be discussed at the June TIGERS meeting.
At the conclusion of the data elements session, Terry Garber proposed that VRI take the feedback provided on how to define different types of data elements and apply the same types of solutions and patterns to the remaining data elements. The revised list will then be distributed to the TIGERS and consortium groups, prior to the June meeting.
State Payments Schema
The state payments schema is based on the IRS payments schema. The schema will allow for both payments with a return, or payments on their own.
A return header for payments sent without the return will need to be created. This should not be very difficult. The group started to discuss how to deal with credit memos and prior overpayments. Can or should these items be included in the payment schema? An action item was created to propose how to address credits and overpayments in the schema structure. The proposed solution will be addressed at the June meeting.
States will likely keep all other existing payment alternatives open. The COTS SPEF solution will be another method of filing for business owners. The group discussed the needs for bulk payment processors. Some vendors or states will likely need bulk filing. The header for bulk payments will need to include a payment roster and payment manifest. GovOne agreed to work with VRI to add the needed elements for bulk payments.
COTS SPEF Consortium Meeting
Thursday, April 25, 2002 5:00 - 6:40 PM
State Payments Overview
Bruce Krumlauf and Ron Thompson, of govOne Solutions, provided a presentation entitled "COTS SPEF Payments," which provided an overview for how payments and state EFT programs will work within the COTS SPEF model. The state payments schema is based on the IRS payments schema, and that schema will allow for both payments with a return, or payments on their own. They also outlined the plans for state payments.
GovOne provided a list of payment data elements, which included what the states have published as their standard for payments. Several states also provided data elements for payments. The consortium identified the need to add four additional data elements: the state employer account number, the bank account number, the tax code defined as a TaxCodeType, and the PaymentMethodType to describe the type of payment with one character: D = Debit Authorization Enclosed, C = ACH Credit, E = Debit Authorization EFT. The govOne list, and additional data elements, will be used to revise the payments schema.
The group discussed the need for pre-enrollment or registration for payments. IL is planning to accept payments without pre-enrollment. Including all the data elements for a payment without pre-enrollment could provide some challenges. It is common for businesses planning to make payments to pre-enroll in payment programs. Several states plan to continue that practice. The vendors can collect the required information for payments without registration, save it in the customers' profile and submit it to the state. This is ok if the payment is being sent to the state gateway, if the gateway could strip the additional data elements before it is sent to the EFT provider. The payments sent to banks should not include any additional data elements than currently required. We need to also consider how processing time at a gateway would effect time sensitive payment transactions. Please review the govOne COTS SPEF Payments presentation for additional information on state payments. The presentation is located on the COTS SPEF POF under the Payments section.
States and Vendor Reports on Plans for Implementing COTS SPEF Solutions
California (CA) has developed the planning documents, and has received the authorization to purchase the hardware and software needed to build its gateway. There is some support from management for the project and a proposal to move forward with the project has been submitted. They are waiting to hear for approval. They are optimistic, but need to hear back on a timeframe for implementing the project. The California representatives have participated in calls with both Intuit and Fileyourtaxes.com about possible pilot tests.
Connecticut (CT) is ready to move forward with the pilot test. The CT Department of Labor (DOL) has brought up a state gateway, the hardware and network is in place, and they are in the process of testing UI filings. The CT DOL has agreed to accommodate the withholding returns at their gateway, as well as UI filings. They have a project plan, and are covered under the DOL gateway budget. CT has hired a vendor to work on acknowledgements. There is a separate project for payments. ITCI, a semi-public UI Technology Vendor, is assisting them with the project. They need additional information on how to configure the gateway for COTS SPEF filings. CT has spoken with Intuit and is ready to set up a timeline to test with any other vendors.
South Carolina (SC) considers the project high on its priority list, but is facing tight funding constraints. SC is offering an amnesty program right now, which is keeping staff busy. It plans to size the project and look at the lowest cost solution for implementation of the COTS SPEF standards.
Maryland (MD) has been undecided up until this point based on the slow movement of the project . However, Stephen Bouchard will share the recent progress made on the schemas and gateway definition with the other MD representatives to assess when the project might be implemented. It will not likely make the priority list this year, but Stephen could see vendor commitment and real progress with the technical design of the schemas and gateway. MD would like to see the W-2s included in the project.
Pennsylvania (PA) has trained some of its IT staff on use of XML technology, and the COTS SPEF filings will likely be its first XML project. PA will take the information from the meeting, share it with its state management, and report back on when they might implement the COTS SPEF solution.
Intuit plans to test with IL, CT, and any other states that are ready. They will be code complete for their offering in July, and will format the data according to the COTS SPEF requirements, to test with states that are ready.
Fileyourtaxes.com is developing a COTS SPEF-based solution, but does not have a time line to share the with the consortium yet.
GovOne is committed to aggressively developing a COTS SPEF solution. Although govOne does not have a date for a release yet, it is willing to work with states who are ready.
State Gateway Specifications Discussion
Friday, April 26, 2002
Terry Garber led the group in a discussion on the state gateway specifications. The group used version 1.4 of the COTS SPEF Gateway Document as an outline for the discussion. The document was last updated prior to the July 2001 consortium meeting, and before the consortium adopted the IRS schema structure as a basis for developing the state employment schemas. The group reviewed the document, deleted obsolete information, and update the gateway specifications based on the new employment schema structure.
A number of decisions were made and are identified below:
1. The consortium re-defined the mandatory functions of the gateway to include the following functions:
1) Receive transmissions
2) Handle SOAP protocols
3) Authenticate the transmitter
4) Send transmission receipts
5) Send transmission acknowledgements
6) Post acknowledgements to be retrieved by the transmitter
2. Optional suggested gateway functions included:
1) Receipt of acknowledgements from legacy systems
2) Provide additional information on the status of each return
3) Provide a time estimate for when the transmission acknowledgement will be available
4) Allow users to query batches by transmission ID
5) Parsing of XML documents function may reside on the gateway, but can be performed at another location.
6) Password management
Authentication: Most states intend to pre-register Transmitters, and authenticate Transmitters through a PIN or Password, or through PKI. The group discussed whether the state gateway would require state vendor registration for a connection solution or be able to receive filings from anyone. Some states had strong opinions for pre-registration, mostly for security concerns. Other states may not implement registration for connections to the gateway. States who require pre-registration of Transmitters will either use PIN and Password or PKI for connection validation.
Filing: Vendors will upload the SOAP-based XML file using HTTPS. They may or may not use a browser. The transmission receipt will be received in the same connection. The vendors indicated that they would like to standardize on one transmission protocol for sending filings to the gateway. The group agreed on use of HTTPS as its transmission protocol. A concern was raised that unless a browser like Internet Explorer or Netscape is used, an HTTPS server certificate license may be required from Netscape, which costs about $75,000. The group agreed that more research needed to be done on this issue. It will be discussed again at the June TIGERS meeting.
Additionally, the vendors will be permitted to send multiple transmission (filings) without having to first pick up acknowledgements waiting for them from a previous transmission.
Data Validation: The first step of data validation is to parse the XML document to see if it is "well formed." The parsing may occur at the gateway, but can be performed at another location of the state's information systems, if desired. The gateway is only responsible for posting the results of the validation in the form of a transmission acknowledgment.
Other than accepting or rejecting the return, other data validation is left to the capabilities and business rules of the state.
Data Staging: Data staging is defined as preparing, or re-formatting, the return for processing by legacy systems. This is a function that could be done at the gateway, but is not required to be performed by the gateway. The group agreed that this issue is out of the scope of the COTS SPEF project.
Acknowledgements: The acknowledgement assumes pre-registration of Transmitters with PIN/Password or PKI connection to the gateway. CA indicated they may not require pre-registration of transmitters. A check of a transmitter ID will rely on the business rules of the state.
The first acknowledgment will be called a Transmission Receipt. This acknowledgement will be provided in real time in the same session as when the transmission is received by the state gateway. The Transmission Receipt will include the following information:
Transmission Receipt:
1) TransmitterIDNumber
2) TransmissionIDNumber
3) TransmissionTimeStamp
4) FileSize
The second acknowledgement is defined as the Transmission Acknowledgement and includes an acknowledgement for each return within the transmission. For rejected returns the Transmission Acknowledgement will indicate at what level the return was rejected, at the Transmitter, Originator or return level. The Transmission Acknowledgement will include the following:
Transmission Acknowledgement:
1) WellformedDocument
2) TransmitterID
3) ItemCount (returns, payments or return payment combinations) loop
4) TimeStamp
5) UniqueIDNumber (similar to the DCN)
6) PaymentReceived
7) OriginatorIDNumber
8) TaxpayerIDNumber
9) FormType(including whether payment is attached)
10) Accepted/Rejected
11) ErrorCode (per rejected item)
12) RejectionMessage (optional)
The group discussed what timeframe would be acceptable to states and vendors for receipt of the transmission acknowledgements. The group also discussed including an optional field that provides vendors with an estimated number of hours before they will receive the transmission acknowledgement.
The state gateway will post acknowledgements and the Transmitter will be responsible for pulling acknowledgments down from the gateway. A loop will be added to the acknowledgement schema to count the number of returns in the transmission.
The group also re-visited whether there would be legal issues with receiving the UI and Withholding filings in the same transmission or at the same gateway. Each state will look into whether it sees any issues with this and will report back at the June TIGERS meeting.
Terry Garber volunteered to update the Gateway Document with the new specifications prior to the June TIGERS/Consortium meeting.
Timely Filed Timestamp
The vendors stated that taxpayers need to have confidence that electronic returns are considered timely filed, otherwise they may not choose to use the service. They also made the point that electronic returns should receive the same treatment as a post marked return, with respect to being counted as timely filed.
The IRS currently allows vendors to use the time stamp on their servers for timely filed returns. The IRS also provides the vendors with a grace period to correct and retransmit returns timely filed to the vendor. The vendors proposed using the vendor servers' date and time stamp for "timely filed" returns with the states also, with a grace period to correct and retransmit returns timely filed to the vendor. The vendors would also have a deadline for submitting returns received timely on their servers to the state gateway.
For some states, this decision might be handled administratively; for others, it may be a legislative issue. Faye Shea of Intuit agreed to draft a letter requesting that the states adopt a policy of using the vendor or transmitter servers' timestamp as a timely filed return, with a grace period for retransmitted returns. The states agreed to bring the letter to the attention of the appropriate state management for consideration.
Intuit proposed possibly adding a re-transmission flag to the schema to identify retransmitted returns. This issue will be researched prior to the June TIGERS meeting and a proposal will be made at that time as to how to include the vendor's return receipt time stamp, and how to add a retransmit flag to the employment schemas.
Future of the COTS SPEF Project
Beatrice Howell spoke to the group about the future support for the project. She indicated that resources to the support project may be reduced or eliminated in the future. For now we are proceeding, but she fears that future contractor support may be in jeopardy.
Several states offered to write letters to their congressmen and Governors asking that they write to the IRS Commissioner regarding the continued support and participation from the IRS for the completion of COTS SPEF project.
Terry Garber volunteered to draft a letter to Harley Duncan, Executive Director of the Federation of Tax Administrators, which expresses the feelings of the TIGERS group on the value of the project, and the desire that it be seen through completion.
Beatrice asked members of the consortium what criteria would need to be met to consider the COTS SPEF project a success. The following criteria was identified:
1) Published XML schemas for use in COTS SPEF filings
2) Technical specifications for developing a state gateway to receive COTS SPEF filings
3) At least one successful pilot demonstration between a vendor, state and the IRS for the IRS 941, state withholding and state unemployment insurance.
4) Identification of an infrastructure to maintain the COTS SPEF specifications and standards (which TIGERS has agreed to do)
Action Items
As a result of the TIGERS and Consortium meetings, the following action items were identified for completion prior to the June TIGERS meeting:
1. Draft and distribute COTS SPEF-related meeting minutes to consortium by 5/15/02. - VRI Team
2. Add data element lists from MT, NY, OK, MS, ID, MI. Collect annual reconciliation data elements from partner states. Due by 5/14/02. - VRI Team
3. Provide VRI with a list of state W-2/W-3 data elements by 5/15/02. Faye Shea (Intuit)
4. Revise XML tag names for all three data elements lists (filing, payments, annual reconciliation) - VRI Team
5. Eliminate redundant elements and distribute to the consortium the revised data elements lists by 5/24/02 - VRI Team
6. Revise state employment schemas based the IRS candidate release v2, and decisions from the TIGERS/Consortium meetings and publish as working draft. Due date 5/24/02 - Jim Rowland, VRI Team
7. Update Gateway Document with specifications identified in the meeting. - Terry Garber (SC)
8. Document and post acknowledgement specifications. - Terry Garber (SC)
9. Research and document how to manage PKI within the employment schemas by 6/4/02. - Mary Thomas (IL) (Lead), Faye Shea (Intuit), Timur Taluy (fileyourtaxes.com)
10. Research HTTPS licensing requirements for gateways, provide proposed resolution to Terry Garber for the gateway document. - Richard Rogers (CA) (Lead), Christian Bethea (Nelco)
11. Post June meeting announcement and agenda. - Terry Garber (SC), Jonathan Lyons (FTA)
12. Propose how to generate and deliver a unique tracking number (similar to the IRS DCN) for each return by June 4, 2002 - Timur Taluy (fileyourtaxes.com) (Lead), Stephen Bouchard (MD)
13. Propose a way to incorporate the vendor's return receipt date/time stamp and add a retransmit flag to the employment schemas, which may serve to indicate that the return was timely filed. Due date 6/4/02. - Faye Shea (Intuit) (Lead), Timur Taluy (fileyourtaxes.com) , VRI Team
14. Draft and send a letter requesting the states accept the receipt date of vendors' servers as a timely filed return, with a grace period for retransmitted returns. - Faye Shea (Intuit)
15. Deliver letter/proposal from Intuit for timely filed dates to state management. - Consortium states
16. Schedule a conference call/meeting the week of May 20th to discuss gateway specifications with CT (Lead), ITCI, Glenda Hayes (MITRE), EzGov, Jim Rowland.
17. Determine legal issues and implications of receiving withholding and UI filings in the same transmission through a single gateway and report at the next meeting (6/4/02). - Each State
18. Add OK, MS, ID, MI state contacts to the consortium. - Beatrice Howell, Tracy Green (IRS)
19. Obtain partner agreement from EzGov, Greatland Corporation, ProBusiness Services, Inc. - Beatrice Howell, Tracy Green (IRS)
20. Invite Dan Swenson to the June 4 TIGERS meeting to present on API Development plans. - Beatrice Howell, Tracy Green (IRS)
21. Add and revise payments data elements according to decisions from the April meeting. - govOne, VRI Team
22. Develop and propose schema design to accept bulk payments, in addition to other payments. - govOne, VRI Team
23. Develop and propose schema design to accommodate overpayments and credits. Due date 6/4/02 - Mary Thomas (IL), VRI Team
24. Develop a payments schema to accommodate items #21 - #23 - VRI Team
25. Schedule consortium conference call for Wednesday, May 29th to discuss data elements list and schemas. Beatrice Howell/Tracy Green (IRS)