שילוב מחסן חלק: 1C-Bitrix ו-DCT

ניהול ידני של מלאי וקליטת סחורות במחסן מוביל לשגיאות ועיכובים שעולים לעסקים זמן וכסף. אנו מפתחים אינטגרציה של 1C-Bitrix עם מסופי איסוף נתונים (DCT), תוך אוטומציה של פעולות המחסן באמצעות REST API אמין. הצוות שלנו מספק פרויקט סוהר—מהארכיטקטורה ועד היישום—ומבטיח ביצועים יציבים ותמיכה מתמשכת.
השירותים שאנו מציעים
מציג 1 מתוך 1כל 1626 השירותים
שילוב מחסן חלק: 1C-Bitrix ו-DCT
בינוני
~1-2 שבועות

הכישורים שלנו:

שאלות נפוצות

שילוב מחסן חלק: 1C-Bitrix ו-DCT

תארו לעצמכם: המחסן שלכם מכיל 10,000 יחידות סחורה, מלאי לוקח יומיים, ואחרי הזנה ידנית אתם מגלים 5% פערים. שילוב 1C-Bitrix עם מסופי איסוף נתונים (DCT) פותר את זה: כל סריקה נכנסת מיידית למערכת, רמות המלאי מתעדכנות אוטומטית, ושגיאות מתבטלות. חיסכון בעלויות תפעול והפחתת שגיאות מלאי משתלמים תוך החודשים הראשונים. לפי Oracle, אוטומציה של מחסן מפחיתה שגיאות תפעוליות ב-70%.

איך עובד שילוב DCT עם Bitrix

ארכיטקטורה: ה-DCT אף פעם לא מדבר ישירות עם מסד הנתונים של Bitrix — זו תהיה פרצת אבטחה וזה בלתי אפשרי טכנית. הסכימה הנכונה היא: DCT ↔ REST API בצד של Bitrix ↔ מודולי catalog ו-sale. אנו מיישמים סט של נקודות קצה API שה-DCT מתקשר איתן דרך WiFi של המחסן. למצב לא מקוון, המכשיר שומר את המשימה מקומית ומסנכרן כשהחיבור משוחזר.

אימות: כל DCT מקבל אסימון API אישי (שמור ב-HL-block bl_tsd_tokens). האסימון מקושר בצורה נוקשה ל-warehouse_id — המכשיר רואה רק משימות למחסן שלו. אסימונים הם קבועים אך ניתן לבטל אותם דרך ממשק הניהול. במהלך השילוב אנו מבטיחים שהאסימונים נוצרים דרך REST API ותומכים בביטול ללא אובדן נתונים.

למה REST API הוא הפרוטוקול הטוב ביותר

מסופי DCT מודרניים רצים על Android, שם REST/JSON הוא הפורמט הטבעי. עבור מכשירי Windows CE (למשל, Motorola MC9200) אנו משתמשים ב-HTTP POST עם פונקציונליות מוגבלת — רק איסוף הזמנות, לא מלאי. REST API Bitrix מאפשר:

  • שליפת משימת איסוף (רשימת פריטים עם ברקודים ומיקומי אחסון);
  • אישור כל סריקה;
  • השלמת המשימה והעברת ההזמנה לסטטוס "מוכן למשלוח".

הבקר /api/tsd/v1/ בודק את הברקוד דרך \Bitrix\Catalog\ProductTable (שדה BARCODE או טבלה b_catalog_product_barcode), מוצא את פריט המשימה, ומעדכן את המונה. שגיאות: אם הברקוד לא נמצא או שהפריט לא במשימה, ה-API מחזיר 422 עם תיאור.

REST API עבור DCT מהיר פי 5 מהחלפת קבצי XML ואינו דורש ממירים נוספים.

פתרון פעולה לא מקוונת

ה-DCT שומר את המשימה מקומית ב-SQLite. כשחיבור ה-WiFi נופל, סריקות מצטברות; לאחר חיבור מחדש, הן נשלחות לשרת. נעשה שימוש בתור: כל בקשה מקבלת request_id ייחודי, והשרת בודק כפילויות. זה מבטיח שאף סריקה לא הולכת לאיבוד או משוכפלת.

הגדרת שילוב ב-5 שלבים

  1. עיצוב סכמת מסד נתונים: HL-blocks למשימות, אסימונים ותוצאות סריקה.
  2. פיתוח REST API: בקרים לאיסוף, קבלה ומלאי.
  3. ממשק ניהול: יצירת משימות, צפייה בדוחות, ניהול אסימונים.
  4. בדיקה עם מכשיר אמיתי: אימות כל התרחישים (לא מקוון, קונפליקטים של ברקודים, הצפת תור).
  5. הכשרת צוות המחסן: מפגש מקוון של שעה.

דוגמת בקשה:

POST /api/tsd/v1/shipment/scan
Content-Type: application/json
Authorization: Bearer <token>

{
  "task_id": 123,
  "barcode": "4601234567890",
  "qty_actual": 1
}

תשובה: POST /api/tsd/v1/shipment/scan Content-Type: application/json Authorization: Bearer <token> { "task_id": 123, "barcode": "4601234567890", "qty_actual": 1 } או 200 OK עם תיאור שגיאה.

מה כלול

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

מלאי דרך DCT

למלאי אנו יוצרים משימה מסוג 422 Unprocessable Entity. ה-DCT טוען רשימת מוצרים עם כמויות צפויות (inventory); הצוות סורק ומזין כמויות בפועל. לאחר השלמה, נוצר דוח פערים (qty_system לעומת qty_system). תהליך זה מקצר את זמן המלאי ב-80% ומשפר את הדיוק ל-99.9%.

class TsdInventoryTask {
    public function create(int $warehouseId, array $productIds = []): array {
        // Создаём запись в bl_tsd_inventory_task
        $taskId = InventoryTaskTable::add([
            'WAREHOUSE_ID' => $warehouseId,
            'STATUS' => 'pending',
            'CREATED_BY' => $GLOBALS['USER']->GetID(),
        ])->getId();

        // Загружаем ожидаемые остатки из b_catalog_store_product
        $expected = \Bitrix\Catalog\StoreProductTable::getList([
            'filter' => ['STORE_ID' => $warehouseId],
            'select' => ['PRODUCT_ID', 'AMOUNT'],
        ]);

        while ($row = $expected->fetch()) {
            InventoryItemTable::add([
                'TASK_ID' => $taskId,
                'PRODUCT_ID' => $row['PRODUCT_ID'],
                'QTY_SYSTEM' => $row['AMOUNT'],
                'QTY_ACTUAL' => null, // заполнит ТСД
            ]);
        }

        return ['task_id' => $taskId];
    }
}

קבלת סחורה

במהלך קבלת סחורה, הצוות סורק כל יחידה. ה-handler של ה-API qty_actual מתאים את הברקוד לשורת קבלה (דרך טבלת ספקים class TsdInventoryTask { public function create(int $warehouseId, array $productIds = []): array { // Создаём запись в bl_tsd_inventory_task $taskId = InventoryTaskTable::add([ 'WAREHOUSE_ID' => $warehouseId, 'STATUS' => 'pending', 'CREATED_BY' => $GLOBALS['USER']->GetID(), ])->getId(); // Загружаем ожидаемые остатки из b_catalog_store_product $expected = \Bitrix\Catalog\StoreProductTable::getList([ 'filter' => ['STORE_ID' => $warehouseId], 'select' => ['PRODUCT_ID', 'AMOUNT'], ]); while ($row = $expected->fetch()) { InventoryItemTable::add([ 'TASK_ID' => $taskId, 'PRODUCT_ID' => $row['PRODUCT_ID'], 'QTY_SYSTEM' => $row['AMOUNT'], 'QTY_ACTUAL' => null, // заполнит ТСД ]); } return ['task_id' => $taskId]; } } או טבלת רכישות מותאמת אישית) ומגדיל את הכמות שהתקבלה. עם השלמה, המערכת אוטומטית:

  • מעדכנת מלאי ב-/api/tsd/v1/receipt/scan;
  • יוצרת מסמך כניסה דרך API של b_catalog_docs_element;
  • אם קיימים פערים, יוצרת משימה למנהל ב-CRM.

מכשירי DCT פופולריים ותאימות

מכשיר מערכת הפעלה פרוטוקול סטטוס
Honeywell CK65 Android 8+ REST/JSON תמיכה מלאה
Zebra TC52/TC57 Android 8+ REST/JSON תמיכה מלאה
Urovo DT50 Android REST/JSON תמיכה מלאה
Datalogic Memor 20 Android REST/JSON תמיכה מלאה
Motorola MC9200 Windows CE 7 REST דרך HTTP POST מוגבל

עבור Windows CE, אנו ממליצים להגביל את הפונקציונליות לאיסוף הזמנות — מלאי וקבלה רצים לאט בגלל מגבלות מחסנית ה-HTTP.

לוחות זמנים ועלות

לוחות זמנים אופייניים: 12 עד 15 ימי עבודה. עלויות מתחילות מ-$2,500 ומחושבות באופן אישי לפי מספר סוגי המשימות, צורך באינטגרציות נוספות (1C, CDEK), ומורכבות הלוגיקה העסקית. אנו מעריכים את הפרויקט על בסיס המפרט הטכני.

שלב משך
עיצוב API וסכמת מסד נתונים יומיים
בקרי API (איסוף, קבלה, מלאי) 5–6 ימים
ממשק ניהול לניהול משימות 3 ימים
בדיקה עם DCT אמיתי 2–3 ימים
סה"כ 12–15 ימים

חוזקות החברה

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

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