Imported Bank Statements for a single date converts the dates

There appears to be an expansion on this issue. The issue can be reproduced by multiple transactions limited to activity on one day only ie. The import with transactions on one date only?

It appears that there is no date issue if imports include at least two different dates.

Can someone else confirm this issue please. Maybe the import process needs at least a second date to reference so that it can establish the difference between day and month?

OK latest version presents the same issue. This has come to light as we have an entity who import daily to keep abreast with banking activity.

As a workaround, if they also select the day prior as part of the import, then the day prior transactions will be ignored as they have already been imported.

The latest version (18.1.66) should be smarter about determining date format in this situation.

Tremendous - Fixed - Just tested OK, Thank you.

This is still happening in 10.12.22 desktop version. The dates are in a qif bank statement export file (sample below) in the format dd/mm/yy. Manager date format is set to dd-mm-yyyy, machine date format is dd/mm/yyyy

e.g.
D09/01/19
T-2240.00
PANZ INTERNET BANKING PAYMENT

Did you mean version 18.12.22? I assume so, because I don’t believe Manager dates back to version 10.

You just need to make dates match formats. Manager is going to interpret your dates as being in the year 19. You already said both your operating system and Manager are operating on 4-digit years.

Yes 18.12.22. The problem seems to be that the bank is supplying two digit years, date format dd/mm/yy. Does that mean I have to set my computer’s date format or Managers date format to the same to get the bank statement to import correctly or do I need to edit the bank statement file to have four digit years before importing? Dates import correctly once it becomes obvious which part is the day

I would edit the bank statement file, since that involves the fewest steps. And spreadsheet search/replace/format/edit options are plentiful.

This is still an issue.
When the QIF file date format is DD/MM/YY, Manager Date Format Preference is set to DD/MM/YY but import is only for one date, Manager converts date to MM/DD/YY.
I’m using version 20.5.2.
I suggest that this be considered a bug.

@whosat, what you describe is impossible. Manager does not have a MM/DD/YY format. It is possible dates are being misinterpreted, but not in the way you suggest, by being converted to a non-existent format.

You should illustrate your situation with screen shots.

Thanks Tut,
Here are some screen shots.
As you can see, the QIF file has the date 06/05/20, but after import, Manager has the date 05/06/20.
image
image

Your screen shots illustrate misinterpretation of the input data, not conversion to a non-existent format.

@whosat, it is clear from your screenshots that Manager has converted DD/MM/YY data into a MM/DD/YY format even though that format is non-existent under date preferences.

Manager, shouldn’t have this misinterpretation of input data, especially as this “bug” - reversing the DD/MM positions - was supposedly fixed in version 18.1.66.

Therefore this appears to a regression, so will relist it as a bug.

I do not believe this is true. I don’t believe it is technically possible for the program to use a non-existent format. As I wrote, I believe the screen shots indicate the program misinterpreted the input data. In that case, the program would not think the transaction shown occurred on May 6, 2020. It would think it occurred on June 5, 2020. The way to resolve this is for @whosat to look at the Summary page to determine whether there is a notice at the top about transactions dated after the end date set for the Summary.

Whether it is possible for Manager to resolve ambiguities like this depends not only on how the program parses the imported file, but also on how well the bank adheres to the QIF data standard.

No one has ever stated that the programme is using a non-existing format, except for your own introduced red herring. All the User did, was use the DD MM YY symbols to illustrate the change in data.

Note their comment “Manager converts date to MM/DD/YY”. Converts the data not the format.

Correct, and that “misinterpreted the input data” is what created this topic originally.

Yes it is - read post #5 “Tremendous - Fixed - Just tested OK”

Yes, but that was before what you yourself described as a regression bug.

Hi,
Yes the Summary page does include the notice: “There are 2 transactions dated after 23/05/20 therefore they are not accounted for in this view”.
It is true that the issue could be with the QIF file. I don’t know enough about them to know how to check. The screenshot of the QIF file I sent earlier was of the file opened in Windows Notepad.
I’ve been using Manager and importing QIF files from this bank for over four years and have not seen this issue before, but perhaps I’ve never imported transactions from only one date before.
Not a major problem, but thought it was worth noting here.
All the best.

Also. Sorry for any confusion. You are right, Manager is not changing the date format to MM/DD/YY, it is misreading the date format as MM/DD/YY and converting it to DD/MM/YY when no conversion is required.

Some further research reveals that correct date parsing of QIF imports by financial and accounting programs is a common problem, particularly when:

  • Transactions occur early in a month (days 1-12)
  • Only one or very few dates are involved (programs have more and less sophisticated algorithms for identifying date sequences)
  • Transactions are not listed chronologically in the imported file (the QIF standard does not require chronological order, since each transaction contains its own Date field)
  • The file has been opened by Excel—particularly older versions—during the import process (Excel has had changing protocols over the years that attempt to identify dates as conforming to the US standard MM/DD/YY or MM/DD/YYYY formats, without user intervention)

The problem originates with the lack of a definite date format in Quicken’s now-antiquated QIF specification. (Even Quicken eliminated support for QIF files in most of its products a dozen years ago in most regions of the world.) Thus, Manager is not unique in having this problem. Documentation of other financial programs includes strong cautions to manually review—and edit if necessary—dates from imported QIF files.

Personally, I don’t think this qualifies as a bug any more than would the inability to correctly identify a 2-digit year. @whosat, if your bank offers other formats, you might try them and see if you get better results. In my experience, both QFX and OFX are both better.