Bug 385060 - Could not enter receiver if not enabled as payee
Summary: Could not enter receiver if not enabled as payee
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kmymoney
Classification: Applications
Component: general (show other bugs)
Version: 4.8.0
Platform: Other All
: NOR normal
Target Milestone: ---
Assignee: KMyMoney Devel Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-25 19:06 UTC by Ralf Habacker
Modified: 2022-08-25 17:19 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
Scrennshot showing the fomular for adding a new transaction (87.12 KB, image/png)
2017-09-27 06:47 UTC, Ralf Habacker
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Habacker 2017-09-25 19:06:17 UTC
It is not possible to add a receiver without adding as payee.

How to reproduce ?
1. start kmymoney
2. load present file or create a new file
3. open ledger
4. Add a new transaction by pressing STRG-Insert or press 'new' button
5. Enter a receiver
6. Select 'No' on the request to add the receiver as payee

What happens ?
The entered receiver is deleted. There is no way to add it without adding as payee

What is expected ?
The receiver should not be deleted
Comment 1 Ralf Habacker 2017-09-25 19:14:40 UTC
Furthermore pressing 'no' adds a new empty transation without been able to enter receiver, category/account and amount.
Comment 2 Jack 2017-09-25 19:41:01 UTC
A standard payment transaction is a transfer of money to a payee.  If the recipient of the funds is not a payee, how can KMM create a balanced transaction?  The money has to go somewhere.  The only way not to need a payee is to make a transfer, and that needs another account to transfer to.

Also, from my attempts, saying "no" to add the payee, just blanks out the payee field, and advances the cursor to the category field.  It also changes the transaction type from withdrawal or deposit to transfer, and the category dropdown is populated with accounts.  I have never had it immediately enter an empty transaction.
Comment 3 Ralf Habacker 2017-09-26 06:34:01 UTC
(In reply to Jack from comment #2)
>  I have never had it immediately enter an empty transaction.
In the initial report I missed to mention that this happens if settings->ledger->display->"Show transaction form" is unselected.
Comment 4 Thomas Baumgart 2017-09-27 06:23:41 UTC
Regarding your procedure: KMM works as designed.

Regarding the creation of an empty transaction: that certainly is not expected. What Jack describes in Comment #c2 is the expected behavior.
Comment 5 Ralf Habacker 2017-09-27 06:47:01 UTC
Created attachment 108053 [details]
Scrennshot showing the fomular for adding a new transaction

(In reply to Thomas Baumgart from comment #4)
> Regarding the creation of an empty transaction: that certainly is not
> expected. What Jack describes in Comment #c2 is the expected behavior.
> 
>> It also changes the transaction type from withdrawal or deposit to transfer,

With settings->ledger->display->"Show transaction form" unchecked there is no transaction type visible, see appended screenshot
Comment 6 Jack 2022-08-24 21:47:29 UTC
Is this still a problem?  I don't follow what is meant by Comment #5.  I don't recall that Transaction Type is actually anything but a description of some of the fields.  A transaction with a payee is either a deposit or withdrawal (different names perhaps for different account types) and a transfer if the money goes between two different accounts.

One other question - is there perhaps a translation issue?  What is meant by "receiver" exactly?  If it is where the money goes in a transaction, by the design of the program, it can be either a Payee or another Account.  Am I missing something else it could be?
Comment 7 Thomas Baumgart 2022-08-25 06:10:20 UTC
Using my German dictionary, I'd say 'receiver' equals 'payee' in this context. OTOH, looking at master where the differentiation between in-ledger and in-form data entry does not exist anymore and the version this was reported for, I suggest to close it as unmaintained.
Comment 8 Jack 2022-08-25 17:12:46 UTC
On 2022.08.25 02:10, Thomas Baumgart wrote:
> https://bugs.kde.org/show_bug.cgi?id=385060
> 
> --- Comment #7 from Thomas Baumgart <tbaumgart@kde.org> ---
> Using my German dictionary, I'd say 'receiver' equals 'payee' in this  
> context.
> OTOH, looking at master where the differentiation between in-ledger  
> and in-form
> data entry does not exist anymore and the version this was reported  
> for, I
> suggest to close it as unmaintained.
Even if that particular place where the literal term "Payee" is used is  
no longer present, I plan to call it INTENTIONAL.   Even in the new  
ledger, there is a column PAYEE, which does include both payees and  
payers.  Using "Payee/Payer" would be more correct in terms of  
vocabulary, but I think would make the UI more clunky feeling.
Comment 9 Jack 2022-08-25 17:19:42 UTC
Sorry - that comment was actually meant for a totally different bug.  I agree to close as UNMAINTAINED, since it was opened against a very old version.  Requiring a Payee or Account to receive the funds is inherent to the design of the program.  As Thomas pointed out, the design of the UI has changed since then, so if there is still a related problem with the latest version, I'd suggest opening a new bug.