[kmymoney] [Bug 358579] Node was not TRANSACTION dans le fichier e: \r\build\extragear\kmymoney-4.6.1-20110918\work\kmymoney-4.7.2\kmymoney\mymoney\mymoneytransaction.cpp à la ligne 53

Wed Feb 10 12:48:35 UTC 2016

https://bugs.kde.org/show_bug.cgi?id=358579

--- Comment #12 from MGR <mgrgbn at aol.com> ---
I succeeded and have now an operational KMY file (KeyMyMoney).

As recommended, during a whole week, I have cleaned the "<" & ">" from 
the "comments" of all involved operations in my GSB file (GRISBI).
I dont know if it was the real blocking problem, but it is sure that the 
updated operations contribute to clear up the QIF files (derived from my 
multiple accounts - about sisty).

Then I restarted to introduce the QIF files in a new KMY file.
I entered "slowly" the QIF files (= each account), saving the KMY file 
each time and geting out after 5 entrance, so that I could see if the 
blocking problem appeared again. Testing each time took more than two 
days...
With this procedure, I entered all the files (except one) without 
"paying attention" to the messages with problems to be solved (for a 
good KMY file), pop up messages appearing when I save the changed KMY file.

I have indeed met a *_/first error/_*, because when you enter a QIF 
file, the "main" account (involved) is correct, but all the accounts 
also concerned by the relevant transactions are _supposed to start at 
the date of the creation of the major KMY file_ (01/02/2016 for me), so 
that the transactions are supposed to be BEFORE the creation of the 
account. When entering the new QIF file that matches the "wrong" account 
("wrong" with wrong date of creation), the good date is included and 
corrects the concerned problems in the pop up messages.
Entering all the QIF files "at once" (progressively), I have the 
majority of the problems cleared away.
I have corrected the last account using "EDIT the account" and writing 
the appropriate date.

It is natural and normal that a file (the *KMY file*) have an "*creation 
date*" (in "file informations"). But, there should also have a 
"_STARTING DATE_", so that all QIF files from an existing software could 
be introduced and
   have a correct "opening date", eliminating many and many problems.
This _SHOULD be DONE_, because yesterday, using the "totally correct" 
file, I started to enter new operations (so not transactions between 
account) and I have to created a new "CATEGORY" for a payment dated of 
the 27/01/2016. It was _IMPOSSIBLE because it was "updated"_, so I was 
forced to enter the operation at the 01/02/2016, date of creation of the 
"new" KMY file (date automaticaly generated).
KMY file creation date dont have to be the reference for the operations 
and creation. If necessary "opening date" of the account can be a 
security reference. So "STARTING DATE" should be the best security 
reference.

*/_Second problem_/* matched is the _/correlation/_ between two QIF 
files entered involving the same account.
In most cases, there is an excellent correlation between the 
transactions (between two accounts).
But, the good written operations have two additional lines, so that you 
can visually correlate the two entered operations. It is a good thing 
for security, but, to clean up the account, _you have to ACCEPT each 
operation_ ; and it takes very long times when you have a big file with 
many and many transactions.
Possible improvement : I think that, after solving the eventual 
problems, you should be able to ACCEPT ALL the transactions at once.
But there is a "real" problem of correlation with two QIF files with 
accounts not in the same position with "RECONCILIATION" ("R" is 
reconciliation with a bank paper).
_If you entered first_ the "NON RECONCILIATED" account (CASH account for 
example), _no matter_ ; the correlation is goog in the second account 
(checking account for exemple) ; you have only to ACCEPT each 
transaction in this second account.
But,*if you enter the "R" file first*, you generate a second account 
with all over "R" operations... so that when you enter the "non R" QIF 
file, you have *NO CORRELATION* and all the transactions ("R"<>"non R") 
between the two accounts are *DUPLICATED*.
It is the reason why I have not entered my last QIF file, with "non R" 
transaction, generating to many problems...
For me, it is clear that the "CORRELATION" is not performing enough !

Thus, after entering QIF files, I_had to check up all the operations_ in 
all the accounts to RECONCILIATE the right ones and to be able to *make 
THE first reconciliation* of all the accounts...
After three working weeks, I think my KMY file is now clean and all the 
accounts are right (with good figures), except the last one. I can 
finally work again !

Another little problems :
1/ the "RECCURENT operations" have disappeared. No QIF file is able to 
enter the operations. I have to do it manualy.
2/ when entering a "beneficiary", it seems the KMY software takes the 
_first appearance_ of the name to propose the right informations for the 
new operations (option choosen). All the software I used before proposed 
the*last appearance* of the beneficiary. It seems that I have no choice 
(in "configuration"). Is this choice generated so because I entered QIF 
files ?
3/ I have not found the way to configurate the *width of the columns* , 
when an account is displayed in the "Great Book". The _date _is not 
totally visible and the FIGURES (in _DEBIT_, _CREDIT _and _BALANCE_) are 
limited to five visible numbers (for exemple 215,38 instead on 10215,38).

Kind regards
MGR

Le 04/02/2016 13:49, allan via KDE Bugzilla a écrit :
> https://bugs.kde.org/show_bug.cgi?id=358579
>
> allan <agander93 at gmail.com> changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>               Status|CONFIRMED                   |RESOLVED
>           Resolution|---                         |WAITINGFORINFO
>
> --- Comment #11 from allan <agander93 at gmail.com> ---
> (In reply to MGR from comment #9)
> <snip>
>> I will give you the result, when the whole correcting and entering work
>> will be done.
> <snip>
>> MGR
> (from aga)
> Await above feedback.
>
> With the '<' & '>' edited out, the two files do import correctly, and the
> relevant transactions get matched correctly during import.
>

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus

-- 
You are receiving this mail because:
You are the assignee for the bug.