GNOME Bugzilla – Bug 620281
Adding reversing transaction to bill transactions creates undeleteable transactions
Last modified: 2018-06-29 22:40:08 UTC
1) Create a transaction using the "Post" function of the "View Bill" tab. 2) Apply menu action "Transaction" -> "Add reversing transaction" to that transaction. Obviously the edit/delete protection is copied to the reversing transaction. This causes the transaction to be undeleteable, as only the original transaction can be deleted using "Unposted" from the "View Bill" tab.
Yes, that option does not apply to the business features and probably should be completely disabled.
I think it would be difficult to disable this feature as you suggest. An ordinary register doesn't make a distinction between transactions created when posting a bill or transactions created manually. But I think it would make sense to make sure "Add reversing transaction" doesn't copy the read-only state of the original transaction. That just doesn't make sense. Or would reversing a business transaction confuse the business logic in some way ?
Anyway, comment #1 confirms the problem so I have marked the bug as New (meaning confirmed).
(In reply to comment #2) > Or would reversing a business transaction confuse the business logic in some > way ? I believe this is the case.
I use the latest Stable (2.4.13) version of GnuCash, and I just ran into this problem last night. In my case, I accidentally "reversed" a posted invoice in the Accounts Receivable register (same logic as a posted bill, but on the accounts-receivable side instead of accounts-payable), and ended up with a transaction that I couldn't delete. I had to manually extract the .gnucash file to an XML, remove the offending read-only flag from the transaction(s) that I couldn't delete, re-compress to a .gnucash file, re-load and then I could delete the mistaken transaction. I believe the algorithm for preventing this would be VERY simple. IF a transaction is an auto-generated, posted business transaction (Is this the only reason for a Read-only flag?), then it should NOT be reversed or duplicated. Since I use GnuCash for my everyday accounting work, critical to my business, I am following the ordinary protocols, which means I have not tried the "unstable" 2.5 versions of GnuCash yet. If this bug is fixed in there, that's great, and we should just mark it as such. But if not, this would be a really good candidate for fixing in 2.5, since it's been open since 2.2 and not fixed in 2.4 yet, and it should be a very easy and isolated fix.
Thank you for reporting this bug and apologies for the long delay in replying. The issue you describe is a valid one and I have just committed a fix for it. It will appear in the next version of gnucash (2.6.12)
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=620281. Please update any external references or bookmarks.