[GNC-dev] "Mortgage Repayment Druid"

David Carlson david.carlson.417 at gmail.com
Wed Sep 16 14:48:08 EDT 2020

Regarding https://github.com/Gnucash/gnucash/pull/682,
for me, as a user, I consider it TL;DR.
I will comment, tho, a simple step or incremental improvement like making
the current account balance available as a variable for SX's would be
usable for that specific SX type and generally for users to use in
construction of custom SX's.

On Wed, Sep 16, 2020 at 12:19 PM Michael or Penny Novack <
stepbystepfarm at comcast.net> wrote:

> On 9/16/2020 12:52 PM, David Carlson wrote:
> >   Unfortunately, it is not flexible enough to
> > handle modern calculations involving daily interest calculations,
> > prepayments, and other variations, but it can still be used to set up a
> > reasonably good estimated split between principal and interest with or
> > without escrow or insurance, but to keep an accurate running balance it
> is
> > usually necessary to manually adjust
> It is actually a "tricky" problem if needing to exactly match the bank's
> amortization table. And in any case will need at least an annual
> adjustment for changes to the escrow component << which if anything, is
> even nastier even after the "what it has to cover for the year*" has
> been entered (the new RE tax and insurance). There are simply too many
> places where you algorithm and what the bank used might make different
> assumptions, where rounding takes place, significant digits used, how
> the final payment to be, etc.**
> Michael D Novack
> * The problem is that NOT simply "enough to cover those payments" (over
> the year) but to be such that the account NEVER goes below zero or a
> specified safety amount at any time during the year. Likely best handled
> by a "trial and error" algorithm to determine the least per payment
> amount that will accomplish that. It is why the amount appears to jump
> around so wildly year to year.
> ** For that reason, I also used a "trial and error" algorithm for that
> which produced more than one potential solution for the amortization
> table, one of which guaranteed to match the bank to the penny << in
> other words, which had the same payment - escrow component as the bank
> did >> In other words, knowing the payment the bank claimed was correct,
> produce the amortization table that matched that . The bank would the
> table FOR A FEE but hey, I was doing software for a living.
> --
> There is no possibility of social justice on a dead planet except the
> equality of the grave.
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

David Carlson

More information about the gnucash-devel mailing list