В процессе работы с программой 1С:Зарплата и кадры государственного учреждения 3.1 (ЗиКГУ) многие пользователи сталкиваются с методической сложностью: при попытке отсортировать расчетные листки по табельным номерам система начинает «дробить» печатные формы. Вместо одного листка, объединяющего основное место работы и внутреннее совместительство, программа выдает несколько отдельных страниц на каждого Сотрудника.
В данной статье мы подробно разберем, почему стандартные механизмы сортировки ведут себя именно так, проанализируем внутреннюю структуру данных отчета и рассмотрим несколько способов решения этой задачи — от простых настроек в пользовательском режиме до внесения изменений в систему компоновки данных (СКД).
Для начала проанализируем ситуацию с точки зрения архитектуры данных 1С. В конфигурациях на платформе 8.3 (ЗУП, ЗиКГУ) разделяются понятия Физическое лицо и Сотрудник. У одного физического лица может быть несколько карточек сотрудников: одна для основной должности, другие — для внутреннего совместительства. У каждой такой карточки свой уникальный Табельный номер.
Типовой отчет «Расчетный листок» спроектирован так, чтобы собирать все начисления по человеку в одну форму. Это достигается за счет группировки данных по полю Физическое лицо. Когда мы включаем сортировку по полю Сотрудник.Табельный номер, система компоновки данных (СКД) получает противоречивые инструкции:
В результате алгоритм группировки часто «сбивается», и программа начинает выводить листки в порядке табельных номеров, игнорируя целостность данных по физическому лицу. Рассмотрим, как можно обойти это ограничение.
Рассмотрим подробнее возможность настройки отчета без программирования. В последних релизах ЗиКГУ 3.1 в расширенном режиме настроек можно добраться до реквизитов, которые не лежат «на поверхности».
Выполним следующие шаги:
Сотрудник.Табельный номер нам нужно найти поле, которое однозначно определяет основной табельный номер для всей группы. Для этого нажмем кнопку «Добавить» и в дереве выбора полей пройдем по следующему пути: Физическое лицо -> Основной сотрудник -> Табельный номер.Важный нюанс: Поле Основной сотрудник заполняется автоматически для тех физических лиц, у которых есть действующие трудовые договоры. Сортировка по этому полю позволит системе выстраивать цепочку листков, ориентируясь только на номер основной карточки сотрудника, при этом не разделяя данные совместителей. Проанализируем результат: теперь записи совместителей будут «подтягиваться» к основному сотруднику, так как для всей группы ключом сортировки будет выступать один и тот же номер.
Выясним причину, по которой даже при включении правильной сортировки номера могут идти не по порядку (например: 1, 10, 100, 2, 20). В системе 1С Табельный номер — это строка. Строковая сортировка работает посимвольно.
Для корректного вывода без изменения конфигурации можно использовать следующий прием: приведите все табельные номера к одинаковой длине с помощью ведущих нулей. Например, номер 5 должен выглядеть как 00005. В этом случае сортировка будет работать математически верно. Если в вашей базе номера уже введены в разном формате, можно воспользоваться обработкой «Групповое изменение реквизитов», чтобы добавить префиксы или нули.
Если сортировка через поле Основной сотрудник по каким-то причинам не срабатывает (например, в базе сложная история перемещений), можно применить механизм дополнительных реквизитов. Разберем этот метод по шагам:
Физические лица создадим новый реквизит, назовем его, например, «НомерДляСортировки» (тип — Число или Строка).Физическое лицо.НомерДляСортировки.Поскольку этот реквизит привязан напрямую к объекту Физическое лицо, по которому идет группировка в отчете, конфликт между группировкой и сортировкой будет полностью исключен.
Если пользовательские настройки не помогают, или требуется автоматизировать процесс без ручного заполнения доп. реквизитов, необходимо вмешаться в работу Системы компоновки данных. Рассмотрим пример того, как это реализуется в коде или через схему компоновки.
Основная задача — добавить в набор данных запрос или вычисляемое поле, которое будет возвращать табельный номер основного сотрудника в числовом виде. Посмотрим на пример выражения для вычисляемого поля в СКД:
// В СКД создаем вычисляемое поле "ТабельныйНомерДляСортировки"
// Выражение для поля может выглядеть следующим образом:
ВЫБОР
КОГДА ФизическоеЛицо.ОсновнойСотрудник.Код ЕСТЬ NULL
ТОГДА "0"
ИНАЧЕ ФизическоеЛицо.ОсновнойСотрудник.Код
КОНЕЦ
После добавления такого поля в схему, мы можем настроить группировку в СКД. Проанализируем структуру группировок типового отчета:
Физическое лицо.Нам необходимо установить сортировку именно на уровне Верхней группировки (по физлицу). Если мы установим сортировку на уровне «Отчет», она может применяться к детальным записям, что снова приведет к их разделению. Правильная настройка выглядит так: выделяем группировку по Физическое лицо, заходим в ее свойства и на вкладке «Сортировка» указываем наш реквизит.
Выясним, какой из методов будет наиболее эффективным в конкретной ситуации:
Основной сотрудник. Это не требует программирования и легко поддерживается при обновлениях.Подводя итог, отметим, что проблема сортировки расчетных листков в ЗиКГУ 3.1 — это не ошибка программы, а следствие гибкости учета по нескольким местам работы. Используя предложенные методики настройки Физическое лицо.Основной сотрудник.Табельный номер или механизмы Дополнительных реквизитов, вы сможете добиться требуемого порядка документов в пачке для выдачи сотрудникам.