Motor Fuel XML Redesign Outstanding Questions For The Uniformity

motor fuel xml redesign outstanding questions for the uniformity team sept. 19, 2008 team members: * doreen warre

Motor Fuel XML Redesign
Outstanding Questions for the Uniformity Team
Sept. 19, 2008
Team Members:
*
Doreen Warren
*
Larry Hanson
*
Stan Whaley
*
Cheryl Gilson
*
And various Uniformity and TIGERS committee members.
Comment: The XML design team would like to stress that we are
committed to creating the XML schemas that support the Uniformity EDI
guidelines and Principles. (Uniformity EC committee confirmed that we
should develop schemas that utilize this direction as closely as
possible. Don’t include optional elements and/or structures unless
explicitly stated, as a “standard”, within the existing EDI guide).
1.
Header/ Filer Type Issue (State License Number):
Which identifying information should be permitted at the Filer
return/report level?
Option 1:
*
Require at least 1, at most 2 of FEIN, SSN, CBN, State License
Number
Option 2: Committee agreed with our recommendation (Filer level only
include optional
SLN)
*
Require 1 of FEIN, SSN, CBN
*
State License Number optional
Recommendation: Option 2 as it most closely resembles the current EDI
Implementation Guide.
Option #2

Basic XML
* Solid connecting line “­­_________“means the data is mandatory
* Dashed connecting line “------“means the data is optional
* Choice Gate means you can only select one data element per loop
* Plus sign in the box means there is one or more data elements. Click
on box to expand.
*
Connect dots in the box means data must be in that order/sequence.
Option #1 - Rejected

2.
General Schedules Issue
Which identifying information should be included in the schema at the
schedule level for carriers, sellers, buyers, position holders and
consignors? (Structure used all schedules and returns).
Option 1: Committee decided to not allow the State License Number.
This is consistent with the current Uniformity EDI standards and
Business Rules.
*
Include only FEIN, SSN or CBN
Option 2:
*
Include FEIN, SSN, CBN, or State License Numbers
Option 3:
*
Include FEIN, SSN, CBN, or State License Numbers in the schema;
since the uniformity standard is to not require license numbers;
any state that did would be deviating from uniformity, but this
option would allow those states (and taxpayers that file in those
states) to still take advantage of the uniform schema
Recommendation: Option 1 or 3
Option 1 most closely resembles the current EDI Implementation Guide.
Option 3 resembles actual practice from several states with optional
SLN.

1.
Schema flexibility issue
How much flexibility should be built into the uniform XML Schema?
Examples:
On supplier schedules, should origin and destination always be
required?
On terminal operator schedules, should carrier always be required?
(Some jurisdictions don’t require all fields when industry re-brands
fuel)
Option 1:
*
Make schema firm – if state deviates from uniform schema, they are
not uniform and will have to create their own schema
Option 2: Committee agreed with our recommendation. Stay with existing
Business Model.
*
Make schema flexible –Uniformity Committee would set standard
rules or ‘best practices’ using schema structure; this option
requires more responsibility on e-commerce to review xml
implementation guides and from individual states to comply with
uniformity guidelines
Recommendation: Option 2 – this most closely resembles current EDI
implementation guide & uniformity practices
2.
Non-IRS Terminal Reporting
Will XML schema handle reporting for non-IRS (unapproved) terminals
within the terminal report?
Option 1:
*
Make terminal code optional
Option 2: Committee agreed with our recommendation. Also remove the
TCN
pattern. This would allow states to use back end system to validate
(could use Non-TCN number). These are currently Bio-Diesel producers,
but could have additional IRS TCN types in future.
*
Leave terminal code as required. Re-address this issue if a
uniform method of reporting non-IRS terminals is added
Recommendation: Option 2
Question: Do we need to consider making the TCN longer than 9
characters?
Committee said we should remain nine alphanumeric.
3.
Terminal Report Details
Should calculated fields (total receipts, total available, total
disbursements, quantity available) from the terminal operator form be
included in the XML schema?
Option 1:
*
Include these totals; they are on the form and should be allowed
in the xml schema
Option 2: Committee agreed with our recommendation, but we need to
verify
“exceptions” that should be included (in schemas). See Note:
*
Do not include these totals; uniformity guidelines are not to
require fields that can be calculated
Recommendation: Option 2
Exceptions: Summary (control figures) totals such as Total Net
Reported or Total Net Transported. These allow states that aren’t at
the rack to reconcile with schedules. Other states need to confirm
taxpayer intent. We agree that totals that can be calculated from the
schedule detail shouldn’t be included.
4.
Optional Product Type
Should we have the Product Type as an optional element at the current
level? This means that all data below would be linked to the product
type, if provided, but it could be sent without a product type
(inventory without a product) as presently structured.
Option 1:
*
Leave Optional Product type at its current level within schema.
This would means all data below could be sent without a product.
Option 2:
*
Make Product type mandatory at it current level within schema.
This means that a product is required by schema, but would enforce
all data is associated with the product (including Credit element)
Option 3: Committee agreed with our recommendation. Question
concerning making
Product type mandatory within MFReportDetailType. It appears with need
to
make it mandatory.
*
Leave Optional Product type at its current level within schema,
but also provide non-product specific elements at higher level of
schema to allow for data (ex. Credit) that isn’t associated with a
particular product type.

The next example allows for both Credits that are Product specific and
the “summary” Credits that aren’t product specific.
* Product Type becomes mandatory in the following option.

Follow up Meeting:
1.
We will hold a Conference Call and WebEx on either Oct. 7/8th to
confirm the results from the Uniformity meeting. Doreen Warren and
Larry Hanson weren’t able to attend this meeting.
2.
XML redesign team will make changes and produce a new draft before
the Dec. TIGERS meeting.
3.
We will report back to the Uniformity Committee at their Jan. 9-10th.
We should have the final draft ready for distribution.
4.
We still need to provide documentation about the XML schemas for
the Uniformity EC Implementation Guide.
a.
XML 101 (limited XML expertise in the Uniformity EC Committee)
b.
High Level explanation of how the XML differs from traditional
X12 EDI.
c.
Explanation of specific structures within Schemas such as
Enumerated List Type.
d.
All will need to be ready by the May 2009 Uniformity Meeting for
inclusion in the 2009 Guide.