Почему в отчете на СКД задваиваются данные по сотруднику в 1С:ЗУП 3?

Ситуация, когда отчет, построенный на Системе компоновки данных (СКД), выдает некорректные (задвоенные) результаты при абсолютно правильном тексте запроса, — одна из самых коварных в практике разработчика 1С. Особенно часто это встречается в конфигурации «Зарплата и управление персоналом 3.1», где учет пронизан множеством аналитических разрезов: КБК, статьи расходов, источники финансирования и статусы застрахованных лиц. Рассмотрим подробнее, почему возникают лишние строки и как их победить.

Анализируем разницу между запросом и компоновкой

Первым делом проанализируем важный симптом: если вы копируете запрос из схемы компоновки, вставляете его в Консоль запросов, и там данные отображаются корректно (без задвоений), значит, проблема кроется не в самом тексте SELECT, а в том, как процессор компоновки интерпретирует эти данные. СКД — это не просто способ выполнения запроса, это интеллектуальный движок, который сам достраивает соединения, группировки и итоги на основе настроек полей и связей.

Проверяем историю сотрудника и регистрацию в программе

Разберем ситуацию, упомянутую в обсуждении: сотрудник был уволен, а затем принят снова на то же физическое лицо. В 1С:ЗУП 3 это означает, что у одного Физлицо теперь есть два разных элемента в справочнике Сотрудники.

Проанализируем, как это влияет на отчет:

1. Если отчет строится в разрезе физических лиц, но запрос или связи наборов данных не учитывают конкретный объект Сотрудник, суммы по обоим местам работы могут суммироваться или дублироваться.
2. Выясним причину появления «пустого КБК». Часто это происходит из-за того, что по одному из «воплощений» сотрудника (старому или новому) данные по источникам финансирования не заполнены или заполнены некорректно.

Совет: Всегда проверяйте отчет в разрезе детальных записей с выводом поля Регистратор и ПериодСекунда. Это позволит точно увидеть, какой документ делает «лишнюю» запись.

Настройка ролей полей в СКД

Одной из самых частых причин задвоения являются неправильно настроенные Роли на закладке «Наборы данных». Когда мы выводим остатки или обороты по аналитике (например, КБК или Статья расходов), СКД ориентируется на роли полей.

Рассмотрим по шагам, что нужно проверить:

• Игнорирование NULL: Если для поля аналитики (КБК) не установлен флаг «Игнорировать NULL», СКД может воспринять отсутствие значения как отдельную категорию для группировки и попытаться соединить ее с другими наборами данных, что породит пустую строку.
• Обязательное поле: Если поле помечено как обязательное, компоновщик будет принудительно включать его в запрос, даже если оно не выбрано пользователем в настройках. Это может привести к неявному левому соединению, которое размножит строки.
• Роль «Без порядка»: Иногда для измерений регистров накопления стоит проверить корректность указания ролей. Если поле является измерением, убедитесь, что оно отмечено соответствующим образом.

Проблема периодичности регистров сведений

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

Посмотрим на пример типичной ошибки в соединении с виртуальной таблицей:

ВЫБРАТЬ
    Начисления.Сотрудник,
    Начисления.Результат,
    КадроваяИстория.Должность
ИЗ
    РегистрНакопления.НачисленияУдержанияПоСотрудникам КАК Начисления
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.КадроваяИсторияСотрудников.СрезПоследних(&Период, ) КАК КадроваяИстория
    ПО Начисления.Сотрудник = КадроваяИстория.Сотрудник

Если в КадроваяИстория на &Период окажется две записи по одному сотруднику за один день, сумма Результат удвоится. В СКД такие соединения часто происходят неявно через вкладку «Связи наборов данных». Обязательно добавляйте условия связи не только по сотруднику, но и по дате (периоду).

Аналитика «Статья расходов» и пустые значения

Выясним, откуда берется пустой КБК. В ЗУП 3 данные о финансировании часто «прилетают» из регистров накопления НачисленияУдержанияПоСотрудникам или ВзаиморасчетыС_Сотрудниками.

Проанализируем возможные сценарии:

1. Автоматические корректировки: При пересчетах прошлых периодов система может сторнировать сумму по одному КБК и начислить по другому. Если в отчете не выведен период регистрации, вы увидите две строки.
2. Распределение основного заработка: Если у сотрудника настроено распределение по КБК, но в каком-то документе (например, «Премия») аналитика не была заполнена вручную, она может остаться пустой, создавая ту самую «лишнюю» строку.

Специфика учета иностранных сотрудников

Как было замечено в сообщении форума, стоит обратить внимание на «иностранцев». У таких сотрудников часто меняется статус застрахованного лица (например, с «Временно пребывающий» на «Временно проживающий»). Эти данные хранятся в регистре сведений СтатусЗастрахованныхЛиц.

Если отчет пытается соединить данные о зарплате с этим регистром, и статус изменился внутри месяца, СКД может разбить одну строку начисления на две — по числу записей в регистре статусов. Чтобы этого избежать, при соединении наборов данных нужно использовать функцию ЕСТЬNULL или четко ограничивать выборку статуса концом расчетного периода.

Как проверить отчет и найти ошибку?

Разберем алгоритм поиска «виновника» задвоения:

1. Откройте настройки отчета и перейдите на уровень Детальные записи.
2. Добавьте в колонки поля: Регистратор, Период (день, секунда), Сотрудник.Ссылка, Статья расходов.
3. Посмотрите на записи с пустым КБК. Если у них один и тот же регистратор, что и у правильных записей, значит, проблема в самом документе или его проведении по регистрам.
4. Если же в детальных записях пустых строк нет, а в группировках они появляются — проблема 100% в Связях наборов данных или Ролях полей внутри схемы СКД.

Проанализируем вкладку «Связи наборов данных». Если вы соединяете Набор1 (Зарплата) и Набор2 (Кадровые данные), убедитесь, что в параметре связи Условие связи указано ограничение по дате, а не только по сотруднику. В противном случае СКД выполнит классическое Cross Join (декартово произведение) для каждой записи сотрудника с его историей.

Используя эти методы, мы сможем не только найти причину задвоения, но и глубже понять механику работы отчетов в ЗУП 3, что поможет избегать подобных ошибок в будущем.