При расчёте отпуска сумма заработка не полностью включается в расчёт.

Это баг в КЗ (ИМХО).

По умолчанию, сумма РК для расчёта среднего заработка не берётся из ЛС "как есть", а зачем-то рассчитывается.

В данном случае в ЛС присутствуют два вида РК:

- РК с заработной платы, который рассчитывается штатным способом - по алгоритму 99,

 - РК с премии, который рассчитывается по 34 столбцу ТВХ пользователя, т.е. способ расчёта "нештатный" - через параметры алгоритма 99.

Когда при расчёте среднего заработка КЗ вычисляет РК с заработной платы - полёт нормальный.

А вот с "нештатное" вычисление РК с премии расчёт среднего заработка не видит и считает сумму не по 34 столбцу, а по стандарному 11. Отсюда и "недобор" декабрьского заработка = 685.47 руб.

Способ добиться желаемого результата - брать сумму РК из ЛС такой, какая есть:

Настройка --> Настройки параметров расчёта --> Настройки расчёта отпуска --> Способ выделения РК = 2

Добрый день

Вопрос можно закрывать?

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

это не баг, а фича.

Пока РК в ЛС один - безусловно, фича. Но пока присаутствует это самое "пока" - это баг.

Вопрос можно закрывать?

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

Игорь, вопрос бы адресован не к вам, а к топикстартеру.

Как исправить ситуацию - было отвечено. 

Что еще осталось непонятным, требующим ответа "разработчиков"?

Игорь, вопрос бы адресован не к вам, а к топикстартеру.

Можно сказать, что топикстартер - Челябинский филиал. Просто я на больничном и с мы с Анатолием не имеем возможности общаться лично.

Что еще осталось непонятным, требующим ответа "разработчиков"?

Думаю, ответ очеведен - будет ли исправлен баг.

А что значит "нештатное" начисление р/к? Оно не укладывается в стандартные 12,15,99,98 алгоритмы? Почему?

Почему вы считаете это баг? У вас написан некоторый свой алгоритм, вы запускаете расчет среднего с указанием: "а пересчитай ка мне некоторый набор видов с учетом тех сумм, что попадают в расчет среднего". То есть ваш алгоритм должен уметь работать в такой ситуации. Это он должен понимать, что кроме того, что он считается в обычном режиме по некоторому набору видов, он должен уметь считаться в расчете среднего, когда надо взять "пересечение" двух наборов видов (обычного и того, по которому среднее считается).

"Параметры алгоритмов", которыми Вы любите пользоваться так не умеют. Скрипты - можно научить.

01.12.2016 релиз 591.0

! s100ras может отрабатывать по пользовательскому алгоритму при расчете среднего.
Извечной проблемой было то, что при расчете среднего можно указать виды, которые
при выборке в среднее подвергаются пересчету (районный коэффициент, процентные надбавки),
с целью не включить в выборку ту долю пересчитываемого вида, которая приходится на виды,
по которым среднее не считается (а пересчитываемый вид считается).
В качестве таких видов можно было указывать только виды, по которым написан специальный алгоритм
в s100ras (12,15,98,99).
Сейчас s100ras при своем вызове:
1) запоминает столбец по котором она должна отработать и его можно получить в алгоритме пользователя через GetLastS100rasColumn
2) если не находит алгоритм в числе "известных" s100ras, запускает для пересчета вида обычный расчетный алгоритм с флагом b3=7.
Таким образом, у внедренца есть возможность доработать свой алгоритм с прицелом на то, чтобы при вызове его с флагом b3=7 (то есть из s100ras)
этот алгоритм учел столбец, по которому отрабатывает s100ras (например используя w2dopst).

Это можно считать тем, что "бага" о котором Вы говорите в программе нет уже 2 года, а есть баг в Вашем алгоритме?

А что значит "нештатное" начисление р/к? Оно не укладывается в стандартные 12,15,99,98 алгоритмы? 

Вполне укладывается. Выше я писал:

РК с премии, который рассчитывается по 34 столбцу ТВХ пользователя, т.е. способ расчёта "нештатный" - через параметры алгоритма 99.

Т.е. второй РК рассчитывается по стандартному алгоритму 99, но суммы выбираюнся по "нестандартному" 34 столбцу ТВХ. Для этого в параметрах алгоритма поставили 34, а в 26 столбце спецТВХ - 1. 

"Параметры алгоритмов", которыми Вы любите пользоваться так не умеют.

Видимо, тут и "собака порылась"...

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

А точно отличаются только столбцом? Параметр, задающий столбец для "обычного" 12-15 алгоритма и для "параметризованного" алгоритма имеют одинаковый порядок. Ну то есть, если не писать что-то вроде 1=N, а просто перечислять параметры через запятую - то все работало бы.
Легко же проверить. Включите вашим особым видам РК расчет не через параметры, а через обычный алгоритм (2 в 26 столбце специальной ТВХ)
s100ras по стандартным то алгоритмам 12,15 давно умеет работать (в том числе с учетом другого столбца в параметре).

Вопрос был решен? Тему можно закрывать?