Почему расчетный листок в 1С:ЗУП 3.1 увеличивает суммы и время в несколько раз?

Проблема, при которой расчетный листок в типовой конфигурации «Зарплата и управление персоналом 3.1» начинает «врать», увеличивая суммы начислений, количество дней и часов в 2, 4, 8 или даже более раз, является довольно распространенной. Ситуация выглядит пугающе: в регистрах расчета всё верно, документы проведены правильно, но в отчете суммы по конкретному сотруднику превращаются в миллионы. Разберем детально, почему это происходит и как это исправить.

Причина проблемы: эффект «декартова произведения»

Расчетный листок в ЗУП 3.1 — это не просто выборка из регистра расчета. Это сложнейший отчет, построенный на системе компоновки данных (СКД), который собирает информацию из десятков таблиц: начислений, удержаний, выплат, а также многочисленных технических регистров сведений, хранящих кадровые состояния, тарифные ставки и плановый ФОТ.

Проанализируем ситуацию: когда в одном из таких вспомогательных регистров по сотруднику на один и тот же период (месяц формирования отчета) приходится две или более записи, запрос отчета выполняет соединение таблиц. Если условия соединения допускают пересечение периодов, происходит размножение строк. Например, если в таблице начислений 10 строк, а в таблице кадровых данных из-за ошибки записи нашлось 2 строки на этот же период, на выходе мы получим 20 строк. Суммы, дни и часы при этом суммируются в ресурсах СКД, что и дает эффект удвоения, учетверения и так далее по геометрической прогрессии.

Регистры-виновники, которые нужно проверить в первую очередь

Как показывает практика и обсуждения специалистов, чаще всего «мусорные» записи появляются в следующих регистрах:

1. Плановый ФОТ Итоги. Это наиболее частый виновник. В этом регистре хранятся сведения о плановом заработке для быстрой работы отчетов. Если в нем есть пересекающиеся записи с разными значениями тарифной ставки хотя бы на копейку, отчет «раздувается».
2. Текущие кадровые данные сотрудников. Здесь хранятся актуальные сведения о позиции, подразделении и графике. Дубли в этом регистре приводят к задвоению строк в расчетном листке.
3. Текущая тарифная ставка сотрудников. Аналогично предыдущему, дублирование записей вызывает умножение сумм.
4. Данные для подбора сотрудников. Еще один технический регистр, ошибки в котором могут влиять на построение временных таблиц внутри запроса расчетного листка.

Рассмотрим пример математической зависимости, выявленной опытным путем: если добавить в регистр ПлановыйФОТИтоги лишние записи, сумма в листке будет расти пропорционально квадрату количества записей (N²), так как соединения происходят многократно на разных этапах запроса.

Как найти и исправить некорректные данные

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

Шаг 1. Пересчет планового ФОТ

Прежде чем приступать к ручному удалению записей, попробуем воспользоваться штатным механизмом исправления. В конфигурациях на платформе 8.3 предусмотрена процедура пересчета служебных данных. Перейдите в раздел Администрирование — Обслуживание — Корректировка данных и найдите пункт Пересчет планового ФОТ. Выполните его для проблемного сотрудника. Это часто помогает очистить регистр ПлановыйФОТИтоги от ошибочных записей, созданных программными сбоями.

Шаг 2. Проверка и очистка регистров вручную

Если автоматический пересчет не помог, проанализируем записи в регистрах через «Функции для технического специалиста». Нам нужно проверить:

• Регистр сведений Текущие кадровые данные сотрудников
• Регистр сведений Текущая тарифная ставка сотрудников

Ищите записи, где один и тот же сотрудник фигурирует дважды с пересекающимися периодами. Часто такая ситуация возникает после использования обработки «Поиск и удаление дублей», когда ссылки были заменены, но записи в независимых регистрах не «схлопнулись» автоматически.

Шаг 3. Анализ регистра «Плановый ФОТ Итоги»

Этот регистр не имеет регистратора, поэтому его можно редактировать напрямую (хотя это крайняя мера). Рассмотрим ситуацию, когда ошибка возникает из-за разницы в датах окончания записей. Если дата окончания старой записи пересекается с датой начала новой хотя бы на одну секунду (например, 30.09.2023 23:59:59 и 30.09.2023 23:59:59), отчет может учетверить данные. Убедитесь, что записи идут строго последовательно.

Сложности программного анализа запроса

Проанализируем ситуацию со стороны разработчика. Почему стандартный расчетный листок сложно отладить в консоли запросов? Дело в том, что формирование данных происходит программно через вызов процедур общего модуля. Типовой вызов выглядит так:

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

Внутри этого процесса создается ПроцессорКомпоновкиДанных, в который передаются внешние наборы данных. Основная сложность заключается в том, что запрос содержит около 3000 строк и активно использует временные таблицы, которые уничтожаются сразу после вывода данных. Чтобы «перехватить» такой запрос, рекомендуется модифицировать код в месте инициализации процессора вывода:

// В месте получения данных отчета
ПроцессорВывода.Вывести(ПроцессорКомпоновки, Истина);
// В этой точке можно выгрузить ДанныеОтчета (ДеревоЗначений) в таблицу и проанализировать структуру строк.

Если вы пытаетесь повторить формирование программно, как в примере ниже, данные могут быть верными, потому что вы не используете те же настройки или внешние наборы данных, что и типовой отчет:

ОбщегоНазначенияКлиентСервер.УстановитьЭлементОтбора(НастройкиОтчета.Отбор, "ФизическоеЛицо", СписокСотрудников, ВидСравненияКомпоновкиДанных.ВСписке, , Истина);
ОтчетОбъект.КомпоновщикНастроек.ЗагрузитьНастройки(НастройкиОтчета);
// ... формирование макета и процессора ...

Различие в результатах между вашим кодом и типовым отчетом подтверждает, что проблема кроется в специфических параметрах или соединениях с кадровыми регистрами, которые типовой отчет подключает «под капотом» для формирования шапок, группировок и условий по ФОТ.

Выводы и рекомендации

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

Для решения проблемы:

1. Проверьте регистр ПлановыйФОТИтоги на наличие пересекающихся записей по сотруднику.
2. Воспользуйтесь штатным сервисом «Пересчет планового ФОТ».
3. Просмотрите кадровые регистры (Текущие кадровые данные) на предмет дублей после объединения физлиц.
4. Если вы программист — используйте консоль запросов с возможностью перехвата временных таблиц через МенеджерВременныхТаблиц, чтобы увидеть, в какой именно ВТ (например, ВТКадровыеДанныеСотрудников) происходит размножение строк.

Важно помнить, что расчетный листок — это лицо работы бухгалтерии, и подобные «глюки» могут привести к реальным финансовым ошибкам при выплате зарплаты, если расчетчик не заметит аномалию вовремя. Поэтому контроль чистоты технических регистров в ЗУП 3.1 — важная часть администрирования системы.