Проблему можно решить еще по-другому: сначала в реестр добавить заготовку для ЭЛН (выбрать сотрудника и указать номер ЭЛН), а после этого уже импортировать. Тогда ЭЛН привяжется именно к тому сотруднику, что требуется.
Но с другой стороны связь между лицевыми счетами и реестром ЭЛН в любом случае идет по СНИЛСу. Поэтому то, что в реестре подставился "не тот табельный" сейчас не помешает корректно выполнить расчет больничного (потому что расчет вы будете делать из сотрудника).

Вот когда мы сделаем расчет из реестра, тут да, скорее всего мы будем пытаться делать расчет для того табельного номера, что нашли.

Травматизм считается без округления с общего ФОТ.
Если вы посчитаете сумму травматизма с общего фот и округлите до копеек получите "сумма 0".
Если вы ФОТ разделите на 3 части и так же посчитаете травматизм с округлением до копеек, то получите сумму 1, сумму 2 и сумму 3.
Так вот в общем случае сумма 1+ сумма 2+ сумма 3 не равны сумме 0.
Отсюда выход: либо считать травматизм по людям в копейках (но это противоречит законодательству), либо понимать что травматизм с части фот, может отличаться от травматизма с полного фот.

Погрешность округлений учитывается при вертикальной организации свода (когда категории у вас будут не столбцами заданы а ключевым значением для строки). В этом случае общая сумма по травматизму всегда будет совпадать с суммами по строкам свода.

Исправлено в 600.1

У строк видов Н-У есть собственные подразделения.
Если вы у видов(!) по совмещению поставите подразделение 110 то в свод они полетят как относящиеся к 110 подразделению (без объектов).

Соглашусь что в данном случае проще всего решать вопрос через разбиение.
Не обязательно заводить разные виды окладов, как пишет Игорь Шалдин. Это может быть неудобно из-за того что каждый месяц программы могут меняться, надо "множить" строчки окладов. Много строк окладов (вместо одной строки) может приводить к тому что общая сумма оклада будет не равна окладу (на копейки но все же!).

Поэтому вполне подходит тот, вариант который сделали вы - мнимый вид.
Но в этом случае надо стандартные алгоритмы разбиения немного доработать под вас.

Если это не принцииально, то для простоты доработки часы с разбивкой по программам, заносить в этот мнимый вид не в рабочее время а в сумму.
Тогда в стандартное разбиение надо добавить предварительный шаг, на котором оклад будет разбит по этому мнимому виду, а все остальное уже по окладу.