On 2024.07.16 03:32, Thomas Baumgart via KMyMoney-devel wrote:
[snip translation discussion]
> I have a question about the payee section. Payees and payers are
merged
> into a single list. Wouldn't it be clearer for the user to separate
the
> two? And then offer only payers in the dropdown when adding a
deposit and
> only payees when entering a withdrawal in ledger?
>
> A second suggestion came to mind when using the application. I can
imagine
> the list with payees gets very long over time. This might be a bit
less
> overwhelming by selecting a category first under ledger and then
only get a
> list of the payees with that default category. For example when
choosing
> category groceries the drop-down list would only contain grocery
stores.
Those sound like useful additions. Would you mind to enter them as
wish list
items on
https://bugs.kde.org/enter_bug.cgi?product=kmymoney&format=guided
so that they don't get forgotten? Although, the latest development
version
does not differentiate between withdrawal and deposit as earlier
versions did.
We'll see.
I'll add comments to a wishlist when it gets filed, but I do have a
problem with separating payers and payees. If I have a payer such as a
credit card company (to whom I would pay fees and/or interest, what
happens if I overpay and get a refund. That transaction is a deposit,
but the payee would not be listed in this case. I suppose a
configuration setting whether to list only payees or payers or list all
is one way, or else a button to "list all" to override the default
would also work.
I also see a downside to selecting the category first. If I select a
payee that has a default category, I then don't need to select the
category - it is set automatically. This way I would need to set
both. However, I suppose if you DO set the category first, then
limiting the payees offered in the dropdown might make sense. In
either case, entering a transaction with a category other than the
default for that payee would take more effort. It's certainly a less
common event, so taking more effort than the common use cases is not
unreasonable.
Jack
