דרופשיפינג על ביטריקס: מקרי הגדרה, לוחות זמנים, אוטומציה

דרופשיפינג על ביטריקס: מקרי הגדרה, לוחות זמנים, אוטומציה

תארו לעצמכם: חנות מקבלת הזמנות, הספק שולח ישירות ללקוח. ההיגיון פשוט, אבל לביטריקס הסטנדרטית אין ניתוב מובנה לפי ספקים, סנכרון מלאי בזמן אמת או חלוקת תשלומים. ללא פיתוח מותאם אישית, כל הזמנה דורשת טיפול ידני — מנהל בודק זמינות, מתאם עם הספק, מזין נתונים. ב-200 הזמנות ביום, זה 4 שעות של שגרה, שגיאות ועיכובים. אנחנו פותרים את הבעיה הזו: במשך 10 שנים הקמנו דרופשיפינג ל-50+ פרויקטים — מחנויות מקוונות קטנות ועד מרקטפלייסים פדרליים. לדוגמה, עבור רשת אלקטרוניקה יישמנו מערכת עם 15 ספקים המעבדת 2000 הזמנות ביום. תוצאה: הפחתה של 70% בעבודה ידנית וביטול שגיאות משלוח. המהנדסים שלנו הם מומחי 1C-Bitrix מוסמכים, המבטיחים תהליך יישום שקוף.

בעיות שדרופשיפינג על ביטריקס פותר

הכאב העיקרי הוא עיבוד הזמנות ידני. ללא אוטומציה, מנהל מבזבז עד 5 דקות על כל הזמנה: בדיקת מלאי ספק, אישור מחיר, העברת נתונים. ב-500 הזמנות ביום, זה מעל 40 שעות בשבוע. הבעיה השנייה היא אי-התאמות במלאי. ספקים מעדכנים נתונים בצורה לא אחידה: חלק כל שעה, חלק פעם ביום. כתוצאה מכך, החנות מוכרת פריטים שאינם במלאי. זה מוביל לביטולי הזמנות ואובדן אמון. השלישית היא חלוקת תשלומים. אם הספק דורש תשלום לאחר המשלוח, ואתם לוקחים כסף מיד, אתם צריכים מערכת התחשבנות שקופה. אנחנו פותרים את כל שלוש המשימות באמצעות פיתוח מותאם אישית: יצירת מערכת ניהול ספקים אחידה, סנכרון מלאי בזמן אמת וניתוב הזמנות גמיש.

איך דרופשיפינג עובד על ביטריקס

מערכת דרופשיפינג מינימלית נשענת על שלושה אלמנטים:

1. קישור מוצר-לספק דרך מאפיין בלוק מידע או HL-block.
2. ניתוב הזמנות — כשנוצרת הזמנה, אנו קובעים לאילו ספקים להעביר פריטים.
3. סנכרון מלאי — הספק מעביר נתונים עדכניים דרך API או קובץ.

כל נקודה דורשת תכנון קפדני: ללא ארכיטקטורה נכונה, נוצרות שגיאות בהזמנות ואי-התאמות במלאי. לדוגמה, אם לא מגדירים ולידציה בעת שינוי ספקים, אפשר לשלוח הזמנה עבור מוצר שהופסק.

איך לארגן ניתוב הזמנות לפי ספקים

בעת יצירת הזמנה, ה-handler על אירוע OnSaleOrderSaved מפצל פריטים לפי ספקים ושולח הודעות. גישה זו משמשת ב-90% מהפרויקטים.

// /local/php_interface/init.php
AddEventHandler('sale', 'OnSaleOrderSaved', ['\Local\Dropshipping\OrderRouter', 'route']);

// /local/lib/Dropshipping/OrderRouter.php
namespace Local\Dropshipping;

use Bitrix\Main\Application;

class OrderRouter
{
    public static function route(\Bitrix\Sale\Order $order): void
    {
        $supplierItems = [];
        foreach ($order->getBasket() as $item) {
            $productId = (int)$item->getProductId();
            $supplierId = self::getSupplierByProduct($productId);
            if ($supplierId) {
                $supplierItems[$supplierId][] = [
                    'product_id' => $productId,
                    'name' => $item->getField('NAME'),
                    'quantity' => $item->getQuantity(),
                    'price' => $item->getPrice(),
                    'sku' => self::getSupplierSku($productId, $supplierId),
                ];
            }
        }
        foreach ($supplierItems as $supplierId => $items) {
            self::notifySupplier($order, $supplierId, $items);
        }
    }

    private static function notifySupplier(\Bitrix\Sale\Order $order, int $supplierId, array $items): void
    {
        $supplier = self::getSupplierData($supplierId);
        if (!empty($supplier['WEBHOOK_URL'])) {
            self::sendWebhook($supplier['WEBHOOK_URL'], $order, $items);
        } else {
            self::sendEmail($supplier['EMAIL'], $order, $items);
        }
    }
}

חשוב: ה-handler חייב להתחשב במשלוח חלקי והחזרות. אנו מוסיפים סטטוסים 'ממתין לספק' ו'הועבר לספק' כדי למנוע הודעות כפולות.

למה HL-blocks עדיפים על מאפייני בלוק מידע

לקישור מוצרים לספקים, אנו משתמשים ב-HL-block // /local/php_interface/init.php AddEventHandler('sale', 'OnSaleOrderSaved', ['\Local\Dropshipping\OrderRouter', 'route']); :

HL-block נוח יותר: תומך במספר ספקים למוצר, שומר מחירי רכישה בנפרד ממחירי קמעונאות, וניתן להרחבה בקלות. מאפייני בלוק מידע הופכים במהירות לבלתי ניתנים לניהול עם עשרות ספקים. אם יש לכם 50 ספקים ו-10,000 מוצרים, HL-block עם אינדקס על UF_SUPPLIER_PRICE מבטיח שאילתות מהירות, בעוד שמאפייני בלוק מידע מובילים לפגיעה בביצועים.

איך אנחנו פותרים סנכרון מלאי

סנכרון מלאי הוא נקודת כשל מרכזית. אם המלאי לא מתעדכן בזמן, החנות מוכרת מה שאין לספק. אנו מגדירים שני תרחישים:

• Pull — סוכן מתוזמן. כל 10 דקות, סוכן מבקש מלאי ומעדכן את הכמות במחסן. מתאים ל-80% מהמקרים.
• Push — webhook מהספק. הספק שולח בקשת UF_STORE_ID עם מלאי עדכני. מעובד בזמן אמת, אבל דורש עבודה מותאמת אישית בצד הספק.

כל ספק מקבל מחסן נפרד ב-UF_PRODUCT_ID. המלאי מאוחסן ב-POST. זה מאפשר לראות לא רק מלאי כולל אלא מלאי של ספק ספציפי. טעות אופיינית היא בלבול בין מחסנים במהלך סנכרון. אנו מגדירים מיפוי b_catalog_store כדי להבטיח שהנתונים מגיעים למקום הנכון.

// Агент, запускаемый каждые 10 минут
function syncSupplierStocks(): string {
    $suppliers = getSuppliers();
    foreach ($suppliers as $supplierId) {
        $stocks = fetchSupplierStocks($supplierId);
        updateStocks($supplierId, $stocks);
    }
    return __FUNCTION__ . '();';
}