Profit and Loss Statement for Closed Books

Colin Scott gnucash at double-bars.net
Tue Mar 27 18:51:00 EDT 2012


> Well that is where somebody like myself could be very useful since 
> at one time or other I have "worn all the hats".

Likewise.

> I think you will 
> find that with projects like these the developers number few among 
> themselves who have worked as "analyst sitting with the users". 
> BTW, that is a very important role. Users usually have only a 
> rather vague idea of what the system of their dreams should do. 
> They may have a good idea how it should behave "usually" but are 
> close to totally unable to conceive of all of the  exception/rare 
> situations.

Agreed.

> How odd. I have never been unable to export data from gnucash and 
> then manipulate it as desired. I really think this is a matter of 
> where you think this manipulation should take place, inside gnucash 
> or outside gnucash.

Don't misunderstand me.

1.  I have some very specific requirements (imposed on me by my own users) that would only be provided on a custom program.  Given that gnucash is a somewhat cheaper approach than that, I have no problem with the concept that I need to do some work on the data I get out of gnucash.  Note, however, that I always try to automate such tasks. That is what computers are for!  :-)

2.  Leaving aside these specific requirements,  I have some general expectations of any accounting product and the data one can get out of it.  At the very least I would expect reports that are properly formatted, and gnucash reports are anything but.  For example:  -

* reports don't page - if you print out a gnucash report direct from the program, you will like as not find that the page breaks mid-line, leaving the top half of the line on one page, and the lower half on the next.

* because reports don't page, there are no page numbers.  At the very least, any report should print a page number at the bottom of each page - and preferable it should be in the format
                "page <pagenum> of <numpages>".

*similarly, because reports don't page, there is no page header on each page - which on would normally expect to show info like report name, date, and (essential, this!) columnar headings.

* vertical alignment is problematical.  If any of the fields in the on one line of a report wraps onto a second line, the other fields centre-align vertically.  They should top-align.

There are a number of other similar horrors in the several of the reports (I only use a small subset of them, so have no idea how many!).  The effect of these problem is that I am not prepared to ptu these reports in front of any of my users, and I process them in Excel to produce a properly laid out and paged report.  This step should not be necessary, though I can live with it, except that Excel processing is hampered by the eccentric column management used by some reports, which ensures in Excel some fields are placed in the wrong column.

All the above is to give you some indication of what I mean by it being difficult to get info out of gnucash in a useful form.

> Although that is a standard report for one type of entity (a 
> non-profit) I do not expect gnucash to produce that finished 
> product internally. I do expect it to be able to export the 
> necessary data (in this case, two Income Statements and two Balance 
> Sheets)  and then I use my favorite editor to produce the finished 
> product. COULD I write custom software that did this? Of course I 
> could. Worth the time and trouble, of course not.

You have missed my point, which was not that I wanted gnucash to produce a combined report, but that it *DID* produce a combined report, and then stopped doing it. I had invested a conserable amount of effort in developing spreadsheets to deal with all the problems listed above in the original reports.  When the changes occurred, I decided that I could not justify re-writing those spreadsheets, as to do so would give me no benefit that couldn't be obtained more easily simply by continuing to use the old report from the previous release.
  
Colin

-------- Original Message --------

*Subject:* Re: Spam:****, Re: Profit and Loss Statement for Closed Books
*From:* Mike or Penny Novack <stepbystepfarm at mtdata.com>
*To:* gnucash at double-bars.net
*CC:* john.layman at laymanandlayman.com, warlord at MIT.EDU, gnucash-user at gnucash.org
*Date:* Mon, 26 Mar 2012 17:29:51 -0500

>
>Another excellent point, but this is, of course, a two-way street, and as well as commitment from the users there would need to be commitment from the developers to such a process.  I see little indication that the developers are interested in working with users in the way you describe.
>
>  
>
Well that is where somebody like myself could be very useful since at 
one time or other I have "worn all the hats". I think you will find that 
with projects like these the developers number few among themselves who 
have worked as "analyst sitting with the users". BTW, that is a very 
important role. Users usually have only a rather vague idea of what the 
system of their dreams should do. They may have a good idea how it 
should behave "usually" but are close to totally unable to conceive of 
all of the  exception/rare situations.



>>Gnucash does accounting for 
>>me just fine, thank you.
>>    
>>
>
>Indeed it does, and in this regard it is entirely admirable and I have absolutely no complaint.  However, getting information out of the system in a useful form is somewhat problematical.
>
>Colin
>
>  
>
How odd. I have never been unable to export data from gnucash and then 
manipulate it as desired. I really think this is a matter of where you 
think this manipulation should take place, inside gnucash or outside 
gnucash.

Let's take a look at *my* requirement.

The report (hereafter called annual financial report) shall consist of:

a) A pair of "Income Statements" for two consecutive accounting periods 
side by side. The account names should appear only once.
b) A pair of "Balance Sheets" ditto
c) Both of the above shall possibly have numbers in parentheses added 
after items.
d) Both of the above, if "c": applies, shall have number identified text 
lines or paragraphs explaining the item (which is in some way unusual 
and to be discussed wen the treasurer's report is delivered).
e) A more of less fixed text, possibly a couple pages, explaining the 
accounting principles in effect. Stuff like how large must an item be to 
be a minimum size "fixed asset" and what depreciation schedule will be 
used (unlike for profit businesses, a non-profit has some leeway of 
choice but still must say what they are choosing to do).

Although that is a standard report for one type of entity (a non-profit) 
I do not expect gnucash to produce that finished product internally. I 
do expect it to be able to export the necessary data (in this case, two 
Income Statements and two Balance Sheets)  and then I use my favorite 
editor to produce the finished product. COULD I write custom software 
that did this? Of course I could. Worth the time and trouble, of course 
not.


Michael


Michael




More information about the gnucash-user mailing list