При настройке обмена данными между конфигурациями 1С:Управление торговлей 11 и 1С:Бухгалтерия предприятия 3.0 специалисты часто сталкиваются с ситуацией, когда данные успешно передаются в базу-приемник, но в базе-источнике они продолжают числиться как "неотправленные". Это приводит к тому, что при каждом новом сеансе синхронизации система заново обрабатывает десятки тысяч документов, создавая колоссальную нагрузку на сервер. Проанализируем причины этого поведения и разберем по шагам, как привести регистрацию изменений в порядок.
Прежде всего, нам необходимо понять фундаментальный принцип работы Библиотеки стандартных подсистем (БСП), на которой построена современная синхронизация. Процесс обмена — это не просто передача данных в одну сторону, это диалог между двумя базами. Рассмотрим этот механизм подробнее:
В рассматриваемой ситуации База "А" (УТ) отправляет данные, но База "Б" (БП) либо не отправляет подтверждение, либо делает это некорректно. Чаще всего это происходит, когда пользователи пытаются настроить "односторонний" обмен, просто отключив выгрузку из БП. В итоге УТ "не знает", что данные дошли, и пытается отправить их снова и снова.
Выясним, как реализовать требование "данные только из УТ в БП", не нарушая логику квитирования. Вместо того чтобы полностью отключать синхронизацию со стороны БП, необходимо настроить фильтры. Рассмотрим, как это сделать штатными средствами:
В базе 1С:Бухгалтерия предприятия перейдем в раздел Администрирование — Синхронизация данных. Откроем настройки нашей синхронизации и найдем пункт "Правила отправки данных". Вместо того чтобы полностью останавливать обмен, установим значение "Не выгружать" для всех документов и справочников. При такой настройке БП перестанет отправлять свои документы, но продолжит формировать "технические пакеты", содержащие номер принятого сообщения из УТ. Это позволит УТ корректно очищать очередь регистрации после каждой успешной сессии.
Если в очереди уже скопилось огромное количество объектов (например, 33 тысячи, как в нашем случае), и мы не хотим ждать, пока они "пролопатятся" естественным путем, мы можем очистить регистрацию вручную. Для этого проанализируем возможности встроенной обработки:
Администрирование — Синхронизация данных.Регистрация изменений для обмена мы увидим дерево объектов, которые "ждут" отправки.Важно: После выполнения этой операции при следующем обмене будут переданы только те документы, которые были изменены после момента очистки.
В некоторых случаях, например, при автоматизации процесса через регламентные задания, может потребоваться программный способ удаления регистрации. Рассмотрим пример кода, который использует объект ПланыОбмена и метод УдалитьРегистрациюИзменений. Посмотрим на пример реализации:
// Определим узел, для которого нужно очистить регистрацию
УзелОбмена = ПланыОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат.НайтиПоКоду("БП");
Если Не УзелОбмена.Пустая() Тогда
// Удаляем регистрацию для всех типов объектов по данному узлу
ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена);
Сообщить("Регистрация изменений успешно очищена для узла: " + УзелОбмена);
КонецЕсли;
Такой код можно оформить в виде внешней обработки или добавить в процедуру, которая выполняется сразу после завершения выгрузки данных, если штатный механизм подтверждения по каким-то причинам недоступен (например, при специфических ошибках COM-соединения).
В процессе обсуждения был затронут вопрос изменения префикса базы и сбоя нумерации документов. Проанализируем, как вернуть прежний порядок нумерации. При смене префикса 1С начинает отсчет номеров заново или с префиксом новой базы, что может привести к дублированию или путанице. Разберем шаги по исправлению:
Функций для технического специалиста. Эта обработка принудительно пересчитывает последний использованный номер в базе для каждого типа документа.Групповое изменение реквизитов. Будьте осторожны: изменение номера документа может повлиять на ссылки в других системах.Префикс информационной базы в разделе Администрирование — Синхронизация данных. Убедитесь, что он соответствует ожиданиям и не конфликтует с префиксами в базе-приемнике.Рассмотрим нюанс, упомянутый автором: использование прямого подключения. При таком способе обмена База "А" (УТ) сама подключается к Базе "Б" (БП), выполняет в ней действия и завершает сеанс. Если в процессе записи подтверждения в УТ происходит программный сбой или разрыв соединения (например, из-за нехватки памяти или разницы в разрядности 32/64 бит), транзакция откатывается, и подтверждение не записывается.
Если проблема с "зависшей" регистрацией сохраняется даже при правильных настройках, мы рекомендуем сменить способ подключения с "Прямого подключения" на "Обмен через файловый ресурс" или "FTP". Это сделает процесс обмена прозрачнее: вы сможете физически видеть файлы сообщений и файлы ответов, что значительно упрощает диагностику ошибок квитирования.