Тема уже была Расчетный листок в 8 раз увеличивает суммы, но там ответа нет.

все с начислениями в порядке, но расчетный листок в стандартной конфиге ЗУП (версия 3.1.25.40, 8.3.22.1923) по одному сотруднику в одном месяце удвоил записи начислений, а их суммы умножены в 2 или 4 раза. При этом умножены и дни, и часы. Перехватить расчетный листок в консоли запросов не получается, он формируется программно. Надо какую-то продвинутую консоль, но их в инете тысячи.

Если я формирую программно РЛ, данные верные.
    ОбщегоНазначенияКлиентСервер.УстановитьЭлементОтбора(НастройкиОтчета.Отбор, "ФизическоеЛицо", СписокСотрудников,
    ВидСравненияКомпоновкиДанных.ВСписке, , Истина);
    ОтчетОбъект.КомпоновщикНастроек.ЗагрузитьНастройки(НастройкиОтчета);
    ОтчетОбъект.КомпоновщикНастроек.ПользовательскиеНастройки.ДополнительныеСвойства.Вставить("КлючВарианта", "РасчетныйЛисток");
    КомпоновщикМакета = Новый КомпоновщикМакетаКомпоновкиДанных;
    МакетКомпоновкиДанных = КомпоновщикМакета.Выполнить(ОтчетОбъект.СхемаКомпоновкиДанных, ОтчетОбъект.КомпоновщикНастроек.Настройки, , , Тип("ГенераторМакетаКомпоновкиДанныхДляКоллекцииЗначений"));
    ПроцессорКомпоновкиДанных = Новый ПроцессорКомпоновкиДанных;
    НачисленияУдержанияДокумента = ЗарплатаКадрыОтчетыБазовый.НаборыВнешнихДанныхАнализНачисленийИУдержаний();
    ПроцессорКомпоновкиДанных.Инициализировать(МакетКомпоновкиДанных,НачисленияУдержанияДокумента,,Истина);
    ПроцессорВывода = Новый ПроцессорВыводаРезультатаКомпоновкиДанныхВКоллекциюЗначений;
    ДанныеТЗ = Новый ДеревоЗначений;
    ПроцессорВывода.УстановитьОбъект(ДанныеТЗ);
    ПроцессорВывода.Вывести(ПроцессорКомпоновкиДанных);

Если вызывается типовая процедура
    ОтчетРасчетныйЛисток = ЗарплатаКадрыОтчеты.ОтчетРасчетныйЛисток();
    Результат = Отчеты.АнализНачисленийИУдержаний.РасчетныйЛисток(ФизическиеЛица, Организация, МесяцФормированияОтчета, ОтчетРасчетныйЛисток);

то отчет врёт.

нашел, где получаются данные в конфигурации

        ПроцессорКомпоновки = Новый ПроцессорКомпоновкиДанных;
        ПроцессорКомпоновки.Инициализировать(МакетКомпоновки, ВнешниеНаборыДанных, , Истина);
        
        ДанныеОтчета = Новый ДеревоЗначений;
        
        ПроцессорВывода = Новый ПроцессорВыводаРезультатаКомпоновкиДанныхВКоллекциюЗначений;
        ПроцессорВывода.УстановитьОбъект(ДанныеОтчета);
        
        ПроцессорВывода.Вывести(ПроцессорКомпоновки, Истина);
        
        ДопСвойства.Вставить("ОтчетПустой", ДанныеОтчета.Строки.Количество() = 0);
        
        РезультатКомпоновкиМакета.Вставить("ДанныеОтчета", ДанныеОтчета);

запрос там тот же, что и в моем программном формировании, но результаты разные. параметров там десятки. есть возможность как-то сравнить эти запросы и параметры? на глаз никаких отличий не вижу. ну или перехватить их. запрос 3000 строк, глаза сломать можно.

Давайте картинки трёх месяцев р/л: до плохого, плохой и после плохого.

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

(1) так, анализ проблемы показал, что этот сотрудник попадал под удаление дубликатов. полез повторно в кадровую информацию, нашёл несколько подозрительных записей, удалил их, а именно в регистрах Текущие кадровые данные сотрудников и текущая тарифная ставка сотрудников.
исправление первого регистра убрало ошибку задвоения записей начислений, исправление второго регистра убрало дублирование записей в карточке сотрудника и вернула нормальный расчетный листок.
всем спасибо, вопрос решён.

Ну... так неинтересно )

(3) было такое, регистр состояний сотрудников некорректно перенесли. У людей по несколько лямов в расчетках было )

Раз это уже вторая ветка за короткое время, то нельзя оставлять непонятым баг учетверения. Открыл демо и порылся. Гадит вот этот регистр сведений: ПлановыйФОТИтоги
Как ни странно, но программа ЗУП 27.51 позволяет править этот регистр вручную напрямую:
https://i.ibb.co/XjJPJ77/2023-09-22-09-11-25.png

Экспериментальные данные:
1. Если по сотруднику две записи любого интервала действия (хоть и с пересечением), но значения ресурса ТарифнаяСтавка совпадают, то с р/л всё нормально.
2. Чудеса с учетверением начинаются, если значения ресурса ТарифнаяСтавка отличаются в записях хоть на одну копейку. И здесь уже важна дата действия.

3. Возьмём текущий сентябрь и проставим в одной записи дату окончания 30.09.2023 23:59:58
https://i.ibb.co/Y23XKF0/2023-09-22-09-04-25.png

Смотрим р/л:
https://i.ibb.co/yNxMHcN/2023-09-22-09-07-53.png
Всё нормально.

4. А теперь добавим одну секунду в дату окончания первой записи регистра:
https://i.ibb.co/G7wNmdK/2023-09-22-09-14-43.png

Смотрим р/л:
https://i.ibb.co/9G81Jrb/2023-09-22-09-17-05.png
Пошло учетверение.

Теперь понятно как быстро исправлять учетверение р/л у клиентов. Просто закрывать по-раньше дату окончания старой записи РС "Плановый ФОТ Итоги".

А перфекционисты могут глянуть код и найти баг, если будет время и желание )

Еще нашлись кривые записи в регистре Данные для подбора сотрудников, правда, их там нельзя удалять/редактировать, но через Поиск ссылок на объект можно.

(6) >Как ни странно, но программа ЗУП 27.51 позволяет править этот регистр вручную напрямую
Этот регистр не может иметь регистратора так как заполняется сервисными фоновыми заданиями и по моему разными другими регистрами. В следствии чего писать туда можно(но не нужно) хоть кому. Это служебный регистр и есть средства его пересчитать, что удалит все "кривые записи".
Записи двоятся и троятся скорее всего по тому, что по этим записям при формировании отчета строятся соединения в запросе при формировании РЛ. Никакого бага здесь нет. Есть кривые исходные данные. Тоже самое касается упомянутого в (7)"Данные для подбора сотрудников" в модуле менеджера этого регистра есть метод который позволяет перезаполнить его по указанным сотрудникам.

(8) Да, согласен. Просто при удалении помеченных на удаление сотрудников расчетчик заменяла в регистрах сведений помеченных на удаление сотрудников рабочими, а не удаляла, потому что тупая обработка удаления помеченных объектов не умеет работать с регистрами сведений. Так в этих регистрах появились лишние и некорректные данные. при перепроведении исходных документов обновляются правильные записи, а лишние могут и проигнорироваться. Так что иногда и руками можно залезть, зная, что исходные данные верные, тем более что некоторые документы нельзя перепроводить из-за их фиксации.

(8) Как скажете... не баг, так не баг...
Добавил третью запись - р/л вырос уже в 9 раз.
Добавил 4-ю - в 16 раз.
Добавил 5-ю - в 25 раз.

Интересно )
В р/л собирается N² дней и сумм, где N - число записей регистра "Плановый ФОТ Итоги" с отличающимися тарифными ставками.

Если это не баг, то я Жан-Поль Бельмондо )

хочешь быстро и много заработать - спроси меня как! (с) )))

Давайте подумаем. Где-то в кишочках кода р/л вместо выбора одной записи стоит обход всех с суммированием и счётчиком, сориентированным на количество записей.

1. Одна запись. После прохода Счётчик = 1. Цикл закончен.
2. Две записи. Первый проход: Счётчик = 1, но Число записей = 2. Пока удвоение после суммирования. Второй проход: Счётчик = 2 = Число Записей. Цикл закончен. Итоговое учетверение.
3. Три записи. Вальс: 1-2-3, 1-2-3, 1-2-3. Счётчик = 3 = Число записей. Итоговое удевятерение.
4. и т.д. Точный квадрат.

(6) насчет перфекционизма, не могу понять одну мелочь в запросе, который формирует ВТКадровыеДанныеСотрудников. В нём
формируется ВТСведенияКадровойИсторииСотрудников,
в которой в самом конце подзапроса есть условие
    И (РегистрСведений.Сотрудник = ИзмеренияДаты.Сотрудник)
    И (РегистрСведений.ФизическоеЛицо = ИзмеренияДаты.Сотрудник.ФизическоеЛицо)

Зачем писать ИзмеренияДаты.Сотрудник.ФизическоеЛицо, если у таблицы ИзмеренияДаты уже есть реквизит ФизическоеЛицо?

Из-за этой мелочи запрос не перехватывался, после замены
ИзмеренияДаты.ФизическоеЛицо он сработал, и ошибка была найдена. только кучу времени убил.

(10)>Добавил третью запись - р/л вырос уже в 9 раз.
Ждем поста: "Добавил запись в регистр расчетов, увеличилась сумма в расчетном листке. Что за баг и как обойти". Если это баг подсказываю решение: Не создавай ненужных записей, там где этих записей не должно быть. Я уже написал, записи в этот регистр руками добавлять не нужно. Но если уж так вышло, что они там кривые, можно убить и пересчитать. Или просто пересчитать. И после этого не создавать ситуаций в исходных данных которые приводят к ошибкам в отчетах. Я не понимаю почему это простое решение не укладывается в твоей голове жан поль

>Если это не баг, то я Жан-Поль Бельмондо )
Хорошо.  Хоть горшком назови. Только в печь не ставь.

(14) И после этого не создавать ситуаций в исходных данных которые приводят к ошибкам в отчетах
В жизни такое неосуществимо. Всегда существовали, существуют и будут существовать неправильные действия расчётчиц.
Хорошо, баг - слишком сильный термин. Будем считать отсутствие "защиты от дурака" недоработкой.

Почему это важно в данном случае?
Потому что речь идёт о деньгах. Когда много сотрудников, то расчётчица вполне может не увидеть учетверение зарплаты у одного кекса, особенно, если это была маленькая зарплата за несколько отработанных дней/часов в данном месяце. В результате деньги уйдут работнику на карточку и потом попробуйте их вернуть/удержать у малооплачиваемого сотрудника. Крик будет до небес.

Вывод: программисту-перфекционисту надо прописать в коде вывод сообщения об ошибке по данному сотруднику, когда алгоритм наталкивается в РС ПлановыйФОТИтоги на пересечение записей во времени с различной тарифной ставкой.

(15)Тогда невозможно в принципе получить рабочую систему. Расчетчик просто внесет на один ноль больше или на один ноль меньше цифру разнося премию. Пусть 1С и это проверяет тоже. Ведь крику будет до небес. Я думаю это самый правильный аргумент, чтобы свои ошибки перевесить на кого-то другого.

> надо прописать в коде вывод сообщения об ошибке по данному сотруднику, когда алгоритм наталкивается в РС
А когда документ заполняется и рассчитывается в фоновом режиме и пользователя просто нет, кому это сообщение показывать? А когда это ожидаемое поведение и в регистре должно быть несколько записей, что делать?
Никто не против. Если ты вдруг обнаружил мельницу, то есть поведение которое можно сделать лучше, следует вооружиться отладчиком, разобрать код и сделать его лучше. У меня есть доступ к партнерской подписке. Я попробую отправить твое предложение об улучшении. Я не работаю с ЗУП уже больше года. Но помню, что там не просто так может быть несколько записей в одном периоде.

Эх, вы.
Берете ваш конечный запрос, который увеличивает суммы.
Удаляете соединения в нем, смотрите на каком перестанет 8рить.
Далее копаете в сторону того регистра или временной таблицы.
Всегда так делал, всегда помогало.

(18)>Берете ваш конечный запрос, который увеличивает суммы.
Удаляете соединения в нем, смотрите на каком перестанет 8рить.Далее...

Слишком длинно написал неуниверсально. Надо вот так: Эх вы берете запрос. Анализируете. Всегда помогало.

(18) Ну так в том-то и вопрос, что запрос трудно достать. В конфигурации его нет, надо ловить его программно, а он не ловится, потому что в нем ошибка. Повезло, что она легко исправилась, тогда запрос сработал, и даже никакие соединения убирать не надо, достаточно посмотреть, какая ВТ содержит нужные данные и с какими регистрами она связана. Дело в том, что простые динамические списки перехватываются без проблем, а тут сложный список - в нем идет подготовка временных таблиц, получается нужный результат, а потом таблицы уничтожаются. текст запроса затирается. и мы видим при перехвате урезанный запрос, который получил нужные данные и все за собой удалил. То есть надо лезть в код и ловить запрос по пути. И промежуточный запрос не хочет формироваться в консоли запросов. Там что-то связано с типизацией, при перехвате запроса она как-то слетает. Обычно достаточно убрать из входных данных запроса в колонках таблиц составность (null), но тут это не помогло. А в ERP, например, так просто и не разберешься, что можно убирать, а что нельзя, там море сложных типов данных.

(19) типа я в ЗУПе 3.1 не копался? копался и даже собирал этот запрос с временными таблицами, использовал консоль Кораблева, которую он удалил почему-то с ИС.

(20) пиздоус, как говорится, как тяжко в 1Се.
уже забыл совсем. ну да, если там портянка длиннющая перехватывается, то делать нехер, придется лезть.
другое дело - как они такое в прод катнули, типа в 1С тестирование отсутствует как явление? у них же может быть набор реальных данных с базок, которые им клиенты посылают.

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