Когда один товар продаётся на Ozon, собственном сайте и другом маркетплейсе, главный риск — не сама задержка обновления числа на экране. Опаснее двойная продажа последней единицы и расхождение резервов после отмены или возврата. Решение для синхронизации оценивают по поведению в таких событиях и полной стоимости владения, а не по обещанию «обновление в реальном времени».
Коротко. Назначьте один источник истины для доступного остатка и проверьте четыре события: одновременные заказы, недоступность связи, повторную отмену и возврат разного качества. Затем сравните предложения по одинаковому числу SKU, кабинетов, складов и горизонту: внедрение + лицензия + обслуживание + обновления + оценённые потери сбоев. Тариф сервиса без теста резервов не подтверждает безопасность продаж.
Где находится настоящий остаток
Для каждой товарной единицы определите учётный ключ: SKU, штрихкод, вариант, комплект и склад. Физический остаток, доступный к продаже остаток и резерв — разные числа. Если на полке пять единиц, две уже закреплены за заказами и одна повреждена, показывать во всех каналах «5» нельзя. Источником истины может быть учётная система, складская программа или иной утверждённый регистр; важно, чтобы изменения из каналов возвращались туда согласованным образом.
Запишите владельца операции. Кто создаёт остаток при приёмке? Кто резервирует товар при заказе? Кто снимает резерв при отмене? Кто переводит возврат в пригодный или непригодный запас? Если на эти вопросы отвечают две программы одновременно, расхождение может возникать даже при очень быстрой передаче данных.
Тест последней единицы
На копии системы создайте товар с одним доступным экземпляром и почти одновременно разместите заказ в двух каналах. Успешный результат заранее сформулируйте: только один канал подтверждает доступность, второй получает корректное отсутствие товара или иной безопасный статус. Запишите время событий, исходный резерв и итоговый остаток. Если оба заказа прошли, проблема не исправляется только сокращением интервала синхронизации — нужна стратегия резервирования и обработки конфликта.
Повторите тест с временно недоступным API. Что делает система: сохраняет событие в очереди, ограничивает доступный запас, сообщает оператору или продолжает публиковать старое число? В последнем случае измерьте, сколько заказов может прийти до восстановления. Фразу «задержка не более минуты» нужно подтверждать тестом под вашей нагрузкой и условиями договора, а не рекламным описанием.
Отмена, возврат и комплект
Повторная доставка одного события не должна дважды увеличить остаток. Если заказ на две единицы отменён, доступный запас должен вернуться к правильному числу один раз; повтор той же отмены не должен прибавить ещё две. Для возврата сначала решите, пригоден ли товар к повторной продаже. Факт физического прибытия вещи не всегда означает немедленное увеличение доступного остатка.
Комплекты требуют отдельной проверки. Продажа набора из двух SKU должна уменьшить оба компонента, а не только виртуальный остаток набора. Если один компонент продаётся отдельно в другом канале, тестируйте конфликт на уровне компонентов. Такой сценарий часто выявляет слабость интеграции лучше, чем обычный заказ одного товара.
Полная стоимость за одинаковый горизонт
| Статья | Что запросить у поставщика решения |
|---|---|
| Внедрение | Настройка каналов, перенос номенклатуры, тесты, обучение |
| Лицензия | Лимиты SKU, кабинетов, складов, заказов и пользователей |
| Обслуживание | Поддержка ошибок и контроль очереди событий |
| Обновления | Кто оплачивает доработки при изменении API или правил канала |
| Сбой | Время ручной обработки, отмены, потери и компенсации по вашим данным |
Условно вариант А требует 30 000 ₽ внедрения и 3 000 ₽ в месяц — 66 000 ₽ за первый год. Вариант Б: 10 000 ₽ и 5 000 ₽ в месяц — 70 000 ₽. Разница 4 000 ₽ не означает победу А: неизвестны лимиты функций, стоимость обновлений и измеримые потери при сбое. Не подставляйте в последнюю строку ноль только потому, что истории аварий пока нет; укажите диапазон и способ наблюдения.
Как принять решение
Сравнивайте предложения на одном наборе SKU, одинаковых каналах и складах, с одинаковыми тестовыми событиями. Попросите показать журналы передачи, повторной обработки и восстановления после обрыва. В акте приёмки фиксируйте входное состояние, событие и итоговый резерв, а не только «интеграция запустилась».
Результат. Вы знаете не только годовую цену, но и поведение системы в момент, когда два канала конкурируют за один товар. Это основа для выбора между ручным контролем, штатным обменом и специализированной интеграцией.
Что изучить дальше
- Если остатков немного и пока нужен ручной процесс, проверьте ведение остатков на Ozon до покупки интеграции.
- Если основой учёта служит 1С, сначала сформулируйте контрольные операции для обмена с Ozon и проверьте версию своей базы.
- Если двойные продажи уже происходят, разберите конкретный заказ и дату резерва, прежде чем менять систему целиком.
Источники и ограничения
Сценарии тестирования и формула TCO — редакционная методика. Цены в примере условные, не предложения поставщиков. Для публикации нужны датированные предложения, проверка совместимости конкретных каналов, действующих API и прав доступа, а также результаты теста на копии учётной системы. До этого материал остаётся noindex и не является рекомендацией конкретного сервиса.