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