При доработке типовых отчетов в 1С:Зарплата и управление персоналом 3.1, таких как Анализ начислений и удержаний, программисты часто сталкиваются с неприятным эффектом: если у сотрудника за один и тот же период есть несколько начислений с абсолютно одинаковой суммой, в итоговом отчете отображается только одна из них. Ситуация становится еще более странной, когда при изменении суммы хотя бы на один рубль проблема исчезает, и обе строки корректно выводятся в отчет. Рассмотрим подробно, почему это происходит и как правильно настроить схему компоновки данных (СКД), чтобы избежать «схлопывания» данных.
Проанализируем архитектуру отчета. Типовой отчет Анализ начислений и удержаний базируется на нескольких наборах данных, которые объединяются по полям Сотрудник, Организация и Период. Когда мы решаем добавить в него дополнительные колонки, например, по страховым взносам (ПФР, ФСС, ФФОМС), мы обычно добавляем новый набор данных-запрос к регистру накопления СтраховыеВзносыПоФизическимЛицам и связываем его с основным набором через Левое соединение.
Выясним причину проблемы. Система компоновки данных 1С при выполнении запросов стремится оптимизировать выборку. Если в настройках полей или связей наборов данных не указаны поля, обеспечивающие уникальность каждой строки (суррогатные ключи), СКД может применить неявную группировку. Если у нас есть две записи:
При добавлении связи со страховыми взносами, которые в ЗУП 3.1 чаще всего рассчитываются одной общей строкой за месяц в документе Начисление зарплаты и взносов, механизм соединения не может однозначно определить, к какому из двух начислений «прикрепить» взнос. В результате, если поля Регистратор или НомерСтроки не задействованы в группировках и не отмечены как обязательные, система воспринимает эти строки как идентичные дубли и объединяет их.
Самый надежный способ разделить одинаковые суммы — это включить в набор данных поля, которые делают каждую запись уникальной. Разберем по шагам, как это сделать в конструкторе схемы компоновки данных.
Во-первых, в запросе основного набора данных (где выбираются начисления) необходимо обязательно выбрать поле Регистратор. Даже если вы не планируете выводить его в пользовательские настройки отчета, оно должно присутствовать в выборке. Посмотрим на пример фрагмента запроса:
ВЫБРАТЬ
НачисленияУдержания.Сотрудник КАК Сотрудник,
НачисленияУдержания.Результат КАК СуммаНачисления,
НачисленияУдержания.Регистратор КАК Регистратор,
НачисленияУдержания.НомерСтроки КАК НомерСтроки,
НачисленияУдержания.Период КАК Период
ИЗ
РегистрНакопления.НачисленияУдержанияПоСотрудникам КАК НачисленияУдержания
Во-вторых, на вкладке Наборы данных для поля Регистратор и НомерСтроки нужно правильно настроить Роли. Укажите, что эти поля являются измерениями. Это даст системе понять, что записи с разными регистраторами — это разные данные, даже если все остальные показатели (сотрудник, сумма, период) совпадают.
Если отчет использует несколько наборов данных (например, один для начислений, другой для взносов), проанализируем вкладку Связи наборов данных. Часто ошибка кроется в том, что связь настроена только по физическому лицу. Рассмотрим правильную настройку связи:
Сотрудник = Сотрудник И Период = Период.Важный нюанс: Если взносы в базе рассчитаны одним документом за месяц, а начислений по договорам несколько, то при левом соединении сумма взноса может либо задублироваться (примениться к каждой строке начисления), либо «схлопнуть» начисления. Чтобы этого не произошло, для числовых полей взносов в выражении ресурсов используйте функции распределения или убедитесь, что группировка в отчете идет до уровня, на котором данные по взносам являются корректными.
Иногда при доработке запроса программисты по привычке добавляют ключевое слово РАЗЛИЧНЫЕ (или DISTINCT) в начало текста запроса, чтобы избежать дублей, возникающих из-за сложных соединений таблиц. Однако в контексте отчетов по начислениям это вредно. Выясним почему: если у сотрудника действительно два разных начисления по 100 000 рублей, оператор РАЗЛИЧНЫЕ удалит одно из них еще на этапе выполнения запроса к базе данных, так как строки будут идентичны по значениям полей.
Проанализируйте свой текст запроса и, если РАЗЛИЧНЫЕ присутствует, удалите его, обеспечив уникальность строк через добавление аналитики (ДокументОснование, Регистратор).
В некоторых версиях платформы 8.3.17 наблюдались специфические ошибки работы СКД при соединении наборов данных, когда в одном из наборов отсутствуют данные (значения NULL). Рассмотрим ситуацию: если для одного из начислений не найдены соответствующие страховые взносы, система может некорректно обрабатывать группировку строк.
Чтобы минимизировать влияние ошибок платформы, придерживайтесь следующих правил:
ЕСТЬNULL(СуммаВзноса, 0), чтобы гарантировать наличие числового значения для агрегатных функций.Подведем итог. Чтобы ваш доработанный отчет выводил все суммы корректно, проверьте следующие моменты:
Регистратор в основной запрос начислений?РАЗЛИЧНЫЕ в тексте запроса?СУММА()?Соблюдение этих правил гарантирует, что даже при полном совпадении сумм и периодов, каждое начисление будет учтено в итоговом результате отчета, обеспечивая точность бухгалтерского и управленческого учета в 1С:ЗУП 3.1.