[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
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
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 choice generated s
[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
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] New: 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
https://bugs.kde.org/show_bug.cgi?id=358579 Bug ID: 358579 Summary: Node was not TRANSACTION dans le fichier e:\r\build\extragear\kmymoney-4.6.1-20110918\work\kmym oney-4.7.2\kmymoney\mymoney\mymoneytransaction.cpp à la ligne 53 Product: kmymoney Version: unspecified Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: critical Priority: NOR Component: General Assignee: kmymoney-de...@kde.org Reporter: mgr...@aol.com 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 Reproducible: Always Actual Results: Entering QIF files to fill up a new count manager,when I work the counts to exit the faults and duplications Expected Results: A pop up box telling the problem, then closing the programm. And after, impossible to open a count. -- You are receiving this mail because: You are watching all bug changes.
