Beyond inconvenience questions, I think error questions are more weighty. If the engine creates a balancing split, you see it and react. And if, for some reason, you don't see it, you'll catch it later by noticing that the imbalance account has non-zero balance.
On the other hand, if gnucash changes the other split and that's not what you meant, but for some reason you accept the transaction anyway (say because hitting return is a highly ingrained behaviour), it would be very difficult to catch later. (It also introduces weird behaviours where the engine has to keep track of how many times you've edited splits and in what order in order to know when to create an error split or adjust some other split. That quickly becomes non-intuitive for users.) Jeff On 03/12/18 23:11, David Cousens wrote: > Dave, > > The problem for GnuCash is that when you have duplicated a previous > transaction and then edit it, GnuCash has no way of knowing what your > intentions are. The engine is currently setup to maintain a transaction in > balance as it is edited. When you change the value of one split of the > transaction, the engine is designed to calculate the difference between the > new sum of the splits and zero and allocate that to the Imbalance account > which simplifies creating transactions with 2 or more splits. > > It would be feasible in principle to detect whether the editeded transaction > only has two splits and to adjust the value of the second split rather than > the imbalance account in that case. How easy that is to do will require a > close look at how the engine manages the balancing. > > This introduces a further complication however. If your intention was to > change this to a transaction with 3 or more splits. You could not do what > you would do at present which is edit the existing two splits into an > imbalanced state and have GnuCash create the 3rd split automatically and > allocate it to the Imbalance account which you then reassign to the account > you desire that split to go to. > > You would have to create the split to the third account and assign it a > value first to break the two split calculation as above out of the two split > mode rather than just edit the existing splits. > > It will be a judgement call as to how many users would be inconvenienced by > the current approach relative to those who would then be inconvenienced if > it was changed as described above. > > Perhaps raise a feature enhancement request at bug.gnucash.org. > > David Cousens > > > > ----- > David Cousens > -- > Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html > _______________________________________________ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > If you are using Nabble or Gmane, please see > https://wiki.gnucash.org/wiki/Mailing_Lists for more information. > ----- > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. -- Jeff Abrahamson +33 6 24 40 01 57 +44 7920 594 255 http://p27.eu/jeff/ http://transport-nantes.com/ _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.