מדי יום, מנהלים מבזבזים שעות במעבר בין חשבונות אישיים ב-Ozon, Wildberries ו-Yandex.Market—הזמנות מתבלבלות, המלאי הופך לשלילי, ולקוחות מתלוננים על עיכובים. שגיאות הזנה ידניות מגיעות ל-5% מההזמנות, מה שמוביל ליתרת הזמנות יתר ולחוסר שביעות רצון. אנחנו פותרים זאת עם אינטגרציה אחת: הזמנות מכל הערוצים זורמות למערכת ניהול ההזמנות המאוחדת של האתר שלך. הניסיון שלנו—מעל 5 שנים בשוק, 50+ פרויקטי אינטגרציה למרקטפלייסים. אנחנו יודעים לנרמל נתונים גולמיים מכל API, לבנות תור אמין, ולעולם לא לאבד אף הזמנה.
עיבוד הזמנות ידני עולה עשרות דולרים—כ-$9–13 בחיסכון חודשי רק במשכורות מנהלים, לא כולל הפסדים משגיאות ועיכובים. האינטגרציה שלנו מחזירה את עצמה תוך חודשיים עד שלושה—מנהלים מפסיקים להעתיק נתונים ומתמקדים בלקוחות.
איך עובד סנכרון הזמנות
הארכיטקטורה בנויה על תבנית queue-adapter-normalizer. לכל מרקטפלייס (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 תקופתיות, אנחנו משתמשים ב-webhooks או בבדיקות רקע עם מרווחים, מה שמפחית עומס על שרתי המרקטפלייס ועל ערוץ הרשת שלך.
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, והמנהל מגלה רק כעבור שבוע. ה-Ozon Order ─────┐ WB Order ──────┼──→ Order Normalizer ──→ Unified Orders DB ──→ Processing YM Order ─────┘ ↓ Site Order ─────────────────────────────→ WMS / ERP / 1С שלנו יוצר החזרה במערכת באופן מיידי ומשחזר את המלאי. הוא תומך בהחזרות מלאות וחלקיות, מחשב מחדש עמלות אוטומטית ומודיע לגורמים האחראים.
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 למרקטפלייסים, תיעוד לוגיקה עסקית | מפרט טכני |
| עיצוב | פיתוח סכמת מסד נתונים, מכונת מצבים, תורים | מסמך ארכיטקטוני |
| פיתוח | יישום אדפטרים, נורמליזטור, webhooks, מטפל בהחזרות | קוד מוכן |
| בדיקות | בדיקות מדומה על הזמנות בדיקה, בדיקות אינטגרציה עם APIs אמיתיים | פרוטוקול בדיקות |
| פריסה והדרכה | פריסה לסביבת ייצור, הדרכת מנהלים על הפאנל המאוחד | מערכת מחוברת + תיעוד |
לוחות זמנים
סנכרון הזמנות עבור 2–3 מרקטפלייסים עם פאנל שליטה מאוחד: 16–24 ימי עבודה. העלות מחושבת באופן אישי לפי מספר המרקטפלייסים ומורכבות הדרישות המותאמות. קבלו ייעוץ להערכה מדויקת של הפרויקט שלכם.
עבודה ידנית מול אוטומציה: השוואה
| קריטריון | עבודה ידנית (ממוצע) | האינטגרציה שלנו |
|---|---|---|
| זמן לסנכרון סטטוסים | 1–2 שעות ביום | אוטומטי, <דקה |
| שגיאות הזנת נתונים | ~5% מההזמנות | 0% |
| זמן עיבוד החזרה | 2–3 ימים | 10 דקות |
| עלויות מנהלים | משמעותיות (כ-$9–13 בחיסכון חודשי) | מחזיר את עצמו תוך 2–3 חודשים |
אוטומציה מפחיתה את עלויות הזמן פי 120—במקום שעתיים של עבודה ידנית, המערכת עושה זאת בדקה. טיפול ידני בהחזרות עולה סכום ניכר במשכורת מנהל; האינטגרציה שלנו מבטלת הוצאות אלו.
טעויות נפוצות באינטגרציה עצמית
- סכמות שמות מוצר שונות. באתר שלך, SKU הוא "ABC-001"; ב-Ozon, "ABC001." תוצאה: אי-התאמות מלאי. פתרון: השתמשו ב-SKU אחיד בכל המערכות.
- חוסר אידמפוטנטיות. נוצרות הזמנות כפולות על בקשות חוזרות. פתרון: בדקו
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; }לפני הכנסה. - החזרות שהוחמצו. המרקטפלייס לא תמיד שולח הודעה. פתרון: בדיקות רקע קבועות דרך API.
כבר יש לכם אינטגרציה, אבל משהו לא יציב? נבצע הערכה של היישום הנוכחי שלכם ונציע שיפורים—צרו קשר. הזמינו אינטגרציה ושחררו את המנהלים שלכם משגרה.







