taxVatCode
Locked
 
Administrator
|
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 |
|
Administrator
|
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 |
|
Administrator
|
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 > > 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 |
|
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. 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. 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. --- Jacques Le Roux <[hidden email]> 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 > > |
|
|
In reply to this post by Jacques Le Roux
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. 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). 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 |
|
Administrator
|
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 > > 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 > |
|
Administrator
|
In reply to this post by cjhowe
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 <[hidden email]> 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 > > 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 > > 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 > > 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 > > > > |
|
|
In reply to this post by Jacques Le Roux
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
|
|
|
In reply to this post by Jacques Le Roux
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 <[hidden email]> 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 <[hidden email]> 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 > > > > > > > > |
|
Administrator
|
Hi Chris,
> 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. I use Outlook Express, not sure how to tune it for that. I was unable to migrate my sub-dirs filters (189 at this day) to another email clientso far, so I'm caught (I can't live without those filters) Jacques |
|
|
In reply to this post by Jacques Le Roux
Hi Jacques,
I'm sure the idea of storing the price ex vat has been around before and from memory leads only to problems, although pushing the number of decimals up does get around the obvious quantity multiplication and rounding issues. In fact a short spell searching the archives does provide several threads worth reading like : Users - VAT and rounding A few more comments in line: Jacques Le Roux wrote: > 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). > Let me ask this question for those currently working with net prices and adding sales tax, how do you manage a product that has different rates compared to what is held in the store under "Vat Tax Auth Geo Id" and "Vat Tax Auth Party Id"? From looking at the accounting "Tax Authorities" screens I would guess the intention was to use product categories to manage different rates, in which case I would suggest following the same pattern. I also notice that in the tax authorities there is already a field for "include tax in price". > 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 > > It would be worth turning on some of the Tax Authority settings to test the existing price including VAT features. I didn't come across it specifically but I remember one thread where David suggested it was being used by some people with a few customised areas like order summary, order processing etc. We may well find certain feature don't work but getting a list of those together would be a good start as well. Ray |
|
Administrator
|
Hi Ray,
Before all, thanks for your interest in this > Hi Jacques, > > I'm sure the idea of storing the price ex vat has been around before and > from memory leads only to problems, although pushing the number of > decimals up does get around the obvious quantity multiplication and > rounding issues. In fact a short spell searching the archives does > provide several threads worth reading like : Users - VAT and rounding I believe I know that pretty well. I opened an issue in Jira with all the links and infos I found some time ago https://issues.apache.org/jira/browse/OFBIZ-366 Nevertheless, nothing came from it for now. And I want to go ahead, carefully though. > A few more comments in line: > > Jacques Le Roux wrote: > > 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). > > > I don't see much sense in using the effectively deprecated Tax fields. > Let me ask this question for those currently working with net prices and > adding sales tax, how do you manage a product that has different rates > compared to what is held in the store under "Vat Tax Auth Geo Id" and > "Vat Tax Auth Party Id"? I guess as you suggested below they use "Product Rates" mixed with Categories (Tax Authority Product Categories). I can't see any other options. I can't see also why we keep this deprecated fields. I must acknowlede that at this stage I did not look deeply in related code... I prefer to avoid this step if possible and remain at business level as possible > >From looking at the accounting "Tax Authorities" screens I would guess > the intention was to use product categories to manage different rates, > in which case I would suggest following the same pattern. I also notice > that in the tax authorities there is already a field for "include tax in > price". Yes, that's what I meant above when speaking about "Product Rate" in a drop down . BTW I send a following message in this thread saying that I believe it's the only option. I believe they are no alternatives contrarily as what I wrote above (in my 1st msg). So yes I agree, using deprecated Tax fields is a dead end. > > 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 > > > > > It would be worth turning on some of the Tax Authority settings to test > the existing price including VAT features. I didn't come across it > specifically but I remember one thread where David suggested it was > being used by some people with a few customised areas like order > summary, order processing etc. We may well find certain feature don't > work but getting a list of those together would be a good start as well. From the top of my head this only intended for prices shown on sale or purchase part (eCommerce or Order Manager), not in catalog. That's only what I want to enhance : prices in catalog. To ease work of persons working always in gross prices (like some your retailers clients, if I remember well). Perhaps it's obvious ? Maybe there are better ways that the one I proposed ? Perhaps my propostion is not safe (but I can't see why) ? And yes I agree, this is also a part of the work (checking price including VAT features) ... Jacques > > Ray |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |