are scheduled/recurring transactions ignored by reports?

[Matt Price]

On Wed, 2009-02-25 at 09:17 +0000, Fred Bone wrote:
> On 24 February 2009 at 22:56, kevinfishburne said:
> 
> > 
> > I think this post
> > 
> > http://www.nabble.com/Beginner-help%3A--budgets-and-scheduled-transactions
> > -td22123915.html#a22123915
> > 
> > may have been asking the same question, but to make sure I thought I'd
> > phrase it differently. Do any of the reports take scheduled transactions
> > into account? Any report I run shows the actual scheduled transaction (the
> > one I entered manually prior to scheduling it), but not the future
> > occurrences of it within the report's specified date range.
> > 
> > If this is the case, has anyone written or modified an existing report so
> > that it is capable of using scheduled transactions? Having no practical
> > way to project one's finances into the future would cripple an otherwise
> > fantastic program.
> 
> The reports show the transactions that are present in the ledger. There 
> are doubtless several reasons for this, but the killer that springs to my 
> mind is this: scheduled transactions will often be variable, either in 
> amount or date.
> 
> Would you really want to have to supply variable data for a collection of 
> scheduled transactions *every*single*time* you run such a report?

> 

I think I was trying to ask the same question in that earlier post,
though Kevin frames it better.  I don't know what Kevin's motivation is,
but mine is simple -- I'm trying to forecast my family's budget for the
next 12 months  or so, and to do that I need an approximation of what
our expenses and income are.  For this relatively unsophisticated
forecast, I don't need to know in advance the exact amounts I'll need to
pay -- my estimates are sufficient.  So I'd also really like to hear if
someone has written a modified report that takes scheduled transactions
into account.  

I guess just using a spreadsheet would be one option, but I'd hate to
have to keep track of two datasets instead of just one.

m
-- 
Matt Price
matt.price at utoronto.ca