Синхронізація замовлень: єдина система для сайту та маркетплейсів

Щодня менеджери витрачають години на перемикання між особистими кабінетами 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 при перевищенні порогів. Це дозволяє оперативно реагувати на збої, не даючи їм вплинути на клієнтів.

Що входить у роботу

Ми надаємо інтеграцію під ключ:

Строки

Синхронізація замовлень для 2–3 маркетплейсів з єдиною панеллю управління: 16–24 робочих дні. Вартість розраховується індивідуально залежно від кількості маркетплейсів та складності кастомних вимог. Отримайте консультацію для точної оцінки вашого проєкту.

Як порівняти: ручна робота vs автоматизація

Автоматизація скорочує витрати часу в 120 разів — замість 2 годин ручної роботи система робить все за хвилину. Ручна обробка повернень обходиться в помітну суму на зарплаті менеджера, наша інтеграція позбавляє цих витрат.

Типові помилки при самостійній інтеграції

• Різні схеми найменування товарів. На сайті артикул «ABC-001», на Ozon — «ABC001». В результаті не збігаються залишки. Рішення: використовувати єдиний SKU у всіх системах.
• Відсутність ідемпотентності. При повторному запиті замовлень створюються дублі. Рішення: перевірка за sourceOrderId перед вставкою.
• Пропуск повернень. Маркетплейс не завжди надсилає повідомлення. Рішення: регулярні фонові перевірки через API.

У вас вже є інтеграція, але щось працює нестабільно? Оцінимо вашу поточну реалізацію та запропонуємо покращення — зв'яжіться з нами. Замовте інтеграцію та позбавте менеджерів рутини.