Как связать сайт, CRM и 1С: какие данные должны передаваться между системами
В проекте интеграции сначала нужно распределить ответственность за данные. Где хранится правильная цена, кто подтверждает оплату, какая система считает доступный остаток и откуда клиент получает статус доставки. После этих решений можно выбирать модуль обмена и оценивать доработки.
Содержание статьи
Одна цена, несколько копий
Представим условный магазин: сотрудник обновил цену в 1С, менеджер сделал персональную скидку в CRM, а сайт сохранил старую стоимость. Каждая система по отдельности работает. Ошибка возникает при обмене: непонятно, какое значение должно заменить остальные и относится ли скидка к товару вообще или только к этому заказу.
Поэтому для каждого поля назначьте систему, в которой его разрешено менять. Остальные получают копию или передают запрос на изменение. Это рабочее правило проекта, которое стоит записать в таблице. Возможность технически отправить данные в обе стороны еще не отвечает на вопрос, кто имеет последнее слово.
В проекте THE U мы связали два интернет-магазина с RetailCRM и 1С. Продажи шли в рублях, долларах и дирхамах. Здесь цена без валюты теряет смысл, а одинаковое название товара еще не гарантирует одинаковые условия продажи. Опубликованный пример подтверждает состав связки; он не заменяет обследование другого магазина и его учетной базы.
Составьте карту обмена по объектам
Ниже условная схема для магазина, где 1С ведет товарный учет, CRM помогает обрабатывать заказы, а сайт принимает покупки. В вашей компании обязанности могут распределяться иначе. Таблица нужна для обсуждения этих различий.
| Объект | Что передавать | Кто отвечает в условной схеме |
|---|---|---|
| Товар и его вариант | Постоянный идентификатор, артикул, размер, цвет, единица измерения | 1С ведет справочник; сайт дополняет описание и фотографии |
| Цена | Сумма, валюта, тип цены, срок действия | 1С задает базовую цену; скидка заказа хранится отдельно |
| Остаток | Склад, доступное количество, резерв, время обновления | Учетная система рассчитывает доступность по принятому правилу |
| Заказ | Номер и источник, состав, количество, стоимость, доставка, клиент | Сайт создает; CRM обрабатывает; 1С принимает согласованные данные |
| Оплата | Идентификатор операции, сумма, валюта, состояние | Подтвержденные данные платежного или учетного сервиса поступают в CRM |
| Отгрузка и возврат | Документ, состав, количество, дата, связанный заказ | Складской учет передает факты исполнения и возврата |
| Коммуникация | Контакт, нужный язык, история обращения, состояние подписки | CRM хранит данные для работы с клиентом |
Таблицу можно прокрутить вправо
Для каждой строки добавьте частоту обмена и ответственного за ошибки. Остаткам может требоваться более частое обновление, чем описаниям. Допустимую задержку определяют по скорости продаж и последствиям ошибки. Обещание «все синхронизируется мгновенно» без проверки платформ, нагрузки и режима обмена ничего не объясняет.
Уточните и состав заказа. Стоимость доставки, скидку на отдельную позицию и скидку на заказ нужно переносить по согласованным правилам. Иначе общая сумма совпадет, но после частичного возврата расчеты разойдутся. Для нескольких валют сохраняйте валюту операции отдельно от суммы в управленческом отчете.
Сначала сопоставьте товары и клиентов
Названия меняются: редактор поправляет карточку, закупщик сокращает описание, на сайте появляется перевод. Для связи записей используйте постоянные идентификаторы и таблицу соответствий между системами. Отдельный размер или цвет должен находить именно свое торговое предложение. Это стоит проверить до загрузки заказов.
Порядок имеет практическое значение. В инструкции RetailCRM для 1С:Розницы 2.3 выгрузка остатков следует после каталога, а корректная загрузка заказов требует каталога или сопоставления товаров. Это пример конкретного модуля. У другой конфигурации условия нужно проверять отдельно.
С клиентами задача сложнее. Покупатель может сменить почту, оформить заказ с другого телефона или купить подарок на чужой адрес. Получатель заказа и покупатель могут быть разными людьми. Заранее опишите, какие признаки связывают записи автоматически, а какие случаи попадают на ручную проверку. Перед общей загрузкой сохраните исходные данные и выполните пробный перенос.
Разделите оплату, заказ и доставку
Один общий статус «Завершен» скрывает несколько событий. Товар могли оплатить, но еще не отгрузить. Курьер мог вернуть посылку после частичной выдачи. Для такого заказа нужны отдельные состояния оплаты и исполнения, а иногда статусы отдельных позиций.
Составьте таблицу переходов: какое событие произошло, какая система его подтвердила, какие поля меняются и что получает клиент. Менеджер должен понимать разницу между запросом на возврат и фактически выполненной операцией. Перемещение карточки по воронке само по себе не должно создавать неподтвержденный факт движения денег.
Уведомления проверяйте отдельно от статусов. В документации RetailCRM описан случай, когда трек-номер появляется позже смены статуса заказа. Отправка письма только по смене статуса может оставить клиента без номера. Условие такого сообщения стоит связывать с появлением нужных данных.
Договоритесь, что произойдет при сбое
В задании на обмен предусмотрите повторную передачу одного события. Система должна распознать уже обработанный заказ или платеж и не создавать вторую запись. Для этого разработчик использует постоянные идентификаторы и сохраняет результат обработки. Конкретный способ зависит от доступных интерфейсов систем.
Добавьте журнал ошибок с понятным владельцем. В нем нужны объект, время попытки, направление передачи и причина отказа. Менеджеру полезен список заказов, требующих вмешательства; техническому специалисту нужны подробности для диагностики. Пароли и лишние клиентские данные в таком журнале не нужны.
Если связь пропала, сайт может продолжить прием заказов по последнему известному остатку. Для магазина с редкими товарами это существенный риск. Решите заранее, когда показывать ограничение, как остановить продажу спорной позиции и кто связывается с покупателем. После восстановления обмена необходимо сверить пропущенный период.
Принимайте интеграцию на реальных сценариях
Проверка одной успешной покупки оставляет слишком много неизвестного. Для приемки соберите небольшой каталог и тестовые заказы с разными условиями.
- Один товар с несколькими вариантами правильно сопоставляется во всех системах.
- Повторная отправка заказа сохраняет единственную запись и ее номер.
- Персональная скидка переживает обмен и не меняет базовую цену товара.
- Частичная оплата и отмена передаются с верными суммами и состояниями.
- Возврат части покупки меняет нужные позиции без отмены оставшейся отгрузки.
- Временно недоступная система получает пропущенные изменения после восстановления связи.
- Суммы, валюты и количество товаров сходятся при контрольной сверке.
Сверку полезно сохранить и после запуска: сравнивать число заказов, состав и суммы за одинаковый период, отдельно разбирать исключения. Успешный ответ сервера подтверждает передачу сообщения. Содержимое заказа все равно должно совпасть с ожидаемым результатом.
Перед оценкой бюджета запишите версии платформы и конфигурации 1С, доработки базы и название модуля. В открытом репозитории RetailCRM указано, что с апреля 2025 года сопровождение модулей передано партнерам, дальнейшее развитие опубликованной реализации не планируется. Поэтому доступный архив сам по себе не подтверждает поддержку вашей версии.
Для обсуждения разработки и интеграций подготовьте карту обмена и два проблемных заказа без лишних персональных данных. Если сама последовательность работы еще спорная, сначала пригодится подготовка к внедрению CRM. Признаки ошибок на стороне обработки собраны в статье о потерях заказов интернет-магазина.