I’ve updated my homemade extrapolator

The purpose is still the same, so you can read all about what it’s used for from past post

I’ve updated two things: First is I’ve put in a config.xml so people could assign different dynamic values that the application uses. Second, and more importantly, is that I’ve revised the syntax of the expenses xml file. ¹ Notice I didn’t list that as a filename anymore – since the config.xml file will allow people to change it I’ll be talking about the two changes in detail below.

Configuration file

The config.xml file is pretty simple, here’s what it looks like:

<xml>
    <expenseURL debug="false">expenses.xml</expenseURL>
    <headers>
        <name>account</name>
        <low>lowest</low>
        <high>highest</high>
        <min>minimum</min>
        <extra>surplus</extra>

        <start><![CDATA[<br>BEGINNING<br>BALANCE]]></start>
        <end><![CDATA[<br>ENDING<br>BALANCE]]></end>
        <allotment><![CDATA[<br>MINIMUM<br>ALLOTMENT]]></allotment>
     </headers>
</xml>

The expenseURL tag is now a path to any file you choose which contains your actual expense data.

The debug attribute is just for demo purposes. The app is designed to always display starting from the current month you’re in – which is bad news if if you try to view the demo application 5 years from now. If you set debug to true however, you lock the starting day to January 2012. Like I said, it’s for demo purposes.

Everything in the headers tag are exactly that: headers. So if you fancy using different terms for the headers (e.g. if you want to use the word “disposable” in place of “surplus”) then you can change it here.

Smarter Handling of Syntax

It’s very similar to the old syntax as far as the basic values go.

<account name="ACCOUNT_NAME" balance="X" minimum="X">
    <expense start="MM/YYYY" end="MM/YYYY" price="X" period="X">EXPENSE_NAME</expense>
</account>

Take note that current has been changed to balance on the parent node (account) The difference is that now it’s much smarter in interpreting the calculations based on what attributes are present/absent.

There are about 10 valid permutations which I’ll discuss one by one. I’ve also added an EXAMPLE 07 to show how they are plotted out in the application.

Monthly

An expense in it’s very basic and functional form would be:

<expense price="X">EXPENSE_NAME</expense>

This works, and is the first permutation. It assumes the entry to be a monthly occurrence which has no start nor end – which is fine because that’s how monthly payments work.

Monthly with start date

<expense price="X" start="MM/YYYY">EXPENSE_NAME</expense>

If you add a start attribute, this allows for a planned recurring expense which continues on forever – like getting a new plan for your phone in 3 months.

Monthly with end date

<expense price="X" end="MM/YYYY">EXPENSE_NAME</expense>

Similar to the previous permutation, this assumes an recurring expense you’re currently engaged in which you intend to terminate in the future. So this is useful for car/housing loans that have already started, etc.

Monthly with start and end

<expense price="X" start="MM/YYYY" end="MM/YYYY">EXPENSE_NAME</expense>

It’s basically a combination of the two previous permutations. So it’s essentially a ranged expense that starts at a particular time and likewise, ends at a certain time. I’m sure you can imagine what this can be useful for.

Periodic

All previous examples have the price set to your actual monthly “fee”, and assumes you pay every month. But what if you want to pay every X months? Then you use the period attribute

<expense price="X" start="MM/YYYY" period="5">EXPENSE_NAME</expense>

Take note that any periodic type of payment requires a start date. Because common sense tells us that you need to know what to base the interval with. ² You can’t just say “every 5 months” – 5 months starting which month? That’s automatically 12 possibilities.

Apart from that, this behaves like the 3rd example, where it has a start, but never ends. The only difference is it does it on an interval of months instead of every month.

Incidentally, you can set the period to 1 and it’ll behave exactly like the 2nd example. 🙂

Periodic with end date

<expense price="X" start="MM/YYYY" end="MM/YYYY" period="5">EXPENSE_NAME</expense>

Again, just like the previous example, but now with a termination date.

Periodic deferred

<expense price="X" start="MM/YYYY" period="12" deferred="true">EXPENSE_NAME</expense>

The deferred attribute is basically sort of a “savings” flag. Meaning the “expense” is expected at the end of each period. Obviously, this means you don’t need to “pay” anything (yet) when the allotment is started. Hence the “savings” analogy ³ Which probably isn’t even an analogy come to think of it

This is particularly useful if you want to “ease into” a major recurring investment – such as an insurance premium. If the premium is 30k and you plan to get it a year from now. If you set it to start now (but on a “deferred” mode) then the app will include a monthly allotment for the premium. Then come the time next year you need to pay that 30k you’ll be ready 🙂

Periodic deferred with end

<expense price="X" start="MM/YYYY" end="MM/YYYY" period="5" deferred="true">EXPENSE_NAME</expense>

Certainly you should notice the pattern by now. This is similar to “Periodic with end date” – but on a “deferred” mode 😉

Savings

<expense price="X" start="MM/YYYY" end="MM/YYYY" deferred="true">EXPENSE_NAME</expense>

Notice how the syntax works for this particular expense. deferred is set to true, and there’s no period attribute.

So what happens basically is if the app sees this particular combination, it’ll calculate dynamically how many months there are between the start and end date, and use that as for the period value. So if you set it say from Jan 2013 to April 2015 that’s approximately 28 months. And the price will be divided by 28 as your monthly allotment.

Then the deferred attribute basically says that you pay it at the end instead of the start.

In effect, you literally get a savings breakdown, telling you how much you need to put it from the time you start “saving” till when you actually pay for the thing you’re saving for.

Likewise, you can accomplish the same thing by using the periodic deferred with end syntax – provided you know (and input) how many months you’ll be saving for. This is obviously an easier way of doing that same thing 🙂

One-time

<expense price="X" start="SAME_MM/YYYY" end="SAME_MM/YYYY">EXPENSE_NAME</expense>

While not particularly useful as far as the purpose of the application goes, in case you just want to plot in some single-time expenses for whatever reason, you can certainly do so by just setting the start and end to the same date.

Conclusion / Download

So there you have it, a [hopefully] easier way to use the Financial Extrapolator

Download the mac or windows application (built with Flash)