[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: No Subject
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]