Почему при синхронизации 1С пропал прогресс-бар и не видны ошибки во второй базе?

← На главную

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

Переход на асинхронный режим работы

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

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

Проблема «невидимых» ошибок при использовании COM-соединения

Выясним причину ситуации, когда в базе-инициаторе обмен завершается «успешно», а во второй базе фактически происходит сбой. Рассмотрим механизм работы через COM-соединение в новых реалиях:

Первая база (отправитель) формирует пакет данных.
Через транспортный протокол (например, COM) пакет передается во вторую базу.
Для первой базы работа на этом этапе считается завершенной — транспорт отработал, данные «ушли». Программа фиксирует успешный статус.
Вторая база (приемник) получает пакет и ставит его в очередь на загрузку в фоновом режиме.
Если при непосредственной записи объектов во второй базе возникают ошибки (например, не заполнено обязательное поле или сработала проверка в модуле), первая база об этом уже не узнает, так как сессия связи была закрыта сразу после передачи файла.

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

Выбор оптимального транспорта: COM, Web-сервис или HTTP?

Разберем, какой вид транспорта лучше использовать в современных условиях. Традиционное COM-соединение постепенно признается устаревшим и «капризным» методом. Проанализируем основные недостатки COM:

Зависимость от операционной системы Windows (не работает на серверах Linux).
Проблемы с регистрацией библиотек comcntr.dll при обновлении платформы.
Конфликты разрядности (32-битные vs 64-битные системы).

Рассмотрим альтернативы. Использование штатных Web-сервисов (например, Interface.Interface) или HTTP-сервисов является более современным и надежным решением. В отличие от COM, они работают через стандартные протоколы обмена данными и не требуют прямой регистрации низкоуровневых библиотек в системе. Кроме того, при использовании Web-сервисов база-инициатор может более эффективно запрашивать статус выполнения фонового задания у базы-приемника.

Как настроить автоматический мониторинг

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

Перейдем в раздел Администрирование — Синхронизация данных.
Настроим расписание для синхронизации, чтобы она проходила в автоматическом режиме без участия «девочек-бухгалтеров».
В разделе Администрирование — Обслуживание включим рассылку отчетов об ошибках. Это позволит администратору оперативно получать уведомления о сбоях, не заходя в каждую базу вручную.

Исправление ошибок формата EnterpriseData

Иногда ошибки возникают из-за несовпадения версий метаданных, особенно при использовании формата EnterpriseData. Рассмотрим ситуацию, когда в новой версии конфигурации реквизит был переименован (например, добавлен префикс «Удалить»). Если одна база уже обновилась, а вторая нет, обмен может «упасть».

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


// Пример логики для замены устаревших имен реквизитов в XML
Чтение = Новый ЧтениеXML;
Чтение.ОткрытьФайл(ПутьКФайлу);
Запись = Новый ЗаписьXML;
Запись.ОткрытьФайл(ПутьКФайлу + "_temp");

Пока Чтение.Прочитать() Цикл
    Если Чтение.ТипУзла = ТипУзлаXML.НачалоЭлемента И Чтение.Имя = "БанковскиеСчета" Тогда
        Запись.ЗаписатьНачалоЭлемента("УдалитьБанковскиеСчета");
    Иначе
        Запись.ЗаписатьТекущий(Чтение);
    КонецЕсли;
КонецЦикла;

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