On Sun, 02 Jul 2000, Robert Graham Merkel wrote:
> To get a handle on the reporting features
> * Periodic income/expense reports (over a year, by month, for
> example). Don't have, but it's not hard.
The sticky thing here has to do with the generation of reports that
cross accounting periods. We must be able to distinguish, and ignore, entries
which are related to reconciliation or the "closing" of income/expense
accounts.
Remember that the P&L is generated BEFORE the income/expense accounts are
zeroed. The Balance Sheet is generated AFTER the income/expense accounts are
zeroed.
> * 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?
Generally, AR/AP reports summarize the amounts by "age".
> * 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
I totally disagree. To me, this is the ONLY reason to keep the books.
I MUST be able to designate a view of the accounts that gets sorted and
summarized according to the taxman's view.
Basically, look it this way. You may categorize (income or) expenses into any
number of "accounts". However, I need to be able to generate various
different reports by combining those accounts in different ways. Further,
once I have set them up, I need to be able to view new data according to any
of those views.
For example, if I want to compute "Return on Investment", I need ALL the cash
inflows/outflows relating to a stock whether they are "taxable" or not,
"reinvested", etc.
When I sell some, stock/inventory/... I need a different report to allow me
to calculate the allocation of the sale price to COG/basis,
profit/short_gain/long_gain, etc.
At tax time, I need to look at things in yet another way.
There is virtually no value in having a large number of "accounts" if I
cannot automate the summary of those accounts for the purpose at hand.
The way I summarize things has to vary with the purpose.
> * Missing cheques? Not hard to implement, but isn't this what
> reconciliation's for, and does anyone ever use it?
It is used to help make sure that you have not failed to post some expense.
Once the check is posted, the reconciliation report will show the uncleared
cheque. However, it does not catch an expense which is neither cleared nor
posted.
> * Sales tax reports.
>
> 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.
>
> *Investment Income Report
> - All rather complex -
> how can we distinguish
> taxable/non-taxable
> transactions?
They are different "accounts". The real question is "how do I find the
accounts that are affected by activity related to ....?"
> 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?
Tax laws allow multiple ways to compute this. We must be able to designate
the items sold and generate a report of the status of the remainder.
> 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.
It's not a question of gnucash making the decision but rather of it being
able to readily generate the report which reflects that decision.
> We need to be able to specify dates in a relative manner, such as "this
> month" or "current accounting period".
Agreed.
> Quicken defaults to assuming to a FIFO discipline, but lets you specify
> explicitly if you wish.
> According 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.
Only because that is the easiest for them. When you have a large number of
transactions, the utility of simply tracking the total number bought/sold and
the total money exchanged often outweighs the tax implications of tracking
individual items.
> 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.
THIS POINT NEEDS A SIGNIFICANT DISCUSSION.
You seem to imply that there is ONE hierarchy of accounts and that it is
simply a matter of having a few views of the tree.
I argue that it is more complex than that. The set of accounts fall into a
multidimensional space and there is a need to be able to map that space into
the one or two dimensional space of a report in various ways.
For example, look at the mapping of a simple two dimensional report onto a
one dimensional report. For one purpose, I might want it mapped "by row". For
another purpose, "by column" would be the more appropriate mapping.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
