Подключить интернет-магазин к МойСкладу обычно просят одной строкой: остатки на сайте, заказы в учёте. Обмен запускается быстро, а проблемы всплывают потом, на живых заказах: позиция легла не на тот размер, в учёте может появиться второй документ, карточка показывает «в наличии» товар, которого на вашем складе нет. Ниже восемь проверок, которые стоит пройти до запуска. Они собраны из нашего проекта: магазин переехал с InSales на собственный движок и работает с МойСкладом.
Короткий ответ
Короткий ответ. Передача остатков и заказов заработает сразу. Обмен с МойСкладом ломается на крайних случаях: учёт не ответил, складов несколько, у товара есть размеры, к заказу применена скидка. Каждый из них проверяется на настоящих данных до запуска.
- Сначала вопрос о поведении при отказе: что делает сайт, когда учёт не ответил.
- Тестовой копии учёта в нашем проекте не было, поэтому записью в учёт управляют два условия сразу.
- Два самых неприятных дефекта нашли сотрудники заказчика в своих документах, а не автоматические тесты. Приёмку на живых заказах стоит закладывать в срок.
Что обычно передают между магазином и учётом
Схема обычная. Остатки и цены идут из учёта на сайт. Заказы идут с сайта в учёт документами «заказ покупателя». Статусы ведёт менеджер в учёте, а сайт их забирает. В нашем проекте остатки обновляются каждые 15 минут, цены раз в час, оплаченные заказы уходят в учёт сами. Если МойСклад недоступен, заказ ждёт в очереди и уходит, когда сервис вернётся.
Статусы мы забираем опросом, а не вебхуком. Вебхук нужно настраивать в вашей учётной записи и открывать для него публичный адрес, то есть обмен начинает зависеть от чужих настроек. Опросу хватает токена, который у нас уже есть.
1. Запись в учёт включается отдельным решением
Любая запись через API попадает в ваш настоящий учёт. В нашем проекте отдельной песочницы с копией данных не было. Поэтому выгрузка заказа у нас по умолчанию ничего не отправляет: она собирает документ, проверяет его и останавливается. Запись включается двумя условиями сразу, настройкой окружения и явным подтверждением в вызове. Тогда случайный запуск с компьютера разработчика не может создать документ в вашем учёте.
Что спросить у подрядчика: как он проверяет выгрузку, если тестовой копии нет, и что мешает ему случайно записать пробный заказ в ваш учёт.
2. Отказ учёта не равен пустому ответу
Сотрудница заказчика открыла в учёте свежий заказ примерно на три десятка позиций. Одна позиция стояла на карточке товара, а не на размере, который выбрал покупатель. В нашей базе строка заказа была верной. Причина нашлась в журнале службы: в минуту оформления учёт ответил ошибкой 429, то есть превышен лимит запросов. Выгрузка делала по запросу на каждую карточку, около тридцати подряд, и упёрлась в лимит. Повтора у неё не было, а поиск считал любой ответ, кроме успешного, словами «ничего не нашлось». Позиция молча легла на карточку, и менеджеру никто об этом не сказал.
Правила, к которым мы пришли:
- На ответ 429 запрос повторяем, паузу берём из самого ответа учёта. Это относится и к записи: 429 значит «запрос не принят», документ не создан.
- Запись при сбое на стороне учёта не повторяем никогда. Учёт мог создать документ и упасть уже после, и повтор завёл бы второй. Отказ менеджер видит в истории заказа и выгружает кнопкой, а дубль кто-то должен найти и удалить руками.
- Документ создаём, только когда его отсутствие подтверждено ответом учёта. Любой другой ответ откладывает выгрузку, её можно повторить кнопкой.
- Позиция, для которой не нашёлся размер, остаётся в предупреждениях выгрузки с названием и причиной: «не найдено в учёте» или «учёт не ответил».
Третье правило появилось не сразу. Первая версия исправления повторяла запись на 429 и сама открыла дыру: проверка «документ уже есть?» получала 429, запись со второй попытки проходила, и если документ в учёте уже был, рядом появлялся второй. Нашла это независимая проверка до выкатки. Поэтому документ создаём только при подтверждённом отсутствии, а не когда проверка «ничего не нашла».
Для приёмки попросите показать поведение при отказе: заглушку вместо учёта, которая отвечает ошибкой на каждый запрос. Заказ при этом должен оформляться, а выгрузка откладываться.
3. Остаток: с какого склада
В одной учётной записи может быть несколько складов и несколько юрлиц. Запрос ассортимента без фильтра отдаёт остаток суммой по всем складам. У нас в неё попадали склад брака, склад с отрицательным остатком и склад второго юрлица, зарегистрированного в другой стране. Карточка на российском сайте показывала «в наличии» товар, который физически лежал только за границей. Это тоже нашла сотрудница заказчика на живом товаре.
Лечится фильтром по складу, с которого сайт реально продаёт. Тот же склад указываем в документе заказа, иначе сайт и учёт считали бы остаток по разным складам. Спросите: с какого склада сайт берёт остаток и в какой склад уходит резерв.
4. Размер и резерв: позиция ссылается на модификацию
Покупатель выбрал размер или цвет, и позиция в документе обязана ссылаться на этот размер, а не на родительскую карточку. У нас сначала уходила ссылка на родителя. В учёте это выглядело так: у карточки остаток ноль и «доступно минус один», а у размера лежат десять штук без всякого резерва. Товар в минусе при полном складе.
Второе: без поля резерва в позиции МойСклад товар не держит. Документ создан, заказ в учёте есть, а остаток остаётся свободным, и тот же товар продают второй раз. Когда остаток неизвестен, мы просим зарезервировать всё заказанное: молча уронить резерв в ноль хуже, чем занять лишнее.
5. Статусы: по идентификаторам, а не по названиям
- Номера на истории. При переезде исторические заказы получили префикс, а в учёте у тех же заказов остались голые номера. Новые заказы совпадали, по истории совпадений не было: статусы заказов, ещё находившихся в работе, не доезжали. Теперь номер ищется и с префиксом, и без.
- Похожие названия. В учёте заказчика есть и «Ждём оплату», и «Ждем оплату», и это два разных состояния. Сравнение без учёта регистра или с заменой «ё» на «е» связало бы заказ не с тем состоянием. Состояние выбираем по идентификатору, а имя, которое встречается дважды, не угадываем.
- Соответствие статусов. Какое состояние учёта соответствует «доставлен» или «отменён», решает заказчик, а не разработчик. Проверьте, что это записано, а не лежит в голове исполнителя.
6. Суммы: одна цифра в учёте, на сайте, в чеке и в корзине шлюза
Сумма заказа должна совпадать везде, где она есть. Что у нас расходилось:
- Наценка за опции хранилась на единицу товара, а при выгрузке читалась как наценка на всю позицию. У заказа с двумя одинаковыми позициями с опцией документ в учёте выходил меньше заказа на стоимость опции.
- Ручная скидка менеджера не доезжала в учёт. Сотрудники видели «в системе одна сумма, в МойСкладе другая».
Тест проверял заказ на одну штуку, а при количестве один числа совпадают. Проверяйте на заказе с количеством больше одного, со скидкой и с опциями.
7. Два идентификатора у каждой позиции
У позиции в МойСкладе два идентификатора. Внешний код удобно хранить на сайте, а во внутренний упираются ссылки документов. Подставить один вместо другого легко, и на пробных данных это часто проходит. Мы споткнулись дважды: при выгрузке заказа запрос по внешнему коду дал 404 на трёх товарах из трёх, а при чтении резерва по заказу позиции не сошлись ни на одной строке из одиннадцати. Тест при этом был зелёным, потому что проверял нашу же неверную посылку. Ошибка нашлась только запросом к настоящим документам.
8. Экраны менеджера при недоступном учёте
Недоступный МойСклад не должен ломать карточку заказа, которую менеджер открывает десятки раз в день. Там, где данные берутся из учёта вживую, при отказе остаётся прочерк, а карточка открывается. Такой экран не ждёт пятнадцать секунд: у него один запрос с коротким временем ожидания.
Как проверять без записи в учёт
После исправления мы прошли запросами только на чтение все заказы за месяц и сравнили, куда ссылается каждая позиция в учёте, с тем, куда она должна ссылаться. Расхождение нашлось одно, тот самый заказ. Такая сверка не создаёт документов и не меняет учёт, поэтому её можно повторять сколько нужно, а закончить стоит открытием нескольких документов глазами сотрудника, который с ними работает.
Что спросить у подрядчика до старта
Если выбирать одну проверку из восьми, берите вторую: потерянную позицию и второй документ в учёте труднее всего заметить, пока кто-то не откроет заказ.
- Что запрещает случайную запись в мой учёт и как проверяется выгрузка без тестовой копии.
- Что происходит, когда учёт не ответил или ответил ошибкой: оформление заказа, повтор, предупреждение менеджеру.
- Как исключён дубль документа при повторе.
- С какого склада сайт берёт остаток и в какой склад идёт резерв.
- На что ссылается позиция заказа с размером и держится ли резерв.
- По чему сопоставляются статусы и кто решает соответствие.
- Совпадают ли суммы на заказе с количеством больше одного, со скидкой и с опциями.
- Как выглядят экраны менеджера, когда учёт недоступен.
Когда эта проверка не нужна
Если склад один, товары без размеров, заказов немного, а менеджер и так заносит каждый в учёт руками, простая выгрузка раз в день может обойтись дешевле. Проверки нужны там, где обмен ходит сам, а ошибка выглядит как аккуратный документ.
Как устроен обмен с учётной системой в целом, кто источник правды и что делать, когда учёт недоступен, мы разобрали в статье про интеграцию магазина с 1С. Если вы заодно уходите с платформы, смотрите переезд магазина на свой движок. Чтобы мы назвали состав работ и срок по вашему учёту, опишите в форме ниже, сколько у вас складов и юрлиц, есть ли размеры у товаров и какие статусы вы ведёте.
