Как настроить точный обмен банковскими выписками «один в один» в 1С:Бухгалтерия без искажения реквизитов?

При настройке регулярного обмена данными между двумя базами «1С:Бухгалтерия предприятием 3.0» (БП 3.0) разработчики часто сталкиваются с неприятной особенностью работы универсального формата (EnterpriseData / КД3). При переносе документов «Списание с расчетного счета» и «Поступление на расчетный счет» база-приемник начинает вести себя избыточно «самостоятельно»: произвольно меняются виды операций, счета расчетов с контрагентами и статьи движения денежных средств (ДДС). Документ, который в базе-источнике был заполнен идеально, в базе-приемнике превращается в хаос.

В этой статье мы подробно разберем, почему стандартный механизм EnterpriseData искажает отправленные данные, и проанализируем четыре практических способа реализации обмена «один в один», включая программирование в расширениях, переход на КД2 и правильную настройку распределенных информационных баз (РИБ).

Выясним причину: почему EnterpriseData искажает данные при загрузке?

Для начала разберем по шагам физику процесса загрузки пакета через КД3. Концепция универсального формата обмена (EnterpriseData) подразумевает, что принимающая сторона не просто записывает XML/JSON-пакет напрямую в СУБД, а проводит его через сито бизнес-логики своих общих модулей. Это сделано для обеспечения целостности и непротиворечивости учета в базе-приемнике. Однако при попытке сделать жесткий односторонний перенос «один в один» эта логика начинает мешать.

Проанализируем основные точки перезаписи реквизитов:

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

Стандартная установка свойства ОбменДанными.Загрузка = Истина предотвращает выполнение проверок в обработчиках ПередЗаписью непосредственно на уровне объектов конфигурации, но логика трансформации данных КД3 отрабатывает еще на этапе разбора XDTO в памяти, поэтому стандартный механизм отключения проверок здесь бессилен.

---

Способ 1. Использование расширения конфигурации (Рекомендуемый путь для КД3)

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

Разберем алгоритм реализации этого способа:

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

Рассмотрим пример кода, который можно внедрить в расширение для предотвращения автоматического пересчета счетов расчетов и статей ДДС:

&Вместо("ЗаполнитьРеквизитыТабличнойЧастиДенежныеСредства")
Процедура Расш_ЗаполнитьРеквизитыТабличнойЧастиДенежныеСредства(СтрокаТабличнойЧасти, ДанныеXDTO, НаправлениеОбмена)
    // Вызываем стандартную обработку заполнения реквизитов
    ПродолжитьВызов(СтрокаТабличнойЧасти, ДанныеXDTO, НаправлениеОбмена);
    
    // Принудительно возвращаем значения реквизитов из XDTO, 
    // если логика приемника перезаписала их дефолтными настройками
    Если НаправлениеОбмена = "Получение" Тогда
        Если ДанныеXDTO.Свойство("СчетУчетаРасчетов") И ЗначениеЗаполнено(ДанныеXDTO.СчетУчетаРасчетов) Тогда
            СтрокаТабличнойЧасти.СчетУчетаРасчетов = НайтиСчетПоКоду(ДанныеXDTO.СчетУчетаРасчетов);
        КонецЕсли;
        
        Если ДанныеXDTO.Свойство("СтатьяДвиженияДенежных Средств") Тогда
            // Блокируем автоподстановку ДДС по умолчанию
            СтрокаТабличнойЧасти.СтатьяДвиженияДенежныхСредств = ПолучитьСсылкуНаСтатьюДДС(ДанныеXDTO.СтатьяДвиженияДенежныхСредств);
        КонецЕсли;
    КонецЕсли;
КонецПроцедуры

Этот подход гарантирует сохранение архитектуры обмена через EnterpriseData, но дает нам полный контроль над процессом трансформации реквизитов «на лету».

---

Способ 2. Переход на Конвертацию данных 2.0 (КД2)

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

Разберем по шагам, как настроить такой обмен:

1. Выгружаем структуры метаданных базы-источника и базы-приемника с помощью обработки MD83Exp.epf.
2. Загружаем полученные структуры в конфигурацию «Конвертация данных 2.1».
3. Создаем новые правила обмена (ПКО) для документов СписаниеСРасчетногоСчета и ПоступлениеНаРасчетныйСчет. Так как метаданные баз идентичны или крайне близки, сопоставление реквизитов (счетов расчетов, статей ДДС, контрагентов, договоров) настраивается напрямую: «Источник.СчетРасчетов -> Приемник.СчетРасчетов».
4. В правилах конвертации свойств (ПКС) для переносимых реквизитов отключаем любые обработчики автоматического заполнения на стороне приемника.
5. Создаем нетиповой план обмена в базах для регистрации изменений только по нужным документам и справочникам.
6. Настраиваем регламентное задание в базе-источнике для автоматической выгрузки и загрузки данных по расписанию через созданные правила КД2.

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

---

Способ 3. Использование РИБ с сопоставлением данных

Использование распределенной информационной базы (РИБ) обеспечивает самый надежный перенос данных «один в один» на уровне СУБД. Однако при попытке настроить РИБ между базами, которые изначально создавались как независимые, разработчики сталкиваются с двумя критическими проблемами.

Проблема 1. Ошибка несоответствия конфигураций

При попытке создания узла РИБ система выдает ошибку: «Конфигурация узла распределенной ИБ не соответствует ожидаемой!». Это происходит из-за малейших расхождений в структуре метаданных (даже если базы визуально идентичны, в одной из них может быть добавлен один нетиповой реквизит или изменена длина строкового поля).

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

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

Проблема 2. Дублирование справочников

Когда РИБ связывает две ранее независимо работавшие базы, при первом обмене неизбежно возникнет лавина дублей справочников (Контрагенты, Номенклатура, Договоры, Статьи ДДС), так как внутренние уникальные идентификаторы (GUID) этих объектов в базах различаются.

Разберем схему решения проблемы дублей, предложенную участниками форума:

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

---

Способ 4. Синхронизация аналитических настроек без программирования

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

Проанализируем шаги по синхронизации настроек:

1. Выравнивание регистра счетов учета расчетов: Скопируем содержимое регистра сведений СчетаУчетаРасчетовСКонтрагентами из базы-источника в базу-приемник. Это можно сделать с помощью обработки «Выгрузка и загрузка данных XML». Если правила подбора счетов учета для каждого контрагента и договора в базах будут абсолютно идентичными, то при загрузке документов алгоритмы КД3 выберут те же счета, что были в источнике.
2. Идентичность справочника Статьи ДДС: Нам нужно добиться полной синхронизации элементов справочника СтатьиДвиженияДенежныхСредств. Настроим одинаковые связи статей ДДС с хозяйственными операциями в настройках параметров учета обеих информационных баз.
3. Контроль ручных корректировок: Обучим пользователей базы-источника минимизировать ручные корректировки счетов расчетов непосредственно в документах выписок, перенося эти настройки в регистры счетов учета по умолчанию.

Этот способ требует организационных усилий и педантичного ведения нормативно-справочной информации (НСИ), однако он позволяет оставаться в рамках полностью типового функционала обновления программных продуктов 1С.