- какие данные передаются между сайтом и учётной системой в обе стороны;
- три способа связать системы и когда какой оправдан;
- почему «раз в сутки» ломает продажи, а «каждую минуту» кладёт 1С;
- как устроены персональные цены и скидки для оптовых клиентов;
- какие аварии случаются чаще всего и как их замечать до жалоб клиентов.
Пока в каталоге десяток позиций, сайт можно вести руками. Проблемы начинаются на сотнях и тысячах: цена в 1С поменялась, на сайте осталась старая; товар закончился, а заказы продолжают приходить; менеджер вбивает каждый заказ в учётную систему повторно. Интеграция 1С с сайтом решает именно это — синхронизирует данные, чтобы люди перестали работать копировальным аппаратом.
Интеграция 1С с сайтом: что именно обменивается
Обмен всегда двусторонний: из учётной системы на сайт идут товары, цены и остатки, обратно — заказы и данные клиентов. Направление каждого потока определяется до старта разработки.
| Данные | Направление | Как часто нужно |
|---|---|---|
| Номенклатура, характеристики, категории | 1С → сайт | При изменениях, обычно раз в сутки |
| Цены (в том числе по типам цен) | 1С → сайт | Несколько раз в день |
| Остатки по складам | 1С → сайт | Каждые 15-30 минут |
| Изображения и описания | 1С → сайт | При изменениях |
| Заказы | Сайт → 1С | Сразу после оформления |
| Данные клиента и контрагента | Сайт ↔ 1С | При заказе и регистрации |
| Статусы заказов, отгрузки | 1С → сайт | Несколько раз в день |
| Документы (счета, накладные) | 1С → сайт | По событию |
Ключевой принцип, который стоит зафиксировать до начала работ: у каждой сущности один хозяин. Номенклатура и остатки — хозяин 1С, сайт их только отображает. Заказ рождается на сайте, но дальше живёт в учётной системе. Контент — описания, фото, SEO-тексты — обычно удобнее вести на сайте, потому что в 1С для этого нет инструментов.
Нарушение этого принципа — самая частая причина боли. Если товары можно заводить и там, и там, через месяц справочники разъедутся, и никто не скажет, где правда.
Три способа связать сайт и 1С
Интеграция 1С делается одним из трёх способов: типовой обмен CommerceML, обмен через API и промежуточный сервис. Первый быстрее запускается, второй гибче, третий нужен при нескольких системах.
Типовой обмен CommerceML
Стандартный протокол обмена, поддерживаемый и 1С, и большинством CMS. Данные передаются XML-пакетами: сайт периодически запрашивает выгрузку, 1С отдаёт файл с товарами и остатками, заказы забираются обратно.
Плюсы: быстрый запуск, минимум разработки, много специалистов на рынке. Минусы: обмен идёт пакетами по расписанию, а не мгновенно; при больших каталогах выгрузки становятся тяжёлыми; нестандартные поля требуют доработки с обеих сторон.
Подходит: интернет-магазинам со стандартной структурой каталога, особенно на 1С-Битрикс, где обмен реализован из коробки.
Обмен через API
Системы общаются напрямую: сайт запрашивает у 1С конкретные данные, 1С отправляет события при изменениях. Обмен становится точечным — обновилась одна цена, передалась одна цена, а не весь каталог.
Плюсы: скорость, гибкость, экономия ресурсов при больших объёмах. Минусы: требует разработки на обеих сторонах и грамотной обработки ошибок — если сервис недоступен, данные нельзя просто «потерять».
Подходит: B2B-порталам, личным кабинетам, каталогам от десятков тысяч позиций, проектам с персональными ценами.
Промежуточный сервис (шина)
Между 1С и сайтом ставится отдельный слой, который принимает данные, приводит их к нужному виду и раздаёт потребителям. Оправдан, когда систем больше двух: например, 1С, сайт, маркетплейсы и мобильное приложение.
Плюсы: каждая система знает только про шину, изменения не ломают всё разом. Минусы: ещё один компонент, который нужно поддерживать.
Частота обмена: почему это важнее, чем кажется
Слишком редкий обмен приводит к заказам несуществующего товара, слишком частый — к нагрузке, из-за которой 1С тормозит у бухгалтерии. Разные данные требуют разной частоты.
Разумная схема выглядит так:
- Остатки — каждые 15-30 минут. Это компромисс между актуальностью и нагрузкой. В нишах с быстрым оборотом — чаще, но тогда лучше через API и только по изменившимся позициям.
- Цены — несколько раз в день или по событию изменения. Цена меняется реже остатка, но её неактуальность бьёт больнее: клиент видит одно, а в счёте другое.
- Каталог целиком — раз в сутки, ночью. Полная выгрузка тяжёлая, днём она мешает работе учётной системы.
- Заказы — немедленно. Задержка здесь означает, что менеджер узнаёт о заказе позже клиента, который уже звонит.
Отдельно про нагрузку: полная выгрузка каталога на десятки тысяч позиций может занимать минуты и заметно нагружать сервер 1С. Если бухгалтерия в это время формирует отчётность, страдают все. Поэтому тяжёлые операции ставят на ночь, а днём гоняют только изменения.
Персональные цены и скидки для B2B
Интеграция 1С в опте усложняется тем, что у каждого контрагента своя цена, и логика её расчёта должна жить в 1С, а не дублироваться на сайте. Сайт запрашивает цену для конкретного клиента и показывает её.
Как это устроено на практике:
- Клиент авторизуется в личном кабинете — сайт знает, какому контрагенту в 1С он соответствует.
- При отображении каталога сайт запрашивает цены для этого контрагента: его тип цен, скидочную группу, индивидуальные соглашения.
- Цены кешируются на короткое время, чтобы каталог не тормозил.
- При оформлении заказа цена ещё раз проверяется — на случай, если она изменилась, пока клиент собирал корзину.
Типичная ошибка — попытка перенести всю логику скидок на сайт. Она живёт в учётной системе не случайно: там договоры, история закупок, лимиты и отсрочки. Дублирование правил приводит к расхождениям, которые обнаруживает клиент, а не вы.
Если помимо цен нужны отгрузочные документы, лимиты кредита и история заказов, речь идёт уже не про интернет-магазин, а про B2B-портал — с личным кабинетом контрагента и полноценным обменом с учётной системой. Похожая логика была в нашем проекте B2B-портала производителя стройматериалов.
Битрикс и 1С: почему «из коробки» работает не всегда
Штатный обмен закрывает типовой каталог и стандартные заказы. Как только появляются нестандартные характеристики, несколько складов или своя логика цен, начинается доработка.
Коробочный обмен рассчитан на типовую модель данных. Расхождения начинаются, когда:
- у товара нестандартные свойства — например, размерная сетка, кратность упаковки, характеристики, которых нет в типовой конфигурации;
- складов несколько, и нужно показывать наличие по каждому или считать доступность с учётом резервов;
- цены зависят от объёма или договора, а не задаются одним типом цен;
- конфигурация 1С самописная или сильно доработанная — а таких большинство.
Это не значит, что коробка плоха: она экономит время на старте. Но закладывать в план нужно этап доработки обмена под вашу конфигурацию, а не рассчитывать, что всё заведётся за день. Подробнее про сайты на этой платформе — на странице разработки на 1С-Битрикс.
Типичные аварии и как их замечать
Интеграция 1С ломается тихо: сайт продолжает работать со старыми данными, и об этом узнают от клиента. Нужен мониторинг, а не вера в то, что «всё настроено».
Дубли номенклатуры
Возникают, когда сопоставление идёт по названию, а не по уникальному коду. Меняется название — создаётся новая карточка, старая остаётся с остатками. Лечится связкой по внутреннему идентификатору 1С.
Расхождение единиц измерения
Классика: в 1С товар в упаковках, на сайте в штуках. Клиент заказывает 10, получает 10 упаковок по 12 штук. Кратность и единицы фиксируются в обмене явно.
Отвалившийся обмен
Истёк пароль, сменился адрес сервера, обновилась конфигурация — обмен перестал проходить. Сайт при этом выглядит нормально: товары на месте, просто данные вчерашние. Через неделю выясняется, что половина заказов — на отсутствующий товар.
Защита простая: мониторинг времени последнего успешного обмена. Если он не проходил дольше заданного порога, ответственный получает уведомление. Это дешевле любых разбирательств с клиентами.
Частичная выгрузка
Обмен прошёл, но передалась половина позиций — например, из-за таймаута на большом каталоге. Внешне ошибки нет. Помогает контроль количества: если число активных товаров резко изменилось, это повод для проверки.
Заказы, потерянные при недоступности 1С
Учётную систему перезагрузили, а заказ в этот момент оформлялся. Правильное поведение сайта — принять заказ, сохранить у себя и отправить в 1С позже, при восстановлении связи. Заказ никогда не должен теряться из-за недоступности внешней системы.
Чек-лист перед стартом интеграции
Половина проекта решается до написания кода: на бумаге фиксируются состав данных, хозяева сущностей, частота обмена и поведение при сбоях.
- Перечень данных и направление по каждой сущности — таблица из первого раздела, заполненная под ваш проект.
- Хозяин каждой сущности. Где заводится товар, где меняется цена, где живёт описание.
- Правило сопоставления. По какому полю связываются товары и контрагенты — код 1С, артикул, GUID.
- Частота и окна обмена. Что гоняем ночью, что каждые 15 минут.
- Поведение при сбоях. Что делает сайт, если 1С недоступна: копит, повторяет, уведомляет.
- Мониторинг. Кто и как узнаёт, что обмен встал.
- Тестовый контур. Обмен проверяется на копии базы, а не на боевой — ошибка на проде стоит дороже.
- Ответственные с обеих сторон. Нужен человек, знающий вашу конфигурацию 1С, иначе проект встанет на первом же нестандартном поле.
Отдельно стоит заранее обсудить, кто дорабатывает конфигурацию 1С: обычно это ваш франчайзи или штатный специалист, и его загрузка — фактор сроков не меньший, чем работа веб-разработчика. Как мы выстраиваем такие проекты, описано в разделе разработки и автоматизации.
Частые вопросы
Сроки, доработка конфигурации, самописные базы и маркетплейсы — вопросы, с которых начинается почти каждый проект, где нужна интеграция 1С.
Сколько времени занимает интеграция?
Типовой обмен на стандартной конфигурации и типовом каталоге — недели. Проект с персональными ценами, несколькими складами и самописной конфигурацией — месяцы. Основное время уходит не на код, а на сверку данных и обработку исключений.
Придётся ли дорабатывать саму 1С?
Почти всегда — хотя бы в части выгрузки нужных полей. Полностью типовые конфигурации без доработок в реальном бизнесе встречаются редко.
А если у нас старая или самописная конфигурация?
Интеграция возможна, но её объём определяется после осмотра базы. Иногда дешевле сделать промежуточный слой, который забирает данные напрямую, чем перестраивать выгрузку внутри конфигурации.
Можно ли обойтись без обмена и вести каталог вручную?
Можно, пока позиций немного и они меняются редко. Как только счёт идёт на сотни SKU и остатки двигаются ежедневно, ручное ведение обходится дороже интеграции — и деньгами, и потерянными клиентами.
Как это связано с маркетплейсами?
Логика та же: у площадок свои форматы, и данные им нужно отдавать из того же источника. Когда каналов продаж больше двух, обычно и появляется смысл в промежуточном сервисе, о котором говорилось выше.