Добрый день!
Подскажите пожалуйста каким образом можно один объект метаданных в конфигурации поставщика заменить на тот же объект из той же самой базы, но из основной конфигурации?

(0) а зачем это делать?
обячно просто хотят обратного и обратное-то как раз и понятно

А я знаю как, и что будет при следующем обновлении :)

(1) Обратно - это значит основную привести к поставщика? Ну вроде бы основную можно просто руками открыть и отредактировать как нужно, в т.ч. так чтоб совпала

(2) Я тоже знаю.
При следующем обновлении я не увижу такой вот картинки: http://i63.fastpic.ru/big/2015/0303/9f/b847db5eb92de24961cd687e33bc449f.jpg

А я и не хочу её видеть.

(1) + зачем?

(4) если тебе удастся заменить объект в конфе поставщика, то при обновлении все станет еще хуже - 1с посчитает, что в типовой конфе документ удалили и добавили заново.
Чтобы все заработало по-человечески, тебе надо восстановить правильный GUID у метаданных документа.

(6) !

(6) 1с посчитает, что в типовой конфе документ удалили и добавили заново  - в пределах одного релиза? Номер конфигурации-то не изменится

(8) Ну и нафига документ руками добавляли?

(8) Ну это я уж тебе не отвечу как оно так получилось, сам не знаю

(10) То есть сломали одно - надо дальше доламывать?

(10) Надо было изначально нормально обновлять.
Если документов немного, то как вариант:
1. Выгрузи их в XML стандартной обработкой.
2. Переименуй свой документ.
3. Обнови нормально.
4. Загрузи обратно документы в новый справочник с правильным УИДом.

(12) Чтобы сделать шаг 3 мне нужно конфигурацию поставщика сохранить в файл, а я тоже не знаю как это сделать

(11) Да не переживай, я ничего не сломаю, ты на (0) ответь, а дальше я поэксперименирую, проверю десять раз, если что-то не устроит ещё спрошу

(13) В окне настройки поддержки есть кнопка "Сохранить в файл".

+(14) Надо привести к типовой, в (12) всё верно написано. А в (0) дурацкая хотелка, обнаруживающая непонимание.

(15) Дык я и не отрицаю непонимание, я ж только разбираюсь с этим всем. За (14) спасибо, щас поковыряюсь

(16) Смысл в том, что стандартно через конфигуратор изменить конфигурация поставщика нельзя.
Можно в 2 этапа выгрузить ее в текст либо расковырять внешними утилитами типа v8unpack, поменять, и загрузить обратно.
Но твою проблему это не решит.
Сообщение о расхождении исчезнет, но снова появится при следующем обновлении.
Нужно именно обновлять основную по конфигурации поставщика.

(17) Ох, Евгения, не надо таких подрывных советов давать :) Это не для крепких духом и слабых умом.

(18) Слабых умом - это ты про себя, очевидно?

(19) Решение задачи в лоб никакой силы ума под собой не обнаруживает, увы. Так что нет, не про себя.

Еще читал такую фигню (в проф-разработке, кажись), что при ПЕРВИЧНОМ объединении конфы с конфигурацией поставщика (с постановкой на поддержку с возможностью изменений) есть возможность выполнить ручную установку соответствий объектов конфигурации. Т.е. возможность разных внутренних ID в основной конфе и конфе поставщика предусмотрена, получается. Но сам ни разу не пробовал. Можно попробовать через этот пень выкрутиться. Естественно, полная поддержка после такого уже не светит, как я понимаю.

(21) Не нужно это. У него типовой(или слегка измененный) документ с другим ID. Ему нужно привести к типовой, проще всего это сделать через обновление+перенос данных. Зато в дальнейшем таких проблем не возникнет. А изменение конфы поставщика и шаманства с ID выльются в гемор при каждом обновлении.

гуид можно легко поменять,  выгрузи конфу в файлы

но лучше менять гуид в рабочей базе, чем у поставщика

(22) Это не шаманство. Это штатная возможность, как я понял. Она дает возможность при горизонтальной поддержке иметь один и тот же объект конфигурации на поддержке у разных поставщиков одновременно. Типа один и тот же док, а в разных конфигурациях поставщика разные формы поддерживаются, например.

(25) Дело не в этом. Задаться надо вопросом "зачем"? В данном случае это не нужно, только будет много телодвижений при повторной постановке на поддержку.

(26) Ну, я бы попробовал из интереса. Снять с поддержки, а потом объединить с конфой поставщика, установив ручное соответствие для проблемного дока. Если я всё правильно понял и это сработает, то в дальнейшем проблем с обновлениями не будет (будет использоваться зафиксированное соответствие). Зачем? Не придется перебрасывать данные.

(27) Проще тогда (23)(24), быстрей и снимать-ставить не надо будет.

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

(29) Подводные камни везде могут быть.

(30) На суше вероятность подводных камней исчезающе мала.

(31) Фигня это. Лучше разбираться досконально в том, как всё устроено, чем молиться на инструменты(которые тоже далеко не безглючны).

(32) Лучше. Но стоит ли? Да и возможности реверс-инжиниринга ограничены.

(33) Это эксперимент :) Как и то, что ты предлагаешь. И сущностей этот эксперимент не плодит, в отличие от "таблицы соответствия" в твоём предложении.

(34) Не спорю. Зная привычку 1С знатно кособочить в редких кейсах, плотно тестить придется оба варианта.

А насчет лишней сущности - не уверен. "Таблица соответствий" может использоваться всегда, только в простейшем случае используется соответствие 1:1