sql-ledger-users

[SQL-Ledger-users] OT: Web-based Checking Software

[Roderick A. A. <raa...@ti...>]

Slightly off topic but I'm looking for check book software.  I'm
currently using GnuCash which is nice but I haven't found a reasonable
way to tie into SQL-Ledger.  So I'm hoping someone knows of some
web-based software.  Probably, needless to say, but perl based, and
using PostgreSQL (or other DBI based method) it preferred.

TIA,
Rod
-- 
                 Remove the word 'try' from your vocabulary ... 
                     Don't try.  Do it or don't do it ...
                                Steers try!

                                                            Don Aslett

Re: [SQL-Ledger-users] OT: Web-based Checking Software

[<li...@li...>]

On Thu, May 03, 2001 at 04:37:12PM -0700, Roderick A. Anderson was heard to=
 remark:
> Slightly off topic but I'm looking for check book software.  I'm
> currently using GnuCash which is nice but I haven't found a reasonable
> way to tie into SQL-Ledger.  So I'm hoping someone knows of some
> web-based software.  Probably, needless to say, but perl based, and
> using PostgreSQL (or other DBI based method) it preferred.

If anyone can help the gnucash developers in figuring out how to tie
into sql-ledger (and/or writing the code to do the same) that would be
great.   BTW, gnucash has a a beta postgres backend.  It works fine in=20
single-user mode, but has difficulties in multi-user mode.

If you do debate this further, please cc. the gnu...@gn...
mailing list.

--linas

>=20
> TIA,
> Rod
> --=20
>                  Remove the word 'try' from your vocabulary ...=20
>                      Don't try.  Do it or don't do it ...
>                                 Steers try!
>=20
>                                                             Don Aslett
>=20

Re: [SQL-Ledger-users] OT: Web-based Checking Software

[John F. <jf...@au...>]

Linas Vepstas wrote:
> 
> On Thu, May 03, 2001 at 04:37:12PM -0700, Roderick A. Anderson was heard to remark:
> > Slightly off topic but I'm looking for check book software.  I'm
> > currently using GnuCash which is nice but I haven't found a reasonable
> > way to tie into SQL-Ledger.  So I'm hoping someone knows of some
> > web-based software.  Probably, needless to say, but perl based, and
> > using PostgreSQL (or other DBI based method) it preferred.
> 
> If anyone can help the gnucash developers in figuring out how to tie
> into sql-ledger (and/or writing the code to do the same) that would be
> great.   BTW, gnucash has a a beta postgres backend.  It works fine in
> single-user mode, but has difficulties in multi-user mode.
> 
> If you do debate this further, please cc. the gnu...@gn...
> mailing list.
> 
> --linas
--------------------------------------------------------------
Hi Linas! I recently suggested that SQL-Ledger incorporate the ability
to import/export ".qif" style files directly into its database. That may
not be the best solution, but by putting a table or tables in place that
handle bank related functions it would be possible to use gnucash or
moneydance (or most other money management systems) to include realtime
cash management functions into SQL-Ledger. I am very weak in postgresql
skills, there may be a way to do the same thing from some postgresql
management system. I have also proposed that to the developers at
Webmin.
If/when the beta gnucash with a postgresql backend becomes stable in a
multiuser environment the procedure becomes simply a matter of using a
single incorporated database that has all of the tables necessary. ( a
dream come true)
This is very important to me as it is an integral part of the
development of a complete retail environment using only open source
software. Please cc: jf...@au... with any discussion on this. 
Thanks.
John Foster

Re: [SQL-Ledger-users] OT: Web-based Checking Software

[<li...@li...>]

Hi John,

On Fri, May 04, 2001 at 10:34:31AM -0500, John Foster was heard to remark:
> Linas Vepstas wrote:
> >=20
> > On Thu, May 03, 2001 at 04:37:12PM -0700, Roderick A. Anderson was hear=
d to remark:
> > > Slightly off topic but I'm looking for check book software.  I'm
> > > currently using GnuCash which is nice but I haven't found a reasonable
> > > way to tie into SQL-Ledger.  So I'm hoping someone knows of some
> > > web-based software.  Probably, needless to say, but perl based, and
> > > using PostgreSQL (or other DBI based method) it preferred.
> >=20
> > If anyone can help the gnucash developers in figuring out how to tie
> > into sql-ledger (and/or writing the code to do the same) that would be
> > great.   BTW, gnucash has a a beta postgres backend.  It works fine in
> > single-user mode, but has difficulties in multi-user mode.
> >=20
> > If you do debate this further, please cc. the gnu...@gn...
> > mailing list.
> >=20
> > --linas
> --------------------------------------------------------------
> Hi Linas! I recently suggested that SQL-Ledger incorporate the ability
> to import/export ".qif" style files directly into its database. That may
> not be the best solution, but by putting a table or tables in place that

The QIF format is a nasty, nasty format that is very hard to handle
correctly.  For example, it fails to denote the currency.   So, for
example, say you export a transaction for 100.  Thats what, 100 dollars?
pesos? widgets in stock?   Thats only the crowd-warmer for the stock of
sick jokes that QIF has in store ...

> handle bank related functions it would be possible to use gnucash or
> moneydance (or most other money management systems) to include realtime
> cash management functions into SQL-Ledger. I am very weak in postgresql
> skills, there may be a way to do the same thing from some postgresql
> management system. I have also proposed that to the developers at
> Webmin.

Note that gnucash has a prototype xml protocol for querying a server
to get the financial data it displays.   There might be a way of
stapling that into sql-ledger, and then one gets the live data
manipulation, reports, etc.=20

(There is also an rpc backend ... lets talk more if this get serious).


> If/when the beta gnucash with a postgresql backend becomes stable in a
> multiuser environment=20

Well, its 'almost' usable, except for one interesting technical problem
I'd like to tell you about.  GnuCash likes to display accounts in a
'checkbook register style': that means that there is a running balance
displayed in one of the columns (far right column).

Say one has a millions transactions in the database. Clearly its insane
to fetch all of them to compute a running balance.  We could store a
running balance with each transaction, but this has a nasty update
semantic: changing one transaction would require updates to hundreds
or thousands of others that occur at a later date.  We talked about
storing 'balance checkpoints' to solve that problem.  But this
introduces another problem: I would need to query a contiguous set of
transactions between checkpoints.  At this point, the sql queries start
getting complex, there's a lot of traffic to the database, and yuck,
so we left it to ferment a bit more.    If you are willing to ignore
the running balance column, then I think the multi-user mode is not far
off.  (there's some minor misc stuff that needs to be brushed up, I
forget what).


> the procedure becomes simply a matter of using a
> single incorporated database that has all of the tables necessary. ( a
> dream come true)

Uh, not quite.  You could put all the tables in one database, but so
what?  Unless you modified some code somewhere, you'd still have to
enter any giving transaction twice, by hand.   The gnucash sql tables
are no doubt quite different than the sql-ledger tables.

> This is very important to me as it is an integral part of the
> development of a complete retail environment using only open source

Ohh. ahh.

Let me just say that I'd like to have gnucash develop more/better
sophisitcated capabilites, and I'd rather do so in cooperation with
sql-ledger, than in competition.  I think we can accomplish more
if we can avoid re-inventing each-others core features.

--linas


> software. Please cc: jf...@au... with any discussion on this.=
=20
> Thanks.
> John Foster

--=20
Linas Vepstas -- li...@gn... -- http://www.gnumatic.com/

Re: [SQL-Ledger-users] OT: Web-based Checking Software

[Donald L G. Jr. <dg...@au...>]

  Linas,
  Rather than keep a running total on a per-transaction basis, why not
keep a daily balance.  Then if you change a transaction 2 months ago,
you've got to apply one change to 60 entries and the change is always
the same (+/- X).  A single query can do that lickity-split.
  Then when you display, you calculate the running total from the
starting balance of the first day displayed, allowing you to process
(hopefully) very few transactions.  Alternately the running total could
be based on some arbitrary number of transactions (say the balance every
hundredth transaction to avoid problems with high-volumes of
transactions (e.g. a video store or a fast-food resteraunt that does
1000+ transactions/day).
  Just a thought

Linas Vepstas wrote:
> 
[...] 
> Well, its 'almost' usable, except for one interesting technical problem
> I'd like to tell you about.  GnuCash likes to display accounts in a
> 'checkbook register style': that means that there is a running balance
> displayed in one of the columns (far right column).
> 
> Say one has a millions transactions in the database. Clearly its insane
> to fetch all of them to compute a running balance.  We could store a
> running balance with each transaction, but this has a nasty update
> semantic: changing one transaction would require updates to hundreds
> or thousands of others that occur at a later date.  We talked about
> storing 'balance checkpoints' to solve that problem.  But this
> introduces another problem: I would need to query a contiguous set of
> transactions between checkpoints.  At this point, the sql queries start
> getting complex, there's a lot of traffic to the database, and yuck,
> so we left it to ferment a bit more.    If you are willing to ignore
> the running balance column, then I think the multi-user mode is not far
> off.  (there's some minor misc stuff that needs to be brushed up, I
> forget what).
> 
[...]

-- 
--------------------------------------------------------
Donald L. Greer, Jr                  dg...@Au...
System Administrator                 Voice: 512-835-8005
AustinTX.COM                    http://www.AustinTX.COM/
  All opinions are my own.  Flame me directly.

"I don't necessarily believe software should be free...
but if you pay for it, it should work!" -- Me

Re: [SQL-Ledger-users] OT: Web-based Checking Software

[<li...@li...>]

Hi Don,
Good to hear from you, been a long time ...

On Sat, May 05, 2001 at 04:17:40PM -0500, Donald L Greer Jr. was heard to remark:
>   Linas,
>   Rather than keep a running total on a per-transaction basis, why not
> keep a daily balance.  Then if you change a transaction 2 months ago,
> you've got to apply one change to 60 entries and the change is always
> the same (+/- X).  

right.  This is what I called a 'balance checkpoint' in the original
note. (could be daily, could be every N transactions, whatever).

> A single query can do that lickity-split.

Umm. How good are you at sql?  I can't say that I know how to 
select 60 rows, add a value to a field, and update those rows,
in a single sql statement.   Have I just not mastered the finer points
of sql?  Can you sketch out that statement?

>   Then when you display, you calculate the running total from the
> starting balance of the first day displayed, allowing you to process
> (hopefully) very few transactions.  Alternately the running total could
> be based on some arbitrary number of transactions (say the balance every
> hundredth transaction to avoid problems with high-volumes of
> transactions (e.g. a video store or a fast-food resteraunt that does
> 1000+ transactions/day).
>   Just a thought

The problem with what you describe is this:
Say I want to display all transactions since noon, but the last
balance checkpoint was midnight.  Thus, I have to query all transactions
since midnight, compute the running blance, and display only those
since noon.   It requires a little extra work, but its doable.

Now imagine I want to show all transactions whose memo field starts
with the letter A...

see what the problem is? first I get all with letter A.  Then I need to
figure out what checkpoint lies before the earliest transaction, get
that, and then get all transactions since then, then compute the running
balance ...  Ugh.

Not too hard to explain, but rather tedious to code up.    Just tedious
enough that I haven't done it ...

--linas


> 
> Linas Vepstas wrote:
> > 
> [...] 
> > Well, its 'almost' usable, except for one interesting technical problem
> > I'd like to tell you about.  GnuCash likes to display accounts in a
> > 'checkbook register style': that means that there is a running balance
> > displayed in one of the columns (far right column).
> > 
> > Say one has a millions transactions in the database. Clearly its insane
> > to fetch all of them to compute a running balance.  We could store a
> > running balance with each transaction, but this has a nasty update
> > semantic: changing one transaction would require updates to hundreds
> > or thousands of others that occur at a later date.  We talked about
> > storing 'balance checkpoints' to solve that problem.  But this
> > introduces another problem: I would need to query a contiguous set of
> > transactions between checkpoints.  At this point, the sql queries start
> > getting complex, there's a lot of traffic to the database, and yuck,
> > so we left it to ferment a bit more.    If you are willing to ignore
> > the running balance column, then I think the multi-user mode is not far
> > off.  (there's some minor misc stuff that needs to be brushed up, I
> > forget what).
> > 
> [...]
> 
> -- 
> --------------------------------------------------------
> Donald L. Greer, Jr                  dg...@Au...
> System Administrator                 Voice: 512-835-8005
> AustinTX.COM                    http://www.AustinTX.COM/
>   All opinions are my own.  Flame me directly.
> 
> "I don't necessarily believe software should be free...
> but if you pay for it, it should work!" -- Me

-- 
Linas Vepstas -- li...@gn... -- http://www.gnumatic.com/

Re: [SQL-Ledger-users] OT: Web-based Checking Software

[Ron P. <rp...@bo...>]

I could be wrong about this -- I'm not an accountant and do not use
accounting software much -- but is it not an important principle that once
you make an entry in a computerized accounting system, you do not allow it
to be changed. If you want to cancel a previous entry, that cancellation is
a new entry that just reverses the previous entry. And if you made a
mistake in a previous entry, you do not go back and change that entry, but
instead you create new entries that make the correction. If this is true,
then there is no consideration of changing an old entry and then
recalculating the balance. The balance will always be up-to-date.

Ron

 At 04:17 PM 05/05/01 -0500, you wrote:
>  Linas,
>  Rather than keep a running total on a per-transaction basis, why not
>keep a daily balance.  Then if you change a transaction 2 months ago,
>you've got to apply one change to 60 entries and the change is always
>the same (+/- X).  A single query can do that lickity-split.
>  Then when you display, you calculate the running total from the
>starting balance of the first day displayed, allowing you to process
>(hopefully) very few transactions.  Alternately the running total could
>be based on some arbitrary number of transactions (say the balance every
>hundredth transaction to avoid problems with high-volumes of
>transactions (e.g. a video store or a fast-food resteraunt that does
>1000+ transactions/day).
>  Just a thought
>
>Linas Vepstas wrote:
>> 
>[...] 
>> Well, its 'almost' usable, except for one interesting technical problem
>> I'd like to tell you about.  GnuCash likes to display accounts in a
>> 'checkbook register style': that means that there is a running balance
>> displayed in one of the columns (far right column).
>> 
>> Say one has a millions transactions in the database. Clearly its insane
>> to fetch all of them to compute a running balance.  We could store a
>> running balance with each transaction, but this has a nasty update
>> semantic: changing one transaction would require updates to hundreds
>> or thousands of others that occur at a later date.  We talked about
>> storing 'balance checkpoints' to solve that problem.  But this
>> introduces another problem: I would need to query a contiguous set of
>> transactions between checkpoints.  At this point, the sql queries start
>> getting complex, there's a lot of traffic to the database, and yuck,
>> so we left it to ferment a bit more.    If you are willing to ignore
>> the running balance column, then I think the multi-user mode is not far
>> off.  (there's some minor misc stuff that needs to be brushed up, I
>> forget what).
>> 
>[...]
>
>-- 
>--------------------------------------------------------
>Donald L. Greer, Jr                  dg...@Au...
>System Administrator                 Voice: 512-835-8005
>AustinTX.COM                    http://www.AustinTX.COM/
>  All opinions are my own.  Flame me directly.
>
>"I don't necessarily believe software should be free...
>but if you pay for it, it should work!" -- Me
>

Re: [SQL-Ledger-users] OT: Web-based Checking Software

[<li...@li...>]

On Sun, May 06, 2001 at 08:33:34PM -0400, Ron Pero was heard to remark:
> I could be wrong about this -- I'm not an accountant and do not use
> accounting software much -- but is it not an important principle that once
> you make an entry in a computerized accounting system, you do not allow it
> to be changed. If you want to cancel a previous entry, that cancellation is
> a new entry that just reverses the previous entry. And if you made a
> mistake in a previous entry, you do not go back and change that entry, but
> instead you create new entries that make the correction. If this is true,
> then there is no consideration of changing an old entry and then
> recalculating the balance. The balance will always be up-to-date.

Gnucash is designed for the home user.  Thus, this proceedure is a bit
too compilcated; instead or paradigm is edit, and at some later date,
(after reconciliation/book close) freeze.  Certainly, after the books
are closed, one *must* do as you describe.

(Its easy to log such changes.  The hard part is to figure out how to
handle it elegantly in the user interface.  Even pro's want to
distinguish between a 'real' transaction, and a train of typos.
Visual and mental clutter leads to even more mistakes ...)

We've talked about having this kind of journalling, but this seems to be
a low priority for our user base.

--linas

Re: [SQL-Ledger-users] OT: Web-based Checking Software

[John O. <jo...@ca...>]

My name is John and I am an accountant. (sounds like Alcoholics Anonymous)

Ron is correct in that older text based accounting packages used, reversing
of incorrect entries, instead of amending them, however, there are about
three or four commercially available packages, which seamlessly amend these
erroneous ones, and replace them with the correct one. It helps the
readability of a transaction listing, not to have to manually stroke off
contra entries.
What the better ones do, is to take a copy of the entry being chanegd and
dump it into another file to allow the year end auditors to see the
transactions which were changed, by whom and when. This makes two reports
available, one for the user, and one for the auditors.


John Osborne


----- Original Message -----
From: Ron Pero <rp...@bo...>
To: <sql...@li...>
Sent: Monday, May 07, 2001 1:33 AM
Subject: Re: [SQL-Ledger-users] OT: Web-based Checking Software


> I could be wrong about this -- I'm not an accountant and do not use
> accounting software much -- but is it not an important principle that once
> you make an entry in a computerized accounting system, you do not allow it
> to be changed. If you want to cancel a previous entry, that cancellation
is
> a new entry that just reverses the previous entry. And if you made a
> mistake in a previous entry, you do not go back and change that entry, but
> instead you create new entries that make the correction. If this is true,
> then there is no consideration of changing an old entry and then
> recalculating the balance. The balance will always be up-to-date.
>
> Ron
>
>  At 04:17 PM 05/05/01 -0500, you wrote:
> >  Linas,
> >  Rather than keep a running total on a per-transaction basis, why not
> >keep a daily balance.  Then if you change a transaction 2 months ago,
> >you've got to apply one change to 60 entries and the change is always
> >the same (+/- X).  A single query can do that lickity-split.
> >  Then when you display, you calculate the running total from the
> >starting balance of the first day displayed, allowing you to process
> >(hopefully) very few transactions.  Alternately the running total could
> >be based on some arbitrary number of transactions (say the balance every
> >hundredth transaction to avoid problems with high-volumes of
> >transactions (e.g. a video store or a fast-food resteraunt that does
> >1000+ transactions/day).
> >  Just a thought
> >
> >Linas Vepstas wrote:
> >>
> >[...]
> >> Well, its 'almost' usable, except for one interesting technical problem
> >> I'd like to tell you about.  GnuCash likes to display accounts in a
> >> 'checkbook register style': that means that there is a running balance
> >> displayed in one of the columns (far right column).
> >>
> >> Say one has a millions transactions in the database. Clearly its insane
> >> to fetch all of them to compute a running balance.  We could store a
> >> running balance with each transaction, but this has a nasty update
> >> semantic: changing one transaction would require updates to hundreds
> >> or thousands of others that occur at a later date.  We talked about
> >> storing 'balance checkpoints' to solve that problem.  But this
> >> introduces another problem: I would need to query a contiguous set of
> >> transactions between checkpoints.  At this point, the sql queries start
> >> getting complex, there's a lot of traffic to the database, and yuck,
> >> so we left it to ferment a bit more.    If you are willing to ignore
> >> the running balance column, then I think the multi-user mode is not far
> >> off.  (there's some minor misc stuff that needs to be brushed up, I
> >> forget what).
> >>
> >[...]
> >
> >--
> >--------------------------------------------------------
> >Donald L. Greer, Jr                  dg...@Au...
> >System Administrator                 Voice: 512-835-8005
> >AustinTX.COM                    http://www.AustinTX.COM/
> >  All opinions are my own.  Flame me directly.
> >
> >"I don't necessarily believe software should be free...
> >but if you pay for it, it should work!" -- Me
> >
>
>

Re: [SQL-Ledger-users] OT: Web-based Checking Software

[Dieter S. <dsi...@sq...>]

Transactions are sent to the backend in the form of 'script.cgi ARGV[0]'

i.e to post a GL transaction first set the environment variable
HTTP_COOKIE to sql-ledger=username and then issue a call to gl.cgi in the
form of

gl.cgi "variable=value&........."

ARGV[0] must be escaped (%20, %2f, etc)

variables must include
  action                             subroutine in gl.cgi
  transdate                          date of transaction
  source                             source
  comment                            comment
  rowcount                           number of debit/credit rows
  accno_(1 .. n)                     account number from chart
  debit_(1 .. n)                     debit
  credit_(1 .. n)                    credit

debit and credit cannot have both a value assigned, one must be zero or
empty, if an error occurs the script dies, nothing will be posted if one
step fails in the posting process

This is your basic API for version 1.2.

The next release uses perl modules for all the backend code.


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 Thu, 3 May 2001, Linas Vepstas wrote:

> On Thu, May 03, 2001 at 04:37:12PM -0700, Roderick A. Anderson was heard to remark:
> > Slightly off topic but I'm looking for check book software.  I'm
> > currently using GnuCash which is nice but I haven't found a reasonable
> > way to tie into SQL-Ledger.  So I'm hoping someone knows of some
> > web-based software.  Probably, needless to say, but perl based, and
> > using PostgreSQL (or other DBI based method) it preferred.
> 
> If anyone can help the gnucash developers in figuring out how to tie
> into sql-ledger (and/or writing the code to do the same) that would be
> great.   BTW, gnucash has a a beta postgres backend.  It works fine in 
> single-user mode, but has difficulties in multi-user mode.
> 
> If you do debate this further, please cc. the gnu...@gn...
> mailing list.
> 
> --linas
> 
> > 
> > TIA,
> > Rod
> > -- 
> >                  Remove the word 'try' from your vocabulary ... 
> >                      Don't try.  Do it or don't do it ...
> >                                 Steers try!
> > 
> >                                                             Don Aslett
> > 
> 
> 

Re: [SQL-Ledger-users] OT: Web-based Checking Software

[<li...@li...>]

On Fri, May 04, 2001 at 10:30:12AM -0600, Dieter Simader was heard to remar=
k:
>=20
> variables must include
>   action                             subroutine in gl.cgi
>   transdate                          date of transaction
>   source                             source

what's 'source'?  is it another account number from the chart?

>   comment                            comment
>   rowcount                           number of debit/credit rows
>   accno_(1 .. n)                     account number from chart
>   debit_(1 .. n)                     debit
>   credit_(1 .. n)                    credit
>=20
> debit and credit cannot have both a value assigned, one must be zero or
> empty, if an error occurs the script dies, nothing will be posted if one
> step fails in the posting process

I assume you mean debit_k and credit_k cannot both occur, but that
debit_1=3D100.0&credit_2=3D50.0  is perfectly valid.

--linas

--=20
Linas Vepstas -- li...@gn... -- http://www.gnumatic.com/

Re: [SQL-Ledger-users] OT: Web-based Checking Software

[Dieter S. <dsi...@sq...>]

source is used to store a cheque number, receipt number, etc; it's a text
field.

debit_1=100&credit_2=50 is correct

you can also use debit_1=100&credit_1=&debit_2=&credit_2=50

If you edit a transaction then the 'id' from the gl table must be sent to
the backend too.


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 Fri, 4 May 2001, Linas Vepstas wrote:

> On Fri, May 04, 2001 at 10:30:12AM -0600, Dieter Simader was heard to remark:
> > 
> > variables must include
> >   action                             subroutine in gl.cgi
> >   transdate                          date of transaction
> >   source                             source
> 
> what's 'source'?  is it another account number from the chart?
> 
> >   comment                            comment
> >   rowcount                           number of debit/credit rows
> >   accno_(1 .. n)                     account number from chart
> >   debit_(1 .. n)                     debit
> >   credit_(1 .. n)                    credit
> > 
> > debit and credit cannot have both a value assigned, one must be zero or
> > empty, if an error occurs the script dies, nothing will be posted if one
> > step fails in the posting process
> 
> I assume you mean debit_k and credit_k cannot both occur, but that
> debit_1=100.0&credit_2=50.0  is perfectly valid.
> 
> --linas
> 
> 

Re: [SQL-Ledger-users] OT: Web-based Checking Software

[Designer <wir...@ta...>]

"Roderick A. Anderson" wrote:

Try CBB, or Check Book Balancer. However, it only a personal finance
module, but it is written inter Perl and TK......
> 
> Slightly off topic but I'm looking for check book software.  I'm
> currently using GnuCash which is nice but I haven't found a reasonable
> way to tie into SQL-Ledger.  So I'm hoping someone knows of some
> web-based software.  Probably, needless to say, but perl based, and
> using PostgreSQL (or other DBI based method) it preferred.
> 
> TIA,
> Rod
> --
>                  Remove the word 'try' from your vocabulary ...
>                      Don't try.  Do it or don't do it ...
>                                 Steers try!
> 
>                                                             Don Aslett

Re: [SQL-Ledger-users] OT: Web-based Checking Software

[Roderick A. A. <raa...@ti...>]

On Fri, 4 May 2001, Designer wrote:

> "Roderick A. Anderson" wrote:
> 
> Try CBB, or Check Book Balancer. However, it only a personal finance
> module, but it is written inter Perl and TK......

I have used CBB and liked it a lot.  But ... I'd really like a
server/browser version that I could tie into SQL-Ledger.


Rod
-- 

Re: [SQL-Ledger-users] OT: Web-based Checking Software

[Terry C. <te...@wo...>]

Ron Pero wrote:
> 
> I could be wrong about this -- I'm not an accountant and do not use
> accounting software much -- but is it not an important principle that once
> you make an entry in a computerized accounting system, you do not allow it
> to be changed. If you want to cancel a previous entry, that cancellation is
> a new entry that just reverses the previous entry.

That is the way that it is done in the commercial programs that I am
forced to use.

Consider the case of sales, where there is a double entry.

Debit  Income from sale
Credit   Bank Account or Accounts Receivable
Debit  Cost of Goods Sold
Credit   Asset account for stock


--
   Terry Collins {:-)}}} Ph(02) 4627 2186 Fax(02) 4628 7861  
   email: te...@wo...  www: http://www.woa.com.au  
   WOA Computer Services <lan/wan, linux/unix, novell>

 "People without trees are like fish without clean water"