GNOME Bugzilla – Bug 120854
Entering the current value instead of the increase/decrease
Last modified: 2018-06-29 20:36:31 UTC
<nomeata> benoitg: what I would like to see it that you at least can enter the current value and it calculates the right amount for this transactions (for the beer case). <benoitg> nomeata: Good point... where the beer case is: <g~benoitg> nsilva: It happens all the time. For example I don't sum the cost of every bear I drink in a bar. I just count how much money is left, and write an adjestement trnasaction.
I have no idea what this means. Are we talking about exchange-rates here or what?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information Chris asked for. Thanks!
Sorry, I must have missed the request for additional information somehow: In the regular account view, when entering a new transaction, I have enter the amount either in the “increase” or the “decrease” column. What I’d like to see is that I can also enter the current balance in the “balance” column, and the correct increase or decrease is calculated by gnucash. The use case is, as benoitg describes, this: I know that my gnucash account for my cash is up to date. I then go somewhere where I make payments that I don’t remember individually. So the next morning, I count my money and want to enter that, instead of manually substracting the counted balance from gnucash’s last recorded balance and entering that in the decrease column. Does that make more sense now? :-)
It wouldn't be hard to add a menu entry to 'Update balance' which would pop up a dialog box where you enter 1) balance and 2) account to use for the balance. It would be harder to allow a split where more than 1 account is used.
Why not just make the “Balance” column writable if the Basic Ledger view is active and no split transaction is being entered? This would avoid having to create an extra dialogue.
Simply because that is much more work.
Ok, point taken :-)
Note that entering this sort of balance difference transactions is already possible by using the calculator features of the amount field, i.e. if the balance yesterday was 23.45 and today's balance is 12.34 you can enter a balance with the amount "23.45 - 12.34", which is calculated to the correct amount on-the-fly.
(In reply to comment #8) > Note that entering this sort of balance difference transactions is already > possible by using the calculator features of the amount field, i.e. if the > balance yesterday was 23.45 and today's balance is 12.34 you can enter a > balance with the amount "23.45 - 12.34", which is calculated to the correct > amount on-the-fly. Right, this is precisely what I’m doing so far. It’s just a bit tedious, as I have to manually copy the current balance, and consider whether I have to put the difference in the increase or decrease column.
Created attachment 229837 [details] [review] Proof of concept, does not handle every case well
Hi, I still believe that it should be possible to have the computer do for me what I’m currently doing manually, by copying the balance into the debit field and subtracting the current balance. I have attached a patch that enables this feature for existing transactions (even split transactions). It makes the balance column editable, and if, after editing, it differs from the previous balance of that split, the difference is added to the amount. In views of several accounts or in search results, the balance column is not editable. What do you think – is this a viable approach?
Created attachment 229842 [details] [review] Better proof of concept
The updated patch now also handles the case where the user edits the blank split at the end of the ledger; in that case, if he modifies the balance column, the total balance of the account is taken to calculate the difference. (Actually, the patch 229842 is broken when the user does _not_ modify the balance field, I’ll fix that right away.)
Created attachment 229861 [details] [review] Handle the blank split better
Review of attachment 229861 [details] [review]: First, my apologies for taking so long to review your patch. I got caught up in a lot of other work. On the patch itself: the calculations work very well. I can enter an amount in the balance column after which the credit or debit column is properly updated. Very nice ! But there is also still a glitch in the gui refresh code you should try to solve. There seems to be an issue when you click on a row with a negative balance. When you do that, the balance cell will be updated to the value of the last row previously selected with a positive balance (or 0 balance from the empty split). It doesn't trigger any recalculations, and is only visible as long as the row is selected. When you select another row, the balance cell in the previously selected row will show the correct negative value again. Can you verify this ?
Additionally, when playing around some more the following issue also appears: - I had entered a new transaction the traditional way (ie using a decrease, not the altering the debit value) - I moved to another registry row, and then decided that I had entered a wrong value. - So I went back to the transaction just entered and change the debit amount - Hit enter => What I entered is ignored. Instead another value is entered to come to some balance I didn't intend. Note that I didn't alter the balance manually. An example to play with (entered in a Liabilities account): - What I entered the first time: Description: Some transaction Transfer: Expenses:Groceries Increase: 1000 => Finishing this entry, I get a net balance of 4930,78 € - I leave the entry and enter it again - Change the Increase to 500 - Hit return to leave the transaction => Increase now is empty, instead my Decrease is set to 9361,56 €, the balance is -5430,78 € (negative!) So what it seems to have done is adding 500 to the original balance and then reverse the sign, recalculating what the difference should have been. Setting the Increase back to 1000 restores the original balance. However changing it again will mess it up again. It looks like you have some sign issues in your code.
Dear Geert, thanks for the review. Luckily, my changes still apply cleanly to the latest code, so I can continue working on it (although I probably forgot completely what I did :-)). I cannot reproduce the UI glitch. I have created a new account, added 10€ and in the next transaction, removed 20€. Now I can click around wildly, and the balance columns remain unchanged. What I notice is that if move the focus to the balance field, its color changes back to black while editing. Is that what you mean? Is that a problem? Unfortunately, I also cannot reproduce the other problem. Unless you have been editing both the increase and the balance in one go: This does yield somewhat unpredictable behavior, as it first calculates the change according to the balance, and then adds the change entered in increase/decrease. Also, I notice that setting the balance to 0 does not work, although from reading the code I don’t see why. It seems guess someone with better knowledge of gnucash internals (gnc_numeric_sub,gnc_price_cell_get_value) than me needs to have a closer look at the actual code I wrote.
I haven't done any further testing, but it's very well possible that what I experience only happens in some type of accounts. Some accounts do internal sign inversion before displaying or reading values. In my example I played with a Liabilities type account. You didn't specify which account type you were using, but perhaps it was of a kind that doesn't do sign reversals. Additionally I'll add that the register is currently undergoing a complete rewrite. See bug 673193 and all its dependencies. So for your feature to appear in future versions of GnuCash, I'm afraid you will have to rewrite your code against the new register code.
Ok, thanks for the warning about the rewrite; I guess I’ll just wait for that to be done before I look into this again. I have been living without the feature for more than 10 years now, I can wait another year or two :-)
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=120854. Please continue processing the bug there and please update any external references or bookmarks.