> On Juni 17, 2015, 4 nachm., 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.
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;
}
- Thomas
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124115/#review81525
-----------------------------------------------------------
On Aug. 19, 2015, 12:15 nachm., Allan Anderson wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124115/
> -----------------------------------------------------------
>
> (Updated Aug. 19, 2015, 12:15 nachm.)
>
>
> Review request for KMymoney and Thomas Baumgart.
>
>
> Bugs: 349027
> http://bugs.kde.org/show_bug.cgi?id=349027
>
>
> Repository: kmymoney
>
>
> Description
> -------
>
> Initially reported as problem with QIF file import incorrectly classing a
> transaction as a "transfer" instead of a "withdrawal", but also found in CSV
> importing. In fact, it isn't really an importing problem, but in KMyMoney
> itself.
>
>
> Diffs
> -----
>
> kmymoney/widgets/transaction.cpp 77bbcb1
>
> Diff: https://git.reviewboard.kde.org/r/124115/diff/
>
>
> Testing
> -------
>
> Checked with downloads and also manually edited transactions.
>
>
> Thanks,
>
> Allan Anderson
>
>
_______________________________________________
KMyMoney-devel mailing list
KMyMoney-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmymoney-devel
