Year end reports

[Donald Allen]

On Dec 26, 2007 10:27 AM, Derek Atkins <warlord at mit.edu> wrote:
> Quoting Terry Therneau <therneau at mayo.edu>:
>
> >  Three questions/comments
> >
> >  1. I've been using Gnucash for the last 8-9 months, after ~10 years of
> > Quicken.  (The DOS version, run in a Unix dosemu window --- why change when
> > something works?  But I needed to upgrade to Ubuntu for other reasons, and
> > couldn't get it to run.)   I'm having troubles with reports.  What I'd really
> > like is what Q called "itemized category", which was a sum of all expenses by
> > category/ subtotal by subcategory.  I do this to
> >    The manual section that I can find on reports is very thin, lists
> > names but
> > almost no detail.  Am I overlooking some documentation?
> >    If not, what report would work?
>
> Income Statement (used to be called the Profit and Loss report)
>
> >  2. Even better would be the ability to export the data.  I would
> > read it into
> > the S language ("R" is the GPL implementation, "S-Plus" the commercial one)
> > and do my reports there.  This would make any number of summaries,
> > reports, or
> > graphs very simple to create.  It happens to be what that language
> > was designed
> > to do.  (I'm a statistician working in medical research.  Studies can cost
> > thousands to millions of dollars, so the resultant data is looked at from
> > every angle.)
> >   My first try was to take the transaction report, choose options to remove
> > subtotals, get the right columns, etc.  If I could save this as text it would
> > be easy for me to import, but cut/paste doesn't work!  Parsing the
> > html is going
> > to be a lot harder.  (BTW, reading a complete transaction report is how I got
> > my data into gnucash in the first place -- my version of Quicken predated QIF
> > output.  Read it into S, and then wrote my own qif).
> >
> >   What's the best way to output all the transactions from a given date range?
>
> The transaction report and parsing the HTML.
>
>
> >
> > 3. The whole thread on "year end" has been fun to read.  Some comments
> >
> >  - I think that simple export is the best tool.  The package will
> > never contain
> > all the reports that people might want, nor be able to support all
> > the packages
> > that users might use.  My point 2 above is a good case: no one had
> > yet mentioned
> > MY favorite language in the debate!  I will go back and look at the
> > gnucash to
> > sql thread.  But if I could add one report it would be a "export
> > selected data
> > as a text file".
> >
> >  - MikeorPenny Novak claim that all languages can be written well.  I think
> > that there are some notable counterexamples.  APL, which I once knew very
> > well, has been described as a "write only" code -- and I agreed with that
> > statement even then, when I first fell in love with the language.  It
> > had many
> > groundbreaking ideas, which thankfully influenced other languages which were
> > not so unforgivably terse.  But the best counterexample has to be MUMPS, a
> > language once popular in medical laboratory systems, and
> > unfortunately not yet
> > quite eradictated.  Variable names are limited to 2 characters for instance,
> > and all comments and extra spacing minimized to increase exectution speed.
> >
> >  - Lovers of Lisp and its offspring such as scheme are often passionate about
> > the language's ease of learning, coding, and/or purity.  But they continue to
> > remain a tiny fraction computerdom.  This will continue to severely restrict
> > the gnucash developer base.  The number of potential contributers should be a
> > part of your considerations on future code evolution.  Judging from the
> > mailing list, 2-3 people currently carry a very large fraction of the load,
> > which prompts both accolades for their dedication and worries for the future.
>
> I'll point out that even though 80% of GnuCash is C (and Gtk), and really
> the only parts of GnuCash still in Scheme are the QIF Importer and Reports,
> I think that "Scheme" is a Red Herring in terms of lack of developers.
> There's plenty to do for a developer who doesn't know Scheme and doesn't
> want to learn Scheme.  But people aren't chomping at the bit to send in
> code changes.
>
> Personally I think that most people just don't consider a finance application
> "Sexy".  I dont think that language has anything to do with it.

I don't disagree with any of this, except to say that I think the
reports are an area of gnucash that really need to be
customizable/extensible, perhaps more so than any other area of the
application. People just have their own way of wanting to slice and
dice things, and it's hard to be all things to all people in this
area. Sure, you can supply options/preferences, but it's difficult to
anticipate everything. In the ideal world, when someone has a bright
idea in reporting worthy of being shared with the gnucash community,
it ought to be as easy as possible for them to just implement it
themselves. Much as I love Scheme, those of us who do are on the tail
of the distribution, as Terry points out. This is the essence of why
I've argued for something else -- to get the reports more in the
middle of the fat part of the distribution so there are more potential
contributors to draw from.

/Don

>
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
>
> -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
>        warlord at MIT.EDU                        PGP key available
>
>
> _______________________________________________
> 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.
>