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