В практике работы с конфигурациями на базе 1С:Предприятие 8.3 (такими как ЗУП 3.1, ERP 2.5 или КА) часто возникает ситуация, когда документ, созданный текущей датой, отказывается проводиться из-за установленной даты запрета редактирования. Особенно ярко это проявляется в документе «Регистрация переработок». Давайте вместе разберем, почему система блокирует документ, который фактически относится к открытому периоду, и где именно в конфигураторе скрыта логика этой проверки.
Рассмотрим типичный сценарий: на календаре март, мы создаем документ Регистрация переработок. В самом документе мы указываем период (например, 1 квартал: январь, февраль, март). Дата самого документа — 10 марта. Дата запрета в системе установлена на 28 февраля. При попытке проведения мы получаем отказ. Проблема заключается в том, что механизм даты запрета в современных конфигурациях (построенных на БСП — Библиотеке Стандартных Подсистем) работает гораздо глубже, чем простое сравнение даты документа с константой.
Проанализируем причины отказа:
Регистрация переработок есть реквизит ПериодРегистрации (Месяц), который может указывать на прошлый месяц.Как было верно замечено в обсуждении, одной из ключевых точек является параметр сеанса ДействующиеДатыЗапретаИзменения. Выясним, что это такое. Это структура, которая кэшируется при старте сеанса пользователя. В ней хранятся настройки: для каких объектов, по каким реквизитам и для каких пользователей действуют ограничения.
Посмотрим, где эта структура инициализируется. Основная логика сосредоточена в общем модуле ДатыЗапретаИзмененияСлужебный. Система динамически собирает правила проверки. Чтобы понять, какой именно реквизит вашего документа проверяется, нам нужно найти процедуру ПриОпределенииОбъектовСПроверкойДатыЗапрета. Именно там программно описывается связь: «ТипОбъекта -> РеквизитПроверки».
Если вы хотите точно увидеть момент, когда 1С принимает решение о запрете, разберем порядок действий в конфигураторе:
Во-первых, обратим внимание на подписки на события. В БСП за проверку даты запрета отвечают стандартные обработчики:
ДокументыПроверкаДатыЗапретаПриЗаписиРегистрыПроверкаДатыЗапретаПриЗаписи (для наборов записей)Во-вторых, найдем общий модуль ДатыЗапретаИзменения. В нем нас интересует функция ПроверитьДатуЗапретаИзменения. Установим в ней точку остановки. Проанализируем параметры, которые приходят в эту функцию. Чаще всего это Источник (сам документ или набор записей) и Отказ.
Пример упрощенной логики, которую мы можем встретить внутри механизма:
// Фрагмент логики определения даты для проверки
Если ТипЗнч(Данные) = Тип("ДокументОбъект.РегистрацияПереработок") Тогда
ДатаДляПроверки = Данные.ПериодРегистрации; // Или другой специфический реквизит
ИначеЕсли ТипЗнч(Данные) = Тип("РегистрНакопленияНаборЗаписей.ДанныеОВремениДляРасчетаСреднегоЗаработка") Тогда
// Проверка каждой строки набора
Для Каждого Запись Из Данные Цикл
Если Запись.Период <= ДатаЗапрета Тогда
Отказ = Истина;
КонецЕсли;
КонецЦикла;
КонецЕсли;
Выясним причину, специфичную для кадрового учета. Документ Регистрация переработок предназначен для фиксации фактически отработанного времени сверх нормы за учетный период. Несмотря на то, что расчет производится в марте, данные «привязываются» к месяцам, в которых эта переработка возникла.
Система безопасности расценивает запись данных за январь-февраль как изменение базы прошлых периодов. Это критично, так как эти данные могут повлиять на уже рассчитанную зарплату, налоги и средний заработок в закрытых периодах. Проверка срабатывает не по дате самого документа, а по движениям в регистры сведений и накопления, которые «улетают» в прошлые месяцы.
Разберем основные варианты действий в зависимости от ваших полномочий и требований бизнеса:
Вариант 1: Временное изменение даты запрета. Это самый простой и правильный путь с точки зрения целостности данных. Администратор или ответственный бухгалтер временно сдвигает дату запрета на начало года (или на 31.12 прошлого года), пользователь проводит документ, после чего дата запрета возвращается на 28.02. Это гарантирует, что все регламентные проверки БСП будут пройдены корректно.
Вариант 2: Использование исключений в настройках. В интерфейсе настройки даты запрета изменений (Администрирование — Поддержка и обслуживание — Дата запрета изменения) можно установить общую дату для всех, но добавить исключение для конкретного пользователя. Например, расчетчику, который вводит переработки, можно разрешить редактирование данных более ранним числом.
Вариант 3: Программное вмешательство (для разработчиков).
Если необходимо полностью исключить документ из проверки (что не рекомендуется), нужно найти общий модуль ДатыЗапретаИзмененияПереопределяемый. Там существует процедура ПриОпределенииОбъектовИсключенийДатыЗапрета. Добавив туда наш документ, мы заставим систему игнорировать его при проверке даты запрета.
Рассмотрим пример кода для добавления исключения:
Процедура ПриОпределенииОбъектовИсключенийДатыЗапрета(ОбъектыИсключения) Экспорт
// Добавляем документ в список исключений
ОбъектыИсключения.Вставить(Метаданные.Документы.РегистрацияПереработок.ПолноеИмя());
КонецПроцедуры
Мы выяснили, что причина блокировки документа Регистрация переработок кроется в его движениях по регистрам за прошлые периоды. Для поиска конкретного места проверки в коде следует использовать отладку в общем модуле ДатыЗапретаИзменения и анализировать параметр сеанса ДействующиеДатыЗапретаИзменения. Самым безопасным решением остается временное изменение настроек даты запрета в пользовательском режиме, не прибегая к модификации кода конфигурации.