More detail on r1449615 please

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

More detail on r1449615 please

Paul Foxworthy
Hans,

I am not clear on the need for r1449615 (https://fisheye6.atlassian.com/changelog/ofbiz?cs=1449615).

The commit adds an option calcTaxAfterPromotion to the ProductStore. I assume the idea is that tax could be calculated either before or after a promotional adjustments to a price. But, we already have the capability in TaxAuthorityRateProduct to say that tax should be applied to promotional adjustments. Would that achieve the same goal? Is there another reason for the change I have missed?

I do not understand why the new behaviour only happens when the quantity ordered is one. Can you explain please?

Was there a Jira for this change?

Thanks

Paul Foxworthy
--
Coherent Software Australia Pty Ltd
http://www.coherentsoftware.com.au/

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
Reply | Threaded
Open this post in threaded view
|

Re: More detail on r1449615 please

Paul Foxworthy
One more...

Is the ProductStore the right place for the new option? Could it be viewed as a compliance matter required by a TaxAuthority? In other words, should the option be defined in TaxAuthorityRateProduct, and not the ProductStore?

Thanks

Paul Foxworthy

Paul Foxworthy wrote
Hans,

I am not clear on the need for r1449615 (https://fisheye6.atlassian.com/changelog/ofbiz?cs=1449615).

The commit adds an option calcTaxAfterPromotion to the ProductStore. I assume the idea is that tax could be calculated either before or after a promotional adjustments to a price. But, we already have the capability in TaxAuthorityRateProduct to say that tax should be applied to promotional adjustments. Would that achieve the same goal? Is there another reason for the change I have missed?

I do not understand why the new behaviour only happens when the quantity ordered is one. Can you explain please?

Was there a Jira for this change?

Thanks

Paul Foxworthy
--
Coherent Software Australia Pty Ltd
http://www.coherentsoftware.com.au/

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/
Reply | Threaded
Open this post in threaded view
|

Re: More detail on r1449615 please

Scott Gray-2
+1, I'd also like to hear more about the motivations behind this change.

Thanks
Scott

On 19/03/2013, at 2:13 AM, Paul Foxworthy wrote:

> One more...
>
> Is the ProductStore the right place for the new option? Could it be viewed
> as a compliance matter required by a TaxAuthority? In other words, should
> the option be defined in TaxAuthorityRateProduct, and not the ProductStore?
>
> Thanks
>
> Paul Foxworthy
>
>
> Paul Foxworthy wrote
>> Hans,
>>
>> I am not clear on the need for r1449615
>> (https://fisheye6.atlassian.com/changelog/ofbiz?cs=1449615).
>>
>> The commit adds an option calcTaxAfterPromotion to the ProductStore. I
>> assume the idea is that tax could be calculated either before or after a
>> promotional adjustments to a price. But, we already have the capability in
>> TaxAuthorityRateProduct to say that tax should be applied to promotional
>> adjustments. Would that achieve the same goal? Is there another reason for
>> the change I have missed?
>>
>> I do not understand why the new behaviour only happens when the quantity
>> ordered is one. Can you explain please?
>>
>> Was there a Jira for this change?
>>
>> Thanks
>>
>> Paul Foxworthy
>
>
>
>
>
> -----
> --
> Coherent Software Australia Pty Ltd
> http://www.coherentsoftware.com.au/
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/More-detail-on-r1449615-please-tp4639907p4639908.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: More detail on r1449615 please

Saroj Khamlue
This post was updated on .
In reply to this post by Paul Foxworthy
Hello Paul Foxworthy,

I'm Tom, I'm working at Antwebsystems (Hans's company).

I did the change on r1449615. the detail is If you set a tax rule to tax on items that cost more than $100 for some regional tax authority and then configure a promo that lowers the price of that product below $100 then the item is still charged tax.

For example :
The tax rule is 10% (if min item price is 100$) and the promotion is -20%. If we buy 1 item price 100$, total is 80$ and tax will be 10$. We don't want to charge tax on this case but if we buy more than 1 item that's fine to charge tax on the final amount.

This case will happen only when we buy only one item if item amount(with discount) less than item price.

Please look at calcTaxAfterPromotion.diff that make the same result with r1449615 and let me know what do you think or any suggestions.

Regards
Saroj Khamlue
Reply | Threaded
Open this post in threaded view
|

Re: More detail on r1449615 please

Paul Foxworthy
Hi Tom,

Thanks for your reply.

OK, I see the problem. Some taxes cut in at a minimum item or purchase price. A promotional adjustment can lower the price the customer is paying, so they should not have to pay any tax. However, the tax is being calculated on the base price, before any promotional adjustment.

I think your original change was a partial fix, but only when the order quantity is one. In the more complex situation where the quantity is greater than one, at present the tax calculation does not have the information it needs. All it has is the base unit price for the item ("itemPrice"), and the total amount for the item ("itemAmount", which is itemPrice * quantity - adjustments).

Your new patch breaks when the quantity is greater than one, so r1449615 should stay for now. However, it is limited and not a complete fix.

Here's what I think needs to happen.

1. We need to define two categories of item adjustments:

- those which modify the price, including promotional pricing and discounts
- adjustments for additional services such as shipping, an extended warranty and so on.

The first category should be combined with the product price before tax calculations are done. The second category may need to be taxed separately.

2. An additional list of data needs to be supplied to the tax calculation, a list of adjusted unit prices with promotional discounts and any other adjustments in the first category above. The tax calculation would, of course, use the adjusted unit price, so the change at https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java?hb=true#to215
won't be needed any more.

If we do these, there would be no need for the calcTaxAfterPromotion attribute. In effect, it would always apply, for adjustments in category 1. If anyone didn't want that behaviour, all they would need to do is define an adjustment in category 2, not 1.

I have created a new Jira issue at https://issues.apache.org/jira/browse/OFBIZ-5163. I would like comments from everyone before we start work on any changes.

Tom, I believe you found a real problem in OFBiz, thank you for your efforts. In future, please create a Jira issue so we can see proposed changes before they are committed, not after.

Cheers

Paul Foxworthy

Saroj Khamlue wrote
Hello Paul Foxworthy,

I'm Tom, I'm working at Antwebsystems (Hans's company).

I did the change on r1449615. the detail is If you set a tax rule to tax on items that cost more than $100 for some regional tax authority and then configure a promo that lowers the price of that product below $100 then the item is still charged tax.

For example :
The tax rule is 10% (if min item price is 100$) and the promotion is -20%. If we buy 1 item price 100$, total is 80$ and tax will be 10$. We don't want to charge tax on this case but if we buy more than 1 item that's fine to charge tax on the final amount.

This case will happen only when we buy only one item if item amount(with discount) less than item price.

Please look at calcTaxAfterPromotion.diff that make the same result with r1449615 and let me know what do you think or any suggestions.

Regards
Saroj Khamlue
--
Coherent Software Australia Pty Ltd
http://www.coherentsoftware.com.au/

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/