Сообщения, касающиеся импорта из файлов ввода данных Ивест, перенесены в отдельную тему:
Импорт файлов ввода Ивест

Процесс экспорта из 10-ки в СОЛИ не зависит от справочников. Этот конвертер один в один переносит классификационные коды в структуру БД СОЛИ не обращаясь к справочникам.

Это не трудность. Это преимущество, без которого не возможна реализация таких функций как поиск по сопутствующим породам, актуализация насаждений на возраст, а в несостоявшемся будущем корректное определение бонитета в молодняках и персонализация процента выборки при РУ в условиях НЛУ... И многое другое.
Первый же вопрос, который возникнет у любого профессионала - разработчика к авторам Вашего импорта - "а зачем они берут из источника лишнее?" Справочники же они как то загружают наши? Да и поля лишние они как то отсеяли? В нашей базе масса других полей как содержательных, так и служебных, используемых в нашей системе для аналитики, которой нет ни в СОЛИ ни в других системах. Они же их не загрузили? Почему у них возникли проблемы отсечь в молодняках "лишние" для них описания пород?

Это они не "от Вас" получают некорректный материал,  а из "АРМ таксатора", разработчики которого не позаботились о контроле и отсеве лишней для них информации из существующих систем.  Разработка и поддержание импорта - это обязанность разработчика  принимающего продукта, а не отдающего! И если что то не так - это его косяк, который он должен исправлять по замечаниям пользователей.

Вообще то, единичники должны описываться отдельным, 9-м ярусом. Это было зафиксировано во всех методических материалах по заполнению карточек таксации начиная с ЕС 1033 и заканчивая СМ1600-1700 и далее ПК.

Естественно. Этот инструмент для того и создавался, чтобы формировать базу в привычном таксатору режиме. Однако в базе все сидит как положено в нормализованных реляционных структурах.

А этот инструмент создавался для аналитической работы с базами, а также таких задач как актуализация, которая, кстати, как метод сидит в Вашей инструкции. Вы как собирались актуализировать? Ярусом? По его средней высоте? )) Актуализировать нужно и можно только по породам, т.к. у каждой свой характер хода роста. Там кроме H/D по сопутствующим есть еще и поля с точными значениями актуализации по возрасту, высоте, диаметру... Они их тоже как то отсекли?

Плюсовые посмотрим, проанализируем, думаю, что там они реально не нужны. А у сопутствующих можем убрать только из результатов экспорта, т.к. курочить свою базу в угоду неграмотным решениям мы не готовы.

Все таки, единичники - это 9-й ярус. У Вас есть какие то Ваши, утвержденные Вашим ЦА, методички или рабочие правила по заполнению КТ? А то мне кажется, что это какая то отсебятина сибиряков... И эти яруса участвуют в некоторых расчетах, кажется, РУ и СР... их для того в ярус и выделяли, чтобы можно было управлять обработкой.

Подытожим. Если разработчики АРМа таксатора отказываются исправить свой косяк импорта, то сделаем опцию для усеченного варианта при экспорте для передачи коллегам. Базу ломать конечно не будем. А справочники пусть делают из "АРМа".

Все эти вопросы уже поднимались и мы на это отреагировали доработками - по файлу набивки в теме:
http://lesis.mybb.ru/viewtopic.php?id=775

Импорт и экспорт из-в СОЛИ был реализован год и полгода назад соответственно и обсуждался в этой теме, куда я перенес Ваш вопрос.
И в конце обсуждения мы попросили протестировать как можно быстрее, пока разработчики не забыли алгоритмы. В ответ тишина.

Все, что Вам нужно было сделать - написать, что Вам нужен либо экспорт в ивест, либо в экспорте в СОЛИ сделать кастрированный вариант для Ваших коллег из других филиалов без высот и диаметров второстепенных в молодняках.

Полгода назад это заняло бы у программиста один день, сейчас не берусь сказать.
Будем тоже смотреть, что проще  - добавить файл набивки в txt формате или урезать экспорт СОЛИ.

'B' is not a valid integer value - это нужно проверять соответствие значений полей базы logstr.dat-у. То есть, если программа прочитала значение "B" там, где она по logstr.dat  ждет число, то вставить его в целочисленное поле не сможет. Нужно либо корректировать logstr.dat либо искать "родной" именно для этой базы.
Ну или структура базы СОЛИ изменена относительно стандарта СОЛИ. Например, у нас в РФ есть регионы где типы ТЛУ отражаются по разному - где то это группа леса, где то Погребняк, а где то числовые (классификационные коды).
Нужно найти один выдел, где ошибка ТОЧНО проявляется методом "половинок":
http://lesis.mybb.ru/viewtopic.php?id=257#p2288
В данном случае на копии рабочей базы импортируете или экспортируете только часть БД СОЛИ, можно начать с одного квартала.
Чтобы мы могли это проверить, нам нужен образец такой базы+logstr.dat на выдел или квартал, где ошибка проявилась..
На имеющихся у нас образцах такая ошибка не проявляется.