При работе в связке конфигураций «1С:Зарплата и управление персоналом 3» (ЗУП) и «1С:Бухгалтерия предприятия 3.0» (БП) пользователи часто сталкиваются с крайне специфическим поведением системы. После очередного обновления конфигураций (особенно часто проблема проявлялась начиная с релиза БП 3.0.72.60) процесс синхронизации завершается сообщением: «Не удалось синхронизировать данные».
При этом детальный анализ баз показывает странную картину: все документы, справочники и проводки физически перенеслись в базу-приемник без каких-либо искажений. Статус отправки данных в базе-инициаторе обновляется на актуальное время, однако статус получения зависает в прежнем положении или сигнализирует об ошибке. В Журнале регистрации обеих информационных баз при этом нет абсолютно никаких сообщений об ошибках, транзакциях или сбоях. Процесс выглядит со стороны системы как аварийно прерванный, хотя содержательная часть обмена выполнена на 100%.
В этой статье мы подробно разберем техническую природу этой проблемы, выясним, почему «молчит» Журнал регистрации, и рассмотрим несколько эффективных способов решения — от установки временных исправлений до перенастройки архитектуры самого обмена.
Описанное поведение системы — это классический баг совместной работы технологической платформы «1С:Предприятие» и встроенной в конфигурации Библиотеки стандартных подсистем (БСП). Ошибка проявляется исключительно при использовании схемы прямого подключения (COM-соединения) между информационными базами.
Давайте по шагам разберем, как устроен процесс синхронизации по COM-каналу в этот момент:
comcntr.dll выполняет авторизацию и подключается к базе-корреспонденту (БП).ЗафиксироватьПолучениеДанных.Именно на третьем этапе происходит сбой. Из-за внутренней ошибки в программном коде БСП обновленного релиза Бухгалтерии возвращаемое значение функции закрытия сессии обрабатывается некорректно. При передаче структуры данных через COM-границу между двумя процессами 1С возникает ошибка сериализации (несоответствие типов данных или невозможность корректно упаковать результирующий объект).
Платформа «1С:Предприятие» расценивает эту системную ошибку сериализации как критический сбой канала связи и аварийно завершает COM-сессию. База-инициатор видит внезапное падение соединения, прекращает выполнение сценария и выводит пользователю сообщение: «Не удалось синхронизировать данные».
Поскольку транзакция записи и проведения документов к этому моменту уже была полностью завершена и зафиксирована в базе-приемнике, физически данные остаются на месте. А так как сессия COM оборвалась мгновенно на уровне самой платформы, БСП просто физически не успевает перехватить эту ошибку в общий блок Попытка...Исключение и записать стек вызовов в Журнал регистрации. Именно поэтому Журнал регистрации остается абсолютно «чистым».
Ниже приведен схематичный пример того, как выглядит проблемный участок кода БСП, приводящий к сбою на стороне принимающей базы при попытке вернуть статус обмена:
// Упрощенная демонстрация проблемной логики в модуле ОбменДаннымиСервер
Функция ЗафиксироватьРезультатыОбменаНаСторонеПриемника(ПараметрыОбмена) Экспорт
НачатьТранзакцию();
Попытка
// Данные успешно записываются в базу
ЗаписатьПолученныеДанные(ПараметрыОбмена);
ЗафиксироватьТранзакцию();
Исключение
ОтменитьТранзакцию();
ЗаписатьВЖурналРегистрации("Синхронизация", УровеньЖурналаРегистрации.Ошибка, , , ПодробноеПредставлениеОшибки(ИнформацияОбОшибке()));
ВызватьИсключение;
КонецПопытки;
// КРИТИЧЕСКАЯ ТОЧКА:
// Попытка возврата структуры через COM-соединение.
// Если структура содержит несериализуемые системные типы данных,
// платформа аварийно разорвет COM-соединение прямо в момент возврата.
Возврат ПолучитьСтатусИПодтвержденияНомеровСообщений(ПараметрыОбмена);
КонецФункции
---
Рассмотрим несколько вариантов решения проблемы — от простых обходных путей до фундаментального изменения настроек синхронизации.
Прямое COM-соединение исторически является одним из самых проблемных мест в администрировании 1С. Оно крайне чувствительно к разрядности платформы (32/64-бит), требует регулярной перерегистрации библиотеки comcntr.dll в операционной системе при каждом обновлении платформы и часто страдает от утечек памяти.
Самый надежный способ навсегда избавиться от подобных багов — перевести синхронизацию на бесконтактный режим обмена. Настроим обмен через сетевой каталог (локальную или общую сетевую папку) или через FTP-сервер:
При таком подходе базы взаимодействуют изолированно друг от друга через файлы выгрузки. Отсутствие прямого вызова процедур по COM-соединению гарантирует, что никакие ошибки сериализации и падения сессий платформы не повлияют на итоговый статус синхронизации.
В некоторых версиях БСП ошибка сериализации параметров обмена возникает асимметрично. Это значит, что если инициатором обмена выступает ЗУП, то в конце сессии БП возвращает некорректную структуру и происходит вылет. Однако, если запустить тот же самый обмен в обратную сторону (инициатором выступает Бухгалтерия), цепочка вызовов процедур меняется.
Проверим этот обходной путь:
Администрирование -> Синхронизация данных -> Настройки синхронизации.Во многих случаях при смене инициатора обмена сессия закрывается корректно, и обе базы успешно получают статус «Синхронизация завершена успешно».
Фирма «1С» оперативно реагирует на критические ошибки БСП, которые затрагивают базовые механизмы обмена данными. Для исправления этой коллизии выпускаются оперативные исправления — патчи (имеют префикс вида EF_...).
Если ваши конфигурации находятся на официальной поддержке и имеют доступ к интернету, выполним следующие шаги для автоматической загрузки исправления:
Администрирование.Обслуживание, далее раскроем подраздел Обновление программы.Установка обновлений и исправлений (патчей).После автоматической установки патча и перезапуска сеансов пользователей 1С, проблема с обменом должна исчезнуть.
Если официальный патч по каким-то причинам недоступен или конфигурации не обновляются до актуальных релизов оперативно, можно воспользоваться механизмом расширений конфигурации. Специальное корректирующее расширение перехватывает сбойную функцию БСП в момент закрытия сессии COM и принудительно очищает возвращаемую структуру от несериализуемых системных типов данных платформы.
Для подключения расширения выполним стандартную процедуру:
Администрирование -> Печатные формы, отчеты и обработки -> Расширения.Добавить из файла... и выберем файл расширения (предварительно полученный от обслуживающего партнера или из доверенного источника технической поддержки 1С).Безопасный режим для данного расширения, так как расширению обмена требуются права на выполнение серверных операций и доступ к файловой системе/внешним соединениям.Иногда нестабильное завершение COM-сессий связано с тем, что на сервере или локальном компьютере зарегистрирована устаревшая версия компоненты comcntr.dll, либо в системе одновременно установлено несколько разных версий платформы «1С:Предприятие», конфликтующих между собой.
Для устранения этой причины выполним ручную перерегистрацию библиотеки в операционной системе Windows:
regsvr32 /u "C:\Program Files\1cv8\8.3.XX.XXXX\bin\comcntr.dll"
(где вместо 8.3.XX.XXXX укажем номер старого релиза платформы).
regsvr32 "C:\Program Files\1cv8\8.3.18.1300\bin\comcntr.dll"
После успешной регистрации библиотеки в реестре операционной системы перезапустим службу Агент сервера 1С:Предприятия (если базы серверные) или перезагрузим локальный рабочий компьютер (при работе в файловом варианте).
Проанализировав все рассмотренные методы, мы можем сделать вывод: наиболее надежной и долгосрочной стратегией является переход на файловый обмен через каталоги. Это полностью исключает влияние системных обновлений Windows, разрядности операционных систем и специфических ошибок сериализации объектов БСП на стабильность работы пользователей.