Общий подход такой:
Создаете структуру дерева своих данных:
https://www.lesis.ru/infot/teh_create.html
Формируете НСИ:
https://www.lesis.ru/infot/teh_nsi.html
Пока достаточно первого абзаца - подраздел "Создание НСИ". Прикурить НСИ можно из деморегиона.
Импортируете сами базы по "Правая кнопка на лесничестве - Импортировать - данные из ЛесГИС". В следующем каталоге указываете путь к файлу таксации в каталоге с базой ЛесГИС вида "Имя лесничества.DBF"
В нашей документации еще есть устаревшее описание импорта из ЛесГИС в версию 6.8.
Но импорт таксации по этой схеме делать уже НЕ НАДО!!! Вообще не устанавливайте ГИС TopoL-L 6.8 - учитывая отсутствие у Вас опыта работы с ней это сто процентная гарантия, что на современном компьютере Вы убьете активацию ключа защиты!
Мы пока оставили этот раздел для "задержавшихся в версии 6.8".
Из этого раздела помощи актуален только подраздел
Импорт картографических данных из MidMif (MapInfo)

Вбиваем эту фразу в поиске и находим:
http://lesis.mybb.ru/viewtopic.php?pid=95#p95
Пункт 4:
4. Импорт из версии 6.8
Проблема. В протоколе сообщение:
Ошибка при конвертации справочника "Имя справочника", конвертация не выполнена:
Объект 'Имя справочника' не найден ядром базы данных Microsoft Jet. Проверьте существование объекта и правильность имени и пути
Решение. Проблема в отсутствии или неправильном адресе ссылки на BDE.
Запустить наш REG-файл от 6.8, проверив в нем правильность ссылки:
"DLLPATH"="C:\\TOPOL\\L\\"
Только в данном случае речь не о версии 6.8, а о DBF файле, для чтения которого требуется BDE - часть Вашей операционной системы, отвечающая за работу с DBF.
У Вас в этом случае два пути:
1. Самостоятельно установить и прописать в параметрах системы путь к библиотекам BDE. Тут мы Вам ничего не подскажем так как давно не работаем с ними. Используется только для импорта всякого старья.
2. - Установить ГИС TopoL-L 6.8.
- Чтобы потом не иметь проблем с активацией ключа удалить в нем файлы:
d:\Topol\l\TopoL_L.exe
d:\Topol\l\TopoL_Lu.exe
d:\Topol\65\TOPOL_ba.exe
d:\Topol\65\TOPOL_di.exe
а заодно и ярлыки к ним.
- Запустить файл реестра:
d:\Topol\l\BorlReg.reg
проверив в нем правильность ссылки:
"DLLPATH"="C:\\TOPOL\\L\\"
и согласиться с внесением изменений.
Где d:\Topol\ - путь установки. Он может быть у Вас другим в части имени диска.
Не помню, нужна или нет перезагрузка...

Импорте ЧЕГО? Карты? Таксации?

Вбиваем эту фразу в поиске и находим:
http://lesis.mybb.ru/viewtopic.php?pid=95#p95, пункт 5:

Там речь про импорт из 6.8, но суть не меняется - отсутствие полей... их заполнение значением Null... несоответствие использование в качестве их имен служебных слов... несоответствие типов данных приемника и источника... Я думаю, что это относится не только к структурам полей "принимающей" БД, но и у источника.
Сравните структуру полей деморегиона и Вашей БД. Убедитесь, что нет ситуации "старая версия программы + новая структура БД".

Это говорит о том, что проблему нужно искать именно в базах ЛесГИС, которые не прошли импорт. Они чем то отличаются от тех, что прошли? Может размер? Странности содержимого?

Ну это не много. Иногда можно даже беглой прокруткой увидеть что то странное. Потом сравнить структуры одной БД, которая прошла проверку и той, что не прошла. Если одинаковые, то попробовать использовать метод половинок:
http://lesis.mybb.ru/viewtopic.php?id=257#p2288
В данном случае нужно открывать DBF, например, в стареньком DBF Navigator-е (Алексея Долгачева, 2002г, он, по-моему, хорош тем, что ничего не преобразует в исходном DBF)  и удалять половину. Оставшуюся импортировать. Если ошибка проявилась - повторяем прием, если нет - то анализируем предыдущую удаленную половину. Если в обеих проявилось - продолжаем с любой из них. И так пока не останется один выдел, который ТОЧНО не проходит импорт. В зависимости от размера БД за 10 - 30 минут найти такой можно. И с ним разбираемся досконально по каждому полю. Тут важен принцип - нашел в одном выделе, значит, нашел во всех данных.
Возможно, Д.А. сможет в режиме отладки найти такое место - пришли набор данных на одно лесничество.

Обрати внимание в каком формате сохранял и в каком формате у тебя "хорошие" DBF и "плохие". Возможно, для каких то данных имеет значение какой из форматов использован. Если память не изменяет в тот период, когда использовали 6-6.8 их было три - dbase III, dbase III+, dbase IV. Шестерка использовала IV. Но у меня загрузился и файл III и файл IV. В III+ у меня нет опции сохранять, не проверил. Может у тебя был он.

Редакторы DBF, видимо, для возможности отката, при удалении записи обычно сохраняют ее, помечая как удаленная (приглушает... ставит галочку или крестик...). Запись при этом перестает участвовать в запросах. Физическое удаление осуществляется функцией "Сжать". Поищи ее в подменю "Файл" или "Правка".

Не уверен в синтаксисе данного сообщения, но модулю импорта для вставки в целочисленное поле подставляется не целочисленное значение. Учитывая, что у тебя под видом 'B' идет кириллическая буква то скорее всего это значение и надо искать в полях базы (может быть В - вяз? В полях с породой вместо 202500). Пустое поле или запись обычно идет как '' is not a valid integer value.

Нет, 100100 - это как раз правильно. Ошибка возникнет как раз если в поле пород будет сидеть "С". Если такого нет, то все нормально.

Я с DBF уже лет 10 не контактирую. Практиковал когда то еще DbfShow (http://jobtools.ru/dbfshow/), он хотя бы этот заголовок показывает, но сейчас открыл один образец, а там заголовок перечисляет все кроме 3-ки без плюса - "FoxPro, FoxBASE+, dBASE III PLUS, dBASE IV (без memo)". Видимо они не отличались.
Да и вряд ли, все же версия влияет. Файл DBF, по сути, текстовый. Там бинарные скорее всего "префикс" и "суфикс" файла. И я думаю, что наш модуль скорее всего вообще в заголовок не лезет, а берет само тело БД.
"Половинь" до одного выдела. Проще будет понять.

Значит у них в БД сидят буквенные значения пород, а мы их перекодируем в классификационные коды как этого требует система обработки ЛУ информации (СОЛИ, но не как прога, а как система алгоритмов). Разумное предположение может быть только одно - если у них этот формат служит и для таксационных баз и для файлов ввода, где буквенные коды возможны. В противном случае... если это не ивест, а рабочая база... то я лучше промолчу... )))
В любом случае, если в БД буквы - я бы проверил справочник пород при базе-приемнике - для всех ли пород есть перекодировка. Я не знаю как поведет себя модуль в этом случае - возможно, попытается сунуть букву и в этом случае понятно, что за "is not a valid integer value". В общем:

и потом проверять наличие его в справочнике пород (ну или мало ли в каком еще поле у них буквы окажутся).

Сергей, переведи пожалуйста:

'В' - это что, первая буква названия региона? Она стояла где, в базе? Или в НСИ? Или в ЛесГИСе? Где конкретно?

Где именно? У тебя что, регион в имени нашего файла F001R###L###U###_Vyd.mdb не соответствовал каталогу региона d:\LesIS\####\R###? Или в данных ЛесГИС?  Каких именно?
Я импортировал данные ЛесГИС в демо региона 099 и лесничество того же региона 099, все прошло. А регион ЛесГИСа мне неизвестен и я не выяснял - точно не 099.

Нужно искать разницу в базах ЛесГИС прошедших импорт и не прошедших. И регион - лесничество в нашей системе должны соответствовать друг другу и НСИ.
У меня два свежих образца от пользователей, в обоих в НСИ в породах сидят символы (С, Б...). Через импорт они проходят:

В базу попадают 100100, в интерфейсе - соответственно выбранному режиму показа.
Чтобы твои сообщения были понятны и принесли пользу другим пользователям от тебя нужен анализ - что именно не так и где конкретно. Как мы Вам  всегда поясняем.

Подсказываем насколько сами помним. )
Продолжу это делать, т.к. возможно, у тебя там еще какая то ошибка с 'В' есть:

Сергей, в DBF нет поля 'B'. Просто на картинке у тебя DBF открыт в Excel - 'B' это имя графы таблицы в нем. Поэтому "LesIS" не может на него жаловаться, т.к. не видит. А в DBF это поле sri (взято "разработчиками" из литовского комплекса соли). Тем более, что в сообщении импорта буква русская (в экселе - английская). Это легко проверить поместив это сообщение в notepad++ и поменяв кодировку на UTF-8, например. Ты увидишь там вместо 'B' вот это:

'xC2' is not a valid integer value.

Так что сообщение про 'B' относилось к чему то еще. Поищи, т.к. можешь не заметить и ошибка останется. Но если после замены региона все прошло нормально, то может и ушло из-за приведения в соответствие справочника. Смотри сам, на месте виднее.

Странно, а у меня две базы от клиентов были с символами. Возможно, "твои" уже кто то перевел в коды зачем то. Или у них как писал выше одно поле для двух вариантов используется. А в структуру не заглядывал? У них 100100 стоит как число или как символ? Если символ, то возможен этот самый двухвариантный подход.

К сожалению, не получится, т.к. что то подобное для базы - "источника" нужно. У нас то структура стандартная, а там гуляет. И ты через шаблон структуры коды в символы не преобразуешь на лету. Можно было лишь сделать анализ данных и переключение на прием кодов без перекодировки по справочнику. Но тогда таких баз у нас не было.

Не понял вопроса, переведи.

Не факт.

Я начинаю догадываться почему. )

Не планируем. Наши форматы открыты и хорошо описаны. Есть экспорт в СОЛИ и Xml для обмена. При передаче данных между системами это задача принимающей стороны. Пусть трудятся, им на это денег достаточно дали. )

Я не сомневался в тебе! )

Да.

Рядом с файлом конфигурации LOGSTR.DAT. Например, я, поскольку с СОЛями не работаю лет 20-ть, держу весь импорт - экспорт так:
d:\LesIS\ImpExp\l\99\s\LOGSTR.DAT - файл конфигурации таксационной базы
d:\LesIS\ImpExp\l\99\s\*.### - базы
d:\LesIS\ImpExp\l\99\n\LOGSTR.DAT - файл конфигурации НСИ.
d:\LesIS\ImpExp\l\99\n\*.000 - файлы НСИ.
Во второй строке файла конфигурации таксационной базы должен быть прописан путь к базе НСИ:
000   (d:\LesIS\I_ImpExp\99\n)*, где 000 - нулевая степень сжатия (если память не изменяет), т.к. бинарные файлы СОЛИ мы не импортируем.

Теперь понятен твой вопрос:

Ответ в нашей системе, где разнообразие систем ТЛУ мы перевели в числовые значения, причем, формируемые автоматически при заполнения  справочника и не изменяемые вручную. Не готов сейчас прочитать лекцию по алгоритму, надо вспоминать, но он простой - А1=11, А2=12...В3=23, В4=24.... и т.д. и т.п. Для текстовых ТЛУ типа ТР свой алгоритм, но сейчас с ходу не смогу сказать, да и не важно это - ввод можно осуществлять только текстом, а кодировка идет автоматом примерно как автоинкремент. Отличные от А0-Д5 ТЛУ система распознает как наборы двузначных кодов на каждую букву. Объединять в один справочник эти две системы не получится, т.к. будут пересечения, да и смысла нет - они не применимы в регионах, где используется другая система ТЛУ.
Кодирование числовое выбрано для аналитики - система по Погребняку позволяет легко строить логические выражения не только по влажности, но и по плодородию. А альтернативной системе сложнее, приходится перебирать, строить массивы значений.
"Соответствия" нужно искать в региональных НПА. И не всегда ты сможешь найти прямое, т.к. такие системы принимаются обычно в регионах, где кроме влажности и плодородия учитываются другие средообразующие факторы - например, рельефные и ландшафтные характеристики. Другими словами С3 в Туле <> С3 в пойме горной реки <> C3 северного склона.   
Но правильный ответ должен быть прописан в НПА и он должен учитывать реалии времени если отрасль не хочет плестись в хвосте ИТ. Любые параметры можно формализовать и закодировать в единой для РФ системе.

Мне не на чем проверить - БД ЛесГИС с такой системой не располагаю.