scheduled transactions

Aaron Peromsik aperomsik@mail.com
01 Jul 2001 03:03:53 -0400


Josh Sled <jsled@asynchronous.org> writes:

JS> On Tue, Jun 26, 2001 at 12:21:26AM -0400, Aaron Peromsik wrote:
JS> 
JS> | At work, in completely unrelated software, we often focus on the
JS> | number of mouse clicks required to perform common tasks as a measure
JS> | of usability.
JS> 
JS> Noted... I'd be interested to see your report on how
JS> GnuCash::ScheduledTransactions fares in this study... [ :) ]

Well, I don't exactly have a report yet, but my initial reaction was
"too many clicks." However based on our subsequent discussion I've
gathered most of them will eventually be optional, so hopefully we
should be OK when you're finished.

JS> When I say "defer the creation of", I'm thinking that a particular SX
JS> comes due [utilities bill], but you haven't actually received the bill
JS> yet [the DOM is a Saturday, and you'll get the bill on Monday]... so you
JS> defer it's creation such that it will keep coming up as 'to-be-created'
JS> ea. time you start GnuCash, until you actually have the facilities to
JS> create it [the bill, with the correct amount].

I can see that this is something that some people will want. However,
for my own use, I think it would take fewer clicks to have the
transaction shown in the register already with the initial
estimate. When the actual bill shows up I can fix the date and amount
and then "enter" the transaction for real.

I guess it's partly a philosophical issue... some people want dialogs
saying "I'd rather you didn't do anything else until you deal with
this bill, unless you'd rather defer it." I'm happier with an entry in
the register highlighted in blue so that I remember I have to do
something about it, but I don't have the system nagging me with a
blocking dialog. 

JS> As far as I see and understand what you're saying, there's no call to
JS> interact with the 's' transactions in the register... they're there until --
JS> as you say -- you actually write the check; at that time they're created,
JS> and you fill in the check number and appropriate amount.

Right, but I want to do that directly in the register, with a minimum
of extra UI.

JS> Up until that time, many things might change.  You may change the frequency
JS> or the parameters of the SX.  Instead of going through the books, removing
JS> these 's'-status actual transactions, and creating the new ones, I think
JS> it makes more sense to not have created them at all.
JS> 
JS> This is not to say that they won't appear in the register... the register
JS> should show a user-configurable window of future transactions... but I
JS> think they're not marked 's' so much as they have a ' '/null-reconciliation
JS> field: they're not [yet] transactions, and they don't exist in the books.

Are you saying that the register will have additional functionality
for display scheduled transactions that don't exist yet and are not in
the database? That sounds like considerable extra work.

My gut feeling is that, if you have a field associated with 's'
transactions telling which SX it came from, then implementing the
process of ripping them out and replacing them when an SX's parameters
change will be easier than implementing support for phantom entries in
the register.

JS> However, this would not be appropriate for you, if you intend to run
JS> reports over future transactions... [?].

I *don't* have plans to run reports over *future* transactions, but if
the right report came along it could suddenly become useful. However,
's' transactions in the past, where I haven't quite paid yet but maybe
should have, really ought to be in reports if I am using reports to
decide whether I can afford a new whatever.

JS> I'm starting to fear that the creation-policy options will be too
JS> cumbersome... I'll code it up and we can see how much is there at the end,
JS> and then make the tough decision about which policy to ignore.

I'm not sure I follow... are you saying you think we're coming up with
too many configurable options relating to creation policy?

Dividing them up into things you'd want to do differently per
transaction vs global system preferences (per gnucash file) may help
a bit. I don't think having too many of the latter kind is a problem
since most people will configure those exactly zero or one time(s).

JS> I'm thinking multiple roommates...

Interesting.

JS> I know another user will likely make use of this for his loan repayment,
JS> which he seperates out into splits for the interest and principal payments.
JS> Once the formulas can contain functions, this becomes auto-calculable;
JS> however, I doubt this is a first-cut feature...

I expect that a much greater number of users will find this useful
than the formula stuff. As evidence, Quicken autocomputes loan
payments, but doesn't have the formulaic splits like the ones you
describe at a user-editable level.

Just something to keep in mind. I know you'll implement the stuff you
need first, since that's the name of the open-source game, but if LDP
wants to make money off this then they should keep in mind that
handling loan payments might be seen as pretty basic missing
functionality vs the competition.

JS> Ahh... I remember that post...  and it did influence my targets for this,
JS> though it may not be apparent in the code right now... but there's still
JS> plenty left to do.

OK, just checking... as you say, it's not obvious yet, but I don't
mind that if it's temporary.

JS> | What I intend to gain from pre-entering scheduled transactions in the
JS> | register is to know what my key accounts' balances are likely to be in
JS> [deletia]
JS> | transactions there. But I don't think that's the intended meaning of
JS> | "double-entry accounting--" I want to do it all in one place.
JS> 
JS> "double-entry accounting"... heh... 
JS> 
JS> I hope that the budgeting stuff will ultimately be more useful than the
JS> use of scheduled transactions for this, but that's in the future...

I've mentioned before that Quicken's budgeting takes way too much work
to get any reasonable info out of. No offense, but I don't expect
yours to be too much better. It's hard to do the computations without
specific data, and yet when you go to make assumptions based on
previous data, you're bound to get something wrong that I'll have to
fix before your outputs are useful.

Fortunately, I think the use of scheduled transactions will be
sufficient for my needs.

-- Aaron