+
++ More account types + Introduce more 'fundamental' account types: (ammortized) Loan, + Mortgage, ESOP, House, Line of Credit. +
++ Bank name in combo-box pull-down + When user enters a new bank name, should be presented with + a combo-box listing other bank-account names ... + (note this may require implementation of engine callbacks + so that relevent code can be informed when there are new + bank names?) +
++ Currency Selection Popup + Currency field should get preplaced by menu of long-hand + currency names, three-letter ISO abbreviations, and symbols. + User should be able to add new currency types. + Should also keep a static exchange-rate table. +
++ Popup Calculator + All price/amount fields should pop up a calculator widget; + output of calculator gets entered in field. +
++ Popup Calender + All date fields should pop up a calender widget; + selected date should get entered in field. +
++ Register View + Allow user to view only non-reconciled transactions ... +
+Wizards/Context sensitive help. @@ -944,6 +1007,11 @@ we've been, and where we're going. multiple charts ...
+Status: +
This should be handled by having a way of bouncing out - to some Guile code to generate transactions with computed - values. -
-+ Retirement Savings Plans often do not put a high priority on tracking costs, as the tax implication is that amounts are taxable upon withdrawal, meaning that there is little - necessity to track capital gains. + necessity to track capital gains. (huh??) +
+
@@ -1087,31 +1145,107 @@ we've been, and where we're going. -+ Design requirements: implement multiple (not just two) alerts + for any account type. Alert should consist of (1) value point + or price point, (2) movement direction (3) 'is active' boolean + flag (i.e. Should be possible to 'turn off alert' without + deleting it) (4) memo text. +
+Status: -
Add support for automatic, recurring transactions, - e.g. mortgage payments, fixed-interest bonds, bank - accounts, etc.
+Note that the design for this could be very different, - depending on whether the multi-user functions are available - or not.
+Design/implementation for this is tricky. It should - probably leverage crontab, but this can lead to - difficulties and bugs.
++ Loans & mortgages are one of the more complicated recurring + transactions. Consider the following dialogue layout: +
+loan amount $_____________ currency _________ (pull-down menu) +Remaining balance $___________ +Payment amount $___________ +balloon payment $_____________ +other payment $________ (e.g. escrow, tax) +Payment frequency (weekly/monthly/bimonthly/quarterly/yearly) +loan start date mm/dd/yy length -----(weeks/months/years/peyments) +loan time left (number of days/weeks/months, rounded) +number of payments left +interest rate %__________________ +payee ____________ +pay-from account __________________ +next due date mm/dd/yy ++ Note that in the above, not all fields are independent: + some can be calculated from others. + The other payment should bring up a mini-register, + allowing user to add any number of splits. + +
+ Recurring bills, salary income, etc. are simpler to handle, + since they don't have intersest rates, balloons, etc. They + do/will have multiple splits (e.g. payroll gross, fica, futa, + income taxes, payroll net). +
++ Provide a calender-display of upcoming & past scheduled + payments. Clicking on a calander day should raise up + editable list of transactions. Calendering should include + generic red-lettering of important dates: taxes due, + insurance renewal dates, domain registration renewal dates, + ISP contract expiration date :-). These may or may not + be associated with transactions. Memoes should be possible. + Popups should happen when dates get close. Technology: + need to find/evaluate gnome-calender/dayplanner for + integration. +
++ Provide list of upcoming & recently paid bills/scheduled + payments/scheduled deposits for the next 1,2,3,6,12 months. + Historical view shows payments crossed out (!?) +
+Design Notes: + Most alerts & data storage should be driven out of the engine. + This will enable multi-user, distributed use. + Note: alerts should be piggy-backed on a general alert + infrastructure within the engine, viz, registered callbacks + when balances change, so that windows can be redrawn. + Not clear on if/how calander events might be server-ified. + (On the other hand, a good calander should be server-ified, + and thus viewable by secretaries, co-orkers, etc.) +
+More complex financial instrucments may need a guile-based + extension mechanism to compute values .... simple + interest/mortgage calculators should be done in C in + the engine ...
May need interfaces to email for emailed alerts.
- -Interfaces into calendaring systems? +
Plot forcast graphs based on scheduled income & opayments ... + is this tied into budgeting ????
Status: