Ситуация, когда один и тот же программный код ведет себя по-разному в тестовой и рабочей информационных базах, — одна из самых коварных задач в практике разработчика 1С. Особенно часто это проявляется в процедуре ОбработкаПроверкиЗаполнения модуля объекта. На тестовом стенде проверки срабатывают штатно, а в «боевой» базе система будто игнорирует написанные алгоритмы, пропуская пустые поля или неверные данные. Проанализируем причины этого явления и разберем по шагам, как локализовать и устранить проблему.
Первое, с чем сталкивается разработчик при попытке разобраться в ситуации на рабочей базе — это утверждение, что отладка в серверных процедурах невозможна. Выясним, почему это миф. Процедура ОбработкаПроверкиЗаполнения выполняется на стороне сервера, и для того, чтобы «поймать» в ней выполнение кода, необходимо выполнить два условия:
-debug, точки останова в серверных модулях срабатывать не будут. Проверим параметры запуска службы в реестре или через консоль администрирования.Рассмотрим пример того, что мы должны увидеть в отладчике. Часто проблема кроется в проверке прав. Проанализируем типовой фрагмент кода:
Процедура ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
Если Не РольДоступна("ПолныеПрава") Тогда
// Наша логика проверки
Если Не ЗначениеЗаполнено(Организация) Тогда
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "Не заполнена организация!";
Сообщение.Поле = "Объект.Организация";
Сообщение.УстановитьДанные(ЭтотОбъект);
Сообщение.Сообщить();
Отказ = Истина;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
Если в рабочей базе этот блок не срабатывает, отладчик позволит увидеть значение функции РольДоступна("ПолныеПрава"). Если она возвращает Истина там, где должна возвращать Ложь, значит, проблема в настройке прав конкретного пользователя или в использовании привилегированного режима.
Одной из самых частых причин «мистического» поведения является кэш. Кэш в 1С бывает двух видов: клиентский и серверный. Разберем подробнее, как они влияют на выполнение ОбработкаПроверкиЗаполнения:
Для решения проблемы на рабочей базе рекомендуется выполнить полную очистку кэша у пользователя (удаление базы из списка и повторное добавление) и, если это не помогает, перезапустить службу сервера 1С:Предприятие с удалением содержимого папки snaccxt в каталоге данных сервера.
Если код в тестовой и рабочей базах идентичен в основной конфигурации, необходимо проверить наличие расширений в рабочей базе. Расширения могут перехватывать управление процедурой ОбработкаПроверкиЗаполнения. Выясним, как это работает:
В расширении может быть создана одноименная процедура с аннотациями &Вместо, &Перед или &После. Если используется &Вместо, то оригинальный код в модуле объекта вообще не будет выполнен, если только внутри расширения не вызван метод ПродолжитьВызов(). Посмотрим на пример кода в расширении, который может блокировать проверку:
&Вместо("ОбработкаПроверкиЗаполнения")
Процедура Расш1_ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
// Если здесь нет кода или вызова ПродолжитьВызов(),
// оригинальная проверка из модуля объекта будет проигнорирована
КонецПроцедуры
Проанализируем список установленных расширений в рабочей базе через «Администрирование» — «Расширения» и проверим их влияние на целевой документ.
Процедура ОбработкаПроверкиЗаполнения всегда выполняется на сервере. Если вызов записи или проведения документа происходит внутри программного блока, где установлен привилегированный режим, поведение функций проверки прав меняется. Рассмотрим ситуацию:
Функция РольДоступна() в привилегированном режиме всегда возвращает Истина. Если ваша проверка обернута в условие Если Не РольДоступна("ПолныеПрава"), то в привилегированном режиме этот блок будет пропущен. Выясним причину включения этого режима в рабочей базе: это могут быть подписки на события или вызовы из сторонних обработок, которых нет в тестовой базе.
Также стоит проверить Функциональные опции. Если логика проверки зависит от константы или значения другого реквизита, который управляет функциональной опцией, разница в настройках баз приведет к разному результату. Проанализируем значения констант, влияющих на видимость или доступность реквизитов в рабочей базе.
Важно проверить состояние свойства ОбменДанными.Загрузка. Даже если пользователь создает документ интерактивно, некоторые сторонние модули или подписки на события в рабочей базе могут устанавливать этот флаг в Истина. Платформа 1С автоматически отключает стандартные проверки заполнения, если этот режим активен. Убедимся, что в коде процедуры есть явная обработка этого флага:
Процедура ОбработкаПроверкиЗаполнения(Отказ, ПроверяемыеРеквизиты)
Если ЭтотОбъект.ОбменДанными.Загрузка Тогда
Возврат; // Проверки не выполняются при загрузке данных
КонецЕсли;
// Далее основной код проверок
КонецПроцедуры
Если в рабочей базе по какой-то причине этот флаг установлен (например, из-за специфической формы или расширения), проверки работать не будут.
Для окончательного выявления причины рекомендуется выполнить следующие шаги:
.cf и сравнить её с конфигурацией тестовой базы через инструмент «Сравнить конфигурации».ОбработкаПроверкиЗаполнения и на каких строках он завершил выполнение.Таким образом, «странное» поведение обычно объясняется либо кэшированием старого кода, либо внешним влиянием расширений и контекста выполнения (привилегированный режим, режим загрузки данных), который отличается в рабочей среде.