After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 620281 - Adding reversing transaction to bill transactions creates undeleteable transactions
Adding reversing transaction to bill transactions creates undeleteable transa...
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Business
2.2.9
Other Linux
: Normal normal
: ---
Assigned To: Derek Atkins
Derek Atkins
Depends on:
Blocks:
 
 
Reported: 2010-06-01 17:14 UTC by Sebastian Busch
Modified: 2018-06-29 22:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastian Busch 2010-06-01 17:14:12 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.
Comment 1 Derek Atkins 2010-06-02 13:42:53 UTC
Yes, that option does not apply to the business features and probably should be completely disabled.
Comment 2 Geert Janssens 2011-10-06 20:50:30 UTC
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 ?
Comment 3 Geert Janssens 2011-10-06 20:51:07 UTC
Anyway, comment #1 confirms the problem so I have marked the bug as New (meaning confirmed).
Comment 4 Derek Atkins 2011-10-07 15:13:50 UTC
(In reply to comment #2)

> Or would reversing a business transaction confuse the business logic in some
> way ?

I believe this is the case.
Comment 5 David Beattie 2013-10-14 21:54:26 UTC
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.
Comment 6 Geert Janssens 2016-03-19 13:39:06 UTC
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)
Comment 7 John Ralls 2018-06-29 22:40:08 UTC
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.