OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tax message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [tax] Draft Tax XML teleconference minutes


I agree somewhat with the approaches described below....I would caution
against starting the building process with a set of common (globally
relevant) components (top down approach) as it will result in delays to
any tangible outcomes due to decision churn that is inevitable in a
committee approach to development. I would propose we pick a
jurisdiction, maybe one that has a maturing (or close to) taxonomy that
is willing to donate, which would provide the TC examination and
validate some of the statements below. Sure this will result is some
duplication (which can be mapped of course) - I believe it results in
speedy outcomes.

If we haven't already, we should seek permission to examine the IRS & UK
IR Corporate schema's, and contact X12G2 / Tigers for Sales Tax; EU for
VAT....you get the picture 

Finally I still see the value in creating a statement (press release) to
the effect that the TC will examine and develop generic Individual /
Corporate / GST / VAT / Sales / Transfer pricing.....(one / some / all
of the above) -- this will attract further interest /participation in
the TC so that there are more hands to do the work and acceptance by
association. The current charter is too vague.

Peter

-----Original Message-----
From: John.Glaubitz@vertexinc.com [mailto:John.Glaubitz@vertexinc.com] 
Sent: Wednesday, March 12, 2003 1:29 PM
To: Andy Greener
Cc: tax@lists.oasis-open.org
Subject: RE: [tax] Draft Tax XML teleconference minutes


Andy (and others),

Thanks for laying out the case for establishing a framework where "there
are container "documents" comprising re-usable "common" components" and
suggesting that our direction is to "take a coherent view of the problem
and tackle both aspects within the same fundamental framework where we
not
only avoid duplication of effort, but we also fit right in as a logical
extension to existing and emerging business standards."  I agree
completely
with this direction and the suggestion that there's an overlap of much
of
what is required for "direct" and "indirect" taxation.

However, there is still the question of what "container documents" we
care
about and what do those containers need to contain?  What of those
contents
are re-usable common components (such as those defined by UBL/ebXML),
what
are tax specific and may need to become a re-usable tax component or BIE
(Business Information Entity) and finally what are specific to a tax
type
or a jurisdiction?  To determine how to answer these questions we'll
need
to understand the context of the tax administration process that a
"container document" supports.  While we may be able to get to a good
general understanding of the requirements for tax administration,
perhaps
with some high level modeling, at some point we'll need to focus our
attention on specifics such as tax type to identify the document types
involved and validate the tax-specific components.

There seems to be two ways to approach this.  One is to start by
focusing
on a tax type and working through the details and producing the
deliverables for that type and then moving on to the next.  This may get
us
the first set of results more quickly, but may require a good deal of
re-work as each new tax type is considered.  The other is to start by
focusing on a tax administration process, understand the commonalities
and
then move on to the details for the tax types.  This may be a better way
to
identify what is truly common, what is tax specific and what is tax type
specific so that components can be more re-usable.  This approach may
allow
us to make progress that will have value to all concerned before
selecting
a tax type to focus on.  Ideally, once we start to focus on the
specifics
we'll be able to move more quickly from tax type to tax type.

By performing this analysis we'll be able to identify which components
or
BIEs are truly tax specific, which are common business elements and
should
be reused, and which are specific to a particular jurisdiction, tax type
or
application and should not be included in the standard.

To get this effort moving, it would be helpful to know the expectations
for
the direction and deliverables of those that plan to contribute to
either
the business or technical commitee.  Also, if there are any projects in
the
works that could contribute to both the business and technical analysis,
we
should determine how to take advantage of these efforts and how this
information could be shared.

John Glaubitz
Michael Roytman
Vertex, Inc.



 

                      Andy Greener

                      <andy@gid.co.uk>         To:
tax@lists.oasis-open.org

                                               cc:

                      03/11/2003 04:45         Subject:  RE: [tax] Draft
Tax XML teleconference minutes                                
                      PM

 

 





At 8:25 am -0500 7/3/03, Lutes Terence H wrote:
      First, my biases.  It is not news to anyone that the U.S. does not
      have a VAT/GST at the federal level.  The states would likely have
an
      interest.  I would not support working on indirect taxes if that
      means delaying income taxes.  I know a large number of countries
are
      modernizing or just developing electronic income tax systems.
Thus
      to delay standards development on the income tax side would be to
      miss a tremendous opportunity.  If there is a desire to work
income
      taxes right away, I would suggest consideration of two technical
      subcommittees, one for income taxes and one for indirect taxes.
The
      question is, "do we have the bandwidth for this?"

From a technical point of view I don't think that it would be good idea
to carve up the territory into "direct" and "indirect" taxes. To my mind
these are two sides of the same coin and we would benefit from dealing
with both together. Let me try to explain....

When we think about "direct" taxation we usually have in mind
transactions
that are primarily designed to report, or even to arrange payment of,
taxes
rendered from some sort of legal entity to a tax jurisdiction in
fulfillment
of some legal requirement. Typically, in the paper world, we have some
sort
of
tax form, specifically designed to convey identification information,
tax compliance information and perhaps actual financial information,
sometimes
accompanied by payment information (a cheque, credit card details or
even
pieces of paper issued by a central bank that "promise to pay the bearer
on
demand...." - ie money).

When you think about this kind of transaction in a logical way, it
really
boils down to a "container" document defined by the tax authority which
carries
a number of well-defined components, some of which have nothing
intrinsically
to do with tax (names, addresses, time periods, financial calculations,
payments, etc) but which are the subject of other standards initiatives
(e.g.
the OASIS extensible Name and Address Languages - xNAL, or XBRL), and
some
of which are specific to a tax jurisdiction and/or a particular type of
tax.

Now examine the transactions that involve "indirect" taxation. These are
usually business documents of one form or another (invoices, receipts,
etc),
the primary purpose of which is not to report or collect indirect tax.
Tax
authorities have no direct influence over the design and construction of
these documents, save perhaps for the legal requirements to show the tax
information in certain ways. The tax component of these documents is
just
one of a number of components that you'd typically find embedded therein
(names, addresses, time periods, product descriptions, payments etc -
spotted a pattern yet? :-).

On the one hand, taxation is the primary purpose of direct tax
"transactions",
and a number of subsidiary "common" components are required to compose
the
"ensemble". On the other hand, indirect tax is a subsidiary "common"
component
in the "ensemble" required to compose a business "transaction".

When you look at these two aspects together, it becomes pretty clear
that
in all cases there are container "documents" comprising re-usable
"common"
components. In the direct tax case, we (as a tax standards body) are
likely
to have jurisdiction over the document types, or "templates", and the
tax-
specific components (which may or may not be re-usable). In the indirect
tax
case, we may have jurisdiction over the tax-specific components ceded to
us
by the bodies responsible for various types of business documents. In
both
cases we will need to adopt or work with standards already defined for
non-tax-specific components or document templates.

If we take a coherent view of the problem and tackle both aspects within
the same fundamental framework then we not only avoid duplication of
effort,
but we also fit right in as a logical extension to existing and emerging
business standards.

It will probably not have escaped your attention that I'm referring in a
rather thinly veiled way to UBL/ebXML and their framework of document
templates and re-usable components (called Core Components in ebXML and
defined there as abstract entities, and called Business Information
Entities,
BIEs, in UBL where the abstract entities are made flesh in the guise of
XML Schemas). An awful lot of work has already gone into UBL, which is
underpinned by ebXML, and it is beginning to look like the only game in
town (unless we want to re-invent a whole bunch of wheels).

Perhaps, once the technical sub-committee is constituted, it will be
time
to
put up a "strawman" proposal for our work, based on the UBL framework.
Then
the technical SC can get to grips with the technical complexities of UBL
and ebXML whilst the business SC defines requirements that will
eventually
be satisfied by tax-specific UBL document templates and tax-specific
BIEs
cranked out by the techies.

        Andy
--


Andy Greener                         Mob: +44 7836 331933
GID Ltd, Reading, UK                 Tel: +44 118 956 1248
andy@gid.co.uk                       Fax: +44 118 958 9005








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]