Bug 135198 - kmymoney2: Virtual float accounts
Summary: kmymoney2: Virtual float accounts
Status: CONFIRMED
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: git (master)
Platform: Gentoo Packages Linux
: NOR wishlist
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
: 342989 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-10-06 14:39 UTC by esigra
Modified: 2021-03-24 16:33 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Tiny start for a patch. (12.41 KB, patch)
2006-10-06 22:54 UTC, esigra
Details
Tiny start for a patch. (16.41 KB, patch)
2006-10-07 17:23 UTC, esigra
Details
Table that describes the validity enforcement of the float data. (12.29 KB, application/vnd.oasis.opendocument.spreadsheet)
2006-10-07 17:24 UTC, esigra
Details

Note You need to log in before you can comment on or make changes to this bug.
Description esigra 2006-10-06 14:39:23 UTC
Version:           0.8.5 (using KDE KDE 3.5.4)
Installed from:    Gentoo Packages
OS:                Linux

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.

This request is also registered for gnucash:
http://bugzilla.gnome.org/show_bug.cgi?id=353602

The relevant discussion is at:
https://lists.gnucash.org/pipermail/gnucash-user/2002-October/004391.html
Comment 1 esigra 2006-10-06 22:54:32 UTC
Created attachment 18045 [details]
Tiny start for a patch.

This is just a tiny start of a patch. It makes it possible to edit, save and
load the information, but it is not used yet.
Comment 2 esigra 2006-10-07 17:23:02 UTC
Created attachment 18050 [details]
Tiny start for a patch.

This patch enforces validity when entering the information. See table (attached
soon) for explanation of the validity enforcement.
Comment 3 esigra 2006-10-07 17:24:57 UTC
Created attachment 18051 [details]
Table that describes the validity enforcement of the float data.
Comment 4 Ian Neal 2009-03-28 17:39:16 UTC
(In reply to comment #2)
> Created an attachment (id=18050) [details]
> Tiny start for a patch.
> 
> This patch enforces validity when entering the information. See table (attached
> soon) for explanation of the validity enforcement.

Is this patch still valid or has it bitrotted? I think this would be useful functionality for those that want it - perhaps pref controlled?
Comment 5 esigra 2009-03-28 18:43:05 UTC
I did not test the patch recently so it is probably bitrotted. It was never complete anyway.
Comment 6 Cristian Oneț 2014-08-20 20:31:53 UTC
Moving this wish to kmymoney4.
Comment 7 Thomas Baumgart 2015-01-18 07:42:49 UTC
*** Bug 342989 has been marked as a duplicate of this bug. ***
Comment 8 Thomas Baumgart 2021-03-24 12:37:11 UTC
*** Bug 434871 has been marked as a duplicate of this bug. ***
Comment 9 Roman Zimmermann 2021-03-24 16:33:38 UTC
*** This bug has been confirmed by popular vote. ***