Many of my transaction entries are auto-filled, that is, I'm entering a receipt from a previously used payee. GnuCash helpfully and dutifully fills in the last matching transaction splits for me and I begin editing. Some of this editing involves deleting splits to accounts that aren't pertinent to this transaction. Occasionally, I have two or more splits assigned to the current register's account. If I intentionally or inadvertently delete one of them, the entire transaction simply disappears and I'm back at a blank transaction. No warning is given. (if I were editing an already saved transaction, a warning does appear that I'm deleting the split that ties the transaction to that register) Certainly, there are workarounds, but 'blowing up' your entry and not even telling you what happened just doesn't seem like a user friendly practice. Ideally, I would like to be able to delete splits at will and there not be any issue. If I save the transaction without a split tying it to the current register, I expect it would then no longer appear there, and even then a warning would be nice, but this is what I currently have to do: 1. Start the transaction and accept the auto-fill (no choice here really) 2. Edit everything I need, zeroing out the splits tied to the current register I don't want but otherwise leaving the account assignment untouched. 3. Open the transaction in some other register with tied splits. (either manually or via the Jump function) 4. Delete the split I don't want. I can alternately assign the unwanted split to some other account and then delete it, but that's still an extra step of workaround. It seems the code checking on the tied-splits is firing too early, and doesn't take into account that other splits might still be tying the transaction to the current register. Steps to reproduce: 1. Create a transaction with two or more splits with the same account assignment as the current register. 2. Create other splits as desired for balance. 3. Save the transaction. 4. Create another transaction with same Description, observe GnuCash will auto-fill the previous splits. 5. Delete ONE of the splits assigned with the same account. 6. GnuCash will cancel the entry and leave you at a blank transaction despite one or more splits remaining that still ties the transaction to the register. 7. Observe no warning or way out is given.
I have been looking at this and it looks like the autofill transaction gets copied to the blank transaction and the blank split is used for the first split of this new transaction but the reg does not get updated with the new blank split. As part of the delete handler the split is compared to the blank split and if they match the action is cancelled. Need to figure out where this needs updating.
I have added a possible fix to PR442, need to see if it is accepted.
https://github.com/Gnucash/gnucash/pull/442 merged, will be released in GnuCash 3.4.
I can confirm in testing today on 3.5, that this fix indeed addressed this issue. Attempting to delete the first instance of an anchoring split fires the warning and doesn't allow deletion. Attempts to delete subsequent anchoring splits works as expected. (they are removed) Thus, the first instance becomes the 'anchor' and the rest are allowed to be deleted. Thanks Bob! Note, there is one area left of inconsistent treatment on this point but I'll file it separately if it isn't already filed.
It seems I spoke too soon. I was editing a transaction in a liability account and I wasn't able to delete the extra anchoring split. I had to jump to another account and do it from there. Note, at least it didn't blow up the transaction, but the error message simply told me I couldn't remove the split.
Not sure I understand, what are you calling extra anchor splits? Can you attach screen shot of transaction and indicate what split you are deleting. Is this reproduceable?
Sorry, I've long fixed that transaction but I'll try to create a test and screenshot it for you. To answer the question, I'm calling any split assigned to the same account as the current register after the first such split an 'extra anchor split'. (I guess technically they shouldn't be 'anchors' but seem to act as one) PR442 appeared to fix this but apparently liability accounts are not affected by it. I'll also try to test other account types to see if there are others (equity?) which also need addressing.
There should be no difference between registers but what I have seen is if you open a register for account 'x' which has multiple splits of account 'x' there will be one anchor split but that might not be the first one in the list for that account. It may have to do with credit/debit order.
I tried every split. They all thought they were anchors. I'm in the middle of another project but I will get to creating a test transaction for this and report back on if I can reliably recreate the problem or not.
I'm not sure if changes were made for 3.7, but now we're back to being unable to delete any split with the same account assignment as the current register without first committing the transaction. In comment 5 I had learned that one of my liability accounts was still behaving this way, but my cash account was working as expected. (only 1 was the anchor and you could delete the rest) Now it is also my cash account. I'll see about testing others. Looks like this is back to square 1.
This just happened again with an asset account. (Accrued Revenue in this case, but other than name, nothing special about it) I cannot delete an auto-filled second split of the same 'anchor' account. (it doesn't crash, it just won't let me and tells me so) My Cash account still works as expected.
