Когда интернет-магазин только запускается, соблазн велик: товары брать напрямую из 1С, заказ сразу писать в CRM, а весь процесс собрать одной длинной цепочкой запросов
Проблема проявляется позже. Один внешний сервис отвечает медленнее обычного — и пользователь уже чувствует это на витрине. Поменялся способ загрузки каталога — приходится переделывать публичные страницы. CRM временно недоступна — оформление заказа превращается в ошибку
Ниже — схема, которую я использую в рабочем контуре РЕТОН. Это не единственно правильная архитектура, но она хорошо показывает главный принцип: публичный сайт и внешние учётные системы не обязаны быть одним монолитом
1. 1С — источник данных, но не движок витрины
В 1С Fresh хранятся товарные данные, которые нужны магазину. При этом публичный сайт не делает запрос в 1С каждый раз, когда посетитель открывает каталог
Между ними есть отдельный импорт:
1С Fresh → получение данных → нормализация → локальное представление каталога → сайт
Такой промежуточный слой решает сразу несколько задач
- временная недоступность 1С не выключает уже опубликованный каталог
- сайт получает данные в собственной понятной структуре
- правила публикации можно отделить от правил бухгалтерского учёта
- источник каталога можно заменить без переписывания всей витрины
Последний пункт особенно важен. Хороший публичный интерфейс не должен знать, пришёл товар из 1С, CMS или другой системы. Для него существует единый контракт каталога
2. Новая номенклатура не должна автоматически становиться товаром на сайте
Сам факт появления позиции в 1С ещё не означает, что её надо немедленно показывать покупателю
У товара могут отсутствовать нормальная цена, описание, изображения или понятное коммерческое название. Поэтому полезно разделить два события:
- товар появился в источнике данных
- товар готов к публикации на витрине
Между ними может быть слой правил или ручного подтверждения. Это особенно полезно, когда 1С изначально создавалась для учёта, а не как полноценная система управления содержанием сайта
3. Заказ сначала должен сохраниться, а потом путешествовать по интеграциям
Ещё одна опасная схема выглядит так:
клиент нажал «Заказать» → запрос в CRM → CRM ответила → только после этого считаем заказ созданным
В этом случае доступность CRM становится частью клиентского сценария
Надёжнее сначала создать заказ в собственном контуре магазина, получить его внутренний номер и только затем передавать данные дальше
оформление → заказ магазина → передача в CRM → дальнейшая работа менеджера
Если внешняя передача временно не прошла, у системы остаётся сам заказ и возможность повторить действие, а не просить клиента заполнить форму заново
4. CRM и магазин решают разные задачи
Bitrix24 удобен как рабочее пространство сотрудников: сделка, контакт, стадия, коммуникация, дальнейшие действия
Но это не значит, что внутренняя модель интернет-магазина должна полностью повторять модель CRM
На стороне магазина полезно сохранить свой стабильный формат заказа, а преобразование в поля конкретной CRM делать внутри интеграционного слоя
Тогда изменение CRM не требует одновременно переписывать оформление заказа, корзину и публичный интерфейс
5. Оплату и фискализацию лучше держать отдельным контуром
Платёжная система, касса, НДС, маркировка — это уже другой набор требований и состояний
Их не стоит размазывать по компонентам карточки товара. Пользовательский интерфейс должен знать, что заказ можно оплатить и какой сейчас статус, но технические детали фискализации должны оставаться в отдельной бизнес-логике
В рабочем магазине РЕТОН это особенно важно из-за маркированных товаров: одна покупка затрагивает не только платёж, но и корректную передачу данных для кассового контура
6. Что получается в итоге
Упрощённо архитектура выглядит так:
1С Fresh → слой каталога → сайт → заказ → CRM
Параллельно с заказом работают отдельные контуры:
- оплата
- фискализация
- маркировка, где она требуется
- консультация и передача оператору
- диагностика внешних интеграций
Главное преимущество здесь не в количестве технологий. Наоборот: каждая система делает свою работу и не получает лишнюю власть над остальными
Когда такой подход особенно полезен
Он имеет смысл, если у бизнеса уже есть 1С и CRM, а новый интернет-магазин должен встроиться в существующие процессы, а не заставить компанию полностью перестраивать учёт под сайт
Для маленькой витрины из пяти товаров такая архитектура может быть избыточной. Но как только появляются реальные остатки, разные источники данных, менеджеры, платежи и внешние сервисы, разделение контуров начинает окупаться просто за счёт управляемости