Работа с распределенными информационными базами (РИБ) в 1С требует понимания механизмов регистрации изменений и квитирования (подтверждения) доставки сообщений. Одной из наиболее частых и трудоемких проблем является ситуация, когда при каждом сеансе обмена система пытается выгрузить весь массив данных, что приводит к многочасовым задержкам и перегрузке каналов связи. Разберем детально, почему это происходит и как вернуть обмен в штатный режим.
Для начала проанализируем, как 1С понимает, какие данные нужно отправлять, а какие — нет. В основе лежит объект метаданных ПланОбмена. Когда в базе изменяется какой-либо объект (документ, справочник), система делает запись в специальной таблице регистрации изменений для конкретного узла.
Процесс обмена строится по строгому циклу:
НомерОтправленного = 10).Выясним причину проблемы: Если этот цикл разрывается на любом этапе, Центр "считает", что ПБ не получила данные, и при следующей выгрузке снова включает все старые изменения плюс новые в следующий пакет. Так возникает эффект "снежного кома".
Рассмотрим ситуацию, описанную автором: база только что развернута из начального образа. В этот момент критически важно совершить полный цикл "туда-обратно".
Часто после создания образа в периферийной базе счетчики сообщений сбрасываются или устанавливаются некорректно относительно Центральной базы. Если в Центре для этого узла уже числится НомерОтправленного равный 1, а база выгружает огромный объем накопленных данных, то пока Периферия не загрузит этот пакет и — что самое важное — не отправит ответ, Центр не "успокоится".
Если на стороне Периферии возникают ошибки (например, недостаточно прав на FTP или конфликты данных), ответный файл либо не создается, либо не содержит подтверждения. В результате при каждом новом обмене Центральная база генерирует файл со всеми объектами заново.
Разберем подробнее, как конфликты блокируют очистку регистрации. В РИБ конфликт возникает, если объект был изменен одновременно в обеих базах. По умолчанию приоритет имеет Центральная база.
Если при загрузке данных в Периферию система встречает конфликтный объект, она может пометить его как "требующий решения". В некоторых конфигурациях, если загрузка данных прошла с предупреждениями или ошибками в транзакции, номер принятого сообщения в заголовке узла может не обновиться. Посмотрим на логику системы: если номер НомерПринятого в узле обмена не увеличился, значит, при следующем обмене Центр снова отправит те же самые данные.
Рекомендация: Проанализируем журнал регистрации на стороне Периферии. Ищем записи с событием "Обмен данными" и статусом "Ошибка". Особое внимание стоит уделить ошибкам записи объектов (например, нарушение уникальности кодов или пустые обязательные реквизиты). Пока эти ошибки не будут устранены, объект не будет считаться принятым.
Иногда система "зацикливается" настолько, что автоматические механизмы не справляются. В этом случае мы можем прибегнуть к ручной корректировке номеров сообщений. Это заставит Центральную базу поверить, что данные уже доставлены.
Проанализируем шаги по ручной корректировке:
НомерОтправленного и НомерПринятого.НомерПринятого в Центральной базе равным НомеруОтправленного из последнего успешно ушедшего пакета.Пример кода для программного сброса номеров сообщений (использовать с осторожностью):
// Получим узел обмена
УзелОбмена = ПланыОбмена.РаспределеннаяИнформационнаяБаза.НайтиПоКоду("П01");
ОбъектУзла = УзелОбмена.ПолучитьОбъект();
// Устанавливаем номера так, чтобы база считала обмен завершенным
ОбъектУзла.НомерОтправленного = 100; // Номер последнего файла
ОбъектУзла.НомерПринятого = 100; // Подтверждаем получение
ОбъектУзла.Записать();
Чтобы окончательно убедиться, что проблема в регистрации, воспользуемся стандартной обработкой "Регистрация изменений для обмена" (она входит в состав БСП и доступна в большинстве современных конфигураций).
Рассмотрим алгоритм действий:
Бывают случаи, когда обмен проходит успешно, регистрация очищается, но тут же заполняется снова. Это происходит из-за неудачно написанных подписок на события или обработчиков ПередЗаписью / ПриЗаписи.
Проанализируем ситуацию: 1. Объект загружается из Центра в Периферию. 2. Срабатывает код в Периферии, который при записи объекта что-то в нем меняет (например, заполняет ответственного или обновляет дату актуальности). 3. Изменение объекта в Периферии тут же регистрирует его к выгрузке обратно в Центр. 4. Центр получает объект, записывает его, у него срабатывает своя логика, и объект снова регистрируется к выгрузке в Периферию.
Чтобы избежать этого, в коде всегда нужно проверять свойство ОбменДанными.Загрузка. Если оно равно Истина, дополнительные модификации объекта производиться не должны.
Процедура ПередЗаписью(Отказ)
Если ОбменДанными.Загрузка Тогда
Возврат; // Не регистрируем изменения и не меняем реквизиты при загрузке из другой базы
КонецЕсли;
// Ваша логика изменения реквизитов
КонецПроцедуры
Если вы столкнулись с тем, что 1С выгружает все данные при каждом обмене, выполните следующие действия:
ОбменДанными.Загрузка.Соблюдение этих правил позволит сократить время синхронизации с нескольких часов до нескольких минут, обеспечив стабильную работу розничных точек и удаленных офисов.