Единая система для отдела продаж дистрибьютора: офис, агенты, склад, учёт

Возьмём обычную заявку. Торговый агент в 11:40 принимает заказ в магазине у дома, записывает его в блокнот или в приложение, вечером заявка попадает к оператору, утром оператор переносит её в 1С, кладовщик узнаёт о ней из распечатки, а бухгалтер — когда приходит УПД на подпись. К этому моменту выясняется, что у клиента просрочка, а двух позиций нет на складе. Каждый участник работал добросовестно, но в своей программе и со своими данными. Разрыв между ними и есть то, что называют отсутствием единой системы.

В этой статье разберём, из каких контуров состоит отдел продаж дистрибьютора, какие данные должны быть общими, что пусть остаётся в 1С, а что удобнее вынести в операционный слой вокруг неё, и в каком порядке это внедрять, чтобы не остановить отгрузки.

Путь одной заявки: где теряется время и деньги

Прежде чем выбирать программы, нарисуйте путь заявки от точки до оплаты. Для типового дистрибьютора продуктов или бытовой химии он выглядит примерно так:

1. Агент на визите проверяет остатки на полке, смотрит историю заказов точки и формирует заявку.
2. Заявка проверяется: цены по соглашению с клиентом, акции, кредитный лимит и просроченная задолженность.
3. Офис подтверждает заказ, резервирует товар, при нехватке предлагает замену или переносит часть на следующую отгрузку.
4. Склад собирает заказ, печатает или формирует в ЭДО документы — УПД, ТТН, при маркированном товаре передаёт коды.
5. Логист ставит заказ в маршрутный лист, экспедитор доставляет и фиксирует факт: принято полностью, частично, возврат.
6. Бухгалтерия видит отгрузку и ждёт оплату по графику отсрочки, агент получает сигнал, если клиент вышел в просрочку.

На каждом переходе, где данные переписываются руками или пересылаются файлом, появляются три вида потерь: задержка (заказ уехал на день позже), ошибка (не та цена, не тот товар) и слепота (руководитель узнаёт о проблеме из отчёта через неделю). Единая система нужна не ради красивой архитектуры, а чтобы на этих переходах данные передавались сами.

Четыре контура и кто за что отвечает

У отдела продаж дистрибьютора четыре рабочих контура. У каждого свои пользователи и свои данные, и ошибка многих проектов — пытаться дать всем один и тот же интерфейс.

Отсюда главное требование: каждый контур должен работать в удобном для себя инструменте, но с одними и теми же справочниками и с мгновенной передачей событий. Агенту нужно мобильное приложение для торговых представителей с офлайн-режимом, кладовщику — терминал сбора данных, бухгалтеру — привычная 1С, руководителю — сводная картина без выгрузок в Excel.

Общие данные: одна карточка клиента, товара и цены

Единая система начинается не с интерфейсов, а с мастер-данных — справочников, на которые ссылаются все документы. Если у агента клиент называется «Магазин на Ленина», у оператора «ИП Петрова», а в 1С это два разных контрагента с разными ИНН-ошибками, никакая интеграция не спасёт.

• Клиент и торговая точка — разные сущности. Одно юрлицо может иметь десять точек с разными адресами, графиками приёмки и агентами, а кредитный лимит и договор обычно задаются на юрлицо.
• Товар — единый код, единицы измерения и кратность упаковки, признак маркировки, срок годности. Штрихкоды и артикулы поставщиков хранятся как дополнительные идентификаторы.
• Цена — вид цены или прайс-колонка, привязанная к соглашению с клиентом, плюс действующие акции. Агент не должен вводить цену руками.
• Сотрудник и роль — кто какую территорию ведёт, кто согласует скидку сверх нормы, кто видит маржу.

Для каждой сущности нужно назвать систему-владельца: где запись создаётся и правится, а куда только копируется. Типичная схема: юрлица, договоры, товары и цены — владелец 1С; торговые точки, визиты, маршруты агентов и фото — владелец CRM. Подробно о том, как избежать дублей при обмене, — в статье интеграция CRM дистрибьютора с 1С без дублей.

Архитектура: учётное ядро и операционный слой

Почти у любого дистрибьютора учёт уже ведётся в 1С — «Управление торговлей», «Комплексная автоматизация» или ERP. Это хорошее учётное ядро: документы, остатки, взаиморасчёты, регламентированная отчётность. По описанию 1С, в «Управлении торговлей» есть соглашения с клиентами с ценовыми, финансовыми и логистическими условиями, графики оплаты, контроль задолженности, управление доставкой и мобильное рабочее место кладовщика. Ломать это ядро незачем.

Что обычно достраивают вокруг: мобильный контур агентов и экспедиторов, рабочее место оператора с очередью заявок и подсказками, B2B-кабинет или бот для самостоятельных заказов клиентов, сводную аналитику и уведомления. Этот операционный слой — то, что называют CRM для оптовой торговли. Он хранит то, чего нет в учёте (визиты, маршруты, фото, задачи), и обменивается с 1С документами и справочниками через интеграцию CRM с 1С.

Если компания выросла до нескольких складов, юрлиц и собственного импорта, разговор переходит от CRM к ERP для дистрибьютора, где операционный слой проектируется вместе с учётом. Где проходит граница, разобрано в статье ERP для дистрибьютора: когда 1С:УТ мало.

Какие события должны передаваться сами

Хороший тест на единую систему — список событий, которые сейчас кто-то пересказывает голосом или в мессенджере. Каждое из них должно стать автоматическим уведомлением или изменением статуса:

• Агент отправил заявку — она сразу видна оператору с отметками «цена по соглашению», «превышен лимит», «нет в наличии».
• Клиент вышел в просрочку — агент видит это в карточке точки до визита, а не после отказа склада в отгрузке.
• Склад собрал заказ не полностью — оператор и агент получают список недовложений и могут предложить замену.
• Экспедитор зафиксировал частичную приёмку или возврат — корректировка уходит в учёт, задолженность клиента пересчитывается.
• Поступила оплата — блокировка отгрузок снимается без звонка в бухгалтерию.
• Пришёл товар, которого ждали клиенты, — агенты получают список точек, где его заказывали или спрашивали.

Склад здесь — такой же полноправный участник. Сборка с ТСД и статусы «собрано», «отгружено» в реальном времени закрывают половину вопросов офиса; о складском контуре — на странице складское приложение для ТСД.

Порядок внедрения без остановки отгрузок

Единую систему не включают в понедельник для всех. Безопаснее идти от данных к людям и от одного контура к остальным:

1. Чистка справочников. Дубли контрагентов, точки без адресов, товары без кратности. Без этого любой следующий шаг упрётся в ошибки обмена.
2. Описание событий и владельцев данных. Таблица: сущность, владелец, кто читает, частота обмена. Это и есть техническое задание на интеграцию.
3. Интеграция с 1С на тестовой базе. Справочники, цены, остатки, задолженность — в одну сторону; заказы и факт доставки — в другую.
4. Пилот на одной территории. Пять–десять агентов, один оператор, реальная работа параллельно со старым процессом две–три недели.
5. Склад и доставка. Подключение сборки и фиксации доставки, когда поток заявок уже стабилен.
6. Самостоятельные заказы клиентов через B2B-кабинет или бота — когда цены, остатки и лимиты в системе уже достоверны.

Ориентировочный бюджет и окупаемость удобно прикинуть до начала проекта: стоимость считает калькулятор окупаемости CRM на ваших цифрах — число агентов, заявок в день и время на ручной перенос.

Как понять, что система действительно единая

Через два–три месяца после запуска проверьте простые признаки. Они важнее любой презентации:

Если хотя бы на два вопроса ответ из правой колонки, у вас не единая система, а несколько программ, соединённых людьми. Это нормальное состояние для растущей компании — важно знать, какие переходы автоматизировать первыми. Обычно начинают с заявок агентов и проверки лимитов: о второй теме подробно — в статье кредитный лимит и отсрочка платежа в CRM.