1) Что не определяется в строке stavka = normZP/norm(2); можно легко посмотреть в отладчике скриптов.

2) чтобы norm(2) оказался нулевым, надо чтобы нормативный график был не заполнен. При этом программа будет про это верещать каждый раз, когда идет обращение к этому графику (например при чтении ЛС).
3) При делении на ноль получите "исключение", поэтому "не заметить" это будет не возможно (попробуйте просто написать в скрипте 1/0).

Резюме: норма времени не причем, ноль по ставке получаете из-за нуля по нормативной зарплате. Ноль по нормативной зарплате получаете из-за того что алгоритм не учитывает внутри себя варианта "а сейчас мы работаем не по фактическому времени а по нормативному". На поставочных алгоритмах такого нет, потому что алгоритм того же оклада заполнит табель (за весь месяц) по нормативному графику и соответственно получит полный оклад. А у вас, как раз проблема в том что алгоритм табель не заполняет, а считает что его кто-то заполнит до него.

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

1) передан не внутренний код совместительства, а внешний
2) передается не целое число а строка.

Ну то есть вместо combine надо написать ExtCombineToInt(combine)

У ЭЛН есть уникальный идентификатор состояния в ЕИИС "Соцстрах". При каждом изменении ЭЛН этот уникальный идентификатор изменяется.
Сообщение означает, что между тем моментом когда вы скачали ЭЛН в Контур-Зарплата и попыткой отправить результаты расчета на сайт ФСС, кто-то изменил этот ЭЛН. Например кто-то отправил результаты расчета через Контур-Экстерн. Поэтому уникальный идентификатор состояния ЭЛН который сейчас есть в Контур-Зарплата отличается от уникального идентификатора состояния этого ЭЛН в ФСС и ФСС отказывается принимать данные.
Надо скачать свежее состояние ЭЛН, сверить данные расчета, и после этого выполнить отправку.

В начале сентября выпустим.

А в совместительстве то нет что ли "оклада" (или других видов), по которым ставка считается?

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

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