Hi Jacques, I'm sure the idea of storing the price ex vat has been around before and from memory leads only to problems, although pushing the number of decimals up does get around the obvious quantity multiplication and rounding issues. In fact a short spell searching the archives does provide several threads worth reading like : Users - VAT and rounding
A few more comments in line: Jacques Le Roux wrote: > Hi, > > I'm finally considering a pragmatic solution for entering gross prices (tax > included, VAT included more precisely). In my mind and > the sequel I will assimilate tax as a VAT of a specific rate defined by > product. But I guess this is applicable for other similar > types of taxes. Actually a gross prices is composed of 2 parts : net prices > (without tax) and tax. At some point it may be annoying > to loose precision about them; but if we want to enter gross prices we have > to make some choices. And at the end, reconstructing the > gross prices from the 2 parts seems easy. If we keep enough information (ie > decimals) this might be manageable. As we use now Big > Decimal for prices this is not a problem (except in POS where I hope to > change that "soon") > > Before describing my proposition (very simple actually, because I can't see > any other means) I want to be sure that taxVatCode is > not used anymore (catalog/product screen). I can't see any use of it except > in ProductForms.xml and in > applications/product/entitydef/entitymodel.xml which are only declarations. > Anybody can confirm, please ? If it's not used anymore I > suppose that Tax Category Tax Vat Code and Tax Duty Code fields > are also not needed ? > > My proposition is to enhance the existing UI, to allow gross prices entering. > This behaviour will be a store property (prices tax > included or not). > > Actually this will be only at the UI level because we will keep net prices in > DB. So given a price tax included and a tax rate we > will calculate and store only net prices. By default the store has a tax rate > (pecentage) given by the "Vat Tax Auth Geo Id" and > "Vat Tax Auth Party Id" fields pair. As tax rates may depends on products we > have to create a specific mechanism and related field > in catalog/product screen. Either by suggesting defined "Tax Types" in "Tax > Autority" "Product Rate" in a drop down or simply by > entering a tax rate (percentage) in this field (it will then subsume - or > override in other words - the defautl store tax rate). In > such a case we will need to add a new attribute in Product entity to store > the eventual subsuming percentage. And we may suppress > (or recycle) related attributes and fields (ie Tax Category Tax Vat Code > and Tax Duty Code). > I don't see much sense in using the effectively deprecated Tax fields. Let me ask this question for those currently working with net prices and adding sales tax, how do you manage a product that has different rates compared to what is held in the store under "Vat Tax Auth Geo Id" and "Vat Tax Auth Party Id"? >From looking at the accounting "Tax Authorities" screens I would guess the intention was to use product categories to manage different rates, in which case I would suggest following the same pattern. I also notice that in the tax authorities there is already a field for "include tax in price". > We shall keep at least 5 decimals for the net price, perhaps even more, what > do you think ? This seems so simple, that I'm surely > forgetting something :o) > > Anyway, we have to go further if we want to facilitate OFBiz acceptation in, > at least, Europe. > > Jacques > > It would be worth turning on some of the Tax Authority settings to test the existing price including VAT features. I didn't come across it specifically but I remember one thread where David suggested it was being used by some people with a few customised areas like order summary, order processing etc. We may well find certain feature don't work but getting a list of those together would be a good start as well. Ray
