RE: Citibank Visa OFX Problem
> t...@net-bembel.de on Mon, 18 Jul 2016 08:26:27 +0200 > > Jeff, > > On Sunday 17 July 2016 21:45:27 jeffjl@outlook.com wrote: > > > > On 2016.07.17 15:48, Brendan Coupe wrote: > > > > Apparently Citibank is ingnoring the date range so it downloads > > > > everything it has which dates back over 6 months from when the card > > > > was activated. > > > > I have this same problem with my Citi card. Sometimes it actually uses the > > dates in the OFX request, but most of the time it returns every single > > transaction for the last (I think) 2 years. (I've had the card for longer > > than 2 years.) I tried modifying the OFX request and could not find the > > magic words to make it work properly. > > > > In my case KMM would take about 2 or 3 minutes importing and trying to match > > all those transactions, and as I recall, I would usually have to manually > > fix/delete and/or re-accept the payment transfers. > > > > This won't help you, but I got tired of it and modified my copy of the KMM > > statement importer to ignore transactions prior to the "Start date of > > import" in the account's online settings. > > Can you provide me with your patch (against the 4.8 branch is fine) so that I > can check if we can add it to KMM? If you want, please use reviewboard > (https://git.reviewboard.kde.org/ ). > Well, this finally made me switch from the 4.7 to the 4.8 branch. Which let me document my build problem on Windows, thus the new bug report. I also posted my patch for the Citibank problem to the review board. Jeff.
RE: Citibank Visa OFX Problem
> On 2016.07.17 15:48, Brendan Coupe wrote: > > Apparently Citibank is ingnoring the date range so it downloads > > everything it has which dates back over 6 months from when the card > > was activated. I have this same problem with my Citi card. Sometimes it actually uses the dates in the OFX request, but most of the time it returns every single transaction for the last (I think) 2 years. (I've had the card for longer than 2 years.) I tried modifying the OFX request and could not find the magic words to make it work properly. In my case KMM would take about 2 or 3 minutes importing and trying to match all those transactions, and as I recall, I would usually have to manually fix/delete and/or re-accept the payment transfers. This won't help you, but I got tired of it and modified my copy of the KMM statement importer to ignore transactions prior to the "Start date of import" in the account's online settings. Jeff
RE: invenstment transaction report question
What if you recorded it as a "sell" in the investment account, but send the funds to a special "charity" account(s) instead of the (Brokerage) account. Then withdraw the funds from the "charity" account to show that you don't actually have the money. This should allow reports to be made. But it does misrepresent reality a little bit. Maybe you document that in the memos. > Date: Wed, 1 Jun 2016 16:28:47 -0400 > From: ostrof...@users.sourceforge.net > Subject: invenstment transaction report question > To: kmymoney-devel@kde.org > > I have been making some of my charitable donations in the form of > appreciated stock. I have recorded this in KMM as a "remove shares" > with a note in the memo about who they were donated to. I would now > like to get a listing or report of those transactions, including their > value. The problem seems to be twofold. First, neither the > transaction reports nor the investment reports include add/remove > shares transactions. Second, in the ledger, I could filter to the > desired transactions, but add/remove shares transactions do not include > the price as of that date. Is there anything I can do, or would it > require actually digging into the kmy file and extracting both the > transactions and prices separately? > > Thanks for any suggestions. > > Jack
RE: Handling Investment gain and loss
>> Unrealized gain/loss is different than what I'm talking about I know. I took the opportunity to expand the discussion to cover both realized and unrealized :-) Date: Thu, 26 May 2016 08:27:02 -0700 Subject: Re: Handling Investment gain and loss From: mi...@comwestcr.com To: kmymoney-devel@kde.org Unrealized gain/loss is different than what I'm talking about, I'm talking about "realized" gain/loss. Unrealized gain/loss wouldn't be entered into a ledger. I never import transactions, so we definitely are thinking about it from different perspectives. Even if you import transaction, it seems like the time to enter the information for "realized" transactions is then, not when you run a report. Although, the exact procedure for doing it at import time is less clear to me. On Wed, May 25, 2016 at 6:37 PM, wrote: Why would I? To have the software do the work instead of the user. And to get the unrealized gain/loss - useful at the end of the year for tax planning, e.g. do I want to take that loss to offset a gain I've already taken. Also, I generally don't enter transactions. I download / import them. That may be another reason I'm looking at it differently. It is definitely more implementation work for the programmer. Date: Wed, 25 May 2016 07:28:57 -0700 Subject: Re: Handling Investment gain and loss From: mi...@comwestcr.com To: kmymoney-devel@kde.org Although you could probably do much of this via reports, the main question I have is "why would you?" Why not enter all the information when you enter the transaction rather than waiting to see it in a report? And doing it via reports strikes me as a much more complex undertaking than adding a couple fields to the transaction entry form. >From an accounting point of view, "Sell" transactions are essentially >unbalanced transactions. You get a "debit" to your brokerage account for the >money you received, but there's no corresponding "credit" entries for the gain >or for reducing the basis of the asset. On Tue, May 24, 2016 at 6:12 PM, wrote: I'm thinking this could be more of a reports function than a new transaction field. If appropriate "activity" choices are added for transactions, e.g. reinvested long/short term capital gains, return of capital, depreciation if we include assets in general, etc. (there may be quite a few), then it is a matter of collecting the transactions for a given asset and calculating the cost basis (and gain/loss) in a report. Except for the report, those new activities could be treated the same as existing activities, couldn't they? Existing functions could treat a reinvested long term capital gain transaction just like a "buy", for example. No change required to existing code other than recognizing the equivalence. The report could offer selectable specifics like FIFO or average price. I'm not sure the best way to select the assets - maybe choose a date range and display any assets that had "sells" in that range? And the specific lot method probably still needs a new UI. A report could also give you an estimated gain/loss/cost basis on an asset you still owned (unrealized gain/loss). On the taxable / tax-deferred issue - it would be nice if this could be set at the account level. But a report does not provide a way to tag a specific sale with a cost basis method. If you are going to use KMM data to actually do your taxes, that could be important. > Date: Sun, 22 May 2016 18:00:45 -0400 > From: ostrof...@users.sourceforge.net > Subject: Re: Handling Investment gain and loss > To: kmymoney-devel@kde.org > > On 2016.05.22 15:04, Mitch Frazier wrote: > > While entering a number of investment transactions recently I > > realized that > > KMM doesn't actually have a way to record the gain/loss on the sale > > of an > > investment. I was thinking about implementing something to solve > > this but > > wanted to pass the idea past the list first. > > > > As a first step at a solution, I was going to add a couple more rows > > to the > > transaction detail in the investment register: > > > > - A cost basis field. This would be an amount field that is > > used to determine how much the cost of the investment is > > reduced by the sale. Initially this field could be pre-filled > > by the average cost (based on the number of shares being sold). > > If the entire investment is sold, this field would be fixed > > and not editable. > > > > - A gain/loss field. This would be an splitable account field > > for entering the category or categories for the gain/loss. > > Splits are useful for allowing both short-term and long-term > > gain/loss specifications on a transaction. > > > > The current implementation "hides" the gain/loss because the balance > > of an > > investment shows as zero when the share value is zero, regardless of > > the > > amount the investment is sold for. Whereas, since the gain/loss is > > not > > re
RE: Handling Investment gain and loss
Why would I? To have the software do the work instead of the user. And to get the unrealized gain/loss - useful at the end of the year for tax planning, e.g. do I want to take that loss to offset a gain I've already taken. Also, I generally don't enter transactions. I download / import them. That may be another reason I'm looking at it differently. It is definitely more implementation work for the programmer. Date: Wed, 25 May 2016 07:28:57 -0700 Subject: Re: Handling Investment gain and loss From: mi...@comwestcr.com To: kmymoney-devel@kde.org Although you could probably do much of this via reports, the main question I have is "why would you?" Why not enter all the information when you enter the transaction rather than waiting to see it in a report? And doing it via reports strikes me as a much more complex undertaking than adding a couple fields to the transaction entry form. >From an accounting point of view, "Sell" transactions are essentially >unbalanced transactions. You get a "debit" to your brokerage account for the >money you received, but there's no corresponding "credit" entries for the gain >or for reducing the basis of the asset. On Tue, May 24, 2016 at 6:12 PM, wrote: I'm thinking this could be more of a reports function than a new transaction field. If appropriate "activity" choices are added for transactions, e.g. reinvested long/short term capital gains, return of capital, depreciation if we include assets in general, etc. (there may be quite a few), then it is a matter of collecting the transactions for a given asset and calculating the cost basis (and gain/loss) in a report. Except for the report, those new activities could be treated the same as existing activities, couldn't they? Existing functions could treat a reinvested long term capital gain transaction just like a "buy", for example. No change required to existing code other than recognizing the equivalence. The report could offer selectable specifics like FIFO or average price. I'm not sure the best way to select the assets - maybe choose a date range and display any assets that had "sells" in that range? And the specific lot method probably still needs a new UI. A report could also give you an estimated gain/loss/cost basis on an asset you still owned (unrealized gain/loss). On the taxable / tax-deferred issue - it would be nice if this could be set at the account level. But a report does not provide a way to tag a specific sale with a cost basis method. If you are going to use KMM data to actually do your taxes, that could be important. > Date: Sun, 22 May 2016 18:00:45 -0400 > From: ostrof...@users.sourceforge.net > Subject: Re: Handling Investment gain and loss > To: kmymoney-devel@kde.org > > On 2016.05.22 15:04, Mitch Frazier wrote: > > While entering a number of investment transactions recently I > > realized that > > KMM doesn't actually have a way to record the gain/loss on the sale > > of an > > investment. I was thinking about implementing something to solve > > this but > > wanted to pass the idea past the list first. > > > > As a first step at a solution, I was going to add a couple more rows > > to the > > transaction detail in the investment register: > > > > - A cost basis field. This would be an amount field that is > > used to determine how much the cost of the investment is > > reduced by the sale. Initially this field could be pre-filled > > by the average cost (based on the number of shares being sold). > > If the entire investment is sold, this field would be fixed > > and not editable. > > > > - A gain/loss field. This would be an splitable account field > > for entering the category or categories for the gain/loss. > > Splits are useful for allowing both short-term and long-term > > gain/loss specifications on a transaction. > > > > The current implementation "hides" the gain/loss because the balance > > of an > > investment shows as zero when the share value is zero, regardless of > > the > > amount the investment is sold for. Whereas, since the gain/loss is > > not > > recorded anywhere, the balance ought to be negative if the investment > > was > > sold for a gain and positive if sold for a loss. > > > > Mitch > > > > Unfortunately, I think that may be a bit simplistic. Once you have > sold all off an equity, its value is zero, since you don't have any of > it any more. When you do sell, the amount of the basis is not income - > it just gets back what you paid to acquire it. It is the difference > between that basis and the sale price which becomes the short or long > term capital gain or loss. If you actually buy the shares, that > purchase price is the cost. The only reason you would need to be able > to manually adjust this is if you "add" shares you bought before > tracking with KMM, or if the shares are swapped for a different equity, > in which case you "remove
RE: Handling Investment gain and loss
I'm thinking this could be more of a reports function than a new transaction field. If appropriate "activity" choices are added for transactions, e.g. reinvested long/short term capital gains, return of capital, depreciation if we include assets in general, etc. (there may be quite a few), then it is a matter of collecting the transactions for a given asset and calculating the cost basis (and gain/loss) in a report. Except for the report, those new activities could be treated the same as existing activities, couldn't they? Existing functions could treat a reinvested long term capital gain transaction just like a "buy", for example. No change required to existing code other than recognizing the equivalence. The report could offer selectable specifics like FIFO or average price. I'm not sure the best way to select the assets - maybe choose a date range and display any assets that had "sells" in that range? And the specific lot method probably still needs a new UI. A report could also give you an estimated gain/loss/cost basis on an asset you still owned (unrealized gain/loss). On the taxable / tax-deferred issue - it would be nice if this could be set at the account level. But a report does not provide a way to tag a specific sale with a cost basis method. If you are going to use KMM data to actually do your taxes, that could be important. > Date: Sun, 22 May 2016 18:00:45 -0400 > From: ostrof...@users.sourceforge.net > Subject: Re: Handling Investment gain and loss > To: kmymoney-devel@kde.org > > On 2016.05.22 15:04, Mitch Frazier wrote: > > While entering a number of investment transactions recently I > > realized that > > KMM doesn't actually have a way to record the gain/loss on the sale > > of an > > investment. I was thinking about implementing something to solve > > this but > > wanted to pass the idea past the list first. > > > > As a first step at a solution, I was going to add a couple more rows > > to the > > transaction detail in the investment register: > > > > - A cost basis field. This would be an amount field that is > > used to determine how much the cost of the investment is > > reduced by the sale. Initially this field could be pre-filled > > by the average cost (based on the number of shares being sold). > > If the entire investment is sold, this field would be fixed > > and not editable. > > > > - A gain/loss field. This would be an splitable account field > > for entering the category or categories for the gain/loss. > > Splits are useful for allowing both short-term and long-term > > gain/loss specifications on a transaction. > > > > The current implementation "hides" the gain/loss because the balance > > of an > > investment shows as zero when the share value is zero, regardless of > > the > > amount the investment is sold for. Whereas, since the gain/loss is > > not > > recorded anywhere, the balance ought to be negative if the investment > > was > > sold for a gain and positive if sold for a loss. > > > > Mitch > > > > Unfortunately, I think that may be a bit simplistic. Once you have > sold all off an equity, its value is zero, since you don't have any of > it any more. When you do sell, the amount of the basis is not income - > it just gets back what you paid to acquire it. It is the difference > between that basis and the sale price which becomes the short or long > term capital gain or loss. If you actually buy the shares, that > purchase price is the cost. The only reason you would need to be able > to manually adjust this is if you "add" shares you bought before > tracking with KMM, or if the shares are swapped for a different equity, > in which case you "remove" all the original shares and "add" however, > many shares you get of the new equity. (In that case, hopefully KMM > should be able to do the conversion, so you still shouldn't need to do > it manually.) The cost basis just transfers from the old to the new. > I don't see how you get a cost basis by averaging anything. > > I'm not certain about how to record the gain/loss, but I know I already > have category fields for short and long term gain and loss, and two > sets of each - one for taxable, one for tax deferred. So far, I only > use them where the broker designates a dividend (usually for a > reinvestment transaction) as a capital gain, but I don't see why it > won't also work for a sale, expect for needing a category to represent > the recapture of the original payment (cost basis). I suppose creating > a category of cost basis would make sense. When you buy, that's where > the purchase price goes. When you sell, the cost basis category is > reduced by the same, with the appropriate capital gains category > getting the difference from the actual sale price. > > One complication is that if you acquire an equity through multiple > purchases, at different share pric
RE: Can't build gitHEAD version on windows
To clarify - After searching for a way to build KMM on Windows, I ended up with "emerge". It will (with quite a few fixes since it is a bit out of date) download and build everything needed to build KMM on a pure Windows system, e.g. mingw, gcc, msys, QT, KDE, libraries, and KMM. The emerge scripts create build folders based upon the names of the script files. It looks like the script file names are not always maintained and many script file names have versions and dates that are different from what they actually download and build. The script in emerge for KMM built version 4.6.4 but was still named "kmymoney-4.6.1-20110918.py". I modified the script to pull the master branch from git (that option was in the original script but was not used) but I didn't change the script file name (a new script name would disconnect it from the emerge git repository). So the git master branch is getting built in the folder tree containing the name "kmymoney-4.6.1-20110918". I am not mixing versions. Sorry for the confusion. Yes, the "emerge --cleanbuild" removed the entire KMM build folder tree. Next time I do a build I will capture the actual error messages and file a bug report. Thanks. Jeff. > Subject: Re: Can't build gitHEAD version on windows > To: kmymoney-devel@kde.org > From: agande...@gmail.com > Date: Sun, 15 May 2016 11:28:33 +0100 > > > > Hi Jeff > > See below. > > On 15/05/16 10:02, Christian Dávid wrote: > > Hi Jeff, > > > > I do not know what "emerge --cleanbuild" does. If it means "remove the hole > > build folder and rebuild" then you found a bug. > > > > Maybe gcc on Linux is more forgiving in this case, so I never saw this. > > However, I will try to fix this. Due to a lot of work this will probably > > take some time. If possible, could you file a bug report? I will mark > > myself as assignee so I cannot forget it. > > > > Greetings > > Christian > > > >> jeffjl@outlook.com hat am 7. Mai 2016 um 05:53 geschrieben: > >> > >> > >> Hi Christian, > >> > >> I just tried > >> "emerge --cleanbuild kmymoney" > >> > >> which removed everything under > >> ...\build\extragear\kmymoney-4.6.1-20110918\work\mingw4-RelWithDebInfo-gitHEAD" > > I'm puzzled by the reference to "kmymoney-4.6.1-20110918". Why is it > not referencing the 4.7.x location? There can be problems if there > is more than one KMM version installed. > > I must add that I know nothing about Windows installs so ignore me if I > am talking rubbish. > > Allan > > >> > >> followed by > >> "emerge --update kmymoney". > >> > >> Which seems to recompile everything. Still breaks at linking kmymoney.exe > >> due to multiple payeeIdentifierLoader. > >> > >> Sorry about the "gitHEAD" nomenclature. That's what the emerge python > >> script uses. It just did a git today from the master branch. In fact, I've > >> been trying this (new git) every month or so since about August 2015. As I > >> recall, it has always had this linking problem. (In the mean time I've > >> just been using the 4.7.2 branch because it builds.) > >> > >> I've always assumed it was a Windows thing, and that it would eventually > >> get fixed with the next release (when you tried to build the Windows > >> version). I just recently chased down what's wrong and decided to ask if > >> it was an easy fix. > >> > >> Thanks, > >> Jeff. > >> > >>> From: christian-da...@web.de > >>> To: kmymoney-devel@kde.org > >>> Subject: Re: Can't build gitHEAD version on windows > >>> Date: Fri, 6 May 2016 20:59:55 +0200 > >>> > >>> Hi Jeff, > >>> > >>> did you use a "make clean" or even better removed the build folder and > >>> rerun > >>> cmake? My gcc on Linux has no problems building it at all. > >>> > >>> payeeIdentifierLoader is automatically added to kmymoney.exe because it is > >>> marked "LINK_PUBLIC" in target_link_libraries of kmm_mymoney. This is not > >>> good > >>> (I did it as a work around). If this really needs to be corrected, the > >>> library > >>> has to be build as part of kmm_mymoney with correct export attributes > >>> (which > >>> is some work, so I hope the clean will solve the issue :/) > >>> > >>> Greetings > >>> Christian > >>> > >>> P.S.: I assume you are using the branch master. HEAD and 4.7.90 do not > >>> include > >>> too much info. Especially as "HEAD" is a local ref and can stay the same > >>> forever if you never pull. > >>> > >>> Am Freitag, 6. Mai 2016, 15:42:05 CEST schrieb jeffjl@outlook.com: > I got version 4.7.2 to build on windows using emerge and mingw. > > I have trouble with version 4.7.90. It gets to linking kmymoney.exe and > gets > "multiple definition of payeeIdentifierLoader". The problem seems to be > that kmm_mymoney.dll already contains payeeIdentifierLoader but > kmymoney.exe links both the dll and the payeeIdentifierLoader itself. > If I > manually edit the > ...work\mingw4-RelWithDebInfo-gitHEAD\kmymoney\CMakeFiles\kmymoney.dir\link
RE: Can't build gitHEAD version on windows
Hi Christian, I just tried "emerge --cleanbuild kmymoney" which removed everything under ...\build\extragear\kmymoney-4.6.1-20110918\work\mingw4-RelWithDebInfo-gitHEAD" followed by "emerge --update kmymoney". Which seems to recompile everything. Still breaks at linking kmymoney.exe due to multiple payeeIdentifierLoader. Sorry about the "gitHEAD" nomenclature. That's what the emerge python script uses. It just did a git today from the master branch. In fact, I've been trying this (new git) every month or so since about August 2015. As I recall, it has always had this linking problem. (In the mean time I've just been using the 4.7.2 branch because it builds.) I've always assumed it was a Windows thing, and that it would eventually get fixed with the next release (when you tried to build the Windows version). I just recently chased down what's wrong and decided to ask if it was an easy fix. Thanks, Jeff. > From: christian-da...@web.de > To: kmymoney-devel@kde.org > Subject: Re: Can't build gitHEAD version on windows > Date: Fri, 6 May 2016 20:59:55 +0200 > > Hi Jeff, > > did you use a "make clean" or even better removed the build folder and rerun > cmake? My gcc on Linux has no problems building it at all. > > payeeIdentifierLoader is automatically added to kmymoney.exe because it is > marked "LINK_PUBLIC" in target_link_libraries of kmm_mymoney. This is not > good > (I did it as a work around). If this really needs to be corrected, the > library > has to be build as part of kmm_mymoney with correct export attributes (which > is some work, so I hope the clean will solve the issue :/) > > Greetings > Christian > > P.S.: I assume you are using the branch master. HEAD and 4.7.90 do not > include > too much info. Especially as "HEAD" is a local ref and can stay the same > forever if you never pull. > > Am Freitag, 6. Mai 2016, 15:42:05 CEST schrieb jeffjl@outlook.com: > > I got version 4.7.2 to build on windows using emerge and mingw. > > > > I have trouble with version 4.7.90. It gets to linking kmymoney.exe and gets > > "multiple definition of payeeIdentifierLoader". The problem seems to be > > that kmm_mymoney.dll already contains payeeIdentifierLoader but > > kmymoney.exe links both the dll and the payeeIdentifierLoader itself. If I > > manually edit the > > ...work\mingw4-RelWithDebInfo-gitHEAD\kmymoney\CMakeFiles\kmymoney.dir\link > > .txt and remove "..\bin\libkmm_payeeidentifier_loader.a", it links OK. I > > cannot figure out how to fix the make files such that > > libkmm_payeeidentifier_loader.a is not added to the link.txt file. > > > > This same problem occurs linking in some of the test programs (the first one > > being mymoneyfiletest), but I can work around that by not building the test > > programs. > > > > How does libkmm_payeeidentifier_loader.a get added to the link.txt file? > > What do I change to get it to stop doing that? > > > > Thanks. > > Jeff > >
Can't build gitHEAD version on windows
I got version 4.7.2 to build on windows using emerge and mingw. I have trouble with version 4.7.90. It gets to linking kmymoney.exe and gets "multiple definition of payeeIdentifierLoader". The problem seems to be that kmm_mymoney.dll already contains payeeIdentifierLoader but kmymoney.exe links both the dll and the payeeIdentifierLoader itself. If I manually edit the ...work\mingw4-RelWithDebInfo-gitHEAD\kmymoney\CMakeFiles\kmymoney.dir\link.txt and remove "..\bin\libkmm_payeeidentifier_loader.a", it links OK. I cannot figure out how to fix the make files such that libkmm_payeeidentifier_loader.a is not added to the link.txt file. This same problem occurs linking in some of the test programs (the first one being mymoneyfiletest), but I can work around that by not building the test programs. How does libkmm_payeeidentifier_loader.a get added to the link.txt file? What do I change to get it to stop doing that? Thanks. Jeff
Re: [Kmymoney-devel] libOFX question (relates to recent OFX failures with Chase credit card downloads)
From: t...@net-bembel.de > Valid point: How about a checkbox in the very same dialog that enables the > edit widget and the CLIENTUID processing? This way, the user has full control. I actually used a checkbox on the "first draft" of my fix. Then decided it was redundant since an empty / not-empty edit box meant the same thing (and I would only need to store one new thing for the account, the string; instead of 2, the string and the checkbox state). But a checkbox may be more obvious to the user. My other thought on the string itself: per a document I found (I think from Intuit, I don't recall), Quicken, using an irreversible "secure algorithm", combines a 128 bit random number associated with the data file, the USERID, and the Branding Identifier (BID) of the FI to generate the CLIENTUID. Using the same exact string (the file ID) for different institutions would be a little less secure. Jeff ___ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
Re: [Kmymoney-devel] libOFX question (relates to recent OFX failures with Chase credit card downloads)
Hi Thomas, >> Just changed time.tm_isdst as follows: > Maybe this is only needed for Windows. Have not checked under Linux. The only reason I noticed the problem is that "daylight" variable was still '1' after DST had expired and my credit card company sets the statement date (possibly violating the OFX spec) such that libofx sees it as uncorrected midnight. So libofx was subtracting an hour from midnight, thereby making the statement look like it was for 11 PM on the previous day, and my balances wouldn't match. > When loading the edit field in the dialog from m_fiSettings, and this value is > empty/not present, then preset it This is why I was thinking a more complete solution than I currently have would be a button on the OFX Details page to fill the edit box with a "generated" string only at the user's request, because I'm not sure what happens if you send a to a server that doesn't expect (or require) it. So I made libofx not send it if its length was zero (corresponding to an empty edit box), which is also good for backwards compatibility. Jeff ___ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
Re: [Kmymoney-devel] libOFX question (relates to recent OFX failures with Chase credit card downloads)
> against which version of libOFX did you apply the patch?
"http://downloads.sourceforge.net/project/libofx/libofx/0.9.10/libofx-0.9.10.tar.gz";
Just changed time.tm_isdst as follows:
--- libofx-0.9.10.orig\lib\ofx_utilities.cpp 2015-11-07 10:06:17.446846600 -0600
+++ libofx-0.9.10\lib\ofx_utilities.cpp 2015-11-07 16:58:40.645096200 -0600
@@ -116,7 +116,7 @@
string ofxdate_whole;
time_t temptime;
- time.tm_isdst = daylight; // initialize dst setting
+ time.tm_isdst = -1; //mktime will figure out daylight savings based on locale
std::time(&temptime);
local_offset = difftime(mktime(localtime(&temptime)),
mktime(gmtime(&temptime))) + (3600 * daylight);
I am building on Windows 8.1 with mingw, gcc version 4.8.2. The handling of
tm_isdst by mktime apparently has a checkered past, so I only know that this
fixed my problem on Windows when DST was not in effect.
While I'm at it, here's the change:
--- libofx-0.9.10.orig\lib\ofx_request.cpp 2015-11-29 11:30:54.119081400 -0600
+++ libofx-0.9.10\lib\ofx_request.cpp 2015-11-29 11:28:46.128634400 -0600
@@ -103,6 +103,9 @@
else
sonrqTag.Add( "APPVER", "1400");
+ if ( strlen(m_login.clientuid) > 0 )
+sonrqTag.Add( "CLIENTUID", m_login.clientuid);
+
OfxAggregate signonmsgTag("SIGNONMSGSRQV1");
signonmsgTag.Add( sonrqTag );
where m_login.clientuid needs to be added to libofx.h. My libofx.h currently
has a bunch of other changes so my patch line numbers won't match, but the
changes there are:
@@ -90,6 +90,7 @@
#define OFX_APPID_LENGTH (32)
#define OFX_APPVER_LENGTH (32)
#define OFX_HEADERVERSION_LENGTH (32)
+#define OFX_CLIENTUID_LENGTH (36 + 1)
@@ -811,6 +937,7 @@
char header_version[OFX_HEADERVERSION_LENGTH];
char appid[OFX_APPID_LENGTH];
char appver[OFX_APPVER_LENGTH];
+char clientuid[OFX_CLIENTUID_LENGTH];
};
Then I have KMM set the OfxFiLogin.clientuid. Snippet (not a diff) from
mymoneyofxconnector.cpp:
void MyMoneyOfxConnector::initRequest(OfxFiLogin* fi) const
{
memset(fi, 0, sizeof(OfxFiLogin));
strncpy(fi->fid, fiid().toLatin1(), OFX_FID_LENGTH - 1);
strncpy(fi->org, fiorg().toLatin1(), OFX_ORG_LENGTH - 1);
strncpy(fi->clientuid, clientUid().toLatin1(), OFX_CLIENTUID_LENGTH - 1);
strncpy(fi->userid, username().toLatin1(), OFX_USERID_LENGTH - 1);
strncpy(fi->userpass, password().toLatin1(), OFX_USERPASS_LENGTH - 1);
where the clientUid comes from the new edit box I added in the OFX Details
dialog and stored as m_fiSettings.value("clientUid");
___
KMyMoney-devel mailing list
KMyMoney-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmymoney-devel
Re: [Kmymoney-devel] libOFX question (relates to recent OFX failures with Chase credit card downloads)
The only place I found that the server tells the client that is required is in the account profile response (I can see it in a Quicken ofx log file). Ideally, the client (KMM) would request a profile of the account, see that is required, and from then on include it in sign on messages. libofx does not support account profiles. So you "just have to know" whether to use the for any particular account. I have not tried sending a to a server that does not require it. I have successfully used header 102 and 103 with the , though I did see the same note about 103 being required. KMM supports both, so that's not a problem. > Date: Thu, 10 Dec 2015 10:49:27 -0500 > From: ostrof...@users.sourceforge.net > To: kmymoney-devel@kde.org > Subject: Re: [Kmymoney-devel] libOFX question (relates to recent OFX failures > with Chase credit card downloads) > > I only see an error in that, not a request for anything. My best > current understanding is that Chase does not explicitly request > but expects it to be included in the client's request. > Also, a minor note, but you need to use version 103 instead of 102. > Apparently CLIENTUID is not included in 102, and allowed (but not > required) in 103. > > It appears to me (unless there is part of the OFX handshake not put > into the log file) that Chase is not explicitly requesting the > CLIENTUID, but if it is not present, then it simply fails to generate > the message to the secure message center, but doesn't actually realize > anything has gone wrong. > > Thomas - am I correct that KMM 4.x can only use aqbanking < 5.0? If > so, I can't test it, since 5.0.25 is the lowest version still available > in Gentoo. (I suppose I could compile from source, but prefer not to > for now.) I do have 5.0.25 installed, but I can't figure out how to > configure it, and it also doesn't look like the cli will allow me to > test this particular issue. I suppose I might have to install one of > the other finance tools (skrooge or gnucash?) to see if they will use > the new aqbanking, including the CLIENTUID. > > Jack > > On 2015.12.10 09:43, Michael Wolfe wrote: > > I just saw a request for the OFX data that Chase sends; here is a > > copy of the response I got from Chase after trying (and failing) to > > download OFX data: > > > > response: > > OFXHEADER:100 > > DATA:OFXSGML > > VERSION:102 > > SECURITY:NONE > > ENCODING:USASCII > > CHARSET:1252 > > COMPRESSION:NONE > > OLDFILEUID:NONE > > NEWFILEUID:20151210083844.000 > > > > 15510ERRORPlease > > > > verify your identity within the next 7 days. Using your desktop > > computer, go to your bankӳ website and visit the Secure Message > > Center for > > instructions.20151210093848.702[-5:EST]ENGB11089820151210083844.00015500ERROR1 > > Completed > > > > Grabbed from the 'ofxlog.txt' file. > > > > -Mike > > > > > > On 12/10/2015 8:20 AM, Michael Wolfe wrote: > >> As a side note, I am also having this problem; I wasn't aware that > >> there was something Chase was expecting KMyMoney to send back. > >> > >> If anyone needs testing for a fix with Chase Bank, I'm available to > >> do so if there's a testing version available for Windows (or > >> alternatively some handholding with a code patch so I can build it > >> myself!). > >> > >> -Mike Wolfe > >> wolfe...@gmail.com > >> > >> On 12/10/2015 4:53 AM, Thomas Baumgart wrote: > >>> Hi, > >>> > >>> On Wednesday 09 December 2015 19:38:08 Jack wrote: > >>> > Some of you may have seen some other posts I've made about this, > but I > think I've tracked down the problem. > >>> Thanks for the information. That helped a lot to identify what's > >>> going on. > >>> > Background: last month Chase credit cards made a "security > enhancement" > change that has made all OFX downloads since 11/17 fail. The error > message says to got to the Chase secure message center for info on > how > to verify your identity, but no such message ever appears. The > section > at > http://wiki.gnucash.org/wiki/Setting_up_OFXDirectConnect_in_GnuCash_2#Chase_ > .22username_or_password_are_incorrect.22 indicates the need for > using a UID > (user id) within the OFX request. It looks like they associate > that user > UID with the account, probably to limit access. However, the > first time > they see a UID on an OFX request, they should generate a PIN and > send it to > your account at their Secure Message Center. You then use that > PIN on > another page the message links to. I suppose since KMM isn't > sending the > UID, they don't generate that message. > > So - I don't see any place in KMM for a user UID. In fact, looking > into the libOFX source, I see the UUID type defined, but no element > defined as that type which looks like a user id. Can someone > con
Re: [Kmymoney-devel] libOFX question (relates to recent OFX failures with Chase credit card downloads)
I have a fix for this that I've been using for my Chase bank accounts since shortly after they made their change (but I do not have a credit card account at Chase). It's a pretty simple change to libofx to support , and I added an edit box on the "OFX Details" tab of the "Online Settings" tab of the "Edit Account" dialog so KMM could support it - I made a new account ".value()" for it. (Aqbanking also provides an edit box for this purpose.) The itself is still a bit of a mystery to me. For my Chase accounts, I used the 32 character hex string that Quicken uses, so KMM and Quicken are using the same string. That seems to work. I think if you don't "know" what to use for , you can just come up with a random string of up to 36 characters. But I'm not 100% sure whether the client (KMM) or the bank (Chase) comes up with the string. I thought about adding a button to KMM to generate a hash of the file name and account name, which is, I think, what Quicken does. But from what I've read, your bank / broker probably limits the number of different you can have, so you don't want to be changing it a lot. Though I've read that people can call the bank and ask for more and / or reset the "counter", if you can manage to talk to the knowledgeable person at the bank. The Chase change came up while I was making a bunch of other changes to libofx to support options (puts & calls), cash balance in investment accounts, and investment positions (how many shares your broker thinks you have) (for which I made a new callback from libofx). So this simple fix is buried in a larger change. I'm fairly comfortable that those changes are working, but I'd still consider them a work-in-progress. Oh, and I changed the daylight saving flag in libofx. It stopped working when my area went off DST (my credit card statement stared looking like it was for the previous day). My change now makes it work while we are off DST, but it is untested for when we go back on DST. The change lets mktime() determine whether DST is in effect. I could post the whole libofx change if people are interested. Or I could work on splitting out just the change. I don't think the larger change would break anything in KMM, but I haven't tested that either. And I have not worked on the "ofc" parser, I've only been changing the "ofx" parser, since that's the one I use and can test. To: t...@net-bembel.de; kmymoney-devel@kde.org From: wolfe...@gmail.com Date: Thu, 10 Dec 2015 08:43:26 -0600 Subject: Re: [Kmymoney-devel] libOFX question (relates to recent OFX failures with Chase credit card downloads) I just saw a request for the OFX data that Chase sends; here is a copy of the response I got from Chase after trying (and failing) to download OFX data: response: OFXHEADER:100 DATA:OFXSGML VERSION:102 SECURITY:NONE ENCODING:USASCII CHARSET:1252 COMPRESSION:NONE OLDFILEUID:NONE NEWFILEUID:20151210083844.000 15510ERRORPlease verify your identity within the next 7 days. Using your desktop computer, go to your bankӳ website and visit the Secure Message Center for instructions.20151210093848.702[-5:EST]ENGB11089820151210083844.00015500ERROR1 Completed Grabbed from the 'ofxlog.txt' file. -Mike On 12/10/2015 8:20 AM, Michael Wolfe wrote: As a side note, I am also having this problem; I wasn't aware that there was something Chase was expecting KMyMoney to send back. If anyone needs testing for a fix with Chase Bank, I'm available to do so if there's a testing version available for Windows (or alternatively some handholding with a code patch so I can build it myself!). -Mike Wolfe wolfe...@gmail.com On 12/10/2015 4:53 AM, Thomas Baumgart wrote: Hi, On Wednesday 09 December 2015 19:38:08 Jack wrote: Some of you may have seen some other posts I've made about this, but I think I've tracked down the problem. Thanks for the information. That helped a lot to identify what's going on. Background: last month Chase credit cards made a "security enhancement" change that has made all OFX downloads since 11/17 fail. The error message says to got to the Chase secure message center for info on how to verify your identity, but no such message ever appears. The section at http://wiki.gnucash.org/wiki/Setting_up_OFXDirectConnect_in_GnuCash_2#Chase_ .22username_or_password_are_incorrect.22 indicates the need for using a UID (user id) within the OFX request. It looks like they associate that user UID with the account, probably to limit access. However, the first time they see a UID on an OFX request, they should generate a PIN and send i
Re: [Kmymoney-devel] find transaction using T number
> On 09/11/15 06:54, Thomas Baumgart wrote: > > Hi, > > > > On Monday 09 November 2015 00:28:08 jeffjl@outlook.com wrote: > > > >> I'm looking for a way to find the consistency check problem transactions > >> using the T000... number reported. > >> > >> When I googled this, I found something that said use the Edit/Find > >> transaction dialog. I can't see how that does it. And in looking through > >> the MyMoneyTransactionFilter::match() function there is nothing that looks > >> at the transaction.id(). > >> > >> I am using KMM 4.7.2. > > > > AFAIR, the search feature is only available in the git master version which > > might not be available as binary package for your environment. The Find > > transaction dialog is not the right place to drop the transaction ID: use > > the > > search bar above the ledger instead. > > > > Hi Thomas > > I tried this yesterday, without success. > > Allan > Using the ledger, wouldn't you have to know the correct account? Or try the search in each account ledger until you find it? > > > > > If that does not work, your version is a bit too old, but you could use a > > text > > editor and take a look at the .kmy file. After all, it's just a gzipped XML > > file. There you can search for the ID to get some more information about the > > transaction. > > Here's what I did, for a short term hack. I modified MyMoneyTransactionFilter::match() to look at the "number from" and "number to" fields and if they start with 'T' and are 19 characters long, compare them to the transaction.id() instead of the split.number(). I was then able to find my consistency check problems using Edit/Find transaction. I did this based on KMM 4.7.2 sources because I could not get the git master version to build on Windows last time I tried it (about a couple months ago). Jeff ___ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
[Kmymoney-devel] find transaction using T number
I'm looking for a way to find the consistency check problem transactions using the T000... number reported. When I googled this, I found something that said use the Edit/Find transaction dialog. I can't see how that does it. And in looking through the MyMoneyTransactionFilter::match() function there is nothing that looks at the transaction.id(). I am using KMM 4.7.2. Am I missing something or is this capability not provided? Thanks, Jeff. ___ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
Re: [Kmymoney-devel] Review Request 124957: Bug 351874 - QIF import of investment buys and sells mishandles commissions
> On 31 Aug 2015 12:40:37 +0100, agande...@gmail.com wrote: > If I am understanding you correctly, this may well be to maintain > compatibility with the QIF 'standard', where there no negative signs, I > believe, both buy and sell have positive amounts. My QIF file (from Quicken) has positive amounts for both buys and sells. But, there is a case where a sell can have a negative number in the QIF file. If the commission is greater than the price*shares, i.e. the stock was almostworthless when sold and the sale did not cover the commission, the total amount in the QIF file is negative. This is not a common occurrence. But I didn't notice that case until now and my last patch does not handle it properly. I don't think there is an equivalent case on the buy transaction where thetotal amount could be negative. I need to look at the fix again. Jeff. ___ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
[Kmymoney-devel] Import of QIF investment transactions that have commissions
I am using KMM 4.7.2. I export my data from Quicken 2013 to a QIF file. When KMM imports a QIF investment buy or sell transaction that includes a commission, the total for the transaction has the commission added 3 times, so the total amount is wrong, and the warning triangle is added to the record in the ledger view. I have debugged this and come up with fixes. But I'm surprised (and concerned about the impact of my changes) that this has not been brought up as an issue before. The changes that make the import work and remove the warning in the ledger are summarized below: 1. The "T" line in the QIF buy/sell record is the total including commissions. MyMoneyQifReader::processInvestmentTransactionEntry() puts the total from the "T" line in tr.m_amount. It also puts the commission in tr.m_fees, so they are included in the transaction. I changed it so that tr.m_amount is the amount without the commission. 2. The original MyMoneyStatementReader::processTransactionEntry() adds the transaction amount and the transaction fee and puts the result in the split s1.value. In the original code, since the amount already includes the commission, this is the 2nd addition of the commission. Since the fee is going to be split out separately, I changed this to not add the fee to s1.value, and from change #1, s1.value now has no commission in it. 3. Since the QIF reader did not put the price per share in the transaction (even though it is available), the statement reader calculates a price per share. But it adds the commission to the transaction amount (which originally already included the commission) before dividing by the number of shares. This effectively adds the commission for the 3rd time. I changed it to not add the commission when calculating the price per share, and due to change #1 use the amount that does not include any commission. (This results in calculating the price per share that is in the QIF file but is not used.) 4. Finally, to get rid of the warning triangle, I had to change the amount that gets split to the investment account's associated checking account. I had to add the commission to "transfervalue". This actually puts "transfervalue" back to the number it would have had in the original code since the transaction amount originally included the commission. With these changes, I can import my QIF and the buy/sell transactions in both ledgers (investment and associated checking) have the correct numbers and no warning triangles. Comments? Thanks, Jeff. ___ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
Re: [Kmymoney-devel] Startup is slow
> On Sat, 22 Aug 2015 00:38:06 -0300, asolive...@kde.org wrote > Hello Jeff, > Could you provide a version of that file in anonymous format (Save As -> > Anonymous file), so that we could run some tests and find a possible > fix? > > There's a cache for balances, so it shouldn't call transactionList > twice, thus I'm very interested to know why this happens in this case. > I don't think a balance cache would help because KMM is determining, at QIF import for the first time, the balance on each of thousands of stocks. That's thousands of individual balances it has to calculate. And for each balance it has to search through even more thousands of transactions looking for buys/sells of that particular stock to figure the balance for that particular stock. (But I don't think the search is the time consumer. The slow part is that date filter that comes up with the transactions to search. And it does that once per stock.) Once it has done that, a balance cache would help. At least, that's my understanding of what it is doing. Is the balance cache is saved in the file? It might be that KMM starts up faster once I save the file after doing the QIF import. I can't remember. I think it is still slow. Since I'm having issues with data integrity through the QIF import, I don't often save the file. If I misunderstand and you still need my file, I can do that. It would take me (actually KMM) a while to make it, and it will be quite big. I'm not working with the full file right now. But even this subset file is a little slow. Maybe it would work for your test. And I could make it quickly. But if it's the QIF import making the stocks and transactions "new" that's important, the KMM file won't help either. Let me know what I can do to help. Thanks,Jeff. > > > On 2015-08-20 12:10, jeffjl@outlook.com wrote: > > Since I first wrote of this problem, I have changed my baseline. I am > > now using emerge version 4.12, mingw, gdb, eclipse (for debug), and > > KMM version 4.7.2, still on Windows. (I may not have done that right. > > I couldn't figure out how to get the current version of emerge to > > fetch KMM version 4.7.2 and the appropriate Qt/KDE/mingw, so I used an > > old version of emerge.) > > > >> > at startup, KMyMoney spends literally minutes > >> > in the KHomeView::investmentBalance() function. > > > > I have further narrowed this down to the > > MyMoneySeqAccessMgr::calculateBalance function calling the > > transactionList(list,filter) function. It spends about 2 seconds in > > each call of transactionList(), and it calls it many thousands of > > times. > > > > Just to verify that the root problem is that all my historical trades > > look "open" to KMM, I added some code to KHomeView::investmentBalance > > to close the stock if its balance was zero. Then, when importing the > > QIF, KMM runs one time for about 20 minutes calculating balances and > > closing stocks before the home screen updates with balances. I can > > save that file and KMM performs reasonably with it from then on. > > > > I'm OK with patching my copy of KMM with that "close the stock" hack > > just to make my file usable and then removing the hack. I'm not sure > > what a real fix would be. It looked like maybe that transacionList() > > call was doing the same exact thing for every file->balance() call in > > the for loop in KHomeView::investmentBalance - just filtering by date. > > If that's true, filtering once per call to > > KHomeView::investmentBalance (outside the for loop) instead of once > > per stock (inside the for loop) would save enormous amounts of time on > > a file like mine (spending 2 seconds per account instead of 2 seconds > > per stock). > > > >> - "File/File information" showing details about your data. Can you > > post a > >> screenshot of that information here to let us know something about > > the number > >> of items in your file? > > > > I've actually moved on for now and I'm not using my entire Quicken > > database for debug, so I don't have that info handy. > > > > I'm currently just trying to get one investment account to import > > properly. It has short sells and cover shorts in it. Handling those > > looks like a pretty simple change to the QIF reader. But KMM does not > > handle trade commissions properly, at least with my QIF from Quicken > > 2013. And KMM is going to have to allow buying and selling a "stock" > > for a total cost of zero (i.e. an expired option). So that's where my > > focus is right now. > > > > But a fix to the slow filtering would be appreciated. > > > > > > ___ > > KMyMoney-devel mailing list > > KMyMoney-devel@kde.org > > https://mail.kde.org/mailman/listinfo/kmymoney-devel > ___ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
Re: [Kmymoney-devel] Startup is slow
Since I first wrote of this problem, I have changed my baseline. I am now using emerge version 4.12, mingw, gdb, eclipse (for debug), and KMM version 4.7.2, still on Windows. (I may not have done that right. I couldn't figure out how to get the current version of emerge to fetch KMM version 4.7.2 and the appropriate Qt/KDE/mingw, so I used an old version of emerge.) > > at startup, KMyMoney spends literally minutes > > in the KHomeView::investmentBalance() function. I have further narrowed this down to the MyMoneySeqAccessMgr::calculateBalance function calling the transactionList(list,filter) function. It spends about 2 seconds in each call of transactionList(), and it calls it many thousands of times. Just to verify that the root problem is that all my historical trades look "open" to KMM, I added some code to KHomeView::investmentBalance to close the stock if its balance was zero. Then, when importing the QIF, KMM runs one time for about 20 minutes calculating balances and closing stocks before the home screen updates with balances. I can save that file and KMM performs reasonably with it from then on. I'm OK with patching my copy of KMM with that "close the stock" hack just to make my file usable and then removing the hack. I'm not sure what a real fix would be. It looked like maybe that transacionList() call was doing the same exact thing for every file->balance() call in the for loop in KHomeView::investmentBalance - just filtering by date. If that's true, filtering once per call to KHomeView::investmentBalance (outside the for loop) instead of once per stock (inside the for loop) would save enormous amounts of time on a file like mine (spending 2 seconds per account instead of 2 seconds per stock). > - "File/File information" showing details about your data. Can you post a > screenshot of that information here to let us know something about the number > of items in your file? I've actually moved on for now and I'm not using my entire Quicken database for debug, so I don't have that info handy. I'm currently just trying to get one investment account to import properly. It has short sells and cover shorts in it. Handling those looks like a pretty simple change to the QIF reader. But KMM does not handle trade commissions properly, at least with my QIF from Quicken 2013. And KMM is going to have to allow buying and selling a "stock" for a total cost of zero (i.e. an expired option). So that's where my focus is right now. But a fix to the slow filtering would be appreciated. ___ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
[Kmymoney-devel] Startup is slow
Hi all, I am new to KMyMoney (and KDE). I'm thinking KMyMoney could be my replacement for Quicken (I'm getting more and more fed up with them). But I do have some issues. At the top of my list is that, at startup, KMyMoney spends literally minutes in the KHomeView::investmentBalance() function. I have imported my QIF from Quicken into KMyMoney and I have thousands of historical holdings for which my share balance is now zero (the vast majority of them are expired put and call options, which is going to lead to some more things on my issues list). I suspect it must be going through each one of those. I know it spends over a minute in that for() loop for each of several calls to the function (I have more than one brokerage account). I looked for an easy way to not waste time calculating a balance for a stock account when there are zero shares in the account, but I don't see it. But I am a long way from understanding all of the code. It checks for stock.IsClosed(), but since these came in from Quicken, the stock accounts are not closed. I am building on Windows with MSVC2013 via emerge. So debugging is pretty much limited to watching program flow. (I don't see "readable" variable values, for example.) Any thoughts or guidance? I am willing and able to change my copy of the code and try things. Thanks, Jeff. ___ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
