Как найти банковские выписки в пакетах XDTO EnterpriseData и настроить их выборочную выгрузку

При переходе на технологию Конвертации данных 3 (КД3) и универсальный формат обмена EnterpriseData разработчики часто сталкиваются с неочевидной структурой пакетов XDTO. Типичный пример — попытка найти привычные документы бухгалтерского учета, такие как "Поступление на расчетный счет" или "Списание с расчетного счета", по их прямым названиям или маскам вроде "Выписка" или "Банк". Поиск не дает результатов, что вызывает ступор.

В этой статье мы подробно разберем, по какой логике именуются банковские документы в пакетах XDTO EnterpriseData, где искать их описания в конфигурации "1С:Бухгалтерия предприятия 3.0" (БП 3), и как правильно настроить выборочную онлайн-выгрузку этих документов без создания "велосипедов" и лишних планов обмена.

Почему банковские выписки не находятся по маске "Банк" или "Списание"

Главная причина, по которой в пакетах EnterpriseData не удается найти привычные метаданные, заключается в том, что универсальный формат обмена ориентирован на операционный (управленческий) учет, принятый в ERP-решениях (1С:ERP, 1С:Комплексная автоматизация, 1С:Управление торговлей), а не на регламентированный бухгалтерский учет. В этих конфигурациях понятия "банковская выписка" как самостоятельного документа не существует, а движение денежных средств фиксируется первичными платежными документами.

В формате EnterpriseData банковские документы отражаются в концепции движения безналичных денежных средств:

• Поступление на расчетный счет (в БП 3) транслируется в объект формата: ПоступлениеБезналичныхДенежныхСредств (в схемах и коде часто сокращается как ПБДС).
• Списание с расчетного счета (в БП 3) транслируется в объект формата: СписаниеБезналичныхДенежныхСредств (в схемах и коде обозначается как СБДС).

Внутри XDTO-пакета (в зависимости от используемой версии формата, например, EnterpriseData 1.15) эти типы данных дополнительно детализируются по хозяйственным операциям. Если мы откроем пакет XDTO в конфигураторе, нам нужно искать типы объектов, начинающиеся со следующих конструкций:

• Документ.ПБДСРасчетыСКонтрагентами — поступление безналичных ДС при расчетах с покупателями и поставщиками;
• Документ.ПБДСПрочееПоступление — прочие поступления на расчетный счет;
• Документ.СБДСРасчетыСКонтрагентами — списание безналичных ДС по расчетам с контрагентами;
• Документ.СБДСПлатежиВБюджет — списание безналичных ДС на уплату налогов и пошлин.

Где посмотреть соответствия объектов в конфигурации

Чтобы точно сопоставить объекты информационной базы (ОИБ) и объекты формата (ОФ), не обязательно вручную перебирать весь XDTO-пакет. Вся логика сопоставления жестко прописана в коде конфигурации.

Проанализируем общий модуль МенеджерОбменаЧерезУниверсальныйФормат (или аналогичный менеджер конкретной версии формата, если логика вынесена в отдельные модули). Именно здесь сосредоточена вся карта сопоставления.

В процедуре ЗаполнитьПравилаКонвертацииОбъектов (ПКО) мы можем увидеть, как документ информационной базы связывается с типом XDTO. Например, для поступления на расчетный счет это выглядит так:

Правило = ПравилаКонвертации.Добавить();
Правило.Имя = "ПоступлениеНаРасчетныйСчет_ПоступлениеБезналичныхДенежныхСредств";
Правило.ОбъектИсточника = "ДокументСсылка.ПоступлениеНаРасчетныйСчет";
Правило.ОбъектПриемника = "Документ.ПоступлениеБезналичныхДенежныхСредств";

Аналогично в процедуре ЗаполнитьПравилаОбработкиДанных (ПОД) настраиваются правила выборки данных из базы для последующей отправки. Если нам нужно понять, как именно заполняются реквизиты формата из реквизитов документа "1С:Бухгалтерии", нам достаточно изучить процедуры экспорта в этом модуле, которые начинаются с ПКО_Документ_ПоступлениеНаРасчетныйСчет_ПоступлениеБезналичныхДенежныхСредств_ПриОтправке.

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

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

Рассмотрим эту идею. Использовать план обмена Полный для интеграции через универсальный формат КД3 категорически не рекомендуется по следующим причинам:

1. План обмена Полный ориентирован на механизмы распределенных информационных баз (РИБ) с полной идентичностью конфигураций. Он не содержит в своей структуре и подписках механизмов БСП, необходимых для работы с универсальным форматом.
2. На данном плане обмена будет крайне сложно и трудоемко настроить выборочную фильтрацию объектов "на лету" средствами КД3. Придется полностью переписывать правила регистрации и логику работы транспорта обмена.

Вместо создания "велосипедов" воспользуемся штатным механизмом БСП. Для обменов через EnterpriseData предназначен специализированный предопределенный план обмена. В зависимости от версии БСП он может называться:

• СинхронизацияДанныхЧерезУниверсальныйФормат
• ОбменДаннымиЧерезУниверсальныйФормат
• ДругаяПрограмма

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

Реализация выборочного обмена: два практических подхода

Выясним, как ограничить выгрузку только двумя документами (списание и поступление по расчетному счету) с отбором по конкретной организации.

Способ 1. Настройка в пользовательском режиме (без изменения кода и правил)

В современных релизах БСП при настройке синхронизации данных через универсальный формат ("Другая программа") доступен мощный интерактивный функционал настройки правил отправки. Разберем этот процесс по шагам:

1. Переходим в раздел Администрирование — Синхронизация данных — Настройки синхронизации.
2. Создаем новую синхронизацию через универсальный формат.
3. На этапе настройки правил отправки данных находим опцию "С отбором по разделам учета и видам документов".
4. Нажимаем гиперссылку настройки фильтра по типам документов. В открывшемся дереве метаданных снимаем флажки со всех документов, кроме:
   • Поступление на расчетный счет
   • Списание с расчетного счета
5. В поле "Организации" выбираем режим "Указанные организации" и добавляем в список нашу организацию, по которой должен идти отбор.

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

Способ 2. Использование собственных правил регистрации объектов (ПРО)

Если стандартных интерактивных отборов БСП вам недостаточно (например, требуется сложная фильтрация выписок по видам операций или статьям движения денежных средств), мы можем использовать механизм КД3 для создания индивидуальных правил регистрации.

Для этого выполним следующие действия:

1. Запускаем конфигурацию Конвертация данных, редакция 3.
2. Загружаем структуру метаданных нашей конфигурации "Бухгалтерия предприятия 3.0".
3. Переходим в раздел работы с правилами регистрации объектов (ПРО).
4. Для плана обмена СинхронизацияДанныхЧерезУниверсальныйФормат настраиваем правила регистрации только для двух объектов: Документ.ПоступлениеНаРасчетныйСчет и Документ.СписаниеСРасчетногоСчета.
5. Для остальных классов документов в свойствах регистрации указываем режим Не регистрировать или просто удаляем их из состава правил регистрации.
6. В обработчиках правил регистрации (например, ПередЗаписью или ПриРегистрации) прописываем код проверки организации. Пример условия:
   Скопировать код

   
   Если Объект.Организация <> ПараметрыРегистрации.ОрганизацияОтбора Тогда
       Отказ = Истина;
   КонецЕсли;
   

7. Выгружаем полученные правила в XML-файл.
8. В рабочей базе заходим в настройки синхронизации данных, открываем параметры загрузки правил и загружаем наш XML-файл в качестве индивидуальных Правил регистрации объектов. Это также можно сделать напрямую через регистр сведений Правила для обмена данными.

Как решать проблему разных релизов баз "Бухгалтерии"

Автор темы выразил опасение, что базы-приемники и база-источник могут находиться на разных релизах. При использовании КД2 это действительно было бы серьезной проблемой, требующей постоянного обновления правил обмена под каждый релиз. Но в КД3 эта проблема решена на архитектурном уровне.

Посмотрим, как работает механизм совместимости версий формата:

• Каждая база БП 3 при инициализации сеанса обмена выполняет так называемое "рукопожатие" (handshake). Базы обмениваются списками поддерживаемых версий формата EnterpriseData (например, источник поддерживает версии 1.5, 1.6, 1.7, 1.8, а приемник — только 1.5 и 1.6).
• БСП автоматически выбирает максимальную общую поддерживаемую версию (в нашем примере это будет версия 1.6).
• Источник формирует XML-пакет строго в формате версии 1.6, используя соответствующую ветку логики в общем модуле менеджера обмена.
• Приемник гарантированно успешно читает этот пакет, так как структура формата версии 1.6 ему полностью известна.

Таким образом, разность релизов баз не помешает вашей интеграции взлететь и стабильно работать без постоянного вмешательства программиста.