On Oct 26, 2006, at 5:26 PM, Si Chen wrote:
Hi everybody-
I am trying to figure out a problem of fixing a tax on shipping
bug. Basically, right now, if you set the store to not pro-rate
your shipping, it will still try to pro-rate your tax on shipping,
which causes erroneous results when you later add more shipping
charges as additional adjustments.
The rest of your email goes into more detail and proposes a fix, but
even in this first paragraph I think you hit it right on the head.
We could use this same flag to not pro-rate order level tax, but it
would probably be better to make it a separate setting (that should
generally be Y if the don't pro-rate shipping is Y). That should both
solve the problem, and make the solution a little bit cleaner (or
less "hack-ish").
-David
I think the core problem is that we lack the data model to
associate one OrderAdjustment with another (ie, no
OrderAdjustment.originalAdjustmentId) and also OrderAdjustment to
Invoice (an OrderAdjustmentBilling entity) really to know which tax
is on which shipping and which has already been invoiced.
As a quick fix, we came up with a rule so that order-level taxes
(OrderAdjustment of SALES_TAX type without an orderItemSeqId) is
not pro-rated when shipping is not pro-rated: ie charged lumpsum to
the first invoice.
Is this good to put back into the project as a fix for now, as it
does fix the bug at hand and does not seem to break things? Or is
something like this too much of a hack and should be kept out?
Best Regards,
Si
[EMAIL PROTECTED]
