Как исправить ошибку «Переменная не определена» при сохранении расширения конфигурации

← На главную

При разработке расширений в среде 1С:Предприятие 8.3 программисты часто сталкиваются с ситуацией, когда при сохранении метаданных система выдает ошибку синтаксического контроля, связанную с мобильным клиентом или автономным режимом. Типичный текст ошибки выглядит так: Переменная не определена (ИмяМодуля) (Проверка: Мобильный клиент (автономная конфигурация). Клиент). Это происходит даже в том случае, если код явно закрыт директивами препроцессора.

В этой статье мы подробно разберем, почему возникает эта ошибка, и рассмотрим несколько способов её устранения: от настройки параметров конфигуратора до «обмана» системы через динамический вызов процедур.

Анализируем причину возникновения ошибки

Выясним причину, по которой платформа 1С игнорирует директивы препроцессора типа #Если НЕ МобильноеПриложениеКлиент Тогда при проверке модуля. Дело в том, что при сохранении расширения конфигуратор выполняет полную проверку синтаксиса для всех целевых платформ, указанных в свойствах расширения или в настройках проверки модулей. Если в расширении включена поддержка автономной работы, платформа пытается скомпилировать код для мобильного автономного сервера. На этом этапе некоторые общие модули основной конфигурации или самого расширения могут быть «невидимы» для этой специфической среды, что и вызывает ошибку Переменная не определена.

Решение 1: Настройка параметров проверки модулей

Прежде всего, проанализируем настройки самого конфигуратора. Если вы предпочитаете альтернативные среды разработки, обратите внимание на плагин для работы с расширениями в VS Code. Часто проверка на мобильную автономную конфигурацию включена по умолчанию, даже если вы не планируете использовать этот функционал. Разберем по шагам, как это отключить:

Откроем пункт меню Сервис — Параметры.
Перейдем на закладку Модули, а затем на подпункт Проверка.
В списке конфигураций, для которых выполняется проверка, найдем пункт Мобильный клиент (автономная конфигурация).
Снимем флажок с этого пункта.
Нажмем Применить и попробуем снова сохранить расширение.

Это самый простой способ, который помогает в большинстве случаев, если ошибка носит исключительно информационный характер и не препятствует реальной работе приложения.

Решение 2: Использование расширенных директив препроцессора

Иногда стандартной директивы #Если НЕ МобильноеПриложениеКлиент недостаточно, так как проверка может спотыкаться на автономном сервере. Рассмотрим более полный вариант исключения кода из проверки. Проанализируем ситуацию: если код предназначен только для толстого или тонкого клиента «большой» 1С, стоит использовать максимально жесткую отсечку.

Попробуем заменить стандартное условие на следующую конструкцию:


#Если НЕ МобильныйАвтономныйСервер И НЕ МобильноеПриложениеСервер И НЕ МобильноеПриложениеКлиент И НЕ МобильныйКлиент Тогда
    // Ваш код, который вызывает ошибку
    Если ДокументыСерверФП.ДоступнаРольПользователяРабочихСтолов() Тогда
        КлиентскоеПриложение.УстановитьРежимОсновногоОкна(РежимОсновногоОкнаКлиентскогоПриложения.ПолноэкранноеРабочееМесто);
    КонецЕсли;
#КонецЕсли

Такой подход позволяет гарантированно скрыть код от всех видов мобильных и автономных чекеров платформы.

Решение 3: Изменение свойств расширения

Проверим важную настройку в корне метаданных вашего расширения. Если расширение было создано на базе современной версии платформы, у него может быть активно свойство использования в автономном режиме.

В дереве метаданных щелкнем правой кнопкой мыши по корню расширения и выберем Свойства (для детального изучения структуры пригодится обработка для анализа метаданных — см. архитектурный анализ конфигураций и выявление зависимостей).
Найдем свойство Использование в автономной конфигурации.
Установим его в значение Не использовать.

Это действие «подскажет» платформе, что данное расширение в принципе не предназначено для работы в автономном режиме мобильного клиента, и лишние проверки при сохранении будут отключены.

Решение 4: Динамическое обращение к модулю (Обход системы)

Если вышеуказанные методы не помогают (что иногда случается из-за особенностей кеширования или версии платформы), применим метод динамического вызова. Суть заключается в том, чтобы скрыть имя общего модуля от статического анализатора кода. Вместо прямого обращения к ДокументыСерверФП, мы будем использовать функцию Вычислить() или механизмы БСП.

Рассмотрим пример реализации через Вычислить() (быстро набросать структуру кода поможет консоль кода с ИИ-помощником — для этого пригодится набор инструментов разработчика для отладки и написания кода):


#Если НЕ МобильноеПриложениеКлиент Тогда
    МодульОбъект = Неопределено;
    Попытка
        МодульОбъект = Вычислить("ДокументыСерверФП");
    Исключение
        // Модуль недоступен
    КонецПопытки;

    Если МодульОбъект <> Неопределено И МодульОбъект.ДоступнаРольПользователяРабочихСтолов() Тогда
        КлиентскоеПриложение.УстановитьРежимОсновногоОкна(РежимОсновногоОкнаКлиентскогоПриложения.ПолноэкранноеРабочееМесто);
    КонецЕсли;
#КонецЕсли

Если в вашей конфигурации используется Библиотека Стандартных Подсистем (БСП), более элегантным решением будет использование функции ОбщегоНазначения.ОбщийМодуль(). Это позволит избежать прямого упоминания модуля в коде, и синтаксический контроль пройдет успешно. Для работы с библиотекой удобно использовать справочник по методам БСП с примерами.

Посмотрим на пример вызова через БСП:


// Используем безопасный метод получения модуля
МодульСервер = ОбщегоНазначения.ОбщийМодуль("ДокументыСерверФП");
Если МодульСервер.ДоступнаРольПользователяРабочихСтолов() Тогда
    // Действие
КонецЕсли;

Решение 5: Проверка флагов общего модуля и очистка кеша

Иногда проблема кроется в том, что сам общий модуль ДокументыСерверФП настроен некорректно. Проанализируем свойства модуля в расширении. Для того чтобы он был доступен в модуле управляемого приложения (который компилируется на клиенте), у него должны быть установлены соответствующие флаги:

Сервер — обязательно для серверных модулей.
Вызов сервера — если вы обращаетесь к методам модуля напрямую с клиента.
Клиент (управляемое приложение) — если модуль должен быть виден на стороне клиента.

Важный нюанс: Если вы столкнулись с «фантомной» ошибкой, которая не исчезает после всех правок, попробуйте стандартную процедуру очистки кеша расширений:

Снимите галочку Активно в списке расширений.
Примените изменения в базе данных (F7).
Снова установите галочку Активно и примените изменения.

В крайних случаях помогает выгрузка расширения в файл .cfe, его полное удаление из списка и повторная загрузка. Это заставляет платформу полностью перестроить дерево метаданных и индексы связей модулей.

Подводя итог, можно сказать, что ошибка Переменная не определена в контексте мобильного клиента — это чаще всего избыточная строгость конфигуратора. Использование динамического вызова через Вычислить() или корректная настройка параметров проверки позволяют избавиться от раздражающих сообщений и успешно сохранить конфигурацию расширения.