RetailCRM собрана вокруг заказа, а не вокруг сделки: в ней есть статусы доставки, службы курьеров, возвраты и подключение маркетплейсов, но нет и не должно быть бухгалтерии и складского учёта. Поэтому связка с 1С здесь решает одну задачу — держать заказ и остаток в согласованном виде между витриной, оператором и складом. Всё, что касается воронки и общения с покупателем, в учётную систему не передаётся вообще.
Главный вопрос такой связки — не «как соединить», а «кто хозяин остатка». Пока на него нет ответа, любой обмен рано или поздно продаст один и тот же товар дважды: на сайте, на маркетплейсе и в розничной точке одновременно. Второй по важности вопрос — возвраты: в рознице их 5–10 % от заказов, и именно они чаще всего выпадают из технического задания.
Ниже — семь направлений обмена с частотой и типовыми поломками, разбор по конфигурациям 1С, механика хозяина остатка при нескольких складах и маркетплейсах, путь возврата из четырёх состояний и расчёт для магазина на 600 заказов в месяц.
Что возит связка: семь направлений
Обмен удобно описывать не объектами, а направлениями: что, куда и с какой периодичностью. Так техническое задание проверяется за пять минут, а не превращается в спор о формулировках после приёмки.
| Направление | Куда идёт | Частота | Что ломается чаще всего |
|---|---|---|---|
| Заказ и его состав | RetailCRM → 1С | В момент подтверждения оператором | Позиция без пары в справочнике 1С — заказ приезжает неполным |
| Оплата | Обе стороны | По событию | Онлайн-оплата отражается дважды: и по эквайрингу, и по выписке |
| Отгрузка и трек-номер | 1С → RetailCRM | По проведению реализации | Статус доставки перестаёт обновляться при смене службы доставки |
| Возврат | RetailCRM → 1С | По каждому состоянию, а не только по итогу | В учёт попадает только финальное состояние — товар «висит» неделю |
| Остатки | 1С → RetailCRM | Каждые 10–15 минут при живом обмене | Выгрузка раз в несколько часов: продажи товара, которого уже нет |
| Цены и акции | 1С → RetailCRM | 1–2 раза в сутки | Акционная цена ставится в CRM руками и перетирается обменом |
| Справочник товаров | 1С → RetailCRM | По изменению | Новые позиции заводят в CRM руками — появляются дубли без кода |
Карта связей. Слева четыре источника заказов: «сайт», «маркетплейс 1», «маркетплейс 2», «розничная точка» — все стрелки сходятся в узел «RetailCRM». Из него вправо стрелка «заказ, оплата, возврат» в узел «1С:УТ». Обратная стрелка подписана «остатки каждые 10–15 минут, цены 1–2 раза в сутки». Под узлом 1С — два прямоугольника «склад 1» и «склад 2» с подписью «единый источник остатка». Чертёжная подача, подписи по-русски.
Почему на 1С:Бухгалтерия эта связка не строится
Причина не в интеграции, а в том, что в Бухгалтерии нет объектов, которые нужны рознице. Заказ покупателя, резерв под заказ, остаток по конкретному складу, перемещение между точками — этого там просто не существует, и никакой обмен эти сущности не создаст. Подрядчик, который берётся связать RetailCRM с Бухгалтерией «под ключ», на самом деле собирается дописать в неё товарный контур, и это уже не интеграция, а разработка на несколько сотен тысяч рублей.
| Конфигурация | Заказы и резерв | Что получится со связкой |
|---|---|---|
| 1С:Бухгалтерия 3.0 | Нет | Только выгрузка реализаций и оплат постфактум: остатков и резерва не будет |
| 1С:Управление нашей фирмой (УНФ) | Есть | Строится без переделки: заказы, склады, резерв, возвраты — всё на месте |
| 1С:Управление торговлей 11 (УТ) | Есть | Базовый вариант для интернет-магазина: несколько складов, типы цен, соглашения |
| 1С:Розница | Частично | Заказы есть, но логика остатков привязана к магазинам — резерв под интернет-заказ требует доработки |
| 1С:КА 2 и ERP 2 | Есть | Работает, но обмен согласуется с общими регламентами и правами — срок больше на 2–3 недели |
Практический вывод: если сейчас у вас только Бухгалтерия, честный порядок — сначала товарный контур, потом CRM. Как выбирают между конфигурациями, мы разбирали в статье про то, какую конфигурацию 1С выбрать, а механику обмена витрины с учётом — в материале про обмен интернет-магазина с 1С.
Сравнительная таблица-схема из пяти столбцов: «Бухгалтерия 3.0», «УНФ», «УТ 11», «Розница», «КА 2 и ERP 2». Три строки признаков с отметками: «заказ покупателя», «остаток по складу», «резерв под заказ». У Бухгалтерии все три отметки пустые, подпись снизу «остатков и резерва не будет»; у УНФ и УТ все три заполнены, подпись «строится без переделки»; у Розницы третья отметка половинчатая с подписью «резерв под интернет-заказ — доработка»; у КА и ERP все три заполнены с подписью «плюс 2–3 недели на регламенты». Чертёжная подача, подписи по-русски.
Кто хозяин остатка при нескольких складах и маркетплейсах
Правило одно и оно не обсуждается: хозяин остатка — учётная система, а CRM и площадки получают производную величину. Как только остаток начинают править вручную хотя бы в одном канале, согласовать каналы между собой становится невозможно: у каждого своя правда, и правильной оказывается та, где меньше жалоб.
- 1Физический остаток считается по складам в 1С. Это единственное число, у которого есть подтверждение документами.
- 2Из него вычитается резерв — то, что уже обещано покупателям по подтверждённым заказам, включая заказы с маркетплейсов, ожидающие сборки.
- 3Полученный доступный остаток уходит в CRM, а из неё — на витрину и площадки. Каждому каналу можно назначить свою квоту: например, маркетплейсу отдать не весь доступный остаток, а его часть.
- 4Обратно из канала приходит только заказ. Никакой канал не имеет права менять остаток — он может его только уменьшить фактом заказа.
Квоты — единственный работающий способ не продать один товар дважды, когда каналов больше двух. Площадка не знает про ваш сайт, сайт не знает про розничную точку, и все трое видят одно и то же число. Если последней позиции на складе назначена квота — например, маркетплейсу отдаётся не больше 60 % доступного остатка, — то одновременная продажа в двух каналах перестаёт быть вопросом везения. Механика простая: квота считается в 1С от доступного остатка, а не задаётся в кабинете площадки руками, иначе она сама становится ещё одним числом с неизвестным хозяином.
При выгрузке остатков дважды в сутки в модельном магазине на 600 заказов около 1,2 % заказов приходится на товар, которого уже нет, — это 7 отмен в месяц, каждая с извинением и отменённой доставкой. При обмене каждые 10–15 минут доля падает в разы. Именно поэтому «раз в сутки ночью» — не экономия, а отложенный счёт. Механику двойных заказов при обмене мы разбирали отдельно: задвоенные заказы при обмене.
Возвраты: самая частая дыра розничного обмена
В техническом задании обычно написано «передавать возвраты». На практике возврат — это не событие, а четыре состояния, и учёт должен видеть каждое: иначе товар физически едет обратно неделю, а в системе его нет ни на складе, ни в пути, ни у покупателя. Это прямые деньги: позиция не продаётся, потому что её нет в остатках.
- 1Заявлен
Покупатель сообщил о возврате, оператор оформил заявку в CRM. В учёт уходит признак ожидаемого возврата — резерв под эту позицию снимать ещё рано, но планировать закупку под неё уже не надо.
- 2В пути
Служба доставки забрала посылку. В 1С позиция переходит в состояние «ожидается на складе»: она не продаётся, но и не считается утраченной. Отсутствие этого состояния — главная причина, по которой возвраты «теряются».
- 3Принят на складе
Кладовщик принял и проверил товар. Только здесь позиция возвращается в доступный остаток и снова уезжает в каналы продаж — при живом обмене в течение четверти часа.
- 4Деньги возвращены
Проведён возврат оплаты, закрыт документ. В CRM статус заказа меняется на финальный, в учёте закрываются взаиморасчёты. Разрыв между третьим и четвёртым шагом — нормальная ситуация, и обмен должен её выдерживать.
Горизонтальная схема из четырёх блоков со стрелками: «Заявлен» → «В пути» → «Принят на складе» → «Деньги возвращены». Под вторым блоком подпись «не продаётся, но не потерян», под третьим — выделенная подпись «возвращается в доступный остаток». Пунктиром показан частый неправильный вариант: длинная стрелка от первого блока сразу к четвёртому с подписью «товар лежит на полке, в системе его нет неделю». Чертёжная подача, подписи по-русски.
Модельный расчёт: магазин на 600 заказов в месяц
Считаем на интернет-магазине со средним чеком 3 800 ₽ и валовой рентабельностью 25 %: 600 заказов в месяц, два склада и две площадки, возвратов 8 %, остатки выгружаются вручную дважды в день. Ставка сотрудника — 700 ₽/час.
В расчёте намеренно нет строки «рост продаж». Обмен не увеличивает спрос — он убирает ручную работу и отмены, и всё, что можно обещать честно, находится в этих двух строках. Если подрядчик кладёт в обоснование рост конверсии, попросите показать, из какого механизма он берётся: обычно оказывается, что из скорости обновления остатков, а она уже посчитана выше.
Когда связка не нужна
Есть четыре ситуации, в которых обмен между RetailCRM и 1С не окупается, и это стоит проверить до договора.
- Меньше 100 заказов в месяц. Ручной перенос стоит около 3 500 ₽ в месяц по ставке 700 ₽/час, а поддержка обмена — 9 000 ₽. Здесь дешевле переносить заказы руками и вернуться к вопросу после трёхкратного роста потока.
- Один склад и товар под заказ. Если позиция закупается под каждый заказ, остатков как таковых нет, и главная функция связки отпадает. Достаточно выгрузки реализаций в учёт раз в день.
- Каталог не меняется. Полсотни неизменных позиций проще завести в CRM руками, чем платить за обмен номенклатурой и потом разбираться, почему в одной системе есть код, а в другой нет.
- Учёт ведётся только в Бухгалтерии и менять её не планируют. Тогда обмен упирается в отсутствие заказов и складов, и разговор идёт не про интеграцию, а про смену конфигурации — это другой проект с другой сметой.
Если проект остался нужен, самое полезное, что можно сделать до его начала, — письменно зафиксировать хозяина каждого числа: остатка, цены, статуса заказа, статуса возврата. Эта таблица занимает одну страницу и снимает большую часть будущих споров о том, чьи данные правильные. Общий разбор способов связать витрину и учёт мы собрали в статье интеграция 1С с сайтом, а цены на такие проекты — на странице интеграций. Если склад к тому моменту сам стал узким местом, смотрите автоматизацию склада.
Каналов продаж может быть сколько угодно. Остаток должен быть один, и жить он должен в учёте.
