Я так помню что сейчас в расширениях можно добавлять своих хранимые сущности - реквизиты, справочник и пры. А как быть если мне нужно из такой вот базы с расширением перенести данные в другую базу? Штатная то обработка с выгрузкой структуры в конфигурацию конвертации ведь ничего про объекты расширения, в отличии от штатных метаданных основной конфигурации, знать ничего не будет? Как быть?

(0) почему не будет знать.. вся структура описана в правилах обмена..

(1) Вопрос не про написанные готовые правила обмена. Правила обмена писать мне. Вернее, в идеале, лучше вообще не писать а воспользоваться какой-нибудь обработкой между похожими или идентичными конфигурациями.
Какую я перед собой ставлю задачу. Есть допиленая типовая конфигурация, в которой те кто её дорабатывал добавили ряд справочников и документов. Заказчик тем что конфигурация снята с замочков страшно недоволен. Я хочу подготовить такой же релиз, с такими же добавляемыми объектами, но объекты будут добавлены в расширении.
Правила того же релиза в части обмена конфигурация-конфигурация о добавленных разработчиками и соответственно добавляемыми мной в расширение объектах ничего не знают. Значит придётся выгружать правила обмена. Загружать в КД. Загружать в КД структуру метаданных и править правила.
Есть штатные обработки по выгрузке структуры метаданных, в моём случае это обработка MD83Exp.epf  идущая в поставке. В части конфигурации в которую предыдущие разработчики объекты вопрос не большой, они в метаданных основной конфигурации, ну конечно если я и получателя, то есть приведу к виду что все те же самые объекты которые добавил разработчик будут добавлены в расширении, то наверняка можно пренебречь тем что часть метаданных не в основной конфигурации, а в расширениях. Ну а в принципе. В сферическом абстрактном случае. Если часть метаданных не в основной конфигурации, а в расширении, чем их выгружать в КД чтобы потом использовать их для разработки правил обмена и/или правил регистрации?

"Заказчик тем что конфигурация снята с замочков страшно недоволен"
Беги оттуда

(3) +100500

(3) (4) какой смысл у этого совета к описываемой ситуации?

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

В итоге таких попыток, самые последние релизы глючат на использовании РИБ обменов.

Альтернатива, которую от безысходности в данном конкретном моменте продвигает 1С - обмен в виде, например
---
Информация об обновлениях программных продуктов 1С:Предприятие1С:Управление торговлей 11
Новое в версии 11.4.1
... Организована поддержка версии 1.4 формата «Enterprise Data».
---

Я честно в Enterprise Data не копался - большего посоветовать не могу

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

(7) а почему некая старая обработка должна видеть чего-то где-то в расширении для новых платформ?

(8) потому что она пользуется методами платформы и её глубоко пофиг как физически хранятся данный, в основной конфе или в расширении

(8) А почему старая обработка видит данные в новой конфигурации и её не нужно каждый раз переделывать?
Потому что обработка универсальная, использует методы платформы. А если платформа позволяет дополнять метаданные с помощью расширения, значит и обработка обратившись к этой платформе получит информацию о метаданных.
Эксперимент не проводил, но уверен, что никакой проблемы в сабже нет.

(5) Замочки, отсутствием которых "недоволен Заказчик", никакого отношения к кривой реализации не имеют.

остроумные ответы

(12) проверил, Макс прав, старая обработка работает. Всё видит.

(9) и какого фига тогда ТИИ "методами платформы" гробит данные, внесенные в базу расширением?

(14) Есть подозрение, что на ТИИ просто забили

(15) потому что как раз Тии манипулирует данными напрямую, и ей пофиг что там платформа думает и знает

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