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: Tax Rate Structure

Dear all,
yesterday's discussion in the Indirect Tax CC about tax (rate) structure,
calculation (or not) on individual lines etc. made me think about these
issues again. 
If we agree on:
(1) The process of tax calculation itself is out of scope of standardisation
on business documents.
(2) However, business documents like invoices have to contain all
information necessary to do (maybe better: verify) such calculation.
(3) Therefore for every line item in an invoice there has to be an indicator
of the tax treatment applied to that line.
Then we may also agree on:
(A) For every line item we want an attribute that provides the indication of
tax treatment applied (That is more or less the "tax rate structure", but it
only needs to be a name, an identification, not the explicit structure: We
might see it just as the name of a function.)
(B) For every line either itself and/or the document structure "upstream"
have to contain all data necessary to perform (or verify) that calculation
(the arguments of the function).

For a simple percentage-tax the name/identifier of the relevant tax
structure for ease of understanding might be just that rate ("5%" instead of
something like "LowRate"), but for a tiered structure, it would have to be a
name of that structure and not the rate that happens to apply in the
particular situation. The actual numeric rate resulting from the application
of the function (you might say an intermediary result of the calculation)
may or may not be something you want to include in the document along with
the resulting tax amount.

While the "function name" (the tax structure name) from a document interface
perspective does not serve as a means to calculate, it may serve as a means
to check for consistency of the document. For by virtue of (B) above it
becomes clear what elements that are optional in the general document
structure become mandatory in the particular situation (as they are needed
as arguments in the function).

The discussion about the calculation in the Canadian GST/HST environment
(where my feeling was that something had to be relevant on the line level)
could be resolved by a tax treatment indicator on the line level that
relates to the treatment 'add amount of this line into such and such sum and
apply such and such function on  the final result on invoice level'. 

I hope this is a step to clarification, not to confusion.

Kind regards

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