Как разблокировать базу 1С и отключить режим автономного рабочего места (АРМ) после выгрузки из облака?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

При переносе информационных баз из облачных сервисов, таких как 1С:Фреш, пользователи часто сталкиваются со специфической блокировкой: программа не позволяет изменять настройки, редактировать состав функциональных опций или управлять планами обмена. При попытке внести изменения система выдает уведомление: "Изменять функциональность можно только в режиме сервиса". Проанализируем, почему это происходит и как превратить "облачную" базу в полноценную локальную версию.

Выясним причину возникновения проблемы

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

Для того чтобы снять эти ограничения, нам необходимо выполнить комплекс действий по "отвязке" базы от облачной инфраструктуры. Разберем этот процесс по шагам.

Шаг 1: Сброс привязки к главному узлу (РИБ)

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

Попробуем запустить базу в режиме Конфигуратор с использованием специального ключа командной строки. Это базовое действие, которое должно инициировать процедуру отвязки:

  1. Закроем все сеансы работы с базой.
  2. В списке информационных баз нажмем кнопку "Изменить".
  3. Перейдем на закладку "Дополнительно".
  4. В поле "Параметры запуска" впишем: /ResetMasterNode.
  5. Запустим базу.

Иногда этого недостаточно, или система не запрашивает подтверждение при входе. В таком случае воспользуемся программным методом. Создадим внешнюю обработку или воспользуемся консолью кода, чтобы выполнить следующую команду:


ПланыОбмена.УстановитьГлавныйУзел(Неопределено);

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

Шаг 2: Сброс системных констант АРМ

Выясним, какие внутренние настройки блокируют интерфейс. В прикладных решениях 1С существуют специальные константы, которые определяют логику поведения программы. Рассмотрим наиболее важные из них:

Для исправления ситуации нам необходимо программно сбросить эти значения. Если у вас есть возможность использовать обработку "Групповое изменение реквизитов", найдем в ней раздел "Константы" и установим значения Ложь для указанных выше параметров. Если же интерфейс полностью заблокирован, выполним код:


Константы.ЭтоАвтономноеРабочееМесто.Установить(Ложь);
Константы.НастройкаПодчиненногоУзлаРИБЗавершена.Установить(Ложь);

После выполнения этого кода и перезапуска сеанса 1С:Предприятие, надпись "в режиме сервиса" должна исчезнуть, а доступ к настройкам функциональности — открыться.

Шаг 3: Полная очистка от "облачного прошлого"

Проанализируем ситуацию глубже. Даже после сброса констант в базе могут оставаться "хвосты", которые будут инициировать фоновые задания или попытки связи с несуществующим сервером. Разберем дополнительные меры по очистке:

  1. Удаление планов обмена: Перейдем в меню "Все функции" (или "Функции для технического специалиста") и откроем справочник "Планы обмена". Найдем план обмена, отвечающий за автономную работу. Если там остались записи, их следует удалить, предварительно пометив на удаление и очистив ссылки.
  2. Отключение разделения данных: В облаке данные разных клиентов разделены. В локальной базе это не требуется. Проверим состояние константы ИспользоватьРазделениеПоОбластям. В нормальной локальной базе она должна быть в состоянии Ложь.
  3. Проверка расширений: Часто при выгрузке из сервиса в базу попадают служебные расширения конфигурации (например, для патчей или связи с техподдержкой провайдера). Рекомендуется зайти в раздел "Администрирование" — "Печатные формы, отчеты и обработки" — "Расширения" и проанализировать список. Удаление специфических "облачных" расширений поможет избежать конфликтов в будущем.

Шаг 4: Работа с правами доступа и блокировками

Рассмотрим еще один важный аспект. В облаке права администратора могут быть ограничены (роль "Владелец абонента" дает права в сервисе, но не всегда транслируется в полные права "Администратор системы" в локальной версии). Если после всех манипуляций какие-то действия все равно недоступны, проделаем следующее:

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

Резюме и рекомендации

Мы проанализировали процесс превращения автономного рабочего места в обычную базу. Основной алгоритм действий всегда сводится к трем этапам: сброс связи с главным узлом через УстановитьГлавныйУзел(Неопределено), обнуление константы ЭтоАвтономноеРабочееМесто и последующая очистка планов обмена.

Помните, что перед выполнением любых низкоуровневых операций с базой (изменение констант или сброс узлов РИБ) крайне важно создать резервную копию. Это позволит вам вернуться в исходное состояние, если в процессе "лечения" возникнут непредвиденные ошибки в программном коде БСП.

← На главную