GnuCash V 3.2 (also 3.0 and 2.6.21) German version on a SQL Data file running on Mac OS 10.13.6 (High Sierra) on a MacBookPro: Entered a few (8) invoices for one customer, managing to duplicate one invoice after editing it (wrong customer assignment, this editing DID go thru). The invoice's billing of all three instances cannot be undone, preventing editing of the invoice. Other invoices for the same customer CAN be billed and "unbilled". Tried saving the data as XML file and attempted unbilling there -no joy with either V 3.2 or 2.6.21. Tried unbilling from the tool bar as well as from menu - no joy either way. Toolbar button visibly reacts to click, but comes up unchanged, i.e. does not perform its function. Looks to me like some fault in the billing module irrespective of data model. Greetings from ol'Europe.
Thank you for your report. I'm afraid however I don't understand exactly what your issue is. The terms "billing", "billed" and "unbilled" are a bit ambiguous to me in this context. It's also unclear what you mean with "The invoice's billing of all three instances cannot be undone". What are "instances" in this context ? Perhaps you can attach some screen shots (with sensitive data edited out) ? Based on a fairly liberal interpretation of your description, could this be a duplicate of bug 796836 ?
Hi, Geert. Firstly: I do NOT think this is a duplicate of bug 796836 (which I understand deals with amount sometimes being registered with the inverse amount) What happens in my case is that I 1. create a new bill by entering a bill ("Rechnung" in my German GC) in the dedicated window titled "Neue Rechnung" ("new bill" I guess, in English) 2. enter customer ("Kunde") name and order name ("Auftrag") and any other required data 3. fill out the items of the bill in a window titled "(data file name) - Rechnung anzeigen - (bill number, e.g. 2018007) - GnuCash" and then enter it ("bill" it, book it, register it, make it a transaction, ... what would be the acceptable term?) by hitting the menu "Bearbeiten" (from the left: GnuCash - Datei - Bearbeiten - Ansicht - ...) presumably GnuCash - File - Edit - View - ... in English i. e. the "Edit" menu > "Rechnung buchen" (sixth item from the top in the dropped down menu, not counting the header "Bearbeiten") 4. have the bill now established in the data set 5. notice I have made some error and 6. now try to "unbill" it ("unhook"?, "unregister"?, remove it from the (not user accessible) list of finalized bills?) in order to edit it again by hitting Bearbeiten > Rechnungsbuchung rückgängig (drop down menu entry just below "Rechnung buchen") Step 6 fails occasionally under the circumstances described in the OP. I have not been able to identify a trail, which reproducibly leads to this sorry state; nor a trail which prevents it. Since I dumped the messed up data file and fell back on a backup I cannot (allowing I would be foolish enough to spread my financial data around) supply the messed up data for inspection. The file was an about 40 MB Sqlite data file. If I ever get an attack of acute free time I may try to reproduce the state in a dedicated test file ;). Until then only some thought: it "felt", as if there was a hidden bill somewhere, preventing the "unbooking" access to the bill. Could there be a link not reset by "unhooking" a bill then preventing the "unhooking" for the next bill? Not a very strict error analysis, I realize... Cheers
Ok, I'll add the proper terms in English to avoid confusion: 1. Create "New Invoice" 2. Enter "Customer" and "Job" and any other required data. 3. Add entries to the invoice in the main invoice window, called "(data file name) - Edit Invoice - (invoice id) - GnuCash and then "Post" it using Edit->Post Invoice. 4. Invoice is now in the data 5. Notice some error 6. Now try to "Unpost" the invoice using Edit->Unpost Invoice. When it happens next time, please attach the gnucash trace file and some (censored) screen shots of the bad state. That may contain hints as to why the invoice can't be unposted.
Hi Geert, this bug has gone stale by now. I cannot for the love of it recall what I did at the time... I suggest to kill it. On the other hand....: Since I have started using invoices quite a bit recently, I have meanwhile found, that an invoice without any item (the "transaction like" line with Date, "Rechnung erhalten", Description, Action, account, number, price per item, ... etc.) [which corresponds to a record in the "entry" table of the sql file] cannot be posted and CANNOT have an item added in the invoice body; the first line is shown as dated 1 Jan 1904, and neither can the date be edited nor the rest of the item. I have taken to the workaround of messing with the sql file directly with GC not running, identifying the invoice UID and creating a dummy record in the "entry" table, linking that into the invoice record and then closing the sql editor, starting GC, posting the invoice (this now can be done), unposting it and voilà, the invoice can now be edited. Knowing this, I am now VERY careful not to mess with items in pre-existing invoices ;=) Cheers after many years from -at present- Corona Country. Joachim
Hi Joachim, It's by design that you can't post an invoice without entries. I don't understand however how you can get into a situation where you can't add entries either if the invoice is unposted. Does such an invoice have a post date ? The default entry date for your new entries should be derived from your bill's opening date. 1 Jan 1904 seems like an uncommon date. Also what version of gnucash are you currently using ?
Hi Geert, Currently on 4.4+ 2020-12-28 as per splash screen. Not being able to post an "empty" invoice was *not* surprising, not being able to EDIT it *was*. Isn't 1 Jan 1904 the "zero" date of Mac? If I recall correctly, the invoice was NOT yet posted, so there was no posting date. I have meanwhile cleaned up the misfits by the mentioned workaround and I am reluctant to mess around with my data file to create one again. Cheers J
> Isn't 1 Jan 1904 the "zero" date of Mac? Nope, midnight UTC 1 Jan 2001 is: https://developer.apple.com/documentation/foundation/nsdate/1417376-timeintervalsincereferencedate?language=objc But GnuCash uses Unix time so 0 is midnight UTC 1 Jan 1970 And before you ask, it's not Microsoft Windows system time 0 either, that's 1 Jan 1601: https://docs.microsoft.com/en-us/windows/win32/api/winternl/nf-winternl-ntquerysystemtime
I stand enlightend. :) But see: https://docs.microsoft.com/en-us/office/troubleshoot/excel/1900-and-1904-date-system for - to be precise - the zero date of Macintosh EXCEL, according to M*soft. Cheers
(In reply to Joachim Wetzig from comment #8) > I stand enlightend. :) > > But see: > https://docs.microsoft.com/en-us/office/troubleshoot/excel/1900-and-1904- > date-system > > for - to be precise - the zero date of Macintosh EXCEL, according to M*soft. > > Cheers And what exactly does that have to do with this bug?
