[GNC] How do I manage IOUs between household members?
My wife and I would like to separate our individual money from the money that is "communal". Every month, we take 80% of our salaries and deposit them into a communal account, leaving 20% as pocket money for ourselves. So for example, if I make $1000 in one month and my wife makes $2000, then I would get $200 for myself, she would get $400, and the communal "pot" would get $2400. All money is in the same account with our bank and is not separated. I initially thought we could represent this with Equity: Equity - Shared Equity ($2400) - Me ($200) - Wife ($400) Assets - Bank Account ($3000) However, what happens now if I want to lend a friend $200 from my own money? This is where I get confused. Normally I'd represent a loan as a withdrawal from the bank account and creation of an "IOU" asset, but how do I also show that this has come out of "my" money? For example, if I just create an asset account there's no way to represent the fact that if my friend defaults on the loan, it should be paid out of my account: Equity - Shared Equity ($2400) - Me ($200) - Wife ($400) Assets - Bank Account ($2800) - IOU to my friend ($200) How can I represent this? Do I have to create a separate transfer of equity from "Me" to "Shared Equity"? This seems confusing since there is no intuitive way to ensure that I will remember where to return the funds when my friend pays me back. E.g. if I forget whether the loan to my friend was from me or from the shared funds, there's no way for me to tell from the structure of the accounts. I really, really want to avoid creating multiple account files as I like the ability to report on the net assets and income from our whole portfolio. Arman ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
[GNC] how to import a csv of transactions?
I've tried on both 4.4 and 4.6 but it seems that importing csv transactions is broken. Before I continue down this path, is csv importing an actually supported feature or are the issues with it known? Normally I'd put more effort into repro steps but I think it's so broken the devs hopefully already know about it. Errors I encountered: - Anything more than 200 transactions results in a fatal exception when selecting "GnuCash export format" - Account name is ignored, meaning you have to manually link every account. I'm on windows. Are there any working alternatives for getting transactions out of one gnucash file and into another? Sorry again for the lack of detail. Arman ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] how to import a csv of transactions?
Thanks for the replies. To clarify, I have 2 separate gnucash files, one for my everyday expenses and another for investments. In retrospect I regret this decision and wanted to merge them together. Steps I followed: 1) Go to the everyday accounts file and rename the top-level accounts by appending "Household" to them to make sure there are no clashes. So my top level accounts are "Household Equity", "Household Income", etc. I'll split these out again later but I just want to make sure I can do the merge without issues. 2) From the everyday gnucash file, go to file -> export -> Export Account Tree to CSV. I imported this tree in the investments file. I didn't list more details here as this all worked fine and the new account tree appears in the investments file. 3) Go back to the everyday accounts, select file -> export -> Export Transactions to CSV. Clicked through all options, just selecting defaults, "Select all" accounts. 4) Go to my investments accounts file, select file -> Import -> Import Transactions from CSV. Select the exported file. In the "Import Preview" section of the wizard I now see all columns selected as "None". I assume this means I need to load the correct profile, so I select the "Load and Save Settings" dropdown (which says "No Settings" by default) and select "Gnucash export format". When I do this Gnucash immediately hangs for about 5 seconds, then a popup appears with the title "Fatal error in GC" and text "Too many root sets". The only options is "OK". When I click it, gnucash force-closes. Things I tried: - exporting with quotes in case there are special characters in my transaction descriptions. This doesn't seem to have any effect. - I then searched for the "semicolon" character in my transaction descriptions and confirmed that this character wasn't used anywhere, so I exported my CSV with that as the separator. The result was... Weird. It didn't fail this time when I selected "Fatal error in GC", but instead it defaulted back to "comma" separation even though I'd selected semicolons. When I then manually switched it back to semicolons, it would retain column headings for the first 2 or 3 columns, but then revert back to "None" for the rest. I started manually selecting the columns, but when I got to "Price" it just crashed again with "Too many root sets". - Reducing the export to 100 elements by manually truncating the csv file "kind of" worked in that it didn't crash when I selected "Gnucash export format" but then as soon as I confirm the dialog it takes me to a screen where I have to manually map each account. This would be fine if I only had to do it once, but with around 1000 rows I'd have to manually map 30-40 accounts around 10 times, which sounds tedious and error prone. Arman On Mon, 12 Jul 2021 at 23:50, David Carlson wrote: > Arman, > > While CSV transaction imports are definitely supported in GnuCash, there > have been some bugs reported with the 'new' CSV importer. There used to be > a fatal bug with the 'old' CSV importer that caused GnuCash to crash if the > incorrect date format was selected, and it may still be possible to see > that crash if you choose the wrong date format. That is the reason that > there is a new process to save import settings including the base account > selection. It is critical to do that import setup and save very carefully. > > Additionally, when getting familiar with the import process it is very > possible to get results that you do not like so you can expect to fine tune > settings until you like the results. With some financial institutions you > may even want to preprocess the CSV file before importing it. Thus, start > with a disposable copy of your data file and work with small import files. > This especially includes the process of training the import matcher in the > final step of the import. At that stage, when you can describe in detail > what you want to do, users here will step up to help. > > Good luck. > > On Mon, Jul 12, 2021 at 7:40 AM Geoff wrote: > >> Hi Arman >> >> Yes, this *definitely* works with v4.4 on Windows. I haven't tried v4.6 >> yet, but I'd be surprised if it was broken. >> >> See the fifth post in this thread which includes screenshots and a >> sample CSV file: >> >> >> http://gnucash.1415818.n4.nabble.com/GNC-Tracking-cash-flows-with-balanced-transactions-td4721056.html >> >> Good luck! >> >> Geoff >> = >> >> On 12/07/2021 10:01 pm, Arman Schwarz wrote: >> > I've tried on both 4.4 and 4.6 but it seems that importing c
Re: [GNC] how to import a csv of transactions?
I ended up doing the merge manually with a text editor, by just copying the account structure over and then the individual transactions. On Tue, 13 Jul 2021 at 15:34, Arman Schwarz wrote: > Thanks for the replies. To clarify, I have 2 separate gnucash files, one > for my everyday expenses and another for investments. In retrospect I > regret this decision and wanted to merge them together. > > Steps I followed: > > 1) Go to the everyday accounts file and rename the top-level accounts by > appending "Household" to them to make sure there are no clashes. So my top > level accounts are "Household Equity", "Household Income", etc. I'll split > these out again later but I just want to make sure I can do the merge > without issues. > 2) From the everyday gnucash file, go to file -> export -> Export Account > Tree to CSV. I imported this tree in the investments file. I didn't list > more details here as this all worked fine and the new account tree appears > in the investments file. > 3) Go back to the everyday accounts, select file -> export -> Export > Transactions to CSV. Clicked through all options, just selecting defaults, > "Select all" accounts. > 4) Go to my investments accounts file, select file -> Import -> Import > Transactions from CSV. Select the exported file. In the "Import Preview" > section of the wizard I now see all columns selected as "None". I assume > this means I need to load the correct profile, so I select the "Load and > Save Settings" dropdown (which says "No Settings" by default) and select > "Gnucash export format". When I do this Gnucash immediately hangs for about > 5 seconds, then a popup appears with the title "Fatal error in GC" and text > "Too many root sets". The only options is "OK". When I click it, gnucash > force-closes. > > Things I tried: > - exporting with quotes in case there are special characters in my > transaction descriptions. This doesn't seem to have any effect. > - I then searched for the "semicolon" character in my transaction > descriptions and confirmed that this character wasn't used anywhere, so I > exported my CSV with that as the separator. The result was... Weird. It > didn't fail this time when I selected "Fatal error in GC", but instead it > defaulted back to "comma" separation even though I'd selected semicolons. > When I then manually switched it back to semicolons, it would retain column > headings for the first 2 or 3 columns, but then revert back to "None" for > the rest. I started manually selecting the columns, but when I got to > "Price" it just crashed again with "Too many root sets". > - Reducing the export to 100 elements by manually truncating the csv file > "kind of" worked in that it didn't crash when I selected "Gnucash export > format" but then as soon as I confirm the dialog it takes me to a screen > where I have to manually map each account. This would be fine if I only had > to do it once, but with around 1000 rows I'd have to manually map 30-40 > accounts around 10 times, which sounds tedious and error prone. > > Arman > > On Mon, 12 Jul 2021 at 23:50, David Carlson > wrote: > >> Arman, >> >> While CSV transaction imports are definitely supported in GnuCash, there >> have been some bugs reported with the 'new' CSV importer. There used to be >> a fatal bug with the 'old' CSV importer that caused GnuCash to crash if the >> incorrect date format was selected, and it may still be possible to see >> that crash if you choose the wrong date format. That is the reason that >> there is a new process to save import settings including the base account >> selection. It is critical to do that import setup and save very carefully. >> >> Additionally, when getting familiar with the import process it is very >> possible to get results that you do not like so you can expect to fine tune >> settings until you like the results. With some financial institutions you >> may even want to preprocess the CSV file before importing it. Thus, start >> with a disposable copy of your data file and work with small import files. >> This especially includes the process of training the import matcher in the >> final step of the import. At that stage, when you can describe in detail >> what you want to do, users here will step up to help. >> >> Good luck. >> >> On Mon, Jul 12, 2021 at 7:40 AM Geoff wrote: >> >>> Hi Arman >>> >>> Yes, this *definitely* works with
Re: [GNC] How do I add stock trades?
Thanks guys for the clarity, I will look into that documentation. On Sat, 2 May 2020 at 17:19, David Cousens wrote: > The trading accounts should be created automatically when you buy and sell > shares and stock once the feature is enabled as described in the WIki. You > don't need to create them at all. I have just started on documneting the > use > of trading accounts with currency transactions. They appear under their own > top level account Trading of type Trading ( which is a specialized form of > income account) .This will have a subaccount CURRENCY under which the > currency exchange transactions are recorded in subaccounts for each > currency > in use. I would expect for stock trades you should get a sub-account > COMMODITY automatically created and under that a trading account for each > commodity/security you have buy/sell transactions for. I haven't tried to > set it up yet myself but from my experience with the CURRENCY transactions > this is what I would expect to happen. > > David Cousens > > > > - > David Cousens > -- > Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html > ___ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > If you are using Nabble or Gmane, please see > https://wiki.gnucash.org/wiki/Mailing_Lists for more information. > - > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. > ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
[GNC] How are donations to the GnuCash project distributed?
First up, apologies if this is the wrong place to send this. I looked through the mailing lists page on the gnucash website and couldn't find any mailing lists that seem to fit this question so I'm asking it here. I'd like to set up regular donations to the GnuCash project (because I use the software a lot and don't have time to contribute in any other way), but I'd like some clarity on a few points, the answers to which I couldn't find on the site: Where do the funds go? Ie. how are they split between transaction/admin fees, server costs, and to the volunteers? How is the decision to distribute the funds made? Ie. what's the process for deciding who gets what? Is it transparent? Is there any region in which GnuCash has charity status? Thanks Arman ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] How can I add statement balances to my accounts as checks?
Thanks Christopher, also for putting a name to what I was trying to describe. It seems odd to me that the devs would spend time implementing "Reconciliation" and then delete the most important part right after it's provided (the balance). Was this a deliberate design decision or are balance assertions on the roadmap? If not, what was the reason and what is the intended workflow to prevent errors creeping into my accounts? On Wed, 2 Oct 2019 at 14:38, Christopher Lam wrote: > This is a feature called balance assertions present in ledger-cli, another > bookkeeping tool. GnuCash doesn't have it. However you can approximate it: > > https://bit.ly/2mMAKmf > > On Wed, 2 Oct 2019, 12:28 armanschwarz, wrote: > >> Suppose on July 1, 2019 I get a statement that my account balance is $100. >> Since I know this is true and won't change in the future, I should be able >> to tell GnuCash that this is the expected balance, and for some kind of >> warning to appear if that condition is ever violated for the corresponding >> account in GnuCash (kind of like a unit test). >> >> Looking at the documentation for Reconciliation, it seems like this that >> feature more targeted at individual transactions rather than setting known >> values for balances at given points in time. If I reconcile an account for >> 12 months every month, and then stop reconciling it the year after, what's >> stopping all of those historic balances from getting thrown out of whack? >> Does GnuCash remember what the balances should be and prevent this? >> >> Also, if I accidentally enter a wrong date every 5% of the time, and I >> accidentally reconcile them incorrectly 5% of the time, then for a large >> number of transactions I'm virtually guaranteed to have my history broken, >> whereas remembering statement balances would avoid this problem. >> >> >> >> -- >> Sent from: >> http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html >> ___ >> gnucash-user mailing list >> gnucash-user@gnucash.org >> To update your subscription preferences or to unsubscribe: >> https://lists.gnucash.org/mailman/listinfo/gnucash-user >> If you are using Nabble or Gmane, please see >> https://wiki.gnucash.org/wiki/Mailing_Lists for more information. >> - >> Please remember to CC this list on all your replies. >> You can do this by using Reply-To-List or Reply-All. >> > ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] How can I add statement balances to my accounts as checks?
tically from an actual > reconciliation. (rather than being not up to date in doing so, or manually > noting the asserted balance.) Perhaps an RFE would be in order, however, I > don’t know how much work would be involved or where that would even appear > in the UI. > > Regards, > Adrien > > > On Oct 1, 2019 w40d274, at 11:51 PM, Arman Schwarz < > armanschw...@gmail.com> wrote: > > > > Thanks Christopher, also for putting a name to what I was trying to > > describe. > > > > It seems odd to me that the devs would spend time implementing > > "Reconciliation" and then delete the most important part right after it's > > provided (the balance). Was this a deliberate design decision or are > > balance assertions on the roadmap? If not, what was the reason and what > is > > the intended workflow to prevent errors creeping into my accounts? > > > > On Wed, 2 Oct 2019 at 14:38, Christopher Lam > > wrote: > > > >> This is a feature called balance assertions present in ledger-cli, > another > >> bookkeeping tool. GnuCash doesn't have it. However you can approximate > it: > >> > >> https://bit.ly/2mMAKmf > >> > >> On Wed, 2 Oct 2019, 12:28 armanschwarz, wrote: > >> > >>> Suppose on July 1, 2019 I get a statement that my account balance is > $100. > >>> Since I know this is true and won't change in the future, I should be > able > >>> to tell GnuCash that this is the expected balance, and for some kind of > >>> warning to appear if that condition is ever violated for the > corresponding > >>> account in GnuCash (kind of like a unit test). > >>> > >>> Looking at the documentation for Reconciliation, it seems like this > that > >>> feature more targeted at individual transactions rather than setting > known > >>> values for balances at given points in time. If I reconcile an account > for > >>> 12 months every month, and then stop reconciling it the year after, > what's > >>> stopping all of those historic balances from getting thrown out of > whack? > >>> Does GnuCash remember what the balances should be and prevent this? > >>> > >>> Also, if I accidentally enter a wrong date every 5% of the time, and I > >>> accidentally reconcile them incorrectly 5% of the time, then for a > large > >>> number of transactions I'm virtually guaranteed to have my history > broken, > >>> whereas remembering statement balances would avoid this problem. > > > ___ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > If you are using Nabble or Gmane, please see > https://wiki.gnucash.org/wiki/Mailing_Lists for more information. > - > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. > ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] How can I add statement balances to my accounts as checks?
Sorry for the wordy reply. The TLDR; I think we're on the same page that Balance Assertions are a "nice to have" but I feel I haven't really articulated the scenario/s that I think make this feature quite important, hence why I'm replying again. > For example, if I enter a > transaction from July 10, 2019 with the incorrect date of July 10, > 2010, This has actually happened to me before, where I'm backfilling some statements and I get the years mixed up, but you could imagine it might happen also if I'm punching in years on a number pad and write the wrong value, or if the user is prone to mixing up numbers (also very common). Now imagine that at the time of this error reconciliation has been done for all months up to June 2019. 9 years worth of balances are now wrong, and GnuCash will quite happily ignore the fact that I've told it on multiple occassions what the balances should be at various dates (hence the missing feature of balance assertions that you should "get for free" with every reconciliation should you want it). I think the premise of your responses is that I should now do a reconciliation to find this issue. > WHY would you ‘clear’ a 9 year old transaction erroneously it it doesn’t appear on *this month’s* statement? (Remember that the transaction will appear on my reconciliation as well as my statement, it's just that the date will be wrong, but I'll try to respond to the core of the question - why would I sign off on something that's wrong?) Firstly I'd say that I shouldn't have to, as GnuCash has at this point been given all the information it would need to point out to the user that there is a discrepency (via the many statement balances I would have given it to do the reconciliations up to this point). Secondly, most of the time I think you're right in that I would catch this issue in a reconciliation but I might not becuse: - Many human errors are not random, but symptomatic of a cognitive bias. For example, I might mix up 9s and 0s, causing me to type "2010" instead of "2019". This would make me prone to missing this problem in reconiliation, or - I might be in a rush or might only check the balances. I might just _happen_ not to check the year because I've been staring at dates all day and I'm starting to get a bit frazzled. Remember, I've already made the mistake by inputting the data incorrectly. There's a good chance I'm confused about the dates at this point, so the likelihood I'm going to stuff it up at reconciliation is larger than it would be for other transactions. In the above example I got the balance, day and month right, so there's literally only a single digit off! But the worst part about this scenario is that there is no mechanism to catch this down the road. If I make a mistake on the date in reconciliation, that's it, it's there forever. Future balances will be correct because only the date is wrong, and I'm now stuck with this mistake forever, and can't know about it even though I've _told_ GnuCash the info it needs to find the mistake. It seems like there are several workarounds that reduce the likelihood of this happening, such as exercising more diligence as Adrien points out, or the various autocompletion features Liz mentioned. David's point about the order of entries might also help. But all of these seem to only partially reduce the likelihood of errors creeping in that really shouldn't be allowed to exist in the first place. I think as a software design philosophy the software really should be making it as easy as possible to get it right. I don't dispute that we should be diligent when reconciling values, but I think it's not ideal that the normal workflow could result in permanent errors from a single mistake (well, two mistakes I suppose, since you'd need to reconcile incorrectly, but it's not out of the question as I've illustrated). So it really wasn't my intention to come off as cynical, and I hope I haven't done that - I'm actually hugely impressed by GnuCash and will continue to use it regardless of whether it has balance assertions or note (I'll just build it myself), but I'm hoping that I've succeeded in articulating why I think it's a worthwhile feature (I know Adrien already acknowledged this but I wanted to give a specific scenario). On Wed, 2 Oct 2019 at 19:49, D via gnucash-user wrote: > Moreover, when next you go to reconcile, that entry for 2010 will display > up at the very top of the reconcile window, and one might wonder at that, > see the incorrect date and fix it. > > [Technically, Gnucash doesn't store the reconciled amount, it calculates > it at each reconcile for all transactions with the reconcile flag set.] > > David > > On October 2, 2019,
Re: [GNC] How can I add statement balances to my accounts as checks?
All the issues I've highlighted really boil down to inserting transactions before already reconciled ones, so if we could prevent that it might make my concern moot. So perhaps an easier route from a software design perspective would be just adding a warn dialog whenever you try to insert a transaction that comes before any reconciled transactions. You could also warn if the user tries to perform a reconciliation that leaves reonciled transactions _after_ unreconciled transactions. If you try to insert a transaction before a reconciled transaction, valid responses could be; 1) Go ahead anyway 2) Go ahead, but un-reconcile all transactions after the inserted transaction 3) Cancel, never warn again, etc. Actually before I emberass myself here - does this already exist? On Wed, 2 Oct 2019 at 21:06, Christopher Lam wrote: > FWIW I do think it's a nice feature to have. > > It's not terribly difficult to implement either. Allow user to add a > special entry with some metadata stating the balance should be X dollars, > and if the user tries to input a transaction which will fail the balance > assertion, pops a warning "Error - this transaction cannot be entered > because it will invalidate balance on d/m/y which should be $amount.". > > As always the devil is in the details: this will be a brand-new error > condition that only triggers upon user input. Should this trigger when user > imports transactions via CSV/OFX/QIF? What about with custom scripts > whereby a book has been modified but the balance assertions are no longer > valid? What about a book modified externally whereby the assertions now > fail? Should GnuCash fail to open the book because it's now "invalid"? > Should there be a framework/central mechanism to capture all these sanity > checks? > > It's really difficult. Software development is hard. For that matter I > don't think any current developer has found this issue particularly high > priority, so, it has never been done. > > On Wed, 2 Oct 2019 at 10:41, Arman Schwarz wrote: > >> Sorry for the wordy reply. The TLDR; I think we're on the same page that >> Balance Assertions are a "nice to have" but I feel I haven't really >> articulated the scenario/s that I think make this feature quite important, >> hence why I'm replying again. >> >> > For example, if I enter a >> > transaction from July 10, 2019 with the incorrect date of July 10, >> > 2010, >> >> This has actually happened to me before, where I'm backfilling some >> statements and I get the years mixed up, but you could imagine it might >> happen also if I'm punching in years on a number pad and write the wrong >> value, or if the user is prone to mixing up numbers (also very common). >> >> Now imagine that at the time of this error reconciliation has been done >> for >> all months up to June 2019. 9 years worth of balances are now wrong, and >> GnuCash will quite happily ignore the fact that I've told it on multiple >> occassions what the balances should be at various dates (hence the missing >> feature of balance assertions that you should "get for free" with every >> reconciliation should you want it). >> >> I think the premise of your responses is that I should now do a >> reconciliation to find this issue. >> >> > WHY would you ‘clear’ a 9 year old transaction erroneously it it doesn’t >> appear on *this month’s* statement? >> >> (Remember that the transaction will appear on my reconciliation as well as >> my statement, it's just that the date will be wrong, but I'll try to >> respond to the core of the question - why would I sign off on something >> that's wrong?) >> >> Firstly I'd say that I shouldn't have to, as GnuCash has at this point >> been >> given all the information it would need to point out to the user that >> there >> is a discrepency (via the many statement balances I would have given it to >> do the reconciliations up to this point). >> >> Secondly, most of the time I think you're right in that I would catch this >> issue in a reconciliation but I might not becuse: >> >> - Many human errors are not random, but symptomatic of a cognitive bias. >> For example, I might mix up 9s and 0s, causing me to type "2010" instead >> of >> "2019". This would make me prone to missing this problem in reconiliation, >> or >> - I might be in a rush or might only check the balances. I might just >> _happen_ not to check the year because I've been staring at dates all day >> and I'm star
Re: [GNC] How can I add statement balances to my accounts as checks?
Another complimentary feature might be to restrict the date range of reconciliations - if I'm reconciling a July 2019 statement against my accounts, why should I be given the option of using a July 1010 transaction to reconcile against? Maybe I should be able to specify the date range of the statemetn I'm reconciling against? On Wed, 2 Oct 2019 at 21:22, Arman Schwarz wrote: > All the issues I've highlighted really boil down to inserting transactions > before already reconciled ones, so if we could prevent that it might make > my concern moot. > > So perhaps an easier route from a software design perspective would be > just adding a warn dialog whenever you try to insert a transaction that > comes before any reconciled transactions. You could also warn if the user > tries to perform a reconciliation that leaves reonciled transactions > _after_ unreconciled transactions. > > If you try to insert a transaction before a reconciled transaction, valid > responses could be; > 1) Go ahead anyway > 2) Go ahead, but un-reconcile all transactions after the inserted > transaction > 3) Cancel, never warn again, etc. > > Actually before I emberass myself here - does this already exist? > > On Wed, 2 Oct 2019 at 21:06, Christopher Lam > wrote: > >> FWIW I do think it's a nice feature to have. >> >> It's not terribly difficult to implement either. Allow user to add a >> special entry with some metadata stating the balance should be X dollars, >> and if the user tries to input a transaction which will fail the balance >> assertion, pops a warning "Error - this transaction cannot be entered >> because it will invalidate balance on d/m/y which should be $amount.". >> >> As always the devil is in the details: this will be a brand-new error >> condition that only triggers upon user input. Should this trigger when user >> imports transactions via CSV/OFX/QIF? What about with custom scripts >> whereby a book has been modified but the balance assertions are no longer >> valid? What about a book modified externally whereby the assertions now >> fail? Should GnuCash fail to open the book because it's now "invalid"? >> Should there be a framework/central mechanism to capture all these sanity >> checks? >> >> It's really difficult. Software development is hard. For that matter I >> don't think any current developer has found this issue particularly high >> priority, so, it has never been done. >> >> On Wed, 2 Oct 2019 at 10:41, Arman Schwarz >> wrote: >> >>> Sorry for the wordy reply. The TLDR; I think we're on the same page that >>> Balance Assertions are a "nice to have" but I feel I haven't really >>> articulated the scenario/s that I think make this feature quite >>> important, >>> hence why I'm replying again. >>> >>> > For example, if I enter a >>> > transaction from July 10, 2019 with the incorrect date of July 10, >>> > 2010, >>> >>> This has actually happened to me before, where I'm backfilling some >>> statements and I get the years mixed up, but you could imagine it might >>> happen also if I'm punching in years on a number pad and write the wrong >>> value, or if the user is prone to mixing up numbers (also very common). >>> >>> Now imagine that at the time of this error reconciliation has been done >>> for >>> all months up to June 2019. 9 years worth of balances are now wrong, and >>> GnuCash will quite happily ignore the fact that I've told it on multiple >>> occassions what the balances should be at various dates (hence the >>> missing >>> feature of balance assertions that you should "get for free" with every >>> reconciliation should you want it). >>> >>> I think the premise of your responses is that I should now do a >>> reconciliation to find this issue. >>> >>> > WHY would you ‘clear’ a 9 year old transaction erroneously it it >>> doesn’t >>> appear on *this month’s* statement? >>> >>> (Remember that the transaction will appear on my reconciliation as well >>> as >>> my statement, it's just that the date will be wrong, but I'll try to >>> respond to the core of the question - why would I sign off on something >>> that's wrong?) >>> >>> Firstly I'd say that I shouldn't have to, as GnuCash has at this point >>> been >>> given all the information it would need to point out to the user that >>>
