scheduled transactions

[Josh Sled]

On Sun, Jul 01, 2001 at 03:03:53AM -0400, Aaron Peromsik wrote:

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

Well, I have a couple of ideas about how the UIs could be different... 

For the Editor, I'm thinking that each area of the window is basically
mutually-exclusive WRT editing.  You edit the options, then you edit the
frequency, then you edit the template transaction.  You don't need to see
and sub-section to correctly interpret/edit the other two... so, we can
save a bunch of screen real-estate by making each sub-section ["options",
"Frequency", "template transactions"] a page in a notebook...

As GTK/glade lends itself well to making a change like this, I might do
this soon, unless I get a lot of bad feedback to the idea.

For the Since-Last-Run dialog, we have a couple of issues...

1. It's going to get too big, with all three sections there.
2. It really should have a GL-style register in addition  to the to-create
   clist and variable-entry stuff; you should be able to edit
   the register-like transactions, as you would expect to be able to.
   However, they should still not be placed finally into the books until
   they are correct.
3. The reminders aren't really supported so well...

So, I propose the following...

The reminders section is moved out to a new dialog, containing a list
of the upcoming-for-creation SX reminders.  The user has the option to
select which of these she would like to create immediately [before it's
officially come-due]... these are then moved into the auto/to-created
[as appropriate] list of the since-last-run dialog.

The since-last-run dialog contains two GLs: one for the auto-created
transactions and one for to-be-created transactions.  The to-create GL
shares some horizontal space with the GtkTable which is allowing the user
to input variable bindings, and thus get the template transaction created
according to their desires...

Once all transactions are "valid", the dialog can be dismissed, and the
books are now up-to-date.

Most of this since-last-run dialog talk is relative to the current state
of the since-last-run dialog, which I haven't put in CVS yet...  I'll do
so after sending this mail.

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

This will take a bit more work, but should be possible...

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

Yah... both should be supported... but the since-last-run dialog will be
supported first...

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

Yes, but I believe it's the right thing to do...

The books should contain transactions which exist [or will exist].
If we populate them with some forward-looking set of transactions that
may or may not exist [with split amounts that may or may not be correct],
we've just trashed the books; they no longer reflect reality.

If this is what the user wants [via selecting the "create N days in
advance" option for the SX], then so be it: they've acknowledged and asked
for inconsistency.  But we shouldn't force transactions to be created in
the books w/o the user's direct intervention.

OTOH, the register _should_ contain a forward-looking window of scheduled
transactions, as you say; when viewing the ledger for an account it's
helpful to see upcoming transactions in there.

However, there is a distinction between seeing them in the ledger and
seeing them in the books.

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

Reports, or the Budgeting Workbench/What-If? dialog.  But, again, as this
isn't even close to existing I'll just shut my trap. :)

Actually, reports that knew about SXes would be a great thing.

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

Not really.  I just hope users don't think so. :)

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

Well, these split formulas can't quite do computation, yet, but easily could
[if the variable name matches "\w+\(\w*\)", it's a function invocation;
if the second '\w*' matches anything, they're arguments to the function]..

Then, there's the issue of informing the user that they have this function
library available to them when creating a template transaction, but that's
at some level just a user-reading-the-docs/tip-of-the-day issue.

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

Agreed.

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

Well, check src/doc/TODO-schedxactions ... it is intended to be a complete
list of TODO-functionality.  So if you don't see stuff on there that you
want [or see stuff spec'd incompletely/incorrectly], raise an alarm.

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

Sounds like a challenge to me.... :)  just you wait... ;)

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

Indeed.

...jsled