Нормативный заработок в лицевом счёте

В ходе презентаций КЗ для бюджетных учреждений часто возникает вопрос: "а как мне увидеть зарплату за полный месяц, вот в Парусе/СТЭКе у меня сразу всё видно".

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

Да пожалуйста:

Можем включить в поставку для сильно страждущих. Но пользоваться этим можно, только если при расчете нормативного заработка не используются алгоритмы работающие по месяцу начисления.
Если какие-то виды для нормативного заработка считаются по месяцу начисления (что вообще говоря странно для нормативного заработка, пересчеты не должны на него влиять) - то пользоваться не стоит.

Игорь, а у Вас на скриншоте ошибка? районный коэффициент с премии разве может входить в нормативный заработок?

Можем включить в поставку для сильно страждущих. 

А можно какую-нибудь "заплатку" на текущую версию чтобы понять как это всё работает?

у Вас на скриншоте ошибка?

В данном случае - да (заметил уже когда опубликовал скрин, а исправить поленился).

районный коэффициент с премии разве может входить в нормативный заработок?

Почему бы и нет? Допустим, премия ежемесячная и по каким-то причинам надо выделять долю РК...

ну лишь бы и премия тогда тоже входила в нормативный заработок. Вариант Р/К входит, а то на что накручивается не входит - не взлетит.

Если какие-то виды для нормативного заработка считаются по месяцу начисления (что вообще говоря странно для нормативного заработка, пересчеты не должны на него влиять) - то пользоваться не стоит.

А можно на примере показать, что имеется в виду под "виды считаются по месяцу начисления".

Речь про то, что пересчёты за предшествующие месяца не будут включаться в нормативный заработок текущего?

Более корректно выражусь (речь не только о выборке по месяцу начисления).

Речь о ситуациях, когда в алгоритме используются функции типа CollectSumm вместо s100... Такие алгоритмы не отработают.

Увопроса появилась отметка "Завершен"...

А когда результат завершения "пощупать" можно будет?

Ну мы сделали.
А потом когда тестировать начали, всплыли "нюансы". Поэтому точно не в ближайшее обновление. Надо сначала исправить эти нюансы. Кстати если исправим их, то и ограничений на CollectSum в алгоритме скорее всего не будет. Сменил статус на Начат :)

когда тестировать начали, всплыли "нюансы"

Может сильно глубоко копали, когда делали? Ну или не в ту сторону...

Объясню ситуацию на примере:

Если добавить в ЛС мнимый вид с алгоритмом расчёта:

{ int col = 33; // столбец для расчета нормативного заработка
var D = CreateObject("KDate");
D.SetDateII(countday,mrasch);
rwlsbuf(1);
if ( ras_normzar(col-1,"1",1,0,n1,D)==ESC )
n1 = 0.;
rwlsbuf(0);
worktime(info.crow,info.b3,0);
r[2] = dney_v_tab(rsimv,calm,1,31);
zamena_simv_v_tab("Р","2",calm,1,countday,info.crow,0);
n1 *= r[2]/norm(1);
break;
}

то при расчёте строки будет виден искомый нормативный заработок.

Посчитали сколько человек получил бы, если бы отработал полный месяц, и всё. Вроде ни каких "нюансов"... 

Или я чего-то, в силу своего дилетанства, не учитываю? 

В нашем случае нельзя пользоваться rwlsbuf. В этом и проблема.

Нет ни каких подвижек по данному вопросу?