Post on 12-Feb-2016
description
transcript
Tigers Working Group
4.x Schema review
Participants
Scott Mueller, Wisconsin Richard Rogers & JoAnn Costa, California Toraino Owens, Florida Penny Berman, Maryland Angela Gridley & Preston Barnett, Ceridian Jenine Hallings, PayChex Joyce Inouye, ADP Winston Stein, BSWA Faye Shea, Intuit
Meeting Goals
General Schema review, including alignment with MeF Packaging
Support for FTP and. Web Services Allow transmission packaging to support larger service providers
Support for Acknowledgements Support for PDF attachments The Question of a Manifest
New Hire and Contractor Reporting Enrollment and Data Exchange Schema Updates Gateway update
Need for new service to support Data Exchange Response Progress on creating a Reference WSDL for use in developing a
Web Service solution Accompanying documentation
Including Standard Error messaging
4.x Alignment with MeF• WH, UI and Combined filings and payments review is complete
• New Hire and Contractor reporting
• Verified initial Schemas provided
• Scott will evaluate latest version against 4.x standards – To be done before Orlando
• Data Exchange and Enrollment
• Verified alignment with MeF
• Questions from Tucson meeting
• TimeStamp – Concern that this may be a reserved word
• Tag is used in MeF, and is also in the other filing schemas.
• Team recommendation - Leave this tag as is and address all schemas if the decision is made to change it.
• Length of tag names
• Team recommendation - Tag names are consistent with MeF and other filing schemas
Packaging
Packaging: One to Many Submissions per transmission
HTTPS/FTP
• Transmission sent with Transmission and Transmission header
• Include 1 to many submissions of Return State
Web Services
• Each submission is a separate instance documents
• Submissions can be zipped and transmitted together
Packaging – AcknowledgementsSupport for Acknowledgements
• Message Receipt for transmission
• Each return has a submission id allowing acknowledgements for each submission
Packaging – PDF Attachments• Utilize existing MeF mechanism to provide support for Binary Attachments
• Consists of 4 elements
• Reference (Form & Line number)
• Document Type (PDF)
• Description (Text – for example POA)
• Attachment Location (File Name, for example SubmissionId.pdf
• 2 Folders inside zip file
• Separate folders for XML and PDF
• Naming Standards
• xml
• attachment
Example Enrollment1.xml
Enrollment1.pdf
…
Enrollment99.xml
Enrollment99.pdf
The Question of a Manifest
Purpose – IRS identification and minimal validation of state filings
• Identify Jurisdiction
• FEIN, Name Control Check
• Determine Link v. Unlinked submission
• Designed to allow IRS to read and react without reading state return
Team Recommendation
– No need for a manifest until FSET is included in MeF. We can add at that time.
New Schemas for 4.x
New Hire and Contractor Reporting
Added to Return State Structure
Enrollment Schema Updates
Modifications to Enumerated List A,C,D to Add, Change, Delete EML, FAX, USP to E-mail, Fax, USPS
Restructured to support: Multiple Enrollment per transmission Separate Acknowledgement for each
enrollment Support for PDF Attachments
Enrollment Schema• Support for FTP and. Web Services
• Allow transmission packaging to support larger service providers
• Support for Acknowledgements
• Support for PDF attachments
Data Exchange Schema Update
Categorization of Data Requirement
Provide ability to send separate data exchange requests This could be required for agencies with multiple back-end
systems (Today CA has 3 separate data exchange formats), or for WH data vs. UI data
Proposal Addition of 3 optional tags
EFT, Rates, and Applied for If Agency chooses to use the tags, implementation
documentation will provide instructions on how to populate this field and what fields will be returned for each option.
This also allows for one submission All tags could be checked, or the tag could be omitted
Data Exchange Schema UpdateOne v. Two Schemas
Requirement Determine optimal schema format to allow:
Only required fields to request data to be sent to agency Separate Request and Response elements Allow for repetition of Request elements in Response – while minimizing
complexity of maintenance (if the tags are changed in either it is changed for both)
Proposal RequestExchangeDataState.xsd
Contains only the elements to be sent when sending a request ResponseExchangeDataState.xsd
Includes RequestExchangeDataState.xsd as well as all possible response elements
Data Exchange Schema Update
• Packaging
• Support for FTP and Web Services
• Allows for Transmission packaging to support larger service providers
• Support for Acknowledgements
• Support for PDFs? Is this required?
Gateway Update
Gateway Methods
Recommended Gateway Services can be used for this new structure
SendSubmissions GetAcks GetNewAcks ChangePassword
Additional Gateway Service required to Get Response for Data Exchange
GetResponse, GetNewResponse?
Gateway – Next Steps
Creation of ‘Reference’ WSDL for state use Documentation for implementation
Update WSDL recommendation to reflect decisions Include supported services Name for new services
GetResponse, GetNewResponse Document Mandatory vs Optional Services
For example ChangePassword may be optional How to implement Gateway Include flowchart of how the process works Include ‘Lessons learned’
Volunteers to work with Richard Faye will help with documentation Scott will help with technical part Other volunteers welcomed!
Still To Be discussed . . . .
Recommendation for Standardized error messages
Recommendation for Supporting documentation
Actions from February Discussion
Open State Contractor Schema name to long – can’t be longer than 30 Verify persontype is consistent with other 4.x schemas in New Hire
and contractor reporting Location of submission id on various schemas
Working group to discuss, document both options and send with pros & cons for group vote
Closed Packaging - folders
Recommendation included in this PPT Is there a need for the gateway to handle submissions through one
gateway to send to other agencies in the state This will not be supported in Version 1
We can reopen if the need arises If we extend the gateway to support this, it may reopen the question of the
manifest