Newbie migration issues

[Rod Engelsman]

Josh Sled wrote:

>On Sat, 2005-01-29 at 01:05, Rod Engelsman wrote:
>
>  
>
>>I go into the Loan Druid. On the first screen I enter 8183.47 in the 
>>"Amount" box. Loan account is "Liabilities:Loan:Student Loan". Interest 
>>rate 3.125%. Type is "Fixed". Start date 2/20/2005. Length is 476 months 
>>(calculated by the Financial Calculator). Months remaining says 476 as 
>>well. Hit "Next".
>>Skip all the Mortgage options because they don't apply. Next screen 
>>says: Name = Loan, Amount = pmt( 0.03125 / 12 : 476 : 8183.47 : 0 : 0 ). 
>>Payment from, principal to, and Interest to is all correct. Repayment 
>>frequency is monthly, start date 2/20/2005. Hit "Next".
>>    
>>
>[deletia]
>  
>
>>Obviously, this amortization schedule is way screwed up. So what did I 
>>do wrong?
>>    
>>
>
>Yeah, quite screwed up.
>
> can only get 476 months when I use the financial calculator entering...
>
>* Interest Rate: 3.125
>* Present Value: 8183.47
>* Periodic Payment: -30
>* Future value: 0
>
>...but since the future value isn't $0 -- since there's another 116
>months of payments -- that's simply user-error on your part.
>  
>
Depends how you look at it. The Loan Druid is written in such a way that 
your input parameters are loan amount, repayment period, and future 
value. The payment amount is then a calculated result. In order to get a 
scheduled transaction equal to $30 with the principal balance and 
interest rate given I have to pretend that the $30 payment goes on 
forever. Then when the payment amount changes in January 2006, I just 
have to re-do the SX to reflect the real repayment schedule. The Druid 
has a mechanism to handle changes in interest rates (variable loans) but 
not changing payment amounts (that I can tell).

The problem is that the way your bank figures your payments isn't likely 
to be exactly according to the ideal loan equation; they take into 
consideration rounding to the nearest cent and the variable number of 
days between payments due to the variable number of days in a month. The 
ideal equation is only an estimate -- fairly close, but not really what 
your payment is going to be. Furthermore, the real split between 
principal and interest will depend on exactly when they post your 
payment and if you've made any extra payments to principal.


>The last two parameters of the `pmt(...)` formula are "future value" and
>"type" [type = payments at beginning or end of period]; you could
>manually edit the SX after the fact to get the correct future value of
>the account [8183.47 - 11*30, assuming no interest accumulates which it
>probably does...]; then it's be 11 payments [not 476], and it should
>calculate the correct principle/interest amounts...  Of course, you'll
>need to setup another Loan SX after those 11 payments to account for the
>change, since as Derek points out the loan druid can't yet handle that.
>
>That all assumes that the basic computations are correct ... 
>
>I can't seem to reproduce the computations described above in any way
>... with 11 payments, it believes that the FV is 0, and thus computes
>payments of ~$755.  With 476 payments, it correctly computes payments of
>$30 [plus $0.01, unfortunately].  There's the other bug you described,
>but I'm not sure _how_ this occurs.  If you find `fin.scm`, you'll see
>that the calculations being done -- as one would expect -- are about as
>simple as any.
>
>
>  
>
Are you saying that when you input my numbers into the Druid you get the 
correct payment and amortization schedule? If so, that leads me to 
believe there is something wrong with the FC3 package.  But there's an 
even more fundamental problem. Using the formula for number of payments 
from the help file (confirmed by doing the same calculation in 
OpenOffice.org Calc), the correct number of payments should be 206 
instead of 476!


>Obviously, the loan druid should be better, in many ways.  I ran out of
>time; more recently, when I've found time to work on GnuCash again,
>there are more pressing concerns [gnome2 port], the resolution of which
>has a higher priority, and in fact will help set-up the playing field so
>that I can -- for instance -- re-write the formula expression parser. 
>Which would make it easier to have, say, a first-class formula editor,
>that could say "hey, user, this 4th argument is the 'future value'
>parameter".  Or to support variable- and piecewise- loan-repayment
>schedules.  Or using the actual account-balance rather than the
>idealized form of the loan payment.
>  
>

That would be ideal.

>So, you can help in a variety of ways, or you can not use the software
>or whatever. But your current attitude of complaining while
>simultaneously asking for support doesn't really make me want to help
>you.
>
>...jsled
>
>  
>
I'm sorry if I came out sounding belligerent. It was the result of much 
frustration. I really appreciate the work you've done with this program. 
The ledgers part of it works great!

Unfortunately, I'm not a programmer so I don't know how much I can help 
on that end, but I would be willing to work on documentation. But first 
I would need to know how the thing is *supposed* to work. That was my 
hang-up. I couldn't figure out if I was doing something wrong or hitting 
a bug.  That's the result of the UI being ambiguous and the total lack 
of any documentation to be found for that function. As far as the help 
files are concerned it doesn't even exist.

Like you said, the basic equations are well-known and not that complex, 
so I was having a hard time understanding why I was getting such bizarre 
results. Now I know that part doesn't work, so I'll quit banging my head 
against a brick-wall about it. I'll still use the product -- at least 
for a few months -- because even if I decide to go crawling back to 
Bill's world, I can always export the files and set it all up again in 
MSMoney.

I'd still like someone to tell me how the tax categories and reports are 
*supposed* to work. Since there's absolutely no documentation on it I 
have no idea if I'm just doing something wrong or what. Any light you 
(or anyone else) can shed on the matter would be greatly appreciated.

Thanks,

Rod