← На главную

При совместной командной разработке в среде 1С:Предприятие через механизм Хранилища конфигурации разработчики нередко сталкиваются с ситуацией: в процессе работы создано несколько новых объектов метаданных (к примеру, новый документ ЗаявкаНаЗамену и новый план обмена ПланОбменаССайтом). Задача по плану обмена уже завершена и протестирована, а работа над документом еще продолжается. При попытке передать готовый план обмена в Хранилище Конфигуратор выдает ошибку:

«Для выполнения операции требуется помещение объектов: ЗаявкаНаЗамену»

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

Почему платформа 1С блокирует частичное помещение новых объектов

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

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

1. Неделимость дерева метаданных: Чтобы передать в Хранилище хотя бы один новый объект, платформа обязана обновить и корень метаданных. Нельзя поместить новую версию корня, если в ней содержатся ссылки на идентификаторы объектов, отсутствующих на сервере Хранилища.
2. Системные связи и ссылки: Даже если созданные объекты логически не связаны между собой, они могут автоматически пересекаться на уровне подсистем, интерфейсов, прав или состава планов обмена. Платформа проверяет ссылочную целостность всей конфигурации перед фиксацией транзакции.

Именно поэтому механизм Хранилища воспринимает добавление группы новых объектов как единое неделимое изменение дерева метаданных.

Решение 1. Разделение изменений через промежуточный файл конфигурации

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

1. Сохраняем текущую рабочую конфигурацию с обеими доработками в отдельный файл на диске: Конфигурация → Сохранить конфигурацию в файл... (например, backup_work.cf).
2. Отменяем захват всех удерживаемых объектов и корня конфигурации в Хранилище: Хранилище конфигурации → Отменить захват.... При этом локальная база возвращается к актуальному состоянию из Хранилища, а несохраненные изменения откатятся (они надежно сохранены в файле).
3. Захватываем в Хранилище корень конфигурации без подчиненных объектов.
4. Выполняем сравнение и объединение: Конфигурация → Сравнить, объединить с конфигурацией из файла..., указав сохраненный backup_work.cf.
5. В окне сравнения и объединения снимаем все отметки и отмечаем флажком только готовый объект — в нашем примере это ПланОбменаССайтом. Документ ЗаявкаНаЗамену оставляем неотмеченным. Нажимаем Выполнить.
6. Помещаем подготовленные изменения в Хранилище (план обмена и корень конфигурации). Теперь готовый функционал доступен коллегам, а корень свободен.
7. Снова открываем сравнение и объединение с файлом backup_work.cf, но теперь отмечаем флажком только наш недоработанный документ ЗаявкаНаЗамену. Применяем объединение и продолжаем разработку в спокойном режиме.

Решение 2. Помещение всех объектов с блокировкой доступа

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

1. Помещаем в Хранилище и план обмена, и недоработанный документ.
2. Чтобы недописанный документ не мешал пользователям и коллегам, изолируем его: исключаем из состава подсистем, отключаем для него стандартные команды открытия и убираем права из типовых ролей.
3. В модуль формы документа или в модуль объекта на период разработки можно поместить программную заглушку:
   Скопировать код

   
   &НаСервере
   Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
       #Если Не Внедрение Тогда
           ВызватьИсключение НСтр("ru = 'Объект находится в разработке и временно недоступен.'");
       #КонецЕсли
   КонецПроцедуры
   

4. Сразу после фиксации изменений в Хранилище снова захватываем документ ЗаявкаНаЗамену для продолжения работы.

Решение 3. Использование локального расширения конфигурации

Посмотрим на более современный и удобный способ изоляции функционала без риска заблокировать Хранилище. Незавершенный объект можно на время вынести в отдельное локальное расширение:

1. Создаем в локальной информационной базе новое расширение конфигурации (с назначением Дополнение или Адаптация). Локальные расширения не привязаны к Хранилищу основной конфигурации.
2. Переносим реквизиты, формы и модули недоработанного документа ЗаявкаНаЗамену в расширение.
3. Удаляем документ из основной конфигурации.
4. Спокойно помещаем готовый план обмена ПланОбменаССайтом и корень метаданных в Хранилище — никаких конфликтов зависимостей больше не возникнет.
5. После освобождения корня переносим документ из расширения обратно в основную ветку конфигурации.

Организационный лайфхак: пул объектов-болванок

В крупных командах захват корня конфигурации часто становится «бутылочным горлышком», блокирующим параллельную работу. Чтобы свести к минимуму необходимость захвата корня, опытные разработчики используют превентивное создание пустых объектов («болванок»):

1. Администратор Хранилища заранее создает и фиксирует в базе набор пустых каркасов: Справочник1...Справочник5, Документ1...Документ5, РегистрСведений1...РегистрСведений5.
2. Когда программисту требуется создать новый объект метаданных, ему не нужно захватывать корень конфигурации и блокировать коллег. Достаточно захватить одну из свободных болванок, переименовать ее под текущую задачу и наполнить требуемыми реквизитами и формами.
3. Поскольку сам объект уже зарегистрирован в структуре дерева метаданных Хранилища, его переименование и настройка не требуют фиксации корня и могут быть помещены в Хранилище изолированно от других изменений.

Выбор конкретного метода зависит от принятых в проекте регламентов: для быстрых разовых задач отлично подходит вариант с промежуточным объединением через .cf-файл, а для постоянной масштабной разработки стоит настроить работу через расширения или пул предварительно созданных объектов.