Интеграции и e-commerce
Интеграция 1С с сайтом и интернет-магазином
Надёжная интеграция начинается с правил владения данными: где создаются товары, кто меняет цену, какая система хранит остаток и в какой момент заказ считается принятым.
Коротко
Для интеграции 1С с сайтом сначала определите источник истины для товаров, цен, остатков и заказов. Затем выберите механизм обмена — штатный CommerceML, HTTP/REST-сервисы или промежуточный API — и обязательно добавьте журнал, защиту от дублей, повтор операции и ручное восстановление. Запускать обмен лучше поэтапно: сначала каталог, затем остатки и только после этого заказы и статусы.
Какие данные обычно передают между 1С и сайтом
В типовом интернет-магазине из 1С на сайт передают номенклатуру, торговые предложения, характеристики, цены и остатки. В обратную сторону идут заказы, состав корзины, данные покупателя, способ доставки и оплаты. После создания заказа системы могут продолжать обмениваться статусами, отменами и документами.
Не все данные нужно синхронизировать в обе стороны. Двунаправленный обмен одним полем создаёт конфликт: менеджер меняет цену на сайте, бухгалтер — в 1С, а следующий сеанс перезаписывает одно из значений. Поэтому до разработки назначают систему-владельца для каждой сущности и поля.
Если сайт работает с несколькими складами, типами цен или юридическими лицами, схема усложняется. Эти правила нужно раскрыть до оценки, а не прятать под формулировкой «подключить 1С».
| Сущность | Обычное направление | Что согласовать |
|---|---|---|
| Товары и характеристики | 1С → сайт | Идентификаторы, категории, обязательные поля |
| Цены | 1С → сайт | Типы цен, акции, округление, валюта |
| Остатки | 1С → сайт | Склады, резерв, допустимая задержка |
| Заказы | Сайт → 1С | Момент создания, состав, доставка, клиент |
| Статусы | В обе стороны | Справочник и допустимые переходы |
| Возвраты | По процессу бизнеса | Кто инициирует и какие документы нужны |
CommerceML, REST API или промежуточный сервис
Открытый протокол обмена 1С с сайтом использует CommerceML 2 и разделяет публикацию каталога и обмен заказами. Он подходит, когда конфигурация 1С и CMS поддерживают типовой сценарий, а бизнес готов работать в его правилах.
HTTP-сервисы, REST или OData удобнее для нестандартного продукта, обмена отдельными событиями и более точного контроля. Промежуточный сервис нужен, когда систем несколько, форматы сильно различаются или обмен нельзя выполнять синхронно. Он принимает событие, проверяет данные, ставит задачу в очередь и хранит технический статус.
Выбор нельзя делать только по названию CMS. Сначала проверяют конфигурацию 1С, объём каталога, частоту изменений, доступную документацию и ограничения сервера.
| Подход | Когда подходит | Ограничение |
|---|---|---|
| CommerceML | Типовой каталог и обмен заказами | Сложнее отойти от стандартного протокола |
| REST / HTTP-сервисы | Событийный и нестандартный обмен | Нужен стабильный контракт API |
| OData | Чтение и работа с доступными данными 1С | Не заменяет проектирование процесса |
| Промежуточный сервис | Несколько систем, очереди, высокая критичность | Появляется отдельный компонент для поддержки |
Зафиксируйте правила до первой строки кода
Для каждого объекта нужен неизменный внешний идентификатор. Название товара не подходит: его редактируют, дублируют и переводят. Идентификатор связывает одну сущность в 1С, на сайте и в журнале обмена.
Определите допустимую задержку. Цена может обновляться каждые десять минут, остаток — чаще, а полное описание товара — раз в сутки. Если все данные выгружать одним тяжёлым пакетом, небольшой сбой будет блокировать весь каталог.
Отдельно опишите удаление. Чаще безопаснее не удалять товар физически, а скрывать его из продажи, сохраняя URL заказа и историю операций. Для статусов нужен явный справочник соответствий.
- Источник истины для каждой сущности и поля.
- Стабильный идентификатор между системами.
- Периодичность и максимальная задержка.
- Правила создания, обновления, скрытия и удаления.
- Соответствие статусов и допустимые переходы.
- Обязательные поля и поведение при неполных данных.
Как не потерять заказ при сбое обмена
Критичная операция должна иметь технический идентификатор и статус. Если 1С временно недоступна, сайт сохраняет заказ, показывает покупателю корректное подтверждение и ставит передачу в очередь. Повтор того же события не должен создавать второй заказ.
Журнал должен отвечать на четыре вопроса: что отправляли, когда, какой ответ получили и что делать ответственному. Ошибка «обмен не прошёл» бесполезна без номера заказа, поля и причины.
Мониторинг сообщает о накоплении очереди, повторяющихся ошибках и отсутствии успешного обмена дольше допустимого интервала. Для ручного восстановления нужен безопасный повтор конкретной операции.
Как запускать интеграцию по этапам
Сначала создают тестовую копию каталога и сверяют идентификаторы, категории, цены и изображения. Затем подключают остатки и проверяют задержку. Только после стабильной односторонней выгрузки включают заказы и обратные статусы.
Перед production готовят контрольный набор: товар с несколькими предложениями, нулевой остаток, скидка, новый клиент, повторный заказ, отмена и ошибочное обязательное поле. Эти примеры быстрее выявляют противоречия, чем попытка сразу выгрузить весь каталог.
- АудитПроверить конфигурацию 1С, CMS, данные, доступы, объём и документацию.
- КонтрактЗафиксировать поля, владельцев, идентификаторы, статусы и ошибки.
- КаталогЗапустить товары и цены на тестовой среде.
- ОстаткиПодключить склады, резерв и регламент обновления.
- ЗаказыПередавать состав, клиента, оплату, доставку и статусы.
- КонтрольВключить журнал, мониторинг, резервный сценарий и документацию.
От чего зависит стоимость интеграции 1С с сайтом
На цену влияют не количество товаров само по себе, а конфигурация 1С, качество исходных данных, число складов и типов цен, двусторонние статусы, возвраты и требования к отказоустойчивости. Типовой обмен дешевле собственного промежуточного сервиса.
Для оценки подготовьте версию и конфигурацию 1С, адрес тестового сайта, пример выгрузки, объём каталога, список складов и схему заказа. Если этих данных нет, начните с технического аудита.
Отдельную интеграцию можно заказать через страницу разработки и интеграции API. Для магазина с каталогом и заказами посмотрите состав пакета интернет-магазина и кейс Instrument Pro.
Надёжный обмен строится не вокруг кнопки «синхронизировать», а вокруг ясного владельца данных и контролируемого восстановления после ошибки.
FAQ
Частые вопросы
01Можно ли интегрировать 1С с самописным сайтом?
Да. Используют HTTP/REST-сервисы, OData, CommerceML или промежуточный API. Конкретный способ зависит от конфигурации 1С, модели данных и допустимой задержки.
02Как часто можно обновлять остатки?
Частота зависит от объёма, нагрузки и бизнес-риска. Важно определить допустимую задержку и отделить частые небольшие изменения от полной выгрузки каталога.
03Что делать с дублями товаров?
Нужно выбрать стабильный идентификатор, очистить соответствия до запуска и запретить создание новой сущности только по названию. Ошибочные соответствия фиксируют в журнале.
04Сайт остановится, если 1С недоступна?
Не должен. Заказ сохраняется на стороне сайта, операция ставится в очередь или получает статус для повторной передачи, а ответственному приходит уведомление.
Источники и документация
Материал подготовлен редакцией ХЭМС на основе проектной практики. Цены и технические условия актуальны на дату публикации и уточняются после разбора задачи.
Обсудить проект
Спроектируем обмен до разработки
Проверим системы, данные и сценарии ошибок. Вы получите схему интеграции, границы работ и ориентир по запуску.