Bug 338272

For some reason, I remember that this behavior is by design, but I cannot remember the details that led to it. It is not related to #332793, sorry.

I'm not sure this is an issue at all, if I understand correctly the payee is not visible from the account of the second split?

The payee is stored at the split so you could have a transaction with different payees depending on the account from which you are looking at the transaction.

The problem does not involve splits (as in a sum composed of multiple sources).

I am simply attempting to assign to more than one transaction a single account (as might occur in a transfer of funds between two accounst). I've recently found that the problem also occurs when assigning to more than one transaction a single category. 

If I select a single transaction in the ledger of Account1 and change the account/category field to Account2, then I get the expected result -- the transaction has the same payee when viewed in Account1 or in Account2.

It makes no sense to me that if I instead select 2 or more transactions and perform the same operation, then the payee information is lost (but only in one of the two ledgers where the transaction is visible). This is an insidious problem as there is no indication that the information was lost. I personally have set the account of hundreds of transactions this way during weeks of use before I realized that the payee field of all these transactions has been erased in one of the ledgers.

I chose to use KMyMoney over GnuCash partially because of the ability to select and operate on multiple transactions. But that feature is less than useful if it results in a loss of data, especially without warning.

Is this issue the same with the problem reported by Allan in comment #6 of BUG 332793?

https://bugs.kde.org/show_bug.cgi?id=332793#c6

For been able to reproduce this issue it is required to get a simple ofx test file containing the mentioned ofx transaction.

(In reply to BobSCA from comment #3)
> The problem does not involve splits (as in a sum composed of multiple
> sources).
> 
> I am simply attempting to assign to more than one transaction a single
> account (as might occur in a transfer of funds between two accounst). I've
> recently found that the problem also occurs when assigning to more than one
> transaction a single category. 

I retested this with 4.8.1 and it works as expected.

(In reply to BobSCA from comment #0)
> If I select multiple transactions in Account1 which each initially have an
> unassigned account and change the category/account to Account2 then they
> appear in the Account2 ledger with no payee. In the Account1 ledger they
> continue to appear as expected with the correct payee. In my test case, the
> problem was reproducible only with imported transactions and not with
> transactions that entered manually.

To check if the issue is also fixed a minimal ofx file containing two or more transactions is required. 
Unfortunally there are several variants to create such an ofx file and it may not trigger the issue, if it is still present.

The problem can still be reproduced in master. Here's howto reproduce it w/o online banking. The scenario is the same.

a) create two transactions to one or two payees but leave the category unsassigned
b) select both of them
c) assign another account as transfer account
d) open the ledger of the other account
-> transactions don't have a payee assigned

The reason for that is, that the payee is kept with the split for the account. When there is no category or account assignment, then the transaction only has that one split. In case you now add a category or account, the second split is created and the second account assigned. In case of a single transaction edit the payee is also copied. In case of a multi-selection edit this is not performed, since for multi-selection edit only those fields are changed that contain data in the widget. Since the payee is empty, it is not modified.

So far things work as they were designed. This does not mean that they cannot be changed if there is a desperate need for that.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!