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 301264 - Changing anchor split in register is ignored by gnucash
Changing anchor split in register is ignored by gnucash
Status: VERIFIED DUPLICATE of bug 166101
Product: GnuCash
Classification: Other
Component: Register
1.8.x
Other Linux
: Normal normal
: ---
Assigned To: David Hampton
Chris Shoemaker
Depends on:
Blocks:
 
 
Reported: 2005-04-20 02:59 UTC by Mark Johnson
Modified: 2018-06-29 20:51 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Mark Johnson 2005-04-20 02:59:31 UTC
Version details: 1.8.11
Distribution/Version: Slackware 10.0

I don't have the auto-split style of register selected, but I don't think it
alters this behaviour.

1. Open a register (Eg. Assets:checking)
2. Enter a transaction description which will activate quick-fill.  At this
point, I click Split in the tool bar to show the splits. (Mine shows the split
anchoring the transaction to this register as the last row.)
3. Tab through the splits until you get to the split for Assets:Checking.
4. In the split for Assets:Checking, change the account to something else (Eg.
Expenses:Groceries)
5. Tab over to the "deposit" column.  Enter an amount.  Tab over to the
"withdrawal" column.  Delete this amount.
6. Tab to a new split. 
7. Tab over to select an account.  Select Assets:Checking.
8. Hit Tab again.
9. Hit Enter.
10. Observe that gnucash has altered the account selected in step 4 to once
again be its original value - Assets:Checking.  However, you now have two splits
for Assets:Checking, and none for Expenses:Groceries.  This is incorrect.  

Once this transaction is entered, my checking account register now shows two
transactions (as a result of two splits referring to the checking account).  My
checking account balance is wrong.  My grocery expenses are wrong.

I expect that gnucash has changed that split back to its original account
because the transaction must have a split anchoring it to the current register's
account.

Note that hitting Tab vs. Enter is important in reproducing the above.  For
example, in step 6, if you hit Enter instead of Tab, nothing appears to happen.
 Hitting Enter again causes the transaction to disappear!  Also an incorrect
behaviour.  (Possibly this should be a separate bug, but I think the person
checking/repairing this one should make that decision.)

I see two options for repair.
First option: do not allow the user to change the account for the split which
anchors the transaction to this register.  This would be done preferably by
graying out the account selection for that split. Alternatively, gnucash could
post a dialog drawing this to the user's attention.

Second option: Scan the list of splits just before entering the entire
transaction to make sure that at least one split exists to anchor it to the
current register's account.  Show a dialog to call the problem to the user's
attention.  Don't enter the transaction until corrected.

I prefer the first option, and suspect it is less work (especially if you just
do the graying out rather than making a dialog).

In the meantime, I have a workaround: never change the account in the split
belonging to this register's account.  You can safely change this split's amount.
Comment 1 Christian Stimming 2005-04-20 08:15:18 UTC
Thanks for this precise and verbose bug report. Yes, the two splits are
obviously wrong. However, your observed behaviour "Hitting Enter again causes
the transaction to disappear" is a quite common case, i.e. it means that you
commit your changes after description step 5. instead of continuing to edit that
transaction. In that case, the transaction has no longer a split in the current
amount, and it (correctly!) immediately disappears from the current account's
register, but it is now visible in the other register(s). So that behaviour is
quite right. Nevertheless I'm not sure what about your original problem. IMHO
it's wrong that gnucash modifies the account of that one split, but I don't know
how to fix it. Probably some other developer knows.
Comment 2 Mark Johnson 2005-04-22 14:33:58 UTC
I understand why that transaction disappears, but it is certainly unexpected
behaviour for this user.  So I disagree that it is quite right.  It may also be
a separate issue from this bug.
Comment 3 Chris Shoemaker 2006-03-20 18:54:31 UTC
Regarding the secondary issue of the disappearing transaction: I don't feel strongly about it, but if you do, this belongs as a separate bug entry or RFE.  Perhaps Gnucash should let the transaction be re-anchored and then show a dialog saying "The transaction is no longer anchored to this register/account, so it will no longer be shown here."  *poof*


*** This bug has been marked as a duplicate of 166101 ***
Comment 4 John Ralls 2018-06-29 20:51:27 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=301264. Please update any external references or bookmarks.