Strangeness in Mortgage/Loan Repayment Druid

[Daniel Hannum]

I'm looking into fixing this myself rather than bothering with bugzilla. 
(as an aside, is that ok, or, from a change-control standpoint, do you 
want a bug filed?)

There are other bugs too. If you ask for a 60 month loan, it gives you 
61 payments. The last 60 are exactly right (in terms of 
interest/principal pmts), but the first one is strange. Looks like the 
second generated payment should be the first. Everything else is right. 
I'll look into that, and the other bugs we've discussed.

However, I was concerned that my tinkering would break the things I 
don't understand, like the variable interest rate loans and escrow 
accounts. But then, after playing with the variable interest rate loans, 
I'm not sure they actually do anything. I created a loan with a monthly 
varying interest rate (I tried both 3/1 Year and 10/1 Year) and the 
produced schedule was exactly the same as fixed rate loan.

So I'm confused. It's probably my fault because I have no idea what 10/1 
Year even means.

I'm also hoping to enhance it so that it looks at the current balance 
when adding the scheduled transaction. That's much more difficult 
because it requires a change in our use of "pmt()". I'm thinking I can 
cleverly take advantage of 'pv' in that formula to be the current 
principal value. We would still have the possibility that the 
transaction might be paid off prematurely. It's messy. I'll have to 
think more about that. Right now I'm looking to do easy stuff because 
I've never hacked gnucash before.

Also, as an aside, what language are these SCM files in? Lisp?

dan

Josh Sled wrote:

>| Now, when I put the principal, rate and term into Gnucash's druid, it 
>| comes up with 374.13, but that's not good, because that's not what I'm 
>| actually going to pay.
>
>4 whole cents off?  Good enough for government work... ;)
>
>If it's a constant 0.04, you could modify the formulae to add/subtract that
>out, but that's a nasty hack.  OTOH, it might solve your immediate problem,
>though I imagine that the rest of the calculations would be off, as well. :(
>
>I had expected that the calculation would vary from most people's actual
>payments for various reasons ... this is a good example of this.  Sorry.
>
>| 1. How do I force a particular loan payment? On the page of the Druid 
>| where you specify the 'Amount' and the accounts where the principal and 
>| interest will be, I tried replacing the "pmt()" expression with $374.09, 
>| but it seemed to ignore me; the next page still had 60 payments of $374.13
>
>Hmm... that should actually work, IIRC.  
>
>In playing with it, it does look like any changes made to the Payment
>field are ignored, which is quite unfortunate.  Filing a bug at
>bugzilla.gnome.org is appreciated.
> 
>| 2. What does "pmt( 0.07900 / 12 : 60 : 18495.00 : 0 : 0 )" mean? 
>| Obviously, it's rate, term, principal, but what are the last 2 zeroes? 
>| Perhaps I shouldn't care. Or perhaps it could help to know.
>
>This one can be answered by looking in src/scm/fin.scm [I forget where
>it's copied on install, but `locate fin.scm` should find it] -- the last
>two terms are the "future value" and "type", as defined by the Gnumeric
>1.0.8 functions of the same name.  Future value could be non-zero, but
>I made the simplifying that it is.
>
>I was hoping to have a more name=value function syntax in the future, but
>time's a bitch.
>
>| 3. If I were to start paying the loan off faster, with irregular 
>| amounts, I would have to put these transactions in by hand. Does it seem 
>| correct to take the balance after the previous payment, multiply it by 
>| 7.9%/12 and use that as the interest portion? I would think that would 
>| be right, but when I try that with the current balance, it doesn't come 
>| up the same as what the scheduled transaction generator is producing... 
>| so you guys must have a different algorithm.
>
>Yes ... there's an existing bug [and some design-time requests which were
>not incorporated] that any future transactions should be based on the
>present value of the account at the time of payment... this would be a
>nice expansion of the feature. :(
>
>| Any help would be appreciated.
>
>I fear that wasn't a lot of help, unfortunately, but hopefully it's
>more clear.  My time to enhance this [or any] part of the codebase is
>non-existant at present, a situation I don't think will be resolved for
>some number of months.  Hopefully someone will step up to this.
>
>....jsled
>  
>