Интеграция сайта и интернет-магазина с 1С: цены, остатки и заказы

Покупатель оформляет заказ на последнюю единицу товара. На карточке есть цена, кнопка активна, деньги приняты. Через несколько минут оператор видит, что позиция уже зарезервирована под другой канал, а в 1С заказ ещё не появился. Для покупателя это отмена после оплаты. Для команды — спор о том, где искать ошибку: в сайте, учёте, складе или обмене.

Интеграция сайта с 1С начинается с правил для данных. Мы фиксируем, кто управляет ценой, какой остаток сайт вправе показать, в какой момент заказ становится документом в учёте и как система действует при повторе или задержке события. Затем выбираем транспорт и проверяем один сквозной маршрут.

Витрина показывает решение нескольких систем

Покупатель видит один товар. За ним часто стоят карточка в CMS, системе управления содержимым сайта, номенклатура и варианты фасовки в 1С, складской остаток, правила скидок, платёжный сервис и доставка. Данные меняются в разном темпе. Контент каталога может обновляться раз в день, остаток последней единицы требует более жёсткого правила, а заказ должен получить подтверждение без двусмысленности.

Сайт не обязан хранить всю учётную логику. Его задача — показывать условия продажи, которые бизнес готов исполнить. Поэтому до разработки мы отделяем физический остаток от доступного для продажи, базовую цену от промо-правила, заказ на витрине от проведённого документа. Одно поле «количество» не отвечает на вопрос, можно ли принять оплату прямо сейчас.

Этот разбор важен и для масштаба рынка. По данным Insight, в 2025 году российская розничная интернет-торговля достигла 13,4 трлн рублей, а число онлайн-заказов — 8,3 млрд. Показатели рынка не предсказывают эффект для отдельного магазина. Они объясняют, почему ошибки в данных быстро становятся операционной проблемой.

Цена: витрина фиксирует условие продажи

Первый переход маршрута — цена. 1С или другой согласованный источник передаёт значение, сайт связывает его с продаваемым вариантом, а покупатель видит условие, по которому начинает оформление. В момент изменения важно сохранить дату вступления цены в силу и правило для активной корзины. Иначе одна и та же покупка получает разные значения в карточке, платёжной форме и учётном документе.

У этого перехода есть владелец данных. Он отвечает за решение и за хранение поля. Например, 1С может быть источником номенклатуры, но редактор каталога на сайте меняет описание и фотографию. В модели тогда нужны устойчивые идентификаторы товара и варианта, а обмен обновляет только согласованный набор атрибутов. Полная выгрузка сохраняет контент редактора, а локальная правка сохраняет сопоставление с учётной позицией.

Владелец данных отвечает за решение, а не только за хранение поля. Например, 1С может быть источником номенклатуры, но редактор каталога на сайте меняет описание и фотографию. В таком случае в модели должны существовать устойчивые идентификаторы товара и варианта, а обмен обновляет только согласованный набор атрибутов. Иначе полная выгрузка способна перезаписать работу контент-команды, а локальная правка — разрушить сопоставление с учётной позицией.

Для статусов та же логика выглядит жёстче. «Оплачен», «зарезервирован», «собран» и «отгружен» описывают разные действия. Нельзя объединять их в один зелёный значок ради короткой витрины. Сайт может показывать покупателю понятный текст, но внутри нужен словарь соответствий: какой внутренний статус породил сообщение, какое событие вправе его изменить и какой переход считается ошибкой.

Резерв: последняя единица перестаёт быть общей

После цены маршрут переходит к резерву. Остаток зависит от склада, резерва, поставки в пути и правил продажи. В этот момент сайт получает ответ на вопрос: может ли конкретный покупатель оформить позицию в выбранном канале.

Мы начинаем с формулировки, которую можно проверить в интерфейсе: какой остаток доступен этому покупателю в этом канале и до какого события он считается актуальным. Для одного магазина достаточно общего доступного количества. Для нескольких складов или каналов требуется решить, суммирует ли витрина остатки, привязывает ли заказ к складу и когда резерв уменьшает доступность.

Отдельно фиксируем поведение при задержке. Допустим, 1С уже приняла документ, а сайт ещё не получил подтверждение резерва. Карточка товара не должна самостоятельно придумывать новое количество. Она действует по согласованному правилу: временно скрывает возможность купить последнюю единицу, показывает срок подтверждения или оставляет позицию доступной в пределах допустимого риска. Выбор зависит от маржи, скорости оборота, числа каналов и того, можно ли предложить замену.

Ценовые изменения также требуют момента вступления в силу. Магазину важно различать цену, которую покупатель видел в карточке, цену, с которой он начал оформление, и цену, с которой документ попал в учёт. При конфликте команда заранее определяет, какую цену подтверждает заказ и кто разбирает исключение. Это защищает и покупателя, и оператора от ситуации, где у одного заказа одновременно три правдоподобных значения.

В публичном кейсе HOTZ мы описали сквозной каталог для четырёх продуктовых линеек: интерфейс связали с 1С по ценам, остаткам, фасовкам и номенклатуре. Этот пример полезен именно как подтверждение состава данных. Сроки, бюджет и результаты другой интеграции на него переносить нельзя: модель учёта, склады и правила продажи у каждой компании различаются.

Когда правила становятся сложнее типового обмена, полезно обсудить карту интеграций для e-commerce до выбора модуля и оценки разработки. Мы разбираем контур по данным, каналам заказа и точкам, где бизнесу нужна подтверждённая доступность.

Заказ проходит один маршрут, хотя статусы меняются в нескольких контурах

Сквозной сценарий лучше начинать с одного заказа. Сайт создаёт его с внешним идентификатором и составом позиций. 1С принимает документ либо возвращает понятную причину отказа. Склад подтверждает резерв и исполнение. Сайт получает статус, который можно показать покупателю. Платёж и доставка добавляют собственные события, но не должны превращать одну покупку в несколько документов.

1. Покупатель оформляет заказ, а сайт сохраняет внешний ID и фиксирует состав.
2. Интеграционный контур передаёт операцию в 1С и получает результат обработки.
3. Учётная система подтверждает документ, резерв или ограничение, которое меняет сценарий исполнения.
4. Сайт обновляет статус для покупателя и оставляет сотруднику историю операции.
5. Повтор события сверяется с исходным ID и не создаёт второй заказ.

У этого маршрута есть два частых возражения. Первое: «у нас обмен уже работает». Один успешный запрос подтверждает канал связи, но не проверяет отмену после резерва, повторное уведомление или восстановление после паузы. Второе: «достаточно синхронизировать заказ раз в несколько минут». Такой режим подходит, когда бизнес принимает задержку. Продажа последней единицы на нескольких каналах требует отдельного правила доступности и резерва.

В результате оператор видит конкретную операцию: какой заказ остановился, на каком шаге, с каким внешним ID и что требуется для продолжения. Это сокращает время поиска причины без обещаний, что интеграция никогда не даст сбой.

Состав заказа тоже нужно считать частью контракта. Изменение количества, замена позиции, частичная отмена и возврат не всегда укладываются в одну операцию «обновить статус». Команда решает, допускает ли сайт редактирование после передачи в 1С, как связываются исходная и новая строки, какие изменения отправляются обратно покупателю. Так интеграция сохраняет историю решения, а не только его финальное состояние.

Оплата: подтверждение связывается с тем же заказом

После резерва заказ переходит к оплате. Платёжный сервис сообщает о результате, сайт сопоставляет уведомление с внешним ID, а учётный контур получает событие, которое относится к тому же составу позиций. В этом месте появляются повторы уведомлений, задержки ответов и отмены после авторизации. Для каждого случая нужен статус, который видит покупатель, и действие, которое получает оператор.

Оплата не подтверждает отгрузку. Она запускает следующий переход: проверку резерва, подготовку задания складу и передачу данных в доставку. Когда эти события сливают в один статус, сотрудники теряют момент, на котором заказ остановился. Разделённая цепочка даёт покупателю честный ответ, а команде — точку для исправления.

Отгрузка: фактическое исполнение возвращается на витрину

Склад подтверждает резерв, сборку, частичную выдачу или отмену. Сайт получает только то состояние, которое полезно покупателю: заказ принят, собирается, передан в доставку или требует уточнения. Внутренний маршрут сборщика остаётся в операционном контуре, но результат должен вернуться на витрину вместе с тем же идентификатором заказа.

На этом переходе особенно важна сверка. Она находит операции, которые появились в одном контуре и не дошли до другого: оплату без заказа, заказ без резерва, отгрузку без обновлённого статуса. Сверка не дублирует обработку. Она сопоставляет исходные идентификаторы и передаёт сотруднику только то исключение, которое требует решения.

OData, HTTP и очередь выбирают после описания событий

У 1С есть несколько способов работать с внешними системами. В документации ИТС 1С сказано, что платформа может автоматически создать REST-интерфейс OData для прикладного решения. В отдельном материале 1С перечислены веб- и HTTP-сервисы, REST/OData, JSON, XML и планы обмена. Такие механизмы задают способ передачи данных; выбор зависит от правил, которым они подчиняются.

Синхронный запрос удобен, когда сайту нужен ответ в пределах одного действия. Регламентный обмен подходит для данных с согласованной задержкой. Асинхронная доставка помогает разделить приём события и его обработку. В описании 1С решение «1С:Шина» названо вариантом гарантированной асинхронной доставки сообщений. Это пример класса решений, который не становится обязательным компонентом интернет-магазина.

Мы выбираем транспорт по ограничениям конкретного маршрута: как быстро нужно подтвердить изменение, сколько сущностей меняется одновременно, что происходит при недоступности одной системы, как распознаются повторы и кто сопровождает обмен после запуска. Такой порядок помогает не привязывать бизнес-правила к названию протокола.

Для команды это означает отдельную работу с наблюдаемостью. У каждой попытки обмена есть идентификатор, время создания, время последнего ответа, число повторов и итог. Такие записи полезны при разборе инцидента и при сверке: можно найти заказ, который принял платёжный сервис, но не получил учётный документ, или изменение цены, остановившееся до витрины. Формат журнала и срок хранения определяют требования безопасности и эксплуатации конкретной компании.

Приёмка проходит по тому же маршруту заказа

Проверка интеграции проходит по тому же пути, что и реальная покупка. Команда меняет цену в учётной системе и смотрит, когда её видит карточка. Затем доводит доступный остаток до нуля, создаёт заказ, повторно отправляет событие об оплате и отменяет операцию после резерва. Для каждого перехода заранее записывают ожидаемое состояние на сайте, документ в 1С, запись в журнале и действие сотрудника.

Отдельно воспроизводят недоступность одного контура. Операция должна попасть в журнал, повториться по согласованному правилу или перейти сотруднику. После восстановления сверка ищет пропуски и не применяет уже учтённые изменения второй раз. Так сценарий приёмки проверяет весь маршрут, а не отдельные запросы.

Журнал в этом списке нужен для действий, а не для отчётности. Сотрудник должен найти операцию, увидеть входные данные, последнюю попытку, ответ системы и следующий шаг. Полезно отдельно договориться, кто следит за такими записями после запуска и как часто команда сверяет пропущенные изменения.

Сначала фиксируем контур, затем оцениваем интеграцию

Интеграция сайта с 1С готова к оценке, когда по одному заказу можно ответить на четыре вопроса: откуда берутся цена и доступность, кто создаёт документ, как статусы возвращаются на сайт и что происходит при сбое. После этого выбор API, модуля или очереди становится инженерной задачей с измеримыми ограничениями.

Правило запуска: сначала проведите один заказ через данные, оплату, резерв и исполнение на схеме, затем переносите этот маршрут в код. Если нужно разобрать текущий обмен, расскажите нам о 1С, сайте, складах и каналах заказа. Мы поможем определить границы первого контура и проверки перед запуском.