Jacopo, > Jacques, > > this is just a minor comment to your post (sorry but I have no time at > the moment to study your proposal), just to clarify one little thing: > vat support has nothing to do with showing prices with vat included. > I mean that you could also want to show prices with tax included even if > the tax is not vat.
Yes I agree. It's just that I'm more concerned with VAT issues. > By the way, in all the ERP systems that I'm aware of, that support vat > tax, prices are entered into the system without tax (so I agree with > what you suggest here). Yes, gross prices entered in the system is a nonsense I guess. Jacques > Just my two cents > > Jacopo > > > Jacques Le Roux 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 >
