[Kmymoney-devel] Review Request 124115: BUG:349027 Fix transaction classed as a "transfer" instead of a "withdrawal".

[aga]

On 26/08/15 14:36, Thomas Baumgart wrote:
> Hi,
>
> On Wednesday 26 August 2015 10:56:00 Allan Anderson wrote:
>
>>> On June 17, 2015, 2 p.m., Thomas Baumgart wrote:
>>>> I doubt that this is the solution. I still don't see the problem:
>>>> withdrawal and deposit are disabled (greyed out) only if the category
>>>> contains another asset or liability account. it it's empty, all three
>>>> are accessible. How can I reproduce the problem? Can you attach
>>>> necessary files to the bug entry?
>>>>
>>>> In case it's a KMyMoney general problem and not related to any import
>>>> action, one should be capable of entering a transaction via the form to
>>>> show the problem.>
>>> Allan Anderson wrote:
>>>      As I indicated to the OP on the BKO, I don't see, and have never seen,
>>>      the withdrawal and deposit fields being disabled. He is on, I think,
>>>      4.7.1.
>>>
>>>      So, I concentrated on the mis-classification of a "transfer" as a
>>>      "withdrawal".
>>>
>>>      Entering manually a new transaction, or editing an existing withdrawal
>>>      or deposit, with no category, it will show as a transfer. Open it for
>>>      editing, and it will then switch to either withdrawal or deposit.
>>>      Close without any change, and it reverts to a transfer.  As this
>>>      seemed similar to the OP's other issue, I investigated that.
>>>
>>>      Similarly, an imported transaction with no category will show as a
>>>      transfer, and one with a category will show as either withdrawal or
>>>      deposit.>
>>> Allan Anderson wrote:
>>>      Do I need to be doing anything with this?  I'm thinking of the
>>>      upcoming 4.8.>
>>> Thomas Baumgart wrote:
>>>      I investigated this a bit further. The problem can only exist, if the
>>>      transaction is not categorized. In that case, the transaction has
>>>      only a single split. In all other cases, the existing logic works as
>>>      designed and should not be changed.
>>>
>>>      The fix should keep the current logic unchanged (it will change it in
>>>      case of a mixed multi-split transaction and shows different results
>>>      depending on the order of the splits referencing income/expense or
>>>      asset/liability accounts). If the first one found is income/expense
>>>      it shows 'Withdrawal' or 'Deposit' if it is asset/liability it will
>>>      show 'Transfer'. The current implementation shows
>>>      'Deposit/Withdrawal' for any mixed multi-split transaction.
>>>
>>>      I suggest to enclose the current logic to cover the corner case of a
>>>      single split transaction and determine withdrawal/deposit solely on
>>>      the amount of the split in this case, e.g.>
>>>          KMyMoneyRegister::Action StdTransaction::actionType() const
>>>          {
>>>
>>>            KMyMoneyRegister::Action action = ActionNone;
>>>
>>>            if(m_transaction.splitCount() > 1) {
>>>
>>>              // keep the current logic as is
>>>
>>>            } else {
>>>
>>>              action = m_split.shares().isNegative() ? ActionWithdrawal :
>>>              ActionDeposit;
>>>
>>>            }
>>>            return action;
>>>
>>>          }
>>
>> I'm missing something here.
>>
>> Without your proposed patch, I still don't see the withdrawal and deposit
>> fields being disabled.
>>
>> If I import a simple QIF file, like -
>> !Type:Bank
>> D01-06-08
>> PADDED NET INT
>> T80.07
>> ^
>>
>> initially the Transfer tab is enabled, although clicking on any of them
>> moves focus to the following empty transaction.
>
> This is in view (as opposed to edit) mode. A click on any of the tabs creates
> a new transaction in this mode.
>
>> If I click Edit, any tab may be selected.
>
> That is OK, because it is not categorized yet.
>
>> If I select Withdrawal, and edit the payee and add a
>> category, as per the OP, both the Deposit and Withdrawal tabs are enabled.
>
> Yes, which is OK since you have a category and can switch between debit and
> credit transaction using these two tabs.
>
>> Clicking Enter, the transaction is saved correctly.
>
> Good to know.
>
>> If I don't add a category, all three are still enabled.
>
> Yes, because the transaction is still uncategorized.
>
>> If I enter an asset or liability account, only then are they disabled.
>
> Yes, because the transfer does not differentiate between a credit and debit
> transfer.
>
> I don't see where the problem is. Your description is completely in line with
> the original design (a few years old btw).

I don't, either, but that's not what the OP sees.  See his bug 
description.  And, this is without your patch.

Allan