Re: [GNC-dev] "Mortgage Repayment Druid"

2020-09-20 Thread Adrien Monteleone
I've seen several threads over the years that a user wanted to make an 
SX based on the current account balance. I'm glad to see the code 
exists, and hope to see it finally included.


I'll make my way through that PR discussion and chime in once I have a 
grasp of the nuances, but for now, I'd say this will also be very useful 
for envelope budgeting. This was my first hangup trying to implement it.


I've also seen a use case of someone calculating their charitable 
donations based on the balance of some accounts at a certain point in 
time, so grabbing that automatically would be nice.


This might turn out to be 'build it and they will come' sort of code. 
People may find uses for it that aren't anticipated yet.


Regards,
Adrien

On 9/16/20 12:08 PM, Jean Laroche wrote:
Note that there is a pull request that adds the ability to use the 
current balance of an account in a scheduled transaction.

https://github.com/Gnucash/gnucash/pull/682

This allows setting up a scheduled transaction for your mortgage payment 
that's smart enough to compute the interest owned based on the current 
balance of the mortgage account. So for example, if you make an extra 
payment, the scheduled transactions created by the current "Mortgage & 
Loan Repayment Assistant" will all be off. But if you setup your 
schedule transaction to use the current balance to compute the interest 
owned, the correct interest will be calculated no matter your 
prepayments etc.


That pull request has been sitting on the list since April, as the 
powers that be don't seem to think it's a priority or even a good idea 
to merge it into maint or master. Check it out, and voice your interest 
if you think that would be useful to you.


Jean


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] "Mortgage Repayment Druid"

2020-09-16 Thread 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 <
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





___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] "Mortgage Repayment Druid"

2020-09-16 Thread David Carlson
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


Re: [GNC-dev] "Mortgage Repayment Druid"

2020-09-16 Thread Michael or Penny Novack

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


Re: [GNC-dev] "Mortgage Repayment Druid"

2020-09-16 Thread Jean Laroche
Note that there is a pull request that adds the ability to use the 
current balance of an account in a scheduled transaction.

https://github.com/Gnucash/gnucash/pull/682

This allows setting up a scheduled transaction for your mortgage payment 
that's smart enough to compute the interest owned based on the current 
balance of the mortgage account. So for example, if you make an extra 
payment, the scheduled transactions created by the current "Mortgage & 
Loan Repayment Assistant" will all be off. But if you setup your 
schedule transaction to use the current balance to compute the interest 
owned, the correct interest will be calculated no matter your 
prepayments etc.


That pull request has been sitting on the list since April, as the 
powers that be don't seem to think it's a priority or even a good idea 
to merge it into maint or master. Check it out, and voice your interest 
if you think that would be useful to you.


Jean

On 9/16/20 9:52 AM, David Carlson wrote:

In release 2.6.19, which I am still using, it is found in the menu tree in
the location Christopher Lam described.  The help manual section for
Account Tree > Actions > Scheduled Transactions > Mortgage & Loan
Repayment... refers to a section called Mortgage & Loan Repayment Assistant
which describes how it works.  There used to be a reference to a section on
the website about using variables in scheduled transactions, but I cannot
find it today.

This tool works fine as far as it goes, to set up a traditional mortgage
repayment scheduled transaction following the calculation methods
traditionally used in the US.  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
  each payment transaction in GnuCash  when the payment is actually made to
reflect the actual values reported by the lender.

There have been many discussions over the years in the user maillist about
these shortcomings.
Many users, myself included, would appreciate work on improving this
assistant.

David Carlson

On Wed, Sep 16, 2020 at 10:01 AM Christopher Lam 
wrote:


I think it has been renamed to Actions > Scheduled Transactions > Mortgage
& Loan Repayment...? Maybe it has hit a raw nerve with some wizards and
warlords.

On Wed, 16 Sep 2020 at 14:27, Dean Jagels  wrote:


There are a couple of old enhancement requests that refer to a "Mortgage
Repayment Druid."  Is/was this a wizard of sorts?  Does it still exist?
The House Mortgate How-To in the doc's makes no mention of such a thing.

Thanks,
Dean


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel





___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] "Mortgage Repayment Druid"

2020-09-16 Thread David Carlson
In release 2.6.19, which I am still using, it is found in the menu tree in
the location Christopher Lam described.  The help manual section for
Account Tree > Actions > Scheduled Transactions > Mortgage & Loan
Repayment... refers to a section called Mortgage & Loan Repayment Assistant
which describes how it works.  There used to be a reference to a section on
the website about using variables in scheduled transactions, but I cannot
find it today.

This tool works fine as far as it goes, to set up a traditional mortgage
repayment scheduled transaction following the calculation methods
traditionally used in the US.  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
 each payment transaction in GnuCash  when the payment is actually made to
reflect the actual values reported by the lender.

There have been many discussions over the years in the user maillist about
these shortcomings.
Many users, myself included, would appreciate work on improving this
assistant.

David Carlson

On Wed, Sep 16, 2020 at 10:01 AM Christopher Lam 
wrote:

> I think it has been renamed to Actions > Scheduled Transactions > Mortgage
> & Loan Repayment...? Maybe it has hit a raw nerve with some wizards and
> warlords.
>
> On Wed, 16 Sep 2020 at 14:27, Dean Jagels  wrote:
>
> > There are a couple of old enhancement requests that refer to a "Mortgage
> > Repayment Druid."  Is/was this a wizard of sorts?  Does it still exist?
> > The House Mortgate How-To in the doc's makes no mention of such a thing.
> >
> > Thanks,
> > Dean
> >
> >
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >
> ___
> 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


Re: [GNC-dev] "Mortgage Repayment Druid"

2020-09-16 Thread Frank H. Ellenberger



Am 16.09.20 um 16:42 schrieb D. via gnucash-devel:
> Way back when, computer folks referred to system assistants (such as the new 
> accounts assistant, or the mortgage setup assistant) as "druids." There was 
> some obscure reasoning for this. Gnucash originally referred to its 
> assistants as druids, but abandoned them for normal English terminology a 
> long time ago. 

To be more specific, in ancient times the GNOME devs called assistants
druids.

Frank
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] "Mortgage Repayment Druid"

2020-09-16 Thread Christopher Lam
I think it has been renamed to Actions > Scheduled Transactions > Mortgage
& Loan Repayment...? Maybe it has hit a raw nerve with some wizards and
warlords.

On Wed, 16 Sep 2020 at 14:27, Dean Jagels  wrote:

> There are a couple of old enhancement requests that refer to a "Mortgage
> Repayment Druid."  Is/was this a wizard of sorts?  Does it still exist?
> The House Mortgate How-To in the doc's makes no mention of such a thing.
>
> Thanks,
> Dean
>
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] "Mortgage Repayment Druid"

2020-09-16 Thread D. via gnucash-devel
Way back when, computer folks referred to system assistants (such as the new 
accounts assistant, or the mortgage setup assistant) as "druids." There was 
some obscure reasoning for this. Gnucash originally referred to its assistants 
as druids, but abandoned them for normal English terminology a long time ago. 

No doubt these ancient enhancement requests have languished for as long as they 
have because working out the details in setting up a mortgage repayment 
schedule are highly complex, and the return is so minimal. Variations in 
calculating interest alone pretty much guarantee that predicted values will 
diverge from the actuality, which force the user to modify those transactions 
anyway. I personally abandoned using scheduled transactions for loans for this 
reason. 

David T. 


 Original Message 
From: Dean Jagels 
Sent: Wed Sep 16 10:25:47 EDT 2020
To: gnucash-devel@gnucash.org
Subject: [GNC-dev] "Mortgage Repayment Druid"

There are a couple of old enhancement requests that refer to a "Mortgage 
Repayment Druid."  Is/was this a wizard of sorts?  Does it still exist?  
The House Mortgate How-To in the doc's makes no mention of such a thing.

Thanks,
Dean


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel