1. В ПБ загружен и выгружен обмен из ЦБ, ошибок не возникло, в Конфигураторе ПБ конфигурация обновлена и больше не просит обновить, в ЦБ при загрузке выходит названная ошибка
Ошибка чтения файла сообщения обмена: {Обработка.КонвертацияОбъектовРаспределенныхИнформационныхБаз.МодульОбъекта(197)}: Ошибка при вызове метода контекста (ПрочитатьИзменения): Данные принимаются от узла, для которого зарегистрированы изменения конфигурации.
Необходимо произвести перенос изменений конфигурации в узел.

2. по рекомендациям http://catalog.mista.ru/public/65456 провёл первый способ в ПБ, то есть отвязал ПБ от ЦБ, загрузил конфигурацию и привязал снова, выгрузил в ЦБ и та же ошибка при загрузке в ЦБ

3. открыл XML
в ЦБ  
<v8de:Digest1>6a70a37b3258ee9d759c6d3c496abe86</v8de:Digest1>
<v8de:Digest2 [v2="0f6e26b75bc66a05cdcfe4c397d75f62" Extensions="0000000000000000000000000000000000000000"]>d41d8cd98f00b204e9800998ecf8427e</v8de:Digest2>

в ПБ
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2 [v2="e24e0c39fcae7c07fb4079a25b228918" Extensions="0000000000000000000000000000000000000000"]>d41d8cd98f00b204e9800998ecf8427e</v8de:Digest2>

Таким образом, Digest2 параметр совпадает, тем не менее, ЦБ не принимает. Как решить, может что упустил ?

3. Попробовал Способ 2, загрузил в ПБ исправленный файл с дайджестами ровно как в выгрузке из ПБ, ПБ отказывается загружать такой обмен, говорит Искажены изменения конфигурации! Может тут что-то не так сделал ?
4. Гипотезы что сделать ещё:  
4.1 Есть ли смысл в XML от ЦБ в ПБ удалять ветки Metadata ? Может от этого в ПБ загрузится нормально ?
4.2 Может по пункту 3. не нужно переносить из файла ПБ в файл ЦБ параметр v2 ?  
4.3 Может в Выгрузке из ПБ в ЦБ что-то исправить, чтобы ЦБ "признала правильной" загрузку ? Только что исправить, если Digest2 и так совпадает ?
Конфигурацию в ЦБ саму с собой сравнивал, нет различий, обмены остановлены, база ПБ файловая локальная
Насчет сброша кеша, где это стоит сделать если стоит и как ?

чем выгружаешь и по какому формату

(1) выгрузка обычным встроенным обменом в УТ11.4,  формат XML ...

не вдаваясь в подробности уидов и т.д. Нарушена сама последовательность, кто центральный, кто периферийный.

Если у тебя есть в Центральном изменения конфига для ПБ, то их таки нужно выгрузить и принять в периферийке, а затем уже отправлять обратное сообщение. А у тебя над ПБ делаются некие манипуляции, но выгрузку из ЦБ не делаешь и не принимаешь. Может и можно руками подшаманить, но зачем, если есть нормальный способ сделать все последовательно

получил в ЦБ сообщение с отказом принимать нечто.
сформировал выгрузку в ПБ
принял эту выгрузку в ПБ
сформировал пакет для ЦБ - принял и увидел как все прошло

(3) в ПБ штатно загружал, принял обновление в ПБ, но ЦБ не принимает, только потом стал извращаться со спецметодами
(4) именно так проводил, ЦБ не принимает, в http://catalog.mista.ru/public/65456 это разжевано

там разжевано для сообщения другого вида

Какую строку нужно добавить в XML файла из ПБ в ЦБ, чтобы дать понять ЦБ, что конфигурация в ПБ принята и ЦБ "успокоилась" ?

(0) Демоническое обновление, попробуй очистить кэш конфигурации на ЦБ.

Для перестраховки (вместо очистки кэша) можно выгрузить конфу ЦБ и загрузить её в новую(!) пустую базу. После этого выгрузить конфигурацию из новой базы и использовать её для загрузки в ЦБ(!) и в ПБ(!). После этого провести взаимный обмен как обычно.

(8) очистка кеша не помогла

(9) а что ты сделал после очистки?

(10) повторно выгрузить из ЦБ в ПБ, верно ?

(11) конфигурация попала в выгрузку? Что сказала ПБ на это?

(12) конфигурация попала, ПБ приняла и обновления в конфигураторе ПБ не потребовала

Тогда я бы попробовал просто сбросить все зарегестриванные в ЦБ для выбранного узла изменения. Хуже не будет, а ошибка должна пропасть. Изменения из ЦБ данных прошли, т.к. ПБ их приняла без сообщений

Синтаксис:

УдалитьРегистрациюИзменений(<Узлы>, <Данные>)
Параметры:

<Узлы> (обязательный)

Тип: ПланОбменаСсылка.<Имя плана обмена>; Массив.
Одиночное значение типа ПланОбменаСсылка.<Имя плана обмена> или массив таких значений, показывающие для каких узлов удаляются записи регистрации изменений.

Удалять регистрацию изменений - бесполезный совет - "регистрация изменений данных" <> "регистрация изменений конфигурации".

(16) как "сказать" ЦБ, чтобы она перестала считать ПБ не обновившей у себя конфигурацию ? Либо в XML должна быть соответствующая секция, либо в самой ЦБ можно как-то изменить признак для конкретной ПБ ?  с учетом что ЦБ серверная, может проще изменить нужное значение в нужной табличке как крайний вариант либо что-то в ХМЛ из ПБ в ЦБ подправить ?

(17) ну на самый крайний случай, я и такое пробовал в безвыходной ситуации (помогало) : измени что-то из структуры метаданных. Например, не важную какую константу или добавь еще одну константу - просто, что конфигуратор решил, что есть реструктуризация метаданных. Тогда он при выгрузке перезатреть эту всю инфу заново и возможно все пройдет уже успешно.

ап !! как "сказать" ЦБ, чтобы она перестала считать ПБ не обновившей у себя конфигурацию ?

См. (0):

ЦБ отправляет обновление (Digest1 = "6a70a37b3258ee9d759c6d3c496abe86") для ПБ с конфигурацией "0f6e26b75bc66a05cdcfe4c397d75f62" (значение Digest2). ПБ обрабатывает обновление, но возвращает значение Digest2 = "e24e0c39fcae7c07fb4079a25b228918" - конфигурации не идентичные.

Если ЦБ получит "нужное" значение от ПБ, то ЦБ перестанет третировать ПБ обновлением и в очередном сообщении обмена от ЦБ Digest1 будет заполнен нулями, а Digest2 - значением ожидаемой конфигурации ПБ. Те-же самые значения ожидаются и от ПБ.

Это всё теория, это всё - как должно быть.

А на практике пока что у Вас демоническое обновление и два варианта: а) ЦБ отправляет в ПБ неверное значение "внутреннего идентификатора" конфигурации базы; б) ПБ отправляет в ЦБ неверное значение "внутреннего идентификатора" конфигурации базы.

Т.е, если говорить проще, то вероятность возникновения демонического обновления есть как на стороне стороне ЦБ, так и на стороне ПБ. Замечу при этом: я говорю о конфигурациях информационных баз, а не тех конфигураций, которые Вы выгружаете/загружаете.

Имхо, в особо тяжелом случае, я бы повторил бы обновление конфигурации в новой, пустой базе с предыдущей версией конфигурации из архива рабочей базы и, используя обновленную конфигурацию как эталон, - залил бы её и в ЦБ, и в ПБ.

Надеюсь не сложно сказал.

(20) почему вы ориентируетесь на "предпараметр" v2, а не на реальный параметр >d41d8cd98f00b204e9800998ecf8427e< ?

Пока надумал две гипотезы:
1. в файле от ПБ удалить нафик препараметр v2 (не знаю как правильно в терминах XML это называть) и скормить это ЦБ, то есть
в ПБ
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2 [v2="e24e0c39fcae7c07fb4079a25b228918" Extensions="0000000000000000000000000000000000000000"]>d41d8cd98f00b204e9800998ecf8427e</v8de:Digest2>
заменить на:
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2>d41d8cd98f00b204e9800998ecf8427e</v8de:Digest2>

2. заменить препараметр v2 в ПБ на аналогичный в ЦБ
по рекомендации (20)

(22) Вам слово "Extensions" ни на что не намекает? Пока в платформе не появились расширения, формат Digest2 соответствовал формату Digest1, они имели одинаковый формат. Когда (если) получите ошибку "Данные принимаются от узла с другим набором расширений, меняющих структуру данных" - вспомните про дополнение-расширение к Digest2.

PS: неправда, я Вам не рекомендовал заменять параметры - это бесполезно. Я только предположил, как это должно быть при "штатной" обработке сообщений обмена с передачей изменений конфигурации.