You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2007/02/17 22:56:02 UTC
taxVatCode
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
Re: taxVatCode
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
Re: taxVatCode
Posted by Ray Barlow <ra...@makeyour-point.com>.
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).
>
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"?
>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
Re: taxVatCode
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
>
Re: taxVatCode
Posted by Jacopo Cappellato <ti...@sastau.it>.
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
Re: [1/2] taxVatCode
Posted by carlj <ma...@carl-johansson.com>.
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.
Re: taxVatCode
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
Re: taxVatCode
Posted by Chris Howe <cj...@yahoo.com>.
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 <ja...@les7arts.com> 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 <ja...@les7arts.com> 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
> > >
> > >
>
>
Re: taxVatCode
Posted by Jacques Le Roux <ja...@les7arts.com>.
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 <ja...@les7arts.com> 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
> >
> >
Re: taxVatCode
Posted by Chris Howe <cj...@yahoo.com>.
>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 <ja...@les7arts.com> 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
>
>
Re: taxVatCode
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
Re: taxVatCode
Posted by Jacques Le Roux <ja...@les7arts.com>.
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