Predicting Future Minimum Balance

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Predicting Future Minimum Balance

David Berg
I have an account with very predictable deposits and withdrawls.  I'm
looking to enter the transactions and look down the road several
months to make sure that the balance doesn't go negative or get too
large.  Is there a good way to do this in GnuCash 2.0.1?

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?

--Dave
_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: Predicting Future Minimum Balance

Derek Atkins
"David Berg" <[hidden email]> writes:

> I have an account with very predictable deposits and withdrawls.  I'm
> looking to enter the transactions and look down the road several
> months to make sure that the balance doesn't go negative or get too
> large.  Is there a good way to do this in GnuCash 2.0.1?
>
> 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..

> --Dave

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: Predicting Future Minimum Balance

Josh Sled
On Thu, 2006-09-14 at 09:59 -0400, Derek Atkins wrote:

> "David Berg" <[hidden email]> 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}`

_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Predicting Future Minimum Balance

Derek Atkins
Josh Sled <[hidden email]> writes:

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

It might be interesting to have an API that gives us "virtual"
transactions so we can report on them even if they don't appear in the
registers.

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

yeah..

> ...jsled
> http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`

-derek
--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: Predicting Future Minimum Balance

Dale Alspach
A crude approach would be to just clone the gnucash data file (and
ancillaries) under a new name, run the SX or other "what if" transactions on
the clone, do reports on the clone, save the report output if desired, and
then blow all of the cloned stuff away until the next "what if" session.

There could just be a "what if" menu choice which does all the cloning.
Maybe there could be a color change (border, backgrounds?) to visually show that the user is no
longer working  on the real file. When the user wants to end the "what if",
he is asked what to save and then gnucash destroys the files from the
clone or renames as directed by the user.


Dale Alspach


_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
Reply | Threaded
Open this post in threaded view
|

Re: Predicting Future Minimum Balance

Brian Dolbec
On Thu, 2006-14-09 at 13:20 -0500, Dale Alspach wrote:

> A crude approach would be to just clone the gnucash data file (and
> ancillaries) under a new name, run the SX or other "what if" transactions on
> the clone, do reports on the clone, save the report output if desired, and
> then blow all of the cloned stuff away until the next "what if" session.
>
> There could just be a "what if" menu choice which does all the cloning.
> Maybe there could be a color change (border, backgrounds?) to visually show that the user is no
> longer working  on the real file. When the user wants to end the "what if",
> he is asked what to save and then gnucash destroys the files from the
> clone or renames as directed by the user.
>
>
> Dale Alspach
>

What about a graph with time for the x axis and value the y.  Of course
that would go along with the budget data so that anything future dated
would use the budget data along with non-dupe sx's.

--
Brian Dolbec <[hidden email]>

_______________________________________________
gnucash-user mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.