Year end reports

Donald Allen donaldcallen at gmail.com
Wed Dec 26 11:04:45 EST 2007


On Dec 26, 2007 10:16 AM, Terry Therneau <therneau at mayo.edu> wrote:
>   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?
>
>   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?
>
>
>  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".

Or a .csv file. While I agree with your comment above that exporting
would be useful, it will never address all the reporting requirements.
Ultimately, we need an easily extensible reporting system for gnucash.

But one of the beauties of gnucash is that the data is represented in
a standard way, xml in this case. As I've mentioned to this list, I've
written a report utility for myself that uses an xml parser that is
part of the python environment, walks the the resulting tree, builds
the data structures I need, and produces reports (using latex) and
graphs (using gnuplot). Works great, it's fast, and I'm able to get
the reports I want in the form I want them.

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

Yep, APL was a useful language that was impossible to read because of
all the special symbols. There was a VLSI design system at MIT many
years ago written in APL!

Not surprised you're an R programmer. My colleagues and I at work use
it heavily. Very nice for the right problem domains.

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


More information about the gnucash-user mailing list