В нашем случае для проекта обновления «1С:ERP УХ» 3.2.1.83 → 3.2.8.9 со сложными интеграционными цепочками — это обернулось невозможностью записи документов ВерсияСоглашенияКредит: система требовала наличия данных, которые физически не могут появиться в документе до момента его фиксации в ИБ.
Для заполнения реквизита — документ должен быть записан, для записи документа — иметь заполненный реквизит
В конфигурации «1С:ERP УХ» клиента в документ ВерсияСоглашенияКредит был добавлен обязательный реквизит, необходимый для корректного проведения. Исторически сложилась следующая схема работы:
- Пользователь создает и записывает документ, реквизит не заполнен.
- Выполняется автоматизированный обмен данными с внешней системой.
- В процессе обмена добавленный реквизит заполняется программно.
- Только после этого документ становится доступен для проведения.
Но после обновления на релиз 3.2.8.9 запись документа стала невозможна. Система требовала заполнения реквизита уже на этапе записи, создавая «замкнутый круг»: для заполнения реквизита через обмен документ должен быть в базе, то есть записан, но записать его нельзя из-за отсутствия этого реквизита.
В ходе отладки было установлено, что в старом релизе 3.2.1.83 процедура ОбработкаПроверкиЗаполненияНаСервере в модуле формы документа вызывалась исключительно при проведении. В новом релизе проверка сместилась на этап записи.
Причиной стало изменение в общем модуле ДоговорыКонтрагентовФормыУХКлиент. В метод ПередЗаписьюВерсииСоглашения разработчиками вендора был добавлен следующий код:
Вызов Форма. ПроверитьЗаполнение() инициирует проверку массива проверяемых реквизитов непосредственно перед фиксацией записи в ИБ. Поскольку добавленный реквизит присутствовал в этом массиве, так как он обязателен для проведения, запись блокировалась.
«Размыкая круг» с &ИзменениеИКонтроль
Поскольку реквизит должен оставаться обязательным для проведения, удаление его из состава ПроверяемыеРеквизиты недопустимо. Решением стала адаптация типового кода через расширение с использованием аннотации &ИзменениеИКонтроль.
Алгоритм решения заключался в проверке режима записи документа. Если инициирована простая запись, не проведение, принудительный вызов Форма.ПроверитьЗаполнение() должен игнорироваться.
Добавление проверки режима записи позволило восстановить последовательность заполнения документа.
Вероятно, изменение типового поведения в новых релизах «1С: ERP УХ» в сторону ужесточения проверок при записи — это осознанный тренд вендора на повышение качества данных «в моменте».
Однако при наличии сложных интеграционных цепочек, где объект заполняется в процессе обмена, такие изменения требуют оперативной адаптации. Использование &ИзменениеИКонтроль в данном случае является наиболее безопасным методом, так как позволяет быстро отследить дальнейшие изменения этого метода со стороны вендора и, при необходимости, например, если клиент пересмотрит последовательность заполнения документа, легко откатиться к типовой логике.
Вступайте в нашу телеграмм-группу Инфостарт
