scheduled transactions

[Joshua Sled]

I've been focusing recently on scheduled transactions, since that's what
people more seem to want [more than budgeting], and the budgeting stuff
should make use of a seperable scheduled-transaction subsystem.  My hope
is that soon/eventually, someone else will finish/polish/maintain the
scheduled transaction stuff while I focus on budgeting...

In any case, this is what I'm thinking...  feedback, esp. about the hacky
"date-anchor" structure, is appreciated.  It's expected that there will
be some set of functions like findComeDueTransactionsSince(time_t) and
isSXactionDueOnDate( ScheduledTransaction, time_t ) used to deal with
the Frequency structure...

/**
 * Updated frequency enum.
 *
 * The financial-calculator also has a notion of:
 *  . tri-annual
 * which may make an appearance later...
 *
 * For each element of the frequency enum, we must have some set of
 * anchors from which to compute the new date.
 *
 * daily       : N/A
 * weekly      : { 0==sun, .., 6==sat }
 * biweekly    : start day of month
 * semi_monthly: first, second days of month
 * bi-monthly  : day of month
 * monthly     : day of month
 * quarterly   : start month,day in year \
 * semi_yearly : first month,day in year  } [watch out for leap day]
 * yearly      : day of year             /
 **/
enum FrequencyEnum {
  DAILY,
  WEEKLY,
  BI_WEEKLY,    // strict 2-week
  SEMI_MONTHLY, // strict twice a month.
  BI_MONTHLY,   // every other month
  MONTHLY,
  QUARTERLY,
  SEMI_YEARLY,  // 6-month
  YEARLY,
};

struct Frequency {
  FrequencyEnum	freq;

  /**
   * The dateAnchor anchors the dates to determinable days.
   *
   * DAILY: N/A
   * WEEKLY: dateAnchor[0] contains 0..6 [sun-based]
   * BI_WEEKLY: dateAnchor[0] contains the first date-of-month.
   * SEMI_MONTHLY: dateAnchor[0] contains the first date-of-month,
   *   dateAnchor[1] the second.
   * BI_MONTHLY,MONTHLY: dateAnchor[0] contains the date-of-month.
   * QUARTERLY: dateAnchor[0] contains the first year-in-month,
   *   dateAnchor[1] contains the date-in-month.
   * SEMI_YEARLY: dateAnchor[0] contains the first year-in-month,
   *   dateAnchor[1] contains the date-in-month.
   * YEARLY: dateAnchor[0] contains the year-in-month, dateAnchor[1]
   *   contains the date-in-month.
   **/

  int[2]	dateAnchor;
};

/**
 * A single scheduled transaction.
 *
 * Scheduled transactions have a list of transactions, and a frequency
 * [and associated date anchors] with which they are scheduled.
 *
 * Things that make sense to have in a template transaction:
 *   [not] Date [though eventually some/multiple template transactions
 *               might have relative dates].
 *   Memo
 *   Account
 *   Funds In/Out... or an expr involving 'amt' [A, x, y, a?] for
 *     variable expenses.
 *
 * Template transactions are instantiated by:
 *  . copying the fields of the template
 *  . setting the date to the calculated "due" date.
 *
 * We should be able to use the GeneralLedger [or, yet-another-subtype
 * of the internal ledger] for this editing.
 **/
struct ScheduledTransaction {
  Frequency	freq;

  /**
   * The template transactions.
   **/
  GList /* <Transaction *> */	*templateTrans;
};


/**
 * Integration possibilities:
 *
 * . create files/interface for scheduled transaction data structs.
 *   . structs
 *   . interface suitable for UI
 *   . programatic interface
 * . user configuration:
 *   . show future scheduled transactions?
 *     . scheduled transaction post-blue-line window
 *   . auto-instantiate scheduled transactions?
 * . some "since-last-run" UI for instantiating scheduled
 *   transactions.
 * . create stand-alone UI for scheduled transactions.
 * . register modifications for scheduled transactions.
 *   . register indication of recurring/scheduled transaction.
 *   . post-blue-line display
 *   . instantiation of pre/post-blue-line scheduled transactions
 **/