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

1) выглядит странным посыл отчетности без сверки со сводами.

2) еще будет страннее, если бухгалтер в данной ситуации выберет вариант "заплатить пени" вместо "подать корректировку". Так как по факту нарушения то нет, и взносы все платились в полном объеме.

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

Добрый день тестирование программы на компьютере с установленным офис 2019. Проблем с этим офисом не выявило.

Попробуйте полное удаление офиса с помощью средства поддержки удаления.

Всегда есть вариант с использованием Libre Office (Open Office).

обсудим этот бред

Это не бред, в том случае если в БЗ вида летит оклад от полной ставки. Тогда норма от полного графика - это правильно

Сетка - та же таблица.
var t = CreateObject("CurPrnTbl");

t.InitialNameFile(имя файла);
Дальше ходим по строчкам и столбцам этой таблицы.
Только кажется, что это какой-то костыль. Пропишите в сам нормативный график ссылку на полный.

И получайте полный график через GetNumParentCalend(номер календаря).

Не могу представить для чего понадобились такие сложности и какие "проблемы" вы решаете своим подходом.  Поддержу мнение Игоря: организация на ровном месте себе создает проблемы в будущем.

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

рода "неправильностям" и "странностям", так как чаще всего причина
отличий - просто забыли обновить скрипты на какой-то машине.
Из
случаев когда это могло бы быть полезным пришло в голову только "разные
подписанты для формы отчетности" (а точнее, видимо подписант = текущий
расчетчик). Кажется что это лучше решить системно нежели "разные
скрипты".

Основной каталог SCRIPT берется с того же уровня что и
каталог RSCALT из которого запущена исполняемый модуль программы. Если
каталоги RSCALT локальны, то и SCRIPT будет "локален". Если используется
общий RSCALT (например при работе в терминальном режиме, или размещая
RSCALT там же где сетевой ZPL), то и каталог SCRIPT будет "общим" с
теми, кто пользуется одним и тем же RSCALT.

В программе есть
еще SCRIPT, который располагается в ZPL (в сетевой версии в сетевом
ZPL). Как решение для описанных выше недостатков (бывают сложности с
тем, чтобы обеспечить на всех машинах расчетчиков одинаковые версии
доработок, очень часто скрипты копируются одному расчетчику а другому
забывают скопировать или не копируют потому что "он не будет работать с
этим отчетом, зачем я ему буду копировать" и потом появляются вопросы
вида "а почему на одной машине у нас работает, а на другой нет").

Обращение к скриптам из сетевого ZPL делается так:
LoadScriptModule("ZPL:usalg"); // загрузить модуль ZPL\script\usalg.s
Если в ZPL размещается пользовательский "системный" модуль, который раньше
располагался во внешнем каталоге SCRIPT, то чтобы не было конфликтов
надо не забывать выгрузить внешний модуль.

UnloadScriptModule("user\\usalg"); // выгрузить модуль script\user\usalg.s
LoadScriptModule("ZPL:usalg"); // загрузить модуль ZPL\script\usalg.s 

Ну и в каталоге ZPL\script так же можно организовывать свои скрипты в отдельных папках.
Например? если модуль main.s располагается в каталоге ZPL\script\import? то можно обращаться к нему так:
LoadScriptModule("ZPL:Import\\Main");

1) кажется что d1,d2 - это double вида ГГГГММ.ДД, а функция skoljko ждет в качестве параметров целое число от 1 до 31. (день месяца). 

Должно быть что-то вроде:

s50(am);

int z1,z2;
s6400(d1,d2,z1,z2,data);
double nch; skoljko(nch,data,z1,z2,"r",calmras,0); // calmras - т.к. мы же хотим нормативные часы а не фактические?

2) mrasch = am; - это плохая практика. Лучше s50(am) или s50all(am); В частности тогда не будет рассогласования между mrasch и data. А то тут получаем mrasch соответствует одному месяцу, data - другому.

А что скрипты с разных рабочих мест у вас разные? Сохранения их в сетевом каталоге недостаточно?
Регулярно работаю с сохраненками, пока не заметил проблем от того что скрипты в сетевом каталоге сохраняются.

P.S. кажется что сейчас более удобная схема, когда пользовательские скрипты вообще располагаются в SCRIPT сетевого ZPL а не там? где системные скрипты (кажется что так их гораздо проще обновлять).

да. Если в организации других иностранцев с 4 не бывает, то можно даже не заморачиваться с полем nondfl. А в НДФЛ тоже сослаться на status2:4

Не хватает скриншота состояния лицевого счета.
Если например минусовые суммы были введены вручную или суммы больничного переносились с одного вида на другой вручную, а не программа в процессе пересчета, или если у видов менялись источник/объект/подразделение. То возможна потеря связи конкретного больничного с суммами в ЛС.
В этом случае суммы по этому больничному в реестр не попадут.
В лучшем случае что мы можем сделать для такой ситуации: написать строчку "неизвестный больничный" и поставить туда эти странные суммы.
Если же мы говорим про РСВ то туда суммы вытягиваются без привязки к больничным, просто обычной выборкой по видам больничных, так как РСВ не важны ни номер, ни даты больничного. РСВ интересует только начисленная сумма.