Hi Ray, Before all, thanks for your interest in this
> 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 I believe I know that pretty well. I opened an issue in Jira with all the links and infos I found some time ago https://issues.apache.org/jira/browse/OFBIZ-366 Nevertheless, nothing came from it for now. And I want to go ahead, carefully though. > 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"? I guess as you suggested below they use "Product Rates" mixed with Categories (Tax Authority Product Categories). I can't see any other options. I can't see also why we keep this deprecated fields. I must acknowlede that at this stage I did not look deeply in related code... I prefer to avoid this step if possible and remain at business level as possible > >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". Yes, that's what I meant above when speaking about "Product Rate" in a drop down . BTW I send a following message in this thread saying that I believe it's the only option. I believe they are no alternatives contrarily as what I wrote above (in my 1st msg). So yes I agree, using deprecated Tax fields is a dead end. > > 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. >From the top of my head this only intended for prices shown on sale or purchase part (eCommerce or Order Manager), not in catalog. That's only what I want to enhance : prices in catalog. To ease work of persons working always in gross prices (like some your retailers clients, if I remember well). Perhaps it's obvious ? Maybe there are better ways that the one I proposed ? Perhaps my propostion is not safe (but I can't see why) ? And yes I agree, this is also a part of the work (checking price including VAT features) ... Jacques > > Ray
