After thinking about it again, I'm incorrect. To accomplish the same marketing centric pricing, VAT locales would simply have more locale specific entries.
side note: on the std response, is it possible for your mail client not to send a reply-to field in the headers when replying to mailing lists? I'll try to keep a better eye on my replies, but that would be the root cause. --- Jacques Le Roux <[EMAIL PROTECTED]> wrote: > Chris, > > Sorry I send you 2 messages personnaly that were intended to ML, but > using std reponse button in OE did that. > > > >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. > > I understand your POV (or perhaps not ?), but please consider that in > EU, and for instance for retail in France prices but be shown VAT > included to clients. So retail people tend to use (euphemism for use) > gross prices only. The principal reason is that VAT is only paid by > final customers. So it's something that pass thru accounting and has > no > interest for business in itself. > > > 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. > > OK, finally we are on the same page... I keep my previous comment for > illustration purpose. > > > 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. > > I can't see why. Why do you recommend that ? Could you elaborate > please > ? IMHO, this (2 types of prices) will complicate all things without > bringging any "added value" ;o) Because the system does not need to > know about gross prices, only ERP users and front end customers need. > > Jacques > > > --- 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 > > > > > > > >
