Community mailing list archives

Re: Prices incl VAT in ecommerce and POS

Eva Pinter
- 12/12/2014 07:37:46
For the POS sales, the most important is in Europe the price including VAT. The shops are used to set prices (incl.) the way they want and to have the VAT calculated and rounded afterwards. The situation is different in Canada for instance, where you always announce the prices excl. sales tax and you add the sales tax to the total amount.

Therefore, you need to be able to have both options: one price including VAT and one price excluding sales tax.

good luck
Eva P.

Check out our training videos

On 12 Dec 2014, at 12:26, Wolfgang Taferner <> wrote:

>The problem with that approach is that sometimes you can NOT set a price of 

>99.99 for example. Shop owners need to be able to choose the exact displayed 

>retail price.

Jep, but based on this you need to handle both approaches (included/excluded) very consistently and correct which is not the case and I guess this is the reason why it is discussed at all.

For example if you use tax included prices you must use the account round per line and it is impossible to use the round globally option although you would need it for tax excluded invoice lines.

So, the software created a paradoxon for the user b/c either way, it is not possible to use both approaches at the same time for different apps and business use cases. It is most likely only one cent difference but one cent means a not balanced move which cannot be posted b/c of rounding problems and wrongly computed tax lines.

It is very important to either remove/drop one computation approach (included) or make it work for both computations all over.

I think it would be easier and less error-prone to remove the tax included computation and help the user to put the retail prices based on net easily. The new on change convenience and tools should easily help to introduce a field on every model where it is needed to show the computed tax included price.

Who was first? The chicken or the egg? I guess we will go crazy to always fix two ways of computation (which could eventually be done at some point but will never stop challenging) when the nature of the computation and the rounding on each end do not allow to retrieve a single unique result on more difficult use cases…

I would love to have consistency about this issue in the core and not in the configuration and/or the customization…

Or am I completely wrong about my opinion how to solve this problem?

Post to: