Что касается восстановления. Есть более простые способы, включающие не все пункты приведенного ниже списка, но они не всегда помогают, как например было в одном из моих случаев

• Файл с сообщением уже загружался в базу-приемник. Необходимо выгрузить его из базы-источника заново.

Ошибка «Ошибка при копировании файла c FTP ресурса… Ошибка работы с Интернет: Timeout was reached»

• С сайта, через который проходит обмен, не получается скопировать нужный файл. Это может быть связано с медленной работой вашего интернета или с проблемами самого сайта.
• Нужно попробовать повторить обмен через 15-30 минут.

Ошибка «Редактирование данных этого периода запрещено. Изменения не могут быть записаны…»

• Загружаемые данные содержат документы из закрытого периода.
• Нужно провести обмен под пользователям, имеющим право на изменение документов в этом периоде.

Ошибка «Необходимо выполнить обновления конфигурации базы данных. Обновление может быть выполнено в режиме конфигуратора»

• Зайти в конфигуратор.
• Выполнить пункт меню «Конфигуратор / Обновить конфигурацию базы данных».
• Если выдается вопрос с ответами только «Повтор», «Отмена», «Обновить динамически», нажать кнопку «Обновить динамически».
• Если выдается вопрос с ответами только «Повтор» и «Отмена».
  • всем пользователям выйти из 1С.
  • нажать кнопку «Повтор».
• На оставшиеся вопросы ответить утвердительно: «Да», «Принять», «ОК».
• Закрыть конфигуратор.
• Повторить загрузку из центра.

Ошибка «Конфигурация не соответствует ожидаемой», «Попытка приема изменений от неизвестной конфигурации»

• Ошибка в базе данных.
• Необходимо обратиться к специалистам.

Обмен проходит очень долго, зависает

• Поступает много данных.
  • Выясните у отправителя, выполнял ли он групповое изменение документов (проведение, замена реквизитов и т.д.).
  • Если да, оставьте компьютер с обменом на ночь.
• Большой файл не может скачаться из интернета.
  • Если файл имеет большой размер (80-100 Мб и больше), то, возможно, 1С просто не может его скачать.
  • Необходимо скачать файл и загрузить его в 1С вручную (возможно при помощи специалистов).
    • пункт меню «Операции» / Планы обмена / Полный / Кнопка на панели «Прочитать сообщение».
• База повреждена:
  • Попробуйте
• Если эти действия не помогли — придется обратиться к специалистам.

• Если исправить ошибку не удалось, звоните по телефону экстренной поддержки +7 (8512) 64-55-05.
• Наш специалист поможет вам, в каком бы городе вы не находились.

Эта ошибка является типичной для . Ошибка «Конфигурация узла распределенной ИБ не соответствует ожидаемой» является системной. В основном возникает из-за аварийного завершения работы во время обмена данными по УРИБ.

Решить это можно достаточно простым способом. Рассмотрим его.

Инструкция

1. Сделайте копии баз, над которыми будут производиться работы (В конфигураторе «Администрирование - Выгрузить информационную базу»).

2. Запустите конфигуратор главной базы узла РИБ.

3. Сохраните конфигурацию центрального узла в файл базы данных («Конфигурация — Сохранить конфигурацию в файл…»)

4. Откройте конфигуратор базы подчиненного узла.

Получите 267 видеоуроков по 1С бесплатно:

5. Снимите конфигурацию подчиненного узла с поддержки (Конфигурация — Поддержка — Настройки поддержки — Снять с поддержки):

6. Загрузите конфигурацию базы данных («Конфигурация — Загрузить конфигурацию из файла…»).

8. После реструктуризации необходимо зайти в режим предприятия и установить главный узел конфигурации. Это сделать можно с помощью специальной обработки — . Обработка работает как в режиме управляемого приложения, так и в режиме обычного приложения.

9. В обработке необходимо выбрать главный узел и нажать «Выполнить»:

10. Готово! Попробуйте запустить обмен, система должна корректно выполнить обмен.

Для начала список используемых сокращений:

• РИБ - распределенная информационная база
• ЦБ - центральная база, корневой узел РИБ
• УБ - удаленная база, БД удаленного узла РИБ

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

• во время приёма файла сообщения в УБ "упала" база, в связи с чем, видимо, и произошла разсинхронизация между конф. ЦБ и УБ;
• под MSSQL клиент загрузил копию рабочей базы и не выключил в копии регл. задания автообмена, в результате часть сообщений в удаленные узлы формировалась из рабочей БД, а часть из копии, что и привело рассинхронизации конфигураций

Есть также мнение, что к этой ошибке приводит использование механизма динамического обновления базы. Здесь есть сомнения, потому как с одной стороны динамическое обновление никогда не затрагивает структуры БД, а механизмы РИБ всё-таки работают именно со структурой БД, а не с прикладной её частью, тем не менее в РИБ используется механизм формирования цифровой подписи версии конфигурации (в дальнейшем буду называть её для сокращения хэшем), и при изменении прикладной части хэш естественно обязан пересчитаться. Не буду ни отрицать этого, ни утверждать, т.к. если и сталкивался с этой ситуацией, то явных доказательств этого не нашел.

Для исправления использую 2 методики, в зависимости от ситуации.

ПЕРВАЯ МЕТОДИКА

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

Последовательность действий:

1. выгружаем из ЦБ cf-файл;
2. отвязываем УБ от РИБ (метод УстановитьГлавныйУзел, готовую обработку можно найти в приложении или в других публикациях);
3. заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла" (а не сравнением-объединением!!!);
4. восстанавливем признак РИБ для УБ.

В большинстве случаев этих действий более чем достаточно, что восстановить обмен, но не всегда...

ВТОРАЯ МЕТОДИКА

Применяется в случае, если первая методика не сработала, а выгрузить заново узел не представляется возможным.

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

Пришла мысль попробовать подменить хэши файлов конфигураций непосредственно в XML-файлах обмена. Описание структуры файла обмена из книги "Профессиональная разработка в системе 1С:Предприятие 8" дало слабое представление о формировании цифровых подписей конфигураций и изменений в них, но определило направление поиска: значения Digest1 и Digest2. Всё остальное выяснял чисто эмпирическим путём (то бишь методом проб и ошибок), но закономерность установить таки получилось.

Тестовые эксперименты прошли удачно. На рабочих базах тоже всё прошло благополучно.

Итак, последовательность действий:

1. выполняем действия 1 - 4 первой методики;
2. выгружаем из УБ файл обмена, но не загружаем его в ЦБ;
3. выгружаем из ЦБ файл обмена, но не загружаем его в УБ;
4. в файле обмена из ЦБ заменяем блок, содержащий информацию об изменениях конфигурации и хэши (Digest1 и Digest2), на блок хэшей из файла УБ (пример см. ниже)
5. производим загрузку файла из 4-го пункта в УБ;
6. обязательно перезаписываем файл обмена из УБ (2-й пункт)! этот файл не должен быть загружен при обмене в ЦБ!
7. для проверки делаем несколько последовательных обменов.

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

Блок файла обмена из ЦБ

106.0
...здесь идут блоки описания изменений конфигурации...
1cf680807e97a5dc0d1ed7f901b07392
038211651cf680807e97a5dc0d1ed7f9

нужно заменить на блок файла обмена из УБ (обратите внимание Digest1 у файла из УБ всегда равен "00000000000000000000000000000000"!!!)

106.0
00000000000000000000000000000000
11651cf680807e97a5dc0d1ed7f901b0

Перечисленные действия необходимо выполнять с предельной осторожностью, некорректная последовательность чревата полной неработоспособностью РИБ. Поэтому перед этими действиям создание резервных копий ОБЯЗАТЕЛЬНО!

Распределенная информационная база (РИБ) достаточно часто используется для организации работы филиалов и подразделений, позволяя оперативно обмениваться информацией, сохраняя нужную степень автономности. Несмотря на то, что данная технология достаточно надежна, время от времени ломается и она. Сегодня мы рассмотрим одну из довольно распространенных ошибок: Расскажем о причинах ее возникновения и методах борьбы с ней.

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

На практике иногда случается так, что между сеансами обмена, особенно если на периферии плохо с каналом, конфигурация главного узла успевает измениться дважды. Например, внесли изменения, выгрузили, периферийная база изменения получила, но еще не применила их, что может занять некоторое время, и подтверждения еще не прислала. Если в этот промежуток внести изменения еще раз и снова выгрузить обмен, то получится, что центр ожидает увидеть в периферийном узле конфигурацию №1 и попытается обновить ее на конфигурацию №3, а по факту столкнется там с конфигурацией №2. Иногда подобная ситуация возникает при динамическом обновлении центральной базы. В итоге обмен станет невозможным, и вы получите сообщение о том, что Конфигурация узла распределенной ИБ не соответствует ожидаемой!

В общем мораль этой истории проста - не ведите активную доработку рабочей базы, а если ведете, то завершайте все сеансы обмена до внесения следующих изменений. Но как быть, если такая неприятность все-же произошла?

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

Здесь стоит кинуть камень в огород разработчиков, которые выдают как ошибку и точно также подсвечивают красным ситуацию Номер сообщения меньше или равен номеру ранее принятого сообщения , которая в общем-то является вполне нормальной. В итоге у пользователей восприятие ошибок притупляется, и они просто перестают читать выводимые сообщения, считая, что все хорошо и просто другая сторона еще не сделала обмен у себя.

Но вернемся к нашей ошибке. Решение довольно простое и лежит на поверхности: привести конфигурацию периферийной базы к ожидаемой, т.е. привести ее в соответствие с конфигурацией центрального узла. Но на практике сделать это не так просто. Если мы откроем периферийную базу в конфигураторе, то увидим, что изменения заблокированы средствами управления РИБ.

Чтобы изменить конфигурацию подчиненного узла потребуется временно отключить его от центральной базы. Для этих целей можно воспользоваться одной из обработок, которых достаточно представлено в сети, либо отключить ИБ от центрального узла с помощью параметра запуска Конфигуратора /ResetMasterNode .

Откройте командную строку и введите (с учетом версии платформы и реального пути установки):

После выполнения данной команды появится обычное окно стартера, выберите там нужную базу и нажмите кнопку Конифгуратор .

Запуска ИБ при этом не произойдет , т.е. может показаться, что ничего не произошло, но открыв базу в Конфигураторе повторно, можно убедиться, что она отключена от главного узла и доступна для внесения изменений.

Внимание! На платформах 8.3.7 - 8.3.9 выполнение данной команды приводит к аварийному завершению работы. Ошибка исправлена в платформе 8.3.10.

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

Работа с ней предельно проста, запускаем ее в режиме 1С:Предприятия, через Файл - Открыть , затем просто нажимаем нужную кнопку, в нашем случае Отключить главный узел .

Теперь нам потребуется актуальная конфигурация из центрального узла. Для этого откроем центральную ИБ в Конфигураторе и выполним Конфигурация - Сохранить конфигурацию в файл . Полученный файл с расширением cf потребуется передать в периферийный узел.

Затем в периферийном узле запускаем ИБ (предварительно отключив ее от главного узла) в Конфигураторе и снимаем с поддержки. Для этого выбираем: Конфигурация - Поддержка - Настройка поддержки .

В открывшемся окне сначала включаем возможности изменения.

А затем снимаем конфигурацию с поддержки.

Теперь можно загружать конфигурацию из файла, для этого выберите Конфигурация - Загрузить конфигурацию из файла и укажите не переданный из центрального узла cf -файл. После чего вы получите предупреждение о том, что текущая конфигурация не пустая. Обращаем ваше внимание, что проделываемые нами манипуляции потенциально опасны и могут привести к необратимому повреждению ИБ, поэтому перед тем, как продолжать убедитесь, что у вас есть актуальная резервная копия.

Для платформ 1с 8.x при возникновении ошибки «Конфигурация узла распределенной ИБ не соответствует ожидаемой»

Методика решение проблемы

Список используемых мной сокращений:
РИБ — распределенная информационная база
ЦБ — центральная база, корневой узел РИБ
УБ — удаленная база, БД удаленного узла РИБ

По собственному опыт могу сказать, что сталкивался с двумя причинам возникновения ошибки:
во время приёма файла сообщения в УБ «упала» база, в связи с чем, видимо, и произошла разсинхронизация между конф. ЦБ и УБ;
под MSSQL клиент загрузил копию рабочей базы и не выключил в копии регл. задания автообмена, в результате часть сообщений в удаленные узлы формировалась из рабочей БД, а часть из копии, что и привело рассинхронизации конфигураций
Есть также мнение, что к этой ошибке приводит использование механизма динамического обновления базы. Здесь есть сомнения, потому как с одной стороны динамическое обновление никогда не затрагивает структуры БД, а механизмы РИБ всё-таки работают именно со структурой БД, а не с прикладной её частью, тем не менее в РИБ используется механизм формирования цифровой подписи версии конфигурации (в дальнейшем буду называть её для сокращения хэшем), и при изменении прикладной части хэш естественно обязан пересчитаться. Не буду ни отрицать этого, ни утверждать, т.к. если и сталкивался с этой ситуацией, то явных доказательств этого не нашел.

Для исправления использую 2 методики, в зависимости от ситуации.

ПЕРВАЯ МЕТОДИКА

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

Последовательность действий:

1. выгружаем из ЦБ cf-файл;
2. отвязываем УБ от РИБ (метод УстановитьГлавныйУзел, готовую обработку можно найти в приложении или в других публикациях);
3. заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню «Загрузить конфигурацию из файла» (а не сравнением-объединением!!!);
4. восстанавливаем признак РИБ для УБ.
В большинстве случаев этих действий более чем достаточно, что восстановить обмен, но не всегда…

ВТОРАЯ МЕТОДИКА

Применяется в случае, если первая методика не сработала, а выгрузить заново узел не представляется возможным.

Итак, последовательность действий:

1. выполняем действия 1 — 4 первой методики;
2. выгружаем из УБ файл обмена, но не загружаем его в ЦБ;
3. выгружаем из ЦБ файл обмена, но не загружаем его в УБ;
4. в файле обмена из ЦБ заменяем блок, содержащий информацию об изменениях конфигурации и хэши (Digest1 и Digest2), на блок хэшей из файла УБ (пример см. ниже)
5. производим загрузку файла из 4-го пункта в УБ;
обязательно перезаписываем файл обмена из УБ (2-й пункт)! этот файл не должен быть загружен при обмене в ЦБ!
для проверки делаем несколько последовательных обменов.

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

106.0 ...здесь идут блоки описания изменений конфигурации... 1cf680807e97a5dc0d1ed7f901b07392 038211651cf680807e97a5dc0d1ed7f9

нужно заменить на блок файла обмена из УБ (обратите внимание Digest1 у файла из УБ всегда равен «00000000000000000000000000000000»!!!)

106.0 00000000000000000000000000000000 11651cf680807e97a5dc0d1ed7f901b0

Перечисленные действия необходимо выполнять с предельной осторожностью, некорректная последовательность чревата полной неработоспособностью РИБ. Поэтому перед этими действиям создание резервных копий ОБЯЗАТЕЛЬНО!