Главная бизнес-задача
Сократить путь заказа от площадки до производства или сборки, сохранив контроль над каждой позицией и не создавая новую ручную операцию на каждом этапе.
E-COMMERCE И ПРОИЗВОДСТВО · РЕАЛИЗОВАННЫЙ КЕЙС
Единая система заказов: маркетплейсы, amoCRM, склад и производство
Связали четыре маркетплейса с amoCRM и МойСклад, реализовали автоматическую проверку остатков и научили систему выбирать маршрут заказа: сборка со склада или запуск в производство.
4
маркетплейса работают через единый контур
2
ключевые системы: amoCRM и МойСклад
8–10
недель — проектный цикл реализации
Сфера: e-commerce и производство. Wildberries FBS, Ozon FBS, Яндекс Маркет FBS, Лемана ПРО FBS, amoCRM, МойСклад.
Почему обычной интеграции здесь было недостаточно
Заказ нужно не только получить. Его надо правильно сгруппировать, проверить по складу, сопоставить производственные параметры, создать резерв или задание на производство, затем синхронизировать упаковку и статус отгрузки.
Главная техническая задача
Свести разные модели API одним доменным процессом, при этом не потерять уникальные правила Wildberries, Ozon, Яндекс Маркета и Лемана ПРО.
Что изменилось после реализации
- Все новые заказы автоматически появляются в amoCRM.
- Система собирает разрозненные части в понятную карточку заказа.
- МойСклад становится источником истины по товарам и остаткам.
- Маршрут определяется алгоритмом по единым правилам.
- Статусы и грузоместа обновляются без ручного переноса.
Наш подход: отдельный адаптер для каждого маркетплейса, единое ядро бизнес-логики и независимый слой работы с CRM и складом.
Как это работало до автоматизации
Пять точек, в которых заказ терял скорость и требовал ручного решения сотрудника.
- 1
Заказы живут в разных кабинетах
Каждый маркетплейс — отдельное окно со своими правилами и статусами.
- 2
Покупка разбита на части
Одна покупка может быть разбита на позиции, постинги или отправления.
- 3
Остатки проверяются вручную
Остатки и параметры партии приходится сверять в разных системах.
- 4
Ошибки в коробках и статусах
Неверная упаковка или статус создают риск задержек и штрафов площадки.
- 5
Решение принимает сотрудник
Склад или производство — человек решает по памяти, без фиксированных правил.
Четыре площадки — четыре разных сценария
У каждой площадки собственные сущности, лимиты и статусы. Мы реализовали отдельную логику для каждого канала, сохранив единый интерфейс работы в amoCRM.
Wildberries FBS
Позиции одной корзины группируются по общему идентификатору в одну сделку. Система распределяет заказы по поставкам, контролирует лимит до 74 товаров и автоматически создаёт следующую поставку. Сложность: одна покупка разбивается на отдельные сборочные задания.
Ozon FBS
Несколько постингов одного заказа объединяются в одну карточку, а перевод в готовность к отгрузке синхронизирован с фактической сборкой. Сложность: не переводить заказ в готовность раньше физического завершения работ.
Яндекс Маркет FBS
Перед отгрузкой система формирует разметку грузомест: товары и единицы распределяются по коробкам, затем заказ переводится в READY_TO_SHIP. Сложность: корректная структура коробок обязательна до изменения статуса.
Лемана ПРО FBS
Одно отправление создаётся как одна сделка. Система подтверждает его, формирует грузоместа и завершает комплектацию по цепочке created → packingStarted → packingCompleted. Сложность: после завершения упаковки коробки уже нельзя менять.
Для менеджера это один понятный процесс. Для интеграции — четыре независимых набора правил, ограничений и обратных вызовов.
Один процесс поверх шести разных систем
amoCRM стала центром управления заказами. МойСклад отвечает за номенклатуру, остатки и документы. Интеграционный слой приводит данные площадок к единому формату и управляет обратными статусами.
- 1
Маркетплейсы
Wildberries, Ozon, Яндекс Маркет и Лемана ПРО передают заказы через собственные API.
- 2
amoCRM
Карточка заказа, статусы и контроль — центр управления всем потоком.
- 3
Decision Engine
Проверка каждой позиции и выбор маршрута заказа.
- 4
МойСклад
Товары, остатки, резерв и производство — источник истины по номенклатуре.
- 5
Сценарий RESERVE
Резерв товара → заказ покупателя → сборка → коробки → готов к отгрузке.
- 6
Сценарий PRODUCTION
Производственное задание → выпуск одной партией → повторная проверка → сборка.
Единый формат данных
Артикулы, количество, цена, номер заказа, источник и технические идентификаторы сохраняются в единой модели.
Управляемые статусы
CRM показывает реальный этап: новый заказ, на сборку, в производство, готов к отгрузке или ошибка.
Двусторонний обмен
Система не только получает заказы, но и отправляет подтверждения, коробки и изменения статусов обратно.
Мы не пытались заставить четыре площадки работать одинаково. Мы сохранили их правила, но спрятали различия внутри интеграционного слоя.
Decision Engine: система сама выбирает склад или производство
Каждая позиция заказа проходит последовательную проверку. Решение принимается не по общему наличию товара, а по фактическому остатку и производственной совместимости всей партии.
Сопоставление товара
Позиция ищется в МойСклад по артикулу, затем по коду.
Проверка остатка
Количество на складе должно покрывать заказ.
Проверка производственного атрибута
Атрибут «Принтер» должен быть заполнен и одинаков для всех позиций заказа.
Результат RESERVE
Все товары найдены, остатка достаточно, производственный атрибут заполнен и единый — заказ резервируется и переходит на сборку.
Результат PRODUCTION
Хотя бы одна позиция не прошла проверку или товары относятся к разным производственным партиям — создаётся производственное задание.
Диагностика по каждой позиции
Сотрудник видит не общий статус, а результат по каждой строке заказа и конкретную причину: товар не найден по артикулу или коду, остаток меньше требуемого, не заполнен атрибут «Принтер» или у позиций разные значения.
Артефактом проекта стал готовый виджет интеграции маркетплейсов с amoCRM — теперь подключить Wildberries, Ozon, Яндекс Маркет и Лемана ПРО можно как тиражируемое решение, без разработки с нуля.
Виджет «Интеграция маркетплейсов» →Автоматизация должна работать не только на тестовом заказе
Мы заложили защиту от типичных проблем реального API: повторных событий, временных ошибок, лимитов запросов, неполных данных и изменений статусов.
Идемпотентность
Повторный запрос не создаёт второй заказ, резерв или производственное задание.
Защита от дублей
Технические идентификаторы площадки сохраняются и проверяются до создания сделки.
Retry и backoff
Ошибки 429 и 5xx обрабатываются повторными запросами с контролируемой задержкой.
Rate limiting
Клиенты API учитывают ограничения систем и не создают искусственную перегрузку.
Логи и диагностика
Действия и ошибки фиксируются, а токены и чувствительные данные маскируются.
Модульные тесты
Доменный движок проверяется отдельно от HTTP и внешних сервисов.
Не четыре коннектора, а единый операционный контур
Клиенту требовалось убрать ручную обработку заказов и связать продажи, CRM, склад, производство и отгрузку. Заказ проходит весь путь автоматически, а решение по каждой позиции принимается на основании реальных данных из МойСклад.
Что было реализовано
- Автоматическое получение и нормализация заказов из четырёх каналов.
- Единая карточка заказа в amoCRM с корректным составом и источником.
- Decision Engine для проверки товара, остатка и производственных атрибутов.
- Автоматический выбор сценария RESERVE или PRODUCTION.
- Создание нужных документов и статусов в МойСклад.
- Управление коробками, поставками и статусами по правилам площадок.
Что клиент получил после запуска
- Все заказы в одном месте: четыре маркетплейса передают их в amoCRM без ручного переноса.
- Целостная карточка: разрозненные позиции и отправления группируются по бизнес-смыслу.
- Автоматический выбор маршрута — резерв и сборка либо запуск производства.
- Синхронизация с МойСклад: документы, резервы, статусы и производственные задания.
- Корректная упаковка: коробки и грузоместа формируются по правилам конкретной площадки.
- Меньше ручных ошибок: критичные проверки выполняет алгоритм.
Ключевой управленческий эффект
Рост потока заказов перестал означать такой же рост ручной работы. Архитектура масштабирует операции, а не нагрузку на менеджеров. Руководство видит поток заказов, узкие места, ошибки интеграции и готовность к отгрузке.
Что этот проект говорит о нашей команде
Мы работаем не только с воронками и полями amoCRM. Берём на себя проектирование процессов, интеграционную архитектуру и разработку бизнес-логики между продажами, складом и производством. Проект оценён в 260–280 часов и разбит на независимые блоки — интеграции площадок, движок принятия решений и слой МойСклад разрабатывались параллельно.
Понимаем процесс целиком
Начинаем не с API, а с пути заказа, ролей, ограничений и управленческой задачи.
Разделяем типовое и кастомное
Не разрабатываем с нуля то, что можно решить настройкой, и не маскируем сложную задачу готовым коннектором.
Работаем с производством
Учитываем партии, остатки, совместимость позиций, задания и повторную проверку после выпуска.
Проектируем под сбои
Закладываем идемпотентность, retry, логи, диагностику и тесты до выхода в эксплуатацию.
Сохраняем управляемость
Руководитель получает прозрачные этапы и причины решений, а не чёрный ящик.
Готовим систему к росту
Архитектура допускает новые площадки, правила и объёмы без полной переделки ядра.
Есть похожая задача?
Разберём процесс, найдём узкие места и спроектируем рабочий контур автоматизации.