Client would like a comprehensive user guideline developed or changes to make Data Import/Export easy and seamless

Client would like a comprehensive user guideline developed or changes to make Data Import/Export easy and seamless

Client says that instructions are very vague and the import is too sensitive to data changes/ data formatting for any ease of use. Please see comments from Client below.

Client Comments

- 1st and most important for a non-specialist end-user, File Naming Conventions. There are many documents on Knowledgebase which address the required structure of an

import file but none which give a simple set of rules for required filenames.

-I discovered by trial and error that Any filename including the word “template” is invisible on the Data Import screen even when located in the correct directory

(particularly frustrating as the online documentation encourages users to create a Document Type, Export it and then populate it for import. However,

because the application by default names the export file *.template, it is invisible.

-Hours of wasted time trying to spot a non-existent error in the Document Type setup)There appears to be a limit on the number of characters in a filename.

- I’m not sure what it is. This limit should be clearly stated somewhere. There are lots of references in knowledgebase articles to not leaving blank columns, blank fields etc. when

creating a Document Type. These are impossible to comply with. For example, any Document Type based on the “Source Documents” template has 13 mandatory fields

which cannot be edited out. Inevitably some users will leave many of these blank. As far as I can see these instructions are entirely pointless and confusing.

In the end, after many iterations, I left plenty of spaces and everything worked fine. When you create a new Document Type you cannot add or remove any fields

until you have saved it. It would have been good to know that in advance.

- I managed to work out the “Use Import Code Instead” tick on the Document Type setup. However, it’s very unclear in the online documentation.

It needs to be spelled out very clearly with 2 or 3 examples using different codes/ID's, The import files are ludicrously sensitive to formatting issues

-These days a simple Excel file should be readable by a modern accounting application without time-consuming tweaks to the format –particularly date formats.

-In similar vein, the application seems wedded to Excel’97 *.xls formats when the wider world is working with *.xlsx files. This just

looks like a failure to keep pace with MS Office and again end users will find this hard to understand. When the import file is finally visible on the Data Import

screen, if the import fails the error reporting on the Data Import Screen is very poor.

-VBAsic-style dialog boxes with no indication of which row/column is a problem are practically useless for non-specialist users.

-I spent hours trouble-shooting errors on the import file with no useful guidance. When the import finally succeeds

there is no progress bar/success message etc. It simply disappears from the screen. This is pretty disconcerting for a user who doesn’t know if the thing has worked

or not without checking the relevant application modules