Richard Wackerbarth writes:
<snip>
> 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.
Point noted.
<snip>
> > * Accounts Payable/Receivable.
> > Just a transaction report with appropriate accounts selected?
>
> Generally, AR/AP reports summarize the amounts by "age".
>
OK, a transaction report with appropriate sort options.
> > * 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.
>
Perhaps I misspoke. What I am NOT keen to do is provide a
drool-proof "tax report". There are too many jurisidictions, too many
variations in book-keeping styles, and too many other variables.
What I am keen to do is to make things sufficiently configurable that
the other kinds of reports (primarily P&L and perhaps investment
reports), when appropriate accounts are selected, can provide the
correct information.
<snip>
> > *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 ....?"
Yes, that's a good question - how do we track an association between
income and expense accounts and the stock account, where transactions
associated with that stock do not necessarily affect the value of it.
This, however, has implications beyond the reporting system - it's
just as much an engine issue.
> > 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.
>
Yes.
> > 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.
>
OK - again, this is an issue for the engine. Guys - how hard would it
be to add the ability to track this?
> > 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.
Would the ability to build an account hierachy, perhaps using
drag-and-drop on a tree widget, on a report-specific basis be a way to
meet this need? I can see the need - for instance, if you wanted to
account for a specific project you'd want to extract just certain
accounts possibly buried deep in the account hierachy.
------------------------------------------------------------
Robert Merkel [EMAIL PROTECTED]
------------------------------------------------------------
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
