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 120854 - Entering the current value instead of the increase/decrease
Entering the current value instead of the increase/decrease
Status: RESOLVED OBSOLETE
Product: GnuCash
Classification: Other
Component: Register
unspecified
Other All
: Normal enhancement
: ---
Assigned To: David Hampton
Chris Shoemaker
Depends on:
Blocks:
 
 
Reported: 2003-08-27 17:38 UTC by Joachim Breitner
Modified: 2018-06-29 20:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proof of concept, does not handle every case well (4.74 KB, patch)
2012-11-25 20:49 UTC, Joachim Breitner
none Details | Review
Better proof of concept (5.24 KB, patch)
2012-11-25 21:13 UTC, Joachim Breitner
none Details | Review
Handle the blank split better (5.26 KB, patch)
2012-11-25 21:30 UTC, Joachim Breitner
needs-work Details | Review

Description Joachim Breitner 2003-08-27 17:38:56 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.
Comment 1 Chris Shoemaker 2006-03-17 16:00:27 UTC
I have no idea what this means.  Are we talking about exchange-rates here or what?
Comment 2 André Klapper 2006-07-07 02:28:46 UTC
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!
Comment 3 Joachim Breitner 2009-04-25 10:10:43 UTC
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? :-)
Comment 4 Phil Longstaff 2009-05-29 22:14:07 UTC
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.
Comment 5 Joachim Breitner 2009-05-29 22:30:44 UTC
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.
Comment 6 Phil Longstaff 2009-05-29 23:10:24 UTC
Simply because that is much more work.
Comment 7 Joachim Breitner 2009-05-30 09:59:02 UTC
Ok, point taken :-)
Comment 8 Christian Stimming 2009-11-27 09:00:47 UTC
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.
Comment 9 Joachim Breitner 2009-11-27 10:13:32 UTC
(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.
Comment 10 Joachim Breitner 2012-11-25 20:49:32 UTC
Created attachment 229837 [details] [review]
Proof of concept, does not handle every case well
Comment 11 Joachim Breitner 2012-11-25 20:55:48 UTC
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?
Comment 12 Joachim Breitner 2012-11-25 21:13:50 UTC
Created attachment 229842 [details] [review]
Better proof of concept
Comment 13 Joachim Breitner 2012-11-25 21:16:39 UTC
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.)
Comment 14 Joachim Breitner 2012-11-25 21:30:41 UTC
Created attachment 229861 [details] [review]
Handle the blank split better
Comment 15 Geert Janssens 2013-02-08 15:03:22 UTC
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 ?
Comment 16 Geert Janssens 2013-02-08 18:24:52 UTC
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.
Comment 17 Joachim Breitner 2013-02-09 14:01:31 UTC
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.
Comment 18 Geert Janssens 2013-05-17 20:02:30 UTC
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.
Comment 19 Joachim Breitner 2013-05-17 20:06:52 UTC
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 :-)
Comment 20 John Ralls 2018-06-29 20:36:31 UTC
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.