Каждый день менеджеры тратят часы на переключение между личными кабинетами Ozon, Wildberries и Яндекс.Маркета — заказы путаются, склад уходит в минус, а клиенты жалуются на задержки. Ошибки при ручном вводе достигают 5% заказов, что приводит к избыточному резервированию и недовольству. Мы решаем это одной интеграцией: заказы со всех каналов попадают в единую систему управления заказами вашего сайта. Наш опыт — более 5 лет на рынке, 50+ проектов по интеграции маркетплейсов. Мы знаем, как нормализовать сырые данные из каждого API, построить надёжную очередь и не потерять ни одного заказа.
Ручная обработка заказов обходится в десятки тысяч рублей ежемесячно только на зарплате менеджеров, не считая потерь от ошибок и задержек. Наша интеграция окупается за два-три месяца — менеджеры перестают тратить время на копирование данных и сосредотачиваются на клиентах.
Как работает синхронизация заказов?
Архитектура строится на паттерне очередь-адаптер-нормализатор. Каждый маркетплейс (Ozon, WB, YM и другие) имеет свой адаптер, который преобразует сырой ответ API в единую структуру UnifiedOrder. После нормализации заказы попадают в общую базу, где их обрабатывает статусная машина.
Мы используем очередь на Redis или RabbitMQ для гарантии доставки. Если один из маркетплейсов временно недоступен, заказы не теряются — они ждут в очереди и обрабатываются после восстановления соединения. Идемпотентность обеспечивается уникальным sourceOrderId: повторный запрос не создаст дубль.
Ozon Order ─────┐
WB Order ──────┼──→ Order Normalizer ──→ Unified Orders DB ──→ Processing
YM Order ─────┘ ↓
Site Order ─────────────────────────────→ WMS / ERP / 1С
Нормализованная структура заказа
class UnifiedOrder
{
public string $id;
public string $source; // 'site', 'ozon', 'wb', 'yandex_market'
public string $sourceOrderId; // ID заказа в системе источника
public string $status; // mapped to unified statuses
public Customer $customer;
public array $items; // [{product_id, sku, quantity, price}]
public Shipping $shipping;
public float $total;
public string $createdAt;
}
Адаптеры для каждого маркетплейса
interface MarketplaceAdapter
{
public function getNewOrders(): array;
public function toUnifiedOrder(array $raw): UnifiedOrder;
public function updateStatus(string $orderId, string $status): void;
}
class OzonAdapter implements MarketplaceAdapter
{
public function toUnifiedOrder(array $raw): UnifiedOrder
{
return new UnifiedOrder(
source: 'ozon',
sourceOrderId: $raw['posting_number'],
status: $this->mapStatus($raw['status']),
customer: new Customer(
name: $raw['customer']['name'],
phone: $raw['customer']['phone'] ?? null,
),
items: array_map(fn($item) => [
'sku' => $item['offer_id'],
'quantity' => $item['quantity'],
'price' => $item['price'],
'name' => $item['name'],
], $raw['products']),
shipping: new Shipping(
address: $raw['delivery_method']['warehouse'] ?? null,
method: $raw['delivery_method']['name'],
),
total: $raw['financial_data']['total_amount'],
createdAt: $raw['created_at'],
);
}
public function updateStatus(string $orderId, string $unifiedStatus): void
{
$ozonStatus = $this->reverseMapStatus($unifiedStatus);
$this->ozon->updatePostingStatus($orderId, $ozonStatus);
}
}
Почему важна единая статусная машина?
Без статусной машины каждый маркетплейс живёт своей жизнью: «сформирован», «ожидает отгрузки», «передан в доставку». Менеджер вручную отслеживает изменения и копирует статусы. Мы автоматизируем это с помощью маппинга (см. конечный автомат теории). Кроме того, статусная машина позволяет избежать N+1 запросов — вместо периодического опроса API мы используем вебхуки или фоновые проверки с интервалами, снижая нагрузку на серверы маркетплейсов и ваш канал связи.
class OrderStatusMachine
{
private array $statusMap = [
'confirmed' => [
'ozon' => 'awaiting_deliver',
'wb' => 'confirm',
'ym' => 'PROCESSING',
],
'shipped' => [
'ozon' => 'delivering',
'wb' => 'complete',
'ym' => 'DELIVERY',
],
];
public function syncStatus(Order $order, string $newStatus): void
{
$order->update(['status' => $newStatus]);
if ($order->source !== 'site') {
$adapter = $this->getAdapter($order->source);
$adapter->updateStatus($order->source_order_id, $newStatus);
}
}
}
Как обрабатываются возвраты?
Возвраты — частая головная боль. Клиент отправил товар на Ozon, менеджер узнаёт об этом через неделю. Наш ReturnProcessor моментально создаёт возврат в системе и восстанавливает складские остатки. Он поддерживает как полные, так и частичные возвраты, автоматически пересчитывая комиссии и уведомляя ответственных.
class ReturnProcessor
{
public function processMarketplaceReturn(array $returnData, string $source): void
{
$order = Order::where('source', $source)
->where('source_order_id', $returnData['order_id'])
->firstOrFail();
Return::create([
'order_id' => $order->id,
'items' => $returnData['items'],
'reason' => $returnData['reason'],
'source' => $source,
]);
// Восстанавливаем остаток
foreach ($returnData['items'] as $item) {
Product::find($item['product_id'])?->increment('stock', $item['quantity']);
}
// Уведомляем менеджера
app(TelegramNotifier::class)->notifyReturn($order);
}
}
Мониторинг и алерты
Система включает дашборд с ключевыми метриками: количество заказов в очереди, время обработки, количество ошибок по каждому маркетплейсу. Настраиваются алерты в Telegram или Slack при превышении порогов. Это позволяет оперативно реагировать на сбои, не давая им повлиять на клиентов.
Что входит в работу
Мы предоставляем интеграцию под ключ:
| Этап | Что делаем | Результат |
|---|---|---|
| Аналитика | Аудит текущих процессов, сбор доступов к API маркетплейсов, документирование бизнес-логики | Техническое задание |
| Проектирование | Разработка схемы базы данных, статус-машины, очередей | Архитектурный документ |
| Разработка | Реализация адаптеров, нормализатора, веб-хуков, обработчика возвратов | Готовый код |
| Тестирование | Мок-тесты на тестовых заказах, интеграционное тестирование с реальными API | Протокол тестирования |
| Деплой и обучение | Развёртывание на production, обучение менеджеров работе с единой панелью | Подключенная система + документация |
Сроки
Синхронизация заказов для 2–3 маркетплейсов с единой панелью управления: 16–24 рабочих дня. Стоимость рассчитывается индивидуально в зависимости от количества маркетплейсов и сложности кастомных требований. Получите консультацию для точной оценки вашего проекта.
Как сравнить: ручная работа vs автоматизация
| Критерий | Ручная работа (в среднем) | Наша интеграция |
|---|---|---|
| Время на синхронизацию статусов | 1–2 часа в день | Автоматически, < 1 минута |
| Ошибки при вводе данных | ~5% заказов | 0% |
| Обработка возвратов | 2–3 дня | 10 минут |
| Затраты на менеджера | Существенные (тысячи рублей ежемесячно) | Окупается за 2–3 месяца |
Автоматизация сокращает затраты времени в 120 раз — вместо 2 часов ручной работы система делает всё за минуту. Ручная обработка возвратов обходится в заметную сумму на зарплате менеджера, наша интеграция избавляет от этих трат.
Типичные ошибки при самостоятельной интеграции
- Разные схемы именования товаров. На сайте артикул «ABC-001», на Ozon — «ABC001». В результате не совпадают остатки. Решение: использовать единый SKU во всех системах.
- Отсутствие идемпотентности. При повторном запросе заказов создаются дубли. Решение: проверка по
sourceOrderIdперед вставкой. - Пропуск возвратов. Маркетплейс не всегда присылает уведомление. Решение: регулярные фоновые проверки через API.
У вас уже есть интеграция, но что-то работает нестабильно? Оценим вашу текущую реализацию и предложим улучшения — свяжитесь с нами. Закажите интеграцию и избавьте менеджеров от рутины.