-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6705/
-----------------------------------------------------------
(Updated June 16, 2011, 11:01 a.m.)
Review request for kmymoney.
Changes
-------
These are some follow-on changes. Where an 'X' subscript is used, as in DivX,
and
combined with an 'L[accountname]' record, in QIF files, it is pretty
clear what should happen to the payment. If the 'X' or the '[]' are
missing, then things become less clear.
Without either of these, the 'L' record is taken to be a category.
Now, maybe I'm wrong here, but shouldn't the dividend/interest payment
still go into a checking account? If not, that sum cannot be 'spent'
later. If a Brokerage account is specified, then it will be dropped in
there, but is there is not, the record gets flagged as missing an
assignment.
If the type is Div, then the imported transaction can be edited, to
use a suitable account. However, if the type is IntInc, then there
still seems to be an issue as the transaction can not be edited,
probably because IntInc does not have a second split.
As it has been found that some IntInc transactions can have a security,
and share details, would it be sensible to treat them in the same way
as Div transactions, as this would at least give the user the
opportunity to supply his own checking account, rather than having a
possibly unwanted Brokerage account invented? They still need to be
shown as Interest payments, rather than Dividends, though.
These changes are to allow IntInc transactions to be edited, to specify
an appropriate import account. They also allow these transactions to
be input manually.
Summary
-------
When importing a QIF investment file with Lcategory:sub-category, which
indicates a sub-category for the transaction, the importation takes
place without error. In the ledger view of the brokerage account all appears
correct with the Category field or the Interest field displaying what appears
to be Category:Sub-category.
However when inspecting the category list it is evident that only a single
new category has been created with the name of "Category:Sub-category" as
one word and the transaction has been allocated to this category with
nothing in the existing sub-category.
The exact same transaction can be done manually with no error or
newly created categories. This bug only occurs in QIF import of investments.
The reason for this difference is that in imports, if the 'L' record is used
to nominate a category, then there is no means by which to specify a
transfer account.
Looking at the reasons for these problems, two routines were found to be
deficient. In mymoneystatementreader.cpp, the routine
d->interestId(t_in.m_strInterestCategory)) was found not to recognise a
category:sub-category structure already existing, and would create a new
category named like 'category:sub-category'. When the categoryToAccount()
routine was substituted, this recognised and found the correct existing
sub-account, but did not create one if none existed.
Then, in the QIF file in question, transactions of type IntInc were involved,
and, once the category structure was correctly recognised, the categories
created were created as income, when one of them should have been an expense.
As it happened, the statements in question included quantity and price values,
which KMM had decided were not relevant. As the quantity record showed the
correct sign, changes were made to take notice of the quantity and price,
in order to allow a decision to be made on whether a transaction should be
an income or an expense. This should have no effect on others' files.
To assist with the handling of 'L' records which were indicating a category,
changes were made to use any existing brokerage account to supply/receive
any monies. If no brokerage account already existed, the record would be
left flagged as missing an assignment.
MyMoneyStatementReader::Private::nameToId was rewritten to handle category
sub-accounts, recognising existing ones and otherwise creating them.
This addresses bug 274185.
https://bugs.kde.org/show_bug.cgi?id=274185
Diffs (updated)
-----
/trunk/extragear/office/kmymoney/kmymoney/converter/mymoneyqifreader.cpp
1236984
/trunk/extragear/office/kmymoney/kmymoney/converter/mymoneystatementreader.cpp
1236984
/trunk/extragear/office/kmymoney/kmymoney/dialogs/investactivities.h 1236984
/trunk/extragear/office/kmymoney/kmymoney/dialogs/investactivities.cpp
1236984
/trunk/extragear/office/kmymoney/kmymoney/dialogs/investtransactioneditor.cpp
1236984
/trunk/extragear/office/kmymoney/kmymoney/mymoney/mymoneysplit.h 1236984
/trunk/extragear/office/kmymoney/kmymoney/mymoney/mymoneysplit.cpp 1236984
/trunk/extragear/office/kmymoney/kmymoney/widgets/kmymoneymvccombo.cpp
1236984
/trunk/extragear/office/kmymoney/kmymoney/widgets/transaction.cpp 1236984
Diff: http://svn.reviewboard.kde.org/r/6705/diff
Testing
-------
Imported several QIF files having varying formats, both real-life and
constructed to contain mixtures of record types and category structure.
atype run.
Thanks,
Allan
_______________________________________________
KMyMoney-devel mailing list
KMyMoney-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmymoney-devel
