scheduled transactions
Josh Sled
jsled@asynchronous.org
Sat, 30 Jun 2001 22:51:25 -0700
On Tue, Jun 26, 2001 at 12:21:26AM -0400, Aaron Peromsik wrote:
| At work, in completely unrelated software, we often focus on the
| number of mouse clicks required to perform common tasks as a measure
| of usability.
Noted... I'd be interested to see your report on how
GnuCash::ScheduledTransactions fares in this study... [ :) ]
| That's useful, but having things in the register in advance is
| differently useful. As for getting it all in one place, that can be
| done in "general ledger" mode. Not that the dialog is not useful --
| I'd be happy to be able to see things both ways.
That's a good idea; I think the dialog is an appropriate first step,
but that entry via the dialog should feed into the GL so that the user
can make sure that what's about to be created [read: placed in the books]
is correct...
| I'm with you so far, except for the today part. I want to pre-enter
| transactions 30 or 60 days ahead for planning purposes.
Okay... so some version of the current "create SXes for some date
into the future" dialog will want to persist for something other than
debugging... I'll work this in.
| JS> . Maybe, allow the user to select which SXes to defer the creation of.
| JS> I'm undecided on this functionality...
|
| I'm not! This is the whole reason I want the 's' status on a
| transaction. I'll explain below.
I think I'm talking about something slightly different, here.
When I say "defer the creation of", I'm thinking that a particular SX
comes due [utilities bill], but you haven't actually received the bill
yet [the DOM is a Saturday, and you'll get the bill on Monday]... so you
defer it's creation such that it will keep coming up as 'to-be-created'
ea. time you start GnuCash, until you actually have the facilities to
create it [the bill, with the correct amount].
| As far as I'm concerned, 'n' means I have initiated a transaction,
| either by writing a check and mailing it, or performing a transaction
[deletia]
| With this setup, there's no reason for "deferred creation" as you put
| it. "Automatic" transactions go in as 'n', and "manual" transactions
| go in as 's'.
Well, from an implementation and storage standpoint, I think there is
still a reason for deferred creation...
As far as I see and understand what you're saying, there's no call to
interact with the 's' transactions in the register... they're there until --
as you say -- you actually write the check; at that time they're created,
and you fill in the check number and appropriate amount.
Up until that time, many things might change. You may change the frequency
or the parameters of the SX. Instead of going through the books, removing
these 's'-status actual transactions, and creating the new ones, I think
it makes more sense to not have created them at all.
This is not to say that they won't appear in the register... the register
should show a user-configurable window of future transactions... but I
think they're not marked 's' so much as they have a ' '/null-reconciliation
field: they're not [yet] transactions, and they don't exist in the books.
However, this would not be appropriate for you, if you intend to run
reports over future transactions... [?].
| What I actually want is for gnucash to enter all my scheduled
| transactions in the register 30 to 60 days in advance. I don't want to
| be prompted. At the point of converting 's' to 'n' is when I want to
| be specifying values.
Noted... I think I'll be able to work this in, though it's a major
difference from how I was thinking that scheduled transactions would be
used; this is good.
I'm thinking that this is analagous to creating transactions which have
come due since the last run and today... now, it's creating transactions
which have come due since the last run and today, but N days out in
the future. In both cases, the 'last_occur' date and the 'last_run'
dates are valid... just shifted per the SX-configurable "create N days
in advance" option.
I'm starting to fear that the creation-policy options will be too
cumbersome... I'll code it up and we can see how much is there at the end,
and then make the tough decision about which policy to ignore.
| That's fine... I just meant that when a transaction in the register is
| still 's', a right-click menu could summon a dialog for fiddling with
| the variables.
Yes... indeed.
| I think it may be useful for loan payments. For that case I probably
| would almost never change the precomputed values. I'm not sure what
| else it's good for, maybe you can enlighten me?
I'm thinking multiple roommates... I'm an out-of-college renter with two
roommates. I pay the bills and subsequently bill my roommates; to this
effect, I have an "Assets:Money Owed to Me" account for each roommate.
When I get a bill, it goes into splits like the following:
Description Account Credit Debit
----------- ------------------------------------- ------ -------
PG&E Assets:Cash On Hand:BofA Checking $150.00
Utils Expenses:Rent & Living:Gas & Electric $50.00
Roommate1 Assets:Money Owed to Me:Roommate 1 $50.00
Roommate2 Assets:Money Owed to Me:Rommmate 2 $50.00
Thus, the scheduled, template transaction looks like:
Description Account Credit Debit
----------- ------------------------------------- ------ -----
PG&E Assets:Cash On Hand:BofA Checking x
Utils Expenses:Rent & Living:Gas & Electric x/3
Roommate1 Assets:Money Owed to Me:Roommate 1 x/3
Roommate2 Assets:Money Owed to Me:Rommmate 2 x/3
When I get the bill, I only have to enter one amount [x, right off the
bill], and the 4 splits will be correct and entered.
This becomes more important with things like the phone bill, where I pay
my equal share of the base cost, but my roommates exclusively use the LD
service... and the internet is split amongst the roommates and downstairs
neighbors [long cat5 is fun :)], a non-living-here third party who uses
a good chunk of bandwidth... this can then be:
Desc Credit Debit
------------- ----------------------------------- -----------------------------------------------
Phone Company base + (rm1_ld_share + rm2_ld_share) + internet
Me base/3 + internet/8
Roommate1 base/3 + rm1_ld_share + internet/8
Roommate2 base/3 + rm2_ld_share + internet/8
Neighbors internet/8
Third-party internet/2
I know another user will likely make use of this for his loan repayment,
which he seperates out into splits for the interest and principal payments.
Once the formulas can contain functions, this becomes auto-calculable;
however, I doubt this is a first-cut feature...
| I'm not fond of complicated entries. For example, several months ago I
[deletia]
| almost no UI, I'll probably stick with plain numbers and fudge them on
| entry.
As is always an option...
| Yes, we are essentially in agreement about this. However, entry of
| future transactions and the 's' status is more important to me. More
| details of how I intend to use them are in this old posting:
|
| http://www.gnumatic.com/pipermail/gnucash-devel/2000-November/001579.html
Ahh... I remember that post... and it did influence my targets for this,
though it may not be apparent in the code right now... but there's still
plenty left to do.
| What I intend to gain from pre-entering scheduled transactions in the
| register is to know what my key accounts' balances are likely to be in
[deletia]
| transactions there. But I don't think that's the intended meaning of
| "double-entry accounting--" I want to do it all in one place.
"double-entry accounting"... heh...
I hope that the budgeting stuff will ultimately be more useful than the
use of scheduled transactions for this, but that's in the future...
| Sure... in Quicken, the register lets you create simple
[deletia]
| transaction amount between them. You can't see splits in the register,
| and extra mouse clicks are wasted summoning and dismissing the split
Ick. *shudder*
...jsled