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