потому что столбец НУО считается ключевым именно он определяет по какой строке суммы подлежат дополнительному округлению. В указанной форме свода не получится добиться дополнительного округления без разбиения на отдельные строчки.
Красивого вида (без лишней разбивки по строкам) можно добиться своей формой печати для этого свода.

Еще один вариант: вернуться к расчету травматизма на уровне ЛС с округлением до копеек. В этом случае ни в сводах, ни выборках никаких расхождений не будет. Но в 4-ФСС сумма травматизма может не быть равна БАЗА*процент.

Если вопрос актуален можем подключиться удаленно.
Пока тему закрываю.

Ой, только не в rsimv "навсегда" (то есть не в UserSetSimv)!
Это может "выстрелить" в любом алгоритме или форме отчетности (то что буквы В надо считать отработанными) и не факт что это понравится (ведь пожелание только по алгоритму надбавки).

15 алгоритм есть в скриптах (algsys.s SysAlg12_15_25_115(&info,&r)). Можно его утащить в useralg и модифицировать, дать новый номер алгоритма и этот номер алгоритма назначить виду надбавки.
Модификация такая:

string oldrsimv = rsimv; 
rsimv += "В"; 
for(var m=mes1; m<=mes2; m++) 
{
....
}  // 08.11.95
rsimv = oldrsimv;

Судя по отсутствию продолжения, обновление помогло.

Вопрос актуален или уже решен?
Тему пока закрываю.
Если вопрос не решен, нужны ответы на наши вопросы.

В версии 599.0 была улучшена работа с сертификатами (стали поддерживаться сертификаты ориентированные на ГОСТ 2012). Скорее всего проблема была решена.

Решено в 599.0.