Re: [GNC] How to Delete a Runaway Invoice?
That's really interesting. I've never seen that term before. My Credit Notes say 'Credit Note' rather than 'refund'. But I still think you need to focus on the accounting itself. If it is a Debit to AR, despite what the label says, it isn't a Credit Note. (or Refund) Regards, Adrien On 9/27/23 11:32 PM, Jediator wrote: Thanks again for the response. Please find the attached screenshot of Customer Report in reference to the runaway invoice turned to a Refund. I guess I will try to recreate the issue in a test instance and file a bug report accordingly. ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - 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 Delete a Runaway Invoice?
Thanks again for the response. Please find the attached screenshot of Customer Report in reference to the runaway invoice turned to a Refund. I guess I will try to recreate the issue in a test instance and file a bug report accordingly. Thanks! -- JC On 9/27/23 10:50 PM, Adrien Monteleone wrote: On 9/27/23 8:26 PM, Jediator wrote: Thanks again Adrien! I did answer your initial questions in one of the response messages, but it didn't get published. Cutting and Pasted them below. You may be right this isn't a replicated ID issue. To summarize what I encountered was: 1. An invoice automatically become a credit note after reusing the ID. It shows as a refund on the Customer Report. That is odd for sure. But please explicitly state what you mean by 'shows as a refund' because I have used Credit Notes, and other than being a Credit to the account, there is no such 'refund' designation. *note, before going further, if you aren't already using formal accounting labels, at least for troubleshooting, please change that preference and then proceed so we are discussing (and seeing) the same terms. Please see the attached pic. ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - 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 - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Window resizing issues on MacOS
Thanks. That is interesting. This appears to be perhaps an issue with MacOs then. Regards, Adrien On 9/27/23 8:30 PM, Jediator wrote: I haven't encountered any window resizing issue on Ventura 13.5. ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - 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 Delete a Runaway Invoice?
On 9/27/23 8:26 PM, Jediator wrote: Thanks again Adrien! I did answer your initial questions in one of the response messages, but it didn't get published. Cutting and Pasted them below. You may be right this isn't a replicated ID issue. To summarize what I encountered was: 1. An invoice automatically become a credit note after reusing the ID. It shows as a refund on the Customer Report. That is odd for sure. But please explicitly state what you mean by 'shows as a refund' because I have used Credit Notes, and other than being a Credit to the account, there is no such 'refund' designation. *note, before going further, if you aren't already using formal accounting labels, at least for troubleshooting, please change that preference and then proceed so we are discussing (and seeing) the same terms. 2. Searching after that ID via Find Invoice turns out nothing. Again, odd. I'd think at least one or both would have appeared unless you used additional criteria. 3. Clicking on the ID link on the customer report brings you to the AR screen, not to the View Invoice screen. Another oddity. For my Customer Report, if I click the Invoice number link in the Reference column, I get taken to the Invoice or Credit Note. (I tested both, just to be sure) Clicking on the Debit/Credit Amount (which is also link) takes me to the AR account at that transaction. If you changed the Customer assigned to the invoice, it wouldn't show up on the original Customer Report. (did you change it back?) -- I did change the customer name back to the original, but the problem remains. Of course, because you changed the customer back to the original, that makes sense that it shows up on that customer's report. If you like, create a dummy customer, assign that old invoice to them (you'll have to unpost and repost) and then refresh the original Customer Report. It should no longer be there. Then change it back to the original customer. How are you searching for the invoice you can't seem to find? -- The search on the invoice ID turned out to be one. Once opened, it is the newly created one. Fair enough. Did you set any other criteria? Try 'Company Name' and 'Invoice Owner' but don't add any other restrictions. See if they both appear now. (possibly along with other invoices for that customer) Do they both show up in the AR register? -- No, only the old one (now labeled as refund) shows up in AR. However, it is still under Debits instead of Credits. That is really odd. So the Customer Report shows both, but the AR account only shows one? From the Customer Report, click the Debit/Credit amount for the new invoice and see if it takes you to that AR transaction. Then do the same for the old Credit Note. (the AR register should open and jump to the relevant transaction, but it sometimes brings it right at the top and you can't see the Description line so you might have to scroll slightly) You can right-click that transaction to 'Jump to Invoice' -- No 'Jump to Invoice', only 'Jump to another account' which leads to an income account. You might have missed it, as it is in the middle of the menu. The 'Jump to the other account' is at the bottom. (see attached screenshot) I can't delete from that account the corresponding transaction either. That is by design. The proper step is to unpost the Invoice/Credit Note. Once you are viewing the invoice, click the Edit Invoice button on the *toolbar*. (not the Edit link within the invoice!) Now you can change Customer, ID, etc. -- I changed the new invoice to another ID to ensure that the old invoice (labeled by Refund) is by itself. The old invoice is still showing up on the Customer Report (labeled as Refund). It is still showing on AR. Now searching via Find Invoice after that ID turns out an empty result. Where are you seeing this 'Refund' label? I change my errant invoices to "USE NEXT" as the ID so I can spot them easily for re-use. Note, you can't change the type. So if it was a Credit Note, you have to wait to use it for your next Credit Note. (for any customer, as you can re-assign it) Shouldn't a refund/credit note show up in AR as a credit? But this one shows under invoice (debit) in AR. Then why do you think it is a Credit Note? Simply because of the 'Refund' label? Does the Reference column in AR for that transaction say "Credit Note"? If not and it says "Invoice" then it is an Invoice. If this "Refund" label is something of your own typing on the new (actual) Credit Note, and the original invoice is still a Debit to AR, then I'd hazard the original invoice is still an invoice. (as the type is immutable as I noted, or should be) What might have happened is that by duplicating the Invoice number, GnuCash confounded your own typed label of "Refund" and that is why you think it is one, but the accounting says otherwise. As long as the above checks out, I think the only issues
Re: [GNC] Window resizing issues on MacOS
I haven't encountered any window resizing issue on Ventura 13.5. -- JC On 9/27/23 9:22 PM, Adrien Monteleone wrote: I'm running 5.4 on 12.6.9 Monterey and I just noticed that window resizing issues appear worse. Prior to 5.4, resizing worked, but would temporarily or partially blank the target window during the resize. Now, I just accidentally widened my main window and it won't resize smaller. I can resize larger and then back to this same point, but it appears to have a new minimum width. (targeting a window with the mouse has also been a problem for some time, which is how I accidentally resized it) Anyone else notice similar issues? (I'm sure it is a GTK and not GnuCash issue, but I'd thought I'd ask here first) ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - 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 Delete a Runaway Invoice?
Thanks again Adrien! I did answer your initial questions in one of the response messages, but it didn't get published. Cutting and Pasted them below. You may be right this isn't a replicated ID issue. To summarize what I encountered was: 1. An invoice automatically become a credit note after reusing the ID. It shows as a refund on the Customer Report. 2. Searching after that ID via Find Invoice turns out nothing. 3. Clicking on the ID link on the customer report brings you to the AR screen, not to the View Invoice screen. Thanks! -- JC On 9/27/23 12:13 AM, Adrien Monteleone wrote: I think this was a bug in early 5.x, but should be fixed as of 5.4 That said, you can't delete invoices. If you changed the Customer assigned to the invoice, it wouldn't show up on the original Customer Report. (did you change it back?) -- I did change the customer name back to the original, but the problem remains. How are you searching for the invoice you can't seem to find? -- The search on the invoice ID turned out to be one. Once opened, it is the newly created one. Do they both show up in the AR register? -- No, only the old one (now labeled as refund) shows up in AR. However, it is still under Debits instead of Credits. You can right-click that transaction to 'Jump to Invoice' -- No 'Jump to Invoice', only 'Jump to another account' which leads to an income account. I can't delete from that account the corresponding transaction either. Once you are viewing the invoice, click the Edit Invoice button on the *toolbar*. (not the Edit link within the invoice!) Now you can change Customer, ID, etc. -- I changed the new invoice to another ID to ensure that the old invoice (labeled by Refund) is by itself. The old invoice is still showing up on the Customer Report (labeled as Refund). It is still showing on AR. Now searching via Find Invoice after that ID turns out an empty result. I change my errant invoices to "USE NEXT" as the ID so I can spot them easily for re-use. Note, you can't change the type. So if it was a Credit Note, you have to wait to use it for your next Credit Note. (for any customer, as you can re-assign it) Shouldn't a refund/credit note show up in AR as a credit? But this one shows under invoice (debit) in AR. On 9/27/23 9:02 PM, Adrien Monteleone wrote: On 9/27/23 7:28 PM, Jediator wrote: Thanks Adrien! I am using the latest version 5.4 of GC, running on Mac with a Postgresql in the back-end. Please see answers to your questions below. Additional questions to this mailing list: It seems your answers didn't come through for some reason. * Has this bug been reported or should I take the initiative to report (this is the first major headache I encountered in GC). What do you think is the bug? Duplicate ID's? I thought that was fixed for 5.4, but now I see it is not in the release notes. Can you still assign two invoices the same ID with 5.4? Then perhaps checkout bugzilla to see if it was reported and/or add a comment if so. * I was wondering if an SQL-delete to remove that record from the database would solve this problem. However, the old invoice (now it turned into a credit note) is nowhere to find in the invoices table. Where is it recorded? Any damage it may cause if I just delete that record? You *shouldn't* edit the data file with SQL, or at least do so at your own risk. Maybe ask on IRC about specifics. And I"m still not sure how you managed to turn an invoice into a credit note. I thought the types were immutable. - I'll wait for your answers to my below questions as they can help guide my follow-up suggestions on finding and editing the errant credit note. Regards, Adrien On 9/27/23 12:13 AM, Adrien Monteleone wrote: I think this was a bug in early 5.x, but should be fixed as of 5.4 That said, you can't delete invoices. If you changed the Customer assigned to the invoice, it wouldn't show up on the original Customer Report. (did you change it back?) How are you searching for the invoice you can't seem to find? Do they both show up in the AR register? You can right-click that transaction to 'Jump to Invoice' Once you are viewing the invoice, click the Edit Invoice button on the *toolbar*. (not the Edit link within the invoice!) Now you can change Customer, ID, etc. I change my errant invoices to "USE NEXT" as the ID so I can spot them easily for re-use. Note, you can't change the type. So if it was a Credit Note, you have to wait to use it for your next Credit Note. (for any customer, as you can re-assign it) ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
[GNC] Window resizing issues on MacOS
I'm running 5.4 on 12.6.9 Monterey and I just noticed that window resizing issues appear worse. Prior to 5.4, resizing worked, but would temporarily or partially blank the target window during the resize. Now, I just accidentally widened my main window and it won't resize smaller. I can resize larger and then back to this same point, but it appears to have a new minimum width. (targeting a window with the mouse has also been a problem for some time, which is how I accidentally resized it) Anyone else notice similar issues? (I'm sure it is a GTK and not GnuCash issue, but I'd thought I'd ask here first) -- 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 - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Reconciliation of accounts is not permanent
It seems I forgot that is influenced by: Preferences > Register > Reconciling > 'Always reconcile to today'. Apologies. Regards, Adrien On 9/27/23 7:22 PM, Adrien Monteleone wrote: On the contrary, GnuCash has *always* as far as I can recall after over a decade, suggested today's date for the closing date. I don't ever remember it suggesting a date in the past. And when I tested this last night on an account I know I haven't reconciled in over a year (yes, I'm behind in duties) it suggested yesterday's date, not something over a year old. Is your System date correct? ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - 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 Delete a Runaway Invoice?
On 9/27/23 7:28 PM, Jediator wrote: Thanks Adrien! I am using the latest version 5.4 of GC, running on Mac with a Postgresql in the back-end. Please see answers to your questions below. Additional questions to this mailing list: It seems your answers didn't come through for some reason. * Has this bug been reported or should I take the initiative to report (this is the first major headache I encountered in GC). What do you think is the bug? Duplicate ID's? I thought that was fixed for 5.4, but now I see it is not in the release notes. Can you still assign two invoices the same ID with 5.4? Then perhaps checkout bugzilla to see if it was reported and/or add a comment if so. * I was wondering if an SQL-delete to remove that record from the database would solve this problem. However, the old invoice (now it turned into a credit note) is nowhere to find in the invoices table. Where is it recorded? Any damage it may cause if I just delete that record? You *shouldn't* edit the data file with SQL, or at least do so at your own risk. Maybe ask on IRC about specifics. And I"m still not sure how you managed to turn an invoice into a credit note. I thought the types were immutable. - I'll wait for your answers to my below questions as they can help guide my follow-up suggestions on finding and editing the errant credit note. Regards, Adrien On 9/27/23 12:13 AM, Adrien Monteleone wrote: I think this was a bug in early 5.x, but should be fixed as of 5.4 That said, you can't delete invoices. If you changed the Customer assigned to the invoice, it wouldn't show up on the original Customer Report. (did you change it back?) How are you searching for the invoice you can't seem to find? Do they both show up in the AR register? You can right-click that transaction to 'Jump to Invoice' Once you are viewing the invoice, click the Edit Invoice button on the *toolbar*. (not the Edit link within the invoice!) Now you can change Customer, ID, etc. I change my errant invoices to "USE NEXT" as the ID so I can spot them easily for re-use. Note, you can't change the type. So if it was a Credit Note, you have to wait to use it for your next Credit Note. (for any customer, as you can re-assign it) ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - 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 Delete a Runaway Invoice?
Not sure if the title is too "violent" that prevents it from being accepted by the list. Resending... On 9/27/23 6:24 PM, Jediator wrote: Thanks Adrien! I am using the latest version 5.4 of GC, running on Mac with a Postgresql in the back-end. Please see answers to your questions below. Additional questions to this mailing list: * Has this bug been reported or should I take the initiative to report (this is the first major headache I encountered in GC). * I was wondering if an SQL-delete to remove that record from the database would solve this problem. However, the old invoice (now it turned into a credit note) is nowhere to find in the invoices table. Where is it recorded? Any damage it may cause if I just delete that record? Thanks in advance! -- JC On 9/27/23 12:13 AM, Adrien Monteleone wrote: I think this was a bug in early 5.x, but should be fixed as of 5.4 That said, you can't delete invoices. If you changed the Customer assigned to the invoice, it wouldn't show up on the original Customer Report. (did you change it back?) How are you searching for the invoice you can't seem to find? Do they both show up in the AR register? You can right-click that transaction to 'Jump to Invoice' Once you are viewing the invoice, click the Edit Invoice button on the *toolbar*. (not the Edit link within the invoice!) Now you can change Customer, ID, etc. I change my errant invoices to "USE NEXT" as the ID so I can spot them easily for re-use. Note, you can't change the type. So if it was a Credit Note, you have to wait to use it for your next Credit Note. (for any customer, as you can re-assign it) Regards, Adrien On 9/26/23 9:36 PM, Jediator wrote: I was trying to reuse/repurpose an invoice ID for a customer (e.g. change the amount and date), but made a mistake of changing the customer name in between (not sure if was the cause). Now I ended up with two invoices with the same ID on the customer report, with the old entry labeled as a Refund (with the amount still listed under Debits to AR) . I tried multiple ways to kill that refund invoice, but couldn't succeed. Looks like the Invoice ID in GC isn't unique, so I ended up with two invoices and the old one just no where to find and noway to unpost. Any suggestions how to kill that invoice (i.e., remove the corresponding entry in Accounts Receivable)? ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - 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 - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Reconciliation of accounts is not permanent
On 9/27/23 10:47 AM, Mark Truelove wrote: Hi again. Besides my tendency to be details-specific (given my professional background), I also had some college level accounting and understand double-entry, reconciliation, and the basics. No, I am not an accountant, but I have been using GnuCash mostly successfully for more than twelve years now. I am new to this list, but not to the topics we're discussing. Fair enough, thanks for the clarification. Regarding using the wrong year for the reconciliation date, the program suggests an approximate date based on the last, and at the moment that recommendation is 9/24/22. This is not in a vacuum, however, because all of the unreconciled transactions between August '22 and present are still in the ledger awaiting reconciliation against these 12 or so monthly statements that I just re-downloaded. If I'd simply entered the wrong year, this would not be the case. On the contrary, GnuCash has *always* as far as I can recall after over a decade, suggested today's date for the closing date. I don't ever remember it suggesting a date in the past. And when I tested this last night on an account I know I haven't reconciled in over a year (yes, I'm behind in duties) it suggested yesterday's date, not something over a year old. Is your System date correct? 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 - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Reconciliation of accounts is not permanent
Good catch. But that would imply some serious mass editing on the part of the OP to clear the reconcile flag. (and most likely dimissing the warning during those edits) Neither is out of the question, but either or both would be rare for the OP to not remember doing so. Regards, Adrien On 9/27/23 3:53 PM, John Layman via gnucash-user wrote: I can assure you that GnuCash reconciliations 'stick'. I very rarely encounter a discrepancy in the opening balance of a bank or credit card account. When I do, there is always a data-related explanation to account for it. It is not related to a software bug or quirk. Any transaction mistakenly backdated or inadvertently deleted may throw those balance figures off, but it's your error, not the software. The software does not 'lock' reconciled accounts such that you are prevented from making the sort of inadvertent goof that inserts or deletes a transaction prior to the date of the previous reconciliation. ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Reconciliation of accounts is not permanent
Hi David, long in the past I probably reconciled multiple accounts in one session without thinking about it, but after the first incident I started saving after I reconcile each statement. This is the third time this has occurred over about 5 years, prompting me to reach out about it instead of just catching up all the lost reconciliations as I did in the past. Consider that while I'm reconciling without issue across several accounts each month (or maybe up to three, admittedly, for inactive accounts), that the glitch when it appears takes me back several months or a year, over which I definitely did not skip saving my activities. I also handle basic activities (paying bills) twice a month, saving of course as I go. My ledger is currently up to date with no lost transactions, it's only the reconciliation of those accounts that has been forgotten. Besides the main credit card account I mentioned earlier, I have another whose recommended reconciliation date fell back to 8/18/2021. I'm holding off on new activity for now for the sake of this conversation. I'll take this to the next level and open a ticket to see if it goes anywhere. Thanks. On Wed, Sep 27, 2023 at 1:27 PM David Carlson wrote: > Mark, > > From this side of the Internet it almost appears that you are forgetting > to save the data file after reconciling, but always remembering to save > other times, which is not very likely. > > Have you tried breaking down your procedure and inserting cross-checks? > > ie, just before starting a reconciliation, save the file, then reconcile > one month, save the file, review the reconcile box of the freshly > reconciled transactions to verify that they are still reconciled on the > correct reconcile date, save again, rinse and repeat as needed? > > I just tried the reconciliation report for the first time and found that > it shows mountains of information about reconciliation status down to split > details when they exist, so that may help you too. > > If, as I suspect, you do indeed discover that some reconciliations are not > being properly recorded in your file, please both let us know here and also > file a bug report. > > On Wed, Sep 27, 2023, 10:49 AM Mark Truelove wrote: > >> Hi again. Besides my tendency to be details-specific (given my >> professional >> background), I also had some college level accounting and understand >> double-entry, reconciliation, and the basics. No, I am not an accountant, >> but I have been using GnuCash mostly successfully for more than twelve >> years now. I am new to this list, but not to the topics we're discussing. >> >> Regarding using the wrong year for the reconciliation date, the program >> suggests an approximate date based on the last, and at the moment that >> recommendation is 9/24/22. This is not in a vacuum, however, because all >> of the unreconciled transactions between August '22 and present are still >> in the ledger awaiting reconciliation against these 12 or so monthly >> statements that I just re-downloaded. If I'd simply entered the wrong >> year, this would not be the case. >> >> I'd hoped this would have been something familiar to someone, only that I >> didn't know about because I hadn't been on the list previously. Based on >> the responses, it's beginning to look a little obscure now. >> >> On Wed, Sep 27, 2023 at 10:52 AM Michael or Penny Novack < >> stepbystepf...@comcast.net> wrote: >> >> > >> > >> > > The purpose of reconciliation is to verify that from the last closing >> > > date to the new closing date, the listed transactions cleared the >> > > account and thus explain the change from the opening balance (last >> > > closing balance) to the new closing balance listed on the statement. >> > > >> > > The actual balance, in your books, on a given day, or as of a given >> > > day, is irrelevant to that reconciliation. >> > >> > >> > Precisely. You EXPECT there to be a difference based on checks written >> > (appear in the gnucash account) that have not yet cleared. In other >> > words, the main part of the job (if no errors) is to verify that the >> > total of checks written but uncleared matches the difference between the >> > bank statement of the account and the gnucash account as of the date of >> > the statement. >> > >> > When it still doesn't match you then need to find the error, a check not >> > entered for the correct amount. Usually at your end but once I had one >> > of these at a bank end. >> > >> > Michael D Novack >> > >> > ___ >> > gnucash-user mailing list >> > gnucash-user@gnucash.org >> > To update your subscription preferences or to unsubscribe: >> > https://lists.gnucash.org/mailman/listinfo/gnucash-user >> > - >> > 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
Re: [GNC] Reconciliation of accounts is not permanent
I can assure you that GnuCash reconciliations 'stick'. I very rarely encounter a discrepancy in the opening balance of a bank or credit card account. When I do, there is always a data-related explanation to account for it. It is not related to a software bug or quirk. Any transaction mistakenly backdated or inadvertently deleted may throw those balance figures off, but it's your error, not the software. The software does not 'lock' reconciled accounts such that you are prevented from making the sort of inadvertent goof that inserts or deletes a transaction prior to the date of the previous reconciliation. -Original Message- From: gnucash-user On Behalf Of Mark Truelove Sent: Wednesday, September 27, 2023 11:48 AM To: stepbystepf...@comcast.net Cc: gnucash-user@gnucash.org Subject: Re: [GNC] Reconciliation of accounts is not permanent Hi again. Besides my tendency to be details-specific (given my professional background), I also had some college level accounting and understand double-entry, reconciliation, and the basics. No, I am not an accountant, but I have been using GnuCash mostly successfully for more than twelve years now. I am new to this list, but not to the topics we're discussing. Regarding using the wrong year for the reconciliation date, the program suggests an approximate date based on the last, and at the moment that recommendation is 9/24/22. This is not in a vacuum, however, because all of the unreconciled transactions between August '22 and present are still in the ledger awaiting reconciliation against these 12 or so monthly statements that I just re-downloaded. If I'd simply entered the wrong year, this would not be the case. I'd hoped this would have been something familiar to someone, only that I didn't know about because I hadn't been on the list previously. Based on the responses, it's beginning to look a little obscure now. On Wed, Sep 27, 2023 at 10:52 AM Michael or Penny Novack < stepbystepf...@comcast.net> wrote: > > > > The purpose of reconciliation is to verify that from the last > > closing date to the new closing date, the listed transactions > > cleared the account and thus explain the change from the opening > > balance (last closing balance) to the new closing balance listed on the > > statement. > > > > The actual balance, in your books, on a given day, or as of a given > > day, is irrelevant to that reconciliation. > > > Precisely. You EXPECT there to be a difference based on checks written > (appear in the gnucash account) that have not yet cleared. In other > words, the main part of the job (if no errors) is to verify that the > total of checks written but uncleared matches the difference between > the bank statement of the account and the gnucash account as of the > date of the statement. > > When it still doesn't match you then need to find the error, a check > not entered for the correct amount. Usually at your end but once I had > one of these at a bank end. > > Michael D Novack > > ___ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > - > 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 - 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 - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Reconciliation of accounts is not permanent
Mark, The reconciliation has been working well in GnuCash for 10-12 years that I have been using GnuCash, currently 5.4 on Linux and bugs in it are usually picked up pretty quickly as nearly everyone will be using it. I have just entered six months of OFX files and reconciled them to the EOFY with no problems. Half of that was done with 5.3 then I shifted to 5.4. AFAIK the code for reconciliation between OS's will mainly be the graphic library changes and the core code will be largely common. Problems I have encountered have been missing entries, doubled up entries (usually from trying to fix the reconciliation in another account), wrong dates on manually entered data (entering year in format not yy in the register), mismatches of dates between the banks records and mine, transaction which should have had a split to the account being assigned to another account (sometimes happens with transfers between asset accounts which can be assigned to an expense account by the matching procedures on import - I check them but occasionally miss one) instead of the asset account it is going to). I don't use checks/cheques now but when I did the problems Michael Novack mentioned were on the list. Good luck and good hunting. David Cousens On Wed, 2023-09-27 at 11:47 -0400, Mark Truelove wrote: > Hi again. Besides my tendency to be details-specific (given my professional > background), I also had some college level accounting and understand > double-entry, reconciliation, and the basics. No, I am not an accountant, > but I have been using GnuCash mostly successfully for more than twelve > years now. I am new to this list, but not to the topics we're discussing. > > Regarding using the wrong year for the reconciliation date, the program > suggests an approximate date based on the last, and at the moment that > recommendation is 9/24/22. This is not in a vacuum, however, because all > of the unreconciled transactions between August '22 and present are still > in the ledger awaiting reconciliation against these 12 or so monthly > statements that I just re-downloaded. If I'd simply entered the wrong > year, this would not be the case. > > I'd hoped this would have been something familiar to someone, only that I > didn't know about because I hadn't been on the list previously. Based on > the responses, it's beginning to look a little obscure now. > > On Wed, Sep 27, 2023 at 10:52 AM Michael or Penny Novack < > stepbystepf...@comcast.net> wrote: > > > > > > > > The purpose of reconciliation is to verify that from the last closing > > > date to the new closing date, the listed transactions cleared the > > > account and thus explain the change from the opening balance (last > > > closing balance) to the new closing balance listed on the statement. > > > > > > The actual balance, in your books, on a given day, or as of a given > > > day, is irrelevant to that reconciliation. > > > > > > Precisely. You EXPECT there to be a difference based on checks written > > (appear in the gnucash account) that have not yet cleared. In other > > words, the main part of the job (if no errors) is to verify that the > > total of checks written but uncleared matches the difference between the > > bank statement of the account and the gnucash account as of the date of > > the statement. > > > > When it still doesn't match you then need to find the error, a check not > > entered for the correct amount. Usually at your end but once I had one > > of these at a bank end. > > > > Michael D Novack > > > > ___ > > gnucash-user mailing list > > gnucash-user@gnucash.org > > To update your subscription preferences or to unsubscribe: > > https://lists.gnucash.org/mailman/listinfo/gnucash-user > > - > > 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 > - > 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 - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
[GNC] Saved reports in GNUCash 5.x
I eventually got around to installing a new Ubuntu 22.04 VM with flatpak, GNUCash 5.3 and postgres 14. All is well, except that I can't figure out where to put my customised invoices file: saved_reports-2.8 According to /https://wiki.gnucash.org/wiki/Configuration_Locations/ it should be in either one of these: /var/lib/flatpak/app/org.gnucash.GnuCash/current/active/files or /var/lib/flatpak/app/org.gnucash.GnuCash/current/active/files/share/gnucash However, I don't see the custom reports when I open an invoice. Can anyone help with some details please? regards Roland ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Reconciliation of accounts is not permanent
Mark, From this side of the Internet it almost appears that you are forgetting to save the data file after reconciling, but always remembering to save other times, which is not very likely. Have you tried breaking down your procedure and inserting cross-checks? ie, just before starting a reconciliation, save the file, then reconcile one month, save the file, review the reconcile box of the freshly reconciled transactions to verify that they are still reconciled on the correct reconcile date, save again, rinse and repeat as needed? I just tried the reconciliation report for the first time and found that it shows mountains of information about reconciliation status down to split details when they exist, so that may help you too. If, as I suspect, you do indeed discover that some reconciliations are not being properly recorded in your file, please both let us know here and also file a bug report. On Wed, Sep 27, 2023, 10:49 AM Mark Truelove wrote: > Hi again. Besides my tendency to be details-specific (given my professional > background), I also had some college level accounting and understand > double-entry, reconciliation, and the basics. No, I am not an accountant, > but I have been using GnuCash mostly successfully for more than twelve > years now. I am new to this list, but not to the topics we're discussing. > > Regarding using the wrong year for the reconciliation date, the program > suggests an approximate date based on the last, and at the moment that > recommendation is 9/24/22. This is not in a vacuum, however, because all > of the unreconciled transactions between August '22 and present are still > in the ledger awaiting reconciliation against these 12 or so monthly > statements that I just re-downloaded. If I'd simply entered the wrong > year, this would not be the case. > > I'd hoped this would have been something familiar to someone, only that I > didn't know about because I hadn't been on the list previously. Based on > the responses, it's beginning to look a little obscure now. > > On Wed, Sep 27, 2023 at 10:52 AM Michael or Penny Novack < > stepbystepf...@comcast.net> wrote: > > > > > > > > The purpose of reconciliation is to verify that from the last closing > > > date to the new closing date, the listed transactions cleared the > > > account and thus explain the change from the opening balance (last > > > closing balance) to the new closing balance listed on the statement. > > > > > > The actual balance, in your books, on a given day, or as of a given > > > day, is irrelevant to that reconciliation. > > > > > > Precisely. You EXPECT there to be a difference based on checks written > > (appear in the gnucash account) that have not yet cleared. In other > > words, the main part of the job (if no errors) is to verify that the > > total of checks written but uncleared matches the difference between the > > bank statement of the account and the gnucash account as of the date of > > the statement. > > > > When it still doesn't match you then need to find the error, a check not > > entered for the correct amount. Usually at your end but once I had one > > of these at a bank end. > > > > Michael D Novack > > > > ___ > > gnucash-user mailing list > > gnucash-user@gnucash.org > > To update your subscription preferences or to unsubscribe: > > https://lists.gnucash.org/mailman/listinfo/gnucash-user > > - > > 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 > - > 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 - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Reconciliation of accounts is not permanent
Hi again. Besides my tendency to be details-specific (given my professional background), I also had some college level accounting and understand double-entry, reconciliation, and the basics. No, I am not an accountant, but I have been using GnuCash mostly successfully for more than twelve years now. I am new to this list, but not to the topics we're discussing. Regarding using the wrong year for the reconciliation date, the program suggests an approximate date based on the last, and at the moment that recommendation is 9/24/22. This is not in a vacuum, however, because all of the unreconciled transactions between August '22 and present are still in the ledger awaiting reconciliation against these 12 or so monthly statements that I just re-downloaded. If I'd simply entered the wrong year, this would not be the case. I'd hoped this would have been something familiar to someone, only that I didn't know about because I hadn't been on the list previously. Based on the responses, it's beginning to look a little obscure now. On Wed, Sep 27, 2023 at 10:52 AM Michael or Penny Novack < stepbystepf...@comcast.net> wrote: > > > > The purpose of reconciliation is to verify that from the last closing > > date to the new closing date, the listed transactions cleared the > > account and thus explain the change from the opening balance (last > > closing balance) to the new closing balance listed on the statement. > > > > The actual balance, in your books, on a given day, or as of a given > > day, is irrelevant to that reconciliation. > > > Precisely. You EXPECT there to be a difference based on checks written > (appear in the gnucash account) that have not yet cleared. In other > words, the main part of the job (if no errors) is to verify that the > total of checks written but uncleared matches the difference between the > bank statement of the account and the gnucash account as of the date of > the statement. > > When it still doesn't match you then need to find the error, a check not > entered for the correct amount. Usually at your end but once I had one > of these at a bank end. > > Michael D Novack > > ___ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > - > 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 - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
Re: [GNC] Reconciliation of accounts is not permanent
The purpose of reconciliation is to verify that from the last closing date to the new closing date, the listed transactions cleared the account and thus explain the change from the opening balance (last closing balance) to the new closing balance listed on the statement. The actual balance, in your books, on a given day, or as of a given day, is irrelevant to that reconciliation. Precisely. You EXPECT there to be a difference based on checks written (appear in the gnucash account) that have not yet cleared. In other words, the main part of the job (if no errors) is to verify that the total of checks written but uncleared matches the difference between the bank statement of the account and the gnucash account as of the date of the statement. When it still doesn't match you then need to find the error, a check not entered for the correct amount. Usually at your end but once I had one of these at a bank end. Michael D Novack ___ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
