scheduled transactions

[Josh Sled]

On Mon, Jun 25, 2001 at 12:13:11AM -0400, aperomsik@mail.com wrote:

| I've been playing with the scheduled transactions in CVS for a bit.
| I couldn't get the instantiation UI to actually create transactions in
| the specified accounts. Am I missing something, or is this just not
| supposed to be working yet? Still, it's good to start seeing some code.

I've seen it create the transactions, but I haven't thoroughly played with
it; it's definitely not finished.  I think it'll have a big problem with
'once' transactions.

My present tree [which I hope to ./make-gnucash-patch tonight] has
many fixes for recurrance-frequency state saving/restoring from the UI,
which allows me to better play around and test the since-last-run stuff,
which is the next big thing to do... I hope to get to this tonight,
but it doesn't seem highly probable... probably next weekend.

| My initial impression is that I think you have way too much UI.

I like UI. ;)

More seriously, I like visibility.  I want a single dialog which shows me
all the relevant info about a thing, in this case the scheduled transaction
object.  I don't want to cram the editing functionality into the register,
as there's just a different thing going on: you're trying to deal with
this abstracted-transaction which has some not-fixed transaction data,
a recurrance frequency, a start and end date, and a couple of options
about the further handling and creation of it.

I focused on keeping the GNCFrequency widget as compact as possible,
and I think I've gotten it pretty visually small...

But maybe this isn't what you mean when you say too much UI...

| The scheduled transaction dialog needs to exist for editing, but I
| don't think it shouldn't be the primary way to create scheduled
| transactions. I'd like to see the Duplicate button in the register
| copy the selected transaction to the schedule and pop up the
| schedxaction editor to allow the user to specify the frequency.

This is indeed the idea ... some sort of button/context-menu-item
allowing the user to specify/edit this scheduled transaction, a-la
recurring calendar appointments in Outlook/Evo/GnomeCal.   I think that
both approaches should work... and, in fact, there should be two/three
ways to create recurring transactions:

1. Creation through the as-exists SXEditor UI.

2. Right-clicking on any transaction in a register, which will pre-fill most
   of the data in the as-exists SXEditor, including the template
   transaction[s] and making a guess at the frequency spec.

3. Analysis of existing/historical data; if (2) is going to have the
   logic to guess about the template transaction contents and frequency
   specification, then this should be easy.

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

| Instantiation could be a button or just something that happens on
| startup, out to a pre-configurable (not prompted) number of days in
| the future. 

I'm thinking that upon startup, a "last-run-date" check is made.  If the
last-run date != today, then we might have scheduled transactions to
create...

If that list is not empty, then we pop up a dialog similar to the present
since-last run dialog.  This would allow the user to:

. See the transactions that were automagically created [based on the
  flags in the SXEditor].
. See the transactions that have come due, and will be instantiated;
  these may require variable bindings, and thus the user is to be prompted
  for those values.
. Maybe, allow the user to select which SXes to defer the creation of.
  I'm undecided on this functionality...

| When run, all the automatic transactions would just
| happen, and the manual ones would happen too but with a new "s" value
| in the Reconcile field. "s" transactions would be included in the
| "future" balance but not the "present" / "cleared" / "reconciled"
| balances. 

I don't think they should be marked 's'... maybe 'f'... but I think even
more correct is that they are marked 'n', and are indicated as being
in the future because they're past the blue line which denotes 'future'
transactions.

| A right-click menu item ("Enter" ?) could convert "s"
| transactions to "n". It would be nice if the "s" transactions showed
| with a different background color -- say, light blue as the default.

Yes... I was planning on this [right-clicking on future transactions in the
register to instantiate them]... check src/doc/TODO-schedxactions.  I like
the idea of a differently-colored background for doesn't-yet-exist items.

| I guess the main reason for that whole dialog-nextrun thing is for
| future formula-based transactions. 

Not solely.

I think it's a good thing that unless the user specifies so, there's a
way for the user to see what the program is about to do, especially if
that's the creation of multiple transactions across multiple accounts in
the books...

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

| to know what that would look like.) The schedxaction should include
| default values for the variables in the formulae. Those values should
| be used on instantiation, with the option to edit the transaction's
| formula from the register.

I view this present variable/formula-based stuff to be an okay, quick, first
step.  I have some more thoughts about how time-dependent transaction-amount
specification should work for effective budgeting, which may push back into
this formula/amount specification [when they're done :)] ... but unless
you/someone picks up extending this, I think I'm going to leave it for now.

Also, I like the way the register is... it lists only amounts, which is
the right thing [amounts shouldn't change once the transaction is entered].

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

| Of course each sentence above should be preceded by a big fat IMHO,
| but hopefully I'm not the only one who feels this way?

No... in fact, I think we're substantially in agreement about how this
should work... it's just not finished, yet. :)

I think both interfaces should exist, but the bulk of the UI interaction
can be reduced by pre-filling a lot of the editor UI based on the
'right-click-to-specify-recurrance' from the register...

And once the SX entry/editing is done, the impact on the user should be
minimal [unless they have a large number of variable-requiring SXes being
created all the time].

| One of the things I really like about GNUcash is that we don't have
| a whole separate cumbersome dialog for splits the way Quicken does. In
| that sense I think my suggestions fit with the existing design.

I haven't used Quicken, so I don't know exactly what you mean by
this... maybe you can explain a bit more...?

Cheers...
...jsled