Продать то, чего нет на складе, — быстрый путь к отменам и недовольным клиентам. Синхронизация остатков связывает RetailCRM с учётной системой так, чтобы оператор видел реальное доступное количество. Разберём, как настроить обмен, учесть резервы и несколько складов, и не поймать оверселлинг.
Как работает синхронизация остатков
RetailCRM сама остатки не считает — она их отображает. Источником всегда выступает учётная система: 1С:УТ, 1С:Розница, МойСклад или другая. Обмен идёт по одному из принципов:
- По расписанию — учётная система периодически выгружает актуальные остатки пачкой;
- По событию — изменение остатка сразу отправляется вебхуком, обмен почти в реальном времени;
- Гибридно — быстрые события плюс полная сверка по расписанию для страховки.
Остаток, резерв и доступное количество
Главное, что должен понимать настройщик: в CRM нужно показывать не физический остаток, а доступное к продаже количество. Разница между понятиями критична.
| Показатель | Что означает |
|---|---|
| Остаток | Физически лежит на складе |
| Резерв | Зарезервировано под принятые заказы |
| Доступно | Остаток минус резерв — можно продать |
Если синхронизировать «голый» остаток без учёта резервов, два оператора продадут одну и ту же последнюю единицу. Поэтому либо учётная система отдаёт уже доступное количество, либо резервы ведёт сама RetailCRM и вычитает их из полученного остатка.
Несколько складов
Если складов несколько (розничная точка, основной склад, товар в пути), синхронизация усложняется. В настройках обмена задаётся соответствие складов учётной системы и складов RetailCRM.
- Раздельные остатки — каждый склад отображается отдельно, оператор видит, где лежит товар;
- Суммарный остаток — RetailCRM показывает сумму по выбранным складам как единое доступное количество;
- Правила приоритета — с какого склада списывать в первую очередь при отгрузке.
Решение зависит от логистики. Для интернет-магазина с одним фулфилментом хватает суммарного остатка; для сети с самовывозом нужны раздельные остатки по точкам.
Частота обмена и нагрузка
Интервал синхронизации — компромисс между актуальностью и нагрузкой. Слишком часто — упираетесь в лимиты API и тормозите учётную систему; слишком редко — растёт риск продать отсутствующее.
- Быстрый оборот, дефицитный товар — минимальный интервал или обмен по событию;
- Большой запас, медленный оборот — обновление раз в 15–30 минут вполне достаточно;
- Большой каталог — используйте инкрементальный обмен (только изменившиеся позиции), полную сверку — ночью.
Отдельно учитывайте лимиты API. У МойСклад и у RetailCRM есть ограничения на число запросов; при десятках тысяч SKU наивный «обновить всё каждую минуту» просто не пройдёт по лимитам.
Защита от оверселлинга
Оверселлинг — продажа большего количества, чем есть. Даже при частой синхронизации между двумя обменами остаток может обнулиться. Меры защиты:
- Немедленный резерв при оформлении заказа — товар мгновенно вычитается из доступного;
- Обмен по событию для критичных позиций вместо расписания;
- Буфер остатка — показывать в продаже на 1–2 единицы меньше для ходовых товаров;
- Блокировка оформления при нулевом доступном остатке, если это допустимо для бизнеса.
Контроль расхождений
Даже настроенная синхронизация со временем накапливает расхождения: непроведённые документы в 1С, ручные корректировки, сбои обмена. Регулярный контроль обязателен:
- Полная сверка остатков CRM и учётной системы по расписанию;
- Выборочный контроль ходовых позиций вручную;
- Журнал обмена — какие товары не синхронизировались и почему;
- Не сопоставленные SKU — новинки без внешнего кода не участвуют в обмене.
Расхождения проще устранять по горячим следам. Накопленные за месяц несоответствия разбирать долго и дорого.
Итог
Синхронизация остатков RetailCRM со складом держится на трёх принципах: показывать доступное к продаже, а не физический остаток; чётко закрепить, кто ведёт резерв; подобрать частоту обмена под оборот и лимиты API. Плюс несколько складов с корректным маппингом и регулярная сверка расхождений.
Мы настраиваем такую синхронизацию с 1С, МойСклад и другими системами: выстраиваем логику резервов, соответствие складов, защиту от оверселлинга и автоматическую сверку. В результате оператор видит реальные остатки, а отмен из-за отсутствия товара становится в разы меньше.
Частые вопросы
Почему RetailCRM показывает не тот остаток, что на складе?
Скорее всего в CRM попадает физический остаток без учёта резервов или не тот склад в маппинге. Нужно показывать доступное к продаже количество и проверить соответствие складов.
Кто должен вести резерв — CRM или 1С?
Кто-то один. Двойное резервирование занижает доступное количество и вызывает ложные «нет в наличии». Определите единого держателя резерва при настройке.
Как часто обновлять остатки?
Зависит от оборота и лимитов API. Дефицитные ходовые товары — минимальный интервал или обмен по событию, товары с большим запасом — раз в 15–30 минут.
Можно ли синхронизировать несколько складов?
Да. В настройках задаётся соответствие складов, а остатки показываются раздельно по точкам или суммарно — в зависимости от логистики.
Как избежать оверселлинга?
Ставить мгновенный резерв при оформлении, использовать обмен по событию для критичных позиций и небольшой буфер остатка для ходовых товаров.
Что делать с новыми товарами без остатков?
Проверьте, что у них проставлен внешний код и они сопоставлены с CRM. Позиции без сопоставления не участвуют в обмене остатками.
Нужна ли полная сверка, если обмен идёт постоянно?
Да. Ручные корректировки и сбои накапливают расхождения, поэтому полезно запускать полную сверку по расписанию, обычно ночью.
Поможем с настройкой и поддержкой RetailCRM
Поможем с настройкой, доработкой и поддержкой RetailCRM.