testing the book zeroing code (maybe for backport?)
tim at thewunders.org
Fri Dec 28 10:08:26 EST 2007
On Friday 28 December 2007 07:55:59 am Derek Atkins wrote:
> Quoting Tim Wunder <tim at thewunders.org>:
> > Couple things:
> > * it'd be nice to have some sort of feedback to the user that something
> > is happening. How hard would it be to add a progress bar or something?
> Is it really slow enough that a progress bar is needed? In my cursory
> tests the process took the blink of an eye. Doesn't seem worth a progress
> bar when clicking OK makes it look like the dialog just disappears
> (and the accounts get updated). I suppose I could add a "Done" box at
> the end, but that's pretty obnoxious IMHO.
It takes almost 15 seconds on my datafile where the dialog showed a pressed-in
[OK] button and no activity. I suspect it's a matter of how many accounts you
have, and how big the datafile is.
I don't think a "Done" box is needed, but I think, from a user perspective,
knowing that the app is /doing something/ is a Good Thing (TM). Heck, even
flashing the names of the accounts being closed/zeroed may not be functional,
or useful, but it'd be something for the user to look at to see that the app
> > * I noticed that one of my expense accounts was not configured as an
> > expense account, so it was skipped. I then re-ran the book close program
> > only to find out that not only did the revised account get closed out, a
> > second closing transaction was added to the other accounts. This is
> > probably because I chose a future date (12/31/07) for the close out. When
> > I re-ran the close using that future date, gnc didn't see the
> > pre-existing zeroing out transaction on 12/31/07.
> The future date shouldn't matter. The code performs a "BalanceAsOfDate()"
> operation. Did the second transaction have the same Splits as the first?
> If so, then the problem is either that the BalanceAsOfDate is using <
> instead of <=, or the date chooser is giving different timestamps for the
> day. It SHOULD add a new transaction, but it should skip the
> already-processed accounts, because it should notice that they are already
> Is there any chance you could look in your data file for those two
> and email the date_entered and date_posted entries for those two?
> There's clearly a bug here.
<ts:date>2007-12-31 12:00:00 -0500</ts:date>
<ts:date>2007-12-28 09:29:45 -0500</ts:date>
<trn:description>2007 Year End</trn:description>
<ts:date>2007-12-31 12:00:00 -0500</ts:date>
<ts:date>2007-12-28 09:31:44 -0500</ts:date>
<trn:description>Second 2007 Year End</trn:description>
> Also, I question how you have an Expense account that isn't of type
> Expense? GnuCash shouldn't let you do that!
Well, as I was looking in my data file for the dates, I noticed that it was
configured as a BANK account with a parent of an EXPENSE account. Apparently
at one point you could re-parent an account of the wrong type in gnucash. I
can't seem to duplicate the problem with a new account. Re-parenting a BANK
account to an EXPENSE account requires the assignment of a valid account
type. Changing the parent account from a BANK account to an EXPENSE account
requires the reclassification of the sub-accounts. So I have no idea /how/ it
happened, but it happened.
> > * It'd be nice if the dialog would remember the previous entires for
> > the date, income and expense accounts.
> True. It was on my list of useful features. I was also thinking it would
> be nice to base the date on the Edit -> Preferences Period setting. Could
> you file an RFE in bugzilla on this so I don't forget? I might not have
> time to get to this "soon".
> > * It might also be a good idea for the user to be presented with a review
> > dialog with suitable warning about book closing. Something like "This
> > will create a zeroing transaction for all your income and expense
> > accounts as of $DATE_SELECTED" with the obligatory OK/CANCEL buttons.
> Sure, this is easy enough to do, but it's pretty annoying. Why would you
> need this? It's pretty easy to undo; you just have to delete two
> Also, it's not going to do anything until you click that first OK, and
> the operation isn't dangerous. It's not like it's going to delete
> any transactions or do anything that isn't immediately recoverable. So
> I'm not sure the operation warrants a warning dialog like that.
I'm thinking from the user's perspective. Yes, it's not dangerous and is
easily undone and may be slightly annoying to some, but, any time a user
performs a large operation on their data file, it'd be nice to be sure they
really want to do it.
> > *If gnucash can remember the last book close date, a warning could be
> > displayed if the book close is within say 30 days of the last close,
> > telling the user something like "You just closed the books on
> > $LAST_CLOSE_DATE, num_days ago. Are you sure you want to close the books
> > again?"
> Eh, I suppose. Again, I think it's easy enough to undo the operation
> that such a warning isn't important.
True. Although this /is/ something our accounting App at work does when a
period gets closed within a certain number of days of the previous close.
Fedora Core release 6 (Zod), Linux 18.104.22.168-72.fc6
KDE: 3.5.8-1 Fedora
10:00:01 up 3 days, 19:57, 2 users, load average: 0.19, 0.24, 0.26
"It's what you learn after you know it all that counts" John Wooden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20071228/f74125f2/attachment-0001.bin
More information about the gnucash-devel