Как настроить синхронизацию непроведенных документов через универсальный формат в 1С:Бухгалтерии?

При настройке обмена данными между конфигурациями на платформе 1С:Предприятие через план обмена СинхронизацияДанныхЧерезУниверсальныйФормат (EnterpriseData) разработчики и администраторы часто сталкиваются с типовым поведением: программа передает исключительно проведенные документы. Если же в базе-источнике отменить проведение ранее выгруженного документа, в базе-приемнике он автоматически помечается на удаление. Разберем, почему так происходит, где располагаются правила обмена в современных типовых конфигурациях и как переопределить эту логику.

Причины типового поведения формата EnterpriseData

Формат универсального обмена данными ориентирован на интеграцию различных учетных систем и передачу свершившихся фактов хозяйственной деятельности. В концепции конфигурации 1C:Бухгалтерия непроведенный документ рассматривается как черновик, не порождающий проводок и движений по регистрам, поэтому по умолчанию он не подлежит синхронизации.

В типовых механизмах заложены следующие особенности:

1. Логика регистрации: правила регистрации объектов (ПРО) отслеживают изменение состояния реквизитов документа и могут блокировать регистрацию изменений для непроведенных объектов.
2. Логика конвертации (ПОД отправки): в процедурах выгрузки выполняется проверка статуса проведения. Если документ не проведен, выгрузка отменяется либо вызывается метод ОбменДаннымиXDTOСервер.ВыгрузитьУдаление, что приводит к установке пометки удаления в базе-приемнике.
3. Особенности формата XDTO: структура универсального формата не всегда передает признак проведения в явном виде. Приемник при успешной загрузке по умолчанию пытается провести входящий документ.

Где находятся правила обмена универсального формата

В отличие от классического обмена на базе «Конвертации данных 2.0», где правила выгрузки хранятся в XML-макетах планов обмена, в формате EnterpriseData («Конвертация данных 3.0») правила конвертации встроены непосредственно в программный код конфигурации.

Основным местом описания правил конвертации объектов (ПКО) и правил обработки данных (ПОД) является общий модуль МенеджерОбменаЧерезУниверсальныйФормат (или МенеджерОбменаЧерезУниверсальныйФорматXX_XX_XX в зависимости от версии используемого формата).

Пошаговая настройка обмена для передачи непроведенных документов

Разберем по шагам, какие изменения необходимо внести в конфигурацию, чтобы передавать документы независимо от их статуса проведения.

Шаг 1. Корректировка правил регистрации объектов (ПРО)

Проверим правила регистрации в макете плана обмена СинхронизацияДанныхЧерезУниверсальныйФормат. Если в них задано условие на проверку реквизита Проведен, его необходимо отключить, чтобы непроведенные документы регистрировались к отправке на узле плана обмена.

Шаг 2. Доработка модуля на стороне базы-источника

Откроем общий модуль МенеджерОбменаЧерезУниверсальныйФормат и найдем процедуры обработки выгрузки для нужных документов (например, реализации товаров и услуг). В теле процедур исключим отказ от выгрузки для непроведенных объектов и запретим отправку команды удаления при распроведении:

// В обработчике ПОД выгрузки документа
Если Не ДанныеИБ.Проведен Тогда
    // Исключаем вызов метода ОбменДаннымиXDTOСервер.ВыгрузитьУдаление
    // и установку флага Отказ = Истина
КонецЕсли;

Если требуется передавать статус проведения в базу-приемник, сохраним его во вспомогательных свойствах объекта формата через коллекцию ДополнительныеРеквизиты (AdditionalInfo).

Шаг 3. Доработка модуля на стороне базы-приемника

В модуле менеджера обмена базы-приемника в обработчиках загрузки (ПОД получения) скорректируем режим записи объекта. Проанализируем переданное состояние документа и выполним запись без проведения:

// При записи загруженного документа определяем режим
Если ЗагружатьКакНепроведенный Тогда
    Объект.Записать(РежимЗаписиДокумента.Запись);
Иначе
    Объект.Записать(РежимЗаписиДокумента.Проведение);
КонецЕсли;

Почему изменения не применяются сразу

Если после внесения изменений в код или макеты правила продолжают работать по-старому, выясним причину такого поведения. Это связано с внутренними механизмами кэширования БСП:

1. Кэширование правил в информационной базе: правила регистрации и конвертации при старте или настройке обмена загружаются в служебные регистры сведений (например, ПравилаДляОбменаДанными, ПравилаРегистрацииОбъектов). Простого сохранения конфигурации недостаточно — правила необходимо перезагрузить в режиме «1С:Предприятие» в форме настройки параметров синхронизации.
2. Очередь зарегистрированных изменений: если документ был изменен до исправления правил, на узле плана обмена могла зафиксироваться старая команда на удаление. Для корректной отправки необходимо повторно зарегистрировать нужные объекты с помощью обработки Регистрация изменений для обмена данными.

Пересоздавать саму настройку синхронизации или удалять узлы планов обмена при этом не требуется.

Альтернативные решения для обмена между идентичными базами

Если обмен настраивается между двумя одинаковыми базами одной и той же конфигурации (например, 1C:Бухгалтерия и 1C:Бухгалтерия), применение универсального формата EnterpriseData не всегда является оптимальным решением. Рассмотрим альтернативные подходы:

1. Обмен по правилам конвертации («Конвертация данных 2.0»): классический обмен через планы обмена с произвольными правилами передает реквизиты объектов (включая флаги Проведен и ПометкаУдаления) напрямую без ограничений бизнес-логики EnterpriseData.
2. Распределенная информационная база (РИБ): использование механизма РИБ (с фильтрацией по организациям или подразделениям) обеспечивает полную идентичность структуры документов и их статусов проведения без необходимости доработки программного кода.