[
https://issues.apache.org/jira/browse/OFBIZ-5163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13630974#comment-13630974
]
Paul Foxworthy commented on OFBIZ-5163:
---------------------------------------
Hi all,
I've been looking a bit more at the long term fix for the problem Saroj
identified.
It seems to me that the itemPrice is only used for searching the
TaxAuthorityRateProduct, see
https://fisheye6.atlassian.com/browse/ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/tax/TaxAuthorityServices.java?hb=true#to380
All other code in TaxAuthorityServices.java is just communicating it.
So calling code could calculate an adjusted item price first, nothing in
TaxAuthorityServices wants the unadjusted price.
The adjustments passed to TaxAuthorityServices would need to be filtered. The
ones that just adjust a price, promotional and so on, should not be passed to
the tax calculation. Only adjustments for additional services, e.g. shipping,
should be passed for separate tax calculation.
So I think from here the tasks are:
1. Categorise all OrderAdjustments into one of three: price adjustment,
additional service, tax. The first should adjust the price *before* tax
calculation. The second category should still be passed separately from prices
to the tax calculation, as already happens. The third category is generated by
the tax calculations and should not be passed in.
2. In code that calls the tax calculation, adjust the unit price before calling
the tax calculation. The adjusted unit price should only incorporate the first
category of adjustments I listed above.
And I think that's it. It's a simpler fix than I envisaged at first.
More general changes to the tax calculation service deals with adjustments in
general, not specifically promotions and shipping, can follow, but that would
be a separate Jira issue.
Any comments?
Saroj, your commit should go ahead and doesn't need to wait for what I've
described here.
Cheers
Paul Foxworthy
> Tax calculated on unit price before adjustments
> -----------------------------------------------
>
> Key: OFBIZ-5163
> URL: https://issues.apache.org/jira/browse/OFBIZ-5163
> Project: OFBiz
> Issue Type: Bug
> Components: accounting
> Affects Versions: SVN trunk
> Reporter: Paul Foxworthy
> Assignee: Paul Foxworthy
> Attachments: OFBIZ-5163_Edit.patch, OFBIZ-5163.patch
>
>
> Some taxes cut in at a minimum item 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 item price, before any
> promotional adjustment.
> r1449615 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).
> 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.
> So a new attribute should be added to the OrderAdjustment entity to say which
> it is.
> 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.
> This issue was found and worked on by Tom at ANTWebsystems, thanks for your
> help.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
