Tigers Fed/State 1040 Discussion

TIGERS FED/STATE 1040 DISCUSSION

1. Determine our goals.  Easy transition (Donna - AZ)  Consider preparer support cycle (Jack - Drake)  Maintainability (Penny - MD)  Facilitate back end processing – Ping – NYS)  Facilitate development of sw (Greg – Intuit)  Separate data capture from forms design, especially last-minute tweaking (Terry – IL)  Build on what already have (Donna – AZ)  Easy to make changes year to year (Jim – NE)  Flexibility, especially for last minute legislated changes (Terry – KS)  Reduce incremental time for industry to bring up a new state (Terry – SC)  Reduce time for new states to come online (Jamie – Drake)  Ease to implement mandates (Susan – CCH)  Maybe time-out from mandates (Donna – AZ)  Processing efficiency, not just development (Penny – MD)  Not bloat file sizes, eg PDF attachments (Atilla – FYT.com)  Easy to identify and communicate errors (Ping – NYS)  Provide options for states who are not ready (Atilla – FYT.com)  Be ready on time (Donna – AZ)  Semantic clarity (Bill – MN)  Adherence to standards by all states – (Atilla – FYT.com)  Adherence to XML standards (Bill – MN)  Adherence to XML best practices, clean schema design (Jack – Drake)  File naming conventions, schema versions, zipping structures, esp. for transmission (Susan – CCH)  Easy not to violate schemas (Amy – CCH)  Standards for handling multiple versions in production (Sean – CA/FTB)  Backwards compatibility (Greg – Intuit)  Make sure # of accepted efiled returns does not go down year 1! (Jack – Drake)  Uniformity of approach (Atilla – FYT.com)  Release schemas sooner (Shaun – Taxworks)  Reduce development time by leveraging current design elements (Jamie – Drake)  Process for the next 15 years (Scott – WI)  Successful transition – may not be “easy” (Lynn – NYC)  Numbers not decrease (Jack – Drake)  One transition, not multiple (Terry – SC)  Solution could be in phases (Donna – MD)  Preparers and states can both easily support returns coming in (Penny – MD)  Good transmission times for volumes (JoAnn – NC)  Conform with IRS standard practices, eg partial payments and 20-day rule (Ping – NYS)  Get decision made timely (Steve – ID)  Implications for other tax types (Doreen – ID)  Minimize rework (Amy – CCH) 2. Determine pain points. a. With the MeF approach used by Fed/State 1120/1065.  When looking at state instance, need secondary spreadsheet to understand (equate data to) return (Penny – MD)  Difficult to maintain schema, to assign multiple people (Ping – NYS)  Difficult for back end system to map back to form-based data elements (Ping – NYS)  When display data, need to get back to paper forms (Ping – NYS)  Complexity of spreadsheet process, number of people needed to manage eg, boil down, need for SWAT team, turnaround time (Donna – AZ)  Barrier to late changes (Jamie – Drake)  Difficult to use master schema from business person’s perspective, difficult to find the elements (Donna – AZ)  Change control process overhead, need to get approval to add new elements (JoAnn – NC)  Too much flexibility, eg in Header no standard taxpayer identifier (Shaun – Taxworks)  One form spread over multiple records, schemas (Gred – Intuit)  Procedural – dropped ball on boiling down, lot of redundant elements (Scott – WI)  Use of volunteer time to maintain spreadsheet – majority of elements used by only one state (Terry – KS)  Master state schema so different from IRS (Jack – Drake)  Errors in boil down process, in state schemas due to errors in master (Jack – Drake)  Number of meetings needed to keep up, eg Amount1040Type (Jack – Drake)  States needing to wait for master schema release, especially if needed change breaks the master (Penny – MD)  Limitations of Excel as vehicle (JoAnn – NC)  Desire to rely on what is familiar (Susan – CCH)  Difference of state specific schemas to master schema – lack of real uniformity or benefit (Jack – Drake)  Initial benefit vs ongoing pain of maintenance (Penny – MD)  Changing rules, eg ctype structures, category definitions, as new states trying to come on board (Irwin – NJ)  Ease of forms based approach (Ping – NYS, Jamie – Drake, Shaun - Taxworks)  Difficulty identifying IRS vs TIGERS pieces (Bill – MN)  Difficulty implementing how forms work, eg recurring instances (Penny – MD)  Lose readability of XML when not correspond to form (Terry – KS) b. With legacy 1040 efile.  It goes away in three years! (Steve - ID)  Only supports one state linked to federal return (Greg – Intuit)  All data types, editing, must be done manually, in code (Ping – NYS)  Inherent risk in ability for each state to go its own way (Atilla – FYT.com)  Fixed-length fields, eg field 300 – can cause federal return to be rejected (Greg – Intuit)  Lack of support for amended and prior year returns (Bill – MN)  Not handle supporting schedules very well (Donna – AZ)  Expansion of variable records by IRS not match original transmitted record – difficulty in debugging (Ping – NYS)  Difficult to human read (Scott – WI)  Error in one return causes entire download not to process (Terry – IL)  Good – compact, efficient, difficult to contaminate (Atilla – FYT.com)  Familiar (Irwin – NJ)  No parser errors/can get junk (Jack – Drake/Scott – WI)  Related to above, control over how error messages are presented (Jack – Drake)  Generic record getting large, though given state may only use parts (Ping – NYS)  Positive – very flexible for states (Jamie – Drake)  Standardized – not by design, but by practice, lessons learned (Jamie – Drake)  Acknowledgements very general, not atomic, can be improved (Atilla – FYT.com)  Generic record not flexible for repeating forms (Jim – NE)  MeF ack categorizes business rules and has form fields (Greg – Intuit)  IRS not provide way to display federal return in legacy system  Some attachments not incorporated, may not be needed – want completely electronic (Atilla – FYT.com)  Returns needing attachments cannot be filed electronically (Ping – NYS)  IRS consistency validation – pro and con (Jamie – Drake)  Difficulty expanding generic record when needed (Stephen – MD)

3. Possible approaches.  XML wrapper alternative for legacy record format (Atilla – FYT.com)  If state falling behind, can still receive efile (Atilla – FYT.com)  Additional work for sw developers – throw-away code (Greg – Intuit)  Same for states, third system to support (Scott – WI)  If state is ready for XML, not an option (Jamie – Drake)  States could build legacy schema, but not viable long-term solution (Sean – CA/FTB)  May help goal of not reduce # of efilers (Lynn – NYC)  Issue: how include copy of federal return if in XML?  Clarification: still have manifest, XML ack, but schema is single element  Straw vote: not pursue.  Form-based with standardized Header, schemas for each form, standardized financial schema for direct deposit and ACH debit payment, standardized ack, included in state return (Ping – NYS)  Easy to develop (Irwin – NJ)  Part of work already done (Donna – AZ)  Flexible (Jamie – Drake)  Developers would have to do different schema for each form for each state (Amy – CCH)  Less work for developers already supporting 1120/1065 (Donna – AZ)  States can develop own schemas as long as well formed (Shaun – Taxworks)  Category based schema unsupportable; forms-based supportable because can read the form without spreadsheet to interpret (Jamie – Drake)  Master list was for code reuse and software developers; not sure this little bit is of any use (Scott – WI)  Would not have any unused elements (Greg – Intuit)  One source code file corresponds to one form (Greg – Intuit)  Once get arms around superschema, easier tool to turn out new states (Susan – CCH)  More comfort that get data that want from software (Irwin – NJ)  Code reuse – didn’t have with master schema because edits varied between states. Maximum is what have with legacy (Jack – Drake)  Header is example of code reuse – with IRS have between form types. Would make that critical part of code more reliable, same with financial transaction (Greg – Intuit)  Clarification: Header would be extracted from “forms based”  Straw vote: basis? Most agree.  Ability to pick and choose forms for copy of federal return (Ping – NYS)  Already have – independent of discussion of state format (Scott – WI) Agreement.  Also add standardized binary attachment record, ack, and manifest (Greg – Intuit)  Manifest and ack owned by IRS; not depend on format of state return (Scott – WI) Agreement. (But need better documentation where to find! (Bill – MN))  Keep things that work: manifest, ack, some complex types, look at transition to phase in from “string20” approach for all elements, develop libraries of elements and ctypes states can use (Donna – AZ)  Break efileType libraries into simpleTypes and complexTypes, some of which are building blocks, but many of which, like column headings, may want to be more forms based (Scott – WI)  Straw vote: Agreement, no dissent.  Like to see states use IRS efileTypes wherever possible (Jack – Drake)  As few types as possible – where standardization possible, key to code reuse (Greg – Intuit)  Make all numeric items EntityDetailType – description and money (Terry – IL)  General discussion on keeping types very simple:  Would allow state to be category or forms based (Terry – IL)  Concern with need for back-end edits (Terry – SC)  Transition to XML for new states; others could refine further (Donna – AZ)  Concern with EntityDetailType makes xpaths more difficult to code (Penny – MD)  Reduce parser errors Year 1 by keep simple (Jack – Drake)  Can add patterns by state (Shaun – Taxworks)  Three files – IRS efileTypes, state (TIGERS defined) efileTypes, state specific efileTypes (Jack – Drake).  Agreement at conceptual level.  If types exist in IRS or TIGERS, then must be used by states (Atilla – FYT.com)  Again agreement at conceptual level; some concerns.  Stay with current Category approach (Susan/Amy – CCH)  Straw vote: no, but not unanimous.  Throw everything away, including IRS, and build from ground up using XML-centric approach with taxonomy that everyone uses.  Straw vote: do not pursue.  Outside of Header/manifest, not require forms based; allow states to use Categories if desired (Penny – MD)  In some cases, Category does reflect a form (Donna – AZ)  Key is, let states do what want (Scott – WI)  From support, standardization, better that all be forms based (Jack – Drake) (Irwin – NJ)  NACTP standards document reflects lot of work; in that vein, all should agree on approach  Issue with “forms based,” eg desire to omit interim calculation lines (Scott - WI)  Issue is not to split forms across schemas; do support best practices for XML (Jamie – Drake)  Select one approach and all states adhere to it (Atilla – FYT.com)  Straw vote: states support standardization on forms based  States with short form to have one schema, with indicator as to long or short form (Greg – Intuit)  IRS looking at single form; will discuss at Software Developers Conference  Can use style sheet (Greg – Intuit)  Straw vote split half/half on whether this should be a standard.  Eliminate all attempts at uniformity; all states do their own thing (Scott – WI)  ….  No overflow information; elements within form record (Greg – Intuit)  General agreement.  Year 1: keep edits to numeric/string and length only (Jack – Drake)  If not have time to do XML typing, not have time to do back end edits! (Steve – ID)  Outstanding issue!!!  Header schema controlled by TIGERS, forms schemas controlled by states, then Header not restricted by states except in business rules (Penny – MD)  Value to transmitter in having critical information in one place.  Straw vote: most agree, not unanimous  Automated way to take legacy specs and generate XML schemas from them (Greg – Intuit)  Not follow XML best practices (Scott – WI)  Up to individual states (Ping – NYS)  Not 100%, but tool to help new states get started (Greg –Intuit)  If Category concept, relax making states wait for new release of master schema before making changes (Terry – KS)  N/A, but there is the issue of waiting for master efileType lists (Penny – MD).  Not an issue when adding me-toos (Scott – WI)  Value more with ctypes than element names (Jack – Drake)  Value in consistency in element names, as long as mean the same (Atilla – FYT.com)  Value for new states coming on, that want starting point, assistance (Terry – IL)  Header controlled, but bulk of forms-driven schema based on list, but no need to enforce to conform (Donna – AZ)  Want master list, but if need something not on list, just create and let developers make it happen (JoAnn – NC)  From support perspective, value in having element names match language on forms (Jack – Drake)  Some guidance, such as list, is appropriate, especially for very common elements, as long as can vary for legitimate reasons (Jamie – Drake)  Not get too “type-happy” - not force to use if doesn’t fit, not maintain monster list (Shaun – Taxworks  Create list of element names, but allow states to vary such things as whole dollars vs dollars and cents (Jamie – Drake, Penny – MD)  No enforcement, (Ping – NYS)  Issue was process and time needed, have to re-look (Donna – AZ)  Where feasible, use same element names as IRS (Greg – Intuit)  Let sw developers who work with multiple states (all states – (Steve – ID) do first cut (Bill – MN)  Willing to take on state or two to prototype, help, or build the actual schemas; lists and libraries build by TIGERS (Greg – Intuit, Shaun – Taxworks, Jack - Drake)  Eliminate master schema; keep Categories but let states build them as needed (Jack – Drake)  N/A  Implement namespaces for each state so they can define their own types (Shaun – Taxworks)  Would facilitate sharing and pooling of data (Shaun – Taxworks)  If states use ctypes differing from version in library, then should name differently, eg prefix with two/three character state/city id (Greg – Intuit)  Prefix all state-supplied ctypes in case TIGERS later adds them to library (Penny – MD)  Process approach: states transform XML to format needed for processing – developers could do reciprocal (Terry – IL)  As needed.  TIGERS bring in experts in xPath, XSLT for “XML 200” education (Jack – Drake)  All agree.  TIGERS can also help new states by developing set of best practices (Penny – MD)  Are online classes, such as Altova (Tim – PA)  Discussion group on www.statemef.com (Donna – AZ)  Make cleaner schemas by eliminating attachments, statements no longer current (Atilla – FYT.com)  IRS did analysis to eliminate as many as possible; states encouraged to do the same (Atilla – FYT.com)  Each state as separate complex type outside of Header (Pete – IA)  Facilitate getting copy of another state’s return (Pete – IA)  Another state’s return would probably be separate zipped file (Penny – MD)  TIGERS can establish prototype(s) (Terry – SC)  Keep Categories other than Credits; let Credits be forms-base free for all (Scott – WI)  N/A – see prior discussion  Metadata registry – open for comments, but still controlled, regardless of approach (Bill – MN)  Part of master list approach (Shaun – Taxworks)  Start from scratch and use CICA (X12) approach (Scott – WI)  Available tool for state and industry use (Scott – WI)  Standardize indicators, such as checkboxes and Booleans (Ping – NYS)  Establish TIGERS guidelines for best practices, conforming to extent possible with IRS conventions (Ping – NYS, Penny – MD, Jack – Drake)  Use Categories for element/ctype libraries, but states base schemas on forms (Tim – PA)  Limited value (Terry – IL)  Maintain libraries of forms, with formal change control process (Irwin – NJ)  Value of library, for when state needs another state’s forms, but no formal enforcement (Irwin – NJ)  Conceptual value, but hard to keep up – no value if out of date (Jamie – Drake)  Value if actually posted for validation, not just text (Shaun – Taxworks)  Could publish early versions for industry feedback (Jamie – Drake)  Could have one place with links back to each state, to make sure always have latest version (Ping – NYS)  Useful for states to publish separate production and test/working versions (Steve – CT)  Can establish as best practice, even if not enforceable (Jamie – Drake)  Categorize forms, and build standardized schemas to forms categories rather than abstract categories (Scott – WI)  Possible approach (Scott – WI)  Define Header like Generic record start, and remainder of schema like remainder of current layout (Jack – Drake)  Possible approach available to states; could then use XSLT to transform to match current back end (Jack – Drake)  May have additional elements in Header than generic record; would be standardized by TIGERS (Jack – Drake)  Just way to leverage existing structures as starting point where it may be useful (Ping – NYS)  If keep Categories, define specific parents in Categories other than Credits (Penny – MD)  N/A 4. Technical straw men.

Jack Gibson of Drake showed a prototype that he had developed working with Kansas and New York. The prototype will be updated and posted on www.statemef.com.

Results of discussion:

The state return will have a standardized Header, return data that is developed by each state, a standardized FinancialTransaction if needed, and standardized BinaryAttachment if needed.

The return data schemas would be developed by each state, using TIGERS maintained libraries of simpleType and complexType building blocks.

This prototype will be used as the basis for further development work. 5. Action Items/Next Steps  Resolve open issue(s) and 50/50 from discussion #3.  Prepare proposal/recommendation from this meeting to rest of states/industry  All 38 states, or just ones that have signed up? (Donna – AZ)  Good question! (Jonathan – FTA)  Send out email to NACTP listserve for consensus and to point to website and TIGERS listserve (Jamie – Drake)  Future of spreadsheet/boil down?  Will have TIGERS efileTypes of building blocks – work to be done  Will have element list – work to be done  Can eliminate spreadsheet columns back to simple list  Get rid of category prefixes for element names  Start with existing 8/10 state list.  Analyze, simplify, for example where breakout between primary/secondary  Organize elements logically; categories may still be useful just as information (Shaun – Taxworks)  Donna (AZ), Penny (MD), John (NYS), Shaun (Taxworks) to take first cut  Formal directory structure proposal (Jack – Drake, Penny – MD)  Expanded prototypes (Shaun – Taxworks, Jack – Drake, Ping – NYS, Greg – Intuit, Terry – KS) NOTE – dependent on directory structure  Schemas for non-IRS standard forms like some 1099’s  Possible replacement of spreadsheet with RSI database  Complete standard schemas for Financial Transaction, etc.  StatiC schemas: StateReturn, Header, FinancialTransaction, BinaryAttachment, Acknowledgement (Greg – Intuit, Penny – MD, Terry – SC, Jack - Drake)  Discuss options for piggyback during Phase I when all needed IRS forms may not be available  TIGERS recommendation: a specific return would be either all MeF or all legacy. (1099-G is state form, does not exist at IRS level; 1099-R would be considered IRS form)  Capture and disseminate best practices  www.statemef.com is repository  Build draft (including update of MeF 101 for finalization (initial release) in August (Donna – AZ, Joan – IRS, Michael – Intuit, Bill – MN, Penny – MD, Greg – Intuit)  ****TARGET DATE FOR ALL DRAFT DELIVERABLES 7/20/07  Look at joint TIGERS/NACTP session (Jamie – Drake, Terry – SC, Jonathan - FTA)  Re-evaluate RSI role (Terry – SC, Jonathan – FTA)  Create contact list (Terry – SC, Debbie – OK)