On Friday 28 December 2007 07:55:59 am Derek Atkins wrote: > Hi, > > Quoting Tim Wunder <[EMAIL PROTECTED]>: > > 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
is working.
> > * 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
> zero.
>
> Is there any chance you could look in your data file for those two
> transactions
> and email the date_entered and date_posted entries for those two?
> There's clearly a bug here.
>
First:
<trn:date-posted>
<ts:date>2007-12-31 12:00:00 -0500</ts:date>
</trn:date-posted>
<trn:date-entered>
<ts:date>2007-12-28 09:29:45 -0500</ts:date>
</trn:date-entered>
<trn:description>2007 Year End</trn:description>
Second:
<trn:date-posted>
<ts:date>2007-12-31 12:00:00 -0500</ts:date>
</trn:date-posted>
<trn:date-entered>
<ts:date>2007-12-28 09:31:44 -0500</ts:date>
</trn:date-entered>
<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".
>
http://bugzilla.gnome.org/show_bug.cgi?id=506077
> > * 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
> transactions.
> 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.
Tim
--
Fedora Core release 6 (Zod), Linux 2.6.22.14-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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
