On Mon, Jul 5, 2010 at 10:10 PM, Gerald Chudyk wrote:
> On Mon, Jul 5, 2010 at 9:36 PM, Chris Travers wrote:
>>>
>> IIRC, there's a fix in sql/fixes/ for that.
>>
>
> That changed the error. When I look around line 1607 I see this:
> {"taxrate_$i"} ) / 100 which, combined with my initial taxrate
On Mon, Jul 5, 2010 at 9:36 PM, Chris Travers wrote:
>>
> IIRC, there's a fix in sql/fixes/ for that.
>
That changed the error. When I look around line 1607 I see this:
{"taxrate_$i"} ) / 100 which, combined with my initial taxrate of 0 is
probably creating the following problem:
DBD::Pg::st ex
On Mon, Jul 5, 2010 at 9:27 PM, Gerald Chudyk wrote:
> On Mon, Jul 5, 2010 at 9:15 PM, Chris Travers wrote:
>> I think you are missing a step.
>>
>> Set the initial tax rate for the new tax to 0 with a valid to date of
>> when it is enacted.
>>
> Thanks Chris,
>
> When I try to set a tax record t
On Mon, Jul 5, 2010 at 9:15 PM, Chris Travers wrote:
> I think you are missing a step.
>
> Set the initial tax rate for the new tax to 0 with a valid to date of
> when it is enacted.
>
Thanks Chris,
When I try to set a tax record to a 0% rate I get:
DBD::Pg::st execute failed: ERROR: duplicate
On Mon, Jul 5, 2010 at 9:01 PM, Gerald Chudyk wrote:
> I restored lsmb to a clean 1.2.21 program/database to test the
> suggestion from Chris and compare my problem to the current release.
>
> If I set the validto date for all expired tax records, new
> transactions dated after validto work fine:
I restored lsmb to a clean 1.2.21 program/database to test the
suggestion from Chris and compare my problem to the current release.
If I set the validto date for all expired tax records, new
transactions dated after validto work fine: the new tax is used and
the old tax ignored. The problem is new
On Mon, Jul 5, 2010 at 10:51 AM, Chris Travers wrote:
> Currently what I'm doing for my customers is to set the rate to 0
> effective when the tax is no longer collected, and to remove it from
> the drop down once no more invoices could be generated (usually at
> next book close).
>
I think this
I forgot to submit this AA.pm change with the original message.
Transaction moving forward work fine. Outstanding sales orders and
purchase orders seem fine. Creating invoices or purchases dated prior
to the new tax cause a problem. It looks like a module is calling the
tax but missing one of the f
On Mon, Jul 5, 2010 at 10:51 AM, Chris Travers wrote:
> Currently what I'm doing for my customers is to set the rate to 0
> effective when the tax is no longer collected, and to remove it from
> the drop down once no more invoices could be generated (usually at
> next book close).
>
Does this mean
Currently what I'm doing for my customers is to set the rate to 0
effective when the tax is no longer collected, and to remove it from
the drop down once no more invoices could be generated (usually at
next book close).
One change that might be desirable might be to exclude 0-rate taxes
from retri
Having not read this with extraordinary care, I will now dash off some
possibly unnecessary questions...
1. Would another solution to this have been to leave the old taxes
configured, and just remove their accounts from tax related dropdowns?
That may not cover every case, and may also break s
I have a new tax here in British Columbia, Canada (HST) that replaces
the previous two taxes (GST + PST). Coincidentally the new tax rate is
the same as
the total of the two old rates.
My original plan was to remove PST and GST from the system and create
new HST records in the chart of accounts an
12 matches
Mail list logo
