Как сверить заказы сайта, оплаты и CRM
Допустим, на сайте 420 заказов, в CRM 438 сделок, у платежного сервиса 397 успешных оплат. Эти числа могут одновременно быть правильными. Заявка, сделка и платеж описывают разные объекты. Проблему нужно искать после того, как согласованы единица учета, статусы и момент сравнения.
Содержание статьи
Выберите одну покупку как основу сверки
Начните с идентификатора заказа магазина. Свяжите его с ID сделки, платежа, возврата и клиента. В системе может быть несколько оплат одного заказа или несколько сделок, связанных с одной покупкой. Поэтому простое сравнение количества строк почти всегда дает слишком мало информации.
Разделяйте заказ и товарную позицию. Если выгрузка содержит отдельную строку на каждый товар, три позиции одного заказа нельзя считать тремя покупками. Сумму заказа также нельзя складывать по строкам, если она повторена в каждой позиции. Сначала проверьте структуру файла на нескольких известных примерах.
При отсутствии устойчивого ID сопоставление по телефону, сумме и дате оставляйте предварительным. Два одинаковых заказа одного человека могут быть реальными. И наоборот, новый телефон не обязательно означает нового покупателя. Правила идентификации разобраны в статье про сегментацию клиентской базы.
Зафиксируйте дату среза и смысл статусов
Укажите период заказов, часовой пояс и момент выгрузки. Отдельно решите, какие оплаты и возвраты учитываются: известные на дату среза или поступившие позже. Заказ в конце месяца может быть оплачен в следующем. Нельзя незаметно сравнивать создание заказа с датой поступления денег.
Составьте таблицу соответствия статусов: создан, ожидает оплаты, оплачен, доставлен, отменен, возвращен полностью или частично. Название стадии сделки не гарантирует факта оплаты. Если менеджер переводит ее вручную, проверяйте основание перехода.
В Тильде заявки можно выгружать, но наличие строки в файле еще не подтверждает получение денег. У платежного сервиса свои события. Например, ЮKassa описывает уведомления о платежах и возвратах, по которым интеграция получает информацию об изменении состояния. Сверка должна учитывать обе стороны и их связь с заказом.
Разложите расхождения по причинам
Первая группа — заказ существует на сайте, но связанной сделки нет. Проверьте очередь передачи, ошибки интеграции и фильтры создания. Вторая — сделка есть, а исходный заказ не найден. Это может быть ручная продажа, другой канал, старый импорт или дубль. Такие записи нельзя автоматически удалять.
Третья группа — объект найден в обеих системах, но расходятся статус или сумма. Причиной могут быть частичный возврат, изменение состава, скидка, доставка или задержка обновления. Четвертая — связь неоднозначна: одному заказу соответствуют несколько сделок или платежей. Ее разберите до расчета клиентских сегментов.
Отдельно помечайте тестовые записи и технические повторы, сохраняя основание исключения. Не вычеркивайте неудобные строки только ради совпадения итогов. Проверяемый результат — это объясненные расхождения и согласованные правила обработки.
Повторный импорт должен быть предсказуемым
Перед обновлением данных уточните поведение импорта: какие объекты он создает, какие меняет и по какому ключу ищет совпадение. Например, документация Битрикс24 предупреждает, что импорт сделок не предназначен для обновления существующих записей: повторная загрузка может создавать новые сделки.
Сначала проверьте несколько записей на разрешенном тестовом наборе и сохраните исходное состояние. Затем повторите ту же загрузку. Если количество объектов или сумма покупок изменились второй раз без новых событий, способ обновления требует исправления.
Для обмена через интеграцию также проверьте обработку повторных уведомлений, запоздавших событий и временных отказов. Получение одного события несколько раз должно приводить к одному согласованному состоянию заказа. Подготовку такого обмена разбираем в статье про интеграцию сайта, CRM и 1С.
Принимайте результат по реестру
Сохраните по каждой спорной покупке идентификаторы источников, тип расхождения, ожидаемое состояние, ответственную сторону и результат проверки. В итог вынесите количество и сумму заказов на одинаковой базе, а также остаток необъясненных записей. Небольшая разница по общей сумме может скрывать крупные встречные ошибки.
После исправления пересчитайте зависимые показатели: повторные покупки, клиентскую выручку и RFM-сегменты. Совпавший общий итог не гарантирует правильного распределения по людям. Для приемки нужны и контрольные суммы, и проверка конкретных заказов, которые раньше расходились.
Если правила передачи заказов нужно изменить, добавьте в бриф на разработку магазина сценарии повторной передачи, оплаты и отмены. По ним разработчик и команда магазина смогут принять интеграцию.