Re: pretty cool app

[<ke...@dk...>]

On Wed, Jan 02, 2002 at 08:22:43AM -0700, Dieter Simader wrote:
> 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.

OK, Maybe I did not understand it fully. So the sql statements in the FAQ
will also lock new transactions applied after the sql statements have
been applied?

Then I would miss some functionality, as I would like to do some draft
transactions, and only fixate them once every year. I understood
that others also wanted to do something like that, eg every quarter.

> 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.

So this is on your todo? I would really appreciate that. 

Kind regards
Keld

> 
> 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 Wed, 2 Jan 2002, Richard Lyons wrote:
> 
> > On Tuesday 01 January 2002 21:56, Keld Jørn Simonsen wrote:
> > 
> > <snip>
> > 
> > > An accountant cannot call on a system administrator, that
> > > has the appropiate systems accessabilities, and knowledge of sql 
> > 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. 
> > 
> > Can I just put in a vote for flexibility.  In an audited office 
> > environment, with competent operators, the locking ought, of course, to 
> > be automatic, and corrections would be made by contra journal entries 
> > (of course it's then important that these contras are entered as 
> > negative sums to the relevant debit and credit accounts, so that the 
> > total statistics are not distorted in management reports, VAT returns, 
> > etc.).  BUT, for the small user doing his/her own bookkeeping, 
> > mistakes, changes of heart about classification, etc. are common, and 
> > the records would become a nightmare for the poor accountant who gets 
> > the resultant output if the records cannot be simply amended.  
> > 
> > Surely the right approach (in the spirit of open software, too!) is to 
> > allow the locking to be switched on if so desired.  The switch would 
> > only be accessible to the accountant user, of course, so that strict 
> > auditing could be enforced when required.
> > 
> > --
> > richard
> > 
> > 
> 
>