Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Dear All,
I'm looking for a simple way to calculate interests on overdue receivables that will cover several interests rates in apropriate periods e.g. invoice raised on 26 May 2006 for 100USD would be calculate as following
((2006/12/31 - 2006/05/26) * 40%/365 + 30% + 20% + (TODAY()-2008/12/31) * 10% ) * 100USD
assuming the following interest rate details:
InterestRateYear InterestRate
2009 - 10%
2008 - 20%
2007 - 30%
2006 - 40%
I've got over 20 different periods so if I use the above formula it'd too complicated.
Thank you,
Przemek
Are you sure you want simple interest rather than compounded interest? That seems very unusual to me. But if it's really what you want, I'll get you started:
"Invoice Amount"
* ( 1
+ if(len("Overdue On") < 1 or "Overdue On" > now(0), 0
,sum(aggr( "Interest Rate"
* // calculate the number of days overdue in the period here
/ ("Period End" - "Period Start"), Period)))
The trick here, if you can call it one, is the sum(aggr(...,Period)), which essentially loops through all of the periods and sums up the calculated amounts of interest for each.
John,
I meant coumpound interests in a simple way 🙂 How should I put the code to use the below table to calculate invoice of 100 due on 2004-01-02. I didn't quite get what you wrote in the last post?
Interest rates, Valid from
11,5%, 2005-10-15
13,5%, 2005-01-10
12,25%, 2003-09-25
Thanks,
Przemek
I'm going to have to get back to you on this as I'm particularly busy right now. I'm guessing that your interest compounds daily, then? If so, I'd probably use the current interest rate table to build a daily interest rate table. Then rather than sum the interest across the aggr(), you'd need to multiply it. I don't see a product(aggr(...,"Date")) function to do that, so I'm not sure how I'd write it. You'd also want to look closely at the available financial functions, as perhaps this is already built into QlikView. I might be able to look at this in more detail some time next week, and try to come up with an example. Or perhaps someone else can come up with a good solution before then.
And just to confirm, here are several approaches for calculating the final amount due on $1000 borrowed at 10% interest for a year with no payments:
1) simple interest: $1000 * (100% + 10%) = $1100.00
2) compounded monthly: $1000 * (100% + (10%/12))^12 = $1104.71
3) compounded daily: $1000 * (100% + (10%/365))^365 = $1105.16
4) compounded continuously: $1000 * e^10% = $1105.17
You want the third approach, correct? I believe that it's the most common one, though I could be wrong.
And there are no payments being made, correct? The bill is eventually paid, but all at once?
Refering to your questions:
1. Third approach is the one
2. There are na payments so far
3. Bill can be paid partly.
Thanks,
Przemek
I don't yet have an expression for this, but I've been thinking further on it, and I think we may be off track from an overall system standpoint.
If you're actually sending out invoices and collecting payments, you should have an accounts receivable system. The accounts receivable system should be calculating the amount due, not QlikView. QlikView should merely be reporting the amount due given to it by the accounts receivable system.
If you don't have an accounts receivable system, get one. I highly recommend against using QlikView as an accounts receivable system. The reason has to do with QlikView's internal numeric format, which makes it a poor choice when accounting rigor is required. I would NEVER use QlikView to actually manage my books - general ledger, accounts payable, accounts receivable and so on. See my Wiki entry regarding mathematical errors in QlikView for further information:
http://community.qlik.com/wikis/qlikview-wiki/explanation-of-mathematical-errors-in-qlikview.aspx
If this is just a school project, or something you were curious about, or some summary report where it is OK to be off by a few pennies here and there, OK. But if this is truly how you want to track your receivables, I think you may want to rethink that.
Duplicate post. Couldn't delete. Getting strange errors.