WooCommerce и Битрикс24: как передавать изменения заказа и частичный возврат
Создать сделку при покупке недостаточно: состав заказа меняется, платёж подтверждается отдельно, часть товара возвращают. Разбираем модель обмена, которая сохраняет эти различия.
Покупатель заказал две позиции на WordPress, затем отказался от одной. В WooCommerce заказ изменили и оформили частичный возврат, а в Битрикс24 остались первоначальные товары и сумма. Менеджер видит успешную продажу целиком и собирается отправить весь заказ. Передача первой заявки работала, но дальнейшая жизнь заказа осталась за пределами интеграции.
Рассмотрим предлагаемую модель для WooCommerce и сделки Битрикс24. В ней магазин хранит заказ и его коммерческие изменения, CRM помогает менеджеру вести обслуживание, а платёжные факты поступают из выбранного подтверждённого источника. Это проектная схема: готовый плагин может поддерживать только часть перечисленных действий.
Один и тот же телефон не связывает заказ со сделкой достаточно надёжно. У покупателя могут быть несколько покупок, а у компании — общий номер. Нужна постоянная пара идентификаторов: магазин и ID заказа с одной стороны, портал и ID сделки с другой. Для товарной строки сохраняют её собственный ID, а также товар и вариацию.
Товар с размером M и такой же товар с размером L — разные варианты исполнения. Если передать только название, менеджер не узнает, что резервировать. Артикул полезен для сопоставления каталогов, но его заполненность и уникальность нужно проверить отдельно. Нельзя считать номер позиции в массиве постоянным идентификатором: после удаления строки порядок изменится.
Зафиксируйте владельца каждого поля. Если цены и скидки рассчитывает магазин, менеджер не должен исправлять их в CRM без обратного согласованного процесса. Комментарий менеджера о звонке, напротив, не следует стирать очередной выгрузкой магазина. Для конфликтов нужна определённая политика, а не правило «последний записавший прав».
Объект
Что сохранять для связи
Что сверять
Заказ
Магазин, ID заказа, ID сделки
Валюта, сумма, состояние
Товарная строка
ID строки, товар, вариация
Количество, цена, скидка
Возврат
ID возврата и связь с заказом
Сумма, позиции, причина
Доставка
Выбранный способ и связанные данные
Стоимость и состояние исполнения
Это внутренняя карта обмена, а не перечень параметров REST API. Конкретные поля выбирают по используемым версиям и подключённым модулям магазина.
В документации WooCommerce о вебхуках описаны уведомления о событиях магазина и журнал их доставки. Вебхук полезен как сигнал проверить изменение. Сам по себе факт его отправки не подтверждает обновление CRM.
Приёмник проверяет подлинность уведомления выбранным для WooCommerce способом, сохраняет его в журнал и назначает обработку. В журнале нужны заказ, тип изменения, момент получения и состояние переноса. Полные платёжные реквизиты и лишние персональные сведения не должны попадать в технический лог.
Внешние уведомления могут пересекаться с повторным чтением заказа. Поэтому обработчик должен уметь применить одно состояние без второго создания сделки. Если более старый снимок пришёл после нового, он не должен вернуть удалённую позицию или прежний адрес доставки. При сомнении перечитайте текущее состояние заказа и сравните его с последней принятой редакцией.
В Битрикс24 есть универсальный метод сохранения товарных позиций CRM . Перед использованием нужно проверить его актуальные параметры и поведение для выбранного объекта. Для нового обмена также важно учитывать статус устаревших методов, а не брать первый найденный пример из старой инструкции.
Практическая задача шире вызова метода. Решите, является ли товарный состав в CRM точной проекцией магазина или содержит собственные дополнительные строки. В первом случае можно формировать согласованный полный состав из магазина. Во втором нужны устойчивые связи строк и правила сохранения добавлений менеджера. Иначе очередная синхронизация удалит ручную услугу монтажа либо размножит существующие позиции.
Сумму заказа сверяйте вместе с валютой, доставкой, скидками и налоговым представлением. Разность между итогом магазина и суммой строк CRM не следует автоматически «исправлять» скрытой дополнительной позицией. Сначала установите причину: разные правила округления, неучтённая доставка или неправильный перенос скидки.
Учебный пример: заказ содержит два изделия по 3 000 рублей и доставку за 500 рублей. Первоначальный итог — 6 500 рублей. Покупатель возвращает одно изделие, сумма подтверждённого возврата — 3 000 рублей, доставку не возвращают. Чистая сумма платежей после этой операции составляет 3 500 рублей. Ставить всей сделке состояние «возвращено» без пояснения будет неточно.
Храните исходный состав покупки и отдельный факт возврата. У возврата есть связь с заказом, сумма, строки при наличии и состояние исполнения. Запрос на возврат, оформленный документ и фактическое движение денег могут наступить в разное время. Какая система подтверждает каждый факт, нужно решить до настройки статусов.
Для менеджера полезны отдельные показатели: заказано, подтверждено платежами, возвращено, требуется действие. Стадия продажи не заменяет эти суммы. Сходный принцип разбирается в материале о частичных платежах и возвратах из 1С , но источник операций и структура заказа здесь другие.
Подготовьте заказ с вариацией товара, скидкой и платной доставкой. Измените количество, удалите строку, поменяйте адрес до отгрузки, оформите частичный возврат. Отправьте одно уведомление повторно и временно остановите доступ к CRM. Проверяйте каждый раз карточку, товары и журнал связей.
После восстановления обработка должна продолжиться с невыполненного шага. Если карточка создана, а товары ещё не записаны, повторное создание сделки не требуется. Отдельно согласуйте, что произойдёт с заказом, который менеджер уже передал в исполнение: позднее изменение может требовать уведомления сотруднику, а не тихой перезаписи.
Регулярная сверка сопоставляет заказы и сделки за выбранный период, выделяет отсутствующие связи и разницу сумм. Она дополняет обработку событий и позволяет найти пропущенный заказ, даже если техническая доставка уведомлений выглядела успешной.
Когда он поддерживает ваш реальный маршрут: нужные вариации, обновление существующей сделки, доставку и согласованный сценарий возврата. Проверять надо на тестовом заказе, а не только по обещанию «интеграция с CRM». Если возможностей достаточно, отдельный сервис обмена не нужен.
Можно спроектировать такой процесс, но для каждого поля потребуется владелец, проверка конфликтов и ответ на отклонённое изменение. Начать обычно проще с одностороннего коммерческого состава и отдельной передачи согласованных действий менеджера.
NetLabCS поможет разобрать товары, изменения и финансовые состояния при интеграции Битрикс24 с WordPress . Для обсуждения обмена подготовьте обычный заказ и один пример частичного возврата: определим данные, владельцев полей и сценарии восстановления.
