Thanks Tut. Very interesting. Yes, QFX works fine.
I beg your pardon, @Brucanna, but you said precisely that, just two posts earlier:
My comment was not a red herring. As proven by @whosatās statement,
my diagnosis correctly identified the problem. The change introduced in version 18.1.66 improved the programās ability to determine dates from ambiguous inputs. But the fact is, no program on the market can always resolve such ambiguities in QIF files. That is a major reason the format has largely been abandoned, including by its creator, Quicken. It simply traces to an era where US standards were more common because other markets had not yet been thoroughly penetrated.
Manager cannot perform magic. Anyone importing QIF bank files will always need to check for date ambiguities and edit them manually, if wrong. On that basis, I have removed this topic from the bugs category.
1 Like
No, as the QIF file contains the correct date data. Manager a downstream processor of that QIF file does an incorrect interpretation, but only when a single date is being imported.
That is my exact experience with a multiple of banks. In fact with two of my international financial institutions they only provide the QIF option outside CSV, DAT & PDF regardless how justified others feel in offering their opinion about QIF redundancy.
Financial Institution 1 (being USA based)
Financial Institution 2 (being Europe Based)
@Tut, I just wish you would stick to the facts and not convert, mis interrupt and misconstrue comments to give yourself some unjustified self justification when others disagree with you.
Anyhow, I never realised that when a User has a factually illustrated problem with Manager, that a Moderator needs to do external research to establish if that Userās problem has validity or not. I thought the Moderatorās role was to bring a Userās proven problem to the attention of Developer for their determination. Not to make a personal judgement call on its validity.
Your decision to terminate the ābugā report both contradicts the history of this topic and establishes that you consider yourself to be of a higher standing than the Developer when it comes to deciding upon a Userās factually illustrated problem.
My point was not that the QIF file contains incorrect data. It does not. In @whosatās case, it contained ambiguous data that Manager (and other financial programs) cannot resolve due to shortcomings in the QIF standard.
I did not say the QIF format was redundant. I said it was antiquated, and it is. Its developer abandoned it years ago. It is available in Manager for imports because some banks do not provide more modern options, primarily because of licensing fees. For internal purposes, they do not need to, because they know how to interpret their own files. For external purposes, they have little incentive to care, because they are not the ones resolving the ambiguities. So why would they invest in changing their software?
Both your illustrations reinforce my point about inadequacy of the QIF standard, such as it is, last codified (sort of) in 1997. Your financial institutions are offering options with specified formats for month, day, and year. These are options implemented by the institutions on their own, not in compliance with the QIF standard. The standard does not require any defined date format, only inclusion of the date, preceded by the letter D. Order of elements, number of digits, use of leading zeroes, incorporation of textual or numerical months, and delimiters (or their absence) are left to the discretion of the programmer. Every file produced by one of your banksā options could, technically, be a compliant QIF file. Yet they would all differ from the others. Quickenās programmers simply did not look beyond the US market or its MM/DD/YY default format back in 1983 when all this started.
I am sticking to the facts, which seem a better basis for answering questions than opinions. When did understanding why a problem occurs become objectionable? The external research you apparently find offensive revealed why this is a problem outside Managerās control and why a problem previously improvedābut never totally eliminatedāseemed to recur. That is why I removed the topic from the bugs category. If you know a way to unambiguously establish a date in the first 12 days of a month from a single instance in an undefined, numerical format, please share it. Financial programmers around the world will be grateful. Better yet, patent it.
My research also identified why @whosat might continue to encounter the same problem in similar situations. That led me to suggest alternate file formats for imports to Manager, which turned out to work. Surely that is a role for moderators.
You folks seem to get very emotional about all this. I really have appreciated the dedication and effort that both of you have put into this forum over the years. Recently it seems to have become a slightly less amicable space. Please relax a little.
It appears to me that the ambiguity in the QIF file exists because the file doesnāt specify what date format it is using. Manager has to decide what to do about that ambiguity, and it appears that (when the format is ambiguous) Manager assumes that the QIF file is using a MM/DD/YY format. That might be reasonable if that is the format is used by most financial institutions when generating a QIF file. If many financial institutions actually export QIF files in a DD/MM/YY format, perhaps the developer could consider either:
- revising Managerās assumptions to assume the format is DD/MM/YY
- OR ask the user to select the date format before importing
- OR base the assumption on the date format selected in Manager preferences.
Whether it is a bug or not, I think there is potential for the software to better handle the ambiguity, rather than just resign to QIF files importing incorrectly. However, it is a very minor issue that has not caused any huge problems for me and I have a happy solution. So please donāt lose sleep over it!
All the best.
Agree.
I would describe it as an idea.
My preference would be to allow the user to specify (somewhere) and if a date is encountered inconsistent with the user selected format, report an error.
The same logic could be applied to
- csv
- Decimal separators ā.ā or ā,ā
Although for me personally it makes no difference as I can avoid both with my bank imports.
PS I agree the atmosphere does get more tense than ideal at times. Perhaps we should all put more emphases on describing a ābetterā solution rather than picking holes in someone elseās ideas.
I doubt resolution of date ambiguities in QIF files is entirely up to Managerās developer. I suspect at least part of the functionality comes from a library of software developed by others. Various parsing routines exist to attempt to resolve this problem. It is much easier when there are multiple dates and some inference can be drawn from context. The difficulty arises when only one ambiguous date is present. I donāt know precisely the algorithm Manager uses, but it is possible attempts to discern the format actually make things worse in some situations, especially when a bankās transaction order is irregular. It is important to understand the software is attempting to guess information that is literally not contained in the QIF file. Sometimes, it guesses wrongly.
The Guide about bank imports has always contained cautionary statements about imperfect imports and the need to verify and, if necessary, manually edit transactions. As a result of this discussion, it has been modified to draw more particular attention to potential date ambiguities, not only for month-day reversal, but also for identification of year. These challenges can exist with other formats, too, particularly when banks do not follow more modern standards well.
1 Like
We agree.
A solution is for the software to not try to guess at all and instead abide by a user specified format as @whosat suggested.
That is the solution adopted by most other programs with an international market such as spread sheets
I would suggest that a solution would be to add a field to the āBank Rulesā that enables the user to specify the date format of the import file for each bank.
The initial file import may be guesswork, but this could be adjusted after the first file import.
That may sound simple. But I suspect there would still be trouble, considering:
- Users will (rightly) believe they have already specified a date format. Setting additional preferences would require understanding (1) the format used by the bank, (2) how to override it, and (3) when the override applies.
- Exported formats may not match what users are seeing on their bankās screens, so there may be no way of easily determining the first parameter above from the bankās web site.
- Some users will not know how or wish to examine content of an export file, let alone edit it if necessary. And editing may be necessary if the bank uses some form of hybrid text/numerical date format or forgoes delimiters. Remember, there is no requirement that banks choose from among date formats supported by Manager.
- Few will be able to find, understand, or apply export standard documentation. So export files may seem like gibberish, even if the user is willing to examine them.
All these things can apply not only to QIF files, but others as well. This is why parsing algorithms exist. Managerās philosophy seems to be to relieve users of the burden of figuring it all out themselves to the extent possible.