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
>
[hidden email]
>
>
>
Locked
