Types of reports required

Poldi Winkler poldiwinkler@ngi.de
Sat, 15 Jul 2000 23:45:33 +0200


Am Son, 02 Jul 2000 schrieb Robert:
> To get a handle on the reporting features that we need, I've spent
> some time playing with Quicken to see what the competition offers :)
> After wading through the interface (does anyone know how to turn all
> the (*&@#($*& glitz off?), as far as I can tell, the reporting
> capabilities aren't all that far advanced of where we are.  I haven't
> started to dissect graphing - that's another email.  However, in the
> process there were a couple of interesting issues.
> 
> Anyway, here's a (paraphrased) list of reports that Quicken offers.
> It offers both business and personal versions of many of these, but
> as far as I can tell they are essentially the same report with a 
> different title.
> 
> I should apologise for the grammar in the following section - these
> are basically working notes.
> 
> Reports:
> 
> * 	Income & Expense by category - essentially, this is a profit and loss 
> report, which we already have.  We need to be able to specify which accounts
> are included, and whether subaccounts should be consolidated?  Quicken
> also has a neat feature, where clicking on a figure in a summary
> report brings up a transaction report.  Can we duplicate?  Can gtkhtml
> (the new html widget) support a hyperlink that will get passed back to
> a callback internal to gnucash, without turning gnucash into a
> webserver and the security risks that entails?
> 
> * Budget
>   against actual - the above, but compared with budget figures.  
>   When we have budgeting available, this one shouldn't be too tough.
> 
> * Periodic income/expense reports (over a year, by month, for
> example).  Don't have, but it's not hard.
> 
Budget and periodic income/expense is more or less the same I think,

> * Transaction report - we have a good one already (need running
> balance though) * net worth (balance sheet).  Same deal - need to be
> able to include and exclude accounts.  
> 
> * Accounts Payable/Receivable.
> Just a transaction report with appropriate accounts selected?  
> 
> *  Payroll isn't an issue yet.  
> 
It can be a special account and then there is a report

> * Tax-related transactions?  Basically
> just a transaction report with
> 	appropriate accounts selected.  Do we want to do this?  Not
> 	straight away, to be honest - too risky!
> 
> * Tax-return report.  Income & Expense report with selected categories
> - same caveats apply
> 	as tax-related transactions
> 
do you mean vat ? I think it is a very important point for commercial
use of gnucash. But before we talk about the report we need the figures
in gnucash - sum with and without vat. And of course the vat should be
calculated via a database for the different countries and periods. 

 > * Missing cheques?  Not hard to implement, but isn't this
what > reconciliation's for, and does
> 	anyone ever use it?
> 
> * Sales tax reports.  
> 
see tax-return report

> Investment reports:
> 
> * Portfolio reports - already have to some extent.  Relatively easy
> * Investment performance report.  Don't have, but need.
> Have to be able to calculate ROI.
> 
what is ROI?
I miss an input for the costs for buying and selling or for deposit or
whatever in the register of the shares/stocks ?!?

> *Investment Income Report - Dividends
> 	                   (taxable/non-taxable)
>  			  -Interest (taxable/non-taxable)
> 		          - capital gains
> 		           redistribution
> 			  - expenses.  
>                            - realized/unrealized
> 			    gain loss.  
> 
> 
> 			- All rather complex -
> 			  how can we distinguish
> 			  taxable/non-taxable
> 			  transactions?
> 			           
> 		          To calculate income, we need the
> 			  cost basis of the shares.  the cost
> 			  basis is difficult to calculate,
> 			  because precisely which shares
> 			  are we selling????
> 
FIFO - first in, first out  - that should be the rule!

> *Investment transaction report - not the same as other
> 	transaction reports.  Need to show how transactions have
> 	changed either market value or cost basis.  Cost basis is a
> 	problem, as when you sell shares you have to know the cost of
> 	the shares that you are selling.  Is it the oldest, the
> 	newest, what.  Do we need to be able to specify that
> 	explicitly?
> 
> Looking at Quicken's selection of reports, I suspect we could do worse
> but to use their list as a good starting point.  
> The good news is that we actually don't need that many
> different reports, and the non-investment ones aren't that complex.
> 
> As tax issues vary so much between jurisdictions, and are so complex,
> and most people will get accounting advice on them anyway, I'm
> hesitant to do them.  
>
You should forget the tax. In each country and in each year are very
different and very complicated rules. Such a program has to be
separate.

> Instead, we need to give the ability for our 
> users to save report options.  As we already have global options 
> saving code, I can't see this being a huge problem.  In that way,  
> users can select the categories and dates that should be included in 
> the reports to make their own "tax reports" - or anything else.   
> To make this easier, we need to be able to specify dates in a relative
> manner, such as "this month" or "current accounting period".
> 
> Virtually all the information we need to create reports is already
> available from the engine (and could be extracted a little more
> efficiently given the extension to the engine interface discussed
> previously).  There is one exception to this, and it might pose a
> thorny problem, which Richard Wackerbath pointed out before but I
> admit I was not fully aware of the implications.  
> When calculating the cost basis of a holding of
> shares, which you have bought at multiple blocks at different prices,
> and then sold some of, it matters which ones you have sold.
> If I buy 50 shares at $2.00, and 50 shares at $2.50, and then sell 25
> shares, have I sold 25 shares that were bought at $2, 25 shares that
> were bought at $2.50, or a combination of both lots?  Quicken defaults
> to assuming to a FIFO discipline, but lets you specify explicitly if
> you wish.  Accordinging to a friend who works at a big stockbroking
> house, they use an weighted-cost (so the cost of the sold 25 shares
> would be deemed to be $2.25) system.  However, Quicken's system would
> require us to keep track of from which block shares were sold from -
> extra engine functionality.  Will this be necessary or not?
> 
FIFO is OK!

> The final issue I have is how we select which accounts are included in
> reports, and which are displayed explicitly and which are subsumed
> into the display of a parent account.  I believe that a tree-based
> widget could be constructed to do this, but an account selection
> dialog with regular-expression selection (something like the windows
> find-file dialog) might make the job easier.  However, some careful
> thought and experimentation might be necessary to get it right.  Can
> anybody give me some pointers as to a design which me might emulate?
> 
Is it not possible to choose it in each "own report"?