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