CSV/ASCII File Import and Case Insensitive Issue in Elliott 8.5
In Elliott 8.5, you can optionally convert your database to 8.5 format to support alphabetic document number. Of the conversion is Elliott now assume each field is case insensitive when search. While this improve the add-hoc search capability for Elliott database, but it may create a potential problem with CSV/ASCII File Import.
For example, if you enter a customer number "A100" as "a100". In Elliott's user interface, we will convert the lower case "a" to upper case "A" automatically. However, in the CSV/ASCII import, if the source data is "a100", when system validate "a100", the result will come back to be OK. So our system will think customer "a100" does exist and allow the import. This can create problem in various areas in Elliott application.
This issue was first discovered with Elliott sales order import utility which we add additional safety logic to convert lower case key fields import value to upper case, this include customer number, ship-to, salesman, ship-via code, terms code...etc. (Any fields that's a foreign key of another master table).
Recently, we discovered a customer that use GL csv import (in interface with other package). There is an account 2102-401K-EE some how has value of "2010-401k-EE" in the CSV file. Out utility think the lower case "k" is OK and allow to import to general journal and post. That create printing of Trial Balance issue.
So our conclusion is we need to add safety logic to all CSV/Import areas to convert key values (and only key values fields) to upper case. Attached is a list of Elliott programs that may need to be changed. They need to be checked out one by one to determine if the appropriate change is needed.
Program CPORDIMP.CBL is already fixed. Look for the following lines:
MOVE ASCHD-CUSTOMER-NO TO CASE-SENSITIVE-FIELD
PERFORM CONVERT-TO-UPPER-CASE
MOVE CASE-SENSITIVE-FIELD TO ASCHD-CUSTOMER-NO
We will apply the same principle to all needed programs.
In Elliott 8.6, the key fields are now case sensitive so this is no longer a issue if user convert 8.5 database to 8.6.