Почему зависает расчет зарплаты и в журнале регистрации появляется «Регистр расчета.Начисления »?

При заполнении и расчете документа Начисление зарплаты и взносов пользователи и администраторы нередко сталкиваются с ситуацией, когда процесс намертво зависает, фоновые задания аварийно завершаются, а в журнале регистрации фиксируются события модификации набора записей РегистрРасчета.Начисления со значением <Объект не найден>. Разберем механику этой проблемы, выясним природу подобных записей и рассмотрим пошаговые методы устранения сбоя.

Механизм расчета заработной платы и природа битых ссылок в журнале

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

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

1. Для нового или перезаполняемого документа генерируется ссылка с помощью метода менеджера:
   Скопировать код

   
   НоваяСсылка = Документы.НачислениеЗарплаты.ПолучитьСсылку(Новый УникальныйИдентификатор);
   

   Метод ПолучитьСсылку() не ищет существующий документ в базе, а формирует валидную ссылку из переданного или сгенерированного идентификатора типа УникальныйИдентификатор.
2. Внутри отдельной транзакции выполняется временная пробная запись набора движений в РегистрРасчета.Начисления с указанием этой временной ссылки в качестве регистратора.
3. Выполняются платформенные виртуальные таблицы расчета базы и фактического периода действия.
4. Если на каком-либо этапе расчета происходит сбой, таймаут ожидания блокировок или аварийный сброс сеанса, транзакция откатывается. В СУБД сам документ так и не создается, однако события записи движений регистра уже успевают зафиксироваться в журнале регистрации. В результате в колонке регистратора отображается <Объект не найден>.

Убедимся, что реальных битых записей в таблицах базы нет. Выполним проверочный запрос в консоли запросов:

ВЫБРАТЬ
    Начисления.Регистратор КАК Регистратор
ИЗ
    РегистрРасчета.Начисления КАК Начисления
ГДЕ
    Начисления.Регистратор.Ссылка ЕСТЬ NULL

Если запрос возвращает пустой результат, значит, физической деградации данных нет. Появление записей в журнале — это не причина поломки, а прямое следствие аварийно прерванной транзакции фонового расчета.

Шаг 1. Отключение фонового расчета зарплаты для локализации ошибки

Современные версии конфигураций (в частности, 1С:ЗУП) по умолчанию выполняют заполнение и расчет документа в асинхронном режиме через фоновые задания. Если при многопоточном расчете возникает взаимная блокировка (deadlock) общих таблиц или необработанное исключение, фоновое задание тихо «умирает» или бесконечно ожидает освобождения ресурсов.

Переведем расчет в синхронный пользовательский сеанс:

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

Шаг 2. Проверка зацикливаний в планах видов расчета

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

Выполним аудит видов расчета:

1. Откроем раздел Настройка — Начисления.
2. Проверим последние измененные или вновь созданные начисления предприятия.
3. Внимательно изучим вкладки Приоритет, Зависимости и список базовых начислений, исключив перекрестное взаимное влияние.

Шаг 3. Очистка очереди перерасчетов

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

Оптимизируем перерасчеты следующим образом:

1. Перейдем в раздел Зарплата — Сервис — Перерасчеты.
2. Проанализируем список зарегистрированных перерасчетов. Если таблица содержит сотни зависших или старых записей, выделим их и нажмем Отменить.
3. В настройках расчета зарплаты временно установим флаг Выполнять доначисление и перерасчет отдельным документом. Это исключит фоновое сканирование прошлых периодов в основном документе начисления.

Шаг 4. Проверка актуальности итогов регистров расчета

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

1. Запустим базу в режиме Конфигуратор.
2. Перейдем в меню Администрирование — Тестирование и исправление...
3. Обязательно установим флаг напротив пункта Пересчет итогов и нажмем Выполнить.
4. В режиме 1С:Предприятие откроем форму Управление итогами (Все функции / Функции для технического специалиста — Стандартные — Управление итогами) и убедимся, что итоги по регистрам расчета установлены на текущую дату.

Шаг 5. Поиск проблемного сотрудника методом деления списка

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

Локализуем проблемную запись по алгоритму:

1. Создадим новый документ и заполним его не целиком кнопкой Заполнить, а через кнопку Подбор.
2. Добавим первую половину сотрудников из подразделения. Если расчет прошел успешно — очистим документ и добавим вторую половину.
3. Последовательно деля список сотрудников пополам, определим одного конкретного работника, добавление которого вызывает зависание и обрыв транзакции.
4. Для найденного сотрудника проверим:
   • Назначенный график работы и наличие заполненных дней в производственном календаре за расчетный месяц.
   • Историю кадровых переводов внутри текущего месяца (нет ли дублирующихся записей на одну дату).
   • Действующие плановые начисления и зарегистрированные документы-отклонения (больничные, отпуска, прогулы).