Ось Бизнеса 
Тендеры и лиды
Информация
Список вопросов, каждый из которых оплачен чьей-то ошибкой на боевом проекте. Задайте их до подписания договора — и увидите, кто перед вами.
Интеграция интернет-магазина со складом фулфилмента выглядит просто: заказы уходят на склад, статусы возвращаются обратно. Ломается она почти никогда не в сложном — не в архитектуре и не в нагрузке. Ломается в мелочах, которых нет в документации и о которых не думают на старте.
Ниже — вопросы, которые стоит задать подрядчику до подписания договора. Они не выдуманы: список собран по итогам действующей интеграции интернет-магазина с фулфилмент-оператором Бета ПРО — заказы уходят на склад, статусы и документы возвращаются обратно, товар маркированный, доставка через службу перевозчика. Каждый вопрос вырос из конкретной аварии, которую мы либо разбирали сами, либо получили в наследство.
Ответы на них показывают не столько техническую квалификацию, сколько то, работал ли человек с настоящим складом или читал про него.
1. Откуда возьмутся вес и габариты?
В заказе их нет. Там артикулы и количество, а перевозчику нужны килограммы и сантиметры. Значит, их надо откуда-то взять: из карточек товара, из справочника, из головы менеджера.
Хороший ответ звучит так: «Тянем из карточек по артикулу, складываем в одно грузовое место, у каждого значения есть запасное на случай незаполненной карточки». Плохой — «уточним по ходу». Это выяснится на первом же отправлении и остановит отгрузку.
2. Что произойдёт, если в позиции указано количество больше единицы?
Вопрос выглядит наивным, но это самая дорогая ошибка из нашей практики.
Мы отправляли на склад позицию с количеством: артикул, две штуки. Склад принимал задание, показывал «2 шт» — и отгружал одну. Оказалось, в задании этого оператора количества у позиции нет вовсе: строка всегда означает одну единицу, а атрибут игнорируется. Пришлось разбивать позицию на нужное число строк по штуке.
Страшно здесь не то, что ошиблись, а то, как это выглядело: не как сбой, а как «клиенту приехало меньше». В журналах чисто, обе системы отработали штатно, никто ни о чём не сигналит.
Поэтому спрашивайте прямо: как в этой конкретной системе устроена позиция заказа — и попросите показать пример задания, а не рассказать словами.
3. Кто хозяин каждого статуса?
Статусы приходят от склада и от перевозчика, и соблазн простой: показывать их у себя один в один. Так делать не стоит.
В работающей схеме роли разделены: промежуточные статусы ведёт автоматика по данным чужой системы, терминальные ставит человек. Пример из практики: клиент отказался от посылки, менеджер решил не принимать её на склад и отправить замену за свой счёт. Заказ должен спокойно стоять в «Возвращается», пока человек не решит иначе, — а автоматика упрямо сбрасывала его в «Возврат», перебивая ручное решение.
Смешение ролей выглядит для сотрудников как «система живёт своей жизнью», и доверие к ней теряется быстро.
4. Что показывать, если ваш статус и статус перевозчика расходятся?
Правильный ответ: ничего не придумывать. Портал обязан показывать то же, что личный кабинет перевозчика — не «логичнее» и не «раньше».
Первое же расхождение между двумя экранами заканчивается тем, что сотрудник перестаёт верить вашей системе и идёт проверять в чужой кабинет. После этого интеграция теряет смысл: работу она не экономит.
5. Какие статусы означают не то, что написано?
Такие есть всегда. У одного перевозчика «загружено» в сортировочном центре прилетает в момент подтверждения заявки, когда коробка ещё стоит у вас на складе: на боевом заказе это выглядело как «загружено в 8:56», а курьер приехал между 15 и 18. Если считать это отправкой, клиент увидит «в пути» за полдня до того, как посылку заберут.
Подрядчик, который такое встречал, ответит примерами. Тот, кто не встречал, скажет «разберёмся по документации» — и разберётся, но за ваш счёт.
6. Что произойдёт при повторной попытке?
Любой шаг обмена однажды упадёт: сеть, таймаут, перезапуск. Вопрос в том, что случится, когда его повторят.
Наш случай: система создавала заявку в службе доставки и не сохраняла её номер сразу — сначала выполняла следующие шаги. Шаг падал, повторная попытка создавала вторую заявку на тот же заказ, а первая оставалась висеть ничьей. Находится такое в лучшем случае при сверке, в худшем — приездом двух курьеров.
Правило, которое из этого выросло: идентификатор чужой системы сохраняется сразу после ответа, до любых следующих действий. Спросите, как это устроено у подрядчика.
7. Куда придёт сигнал, когда обмен сломается?
Не «будет ли логирование» — логирование будет всегда. Вопрос в том, кто и когда узнает.
Хороший ответ: конкретный человек получит сообщение в мессенджер или на почту, с указанием заказа и причины. Плохой: «всё пишется в логи». Логи никто не читает, пока клиент не позвонил.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13735 тендеров
проведено за восемь лет работы нашего сайта.
8. Как система узнает, что товар вернулся на склад?
Здесь чаще всего и обнаруживается, что интеграцию делали «в одну сторону».
Заказ вернулся, склад оформил его отдельным документом возврата — а в системе он так и висел доставленным. Нашли не по уведомлению, а по расследованию: два кода маркировки числились на складе, хотя были списаны.
Вывод: документы склада надо опрашивать, а не ждать, что о них сообщат. Возврат — это не статус, который придёт сам, а документ, который появляется в списке отгрузок и возвратов.
9. Что происходит с товаром и документами после возврата?
Принять на склад, вернуть коды маркировки в оборот, пробить чек возврата — или не принимать и отправить замену. Это разные деньги и разные документы, и решение принимает человек.
Спросите, где в системе это решение принимается и что она делает до него. Если ответ «автоматически закрывает заказ» — вы получите систему, которая принимает финансовые решения вместо менеджера.
10. Как коды маркировки связаны с позициями заказа?
Если товар маркированный, у каждой единицы свой код, и в чек он должен попасть правильно. Отсюда, кстати, и практический смысл вопроса номер два: пока позиция «две штуки» отправлялась одной строкой, на неё приходил один код — и чек по заказу с двумя одинаковыми товарами пробить было нечем.
11. Что проверяется при переезде на боевые ключи, кроме самих ключей?
Наш первый боевой заказ завис в ожидании оплаты, хотя деньги списались. Причина оказалась не в коде: на боевом терминале платёжного сервиса не были заполнены адреса уведомлений. Тестовый настроен, боевой — нет.
Платёж проходит, а система об этом не узнаёт. Спросите про чек-лист перехода в бой: он должен существовать и включать настройки на стороне чужих сервисов, а не только ваши.
Технически грамотных подрядчиков много. Разница между ними видна не в терминах, а в том, откуда берутся примеры.
Хороший признак: на вопрос отвечают конкретным случаем — «у такого-то оператора вот так, мы на этом обожглись, теперь делаем иначе». Даже если случай не про ваш склад, это значит, что человек проходил боевой запуск, а не только чтение документации.
Тревожный признак: ответы в будущем времени и в общем виде. «Настроим обмен», «синхронизируем статусы», «сделаем логирование». Это не ложь — просто такие ответы одинаково звучат у того, кто сделает, и у того, кто узнает про количество в позиции на третьем месяце работы.
И отдельно: попросите показать, что происходит при ошибке. Не как работает счастливый путь — его покажут все, — а что видит менеджер, когда склад не ответил. Именно эта часть отличает интеграцию, с которой можно жить, от демонстрации.
Из практики — три вещи, о которых потом жалеют:
Кто отвечает за расхождения в данных. Не «если что-то пошло не так», а именно: заказ ушёл, склад отгрузил не то, кто разбирается и за чей счёт.
Что считается завершением работ. Хороший критерий — не «обмен настроен», а «прошёл полный цикл на боевых данных, включая возврат». Возврат обычно и оказывается тем, что не доделали.
Что будет через полгода. API чужих систем меняются, и это нормально. Важно заранее знать, кто будет чинить, когда перевозчик добавит новый статус.
Материал написан по опыту интеграции с фулфилмент-оператором Бета ПРО, службой доставки и системой маркировки на действующем проекте. Если проходили похожее и знаете вопросы, которых здесь не хватает, — пишите в комментариях, список стоит того, чтобы его дополнять.
