Выберите город

Наши офисы

  • Сургут
    Пролетарский проспект 8/3
    +7 (499) 403-37-36
    ПН–ПТ: 9:00–18:00
  • Москва
    117218, улица Кржижановского, дом 29, корпус 5, этаж 2, офис 225.
    +7 (499) 403-37-36
    ПН–ПТ: 9:00–18:00

Переезд с InSales на МойСклад: риски учёта в живых заказах в России

Новости

Переезд с InSales на МойСклад: риски учёта в живых заказах

Интеграция интернет-магазина с учётом в МойСкладе после переезда с InSales выявила системные риски, которые проявляются не в тестах, а в живых заказах. Ошибки возникают не из-за кода, а из-за разницы в поведении системы и ожиданиях. Это не случайность — это архитектурный вызов, с которым сталкивается каждый, кто переносит магазин с платформы на собственный движок. Я считаю, что именно здесь начинается реальная конкуренция: не с соседним магазином, а с маркетплейсом, где всё работает на автомате.

Интеграция с учётом: где ломается связка

Интеграция интернет-магазина с МойСкладом после переноса с InSales выявила, что даже при правильной настройке система может вести себя неожиданно. Ошибки не в коде, а в логике взаимодействия: когда учёт не отвечает, а система принимает это как «нет данных», результат — заказ на неверной позиции. Это не технический сбой, а архитектурный риск, который превращает простой заказ в проблему. Я считаю это важным, потому что в таких случаях клиент не видит ошибку — он видит, что товар «в наличии», а потом получает отказ. Это не просто ошибка, это потеря доверия.

Как работает связка между сайтом и учётом

Сайт получает остатки и цены из МойСклада по ключу externalCode, который хранится в карточке товара. Заказы отправляются обратно как документы «заказ покупателя». Статусы обновляются через опрос — не через вебхук, потому что он требует публичного адреса и настройки в чужой учётной записи. Это делает интеграцию зависимой от внешних условий. Опрос работает с токеном, но не гарантирует, что ответ — не ошибка. Важно, что каждый шаг должен быть проверен: система не должна принимать «ничего не ответил» за «нет данных».

Что изменилось: от теста к реальному заказу

Раньше, когда магазин был на InSales, интеграция работала в изолированной среде. Теперь, на собственном движке, любая запись в МойСкладе — это реальный документ. Нет тестового контура. Любая ошибка в выгрузке — это уже заказ в учёте. Раньше тесты были зелёными, потому что проверяли не то. Теперь — только живые заказы. Это меняет всё: тестирование становится не тестированием, а проверкой реального поведения системы в условиях, близких к боевым.

Кого это касается: вы не в безопасности, если вы не проверили

Это касается любого, кто переносит магазин с платформы на собственный сайт. Особенно тех, кто использует МойСклад. Если вы не проверили, как система реагирует на 429, 5xx, пустой ответ или несоответствие внешнего кода — вы рискуете. Ошибка не в том, что код не работает. Она в том, что система принимает одинаково «не ответил» и «нет данных». Если вы не учитываете это — вы не знаете, где ваш заказ ушёл. И это не про технику — это про бизнес: вы теряете клиента, потому что он не может купить.

Что делать: как проверить систему до запуска

Начинаем с аудита: проверяем, как система обрабатывает ошибки. Убедитесь, что 429 — это не «не нашёл», а «не могу сейчас». Повторяем запросы с учётом заголовка X-Lognex-Retry-TimeInterval. 5xx — не повторяем, особенно при записи. Проверка существующего документа должна быть отдельной от пустого результата. Если документ не найден — не значит, что его нет. Если учёт не ответил — это не ошибка, это сигнал. Вывод: система должна не просто работать, а быть устойчивой к сбоям. Иначе — вы не контролируете заказ.

Что мы с этим делаем: как работает Cetera

Мы в Cetera начинаем с аудита интеграции, проверяем, как система реагирует на сбои, и встраиваем логику, которая не принимает «не ответил» за «нет». В таких проектах сначала смотрим, как клиент находит нужное, а потом — как система работает при сбое. У нас это обычно решается через проверку ответов, отдельную обработку ошибок и фильтрацию данных по складу. Мы не просто пишем код — мы делаем так, чтобы он работал, когда система падает. Более 1000 проектов, из них более 200 в электронной коммерции. Если хотите понять, как это выглядит у вас, — давайте обсудим вашу задачу.

Это часть нашей работы — Интеграция данных. Организация обмена информацией с сервисом-поставщиком данных. Интеграция данных

Автор: Святослав Семенов из Cetera Labs

Новость для бизнеса в Сургуте, Россия

Другие новости

Спонтанные покупки — это не ошибка, а сценарий в России

Издание New Retail пишет, что почти 91,2% россиян за последние три месяца совершили спонтанные покупки без заранее составленного плана. При этом основная масса трат пришлась на продукты питания, одежду, посещение кафе и товары для красоты. Средняя сумма, которую люди готовы тратить на импульсивную п…

Прочитать статью

Покупателям могут дать право отказаться от лишней упаковки в России

В Госдуме обсуждают инициативу, которая позволит покупателям онлайн-магазинов выбирать минимальную упаковку при заказе. Предложение касается отказа от лишних коробок, пакетов и наполнителей, если они не нужны для защиты товара. Это может повлиять на логистику и экологичность доставки.

Прочитать статью

Запишитесь на сбор требований со специалистом по 1С

Расскажите, что сейчас происходит с учётом и программой. Разберём задачу и предложим решение — с оценкой в часах.

Сургут, Россия

Наталия Назарова

Пролетарский проспект 8/3, Сургут

+7 (499) 403-37-36

surgut@1c-cetera.ru