Сделали доработку, чтобы внедренцы могли в скриптовой функции переопределить символы для отпуска.
Достаточно будет в свой скриптовый модуль добавить что-то вида:

GetSimvOtpScript(tipotp,&ar)
{
   if ( tipotp==OTPUSK_DOP ) return 'Ю';
   return 0;
}

Войдет в следующее обновление.

Функциональность в базовом виде появилась 24.06.2019 релиз 599.17.
Посмотреть можно в SCRIPT\forms\BasePrintPoSredn.s
Задача внедренца реализовать UserBasePrintPoSredn(calcSr, &ar) в своем (!!!) скриптовом модуле. В поставочном дается пример как это может выглядеть.
Планируется в поставке реализовать формы печати на базе 425 для бюджетников (этот вариант как раз и есть в примере) и какой-то (пока не определились) для хозрасчетников.

Начнем с того что схема, когда вы среднее считаете по "голому МРОТ", и только итоговую сумму умножаете на районный коэффициент, в корне неверна. То что ФСС настаивает на этой схеме, говорит лишь о их неспособности разобраться в сути вопроса. К счастью ВАС в сути разбирается
Да мы сделали настройку позволяющую считать как хочет ФСС, но дорабатывать под это интерфейс нет смысла. Так как это неправильный способ расчета.

Реализовано в 600.1

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

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

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

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