Include taxes in values.

[birdsarah]

From JoseLMarin on v0.3.2

I'd suggest to consider key(s) to inform users if taxes are included or not in the amount. If taxes are included, the tax rate applied to the amount is also important to work with aggregated data.

[myroslav]

In our case we need a flag for VAT since it is the tax that prices sometimes include it and sometimes are specified without it.

Will something like boolean Tender.totalValue.includedVAT extension work? Is there expectation that some array is necessary, i.e. Tender.totalValue.includedTaxes = ["VAT"]? Is there sense in negating the field: Tender.totalValue.excludedTaxes = [] - that would mean that all texes are included in price by default and only when there is exclusion property, the tax will be considered excluded?

[practicalparticipation]

Schema.org have a valueAddedTaxIncluded boolean property in their PriceSpecification class. However, I think the model proposed above of noting includedTaxes is preferable and more extensible.

Although this may turn out to not be expressive enough, as we may also need to have an explicit inclusion of the VAT rate that applies, and, as you note, systems may vary in whether the price they generate includes or excludes tax.

This does need more investigation of existing data: perhaps we can collect some examples here, and then consider whether a concrete proposal for extending value can be made by the early next week, or whether we do leave this as currently tagged for being an extension.

[jpmckinney]

Unless we have use cases for other taxes than VAT, I think it may be better to stick to the proven use case of valueAddedTaxIncluded.

[AlCollier]

@jpmckinney It may be worth thinking about irrecoverable VAT. In most cases the contracting authority can reclaim the VAT so it is logical for it to quote the price paid as excluding VAT. The VAT goes to the supplier who passes it on to the tax authority - so the ex-VAT amount is also the amount by which the supplier benefits.

In the case of irrecoverable VAT, however, the contracting authority cannot recover the VAT, so the effective cost to the authority goes up. A user interested in, say, the payback period of the project would want to see the figure including irrecoverable VAT.

However another user, interested in how much a particular contractor is making from government contracts, would be interested in the ex-VAT amount. A VAT-inclusive amount without an indication of the VAT rate would also be of no benefit in this use-case - and the rate of VAT can vary hugely, from nil to >20%.

So, in summary, valueAddedTaxIncluded might be a bit simplistic.

As to use cases for other taxes, surely there are many other indirect taxes which might be included? In the UK, for example, we have landfill tax.

[timgdavies]

@myroslav What have you done for handling tax in the open procurement API in the end?

[myroslav]

We'd need only VAT, thus added valueAddedTaxIncluded boolean property. See
http://api-docs.openprocurement.org/en/latest/standard/util.html#value

Unfortunately this does not cover all cases, and we are unclear of
potential changes here. Options discussed are:

• Collecting two different values, one brutto and the other - netto. And only one in cases, when tax does not apply.
• Calculation of only one of the values brutto/netto, and dropping the tax indicator altogether.

This is all because we need to compare apples to apples and oranges to
oranges, but this is not always simple, since we have multiple taxation
schemes and tender participants should have equal rights, as well as
procuringEntity should not be paying more because of these differences.

[timgdavies]

Moving in comment from @myroslav in #219:

"There is possibility to have Tender to be conducted without VAT and to have contract value with VAT. Any analytics regarding these values (matching them) becomes quite complex.

A possible solution is to have multiple Values in contract (i.e. without VAT and with VAT). Is there more elegant solution?"

[timgdavies]

The next task here is to carry out more in-depth research into how taxes are modelled in any existing data.

[timgdavies]

Continued in #383