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