>From my ethnocentric POV, it's #2 for me :-) If I were interested and from my limited experience with VAT, the manner in which VAT people think about the pricing has a marketing component that the states don't have to consider.
When a VAT business is entering their pricing, they're thinking of appealing to their customers with round numbers (5.00) or subliminal numbers (4.99). The business is more concerned about those two numbers being presented to their customer correctly than they are about the tax that is being collected. Because of that, I think you really need to be storing the number they enter as a price type VAT_INCLUSIVE or something similar instead only thinking in VAT_EXCLUSIVE and treating it like the US tax system. --- Jacques Le Roux <[EMAIL PROTECTED]> wrote: > Hi, > > I waited some time and now, that after one week I got any responses > on the ML, I'm asking myself if it's because : > 1. I was unclear. > 2 . This is interesting nobody. > 3. Everybody is OK and just wait for a patch to come and review. > Please feel free to express yourself (even using a single number ;o) > > Thanks > > Jacques > > > > Of course I forgot to say that if we use this idea we shall have to > had some custom code to show prices with tax included to user > in > > backoffice (catalog/prodcut/prices screen at least). And the more I > thing about it the more I believe we shall use "Product Rates" > > in a drop down rather that having a new product attribute (adding > unneeded complexity) even if it seems less easy at first glance. > > > > We may encouter rounding issues but I guess pretty much has been > said/done about this already. > > > > Jacques > > > > > 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). > > > > > > 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 > >
