Re: [GNC] How can I add statement balances to my accounts as
I've written a command-line tool for my own personal use that implements basic assertions. For my part, I've found this incredibly useful. I've used GnuCash for only a couple of months but this tool has already uncovered several errors that crept in after reconciliation. I've published this on github for anyone who is interested: https://github.com/armanschwarz/gnucash_balance_assertions;>https://github.com/armanschwarz/gnucash_balance_assertions Usage is ./gnc_assert.py [path] [assertion regex] -d [digits] So for example I've started adding zero-balance transactions with the format "Balance Assertion: 123.45" at the date of each bank statement. Then I provide the tool with the path to my gnucash accounts file, the regex that digs the balance out of the balance assertion format that I use (in my case this would be something like "(?<=Balance Assertion:)\d*\.\d\d" and provide "2" as the number of decimal places to compare, so: ./gnc_assert.py path/to/account.gnucash "(?<=Balance Assertion: )\d*\.\d\d" 2 Output looks like this: found 0 assertions in account 'Current Assets': found 5 assertions in account 'Bank account A': 2018-02-28: checking value 123.45 against balance of 123.45...OK 2018-03-31: checking value 234.56 against balance of 230.56...ERROR 2018-04-30: checking value 223.45 against balance of 223.45...OK found 0 assertions in account 'Fixed Assets': found 1 errors! -- 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.
Re: [GNC] How can I add statement balances to my accounts as
To David T's point, when there are un-reconciled items in the register, the reconciled balance will still match the bank statement if the reconciliation was completed successfully. Where GnuCash appears to disagree is in the fact that there is no reconciliation report kept in the data file or option to display the reconciled balance in the register. However, Alan is entering the value that GnuCash is displaying in the register when the reconciliation is complete, or the technically un-reconciled balance. Any change in the history preceding that date should show a disagreement between the note and the displayed balance. I agree with Alan that often there are very few outstanding un-reconciled items so it would not be a challenge to mentally adjust for that if even necessary. Also, one could show both reconciled balance and un-reconciled balance in a manual entry used to track those numbers. Personally, I have used a method similar to Alan's in my bank and credit card accounts for years. Most of the errors that I make are in transfers between accounts where whichever transaction was entered last 'breaks' the reconciliation of another account if the transaction is assigned to the incorrect account or if it clears on a different date. For those date mismatches I just choose one and leave the other one incorrect unless I really want to track that float for some reason. I have a special account for those cases. David Carlson On Sun, Oct 13, 2019 at 8:20 AM AEG via gnucash-user < gnucash-user@gnucash.org> wrote: > My reconciliations normally match those of the bank unless I've made an > error > or, as you say, a transaction has not yet been presented to the bank. In > the > first case, I investigate and correct the error. In the second case, I > enter > the actual end-of-day balance in brackets after the statement amount. That > way, I know both the statement amount and the balance amount on the date of > the statement. That should never change unless extra transactions are > inserted with earlier dates or others are deleted. > > Alan > > > > GnuCash - User mailing list wrote > > This is interesting. Let's say that at a later point, a transaction were > > added prior to one of these entries. How will this transaction help in a > > way that looking at the statements wouldn't? > > You see, one of the basic truisms of reconciliation is that your balance > > as of a given date will differ from the bank's. That's because you have > > entered transactions that the bank won't know about. So, the account's > > balance on the date of reconciliation *when correct* will not match the > > bank's. If at some later point, these change relative to one another, > how > > are you going to know? > > > > > > On Sun, Oct 13, 2019 at 13:47, AEG via gnucash-user > > > gnucash-user@ > > > wrote: The way I deal with this is not entirely automatic as it > > involves setting up > > a scheduled transaction for every account that has a regular statement, > > but > > it does allow me to check back for errors later. > > > > For each of my bank or credit card accounts, the statements are normally > > compiled on the same date every month so I set up a single line scheduled > > transaction to trigger on that date in which the debit and credit cells > > are > > left blank. In the Description box I enter the name of the bank and in > the > > Notes box I enter the words "Statement:£" so that it is ready for me to > > enter the statement total when it arrives. From this, I can check its > > accuracy at the time of reconciliation and deal with any discrepancies I > > find. > > > > In the future, if I notice a problem, I can look back through > transactions > > until I find the last time statements and balances matched, thereby > > narrowing the dates to check for errors. > > > > Alan > > > > > > > > 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
Re: [GNC] How can I add statement balances to my accounts as
My reconciliations normally match those of the bank unless I've made an error or, as you say, a transaction has not yet been presented to the bank. In the first case, I investigate and correct the error. In the second case, I enter the actual end-of-day balance in brackets after the statement amount. That way, I know both the statement amount and the balance amount on the date of the statement. That should never change unless extra transactions are inserted with earlier dates or others are deleted. Alan GnuCash - User mailing list wrote > This is interesting. Let's say that at a later point, a transaction were > added prior to one of these entries. How will this transaction help in a > way that looking at the statements wouldn't? > You see, one of the basic truisms of reconciliation is that your balance > as of a given date will differ from the bank's. That's because you have > entered transactions that the bank won't know about. So, the account's > balance on the date of reconciliation *when correct* will not match the > bank's. If at some later point, these change relative to one another, how > are you going to know? > > > On Sun, Oct 13, 2019 at 13:47, AEG via gnucash-user > gnucash-user@ > wrote: The way I deal with this is not entirely automatic as it > involves setting up > a scheduled transaction for every account that has a regular statement, > but > it does allow me to check back for errors later. > > For each of my bank or credit card accounts, the statements are normally > compiled on the same date every month so I set up a single line scheduled > transaction to trigger on that date in which the debit and credit cells > are > left blank. In the Description box I enter the name of the bank and in the > Notes box I enter the words "Statement:£" so that it is ready for me to > enter the statement total when it arrives. From this, I can check its > accuracy at the time of reconciliation and deal with any discrepancies I > find. > > In the future, if I notice a problem, I can look back through transactions > until I find the last time statements and balances matched, thereby > narrowing the dates to check for errors. > > Alan > > > > 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.
Re: [GNC] How can I add statement balances to my accounts as
This is interesting. Let's say that at a later point, a transaction were added prior to one of these entries. How will this transaction help in a way that looking at the statements wouldn't? You see, one of the basic truisms of reconciliation is that your balance as of a given date will differ from the bank's. That's because you have entered transactions that the bank won't know about. So, the account's balance on the date of reconciliation *when correct* will not match the bank's. If at some later point, these change relative to one another, how are you going to know? On Sun, Oct 13, 2019 at 13:47, AEG via gnucash-user wrote: The way I deal with this is not entirely automatic as it involves setting up a scheduled transaction for every account that has a regular statement, but it does allow me to check back for errors later. For each of my bank or credit card accounts, the statements are normally compiled on the same date every month so I set up a single line scheduled transaction to trigger on that date in which the debit and credit cells are left blank. In the Description box I enter the name of the bank and in the Notes box I enter the words "Statement:£" so that it is ready for me to enter the statement total when it arrives. From this, I can check its accuracy at the time of reconciliation and deal with any discrepancies I find. In the future, if I notice a problem, I can look back through transactions until I find the last time statements and balances matched, thereby narrowing the dates to check for errors. Alan 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?
The way I deal with this is not entirely automatic as it involves setting up a scheduled transaction for every account that has a regular statement, but it does allow me to check back for errors later. For each of my bank or credit card accounts, the statements are normally compiled on the same date every month so I set up a single line scheduled transaction to trigger on that date in which the debit and credit cells are left blank. In the Description box I enter the name of the bank and in the Notes box I enter the words "Statement:£" so that it is ready for me to enter the statement total when it arrives. From this, I can check its accuracy at the time of reconciliation and deal with any discrepancies I find. In the future, if I notice a problem, I can look back through transactions until I find the last time statements and balances matched, thereby narrowing the dates to check for errors. Alan 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.
Re: [GNC] How can I add statement balances to my accounts as checks?
Hi, armanschwarz writes: > The problem is that the current process only checks an error once. Coming > back to my July 2019/2010 example, if I mistake 2019 for 2010 and don't > catch it at reconciliation (not because I'm not careful, but because, as you > say, we're all fallible), then future reconciliations won't catch this, > despite almost a decade of balances being now incorrect. You are correct, you need to make the mistake twice. I'll also note that GnuCash does have a feature that will prevent you from entering transactions too far in the past. So if you set this feature, GnuCash will prevent you from entering a transaction dated 2010 while we're here in 2019. > Supposing that GnuCash had instead kept the balance value I gave it during > reconciliation, then I would suddenly see 10 years worth of balance > assertions being triggered. If I make a mistake inputting a balance > assertion, I'd notice immediately because it would be incongruent with the > transactions. Even if I make a mistake and accidentally input an incorrect > transaction _and_ incorrect balance assertion such that the assertion > matched the incorrect balance, it would still be caught during the next > reconciliation as the incorrect transactions would throw off the future > balance assertions (whereas the reconciliation will never catch this as the > transactions are already reconciled). I'm not sure exactly how this would happen. I think it would be very expensive to run this check every time a new transaction is entered. I think the "better" approach would be to just remember the most recent reconcile date for an account and warn if a transaction tries to use a date prior to that date. This is very similar to the existing feature. > I hope I've made this point but I'll reiterate it; this isn't just an extra > check. The current reconciliation requires that the user makes the same > mistake no more than twice, otherwise you end up with a permanent error. > Balance assertions don't have this defect. Sure they do. Users can ignore warning boxes. There are other ways to break the "balance assertions", too. A user could go back and change the balance of a reconciled transaction. This would be even HARDER to detect! > The system is more robust against error and doesn't permit drift in accuracy > over time the way Reconciliation does. I wouldn't say it "doesn't permit drift". I would say it's another tool, albeit an expensive tool as you've described it. > The salt in the wound here is that this data is literally given to GnuCash > at reconciliation, it just discards it. Patches always welcome! :) > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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?
On Mon, 7 Oct 2019 16:18:44 -0500 (CDT) armanschwarz wrote: > The system is more robust against error and doesn't permit drift in > accuracy over time the way Reconciliation does. armanschwarz, we all see and interpret things differently because of backgrounds and training. I'm uncertain whether your point of view represents Computer Science or Computer Engineering training. Mine is in biological and educational matters, so I appreciate that you are interested in a system more robust against error, but I fail to understand how a drift in accuracy over time can be asserted. From the particular case you are arguing, I see sudden leaps are possible comparable to a mutation in an organism, but not a drift. Liz ___ 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?
> On Oct 7, 2019 w41d280, at 12:05 PM, Fred Bone > wrote: > > On 06 October 2019 at 7:48, armanschwarz said: > >> Adrien Monteleone-2 wrote >>> Software can’t fix you. Only you can fix you. You shouldn’t do the >>> reconciliation till you have time not to rush it. The software won’t >>> explode if you don’t reconcile by a certain date. >> >> Yeah I fundamentally disagree with this, almost at a philosophical level. >> If we take the view that mistakes are symptomatic of broken users we'll >> never make software that's actually useful to anyone. >> >> I also think there's a bit of irony as you seem to be suggesting that in >> order to use a feature designed to correct for human errors, we should >> just not make human errors. I don't get it. > > No-one is suggesting that. Reconciliation is about detecting / correcting > differences between two different sets of records. Precisely. I was not suggesting humans are or should be infallible, but that software can help you find mistakes, not prevent you from making them, especially in light of a rush to rubber stamp through such a process like reconciliation. (the antithesis of what that process is about) If that is the user’s desired workflow, they could really skip reconciliation because not only is it then unlikely to serve much if any purpose, it will engender a false sense of ‘correctness’ in the books that likely won’t be there, precisely because it was done incorrectly with the wrong end-result or purpose in mind. ___ 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?
On 10/7/2019 1:24 PM, Derek Atkins wrote: Let me add my $0.02 to this.. There are multiple ways to enter transactions into GnuCash (specifically, importing and hand-entering), and there are multiple ways that errors and discrepancies can happen. The most common error/discrepancy is human error when hand-entering transactions. HOWEVER, I have certainly found bank errors, and I've certainly found bogus transactions (Amazon seems to have a funny way to false billing my wife's credit card periodically). And I'll raise that another $0.02 You need to SEE the discrepancies and make sense out of them. Bank errors (misread of check, for example, but I have experienced one "transit" error) Strange charges on credit card << call CC bank >> And WHY is that check still outstanding << need to contact the person? >> Michael D Novack PS -- that said, I do manual reconciliation for all my orgs. For all of them, six transactions would be a busy month. If instead there were 60, I'd be using the automated. ___ 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?
Hi, On Mon, October 7, 2019 1:05 pm, Fred Bone wrote: [snip] > > No-one is suggesting that. Reconciliation is about detecting / correcting > differences between two different sets of records. Let me add my $0.02 to this.. There are multiple ways to enter transactions into GnuCash (specifically, importing and hand-entering), and there are multiple ways that errors and discrepancies can happen. The most common error/discrepancy is human error when hand-entering transactions. HOWEVER, I have certainly found bank errors, and I've certainly found bogus transactions (Amazon seems to have a funny way to false billing my wife's credit card periodically). I'll note that if you only import transactions and then reconcile to bank statements then you're unlikely to ever detect any of these kinds of bank errors because you're completely trusting the bank to provide your input data (import) and then your reconcile data (statement). But sure, this will mostly eliminate human input errors ;) I don't think anyone here believes that humans are infalible; the point of all the checks is to detect when those errors occur and let you fix them. Again, just my $0.02. > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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?
On 06 October 2019 at 7:48, armanschwarz said: > Adrien Monteleone-2 wrote > > Software can’t fix you. Only you can fix you. You shouldn’t do the > > reconciliation till you have time not to rush it. The software won’t > > explode if you don’t reconcile by a certain date. > > Yeah I fundamentally disagree with this, almost at a philosophical level. > If we take the view that mistakes are symptomatic of broken users we'll > never make software that's actually useful to anyone. > > I also think there's a bit of irony as you seem to be suggesting that in > order to use a feature designed to correct for human errors, we should > just not make human errors. I don't get it. No-one is suggesting that. Reconciliation is about detecting / correcting differences between two different sets of records. ___ 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?
> On Oct 6, 2019, at 5:48 AM, armanschwarz wrote: > > Adrien Monteleone-2 wrote >> Software can’t fix you. Only you can fix you. You shouldn’t do the >> reconciliation till you have time not to rush it. The software won’t >> explode if you don’t reconcile by a certain date. > > Yeah I fundamentally disagree with this, almost at a philosophical level. If > we take the view that mistakes are symptomatic of broken users we'll never > make software that's actually useful to anyone. > > I also think there's a bit of irony as you seem to be suggesting that in > order to use a feature designed to correct for human errors, we should just > not make human errors. I don't get it. > Reconciliation is a manual process because GnuCash has no way to parse your bank statement into a form that it can compare with your book, and even were the bank statement presented to GnuCash there's no code in GnuCash to make the comparison and flag any issues. Adding those capabilities isn't one of the core team's current priorities and isn't likely to be any time soon, but if you'd like to make it your priority and can write clear, maintainable modern C++ we'd be happy to consider a pull request. If you want to take that on please start a new thread in gnucash-devel to discuss your proposed design before you start coding. In the meantime, Adrien is quite right: If you want to ensure that both your book and your bank's records of your account are correct then you need to do a proper job of comparing them. The reconcile window is an aid, not an AI. If you don't care about ensuring that both are correct and agree, don't bother reconciling. The choice is yours. To answer your earlier question, "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? ": Because it's in the account and hasn't yet been marked reconciled. That's the sole criterion for what you get presented for reconciliation. Setting aside that a 1010 transaction is outside of the date range that GnuCash can handle (that currently starts in 1400), a 1009 year old unreconciled transaction is an obvious error. I'd think most users would like to have it flagged. Note as well that you can set a limit to how old a transaction you can enter or edit in File>Properties on the Accounts tab. Regards, John Ralls ___ 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?
Adrien Monteleone-2 wrote > Software can’t fix you. Only you can fix you. You shouldn’t do the > reconciliation till you have time not to rush it. The software won’t > explode if you don’t reconcile by a certain date. Yeah I fundamentally disagree with this, almost at a philosophical level. If we take the view that mistakes are symptomatic of broken users we'll never make software that's actually useful to anyone. I also think there's a bit of irony as you seem to be suggesting that in order to use a feature designed to correct for human errors, we should just not make human errors. I don't get it. -- 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.
Re: [GNC] How can I add statement balances to my accounts as checks?
I agree, that is a bug, and it is already filed! (there are several I can see which probably need to be marked as dupes) I don’t think there has been a resolution on it or comment on them in some time, however. One bug (and associated thread) covered discussion of which fields should be protected. I think the original case was changing a misspelling of a description. Regards, Adrien > On Oct 2, 2019 w40d275, at 9:27 AM, Derek Atkins wrote: > > * I think it's a bug that modifying the Txn Desc unreconciled a > transaction. That should not have affected it in any way. Sure, > modifying the amounts should have caused a change, but description?? > ___ 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?
No it does not exist. Let’s consider this: You are just starting out with GnuCash. You are entering historical data. You keep getting the warning. You get fed up and dismiss it, intending to turn it back on later. You forget to turn it back on. Months later, you accidentally (as noted, hard to do) enter a transaction as really old. The warning never fires... Regards, Adrien > On Oct 2, 2019 w40d275, at 6:22 AM, 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? ___ 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?
Also, how would GnuCash know you weren’t trying to correct a previously hasty reconciliation? At best, perhaps a no-value transaction can be entered in the account register indicating that the balance listed was reconciled at that date. (and time perhaps) I’m not sure what the other account should be or if it can even be the same account. One could do this manually now, but maybe the reconciliation process could do it automatically. The user could elect to hide these if desired with a view filter. These asserted balance entries should not be editable except by re-reconciling, but since that isn’t currently done by specific period, I’m not sure how that would work either. Regards, Adrien > On Oct 2, 2019 w40d275, at 6:06 AM, 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. > ___ 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?
> On Oct 2, 2019 w40d275, at 5:39 AM, 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). What ‘balances’ do you suppose are wrong? The previous reconciliations were allegedly correct, else they should not have been completed in the first place. They involved matching paper (or pdf) statements to GnuCash. Either that matching was successful at the time it was done (each month for 9 years) or it wasn’t. Entering a transaction for 2010 in 2019 when it should have been 2019, doesn’t magically make all of those 108 reconciliations somehow flawed or ‘off’. You just end up with an unreconciled transaction dated 9 years ago. Yes, your running balance will be off by that amount, going back 9 years, but you’ll eventually catch this, at the very latest, when you do the next reconciliation and you see it at the top of the window to be cleared. > > I think the premise of your responses is that I should now do a > reconciliation to find this issue. That should catch the error, sure. You might first notice it however looking at the running balance and noticing it doesn’t match what it should at some point in the past. > >> 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?) And you should notice that date is wrong. Checking dates is part of reconciliation. If you aren’t checking dates, you aren’t reconciling correctly. This is now starting to sound like you want the software to take over the manual process of auditing itself against another set of records. That is entirely the point of reconciliation - *manually* verifying the data, meticulously. > > 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). GnuCash can’t presume you really didn’t need to enter that transaction in 2010 and then re-reconcile it. Otherwise, the software would prevent any historical editing. Certainly there is a case for that, and some people would prefer it lock the past, but that isn’t what the devs want for the software. > 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. Software can’t fix you. Only you can fix you. You shouldn’t do the reconciliation till you have time not to rush it. The software won’t explode if you don’t reconcile by a certain date. > > 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
Re: [GNC] How can I add statement balances to my accounts as checks?
I do not recall the exact scenario but I believe that the other day in release 2.6.19, while I was in a credit card account register I changed the amount assigned to a bank account which was already reconciled from that bank account to a different bank account without unreconciling that transaction line. If I figure out how I did that, I will ask if it can be replicated in release 3.7. David Carlson On Wed, Oct 2, 2019 at 9:32 AM Derek Atkins wrote: > Arman Schwarz writes: > > > 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? > > There may be a significant delay between when you initiate a transfer > and when it clears the bank. For example, some checks that I write (or > get written on my behalf) only clear 60-90 days later. > > You're right that 10-year-old transactions are probably wrong. > > ON THE OTHER HAND, if you do wind up forcing un-reconciliation on a > transaction (this happened to be the other day when I fixed a typo in > the description of a transaction!*) then you *DO* need to re-reconcile it > the next time around. > > > Please remember to CC this list on all your replies. > > You can do this by using Reply-To-List or Reply-All. > > -derek > > * I think it's a bug that modifying the Txn Desc unreconciled a > transaction. That should not have affected it in any way. Sure, > modifying the amounts should have caused a change, but description?? > > -- >Derek Atkins 617-623-3745 >de...@ihtfp.com www.ihtfp.com >Computer and Internet Security Consultant > ___ > 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. > -- David Carlson ___ 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?
Arman Schwarz writes: > 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? There may be a significant delay between when you initiate a transfer and when it clears the bank. For example, some checks that I write (or get written on my behalf) only clear 60-90 days later. You're right that 10-year-old transactions are probably wrong. ON THE OTHER HAND, if you do wind up forcing un-reconciliation on a transaction (this happened to be the other day when I fixed a typo in the description of a transaction!*) then you *DO* need to re-reconcile it the next time around. > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. -derek * I think it's a bug that modifying the Txn Desc unreconciled a transaction. That should not have affected it in any way. Sure, modifying the amounts should have caused a change, but description?? -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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?
There is another scenario where the 'balance assertion' could be useful. I sometimes import credit card transactions that accidentally include payments erroneously credited from the wrong bank account. Then I wonder why the bank account is suddenly out of balance. I have been entering zero-valued transactions for years to accomplish the 'balance assertion' function, usually on the statement dates for some asset or credit card accounts. On Wed, Oct 2, 2019 at 6:32 AM Arman Schwarz wrote: > 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 > >>> there > >>> is a
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 >>> 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.
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 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 >>
Re: [GNC] How can I add statement balances to my accounts as checks?
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 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
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, at 10:17 AM, Liz wrote: > > On Wed, 2 Oct 2019 16:19:10 +1000 > Arman Schwarz wrote: > > > For example, if I enter a > > transaction from July 10, 2019 with the incorrect date of July 10, > > 2010, > > > That is actually harder than you think. > If you do not specify a date,
Re: [GNC] How can I add statement balances to my accounts as checks?
On Wed, 2 Oct 2019 16:19:10 +1000 Arman Schwarz wrote: > For example, if I enter a > transaction from July 10, 2019 with the incorrect date of July 10, > 2010, That is actually harder than you think. If you do not specify a date, you get today's date. If you specify a number for the number of the day in the month you get this month in this year (put in 2 and get 2nd October 2019 If you specify a number for the day, and a number for the month, you get this year. So the lazy entering of incomplete dates pulls you to the correct year. (I know this can be changed in preferences, somewhere). Nextly, the system does know the last balance at reconciliation. It pulls that value in for the next reconciliation. You can certainly type in transactions with no value, just a description, and in that description put "Confirmed balance $123.45" Liz ___ 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?
> On Oct 2, 2019 w40d275, at 1:19 AM, Arman Schwarz > wrote: > > Thanks Adrien, > > I think it's the "if you aren't careful" part of the reconciliation > philosophy that I don't like, but I think your message helped me understand > the intended workflow with GnuCash. > > Just to explain my first comment; Reconciliation seems to depend on the user > checking that transactions are correct, and if a mistake is made, it's > unlikely that it will be caught in future. For example, if I enter a > transaction from July 10, 2019 with the incorrect date of July 10, 2010, then > I will just have thrown off 9 years worth of transactions. If I happen not to > notice this mistake during reconciliation (which is not unthinkable, since I > made the mistake in the first place) then I'll probably never catch it unless > I happen to reconcile old balances (which I'll never do). No, you won’t throw off 9 years of transactions or 9 years of reconciliations. Those are all correct. (presumably) When you reconcile the *next time* you’ll see a 9 year old transaction that is listed as unreconciled. At that point, a mental red flag is supposed to be raised, and you should then pause the reconciliation and investigate. *Note*, the reconciliation process is geared towards comparing a written bank statement with your electronic records. WHY would you ‘clear’ a 9 year old transaction erroneously it it doesn’t appear on *this month’s* statement? That would be entirely against the intended process. (hence my admonition to be careful, some might not understand it isn’t about just clicking things, it is about CHECKING things) If you do a reconciliation RIGHT at worst you’ll have a discrepancy you don’t have time to resolve and thus have to make a correcting transaction. (or the time needed to resolve it costs more than the transaction, in which case, the principle of ‘materiality’ suggests to just correct it and move on rather than solve the problem, such as spending more than a few seconds finding a lost penny or nickel.) > > The issue with "be careful when reconciling" is that if I could be so careful > as not to make mistakes, I wouldn't need reconciliation in the first place. > Well, that's not entirely true, I suppose reconciliation would then still be > helpful in that it would catch mistakes made by the bank or some other third > party. Maybe that's what I'm missing - that reconciliation isn't intended to > catch user errors, just third party errors? That is the entire point of reconciliation - to catch your earlier mistakes made in haste. (or otherwise, or someone else’s.) Reconciliation is NOT a rubber stamp process, quite the opposite. > > Either way, balances are useful pieces of information that GnuCash is > throwing away. I may end up writing a bash/python script combined with > Christopher's suggestion to implement these assertions myself. If I do I'll > post the result but I don't really have enough (any) expertise with GnuCash > to know whether such a feature could be implemented in the software itself. > > Anyway, thanks to both of you for clarifying for me. Yes, noted asserted balances would be helpful as a feature. I’m not sure they should be enforced or trigger warnings, but it wouldn’t hurt to record them somewhere, especially since you’re inputting that info anyway. Regards, Adrien ___ 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 Adrien, I think it's the "if you aren't careful" part of the reconciliation philosophy that I don't like, but I think your message helped me understand the intended workflow with GnuCash. Just to explain my first comment; Reconciliation seems to depend on the user checking that transactions are correct, and if a mistake is made, it's unlikely that it will be caught in future. For example, if I enter a transaction from July 10, 2019 with the incorrect date of July 10, 2010, then I will just have thrown off 9 years worth of transactions. If I happen not to notice this mistake during reconciliation (which is not unthinkable, since I made the mistake in the first place) then I'll probably never catch it unless I happen to reconcile old balances (which I'll never do). The issue with "be careful when reconciling" is that if I could be so careful as not to make mistakes, I wouldn't need reconciliation in the first place. Well, that's not entirely true, I suppose reconciliation would then still be helpful in that it would catch mistakes made by the bank or some other third party. Maybe that's what I'm missing - that reconciliation isn't intended to catch user errors, just third party errors? Either way, balances are useful pieces of information that GnuCash is throwing away. I may end up writing a bash/python script combined with Christopher's suggestion to implement these assertions myself. If I do I'll post the result but I don't really have enough (any) expertise with GnuCash to know whether such a feature could be implemented in the software itself. Anyway, thanks to both of you for clarifying for me. On Wed, 2 Oct 2019 at 15:44, Adrien Monteleone < adrien.montele...@lusfiber.net> wrote: > For now, the workflow is that if you alter a reconciled transaction, > you’ll get a warning. (which is dismiss-able, and which you can elect to > not be shown) There is at least one (though I think several) bug reports on > what should trigger this warning when a reconciled transaction is edited, > depending on what data edit causes the trigger. > > However, I know of no mechanism in GnuCash currently that checks to see > that you’ve entered an historical transaction that *should* have been > reconciled in the past, or even has an erroneous date and should be in the > present but affects a reconciled period. > > Presumably, since it is required for the math to work out, if you are > entering a real historical transaction, it should be part of the historical > reconciliation. Which means if it were not already present, then either you > have some serious errors in your current record, or, you made a correcting > entry that needs to be erased/modified now that you have more accurate > transaction data. > > Regardless of if you enter an old transaction that should have been > included, or mis-enter a date in the past, the next time you reconcile, > you’ll see that/those old transactions and notice something is amiss. While > it would be nice to get such warning at the point of entry, there might be > use cases where warnings are quite a pain, especially for someone > intentionally entering historical data. > > Personally, I don’t have a problem with the current approach. > > If you successfully reconcile a period and don’t have to make an adjusting > transaction, there should be no issue. > > If you reconcile but made errors and don’t feel like, or can’t at the > moment track down why they are there and make an adjusting entry, then > you’ll realize this at worst, at the next reconciliation. > > If you errantly enter an old date on a transaction, you’ll catch this at > the next reconciliation. (unless you aren’t careful) > > Now, it would be nice if upon reconciliation, there were some way to > indicate in a particular transaction (the last of the reconciled period) > that the asserted balance was at a certain level. I do this from time to > time if I happen to count a cash asset, but haven’t gotten around to > reconciling it yet. I’ll note that at the point of the transaction I had a > certain amount physically on hand. That way, when I do get around to formal > reconciliation, I know my balance at that transaction needs to be a certain > amount. And if it is off, I’ll have to either search for the error, or > enter a miscellaneous transaction as a correction. > > If I ever have to make a balancing miscellaneous transaction to complete a > reconciliation, I’ll indicate in it whatever that asserted balance was > supposed to be. That way, if I ever get back to investigating or if I find > a lost receipt for example, I can either edit that balancing transaction > accordingly, or erase/reverse it entirely. > > But that doesn’t include the case of doing so automatically 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
Re: [GNC] How can I add statement balances to my accounts as checks?
For now, the workflow is that if you alter a reconciled transaction, you’ll get a warning. (which is dismiss-able, and which you can elect to not be shown) There is at least one (though I think several) bug reports on what should trigger this warning when a reconciled transaction is edited, depending on what data edit causes the trigger. However, I know of no mechanism in GnuCash currently that checks to see that you’ve entered an historical transaction that *should* have been reconciled in the past, or even has an erroneous date and should be in the present but affects a reconciled period. Presumably, since it is required for the math to work out, if you are entering a real historical transaction, it should be part of the historical reconciliation. Which means if it were not already present, then either you have some serious errors in your current record, or, you made a correcting entry that needs to be erased/modified now that you have more accurate transaction data. Regardless of if you enter an old transaction that should have been included, or mis-enter a date in the past, the next time you reconcile, you’ll see that/those old transactions and notice something is amiss. While it would be nice to get such warning at the point of entry, there might be use cases where warnings are quite a pain, especially for someone intentionally entering historical data. Personally, I don’t have a problem with the current approach. If you successfully reconcile a period and don’t have to make an adjusting transaction, there should be no issue. If you reconcile but made errors and don’t feel like, or can’t at the moment track down why they are there and make an adjusting entry, then you’ll realize this at worst, at the next reconciliation. If you errantly enter an old date on a transaction, you’ll catch this at the next reconciliation. (unless you aren’t careful) Now, it would be nice if upon reconciliation, there were some way to indicate in a particular transaction (the last of the reconciled period) that the asserted balance was at a certain level. I do this from time to time if I happen to count a cash asset, but haven’t gotten around to reconciling it yet. I’ll note that at the point of the transaction I had a certain amount physically on hand. That way, when I do get around to formal reconciliation, I know my balance at that transaction needs to be a certain amount. And if it is off, I’ll have to either search for the error, or enter a miscellaneous transaction as a correction. If I ever have to make a balancing miscellaneous transaction to complete a reconciliation, I’ll indicate in it whatever that asserted balance was supposed to be. That way, if I ever get back to investigating or if I find a lost receipt for example, I can either edit that balancing transaction accordingly, or erase/reverse it entirely. But that doesn’t include the case of doing so automatically 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 > 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
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?
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.
