<p> TIGERS FED/STATE 1040 DISCUSSION</p><p>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)</p><p>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. </p><p>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. </p><p>Results of discussion:</p><p>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.</p><p>The return data schemas would be developed by each state, using TIGERS maintained libraries of simpleType and complexType building blocks.</p><p>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)</p>