Интеграция сайта с 1С: товары, цены, остатки, заказы и документы
Интеграцию с 1С часто обсуждают так, будто это одна функция: «нужно подключить сайт к 1С». На практике за этой фразой может скрываться что угодно — от ночной выгрузки прайса до двусторонней системы, где сайт получает каталог и остатки, а в 1С возвращаются заказы, статусы и документы.
Самая опасная ошибка — начинать с выбора модуля, не договорившись, какая система за что отвечает. Если цены можно менять и на сайте, и в 1С, а остатки обновляются из двух мест, рано или поздно данные разойдутся. И тогда проблема будет не в «плохой интеграции», а в том, что у бизнеса нет единого источника истины.
Интеграция работает хорошо не тогда, когда данные просто передаются. Она работает хорошо, когда понятно, откуда берётся каждое значение, куда оно попадает и что делать, если обмен не состоялся.
С чего начинается нормальная интеграция
До разработки мы раскладываем процесс на сущности и направления обмена. Для большинства интернет-магазинов и B2B-каталогов базовый набор выглядит так:
| Данные | Откуда чаще идут | Куда передаются | Что важно решить |
|---|---|---|---|
| Товары | 1С | Сайт | Артикул, свойства, категории, изображения |
| Цены | 1С или отдельная система | Сайт | Типы цен, акции, НДС, персональные условия |
| Остатки | 1С / склад | Сайт | Физический остаток, резерв, несколько складов |
| Заказы | Сайт | 1С | Состав, клиент, доставка, оплата, комментарий |
| Статусы | 1С / CRM | Сайт или кабинет | Какие статусы видит клиент |
| Документы | 1С | Сайт / кабинет | Счета, накладные, спецификации |
Главный вопрос на этом этапе — где находится мастер-данная. Например, если цена ведётся в 1С, сайт не должен молча сохранять ручную цену, которая через час будет перезаписана обменом. Если карточка товара редактируется маркетологом на сайте, нужно разделить поля: характеристики приходят из учётной системы, а SEO-текст и изображения управляются в CMS.
Почему «синхронизировать всё» — плохое техническое задание
Не все данные нужно передавать в обе стороны. Двусторонний обмен звучит гибко, но увеличивает количество конфликтов. Намного надёжнее заранее определить владельца каждого поля.
Разумно хранить в 1С
- артикулы и номенклатуру;
- базовые цены;
- складские остатки;
- заказы в учётном контуре;
- контрагентов и документы, если это часть процесса.
Разумно хранить на сайте
- SEO-тексты;
- маркетинговые заголовки;
- изображения для контента;
- связанные статьи и кейсы;
- визуальные блоки карточки.
Конкретная схема зависит от компании. Например, у производителя технические характеристики могут быть эталонными в 1С, а у интернет-магазина часть контента ведётся поставщиками. Важно не следовать шаблону, а зафиксировать правила именно вашего проекта.
CommerceML, REST API или готовый модуль
У 1С есть стандарт CommerceML для обмена коммерческой информацией. Официальный протокол обмена с сайтом построен на CommerceML 2 и XML; в типовых сценариях 1С может передавать каталоги и коммерческие предложения, а также обмениваться заказами с интернет-магазином.
Для 1С-Битрикс существует штатная интеграция с 1С и профили обмена. Это хороший вариант, когда процесс близок к типовой модели. Но как только появляются нестандартные поля, несколько источников данных, собственные статусы или особые правила бизнеса, стандартный обмен приходится настраивать или расширять.
| Способ | Когда подходит | Ограничения |
|---|---|---|
| CommerceML | Каталог, предложения, заказы, типовой обмен | Структура формата и логика типовых конфигураций |
| Готовый модуль CMS | Понятный сценарий без сильной кастомизации | Зависимость от возможностей модуля |
| REST API | Нестандартная логика, точечный обмен, внешние сервисы | Нужно проектировать авторизацию, ошибки, лимиты |
| CSV/XML по расписанию | Простой пакетный обмен | Не подходит для оперативных сценариев |
| Ручная выгрузка | Временный старт или редкие обновления | Не масштабируется и зависит от человека |
Не выбирайте транспорт раньше процесса
CommerceML и API — это способы передачи. Они не отвечают на вопрос, что делать с дублем товара, как рассчитывать доступный остаток или кто имеет право менять цену. Эти правила определяются до кода.
Остатки: место, где чаще всего появляются реальные потери
С остатками опасно работать как с одной цифрой. Физически на складе может быть 10 единиц, но часть уже зарезервирована, часть забракована, а часть выделена под другой канал продаж.
Для сайта лучше передавать доступный к продаже остаток, а не просто число из складской ячейки. Если сайт, маркетплейсы и менеджеры продают один и тот же товар, резервирование должно быть частью общей логики.
- когда создаётся резерв — при оформлении или после оплаты;
- сколько живёт резерв неоплаченного заказа;
- что происходит при отмене;
- как восстанавливается остаток после возврата;
- какие склады участвуют в интернет-продажах;
- нужен ли страховой буфер.
Заказы: передать недостаточно, нужно договориться о жизненном цикле
Типичная схема «сайт создал заказ — 1С его получила» решает только первый шаг. Дальше появляются статусы, частичная оплата, отмена, возврат, замена позиции, изменение доставки.
| Событие | Что нужно определить |
|---|---|
| Новый заказ | Когда он уходит в 1С и с каким номером |
| Оплата | Как подтверждение оплаты попадает в учёт |
| Изменение состава | Кто имеет право менять заказ после создания |
| Отмена | Какая система инициирует и как снимается резерв |
| Отгрузка | Возвращается ли статус на сайт |
| Возврат | Как меняются документы и остатки |
Если на сайте есть личный кабинет, статусы становятся пользовательской функцией. Показывать внутренние статусы 1С напрямую обычно не стоит: клиенту понятнее «Заказ принят», «Собираем», «Передан в доставку», чем внутренние коды компании.
Идентификаторы: скучная тема, которая спасает обмен
У каждой сущности должен быть стабильный идентификатор. Нельзя сопоставлять товары только по названию: «Профнастил С21 0,45 мм» легко переименовать, а товар останется тем же.
- внутренний ID 1С;
- артикул / SKU;
- характеристика или торговое предложение;
- штрихкод, если он участвует в процессе;
- ID товара в CMS.
Таблица соответствий особенно важна при миграции старого сайта, где артикулы уже использовались нестрого. До запуска обмена лучше один раз очистить номенклатуру, чем потом исправлять сотни ошибочных связей.
Что происходит, если 1С или сайт недоступны
Интеграция проектируется не только для успешного сценария. Сервер может быть недоступен, XML — повреждён, товар — не найден, API — вернуть ошибку. Если система просто молча прекращает обмен, бизнес узнаёт об этом по звонку клиента.
- вести журнал операций;
- не считать обмен успешным до подтверждения;
- повторять безопасные операции автоматически;
- уведомлять ответственного после нескольких неудач;
- не создавать заказ повторно при повторном запросе;
- фиксировать конфликт данных, а не перезаписывать его молча.
Интеграция без логов удобна ровно до первого сбоя. После него начинается расследование по косвенным признакам: «вчера цена вроде была правильной».
Как проходит внедрение
- Аудит текущих систем. Версии 1С и CMS, структура каталога, склады, заказы, текущие выгрузки.
- Карта данных. Какие сущности и поля передаются, кто является владельцем.
- Сценарии ошибок. Дубли, пропуски, недоступность, повторная отправка.
- Тестовый обмен. Ограниченный набор товаров и заказов.
- Проверка пограничных случаев. Последний товар, нулевая цена, отмена, возврат.
- Пакетный запуск. Массовая загрузка и сверка.
- Мониторинг. Контроль после реальных заказов.
Если сайт уже работает, интеграцию можно реализовать как отдельную доработку. Необязательно пересобирать весь проект, если техническая база позволяет подключить обмен. На странице интеграций JustBusiness мы отдельно описываем работу с CRM, 1С, API, оплатой и другими системами.
Реальный пример: B2B-каталог с 1С
В проекте производственной компании мы разработали B2B-каталог стройматериалов на WordPress и WooCommerce. Каталог и цены синхронизируются с 1С, а стоимость позиции пересчитывается на сервере по параметрам товара.
Здесь интеграция была частью бизнес-логики, а не отдельной кнопкой. Пользователь выбирает характеристики, получает расчёт, собирает подборку и может сформировать PDF-смету. Если бы сайт и 1С жили как две независимые базы, такой каталог быстро начал бы расходиться по ценам и данным.
Что подготовить до обращения
- какая конфигурация 1С используется;
- какая CMS у сайта;
- какие данные нужно передавать;
- в каком направлении идёт каждый тип данных;
- сколько товаров и заказов;
- есть ли несколько складов и типов цен;
- как сейчас создаются заказы;
- есть ли пример выгрузки или API-документация;
- какие ошибки считаются критичными.
Этого уже достаточно, чтобы начать технический разбор. Подробное ТЗ можно сформировать вместе после изучения систем.
Частые вопросы
Можно ли интегрировать с 1С сайт не на 1С-Битрикс?
Да. 1С поддерживает обмен с разными CMS, а при нестандартных сценариях можно использовать CommerceML, API или промежуточный слой. Выбор зависит от структуры данных и требований.
Что обычно передают из 1С на сайт?
Чаще всего номенклатуру, характеристики, цены и доступные остатки. В некоторых проектах также передаются документы, статусы и персональные условия.
Можно ли передавать заказы с сайта в 1С?
Да. Это один из типовых сценариев. Нужно заранее определить момент передачи, идентификаторы, статусы и правила изменения заказа.
Нужно ли делать двустороннюю синхронизацию всех полей?
Нет. Чем больше двусторонних полей, тем выше риск конфликтов. Лучше назначить владельца каждому типу данных.
Как часто можно обновлять остатки?
Зависит от объёма каталога, частоты продаж и способа обмена. Для части проектов достаточно расписания, для ходовых товаров нужен более оперативный обмен и резервирование.
Сколько стоит интеграция с 1С?
Цена зависит от CMS, конфигурации 1С, количества сущностей, направлений обмена, готовности стандартного модуля и сценариев ошибок. Простую выгрузку и двустороннюю B2B-интеграцию нельзя оценивать одинаково.
Можно ли сначала запустить сайт, а 1С подключить позже?
Можно, но лучше заранее заложить идентификаторы и структуру данных. Иначе после наполнения каталога придётся заново сопоставлять товары и варианты.
Итог
Интеграция сайта с 1С — это проект про ответственность за данные. Технический протокол важен, но ещё важнее договориться, где живут товары, цены, остатки и заказы, как разрешаются конфликты и что происходит при сбое.
Если сейчас сотрудники вручную переносят данные между сайтом и 1С или вы планируете новый каталог, лучше разобрать схему до разработки. Это тот случай, где несколько часов проектирования легко экономят недели исправлений после запуска.
