Re: Changing tax.pm in 1.21 for a new tax which replaces two old taxes

[Gerald Chudyk <..hidden..>]

On Tue, Jul 6, 2010 at 10:33 PM, Chris Travers <..hidden..> wrote:
> Here is what I'm going to propose we do:
>
> alter Tax.pm to retrieve no taxes from any modules which have a 0
> rate.  This would allow any tax to be set to 0 and thus be skipped.
> Complex taxes would need to be set to a real rate other than 0.
>
> Try this patch:
>

OK, so here's the thing.

The tax calculations are correct for any new transactions. The new tax
is applied and the old tax is suppressed. This was true before the
recent patch.

The tax calculation is correct for any outstanding transactions (sales
orders, purchase orders). The old taxes still apply correctly. This
was also true before the recent patch.

If I try to create an invoice from an outstanding sales order with the
old tax date, the tax lines disappear on the invoice. No tax is
applied. The new patch stops the app from crashing.

Just for fun, I tried setting the system date of the lsmb server to
June 3, 2010 (the tax change date is June 30, 2010), and the problem
went away. I could create an invoice dated June 3, 2010 and the old
taxes applied correctly. I could open an outstanding sales order and
create an invoice with the correct taxes. If I create anything dated
for July there are no tax lines on the order/invoice when the recent
patch is applied and removing the patch allows the app to crash.

It certainly looks like a date issue. Is the date handled differently
in different modules? I am looking at ir/is modules, but the code
confuses my weak perl brain.

Gerald.