Автозаполнение полей в RetailCRM снимает с оператора рутину: система сама проставляет способ доставки, склад отгрузки, менеджера, тип оплаты и служебные атрибуты по заранее описанным правилам. Разберём, какими механизмами это делается и где заканчивается зона триггеров.
Зачем автозаполнять поля
Каждое незаполненное поле заказа — это либо ручной ввод, либо ошибка в отчётах. Если оператор забыл проставить склад отгрузки, заказ не попадёт в нужную выгрузку; если не указан тип оплаты — не сработает финансовая аналитика. Автозаполнение решает три задачи:
- Скорость. Оператор не тратит время на очевидные значения, которые выводятся из контекста заказа.
- Единообразие. Одинаковые заказы получают одинаковые атрибуты — данные становятся пригодными для сегментации и BI.
- Снижение брака. Меньше пустых и противоречивых полей, из-за которых заказ застревает между статусами.
Какими способами RetailCRM заполняет поля
В RetailCRM нет единой кнопки «автозаполнение» — значение в поле попадает одним из нескольких путей, и важно понимать, какой из них уместен в конкретном случае.
| Механизм | Когда срабатывает | Что удобно заполнять |
|---|---|---|
| Значение по умолчанию у поля | При создании заказа/клиента | Статичные атрибуты: канал, тип клиента |
| Триггер | По событию (создание, смена статуса, изменение поля) | Менеджер, склад, приоритет, служебные флаги |
| Правила интеграции (импорт, маркетплейсы) | При загрузке заказа извне | Источник, способ доставки, магазин |
| API / внешний сервис | Внешний вызов через ключ | Сложная логика, обращение к своим базам |
Правило простое: статичное значение задают в настройках поля, условное — триггером, а вычисляемое из внешних данных — через API.
Автозаполнение через триггеры
Основной инструмент — триггеры в разделе Настройки → Триггеры. Триггер ловит событие, проверяет условия и выполняет действие «Изменить поля заказа». Типовая конфигурация выглядит так:
- Событие — «Заказ создан» или «Изменилось поле».
- Условие — например, регион доставки = Москва и способ доставки не заполнен.
- Действие — проставить склад «Москва-1» и способ доставки «Курьер».
Через триггер удобно заполнять и пользовательские поля. Например, менеджерский приоритет:
Если сумма заказа > 50000 → custom-поле priority = VIP
Справочники и значения по умолчанию
Часть полей опирается на справочники — статусы, типы доставки, способы оплаты, магазины, склады. Чтобы автозаполнение работало предсказуемо, справочники должны быть приведены в порядок:
- У каждого способа доставки задан код и привязка к службе — тогда триггер подставляет именно нужный вариант, а не «похожий».
- Для пользовательских полей типа «список» значения заранее описаны в
Настройки → Пользовательские поля, иначе триггер не сможет присвоить несуществующий пункт. - Значение по умолчанию у поля покрывает случаи, когда контекста для триггера ещё нет (заказ только создаётся).
Хорошая практика — разделить «дефолт при создании» и «уточнение по мере обработки». Дефолт даёт непустое поле сразу, триггеры доводят его до точного значения на следующих шагах воронки.
Сложное автозаполнение через API
Когда значение нельзя вывести внутри CRM — например, нужно подтянуть менеджера из внешней системы распределения или рассчитать поле по своей формуле — используют REST API. Триггер отправляет HTTP-запрос во внешний сервис, тот возвращает данные, и заказ обновляется методом:
POST /api/v5/orders/{externalId}/edit
В теле передаётся объект order с нужными полями, включая customFields для пользовательских атрибутов. Такой сценарий подходит для:
- подстановки данных из ERP или 1С (артикул поставщика, себестоимость);
- гео-логики: определение зоны доставки по адресу через внешний геокодер;
- расчёта скоринга клиента по вашей модели.
/api/v5/orders/fixExternalIds и батч-методы, чтобы не упереться в лимиты частоты запросов API.Порядок срабатывания и приоритеты
Когда над одним заказом работает несколько правил, важен порядок их выполнения. Триггеры отрабатывают последовательно, и результат одного может стать условием для другого. Отсюда несколько практических принципов:
- Сначала базовые значения, потом уточнения. Правило, проставляющее склад по региону, должно отработать раньше правила, которое корректирует склад под конкретный товар.
- Разделяйте события. Заполнение при создании и заполнение при смене статуса — это разные триггеры с разными условиями, их не стоит смешивать в одном.
- Именуйте правила осмысленно. Название вида «Автозаполнение: склад по региону» экономит часы при отладке, когда правил становится несколько десятков.
Если два правила конкурируют за одно поле, добавьте в условия взаимоисключающие проверки — так вы гарантируете, что для конкретного заказа сработает ровно одно из них, а не оба по очереди.
Практические сценарии
Несколько связок, которые закрывают большую часть рутины интернет-магазина:
| Условие | Что заполняется автоматически |
|---|---|
| Заказ с маркетплейса Ozon | Источник, магазин, тип оплаты «предоплата», склад FBS |
| Самовывоз выбран клиентом | Склад = точка выдачи, стоимость доставки = 0 |
| Повторный клиент (есть заказы в истории) | Флаг «постоянный», приоритет обработки |
| Оплата онлайн подтверждена | Статус оплаты, дата, ответственный менеджер отдела отгрузки |
Каждый сценарий — это отдельный компактный триггер с чётким условием. Не пытайтесь уместить всю логику в один «мега-триггер»: их проще отлаживать и отключать по одному.
Итог
Автозаполнение полей — это связка из трёх слоёв: значения по умолчанию для непустоты, триггеры для условной логики и API для сложных вычислений. Держите справочники в порядке, защищайтесь от зацикливания условиями «поле пустое» и разбивайте логику на маленькие понятные правила. Тогда карточка заказа заполняется сама, а оператор занимается клиентом, а не вводом данных.
Мы в B2Bsite настраиваем автозаполнение как часть автоматизации воронки: проектируем поля, справочники и триггеры под ваши процессы и подключаем API-логику там, где штатных средств не хватает.
Частые вопросы
Можно ли заполнять поле только если оно пустое?
Да, для этого в условии триггера добавляют проверку «поле не заполнено». Это стандартный способ защиты от перезаписи и зацикливания.
Чем значение по умолчанию отличается от триггера?
Значение по умолчанию проставляется всегда при создании и не зависит от контекста. Триггер срабатывает только при выполнении заданных условий и может учитывать данные заказа.
Как автозаполнять пользовательские поля?
Через действие триггера «Изменить поля заказа» или через API в объекте customFields. Значения для полей-списков должны быть заранее заведены в настройках.
Почему триггер запускается бесконечно?
Обычно из-за события «изменилось поле», когда триггер сам меняет это же поле. Добавьте условие, ограничивающее срабатывание, например проверку текущего значения.
Можно ли подтянуть данные из 1С при создании заказа?
Да, через API: триггер вызывает внешний сервис, тот обращается к 1С и возвращает данные, после чего заказ обновляется методом orders/edit.
Заполнятся ли поля у заказов с маркетплейсов?
Да. Часть значений задаётся правилами интеграции при импорте, остальное можно доопределить триггерами по источнику заказа.
Сработает ли автозаполнение для уже созданных заказов?
Триггеры на событие «создан» — нет, они срабатывают только на новых. Для массового заполнения существующих заказов используют API-скрипт или триггер по смене статуса.
Поможем с настройкой и поддержкой RetailCRM
Поможем с настройкой, доработкой и поддержкой RetailCRM.