← На главную

При обновлении современных конфигураций 1С, таких как Бухгалтерия предприятия 3.0 или Управление торговлей 11, пользователи часто сталкиваются с ситуацией, когда отлаженная годами синхронизация данных внезапно перестает работать. Типичный сценарий: вчера система успешно принимала файл с именем message_УТ_БП.xml, а сегодня после обновления БП требует файл вида Message_b779c183-858d-472f-9d73-77f786369866_БП.xml. В данной статье мы разберем причины такого поведения системы и рассмотрим пошаговые алгоритмы восстановления обмена.

Выясним причину: конвертация узлов и переход на новые стандарты БСП

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

Во время обновления «1С:Бухгалтерии» происходит процедура конвертации узлов плана обмена. Система создает новый идентификатор для текущей базы или переводит старый план обмена на новый формат работы. В результате программа «забывает» старое имя файла message_УТ_БП.xml и начинает ожидать файл, содержащий её внутренний идентификатор. Именно это и произошло в рассматриваемом случае: БП обновилась, её внутренние настройки синхронизации изменились, и старый файл из УТ перестал распознаваться как корректное сообщение обмена.

Способ 1. Переименование файла и синхронизация кодов (Быстрый метод)

Рассмотрим самый очевидный вариант, который часто выбирают для быстрой «реанимации» обмена. Если БП просит файл с конкретным именем, содержащим GUID, мы можем попробовать дать ей этот файл, переименовав выгрузку из УТ.

1. Выгрузим файл из Управление торговлей в привычном формате.
2. Переименуем полученный файл точно так, как того требует Бухгалтерия предприятия (например, скопировав имя из текста ошибки).
3. Попробуем выполнить загрузку в БП.

Важное предостережение: Как показывает практика, этот метод может привести к проблемам, описанным в сообщении 7 темы форума. Если структура плана обмена претерпела значительные изменения, загрузка может «зависнуть» или вызвать дублирование данных. Если объем данных велик (десятки тысяч объектов), программа может не справиться с сопоставлением по старым правилам в новом контексте.

Способ 2. Корректировка кодов в плане обмена

Посмотрим на более технологичный вариант — приведение кодов узлов к единому знаменателю. Часто после обновления код узла в БП меняется на длинную строку. Нам нужно проверить справочник Сценарии синхронизации данных и непосредственно узлы в плане обмена.

Проанализируем шаги:

1. Зайдем в меню «Администрирование» — «Синхронизация данных» — «Настройки синхронизации».
2. Откроем настройки текущего обмена и найдем поле «Код узла».
3. Если код узла выглядит как b779c183..., попробуем вручную изменить его на короткий код, который прописан в УТ (например, БП).
4. Внимание! В базовых версиях или при определенных блокировках БСП редактирование кода может быть запрещено. В этом случае потребуется использование обработки «Групповое изменение реквизитов» или написание небольшого кода на встроенном языке для принудительной смены кода узла.

Способ 3. Сброс номеров сообщений и очистка регистрации

Даже если мы «подсунем» файл с правильным именем, обмен может не пройти из-за несовпадения номеров сообщений. Каждая база хранит номер последнего принятого и отправленного сообщения. Если в БП после обновления счетчик обнулился, а УТ присылает сообщение №150, система может выдать ошибку.

Для решения этой задачи выполним следующие действия:

1. В обеих базах (УТ и БП) зайдем в параметры синхронизации.
2. Найдем раздел «Номера сообщений».
3. Установим «Номер принятого» и «Номер отправленного» в 0. Это заставит систему начать отсчет с чистого листа.
4. Перед выполнением первой синхронизации после сброса крайне важно проверить регистрацию изменений.

Разберем ситуацию с регистрацией подробнее. Чтобы база не «повисла» при загрузке 100 000 объектов, воспользуемся обработкой Регистрация изменений для обмена. Рассмотрим, как это сделать:

1. Откроем форму синхронизации и нажмем кнопку с иконкой «состава отправляемых данных».
2. Проверим, нет ли там лишних объектов. Если после обновления зарегистрировалась вся база, нажмем «Отменить регистрацию всех объектов».
3. Зарегистрируем вручную только те документы и справочники, которые реально изменились за последние несколько дней. Это позволит избежать переполнения памяти и долгого ожидания.

Способ 4. Пересоздание синхронизации (Рекомендуемый метод)

Как справедливо замечено в сообщении 8, зачастую самый легкий и действенный вариант — это полное удаление старой настройки и создание новой с нуля. Это избавляет от «хвостов» старых версий БСП и гарантирует, что все механизмы сопоставления будут работать по актуальным алгоритмам.

Разберем алгоритм действий:

1. Сделаем резервные копии обеих баз (обязательно!).
2. В Бухгалтерии предприятия и Управлении торговлей удалим текущую настройку синхронизации.
3. В Управлении торговлей запустим мастер создания новой синхронизации.
4. При настройке в БП укажем, что это «продолжение» настройки, и обязательно пройдем этап сопоставления данных.
5. Важный момент: На этапе сопоставления убедитесь, что ключевые справочники (Номенклатура, Контрагенты) сопоставились правильно (по ИНН/КПП или коду), чтобы избежать появления дублей.

Проанализировав проблему «чудес синхронизации», мы видим, что за странными именами файлов стоит закономерный процесс обновления программного ядра 1С. Использование GUID вместо коротких имен — это современный стандарт. Если переименование файла не помогает или вызывает зависания, не тратьте время на «лечение» старого узла — пересоздайте синхронизацию. Это сэкономит время и обеспечит стабильную работу обмена в будущем.