Автоматизация оптовой торговли: заявки, закупки и контроль статусов

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

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

Разделите клиентский и учётный контур

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

Таблица владения данными

Составьте таблицу:

• объект;
• система создания;
• система редактирования;
• данные, нужные второй стороне;
• событие передачи;
• идентификатор связи;
• ответственный за ошибку.

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

Таблицу следует согласовать с представителями коммерческого, закупочного и учётного контуров. Это заранее выявляет одинаковые названия с разным смыслом и показывает, кому передавать вопрос при расхождении данных.

Входящая заявка

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

Если часть информации уточняется позже, не делайте её обязательной на старте. Требование должно появляться перед тем этапом, где без него невозможно решение.

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

Потребность и закупка

Клиентский запрос не всегда автоматически становится заявкой поставщику. Между ними могут быть проверка остатков, условий, категории и внутреннее согласование.

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

Отдельный маршрут закупки от заявки до поставки помогает разделить решение и исполнение.

Документы и согласования

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

Менеджеру не обязательно видеть внутренние комментарии всех подразделений. Права на документы и поля настраиваются по рабочей необходимости. Внешняя отправка также должна использовать подтверждённую версию.

Принципы проектирования собраны в статье о маршруте согласования.

Интеграция с 1С

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

Для каждого сценария нужны идентификатор, направление, обработка пустого значения, повтор и ошибка. Если планируется первоначальная история, отделите её от рабочего обмена. Используйте чек-лист подготовки интеграции и отдельный план миграции.

Статус для клиента

Менеджер должен видеть подтверждённое состояние заказа, но клиенту не нужны внутренние этапы. Подготовьте понятные внешние формулировки и укажите источник актуальности.

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

Управленческие вопросы

На первом этапе руководителю полезнее видеть очередь и отклонения, чем сложные показатели:

• заявки без следующего шага;
• просроченные обязательства;
• возвраты из-за неполных данных;
• связанные закупки без движения;
• документы на согласовании;
• ошибки передачи между системами.

После стабилизации данных можно анализировать длительность этапов и причины отклонений. Формулы должны быть одинаково понятны коммерческому, закупочному и учётному подразделениям.

Порядок внедрения

1. Описать один сквозной сценарий.
2. Назначить владельцев объектов и полей.
3. Упростить этапы и обязательные данные.
4. Настроить роли и доступы.
5. Протестировать маршрут без интеграции на контролируемых данных.
6. Добавить один подтверждённый сценарий обмена.
7. Провести пилот с группой пользователей.
8. Проверить качество статусов и отчётов.
9. Расширять контур по собранным данным.

Чек-лист готовности

• Клиентский и учётный контуры разделены.
• Для каждого объекта назначен источник истины.
• Заявка имеет ответственного и следующий шаг.
• Закупка связана с исходной потребностью.
• Документы разделены по типу решения.
• Интеграция обрабатывает повтор и ошибку.
• Клиентский статус основан на подтверждённых данных.
• Отчёт показывает отклонения, а не декоративные графики.

Отраслевые задачи представлены на странице «Оптовая торговля». Связанные решения: закупки, интеграция с 1С и управленческий учёт.