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

← На главную

Обмен данными с дистрибьюторами — это классическая задача в экосистеме 1С, которая часто осложняется тем, что на стороне партнера может стоять любая конфигурация: от актуальной ERP 2.5 до сильно доработанной Торговля и Склад 9.2 на платформе 7.7. Рассмотрим подробно, как выстроить архитектуру обмена, если нам заранее неизвестна структура метаданных базы-приемника, но нам нужно передать элементы справочника Номенклатура.

Использование стандартных механизмов БСП и универсального формата XML

В большинстве современных типовых конфигураций, построенных на базе Библиотеки стандартных подсистем (БСП), встроена обработка Универсальный обмен данными в формате XML. Это мощный инструмент, который позволяет выгружать данные на основе правил, созданных в конфигурации Конвертация данных 2.0.

Разберем основные моменты этого подхода:

Если база дистрибьютора содержит БСП, мы можем рассчитывать на наличие встроенных механизмов загрузки.
Для выгрузки только базовых типов (строка, число, дата) нам достаточно создать простейшие правила обмена, где сопоставление идет по полям Наименование, Код или Артикул.
Главный минус: нам все равно нужно знать внутренние имена реквизитов в базе дистрибьютора, чтобы правила отработали корректно.

Универсальный стандарт CommerceML

Одним из самых жизнеспособных решений является использование протокола CommerceML. Этот стандарт обмена коммерческой информацией был разработан специально для взаимодействия между различными информационными системами.

Проанализируем преимущества CommerceML:

Стабильность: Структура этого формата практически не менялась со времен платформы 7.7.
Типовые механизмы: Большинство торговых конфигураций 1С (УТ, УНФ, ERP) имеют встроенные модули для чтения и записи файлов в этом формате.
Независимость: Если дистрибьютор не вносил радикальных изменений в типовой механизм импорта, справочник Номенклатура загрузится автоматически без написания кода на стороне приемника.

Обмен через формат EnterpriseData (КД 3.0)

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

Разберем алгоритм работы:

Источник выгружает данные в универсальный формат EnterpriseData.
Приемник «знает», как интерпретировать этот формат и сопоставить его со своими объектами метаданных.
Это решает проблему «неизвестной конфигурации», так как нам не нужно знать, как называются поля в базе дистрибьютора — об этом заботится сама конфигурация-приемник через свой модуль интеграции.

Реализация собственного API через HTTP-сервисы

Для более тесной интеграции и автоматизации процесса (исключая ручную пересылку файлов) рекомендуется использовать HTTPS и REST API. Это позволяет реализовать метод «Push», когда база дистрибьютора сама запрашивает данные или когда база производителя отправляет их напрямую в приемник.

Посмотрим на пример кода, который реализует простейшую обработку загрузки данных через HTTP-запрос с попыткой «угадать» реквизиты:


Попытка
    Соединение = Новый HTTPСоединение("api.distributor.ru");
    Запрос = Новый HTTPЗапрос("/get_nomenclature");
    Ответ = Соединение.Получить(Запрос);
    
    Если Ответ.КодСостояния = 200 Тогда
        ДанныеJSON = Ответ.ПолучитьТелоКакСтроку();
        Чтение = Новый ЧтениеJSON;
        Чтение.УстановитьСтроку(ДанныеJSON);
        Объекты = ПрочитатьJSON(Чтение);
        
        Для Каждого ТекОбъект Из Объекты Цикл
            НоваяСсылка = Справочники.Номенклатура.СоздатьЭлемент();
            НоваяСсылка.Наименование = ТекОбъект.Наименование;
            
            // Пытаемся заполнить дополнительные поля через Catch
            Попытка
                НоваяСсылка.Артикул = ТекОбъект.Артикул;
            Исключение
                // Поле Артикул отсутствует в данной конфигурации
            КонецПопытки;
            
            НоваяСсылка.Записать();
        КонецЦикла;
    КонецЕсли;
Исключение
    Сообщить("Ошибка сетевого взаимодействия: " + ОписаниеОшибки());
КонецПопытки;

Такой подход позволяет гибко обрабатывать различия в структурах баз данных, игнорируя отсутствующие реквизиты.

Использование табличных документов (Excel) как универсального посредника

Не стоит сбрасывать со счетов обмен через Excel. Несмотря на кажущуюся простоту, это самый универсальный способ. В платформе 1С существует стандартная обработка Загрузка данных из табличного документа.

Проанализируем ситуацию, почему это может быть выгодно:

Дистрибьютор может визуально проверить данные перед загрузкой.
Легко реализовать сопоставление колонок (например, «Наименование у поставщика» -> «Наименование в базе»).
Механизм работает даже на очень старых или сильно кастомизированных конфигурациях.

Автоматизированный интерфейс OData

Начиная с версии платформы 8.3.5, в 1С доступен автоматический REST-интерфейс (OData). Если дистрибьютор включит эту возможность, нам не нужно писать никакой код в его базе. Мы можем программно обращаться к его справочникам:

Получаем структуру полей через запрос $metadata.
Анализируем доступные поля (есть ли там Артикул, Штрихкод и т.д.).
Отправляем POST-запросы для создания новых элементов.

Важный момент: Для безопасности такой доступ должен быть ограничен правами пользователя и защищен на уровне веб-сервера.

Практические рекомендации по синхронизации

Чтобы избежать дублей и ошибок при загрузке в «неизвестную» базу, придерживайтесь следующих правил:

Синхронизация по уникальным ключам: Всегда используйте UUID (уникальный идентификатор 1С) или Штрихкод (EAN-13). Синхронизация по наименованию — это путь к появлению дублей из-за лишних пробелов или опечаток.
Предварительная обработка: Поставляйте дистрибьютору внешнюю обработку загрузки. Это позволит вам инкапсулировать логику сопоставления полей внутри этой обработки, не требуя от дистрибьютора внесения изменений в конфигурацию.
Использование расширений: В современных версиях платформы лучше поставлять функционал загрузки в виде Расширения конфигурации. Это позволит добавить необходимые реквизиты или кнопки в интерфейс дистрибьютора максимально безопасно.

Выясним причину выбора конкретного метода: если дистрибьюторов много и они технически не подкованы — используйте Excel или CommerceML. Если это крупные партнеры с собственным ИТ-штатом — внедряйте HTTP-сервисы или EnterpriseData.