Re: pretty cool app

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

I think there is a bit of a misconception here. You do not need an
administrator to prepare the database everytime. You do it once and you
are done.

When you lock the database and effectively create a WORM drive. You can
only add transactions but not delete or change them.

While the "Delete" button is still visible on screen it is just a simple
case of adding a few lines of code to hide it. I can only do so much.
Adding foreign currency and multiple payments took longer than expected
and since I wanted to release 1.8 before years end, some of the minor
things will just have to wait.


Dieter Simader    http://www.sql-ledger.org   (780) 472-8161
DWS Systems Inc.     Accounting Software       Fax: 478-5281
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On a clear disk you can seek forever =3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Wed, 2 Jan 2002, Richard Lyons wrote:

> On Tuesday 01 January 2002 21:56, Keld J=F8rn Simonsen wrote:
>=20
> <snip>
>=20
> > An accountant cannot call on a system administrator, that
> > has the appropiate systems accessabilities, and knowledge of sql=20
> database
> > handling, every time the locking needs to be done. The locking
> > must in principle be done for every transaction! But there is also
> > a need for functionality to only do it when requested, eg
> > every quarter. As far as I understand it, the requirement is
> > considered "good accountant practice" in most countries.=20
>=20
> Can I just put in a vote for flexibility.  In an audited office=20
> environment, with competent operators, the locking ought, of course, to=
=20
> be automatic, and corrections would be made by contra journal entries=20
> (of course it's then important that these contras are entered as=20
> negative sums to the relevant debit and credit accounts, so that the=20
> total statistics are not distorted in management reports, VAT returns,=20
> etc.).  BUT, for the small user doing his/her own bookkeeping,=20
> mistakes, changes of heart about classification, etc. are common, and=20
> the records would become a nightmare for the poor accountant who gets=20
> the resultant output if the records cannot be simply amended. =20
>=20
> Surely the right approach (in the spirit of open software, too!) is to=20
> allow the locking to be switched on if so desired.  The switch would=20
> only be accessible to the accountant user, of course, so that strict=20
> auditing could be enforced when required.
>=20
> --
> richard
>=20
>=20