При работе в международных компаниях часто возникает задача консолидации банковских данных из разных стран. Типичная ситуация: в российском офисе используется технология 1С:ДиректБанк для прямой работы с банком, а в зарубежном офисе (например, в Украине на конфигурациях BAS) требуется получить те же данные в автоматическом режиме. Попытка просто «перенести» обработку ДиректБанка из одной конфигурации в другую наталкивается на серьезные технические и архитектурные препятствия. В этой статье мы разберем, почему прямой перенос невозможен и какими альтернативными способами можно решить задачу автоматизации.
Проанализируем техническую суть технологии. 1С:ДиректБанк — это не просто внешняя обработка, а глубоко интегрированный в БСП (Библиотеку стандартных подсистем) и БЭД (Библиотеку электронных документов) протокол обмена. Рассмотрим основные причины сложности переноса:
ПлатежноеПоручениеВходящее или ПоступлениеНаРасчетныйСчет в украинской базе потребует переписывания сотен строк кода.Выяснив эти причины, мы понимаем, что наиболее рациональный путь — это использование российской базы 1С в качестве «шлюза» или посредника.
Это самый современный и надежный метод. Разберем его по шагам. Поскольку в московской базе выписки уже загружаются штатно, нам нужно организовать передачу этих данных в Киев. Мы можем создать в украинской базе HTTP-сервис, который будет принимать данные, а в московской базе настроить регламентное задание, которое будет «пушить» (отправлять) эти данные.
Проанализируем пример кода для отправки данных из московской базы:
Процедура ОтправитьВыпискуВКиев(СтруктураДанных)
Запрос = Новый HTTPЗапрос("/v1/statements/import");
Запрос.Заголовки.Вставить("Content-Type", "application/json");
ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
ЗаписатьJSON(ЗаписьJSON, СтруктураДанных);
СтрокаJSON = ЗаписьJSON.Закрыть();
Запрос.УстановитьТелоИзСтроки(СтрокаJSON, КодировкаТекста.UTF8);
Соединение = Новый HTTPСоединение("kiev-office.domain.com", 443, "User", "Pass", , , Новый ЗащищенноеСоединениеOpenSSL());
Ответ = Соединение.ОтправитьДляОбработки(Запрос);
Если Ответ.КодСостояния <> 200 Тогда
ЗаписьЖурналаРегистрации("ОбменСКиевом", УровеньЖурналаРегистрации.Ошибка, , , "Ошибка отправки: " + Ответ.ПолучитьТелоКакСтроку());
КонецЕсли;
КонецПроцедуры
На стороне приемника (Украина) мы создаем HTTP-сервис, который парсит полученный JSON и создает документы БанковскаяВыписка или аналоги. Это позволяет полностью исключить человеческий фактор и ошибки ручного копирования через Excel.
Если разработка собственного API кажется слишком сложной, рассмотрим вариант использования стандартного механизма 1С — ПланыОбмена. Мы можем настроить обмен между двумя базами, даже если они имеют разную структуру (через правила конвертации данных).
Разберем алгоритм настройки:
ПланОбмена, в состав которого включаем документы по расчетам с банком.РегистрацияИзменений для фиксации загруженных через ДиректБанк платежей.EnterpriseData (универсальный формат обмена).Посмотрим на пример регистрации изменений в коде:
Процедура ПослеЗагрузкиИзДиректБанка(ДокументСсылка)
УзелОбмена = ПланыОбмена.ОбменСКиевом.НайтиПоКоду("KIEV");
Если НЕ УзелОбмена.Пустая() Тогда
ПланыОбмена.ЗарегистрироватьИзменения(УзелОбмена, ДокументСсылка);
КонецЕсли;
КонецПроцедуры
Этот метод хорош тем, что 1С сама отслеживает, какие данные уже были отправлены, а какие нет. В случае сбоя связи при следующей итерации обмена система просто доотправит недостающие пакеты.
Ситуация усложняется, если прямой доступ между серверами в Москве и Киеве ограничен. В этом случае мы можем использовать промежуточный слой. Рассмотрим схему: Московская 1С загружает выписки -> Выгружает их в облачное хранилище или БД (например, PostgreSQL) -> Украинская 1С забирает данные оттуда.
Это позволяет избежать прямой зависимости баз друг от друга. Вы можете использовать объект HTTPСоединение для взаимодействия с внешним облачным API, который будет хранить очередь выписок на загрузку.
При реализации любого из этих решений важно учитывать следующие моменты:
Контрагентов и Договоров. В московской и киевской базах они будут иметь разные GUID. Рекомендуем выполнять поиск по ИНН/КПП (или их аналогам в Украине — ЕДРПОУ) или завести в справочниках дополнительный реквизит «ID для обмена».Подводя итог, можно сказать: не пытайтесь заставить украинскую 1С работать с российским банком напрямую через ДиректБанк. Это технически нецелесообразно. Используйте готовую интеграцию в московской базе и настройте автоматизированный транспорт данных между системами. Это сэкономит время разработки и обеспечит стабильную работу бухгалтерии в обоих офисах.