4

I want to create a financial planning application (for personal use), for which the overall functionality will be this:

  • User (me..) can create different 'scenarios'.
  • Each scenario is configured with different incomings/outgoings.
  • Scenarios can be 'explored' in a calendar format with projections taking into account tax, interest (on both debt and savings) and so on and so forth.

My problem lies in how to fundamentally approach the project.

I've considered:

  • When creating incomings/outgoings for a script to apply them to each day in a 'days' table of a database, acting as a method of caching. This means that if I wanted to look at January 14th, 2074 there aren't thousands of cycles of calculations to run through and the result can just be pulled.
  • Do each calculation dynamically, but again, I'm finding it hard to visuallize how I would handle different tax allowances (I'm based in the UK by the way), payrises and 'changes' to my incomings/outgoings.

I've sat on this for a couple of days and am struggling to come up with an elegant approach to my problem.

There may well be software out there that does what I'm looking to do (in fact I'm sure it is) but I would like to develop this myself for learning purposes, to be able to add it to my personal life 'toolset' and to allow me to expand on it in the future.

Many thanks to all who have any input on my dilemna.

Anonymous
  • 3,546
  • 2
  • 25
  • 26
  • How detailed data do you need? (Daily, weekly, monthly, yearly?) What are the storage implications (calculating, storing, looking up, etc.) of storing all that data for each scenario? How long do the calculations take to run? (If I was looking for a projection 60 years out, I would be willing to wait a little while to get it.) – user Nov 15 '11 at 10:43
  • A daily view on a calendar, I'm not sure of storage implications or how long calculations may take on the fully-fledged model I have in mind. Given that it's a personal application, waiting time probably won't be an issue providing nothing times out... – Anonymous Nov 15 '11 at 11:06
  • It sounds like you will have one formula with many inputs that calculates your net worth projected forward. That's pretty easy, though caching is harder (if you even need it). Some of the inputs might be objects in their own right (say a salary object that tells you your salary on a given day, and adds 3% annually). You also need a UI to get the inputs and show the projections, but it seems pretty straightforward. What is your specific issue? – psr Nov 15 '11 at 18:17
  • @psr - That's what I thought at first, but there's a lot more to take into account. I'm just struggling to decide what the most efficient (both speed that the application runs and easiest to update) way of doing it is. I want to be able to see my net worth on any given day, but just to give you an example. Some income I receive on the 27th of each month, where as others may be weekly, bi-weekly etc. Tax has to be calculated - taking into account tax allowances that change yearly. Inflation has to be taken into account, interest on savings at the correct points, payrises, etc. There's an over.. – Anonymous Nov 15 '11 at 19:17
  • whelming amount of data to consider for building this. I'm going to build the application in PHP & MySQL. A good dilemna I'm facing at the moment: I want to look at the month of January next year in a calendar view. the calculations must go from now (taking my current wealth - I guess I have to specify that as a starting point) then do all the necessary calculations until it reaches january, THEN it starts printing them. That maths is fairly straightforward, it's just how to organize the data. If you had a db table called 'income' of which I had a record called 'wage' with a value of '20000' – Anonymous Nov 15 '11 at 19:20
  • How would you then go about storing changes to that wage? If every year I received a 4% payrise as mandatory to compensate for inflation, then bonuses and so on.. It's not easy. – Anonymous Nov 15 '11 at 19:20

2 Answers2

2

This is fairly generic advice for any problem, but it may help.

  • Start with the data. Work out what information you'll need to store, how each piece of information relates to the others. If you get the data structure wrong, you can spend an incredible amount of time writing code to "force" it into the correct structure.
  • Caching is "easy to apply" late in the day, as it's generally adding new tables and memory stores. It's best to get the system working first (proof of concept), then cache the data at the bottlenecks you find during real usage. Otherwise you may find yourself making incredibly complex on-demand caches for data that is only used once in the project's lifetime. (Note that "easy to apply" is dependent on you getting the data right, and encapsulating well. However, these are important anyway.)
  • Start small. If you look at all the complexities you will go mad. Accountants and Financial Software Companies are paid a lot for a reason. Start with one specific plan to begin with, and work on generalising once you've got that locked down. Working on the small will allow you to detect the actual issues you'll have to deal with when you reach the large, rather than the issues you currently think you'll have to deal with.
  • Remember this is primarily a self-development project. You're not being pressured to estimate and date, and the penalty for failure is zero. Feel free to experiment and throw away code that doesn't work.
deworde
  • 1,892
  • 14
  • 21
  • Thanks, I think your advice is definitely what was needed. I think my what I thought would be a simple idea has turned out to be monstrously complex to implement, so it's just a case of stepping back and planning what exactly is required more thoroughly. Thanks. – Anonymous Nov 15 '11 at 11:05
  • Sure, just as soon as I sort out my finances... ;) – Anonymous Nov 15 '11 at 11:20
  • +100,000,000 for start with the data! – HLGEM Nov 15 '11 at 16:01
  • Wish I could take full credit for that, but that one came from a colleague. – deworde Nov 15 '11 at 23:20
0

Before starting please check palo bi... İt is a very nice excel integrated solution... İt will inspire you a lot' if you didnt see yet

İ think excel is a better platform for financial stuff,

Your calendar views can be pivot table aggregations maybe?

For small applications Your every income can be line in excel Your senarios can be sheets maybe,

But when size increases you will need olap s dimentional approach...

I just wanted to write some abstract thoughts of me...

Serdar Buyuktemiz
  • 101
  • 2
  • Thanks for taking the time to reply, but I really am looking for some pointers for the design of the aforementioned application. Time/money no object, for learning purposes, so a work-around existing solution isn't really what I'm looking for. – Anonymous Nov 15 '11 at 09:58
  • Oh and by the way, I do currently use excel but would like a more 'polished' application. :) – Anonymous Nov 15 '11 at 09:58