-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Derek,
On 1/14/2014 5:15 PM, Derek Atkins wrote: [] >> Uhm, isn't a 'balance as of date' automatically calculated? >> Executing the past transactions would immediately lead you to how >> much you 'should have paid so far'. Am I missing something? > > No, it is not. The P/I splits assume you always pay the exact > amount. If you over-pay your principal the P/I splits do not > reflect the lower principal (and therefore different P/I split > ratio). E.g., if your mortgage is $995 (P+I) and you pay $1000, > you've paid down your principal by $5 and therefore are paying > interest on $5 less principal. GnuCash does not know how to handle > this, so over time your auto-generated P/I splits get further and > further from reality. I see. This is something I haven't thought of and is a practice that usually comes with a fee from the lender (at least in countries I've lived in, like Italy, Switzerland and France). I know it may seem 'insulting' but I've found this Someone's-Favorite-Spreadsheet template which does handle extra payments: http://www.wikihow.com/Create-a-Mortgage-Calculator-With-Microsoft-Excel It looks like if the extra payment can be done with a variable in the SX that is asked for at each scheduled transaction. A simple checkbox could be introduced in the UI to allow the user to select if (s)he wants to have an 'extra-payment' feature in the scheduled transactions. > >>> I've been told this would be complicated, but I toss it out >>> with hope... >> >> For the sake of discussion (and understanding), isn't a >> 'compounding frequency' field be needed at the very beginning of >> the calculation? The Financial Calculator has it, so I wonder >> why the Loan Assistant does not. > > I don't think that would be required necessarily for handling > principal pre-payments. AFAIK there are basically three formulas involved in the prepayments: pmt, ipmt and ppmt, where ipmt + ppmt = pmt. All of them require the payments frequency to be evaluated and all of them require the effective rate which depends on the payments frequency *and* compounding frequency as well. To my taste the SX editor should not be visible before those parameters have been set and actually if the user has already filled in the needed information to create pmt/ipmt/ppmt there's not even the need for an SX editor to be there. > But the complication of the balance-as-of-date is more a UI issue, > where you want the user to be able to select the account and have > the name shown in the UI, but you want to store the Account GUID > in the SX itself. > > Right now the SX editor doesn't do that, it's a direct string > store<->display. But the editor shows a 12 months compounding frequency by default, which is not the case when you need to handle different compounding frequencies. Al p.s.: I'm not sure if the irc channel is preferred over the mailing list, but in my case I seldom have the possibility to stay online and have a normal chat, therefore I'd rather prefer this list. - -- Alessandro Basili PGP Fingerprint DCBE 430E E93D 808B 45E6 7B8A F68D A276 565C 4450 PGP Public Key available at keys.gnugp.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS1cRNAAoJEPaNonZWXERQFbUH/i7NcyObPwb/102eWGMRRt23 B5Nh3VIZvDjJg8nUDYzq83jmsW/EBsqZoH5Hl2VU3Yf7GO7n+Aj/F4lFQv5dlEdD 4fc4iYFc59I6GCYzYq/2kQnL7yyCSGubazfUY8z/MVdXzfvI8epFKMJcu+p7G55I d2qHbTTnRUm6cf9eR6HYf+eppugU7YM+agdM+giBpGwfx7SMnDEcCWR5Rhuz2GFd w9PW+y5I9F4dGvB+7OwGBaMkCRqeAIIDUH7xNfpoNfDEvzAHMnveU4ubIrjuXq2d +DsmsN5O865jAu13PeBs3lrehTVKm8tRZQiE4soxgIVtkx5149vxLitjp7PWGHQ= =D2OE -----END PGP SIGNATURE----- _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
