GNOME Bugzilla – Bug 443971
Wrong Behavior on "Question" Window after Posting Invoice
Last modified: 2018-06-29 21:38:28 UTC
1. Create an invoice 2. Click on "Post" * a window called "Question" will appear 3. Without changing anything, click "Ok" * WRONG: The message "No Account selected. Please try again." will appear * Have a look at the "Post to Account" text field... It has the following text as value "Assets:Accounts Receivable" 4. Click on "New" and in the new window click "Cancel" 5. Now, click "Ok" and it will work As the text field "Post to Account" has content the error message "No Account selected. Please try again." was not supposed to be shown.
Thanks for your report. As your description is not very detailed, I'd ask whether you could additionally attach screenshots of the windows you are talking of ("create a new attachment" below)? Thanks.
Created attachment 89432 [details] window that pops up after clicking on "Post" (top bar) in the process of creating an invoice, and the error message I hope this answers your question. I don't think I can give you any other useful infomation for this.
Thanks for the screenshot. Is the account "Assets:Accounts Receivable" an actually valid or account, or is it marked as placeholder? In the latter case the error message should be fixed, but in principle it is okay that no transaction is posted to that account.
"Assets:Accounts Receivable" actually does not exist, but I don't think it is wrong to advise the user to use it, the same way as some other accounts are automatically created when you don't define for example the Incoming Account on a transfer.
Wait, it doesn't EXIST??? Um, then how is it showing up at all? The entry should be empty if there are no accounts of type A/R. The code in question resides in src/business/business-gnome/dialog-date-close.c in the function fill_in_acct_info() where it initializes the GNCAccountSel object: gnc_account_sel_set_acct_filters( gas, ddc->acct_types ); gnc_account_sel_set_new_account_ability( gas, TRUE ); gnc_account_sel_set_new_account_modal( gas, TRUE ); /* XXX: Some way to remember the last selection? */ gnc_account_sel_set_account( gas, NULL ); This latter function sets the active entry to "-1" which should mean "nothing". So, it could be a bug in your version of Gtk?
I encounter a slight variation of the problem. Whenever I post an invoice/bill, I usually only edit the date field and then click ok. In this scenario, I get the same error message: No Account selected. Please try again. In my case the account selected in the "Post to account" field does exist. In fact, if I simply click somewhere inthe selected account's text, I can click Ok and the bill/invoice gets posted successfully. Similarly, after editing the date, pressing the tab key until the post to account is/has been highlighted and then clicking ok causes no problems. So it is as if the initial value or default value for the widget is not set until it gets activated. For reference, I am using a self-compiled GnuCash 2.2.1 on Mandriva 2007.1. The version of libgtk+ is 2.10.11. For the record, I don't experience this problem with GnuCash 2.2.1 on Fedora 7, with libgtk+ 2.10.14. So, although annoying, this problem may solve itself automatically in the future.
It's unclear to me, but this may be a duplicate of bug #458653. Certainly, comment #6 is such a duplicate. Also, further to #6, this behavior still exists in libgtk2.0-dev version 2.12.3 on debian, so I'm not so sure that it will resolve itself automatically.
I have looked at bug #458653. The problem I am experiencing is indeed the same. My comment #6 may have been more appropriate to that bug. My remark that this problem might resolve itself was based on this irc conversation http://lists.gnucash.org/logs/2007/10/2007-10-03.html#T12:53:45 and the fact that I don't experience this problem on Fedora 7 (libgtk+2.10.14) On the other hand, my Mandriva installation is now at 2008.0, which uses libgtk+2.0_0-2.12.1-2.1mdv2008.0 and the problem still remains. So indeed it seems the problem won't resolve itself automatically.
In the meantime I have upgraded to Mandriva 2009.1, which ships GnuCash 2.2.9 and gtk+2.0-2.16.1. This release doesn't exhibit the problem anymore. I don't know if it was something in GnuCash, but given it has worked fine all the time on my Fedora system, I would suspect not. So unless the OP still has this issue, I propose to close this bugreport.
I didn't notice before that the bug is reported on Windows and against an old development release. There's another bug for this against a more recent release on Windows and Mac OS X, so I'll close this bug as a duplicate. Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 545319 ***
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=443971. Please update any external references or bookmarks.