Jacques, I just wanted to let you know that I will be very interested in VAT after finishing miltary service and college! Keep up the spirit
Carl Sweden 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 > > > -- View this message in context: http://www.nabble.com/taxVatCode-tf3246357.html#a9144180 Sent from the OFBiz - Dev mailing list archive at Nabble.com.
