При работе с расширениями в системе 1С:Предприятие 8.3 программисты часто сталкиваются с ситуацией, когда новые объекты (справочники, документы), созданные внутри расширения, невозможно выбрать в качестве типа данных для реквизитов других объектов в том же расширении. Особенно остро эта проблема проявилась в релизах ветки 8.3.18. В рамках данной статьи мы подробно разберем причины возникновения этого «глюка», рассмотрим способы его обхода и проанализируем риски хранения данных в расширениях.
Рассмотрим стандартную ситуацию: разработчик добавляет в расширение заимствованный объект (например, Справочник.ДисконтныеКарты) и создает два новых собственных справочника внутри этого же расширения (например, Размер и Источник). При попытке добавить новые реквизиты в ДисконтныеКарты с типами СправочникСсылка.Размер или СправочникСсылка.Источник, эти типы отсутствуют в стандартном окне выбора типов.
Проанализируем причины. Основная причина кроется в ошибках кэширования метаданных в конфигураторе определенных релизов платформы, в частности 8.3.18.1208. Платформа просто «не успевает» обновить дерево доступных типов во вспомогательных диалоговых окнах.
Рассмотрим первый способ обхода (визуальный):
Как показывает практика, в проблемных релизах платформа ведет себя непоследовательно. Если нажать на кнопку выбора типа (три точки) и открыть полноценное окно выбора, новых справочников там не будет. Однако, если попытаться выбрать тип напрямую из выпадающего списка (если это позволяет интерфейс свойств реквизита), нужные объекты могут там присутствовать. Это связано с тем, что разные элементы интерфейса конфигуратора используют разные механизмы получения списка метаданных.
Выясним, какие версии платформы наиболее стабильны для работы с расширениями. Релиз 8.3.18.1208 признан сообществом и разработчиками одним из самых «багованных» в части работы с расширениями метаданных.
Для полноценного решения проблемы рекомендуется выполнить следующие действия:
Если по каким-то причинам оперативно обновить серверную платформу невозможно, разберем по шагам алгоритм «проталкивания» метаданных через файловую базу:
.cfe)..cfe.Важный нюанс: после такой загрузки типы данных будут работать корректно, система будет их распознавать, но изменить их в конфигураторе на этом релизе вы все равно не сможете (они снова не будут видны в списке), пока не обновите платформу.
Проанализируем ситуацию с хранением данных. Многие разработчики опасаются создавать новые справочники и реквизиты в расширениях. Рассмотрим основные риски и способы защиты:
Рекомендация: Если данные критически важны (например, финансовые показатели, учетные данные), надежнее добавлять реквизиты и объекты в основную конфигурацию. Расширения идеально подходят для логики, интерфейсных правок и временных учетных механизмов.
Чтобы минимизировать проблемы при обновлениях основной конфигурации, разберем подход программного добавления элементов. Вместо того чтобы визуально «заимствовать» форму в расширение и менять ее в редакторе, лучше добавлять новые реквизиты на форму программно в процедуре ПриСозданииНаСервере. Это гарантирует, что при изменении типовой формы поставщиком ваше расширение не «развалится» из-за конфликтов объединения.
Также полезно внедрить механизм «чек-поинтов» для контроля версии конфигурации. Рассмотрим пример кода, который можно разместить в общем модуле расширения и вызывать при запуске, чтобы программист не забыл проверить работоспособность после обновления базы:
Функция ПроверитьВерсиюИсполняемогоКода(пРазрешеноРаботатьВерсии, Отказ = Ложь) Экспорт
// Получаем текущую версию метаданных основной конфигурации
ТекущаяВерсия = Метаданные.Версия;
Если ТекущаяВерсия <> пРазрешеноРаботатьВерсии Тогда
ТекстСообщения = "Внимание! Версия конфигурации изменилась с '%1' на '%2'.
|Необходимо проверить корректность работы расширения!";
ТекстСообщения = СтрШаблон(ТекстСообщения, пРазрешеноРаботатьВерсии, ТекущаяВерсия);
// Вывод сообщения пользователю или запись в журнал регистрации
ОбщегоНазначенияКлиентСервер.СообщитьПользователю(ТекстСообщения,,,, Отказ);
КонецЕсли;
Возврат Отказ;
КонецФункции
Этот простой метод позволяет вовремя заметить, что основная конфигурация обновилась, и расширение требует ревизии. Использование таких проверок вместе с внешними инструментами сравнения кода (например, плагины для Notepad++ или специализированные 1С-диффы) существенно ускоряет поддержку доработанных систем.
Подводя итоги, сформулируем основные правила работы с расширениями при возникновении «глюков» платформы:
Проверку конфигурации (с установленной галкой «Проверка расширений») для принудительного обновления индекса типов.