scheduled transactions

Aaron Peromsik aperomsik@mail.com
26 Jun 2001 00:21:26 -0400


Josh Sled <jsled@asynchronous.org> writes:
JS> 
JS> I focused on keeping the GNCFrequency widget as compact as possible,
JS> and I think I've gotten it pretty visually small...
JS> 
JS> But maybe this isn't what you mean when you say too much UI...

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.

JS> This is indeed the idea ... some sort of button/context-menu-item
JS> allowing the user to specify/edit this scheduled transaction, a-la
JS> recurring calendar appointments in Outlook/Evo/GnomeCal.   I think that
JS> both approaches should work... and, in fact, there should be two/three
JS> ways to create recurring transactions:
JS> 
JS> 1. Creation through the as-exists SXEditor UI.
JS> 
JS> 2. Right-clicking on any transaction in a register, which will pre-fill most
JS>    of the data in the as-exists SXEditor, including the template
JS>    transaction[s] and making a guess at the frequency spec.
JS> 
JS> 3. Analysis of existing/historical data; if (2) is going to have the
JS>    logic to guess about the template transaction contents and frequency
JS>    specification, then this should be easy.

OK, cool. I also agree that 3 isn't so much harder than 2; the trick
is in comparing historical transactions to decide how frequent they
should be.

JS> OTOH, instead of opening up the dozen registers involving scheduled
JS> transaction to see what's coming-up to be created, there should be a
JS> single dialog [like the list, but improved] which shows exactly what and
JS> when things will be created... I've thought about ripping the gnomecal
JS> or Evolution week/month-view widgets out for this purpose, but haven't
JS> thought about it too much.

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.

JS> | Instantiation could be a button or just something that happens on
JS> | startup, out to a pre-configurable (not prompted) number of days in
JS> | the future. 
JS> 
JS> I'm thinking that upon startup, a "last-run-date" check is made.  If the
JS> last-run date != today, then we might have scheduled transactions to
JS> create...

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.

JS> If that list is not empty, then we pop up a dialog similar to the present
JS> since-last run dialog.  This would allow the user to:
JS> 
JS> . See the transactions that were automagically created [based on the
JS>   flags in the SXEditor].
JS> . See the transactions that have come due, and will be instantiated;
JS>   these may require variable bindings, and thus the user is to be prompted
JS>   for those values.
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.

JS> | When run, all the automatic transactions would just
JS> | happen, and the manual ones would happen too but with a new "s" value
JS> | in the Reconcile field. "s" transactions would be included in the
JS> | "future" balance but not the "present" / "cleared" / "reconciled"
JS> | balances. 
JS> 
JS> I don't think they should be marked 's'... maybe 'f'... but I think even
JS> more correct is that they are marked 'n', and are indicated as being
JS> in the future because they're past the blue line which denotes 'future'
JS> transactions.

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
online. 'n' is also appropriate for my auto-debited loan payments, and
it would also be appropriate for direct deposit of my
paycheck if it weren't for the little fluctuations in how much tax
gets withheld each period.

Then we have 'c' and 'r' statuses, which have something to do with
when my bank statement reflects the transaction.

But there's a whole other category, which I want to call 's' --
scheduled transactions which haven't been initiated yet in real life. It
has nothing to do with today's date. If I tell my bank's bill payment
system to pay my credit card bill on 05-Jul, I'd call that
'n'. However, my mortgage payment, which I might have scheduled for
20-Jun, didn't get paid until this morning. That's an 's' -- I intend
to pay it, but I haven't paid it yet. This morning when I actually
wrote the check I would have filled in the check number and picked
"Enter" from the context menu, and then it would be converted from 's'
to 'n'. 

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

JS> | I guess the main reason for that whole dialog-nextrun thing is for
JS> | future formula-based transactions. 
JS> 
JS> Not solely.
JS> 
JS> I think it's a good thing that unless the user specifies so, there's a
JS> way for the user to see what the program is about to do, especially if
JS> that's the creation of multiple transactions across multiple accounts in
JS> the books...

OK, then there should be a way to see it, but it should be optional.
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.

JS> But it definitely consolidates the interface if you're about to create
JS> 10 transaction which all need variable bindings [instead of popping up,
JS> say, 10 dialog boxes].

In that case maybe it would be good to have a way to summon this UI
with respect to "overdue" scheduled transactions -- ones which have
status 's' in the register but dates before today. 

JS> | to know what that would look like.) The schedxaction should include
JS> | default values for the variables in the formulae. Those values should
JS> | be used on instantiation, with the option to edit the transaction's
JS> | formula from the register.
JS> 
JS> I view this present variable/formula-based stuff to be an okay, quick, first
JS> step.  I have some more thoughts about how time-dependent transaction-amount
JS> specification should work for effective budgeting, which may push back into
JS> this formula/amount specification [when they're done :)] ... but unless
JS> you/someone picks up extending this, I think I'm going to leave it for now.
JS> 
JS> Also, I like the way the register is... it lists only amounts, which is
JS> the right thing [amounts shouldn't change once the transaction is entered].

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.

JS> This formula business is limited in it's scope/application, and thus I
JS> don't think it should influence the register too much.

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 not fond of complicated entries. For example, several months ago I
simplified my expense account structure because entering my grocery
receipts was taking way too long. Now I usually ignore most of my
subcategories and just file things under Groceries. What I'm getting
at is that if formulaic scheduled transactions don't come with
close-enough values at least 80% of the time, and can't be fixed with
almost no UI, I'll probably stick with plain numbers and fudge them on
entry.

JS> | Of course each sentence above should be preceded by a big fat IMHO,
JS> | but hopefully I'm not the only one who feels this way?
JS> 
JS> No... in fact, I think we're substantially in agreement about how this
JS> should work... it's just not finished, yet. :)
JS> 
JS> I think both interfaces should exist, but the bulk of the UI interaction
JS> can be reduced by pre-filling a lot of the editor UI based on the
JS> 'right-click-to-specify-recurrance' from the register...
JS> 
JS> And once the SX entry/editing is done, the impact on the user should be
JS> minimal [unless they have a large number of variable-requiring SXes being
JS> created all the time].

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

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
the near future, so that (a) I can see at a glance whether my expenses
are exceeding my income, and (b) I can make adjustments to the amounts
or dates of transfers from savings (where my direct deposit goes) to
checking as necessary to keep the bills paid. Currently I am managing
this in a StarOffice spreadsheet by entering all my expected
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.

JS> | One of the things I really like about GNUcash is that we don't have
JS> | a whole separate cumbersome dialog for splits the way Quicken does. In
JS> | that sense I think my suggestions fit with the existing design.
JS> 
JS> I haven't used Quicken, so I don't know exactly what you mean by
JS> this... maybe you can explain a bit more...?

Sure... in Quicken, the register lets you create simple
transactions. You enter the date, check number, category (expense
account), payee, amount. For splits, instead of entering a category
you pick a Split button (there are more than one) which summons a
dialog in which you can enter multiple accounts and divide the
transaction amount between them. You can't see splits in the register,
and extra mouse clicks are wasted summoning and dismissing the split
editor. 

-- Aaron