SUMMARY Display a few more information in the payee view STEPS TO REPRODUCE 1. open KMyMoney 2. Click on "payees" 3. click on an existing payee OBSERVED RESULT The detail area has several tabs, showing the transactions, address, matching information, default category, and account numbers for the payee selected in the list. (see picture in the help https://docs.kde.org/stable5/en/kmymoney/kmymoney/payeeview.png) EXPECTED RESULT same as in OBSERVED RESULT plus these pieces of information: - creation date of the payee in KMyMoney (this may be different from the earliest transaction of the payee) (1 value) - date of earliest transaction booked on the payee (1 value) - date of latest transaction booked on the payee (1 value) - current number of transactions booked on the payee (1 value) - current balance total of the payee (1 value) SOFTWARE/OS VERSIONS Linux: Elementary OS 6.1 ADDITIONAL INFORMATION
First, KMyMoney does not currently track the creation date of Payees, so including this would involve more than a (hoopefully) simple GUI enhancement. I'm just musing here, but would these additional fields go an a new tab (what would it be called?) Might it be reasonable to create a "Additional information" tab to include this new information plus what is currently on the Default Category and Account Numbers tabs? (I think the Transacdtions, Address, and Matching tabs are likely to be too large to merge. Separately, are any of these reasonable to put in an additional column in the Your payees list? There is an additional issue, that Payees can actually be specified on both Transactions and Splits. I don't know how easy or hard it would be to calculate the value to be added when the Payee is listed on the transaction, since it clearly is not the sum of all splits.
(In reply to Jack from comment #1) > First, KMyMoney does not currently track the creation date of Payees, so including this would involve more than a (hoopefully) simple GUI enhancement. Ok. Should i open another wishlist item regarding the database of KmyMoney? like "introduce new database fields: - date of payee creation (type=Timestamp) - channel of payee creation (Type=text) with these members (my suggestions): - created by manual user data-entry - created through manual user data import - created through account synchronized data import > I'm just musing here, but would these additional fields go an a new tab (what would it be called?) Might it be reasonable to create a "Additional information" tab yes, a new tab is a good idea. Called "payee statistics"? > to include this new information plus what is currently on the Default Category and Account Numbers tabs? not if the new tab is called "payee statistics" :) but otherwise, why not. on the other hand, i like the current tab names, because they are very precise. Merging "Default Category" and "Account Numbers" would be a "intuitive navigation loss" there... > (I think the Transactions, Address, and Matching tabs are likely to be too large to merge. i agree > Separately, are any of these reasonable to put in an additional column in the Your payees list? Yes, that is also a good idea and avoids the questions around new tabs or changing existing tabs. > There is an additional issue, that Payees can actually be specified on both Transactions and Splits. I don't know how easy or hard it would be to calculate the value to be added when the Payee is listed on the transaction, since it clearly is not the sum of all splits. I am not sure i understand your point. My understanding of transaction split it that the total transaction amount may be split on distinct categories, but NOT on distinct payees. Therefore all splits of 1 transaction stay booked on 1 single payee. Why should this be an issue to sum up the amounts by payee?
An extra bug is not necessary now. Perhaps in the future if existing data is added to the display, then this bug could be closed and a new one opened for adding items to the data file. In terms of adding columns to the payee list, real estate is limited, so I don't think I would want to add more than one, or risk the display being too crowded. In that case, I'm not sure that any single additional column would actually be useful. On that last point, I think there is an issue of terminology. A typical transaction has two splits: one for an account and one for a category. In that case, whether the payee is listed on the transaction or on the category split or both splits, the amount added to the payee would only be the amount of the category split. The sum of both splits is 0, which is a result of the double entry bookkeeping. However, if this is a "split transaction" there will be one split for the money coming out of the account, and two (or more) splits for different categories. Since it is now possible to assign a payee to each split separately, it IS possible to use a different payee for each category. What is not clear is the meaning and implication of assigning a payee to both the transaction and to one or more individual splits. I'm beginning to think this should not be allowed, forcing either a payee assigned to the transaction, or only to one or more of the category splits. I'll have to think about that some more, and will probably start a separate discussion regarding what options would actually make any sense.
(In reply to Jack from comment #3) > In terms of adding columns to the payee list, real estate is limited, so I > don't think I would want to add more than one, or risk the display being too > crowded. In that case, I'm not sure that any single additional column would > actually be useful. Just adding my thought here. I actually believe all 5 data suggested would be valuable in the table. Those column should be sortable and customization like the account or category list. So maybe only one added by default (balance?) but all other could be added by the users. In terms of real estate, the list and detail pane could easily be 50/50 by default which is still easily usable on standard hd display that most people have nowadays. Finally, here are my use cases for all 5 data. it mostly turns around being able to clean up the list to merge payee (which is currently quite a cumbersome task when importing from bank accounts): - Creation date of the payee in KMyMoney or date of the earliest transaction booked on the payee => when sorted, we can look at the latest created payee to make sure they are not duplicate or more generally that all their info are correct. (Understand the 1st one is not to be expected in the short term.) - date of latest transaction booked on the payee => same as previous if we want to review recently used payee - Current number of transactions booked on the payee and current balance total of the payee => when ordered (and maybe filtered) see which payee is used more to know in which to merge the transaction. Could also be used to clean up almost unused payee (I tend to group single usage payee together, like occasional convenience store, I don't care exactly which one)