Как организовать обмен данными между типовой конфигурацией 1С и самописной базой?

Организация обмена данными между типовой конфигурацией, например, Бухгалтерия предприятия 3.0, и нетиповой самописной системой — классическая задача, с которой сталкиваются разработчики. Рассмотрим основные подходы, которые позволят реализовать синхронизацию справочников и документов надежно и эффективно.

Подход 1: Использование «Конвертации данных 2.0»

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

1. Выгрузите структуру метаданных из обеих конфигураций.
2. Настройте правила конвертации объектов, указав соответствие справочников и документов.
3. Используйте Планы обмена для регистрации изменений, чтобы передавать только те данные, которые действительно были изменены.
4. Настройте Регламентные задания, чтобы обмен происходил автоматически, например, раз в неделю.

Подход 2: Прямое подключение через COM-соединение

Если конфигурации находятся на одном сервере, самым быстрым способом реализации будет написание внешней обработки в Бухгалтерии 3.0, которая будет подключаться к самописной базе.

Рассмотрим пример логики подключения:

// Пример подключения к другой базе через COM-соединение
COMОбъект = Новый COMОбъект("V83.COMConnector");
Подключение = COMОбъект.Connect("Srvr=""Сервер"";Ref=""БазаСамописка"";Usr=""Админ"";Pwd=""Пароль""");

// Получение данных из базы-источника
Выборка = Подключение.Справочники.Номенклатура.Выбрать();
Пока Выборка.Следующий() Цикл
    // Логика переноса данных в текущую базу
КонецЦикла;

Этот метод позволяет обойтись без сложной настройки правил, если объем передаваемых данных небольшой, а структура баз позволяет легко сопоставить объекты.

Подход 3: HTTP-сервисы и интеграция через JSON/XML

Современным и наиболее гибким методом является использование HTTP-сервисов. Вы публикуете базу на веб-сервере (например, Apache или IIS) и создаете сервис, который принимает запросы от второй базы.

Преимущества этого подхода:

• Отсутствие жесткой зависимости от версии платформы или структуры метаданных другой базы.
• Данные передаются в формате JSON, который легко обрабатывается любой из сторон.
• Безопасность: обмен происходит через стандартный протокол, нет необходимости давать прямой доступ к файлам базы.

Ключевая проблема: Синхронизация и дублирование данных

Самая большая трудность при любом обмене — это не способ передачи, а идентификация. Чтобы избежать дублей (например, когда номенклатура «Велосипед» в одной базе имеет один код, а в другой — другой), следуйте этим правилам:

• Используйте Уникальные идентификаторы (GUID). При создании объекта в новой базе сохраняйте GUID объекта-источника в отдельный реквизит.
• Если GUID использовать невозможно, создайте дополнительный реквизит (например, КодБП или Артикул), по которому будет выполняться поиск перед созданием новой записи.
• Всегда сначала проверяйте существование объекта по ключевым реквизитам. Если объект найден — обновляйте его данные, если не найден — создавайте новый.

Итоговые рекомендации

Чтобы выбрать оптимальный путь, ответьте на вопрос о сложности задач:

• Если обмен простой и редкий — используйте внешнюю обработку с прямым подключением. Это сэкономит время на настройку и отладку.
• Если планируется рост функционала — внедряйте БСП (Библиотеку стандартных подсистем) в самописную конфигурацию. Это даст вам готовые механизмы обмена, планы обмена и регистрацию изменений «из коробки».
• Если важна независимость систем — используйте HTTP-сервисы. Это позволит масштабировать систему в будущем, даже если одна из баз будет перенесена на другой сервер.

Помните, что качественный учет начинается с уникальности данных. Каким бы методом вы ни воспользовались, уделите основное внимание механизму поиска и сопоставления объектов.