my two cents
I think it would be wise to collect a precise definition of the formal
requirements before making any design decisions.
ABSOLUTELY -- determining requirements is the first step in design.
How about collecting translations of relevant sections of the actual laws in
the wiki, to
Thilo Pfennig wrote:
Maybe this is a misunderstanding but what I mean is that if I make an
entry into the account bank I think this should still be visible,
because only if it wont there would be an error. I think oen should
distinct the real bank account and the bank account in GnuCash. Sure
Derek Atkins wrote:
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
Bastiaan Veelo wrote:
I think it would be wise to collect a precise definition of the formal
requirements before making any design decisions. How about collecting
translations of relevant sections of the actual laws in the wiki, to
find the common denominator? This bit should be provided by
Am Freitag, 15. Februar 2008 23:50 schrieb Graham Leggett:
a gnucash mode of operation
where the user can not edit older transactions anymore
You would definitely want to set this per account, because some accounts
in gnucash are authoritative (eg accounts dealing with the issuing of
Am Sat, 16 Feb 2008 09:18:03 +0100
schrieb Christian Stimming [EMAIL PROTECTED]:
Makes sense, but do you have any ideas how such a per-account setting
can be implemented in the GUI? Currently, all per-account settings
can be set in the Edit Account dialog. However, a setting Make
this an
Christian Stimming wrote:
Makes sense, but do you have any ideas how such a per-account setting can be
implemented in the GUI? Currently, all per-account settings can be set in
the Edit Account dialog. However, a setting Make this an inalterable
account shouldn't be allowed to be disabled
Thilo Pfennig wrote:
I think from the acounting perspective every entry consists on som
field like the date, the accounts, some text,... I also dont think a
mix of inalterable accounts and alterable accounts makes much sense
because every entry has two ends, so if one end is inalterable the
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
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
Am Sat, 16 Feb 2008 16:52:51 +0200
schrieb Graham Leggett [EMAIL PROTECTED]:
This isn't true - each entry can have more than two ends in the form
of splits, the only requirement is that all the splits add up to zero.
ACK, I should rather have written at least two ends.
Gnucash isn't the
On Fri, 2008-02-15 at 21:43 +0100, Christian Stimming wrote:
Some German business users brought up a feature request that sounds a bit
weird for a programmer: They asked for a gnucash mode of operation where the
user can not edit older transactions anymore!
This is not just important for
Am Fri, 15 Feb 2008 21:43:25 +0100
schrieb Christian Stimming [EMAIL PROTECTED]:
I'm still not completely sure how the actual implementation would
look like.
I think the best way would be not to select the feature but that by
selecting some account templates you will get that.
If anybody
Christian Stimming wrote:
Some German business users brought up a feature request that sounds a bit
weird for a programmer: They asked for a gnucash mode of operation where the
user can not edit older transactions anymore!
Makes perfect sense - wearing my programmer hat on financial systems,
14 matches
Mail list logo
