При разработке собственных механизмов в конфигурации «Бухгалтерия государственного учреждения 2.0» (БГУ 2) программисты часто сталкиваются с тем, что стандартные механизмы защиты данных начинают вести себя непредсказуемо. Одной из таких проблем является некорректное срабатывание даты запрета изменения при попытке записи в новый регистр накопления, созданный в расширении. Ситуация осложняется тем, что даже если дата документа актуальна (например, 2024 год), система может выдавать ошибку, ссылаясь на запрещенный период (например, 2023 год).
В этой статье мы подробно разберем, почему возникает ошибка «невозможно поместить в запрещенный период», проанализируем механизмы Библиотеки стандартных подсистем (БСП) и найдем правильное решение для настройки источников проверки дат запрета.
Рассмотрим ситуацию: вы создали в расширении новый документ и соответствующий ему регистр накопления. Вы добавили процедуру-обработчик, которая должна регистрировать ваш новый объект в системе дат запрета изменений, используя типовой общий модуль ДатыЗапретаИзмененияБГУ. Однако при попытке проведения документа программа выдает ошибку:
«Остатки компенсации с полем Регистратор = "..." невозможно поместить в запрещенный период. Запрещено изменять данные с датой ранее 01.01.2024 (включительно).»
При этом сам документ может быть датирован февралем 2024 года, а дата запрета установлена на 31 декабря 2023 года. На первый взгляд, противоречия нет, но 1С блокирует запись. Выясним причину такого поведения.
Механизм «Даты запрета изменения» в современных конфигурациях 1С работает на уровне подписок на события. Когда набор записей регистра накопления готовится к записи в базу данных, вызывается процедура проверки. Проблема часто кроется в том, как именно указана связь между данными регистра и датой, по которой проверяется запрет.
Проанализируем фрагмент кода, который часто приводит к ошибке:
&После("ЗаполнитьИсточникиДанныхДляПроверкиЗапретаИзменения")
Процедура Изм_ЗаполнитьИсточникиДанныхДляПроверкиЗапретаИзменения(ИсточникиДанных)
ДатыЗапретаИзменения.ДобавитьСтроку(ИсточникиДанных, "РегистрНакопления.цмОстаткиКомпенсации", "Регистратор.Дата", "БухгалтерскийУчет", "учреждение");
КонецПроцедуры
В данном примере в качестве поля проверки указано Регистратор.Дата. Это означает, что система при проверке каждой строки регистра пытается «дотянуться» через регистратор до даты документа. Однако для регистров накопления и регистров сведений в 1С критически важным является использование стандартного поля Период.
Основная ошибка заключается в использовании обращения через точку к дате регистратора. Алгоритмы БСП оптимизированы для проверки физических полей таблиц. Для регистров накопления полем, определяющим время совершения операции, является Период. Именно его проверяет платформа при записи набора записей.
Чтобы исправить ошибку, необходимо изменить параметр в процедуре регистрации источника. Рассмотрим правильный вариант кода:
&После("ЗаполнитьИсточникиДанныхДляПроверкиЗапретаИзменения")
Процедура Изм_ЗаполнитьИсточникиДанныхДляПроверкиЗапретаИзменения(ИсточникиДанных)
// Вместо "Регистратор.Дата" указываем "Период"
ДатыЗапретаИзменения.ДобавитьСтроку(ИсточникиДанных,
"РегистрНакопления.цмОстаткиКомпенсации",
"Период",
"БухгалтерскийУчет",
"учреждение");
КонецПроцедуры
После внесения этого изменения система начнет проверять дату непосредственно из каждой строки движения регистра. Это решает проблему в 95% случаев, особенно если логика проведения документа предполагает, что дата движения совпадает с датой документа.
Если замена Регистратор.Дата на Период не помогла, проанализируем ситуацию глубже. Существует несколько нюансов, которые могут влиять на этот процесс:
Период этих строк попадает в закрытый период. В этом случае нужно либо открывать период, либо менять логику документа (делать исправительные записи текущим периодом).Период в наборе записей присваивается дата из прошлого, проверка даты запрета сработает. Проверьте в отладчике содержимое коллекции Движения.ВашРегистр перед записью.Период попадает пустая дата (01.01.0001), 1С интерпретирует её как максимально глубокое прошлое. Любая установленная дата запрета будет «свежее» этой даты, и документ не проведется.БухгалтерскийУчет, убедитесь, что в настройках программы («Администрирование» — «Настройки пользователей и прав» — «Даты запрета изменения») для этого раздела не установлена специфическая дата, которая перекрывает общую.Посмотрим на технические особенности использования расширений при работе с датами запрета. Важно соблюдать следующие правила:
УстановитьПривилегированныйРежим(Истина);
НаборЗаписей.Записать();
УстановитьПривилегированныйРежим(Ложь);
ПередЗаписью самого регистра.Подводя итог, можно сказать, что корректная настройка источников данных для проверки запрета изменений требует точности в указании метаданных. Всегда отдавайте предпочтение полю Период для любых регистров, так как это базовое поле платформы, на которое опираются все механизмы контроля периодов в 1С.