При настройке синхронизации между конфигурациями 1С:Управление торговлей 10.3 и 1С:Бухгалтерия предприятия 3.0 специалисты часто сталкиваются с неприятным эффектом: количество объектов, зарегистрированных к обмену, начинает лавинообразно расти. Это приводит к тому, что сеансы обмена длятся часами, данные дублируются, а система работает крайне нестабильно. В этой статье мы разберем основные причины возникновения этой ситуации, проанализируем влияние копий баз данных и выясним, как правильно использовать инструменты регистрации изменений.
Разберем ситуацию, которая оказалась решающей в рассматриваемом случае. Часто для тестирования или разработки создается копия рабочей базы УТ 10.3. Если в этой копии не были своевременно отключены регламентные задания или не были изменены настройки узлов обмена, возникает серьезный технический конфликт.
Проанализируем механизм: обмен данными строится на уникальности кодов узлов плана обмена. Если копия базы имеет тот же Код узла, что и основная рабочая база, и обе они обращаются к одному и тому же ресурсу (каталогу, FTP или прямому подключению), система начинает «путаться» в номерах принятых и отправленных сообщений. Когда одна база отправляет пакет данных, она ожидает подтверждения получения. Если в это время «проснулась» копия и считала файл обмена, номера сообщений сбиваются. В результате основная база считает, что партнер не получил данные, и регистрирует их к отправке повторно, что визуально выглядит как резкое увеличение очереди объектов.
Для решения этой проблемы необходимо соблюдать строгие правила при работе с копиями:
/AllowExecuteScheduledJobs -Force с осторожностью только в тех средах, где это безопасно.Рассмотрим еще одну распространенную причину — бесконечную пересылку изменений туда и обратно. Это происходит, когда запись объекта при загрузке в приемнике воспринимается системой как «изменение», которое нужно отправить обратно в источник.
Выясним, как это работает на уровне кода. В 1С существует свойство ОбменДанными.Загрузка. Если в правилах конвертации или в подписках на события не стоит проверка этого свойства, то при записи документа, пришедшего из УТ 10.3, база БП 3.0 поставит его «в очередь» на отправку обратно. Чтобы избежать этого, в обработчиках событий (например, ПередЗаписью или ПриЗаписи) всегда следует анализировать состояние загрузки:
Если ОбменДанными.Загрузка Тогда
Возврат;
КонецЕсли;
Если такая проверка отсутствует, любой пересчет итогов или заполнение пустых реквизитов в БП 3.0 вызовет повторную регистрацию, и объект вернется в УТ 10.3, где ситуация повторится. Это и создает бесконечный цикл роста данных.
Проанализируем структуру плана обмена. Часто в УТ 10.3 включена регистрация не только по самим документам, но и по связанным с ними регистрам накопления или сведений. Если в настройках узла обмена случайно установлена галочка на регистрацию движений, то изменение одного документа может привести к регистрации тысяч записей в таблицах _ChangeRec.
Посмотрим на это с практической стороны: если вы регистрируете изменения вручную через обработку, обратите внимание, не выбраны ли у вас лишние метаданные. Для стандартного обмена с БП 3.0 обычно достаточно регистрации самих документов и справочников, так как бухгалтерия сама перепроводит документы и формирует движения по своим правилам.
В ходе обсуждения возник вопрос: какую обработку использовать для управления регистрацией в УТ 10.3? Рассмотрим два варианта:
УТ 10.3 приведет к ошибкам или пустому окну.УТ 10.3 уже есть мощный инструмент. Найти его можно в меню «Сервис» — «Обмен данными» — «Регистрация изменений для обмена».Преимущество встроенной обработки в том, что она корректно работает с метаданными текущей конфигурации и позволяет точечно удалять или добавлять объекты в очередь обмена. Разберем ситуацию из сообщения: если после ручной регистрации объектов обработкой вы замечаете удвоение, это может означать, что обработка удерживает транзакцию или кэширует состояние, которое конфликтует с фоновым заданием обмена, запускающимся каждые 3 минуты.
Рекомендация: При выполнении массовой ручной регистрации изменений рекомендуется временно отключать расписание регламентного обмена, чтобы избежать блокировок таблиц регистрации (_ChangeRec) и конфликтов записи.
Выясним, почему могут появляться дубли в самой базе-приемнике. Если в правилах конвертации данных поиск настроен по полям (например, ИНН + Наименование), а не по внутреннему идентификатору (UUID), то любое минимальное различие в данных (лишний пробел, точка) приведет к созданию нового объекта. Этот новый объект получит свой GUID, будет зарегистрирован к обмену и отправится в исходную базу как «новый», порождая дублирование данных.
Для предотвращения этого:
UUID должен быть первичным).ОбменДанными.Загрузка.Соблюдение этих правил позволит держать объем передаваемых данных под контролем и избегать утомительной ручной доработки процесса синхронизации в конце рабочего дня.