Архитектура интеграций интернет-магазина: 1С, CRM, склад, оплата и доставка
Как спроектировать интеграции интернет-магазина с 1С, CRM, складом, оплатой и доставкой: источник данных, статусы, очереди, защита от дублей и тестирование.
Интеграции в интернет-магазине начинаются не с выбора API и не с фразы «подключите 1С». Сначала нужно договориться, где живут данные, кто имеет право их менять и как система ведёт себя, когда один из сервисов временно недоступен.
В работе над интернет-магазинами я не раз видел красивый каталог с проблемами в операционке: на сайте один остаток, на складе другой, менеджер получает два одинаковых заказа, а клиент узнаёт об отмене после оплаты. Такие сбои редко возникают из-за одной ошибки в коде. Чаще причина — интеграции проектировали по частям, без единой схемы.
Ниже — мой практический подход к архитектуре связки интернет-магазина, 1С, CRM, склада, платежей и доставки. Он подходит для запуска нового магазина и для аудита уже работающего проекта.
Сначала определяем источник правды
У одного поля должен быть один главный источник. Если цену одновременно меняют в админке магазина, 1С и CRM, расхождения неизбежны. В начале проекта я составляю таблицу владения данными.
| Данные | Основной источник | Кто изменяет | Что получает сайт |
|---|---|---|---|
| Товар, артикул, характеристики | Учётная система или PIM | Товарный отдел | Каталог и карточки |
| Цена и остаток | Учётная система | Коммерческий отдел | Актуальная витрина |
| Клиент и коммуникации | CRM | Отдел продаж | Статус и история обращения |
| Заказ | Магазин или OMS | Сайт и менеджеры | Номер, состав, статус |
| Оплата | Платёжный провайдер | Платёжная система | Подтверждённый статус |
| Доставка | Логистический сервис | Логистика | Тарифы, ПВЗ, трек-номер |
Источник правды не обязан быть одной программой для всего. Важно, чтобы у каждого объекта был хозяин. Магазин не должен перезаписывать остатки, если их ведёт 1С, а CRM не должна «догадываться» о факте оплаты без подтверждения от платёжного сервиса.
Какие потоки нужно описать до разработки
Обычно достаточно выделить пять независимых потоков:
1. Товары и категории: названия, фото, характеристики, варианты, документы.
2. Цена и наличие: обычные и акционные цены, резерв, доступность по складам.
3. Заказ: корзина, клиент, состав, доставка, скидка, комментарий.
4. Статусы: создан, оплачен, передан в сборку, отгружен, отменён, возвращён.
5. Сервисные события: ошибка синхронизации, повторная отправка, ручная корректировка.
У каждого потока должен быть формат, направление, периодичность, допустимая задержка и ответственный. Это звучит формально, но именно в этих пяти пунктах определяется жизнеспособность магазина после запуска.
Синхронный запрос или очередь: что выбрать
Не все данные нужно получать в момент действия пользователя. Я разделяю операции на две группы.
Синхронные
Пользователь ждёт ответ сразу: проверка цены, доступности способа доставки, создание платежа, подтверждение купона. Если такой запрос занимает слишком много времени, магазин должен показать понятную альтернативу, а не зависнуть.
Асинхронные
Пользователь не обязан ждать: передача заказа в CRM, обновление трек-номера, выгрузка полного каталога, отправка уведомлений, пересчёт рекомендаций. Эти операции безопаснее ставить в очередь и повторять при временной ошибке.
Практическое правило: не заставлять страницу оформления ждать ответа от каждой внешней системы. Сначала магазин надёжно фиксирует заказ у себя, присваивает уникальный идентификатор и только затем передаёт его дальше. Так клиент не нажмёт кнопку второй раз, если CRM или 1С ответят с задержкой.
Защита от дублей и потерянных заказов
Дубли появляются по вполне обычным причинам: двойной клик, нестабильная сеть, повторный callback от оплаты, повторная задача в очереди. Поэтому для заказа нужны:
- уникальный идентификатор операции;
- идемпотентный ключ для повторной передачи;
- журнал входящих и исходящих событий;
- понятное правило, что считать успешной оплатой;
- повторная доставка сообщения только до установленного лимита;
- ручной сценарий разбора исключения.
Я не советую подтверждать заказ только по возврату браузера со страницы оплаты. Надёжным источником статуса должен быть серверный callback или проверка у платёжного провайдера. Также нельзя хранить реквизиты карт в самом магазине: это зона платёжного сервиса и его защищённого интерфейса.
1С, CRM и склад: где чаще всего расходятся данные
Самые типичные конфликты выглядят так:
| Симптом | Частая причина | Что заложить в архитектуру |
|---|---|---|
| На сайте товар есть, а на складе нет | Задержка обмена или неверный резерв | Время обновления, правила резерва, мониторинг |
| Заказ не виден менеджеру | Неверное сопоставление полей или сбой очереди | Логи, повторная отправка, уведомление об ошибке |
| В CRM два заказа | Повторный запрос без идемпотентности | Уникальный ключ операции |
| Цена в рекламе отличается от сайта | Разные выгрузки и расписания | Единый прайс-источник и контроль даты обновления |
| Статус доставки не меняется | Не получен webhook или трек-номер | Периодическая сверка и ручной fallback |
Связка с 1С не сводится к «выгрузить XML ночью». Платформа поддерживает веб-сервисы и может быть поставщиком или потребителем сервисов; конкретный способ зависит от конфигурации, нагрузки и политики доступа. Сначала описывается бизнес-процесс, затем выбирается обмен.
Оплата, доставка и онлайн-касса — отдельные контуры
Платёж, отгрузка и фискализация имеют разные статусы. Успешная авторизация платежа не всегда означает, что товар уже отгружен; создание накладной не означает, что клиент получил посылку.
В ТЗ интеграции нужно явно зафиксировать:
- какие статусы платежа принимает магазин;
- что происходит при отмене или частичном возврате;
- когда создаётся чек;
- как выбираются тарифы и пункты выдачи;
- где хранится трек-номер;
- кто инициирует возврат денег;
- как статусы отображаются покупателю и менеджеру.
Для мультискладского бизнеса полезно сразу определить правило выбора склада: ближайший, приоритетный, с полным остатком или вручную назначаемый. Иначе эта логика появится стихийно в нескольких системах.
Логирование и мониторинг: без них интеграция неуправляема
«Интеграция работает» — недостаточный статус. Мне важно видеть:
- когда последний раз обновлялись цены и остатки;
- сколько заказов ждёт передачи;
- какие запросы завершились ошибкой;
- сколько раз задача повторялась;
- совпадают ли данные сайта и учётной системы;
- какие внешние API отвечают медленно.
В логе не должно быть паролей, токенов и платёжных данных. Для расследования достаточно идентификатора заказа, времени, направления обмена, кода ответа и безопасного текста ошибки. Без такого журнала любая ошибка превращается в ручной поиск между несколькими кабинетами.
Безопасность API тоже должна быть частью проекта: разграничение прав, ограничение запросов, проверка входящих webhook, ротация ключей и отказ от передачи секретов в URL. Для базовой оценки рисков можно опираться на рекомендации OWASP по безопасности API.
Как тестировать интеграции перед запуском
Я провожу тестирование не только «по счастливому пути». В минимальный набор включаю:
1. Заказ одного товара с успешной оплатой.
2. Заказ с несколькими вариантами, скидкой и доставкой.
3. Повторную отправку одного события.
4. Недоступность CRM, 1С или службы доставки.
5. Отмену и возврат.
6. Обновление цены и остатка.
7. Одновременное оформление нескольких заказов на последний остаток.
8. Ручную корректировку заказа менеджером.
Для каждого сценария заранее определяется ожидаемый результат: где появится заказ, какой статус увидит клиент, кто получит уведомление и что останется в журнале. Такой подход резко снижает риск «тихих» потерь данных после запуска.
Как связать архитектуру интеграций с SEO и продажами
Интеграции напрямую влияют на качество каталога: цена, наличие, варианты, характеристики и доставка должны совпадать на карточке, в фиде и в учётной системе. Когда данные расходятся, страдает не только конверсия — поисковые сервисы и рекламные площадки тоже могут видеть противоречивую информацию.
Чтобы каталог оставался технически понятным для поиска, рекомендую отдельно пройти SEO-структуру каталога, а для требований к запуску использовать материал «Техническое задание на интернет-магазин». Это соседние, но разные задачи: первая статья — про видимость и архитектуру страниц, вторая — про состав проекта, а эта — про надёжный обмен данными.
Чек-лист перед запуском
- У каждого типа данных назначен источник правды.
- Заказ имеет уникальный идентификатор и защиту от дублей.
- Описаны статусы оплаты, отгрузки, отмены и возврата.
- Есть очередь или механизм повторной передачи для внешних систем.
- Ошибки логируются без секретных данных.
- Настроены уведомления об остановке обмена.
- Проверены сценарии сбоя и ручной обработки.
- Данные сайта, фида и учётной системы сверяются по расписанию.
Если в проекте есть 1С, CRM, несколько складов, персональные цены или нестандартная логистика, архитектуру стоит обсудить до дизайна и разработки. Это заметно дешевле, чем исправлять потерянные заказы и расхождения после запуска.
Обсудить разработку интернет-магазина
Официальные источники
1С:Предприятие — веб-сервисы и интеграция