Re: sql-ledger and postgresql: HOWTO?
On Wed, 2004-08-04 at 03:00, John Hasler wrote:
> John Summerfield writes:
> > Web interfaces have their advantages though: for example, you client
> > machine can be anything anywhere running any web browser. One of the
> > things users like about sql-ledger is that you can do work at a client
> > site, connect to your accounts (possibly using their machine), print up
> > an invoice, process the payment & give them the receipt.
>
> I would never make my accounting system accessible from the Net. I would
> like it to be accessible on the LAN, though, and https seems like a good
> way to do that.
You can also let your client program talk to the PostgreSQL postmaster
through an SSL connection (for remote links) or Kerberos or directly
(for a trusted network).
I don't actively oppose a web interface; it's just that they are such a
pain to debug that I don't want to write one.
> > Also, using a web interface pretty much requires the application be
> > multiuser.
>
> That's a given, isn't it? I'd also want a text interface. My wife hates
> GUIs.
A well-written web-interface should support lynx and similar text-based
browsers. However, I would prefer a dedicated text input program
without the web-browser overhead; so it would work like the old
green-screen programs I used to write. The objective here is maximum
convenience for data entry: type in the data, press return to go to the
next field, predictive text where possible, in-field editing.
> > Eiffel would offend those users who are especially keen on free software,
> > and ensure that the sotware would, at best, be in contrib.
>
> I would not be interested in a non-free package.
Eiffel is free. As has been pointed out, SmartEiffel is a GPL'd
compiler (the official GNU Eiffel compiler, no less!) and the class
libraries are free too. It can even be faster than a program written
from scratch in C, because the optimisation looks at the entire program
before generating the C code rather than the more limited optimisation
that a C compiler can do (according to a current thread on the
smarteiffel mainlig list).
> I have a toy system I spent some time on after I dropped out of the Gnucash
> project. It uses Python and Postgresql and illustrates some ideas I was
> unable to sell to the Gnucash folks, such as using a journal as the
> fundamental data structure. I haven't looked at it in years, so it has
> probably suffered bit-rot.
--------------------
Let me set out what I think are some of the requirements for a good
accounting system (in no particular order):
1. It should properly maintain double-entry, so that a
non-computer-literate bookkeeper can view accounts and understand them
as if he were looking at a written ledger.
2. It should be fully integrated. Cashbook, sales and purchase
invoicing, asset depreciation, employee expenses, tax deductions and
direct journal entries should all interact; the journal should be able
to address any ledger.
3. Account codes should be purely arbitrary. I hate these systems that
force you to use numeric codes to sort the chart of accounts. The
organisation of accounts should depend on separate attributes of the
account definitions, not on their codes.
4. There should be no limits on the number of companies, customers,
accounts or whatever. (Proprietary systems tend to impose these to make
you pay for upgrades.)
5. The system should be modular, so that you only need to install the
bits you use.
6. There needs to be a full printed audit trail. Entries should never
be deleted, only reversed. Use printed checksums to enable it to be
proved that the current system entries are the same as were originally
entered.
7. The system should enforce separation of duties, if the organisation
is large enough to need that. (For example, the people who write
cheques should not be the same people as the bought ledger clerks).
8. In view of the many different legal and tax systems in the world, it
should be easy to integrate tax modules in various places.
9. It should be easy to remove data relating to past years, without
affecting the current data; equally it should be possible to keep
multiple years' data on-line.
I have the beginnings of the design of such a system; if anyone else
would like to contribute ideas, please email me.
--
Oliver Elphick olly@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA
========================================
"And not only so, but we glory in tribulations also;
knowing that tribulation worketh patience; And
patience, experience; and experience, hope."
Romans 5:3,4
Reply to: