При работе с распределенными информационными базами (РИБ) в старых или сильно измененных конфигурациях, таких как Управление торговлей 10.3, специалисты часто сталкиваются с проблемами при создании начального образа подчиненного узла. Одной из наиболее неприятных ошибок является сообщение о том, что реквизит ЭтоГруппа не существует для справочника Склады (места хранения). Эта проблема блокирует первый запуск периферийной базы и не позволяет завершить настройку обмена данными.
В этой статье мы подробно разберем причины возникновения этой ошибки, проанализируем, почему стандартные средства платформы могут подвести, и рассмотрим надежный альтернативный метод создания узла РИБ, который позволит обойти ограничения метаданных.
Для начала разберем, почему возникает ошибка Реквизит "ЭтоГруппа" не существует. В типовой конфигурации «Управление торговлей 10.3» справочник Склады по умолчанию имеет тип иерархии «Иерархия групп и элементов». Это означает, что в структуре таблиц базы данных присутствует служебный реквизит ЭтоГруппа.
Если в процессе доработки конфигурации тип иерархии был изменен на «Иерархия элементов», платформа физически удаляет поле ЭтоГруппа из таблицы справочника. Проблема заключается в том, что при создании начального образа стандартным способом, система инициирует процедуру «Первого запуска». В этот момент запускается программный код в модуле ОбновлениеИнформационнойБазы. В типовом коде 1С часто встречаются жестко прописанные обращения к предопределенным группам справочников или циклы обработки, которые проверяют условие Если Ссылка.ЭтоГруппа Тогда.
Поскольку при первом запуске в новой базе значения многих констант сброшены, система считает, что она обновляется, и пытается выполнить эти процедуры. Обращение к отсутствующему реквизиту ЭтоГруппа вызывает фатальную ошибку, выполнение кода прерывается, и войти в базу становится невозможно.
Попытка вернуть справочнику Склады исходный тип иерархии («Группы и элементы») в конфигураторе часто приводит к другой ошибке: Не может быть изменен признак использования владельца: МестаХранения. Проанализируем эту ситуацию. Справочник МестаХранения в УТ 10.3 является подчиненным справочнику Склады. Логика платформы 1С запрещает менять структуру иерархии родительского объекта, если это может нарушить целостность связей подчиненных объектов. Таким образом, простой возврат к типовым настройкам метаданных без серьезной реструктуризации данных невозможен.
Наиболее эффективным и проверенным методом в данной ситуации является создание периферийного узла не через механизм «Создать начальный образ», а путем прямого копирования файла базы данных (или бэкапа SQL). Рассмотрим этот алгоритм по шагам.
Шаг 1. Подготовка в центральной информационной базе (ЦБ)
Прежде всего, нам необходимо зарегистрировать новый узел в плане обмена. Зайдем в меню «Операции» — «Планы обмена», выберем нужный план обмена (например, «Полный») и создадим новый элемент. Важно четко зафиксировать Код и Наименование этого узла, они понадобятся нам позже.
Шаг 2. Создание физической копии
Для файловой базы данных достаточно просто скопировать файл 1Cv8.1CD в новую папку. Для клиент-серверного варианта необходимо создать новую базу на сервере SQL и развернуть в нее актуальный бэкап центральной базы. Таким образом, мы получаем идентичную копию ЦБ со всеми данными и настройками.
Шаг 3. Превращение копии в подчиненный узел
Теперь нам нужно «объяснить» копии базы, что она больше не является центральной, а является подчиненным узлом. Для этого запустим копию в режиме «Предприятие». Нам необходимо программно установить главный узел. Воспользуемся внешней обработкой или консолью кода и выполним следующий фрагмент:
// Определим узел, который должен стать главным (Центральный узел)
УзелЦБ = ПланыОбмена.Полный.НайтиПоКоду("001"); // Используйте код вашей ЦБ
// Установим главный узел для текущей базы
ПланыОбмена.УстановитьГлавныйУзел(УзелЦБ);
Сообщить("База успешно преобразована в подчиненный узел РИБ");
После выполнения метода УстановитьГлавныйУзел() база изменит свой статус. При следующем запуске она будет считать себя периферийной. Главное преимущество этого метода в том, что система не запускает механизмы первоначального обновления и создания предопределенных данных, так как база уже содержит все необходимые записи в константах и параметрах сеанса. Мы успешно обходим ошибку ЭтоГруппа.
Поскольку мы создали узел методом копирования, в периферийной базе остались все данные центрального узла. Если ваш план обмена подразумевает передачу всех данных («Полный»), то это не является проблемой. Однако, если в плане обмена настроены фильтры (например, по организациям или складам), нам необходимо выполнить очистку лишней информации.
1. Очистка номеров сообщений
Чтобы обмен начался «с чистого листа», необходимо обнулить номера принятых и отправленных сообщений в обеих базах для данного узла. Это можно сделать вручную в форме узла плана обмена, установив значения в 0.
2. Удаление лишних данных (при необходимости)
Если в подчиненном узле не должно быть данных по определенным организациям, придется воспользоваться обработкой удаления объектов. При стандартном создании начального образа платформа фильтрует данные автоматически, но при методе копирования ответственность за состав данных ложится на администратора.
3. Проверка регистрации изменений
После настройки узла рекомендуется очистить таблицу регистрации изменений в подчиненной базе, чтобы она не пыталась отправить в центр все свои документы при первом же обмене. Используйте стандартную обработку РегистрацияИзмененийДляОбмена.
Если метод с копированием базы по каким-то причинам не подходит, можно попытаться временно модифицировать код конфигурации, чтобы подавить ошибку. Рассмотрим, как это сделать правильно:
Ctrl+Shift+F) по строке "ЭтоГруппа".ОбновлениеИнформационнойБазы. Чаще всего проблема кроется в процедурах создания предопределенных элементов.
Попытка
Если ОбъектыСкладов.ЭтоГруппа Тогда
// Логика обработки групп
КонецЕсли;
Исключение
// Если реквизита нет, просто пропускаем это условие
КонецПопытки;
Важный нюанс: После того как база будет успешно создана и запущена, эти изменения в коде необходимо откатить назад в центральной базе. После этого нужно передать изменения конфигурации в подчиненную базу через стандартный механизм обмена. Помните, что конфигурации в ЦБ и ПБ должны быть идентичными для корректной работы РИБ.
Мы проанализировали ситуацию, когда изменение типовой иерархии справочника приводит к краху механизмов РИБ. Самым надежным решением является использование ПланыОбмена.УстановитьГлавныйУзел() на копии информационной базы. Это экономит время на отладку типовых модулей обновления и гарантирует сохранение работоспособности системы даже при значительных отклонениях от типовой структуры метаданных 1С:Управление торговлей 10.3.