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