Как 1С обменивается данными с сайтом и CRM: CommerceML, OData, HTTP-сервисы и файлы — что выбрать

Короткий ответ: у 1С четыре рабочих способа обмена с сайтом и CRM. Типовой «Обмен с сайтом» по CommerceML переносит каталог, цены, остатки и заказы; стандартный REST-интерфейс OData открывает данные базы без доработки конфигурации; собственный HTTP-сервис нужен, когда требуется своя логика; файлы по расписанию годятся для редких выгрузок. Выбор зависит от того, какие данные и как часто должны ходить, и от того, где стоит база. Связку двух систем мы делаем по тарифу интеграций — от 32 000 ₽ и от 2 дней; доработку самой 1С оцениваем отдельно.

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

Какими способами 1С может обмениваться данными?

Для связки с сайтом и CRM на практике используют четыре способа: протокол обмена с сайтом в формате CommerceML, стандартный REST-интерфейс OData, собственные HTTP-сервисы и обмен файлами. Есть ещё SOAP веб-сервисы и прямые HTTP-запросы из 1С наружу, но это частные случаи тех же подходов.

Главное различие — кто начинает обмен:

• 1С отправляет сама. Так работает «Обмен с сайтом»: по расписанию база выгружает каталог и забирает заказы. Так же 1С может по событию отправить HTTP-запрос во внешнюю систему, например сообщить CRM о проведённой оплате, — но это уже код в конфигурации или расширении.
• Внешняя система спрашивает. Так работают OData и HTTP-сервисы: сайт, CRM или программа-посредник обращается к опубликованной базе и получает ответ в момент запроса.
• Обмен через файл. Одна сторона кладёт XML, CSV или Excel в папку или на почту, другая забирает. Просто, но с задержкой и без подтверждения на каждую операцию.

Для CRM типового протокола, как у сайтов, обычно нет: у amoCRM и Битрикс24 есть свои API и вебхуки, а со стороны 1С используют OData или HTTP-сервис. Между ними почти всегда стоит небольшая программа-посредник, которая сопоставляет поля, повторяет неудачные операции и пишет журнал.

CommerceML: где типовой обмен ограничен?

Типовой «Обмен с сайтом» хорош для классической торговли: каталог с ценами и остатками уходит на сайт, заказы возвращаются в 1С. Ограничения начинаются там, где нужна мгновенная реакция, нестандартные данные или своя логика статусов: протокол задаёт и состав данных, и порядок обмена.

Протокол разработали фирмы «1С» и «1С-Битрикс», он открыт, его описание есть на ИТС. Обмен состоит из двух процессов — выгрузки каталога и приёма заказов, — и в обоих инициатор 1С. Сайт только отвечает на запросы. При выгрузке каталога порядок такой: авторизация, параметры приёма (сжимать ли файлы и какой максимальный размер за один запрос), передача файлов и пошаговый импорт; при обмене заказами 1С сама запрашивает у сайта новые заказы, подтверждает их получение и отправляет изменения обратно.

Описание на ИТС датировано 2009 годом, а типовые обработки обмена с тех пор менялись. Правила ниже взяты из него; как именно ведёт себя обмен в вашей конфигурации и релизе, проверяют на копии базы до разработки.

Что из этого следует для бизнеса:

• Остатки обновляются с интервалом обмена. Если 1С выгружает каталог раз в час, сайт час показывает старые остатки. Чаще — можно, но тяжёлый каталог при частой выгрузке нагружает и базу, и сайт.
• Статусы оплаты и отгрузки — только «полностью». По описанию протокола на ИТС состояние заказа по оплате и отгрузке уходит на сайт лишь после полной оплаты и полной отгрузки. Частичную отгрузку покупатель на сайте не увидит.
• Контрагента 1С ищет по ИНН или наименованию — в зависимости от настроек. Для розницы, где у покупателя нет ИНН, правила поиска и создания контрагентов нужно продумать заранее, иначе справочник зарастёт дублями.
• Свойства заказа сопоставляются по названию. Если на сайте поле называется иначе, чем в 1С, при загрузке появится новое свойство со значением типа строка или число, а не заполнится существующее.
• Версии формата. Сайт должен понимать ту редакцию CommerceML, которую отдаёт ваша 1С. На ИТС описана редакция 2.04, а магазин AleksFurs мы делали под 2.08 — расхождение версий проверяют до разработки.

Если сайт написан не на коробочной CMS, приёмную сторону протокола реализует разработчик сайта. В AleksFurs автотест проходит обмен по шагам: новая позиция создаётся, существующая обновляется по артикулу, товар без цены скрыт до загрузки цен, остатки раскладываются по размерам, заказы уходят в 1С и повторно не выгружаются. Такие проверки нужны именно потому, что ошибки CommerceML обычно тихие: файл принят, а на витрине не то.

OData: доступ к данным без доработки конфигурации

Платформа 1С сама формирует REST-интерфейс для всего прикладного решения. После публикации базы на веб-сервере внешняя система может читать справочники, документы и регистры, создавать и менять объекты и проводить документы — без программирования в самой конфигурации.

По описанию на сайте 1С интерфейс работает по протоколу OData версии 3.0, ответы приходят в Atom/XML или JSON. Доступны справочники, документы, константы, перечисления, планы обмена, регистры накопления, сведений и бухгалтерии; у регистров накопления и бухгалтерии можно получить остатки и обороты, у регистра сведений — срез первых и последних записей. Аутентификация та же, что у веб-сервисов 1С.

Где OData удобен:

• CRM показывает менеджеру долг клиента и историю его отгрузок из 1С;
• сайт или бот проверяет остаток конкретного артикула в момент запроса;
• посредник раз в несколько минут забирает новые документы и передаёт их в CRM.

Ограничения тоже есть. В перечне объектов REST-интерфейса отчётов нет — только данные справочников, документов и регистров, поэтому сложную аналитику собирают на стороне посредника. Перед стартом решают, какие именно объекты нужны интеграции и какому пользователю 1С открыть к ним доступ: всё остальное ей не нужно. Запросы строятся по именам объектов конфигурации — ресурс справочника называется Catalog_<имя>, например Catalog_Номенклатура, — и если при обновлении объект или реквизит переименуют, запрос перестанет работать. А запись через OData возможна, но всю бизнес-логику проверок она не заменит: создавать документы этим путём стоит только по согласованию с вашим программистом 1С.

HTTP-сервис: когда нужна своя точка обмена?

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

По документации платформы HTTP-сервис состоит из шаблонов адресов и методов. Шаблон задаёт путь с параметрами, например код товара в адресе; если запрос не подошёл ни под один шаблон, 1С отвечает кодом 404. Публикуются HTTP-сервисы так же, как веб-сервисы, и аутентификация устроена аналогично.

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

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

Способ	Когда подходит	Ограничения и риски	Что нужно от 1С
CommerceML («Обмен с сайтом»)	Каталог, цены, остатки на сайт и заказы обратно в 1С	Обмен запускает 1С по расписанию; набор данных задан протоколом; статусы оплаты и отгрузки уходят на сайт только при полном выполнении	Типовая обработка обмена, настройка узла обмена
REST-интерфейс OData	Чтение справочников, документов, остатков; простая запись без доработки конфигурации	Отчётов в составе интерфейса нет; запросы привязаны к именам объектов и могут сломаться после обновления	Публикация базы на веб-сервере, состав объектов, отдельный пользователь
Свой HTTP-сервис	Особая логика: расчёт цены для клиента, проверка резерва, сложный заказ одним запросом	Это код в конфигурации или расширении: его пишет программист 1С и сопровождают при обновлениях	Доработка в расширении и публикация на веб-сервере
Файлы по расписанию	Редкие выгрузки: прайс раз в день, отчёт раз в неделю	Данные устаревают между выгрузками; сбой формата часто замечают поздно	Обработка выгрузки, общая папка или почта

Какой способ выбрать под вашу задачу?

Начните с вопроса, что и как часто должно ходить между системами. Каталог и заказы магазина — CommerceML; чтение данных 1С из CRM — OData; своя логика расчёта или резерва — HTTP-сервис; редкий отчёт или прайс — файл. Часто в одном проекте сочетаются два способа.

Пример. Оптовая компания хочет, чтобы менеджер в CRM видел долг клиента, а заказы с сайта попадали в 1С. Каталог и заказы идут по CommerceML, долг и отгрузки CRM получает через OData с помощью посредника. Свой HTTP-сервис появляется, только если цена для каждого клиента считается по сложным правилам, которые не хочется повторять вне 1С.

1С в облаке и на своём сервере: что меняется?

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

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

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

Когда сложная интеграция не нужна?

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

Ошибки, из-за которых обмен ломается или не приносит пользы:

• Нет единого ключа. Товар в 1С и на сайте сопоставляют по названию, а не по артикулу или коду — после переименования появляется дубль.
• Две системы считаются главными. Цены правят и в 1С, и в CRM, и обмен по очереди затирает чужие изменения. Для каждого вида данных должна быть одна система-источник.
• Нет журнала. Обмен упал ночью, а узнали об этом от покупателя. Ошибки должны писаться в журнал и приходить уведомлением.
• Открыли всю базу. Пользователь интеграции с полными правами — лишний риск. Права выдают только на нужные объекты.
• Не проверили на реальных данных. На тестовых десяти товарах всё работает, а на настоящем каталоге всплывают пустые цены, характеристики и дубли.

Кто это делает и сколько стоит?

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

По прайсу связка двух систем — тариф «Интеграции и автоматизация», от 32 000 ₽ и от 2 дней. В него входят обмен заказами, товарами, остатками, клиентами и статусами через API или вебхуки, обработка ошибок и журнал операций, проверка на реальных данных и инструкция, что делать при сбое. Каждая система сверх двух оценивается отдельно, доработка конфигурации 1С в тариф не входит, лицензии 1С и CRM вы оплачиваете поставщикам. Если нужен магазин целиком, интернет-магазин стоит от 104 000 ₽ и одна интеграция уже входит в состав.

По договору оплата идёт двумя частями — 50 % предоплата и 50 % после подписания акта; на приёмку у вас 5 рабочих дней, предусмотрено до 2 раундов правок. Гарантия — 30 календарных дней с даты акта, и первые 7 дней после запуска мелкие правки делаем бесплатно; дальше обмен можно передать на поддержку — от 7 900 ₽ в месяц. Исполнитель освобождён от НДС по п. 1 ст. 145 НК РФ.

Как не сломать обмен при обновлении 1С?

Обмен ломается при обновлении, когда меняются имена объектов и реквизитов, формат CommerceML или поведение типовой обработки. Защита — доработки в расширениях, тестовая копия базы для проверки обновления и автотест обмена, который прогоняют до выкладки обновления в рабочую базу.

Порядок, который мы советуем закрепить с программистом 1С:

1. Опишите обмен. Какие объекты и поля участвуют, какой способ, какой пользователь, по какому расписанию. Это одна страница, но без неё любой новый специалист начинает с раскопок.
2. Держите доработки в расширении. Свой HTTP-сервис и правки обмена — в расширении конфигурации, тогда типовую часть можно обновлять штатно.
3. Обновляйте сначала копию. Новый релиз ставят на копию базы и прогоняют обмен: выгрузку каталога, приём заказа, запросы OData.
4. Автоматизируйте проверку. Автотест обмена, как в AleksFurs, за минуты показывает, что сломалось: создание товара, обновление по артикулу, цены, остатки, повторная выгрузка заказов.
5. Следите за журналом первые дни. После обновления ошибки обмена смотрят ежедневно, пока не станет ясно, что всё идёт штатно.

Больше о том, как такие связки окупаются и с какого стыка начинать, — в статье об интеграции 1С, CRM и маркетплейсов, а что такое API простыми словами — в разборе API-интеграции.

С чего начать?

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

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

Короткие ответы на частые вопросы

Можно ли связать 1С с сайтом без программиста 1С?

Часто да. Если хватает типового «Обмена с сайтом» по CommerceML или стандартного REST-интерфейса OData, на стороне 1С нужны только настройка и публикация базы, без изменения конфигурации. Программист 1С понадобится, когда нужен свой HTTP-сервис или правка правил обмена.

Что быстрее работает: CommerceML или OData?

Это разные модели. CommerceML передаёт данные пакетами по расписанию, которое задают в 1С, а через OData внешняя система запрашивает данные сама, когда они нужны. Для каталога на тысячи позиций пакет удобнее, для проверки одного остатка или статуса — запрос по OData.

Работает ли обмен, если 1С в облаке?

Зависит от провайдера. В документации 1С:Фреш есть раздел об использовании сервиса OData для доступа внешних сервисов к данным приложения; условия доступа уточняют у провайдера. Возможность опубликовать собственный HTTP-сервис и открыть нужные объекты уточняем у провайдера до сметы.

Сколько стоит настроить обмен 1С с сайтом или CRM?

Связка двух систем по тарифу интеграций — от 32 000 ₽ и от 2 дней. Доработка конфигурации 1С в тариф не входит и оценивается отдельно, лицензии 1С и CRM вы оплачиваете поставщикам. Итоговую цену называем после брифа и фиксируем в договоре до старта.

Нужно ли открывать 1С в интернет?

Для OData и HTTP-сервиса базу публикуют на веб-сервере, но это не значит «для всех». Доступ закрывают HTTPS, отдельным пользователем с узкими правами и ограничением по адресам, а при необходимости ставят посредника, который один ходит в 1С.

Услуги и кейсы по теме: интеграция с 1С и CRM от 32 000 ₽ · поддержка сайта от 7 900 ₽/мес · кейс AleksFurs · цены и сроки