testing the book zeroing code (maybe for backport?)

[Tim Wunder]

On Friday 28 December 2007 07:55:59 am Derek Atkins wrote:
> Hi,
>
> 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 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
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