[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]