Произвольная смена статуса из БУС в МС

Данный случай относится к часто задаваемым и к нему можно отнести любое произвольное (незапланированное) изменение из БУС в МС.

Опишем самый частый случай такого изменения из БУС в МС

Шаг 1. Определяем источник

Для начала мы должны убедиться, что это именно модуль меняет статус.

Определение источника по пользователю

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

Если пользователь вам 100% говорит, что изменения сделаны из модуля, то пропустите этот шаг. Если же этот пользователь может использоваться в других сервисах или модулях, то стоит определить для модуля только одного уникального пользователя.

Определение источника по IP

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

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

Шаг 2. Проверка веб-хука

Вы можете пропустить этот шаг, если вы уверены что изменения из МС в БУС приходят корректно.

Проверка веб-хука

Теперь нам необходимо проверить веб-хук из МС в БУС. Для этого можно выполнить простое действие -- изменение комментария менеджера. При этом надо быть уверенным, что в настройках модуля вы указали обменивать этот комментарий менеджера.

Меняем комментарий в МС и сохраняем заказ.

Далее в БУС мы должны увидеть результат

Если у вас проблемы с этим шагом, то необходимо с нуля настроить веб-хук: https://docs.despi.ru/rbs-moysklad/settings/web-hooks

Также можете ознакомится с частыми проблемами при работе веб-хука: https://docs.despi.ru/external-docs/ms/web-hooks/faq

Шаг 3. Настройки обмена статусами.

Теперь можно обобщить итоги проверок, теперь мы убедились, что именно модуль меняет статус произвольно и при этом у нас работает изменение из МС в БУС.

Переходим в настройки модуля (вкладка "Экспорт заказа" -> Статусы) и видим такую картину:

Теперь смотрим сколько статусов в МС:

Из этого видно, что статусы в БУС и МС не совпадают 1 к 1. Другими словами на каждый статус МС должен быть установлен статус в БУС, но в нашем случае это не так, у нас всего 3 статуса синхронизируются в обе стороны.

Если у вас настройки аналогичные скриншотам выше, т.е. нет совпадения статусов на 100%, то проблема как раз в этом.

Почему сбиваются статусы при таких настройках?

Здесь все достаточно просто:

1) Вы вручную меняете статус в МС, к примеру "Собран"

2) В настройках модуля этот статус никак не участвует в обмене, следовательно заказ на сайте не меняет свой статус и остается прежним 3) Далее в БУС происходят какие-либо изменения, например, снимаются резервы автоматически (это настраивается в модуле "Интернет-магазин")

4) Модуль обмена подхватывает эти изменения и пытается обновить заказ из БУС в МС. При этом у нас такая картина:

  • На стороне БУС стоит изначальный статус, т.к. он не поменялся из МС, потому что для статуса "Собран" нету сопоставления (ради этого пункта мы и проверяли веб-хук, чтобы убедиться что изменения из МС приходят в БУС).

  • Далее модуль отправляет изменения из БУС в МС, при этом отправляет изначальный статус заказа в МС.

Шаг 4. Решение проблемы с настройкой модуля

Решение актуально для версии 1.9.0 и выше.

Для решения проблемы нам достаточно применить настройку игнорирования изменения статусами (вкладка "Экспорт заказа").

Мы должны сказать модулю, чтобы тот не менял статус из БУС в МС если в заказе МС стоит один из выбранных статусов. Выбирать нужно только те статусы, которые не участвуют в обмене, проще говоря те статусы, которые есть только в МС и их нет в БУС.

Last updated