Вернуться к статьям При одновременной работе сайта, 1С и CRM одна и та же цифра может иметь три разные версии. Особенно опасны цена, остаток и статус: ошибка в них меняет ожидание клиента, а разбор начинается уже после заказа. Техническая связка не решает вопроса о владельце данных сама по себе.
Ниже собрана схема, по которой команда фиксирует источник записи, направление обмена и поведение при конфликте. Она подходит для подготовки требований и приёмки, но не заменяет настройку конкретной учётной системы.
Начните с матрицы владения данными
Когда сайт получает данные и из 1С, и из CRM, главным риском становится не сам обмен, а два владельца одного поля. Цена, остаток, статус заказа и контакт клиента могут обновляться в разное время и по разным правилам. Для каждого объекта составляют матрицу: где запись создаётся, какая система изменяет её первой, куда идут копии, какая задержка допустима и что делать при конфликте. Формулировка «синхронизировать всё» такой матрицей не заменяется.
Отделите коммерческий каталог от работы с обращением
В 1С обычно ведут номенклатуру, условия учёта и доступные остатки. Сайт показывает утверждённую витрину, а CRM хранит историю коммуникаций, ответственного и этап обработки запроса. Конкретное распределение зависит от процесса, но его нужно согласовать до разработки. Если цена зависит от договора, региона или объёма, публичная карточка не должна выдавать устаревшую цифру. Вариантами могут быть диапазон, запрос условий или авторизованная цена, но правило задаёт бизнес-владелец.
Опишите поток статусов
Статус обращения на сайте, статус сделки в CRM и статус заказа в 1С — не обязательно одно и то же. Попытка склеить все статусы в одну линейку обычно создаёт ложные переходы и мешает сотрудникам работать. Полезнее описать события: заявка принята, менеджер запросил данные, заказ подтверждён, отгрузка отражена в учёте. Для каждого события указывают систему-источник и то, что увидит клиент в кабинете или письме.
Учтите задержки и ошибки
Обмен по расписанию не даёт мгновенного обновления. На сайте нужно честно определить, где пользователь видит остаток на момент выгрузки, а где получает подтверждение от менеджера. В журнале интеграции должны быть идентификатор объекта, время, направление, результат и текст технической ошибки без персональных данных. Ручная правка в целевой системе требует отдельного правила, иначе следующая выгрузка перезапишет её.
Примите интеграцию на данных, которые можно проверить
Тестовый набор включает новый товар, изменение цены, нулевой остаток, удалённую позицию, повторный обмен и заказ с несколькими товарами. Для каждого случая команда заранее знает ожидаемый результат в трёх системах. Приёмка также проверяет права: редактор сайта не должен менять учётные остатки, а менеджер CRM — публиковать технические характеристики без утверждённого процесса.
Приёмочный чек-лист
- Для цены, остатка и статуса назначен один владелец, а правила записи из других систем задокументированы.
- В тесте на изменение цены, нулевой остаток и повторный обмен известен ожидаемый результат в 1С, на сайте и в CRM.
- Сопоставление строится на устойчивом идентификаторе, а не на названии товара, e-mail или свободном тексте.
- Для ручной правки определено, разрешена ли она и что произойдёт с записью при следующем обмене.
- Журнал обмена позволяет найти направление, время и техническую причину ошибки без вывода персональных данных.
Матрицу владения стоит хранить рядом с технической документацией и пересматривать при изменении учётной политики или ассортимента. В ней особенно важны идентификаторы: артикул, ID варианта, договор, контрагент и заказ. Если системы связывают записи по названию или почте без устойчивого ключа, обмен начнёт создавать дубли после первой же правки справочника. Отдельная проверка сопоставления идентификаторов экономит больше времени, чем ускорение выгрузки.
Часто задаваемые вопросы
- Можно ли сделать CRM источником цен?
Можно, если цены действительно поддерживаются в CRM и учётный процесс не требует другого источника. Решение фиксируют в матрице владения, включая порядок выгрузки и ответственного.
- Почему нельзя передавать все статусы как есть?
Системы описывают разные процессы. Статус доставки в учёте и этап переговоров в CRM имеют разный смысл, даже если названия похожи.
- Как часто обновлять остатки?
Частота зависит от допустимого расхождения, нагрузки и процесса продажи. Сначала определяют, где обещание наличия критично, затем выбирают расписание или запрос к источнику.
- Что делать при конфликте изменений?
Система-владелец должна быть определена заранее. Второе изменение либо запрещают, либо переводят в согласуемую заявку, иначе обмен будет перезаписывать данные.
- Нужен ли личный кабинет для индивидуальных цен?
Не всегда. Он оправдан, когда партнёры регулярно работают с договорными условиями и документами. Для редких запросов достаточно маршрута через менеджера.
Итог
Для связки 1С, сайта и CRM ключевым артефактом остаётся не диаграмма обмена, а матрица владения данными. С неё начинают проектирование, по ней проверяют обмен и по ней разбирают изменения после запуска.