You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Raj Saini <ra...@gmail.com> on 2011/03/18 07:21:22 UTC
Display VAT on checkout pages
Hi,
I am working a e-commerce application and using new VAT implementation.
I have a problem showing the VAT adjustment as TAX on cart/checkout
pages. ShoppingCart#getTotalSalesTax and in turn
OrderReadHelper#getOrderTaxByTaxAuthGeoAndParty always returns zero as
it does not consider the OrderAdjusment of VAT_TAX type.
I am working on enhancements and trying to find the best way so that it
is generic and my work could be contributed back to the community.
My question is should we add other method in ShippingCart and
OrderReadHelper classes for VAT or enhance the existing methods to
include the OrderAdjustments of VAT_TAX type.
Thanks,
Raj
Re: Display VAT on checkout pages
Posted by Paul Foxworthy <pa...@cohsoft.com.au>.
Bonjour Jacques,
Yes, I agree it's unlikely. I only mentioned it as a thought experiment to
clarify our thoughts on what the method should return.
Cheers
Paul Foxworthy
Jacques Le Roux wrote:
>
> I don't think there are currently any countries in the world where you
> have Sale and Vat tax simultaneously. Of course, this could
> happens but I doubt. Anyway counting them both makes sense, even if it's
> maybe a shoot in the dark.
>
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Display-VAT-on-checkout-pages-tp3386374p3395508.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: Display VAT on checkout pages
Posted by Jacques Le Roux <ja...@les7arts.com>.
It seems nobody wants to add anything, so at this stage I'd say, yes
Jacques
From: "Raj Saini" <ra...@gmail.com>
>I agree it is better to enhance the existing method.
>
> Should I create a JIRA issue for further discussion?
>
> Thanks,
>
> Raj
>
> On Sunday 20 March 2011 06:05 PM, Jacques Le Roux wrote:
>> Though I did not look into code yet, I agree with Paul,
>> I don't think there are currently any countries in the world where you
>> have Sale and Vat tax simultaneously. Of course, this could happens
>> but I doubt. Anyway counting them both makes sense, even if it's maybe
>> a shoot in the dark.
>>
>> I totally agree on the purchase difference for VAT_TAX vs SALES_TAX.
>> I'm not quite sure how is calculated VAT on discount so I have added a
>> small explanation at
>> https://cwiki.apache.org/confluence/display/OFBIZ/VAT#VAT-Discountsappliedperline
>>
>> My 2 cts
>>
>> Jacques
>>
>> From: "Paul Foxworthy" <pa...@cohsoft.com.au>
>>> Hi Raj,
>>>
>>> I vote for enhancing the existing methods.
>>>
>>> If we think of the methods getTotalSalesTax and
>>> getOrderTaxByTaxAuthGeoAndParty as "what tax was collected as part of
>>> the
>>> sale that must be paid to a tax authority?" then those methods should
>>> look
>>> for VAT/GST as well as sales tax.
>>>
>>> Maybe there is some place in the world that has both a sales tax and a
>>> VAT/GST. If there was such a place, would you want these methods to
>>> count
>>> both taxes or not? I think the answer is yes, you would want both
>>> counted.
>>>
>>> To me, the tax types SALES_TAX and VAT_TAX are almost the same thing
>>> *for a
>>> sale*. In both cases, we're collecting tax which is a liability that
>>> must be
>>> paid to a tax authority.
>>>
>>> The major difference between a VAT/GST tax and a sales tax is we also
>>> record
>>> the VAT tax we paid on *purchases*, and that affects the overall
>>> liability
>>> at the time we must pay the tax authority. There's no sales tax on
>>> purchases.
>>>
>>> If you grep for SALES_TAX in the Ofbiz code, there are several instances
>>> where there's no mention of VAT_TAX, and yet the business rule should
>>> probably apply to both. I have been intending to do a thorough study
>>> of all
>>> these instances when I get some time. I believe most of them should
>>> change
>>> to "taxtype == SALES_TAX OR taxtype == VAT_TAX". It seems to me you're
>>> looking at several of those instances right now.
>>>
>>> When we summarise tax at the bottom of an order, I think the most
>>> interesting thing to show is total tax of whatever type, and the
>>> getTotalSalesTax method should do that job. The method getTotalSalesTax
>>> could possibly have a more general name, but I don't think that's really
>>> important.
>>>
>>> So as I said, I think it would be better to modify the methods. For
>>> existing
>>> Ofbiz installations that only define tax authorities that collect a
>>> sales
>>> tax, this change will not break anything at all.
>>>
>>> Cheers
>>>
>>> Paul Foxworthy
>>>
>>>
>>> rajsaini wrote:
>>>>
>>>> Hi,
>>>>
>>>> I am working a e-commerce application and using new VAT implementation.
>>>> I have a problem showing the VAT adjustment as TAX on cart/checkout
>>>> pages. ShoppingCart#getTotalSalesTax and in turn
>>>> OrderReadHelper#getOrderTaxByTaxAuthGeoAndParty always returns zero as
>>>> it does not consider the OrderAdjusment of VAT_TAX type.
>>>>
>>>> I am working on enhancements and trying to find the best way so that it
>>>> is generic and my work could be contributed back to the community.
>>>>
>>>> My question is should we add other method in ShippingCart and
>>>> OrderReadHelper classes for VAT or enhance the existing methods to
>>>> include the OrderAdjustments of VAT_TAX type.
>>>>
>>>> Thanks,
>>>>
>>>> Raj
>>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://ofbiz.135035.n4.nabble.com/Display-VAT-on-checkout-pages-tp3386374p3390807.html
>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>
>>
>>
>>
>
Re: Display VAT on checkout pages
Posted by Raj Saini <ra...@gmail.com>.
I agree it is better to enhance the existing method.
Should I create a JIRA issue for further discussion?
Thanks,
Raj
On Sunday 20 March 2011 06:05 PM, Jacques Le Roux wrote:
> Though I did not look into code yet, I agree with Paul,
> I don't think there are currently any countries in the world where you
> have Sale and Vat tax simultaneously. Of course, this could happens
> but I doubt. Anyway counting them both makes sense, even if it's maybe
> a shoot in the dark.
>
> I totally agree on the purchase difference for VAT_TAX vs SALES_TAX.
> I'm not quite sure how is calculated VAT on discount so I have added a
> small explanation at
> https://cwiki.apache.org/confluence/display/OFBIZ/VAT#VAT-Discountsappliedperline
>
> My 2 cts
>
> Jacques
>
> From: "Paul Foxworthy" <pa...@cohsoft.com.au>
>> Hi Raj,
>>
>> I vote for enhancing the existing methods.
>>
>> If we think of the methods getTotalSalesTax and
>> getOrderTaxByTaxAuthGeoAndParty as "what tax was collected as part of
>> the
>> sale that must be paid to a tax authority?" then those methods should
>> look
>> for VAT/GST as well as sales tax.
>>
>> Maybe there is some place in the world that has both a sales tax and a
>> VAT/GST. If there was such a place, would you want these methods to
>> count
>> both taxes or not? I think the answer is yes, you would want both
>> counted.
>>
>> To me, the tax types SALES_TAX and VAT_TAX are almost the same thing
>> *for a
>> sale*. In both cases, we're collecting tax which is a liability that
>> must be
>> paid to a tax authority.
>>
>> The major difference between a VAT/GST tax and a sales tax is we also
>> record
>> the VAT tax we paid on *purchases*, and that affects the overall
>> liability
>> at the time we must pay the tax authority. There's no sales tax on
>> purchases.
>>
>> If you grep for SALES_TAX in the Ofbiz code, there are several instances
>> where there's no mention of VAT_TAX, and yet the business rule should
>> probably apply to both. I have been intending to do a thorough study
>> of all
>> these instances when I get some time. I believe most of them should
>> change
>> to "taxtype == SALES_TAX OR taxtype == VAT_TAX". It seems to me you're
>> looking at several of those instances right now.
>>
>> When we summarise tax at the bottom of an order, I think the most
>> interesting thing to show is total tax of whatever type, and the
>> getTotalSalesTax method should do that job. The method getTotalSalesTax
>> could possibly have a more general name, but I don't think that's really
>> important.
>>
>> So as I said, I think it would be better to modify the methods. For
>> existing
>> Ofbiz installations that only define tax authorities that collect a
>> sales
>> tax, this change will not break anything at all.
>>
>> Cheers
>>
>> Paul Foxworthy
>>
>>
>> rajsaini wrote:
>>>
>>> Hi,
>>>
>>> I am working a e-commerce application and using new VAT implementation.
>>> I have a problem showing the VAT adjustment as TAX on cart/checkout
>>> pages. ShoppingCart#getTotalSalesTax and in turn
>>> OrderReadHelper#getOrderTaxByTaxAuthGeoAndParty always returns zero as
>>> it does not consider the OrderAdjusment of VAT_TAX type.
>>>
>>> I am working on enhancements and trying to find the best way so that it
>>> is generic and my work could be contributed back to the community.
>>>
>>> My question is should we add other method in ShippingCart and
>>> OrderReadHelper classes for VAT or enhance the existing methods to
>>> include the OrderAdjustments of VAT_TAX type.
>>>
>>> Thanks,
>>>
>>> Raj
>>>
>>
>>
>> --
>> View this message in context:
>> http://ofbiz.135035.n4.nabble.com/Display-VAT-on-checkout-pages-tp3386374p3390807.html
>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>
>
>
>
Re: Display VAT on checkout pages
Posted by Jacques Le Roux <ja...@les7arts.com>.
Though I did not look into code yet, I agree with Paul,
I don't think there are currently any countries in the world where you have Sale and Vat tax simultaneously. Of course, this could
happens but I doubt. Anyway counting them both makes sense, even if it's maybe a shoot in the dark.
I totally agree on the purchase difference for VAT_TAX vs SALES_TAX. I'm not quite sure how is calculated VAT on discount so I have
added a small explanation at https://cwiki.apache.org/confluence/display/OFBIZ/VAT#VAT-Discountsappliedperline
My 2 cts
Jacques
From: "Paul Foxworthy" <pa...@cohsoft.com.au>
> Hi Raj,
>
> I vote for enhancing the existing methods.
>
> If we think of the methods getTotalSalesTax and
> getOrderTaxByTaxAuthGeoAndParty as "what tax was collected as part of the
> sale that must be paid to a tax authority?" then those methods should look
> for VAT/GST as well as sales tax.
>
> Maybe there is some place in the world that has both a sales tax and a
> VAT/GST. If there was such a place, would you want these methods to count
> both taxes or not? I think the answer is yes, you would want both counted.
>
> To me, the tax types SALES_TAX and VAT_TAX are almost the same thing *for a
> sale*. In both cases, we're collecting tax which is a liability that must be
> paid to a tax authority.
>
> The major difference between a VAT/GST tax and a sales tax is we also record
> the VAT tax we paid on *purchases*, and that affects the overall liability
> at the time we must pay the tax authority. There's no sales tax on
> purchases.
>
> If you grep for SALES_TAX in the Ofbiz code, there are several instances
> where there's no mention of VAT_TAX, and yet the business rule should
> probably apply to both. I have been intending to do a thorough study of all
> these instances when I get some time. I believe most of them should change
> to "taxtype == SALES_TAX OR taxtype == VAT_TAX". It seems to me you're
> looking at several of those instances right now.
>
> When we summarise tax at the bottom of an order, I think the most
> interesting thing to show is total tax of whatever type, and the
> getTotalSalesTax method should do that job. The method getTotalSalesTax
> could possibly have a more general name, but I don't think that's really
> important.
>
> So as I said, I think it would be better to modify the methods. For existing
> Ofbiz installations that only define tax authorities that collect a sales
> tax, this change will not break anything at all.
>
> Cheers
>
> Paul Foxworthy
>
>
> rajsaini wrote:
>>
>> Hi,
>>
>> I am working a e-commerce application and using new VAT implementation.
>> I have a problem showing the VAT adjustment as TAX on cart/checkout
>> pages. ShoppingCart#getTotalSalesTax and in turn
>> OrderReadHelper#getOrderTaxByTaxAuthGeoAndParty always returns zero as
>> it does not consider the OrderAdjusment of VAT_TAX type.
>>
>> I am working on enhancements and trying to find the best way so that it
>> is generic and my work could be contributed back to the community.
>>
>> My question is should we add other method in ShippingCart and
>> OrderReadHelper classes for VAT or enhance the existing methods to
>> include the OrderAdjustments of VAT_TAX type.
>>
>> Thanks,
>>
>> Raj
>>
>
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Display-VAT-on-checkout-pages-tp3386374p3390807.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>
Re: Display VAT on checkout pages
Posted by Paul Foxworthy <pa...@cohsoft.com.au>.
Hi Raj,
I vote for enhancing the existing methods.
If we think of the methods getTotalSalesTax and
getOrderTaxByTaxAuthGeoAndParty as "what tax was collected as part of the
sale that must be paid to a tax authority?" then those methods should look
for VAT/GST as well as sales tax.
Maybe there is some place in the world that has both a sales tax and a
VAT/GST. If there was such a place, would you want these methods to count
both taxes or not? I think the answer is yes, you would want both counted.
To me, the tax types SALES_TAX and VAT_TAX are almost the same thing *for a
sale*. In both cases, we're collecting tax which is a liability that must be
paid to a tax authority.
The major difference between a VAT/GST tax and a sales tax is we also record
the VAT tax we paid on *purchases*, and that affects the overall liability
at the time we must pay the tax authority. There's no sales tax on
purchases.
If you grep for SALES_TAX in the Ofbiz code, there are several instances
where there's no mention of VAT_TAX, and yet the business rule should
probably apply to both. I have been intending to do a thorough study of all
these instances when I get some time. I believe most of them should change
to "taxtype == SALES_TAX OR taxtype == VAT_TAX". It seems to me you're
looking at several of those instances right now.
When we summarise tax at the bottom of an order, I think the most
interesting thing to show is total tax of whatever type, and the
getTotalSalesTax method should do that job. The method getTotalSalesTax
could possibly have a more general name, but I don't think that's really
important.
So as I said, I think it would be better to modify the methods. For existing
Ofbiz installations that only define tax authorities that collect a sales
tax, this change will not break anything at all.
Cheers
Paul Foxworthy
rajsaini wrote:
>
> Hi,
>
> I am working a e-commerce application and using new VAT implementation.
> I have a problem showing the VAT adjustment as TAX on cart/checkout
> pages. ShoppingCart#getTotalSalesTax and in turn
> OrderReadHelper#getOrderTaxByTaxAuthGeoAndParty always returns zero as
> it does not consider the OrderAdjusment of VAT_TAX type.
>
> I am working on enhancements and trying to find the best way so that it
> is generic and my work could be contributed back to the community.
>
> My question is should we add other method in ShippingCart and
> OrderReadHelper classes for VAT or enhance the existing methods to
> include the OrderAdjustments of VAT_TAX type.
>
> Thanks,
>
> Raj
>
--
View this message in context: http://ofbiz.135035.n4.nabble.com/Display-VAT-on-checkout-pages-tp3386374p3390807.html
Sent from the OFBiz - User mailing list archive at Nabble.com.