Menu
▾
▴
sql-ledger-users
|
From: adrian <ad...@sn...> - 2001-09-09 21:03:21
Attachments:
error.ps
gl.trans.ps
|
I attampting to post some GL transaction I sometimes get the following error: Error! Debit and credit out of balance! I have attached the screen dumps. More detail: A GL transaction for petty cash, so Petty Cash credit $13.05 Sundry exp $11.86 GST $1.19 Update form Post Transaction ..... Error The crazy thing is that sometimes it works. I had one transaction that I tried several times, several days later I tried again and it worked. I just tried re-logging in, but no success Any thoughts as to why? Adrian -- Adrian Blake Snowy Technology Pty Ltd 26b Bombala St Cooma, NSW 2630 Ph 2-64-524338 mobile 0407 232 978 |
|
From: Dieter S. <dsi...@sq...> - 2001-09-10 16:18:12
|
This error is caused by how numbers are processed by your computer.
Somewhere along the line your machine thinks that the result of adding
11.86 and 1.19 is 13.050000000001 and not 13.05 IMHO this should not
happen but apparently it does.
The workaround. In GL.pm add the following before line 77
$debit = sprintf("%.2f", $debit);
$credit = sprintf("%.2f", $credit);
Dieter Simader http://www.sql-ledger.org (780) 472-8161
DWS Systems Inc. Accounting Software Fax: 478-5281
=========== On a clear disk you can seek forever ===========
On Mon, 10 Sep 2001, adrian wrote:
> I attampting to post some GL transaction I sometimes get the following
> error:
>
> Error!
> Debit and credit out of balance!
>
> I have attached the screen dumps.
>
> More detail:
> A GL transaction for petty cash, so Petty Cash credit $13.05
> Sundry exp $11.86
> GST $1.19
> Update form
> Post Transaction .....
>
> Error
>
> The crazy thing is that sometimes it works. I had one transaction that
> I tried several times, several days later I tried again and it worked.
> I just tried re-logging in, but no success
>
> Any thoughts as to why?
>
> Adrian
>
|
|
From: Matt B. <ma...@li...> - 2001-09-10 17:45:07
|
Dieter and folks, We updated to 1.6.3, after finding that our invoice dates (%invdate%) and due dates all printed as "0, 2000" (after updating to 1.6.2). Unfortunately, we're still seeing this with the 1.6.3 downloaded some minutes ago. Is this the same date bug labelled "fixed dates for GL reports?" Matt Matt Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 tel. 734-761-4689 fax. 734-769-8938 pgr. 734-431-0118 |
|
From: Matt B. <ma...@li...> - 2001-09-10 18:10:24
|
Okay, as everyone must have known, this was entirely my error. I converted the users without checking their properties. I _did_ note one genuine oddity--on my first attempt to save user changes, I had forgotten to fix permissions on the user conf files. It would be handy if admin.pl checked this and reported before attempting the save. I immediately realized that the "user = HASH(0xddddde)" error I did get was related to file permissions, but with less sleep or without Unix experience, I might have been frustrated... Sorry to spam the list. Matt Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 tel. 734-761-4689 fax. 734-769-8938 pgr. 734-431-0118 On Mon, 10 Sep 2001, Matt Benjamin wrote: > > Dieter and folks, > > We updated to 1.6.3, after finding that our invoice dates (%invdate%) and > due dates all printed as "0, 2000" (after updating to 1.6.2). > > Unfortunately, we're still seeing this with the 1.6.3 downloaded some > minutes ago. > > Is this the same date bug labelled "fixed dates for GL reports?" > > Matt > > Matt > > Matt Benjamin > > The Linux Box > 206 South Fifth Ave. Suite 150 > Ann Arbor, MI 48104 > > tel. 734-761-4689 > fax. 734-769-8938 > pgr. 734-431-0118 > > > |
|
From: adrian <ad...@sn...> - 2001-09-10 22:51:27
|
Dieter Simader wrote:
>
> This error is caused by how numbers are processed by your computer.
> Somewhere along the line your machine thinks that the result of adding
> 11.86 and 1.19 is 13.050000000001 and not 13.05 IMHO this should not
> happen but apparently it does.
>
> The workaround. In GL.pm add the following before line 77
>
> $debit = sprintf("%.2f", $debit);
> $credit = sprintf("%.2f", $credit);
>
Should this be included in all future versions? And are there any other
places where it may be necessary?
Adrian
--
Adrian Blake
Snowy Technology Pty Ltd
26b Bombala St
Cooma, NSW 2630
Ph 2-64-524338 mobile 0407 232 978
|
|
From: Francois G. <fg...@ya...> - 2001-09-11 00:25:59
|
Hello,
Using floating point numbers in an accounting context is not optimal, and
some random bugs will appear from time to time. Personally, I have 0.01 baht
(currency in thailand, makes 0.0002 USD) sitting idle in credit of the
account receivable, following such rounding problems. Try to explain THAT to
an average financial controller...
There is a module at CPAN, Math::Currency, which address that issue by
creating a new class of numbers and providing overloaded operators so that
the actual code may run with minimal modifications.
Francois
PS: I'm new to accounting (I used to _hate_ accountants), and very, very
pleased to have found sql-ledger which "opened my eyes" ;-)
On Tuesday 11 September 2001 05:31, you wrote:
> Dieter Simader wrote:
> > This error is caused by how numbers are processed by your computer.
> > Somewhere along the line your machine thinks that the result of adding
> > 11.86 and 1.19 is 13.050000000001 and not 13.05 IMHO this should not
> > happen but apparently it does.
> >
> > The workaround. In GL.pm add the following before line 77
> >
> > $debit = sprintf("%.2f", $debit);
> > $credit = sprintf("%.2f", $credit);
>
> Should this be included in all future versions? And are there any other
> places where it may be necessary?
>
> Adrian
|
|
From: <eli...@li...> - 2001-09-13 16:01:44
|
Hello i noticed that since the upgrade from release 1.4 to release 1.6 my ability to add G/L transaction to accounts with a number range above 4300 has dissapeared. it seems to be there when i first look up the accounts but then when i have to update the form to get the Source in, the ability to bring up *all* the accounts is gone. is this something that anyone else is experiencing or is there a new way to post transactions to g/l accounts in the 5000, 6000 range that i am missing? thanks elizabeth ziph the linux box corporation ann arbor, michigan |
Thanks for helping keep SourceForge clean.
X