Такая функция поможет:

UsrGetNormPeriod(what,&D1,&D2,numcalend)
{
   int am1 = KDateFromStr(D1).GetAbs();
   int am2 = KDateFromStr(D2).GetAbs();
   int tmrasch = mrasch;
   int tmp = nkalend;
   if ( nkalend!=numcalend && numcalend>0 )
      rwnorma(numcalend,0);
   double Total = 0.;
   for (int am=am1; am<=am2; ++am )
   {
      mrasch=am;
      s118();
      Total += norm(what);
   }
   mrasch=tmrasch;
   if ( nkalend!=tmp )
   {
      rwnorma(tmp,0);
      s118();
   }  
   return Total;
}

Пример вызова: 

return UsrGetNormPeriod(1,"01.01.2018","31.12.2018",2);

в поставку добавили параметр 0 - по принадлежности, 1 - по начислению 

CL_COL надо тоже убрать из параметров.

Правильный флаг:  CL_EXACT | CL_MV | CL_NACH для начислений и CL_EXACT | CL_MV | CL_UD - для удержаний. В противном случае если будет несколько строк с одинаковым кодом, суммы по этому коду удвоятся.

Старый надо оставить как "базу знаний" там накопился достаточно большой объем вопросов-ответов, которые актуальны и сейчас. Поэтому в режиме "только для чтения", старый форум был бы полезен.

Скорее всего он перестал им категорически не нравится после того как отпускные перестали неожиданно быть зарплатой и стали облагаться по месяцу начисления.

s1001simv_mv выборку по источникам делает (в данном случае по всем источникам). Если у вас источники - то взлетит если вместо 0 перед ST_ALIMENT укажете mrasch.

Если же исп.должности нужны то 

var CurProp = GetCurPropCountLS();
info.n1 = s1001simv_mv("1",info.d1,info.d2,mrasch,ST_ALIMENT,2, CL_MV | CL_COL | CL_NACH, CurProp);

активнее голосуем и отписываемся в комментариях :)

Пользователи могут "изменить" и "удалить" тему и/или свой комментарий только ограниченное время после создания. В настройках форума это время выставлено на 120 минут. И только если не было связанного чужого комментария к тому, что хотят изменить. Видимо, чтобы не было недоразумений вида: "в теме есть какой-то ответ, но он слабо связан с исходным вопросом, потому что вопрос был исправлен". Можно же легко внести исправления добавив новый комментарий.

Т.е. нужны суммы по доплате до мрот, аесли сн и рк крутить сверху, то часть доплаты “теряется” в общих суммах сн и рк.

Я же написал выше. Ничто не мешает сделать отдельный вид(ы) СН и РК, которые будут считать сумму ТОЛЬКО с доплаты. То есть:

1) Доплата считается без СН и РК (и не учитывает в своем расчете уже начисленные СН и РК)

2) Отдельными видами считается СН и РК с доплаты

3) Основные виды СН и РК накручиваются только на обычную зарплату но не доплату СН и РК.

Плюсы: 

1. минимальные модификации алгоритмов
2. Можно путем задания периода действия отдельных видов СН и РК в любой момент перейти от схемы "доплату увеличиваем на СН и РК" к схеме "доплату счетаем без СН и РК".
3. Трудовики и работники сразу видят что на доплату тоже крутится СН и РК

Минусы: ну я только один вижу - чуть больше видов в ЛС.