Feature request from German list: Disable editing of transactions

Derek Atkins warlord at MIT.EDU
Sat Feb 16 13:37:24 EST 2008


Perhaps this should get tied into the book closing clode?  When you
close the books on a period, all the transactions in that period become
uneditable?   We DO have the ability to mark a transaction specifically
as read-only.  It wouldn't be too hard to also mark the txns as read-only
as we process them for the book closing.

-derek

Quoting Geert Janssens <janssens-geert at telenet.be>:

> Hi,
>
> I'll just chime in with some of my personal findings and 
> observations. Most of
> this based on my personal experience and may not be valid for everyone. But I
> thought different insights might be useful to get a complete picture.
>
> On Saturday 16 February 2008, Graham Leggett wrote:
>> An example of where one split remaining alterable becomes important is
>> when one side of the split goes to "income - sales" (for example), and
>> the other side goes to "bank account". Gnucash isn't the authoritative
>> source for bank account information (the bank is) and therefore it
>> should remain editable until the bank statement is reconciled, but
>> gnucash is the authoritative source for sales. So it must remain
>> possible to allocate the bank split to say "petty cash" or "overs and
>> unders" if a mistake was found.
>>
> Graham's comment on bank reconciliation makes me wonder wether this new
> feature request isn't some kind of variation on reconciliation ?
>
> I used to get a warning when I tried ot modify a reconciled transaction with
> the option to allow the change or not. To my confusion, this doesn't seem to
> work anymore in version 2.2.1 on Mandriva. Maybe this has changed ? But a
> similar method could be used to completely disable editing on a per account
> basis.
>
> In another accounting program I'm using (commercial, windows-only program for
> the Belgian accounting market), disabling the editing of transactions is a
> user initiated action: after entering a number of transactions, and verifying
> them, a user can choose an option "doorboeken" which I would translate
> as "book through". From that point on, these transactions are no longer
> editable, the "book through" action is irreversible. But allowing the user to
> initiate the action, provides room to fix human errors (mistyping a number,
> or posting to a wrong account). It is perfectly normal to make such mistakes,
> and correcting them doesn't fall in the category of "tampering". It makes
> sense to only disable the editing after the entries have been verified. In
> the other accounting program, we usually do the final "booking through" only
> quarterly, after having verified all inputs and just before printing the
> official VAT/tax reports.
>
> <sidenote>
> In this particular program, the transactions are grouped in 
> accounting periods
> (configurable as either months or quarters). When choosing "book through" you
> select for which accounting period you wish to perform this. Although
> the "booked through" transactions can't be edited, it's still possible to add
> new transactions in the same accounting period. This allows for midperiod
> analysis on data that is verified, while later on still entering new
> transactions in the period.
>
> Although not part of the original request, I would really like to see this
> concept of accounting periods in GnuCash as well. It's a concept required by
> Belgian law (we have quarterly or monthly VAT declarations) and it helps in
> dealing with some other difficult cases as well, like for example booking a
> forgotten bill from a previous VAT period.
> </sidenote>
>
> Regardless of this, using a set date to disable editing of transactions
> shouldn't prevent new transactions to be entered before that date, like for
> example a forgotten invoice.
>
> Assuming the feature is user-enabled, it should also be enabled 
> separately per
> account. In my typical scenario, I enter invoices and bills earlier than I
> enter bank account information. So I would disable editing on invoices and
> bills earlier than I would on bank accounts.
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>



-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available



More information about the gnucash-devel mailing list