Ковыряю расчет среднего в ЗУП 2.5 (Начисление отпуска). Расчетчица плачется что тарифникам ставится 29.4 вместо того что ими отработано (тока тока перешли с ЗИК и могло что-то перенестись криво, но этот вариант я пока не рассматриваю).
Потрасировал код. В итоге выловил некий запрос который выливается в выборку
ВыборкаОтработанноеВремя = Запрос.Выполнить().Выбрать();
Просмотрел склеиваемый запрос. Выявил несколько мест в которых возвращается 29.4. Выкусил текст запроса и подменил своим вариантом где вместо 29.4 возвращаются в каждом фрагменте своё значение, но не 29.4. Это помогло не вникая в детали выявить откуда мы имеем цифру. То есть какая ветка запроса даёт нам итоговую цифру. Возвращающий фрагмент заполняющий поле в модифицированном мной варианте получился такой:
    |    ОБЪЕДИНИТЬ ВСЕ
    |    
    |    ВЫБРАТЬ
    |        ЗаписиРасчетаСреднего.НомерСтроки,
    |        ЗаписиРасчетаСреднего.БазовыйПериодНачало,
    |        0,
    |        ВЫБОР
    |            КОГДА ОсновныеНачисленияРаботников.Сотрудник ЕСТЬ NULL
    |                ТОГДА 0
    |            КОГДА СУММА(ВЫБОР
    |                        КОГДА ОсновныеНачисленияРаботников.Сторно
    |                            ТОГДА -1
    |                        ИНАЧЕ 1
    |                    КОНЕЦ * РАЗНОСТЬДАТ(ОсновныеНачисленияРаботников.ПериодДействияНачало, ДОБАВИТЬКДАТЕ(ОсновныеНачисленияРаботников.ПериодДействияКонец, СЕКУНДА, 1), ДЕНЬ)) < РАЗНОСТЬДАТ(НАЧАЛОПЕРИОДА(ЗаписиРасчетаСреднего.БазовыйПериодНачало, МЕСЯЦ), ДОБАВИТЬКДАТЕ(КОНЕЦПЕРИОДА(ЗаписиРасчетаСреднего.БазовыйПериодКонец, МЕСЯЦ), СЕКУНДА, 1), ДЕНЬ)
    |                ТОГДА ВЫРАЗИТЬ(ВЫБОР
    |                            КОГДА ЗаписиРасчетаСреднего.ДатаНачалаСобытия < &ДатаИзмененияКоличестваДнейДляОтпускных
    |                                ТОГДА 28.4
    |                            ИНАЧЕ 29.3
    |                        КОНЕЦ / РАЗНОСТЬДАТ(НАЧАЛОПЕРИОДА(ЗаписиРасчетаСреднего.БазовыйПериодНачало, МЕСЯЦ), ДОБАВИТЬКДАТЕ(КОНЕЦПЕРИОДА(ЗаписиРасчетаСреднего.БазовыйПериодКонец, МЕСЯЦ), СЕКУНДА, 1), ДЕНЬ) * СУММА(ВЫБОР
    |                                КОГДА ОсновныеНачисленияРаботников.Сторно
    |                                    ТОГДА -1
    |                                ИНАЧЕ 1
    |                            КОНЕЦ * РАЗНОСТЬДАТ(ОсновныеНачисленияРаботников.ПериодДействияНачало, ДОБАВИТЬКДАТЕ(ОсновныеНачисленияРаботников.ПериодДействияКонец, СЕКУНДА, 1), ДЕНЬ)) КАК ЧИСЛО(7, 2))
    |            ИНАЧЕ ВЫБОР
    |                    КОГДА ЗаписиРасчетаСреднего.ДатаНачалаСобытия < &ДатаИзмененияКоличестваДнейДляОтпускных
    |                        ТОГДА 27.4
    |                    ИНАЧЕ 29.3
    |                КОНЕЦ
    |        КОНЕЦ,
    |        0
    |    ИЗ
    |        ВТЗаписиДанныхДляСреднего КАК ЗаписиРасчетаСреднего
    |            ЛЕВОЕ СОЕДИНЕНИЕ ВТОсновныеНачисленияРаботниковДляОтпуска КАК ОсновныеНачисленияРаботников
    |            ПО ЗаписиРасчетаСреднего.Сотрудник = ОсновныеНачисленияРаботников.Сотрудник
    |                И ЗаписиРасчетаСреднего.ПериодРегистрации >= ОсновныеНачисленияРаботников.ПериодРегистрации
    |                И (НАЧАЛОПЕРИОДА(ЗаписиРасчетаСреднего.БазовыйПериодНачало, МЕСЯЦ) = ОсновныеНачисленияРаботников.ПериодДействия)
    |    ГДЕ
    |        ЗаписиРасчетаСреднего.ВидРасчета = ЗНАЧЕНИЕ(ПланВидовРасчета.СреднийЗаработок.ПоЗаработкуИндексируемые)
    |        И ЗаписиРасчетаСреднего.СпособРасчета = ЗНАЧЕНИЕ(Перечисление.СпособыРасчетаОплатыТруда.ПоСреднемуЗаработкуДляОтпускаПоКалендарнымДням)

Возвращает 27.4. Стал смотреть. Условие с датой изменения для константы в ветке выбора понятно вполне. Непонятен вот этот фрагмент.

СУММА(ВЫБОР
    |                        КОГДА ОсновныеНачисленияРаботников.Сторно
    |                            ТОГДА -1
    |                        ИНАЧЕ 1
    |                    КОНЕЦ * РАЗНОСТЬДАТ(ОсновныеНачисленияРаботников.ПериодДействияНачало, ДОБАВИТЬКДАТЕ(ОсновныеНачисленияРаботников.ПериодДействияКонец, СЕКУНДА, 1), ДЕНЬ)) < РАЗНОСТЬДАТ(НАЧАЛОПЕРИОДА(ЗаписиРасчетаСреднего.БазовыйПериодНачало, МЕСЯЦ), ДОБАВИТЬКДАТЕ(КОНЕЦПЕРИОДА(ЗаписиРасчетаСреднего.БазовыйПериодКонец, МЕСЯЦ), СЕКУНДА, 1), ДЕНЬ)

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

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

Продолжайте наблюдения

В чем вопрос-то?
Кстати, с апреля используется 29,3.

И вытеснения проверь

Просто расчетчица, как я понял, хочет что бы вместо 29 и 4 в документ летело фактическое количество отработанных часов.

(3) так смотрите оклонения в том периоде и 29.3 все-таки

(4) Возможно всё-таки 29 и 3, но просто мы пытались сделать переход на начало года. Персонал засаббатировал и в итоге пришлось переходить по состоянию на полугодие. У меня под руками осталась база в которой делали перенос по состоянию на начало года и в ней январский документ по начислению отпуска. На нём я и проверяю.

за каждый период должно быть одно и только одно (!) основное начисление. Иначе ЗУП среднее считает криво (практически никак). Ну или можно добавить сторно в нужном количестве.

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

(3) Фактически отработанное - это 30/31 или меньше (из-за отклонений)?

(3) Вы вот этими своими искусственными вставками просто занизите/завысите средний для расчета отпуска. расчетчика так устраивает?

(6) а расскажите как по нескольким будет высчитывать?
просто любопытно

(9) Спокойствие. Вставок пока в рабочей базе никаких нет. Задача моя кроется в том что мне надо понять почему оно отрабатывает таким вот образом и что у нас в базе не так что бы оно отрабатывало должным, по мнению расчетчицы, образом.

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

(6) Одно основное? Я сформировал отчет по регистру расчет в консоли запросов обеспечив выборку всех существующих записей по данному сотруднику. Перенос из ЗИК в ЗУП создал вид расчета с наименованием "Оплата по часовому тарифу (по тарифному разряду)". Только у этого вида расчета стоит зачет нормы времени в "Да" и ВидВремени в "Отработанное время в пределах нормы времени". Вероятно только оно является основным. В виде расчета стоит что требуется ввод разряда. В карточке сотрудника разряд стоит. Вид расчета в основной заработок индексированный в базу входит.

(10) По методу отклонений, например можете посмотреть реализацию в ЗиК 7.7.
(13) Ага. Основное=Отработанное время в пределах нормы времени.
Так вот допустим у вас есть две записи оплата по тарифу с периодами действия 01.05-05.05 и 04.05-29.05, а 30.05-31.05 допустим Больничный. Да вот беда ЗУП не увидит неполного месяца т.к. 4 и 5 мая учтется дважды, тут нужно либо убрать пересечение периодов. либо добавить сторно с 04.05 по 05.05 тем же видом оплаты без суммы, причем период регистрации сторно должен быть позднее периода регистрации сторнируемого начисления.

а если у вас например 2 и больше записей по тарифу с периодом 01.05-31.05, об корректном учете среднего можете забыть. Вернее есть способ, но он немного муторный.

(14) Раньше когда сталкивался с ЗУПом, правда не с тарифниками, а с окладниками, было достаточно настроить вытеснение по видам времени.

(16) не понял причем тут оно. Вытеснение в ЗУП - это вспомогательный механизм для получения ФПД расчета и только. Сами зиписи могут быть либо обычными (+). либо сторно (-). Их "суммой по дням" и формируется период работы сотрудника.

(3) это вообще не правильно, есть офф. расчет этого коэффициента, которого надо придерживаться.
по вопросу: это возможно из-за переноса, было тоже самое... помогло проверка/настройка списка вытесняющих видов расчета у основного начисления и перезапись документов "перенос данных"