[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

[MGR via KDE Bugzilla]

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

--- Comment #14 from MGR  ---
Answer to Thomas Baumgart.

I dont have change the context of the problem.

After the blocking bug which could not be solved quickly, *I was asked 
to report how* I have done for achieving a working file.

_I only added a few suggestions_ and questions to improve KMY.
If you want, they can also be put on the user mailing list. Thank you.

Best regards


Le 10/02/2016 14:25, Thomas Baumgart via KDE Bugzilla a écrit :
> https://bugs.kde.org/show_bug.cgi?id=358579
>
> --- Comment #13 from Thomas Baumgart  ---
> Hi, this is a lot of stuff. Please make sure to keep a single issue with this
> ticket and don't change the original context. Your questions are better placed
> on the user mailing list or the forum. Please check
> https://kmymoney.org/support.php for the relevant information to access them.
> Thank you in advance.
>



---
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 watching all bug changes.

[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

[Thomas Baumgart via KDE Bugzilla]

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

--- Comment #13 from Thomas Baumgart  ---
Hi, this is a lot of stuff. Please make sure to keep a single issue with this
ticket and don't change the original context. Your questions are better placed
on the user mailing list or the forum. Please check
https://kmymoney.org/support.php for the relevant information to access them.
Thank you in advance.

-- 
You are receiving this mail because:
You are watching all bug changes.

[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

[MGR via KDE Bugzilla]

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

--- Comment #12 from MGR  ---
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 

[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

[allan via KDE Bugzilla]

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

allan  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |WAITINGFORINFO

--- Comment #11 from allan  ---
(In reply to MGR from comment #9)

> 
> I will give you the result, when the whole correcting and entering work 
> will be done.

> 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.

-- 
You are receiving this mail because:
You are watching all bug changes.

[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

[allan via KDE Bugzilla]

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

--- Comment #10 from allan  ---
I've been suffering from tunnel vision, and have been reading all the above
comments without noticing that there were two contributors.  Apologies for
that, although it has had no bearing on the cause or analysis.

Your fears -
"< With your answer_, I have a fear, because the two programms (MONEY & 
< GRISBI) used *TRANSFER from one ACCOUNT to another* account, so that you have
not to write < twice the operations in two accounts. So all my big 
< file (*.GSB*) is built on these tranfers.
"
may be groundless.  With the '<' & '>' edited out, the two files do import
correctly, and the relevant transactions get matched correctly during import.

This has caused problems in the past, but KMyMoney is now able to match two
imported transactions, and also two manually entered ones.  This is in the
4.7.2 version.

-- 
You are receiving this mail because:
You are watching all bug changes.

[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

[MGR via KDE Bugzilla]

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

--- Comment #9 from MGR  ---
Thank you for your answer.

What a pity with this problem that has no quick solution !...

After the Aquila's analysis, I started to eliminate the incriminated 
symbols (<&>) in more than 20 accounts (in order to clean up _more than 
40 QIF files_). The main problem is that an automatic clean up of QIF 
files is not possible, because the symbols are not only used for 
separation, but also eventually for multi other purposes... The work is 
very long because I have more than _sex years of datas_!

I hope that this hard work will successful enter the datas of more than 
50 accounts that I export from a "*GRISBI*" file and enter KDE 
"Kmymoney" programm, because "GRISBI" is not performant enough.
For me, "GRISBI" was a transition programm, when "MS MONEY" could not 
run with new WINDOW version...

_With your answer_, I have a fear, because the two programms (MONEY & 
GRISBI) used *TRANSFER from one ACCOUNT to another* account, so that you 
have not to write twice the operations in two accounts. So all my big 
file (*.GSB*) is built on these tranfers.

I will give you the result, when the whole correcting and entering work 
will be done.
I am confident, because during last holidays, I already have transfered 
a "small" file (of my daugter, with 7 account) from GSB to KMY, with 
equivalent tranfers between account, and I had no insolvable problem to 
make it run correctly.

MGR


Le 31/01/2016 14:58, allan via KDE Bugzilla a écrit :
> https://bugs.kde.org/show_bug.cgi?id=358579
>
> --- Comment #8 from allan  ---
> I've started to look at this, but no quick solutions.
>
> However, it seems that it goes wrong when dealing with matched transactions,
> and importing two different files whose transactions  represent the same
> transaction of a transfer from one account to another.  The result appears to
> me that a transaction actually has embedded in it elements from different .kmy
> file entry lines.
>
> Now, the question is - do you really need those '<' and '>' symbol?  If so,
> why?  Could different characters be used instead if something like that is
> needed?  Why I ask is that both of those symbols are heavily involved, even
> essential to XML file formatting.  I strongly suspect that they are the root 
> of
> this problem.
>
> If they are not essential, it may be an easy fix to either filter them out or
> replace them by another character.
>



---
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 watching all bug changes.

[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

[allan via KDE Bugzilla]

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

--- Comment #8 from allan  ---
I've started to look at this, but no quick solutions.

However, it seems that it goes wrong when dealing with matched transactions,
and importing two different files whose transactions  represent the same
transaction of a transfer from one account to another.  The result appears to
me that a transaction actually has embedded in it elements from different .kmy
file entry lines. 

Now, the question is - do you really need those '<' and '>' symbol?  If so,
why?  Could different characters be used instead if something like that is
needed?  Why I ask is that both of those symbols are heavily involved, even
essential to XML file formatting.  I strongly suspect that they are the root of
this problem.

If they are not essential, it may be an easy fix to either filter them out or
replace them by another character.

-- 
You are receiving this mail because:
You are watching all bug changes.

[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

[allan via KDE Bugzilla]

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

allan  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |CONFIRMED

--- Comment #7 from allan  ---
Yes, I can confirm that behaviour.

Application: KMyMoney (kmymoney), signal: Aborted
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f0b4b6627c0 (LWP 27013))]

Thread 3 (Thread 0x7f0b319cd700 (LWP 27014)):
#0  0x7f0b45b7012d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x7f0b410f5fe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f0b410f60ec in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f0b46cd27be in
QEventDispatcherGlib::processEvents(QFlags) ()
from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#4  0x7f0b46ca40af in
QEventLoop::processEvents(QFlags) () from
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#5  0x7f0b46ca43a5 in
QEventLoop::exec(QFlags) () from
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#6  0x7f0b46ba0c5f in QThread::exec() () from
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#7  0x7f0b46c85823 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#8  0x7f0b46ba332f in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#9  0x7f0b415d5182 in start_thread (arg=0x7f0b319cd700) at
pthread_create.c:312
#10 0x7f0b45b7d47d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 2 (Thread 0x7f0b29293700 (LWP 27044)):
#0  0x7f0b45b7012d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x7f0b410f5fe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f0b410f60ec in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f0b46cd27be in
QEventDispatcherGlib::processEvents(QFlags) ()
from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#4  0x7f0b46ca40af in
QEventLoop::processEvents(QFlags) () from
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#5  0x7f0b46ca43a5 in
QEventLoop::exec(QFlags) () from
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#6  0x7f0b46ba0c5f in QThread::exec() () from
/usr/lib/x86_64-linux-gnu/libQtCore.so.4
#7  0x7f0b46c85823 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#8  0x7f0b46ba332f in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#9  0x7f0b415d5182 in start_thread (arg=0x7f0b29293700) at
pthread_create.c:312
#10 0x7f0b45b7d47d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 1 (Thread 0x7f0b4b6627c0 (LWP 27013)):
[KCrash Handler]
#5  0x7f0b45ab9cc9 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#6  0x7f0b45abd0d8 in __GI_abort () at abort.c:89
#7  0x7f0b463c4535 in __gnu_cxx::__verbose_terminate_handler() () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#8  0x7f0b463c26d6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#9  0x7f0b463c2703 in std::terminate() () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#10 0x7f0b463c2922 in __cxa_throw () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#11 0x0045e3a9 in main (argc=1, argv=0x7ffef8d63f58) at
/home/aga/GITA/kmymoney/kmymoney/main.cpp:186

The BT is not very helpful, to me, at least.  However, good work in identifying
the circumstances.

The resulting .kmy file does appear to be corrupt.

-- 
You are receiving this mail because:
You are watching all bug changes.

[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

[mhaquila via KDE Bugzilla]

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

--- Comment #6 from mhaquila  ---
Created attachment 96884
  --> https://bugs.kde.org/attachment.cgi?id=96884=edit
Bugged KMY file resulting of the two importations

With this file you can directly see the error of the program, opening it and
opening then any account.

-- 
You are receiving this mail because:
You are watching all bug changes.

[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

[mhaquila via KDE Bugzilla]

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

--- Comment #5 from mhaquila  ---
Created attachment 96883
  --> https://bugs.kde.org/attachment.cgi?id=96883=edit
Second QIF file

The importation of this second QIF file don't give the error too, but the
importation of the two files, after importation of the second of them.

-- 
You are receiving this mail because:
You are watching all bug changes.

[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

[mhaquila via KDE Bugzilla]

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

--- Comment #4 from mhaquila  ---
Created attachment 96882
  --> https://bugs.kde.org/attachment.cgi?id=96882=edit
First QIF file

The importation of this only file don't give the error

-- 
You are receiving this mail because:
You are watching all bug changes.

[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

[mhaquila via KDE Bugzilla]

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

--- Comment #3 from mhaquila  ---
(In reply to allan from comment #2)
> (In reply to mhaquila from comment #1)
> > Created attachment 96857 [details]
> > Same problem under Ubuntu 14.04 LTS when importing same QIF files
>
> OK, that rules out blaming Window then.
   Yes, it's independent of OS.

> Does this occur only on certain files, or on all files?
   It occurs only on certain files after having imported *some* QIF files
or, according to cases, after having imported them, when we reopen the
saved KMY file and click to go into any account.

> That looks like your .kmy file may be corrupted as that line is expecting to
> find the word "TRANSACTION" in the item being processed.
   Indeed, but see the following.

> Have you another .kmy file you can try, or perhaps create a new one for
> testing purposes.
   I have done that and found what causes the problem: a '<' symbol into a
QIF file.
   However the error never occurs when importing the first QIF file, but
another one with the associated operation.

> Apart from this QIF file problem, does that file otherwise work correctly?
   Yes, the program seems work correctly but the KMY is broken and can't be
used: we can open it, but we can't see any count without exit of the
program.

> If so, might you be able to supply a simple QIF file that can show the
> problem.  Disguise any personal stuff, as long as the error still occurs.
   I join two QIF files with two associated operations for each (the first
operation is correct, but the second gives the error), I join the resulting
KMY file too.

> Allan

I hope that my explanations are clear and I am ready to answer any question you
may have.

mhaquila

-- 
You are receiving this mail because:
You are watching all bug changes.

[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

[mhaquila via KDE Bugzilla]

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

mhaquila  changed:

   What|Removed |Added

 CC||aquila.ab.j...@gmail.com

--- Comment #1 from mhaquila  ---
Created attachment 96857
  --> https://bugs.kde.org/attachment.cgi?id=96857=edit
Same problem under Ubuntu 14.04 LTS when importing same QIF files

Same problem under Ubuntu 14.04 LTS when importing same QIF files

-- 
You are receiving this mail because:
You are watching all bug changes.