Payee for split small annoyance

[lp.allard.1 at protonmail.com]

Thomas,

thank you for chiming in! I was not aware of the mechanics behind the scene, with what you told us, I would agree with option B as it is the one that will achieve the simplest methodology and allow to have filled out fields for each splits and at the same time allow users to override the payees as desired.

Merry Christmas also to you!

On Wednesday, December 24, 2025 03:16 EST, "Thomas Baumgart" <thb at net-bembel.de> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kmymoney/attachments/20251224/ca83e11b/attachment.htm>