I feel that you are already aware of this issue, however I understand that the implementation of a correct treatment of transfer transactions needs considerable re-designing in both forms/dialogues and data-entry functions/code.

Classical cases of transfer transactions are: Boring money (liability->asset), pay a debited Supplier (asset->liability), withdraw/deposit money from/to bank accounts (asset->asset) or using another liability/loan/bill/check [in Greece it is common to issue post-date checks]- to repay another liability (liability->liability).

Currently, with the existing 'simplified approach' on transfer transactions data-entry system, -where we have to put only one Memo, only one No of transaction and only one Payee-, we encounter many correctness and/or awkwardness issues.

This happens because notwithstanding that initially (in form) we enter ONE value at these three fields, the program/script COPIES these values to TWO DIFFERENT RECORDS, each one for the corresponding ledger of the two involved accounts. (Am I right? -I have no skills to exam the code, but I came up to this conclusion after testing)

In this way, however, there are many problems, such as:

1. Ambiguous descriptions in the transactions
i.e. in a flat loan you write as memo "money that I borrowed from my wife" and you see it correctly at your wallet account, but if you go to your wife's account ledger (either at your "Liabilities>Loans by Third Persons->Wife" place, or at your "Assets>Family Cash>My wife's wallet" -in case you keep a common family file) you will see exactly the same description which is not very successful. This ambiguity becomes very annoying especially at the cases where you keep multi sub-accounts of a common asset that you divide with others (such as in a business file with your partners or in your common house file with your cohabitants) and you transfer values between them.

2. Later corrections on Memo or No or Payee at one side of the transaction DOES NOT EFFECT the other side of the same transaction!
After the initial copy of the initial values at the two accounts ledgers, there is no more link between these separated records (particularly at these three fields, because -at least- 'amount' and 'date' fields of the two records are linked), so if you change/correct something in one's account ledger (such as the date which you have to return this loan that you have written in a memo, or the No of the receipt, or even the Payee itself!) nothing happens at the other account ledger/part of the same transaction! -It remains with the old (different) values, and then you have to guess which one is the correct!

3. Necessary different values (at these three fields) cannot be entered at the transaction form
For example, when I pay a supplier by a check, I need to write both my 'Check No' (to be shown in my check account ledger) besides his 'Receipt No.' of the repay (which must be shown in his nominal liability account ledger). Moreover, taking in mind the above #1 issue, I (maybe) would like to write different Memo to be shown in each ledger. And, moreover (!), in most cases, I really need to assign a different Payee for the two parts/sides of the transaction (perhaps I need to leave unassigned -with no Payee- one side of the transaction), because of the issue #4 which I analyze below.
Of course, you can trick using the bug/issue #2 above to adjust different values at these two ledgers, but it is surely not good practice!

4. The existed 'Payee tracking system' becomes obsolete!
Duplicating the same Payee in both 'from' and 'pay to' parts of a transfer transaction, eventuates to credit and debit contemporaneously the same amount in the sheet of the Payee, so the -very necessary information- 'Balance' of a Payee is inaccurate.
i.e. When you buy things by credit from a supplier (using its name as Payee and debiting a Liability account such as 'Suppliers' ), and later you repay him by a check ('Pay to' Payee from Check Account ledger), an opposite transfer ('From' the same Payee) is created automatically at the corresponding Liability Account, and in Payee sheet you see (i.e. for two actions with amount '400') three records:-400, 400 & -400 and the balance remains -400!
So, you prefer to abandon totally the embedded Payee system and to to create a different (liability) sub-account for each supplier that you credit.

The ONLY SOLUTION to all these issues is to split the form in the middle (left - right) by two columns with titles 'From' & 'Pay to' allowing to enter manually and twice the particular three fields (with some automation, such as 'one click copy').

Arguments against or pro?
Chris

Receiving no comments yet and still believing that this issue is a serious demerit of KMM2 (maybe I just overshoot the mark), should I:
a) -post it as a bug ?
b) -post it as a feature request ?
c) -post it in kmymoney developer list?
d) -post it in kmymoney user list?
e) -just waiting / don't be in harry? (leaving it here for a future discussion?)
There many options and I would need a guide for the better practice.
Could somebody suggest me about this situation?
Chris.

I would split up the issues and discuss them separately. For example, the memos was discussed a while back, and there was consensus at the time about how it would work.
Some of them I would log a feature request, and for others I would log a bug, like the payee balance not showing correctly.

Hei Ku wrote:I would split up the issues and discuss them separately. ...... Some of them I would log a feature request, and for others I would log a bug, like the payee balance not showing correctly.

The four mentioned reasons together argue towards a total redesign of the registration & input form/dialog for the transfer transactions. And this is the point. My suggestion is that this should change. So, how can I split it in four deferent issues?

Hei Ku wrote:For example, the memos was discussed a while back, and there was consensus at the time about how it would work.

I searched in forum by keyword 'memo' and it gave me as result only my post. Could you point me where this discussion took place (user ? developer lists?) and approximately when? -to be informed and to not be reinventing the wheel?
Thanks for the answer.
Chris

The memo discussion took place on the developer mailing list in mid-July.

If you look for a redesign, then make your goal or objectives, and we can work on that, rather than in individual changes. There are areas you don't know that would be affected by a change in transfers, and we have to take those into account.

Thanks for the info - I 'll find and read it.
I understand well that a redesign is not an easy thing and also that there would be areas that would be affected which I don't know.
For this reason I posted here for comments the whole initial post where I have propound -as I believe, in a certain level- both the problems and the objectives, combined also by a suggestion for a way of solution.
Of course maybe I have misunderstood or discount something.

I use a lot the transfer transactions in my business bookkeeping (because I use to debit all my suppliers and my personnel to their accounts by schedules, and then I credit them when I pay them -it is very functional if you have not A/P or A/R features!) and I wonder if other users do it and if they have the same problem(s).
I hope that Thomas or any other of the main developers would comment on this issue when they find some time for this.
Chris