testing the book zeroing code (maybe for backport?)

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

testing the book zeroing code (maybe for backport?)

Derek Atkins
Hi,

Over this weekend I implemented a simple book closing feature
that lets you zeroize the Income and Expense accounts into
Equity.  It's comprised of changesets r16713, 16714, and 16715.
It's only impemented in the trunk branch at the moment.

Please test and comment and let me know if you find any problems with
it.  If it works well and doesn't have many issues maybe we can get it
into 2.2.3 or 2.2.4.

Thanks,

-derek
--
       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
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: testing the book zeroing code (maybe for backport?)

Tim Wunder (Lists)
On Wednesday 26 December 2007 05:21:06 pm Derek Atkins wrote:

> Hi,
>
> Over this weekend I implemented a simple book closing feature
> that lets you zeroize the Income and Expense accounts into
> Equity.  It's comprised of changesets r16713, 16714, and 16715.
> It's only impemented in the trunk branch at the moment.
>
> Please test and comment and let me know if you find any problems with
> it.  If it works well and doesn't have many issues maybe we can get it
> into 2.2.3 or 2.2.4.
>
> Thanks,
>
> -derek
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?
* 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.
* It'd be nice if the dialog would remember the previous entires for the date,
income and expense accounts.
* 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.
*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?"

But it looks like a great start to a useful feechur. Thanks, Derek!

Tim
--
Fedora Core release 6 (Zod), Linux 2.6.22.14-72.fc6
KDE: 3.5.8-1 Fedora
 22:05:01 up 3 days,  8:02,  2 users,  load average: 0.24, 0.21, 0.32
"It's what you learn after you know it all that counts" John Wooden

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: testing the book zeroing code (maybe for backport?)

Thomas Bushnell BSG

On Thu, 2007-12-27 at 22:23 -0500, Tim Wunder wrote:

> On Wednesday 26 December 2007 05:21:06 pm Derek Atkins wrote:
> > Hi,
> >
> > Over this weekend I implemented a simple book closing feature
> > that lets you zeroize the Income and Expense accounts into
> > Equity.  It's comprised of changesets r16713, 16714, and 16715.
> > It's only impemented in the trunk branch at the moment.
> >
> > Please test and comment and let me know if you find any problems with
> > it.  If it works well and doesn't have many issues maybe we can get it
> > into 2.2.3 or 2.2.4.

It's kind of inconvenient for me test, but I have a question: I can
decide which Equity account to zero into, right?  I have several,
generally using a new Equity account for each year.

Thomas


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: testing the book zeroing code (maybe for backport?)

Derek Atkins
Quoting Thomas Bushnell BSG <[hidden email]>:

>
> On Thu, 2007-12-27 at 22:23 -0500, Tim Wunder wrote:
>> On Wednesday 26 December 2007 05:21:06 pm Derek Atkins wrote:
>> > Hi,
>> >
>> > Over this weekend I implemented a simple book closing feature
>> > that lets you zeroize the Income and Expense accounts into
>> > Equity.  It's comprised of changesets r16713, 16714, and 16715.
>> > It's only impemented in the trunk branch at the moment.
>> >
>> > Please test and comment and let me know if you find any problems with
>> > it.  If it works well and doesn't have many issues maybe we can get it
>> > into 2.2.3 or 2.2.4.
>
> It's kind of inconvenient for me test, but I have a question: I can
> decide which Equity account to zero into, right?  I have several,
> generally using a new Equity account for each year.

Yes, and indeed you can choose a DIFFERENT account for Income and Expenses
if you wish.

> Thomas

-derek

--
       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
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: testing the book zeroing code (maybe for backport?)

Derek Atkins
In reply to this post by Tim Wunder (Lists)
Hi,

Quoting Tim Wunder <[hidden email]>:

> 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.

> * 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.

Also, I question how you have an Expense account that isn't of type Expense?
GnuCash shouldn't let you do that!

> * 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
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.

> *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.

> But it looks like a great start to a useful feechur. Thanks, Derek!

Thanks!

> Tim

-derek

--
       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
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: testing the book zeroing code (maybe for backport?)

Tim Wunder (Lists)
On Friday 28 December 2007 07:55:59 am Derek Atkins wrote:

> Hi,
>
> Quoting Tim Wunder <[hidden email]>:
> > 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

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: testing the book zeroing code (maybe for backport?)

Tommy Trussell
On Dec 28, 2007 9:08 AM, Tim Wunder <[hidden email]> wrote:

> > > * 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.

alternatively, maybe you could display a "review created transactions"
tab showing the newly-created transactions like the "since last run"
dialog of scheduled transactions can create. This makes it even easier
to back out and it's consistent with another part of the software.

[disclaimer: I'm just reading the discussion -- I haven't tried the
new feature.]
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: testing the book zeroing code (maybe for backport?)

Andreas Köhler
In reply to this post by Derek Atkins
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: testing the book zeroing code (maybe for backport?)

Christian Stimming
Am Mittwoch, 30. Januar 2008 22:18 schrieb Andreas Köhler:

> > Over this weekend I implemented a simple book closing feature
> > that lets you zeroize the Income and Expense accounts into
> > Equity.  It's comprised of changesets r16713, 16714, and 16715.
> > It's only impemented in the trunk branch at the moment.
> >
> > Please test and comment and let me know if you find any problems with
> > it.  If it works well and doesn't have many issues maybe we can get it
> > into 2.2.3 or 2.2.4.
>
> what do you think, shall we consider this for GnuCash 2.2.4?

I'd say yes for back-port. I haven't tested this myself, though, but compared
to other features we have in 2.2.x it is probably complete enough.

Christian
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: testing the book zeroing code (maybe for backport?)

Tim Wunder (Lists)
On Saturday 02 February 2008 03:34:59 am Christian Stimming wrote:

> Am Mittwoch, 30. Januar 2008 22:18 schrieb Andreas Köhler:
> > > Over this weekend I implemented a simple book closing feature
> > > that lets you zeroize the Income and Expense accounts into
> > > Equity.  It's comprised of changesets r16713, 16714, and 16715.
> > > It's only impemented in the trunk branch at the moment.
> > >
> > > Please test and comment and let me know if you find any problems with
> > > it.  If it works well and doesn't have many issues maybe we can get it
> > > into 2.2.3 or 2.2.4.
> >
> > what do you think, shall we consider this for GnuCash 2.2.4?
>
> I'd say yes for back-port. I haven't tested this myself, though, but
> compared to other features we have in 2.2.x it is probably complete enough.
>
Unless it's changed from the last time I tried it at the end of December, I'd
recommend against backport. Adding features that are "probably complete
enough" isn't a good idea, IMO.

Tim
--
Fedora Core release 6 (Zod), Linux 2.6.22.14-72.fc6
KDE: 3.5.8-1 Fedora
 08:30:01 up 5 days, 16:36,  3 users,  load average: 0.46, 0.50, 0.27
"It's what you learn after you know it all that counts" John Wooden

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: testing the book zeroing code (maybe for backport?)

Manfred Usselmann
Tim Wunder <[hidden email]> schrieb am Sat, 2 Feb 2008 08:37:42
-0500:

> On Saturday 02 February 2008 03:34:59 am Christian Stimming wrote:
> > Am Mittwoch, 30. Januar 2008 22:18 schrieb Andreas Köhler:
> > > > Over this weekend I implemented a simple book closing feature
> > > > that lets you zeroize the Income and Expense accounts into
> > > > Equity.  It's comprised of changesets r16713, 16714, and 16715.
> > > > It's only impemented in the trunk branch at the moment.
> > > >
> > > > Please test and comment and let me know if you find any
> > > > problems with it.  If it works well and doesn't have many
> > > > issues maybe we can get it into 2.2.3 or 2.2.4.
> > >
> > > what do you think, shall we consider this for GnuCash 2.2.4?
> >
> > I'd say yes for back-port. I haven't tested this myself, though, but
> > compared to other features we have in 2.2.x it is probably complete
> > enough.
> >
>
> Unless it's changed from the last time I tried it at the end of
> December, I'd recommend against backport. Adding features that are
> "probably complete enough" isn't a good idea, IMO.

What exactly needs to be changed from your perspective to make it good
enough? As far as I remember the discussion in December, there was
no serious issue open? Or did I miss something?

This function would be very useful for me to close 2007. Currently I
didn't do it manually because I was hoping the function would be
available in the near future. So I would love to see it in 2.2.4.

:-)

Manfred

--
________________________________________________________________________
 Manfred Usselmann                            [hidden email]

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: testing the book zeroing code (maybe for backport?)

Derek Atkins
In reply to this post by Christian Stimming
Christian Stimming <[hidden email]> writes:

> Am Mittwoch, 30. Januar 2008 22:18 schrieb Andreas Köhler:
>> > Over this weekend I implemented a simple book closing feature
>> > that lets you zeroize the Income and Expense accounts into
>> > Equity.  It's comprised of changesets r16713, 16714, and 16715.
>> > It's only impemented in the trunk branch at the moment.
>> >
>> > Please test and comment and let me know if you find any problems with
>> > it.  If it works well and doesn't have many issues maybe we can get it
>> > into 2.2.3 or 2.2.4.
>>
>> what do you think, shall we consider this for GnuCash 2.2.4?
>
> I'd say yes for back-port. I haven't tested this myself, though, but compared
> to other features we have in 2.2.x it is probably complete enough.

Just make sure you pull in all the changesets.  There was another bug
that I fixed later where it would create double transactions if you
ran it twice.  So make sure you pull that in, too.

> Christian

-derek

--
       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
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: testing the book zeroing code (maybe for backport?)

Andrew Sackville-West-3
In reply to this post by Manfred Usselmann
On Sat, Feb 02, 2008 at 05:22:59PM +0100, Manfred Usselmann wrote:
> Tim Wunder <[hidden email]> schrieb am Sat, 2 Feb 2008 08:37:42
...

> >
> > Unless it's changed from the last time I tried it at the end of
> > December, I'd recommend against backport. Adding features that are
> > "probably complete enough" isn't a good idea, IMO.
>
> What exactly needs to be changed from your perspective to make it good
> enough? As far as I remember the discussion in December, there was
> no serious issue open? Or did I miss something?
>
> This function would be very useful for me to close 2007. Currently I
> didn't do it manually because I was hoping the function would be
> available in the near future. So I would love to see it in 2.2.4.
>
I agree with both of you.

Tim is right in that a stable branch shouldn't see new features sort
of by definition. It sounds like it hasn't been tested much making it
a really unlikely candidate for backport. I know I haven't tested it.

But on the flip-side, it's gotta one of the most requested features
and one could consider it a serious bug that there isn't book closing
and adding it at any time is a good thing. And what it appears to
implement (from my very light skimming of the code) is pretty simple
both conceptually and implementationally (did I make that up?). Some
things are just simple enough that there *can't* be a lot of bugs in
it (file under "famous last words").

Now that I've muddied the discussion, I withhold my vote pending some
more firm idea of the proposed release date for 2.4.

A

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: testing the book zeroing code (maybe for backport?)

Tim Wunder (Lists)
In reply to this post by Manfred Usselmann
On Saturday 02 February 2008 11:22:59 am Manfred Usselmann wrote:

> Tim Wunder <[hidden email]> schrieb am Sat, 2 Feb 2008 08:37:42
>
> -0500:
> > On Saturday 02 February 2008 03:34:59 am Christian Stimming wrote:
> > > Am Mittwoch, 30. Januar 2008 22:18 schrieb Andreas Köhler:
> > > > > Over this weekend I implemented a simple book closing feature
> > > > > that lets you zeroize the Income and Expense accounts into
> > > > > Equity.  It's comprised of changesets r16713, 16714, and 16715.
> > > > > It's only impemented in the trunk branch at the moment.
> > > > >
> > > > > Please test and comment and let me know if you find any
> > > > > problems with it.  If it works well and doesn't have many
> > > > > issues maybe we can get it into 2.2.3 or 2.2.4.
> > > >
> > > > what do you think, shall we consider this for GnuCash 2.2.4?
> > >
> > > I'd say yes for back-port. I haven't tested this myself, though, but
> > > compared to other features we have in 2.2.x it is probably complete
> > > enough.
> >
> > Unless it's changed from the last time I tried it at the end of
> > December, I'd recommend against backport. Adding features that are
> > "probably complete enough" isn't a good idea, IMO.
>
> What exactly needs to be changed from your perspective to make it good
> enough? As far as I remember the discussion in December, there was
> no serious issue open? Or did I miss something?
>
> This function would be very useful for me to close 2007. Currently I
> didn't do it manually because I was hoping the function would be
> available in the near future. So I would love to see it in 2.2.4.
>
My main complaint with it is that, for my data file, it takes what seems like
a long time to complete, and it offers no feedback to the user that something
is happening during that time. While that's not a game breaker, it adds a
level of unfinishedness that, IMO, shouldn't appear in the branched release.

So, no, that's not a big deal, and I wouldn't complain if the dev's decide to
backport the feature. I just don't think the feature currently has the same
level of completeness that the rest of gnucash has. But, that's just my
opinion and it's worth every penny that you've paid for it.

Tim
--
Fedora Core release 6 (Zod), Linux 2.6.22.14-72.fc6
KDE: 3.5.8-1 Fedora
 08:20:01 up 8 days, 16:26,  3 users,  load average: 0.69, 0.43, 0.30
"It's what you learn after you know it all that counts" John Wooden

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: testing the book zeroing code (maybe for backport?)

Derek Atkins
In reply to this post by Andrew Sackville-West-3
Andrew Sackville-West <[hidden email]> writes:

> Now that I've muddied the discussion, I withhold my vote pending some
> more firm idea of the proposed release date for 2.4.

I suspect 2.4 wont be out until the end of '08 at the earliest.

> A

-derek

--
       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
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: testing the book zeroing code (maybe for backport?)

Derek Atkins
In reply to this post by Tim Wunder (Lists)
Tim Wunder <[hidden email]> writes:

> My main complaint with it is that, for my data file, it takes what seems like
> a long time to complete, and it offers no feedback to the user that something
> is happening during that time. While that's not a game breaker, it adds a
> level of unfinishedness that, IMO, shouldn't appear in the branched release.

Remind me how many accounts you have in your data file?
How many transactions?

Every time I test it on my account it runs really quickly.

-derek

--
       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
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: testing the book zeroing code (maybe for backport?)

Tim Wunder (Lists)
On Tuesday 05 February 2008 09:42:06 am Derek Atkins wrote:
> Tim Wunder <[hidden email]> writes:
> > My main complaint with it is that, for my data file, it takes what seems
> > like a long time to complete, and it offers no feedback to the user that
> > something is happening during that time. While that's not a game breaker,
> > it adds a level of unfinishedness that, IMO, shouldn't appear in the
> > branched release.
>
> Remind me how many accounts you have in your data file?
zcat G2finances.xac |grep "act:name" yields 329 ccounts

> How many transactions?
zcat G2finances.xac |grep "trn:desc" shows 9483 transactions.

Tim

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: testing the book zeroing code (maybe for backport?)

Andrew Sackville-West-3
In reply to this post by Derek Atkins
On Tue, Feb 05, 2008 at 08:39:52AM -0500, Derek Atkins wrote:
> Andrew Sackville-West <[hidden email]> writes:
>
> > Now that I've muddied the discussion, I withhold my vote pending some
> > more firm idea of the proposed release date for 2.4.
>
> I suspect 2.4 wont be out until the end of '08 at the earliest.
>

well then it is my opinion that regardless of what happens, it should
go out *before* the next round of "how do I close the books"
emails whether that means BP or not.

I *still* haven't tested it (school's got me so busy) but I would
agree with Tim, that maybe there should be some indicator of progress,
or at least a "now closing books, this may take a while" notice. But
that's by no meanas a deal breaker for me, just a courtesy for those
of us with big files.

very .02ish

A

ps what about "this is an experimental feature..."?

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: testing the book zeroing code (maybe for backport?)

Tim Wunder (Lists)
On Wednesday 06 February 2008 10:16:53 am Andrew Sackville-West wrote:
> On Tue, Feb 05, 2008 at 08:39:52AM -0500, Derek Atkins wrote:
> I *still* haven't tested it (school's got me so busy) but I would
> agree with Tim, that maybe there should be some indicator of progress,
> or at least a "now closing books, this may take a while" notice. But
> that's by no meanas a deal breaker for me, just a courtesy for those
> of us with big files.

It'd be interesting to see how long it takes for you if indeed you do have a
big file. Derek's file has more accounts, mine has more transactions and we
have significantly different experiences with how long the book close takes.

Tim

--
Fedora Core release 6 (Zod), Linux 2.6.22.14-72.fc6
KDE: 3.5.8-1 Fedora
 10:25:01 up 9 days, 18:31,  3 users,  load average: 0.14, 0.10, 0.08
"It's what you learn after you know it all that counts" John Wooden

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: testing the book zeroing code (maybe for backport?)

David Reiser

On Feb 6, 2008, at 10:35 AM, Tim Wunder wrote:

> On Wednesday 06 February 2008 10:16:53 am Andrew Sackville-West wrote:
>> On Tue, Feb 05, 2008 at 08:39:52AM -0500, Derek Atkins wrote:
>> I *still* haven't tested it (school's got me so busy) but I would
>> agree with Tim, that maybe there should be some indicator of  
>> progress,
>> or at least a "now closing books, this may take a while" notice. But
>> that's by no meanas a deal breaker for me, just a courtesy for those
>> of us with big files.
>
> It'd be interesting to see how long it takes for you if indeed you  
> do have a
> big file. Derek's file has more accounts, mine has more transactions  
> and we
> have significantly different experiences with how long the book  
> close takes.
>
> Tim

Is there a convenient way to count total transactions? I have about  
100 expense accounts and 20 income accounts with a 16MB uncompressed  
data file, and it took just over 4 minutes to close my books as of  
today for about 3 years worth of transactions. Mac OS X 10.5, ppc G5  
chip, svn r16781

Dave
--
David Reiser
[hidden email]




_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
123