Почему зависает и долго рассчитывается документ «Начисление зарплаты и взносов» при повторном расчете?

← На главную

Проблема низкой производительности и зависания системы при заполнении и расчете документа НачислениеЗарплатыИВзносов — одна из самых частых и болезненных проблем, с которой сталкиваются расчетчики и программисты 1С в крупных базах «1С:Зарплата и управление персоналом 3» (ЗУП) и «1С:ERP Управление предприятием». Процесс расчета может занимать от нескольких часов до суток, парализуя работу расчетного отдела, особенно в периоды закрытия месяца.

В этой статье мы подробно разберем, почему возникает данная проблема, как устроен внутренний механизм платформы, приводящий к зацикливанию запросов, и рассмотрим пошаговые методы оптимизации системы — от простых пользовательских настроек до глубоких технических манипуляций на уровне СУБД и программного кода.

В чем причина зависания: разбираем техническую сторону

Давайте проанализируем стандартный сценарий работы пользователей. Расчетчик заполняет документ НачислениеЗарплатыИВзносов, проводит его для предварительного анализа. После этого в базу вводятся новые документы задним числом (например, ДанныеДляРасчетаЗарплаты для начисления цеховой премии, новые больничные листы или кадровые переводы). Чтобы учесть эти изменения, расчетчик запускает повторный расчет или пытается пересчитать документ начисления. Именно на этом этапе программа «подвисает».

Причиной такого поведения является служебный регистр сведений ПредварительныеПерерасчеты. Этот регистр предназначен для отслеживания любых изменений, которые потенциально могут повлиять на результаты расчета прошлых или текущих периодов. Когда в систему вводятся новые первичные документы после проведения основного начисления, программа автоматически делает записи в этот регистр.

При повторном заполнении или расчете документа НачислениеЗарплатыИВзносов система обращается к таблицам регистра ПредварительныеПерерасчеты, чтобы определить список сотрудников, по которым требуется выполнить доначисления. В некоторых релизах конфигураций (особенно при большом объеме данных или возникновении логических коллизий в базе) запрос платформы выполняет неоптимальное соединение таблицы этого регистра самой с собой. В результате СУБД уходит в бесконечный цикл обработки запроса, загружая процессор сервера на 100%, а для пользователя процесс выглядит как глухое зависание программы.

Бизнес-контекст: почему пользователи работают именно так

Часто программисты или системные администраторы пытаются обвинить пользователей в нерациональном ведении учета, утверждая, что нельзя сначала рассчитывать зарплату, а потом вводить первичные данные. Однако на практике существует масса объективных причин для подобного сценария:

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

Программа должна стабильно отрабатывать стандартный функционал перерасчета, независимо от последовательности ввода документов пользователями. Разберем по шагам, как решить проблему зависания.

Решение 1. Включение разделения документов начисления и перерасчета

Самый эффективный и быстрый способ разгрузить документ начисления зарплаты — это разделение основного расчета и механизмов доначисления за прошлые периоды. По умолчанию система пытается рассчитать все корректировки «на лету» прямо внутри текущего документа НачислениеЗарплатыИВзносов на специальной вкладке «Доначисления, перерасчеты».

Для оптимизации этого процесса выполним следующую настройку:

Перейдем в раздел меню Настройка, далее выберем пункт Расчет зарплаты.
Найдем и установим флаг (галочку) «Выполнять доначисление и перерасчет отдельным документом».

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

Решение 2. Безопасная очистка регистра через интерфейс «Перерасчеты»

Если зависание уже произошло, а перерасчет текущего месяца заблокирован, необходимо очистить проблемные записи. Прямое удаление данных из регистра сведений через обработку или «Функции для технического специалиста» не рекомендуется, так как можно потерять важную информацию о реальных недоплатах сотрудникам. Вместо этого воспользуемся штатным сервисом программы:

Перейдем в раздел Зарплата — подраздел Сервис — пункт Перерасчеты.
Перед нами откроется форма, в которой наглядно сгруппированы все зарегистрированные в системе необходимости перерасчетов по сотрудникам, месяцам и документам-основаниям.
Проанализируем записи. Если мы видим огромное количество записей по сотрудникам, вызванных простым перепроведением документов без изменения сумм (так называемые «фантомные» перерасчеты), выделим их (сочетанием клавиш Ctrl + A).
Нажмем кнопку Отменить.

Этот шаг корректно очистит регистр сведений ПредварительныеПерерасчеты, избавив базу от избыточных связей, после чего документ начисления заполнится без зависаний.

Решение 3. Программная очистка регистра (для разработчиков)

В критических ситуациях, когда интерактивный запуск формы «Перерасчеты» также вызывает зависание из-за колоссального объема накопленных данных, программист может прибегнуть к полной или частичной очистке регистра сведений программным путем. Рассмотрим пример кода для быстрой очистки записей регистра:


НаборЗаписей = РегистрыСведений.ПредварительныеПерерасчеты.СоздатьНаборЗаписей();
// При необходимости можно установить отборы, например, по конкретному периоду или организации:
// НаборЗаписей.Отбор.ПериодРегистрации.Установить(НачалоМесяца(ТекущаяДата()));

НаборЗаписей.Записать(Истина); // Запись пустого набора очищает данные в соответствии с отбором

Применение этого кода мгновенно высвобождает ресурсы СУБД и позволяет пользователям продолжить оперативную работу по расчету зарплаты текущего месяца.

Решение 4. Настройка регламентного задания регистрации перерасчетов

За автоматическое наполнение регистра ПредварительныеПерерасчеты в фоновом режиме отвечает регламентное задание РегистрацияПерерасчетов. В крупных информационных базах с большим количеством одновременно работающих пользователей частый запуск этого задания создает постоянную высокую нагрузку на СУБД.

Рекомендуется проанализировать расписание этого регламентного задания:

Перейдем в раздел Администрирование — Обслуживание — Регламентные операции — Регламентные и фоновые задания.
Найдем в списке задание «Регистрация перерасчетов».
Настроим его расписание таким образом, чтобы оно не запускалось в периоды пиковой активности расчетчиков (например, настроить запуск только в ночные часы или один раз в день в обеденный перерыв). В крайних случаях, во время проведения массового расчета зарплаты, данное регламентное задание можно временно отключить.

Решение 5. Внедрение даты запрета изменения данных

Основным источником появления «мусорных» записей в регистре перерасчетов является хаотичное перепроведение документов прошлых периодов смежными службами (например, кадровиками или табельщиками). Даже если в документе за прошлый год не изменился ни один реквизит, простое нажатие кнопки «Провести и закрыть» инициирует создание записи в регистре перерасчетов.

Для предотвращения этой проблемы установим жесткие административные рамки:

Перейдем в раздел Администрирование — Настройки пользователей и прав — Даты запрета изменения данных.
Включим признак использования даты запрета.
Установим дату запрета (например, конец предыдущего месяца или дату выплаты зарплаты) сразу после того, как расчетный период закрыт и ведомости проведены.

Это действие заблокирует возможность любого изменения документов исторических периодов, тем самым полностью исключив генерацию паразитного трафика записей в регистре предварительных перерасчетов.

Решение 6. Оптимизация на уровне СУБД (MS SQL Server / PostgreSQL)

Иногда корни проблемы лежат в плоскости СУБД. Из-за интенсивной записи и удаления данных в служебных регистрах СУБД строит неверные планы запросов (так как статистика распределения данных устаревает). Это приводит к тому, что даже простой запрос начинает выполняться неоптимально.

Для профилактики подобных зависаний системному администратору или SQL-программисту следует настроить регулярное выполнение следующих регламентных процедур на сервере баз данных:

Обновление статистики (Update Statistics): Процедура должна выполняться ежедневно (в ночное время), чтобы оптимизатор запросов СУБД всегда располагал актуальными сведениями о распределении данных в таблицах.
Реиндексация и дефрагментация индексов (Index Rebuild / Index Reorganize): Высокая фрагментация индексов в таблицах перерасчетов замедляет операции поиска и соединения. Регулярная перестройка индексов (например, раз в неделю) позволяет значительно ускорить выполнение аналитических запросов платформы 1С к базе данных.

Совместное применение этих мер гарантирует стабильную, быструю и предсказуемую работу документов расчета зарплаты даже в условиях сложного многопользовательского учета.