Почему документы в 1С:УНФ регистрируются к обмену, но не выгружаются в 1С:Бухгалтерию: решаем проблему КД 3.0

Программист 1С v8.3 (Управляемые формы) 1С:Управление нашей фирмой Управленческий учет IT и автоматизация бизнеса
← На главную

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

Разберем механизм «рукопожатия» в КД 3.0 (Enterprise Data)

Для начала проанализируем ключевое отличие технологии Enterprise Data от старой версии Конвертации данных 2.0. В КД 2.0 правила выгрузки были самодостаточны: если вы прописали правило для документа, он выгрузится в файл независимо от того, что «думает» об этом база-приемник.

В КД 3.0 все иначе. Здесь работает механизм поддерживаемых объектов. Процесс обмена выглядит следующим образом:

  1. При первой синхронизации (или обновлении настроек) базы обмениваются информацией о своих возможностях.
  2. База-приемник сообщает источнику список типов данных и версий формата Enterprise Data, которые она способна корректно обработать.
  3. База-источник при формировании выгрузки сверяется с этим списком. Если объект (например, Документ.ЗаказПокупателя) не заявлен приемником как поддерживаемый, источник просто игнорирует его.

Это сделано для защиты: система предотвращает отправку данных, которые заведомо вызовут критическую ошибку при загрузке. В нашем случае проблема заключалась именно в том, что на стороне БП отсутствовали правила для получения этого документа, поэтому УНФ «молча» отсекала его при выгрузке.

Выясним причины отсутствия данных в файле

Если вы видите документ в окне «Состав отправляемых данных», но не находите его в XML-файле, проанализируем следующие факторы (в этом случае также может помочь простая сверка документов между конфигурациями):

  1. Отсутствие ПКО на стороне приемника: В модуле менеджера обмена (обычно это обработка МенеджерОбменаЧерезУниверсальныйФормат) в базе-приемнике должно быть описано правило получения (ПКО) для конкретного объекта и конкретной версии формата.
  2. Разница в релизах: Если ваша УНФ имеет старый релиз (например, 1.6.17), а БП — актуальный (3.0.128+), они могут использовать разные версии формата Enterprise Data (например, 1.5 против 1.15). Если базы не смогли договориться о «своей» версии формата, часть объектов может быть исключена.
  3. Фильтрация в ПОД (Правила обработки данных): На стороне источника в процедуре ПриОтправкеДанных модуля менеджера может стоять жесткое условие. Рассмотрим пример кода, который может блокировать выгрузку:

Процедура ПОД_ДокументЗаказПокупателя_Отправка_ПриОбработке(ДанныеИБ, ИспользованиеПКО, КомпонентыОбмена)
    
    // Если заказ не проведен или помечен на удаление - не выгружаем
    Если Не ДанныеИБ.Проведен Или ДанныеИБ.ПометкаУдаления Тогда
        ИспользованиеПКО = Ложь;
        Возврат;
    КонецЕсли;

    // Проверка организации
    Если ДанныеИБ.Организация.Наименование = "Непроизводственная" Тогда
        ИспользованиеПКО = Ложь;
    КонецЕсли;

КонецПроцедуры

Пошаговая инструкция по диагностике и решению

Рассмотрим шаги, которые помогут вам найти «узкое место» в обмене:

Шаг 1. Проверка состава поддерживаемых объектов

Проанализируем коллекцию поддерживаемых типов в момент инициализации узла обмена. Для этого необходимо зайти в отладчик и проверить таблицу СтандартныеПодсистемы.ОбменДанными. Если типа Документ.ЗаказПокупателя там нет, значит, база-приемник о нем «не знает».

Также воспользуйтесь стандартным инструментом: в форме настройки синхронизации нажмите «Состав отправляемых данных», выберите интересующий вас документ и найдите кнопку «Проверить наличие правил». Если система выдаст сообщение «Правила не найдены», значит, проблема в модуле менеджера обмена.

Шаг 2. Обновление правил обмена

Поскольку часто одна из конфигураций может быть снята с поддержки (как УНФ 1.6.17 в рассматриваемом примере), правила в ней не обновляются автоматически. Рассмотрим решение:

Шаг 3. Отладка модуля менеджера обмена

Если остановка в отладчике срабатывает в событии ПОД_..._Отправка_ПриОбработке, но выполнение не доходит до ПКО (Правила конвертации объекта), это верный признак того, что объект отсекается либо фильтром, либо проверкой XDTO-схемы.

Посмотрим на пример отладки. Нам нужно убедиться, что объект соответствует версии XDTO-пакета, используемого в обмене. Проверьте процедуру ДобавитьПКО_... в модуле менеджера. Там должно быть четко указано соответствие объекта ИБ и объекта формата:


Процедура ДобавитьПКО_Документ_ЗаказПокупателя_Отправка(ПравилаКонвертации)
    
    Правило = ПравилаКонвертации.Добавить();
    Правило.Имя = "Документ_ЗаказПокупателя_Отправка";
    Правило.ОбъектДанных = Метаданные.Документы.ЗаказПокупателя;
    Правило.ОбъектФормата = "Документ.ЗаказПокупателя"; // Важно: должно совпадать с XDTO
    
КонецПроцедуры

Особенности обмена банковскими выписками (БП -> УНФ)

Иногда возникает обратная проблема: данные из БП 3.0 не приходят в УНФ (или УНФ 3.0). Проанализируем ситуацию с банковскими выписками. Зачастую в типовых правилах Enterprise Data выгрузка банковских документов из Бухгалтерии в управленческие базы отключена по умолчанию.

Это логично с точки зрения методологии 1С: первичные данные (выписки) должны вводиться в оперативной базе (УНФ), а затем транслироваться в БП. Если вам нужно обратное движение, например, выгрузка данных из Бухгалтерии 3.0 в УНФ 3.0, необходимо:

  1. Зайти в настройки синхронизации в БП.
  2. Нажать «Изменить параметры синхронизации».
  3. На вкладке «Правила отправки данных» проверить, установлена ли галочка «Выгружать отчеты о движении денежных средств» или аналогичные настройки для банковских документов.

Резюме

Если объект зарегистрирован, но не выгружается в КД 3.0, мы должны первым делом проверить, «согласна» ли принимающая сторона его принять. В большинстве случаев решение заключается в синхронизации модулей менеджера обмена между базами, чтобы обе стороны использовали одинаковые описания объектов и версий формата Enterprise Data. Если одна из баз сильно устарела, потребуется ручной перенос кода из актуальных типовых конфигураций в расширение или доработанный модуль менеджера.

← На главную