[Kmymoney-devel] [Bug 248420] New: Transaction templates with formulae
csioulis
csioulis at dsa.gr
Thu Aug 19 19:34:40 CEST 2010
https://bugs.kde.org/show_bug.cgi?id=248420
Summary: Transaction templates with formulae
Product: kmymoney4
Version: unspecified
Platform: Ubuntu Packages
OS/Version: Linux
Status: UNCONFIRMED
Severity: wishlist
Priority: NOR
Component: general
AssignedTo: kmymoney-devel at kde.org
ReportedBy: csioulis at dsa.gr
Version: unspecified (using KDE 4.5.0)
OS: Linux
It would be very comfortable to have the ability to predefine some
templates of transactions that we could later choose from a menu to use
for easy data entry.
These templates should be like "scheduled transaction" but with the
following diversities:
a) they should be able to use relations (formulae) between the fields of
amounts (in splits). This means that you should define some amounts to
be computed through simple relations (i.e. X = A * 10/100, or Y= B-A)
from other amounts in the same transaction (through local variables) and
when you call such templated transaction from the relative menu you have
to fill only part of the amounts in splits (given that the other fields
like memos should be already predefined)
b) They should be organized in -and called anytime by- a structured menu
(with categories/titles defined by users) than to be scheduled at a
specific time or frequency. (of course it would be positive if they
could be scheduled also!)
c) I imagine the wizard for defining templates as the one for making a
schedule with splits, but in instead of the column for amounts it should
have two columns named "Demand As" (where the user puts a name for the
variable) and "Compute As" (where the user would be able to define a
formulae based on the names of variables and simple function/operators).
Each split must have filed only one of these columns.
d) Later, when the user "calls" a specific template, a wizard should
demands from him the specific amounts with the names of the variables
that he had defined and when it complete them, he should be passed at a
regular split transaction window (with all the values filled as numbers
-not formulaes) to accept (post) it or to make minor correction (ie in
memo fields). The cancel button must return him to the previous wizard.
Some arguments and thoughts about this feature:
* It should reduce the amount and the procedure of the data-entry (which
is very important issue in all programs of this kind). It should also
reduce data-entry errors.
* The use of formulaes (that has already mentioned as a to-do feature
for KMM and that Gnucash has already implemented this) it has to be
implemented only in a concept of a 'template' of transaction(s)
* All the users in their user cases, apart of the useful scheduled
transactions, they usually repeat a set of similar transactions
occasionally. Duplicating one previous similar transaction helps, but
you have to find it searching in the correct ledger (here is where a
structured user-defined menu helps) and if it has many related splits
you have to update the amounts on each of them (here helps the
formulae).
* Such a feature should help to overcome -in one point- the lack of some
business features and of other similar requests (as 'roommate' feature).
For example you will easily define commissions, share expenses through
partners or groups, compute automatically VATs in multi-split
transactions (now it happens only in simple 2-splits transactions with
only one category assigned to them), etc.
* The set of the functions/operations hasn't to be extensive. Basic
operations plus some aggregations (as SUM or AVERAGE) are enough. Maybe
the syntax and the use of an external interpreter (such as perl or
python) in formulaes may do the job.
* It would be a big plus if there were also some "global variables" to
use in these formulae, such as the balance of a (specific) account, or
the balance of a specific payee.
Reproducible: Didn't try
--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the KMyMoney-devel
mailing list