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

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

Коротко: нужно проверить, откуда приходит статус, как он переводится во внутренний формат и почему не сохраняется в заказе.

Почему это ломается

Проблема возникает из-за измененного API службы доставки, неверного маппинга статусов, просроченных токенов, остановленного cron, недоступного webhook, ошибки в CRM или ручного изменения заказа, которое перетирает автоматический статус.

Что проверяю в первую очередь

  • приходит ли новый статус от службы доставки
  • запускается ли cron или webhook-обработчик
  • правильно ли сопоставлены внешние и внутренние статусы
  • нет ли ошибок авторизации API
  • не блокируют ли обновление права или валидация заказа

Как я это чиню

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

  • исправляю авторизацию и запросы к API доставки
  • обновляю таблицу соответствия статусов
  • чиню cron или webhook-обработчик
  • добавляю логирование неуспешных обновлений
  • проверяю уведомления клиентам после изменения статуса

Что подготовить перед обращением

  • пример заказа с неверным статусом
  • название службы доставки или CRM
  • лог ошибки или время последнего обновления
  • доступ к админке сайта
  • описание правильной логики статусов

Как выглядит нормальный результат

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

Чего лучше не делать

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

Вопросы и ответы

Почему часть заказов обновляется, а часть нет?

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

Можно ли добавить журнал синхронизации?

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

Что важнее: cron или webhook?

Зависит от интеграции. Иногда нужен webhook для быстрых изменений и cron как резервная проверка.

Нужно ли менять CRM?

Обычно нет. Сначала надо проверить обмен и правила сопоставления статусов.

Нужна похожая задача?

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

Итог

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