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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-psc message

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

Subject: Re: [ubl-psc] Taxes

Duvekot, Kees wrote:
> quick answer from me (I'm on holiday)

Thanks for taking the time!

> on part 1:

> TaxCategory also has the TierRange etc because the TaxCategoryType is
> also used outside of TaxSubtotal

Great.  That's what I needed.

> Element cac:ApplicableTaxCategory
> Element cac:ClassifiedTaxCategory
> Element cac:TaxCategory

I was overlooking the more qualified terms.  Your explanation makes this
all clear now.

> The ClassifiedTaxCategory is used to identify the type of Tax that
> would apply to a certain item when sold. So there you also need to be
> able to specify possible tax percentages/rages/tiers etc .. .without
> having a TaxSubtotal to hold the actual tax amounts.

I will see whether some reference to this can be included in the

> So in most cases you do not specify the percentage etc at the
> TaxSubtotal level but under the TaxCategory (because that is where it
> is usually attached to). You could replicate them again under
> TaxSubtotal, but there is no need for that duplication as far as I can
> see.

I will say something about this in the definitions.

> You could argue that they can be removed under TaxSubtotalType ... but
> I am not sure if that is possible from a backwards compatibility point
> of view or from other types of implementations. (they were added on
> UBL 2.0)

It's therefore not possible.

> on part 2:

> On a invoice, for example purposes, you can have 0-n TaxTotals at the
> " header" level. But each TaxTotal at the header level should only
> applies to one specific TaxScheme. (allthough this is not mandated in
> the structure).

We should put something about this in the definitions.

In Europe there is usually only one specific TaxScheme
> (VAT) unless you start going into excise related tax for Petrol,
> Tobacco etc which I have no knowledge about. In the USA it is more
> common to have more TaxScheme's. You could have 2 scheme's that might
> apply to a invoice, State and county/city tax etc for example. Now you
> could even argue that there is not one single EU TaxScheme, but 27 EU
> Tax Schemes (one per member state)

The examples are very helpful.  I'm looking for much more of this in
some of the other definitions.

> Each TaxScheme determines various categories of tax (High Rate, Low
> Rate, etc etc) so if you have various items that apply to different
> categories, or on one invoice you invoice multiple deliveries to
> multiple locations that determine different rates, you will have
> multiple TaxSubtotals (Remember, tax is usually determine based on
> WHAT you deliver WHERE to WHO and also FROM where). And to make things
> even more complex one item can have multiple TaxCategories based on
> where it is sold/delivered etc. (some Items that are classified as Low
> rate VAT in one EU country can be High Rate VAT in an other.)

Again, these examples are very helpful.

> To get some idea about the complex structure around tax categories
> have a look at this EU document:
> http://ec.europa.eu/taxation_customs/resources/documents/taxation/vat/how_vat_works/rates/vat_rates_en.pdf

That's OK, I believe you.

> What you should also take into account is that TaxTotals can appear at
> various levels in a UBL document. If there are TaxTotals at a lower
> level then the TaxTotal at level n should be the sum of the TaxTotals
> of level n+1. (at least .. that is what I think should be the case)
> But because TaxTotals are not a mandatory items you could also only
> specify them at the very lowest level and not at any higher level at
> all. Or only at some intermediate level, or a mix of everything. But
> this all depends on the rules for applying tax on subtotals for each
> TaxScheme. (in some countries you can do rounding at the lowest level,
> in other you can not do rounding at the lowest level but only at the
> highest level)

I think I feel a headache coming on.

> And because all these totals do not have to be used, you can also not
> always " just" apply the percentage to the Taxable amounts at every
> level because it might be that the TaxableAmount is a sum of other
> TaxableAmounts at lower level in the UBL structure. And the same goes
> for TaxAmount, that could also be calculated at a lower level, rounded
> there, and then summarized at a higher level. And due to rounding you
> might end up with different amounts. I would guess the
> TaxEvidenceIndicator could be used to show if this TaxTotal was for
> summary purpose only, or if it was a real calculated TaxTotal. But not
> sure if that would be "correct".
> I am not an full blow UBL tax expert but what I do know is that UBL
> and taxes are complex and that there is no "one correct way" to
> populate the tax related structures. And that is the reason why so
> many things might look duplicated. So each group of trading partners
> need to determine how they are going to use this setup and ALL agree
> on that. Otherwise it might be difficult to correctly interpret the
> tax parts of UBL documents. So that is how I interpreted this setup. I
> suspect other people will have different views.

This is (fortunately!) not the time to revisit the 2.x tax structure,
which is carved in stone for this release; I just want to get the
definitions straight.

My problem is mostly about this definition for TaxTotal:

   The total tax amount for particular tax scheme e.g. VAT; the sum of
   each of the tax subtotals for each tax category within the tax

I see from your examples that I was misreading this.  How about the
following for TaxTotal:

   The total tax amount for a particular tax scheme (e.g., VAT); the sum
   of all the tax subtotals for all of the applicable tax categories
   within the tax scheme.

The definition for each of the following occurrences of TaxTotal then
becomes "The total amount of taxes applicable to this [whatever] under a
particular taxation scheme":

   Consumption / TaxTotal
   ConsumptionLine / TaxTotal
   CreditNoteLine / TaxTotal
   DebitNoteLine / TaxTotal
   InvoiceLine / TaxTotal
   Line Item / TaxTotal
   PriceExtension / TaxTotal
   TelecommunicationsService / TaxTotal
   TelecommunicationsSupplyLine / TaxTotal
   TenderedProject / TaxTotal

Note that in all of these, TaxTotal is 0..n, so you end up with all the
taxes (modulo possible roundoff complications) on each kind of taxable
thing.  However, there's one left over:

   AllowanceCharge / TaxTotal

the cardinality of which is 0..1.  The definition of TaxTotal on
AllowanceCharge is "Describes the totals of Taxes applicable for this
Allowance or Charge", but I have to wonder whether this is correct.  Is
there only ever one applicable TaxTotal per AllowanceCharge?  (I'm
thinking in particular of Federal vs. State taxes in the U.S.)


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