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



_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel

Reply via email to