Monthly Income/Expense Reports

[David T.]

Jeff (and others)--

I can corroborate that the Eguile engine is far more efficient in reporting; I have installed the Eguile Balance Sheet, and it loads nearly instantly, while the standard Balance Sheet takes the better part of two minutes to load. [Unfortunately, the Eguile balance sheet doesn't allow me to select specific accounts, so I end up running both anyhow.]

As for the Multi Column reports: as nifty as this solution might be, AFAIK there is no way to save these reports. This means that you either: 1) keep them always open (with the concomitant load times), or 2) you have to re-set all your report settings from one session to the next.

David

--- On Sat, 2/20/10, Jeff Kletsky <gnucash at allycomm.com> wrote:

> From: Jeff Kletsky <gnucash at allycomm.com>
> Subject: Re: Monthly Income/Expense Reports
> To: gnucash-user at gnucash.org
> Date: Saturday, February 20, 2010, 8:08 AM
> On 2/19/10 3:59 PM, trythis wrote:
> > Crazy...I have been attempting a complete 6 column
> version of this [report] and
> > running this report each time takes 10 seconds of so
> of data crunching. My
> > PC fans have kicked up from running them. I think
> running all 12 might take
> > quite a while.  Its like rendering video almost.
> >    
> I'm likely on to at least one of the problems here, in that
> the 2.2.x HTML creation and rendering seems to take the bulk
> of the time taken, at least for the budget report (nearly 15
> seconds to create the HTML from collected data across two
> months of personal income and spending). I'd be surprised if
> other reports were no structured in similar ways and suffer
> similar problems. I'm in the process of rewriting that
> report using the 2.3.x framework, which (a) optionally uses
> webkit instead of the current, grey-haired gtkHTML (no CSS
> support), and (b) allows eguile to render HTML that bypasses
> the old-style HTML-generation code and hopefully many of its
> inefficiencies.
> 
> Another of the potential problems is the collection of the
> data. The sooner the XML backend is abandoned, the sooner
> internals will be able to much more efficiently look at the
> data as a database, rather than just frantically paw through
> a collection of records. Just my opinion on that, and there
> is still plenty of time for everyone to have theirs heard.
> (I believe XML is a great interchange format, but not a
> "right" answer for data storage and access for this
> application).
> 
> I can't offer to rewrite the report for you, nor are there
> any significant number of Guile-based web developers out
> there, but eguile certainly has the potential to take
> writing reports from obscenely difficult to potentially
> do-able for someone used to some of the simple
> web-templating systems, like PHP.
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>