[kmymoney4] [Bug 371069] CSV plugin mishandles UTF-16 files
https://bugs.kde.org/show_bug.cgi?id=371069 --- Comment #9 from allan --- (In reply to Thomas Baumgart from comment #8) > I tried this on my KDE4, KMyMoney 4.8 production system (this is generated > of HEAD on the 4.8 branch). > When I change the encoding in the dialog to UTF-16 before I select the file, > then things seem to work properly. Just to be clear, are you saying that you do not then see the problem I reported, of the data being garbled? If I ensure that UTF-16 is already selected - displayed in the file selector - then I definitely do see the corruption. > I am looking at the following snippet in > CSVDialog::readFile(const QString& fname): Might this be a non-current git head version? There has recently been some reformatting of the source and I have void CSVWizard::readFile(const QString& fname), as does the current git head. In terms of the actual code, they are identical in this particular area. Just to be clear, again. So far as the selector is concerned, then, yes, there are a couple of problems, although if the decoding is for UTF-16, from previous activity or from setting it prior to selecting the file, then the file should have the required encoding. Some tweaking looks to be necessary though. Allan > > QFile m_inFile(m_inFileName); > m_inFile.open(QIODevice::ReadOnly); // allow a Carriage return - // > QIODevice::Text > QTextStream inStream(&m_inFile); > QTextCodec* codec = > QTextCodec::codecForMib(m_codecs.value(m_encodeIndex)->mibEnum()); > inStream.setCodec(codec); > > QString buf = inStream.readAll(); > > When selecting UTF-16 before selecting your file, QString buf contained the > correct data. I verified this in the debugger and also data displayed in > spread sheet form seemd to be correct. > > Hope that helps for further investigation. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 371069] CSV plugin mishandles UTF-16 files
https://bugs.kde.org/show_bug.cgi?id=371069
--- Comment #7 from allan ---
[from Thomas]
"
Hi Allan,
you found out yourself: the BOM is not wrong, it's missing. I am sure, you
stumbled over https://en.wikipedia.org/wiki/UTF-16.
I have not looked at the code of the CSV importer at that point, but you could
check the beginning of the file (4 bytes) and see if the first two match a BOM
or you find two 0x00 in those four bytes (where that would probably not work
for Asian countries as they fill the upper byte with their characters).
Reading the data through a QTextStream allows to setup the encoding/decoding.
Please take a look at QTextStream::setCodec() and setAutoDetectUnicode(),
though according to the docs I have, the automatic detection should be the
default. Maybe, you add another UI selector for the Encoding, in case you
don't have it. See QTextCodec::availableCodecs() for a list of them. Check
Kate/Kwrite in the Tools/Encding menu how this may look like.
So much for now. If you don't get the codec stuff going, please tell me where
to find the relevant source code and I take a look at it.
Thomas"
[My reply]
"
I have /had -
QTextStream inStream(&inFile);
QTextCodec* codec =
QTextCodec::codecForMib(m_codecs.value(m_encodeIndex)->mibEnum());
inStream.setCodec(codec);
QString buf = inStream.readAll();
...
(void CSVWizard::readFile(const QString& fname) line c843)
which I nicked from Qt, I think.
I have encoding selection in the file selector.
...
QPointer label = new QLabel(i18n("Encoding"));
dialog->layout()->addWidget(label);
//Add encoding selection to FileDialog
QPointer comboBoxEncode = new QComboBox();
setCodecList(m_codecs, comboBoxEncode);
comboBoxEncode->setCurrentIndex(m_encodeIndex);
connect(comboBoxEncode, SIGNAL(activated(int)), this,
SLOT(encodingChanged(int)));
dialog->layout()->addWidget(comboBoxEncode);
(bool CSVWizard::getInFileName(QString& inFileName) line c798)
I don't see a setAutoDetectUnicode().
I don't think I had auto-selection, but encoding was by manual selection
from the list of codecs, but UTF-16 seems not to work. (in my code).
Allan"
I'm afraid I'm not able to commit to coding, still.
--
You are receiving this mail because:
You are the assignee for the bug.
[kmymoney4] [Bug 371069] CSV plugin mishandles UTF-16 files
https://bugs.kde.org/show_bug.cgi?id=371069 --- Comment #5 from allan --- Thomas suggested using Okteta to look at the data to see if the BOM was correct. Here are the first few lines :- " 22 00 4D 00 52 00 20 00 41 00 4C 00 ".M.R. .A.L. 000C 4C 00 41 00 4E 00 20 00 41 00 4E 00 L.A.N. .A.N. 0018 44 00 45 00 52 00 53 00 4F 00 4E 00 D.E.R.S.O.N. " So, no BOM, just the data, and still mis-formatted by the plugin. Ah, I've just checked against the Libre Office Calc file and, just looking at the beginning, the bad one has "22 00", and the good one has "FF FE". So, the BOM is wrong on the bank version. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 371069] CSV plugin mishandles UTF-16 files
https://bugs.kde.org/show_bug.cgi?id=371069 --- Comment #4 from allan --- (In reply to allan from comment #3) > It looks like my attempts to provide an edited sample file either produce > rubbish, or remove whatever causes the problem. > So, I may have to provide a complete file, but I don't wish to broadcast it, > so would like to send it off-line. To whom? > > Allan I've sent a gpg'ed copy to Thomas. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 371180] New: A request for an additional monetary format
https://bugs.kde.org/show_bug.cgi?id=371180 Bug ID: 371180 Summary: A request for an additional monetary format Product: kmymoney4 Version: 4.8.0 Platform: Mint (Ubuntu based) OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: csvimporter Assignee: kmymoney-devel@kde.org Reporter: agande...@gmail.com Apart from the unusual date format, I have a further complication. A credit to the credit card company now produces the following format - "06 Sep","AMAZON UK RETAIL AMAZO AMAZON.CO.UK LUX","£27.50","CR", The plugin did have a similar capability, but I think this has very recently been removed. It would be very helpful if this format could be handled. Reproducible: Always -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 371177] New: Request for additional date format - no year!
https://bugs.kde.org/show_bug.cgi?id=371177 Bug ID: 371177 Summary: Request for additional date format - no year! Product: kmymoney4 Version: 4.8.0 Platform: Mint (Ubuntu based) OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: csvimporter Assignee: kmymoney-devel@kde.org Reporter: agande...@gmail.com My new format credit card statement causes further problems. It produces a date with no year, like "15 Aug". To avoid an on-going need to edit every entry, it would be good if the CSV importer could cope with this format, please. Thanks Allan Reproducible: Always -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 371069] CSV plugin mishandles UTF-16 files
https://bugs.kde.org/show_bug.cgi?id=371069 --- Comment #3 from allan --- It looks like my attempts to provide an edited sample file either produce rubbish, or remove whatever causes the problem. So, I may have to provide a complete file, but I don't wish to broadcast it, so would like to send it off-line. To whom? Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 371069] CSV plugin mishandles UTF-16 files
https://bugs.kde.org/show_bug.cgi?id=371069 allan changed: What|Removed |Added Attachment #101617|0 |1 is obsolete|| --- Comment #2 from allan --- Created attachment 101618 --> https://bugs.kde.org/attachment.cgi?id=101618&action=edit UTF-16 file -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 371069] CSV plugin mishandles UTF-16 files
https://bugs.kde.org/show_bug.cgi?id=371069 --- Comment #1 from allan --- Created attachment 101617 --> https://bugs.kde.org/attachment.cgi?id=101617&action=edit UTF-16 file -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 371069] New: CSV plugin mishandles UTF-16 files
https://bugs.kde.org/show_bug.cgi?id=371069 Bug ID: 371069 Summary: CSV plugin mishandles UTF-16 files Product: kmymoney4 Version: 4.8.0 Platform: Mint (Ubuntu based) OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: csvimporter Assignee: kmymoney-devel@kde.org Reporter: agande...@gmail.com My credit card company has revised their web site, and the statement importing procedure and format has changed. The KMM CSV importer is not happy with this new format. All characters have an interspersed null character (I think, probably 00). Each line is followed by an additional line containing the same odd character. So, the import is incorrect. If I import via Libre Office Calc, all is correct. It is shown as UTF-16. If I load via Kate, this too looks wrong, unless I change the encoding from UTF-8 to UTF-16. In the CSV importer, however, changing the encoding from UTF-8 to UTF-16 makes no apparent difference and the original incorrect result still appears. Reloading an earlier file is as normal. So, it appears that the import encoding has changed and the CSV plugin does not handle it correctly. Reproducible: Always Steps to Reproduce: 1. Import a CSV file encoded in UTF-16. 2. The file will show the incorrect format. 3. Actual Results: As above. Expected Results: The UTF-16 should be handled correctly. There may be more to this, however. When I tried to create a file in UTF-16, it could be imported correctly. So, to be able to demonstrate the problem, I have used a file from my credit card company, deleted everything except the first line and then added a new first line of "12-10-2016,Description,1234.56" Attachment follows. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 368593] KmyMoney File Not opening and gives error As " Please use an older version...."
https://bugs.kde.org/show_bug.cgi?id=368593 --- Comment #7 from allan --- I fear not. If you have no backup, then there is nothing from which to recover. At least, now, do make sure you have enabled automatic backups - Settings>Configure KMyMoney>General>Global. In addition, however, make a practice of saving a copy file each time you finish a session. A possibly forlorn hope or two, however. Do a file search of your system for *.kmy and *.kmy.* files. Also, just in case your file is only partially corrupted, open your file in KMM , then Save as, and set the filter there to XML files. Then, open that file in your browser, Firefox or whatever and look through the file to see if you can recognise any data as your missing data, hoping that perhaps just the beginning of the file is corrupted. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 272398] KMyMoney 4.5.2 (KDE 4.5.5) Ubuntu 10.10 slowed and is now consistently slow in edit Ledger Entry (Transaction)
https://bugs.kde.org/show_bug.cgi?id=272398 --- Comment #8 from allan --- (In reply to Dennis Gallion from comment #7) > Thank you Allan for the very quick reply. As it turns out, 4.8.0-13.3 was > just added this morning to the openSUSE 13.2 KDE:Extra unsupported > repository. I installed it and good news the cpu spike and delay in posting > ledger transactions has apparently been fixed. Thanks! > > However, I noted in the Change Log for 4.8.0 the following: > > * Categories no longer have opening date, which caused annoyingerrors both > during input and while running the consistency check > * Fixed some annoying consistency check errors > > When I ran 4.8.0 the first time, and each time the file is saved, the > Consistency Check is run and it is returning over uncorrectable 5000 errors, > each indicating a posting date that is older than the opening date of the > account. All of the transaction data in the log is for 2007 and older; I > can't say if there are such errors in newer data. It may be that most of > the errors are in data that was imported, but for a certainty I began using > the application after the import in about 2005 so there are errors in at > least some newer data. The fix was specific to categories having an opening date. You may still have other accounts with problem dates, I'm afraid. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 272398] KMyMoney 4.5.2 (KDE 4.5.5) Ubuntu 10.10 slowed and is now consistently slow in edit Ledger Entry (Transaction)
https://bugs.kde.org/show_bug.cgi?id=272398 --- Comment #6 from allan --- I can't really see any prospect of attempting to fix a problem on such an old release. Please, can't you upgrade to a current version? 4.7.2 includes numerous bug fixes, and 4.8.0 was released quite recently. If the problem is still present, then there is a far better prospect of finding a fix. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 362373] layout seems to be changed to TXT mode, losing HTML formats
https://bugs.kde.org/show_bug.cgi?id=362373 allan changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |UNCONFIRMED --- Comment #2 from allan --- (In reply to CPL from comment #1) > Even with 4.8 version, the problem still remains. Oh, well 4.8.0 is only very recently released, with no such problem showing up.. So, we need to consider your .kmy file. Would you create a new, minimal .kmy file and see if that fares any better. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 345655] Rounding problems between checking and investment account
https://bugs.kde.org/show_bug.cgi?id=345655 --- Comment #32 from allan --- Ah, we're on reconciliation. It is indicating a discrepancy with cleared transactions. Uncleared transactions will be excluded from reconciliation. So, in that account, click Not marked in the status (top right). Make sure all those transactions are cleared. It might help in any further difficulty to just reconcile part of the account, into smaller chunks , if that helps to show where the problem lies. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 345655] Rounding problems between checking and investment account
https://bugs.kde.org/show_bug.cgi?id=345655 --- Comment #30 from allan --- I made an assumption that it could be the date field that was red. Obviously now that's not the issue. So, I'm missing something. Are you able to attach a screen-shot to the bug? Allan In Settings/Configure KMM/Colors, a negative value may be set to show as red. Might that explain? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 345655] Rounding problems between checking and investment account
https://bugs.kde.org/show_bug.cgi?id=345655 --- Comment #28 from allan --- Actually, if the answer to the previous comment does not resolve the issue, it would be as well to open a new bug, as your problem is not to do with rounding. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 345655] Rounding problems between checking and investment account
https://bugs.kde.org/show_bug.cgi?id=345655 --- Comment #27 from allan --- (In reply to sven.keller from comment #25) > Hi Folks, > eventually I got the RPM package provided by Opensuse. > I can confirm, for my "productive" file it is not working as expected. > Great work! Thanks a lot for the effort! > > However one question remains (but perhaps not related to this bug) > I double checked and corrected all my investment transactions and the > (visible) amount of the account also matches the amount downloaded from the > bank. > However it is marked in red as if it would not match? > Is there a way to check where a potential mismatch might be? > > Cheers > > Sven Can you be a bit more precise? Is it just the date field? If you hover the pointer, does that produce a clue? Might it be that the opening date for the account is after the transaction date? If so, edit the account's opening date to match the oldest likely transaction. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 364425] CSV import only shows checking accounts when selecting Banking
https://bugs.kde.org/show_bug.cgi?id=364425 allan changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED --- Comment #5 from allan --- (In reply to NSLW from comment #1) > Git commit 9c5397238947c8a010eb2e0939cb34d729dfb751 by Łukasz Wojniłowicz. > Committed on 18/06/2016 at 17:16. > Pushed by wojnilowicz into branch '4.8'. > > Set type of banking statement to unknown during CSV import > > Type of banking statement shouldn't be set to 'checkings' by default, > bacause statement to be imported could be 'checking' but also 'credit > card'. > > M +1-2kmymoney/plugins/csvimport/csvdialog.cpp > > http://commits.kde.org/kmymoney/9c5397238947c8a010eb2e0939cb34d729dfb751 Credit card imports still do not work on 4.8.0. The fix "Thanks for the files. As I wrote before, CSV should be already fixed in upcoming KMM 4.8.1. Something is wrong with QIF importer in KMM, because file has correct type "!Type:CCard" and its account type is being incorrectly recognized. That needs to be fixed. As temporary fix you can use workaround provided by Allan Anderson https://mail.kde.org/pipermail/kmymoney-devel/2016-June/016810.html"; should be present in 4.8.1. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 365802] Cannot import into Credit-Card Account
https://bugs.kde.org/show_bug.cgi?id=365802 --- Comment #1 from allan --- I reported this problem a few weeks ago. It's the result of a recently introduced fix. It is possible to get round this by importing your credit card file into a temporary checking account. Then, select all those transactions, right click and select move transaction to... your atual credit card account. There is a full fix in the offing. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 365307] Download
https://bugs.kde.org/show_bug.cgi?id=365307 --- Comment #4 from allan --- Also, if you can reproduce your problem, please supply the url which is displaying the invalid link, so that it can be attended to. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 365307] Download
https://bugs.kde.org/show_bug.cgi?id=365307 --- Comment #2 from allan --- James, you do not have to register to obtain the download. It looks like you may have been attempting to download from an incorrect link. I'll cc. you in case you are not subscribed to this list, just in case that hasn't happened. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 365023] Payee listing
https://bugs.kde.org/show_bug.cgi?id=365023 --- Comment #1 from allan --- A bit more information might help us. It sounds like you may be importing? If so, by what method? What revision of KMyMoney are you using? (Help>About KMM). Distro package or compiled from source? Have you considered setting up matching for the payee name you wish to use? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 345655] Rounding problems between checking and investment account
https://bugs.kde.org/show_bug.cgi?id=345655 allan changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #24 from allan --- I know you are all up to your eyebrows, and doing fantastic work I've just reopened this to ensure it is not overlooked, as there is still, I think, an outstanding issue. https://bugs.kde.org/show_bug.cgi?id=345655#c23. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 364311] Ledgers columns can't be resized
https://bugs.kde.org/show_bug.cgi?id=364311 --- Comment #14 from allan --- (In reply to mhaquila from comment #12) > As I said you, on a screen size of 1600x800 with the version 4.7.2 IT DIDN'T > FUNCTION CORRECTLY: the screen shots are taken with this version… Because, > as I yet said, the column width depends of the screen size. > You also said, in comment #8 "My version for Linux is the 4.6.4 ...", and the screenshots were provided in comment #5 and #6, so prior to your saying you were on 4.6.4. I can only repeat that 4.7.2 works correctly for me. If it doesn't for you, I would look to your distro/whatever. I cannot help with a Windows problem as I gave up on that some years ago. I believe there have been build problems with the Widows version, but I understand that that issue is now resolved, but probably not yet distributed. > And I don't know at all what you put the bug resolved when it's not! -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 364311] Ledgers columns can't be resized
https://bugs.kde.org/show_bug.cgi?id=364311 allan changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version Fixed In||4.7.x Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 364311] Ledgers columns can't be resized
https://bugs.kde.org/show_bug.cgi?id=364311 --- Comment #11 from allan --- > 4.6.4 is now very old and you are missing a lot of bug fixes and > improvements, particularly in KMM. I would strongly advise getting the > latest release from the Claydoh ppa. If you want to use KMM on Linux, then will you upgrade? No development work will occur if the problem has already been fixed. I have just installed 4.7.2 again and checked this. All columns are fully displayed. On a wide screen, the Details column expands, but the other columns are still displayed correctly. An empty Number field starts off narrow, but expands to show the data in full. I don't think I can say more. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 364311] Ledgers columns can't be resized
https://bugs.kde.org/show_bug.cgi?id=364311 --- Comment #9 from allan --- (In reply to mhaquila from comment #8) > My version for Linux is the 4.6.4 (KDE 4.14.2) and for Windows is the 4.7.2 > (KDE 4.12.5). 4.6.4 is now very old and you are missing a lot of bug fixes and improvements, particularly in KMM. I would strongly advise getting the latest release from the Claydoh ppa. Hopefully you don't see exactly the same behaviour on the Windows version? > No, it's just the problem: adding extra characters into one narrow column > don't increase the column width which is fixed I think in percent of the > screen size independently of the window size. I'm pretty certain this is not the case in the latest versions. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 364311] Ledgers columns can't be resized
https://bugs.kde.org/show_bug.cgi?id=364311 --- Comment #7 from allan --- I don't recollect seeing that sort of behaviour recently. You didn't say what revision of KMM you use? It's some while since I dabbled in this area. Again looking for a work-around, if you add extra characters into one of your narrow columns, does that increase the column width? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 364311] Ledgers columns can't be resized
https://bugs.kde.org/show_bug.cgi?id=364311 --- Comment #3 from allan --- (In reply to mhaquila from comment #2) > (In reply to allan from comment #1) > > Did you try widening the KMyMoney window? > > Yes, I did. However for an easy use of the program, the window can't be > widened more than the screen size, so resize the column seems to be > essential. I assume you know that you can reposition the KMM window to allow stretching to the right? I'm not suggesting that this is a satisfactory solution, but may be a possible work-around. I did actually implement a change to allow column widening, but the current method was preferred by the developers. Just so we have the complete picture, would you give - The KMM version you are using - Your screen size - Whether repositioning is helpful. Perhaps you could attach a screen-shot? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 364311] Ledgers columns can't be resized
https://bugs.kde.org/show_bug.cgi?id=364311 --- Comment #1 from allan --- Did you try widening the KMyMoney window? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 345655] Rounding problems between checking and investment account
https://bugs.kde.org/show_bug.cgi?id=345655 --- Comment #23 from allan --- It looks to me that https://bugs.kde.org/show_bug.cgi?id=303026 still shows its problem. See comment #18. A new manually created copy of its sell transaction still objects if a fee of 12.95 is entered. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 349033] option to invert transaction amounts during import
https://bugs.kde.org/show_bug.cgi?id=349033 --- Comment #3 from allan --- Pending a proper solution, it might save a little effort when importing to select the present amount column as Debit, and some other column as Credit. Then, when importing, you are given the option to accept either the debit or credit column amount, for each transaction. That's a bit of a fag, but it might be easier. The credit amount would need to be edited after import. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 345655] Rounding problems between checking and investment account
https://bugs.kde.org/show_bug.cgi?id=345655 --- Comment #18 from allan --- Referring back to comments #3, #4, #5, and https://bugs.kde.org/show_bug.cgi?id=303026, does that issue now need revisiting? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 345655] Rounding problems between checking and investment account
https://bugs.kde.org/show_bug.cgi?id=345655 --- Comment #10 from allan --- (In reply to Jack from comment #9) > As I understand it, all current developer time is going to the conversion to > KDE Frameworks. This issue is unlikely to be addressed until after that is > complete. > > In addition, while this may certainly be annoying, if does not make KMM > useless. I track several investment accounts in KMM, with multiple brokers, > and it works just fine for me. Remember, nobody is being paid to work on > KMM. > (You may also want to be careful about your choice of words, as "sued" > has a particular legal implication in English, definitely in the US.) I took that to be a typo for 'used'. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 351874] QIF import of investment buys and sells mishandles commissions
https://bugs.kde.org/show_bug.cgi?id=351874 --- Comment #12 from allan --- (In reply to Jeff from comment #9) > That line: > > tr.m_amount = -amount; > > is the one I changed in my patch to fix my problem for "sells". Need remove > the negative sign. Sorry, but I'm a bit puzzled here. With your suggested change, to remove the sign reversal, when the transaction imports, the result shows as a deposit of $8.77 (positive). Throughout the import, the negative sign is maintained, as far as I can see. So, I don't see "The cash account should decrease by 8.77." Why don't I see the result you are expecting? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 351874] QIF import of investment buys and sells mishandles commissions
https://bugs.kde.org/show_bug.cgi?id=351874
--- Comment #8 from allan ---
(In reply to Jeff from comment #6)
> Hi Łukasz,
>
> There is still a problem with the QIF import with your change. My test file
> also tested the case where the commission was greater than the proceeds from
> the sale (which can happen when trading options.) Your fix changed a "sell"
> trade that actually cost money into one that brought in money. The example
> in my test file was the "sell" of the "NFLX Aug 18 2012 110.0 Call". The
> price is 0.02, times 100 shares = 2.00. The commission is 10.77. So income
> of 2.00, outgo of 10.77 makes the total -8.77 (as shown in the U and T
> values in the QIF file). The cash account should decrease by 8.77. Your
> change turned that into a positive 8.77, and increased the cash account.
> This is admittedly a corner case, and I think I am the only KMM user that
> trades options because I have made a bunch of other changes to the KMM code
> to support that.
>
It would not have surprised me if your problem was caused by the same issue I
reported in https://bugs.kde.org/show_bug.cgi?id=362139 comment #7, with the
negative sign getting dropped.
However, the sign appears to be negative throughout the import process until -
Line 1564 in mymoneyqifreader.cpp()
"else if (action == "sell") {
d->st.m_listPrices += price;
tr.m_shares = -quantity;
tr.m_amount = -amount;
tr.m_eAction = (MyMoneyStatement::Transaction::eaSell);"
I don't profess to know anything about a sell where the commission is greater
than the proceeds of the sale. However, I think what happens in general is
that a sell is expected to be input with no sign, and therefore the amount
needs to be set to a negative value. So, in your case, as you have a negative
sign on input, that sign gets removed.
That seems to imply that the commission needs to negative in your case, and
reversing the signs appears to produce your expected result.
If this is all rubbish, just ignore it.
--
You are receiving this mail because:
You are the assignee for the bug.
[kmymoney4] [Bug 362139] CSV Importer asks the same question twice during profile deletion
https://bugs.kde.org/show_bug.cgi?id=362139 --- Comment #10 from allan --- (In reply to NSLW from comment #9) > (In reply to allan from comment #7) > > I think I've traced it, possibly, to the recent fee patch. > > In investprocessing.cpp(), at circa line 1723 - > > tr.m_amount = tr.m_amount.abs() - m_trInvestData.fee.abs(); > > appears to drop the sign. > > I'm glad you did it and gave feedback. I apologize if something is broken > for you lately with CSV imports. I don't have any problem, as I was using a test file, not live data. > I would like to help fixing that. Could you > send your problematic, anonymized CSV test file and explain me what result > you expect after importing? > As I understand, you've got two CashDividends: one negative and one > positive. Frankly I don't get it, shouldn't CashDividends be always > positive, as it its you who gets the cash? The test file is one I've used for several years, and originally I obtained it from another user. At that time, I was developing the CSV investment handling and I found the file quite useful, as the data was not the usual straight-forward simple investment transactions. I cannot now remember if the CashDividend with the negative amount was an original entry, or whether I modified it for the purpose. My "justification/rationale" for the entry was that it was documenting a refund of an erroneous earlier transaction. I suppose a "miscexp" would be similar (or perhaps not). The file was from a US broker, who did produce some odd methods in his files. As it's quite small, here it is below. "Trade Date","Settlement Date","Type","Description 1 ","Description 2","Symbol/CUSIP","Quantity","Price ($)","Amount ($)" "","2/24/2010","DividendAndInterest","Div","description","NECZX","","","504.72" "","3/28/2010","Other","Div","description",""NECZX"","","","-504.72" -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 361021] CSV importer: The transaction has missing assignment of...
https://bugs.kde.org/show_bug.cgi?id=361021 --- Comment #14 from allan --- Just to note that I discovered a possible problem with this, and documented it, in error, in https://bugs.kde.org/show_bug.cgi?id=362139, comment #7. See there for follow up. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 351874] QIF import of investment buys and sells mishandles commissions
https://bugs.kde.org/show_bug.cgi?id=351874 --- Comment #7 from allan --- (In reply to NSLW from comment #4) > Statement reader did it wrong also for CSV imports (see bug #361021) so I > made corrections to the code which seemed to help also QIF reader. Honestly > at that time I didn't know that investment statements are imported by > anything else than CSV and thanks to your bug and code review I see bigger > picture now. I proposed two next patches to statement reader which now I > must review myself because I already see mixed logic between QIF and CSV > imports, which somehow worked by now. > It would be nice if you could send me for testing an anonymized QIF file > with less frequent transaction types such as "dividends" etc. > > I don't know about OFX imports because valid ACCTTYPEs are only: CHECKING, > SAVINGS, MONEYMRKT, and CREDITLINE, and there are no investment ACCTTYPE, so > I assume OFX doesn't support that. Correct me if I'm wrong. The OFX specification 2.0.3 includes - "CHAPTER 13 INVESTMENTS OFX supports download of security information and detailed investment account statements including transactions, open orders, balances, and positions. " plus a lot more in detail. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 362139] CSV Importer asks the same question twice during profile deletion
https://bugs.kde.org/show_bug.cgi?id=362139 --- Comment #8 from allan --- (In reply to allan from comment #7) > Today, and the first for a while, I updated from HEAD and to ensure all was > OK, I did a CSV import of an investment file, which contained two similar > entries. They were both CashDividends, with the main difference being that > one had an identical but negative amount. On import, the negative sign had > been dropped. > I think I've traced it, possibly, to the recent fee patch. > In investprocessing.cpp(), at circa line 1723 - > tr.m_amount = tr.m_amount.abs() - m_trInvestData.fee.abs(); > appears to drop the sign. This comment of mine, #7, was added to this bug when I first discovered this problem, but on investigating, it seems that it doesn't really belong here, but probably to BUG: 361021. I can add this entry to that bug report, but that might cause confusion about which bug to follow. So, do I leave as is? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 362139] CSV Importer asks the same question twice during profile deletion
https://bugs.kde.org/show_bug.cgi?id=362139 --- Comment #7 from allan --- Today, and the first for a while, I updated from HEAD and to ensure all was OK, I did a CSV import of an investment file, which contained two similar entries. They were both CashDividends, with the main difference being that one had an identical but negative amount. On import, the negative sign had been dropped. I think I've traced it, possibly, to the recent fee patch. In investprocessing.cpp(), at circa line 1723 - tr.m_amount = tr.m_amount.abs() - m_trInvestData.fee.abs(); appears to drop the sign. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 362430] KMyMoney crashed on account type change
https://bugs.kde.org/show_bug.cgi?id=362430 --- Comment #1 from allan --- I am able to do this, and then revert it, with no problem, using the development branch. 4.6.6 is now pretty old, and I would advise that you might be better off getting 4.7.2, possibly from the Claydoh PPA. Was this an isolated event, or were you able to reproduce the problem? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 362399] Import of payees details
https://bugs.kde.org/show_bug.cgi?id=362399 --- Comment #1 from allan --- (In reply to Martin Tlustos from comment #0) > I would like to import my payees details into kmymoney. Manually adding the > information for several hundred payees is too cumbersome. > > Reproducible: Always Yes, I can imagine that that would be a bit boring. >From where do you intend to import (which app)? It's a long time since I used Quicken, but if it is relevant, try this - from a Google search 'In Q2012: File > File Export > QIF File. Choose a File to export to. In the "Include in Export" section, uncheck all but "Category List" and "Memorized Payees" then In Q2013: File > File Import > QIF File. Browse to the QIF file created in Q2012. Choose any account (or All Accounts) to import into. In the "Include in import" section, uncheck all but "Category List" and "Memorized Payees". ' - to confirm that you can actually export them. If that works, try to do a QIF import to KMyMoney. If that is unsuccessful, could you attach the file to this bug report, or send off-line to me. Include the categories - they might be useful for comparison. I have, a long time ago, imported a category list, but am not sure about payees. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360435] CSV Importer doesn't recognize security if its symbol isn't lower case
https://bugs.kde.org/show_bug.cgi?id=360435 --- Comment #17 from allan --- (In reply to NSLW from comment #16) > (In reply to allan from comment #15) > > Unfortunately, I am unable to follow the detail of the latest proposed > > patch, but I would like to urge some caution. It may be that the proposal > > does not affect the config file - csvimporterrc, but in its current > > implementation, it is possible for the user to edit the entries in the file > > to suit his needs. If instead the entries are moved into the coding, then > > recompilation would be required for any changes, which most users would not > > wish to face. If this is not the case, then that's fine. > > The second version of the patch is different from the first you've committed > only in asking m_map for security name using its symbol in uppercase instead > of lowercase, because m_map is from now on filled by default with symbols in > uppercase and m_map won't return correct name if asked in lowercase. > > AFAIK no part of csvimporterrc shouldn't impact the behavior changed here. > In fact we make the behavior lax, so user can in any time change his symbol > from uppercase to lowercase or mixed case and still get it detected as the > same symbol. > > If that's fine I think I can apply second version of patch just like you've > applied the first one. That sounds good to me. Would you check on the Frameworks side please, as Christian committed only my 'partial' patch. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 361865] Dialog uses 'share' when in fact referring to shares and/or bonds (i.e., securities)
https://bugs.kde.org/show_bug.cgi?id=361865 --- Comment #5 from allan --- Many/most/some users migrate from Quicken to KMM. The English terms in question are exactly the same as those used in Quicken, and probably the MS equivalent too. My advice is "Leave well alone." -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 361865] Dialog uses 'share' when in fact referring to shares and/or bonds (i.e., securities)
https://bugs.kde.org/show_bug.cgi?id=361865 --- Comment #3 from allan --- I would not waste my time looking into changing the term 'share' here. It is embedded deeply within KMyMoney source code, and appears well over 900 times. Bond appears 13 times. I agree with Jack that possibly instead what is needed is additional guidance to the translators. Out of interest, what is the distinction between the original term and the proposed revision? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360435] CSV Importer doesn't recognize security if its symbol isn't lower case
https://bugs.kde.org/show_bug.cgi?id=360435 --- Comment #15 from allan --- Unfortunately, I am unable to follow the detail of the latest proposed patch, but I would like to urge some caution. It may be that the proposal does not affect the config file - csvimporterrc, but in its current implementation, it is possible for the user to edit the entries in the file to suit his needs. If instead the entries are moved into the coding, then recompilation would be required for any changes, which most users would not wish to face. If this is not the case, then that's fine. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360435] CSV Importer doesn't recognize security if its symbol isn't lower case
https://bugs.kde.org/show_bug.cgi?id=360435 --- Comment #14 from allan --- Very sadly, I find I can not continue my involvement. Thomas is aware of the situation. I think it might be as well for this complete topic to be submitted to Reviewboard. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 361271] after saved file, the file corrupted, and I lost my data
https://bugs.kde.org/show_bug.cgi?id=361271 --- Comment #5 from allan --- (In reply to Ricardo Esdra from comment #4) > Created attachment 98194 [details] > attachment-18641-0.html > > I've auto-backup, in megasync cloud, and his update too stayed with 0 kb > I'll use a old file what I've of february 29, and redoing it until today. > > > How I can create a option for auto daily backup? > exemple [file.kmy_20130401] in the name > > -- > Ricardo Libanio > > > > > > Em Sex, 01 Abr 2016 17:19:30 -0300 allan via KDE Bugzilla > <bugzilla_nore...@kde.org> escreveu > > https://bugs.kde.org/show_bug.cgi?id=361271 > > --- Comment #3 from allan <agande...@gmail.com> --- > Just in case there's a hint of help, I don't suppose you could have setup > for > auto-backup? In which case, there might be copies in the same folder as your > *.kmy files? > > Allan See the KMyMoney handbook - https://docs.kde.org/stable4/en/extragear-office/kmymoney/firsttime.backup.html. The information is also in the application - see Help -> KMyMoney handbook -> Using KMyMoney for the first time -> Backing up. Plus, see Settings → Configure KMyMoney-> General -> Global -> Autosave... Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 361271] after saved file, the file corrupted, and I lost my data
https://bugs.kde.org/show_bug.cgi?id=361271 --- Comment #3 from allan --- Just in case there's a hint of help, I don't suppose you could have setup for auto-backup? In which case, there might be copies in the same folder as your *.kmy files? Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 361191] Reconciled operations won't show up
https://bugs.kde.org/show_bug.cgi?id=361191 --- Comment #1 from allan --- I would advise getting an up-to-date version, first of all. Look for 4.7.2 in the Claydoh PPA. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360435] CSV Importer doesn't recognize security if its symbol isn't lower case
https://bugs.kde.org/show_bug.cgi?id=360435 --- Comment #13 from allan --- (In reply to NSLW from comment #12) > (In reply to allan from comment #11) > > Are you sure about the change to csvwizard.cpp? As far as I can see, with > > "exists = false;" in the while loop, it works correctly. > > As long as list variable is not empty. If it's empty you wont even enter > while loop (thus wont even define exists variable) and it is empty if you > have no securities on "securities tab". It's corner case, I'm sure of. Yes, of course. You are right. I think we're all happy with this now, so I'll be going ahead to commit. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360435] CSV Importer doesn't recognize security if its symbol isn't lower case
https://bugs.kde.org/show_bug.cgi?id=360435 --- Comment #11 from allan --- Are you sure about the change to csvwizard.cpp? As far as I can see, with "exists = false;" in the while loop, it works correctly. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 361050] CSV importer crashes on assigning columns (repro-file included)
https://bugs.kde.org/show_bug.cgi?id=361050
--- Comment #4 from allan ---
(In reply to Felix Leimbach from comment #3)
> That's exactly right and is enough to crash kmymoney-4.7.2 as per the "steps
> to reproduce" above. Obviously the real file - a paypal transaction export -
> contains more rows but they are not required to reproduce.
Not for me, I'm afraid. No crash, no matter what column I select for the date.
Did you completely remove all the remaining rows?
Early on, I did have problems with Paypal, because of the number of columns,
but I think that should be OK now.
So, I can't go any further at the moment.
> In fact we can narrow it down further: Removing all columns starting with
> and including "Rechnungs-Nr." in the one single line does not stop kmymoney
> from crashing. Remove one more column ("Vorgangs-Nr.") and it does not crash
> anymore.
> It is not the "Vorgangs-Nr." itself though, because renaming that does not
> fix the crash. Also, removing some columns at the beginning can also fix the
> crash.
--
You are receiving this mail because:
You are the assignee for the bug.
[kmymoney4] [Bug 361050] CSV importer crashes on assigning columns (repro-file included)
https://bugs.kde.org/show_bug.cgi?id=361050 --- Comment #2 from allan --- I see only a single row, of, apparently, headings, but no actual transaction data. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 361021] CSV importer: The transaction has missing assignment of...
https://bugs.kde.org/show_bug.cgi?id=361021 --- Comment #10 from allan --- (In reply to NSLW from comment #9) > (In reply to allan from comment #8) > > (In reply to NSLW from comment #0) > > > Buy transactions imported by CSV importer always have missing assignment > > > > It's not correct to say that they '...always have missing assignment' it is > > only under certain conditions. > > For me it always has missing assignment during import from CSV and empty > ledger. Do you know conditions under which it doesn't happen? Yes. Often, the problem is that a Buy/Sell/ReinvDiv, which involve funds transfers, does not have the name of the relevant checking/brokerage account provided. During CSV import of these types, an extra dialog opens that asks for the name of the checking/brokerage account that is to be used. If this is correctly entered, then the transaction is not unbalanced. In general, I do not have a problem, over many years, with missing assignments. > (In reply to allan from comment #7) > > There is also another issue, with fees sometimes getting the wrong sign, > > which I identified in https://bugs.kde.org/show_bug.cgi?id=360129. I think > > the patch in this current bug may be related. > > According to my research bug #360129 can be independently fixed from this > bug and this bug can be independently fixed from bug #360129. > Moreover through simple sign changes in my patch I can cause both operations > to display warning about assignment and not only for sell operations. > How do you see them correlated? I don't see the two bugs as related, except that https://bugs.kde.org/show_bug.cgi?id=361029 highlighted the fee sign issue. I'm assuming/hoping that your patch here is for that same problem. I haven't yet had a chance to look into it. > Nevertheless, Allan please analyze this and another bug with patches for > them. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 361021] CSV importer: The transaction has missing assignment of...
https://bugs.kde.org/show_bug.cgi?id=361021 --- Comment #8 from allan --- (In reply to NSLW from comment #0) > Buy transactions imported by CSV importer always have missing assignment It's not correct to say that they '...always have missing assignment' it is only under certain conditions. > (see attachment). > > Reproducible: Always > > Steps to Reproduce: > 1. file->import csv > 2. choose investment > 3. create new profile > 4. open "test file.csv" and assign columns to values (see attachment) > 5. FieldDelimiter to comma > 6. TextDelimiter to double quotes > 7. DecimalSymbol to comma > 8. ImportCSV > > Actual Results: > In ledger: > All buy operations have missing assignment > On home page: > Balance for banking and investment account are equal. > > Expected Results: > In ledger: > All operations should have assignment > On home page: > Balance for banking and investment account should be equal only in special > cases. Correct difference in balance is shown in attachment. > > To get good balance without the need of patching one has to double click > every operation in ledger and press enter button. Upon completion column > value will have exact same values as column from patched KMM. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 361021] CSV importer: The transaction has missing assignment of...
https://bugs.kde.org/show_bug.cgi?id=361021 --- Comment #7 from allan --- (In reply to Jack from comment #5) > Without looking at the details, I believe this is not a problem with the CSV > importer, but with any KMM import of an investment transaction which > requires a brokerage account for transfer of funds. That's not exactly true. I've just done a QIF import of a Buy transaction, as a test, and that correctly identified the checking account to be used. There is also another issue, with fees sometimes getting the wrong sign, which I identified in https://bugs.kde.org/show_bug.cgi?id=360129. I think the patch in this current bug may be related. > (I have it with OFX > import.) The issue is that when KMM imports an investment transaction, it > does not specify the brokerage account, so the missing assignment refers to > the amount which would go to that account. When you edit the transaction, > KMM automatically enters the brokerage account, so the error disappears. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 361004] CSV Importer doesn't read DecimalSymbol stored in csvimporterrc
https://bugs.kde.org/show_bug.cgi?id=361004 allan changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED --- Comment #5 from allan --- Well spotted! Now, why did I do that? I'll come back to this later. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360938] Scheduled transactions entered in credit card (liability) have random descriptions populated
https://bugs.kde.org/show_bug.cgi?id=360938 --- Comment #5 from allan --- On 26/03/16 15:55, via KDE Bugzilla wrote: > https://bugs.kde.org/show_bug.cgi?id=360938 > > --- Comment #4 from lp.allar...@gmail.com --- > I am not off to a good start. First I downloaded the sources of 4.7.2 then > followed the instructions of the README.cmake file which mentions that I > should > run "sudo apt-get build-dep kmymoney" since I am on ubuntu (mint).. The > output > was > > Reading package lists... Done > Building dependency tree > Reading state information... Done > E: Unable to find a source package for kmymoney > > Then I tried to manually start the cmake compilation process and got : > > CMake Error at CMakeLists.txt:72 (find_package): >By not providing "FindQGpgme.cmake" in CMAKE_MODULE_PATH this project has >asked CMake to find a package configuration file provided by "QGpgme", but >CMake did not find one. > >Could not find a package configuration file provided by "QGpgme" with any >of the following names: > > QGpgmeConfig.cmake > qgpgme-config.cmake > >Add the installation prefix of "QGpgme" to CMAKE_PREFIX_PATH or set >"QGpgme_DIR" to a directory containing one of the above files. If "QGpgme" >provides a separate development package or SDK, be sure it has been >installed. > -- Configuring incomplete, errors occurred! > > I am not sure how to proceed since I am not using KDE as my DE and I am not > developing apps for KDE.. > KMyMoney is a KDE application, and to compile from source you would need to have a number of dependencies, "QGpgme" included. However, if you are not familiar with KDE application development, it might be better for you to locate the Claydoh PPA, and you should find a recent KMyMoney release there. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360435] CSV Importer doesn't recognize security if its symbol isn't lower case
https://bugs.kde.org/show_bug.cgi?id=360435 --- Comment #9 from allan --- (In reply to NSLW from comment #8) > (In reply to allan from comment #7) > > I did fix this a while ago, following > > https://bugs.kde.org/show_bug.cgi?id=352789, but somehow things got > > side-tracked, and it was not committed. > > > > The proposed patch looks, good, but I would make one change, in > > " > > securityName = m_wizDlg->m_csvDialog->ui->tableWidget->item(row, > > detail)->text().toUpper().trimmed();" > > > > I would propose removing the '.toUpper()', allowing the user's > > value/preference to be maintained. > > That seems reasonable. Do you need me to send you another patch? No, thanks. I think we have enough. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360747] CSV Importer detects more columns than are assigned
https://bugs.kde.org/show_bug.cgi?id=360747 allan changed: What|Removed |Added Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360747] CSV Importer detects more columns than are assigned
https://bugs.kde.org/show_bug.cgi?id=360747 allan changed: What|Removed |Added Attachment #97981|[PATCH] Use parseLine() to |[PATCH] CSV Importer description|determine most likely |detects more columns than |fieldDelimiter |are assigned -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360435] CSV Importer doesn't recognize security if its symbol isn't lower case
https://bugs.kde.org/show_bug.cgi?id=360435 allan changed: What|Removed |Added Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 --- Comment #7 from allan --- I did fix this a while ago, following https://bugs.kde.org/show_bug.cgi?id=352789, but somehow things got side-tracked, and it was not committed. The proposed patch looks, good, but I would make one change, in " securityName = m_wizDlg->m_csvDialog->ui->tableWidget->item(row, detail)->text().toUpper().trimmed();" I would propose removing the '.toUpper()', allowing the user's value/preference to be maintained. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360379] kmymoney don't start -->kmymoney: symbol lookup error: kmymoney: undefined symbol: _ZTI9onlineJob
https://bugs.kde.org/show_bug.cgi?id=360379 --- Comment #13 from allan --- Christian Are you intending to follow up your concern outside of this bug? Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360500] Unable to enter the same value in the No. field for more than 1 transaction.
https://bugs.kde.org/show_bug.cgi?id=360500 --- Comment #4 from allan --- On 14/03/16 18:45, Christian David via KDE Bugzilla wrote: > https://bugs.kde.org/show_bug.cgi?id=360500 > > Christian David changed: > > What|Removed |Added > > CC||christian-da...@web.de > > --- Comment #3 from Christian David --- > In void TransactionEditor::slotNumberChanged(const QString& txt): > > Why do you use loadText() and not setText() in you patch? There are two separate routines involved, and one was using loadText() and the other setText(). I couldn't see any reason for the difference, and just decided to use loadText(). > However, the loadText() seems unnecessary to me. In the routine you refer to, then, yes, it does seem unnecessary, but not so in void TransactionEditor::assignNextNumber(). The first one there is necessary. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360129] CSV Importer doesn't recognize sell operation in Polish
https://bugs.kde.org/show_bug.cgi?id=360129
allan changed:
What|Removed |Added
Status|UNCONFIRMED |CONFIRMED
Ever confirmed|0 |1
--- Comment #15 from allan ---
(In reply to NSLW from comment #14)
> (In reply to allan from comment #13)
> > What I'm not sure about just now is whether, once the user has chosen to
> > make a substitution, that new term is added to the resource file
> > automatically. It's a few ears since I wrote that code.
>
> That's worth checking. That might be a second bug.
I'll check.
>
> > I know no Polish financial terms. If the Buy list contains a correct Polish
> > term, then that I presume was added by the translator. A possible
> > explanation is that at line 161 (in my version) of investprocessing.cpp the
> > following appears - "m_buyList += i18nc("verb", "buy"); //
> > some basic entries in case rc file missing". It may be that that was when
> > the translation for Buy was added. However, the next line is similar for
> > the Sell operation, and that was not translated apparently.
>
> All terms are and were translated.
In the rc file snippet you attached, only Buy and Reinvdiv have content.
>
> > I would suggest that you include both noun and verb versions for Sell in
> > your resource file.
>
> I already have them and it works for me.
>
> > > As it is now was also misleading to me, to today although I'm an fresh
> > > KMyMoney user :) and translator, so maybe another suggestion will sound
> > > better to an layman:
> > > "Type of operation as in financial statement"
> > >
> > That does sound more understandable, although it would have to be added to
> > every transaction type.
>
> I think you're right, is there any problem for it to be added to every
> transaction type?
Only in terms of bloat. However, if I create a single string, I can refer to
that instead of using the full version.
>
> > > > So, apart from the fee query, are you now in business?
> > >
> > > After manually editing csvimporterrc file, fee is imported just right for
> > > all operations. What do you mean by me being in business?
> >
> > Apologies for that. I'm extremely impressed by the general level of
> > knowledge of English shown by the users, and developers, and I forget myself
> > sometimes and lapse into the vernacular. "being in business" is used to
> > indicate that a problem has been solved and normal service may be resumed.
> > I hope it didn't cause offence.
>
> No, none at all. You've suggested me a workaround and it worked for me as
> expected.
>
> > So far as your suggested patch is concerned, I'm not sure of its purpose.
> > The Subject is "[PATCH] Read operation's type explicitly as QStringList",
> > and in it you add a number of QStringList definitions, which are already
> > included in investprocessing.h, c. line 164.
>
> I think that after my patch, every variable is defined anew locally, which I
> think is not clean way to do this and doesn't remove the source of the
> problem, but it works flawlessly. After the patch my csvimporterrc is
> filled out automatically with all the data whereas before the patch only
> BuyParam and ReinvdivParam were filled out.
> I tell you what, I'm going to see into the problem once again soon and I
> will try to find its source, cause I really want it to see it fixed.
>
> > Oh, and just as a post script, I've added "in Polish" to the bug heading, as
> > the import operation is otherwise as expected.
>
> I would say "in non-English"
Well, we don't know of any other problem, and it seems to depend on
translation, so I think I'll stick with the current version. It can always be
edited if needed in the future.
>
> Łukasz
--
You are receiving this mail because:
You are the assignee for the bug.
[kmymoney4] [Bug 360500] Unable to enter the same value in the No. field for more than 1 transaction.
https://bugs.kde.org/show_bug.cgi?id=360500 allan changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED Version Fixed In||4.8 Latest Commit||dc5109988fbf1f732525e6a6ec1 ||93903b472b632 --- Comment #2 from allan --- I think the intention in clearing the cell contents may have been to assist the user to enter the required value, perhaps. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360500] Unable to enter the same value in the No. field for more than 1 transaction.
https://bugs.kde.org/show_bug.cgi?id=360500 --- Comment #1 from allan --- Created attachment 97898 --> https://bugs.kde.org/attachment.cgi?id=97898&action=edit Fix for bug 306500 This is a trivial patch, and with developer time being scarce, I see no point in going via reviewboard. Unless I hear to the contrary, I propose to push it in about a week, in order to, hopefully, make it into rev 4.8. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360129] CSV Importer doesn't recognize sell operation in Polish
https://bugs.kde.org/show_bug.cgi?id=360129
allan changed:
What|Removed |Added
Summary|CSV Importer doesn't|CSV Importer doesn't
|recognize sell operation|recognize sell operation in
||Polish
--- Comment #13 from allan ---
(In reply to NSLW from comment #11)
> (In reply to allan from comment #10)
> > (In reply to NSLW from comment #8)
> > > Created attachment 97709 [details]
> > > csvimporterrc snippet
> > >
> > > I looked in csvimporterrc and found that
> > > 1) BuyParam=kup
> > >
> > > "kup" is an verb, while "kupno" is noun. Maybe KMyMoney detects "kupno" by
> > > regular expression.
> >
> > It's just "type.contains(*it, Qt::CaseInsensitive", so fairly loose to
> > improve matching chance. Do you see any problem with that?
>
> It works with my Buy operations, but I would like it to work also with my
> Sell operations out of the box.
I'm afraid that may be a tall order. It will only work out of the box if the
file being imported actually uses the exact same translation as that of the
translator of the KMyMoney file. Unfortunately, what tends to be found is that
different financial institutions use different terms to describe their
transaction type, in fact sometimes changing within the same file.
This is the reason I allowed for alternative terms to be added to the parameter
list in the resource file. If the file being imported contains an unrecognised
type, the user will be informed and given the chance to substitute with the
standard KMyMoney transaction type. If this should happen more than the odd
time, the user may add that unrecognised type to the appropriate list in the
resource file.
What I'm not sure about just now is whether, once the user has chosen to make a
substitution, that new term is added to the resource file automatically. It's
a few ears since I wrote that code.
> I think that "type.contains(*it, Qt::CaseInsensitive)" is harmless here.
>
> > > 2) SellParam=
> > >
> > > after setting this parameter to "Sprzedaż" my sell operations are
> > > recognized
> > > correctly, but why isn't that preset just like BuyParam? Maybe SellParam
> > > isn't preset because of last letter in "Sprzedaż", which is diacritic
> > > letter.
I know no Polish financial terms. If the Buy list contains a correct Polish
term, then that I presume was added by the translator. A possible explanation
is that at line 161 (in my version) of investprocessing.cpp the following
appears - "m_buyList += i18nc("verb", "buy"); // some
basic entries in case rc file missing". It may be that that was when the
translation for Buy was added. However, the next line is similar for the Sell
operation, and that was not translated apparently.
I would suggest that you include both noun and verb versions for Sell in your
resource file.
> >
> > I would have to throw that one back to you, as I didn't edit that file.
> > Might you not have been the translator then?
>
> "Sprzedaż" is meant too look like this so no need to edit it. What I meant
> by above is: Could there be an sort of encoding problem in KMyMoney with
> that Polish letter, which in the end prevents positive recognition?
>
> > > As another suggestion, i think it is good to expand context from "verb"
> > > to "Action/Type as
> > > recognized by CSV Importer"
> >
> > Perhaps that would make sense as you are a user as well as a translator?
> > I'm not sure that a non-investment-wise translator might understand?
>
> As it is now was also misleading to me, to today although I'm an fresh
> KMyMoney user :) and translator, so maybe another suggestion will sound
> better to an layman:
> "Type of operation as in financial statement"
>
That does sound more understandable, although it would have to be added to
every transaction type.
> > So, apart from the fee query, are you now in business?
>
> After manually editing csvimporterrc file, fee is imported just right for
> all operations. What do you mean by me being in business?
Apologies for that. I'm extremely impressed by the general level of knowledge
of English shown by the users, and developers, and I forget myself sometimes
and lapse into the vernacular. "being in business" is used to indicate that a
problem has been solved and normal service may be resumed. I hope it didn't
cause offence.
So far as your suggested patch is concerned, I'm not sure of its purpose. The
Subject is "[PATCH] Read operation's type explicitly as QStringList", and in it
you add a number of QStringList definitions, which are already included in
investprocessing.h, c. line 164.
Oh, and just as a post script, I've added "in Polish" to the bug heading, as
the import operation is otherwise as expected.
Allan
--
You are receiving this mail because:
You are the assignee for the bug.
[kmymoney4] [Bug 360379] kmymoney don't start -->kmymoney: symbol lookup error: kmymoney: undefined symbol: _ZTI9onlineJob
https://bugs.kde.org/show_bug.cgi?id=360379 allan changed: What|Removed |Added CC||agande...@gmail.com --- Comment #10 from allan --- (In reply to Jack from comment #9) > Thanks for following up. Since it now works for you now, I would guess that > it was a transient issue related to dependencies, and they fixed it between > between when you updated, and when you just reinstalled. I suppose we can > close as "worksforme" But remember, [initially] "...I used kmymoney without any problems for three weeks since i updated to 4.7.2." My money was on a local issue, caused when "The only thing i do was a update and upgrade of my system." Anyway, all in order now. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360210] Msg: "Stock account must have investment account as parent" adding investment to existing account
https://bugs.kde.org/show_bug.cgi?id=360210 --- Comment #11 from allan --- Oh, and the Brokerage account is showing as an investment account when it should be a checking account. So, things not quite as they should be. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360210] Msg: "Stock account must have investment account as parent" adding investment to existing account
https://bugs.kde.org/show_bug.cgi?id=360210 allan changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED --- Comment #10 from allan --- Just a final thought. Looking at your attachment, which I think you thought was incorrect, I notice that, while it doesn't exactly correspond with your description of the problem, you said "I had a problem getting to this point - the New investment option on the Investments context menu was greyed out". However, that account is an asset account, and it should be an investment account. If I right click on Investments, then I too see your screen-grab 97768. I suspect that this might be the root of the problem. I'll close the bug, anyway. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360379] kmymoney don't start -->kmymoney: symbol lookup error: kmymoney: undefined symbol: _ZTI9onlineJob
https://bugs.kde.org/show_bug.cgi?id=360379 allan changed: What|Removed |Added CC|agande...@gmail.com | --- Comment #6 from allan --- (In reply to soulrebell from comment #5) > I tried > kmymoney -n > and i became the same message. OK so you received the same message, even when no data file was loaded. Just to be certain, when did you receive the message? Was it while KMM was loading? Or, did KMM finish loading and allow you to choose your data file? If it occurred while KMM was loading, then your data file is likely to be OK, but it then means that it is KMM itself which is the problem. Either way, though, it wouldn't do any harm to uninstall KMM, then re-install. Do make sure you uninstall everything - that is, as you installed an Ubuntu package, use the Software centre or Synaptic to uninstall it. Then re-install it and try again. It may be that the update you did has corrupted something. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360379] kmymoney don't start -->kmymoney: symbol lookup error: kmymoney: undefined symbol: _ZTI9onlineJob
https://bugs.kde.org/show_bug.cgi?id=360379 --- Comment #4 from allan --- (In reply to Jack from comment #3) > It sounds to me like a linking symbol, not a stock symbol. Is it possible > the Ubuntu package has a compil/link problem? Yes, That's more likely, definitely. > Also - .kmy files are generally gzipped, so you would need to make a copy of > it, renaming to something like X.xml.gz. Then gunzip that file. Then you > can look at X.xml with any text editor. > I had found an old reply of mine with that method, that , I posted, had worked. I did the same this time before posting, and it does open as a XML file without unzipping, provided the file associations are changed. > I do agree with Allan suggestion to try "kmymoney -n" from a command line. > If that fails, then the error has nothing to do with your file. If it > succeeds, and you still get the error when opening your .kmy file, then > something is funny in the file. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360379] kmymoney don't start -->kmymoney: symbol lookup error: kmymoney: undefined symbol: _ZTI9onlineJob
https://bugs.kde.org/show_bug.cgi?id=360379 --- Comment #2 from allan --- Does _ZTI9onlineJob sound like a valid symbol to you - it doesn't to me. Wondering if your file might have got corrupted. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360379] kmymoney don't start -->kmymoney: symbol lookup error: kmymoney: undefined symbol: _ZTI9onlineJob
https://bugs.kde.org/show_bug.cgi?id=360379 allan changed: What|Removed |Added CC||agande...@gmail.com --- Comment #1 from allan --- First of all, do you have backup files? Secondly, if you get the problem immediately on starting-up, then it sounds like your .kmy file is at fault. If you launch KMM from the console by entering "kmymoney -n", minus the punctuation, it will start up without loading that .kmy file. This gives you a chance to do some investigating. If you do have a backup, you can now try loading that, and look for the symbol in question. If you don't have backup, then you are a bit stuck. Are you reasonably confident in editing files? If so, firstly make a copy of the problem .kmy file, just in case things go nasty. Then, try to open the .kmy file with either kate or kwrite. With luck, you should see an XML formatted file. If you don't, then You may need to go into the KDE System settings program, and open File Associations. Enter kmymoney into the search box and it should find x-kmymoney. Select that, then look at the lower window on the right - Application Preference Order. Click 'Add' and enter either/both kate/kwrite. You should then be able to view your file. Then if that gives you an xml-looking text file, search for the missing entry. Copy every such entry and add to the bug report. If there is sensitive data, you'll have to just disguise it. See how that goes. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360373] New: Save File Dialog - cursor mispostions
https://bugs.kde.org/show_bug.cgi?id=360373 Bug ID: 360373 Summary: Save File Dialog - cursor mispostions Product: kmymoney4 Version: git master Platform: Mint (Ubuntu based) OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: file Assignee: kmymoney-devel@kde.org Reporter: agande...@gmail.com If I have downloaded a file and wish to amend the file name, by adding a prefix, the first letter is positioned correctly, but then the cursor jumps to the endpoint of the existing file name. If this is not noticed, an incorrect name is used, and the extension is unrecognised. Reproducible: Always Steps to Reproduce: 1.Download a file. 2.Start to add a prefix, say a KMM account name before the existing name, which possibly is a date. 3.Original filename say is 2016.csv. 4. Enter the first letter, say 'C' of Current. 5. Now add the second letter, the 'u'. 6. This, and subsequent letters, are added after the file extension. 7. The name becomes C2016.csv.urrent. Actual Results: As above. Expected Results: Filename should be Current2016.csv. Interestingly, if the error is noticed, and the added first letter is backspaced over, the wanted prefix can now be added correctly. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360210] Msg: "Stock account must have investment account as parent" adding investment to existing account
https://bugs.kde.org/show_bug.cgi?id=360210 --- Comment #8 from allan --- Ah, I reread your comment and see that you too had been able to add a second investment. So it looks like you may have to follow your suggestion and use the live file copy and strip it down. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360210] Msg: "Stock account must have investment account as parent" adding investment to existing account
https://bugs.kde.org/show_bug.cgi?id=360210 --- Comment #7 from allan --- (In reply to Paul Gover from comment #5) > Doh! That minimal file in attachment 1 [details] is useless. I thought the > initial setup wizard had created an investment account to go with the > brokerage account that it had created, but no. When I added an investment > account, I could add investments to it as expected. (So why does the wizard > create a brokerage account but no matching investment account?) > > I'll try seeing if I can strip down a copy of my live file to something > usable that shows the problem. I ignored the brokerage account you had created and created a new investment account. I added an initial investment, and the added a second with no trouble. I don't think modifying your live file would be as helpful, as it could still contain whatever it was that caused your trouble. So, try using the basic file and see how that goes. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360210] Msg: "Stock account must have investment account as parent" adding investment to existing account
https://bugs.kde.org/show_bug.cgi?id=360210 allan changed: What|Removed |Added CC||agande...@gmail.com --- Comment #1 from allan --- I don't seem to be able to reproduce your problem, apart from Step 3. Is the problem reproducible, possibly in another file.? If so, are you able to provide a minimal .kmy file demonstrating the issue? Have you tried to run the consistency check? -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360129] CSV Importer doesn't recognize sell operation
https://bugs.kde.org/show_bug.cgi?id=360129 --- Comment #10 from allan --- (In reply to NSLW from comment #8) > Created attachment 97709 [details] > csvimporterrc snippet > > I looked in csvimporterrc and found that > 1) BuyParam=kup > > "kup" is an verb, while "kupno" is noun. Maybe KMyMoney detects "kupno" by > regular expression. It's just "type.contains(*it, Qt::CaseInsensitive", so fairly loose to improve matching chance. Do you see any problem with that? > 2) SellParam= > > after setting this parameter to "Sprzedaż" my sell operations are recognized > correctly, but why isn't that preset just like BuyParam? Maybe SellParam > isn't preset because of last letter in "Sprzedaż", which is diacritic letter. I would have to throw that one back to you, as I didn't edit that file. Might you not have been the translator then? > As another suggestion, i think it is good to expand context from "verb" to > "Action/Type as > recognized by CSV Importer" Perhaps that would make sense as you are a user as well as a translator? I'm not sure that a non-investment-wise translator might understand? So, apart from the fee query, are you now in business? Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360129] CSV Importer doesn't recognize sell operation
https://bugs.kde.org/show_bug.cgi?id=360129 --- Comment #7 from allan --- > Hi Allan, > thanks for fast reply. Your description is good when it comes to Sell > operations, but it is not so with Buy operations, because my Buy operations > are recognized automatically and it seems that in this case KMyMoney > understands Polish. No, I'm afraid not! But, it reminds me that there is a bit more to this than I indicated. It's a while since I've been in this area. When importing investment files from different institutions, It was obvious that they had varying ideas as how to describe investment types. To allow for this, In the importer resource file, I've allowed for alternative versions to be added to a list for each investment type. I did not at that stage even consider non-English versions, but happily they can be added in the same way. I have no idea why 'Kupno' is recognised and 'Sprzedaż' is not. Both are foreign to me! All I can think is that the Polish translator has added 'Kupno' to that file, and I'm interested to know, if you would look for me. The file-name is csvimporterrc, and it should be found in your home directory, under /.kde/share/config/csvimporterrc (it could be .kde4). Look for the section corresponding to the new profile you created, like [Profiles-your-profile], then within that look for 'BuyParam=xxx' and see if 'Kupno' appears. Similarly, there will be a 'SellParam' section. You could edit that and add 'Sprzedaż' minus quotes, and close and restart the csv plugin, to see if that helps. It might help also, to read the section in the user guide on importing csv files. > Surprisingly all transactions are invalid if I've got Sell and Buy in CVS in > English. Please read my additional information from the beginning. > > Besides wouldn't it be good if KMyMoney would ask only to identify > unrecognized operation type? > An excellent idea, and with the edited I mentioned above, that is how it should work. Let me know how that goes. Allan > Łukasz -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360129] CSV Importer doesn't recognize sell operation
https://bugs.kde.org/show_bug.cgi?id=360129 --- Comment #4 from allan --- After your step 10 above, the CSV Importer window displays the first transaction as an Invalid Transaction Type, because the importer does not understand Polish, so it gives you the opportunity to select what type of activity 'Sprzedaż' really is, in KMyMoney language. In the drop-down, you need to select Sell Shares, this being one of the activity types that match the values - quantity, price, amount - that are in that transaction. You should see now that the Type is Sell. As this transaction type involves money, you next need to enter the name of the checking/brokerage account you wish to use. The next transaction follows a similar path, with 'Kupno' as the activity type. So, for this you need to select Buy Shares. The remaining transactions follow the same course. I notice that the Buy transactions imported show as unbalanced, with a missing assignment of 6,00. It rather looks as though the fee is getting the wrong sign, which I'll need to have a look into. If any of that is unclear, please let me know. If you think the handbook needs expanding, also, please say how. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360129] CSV Importer doesn't recognize sell operation
https://bugs.kde.org/show_bug.cgi?id=360129 allan changed: What|Removed |Added CC||agande...@gmail.com --- Comment #3 from allan --- This does work for me, but I'll need to get back to you later with a bit more detail about what is required. Allan -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 330952] Incorrect interest value in a loan account
https://bugs.kde.org/show_bug.cgi?id=330952 --- Comment #14 from allan --- If you are still using 4.6.3, it would be as well to upgrade. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 360044] Online updater finds data but doesn't understand it.
https://bugs.kde.org/show_bug.cgi?id=360044 allan changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED CC||agande...@gmail.com --- Comment #1 from allan --- (In reply to Cameron from comment #0) > INVP.L (Investec stock) appears on Yahoo UK with a current price and time > stamp. The online updater finds the data but says it has no price or no date. > > Similar outcome with a fund. > > GB0032494576.L (Aviva Investors Higher Inc Pls A GBP Inc) > > Reproducible: Always > > Steps to Reproduce: > 1.Create stock / fund and set relevant lookup ID and set to Yahoo UK > 2.Run Online Price Update > 3. > > Actual Results: > 1) INVP.L (Investec stock) > Message on price up date popup: Failed to retrieve a quote for INVP.L from > Yahoo UK. Press No to remove the online price source from this security > permanently, Yes to continue updating this security during future price > updates or Cancel to stop the current update operation. > > Status on "Update Stock and Currency Prices" dialogue: Fetching URL > http://uk.finance.yahoo.com/d/quotes.csv?s=INVP.L&f=sl1d3... > Symbol found: "INVP.L" > Price found: 488.80 (488.8) > Unable to update price for INVP.L (no price or no date) > > 2) GB0032494576.L (Aviva Investors Higher Inc Pls A GBP Inc) > Message on price up date popup: Failed to retrieve a quote for > GB0032494576.l from Yahoo UK. Press No to remove the online price source > from this security permanently, Yes to continue updating this security > during future price updates or Cancel to stop the current update operation. > > Status on "Update Stock and Currency Prices" dialogue: Fetching URL > http://uk.finance.yahoo.com/d/quotes.csv?s=GB0032494576.l&f=sl1d3... > Symbol found: "GB0032494576.l" > Price found: 55. (55) > Unable to update price for GB0032494576.l (no price or no date) > > Expected Results: > Since the page isn't displaying a date, should the application not assume > 'today' and interpret the price data. > > > Similar outcome with a fund. I'm not sure that your suggested 'Fix' is a good idea, and does nothing to resolve the problem. So, next time you try to update, if you do actually retrieve a valid price, it too will receive today's date and will overwrite your previous entry. Retrieving pricing information from different web-sites is error-prone, I'm afraid as the sites have a tendency to change the data format, with little regard for their users. There is more than one possible 'solution'. The first is to try a different web-site. I tried ft.com, inputting your fund name and was able to get an up-to-date quote. The other way is to examine the web-page source data and look for the details you require. You would then need to amend the settings in your kmymoney file to suit the actual data format in use. That involves some knowledge of interpreting regex formats, however. In both cases, though, the process may need to be repeated from time to time. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 243534] QIF import of a stock not yet defined in the account results in Add shares transaction assigned to investment account
https://bugs.kde.org/show_bug.cgi?id=243534 --- Comment #6 from allan --- .(In reply to Jan from comment #4) > I think you can close this. Since it's so long ago, I doubt I can ever > reproduce it. Thanks. OK, I'll close it as Invalid, the closest option, I think. Second attempt -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 243534] QIF import of a stock not yet defined in the account results in Add shares transaction assigned to investment account
https://bugs.kde.org/show_bug.cgi?id=243534 allan changed: What|Removed |Added CC||agande...@gmail.com Resolution|UNMAINTAINED|INVALID Status|NEEDSINFO |RESOLVED --- Comment #5 from allan --- (In reply to Jan from comment #4) > I think you can close this. Since it's so long ago, I doubt I can ever > reproduce it. Thanks. OK, I'll close it as Invalid, the closest option, I think. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 359659] Wrong payee matching for new payees during OFX import
https://bugs.kde.org/show_bug.cgi?id=359659 --- Comment #6 from allan --- (In reply to Jan from comment #4) > Allan: No. I do not have a " " Payee, and the payee to which it matches all > unknown (new) payees are "IBERIA" in one kmm file and "SUNOCO 0498589 > WORCESTERM" in another kmm file. Also, this is OFX, not CSV, although I > would not be surprised both use the same matching code. My fix was within the CSV plugin code, to remove potentially troublesome blank payee names, so before any matching. It could be that the OFX code has the same issue, although it does look like your problem is not the same. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 359659] Wrong payee matching for new payees during OFX import
https://bugs.kde.org/show_bug.cgi?id=359659 --- Comment #7 from allan --- (In reply to Jan from comment #5) > Also, I did not have this problem with KMM 1.05. It appeared the day I > switched to KMM 4.6 Long-standing then. As I don't use OFX, it would be very useful if you could provide a mini .kmy file that demonstrates the problem, and also a simple OFX file too. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney4] [Bug 359659] Wrong payee matching for new payees during OFX import
https://bugs.kde.org/show_bug.cgi?id=359659 allan changed: What|Removed |Added CC||agande...@gmail.com --- Comment #2 from allan --- Does this sound like Bug 348635 - CSV Importer can create Payee consisting of a single or multiple space leading to erroneous matching? A fix for this was committed last June and should be in the next stable release. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 358854] Import CSV or QIF doesn't retain full payee field
https://bugs.kde.org/show_bug.cgi?id=358854 --- Comment #4 from allan --- (In reply to Clark Wierda from comment #2) > "FMCC CAFE 60033818 DEARBORN MI" is interpreted as "DEARBORN MI" > "BEST BUY 4101 DEARBORN MI" is also interpreted as "DEARBORN MI" This looks like a payee 'DEARBORN MI' is set up as a simple match, so, when it is encountered, it is treated as the complete payee name, and the remaining data is dropped. The OP would need to edit matching to enlarge that payee to include whatever data is required. -- You are receiving this mail because: You are the assignee for the bug.
[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 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 the assignee for the bug.
[kmymoney] [Bug 358854] Import CSV or QIF doesn't retain full payee field
https://bugs.kde.org/show_bug.cgi?id=358854 --- Comment #3 from allan --- Come on now! We're a bit tetchy aren't we? I don't think you can have read .my response fully as I am interested.If I gave that impression then I must be more careful.While I did mark it as 'works for me' I went on to indicate a possible cause. I also asked one or two questions to help investigate further.There is an issue there but I need more information from you.So pleawe go back and re-read. With your assistance I might be able fto investigate. Allan Sent from my Samsung device Original message From: Clark Wierda via KDE Bugzilla Date: 02/02/2016 03:20 (GMT+00:00) To: agande...@gmail.com Subject: [kmymoney] [Bug 358854] Import CSV or QIF doesn't retain full payee field https://bugs.kde.org/show_bug.cgi?id=358854 --- Comment #2 from Clark Wierda --- I should know better than to submit bugs to KDE projects by now. I may yet learn. I feel obligated to report the conditions where it fails. "FMCC CAFE 60033818 DEARBORN MI" is interpreted as "DEARBORN MI" "BEST BUY 4101 DEARBORN MI" is also interpreted as "DEARBORN MI" There are others, but you clearly aren't interested since it works for you. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 355116] KMyMKMyMoney Vers.: 4.7.2 Import CSV only "," akzepted - I need ";"
https://bugs.kde.org/show_bug.cgi?id=355116 --- Comment #12 from allan --- (In reply to Clark Wierda from comment #11) > So the suggested fix is to revert to the older version and call it done? Linux - > So just for the in case anyone is experiencing the same problem: this bug > has occurred with 4.7.2-0ubuntu1~ubuntu15.10~ppa3 As the official 4.7.2 stable release works correctly, I would go back to Ubuntu, and look for a more up-to-date version of 4.7.2, and preferably the stable release. Windows - I think it would be more sensible to update to 4.7.2. However, it looks like there is a problem there under Windows. I'm expecting a release of 4.8.0 in the fairly near future, which would be the way forward, rather that reverting, although at the moment you may not have a choice. -- You are receiving this mail because: You are the assignee for the bug.
[kmymoney] [Bug 358854] Import CSV or QIF doesn't retain full payee field
https://bugs.kde.org/show_bug.cgi?id=358854 allan changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME CC||agande...@gmail.com --- Comment #1 from allan --- I've marked this as 'works for me'. However, when I imported a file with four identical payee values, and where there is an existing payee with that (single) name, just a single payee was imported, not all four. If I delete that payee, then the import is successful. If I add all four, again this works. So, in your case, can you provide a CSV file which shows the problem, and indicate which, if any of the four intended payee constituents is already a payee. It may be you need to adjust the matching for that/those payee/s. -- You are receiving this mail because: You are the assignee for the bug.
[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 #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 the assignee for the bug.
[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 #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 the assignee for the bug.
