1с ошибка хеш версии файла конфигурации

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

            <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>

            <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>

Обновлено: 08.04.2023

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

Прочитав эту статью, вы:

• узнаете о причинах возникновения самой распространенной ошибки РИБ: Конфигурация узла распределенной ИБ не соответствует ожидаемой;
• Получите пошаговые инструкции решения проблемы.

Распределенная информационная база (РИБ)

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

В этих случаях выполняют настройку распределенной информационной базы.

Базу центрального офиса, где собираются все данные, называют центральной, а базы филиалов — периферийными.

Рассмотрим создание РИБ на примере 1С:Бухгалтерия 3.0.

Настройка центральной базы

Настройка РИБ выполняется в разделе Администрирование — Настройки программы —Синхронизация данных — ссылка Настройка синхронизации данных — кнопка Новая синхронизация данных — ссылка Распределенная информационная база .

Перед началом настройки выставляется префикс основной базы, например, ЦБ. PDF

Настройка центральной базы РИБ выполняется по этапам:

Настройка выполняется в автоматическом режиме Мастером настройки синхронизации , от пользователя требуется следовать указаниям Мастера и нажимать кнопку Далее .

Результат выполненной настройки в центральной базе.

Настройка периферийной базы

После настройки центральной базы необходимо настроить периферийную базу. Для этого добавьте созданную периферийную базу в список задач 1С. PDF При открытии периферийной базы будет автоматически открыто окно настройки синхронизации.

Настройка периферийной базы РИБ выполняется по этапам:

• настройка параметров подключения; PDF
• настройка правил отправки и получения данных.

Настройка выполняется Мастером настройки автоматически. Для настройки Сценария синхронизации нажмите кнопку Добавить и все правила будут созданы по умолчанию. PDF

Следуя шагам Мастера, завершите настройку.

Результат настройки периферийной базы.

После завершения настройки в периферийной базе проверьте наличие перенесенных данных из центральной базы:

• настройки программы;
• справочники;
• документы;

Все данные должны присутствовать. Пример перенесенных поступлений. PDF

Обмен в РИБ

Для обмена периферийной базы с центральной нажмите кнопку Синхронизировать : раздел Администрирование — Настройки программы — Синхронизация данных — ссылка Настройки синхронизации данных .

Будет выполнен обмен с центральной базой.

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

Аналогичные правила для центральной базы.

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

Причины возникновения ошибки

Если в момент обновления конфигурации база «падает» из-за отключения электропитания или медленно работает канал обмена, конфигурация главного узла успевает измениться. а периферийного — нет.

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

• новое обновление центральной конфигурации до получения ответа о предыдущем обновлении периферийной конфигурации;
• динамическое обновление центральной конфигурации;
• отключение электропитания компьютера в момент обновления;
• и т.д.

Обновление конфигурации центральной базы

В том случае, если периферийная база изменения получила, но еще не применила, а в центральной базе в этот промежуток вносятся изменения еще раз и снова инициируют обмен, то возникает конфликт.

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

Динамическое обновление

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

Это предотвращает в большинстве случаев появление ошибки рассогласования конфигураций центральной и периферийных баз.

Но если по каким-то причинам ошибка все-таки имеет место — проблему нужно решать.

Перед исправлением ошибки обязательно сделайте копии центральной и периферийных баз данных. Иначе вернуться к исходному варианту после неудачной попытки исправления вы не сможете.

Отключение Главного узла периферийной базы

Данная методика неоднократно помогала нам решить проблему у клиентов при получении ошибки РИБ:

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

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

При попытке обновить конфигурацию вручную команда Обновить конфигурацию недоступна.

Что делать? Рекомендуемая последовательность действий:

• выгрузка конфигурации центральной базы (ЦБ) в файл;
• открепление Главного узла в периферийной базе (ПБ);
• обновление конфигурации в периферийной базе (ПБ);
• закрепление Главного узла в периферийной базе (ПБ).

Выгрузка конфигурации ЦБ в файл

Откройте Конфигуратор ЦБ и выгрузите конфигурацию в файл по кнопке Конфигурация — Сохранить конфигурацию в файл .

Этим файлом мы обновим конфигурацию ПБ после открепления в ней Главного узла обмена.

Открепление Главного узла в ПБ

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

Код этой обработки невероятно прост, всего несколько строчек, и вы можете:

• самостоятельно сделать такую обработку по указанному коду; PDF
• скачать готовый вариант от БухЭксперт8.

Запустите обработку через Главное меню — Файл — Открыть .

Запуск выполняется пользователем с Полными правами или возможностью работать с внешними отчетами и обработками.

Будет открыта форма, указывающая на Главный узел ЦБ, в нашем случае БУХЭКСПЕРТ. Для отключения его нажмите на кнопку Отключить Главный узел .

При отключении Главного узла Конфигуратор ПБ должен быть закрыт.

Обновление конфигурации в ПБ

Откройте конфигуратор ПБ и убедитесь, что блокировка на обновление снята и команда обновить конфигурацию доступна: меню Конфигурация — Поддержка — Обновить конфигурацию . Тем не менее обновить конфигурацию ПБ выгруженным файлом конфигурации ЦБ на актуальных конфигурациях 1С не получится, для этого снимем с поддержки конфигурацию ПБ, а потом вернем ее при загрузке файла конфигурации ЦБ: меню Конфигурация — Поддержка — Настройки поддержки — кнопка Снять с поддержки .

Загрузите файл конфигурации ЦБ: меню Конфигурация — Загрузить конфигурацию из файла .

Примите обновление конфигурации по кнопке F7.

Главный результат операции в сопоставлении редакций ЦБ и ПФ. Они должны быть одинаковыми. Проверить после обновления редакцию ПБ можно по меню Справка — О программе .

Подключение Главного узла в ПБ

Откройте ПБ в пользовательском режиме. На актуальных релизах 1С программа автоматически видит отключенный Главный узел и предлагает его восстановить. Нажимаете кнопку Восстановить .

Программа выполнит автоматическое обновление базы данных.

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

В открывшейся форме в поле Главный узел базы укажите тип данных Полный.

Выберите из списка узлов главный, в нашем случае БУХЭКСПЕРТ, и нажмите кнопку Подключить Главный узел .

При подключении Главного узла Конфигуратор ПБ должен быть закрыт.

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

Корректировка файлов обмена РИБ

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

• выгрузка файла обмена из периферийной базы;
• выгрузка файла обмена из центральной базы;
• корректировка файла обмена из ЦБ;
• загрузка скорректированного файла;
• перезапись файла обмена из ПБ;
• проверка исправлений.

Выгрузка файла обмена из периферийной базы

Оставьте рабочим только выполняемое действие настройки Отправка данных , используя кнопку Настроить — Сценарии синхронизации — кнопка Включить/Отключить .

Выполните обмен с центральной базой по кнопке Выполнить сценарий .

Выгрузка файла обмена из центральной базы

Оставьте рабочим только выполняемое действие настройки Отправка данных , используя кнопку Настроить — Сценарии синхронизации — кнопка Включить/Отключить .

Выполните отправку данных из центральной базы по кнопке Выполнить сценарий .

Корректировка файла обмена из ЦБ

В файле обмена из ЦБ замените блок, содержащий информацию об изменениях конфигурации на блок из файла ПБ.

Файлы обмена находятся в папке, которую указали при настройке обмена синхронизации распределенных баз. Всего там находятся два файла:

• Файл выгрузки из периферийной базы: Message_ФЛ_ЦБ.
• Файл выгрузки из центральной базы: Message_ЦБ_ФЛ.

Откройте файл обмена Message_ЦБ_ФЛ, редактором позволяющим редактировать xml-файлы, например, Блокнот.

В файле Message_ЦБ_ФЛ блок <v8de:Config …. </v8de:Config нужно заменить на аналогичный блок файла Message_ФЛ_ЦБ.

Блок файла Message_ЦБ_ФЛ.

Блок файла Message_ФЛ_ЦБ.

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

После замены информации сохраните изменения в файле Message_ЦБ_ФЛ.

Загрузка скорректированного файла

Конфигуратор при получении данных должен быть закрыт.

После этого делаем Отправку данных и переходим в центральную базу.

Проверка обмена в центральной базой

Выполняем Получение данных в центральной базе. Если все хорошо, в отчете отразится информация о том, что данные приняты и отправлены.

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

Да, все отлично. Обмен восстановлен, ошибка исправлена.

Работа с ошибками РИБ относится к разряду профессиональных и Бухэксперт8 рекомендует передавать их для исправления специалистам 1С. При работе с ошибками обязательно копируйте базы данных.

Помогла статья?

Получите еще секретный бонус и полный доступ к справочной системе БухЭксперт8 на 14 дней бесплатно

Похожие публикации

Карточка публикации

(2 оценок, среднее: 5,00 из 5)

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

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

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

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

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

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

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. для проверки делаем несколько последовательных обменов.

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

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

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

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

Механизм распределенных информационных баз 1С в свое время был очень популярен в компаниях, где были филиалы, но не было связи через Интернет. Сейчас Интернет есть почти везде, и большинство удаленных отделов через него подключаются и работают с основной базой. Тем не менее, механизм РИБ до сих пор используется, пользователи работают, и иногда возникают ошибки. Одна из самых распространенных среди них – «Конфигурация не соответствует ожидаемой».

Причины возникновения ошибки

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

Кроме вышеперечисленных вариантов на практике также замечены проблемы после динамических обновлений баз. Однако прямых доказательств и объяснений этому явлению на сегодняшний момент нет. Ошибка «Конфигурация распределенного узла не соответствует ожидаемой» в подавляющем большинстве случаев исправляется достаточно легко. Вам не нужно иметь специальных знаний – достаточно базовых знаний администрирования систем 1С.

Если вы первый раз столкнулись с подобной ошибкой, последовательно выполните следующие шаги и, скорее всего, проблема уйдет:

• Почистите кэш и проверьте работоспособность обмена еще раз. Если ошибка не ушла – приступайте к следующим шагам;
• Завершите все сеансы работы с подчиненной базой и сделайте ее копию;
• Выгрузите конфигурацию в файл с расширением .cf с основной ИБ;
• Далее необходимо отключить основной узел – для этого воспользуйтесь многочисленными обработками из Интернета. Они распространяются под именем, подобном «ОтключитьУзелРИБ.epf»;

После вышеописанных действий попробуйте снова запустить обмен между двумя базами. Вероятность успеха очень высока, а проблема может возникать только в критичных ситуациях. Что же можно предпринять в случаях форс-мажора? Весьма действенным оказался вариант с подменой хэша файлов обмена. Для этого необходимо:

1. Совершить вышеописанный алгоритм;
2. Выгрузить файл обмена из основной базы и дочерней, но не загружать их;

После всех операций проделайте несколько обменов для тестирования. Если не возникнет проблем, значит, все сделано правильно, и ошибка несоответствия узлов РИБ исправлена.

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

Судя по данному тексту вы получили лицензию на СЕРВЕР.

Не найдена лицензия. Не обнаружен ключ защиты программы или полученная программная лицензия!

Данный текст говорит о том, что 1С не видит лицензию на запуск КЛИЕНТА.

Файл программной лицензии не предусматривает возможность запуска клиентских приложений 1С:Предприятия или внешних соединений:
file://C:/ProgramData/1C/licenses/ХХХХХХХХ.lic

100% что это файл той самой лицензии на сервер 1С, который вы только что получили.
Уточнить можно открыв файл лицензии текстовым редактором, например, блокнотом — в конце файла будет информация о лицензии в человекочитаемом виде.

Т.е для работы вам теперь ещё надо получить клиентскую лицензию.
Для полного понимания советую почитать инструкцию по повторному получению лицензии 1С с разборами ошибок и примерами (кстати, ваш случай там тоже есть)
Как восстановить программную лицензию 1С:Предприятие 8

P. S.
Кстати имя файла затерли совершенно зря — оно представляет собой дату и время получения лицензии, никакой уникальной идентифицирующей информации в имени файла нет, например, активированная сегодня лицензия будет вида 202110131012345.lic, где первые 8 цифр — это дата 2021.10.13, а следующие 6 цифр — это время ЧЧ.ММ.СС.

Добавлю еще один момент — активировать многопользовательскую программную лицензию на сервере имеет смысл только в трех случаях:

1. Если будут клиент-серверные базы под SQL, в этом случае лицензии клиентам будет выдавать сервер 1С:Предприятия;
2. Если базы опубликованы на веб-сервере (Apache или IIS), в этом случае лицензии будет раздавать модуль веб-сервера;
3. Если сервер терминальный, в этом случае клиенты при подключении по RDP/RemoteApp смогут получить лицензии из файла сами.

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

Читайте также:

• Не хватает видеопамяти мта провинция
• Как убрать курсор на планшете
• Logitech wireless mouse m310 silver black usb обзор
• Как открыть файл w на телефоне
• Способы и режимы обработки информации на компьютере

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

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

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

1. во время приёма файла сообщения в УБ «упала» база, в связи с чем, видимо, и произошла разсинхронизация между конф. ЦБ и УБ;
2. под 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. для проверки делаем несколько последовательных обменов.

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

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

            <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>

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

В остальном могу только пожелать удачи!

i.egorov	#1 Оставлено : 15 сентября 2020 г. 16:10:01(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 15.09.2020(UTC) Сообщений: 5	Добрый день. При проверке файла подписи из 1С возникает ошибка «Хеш-значение неправильное». Но когда проверяешь файл подписи из онлайн сервисов (Госуслуги, Контур.Крипто) то все ОК. Подпись валидна. Установлена программа КриптоПро CSP 5.0.11823. В 1С проверка проходит путем создания менеджера криптографии. Пример: МенеджерКриптографии = Новый МенеджерКриптографии(,,80); МенеджерКриптографии.ПроверитьПодпись(ДвоичныеДанныеФайл, ДвоичныеДанныеПодпись); Подпись получена от клиента через оператора «Контур». На сайте оператора в ЛК отображается что с подписью все в порядке. Единственное что удалось выяснить что раньше клиент присылал отсоединенную подпись, а сейчас прислал присоединенную. И начались проблемы с проверкой валидности подписи. Подскажите в чем может быть проблема? Почему не удается проверить валидность подписи?

Андрей *	#2 Оставлено : 15 сентября 2020 г. 16:14:55(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,123 Сказал «Спасибо»: 460 раз Поблагодарили: 1946 раз в 1505 постах	Здравствуйте. Цитата: МенеджерКриптографии.ПроверитьПодпись(ДвоичныеДанныеФайл, ДвоичныеДанныеПодпись); В документации у 1С — что написано? что только отсоединенную подпись поддерживает? Попробуйте передать в ДвоичныеДанныеФайл — тоже присоединенную подпись…
Техническую поддержку оказываем тут Наша база знаний
	WWW

i.egorov	#3 Оставлено : 15 сентября 2020 г. 16:44:54(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 15.09.2020(UTC) Сообщений: 5	Цитата: В документации у 1С — что написано? что только отсоединенную подпись поддерживает? МенеджерКриптографии (CryptoManager) ПроверитьПодпись (VerifySignature) Синтаксис: ПроверитьПодпись(<ИсходныеДанные>, <Подпись>, <Сертификат>) Параметры: <ИсходныеДанные> (обязательный) Тип: Строка, ДвоичныеДанные. Исходные данные для проверки. Данные могут размещаться в файле (в этом случае указывается имя файла) или представлены как ДвоичныеДанные. <Подпись> (обязательный) Тип: Строка: ДвоичныеДанные: Поток, ПотокВПамяти, ФайловыйПоток. Подпись для проверки. Исходные данные могут размещаться в файле (в этом случае указываются именем исходного файла) или представлены как ДвоичныеДанные или Поток. <Сертификат> (необязательный) Тип: СертификатКриптографии. В параметре возвращается сертификат, с помощью которого была произведена подпись (если сертификат включен в данные подписи). Описание: Проверяет действительность подписи. Формат исходных данных — CMS (базируется на PKCS#7). Метод не осуществляет импорт сертификатов в хранилище сертификатов из данных подписи. Цитата: Попробуйте передать в ДвоичныеДанныеФайл — тоже присоединенную подпись… Тот же результат, подпись не валидна

i.egorov	#4 Оставлено : 16 сентября 2020 г. 10:21:37(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 15.09.2020(UTC) Сообщений: 5	Есть еще предложения?

Андрей *	#5 Оставлено : 16 сентября 2020 г. 11:34:23(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,123 Сказал «Спасибо»: 460 раз Поблагодарили: 1946 раз в 1505 постах	Автор: i.egorov Есть еще предложения? 1. Узнать, возможно ли это через МенеджерКриптографии (посмотреть документацию\форум) 2. Вместо МенеджерКриптографии использовать CAdESCOM.
Техническую поддержку оказываем тут Наша база знаний
	WWW

Андрей *	#6 Оставлено : 16 сентября 2020 г. 11:36:31(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,123 Сказал «Спасибо»: 460 раз Поблагодарили: 1946 раз в 1505 постах	Проверьте ещё, что передаёте двоичные данные, а не в base64…
Техническую поддержку оказываем тут Наша база знаний
	WWW

Андрей *	#7 Оставлено : 16 сентября 2020 г. 11:37:56(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 26.07.2011(UTC) Сообщений: 12,123 Сказал «Спасибо»: 460 раз Поблагодарили: 1946 раз в 1505 постах	посмотрел.. описание… Отредактировано пользователем 16 сентября 2020 г. 11:38:31(UTC)  | Причина: Не указана
Техническую поддержку оказываем тут Наша база знаний
	WWW

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.