Client reported an odd situation where they would be doing a VI import and the GL account number in the import file would be changed to an entirely different account number for a number of different accounts upon import. If you used file explorer to look at the accounts in question, the accounts did not show up.
After hunting around under the hood, I discovered this situation.
GL account structure is xxxxx-xx-xx. (9 characters not counting the dashes)
A GL account key is also 9 characters.
Comparing the account keys I discovered that GL account 70200-00-01 has an account key of 67000001. There also happens to be a GL account 67000-00-01. Remove the dashes and it is a match to the account key for the other account. The import file has it formatted to 670000001. Apparently when you VI import it first tries to compare to the account key first. If it does not find that then it continues to look for the (visual) account. So in this case it find the account key of 67000001 and picks that and returns 70200-00-01.
Basically it is a coincidence that the account key and visual account match.
Now the trick is to try to fix the account key so it does not conflict (as well as identify all the accounts that conflict).
I tried creating a second GL account and merging the original account into it, then renumbering the new account. Seems logical. Unfortunately that did not change the underlying account key. Apparently the system remembered the original account key and restored it?
Client isn't going to go for changing the GL account structure to make it longer/shorter (I wouldn't either).
Does anyone know of any utility that might "renumber" the underlying account keys?
In the mean time I'm going to try having the client format the import file account number with dashes. Assuming that works for the import, it wouldn't fix other issues such as in explorer.
