Strangeness in Mortgage/Loan Repayment Druid

[Josh Sled]

On Tue, Jul 01, 2003 at 07:59:40PM -0400, Daniel Hannum wrote:

| I have a number of questions about the mortgage/loan repayment druid. 
| BTW, I'm on 1.8.1 (redhat 9). So I this has been fixed, please let me 
| know. I'm not prepared to grapple with upgrading (yet)... it was easier 
| under Debian......

I don't believe the Mortgage/Loan druid has seen any changes since 1.8.0.

| 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