My Money Wish List
[ Home ]


Wish Lists have long been a popular topic of the newsgroup. In no particular, order, here's mine (note that some of them date back more than a decade and still go unfulfilled):

1) Any transaction that can be entered should be able to be scheduled **exactly** the same way. (E.g., I can enter bills and deposits all day long and twice on Sunday with an empty payee--so, why do I have to specify a payee to schedule transactions??? Negative paychecks is another example. You can enter one. You can't schedule one.) This was almost true with M01. M02 and the scheduler redesign broke all of this. Any transaction includes things like Sell Investment. We will not always be in our acquisitive phase. Some Money users already are drawing down savings and investments instead of building them up.

2) Scheduled loan payment should be able to include classification--this was the exception noted above. (This has only been on my list for about a decade. See below.)

3) Find/Replace should be generalized to include the capability to find/replace portions of a memo field. It should also support find/replace on classifications just the same as it supports Categories.

4) The model for scheduling recurrence needs to be vastly improved. Look at Outlook calendar for a better model. Every nth arbitrary unit of time seems pretty obvious as do things like 4th Tuesday of every month and so on. It would also be nice to have a reschedule strategy choice: reschedule on fixed date or fixed interval from most recent instance entered.

5) Performance, performance, and, duh, performance.

6) Improve the integrity of the database: there are still way too many ways for the checks to be printed counter to get out of sync, to get Transaction cannot be entered, Operation cannot be completed, etc. The Nuke-the-Bills repair method is an obvious example of a feature built to get around a failure of the basic program to maintain its own data in both database and business logic sanity. Spurious "negative shares" warnings when entering Buy transactions is another prime example.

7) Continue to improve the repair tools for when previous item still fails. Or get previous item right and quit wasting effort on repair tools.

8) Move beyond QIF and MoneyLink as the only ways to get data in and out and, particularly, the crutch that QIF export is the only way to solve so many problems. Both QIF and MoneyLink have too many limitations. (To name just two: Loan Accounts vs. QIF and Money Link can't get the top transaction of a split with its memo.) Every piece of data that Money can collect the user should be able, somehow, to extract. (E.g., the details for an account or category or classification including the notes. Bill settings like "estimated" and number remaining in a series. Edited series members of a bill series.)

9) (Speaking for others who find themselves here, but not for me:) Improve the interoperability between internationalized versions. At least allow accounts to move even if tax data and so forth gets broken. Provide better data than the spelling of "check" in help to tell one from another.

10) (Speaking for others who find themselves here, but not for me:) Improve the handling of cases like opening a forward level data file (i.e., something more meaningful than the password message like, maybe, "This file was created with a later version of Money and is not backward compatible to this version") and the wrong nationalization ("incompatible version" could read something like "Your existing file was created with Money 1999 for Poland and this is Money 2019 for United States. Money can't deal with this. Get a later version localized for Poland.")

11) Handling of individual transactions or split entries in foreign currencies in addition to just entire accounts would be cool. And I'm not working the bit of entering with an explicit currency conversion where the conversion rate and foreign currency amount is lost forever.

12) Change budgeting to recognize the entirely obvious notion that scheduled transactions are not necessarily in budget. (Of course, this is only relevant if Advanced Budget isn't "disappeared" completely.)

13) Somebody mentioned that it would be nice to be able to associate classification with categories--i.e., Automobile:* category transactions should remind whenever Automobile:* Class is omitted. This would be a nice addition.

14) It should be possible to "close" a category or a classification to remove it from the drop-downs and future use (without an "are you sure?" prompt, like the one for income vs. expense).

15) Money should be capable of simultaneous access to a data file by multiple clients or should, at the very least, refuse to allow it as a preferable alternative to just mangling data files without warning or apology. Many of us now have multiple machines and networks at home. Word and Excel, to name just two, have provided this kind of protection for what, a decade now?

16) It should be possible to add any index investment, not just one from the fixed list.

17) It should be possible to add an investment without creating a position or adding it to the watch account. I can add a category without using it, why not an investment?

18) Money should know how to delete an investment for real (gone forever, not just hidden) if no transactions reference it.

19) Transfer Shares shouldn't break performance reporting.

20) The Investment Cash account portion of an Investment Account should be treated everywhere except the linkage with an Investment Account just like any other cash account. (Favorites, Add/Delete/Close, etc.) With banking reform, increasing numbers of people are able to use them just like, and in place of, regular checking accounts.

21) Return the "Work With an Investment" functionality.

22) (This one added after some discussion with the Money team about the goofy way "unassigned" income or expense works in a split vs. single entry transaction.) Treat, implicitly or explicitly, any unassigned amount in a split the exact same as an uncategorized amount in a single entry transaction.

23) This seems more like a bug fix, but the behavior is probably considered "by [stupid] design": it is just plain goofy to require a number of units to be associated with a scheduled future Investment Buy activity--this implies knowing future investment prices. If we could do this reliably, we wouldn't need to be using Microsoft Money.

24) There shouldn't be restrictions like not being able to create a loan over a year old.

25) Speaking of loans, loans should allow proceeds or funds to be transferred out or in.

Blasts from the past:

(posted 2/13/2001):

How come I can put in predictions (or items not in Money as the case may be) in the tax estimator for Dividends and Interest Income but not for short or long term capital gains? Why is the requirement for being able to put in the out-of-database items any different for the dividends, income, wages, etc than it is for the short- and long-term capital gains?

How does the Money development team make decisions like this? What's easy to code? What the user needs? I need the ability to put in dividend income just exactly the same way I need the ability to put in short- and long-term capital gains.

(posted 8/25/2001--snipped to avoid outright duplication of the above):

…New value-added features:

1) Integrate functionality similar to Morningstar x-ray plus support definition of "looks like" funds for things like captive 401k funds that "look like" other symbols but are not public funds or "look like" indexes or combinations of indexes or similar. This would be an expansion of the existing Details Change Asset Allocation functionality. (For instance, I own a fund that mirrors the Lehman Aggregate Bond index. And another one that is really American New Perspective (ANWPX) but I can't "call" it that for Money since it's not reported in shares and there is an ever-so-slight administrative charge lopped off the top. I've got another one that "invests in four underlying index funds that are designed to track market indices in the following proportions: 50% in the S&P 500 Index, 15% in the Russell Small Cap Completeness Index, 15% in the MSCI EAFE Index and 20% in the Lehman Brothers Aggregate Bond Index." I'd like the ability in Details Change Asset Allocation to tell Money exactly these types of things.)

2) Something like embedded "Savings Bond Wizard" that can value them and track them would be a great improvement over the support for Savings Bonds that exists today.

"Power user" goodies:

1) Some kind of non-cooperative programmatic access. (Generic MonyLink.) (E.g., ODBC or DAO and some "intermediate" queries and stored procedures that can be maintained from version to version whilst you change the real (hidden) internal schema, or a limited object model exposure--but not necessarily automation.) I certainly understand why PSS would be scared to death of this.

2) Improvements in stability, data integrity, fault tolerance, and recovery capability. (E.g., eliminate some of the sources of "damaged accounts" and "corrupted files" as Kimberly and the MSKBs so delicately put it. Also eliminate the "when all else fails, the only solution is to export every account via QIF and import into a new file and then setup all of the many data elements that QIF just can't handle" solution to these "damaged accounts" and "corrupted files." There have to be better ways.)

3) Someone else wrote "Something on my wish list since 1998 has been a way to track data associated with bills, for instance, cellular airtime use so I can figure out which plan to move into, or my water/electricity/etc use so I can analyze change in use vs. change in price. Currently, I use my own predefined grammar in the memo field." I do exactly the same thing and have for years. Some way to add "xml-like" attributes and values (type specification and enforcement would be icing on the cake) to a transaction (or to a scheduled series of transactions) would really be cool; accompanied, of course, by a new report type or extensions of existing reports to collect the data. Then we can export these report values to Excel for real analysis. By way of example, I record "{xxF avg temp, xx days, mm/dd/yy through mm/dd/yy}" in the memo for my gas and electric bill every month and "xx kWh" in the memo for the split for electricity and "xx therms" in the memo for the split for gas.

Not likely but some of us would really like to see:

1) Fix the performance problems created by the M01 feedback and not entirely solved by M02.

2) Reduce the amount of effort, screen real estate, processing time, etc., spent trying to suck us into (fewer "powered by" references, etc.) and related Microsoft initiatives. (E.g., even if any of us really cared about MoneySide, why did you need to tie it into Passport to use a file that isn't even password protected? Why do background quotes and updates require Passport when foreground doesn't? I think it was just to "tie" (in the parlance of the Anti-Trust Division) use of the feature into hooking people into Passport.)

3) Quit manically dumbing it down and adding busy-ness to the UI just to address the top 50 RTFM questions PSS gets each year from the clueless and the challenged. [added this post: like all of the Use Transaction Forms boxes and that infernal Make Recurring box you added in the middle of the Tab Order in M03.] Maybe we need, as someone said, Tools | Options | General | Clueful User Mode.

(posted 8/27/03:)

4) Make the budgeting really useful to people managing their money in real-life scenarios instead of useful to reviewers. Get the sign math right (see other threads) even if we cheat and apply credits to expenses and so on. Come up with some model (not sure what off the top of my head but you are smart people) that enables scheduled transactions to be decoupled from budget. Or just completely decouple them and make the autobudget generator include the prior transactions and the scheduled transactions in generating its recommended budget amounts. Some scheduled transactions are, by any definition, variances to budget. Yes, they should be in cash flow projection. But that doesn't mean they are in budget. Do they let you budget resources at Microsoft by setting budget = plan + history? I doubt it. And, finally, FIX THE STUPID THING TO NEVER INCLUDE AN AMOUNT FROM SCHEDULED TRANSACTIONS UNLESS (NEXT DUE DATE <= END OF BUDGET PERIOD AND NEXT DUE DATE + (NUMBER OF PERIODS REMAINING * LENGTH OF PERIOD) >= START OF BUDGET PERIOD. This seems so painfully obvious. If you do implement these things, feel free for the nth year in a row to claim improved budgeting features. We won't hold it against you.

(originally posted to the CIS MSOFT Applications Money section 9/19/93; reposted to the newsgroup 10/20/02 with excisions for the things that have been solved, but including dupes from above to show my desires have been constant for lo these many years:)

My Money Wish List:

1) Loan Payments ABSOLUTELY need class information for all categories. (E.g., I not only want to categorize it as Automobile:Payments and Interest Expense:Auto Loan Interest but also as class/subclass Automobile:Honda.) ... 4) Once the notion of Projected (generally future) and Actual (generally past) transactions is recognized along with Periodic Cash Flow reporting [more or less treated by Forecast Cash Flow], a way to define values as functions of other values ("Formulas") would be VERY helpful. Projected transactions would recalculate the formula dynamically where Actual transactions would dereference the formula to a value when they "went actual" (e.g., the check was printed or a number was assigned or the date passed or the user converted it from Projected to Actual.) (E.g., I'd like to define a future credit card payment as $200 or 5% of the balance at the time of payment. Or, I'd like to define future quarterly savings earnings as (4.25%/4) of the balance. Or, I'd like to define my future salary splits to include the notion that once the balance on Social Security exceeds the present maximum contribution, this value goes to 0.) ("Formula Entry")

How to do this and maintain "elegant simplicity" for the un-sophisticated target users might be a problem. Basically I see this implemented as some definitional language to describe portions of transactions or account specific values (with words like "Present Balance of xxx Account" or "Gross Pay of this Transaction" or "Balance of Account xxx at End of Previous Month" or "Balance of Account xxx on 25th day of Previous Month") and some Excel-like formula/function language where a value can be either a constant value (which Money already does) or a formula (=MAX($200,5% Present Account Balance)). It would also follow that more information would need to be stored with an account such as periodic interest rate, periodic service charge, minimum payment, etc. Of course, these also tend to be either constants or formulas as well. Another ramification is that some values displayed/reported would be "actual" and some would be "projected" and this poses some potential issues. One way to deal with this would be to always show Actual values (those that are truly Actual and those that are computed solely from Actual values) in a regular font and Projected values (those that are projected or are computed from a Projected value) in an italic font. Coupled with Periodic Cash Flow analysis as outlined above, this would really move Money out in front of the competition by positioning it as much more of a planning/forecasting tool than just an automated register with some budgeting capability. (Budgeting is strategic; Periodic Cash Flow analysis is tactical.) Now that you've got some market share you can afford to be different from Quicken.

5) It follows that "percentage splits" (which Money badly needs) would then be a specific case of the "Formula Entry" abstraction. In addition, there needs to be a way to do nesting of splits. My case is this: I get paid and percentages of the gross both pre- and after-tax are transferred to a 401K/savings plan and invested in various investments according to percentage allocations. Right now, I have to compute all of the constant values out by hand (the pre- and after-tax amounts and then the investment account allocations from the sum of the pre- and after-tax amounts) before entering it in Money, then create a holding account to accept the pre- and after-tax contributions as transfers, then transfer the total value just put into the holding account from the pre- and after-tax splits of the paycheck into the investment plan accounts. This is a PAIN. It would be much easier to allocate 17% of the gross to a split that I then split 80% pre-tax and 20% after tax that I then split 50% to account A, 30% to account B and 20% to account C and 100% to account A respectively. (Still rather gross, admittedly…)

…[Investment accounts were added]…

7) Do more with Credit Limit information for Credit Card Accounts, even if just one more box showing credit available on the Account Book window. Ideally, this information could also be shown along with account balance all places where account balance can be shown. Maybe also an Options Settings selectable warning box for getting close or going over. Right now I don't think you're really doing much of anything with the information.

8) DDE/OLE would be a good addition and could substitute for some more specific Excel affinity (direct export/import as opposed to via text) which would also be helpful.

9) One final, rather dreamy, item: (this would really complicate the database problem, but) I'd really like to be able to record additional amounts of Account or Category specific numeric or text information (a good use for "objects") with a transaction for later manipulation. (E.g., I'd like to record miles and gallons for gasoline purchases to later compute and track and trend and graph MPG by class/subclass. I'd like to be able to record Gallons on water bill payments. I'd like to be able to record CCF and kWh from natural gas/electricity utility bills. Get the idea?) ("Extensible Data Collection")

To help solve the un-sophisticated target user problem, many of these notions could be "transparent extensions" documented in a separate book/set of help screens/"Full Menus" leaving the base product apparently simple. For instance, "Formula Entry", DDE/OLE, and "Extensible Data Collection" could all be in this category and the un-sophisticated user never need know they are there.

Or, you could just provide "Extensible Money" as a pre-packaged Access database!

Fine Print


Last update: 30 March 2009

If this kind of stuff is important to you:

Valid XHTML 1.1

Valid CSS!