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

[Gerald Chudyk <..hidden..>]

On Mon, Jul 12, 2010 at 12:42 PM, Angus Jordan <..hidden..> wrote:
> On Fri, Jul 9, 2010 at 8:03 AM, Gerald Chudyk <..hidden..> wrote:
>> On Wed, Jul 7, 2010 at 10:39 AM, Chris Travers <..hidden..> wrote:
>>> I'll look into it this afternoon.
>>>
>>
>> No luck with this one yet?
>>
>> Regards,
>> Gerald.
>
> Hi Gerald,
>
> I have found a sort of work-around to this problem. We're in BC as
> well, and I was getting a little desperate so I started playing around
> with the tax table. Here is my tax table now:
>
> fred_ledger_db=# select * from tax;
>  chart_id | rate | taxnumber |  validto   | pass | taxmodule_id
> ----------+------+-----------+------------+------+--------------
>    10037 | 0.05 | 816261424 | 2010-06-30 |    0 |            1
>    10037 |    0 |           |            |    0 |            1
>    11106 |    0 | 816261424 | 2010-06-30 |    0 |            1
>    11106 | 0.12 | 816261424 |            |    0 |            1
>    10039 | 0.07 | R470251   | 2010-06-30 |    0 |            1
>    10039 |    0 |           |            |    0 |            1
> (6 rows)
>
>
> 10037 - GST
> 10039 - PST
> 11106 - HST
>
> What this basically does is put $0.00 HST line item on all old
> invoices before the HST switch. Then, for all new invoices July 1st
> forward, the 12% tax is applied for new invoices...
>
> It appears to be working, but I'm still testing.
>
> The only issue is that I had to do this directly in the database. The
> application would not allow me to change the taxes around this way (I
> was getting the same error you initially were asking about)...but this
> may be due to something that I did here, who knows.
>
> I read through the thread and perhaps I missed it, but I didn't see
> that this was tried already. If you find any issues with this setup,
> could you let me know? I will do the same.
>
> Cheers,
> Angus
>


Hi Angus,

I have the same tax table except that I didn't create zero rate
records for PST/GST. I just set the validto dates to July 1 for each
of them. I did have a zero record for HST with a validto date set for
July 1 and then a second record with the correct tax rate and a blank
validto date.

I have taken your suggestion and added the zero rate records for
PST/GST but I don't see any improvement. I have noticed that changing
the server system date will sometimes change the behavior.

Currently I can create a/r invoices both pre and post tax with correct
tax calculation. I can create a/p invoices for the new tax. I cannot
create a/p invoices prior to the new tax.

If I run the sql select statement in Tax.pm directly in psql and using
the correct transdate, I get a good return result. Looks like the
transdate is becoming corrupted somewhere before it gets to the tax
module, but I can't find it. I may also be missing something obvious.

Thanks,

Gerald.