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
