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
