Интеграция интернет-магазина: данные, ошибки и приёмка обмена

Магазин, CRM и учётная система могут быть соединены, но работать несогласованно. Заказ появился дважды. Отменённая покупка продолжает держать резерв. Менеджер исправил адрес, а следующий обмен вернул старый. Такие ошибки не устраняются одной кнопкой «подключить интеграцию».

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

Выберите источник каждого вида данных

Одна система не обязана управлять всем. Товар может создаваться в 1С, описание редактироваться на сайте, а обращение покупателя обрабатываться в CRM. Главное, чтобы один обмен не затирал работу другого.

Запишите направление обмена для каждого поля. Формулировка «двусторонняя синхронизация» не отвечает на вопрос, что делать, если одно поле изменили сразу в двух системах.

Не сопоставляйте товары только по названию

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

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

Опишите обычный заказ и несколько исключений

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

• Что увидит менеджер, если заказ оплачен, но ответ от платёжного сервиса пришёл позже?
• Кто меняет доступный остаток, если последний товар купили одновременно в двух каналах?
• Можно ли редактировать заказ на сайте после передачи в CRM?
• Что происходит с резервом после отмены и кто подтверждает это изменение?

Ответы должны соответствовать вашей работе, а не выдуманному идеальному процессу. Если сотрудники сегодня исправляют заказы вручную, нужно учесть это до запуска обмена.

Сбой должен быть заметен и исправим

Внешний сервис может временно не отвечать. Обсудите повтор передачи, журнал ошибок и уведомление ответственному сотруднику. В журнале должно быть достаточно сведений для поиска сбоя, но не нужно бесконтрольно сохранять пароли и персональные данные.

Повтор того же события не должен создавать второй заказ. Для этого нужна проверка идентификаторов и повторяемости операции. При восстановлении связи важно передать накопившиеся изменения, а не только новые события.

Принимайте обмен на контрольных примерах

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

Сохраните ожидаемые и фактические результаты. Формулировка «ошибок в журнале нет» не заменяет проверку товара, суммы и статуса. Общие проверки запуска разобраны в чек-листе приёмки интернет-магазина.

Что нужно для первого обсуждения

Подготовьте ссылку на магазин, названия систем и краткую схему обработки заказа. Если обмен уже работает, укажите пример проблемы без персональных данных покупателей. Пароли и полные выгрузки для первого обращения не нужны.

IDBI разрабатывает магазины на 1С-Битрикс и InSales. Проверим доступные способы интеграции и ограничения до оценки разработки. Если задача связана именно с 1С, начните также со статьи об обмене интернет-магазина с 1С.