Интеграция 1С и Элемента: как настроить двусторонний обмен товарами через JSON и HTTP-сервисы

Зачем нужен двусторонний обмен товарами между 1С и Элементом

Двусторонний обмен товарами между 1С и Элементом нужен, чтобы номенклатура, цены и остатки в учётной системе и во внешнем приложении совпадали, а изменения из любой стороны доезжали до второй. Технически это цепочка из четырёх звеньев: подключение к Элементу по токену с Bearer-аутентификацией, передача товара в JSON, регистрация изменений на обеих сторонах, обратная загрузка данных в 1С с контролем коллизий. Онлайн-курс 1С:Учебного центра №1 «Интеграция 1С и Элемента: от JSON до двустороннего обмена» разбирает эту цепочку целиком: от первого запроса к API до пакетной передачи и запуска обмена из Элемента через HTTP-сервис 1С. Курс пройдёт с 9 по 12 ноября 2026 года (информационный выпуск №34983 от 06.10.2026).

Сценарии, в которых такая связка встречается чаще всего:

• интернет-магазин на Элементе: каталог и цены тянутся из 1С, а новые карточки и правки описаний возвращаются в учётную систему;
• мобильное приложение или кабинет дилера: остатки и прайс формируются в 1С, а заказы и корректировки идут на сторону приложения;
• B2B-портал или маркетплейс: из 1С уходит товарный массив, обратно приходят статусы, цены и уточнения по номенклатуре.

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

Подключение к Элементу: токен доступа и Bearer-аутентификация

Работа с API Элемента начинается с токена доступа. Сервисная учётная запись отправляет идентификатор клиента и секрет на сервер авторизации, получает токен, и дальше каждый запрос несёт его в заголовке Authorization.

POST /api/v1/token HTTP/1.1
Host: адрес-Элемента
Content-Type: application/json

{
  "client_id": "ID-сервисной-учетки",
  "client_secret": "секрет-из-настроек-Элемента"
}

Дальше запросы к товарному API идут с заголовком вида:

GET /api/v1/products/1024 HTTP/1.1
Host: адрес-Элемента
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Accept: application/json

Слово Bearer в заголовке означает, что предъявитель токена получает доступ к ресурсам, разрешённым этому токену. Отсюда практические следствия: токен не передают в теле запроса и не пишут в открытые журналы; срок жизни токена ограничен, поэтому просроченный токен обновляют автоматически, а не перевыпускают вручную при каждой ошибке; права на чтение и запись товаров задают на стороне Элемента, а не в коде 1С.

Типовые ошибки доступа на этом шаге:

На курсе подключение к Элементу разбирают отдельным блоком: получение токена, HTTP и Bearer-аутентификация, передача товара в JSON (программа курса).

Передача товара в JSON: структура данных и первый запрос

Товар передаётся объектом JSON. Каркас, который закрывает большую часть задач обмена:

{
  "article": "SKU-00123",
  "name": "Кресло офисное Base",
  "price": 12990.00,
  "currency": "RUB",
  "stock": 14,
  "unit": "шт",
  "updated_at": "2026-11-09T09:00:00Z"
}

• article - артикул или внешний идентификатор. По нему товар сопоставляется на обеих сторонах, и без него обратная загрузка превращается в ручной поиск дублей;
• name - наименование, которое увидит покупатель или менеджер;
• price - цена числом, с точкой как десятичным разделителем;
• stock и unit - остаток и единица измерения. Поле часто опциональное: если учёт остатков ведёт только 1С, в Элемент его передают, а обратно не ждут;
• updated_at - временная метка изменения. Пригодится при разборе коллизий.

Отправка одного товара выглядит так:

POST /api/v1/products HTTP/1.1
Host: адрес-Элемента
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json; charset=utf-8

{
  "article": "SKU-00123",
  "name": "Кресло офисное Base",
  "price": 12990.00,
  "unit": "шт"
}

Три технические мелочи, которые ломают обмен чаще всего. Кодировка: тело запроса передают в UTF-8, иначе русские наименования превращаются в набор символов. Экранирование: кавычки и обратные слеши в описаниях экранируют, а переносы строк заменяют на \n. Числа: 12 990,00 из интерфейса 1С нельзя отправлять как есть, JSON ждёт 12990.00, без пробелов и с точкой.

Конкретный набор полей задаёт API Элемента, поэтому схему сверяют с его документацией. В анонсе курса детальная схема не приводится, но в программе заявлена передача товара в JSON и переход от одной позиции к массиву данных.

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

Отладка обмена: журнал и отладчик

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

Смотреть в ответе сервера нужно на четыре вещи:

1. Код состояния: 200 и 201 означают успех, 4xx указывают на проблему в запросе, 5xx на сбой на стороне Элемента.
2. Тело ответа: в нём обычно лежит текст ошибки с названием поля, которое не прошло валидацию.
3. Заголовки: идентификатор запроса, лимиты, требования к повторной авторизации.
4. Время ответа: медленные ответы объясняют таймауты при передаче больших пакетов.

Типовая ситуация: товар не создаётся, ответ 401 Unauthorized. Токен проверяют, он свежий. Тогда открывают отладчик и видят, что заголовок собран как Authorization: eyJhbGci..., без слова Bearer, или что перед запросом не обновили токен после истечения срока. Второй частый случай: ответ 400 с текстом про поле price, потому что цена ушла строкой "12990,00" вместо числа.

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

От одиночных запросов к пакетной передаче: очередь и фоновая обработка

Когда прайс переваливает за несколько сотен позиций, схема «один товар - один запрос» перестаёт работать: время обмена растёт вместе с количеством позиций, пользователь ждёт, а API рано или поздно отвечает 429. Переход к пакету делают за четыре шага.

1. Сформировать массив данных: выбрать товары запросом, разложить их по структуре, которую ждёт API, и разбить на порции.
2. Поставить порции в очередь. В 1С очередь удобно хранить в регистре сведений: ссылка на номенклатуру или номер порции, статус, дата постановки, число попыток.
3. Запустить фоновую обработку: фоновое задание забирает порцию из очереди и отправляет её в Элемент, не блокируя интерфейс.
4. Проверить статус и результат: после ответа обновить статус порции и записать результат по каждой позиции, чтобы ошибки не потерялись.

Размер порции подбирают под ограничения API Элемента: если сервер принимает пакет из 500 позиций и отвечает за секунды, дробить на пятёрки нет смысла; если лимит 50, крупный пакет вернёт ошибку целиком. Повторные попытки делают с нарастающей паузой, а признаком успешной обработки считают не факт отправки, а подтверждённый ответ по каждой позиции. На курсе разбирают пакетную передачу товаров, очередь запросов, фоновую обработку и проверку результата.

Планы обмена и регистрация изменений на обеих сторонах

Передавать весь каталог при каждом сеансе обмена дорого. Дешевле передавать только то, что изменилось, и здесь в 1С работает механизм планов обмена: изменение объекта регистрируется в узле плана обмена, а при обмене выгружаются только зарегистрированные записи. Это тот же принцип, по которому строится типовой обмен между базами 1С.

Что настраивают на стороне 1С:

• узел плана обмена с составом объектов, которые участвуют в синхронизации (номенклатура, цены, остатки);
• регистрацию изменений при записи объекта, чтобы правка цены или наименования попала в очередь на выгрузку;
• правила выгрузки: какие поля уходят, в каком формате, как формируется пакет сообщений.

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

Практическое правило: в каждой системе должно быть поле, по которому видно, что объект менялся и когда. Без этого двусторонний обмен быстро превращается в перезапись вслепую. Курс включает блоки по планам обмена и регистрации изменений в 1С, регистрации изменений в Элементе и загрузке данных в 1С.

Отдельная тонкость: анонс курса не раскрывает конкретные настройки планов обмена и состав полей, поэтому итоговую схему сверяют с конфигурацией и документацией API Элемента.

Обратная загрузка данных в 1С и контроль коллизий

Обратная загрузка начинается с сопоставления. Товар из Элемента находят в справочнике номенклатуры по артикулу или по внешнему идентификатору, и только потом обновляют. Если ключа нет, обмен создаёт дубли и разбирать их приходится вручную. Надёжнее хранить на обеих сторонах один и тот же идентификатор: GUID из 1С, записанный в карточку Элемента.

Коллизия это ситуация, когда один и тот же товар изменили в обеих системах. Пример: менеджер в 1С поднял цену до 13 500 рублей, а в Элементе в это же время изменили описание и оставили старую цену. При синхронизации обе версии претендуют на запись, и правило разрешения задают заранее.

На практике стратегии комбинируют по полям: цену и остатки ведёт 1С, описание и характеристики отдаёт Элемент, а расхождения по критичным реквизитам попадают в отдельный список для ручного разбора. Курс рассматривает двусторонний обмен товарами и контроль коллизий, то есть ситуации, когда один товар изменили в обеих системах.

Запуск обмена из Элемента через HTTP-сервис 1С

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

Схема выглядит так. В конфигурации создают HTTP-сервис с шаблоном адреса и методом, например POST /exchange/products. База публикуется на веб-сервере, а метод получает тело запроса, разбирает JSON и запускает обмен. Элемент отправляет запрос на этот адрес, когда нужно передать изменения или запросить актуальные данные.

POST /exchange/products HTTP/1.1
Host: адрес-публикации-1С
Authorization: Bearer токен-для-1С
Content-Type: application/json; charset=utf-8

{
  "mode": "push",
  "updated_since": "2026-11-01T00:00:00Z"
}

Два момента, которые стоит закрыть до запуска:

• идемпотентность: повторный вызов с тем же телом не должен создавать дубликаты товаров, поэтому запрос несёт идентификатор операции или метку времени;
• безопасность: HTTP-сервис доступен извне, значит нужны аутентификация, ограничение по IP или отдельный шлюз и проверка прав на запись.

Механику HTTP в 1С подробно разбирают в отдельном материале: обзор курса «Механизмы интеграции: протокол HTTP - продвинутый уровень», где речь идёт о пагинации, multipart-запросах, идемпотентности, JWT и контроле нагрузки.

Кому подойдёт курс и какие организационные детали важно знать

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

Организационные данные:

• даты: с 9 по 12 ноября 2026 года;
• формат: онлайн, 4 учебных дня с 9:00 до 12:00, занятия в режиме реального времени;
• стоимость: от 5176 рублей;
• что входит: доступ к записи на 90 дней, база для практических заданий, общение с преподавателем в чате на онлайн-занятиях, свидетельство о прохождении курса;
• как купить: через интернет-магазин учебного центра uc1.1c.ru;
• контакты: edu@1c.ru, +7(495) 688-90-02.

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

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