Типовой обмен или API: как выбрать интеграцию 1С и Битрикс
Для выгрузки товаров, цен, остатков и передачи обычных заказов сначала проверяйте совместимый готовый модуль. Если не хватает одного поля — оценивайте доработку. Если сайт должен запросить расчёт или получить подтверждение резерва до ответа покупателю — проверяйте эту операцию отдельно и при необходимости делайте API. Переписывать весь обмен ради одной такой операции не нужно: каталог может остаться на CommerceML.
Статья про интернет-магазин на «1С-Битрикс: Управление сайтом». «Бэк-офис» и REST Битрикс24 относятся к другой системе. Ниже — выбор на примерах магазина, B2B-цен и продажи последнего товара, а также место WebSocket в этой схеме.
Что выбрать для вашей задачи
| Ваша задача | С чего начать | Когда потребуется другой вариант |
|---|---|---|
| Товары с характеристиками, несколько складов и видов цен; заказ обрабатывает менеджер | Готовый обмен | Нужные данные или изменения заказа не поддерживаются установленным модулем. |
| Обмен работает, но не передаёт дополнительный реквизит | Настройка, затем локальная доработка | Ради реквизита приходится заменять формирование пакета и импорт целиком. |
| Цена определяется договором, составом корзины и текущими условиями в 1С | Готовые виды цен — если они выражают это правило; иначе отдельный запрос расчёта | Нельзя заранее выгрузить применимые цены без потери нужной логики. |
| Нельзя подтвердить продажу, пока 1С не закрепила последний товар | Проверка операции резерва в готовом решении; при её отсутствии — собственная команда | Получение свежего остатка не даёт подтверждения резерва. |
| Нужно доставлять события из закрытой сети 1С без постоянного опроса | Исходящие HTTP-запросы; WebSocket — если нужно постоянное двустороннее соединение | Частота, направление сообщений и ограничения сети оправдывают отдельный сервис соединений. |
CommerceML задаёт структуру коммерческих данных; API — набор доступных операций; HTTP и WebSocket — способы взаимодействия. Это разные уровни. Выбор JSON вместо XML сам по себе не ускорит расчёт цены, а WebSocket не добавит готовое резервирование.
Как проверить типовой обмен до заказа разработки
Начните с точной связки версий. В 1С откройте «О программе» и запишите отдельно версию платформы и конфигурации. На странице модулей обмена найдите своё решение и поддерживаемый релиз. Там есть модули для УТ 11.5, УНФ 3.0, ERP 2, КА 2 и Розницы 2.3. Наличие подходящего названия ещё не подтверждает совместимость с доработанной базой.
Проверку выполните на копии 1С и тестовом сайте. Ниже пути для УТ 11.5 с модулем Битрикс 8.1.x; для другой конфигурации используйте инструкцию из её дистрибутива.
- В 1С откройте 1С-Битрикс: Управление сайтом → Настройки обмена с сайтами. Создайте тестовую настройку, укажите адрес стенда и отдельного пользователя обмена.
- В блоке «Выгрузка информации о номенклатуре» → «Настроить» выберите каталог. В настройках «Цены» задайте виды цен, в «Остатки» — склады и правило учёта резерва, в «Отборы» — тестовые позиции. Отправлять такой ограниченный полный пакет на рабочий сайт нельзя: при настройке деактивации отсутствующих товаров можно скрыть остальные позиции.
- Возьмите товар с двумя характеристиками, разными ценами и остатками на двух складах. Выполните выгрузку. На сайте откройте каждое торговое предложение и сравните его цену, склад и количество с ожидаемыми значениями.
- Измените цену одной характеристики и обнулите её остаток. Запустите обмен изменениями. Убедитесь, что обновился нужный вариант, а соседний остался прежним.
- Настройте предусмотренный модулем обмен заказами. Оформите на стенде заказ, получите его в 1С, выполните используемые магазином изменение и отмену. Проверьте результат на обеих сторонах, включая резерв, если он нужен вашему процессу.
Пути настройки: подключение и режимы, цены, склады и отборы. Результат проверки — список конкретных пробелов: например, «характеристики и склады передаются; дополнительный реквизит заказа не передаётся». Это основание оценить одну доработку. Формулировка «нужна сложная интеграция» такого основания не даёт.
Для каталога измерьте время от изменения в 1С до появления значения на витрине. Для заказа — до нужного состояния в 1С. В штатном режиме реального времени для документов сайт сообщает ожидающему сеансу 1С, что пора начать обмен. Это позволяет не ждать очередного запуска по расписанию, но не гарантирует резерв в момент нажатия кнопки.
Три примера: где хватает модуля, а где нужен код
Магазин: розница, опт и два склада
Условие: в 1С два вида цен, на сайте две группы покупателей. Менеджер подтверждает заказ после поступления в 1С; магазин допускает согласованную задержку обновления остатков.
Решение: готовый обмен каталогом и заказами. Проверьте, поддерживает ли редакция Битрикс несколько типов цен: редакция с единственным типом не подходит для этого сценария. Выгрузите оба вида цен, настройте права групп на сайте и проверьте корзину под розничным и оптовым пользователями. Несколько складов и характеристик сами по себе не требуют собственного API. Если покупатель видит чужую цену, сначала проверьте права типа цены и скидки, а не меняйте технологию обмена.
B2B: цена зависит от договора и всей корзины
Условие: одна и та же позиция для одного клиента стоит по-разному в зависимости от объёма заказа и действующих условий договора. На сайте нужна именно сумма, рассчитанная в 1С.
Решение: если правило выражается заранее подготовленными видами цен и поддерживаемыми условиями, проверьте готовую схему. Если расчёт должен выполняться в 1С для каждой корзины, оставьте каталог на штатном обмене и добавьте операцию расчёта.
- Сайт отправляет идентификаторы клиента и договора, предложения и количества. Идентификатор клиента определяет сервер по авторизованному пользователю; принимать чужой договор прямо из браузера нельзя.
- 1С проверяет доступность договора и возвращает цены строк, валюту, налоги и итог. В собственной схеме добавьте идентификатор расчёта и срок его действия, чтобы понимать, какую сумму подтвердил покупатель.
- Перед оформлением проверьте, что состав корзины и условия расчёта не изменились. Если сумма поменялась, покажите новую покупателю до подтверждения. На время недоступности 1С выберите явный режим: «запросить цену» либо сохранённое предложение, если его ещё разрешено использовать.
Так можно организовать расчёт; готовый модуль не обязательно поддерживает эту схему. Проверять нужно две корзины с одним товаром и разными объёмами: результат сайта должен совпасть с расчётом 1С. Отдельно измените договор после расчёта — старую цену нельзя молча считать действующей.
Последняя единица: два покупателя оформляют заказ одновременно
Условие: товар один, купить его могут и на сайте, и через менеджера в 1С. Покупателю можно сообщить об успешном резерве только после подтверждения системы, которая его ведёт.
Решение: проверка остатка перед заказом недостаточна. Оба покупателя могут успеть получить ответ «1 шт.». Нужна операция, которая в ответственной системе проверяет доступность и закрепляет товар с защитой от одновременного выполнения. Если готовый модуль не даёт нужного результата, реализуйте отдельную команду резерва.
Один постоянный ID операции, внешний ID заказа, предложение и количество.
Проверяет доступность и создаёт резерв с учётом конкурирующих заказов.
«Зарезервировано» — после подтверждения. При ожидании ответа — «Проверяем наличие».
Повтор с тем же ID возвращает состояние или результат операции, не создавая второй резерв.
В этом примере резервом управляет 1С. Отмена заказа и истечение срока резерва требуют отдельной обработки.
Приёмка: одновременно отправьте два разных заказа на последнюю единицу. Два заказа не должны получить подтверждение одной единицы. При исправной связи и выполнении остальных условий один подтверждается, второй получает отказ. Затем повторите его команду и оборвите связь после записи, но до получения ответа. Ни второй резерв, ни второй заказ появиться не должны. Все каналы продаж обязаны учитывать тот же механизм резервирования; иначе защита только на сайте проблему не решит.
Как реализовать API и не привязать магазин к доступности 1С
Когда нужен ответ сейчас — например, расчёт корзины — сайт может вызвать HTTP-сервис 1С. Разработчик создаёт обработчик запроса, проверки и ответ; сервис публикуют с аутентификацией и ограниченным сетевым доступом. До реализации согласуйте максимальное время ожидания и поведение формы при тайм-ауте. HTTP не обязывает обрабатывать запрос синхронно: сервис может принять задание и вернуть его ID для последующей проверки.
Когда можно обработать позже — например, передать заказ на подтверждение менеджеру — сайт сначала сохраняет заказ и задание на отправку. Фоновый обработчик доставляет его в 1С; при сбое задание остаётся для повтора. Если входящие соединения к 1С запрещены, 1С может сама забирать задания с сайта исходящими HTTP-запросами. Для этого публиковать входящий сервис 1С не требуется.
| Результат | Что делает сайт |
|---|---|
| Задание принято, ID операции известен | Показывает ожидание подтверждения и запрашивает состояние. Не сообщает о резерве. |
| Заказ записан, резерв подтверждён | Сохраняет ID заказа 1С и подтверждённый результат. |
| Недостаточно товара или недействителен договор | Показывает причину и предлагает изменить заказ. Не повторяет неизменённый ошибочный запрос бесконечно. |
| Ответ не получен | Проверяет состояние или повторяет ту же операцию с тем же ID. Тайм-аут не доказывает, что запись не состоялась. |
Получатель должен сохранять ID операции и результат так, чтобы одновременно пришедшие повторы не создали дубль. Для изменения заказа дополнительно нужна версия: сообщение о старом состоянии не должно откатить новую отмену.
Можно ли обойтись OData? Стандартный REST-интерфейс 1С позволяет читать и изменять объекты приложения. Он полезен, когда нужны именно такие операции. Но запись документа не равна бизнес-операции «проверить условия и зарезервировать»: нужные проверки и переходы нужно обеспечить отдельно. Документация указывает, что проверка заполнения при этом интерфейсе не выполняется.
На стороне сайта разработчик использует серверные API Битрикс. D7 API каталога — PHP-интерфейс внутри приложения; внешний HTTP-обработчик ещё нужно реализовать. Готовые REST-методы Битрикс24 нельзя переносить в проект «Управления сайтом» по аналогии.
WebSocket в 1С: когда он полезен
WebSocket полезен, когда 1С и сервису интеграции нужно постоянно отправлять сообщения друг другу без нового запроса для каждого события. Например, после изменения резерва 1С сообщает сайту, что пора обновить доступность. Для разового расчёта корзины HTTP обычно проще в эксплуатации.
Нативный WebSocket-клиент появился в платформе 8.3.27; прежде для таких задач использовали, в частности, внешние компоненты. 1С сама устанавливает соединение с WebSocket-сервером и затем отправляет и получает сообщения. Это не встроенный сервер, к которому автоматически подключится магазин. При исходящем соединении открывать входящий доступ к базе 1С ради WebSocket не нужно.
Фиксирует изменение и запись события согласованно, без окна потери. Отправка — после успешной фиксации.
Исходящее защищённое соединение wss. На другой стороне работает WebSocket-сервер.
Сайт применяет актуальную версию данных и отдельно обновляет интерфейс покупателя, если это требуется.
После восстановления доставляются неподтверждённые события; дубли распознаются по ID.
Пример архитектуры: хранение событий, подтверждения и восстановление разрабатываются отдельно. Постоянное соединение само их не обеспечивает.
WebSocket-сервер может быть отдельным компонентом инфраструктуры. Node.js, Go и брокер сообщений — возможные инструменты, а не обязательный набор. RabbitMQ или Kafka не заменяют WebSocket-сервер одним фактом установки.
Что проверить до выбора: поддерживается ли клиент вашей платформой и средой запуска; кто держит соединение без открытого окна пользователя; как сервис переживает перезапуск; как восстанавливаются пропущенные сообщения. Измерьте задержку при рабочей нагрузке: доставка сообщения не устраняет время расчёта, блокировки и запись в 1С. «Миллисекунды» и минимальную нагрузку нельзя обещать по названию протокола.
Что оставить в типовом обмене при переходе на API
Для B2B-примера выше достаточно трёх потоков: карточки и обычные цены — готовым обменом; персональный расчёт корзины — отдельным запросом; заказ — одним выбранным маршрутом. Перед включением второго канала выпишите, какие поля он записывает.
| Поток | Правило записи |
|---|---|
| Каталог через CommerceML | Сохраняет учётные данные товара. Редакционные описания сайта исключены из перезаписи. |
| Персональный расчёт через API | Хранится для конкретной корзины и клиента; не перезаписывает общую розничную цену товара. |
| Создание заказа через API | Штатный канал не создаёт тот же заказ второй раз. Если он участвует в последующих изменениях, использует согласованные идентификаторы и версии. |
| События резерва через WebSocket, если он выбран | Не дают старому пакету остатков затереть новое состояние: вводится проверка версии либо запись этого поля полностью выводится из второго канала. |
Контрольная проверка: получите новую цену или резерв через API, затем запустите полный штатный обмен на стенде. Если цена корзины пропала, резерв откатился или появился дубль заказа, каналы ещё не разделены. На рабочий сайт такую схему переносить рано.
Как сравнить трудоёмкость и получить обоснованную оценку
У готового обмена уже есть значительная часть механики передачи и обработки. В собственной интеграции команда создаёт её и затем поддерживает. Но готовый модуль с многочисленными изменениями тоже может оказаться дорогим. Запросите оценку по одному и тому же сценарию:
| Работа | Готовый модуль с доработкой | Собственный API |
|---|---|---|
| Настройка и сопоставление | Подбор совместимого модуля, склады, виды цен, внешние ID | Те же данные и ID плюс описание запросов и ответов |
| Бизнес-операция | Какая настройка или точка расширения закрывает конкретный пробел | Какие проверки, документы и состояния создаёт собственный обработчик |
| Сбой и повтор | Как модуль восстанавливается именно в вашем сценарии | Где сохраняются задания, результаты и защита от дублей |
| Обновления и поддержка | Проверка доработок на новых релизах, доступ к их исходникам | Версии интерфейса, тесты совместимости, исходники и инструкции эксплуатации |
Большой каталог не является автоматическим доводом за API. На стенде измерьте первичную загрузку и обычный объём изменений: сколько предложений, цен, складских записей и изображений реально передаётся. Если обмен замедляет один обработчик сайта или запрос 1С, новый транспорт не уберёт эту причину. Если работающий обмен расходится в данных, сначала найдите место расхождения.
Попросите разработчика показать на стенде спорную операцию из вашего заказа, с вашими ценами и правилами резерва. Выбор готового обмена, доработки или API должен опираться на её результат и состав работ.
Источники и границы примеров
Проверено 8 сентября 2026 года по документации 1С и Битрикс: совместимость модулей, настройки обмена 8.1.x, параметры выгрузки, HTTP-сервисы, WebSocket-клиент. Сценарии корзины, резерва и доставки событий — примеры проектирования; они не описывают готовые кнопки типового модуля и не являются отчётом об испытании конкретной базы.