|
From: Dieter S. <dsi...@sq...> - 2002-01-02 15:22:48
|
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 |