Ошибки РИБ и как с ними бороться

1. Конфигурация узла распределенной ИБ не соответствует ожидаемой.

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

• Чистка кэша. 

  • При работе в режиме предприятия 1с кэширует метаданные для ускорения работы программы и при динамическом обновлении конфигурации использует их до момента перезапуска сеанса пользователя. При это могут возникать ситуации, когда после перезапуска программа не обновила метаданные из измененной, а продолжает использовать старые. В такой ситуации помогает очистка кэша, при новом запуске программа обновит метаданные. Очистить кэш можно множеством способов, приведу несколько из них:
  • На мой взгляд самый простой из них это удаление базы из списка информационных баз и добавление заново под другим именем. При добавлении базы как новой в список информационных баз программа создаст новый каталог на диски для хранения кэшей к этой базе.
  • Можно очистить базу удалив папки с кэшем. Папки храняться в зависимости от версии windows:

Для Windows XP: 

<каталог пользователя>\Local Settings\Application Data\1C\1Cv82 

<каталог пользователя>\Application Data\1C\1Cv82 

Для Windows 7: 

<каталог пользователя>\AppData\Roaming\1C\1Cv82

<каталог пользователя>\AppData\Local\1C\1Cv82 

Для Windows 8:

<каталог пользователя>\AppData\Roaming\1C\1Cv82

<каталог пользователя>\AppData\Local\1C\1Cv82

Можно воспользоваться готовым bat-файлом для удаление файлов кэша, как это описано в этой статье "Чистка кэша 1с".

• Не денамическое обновление корневого узла. 

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

• Перенос конфигурации в распределенный узел.

  • Самый распространенный способ решения данной проблемы, он почти в 100% случаев помогает решить данную проблему, опять таки замечу, что почти в 100%, т.к. у меня возникали случаи, когда переносом конфигурации из главного узла в подчиненный проблема не решалась. Данный метод заключается в переносе конфигурации из главной базы в распределенную.

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

    • выгружаем из центральной базы конфигурацию в cf-файл;
    • отвязываем переферийную базу от главного узла, вызвав команду:

      ПланыОбмена.УстановитьГлавныйУзел(Неопределено);

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

      ПланыОбмена.УстановитьГлавныйУзел(Параметр);

      где в качестве параметра передаем главный узел распределенной базы.

Для выполнение этих действий удобнее всего воспользоваться обработкой, которую можно скачать здесь (подходит для всех конфигураций на не управляемых формах, т.к. Розница 1.0 или УТ 10.3, огромное множество аналогичных можно найти на просторах инфостарта).

• Подмена хэша конфигурации в файле обмена.

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

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

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

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

Блок файла обмена из главной базы: 

 <v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
    <v8de:Version>106.0</v8de:Version>
    ...здесь идут блоки описания изменений конфигурации...
    <v8de:Digest1>1cf680807e97a5dc0d1ed7f901b07392</v8de:Digest1>
    <v8de:Digest2>038211651cf680807e97a5dc0d1ed7f9</v8de:Digest2>
 </v8de:Config>

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

 <v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
    <v8de:Version>106.0</v8de:Version>
    <v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
    <v8de:Digest2>11651cf680807e97a5dc0d1ed7f901b0</v8de:Digest2>
 </v8de:Config>

2. Номер сообщения меньше либо равен ранее принятому.

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

Бывают случаи, когда файл выгружается или загружается в копию базы и не может быть загружен так как нумерация файлов обмена нарушена. В таком случае помогает изменение нумерации файлов. В типовых конфигурациях это можно сделать с помощью раздела "Регистрации изменений для обмена", в старых версиях на неуправляемых формах (УТ 10.3, Розница 1.0 и т.д.) в него можно попасть из монитора обмена, а в новых (УТ 11, Розница 2.x и т.д.) в него можно попасть из раздела синхронизации данных "Состав отправляемых данных", в нем есть пункт "Изменить номера сообщений" для неуправляемых форм и "Редактировать номера сообщений" для управляемых. Номер принятого в таком случае надо ставить меньше (вплоть до 0), а номер отправленного ставить больше (можно даже 10000). После изменения номеров сообщений обмен должен начать проходить.

3. Ошибка преобразования данных XML.