[GNC-dev] "Mortgage Repayment Druid"

[Jean Laroche]

Yes, the PR is indeed TL;DR. But the gist of it is indeed that the 
current balance is a variable that you can use in your SX.
Jean

On 9/16/20 11:48 AM, David Carlson wrote:
> 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
>>
> 
>