В процессе разработки на платформе 1С:Предприятие часто возникают ситуации, когда функционал логически разделяется на несколько расширений. Однако при попытке назначить реквизиту объекта из одного расширения тип данных (например, справочник), созданный в другом расширении, разработчики сталкиваются с тем, что нужный объект просто недоступен для выбора. Рассмотрим, почему это происходит и какие существуют способы решения данной задачи.
Архитектура платформы 1С:Предприятие построена таким образом, что каждое расширение является изолированной сущностью. Система поддерживает видимость объектов по следующему принципу:
Взаимодействие между двумя независимыми расширениями на уровне метаданных (например, выбор типа реквизита) платформой не поддерживается. Объекты одного расширения «не знают» о существовании объектов другого расширения, что и создает ограничение, с которым столкнулся автор вопроса.
Если функционал ваших разработок тесно связан и требует постоянного обмена данными между собой, самым архитектурно верным и простым способом будет объединение всех объектов в одно расширение. Это позволит:
Если ваши расширения выполняют схожие задачи, лучше потратить время на слияние, чем поддерживать сложную схему синхронизации между несколькими отдельными расширениями.
Если созданный справочник является фундаментальным элементом бизнес-логики и должен использоваться во многих подсистемах или различных расширениях, рассмотрите возможность его переноса в основную конфигурацию. Это позволит сделать объект «глобально видимым» для любого расширения, подключенного к данной базе.
Многие опасаются снимать конфигурацию с поддержки, однако создание объекта непосредственно в конфигурации не означает полной потери возможности обновлять систему. Вы сможете продолжать вести разработку в расширениях, при этом «ядро» данных будет доступно всем участникам процесса.
В тех случаях, когда архитектурные изменения нежелательны, можно отказаться от жесткой типизации реквизита СправочникСсылка в пользу универсального типа. Для этого в регистре сведений можно использовать реквизит типа Строка (длиной 36) или УникальныйИдентификатор.
Этот метод позволяет хранить в регистре строковое представление ссылки. Однако важно понимать, что при таком подходе вы теряете:
При использовании этого метода вам придется самостоятельно реализовывать логику получения данных и проверки их существования в коде, например, через ПолучитьСсылку() по сохраненному идентификатору.
Еще одним способом решения является применение ПланВидовХарактеристик, который создается в основной конфигурации. Этот объект может содержать значения различных типов. Используя ПВХ в качестве типа реквизита, вы можете хранить в нем ссылки на справочники, документы и другие объекты системы, не нарушая архитектурных ограничений. Это требует более сложной программной реализации, но позволяет избежать дублирования объектов и «расползания» логики по разным частям системы.
При попытке реализовать синхронизацию между «копиями» справочников в разных расширениях (как изначально планировал автор), вы столкнетесь с созданием двух разных таблиц в базе данных. Это повлечет за собой:
Рекомендуем придерживаться либо объединения расширений, либо переноса базовых сущностей в основную конфигурацию. Это обеспечит стабильность работы вашей Конфигурация и избавит от излишней технической сложности при дальнейшей разработке.