Какие существуют стандартные форматы обмена заказами и номенклатурой в 1С

← На главную

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

Формат CommerceML (CML) — проверенный стандарт для веб-интеграций

Разберем один из самых известных стандартов в экосистеме 1С — CommerceML. Это XML-ориентированный формат, разработанный компаниями 1С и Microsoft. Он является стандартом де-факто для обмена данными между 1С и популярными CMS, такими как Битрикс, UMI.CMS или InSales.

Рассмотрим структуру обмена через CommerceML. Обычно процесс делится на два этапа:

Выгрузка каталога: Передаются группы товаров, сама номенклатура, свойства, характеристики, цены и остатки.
Обмен заказами: Сайт передает информацию о новых заказах и контрагентах, а 1С возвращает статусы и изменения по этим заказам.

Проанализируем ситуацию с характеристиками и сериями. Несмотря на критику в некоторых сообществах, формат CommerceML 2.0 вполне успешно справляется с передачей характеристик. Если вы используете типовые механизмы, обратите внимание на узлы СтандартныеСвойства и ЗначенияСвойств. Для самописной конфигурации вы можете реализовать формирование XML по схеме CML, что позволит вашему решению "из коробки" подключаться ко многим готовым движкам сайтов.

Использование JSON и HTTP-сервисов: современный подход

Если ваша задача — построить гибкую и быструю систему обмена через GET и POST запросы, стоит рассмотреть создание собственного API на базе HTTP-сервисов и формата JSON. Проанализируем, почему это часто оказывается эффективнее использования старых XML-стандартов.

Во-первых, JSON имеет гораздо меньший объем данных по сравнению с XML, что критично для мобильных сетей и высоконагруженных сайтов. Во-вторых, современные веб-фреймворки нативно работают с JSON. Для реализации такого обмена в 1С мы рекомендуем использовать XDTO-пакеты. Рассмотрим пример того, как это работает:

Вы описываете структуру ваших данных (Заказ, Товар, Контрагент) в дереве XDTO-пакета.
При получении запроса в HTTP-сервисе вы просто сериализуете данные из объектов 1С в JSON, используя встроенные средства платформы.

Посмотрим на пример кода для формирования JSON-ответа из 1С:


ЗаписьJSON = Новый ЗаписьJSON;
ПараметрыЗаписиJSON = Новый ПараметрыЗаписиJSON(ПереносСтрокJSON.Нет);
ЗаписьJSON.УстановитьСтроку(ПараметрыЗаписиJSON);

СтруктураОтвета = Новый Структура;
СтруктураОтвета.Вставить("ИмяОбъекта", "Номенклатура");
СтруктураОтвета.Вставить("Код", ТоварСсылка.Код);
СтруктураОтвета.Вставить("Наименование", ТоварСсылка.Наименование);

ЗаписатьJSON(ЗаписьJSON, СтруктураОтвета);
РезультатСтрокой = ЗаписьJSON.Закрыть();

Такой подход позволяет вам полностью контролировать состав передаваемых данных и легко расширять формат без оглядки на ограничения жестких стандартов.

EnterpriseData — универсальный формат внутри экосистемы 1С

Выясним роль формата EnterpriseData (ED). Это XML-формат, на который опирается Библиотека Стандартных Подсистем (БСП). Он позиционируется как универсальное решение для обмена между любыми конфигурациями 1С (например, между УТ 11 и Бухгалтерией 3.0).

Важный момент: хотя формат ED считается "внутренним" для 1С, его спецификация (XSD-схема) открыта. Это означает, что теоретически любой внешний сайт может научиться принимать и отправлять данные в этом формате. Однако на практике ED очень перегружен лишними полями и метаданными, которые редко нужны простому интернет-магазину. Если вы разрабатываете обмен исключительно между своими базами 1С, использование EnterpriseData через ПланыОбмена и механизмы СинхронизацияДанных будет самым правильным решением.

YML (Yandex Market Language) — специфика для витрин

Проанализируем формат YML. Он был создан Яндексом для загрузки товарных предложений в Яндекс.Маркет. Рассмотрим его особенности:

Простота: Формат очень легкий и понятный, идеально подходит для передачи плоских списков товаров.
Ограниченность: YML предназначен только для выгрузки (в одну сторону). В нем сложно или невозможно передать полноценную структуру заказа или иерархию сложных контрагентов.

Если ваша цель — просто "выставить товары на витрину", использование YML будет отличным выбором. Но для полноценного двустороннего обмена (заказы, возвраты, оплаты) его ресурсов не хватит.

Автоматический REST API через протокол OData

Разберем еще один мощный механизм 1С, который часто незаслуженно обходят вниманием — автоматический интерфейс OData. Это встроенная возможность платформы, которая позволяет получить доступ к данным базы без написания кода HTTP-сервисов.

Чтобы включить этот механизм, достаточно выполнить несколько действий:

В свойствах конфигурации разрешить использование стандартного интерфейса OData.
Настроить состав объектов, которые будут доступны через этот интерфейс.
Опубликовать базу на веб-сервере (Apache или IIS).

После этого внешняя система сможет отправлять GET-запросы по URL вида http://server/base/odata/standard.odata/Catalog_Номенклатура и получать список товаров в формате Atom или JSON. Это самый быстрый способ организовать чтение данных из 1С для внешнего сайта.