Сетка - та же таблица.
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

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

Анатолий, формализуйте более определенно что для вас значит "последний рабочий период". Николай об этом спросил на конкретном примере.
Последний период - это период в котором находится дата начала отпуска или это предыдущий период?
Если предыдущий, то возможен же вариант, когда отпуск в конце периода берется и тогда все равно предыдущий?

Если не сложно, поясните пожалуйста, что именно мешает пользователю пользоваться приказом на отпуск.
Ведь одним рабочим периодом ваши проблемы не заканчиваются. Вам еще потом надо не забыть отразить информацию об использованном отпуске в ленте периодов. Или у вас остаток отпусков в принципе не считается? Или потом последует  "открытие", что просто расчет отпуска (без приказа) не отражается в праве на отпуск и последует просьба это тоже исправить?

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

У страховых взносов есть возможность поставить необлагаемый статус через статус для иностранных граждан. У НДФЛ такой возможности не было. В страховых достаточно поставить статус для иностранцев 4 с той же даты, что вы поставить необлагаемый статус в nondfl...
Если нужна аналогичная настройка в страховых взносах, то можем ее добавить. В этом случае достаточно будет смотреть на одно поле КЧ.

Это мешает открытию счетов? 
Поля являются обязательными к заполнению?

Так то "место рождения" - сущность исходно созданная ПФ для анкеты АДВ-1 для получения СНИЛС.
И меня, как владельца этих перс.данных, интересует вопрос какого лешего сбербанк собирает эти данные...
Для открытия карточек/счетов и т.д. они абсолютно точно не нужны.
Более того, они и у работодателя не обязательно будут заполнены.

З.Ы. Хотя согласен что генерация xml-файла произошла с "ошибкой".