Payee for split small annoyance

[Thomas Baumgart]

Hi,

let me chime in here to clarify a few things. Then we need to discuss how to resolve
the issue in the next step (I provide proposals below).

First of all: there is no such thing as the payee for a transaction. A normal transaction
*always* consists of two splits (once a category is assigned) and the payee information
is part of each split. In the normal transaction editor that second split is not directly
visible to the user to keep things simple.

When you open such a 'normal' transaction in the split editor then you see that second
split already being present. From what I understand, it does have the payee information
filled in, which means that the transaction editor fills the payee information for both
splits with the name visible in the payee widget.

For additional splits entered using the split editor the payee is not automatically
populated and left empty. That certainly results in the behavior being reported here.

What can be done to resolve that?

a) when saving a transaction, the payee information is filled into every split that
   does not have a payee assignment
b) pre-populate the payee when creating a new split with the one visible in the
   transaction editor
c) ???

The proposed solution with grayed out widgets is way too complex and somehow does
not sound logical with the information provided above about how the payee is
logically treated (in every split, not a transaction).

Looking at it, I tend to vote for solution b) above which has the same effect
(all splits reference the same payee) and allow two more things: payee can be
overwritten with a different one per split and in contrast to solution a) allows
to keep the payee information for splits empty. One may have to look into importers
if they need to be adapted and it needs to be checked, what will be done with
existing transactions that have splits without a payee assignment. Your input
is welcome at that point.

> ... splits become IMO a simple bundling of multiple transactions.

Sorry, but a transaction is a bundle of splits. Nothing else.

And with that, I wish all of you who celebrate it a Merry Christmas.

Thomas

On Dienstag, 23. Dezember 2025 16:45:23 CET lp.allard.1--- via KMyMoney wrote:

> Jack,
> 
> I would tend to agree with you. The way I mainly use splits is to track the total cost of a transaction across multiple categories (if applicable). For example an invoice at Lowes can have electrical stuff, plumbing, yard maintenance, etc…. The payee is still Lowes for all of those splits.
> 
> In my humble opinion, the following behavior should be applied by the program:
> 
> If the user enters a payee in the “main” transaction, the program should assume its the same payee for all splits. There should not be a payee field in the splits (or it should be greyed out and indicate the same payee as the parent transaction) and have a tick box next to the field to “add” a custom/different payee.
> 
> If the user ticks that box, and enters a different payee, then this transaction will invariably end up with multiple payees, therefore the payee field in the parent (main) transaction should be greyed out and say “Multiple payees, see splits for details”.
> 
> Something like that…. The idea is to be consistent, if its mostly always a single payee (like for me) then no need to further complicate things. If someone needs to enter different payees (I can see cases where it would be nice to be able to do so), then no need to have redundancy at the upper level, splits become IMO a simple bundling of multiple transactions.
> 
> My 2 cents ;)
> 
> On Monday, December 22, 2025 18:23 EST, "Jack via KMyMoney" <kmymoney at kde.org> wrote:
> 
> > On 2025.12.22 17:49, lp.allard.1--- via KMyMoney wrote:
> >> Hello maillist,
> >>
> >> I just restarted using KMM for good after a few months and noticed a
> >> small issues (?) with payees in split transactions.
> >>
> >> It is now possible to enter different payees for the split
> >> transactions. However, since most of my transactions are done at a
> >> single payee, I usually (out of habit with the older KMM versions)
> >> enter the payee in the “main” transaction, and then populte my splits.
> >>
> >> I noticed if I leave the payee fields empty on the splits, in the
> >> reports these splits will be reported with NO payee. IMO if the payee
> >> field is left empty KMM should automatically use the parent
> >> transction's payee. If KMM cant do this, what's the point of entering
> >> a payee in the main transaction if its necessary to enter one for
> >> each splits?
> >>
> >> Maybe I am not getting the intention behind this behavior?
> >
> > This has indeed been mentioned on the lists, discuss, and bugs, but I'm
> > not sure there is a clear solution of how KMM should behave here. I
> > see three open bugs which might be used, although two refer
> > specifically to split scheduled transactions.
> >
> > I'd like to see a bit more discussion here before any specific solution
> > is proposed, although I think the main reuqest is that if a Payee is
> > entered when a schedule is created (regular or scheduled transaction)
> > and that transaction is then split, the Payee be applied to any new
> > splits created. One option might also be to only apply it to the first
> > split, as there is a use case that one reason for creating the splits
> > is specifically to allow different Payees. Clearing a Payee is not
> > hard, but perhaps there could be a button to apply the transaction
> > Payee to the current split.
> >
> > Other ideas?
> >
> > Jack
> 

-- 

Regards

Thomas Baumgart

-------------------------------------------------------------
There are only 10 types of people in the world: those who
understand binary arithmetic and those who don't.
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 868 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kmymoney/attachments/20251224/38786557/attachment.sig>