Re: [GNC-dev] [GNC] Experimental Balance Sheet report
Ok. Thanks. I'll leave it lie then. Never mind. On Sep 16, 2020, 19:47, at 19:47, Christopher Lam wrote: >Hi David, responses inline. I'm sure you know it's my work, and I am >(for >now) happy to defend its state. TBH I do not need this report myself, >but >figure out it fills a gap. I also think devel is more appropriate. > >In my view it won't come out of experimental anytime soon because of >https://bugs.gnucash.org/show_bug.cgi?id=797786 -- figuring out price >from >stock/foreign-currency into target currency is *HARD*. TL;DR: in some >price-sources (avg-bal/wt-avg) current balance sheet will tally only >txns >UPTO report-date and calculate price from it; in multicolumn report >there >are multiple report-dates therefore this strategy would be far too >slow. >I'm running out of steam to make pricing behave identically to the old >balance-sheet. > >On Wed, 16 Sep 2020 at 16:42, David T. via gnucash-user < >gnucash-u...@gnucash.org> wrote: > >> 1. When initially run, I receive an empty report. This is similar to >the >> initial result of the basic Transaction report, except in the latter >> case, users are given a note that links them to the report options. >It >> would seem to me that at the least, this report should do the same. A >> better solution in both cases would be to have initial parameters >that >> return some kind of data--however unrelated to the user's end >> goal--rather than an empty page. It seems to me that users are better >at >> changing something they see that is wrong, rather than trying to >conjure >> it up out of thin air. (the famous quote from US Supreme Court >Justice >> Potter Stewart regarding obscenity comes to mind here: "I know it >when I >> see it. This is not it."). In the Balance Sheet, changing the Period >> Duration setting from its default "None" to anything else (I'd >suggest >> "Year") yields data from which a user can build. (I have no >suggestions >> for the Transaction Report.) >> > >This would be worthy of an individual bug report . > > >> 2. The report defaults to including all accounts, including hidden >and >> placeholder accounts. While there is an option on the Accounts tab to >> display hidden accounts, I think the decision to include hidden >accounts >> in the report by default is confusing, given that the Account tab >> doesn't display hidden accounts by default. I think it makes more >sense >> for the report either to default to omitting hidden accounts, or to >> default to displaying hidden accounts in the options dialog. I see >that >> the standard Balance Sheet report also includes hidden accounts by >> default, although this is masked because the standard report limits >the >> accounts to 3 levels (the Experimental report defaults to All >levels). I >> will note that there is an option on the Display tab to omit zero >> balance accounts, which may have been seen as a way to skip hidden >> accounts. However, while it may not be prudent or common practice to >> hide accounts that have balances, there is nothing in the program to >> prevent this, which means that hiding zero balance accounts is not >the >> same as including hidden accounts. I'll note that if I Clear All and >> then click Select All on the Accounts tab, the report properly omits >all >> hidden accounts, which it should also do by default. I suggest that >both >> reports should default to omitting Hidden accounts on opening, and >that >> the default level setting should be the same for both. >> > >Also worthy of a bug report. The rationale IMV is that hidden accounts >can >carry balances and if they are skipped during report generation, they >will >cause undue mismatch between children balances and total parent >balances. > > >> >> 3. The report propagates balances all the way up the account >hierarchy, >> which makes sense for accounts denominated in a currency. However, >with >> accounts denominated in commodities (such as Stock or Mutual Fund >> accounts), it makes less sense, and in fact renders the report >extremely >> difficult to follow, especially with accounts with many different >> commodities. Seeing a full listing of all 150 different commodities >(and >> various subsets thereof) repeated for >> >> Assets, >> Assets:Investments, >> Assets:Investments:Taxed, >> Assets:Investments:Taxed:Self, and >> Assets:Investments:Taxable:Self:Brokerage A >> >> gets old and confusing very quickly. It would be better to propagate >> totals for the book currency only, and leave the tallying of stock >and >> mutual fund holdings to the Advanced Portfolio report. I will note >that >> initially, I was going to ask why some entries in the report were >listed >> as hyperlinks, while others were not. After some puzzling, I figured >out >> that the non-linked entries were summarizations of holdings further >down >> the hierarchy. Removing the numerous duplications of commodity >> summmarizations would at least make it a little clearer what is going >on >> in this regard. I will further note tha
Re: [GNC-dev] [GNC] Experimental Balance Sheet report
Hi David, responses inline. I'm sure you know it's my work, and I am (for now) happy to defend its state. TBH I do not need this report myself, but figure out it fills a gap. I also think devel is more appropriate. In my view it won't come out of experimental anytime soon because of https://bugs.gnucash.org/show_bug.cgi?id=797786 -- figuring out price from stock/foreign-currency into target currency is *HARD*. TL;DR: in some price-sources (avg-bal/wt-avg) current balance sheet will tally only txns UPTO report-date and calculate price from it; in multicolumn report there are multiple report-dates therefore this strategy would be far too slow. I'm running out of steam to make pricing behave identically to the old balance-sheet. On Wed, 16 Sep 2020 at 16:42, David T. via gnucash-user < gnucash-u...@gnucash.org> wrote: > 1. When initially run, I receive an empty report. This is similar to the > initial result of the basic Transaction report, except in the latter > case, users are given a note that links them to the report options. It > would seem to me that at the least, this report should do the same. A > better solution in both cases would be to have initial parameters that > return some kind of data--however unrelated to the user's end > goal--rather than an empty page. It seems to me that users are better at > changing something they see that is wrong, rather than trying to conjure > it up out of thin air. (the famous quote from US Supreme Court Justice > Potter Stewart regarding obscenity comes to mind here: "I know it when I > see it. This is not it."). In the Balance Sheet, changing the Period > Duration setting from its default "None" to anything else (I'd suggest > "Year") yields data from which a user can build. (I have no suggestions > for the Transaction Report.) > This would be worthy of an individual bug report . > 2. The report defaults to including all accounts, including hidden and > placeholder accounts. While there is an option on the Accounts tab to > display hidden accounts, I think the decision to include hidden accounts > in the report by default is confusing, given that the Account tab > doesn't display hidden accounts by default. I think it makes more sense > for the report either to default to omitting hidden accounts, or to > default to displaying hidden accounts in the options dialog. I see that > the standard Balance Sheet report also includes hidden accounts by > default, although this is masked because the standard report limits the > accounts to 3 levels (the Experimental report defaults to All levels). I > will note that there is an option on the Display tab to omit zero > balance accounts, which may have been seen as a way to skip hidden > accounts. However, while it may not be prudent or common practice to > hide accounts that have balances, there is nothing in the program to > prevent this, which means that hiding zero balance accounts is not the > same as including hidden accounts. I'll note that if I Clear All and > then click Select All on the Accounts tab, the report properly omits all > hidden accounts, which it should also do by default. I suggest that both > reports should default to omitting Hidden accounts on opening, and that > the default level setting should be the same for both. > Also worthy of a bug report. The rationale IMV is that hidden accounts can carry balances and if they are skipped during report generation, they will cause undue mismatch between children balances and total parent balances. > > 3. The report propagates balances all the way up the account hierarchy, > which makes sense for accounts denominated in a currency. However, with > accounts denominated in commodities (such as Stock or Mutual Fund > accounts), it makes less sense, and in fact renders the report extremely > difficult to follow, especially with accounts with many different > commodities. Seeing a full listing of all 150 different commodities (and > various subsets thereof) repeated for > > Assets, > Assets:Investments, > Assets:Investments:Taxed, > Assets:Investments:Taxed:Self, and > Assets:Investments:Taxable:Self:Brokerage A > > gets old and confusing very quickly. It would be better to propagate > totals for the book currency only, and leave the tallying of stock and > mutual fund holdings to the Advanced Portfolio report. I will note that > initially, I was going to ask why some entries in the report were listed > as hyperlinks, while others were not. After some puzzling, I figured out > that the non-linked entries were summarizations of holdings further down > the hierarchy. Removing the numerous duplications of commodity > summmarizations would at least make it a little clearer what is going on > in this regard. I will further note that the standard report does not > repeat this information up the hierarchy. > This multiplication of commodities only takes place if the report does not convert to target currency. e.g. if you have US tech stocks and set conversion t
Re: [GNC-dev] [GNC] Tabs Behaviors in GNC4.1
Geert, Sorry, it was not my intention to single you out with my comments about how the system appears to leave users out of the development loop. I know you and all the other active developers have limited time and can use whatever help users can give short of re-training in the tools that you are using. I was not aware that there was a nightly build for Linux. That could be useful when I get enough of my personal prerequisites out of the way to try the current 4.x builds. I hope you are able to stay healthy and safe in these difficult times. On Wed, Sep 16, 2020 at 4:00 PM Geert Janssens wrote: > Op woensdag 16 september 2020 21:46:14 CEST schreef David Carlson: > > > Geert, > > > > > > I believe some users have backed off of trying to express informed > opinions > > > about program development or documentation development because of various > > > roadblocks that have been thrown up. Sometimes we are ignored, sometimes > > > asked to learn obscure new skills, and occasionally chastised for waiting > > > until after the fact to 'complain', to name a few. > > > > > We're all contributing what we can in the limited time we have available. > If you feel being ignored, my apologies. Though that's probably because the > devs ran out of time/energy not because your opinion didn't matter. > > > > As for the obscure new skills, that depends on what we are talking about. > I think most users should be capable of installing a nightly build of > gnucash to test the current state of the program. That option is available > on Windows and linux. > > > > > There is a gap that we are having a hard time trying to deal with. I > don't > > > know if there would be a way to 'warn' users about pending changes before > > > they are released. Some programs put changes into an official beta > release > > > available to the general public some time before moving to the stable > > > release. Just an idea. > > > > > We do pre-releases for each major release. For GnuCash 4.x there were > 3.902 to 3.906. Those were the "official beta" releases as far as I can > tell. We did catch and revert another behavioural change thanks to user > testing during that cycle (that reverted change involved the way column > preferences for registers were stored) so it does matter if you test. > > > > > > But perhaps I'll just have to back off myself. I believe I'm getting > burned out on gnucash support. Sorry. > > > > Regards, > > > > Geert > -- David Carlson ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] [GNC] Tabs Behaviors in GNC4.1
Op woensdag 16 september 2020 21:46:14 CEST schreef David Carlson: > Geert, > > I believe some users have backed off of trying to express informed opinions > about program development or documentation development because of various > roadblocks that have been thrown up. Sometimes we are ignored, sometimes > asked to learn obscure new skills, and occasionally chastised for waiting > until after the fact to 'complain', to name a few. > We're all contributing what we can in the limited time we have available. If you feel being ignored, my apologies. Though that's probably because the devs ran out of time/energy not because your opinion didn't matter. As for the obscure new skills, that depends on what we are talking about. I think most users should be capable of installing a nightly build of gnucash to test the current state of the program. That option is available on Windows and linux. > There is a gap that we are having a hard time trying to deal with. I don't > know if there would be a way to 'warn' users about pending changes before > they are released. Some programs put changes into an official beta release > available to the general public some time before moving to the stable > release. Just an idea. > We do pre-releases for each major release. For GnuCash 4.x there were 3.902 to 3.906. Those were the "official beta" releases as far as I can tell. We did catch and revert another behavioural change thanks to user testing during that cycle (that reverted change involved the way column preferences for registers were stored) so it does matter if you test. But perhaps I'll just have to back off myself. I believe I'm getting burned out on gnucash support. Sorry. Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] "Mortgage Repayment Druid"
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] [GNC] Tabs Behaviors in GNC4.1
Geert, I believe some users have backed off of trying to express informed opinions about program development or documentation development because of various roadblocks that have been thrown up. Sometimes we are ignored, sometimes asked to learn obscure new skills, and occasionally chastised for waiting until after the fact to 'complain', to name a few. There is a gap that we are having a hard time trying to deal with. I don't know if there would be a way to 'warn' users about pending changes before they are released. Some programs put changes into an official beta release available to the general public some time before moving to the stable release. Just an idea. On Wed, Sep 16, 2020 at 2:26 PM Geert Janssens wrote: > Op woensdag 16 september 2020 14:46:58 CEST schreef D.: > > > Thanks for pointing this bug out. > > > > > > It's too bad that the suggestion in the bug to discuss this change on the > > > lists was not apparently taken up. The devs would then have at least > heard > > > from some other users about their use cases and preferences, and users > > > would have had a heads up about the change. Instead, a change gets pushed > > > out based on one person's request, mainly because it involves "three > lines > > > of code." I'll set aside the wisdom of making changes to software based > > > primarily on the complexity of the fix, or on a single user and the > > > opinions of three devs... > > > > > > While it might seem overkill to discuss something as seemingly minor as > this > > > change, I think *any* change in the user interface should be discussed > > > more, rather than less. > > > > David, > > > > Yes, more discussion up front is useful. However if you want more > discussion to happen (or more precisely if *you* want to be get involved > more in such discussions) I suggest you actively choose to become more > involved proactively rather than waiting until a finished release is > presented to you. That doesn't mean you have to write or review code, but > you can subscribe to the channels where the devs generally communicate to > get an early idea of what lives there. > > > > Some topics will be brought to the users, others not so much. And by the > way, I don't think gnucash-user is the proper channel for this kind of > discussion. I believe it should be held on gnucash-devel. > > > > > > > > Now, we get to have that discussion. > > > > > > At the risk of repeating myself, let me re-present. In my usage of > Gnucash, > > > I keep a core set of tabs always open. These tabs represent my primary > > > active accounts: my checking account, savings account, credit card > account, > > > and a cash account. > > > > > > I leave them open because they are involved in the vast majority of my > > > transactions, and it is easier to click on one of the tabs than to go to > > > the CoA, locate the account, and open it. I like to have them at the top > of > > > the list at all times because I can quickly locate them there. I know > where > > > they are. > > > > > > With the latest change, I no longer can rely on this. My core tabs move > > > down. If I open one of my more obscure accounts to look at things, it > > > pushes its way in at the top. If I've opened several of them, they are > all > > > at the top, and when I am done with those tabs, I have to carefully close > > > tabs, rather than close all tabs below a certain point on the screen. > > > > > While I see what you mean with closing, I perceive this as a minor > behavioural change. As all the new tabs will be on top, it should not be > too hard to close them one by one by starting with the first one. You don't > have to move your mouse for that. I can imagine you have to be a little bit > more careful to stop clicking in time to avoid closing your first > "always-open" tab. However if you have many always-open tabs that problem > also exists when new tabs open at the end. > > > > > None of this is particularly catastrophic, but it does affect me and my > > > workflow every time I open or close an account, so I would prefer to have > > > the option of restoring the old tab behavior. > > > > > See my other replies here and on the bug. I don't think an option is a > good solution. > > > > > The idea of pinned tabs is interesting, although it doesn't remove the > need > > > for the preference. If I jump to a new account tab from a pinned one, > will > > > the new tab go at the end of the list, or bury itself in the middle of my > > > pinned tabs? I think the user would still want the option of where the > new > > > tabs open. > > > > That problem is not solved by adding an option. > > > > > > > > I'll give a clear and unambiguous preference: I want to be able to choose > > > this behavior with a preference setting. Put this setting on the same > page > > > as the tab location setting, and have it read: > > > > > > Open new tabs: □ At the bottom of the tab list □ After the current tab > > > > > > > Understood. My clear and unambiguous design st
Re: [GNC-dev] "Mortgage Repayment Druid"
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"
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"
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"
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"
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"
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"
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
[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
