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 353602 - Virtual float accounts
Virtual float accounts
Status: VERIFIED WONTFIX
Product: GnuCash
Classification: Other
Component: Engine
unspecified
Other All
: Normal enhancement
: ---
Assigned To: Derek Atkins
Derek Atkins
Depends on:
Blocks:
 
 
Reported: 2006-08-30 21:21 UTC by Erik
Modified: 2018-06-29 21:12 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Erik 2006-08-30 21:21:39 UTC
Suppose one moves money from an account in one bank to another account in another bank. The money is removed from the first account at one point in time and added to the other account at another point in time. The money is said to be floating during that timespan. To model this in the program, one has to manually create a float account and add 2 transactions. But it is very inconvenient to enter several transactions for the same logical transaction. And it is harder to follow the flow of money, because the program does not keep track of which pair of transactions to/from the float account belong together. I think it should be possible to set different dates in transactions. The program would then be able implicitly connect this to a float account. The float account is virtual. The user can see how much he has floating on it, but can not enter transactions directly to/from it. He can only implicitly add transactions to the float account by making transactions between other accounts, where the times differ.

The user should probably be able to create several float accounts if he wishes, and choose which float account a certain transaction should use if it's times differ. Float accounts would of course not be stored in file, but recalculated from the transaction data.

The transaction would then have the following data:
* Source account
* Time that the money leaves the source account
{
* Target account
* Time that the money enters the target account
* Float account (where the money is if the times differ)
}

The part between { and } is repeated for split transactions.

Someone will say that one should do accrual accounting instead of cash accounting, but the bank accounts are cash accounts and therefore needs to be modeled with cash accounting. Accrual accounting can still be used for other accounts in the user's dataset.

This functionality is a requirement for adding more advanced functionality to the program, like interest calculation for bank accounts.

The relevant discussion is at:
https://lists.gnucash.org/pipermail/gnucash-user/2002-October/004391.html
Comment 1 Rolf Leggewie 2008-07-12 19:25:04 UTC
My vote goes for keeping the "in transit" account, because that represents reality, the money is in transit for people who want to track that.  Anything else will only lead to usability deteriorating as far as I can see it.

And seriously, do you move money around in your accounts so often that it is hard to track?  The thread you quoted also was mostly in favour of keeping things the way they are.
Comment 2 Christian Stimming 2008-11-07 21:35:10 UTC
(In reply to comment #1)
> The thread you quoted also was mostly in favour of keeping
> things the way they are.

Agreed.
Comment 3 Erik 2009-04-30 13:55:17 UTC
> My vote goes for keeping the "in transit" account, because that represents
reality, the money is in transit for people who want to track that.

Call it "in transit" account if you wish, as long as th pair of transactions to/from it belongs together, both during data entry and when browsing the data later. (Having just 2 transactions with the same amount but that the data model does not consider connected would be pointless.)
Comment 4 John Ralls 2018-06-29 21:12:05 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=353602. Please update any external references or bookmarks.