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