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
One of the variables could be the balance of an account. We received the following via e-mail: I'd like to propose a small functional improvement: in scheduled transactions, allow the user to use data from accounts to fill the amount field. *_Use case_*: _Introduction_: In my country, bank-issued credit cards are a kind of combination between credit card and a debit card in US terms. Every expenditure by the user is going towards the "debt" of the card. At some set point in the month all off the debt is covered (returns to zero) by transferring the debt amount from checking account to the credit card account. The user cannot change the amount being transferred - all debt of the card has to be zeroed. So, once a transaction has been made the money will be transferred from checking at a given date. KMyMoney is the only application (from those I tested) that asks to create a scheduled transaction at the creation of a credit card account (- big thumbs-up for that!). _Desired functionality_: In scheduled transaction creation the user should be able to "say" that he\she want the amount to be "all of the debt in a specific account" (for credit card creation wizard, the only account available will be the account that is being created). _Suggested UI_: Expand the 'Amount' field to be two fields with radio button for each field. Selection of a radio button makes the associated field enabled. Field 1: the regular numeric text box that is present today. Field 2: editable combo box to select an account (for credit card creation wizard, it will be a text block that says "All of the amount in this account"). _Benefits_: Right now, the scheduled transaction is just a necessary burden that the user has to complete once a month for each card: 1. See what is the debt of the card. 2. Fill that amount in the ledger. Totally automatic with no decision to make. When you do this for 10 cards it could get quite annoying. This suggestion will allow to have the transaction fully automated and remove the burden from the user, making KMyMoney even more awesome.
Credit Card management is just a sub-case of the template's (with formulae) usability. For formulaes we need to use two kinds of variables (and operations between them): A. Constant variables, which should be defined by the user in a table with a pair of fields (Name vs value) such as commission or tax percentages, and B. Computed (from kmm data) variables, given from some predefined functions (which should accept argues!), such as -Balance(account/category, date/period), -Sum(acount/category,[payee,] date/period), and maybe more ... All these seem to be very complicated to be done either from the view of the appropriate GUI (how do you write operations combined with such functions/variables with arguments in a "amount" field???) also for the implementation in code! The BEST way to accomplish the creation of convenient "user defined variables" (to be used in formulaes) with pretty GUI and with simple code reformation, is to use a sub-part of the existent Report's Wizard constraining it in such way that it should create reports/queries that return only one value as a result! Imagine that the user would be able to define his own variables/queries/reports (with the name of his like, i.e. "My X-Bank-Card Balance Last month" -maybe accompanied with a shortcut of one word to be used in formulaes as variable) which would be defined through a similar (a reduced part) of the current Report Wizard where he could choose/filter accounts, categories, payees, dates/periods, even text filters, to take the exact result for his variable! For example, we should be able to create through this wizard very complicated but only "one-value-return reports"(=variables) such as "Sum of sales of categories X,Y for the payees C,D &E for last year where transaction amount > 500 and in memo exist the name John" named as "John_lastyear_sales" and then we could simply write in the "computed field" of the template a simple expression such as [John_lastyear_sales * Sales_Commission_Const] to automatically compute the consequential commission for John! (I always ask for excuse me for my bad English!)
*** Bug 343801 has been marked as a duplicate of this bug. ***
This is an awesome request with many parts. So awesome that I fear it will never be complete. I do encourage who ever picks this up to "nibble" at it a feature at a time. "Good code is not created, it evolves." George Anzinger
(In reply to george from comment #4) > This is an awesome request with many parts. So awesome that I fear it will > never be complete. I do encourage who ever picks this up to "nibble" at it > a feature at a time. > > "Good code is not created, it evolves." > George Anzinger I agree with that, nevertheless it's good to have the bigger picture in front while thinking about developing something even if if it will be done in small steps.
I +1 the Credit Card management part in a first step. Having some kind of formulaes within the scheduled transactions would be great.