Сайт продаёт, 1С считает. Между ними обмен, и рвётся обычно именно он: остатки разъезжаются, заказ не доходит до учёта, после очередного обновления всё встаёт. Разбираю, как обмен устроен внутри, в каких пяти местах он ломается и что спросить у подрядчика до того, как подписывать смету.
Краткий ответ
Обмен ломается не потому, что 1С плохая, и не потому, что сайт кривой. Он ломается потому, что между ними ставят готовый модуль-прослойку, за который не отвечает ни одна из сторон. Устойчивая схема выглядит иначе: один контракт данных и две стороны, которые его соблюдают. Без третьей.
Три решения определяют всё остальное, и принимать их надо до кода:
- Кто источник правды по товарам, ценам и остаткам: сайт или 1С.
- Что едет пакетно раз в сутки, а что должно отвечать в реальном времени.
- Как система ведёт себя, когда 1С недоступна.
Если эти три пункта проговорены и записаны, интеграция становится обычной работой со сроком. Если нет, вы получаете обмен, который «вроде работает», и подрядчика, к которому надо ходить за каждой правкой.
Почему типовой обмен подводит
Первое, что предлагают почти всегда, это типовой обмен с сайтом: выгрузка XML по папкам в формате CommerceML. Механизм рабочий, но исторически он вырос из связки 1С с Битриксом и описывает ровно её сценарии. Как только магазин живёт не там, начинается натягивание: формат не знает про живой остаток перед оформлением, про резерв под конкретный заказ, про статусы, которые надо показывать покупателю. Вы платите за совместимость со стандартом, который не описывает ваш случай.
Второе. Модуль обмена это фактически третья сторона в договоре, которой в договоре нет. Когда что-то не сходится, разработчик сайта показывает на модуль, специалист по 1С показывает на модуль, а модуль предлагает обновиться до следующей версии. Ответственность размазана ровно между теми, кто не может её взять.
Третье, и самое дорогое в перспективе. Форматы обмена меняются вместе с бизнесом: добавили характеристику, завели второй склад, поменяли схему цен. Каждое такое изменение в схеме с прослойкой это платный вызов подрядчика, потому что контракт данных нигде не записан и живёт в настройках модуля.
Главный вопрос не про модуль, а про источник правды
До того, как обсуждать протоколы, ответьте на один вопрос: где хранится правда. Вариантов ровно два, и они ведут к разным проектам.
| Что сравниваем | Схема А: мастер на сайте | Схема Б: мастер в 1С |
|---|---|---|
| Где заводят товар | В админке сайта, в 1С уходит уже готовое | В 1С, сайт показывает то, что пришло |
| Кто правит контент карточки | Маркетолог, без участия учёта | Учёт, либо поля дублируются на двух сторонах |
| Что происходит при сбое обмена | Магазин продолжает торговать, учёт догоняет | Витрина замирает на последней выгрузке |
| Главный риск | Расхождение по остаткам, если не спрашивать живой | Скорость изменений на витрине упирается в учёт |
| Кому обычно подходит | Розница с активным контентом и подборками | B2B и оптовый учёт со сложной ценовой схемой |
По умолчанию я предлагаю схему А. Причина простая: витрина меняется в разы чаще, чем учётная политика, и держать скорость изменений на сайте в зависимости от очереди задач в 1С дорого. Схема Б выигрывает в одном случае, зато выигрывает крупно: если цены у вас живут по контрагентам и договорам, а не в одном прайсе, то дублировать эту логику на сайте бессмысленно, и правда должна остаться в учёте.
Ошибка, которую я вижу чаще других: вопрос не задают вообще, и система оказывается в промежуточном состоянии, где часть полей правится в 1С, часть на сайте, а при следующей выгрузке половина правок затирается. Причём выясняется это обычно на второй месяц работы, когда каталог уже наполнен.
Как выглядит обмен без прослойки
Рабочая схема делится на два контура, и делится именно потому, что у данных разная цена ошибки и разная частота изменений.
| Контур | Что едет | Как | Когда |
|---|---|---|---|
| Каталог, тяжёлый | Товары, характеристики, цены, остаток-снимок, ссылки на изображения | Выгрузка файлом на сервер | Раз в сутки, ночью |
| Операции, лёгкие | Живой остаток, резерв, снятие резерва, заказ, статус | Запросы к сервисам на стороне 1С | По событию, в момент действия покупателя |
Тяжёлое возить в реальном времени не нужно и вредно: каталог на десятки тысяч позиций положит учётную базу, если дёргать её на каждый запрос. Лёгкое возить раз в сутки нельзя: между двумя выгрузками магазин будет продавать то, чего на складе уже нет.
Когда всё это можно не делать: если товар у вас не заканчивается в течение дня, позиции штучные под заказ или склад заведомо глубже спроса, второй контур не нужен. Одной ночной выгрузки хватит, и половина написанного выше к вам не относится. Проверить просто: посмотрите, сколько раз за последний месяц вы отменяли заказ из-за того, что товара не оказалось. Если ноль, не тратьте бюджет на резерв.
Оба контура обязаны говорить на одном ключе. Ключ связи это код номенклатуры из 1С, и он должен быть один и тот же в ночной выгрузке и в оперативных запросах. Категории и группы связываются по идентификаторам, а не по названиям: названия меняет маркетолог по пятницам, идентификаторы не меняются никогда.
Пять мест, где обмен рвётся
1. Кодировка
Выгрузки из 1С регулярно приезжают в cp1251, а сайт ждёт UTF-8. На выходе кириллица превращается в мусор, и хорошо, если это видно сразу на названии товара, а не всплывает через месяц в адресе доставки. Кодировка обеих сторон фиксируется письменно до начала работ, вместе с разделителем и форматом дат.
2. Остаток из ночной выгрузки принимают за настоящий
Снимок остатка на три часа ночи это не остаток на два часа дня. Если магазин показывает доступность и принимает заказ по вчерашнему числу, вы регулярно продаёте то, чего нет, и разбираете это вручную через извинения покупателю. Живой остаток надо спрашивать в двух точках: перед показом доступности и второй раз непосредственно перед резервом.
3. Двойной резерв при обрыве связи
Классика. Сайт отправил запрос на резерв, связь оборвалась, ответа нет. Сайт повторяет, и в учёте появляется второй документ на тот же товар. Лечится тем, что ключ операции генерирует сайт и передаёт его в каждом запросе: повторный запрос с тем же ключом не создаёт второй документ, а возвращает результат первого. Требование звучит скучно, но без него любая нестабильная сеть превращается в двойные резервы и двойные заказы.
4. Категории связаны по названиям
Пока категория называется «Кресла», всё сходится. В день, когда её переименовали в «Кресла офисные», товары теряют привязку и уезжают в неразобранное. Связь строится по идентификаторам, название остаётся тем, что видит покупатель, и меняется свободно.
5. Никто не решил, что делать, когда 1С недоступна
База уходит на регламентные работы, обновление затянулось, сервер перезагрузили. Если сайт в этот момент просто получает ошибку, заказ теряется молча: покупатель видит сбой и уходит, а вы даже не знаете, что он был. Правильное поведение другое: сайт принимает заказ, кладёт операцию в очередь и повторяет её, пока учёт не ответит.
Мы проверили это правило на себе, в другом месте и довольно неприятным способом. Уведомления о заявках с нашего собственного сайта уходили в Telegram, и при сетевом сбое отправка падала вместе с обработкой заявки. Пока не появилась очередь с повторами, часть уведомлений просто не доезжала. Механика ровно та же, что и с 1С: внешняя система имеет право быть недоступной, а вот терять из-за этого заказ нельзя.
Что спросить до начала работ
Семь вопросов, которые экономят месяцы. Задавайте их обеим сторонам сразу, и подрядчику сайта, и тому, кто ведёт 1С.
- Кто источник правды по товарам, ценам и остаткам, и что происходит при конфликте правок.
- Есть ли уже выгрузка из 1С, в каком она формате и в какой кодировке.
- Опубликована ли база и можно ли обращаться к ней по сети, или доступен только обмен файлами.
- Кто пишет код на стороне 1С и в какие сроки: штатный специалист, франчайзи или подрядчик.
- Нужны ли резерв и живой остаток, или для вашей модели достаточно ночного снимка.
- Что происходит с заказом, если 1С не ответила: он теряется, встаёт в очередь или блокирует оформление.
- Где записан контракт данных и кто его хранит после сдачи проекта.
Последний вопрос самый недооценённый. Контракт данных это документ, а не настройки в чужом модуле. Если после сдачи он остаётся у вас, следующая доработка стоит часы. Если нет, она стоит нового обследования.
От чего зависят срок и цена
Универсального прайса на интеграцию с 1С не существует, и любой, кто называет цифру до разговора о вашем контуре, называет её наугад. Разброс создают четыре вещи.
- Стартовая точка. Готовая рабочая выгрузка из 1С и её отсутствие это разные проекты по объёму: в первом случае мы дорабатываем формат, во втором его сначала надо спроектировать и написать.
- Сторона 1С. Код на стороне учёта пишет специалист по 1С, и это отдельная сторона со своим графиком. Срок проекта складывается из двух очередей, а не из одной.
- Глубина оперативного контура. Ночной каталог без резерва делается заметно быстрее, чем полный цикл с живым остатком, резервом, снятием резерва и статусами заказа.
- B2B или розница. Оптовый контур тянет за собой цены по контрагентам, отсрочки, документы и права доступа. Это не надстройка над розничным магазином, а другая логика.
Мы называем фиксированную цену и срок до старта разработки, но делаем это после разбора вашего контура, а не до него. Разбор бесплатный и занимает один рабочий день.
Что у нас за этим стоит
Честно про опыт, потому что в этой теме легко изобразить больше, чем есть. Полностью пройденная миграция магазина у нас одна, и это наш собственный магазин IWANT: с InSales на свой движок на Next.js и PostgreSQL. Перевезли каталог, 3 123 заказа за 2016-2026 годы и 7 636 страниц под полным покрытием 301-редиректами, выборка из 120 адресов прошла проверку за один заход.
Каркас, о котором идёт речь выше, вырос именно оттуда: один контракт данных посередине и тонкий слой на входе под каждый источник. Проекты с 1С у нас сейчас в работе, и подавать их как закрытые кейсы я не буду. Всё, что выше, это требования к каркасу и разбор граблей, а не отчёт о сдаче.
Если у вас магазин и учёт в 1С, и обмен между ними доставляет больше хлопот, чем пользы, опишите свою ситуацию в форме ниже. Посмотрю ваш контур и скажу, что в нём чинится доработкой, а что имеет смысл переделывать.
