В процессе работы с программой 1С:Зарплата и Управление Персоналом 3.1 (особенно в релизах ветки 3.1.14) пользователи и администраторы часто сталкиваются с неприятной ситуацией: встроенный механизм «Контроль ведения учета» начинает выдавать предупреждения о том, что начисленный оклад сотрудника превышает размер его планового оклада. При этом фактический расчет в документе «Начисление зарплаты и взносов» выполнен абсолютно корректно, и никаких реальных отклонений нет.
В данной статье мы подробно разберем, почему возникает это ложное срабатывание, проанализируем программный код, вызывающий ошибку, и рассмотрим несколько способов решения проблемы — от быстрого исправления в коде до использования механизмов расширений.
Для начала проанализируем ситуацию. Механизм контроля предназначен для того, чтобы бухгалтер мог оперативно заметить ошибки ручного ввода или сбои в алгоритмах, когда сотруднику случайно начислили больше, чем положено по его кадровым приказам. Однако в алгоритме самой проверки была допущена техническая неточность.
Проблема кроется в процедуре РезультатПроверкиПревышенияПлановогоОкладаСотрудников, которая расположена в общем модуле ПлановыеНачисленияСотрудниковПроверки. Ошибка заключается в некорректном сопоставлении данных в запросе. Программа пытается связать таблицу фактически начисленных сумм с таблицей плановых показателей, используя поле НомерСтроки.
Важный нюанс: в документах 1С:ЗУП НомерСтроки — это порядковый номер записи в конкретной табличной части документа. Если у сотрудника в одном месяце есть несколько видов начислений (например, оклад, надбавка за выслугу лет, районный коэффициент), то номера строк в таблице «Начисления» и в таблице «Показатели начислений» могут не совпадать. Для корректной связи между конкретной строкой начисления и её показателями (значением оклада) в системе предусмотрен специальный реквизит — ИдентификаторСтроки. Использование простого номера строки вместо уникального идентификатора внутри документа и приводит к тому, что программа сравнивает оклад с показателями других начислений, выдавая ложную ошибку.
Если ваша конфигурация находится на поддержке с возможностью изменения, мы можем внести исправление непосредственно в код модуля. Рассмотрим подробнее, что именно нужно изменить.
Найдем в общем модуле ПлановыеНачисленияСотрудниковПроверки процедуру РезультатПроверкиПревышенияПлановогоОкладаСотрудников. Внутри этой процедуры формируется текст запроса. Нам необходимо найти блок соединения таблиц Начисления и ЗначенияПоказателейНачислений.
Проанализируем фрагмент кода, который подлежит замене. В исходном варианте условие соединения выглядит так:
| И (Начисления.НомерСтроки = ЗначенияПоказателейНачислений.НомерСтроки)
Это условие является ошибочным. Нам необходимо заменить его на использование идентификатора, который гарантирует связь между начислением и его индивидуальными показателями. Исправленная строка должна выглядеть следующим образом:
| И (Начисления.НомерСтроки = ЗначенияПоказателейНачислений.ИдентификаторСтроки)
После внесения этого изменения и сохранения конфигурации проверка в «Контроле ведения учета» начнет работать корректно для большинства стандартных случаев.
Многие специалисты предпочитают не вносить изменения в основную конфигурацию, чтобы не усложнять процесс последующих обновлений. В таком случае мы рекомендуем использовать механизм расширений. Рассмотрим, как это реализовать:
ПлановыеНачисленияСотрудниковПроверки.РезультатПроверкиПревышенияПлановогоОкладаСотрудников в расширение, используя аннотацию &Вместо.НомерСтроки на ИдентификаторСтроки).Существует и более радикальный подход, который упоминали участники обсуждения: если проверка кажется избыточной или мешает работе из-за своей примитивности (например, она плохо отрабатывает изменения оклада в середине месяца), в расширении можно просто «обнулить» тело этой процедуры. Тогда проверка просто перестанет выполняться, не мешая пользователям работать.
Поскольку данная проблема официально признана разработчиками (ошибка номер 10223344), самым правильным и безопасным методом будет обновление программы. Разберем, в каких версиях это было исправлено:
Если оперативное обновление невозможно, проверьте наличие патча EF_000069096 в разделе «Обслуживание» — «Обновление программы» — «Установленные исправления (патчи)». Если база подключена к интернет-поддержке, этот патч мог установиться автоматически, решив проблему без вмешательства программиста.
Проанализируем ситуацию, когда код исправлен, но предупреждение все равно появляется. Это часто случается в «сложных» месяцах, когда у сотрудника происходят кадровые изменения. Например, если с 15 числа месяца сотруднику увеличили оклад.
В документе «Начисление зарплаты и взносов» в таком случае возникнет две строки начисления оклада за разные периоды. Алгоритм проверки в текущей реализации ЗУП 3.1 достаточно упрощен: он может не всегда корректно сопоставлять доли планового ФОТ и фактическое начисление при частичной отработке периода. В таких случаях стоит объяснить пользователям (бухгалтерам), что данные проверки носят информативный характер. Если расчетные листки и своды сходятся с ожиданиями, эти предупреждения в «Контроле ведения учета» можно игнорировать.
Резюме: Мы выяснили, что ошибка носит чисто технический характер и связана с неверным полем связи в SQL-запросе внутри конфигурации. Исправление строки кода или установка официального патча полностью решают проблему ложных уведомлений для стандартных ситуаций начисления зарплаты.