При настройке и администрировании программы «1С:Зарплата и управление персоналом» (ЗУП 3.1) специалисты часто сталкиваются с неочевидным поведением даты запрета изменения данных. Особенно много вопросов возникает при работе с кадровыми и кадрово-расчетными документами, такими как «Увольнение» и «Увольнение списком». Официальные информационные материалы разработчиков (например, ИТС) утверждают, что документы блокируются по максимальной дате из даты документа и даты кадрового события. Однако на практике в некоторых релизах поведение программы кардинально расходится с описанием.
В этой статье мы подробно разберем, как эволюционировал алгоритм проверки дат запрета в ЗУП 3.1, почему в релизе 3.1.8 одиночный документ «Увольнение» блокировался вопреки заявленным правилам, где в программном коде крылась ошибка разработчиков и как этот механизм работает в современных версиях программы.
Для того чтобы понять суть проблемы, нам необходимо проанализировать, как менялся подход к проверке дат запрета изменения в истории развития конфигурации:
ДатаЗапрета. По задумке, при записи любого документа в этот реквизит должно автоматически помещаться максимальное значение из двух реквизитов: даты документа (Дата) и даты кадрового события (например, ДатаУвольнения). Блокировка должна была срабатывать только в том случае, если эта максимальная дата оказывалась меньше или равна установленной дате запрета.Рассмотрим конкретный практический пример, с которым столкнулись пользователи. В системе установлена дата запрета редактирования для всех пользователей — 31.12.2018 (конец прошлого года без отсрочки закрытия).
Кадровый специалист создает два документа:
Проанализируем поведение системы под учетной записью кадровика и расчетчика:
Выясним причину такого расхождения, обратившись к конфигуратору и программному коду.
За определение того, по каким именно полям документов проверяется дата запрета изменения данных, отвечают процедуры в общих модулях ЗарплатаКадрыБазовый и ЗарплатаКадрыРасширенный. В частности, ключевой является процедура ЗаполнитьИсточникиДанныхДляПроверкиЗапретаИзменения.
В проблемных релизах линейки 3.1.8 (например, 3.1.8.214) для документа «Увольнение» правила проверки были настроены следующим образом:
ДатыЗапретаИзменения.ДобавитьСтроку(ИсточникиДанных, "Документ.Увольнение", "Дата", "КадровыйУчет", "Организация");
Обратим внимание на третий параметр функции — "Дата". Это имя конкретного реквизита объекта, то есть стандартной даты создания документа. В данном коде нет никакого упоминания нового реквизита ДатаЗапрета или механизмов отсрочки. Система проверяет блокировку строго по дате создания одиночного увольнения (в нашем примере это 28.12.2018), игнорируя дату события.
В то же время для документа «Увольнение списком» в этой же процедуре была прописана принципиально иная строка:
ДатыЗапретаИзменения.ДобавитьСтроку(ИсточникиДанных, "Документ.УвольнениеСписком", "ДатаЗапрета", "КадровыйУчет", "Организация");
Здесь проверка корректно перенаправлена на новый служебный реквизит "ДатаЗапрета". Именно из-за этой несогласованности в коде поведение одиночных документов увольнения отличалось от списочных. Разработчики попросту забыли обновить настройки источников данных для одиночного документа «Увольнение» при внедрении новой концепции.
В модуле менеджера одиночного документа «Увольнение» при этом корректно присутствовал вызов процедуры заполнения даты запрета:
ЗаполнитьДатуЗапретаРедактирования(ОбъектДокумента, ИмяРеквизитаДатаСобытия);
Эта процедура действительно записывала в скрытое поле объекта максимальное значение между датой документа и датой увольнения. Однако из-за старой настройки в общем модуле ЗарплатаКадрыБазовый система при проведении документа обращалась к реквизиту Дата вместо заполненного реквизита ДатаЗапрета.
В последующих исправлениях и обновлениях ЗУП 3.1 эта программная ошибка была устранена, и одиночные кадровые документы также были переведены на контроль по реквизиту ДатаЗапрета.
Рассмотрим, как функционирует корректно работающий механизм проверки даты запрета изменений. В стабильных релизах ЗУП 3.1 система при проведении кадровых документов одновременно анализирует две даты: дату самого документа и дату регистрируемого кадрового события (приема, увольнения, начала отпуска).
Документ считается открытым для проведения и редактирования, если хотя бы одна из этих двух дат находится в открытом периоде (то есть превышает установленную дату запрета редактирования):
ДатаЗапрета получит значение 10.01.2026. Документ будет полностью доступен кадровику для изменения и проведения, а расчетчику — для начисления сумм.ДатаЗапрета примет значение 15.01.2026. Документ проведется, позволяя отразить кадровое событие задним числом.Часто возникает вопрос: почему расчетчик (бухгалтер) не может рассчитать документ увольнения, если кадровик создал его в закрытом по кадровому учету периоде, даже если расчетный период («Зарплата») еще открыт?
Кадрово-расчетные документы в ЗУП 3.1 являются едиными объектами базы данных. Они содержат реквизиты, относящиеся как к кадровому ведомству (даты, статьи увольнения), так и к расчетному (начисления, показатели, учет времени). При нажатии расчетчиком кнопок «Рассчитать» или «Утвердить» программа производит полноценную запись объекта в базу данных.
В момент записи срабатывает общая подписка на событие ПриЗаписиПроверкаЗапретаИзменения. Она выполняет проверку по всем разделам учета, к которым привязан данный документ. Если для раздела «Кадровый учет» дата документа попадает под запрет, платформа выдает отказ от записи. Бухгалтер не может сохранить свои расчеты, так как система не позволяет перезаписать «закрытый» с точки зрения кадров документ. Для проведения расчетов в таких случаях требуется временно открывать период для кадровиков либо использовать механизмы исправления документов.
Начиная с версий ЗУП 3.1.20.71 и выше, разработчики предоставили администраторам и аналитикам мощный инструмент для кастомизации этого поведения без привлечения программистов и изменения кода конфигурации. В системе появился справочник «Разделы дат запрета изменения объектов» (его можно найти через функции технического специалиста или в меню настройки сервиса).
С помощью этого справочника мы можем гибко управлять проверками:
Документ.Отпуск) добавить два отдельных правила контроля: одно по полю Дата, второе — по полю ДатаНачала. При такой настройке система заблокирует документ, если хотя бы одна дата окажется в закрытом периоде.Таким образом, понимание внутренней архитектуры хранения дат запрета в ЗУП 3.1 и использование современных инструментов настройки позволяет администраторам оперативно решать конфликты блокировок документов и обеспечивать корректную совместную работу кадровой и расчетной служб предприятия.