I am testing the import of bank statements (using a CSV file) with fields = DATE, DESCRIPTION, PAYEE, REFERENCE and AMOUNT. My date format is DD/MM/YY. Say I import a CSV file containing four transactions with dates of 01/01/17, 01/02/17, 01/03/17 and 01/04/17, Manager “thinks” that they are in MM/DD/YY format so the result are transactions dated 1 January 2017, 2 January 2017, 3 January 2017 and 4 January 2017 which is INCORRECT for my format of DD/MM/YY. I can “force” Manager to work correctly be inserting a single “dummy” entry that has the first two characters > 12 (e.g. 13/01/17). Obviously, in the MM/DD/YY format, 13/01/17 would be invalid. So, I assume that Manager “sees” the potential error and “assumes” the DD/MM/YY format. I CAN work around this “bug” in the manner described, but there should really be a more elegant way in which to specify that the import is in DD/MM/YY format. It would make sense that the import routine accessed the date format that is set in “Preferences” @lubos.
Can you export from your bank in any other format? CSV is the least reliable and should really only be used as a last resort. If so, does that correct the problem? (This is difficult to reproduce without a cooperative bank.)
Yes, I can basically use any format for “real” bank imports. However, I was using the functionality of CSV import as a way of importing ALL my historical transactions since the commencement of the financial year. I don’t really understand why the CSV import should be problematic, as it could easily be resolved by Manager “looking” at the date format in “Prefernces” to determine the format. The “instability” of CSV import is very surprising considering how Manager is such a fantastic product with very sophisticated cababilities @lubos … I would consider that a CSV import would be almost a trivial development exercise.