При работе с конфигурацией 1С:Зарплата и Управление Персоналом (ЗУП) версии 3.1.27.291 (и, возможно, других версий), пользователи могут столкнуться с аномальным поведением отчета "Численность и текучесть кадров". В частности, возникает проблема, когда для сотрудника, получившего инвалидность, списочная численность в отчете отражается как 2 вместо 1. Эта ошибка особенно заметна при формировании отчета за период, который включает месяц получения инвалидности, идущий с начала года. Давайте подробно разберем эту проблему и найдем пути ее решения.
Представим ситуацию: в июле месяце сотрудник получает инвалидность, и в программе 1С:ЗУП на него вносится соответствующая справка. При формировании отчета "Численность и текучесть кадров" за период с начала года, если выполнить расшифровку по этому сотруднику, то мы обнаружим, что списочная численность и средняя численность по нему задваиваются, отображая значение "2" вместо корректного "1". При этом до ввода сведений об инвалидности или при формировании отчета за короткий период (например, только за третий квартал), показатели численности отображаются верно. Важно отметить, что у других сотрудников с аналогичными кадровыми событиями такого поведения может не наблюдаться, что делает проблему специфичной для условий получения инвалидности и взаимодействия со схемой компоновки данных (СКД) отчета.
Прежде чем углубляться в отладку, важно понимать, что проблема задвоения численности при вводе сведений об инвалидности является зарегистрированной ошибкой 1С под номером 50011763. Эта ошибка была исправлена в тестовой версии ЗУП 3.1.10. Несмотря на то, что наша версия (3.1.27.291) значительно новее, мы видим, что проблема может вновь проявляться, что указывает на возможность регрессии или возникновения новых условий для ее появления.
Также существуют общие причины некорректного отображения численности, которые мы должны исключить:
Для того чтобы досконально разобраться в причинах задвоения данных, нам потребуется использовать мощные инструменты отладки, предоставляемые платформой 1С. Проанализируем процесс отладки отчета "Численность и текучесть кадров" по шагам.
Первый шаг — это извлечение текста запроса, который формирует данные для отчета "Численность и текучесть кадров". Для этого нам необходимо зайти в режим редактирования схемы компоновки данных (СКД) данного отчета. Обычно это делается через кнопку "Настройки" отчета, затем "Прочее" -> "Изменить вариант отчета" или "Дополнительные настройки", где можно найти доступ к схеме компоновки данных. Внутри СКД нас интересует вкладка "Наборы данных". Мы увидим один или несколько наборов данных, обычно типа "Запрос".
Запросы в отчетах 1С часто используют так называемые "виртуальные таблицы" (представления). Эти представления упрощают написание запросов, но для детальной отладки удобнее работать с полноценным текстом запроса, где все виртуальные таблицы раскрыты до прямых обращений к реальным таблицам базы данных. Для этого в 1С существует специальная служебная процедура.
Воспользуемся функцией ЗарплатаКадрыОбщиеНаборыДанных.ЗаменитьЗапросыКПредставлениямВиртуальныхТаблиц(). Эта процедура принимает на вход текст запроса, использующего виртуальные таблицы, и возвращает его преобразованную версию, где все представления заменены на реальные таблицы и их соединения. Мы можем выполнить этот код, например, в консоли запросов или через обработку для отладки.
Пример использования:
// Предположим, у нас есть текст запроса из СКД, содержащий виртуальные таблицы
ТекстЗапросаНаПредставлениях = "
|ВЫБРАТЬ
| Сотрудники.Ссылка КАК Сотрудник,
| Сотрудники.Период КАК Период
|ИЗ
| РегистрСведений.СотрудникиОрганизаций.СрезПоследних(&Дата, Сотрудник = &Сотрудник) КАК Сотрудники
|ГДЕ
| Сотрудники.Период <= &Дата
|";
// Преобразуем запрос, чтобы раскрыть виртуальные таблицы
ТекстПолноценногоЗапроса = ЗарплатаКадрыОбщиеНаборыДанных.ЗаменитьЗапросыКПредставлениямВиртуальныхТаблиц(ТекстЗапросаНаПредставлениях);
// Теперь ТекстПолноценногоЗапроса можно выполнять в консоли запросов
// и анализировать его структуру и временные таблицы.
Используя этот метод, мы получаем полный текст запроса, который система фактически выполняет для сбора данных, что значительно упрощает дальнейший анализ.
Получив полноценный текст запроса, мы открываем его в консоли запросов (это специальный инструмент для выполнения и анализа запросов в 1С). Для того чтобы сузить область поиска проблемы и сосредоточиться на конкретном сотруднике, по которому возникает задвоение, мы должны параметризовать запрос.
Добавим в запрос условие ГДЕ Бла.Сотрудник = &Сотрудник, где Бла - это псевдоним таблицы, содержащей ссылку на сотрудника. Мы заменим &Сотрудник на ссылку на проблемного сотрудника. После этого выполняем запрос в консоли и внимательно изучаем его результаты, а также структуру временных таблиц, которые формируются в процессе выполнения. Нас особенно интересуют секции ОБЪЕДИНИТЬ ВСЕ или ОБЪЕДИНЕНИЕ, так как именно в них чаще всего происходит задвоение данных, если один и тот же набор записей попадает из разных ветвей объединения.
В процессе детального анализа схемы компоновки данных и запросов отчета, автор проблемы самостоятельно обнаружил корень ошибки. Оказалось, что в СКД отчета "Численность и текучесть кадров", в секции, касающейся выборки данных по инвалидности, использовалось объединение запросов (ОБЪЕДИНИТЬ ВСЕ). При этом запросы, участвующие в объединении, были очень похожи друг на друга. Один из них, по всей видимости, предназначался для получения данных "срезом последних" или для какой-то агрегированной таблицы, а другой — для более детального табличного представления. На первый взгляд, эти запросы могли казаться идентичными или дополняющими друг друга, однако при выборке данных для конкретного сотрудника с инвалидностью они оба возвращали запись о его наличии, что приводило к дублированию. Таким образом, в результате объединения в итоговую выборку попадало две записи для одного и того же сотрудника в один и тот же месяц, что затем проявлялось как задвоенная списочная численность.
Это подтверждает, что даже в новых версиях платформы могут возникать логические ошибки в СКД отчетов, особенно в сложных случаях с различными условиями (как введение инвалидности), которые не всегда корректно обрабатываются множественными источниками данных в объединениях.
Выявив причину задвоения, мы можем приступить к корректировке схемы компоновки данных отчета. Это потребует некоторых навыков работы с СКД, но является прямым путем к устранению ошибки.
Откройте схему компоновки данных отчета "Численность и текучесть кадров" (путь: Отчеты -> Дополнительные отчеты и обработки -> найти "Численность и текучесть кадров", или через Конфигуратор -> Отчеты -> ЧисленностьИТекучестьКадров). Перейдите на вкладку "Наборы данных". Найдите набор данных, который использует несколько запросов, объединенных оператором ОБЪЕДИНИТЬ ВСЕ, и который, как мы выяснили, отвечает за сбор сведений об инвалидности. Обычно это будет запрос, обращающийся к регистрам сведений или документам, где фиксируется информация об инвалидности сотрудника.
Внимательно изучите структуру каждого запроса в объединении. Ваша задача — определить, какой из них является лишним, то есть дублирует данные, которые уже получены другим запросом. Если запросы идентичны или один из них является избыточным для данной логики, он подлежит удалению или изменению.
После того как вы идентифицировали дублирующий запрос, его необходимо исключить из объединения. Это можно сделать одним из следующих способов:
ВЫБРАТЬ ... ИЗ ... ГДЕ ... вместе с предшествующим ему оператором ОБЪЕДИНИТЬ ВСЕ.
ОБЪЕДЕНИТЬ ВСЕ перед ним) поставьте две косые черты //. Это временно отключит его выполнение, позволяя легко вернуть его обратно при необходимости.
// ... другие части запроса
// ОБЪЕДИНИТЬ ВСЕ
// ВЫБРАТЬ
// Т1.Сотрудник КАК Сотрудник,
// Т1.Период КАК Период
// ИЗ
// РегистрСведений.СведенияОбИнвалидности.СрезПоследних(&Дата, ...) КАК Т1
// ... другие части запроса
ГДЕ или набор полей ВЫБРАТЬ в одном из запросов, чтобы избежать дублирования без полного удаления данных. Однако в данном случае, с учетом специфики "задвоения" и "объединения", полное удаление одного из похожих запросов чаще всего является прямым решением.
Важно: При изменении стандартных отчетов рекомендуется сохранять их как "Дополнительные отчеты" или создавать "Новый вариант отчета", чтобы не потерять изменения при обновлении конфигурации и сохранить возможность вернуться к стандартной версии.
После внесения изменений в схему СКД, сохраните отчет и заново сформируйте его. Обязательно проверьте его для того же проблемного сотрудника и за тот же период (с начала года), чтобы убедиться, что списочная численность теперь отображается корректно (1 вместо 2). Также желательно выборочно проверить других сотрудников и другие периоды, чтобы убедиться, что внесенные изменения не привели к новым ошибкам.
Для корректного функционирования всех отчетов и расчетов в 1С:ЗУП, связанных с инвалидностью, важно правильно вносить и обрабатывать эти сведения:
Сведения об инвалидности вносятся в карточке сотрудника или физического лица. Мы заходим в раздел Кадры, затем по ссылке Страхование. Здесь необходимо установить флажок "Есть справка об инвалидности" и тщательно заполнить все поля:
После корректного ввода данных об инвалидности, система автоматически применяет льготный тариф при расчете страховых взносов (например, взносы на "травматизм" будут рассчитываться по ставке 60% от установленного тарифа). Если начисления уже были произведены до ввода справки, мы можем скорректировать взносы с помощью кнопки "Пересчитать взносы" в соответствующем документе начисления или в рабочем месте "Расчет зарплаты".
Сведения об инвалидности также автоматически используются при заполнении различных отчетных форм, таких как раздел 2 формы ЕФС-1, что обеспечивает соблюдение законодательных требований.
Если отчет "Численность и текучесть кадров" все еще вызывает сомнения или выдает некорректные данные по инвалидам, мы можем использовать другие стандартные отчеты для перепроверки. Например, отчеты "Штатные сотрудники" или "Личные данные сотрудников" позволяют добавить в свои настройки поле "Инвалидность" и получить корректный список сотрудников-инвалидов и их численность.
Таким образом, хотя проблема задвоения численности сотрудников-инвалидов в отчете "Численность и текучесть кадров" является специфической ошибкой в логике СКД, ее можно успешно диагностировать и устранить с помощью инструментов отладки и прямой корректировки запросов. Важно подходить к таким изменениям осознанно, предварительно создавая резервные копии или варианты отчетов, чтобы обеспечить стабильность работы системы.