Types of reports required

Christopher Browne cbbrowne@hex.net
Sat, 15 Jul 2000 20:44:18 -0500


On Sat, 15 Jul 2000 23:45:33 +0200, the world broke into rejoicing as
Poldi Winkler <poldiwinkler@ngi.de>  said:
> 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 account
s
> > 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,

Not quite; one involves tracking expenses, whilst budgeting requires
having a parallel tracking of budget information.  Collecting budget
estimates is the thorny issue...

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

Reporting on payroll is the easy part; the _hard_ part is of collecting
together the data and computations required to compute wages and
deductions.

I work professionally with an R/3 payroll system, which is pretty much
"rocket science" level payroll; the complexity is just frightening, and
it's _NOT_ just that R/3 is complex, but rather that tracking the
computations is scary...

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

... And therein lies the thorny issue that is the same as payroll, only
slightly _less_ scary...  

Calculating VAT isn't as simple as having a database of rates by country.
It requires having some assessment of whether the purchase or sale
requires VAT, or is exempt, and what jurisdiction it occurs in, so as
to determine what rate, if any, applies.

>  > * 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?

Return On Investment.

It represents an estimation of how well your portfolio is doing.

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

Ah, but just as with payroll and VAT and other sales taxes, that
may be the rule in _some_ jurisdictions, but the laws of the land
varies from land to land.

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

Probably so.  I suspect this will be true for various complex calculations.
--
cbbrowne@ntlug.org - <http://www.hex.net/~cbbrowne/lsf.html>
((LAMBDA (X) (X X)) (LAMBDA (X) (X X)))