При настройке обмена между современными конфигурациями 1С, такими как 1С:Комплексная автоматизация 2 (КА), 1С:Управление торговлей 11 (УТ) и 1С:Бухгалтерия предприятия 3.0 (БП), специалисты часто сталкиваются с парадоксальной ситуацией. Синхронизация завершается успешно, в журнале регистрации отсутствуют ошибки, объекты зарегистрированы к обмену, но в базе-приемнике ничего не появляется. При анализе сформированного XML-файла выясняется, что он содержит только технический заголовок (хедер), а блоки с данными отсутствуют.
В этой статье мы подробно разберем, почему возникает эта проблема, проанализируем технические причины сбоя и рассмотрим несколько способов восстановления корректной работы обмена.
Рассмотрим типичную ситуацию. В базе 1С:Комплексная автоматизация произведена свертка данных на начало года, настроена стандартная синхронизация через универсальный формат. Пользователь видит, что документы зарегистрированы в плане обмена, запускает выгрузку, которая проходит подозрительно быстро. В структуре XML-файла мы видим следующее:
<msg:Header>
<msg:Format>http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.10</msg:Format>
<msg:CreationDate>2021-08-04T06:01:44</msg:CreationDate>
<msg:Confirmation>
<msg:ExchangePlan>СинхронизацияДанныхЧерезУниверсальныйФормат</msg:ExchangePlan>
...
</msg:Confirmation>
<msg:AvailableVersion>1.10</msg:AvailableVersion>
...
</msg:Header>
Обратим внимание на строку msg:Format. Здесь указана версия формата 1.10. Именно в этом кроется причина сбоя. Проанализируем механизм: при инициации обмена две базы "договариваются" о максимально возможной версии формата EnterpriseData, которую поддерживают обе стороны. Если в обеих конфигурациях программно заявлена поддержка версии 1.10, система выбирает именно её.
Однако в определенных релизах 2021 года возникла критическая ошибка (зарегистрированная как EF_00_00385576). В программном коде модулей обмена была прописана поддержка версии 1.10, но соответствующий XDTO-пакет в дерево метаданных конфигурации добавлен не был. В результате движок обмена пытается выгрузить данные по схеме, которой физически не существует в базе. Система не находит правил для формирования структуры объектов и просто пропускает их, формируя пустой файл с корректным заголовком.
Самый быстрый способ исправить ситуацию без изменения программного кода — принудительно понизить используемую версию формата до стабильной 1.8. Разберем по шагам, как это сделать, так как нужное поле обычно скрыто от пользователя.
Версия формата (или аналогичного скрытого реквизита, отвечающего за версию EnterpriseData).Важно: Аналогичную операцию желательно провести и в базе-приемнике (Бухгалтерии), чтобы при следующем "рукопожатии" систем (автоматическом согласовании параметров) версия снова не перескочила на ошибочную 1.10.
Если ручная правка не помогает или сбрасывается при каждом обновлении настроек, проанализируем программный метод решения. Мы можем принудительно исключить версию 1.10 из списка доступных через механизм расширений. Для этого нам понадобится общий модуль, отвечающий за поддержку версий универсального формата (например, ОбменДаннымиУТ или МенеджерОбменаЧерезУниверсальныйФормат).
Рассмотрим пример кода, который можно разместить в расширении (метод После или Вместо для процедуры определения доступных версий):
// В общем модуле, где формируется список версий формата
Процедура ДоступныеВерсииУниверсальногоФормата(Версии) Экспорт
// Находим строку с ошибочной версией и удаляем её или комментируем
// Версии.Добавить("1.10"); <-- Эта строка вызывает проблему
Версии.Добавить("1.8");
Версии.Добавить("1.7");
КонецПроцедуры
После применения такого расширения система перестанет предлагать версию 1.10 в качестве приоритетной, и обмен начнет использовать стабильный пакет XDTO 1.8, который присутствует в метаданных.
Часто после исправления ошибки с пустым файлом пользователи замечают, что документы Ввод остатков, созданные после свертки базы в КА, все равно не попадают в Бухгалтерию. Выясним причину этой ситуации.
Стандартная синхронизация через EnterpriseData предназначена для трансляции текущих хозяйственных операций. Документы ввода остатков имеют принципиально разную структуру в разных конфигурациях:
В типовом формате EnterpriseData маппинг (соответствие) для документов ввода начальных остатков зачастую просто не предусмотрен разработчиками. Для первоначального переноса данных из свернутой КА в БП рекомендуется использовать не синхронизацию, а специальную обработку "Помощник перехода" или правила конвертации данных (КД 2.0), предназначенные именно для разового переноса остатков.
Проанализируем еще несколько моментов, которые помогут стабилизировать обмен:
Администрирование — Обслуживание — Обновление программы проверьте наличие патча с кодом EF_00_00385576. Его установка автоматически исправит программный код без необходимости ручных правок.Регистрация изменений для обмена. Если объекты там есть, а файл пуст — значит, проблема в версии формата или правилах выгрузки.Тип не определен или Ошибка проверки данных XDTO, что явно указывает на несоответствие схемы XML и структуры базы.Подводя итог, можно сказать, что проблема "пустой выгрузки" при работающей синхронизации в 90% случаев вызвана рассинхронизацией версий формата EnterpriseData и состава метаданных. Принудительный откат на версию 1.8 является самым надежным и быстрым способом возобновить обмен данными между КА и Бухгалтерией.