Интеграция нужна не ради самого подключения, а ради согласованного учёта: одна продажа должна уменьшать доступный остаток один раз, а ошибка обмена — становиться видимой до следующего заказа. Начинайте с карты потоков данных, затем тестируйте небольшой набор SKU. Конкретный модуль, API и порядок подключения зависят от версии 1С, схемы продаж и текущих возможностей Ozon.
Определите владельца каждого поля
Составьте таблицу: кто меняет данные, куда они передаются и какое событие считается подтверждением. Для FBS особенно важны физический остаток на складе продавца, резервы под новые заказы, отмены и возвраты. Две программы не должны одновременно считать себя главным источником одного остатка.
| Данные | Источник решения | Контроль |
|---|---|---|
| Артикул продавца | Номенклатура 1С или единый каталог | Один товар не раздвоен из-за пробелов и регистра |
| Доступное количество | Учётный остаток минус подтверждённые резервы | Число на витрине не больше доступного |
| Заказ | Событие маркетплейса | Есть внешний ID и локальный документ |
| Отмена | Подтверждённый статус события | Резерв снят один раз |
Для Ozon и WB не смешивайте идентификаторы: один физический товар может иметь разные ID площадок, но должен сходиться к одной номенклатуре учёта. Если остаток общий, обе площадки должны получать значение после всех резервов. Иначе две почти одновременные продажи способны превысить доступное количество.
Как выбрать программу обмена
Попросите поставщика интеграции показать не логотипы площадок, а сценарии: новый заказ, отмена после резервирования, частичный возврат, ошибка авторизации, повторная отправка того же события. Уточните частоту обмена и задержку отображения статуса, способ ручной сверки и экспорт журнала ошибок. Обещание «обновление в реальном времени» без измеримого интервала и журнала бесполезно.
Проверьте права доступа. Учётные ключи не должны лежать в общей таблице; ответственный должен знать, кто может их перевыпустить и что случится при отключении интеграции. Перед покупкой модуля выясните стоимость поддержки обновлений API и версии 1С, а не только цену установки.
Тест резервирования на пяти событиях
Возьмите один тестовый SKU с условным доступным остатком 10 штук и проведите контролируемую последовательность. После заказа одной штуки ожидайте 9 доступных; после второго заказа — 8; после подтверждённой отмены первого заказа — 9. Затем повторно доставьте то же событие отмены: остаток должен остаться 9, а не стать 10. Наконец, имитируйте временный сбой соединения и проверьте, восстанавливается ли очередь без пропажи события.
Сохраните журнал с ID заказов, временем события, временем обработки и остатком до/после. Если фактический результат иной, не включайте автоматическое обновление всего ассортимента. Разберите причину: неверное сопоставление SKU, повторная обработка, задержка статуса или ошибка резервирования. Общую настройку складов см. в статье об остатках FBS.
Регулярная сверка
Даже после успешного запуска сравнивайте по датам три числа: учётный физический остаток, зарезервированное количество и число, опубликованное на площадке. Разницу оформляйте инцидентом с причиной, а не ручной правкой без следа. Для второй площадки ведите отдельный столбец резервов. Это помогает увидеть сбой раньше, чем покупатель закажет отсутствующий товар.
До публикации нужно подтвердить официальную документацию Ozon API, доступные статусы и ограничения текущей интеграции, а также протестировать описанный сценарий на конкретной конфигурации. Статья не называет универсальный пункт меню или точное время обмена и остаётся noindex.
