Proposal talk:Tax free shopping

From OpenStreetMap Wiki
Jump to navigation Jump to search

Definitions need tweaking

The definitions, as currently worded, are too precise and allow too many "loopholes". For example, duty_free=yes being defined as "This shop does not collect taxes at all" does not cover the case where a shop collects taxes sometimes, depending on the circumstances. This is the case in many airports where international and domestic passengers mix and both are allowed to use the shop, possibly for different prices. My suggested definition is: "A retail outlet permitted to sell goods without duty or taxes for immediate export by individual travellers."

Duty_free=refund indicates that the shop will provide the documents required to obtain an expeditious refund of the duty and taxes paid, at or close to the point of export. In some countries (e.g. UK), such a refund can be obtained on a purchase from any shop, so there is no need for a tag. In other countries, there are schemes which retailers may participate in (e.g. NL). Conceptually there could be multiple such schemes within a country, so I suggest that a way of indicating the scheme(s) in which a store participates would be a good addition.

It should be mentioned that "duty" and "taxes" are different concepts, but they are used interchangeably in this context, which seems fair enough to me, unless anyone knows of a case where one is payable and the other not, within the scope of this discussion. --Csmale (talk) 20:54, 4 January 2020 (UTC)

Thanks for the definition on "duty_free=yes", I changed it on the proposal page.
Regarding duty_free=refund: It would be interesting to know that "schemes" there are. Currently I know three:
1. There is this refund you get with this extra receipt but not all shops support this.
2. Like 1. but all shops support this (like in the UK). Because all shops support this, I don't think there needs to be a tag here. I simply wouln't tag this at all as it doesn't vary between shops.
3. Different prices for different customers (international and domestic customer mix). I would change the definition of "duty_free=yes" by saying that these shops are permitted to sell goods without duty "only to international customers". This would cover these "mixed-customers shops" but also pure airport-like duty-free shops where only international customers can buy things (without paying duty).
I didn't know that there is a significant difference between tax and duty (in Germany we only have one word for this). As far as I just read (maybe a bit over-generalized): Tax is charged on individuals and may depend on the income and duty is charged on goods? However, I will add "duty" in the page. --Hauke-stieler (talk) 21:29, 4 January 2020 (UTC)
Please don't use "international" in this context as it is misleading. It is not about going from one country to another, but from one customs jurisdiction to another. Even within one country there can be multiple customs jurisdictions; check out for some interesting cases.
Regarding the refund schemes, I think we are talking about different concepts here. The schemes I am referring to, have some kind of branding and membership, from both the consumer side as from the retailers side. I have already found three in that operate in Europe: Global Blue, Easy Tax Free, and Planet Payment. A shop may or may not have the forms for the scheme you are a member of. Knowing which shops participate in a particular scheme, or knowing which schemes are available in a given shop, could influence your shopping activities.
In German I believe the word for "customs duty" is "Zollgebühr" (payable on import/export), with "Verbrauchsteuer" meaning "excise duty" on specific things like alcohol and tobacco, and a plain tax (such as MWSt) would be a "Steuer." In this context I think "duty-free" would imply that none of these are levied. Would that make sense? --Csmale (talk) 22:10, 4 January 2020 (UTC)
What would you suggest instead of "international"? Maybe calling them "foreign" customers (with a description that it means "foreign to the customs jurisdiction")? Phrases like "customers exporting good to a different customs jurisdiction" is so unwieldy.
Regarding refund: Now I understand what you mean, but never heared of these organisations. But it reminds be of the payment tagging-scheme. Maybe "duty_free:global_blue=yes|no" and similar would work? When using this, then "duty_free:refund=yes|no" may be the general tag (used when the organisation is unknown or there's no involved)?
I'm not that much into the exact political-structures here but I would also assume that "duty-free" in Germany means that none of them are levied.
I suggest either leaving it out entirely (so simply "passengers") or using a neutral phrase like "qualifying passengers" would be best. They are correct, and nobody can say they are wrong. Outside of the strict definition, maybe as a footnote within the section, you can give more precision of what is meant: (exiting the customs jurisdiction).
Note that none of this has anything to do with the passenger, but it is about moving the goods from A to B. Talking about "foreign" passengers would invoke thoughts of nationality and residency, neither of which are actually relevant here.
For the refund schemes, I would *guess* that mainly large stores would be members, and that they would typically be members of multiple schemes. The number of such schemes is finite, very low, and pretty static. That would suggest something like duty_free:refund:global_blue=yes would be fine. If the list of schemes would be long and/or very dynamic, then it might be better to treat them as "names" like in "duty_free:refund=Global Blue", allowing multiple values separated by semicolons as usual.
--Csmale (talk) 12:18 5 January 2020 (UTC)
You may say that "qualifying passagers" are usually international passengers.
But you've interesting edge cases, taxes on rum for French people depending if they live on some "ultramarine" islands or not. So you have taxes boundaries inside France. For instance coming in Réunion [1], it depends if you're arriving from mainland France or any other EU country on one side or from the rest of the world on the other side, see [2] for details. For the other direction, you have similar rules. --Nospam2005 (talk) 15:53, 9 February 2020 (UTC)

Proposal: "Shops offering none of those services"

I found the term "Shops offering none of those services" a little confusing. At first I took that as "Shops that don't do tax-free" and had to read the reference to understand. Perhaps it should be "Shops that accept a customer's own customs documents" or similar. Jnicho02 (talk) 09:20, 29 January 2020 (UTC)

Thanks for the hint, I added this to the sentence. --Hauke-stieler (talk) 11:29, 1 February 2020 (UTC)

Avoid over-namespacing and prefix-fooling of keys

The whole section with key "duty_free:refund:*" ends stating "There are probably a lot more companies but this list can easily be extended in the future.". No, keys are a hell of a lot more less easy to extend as compared to values. I'd suggest to revamp the proposal by putting all those "false key-fragments" to the place where they belong: to the values, ;-separated, of one single key "duty_free:refund = general_assistance | global_blue | premier_tax_free | gb_tax_free | easy_tax_free | planet_payment | ...". For a discussion of this over-namespacing and prefix-fooling of keys see e.g. . --Geonick (talk) 22:04, 9 February 2020 (UTC)

Thanks for the feedback.
Fist to the extension of keys: Extending keys is easier in so far as error detection of unknown keys is easier (s. below regarding parsing) and mapper therefore (hopefully) make less mistakes. Furthermore I don't see any difference in adding documentation for a key "duty_free:refund:foobar" or for a value "foobar".
To the generall idea of using lists instead of keys: I personally don't like comma or semicolon separated lists at all. I don't want to go into detail here (as there is the general dicussion you mentioned) but IMO the main downside of comma/semicolon separated lists is: Everybody (humans and computers) have to parse the value in order to get the information what company is supported. Also humans tend to make mistakes that are usually not detected by editors, because they have to parse the value list etc. General I don't think we can say "false" or "where they belong" or so, as there does not exist any pure right and wrong.
Looking at the payment-keys, the strategy of using namespaces with "yes"/"no" instead of lists of values works very well IMO. --Hauke-stieler (talk) 22:41, 9 February 2020 (UTC)