Predicting Future Minimum Balance

[Josh Sled]

On Thu, 2006-09-14 at 09:59 -0400, Derek Atkins wrote:
> "David Berg" <drberg1000 at gmail.com> writes:
> > The only way I've been able to attempt it is by creating SXs and
> > telling them to be created well in advance.  The problem with this
> > route is if I want to change a series of transactions.  Going through
> > and changing each entry in a series is quite time consuming.  Deleting
> > and recreating them isn't any better.  Is there a way to do this that
> > I'm not seeing?
> 
> Unfortunately no..  Not until someone writes a report to actually
> take unprocessed SXes into account..

This will be incrementally easier with upcoming SX changes that make it
easier to get a model of upcoming transactions independent of any
particular piece of the UI.

The transactions created from an SX do have a KVP frame entry of the SX
that they were created from.  If an SX changed, some new code could
query the (future) transactions that were created from it, and delete
and re-create them.


There's still a bigger issue, though, that there's no easy way to see
the *real* effects of those Transactions without either reimplementing a
bunch of code, or actually creating the Transactions "on the books",
which you generally don't want to do in a reporting context.  In other
words, there's no way to have an "excursion" where you create a bunch of
Transactions then roll them back.  Though I guess we could make such a
beast using the transaction (software, not financial) mechanism of the
engine... but keeping large transactions open doesn't strike me as a
good idea.

In any case, probably a topic to follow up on -devel, at some point.
But, no, there's no way to do what you'd like a present.

-- 
...jsled
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.gnucash.org/pipermail/gnucash-user/attachments/20060914/6866bec9/attachment.bin