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 < stepbystepf...@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@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > -- David Carlson _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel