Created attachment 373235 [details] Screenshot of falsely pre-filled field Greetings running GC V3.5 on Mac OS X 10.12.6 (High Sierra) German Language version Situation: Bill posted, acc/rec entry exists. Got payment by bank transfer, assigned it some times ago (marked as "Zahlung" i.e. "payment" in the bank account and acc/rec). Had to change the bill entry by unposting and reposting. This loses the link between bill and payment. Trying to reconnect it by opening giro account's window, selecting "process payment" ("Zahlung bearbeiten" in German) in the edit menu. Error: This opens a window captioned "Zahlung verarbeiten" with the customer ("Kunde") field pre-filled WITH AN ORDER NAME and a modal nagging window, that there is no useable acc/rec account to book to. See attached screenshot Workaround 1: Dismiss the nagging, select either supplier or employee in the top left button, then reselect customer. Now the customer list is properly assigned to the field and the acc/rec list is useable. Obviously an index error on which list to prefill the field with on opening the payment processing window. (Workaround 2: Use the lot editing) Cheers from the middle of Germany J W
I think this is a good use case to fix before the error window/message An empty account type "Kontoart »«" should not appear.
Hi Frank, after some private mail I *thik* I understand what your comment means ;) Let me add my extended comment: To me, who hasn't really looked at (i.e. found...) the underlying code, it "feels", as if the fields (1: customer, 2: acc/rec, ...) are meant to be filled from a number of lists, which are linked somehow, the customer being in e.g. list1, list2 specifying orders, list3 the accounts receivable, list4 something else, etc. List1 is MEANT to go to field1, list2 meant to be set aside, list3 meant to go to field 2, ... Somehow field 1 is prefilled however, with list2, list3 set aside, and field2 tried to fill from list4. List4 holds no useable account data and voila! the error message correctly points this out. Upon changing the desired list for field1 (e.g. from customer to employee) the whole kit and caboodle is re-matched and when you then reset the field1 desire to "customer" it then matches. This may point to one error which I frequently made in my programming days (do you remember Fortran?): initialising a pointer to lists (or arrays, in the olden days) with 0 instead 1 or vice versa. Now, having taken up more of your time, if someone can point me to where I can find the code underlying this entry window I might give it a try to decipher the logic and look for the culprit. Cheers Joachim
Jo, here's a simple trick you can use to find the code associated with a German phrase: Open po/de.po--I like command line tools for this sort of thing, so I just use `less`--and search for the phrase. For example, if you search for "Zahlung verarbeiten", you'll be taken to that msgid. Above it you'll get what the English is so you needn't guess, and above that is listed every line of code that it's used: #: gnucash/gnome/dialog-customer.c:912 gnucash/gnome/dialog-employee.c:692 #: gnucash/gnome/dialog-invoice.c:3058 gnucash/gnome/dialog-invoice.c:3067 #: gnucash/gnome/dialog-invoice.c:3078 gnucash/gnome/dialog-invoice.c:3333 #: gnucash/gnome/dialog-invoice.c:3339 gnucash/gnome/dialog-job.c:560 #: gnucash/gtkbuilder/dialog-payment.glade:61 msgid "Process Payment" msgstr "Zahlung verarbeiten" From there you can see what functions are called and grep for them in the source.
Thx John, that helps. Now for unravelling the logic...
Hi, the error message is raised in gnucash/gnome/dialog-payment.c:1344 On revisiting the error I verify, that the owner combo box data is correctly set up. The transaction data widgets also show correct data. It's just the "post acct" combo that is falsely associated with an empty list. (The transaction is a simple, non-split, giro to a/r transaction) The erroneous association persists even after re-attaching the payment, by way of the workaround, to the a/r entry (checked by looking at the lot in the a/r account, which holds just the payment and the invoice entries). At this point I am stuck and leave further work to the gurus (Geert?). Cheers Joachim
I confirm the bug is also present in v4.2, on Windows.
