כאשר מנהל סוגר עסקה ב-CRM, וצוות הלוגיסטיקה מעביר נתונים ידנית ל-TMS, אובדות עד 30 דקות לכל בקשה — מה שמצטבר למאות שעות עבודה תפעוליות בחודש.
שגיאות הזנה ידניות (כתובת שגויה, משקל לא נכון) מובילות למיון מחדש ומשלוחים חוזרים, ומייצרות הוצאות נוספות. אנו מפתחים אינטגרציה בין Bitrix24 למערכת הלוגיסטית שלך — מיצירת הבקשה ועד מעקב והתראות. בקשה נוצרת אוטומטית עם שינוי שלב העסקה, נתוני הנמען נשלפים מהאיש קשר, והפריטים מהעסקה. זמן העיבוד יורד משעות לשניות, והשגיאות לאפס. פתרון מפתח, עם הבטחות ביצועים יציבים וחיסכון של עד 60% מזמן מחלקת המשלוחים. פתרון האוטומציה שלנו למשלוחים מכסה את כל התהליכים המרכזיים: מהבקשה ועד ההחזרה.
באילו מערכות לוגיסטיות ו-API אנו מבצעים אינטגרציה?
1С:TMS Логистика. שירותי HTTP של 1C, פורמט נתונים — JSON או XML. פעולות עיקריות: יצירת בקשת הובלה, קבלת סטטוס, צירוף מסמכים.
МойСклад. REST API עם OAuth 2.0. תיעוד עשיר, סביבת ארגז חול (sandbox). תומך בניהול הזמנות, משלוחים, מלאי והחזרות.
СДЭК API v2. REST API, אימות JWT. חישוב עלות, יצירת הזמנה, מעקב, רשימת נקודות איסוף.
Яндекс.Доставка / DPD / Boxberry / ПЭК. לכל אחת יש REST API משלה, השונה במבנה הנתונים ובמנגנוני האימות. לצורך אינטגרציה אוניברסלית עם מספר ספקי שילוח, אנו משתמשים בתבנית adapter: ממשק יחיד בתוך האפליקציה, עם מימוש נפרד לכל ספק שילוח.
WMS-системы (Manhattan, SAP Extended Warehouse Management, 1C:WMS). בדרך כלל SOAP או API קנייני. האינטגרציה מורכבת יותר בשל פרוטוקולים legacy.
לפי תיעוד ה-API של CDEK, גרסה v2 מטפלת בעד 100 בקשות לדקה עם זמן תגובה ממוצע של 1.5 שניות.
מדוע עיבוד אסינכרוני קריטי לאינטגרציה?
ממשקי API לוגיסטיים אינם יציבים: מגבלות קצב (rate limits), timeouts, וחוסר זמינות. לכן, אנו בונים תור אסינכרוני (Redis + סוכנים מובנים של Bitrix). ה-webhook מ-Bitrix24 מתקבל באופן מיידי, בעוד קריאת ה-API הלוגיסטי ועדכוני הסטטוס מבוצעים באופן אסינכרוני. זה אמין פי 2-3 מגישה סינכרונית ואינו חוסם את עבודת המנהלים. לדוגמה, עם timeout של 30 שניות, בקשה סינכרונית הייתה חוסמת את הממשק, בעוד גישה אסינכרונית פשוט מנסה שוב לאחר 30 שניות.
תרחישי אינטגרציה
Сделка → заявка на доставку. עסקה ב-Bitrix24 עוברת לשלב "נשלח למשלוח" — webhook מופעל, ה-adapter יוצר בקשה במערכת הלוגיסטית. כרטיס העסקה מקבל את מזהה הבקשה (UF_LOGISTICS_ORDER_ID) ומספר מעקב.
Статусы доставки в CRM. המערכת הלוגיסטית שולחת webhook על שינוי סטטוס: "התקבל במחסן", "במעבר", "נמסר", "החזרה". ה-adapter מעדכן את שלב העסקה באמצעות crm.deal.update ומוסיף תגובה לציר הזמן באמצעות crm.timeline.comment.add.
Расчёт стоимости доставки. בעת יצירת הזמנה (בעסקה או בחנות מקוונת) — בקשה ל-API של הספק לחישוב עלות לפי משקל, ממדים וכתובת. התוצאה נשמרת בשדות העסקה או החשבונית.
Выбор ПВЗ. עבור אינטגרציות עם CDEK, Boxberry, דואר רוסיה — בורר נקודות איסוף על מפה בתוך כרטיס העסקה. מיושם כיישום מוטמע של Bitrix24 עם מפה (Leaflet + נתוני נקודות איסוף מה-API של הספק).
Возвраты. הלקוח יוזם החזרה — תהליך חכם "החזרה" נוצר ב-CRM, ומפעיל את ההליך במערכת הלוגיסטית: איסוף מהלקוח, קבלה במחסן, סטטוס בדיקת פריט.
ארכיטקטורת ה-adapter
אנו בונים אפליקציית PHP אשר:
- מאזינה ל-webhooks של Bitrix24 (אירוע שינוי שלב עסקה)
- ממפה את נתוני העסקה לפורמט המערכת הלוגיסטית
- קוראת ל-API הלוגיסטי
- כותבת את התשובה חזרה ל-Bitrix24
Битрикс24 (stale change webhook) ↓ Адаптер (валидация, трансформация данных) ↓ Логистическая система API ↓ (async — через callback или polling) Адаптер (обработка статуса) ↓ Битрикс24 REST API (crm.deal.update, crm.timeline.comment.add) דוגמה לטיפול ב-webhook ב-PHP:
function handleBitrixWebhook($event) { $dealId = $event['data']['FIELDS']['ID']; $deal = CRest::call('crm.deal.get', ['id' => $dealId]); $address = $deal['UF_DELIVERY_ADDRESS']; $phone = $deal['UF_DELIVERY_PHONE']; // Call CDEK API $cdek = new CdekApiClient(); $order = $cdek->createOrder([ 'recipient' => ['name' => $deal['CONTACT_NAME'], 'phone' => $phone], 'address' => $address, 'items' => $deal['PRODUCTS'] ]); CRest::call('crm.deal.update', [ 'id' => $dealId, 'fields' => ['UF_CDEK_ORDER_ID' => $order['uuid']] ]); } מידע נוסף על טיפול בשגיאות
אם ה-API של הספק אינו זמין, ה-adapter מכניס את המשימה לתור Redis ומנסה שוב עד 5 פעמים עם השהיה אקספוננציאלית: 1, 2, 4, 8, 16 דקות. אם לאחר כל הניסיונות ה-API אינו מגיב, נוצרת משימה ב-Bitrix24 עבור המפעיל עם הקשר השגיאה המלא.מיפוי שדות
קבוצת שדות טיפוסית להעברה למערכת הלוגיסטית:
| שדה Bitrix24 | שדה לוגיסטי | הערה |
|---|---|---|
Битрикс24 (stale change webhook) ↓ Адаптер (валидация, трансформация данных) ↓ Логистическая система API ↓ (async — через callback или polling) Адаптер (обработка статуса) ↓ Битрикс24 REST API (crm.deal.update, crm.timeline.comment.add) + function handleBitrixWebhook($event) { $dealId = $event['data']['FIELDS']['ID']; $deal = CRest::call('crm.deal.get', ['id' => $dealId]); $address = $deal['UF_DELIVERY_ADDRESS']; $phone = $deal['UF_DELIVERY_PHONE']; // Call CDEK API $cdek = new CdekApiClient(); $order = $cdek->createOrder([ 'recipient' => ['name' => $deal['CONTACT_NAME'], 'phone' => $phone], 'address' => $address, 'items' => $deal['PRODUCTS'] ]); CRest::call('crm.deal.update', [ 'id' => $dealId, 'fields' => ['UF_CDEK_ORDER_ID' => $order['uuid']] ]); } |
CONTACT.NAME |
שם מלא |
CONTACT.LAST_NAME |
recipient.name |
כתובת מובנית או מחרוזת |
UF_DELIVERY_ADDRESS |
recipient.address |
מספר טלפון |
פריטי עסקה (UF_DELIVERY_PHONE) |
recipient.phone |
רשימת פריטים, משקל, ממדים |
crm.deal.productrows.get |
cargo.items[] |
סוג משלוח (שליח/נקודת איסוף) |
UF_DELIVERY_TYPE |
service_code |
קוד נקודת איסוף אם נבחרה |
משקל וממדים הם אתגר נפרד. ב-Bitrix24 הם נשמרים בכרטיס המוצר (קטלוג), אך בעסקת CRM הם נלקחים מ-UF_PVZ_CODE באמצעות to_location.code. אם אינטגרציה עם מחסן או 1C לא מוגדרת, ייתכן שנתוני המשקל חסרים — יש צורך ב-fallback (ערכי ברירת מחדל לפי קטגוריית מוצר או הזנה ידנית). עבור החלפה עם 1C באמצעות CommerceML, אנו מגדירים בנוסף סנכרון נומנקלטורה.
מעקב והתראות ללקוח
לאחר קבלת מספר המעקב, אנו בונים שרשרת התראות. רובוט של Bitrix24 שולח SMS או דוא"ל ללקוח (באמצעות אינטגרציה עם שירות דיוור): "ההזמנה שלך נמסרה למשלוח, מספר מעקב: XXX". על כל שינוי סטטוס — באופן דומה. זה מפחית את עומס מוקד השירות פי 4 ומגביר את שביעות רצון הלקוחות. סוכן בדיקת הסטטוס רץ כל 15 דקות, וההתראות נשלחות תוך 5 דקות משינוי הסטטוס.
לצורך קבלה אוטומטית של סטטוס משלוח, אנו משתמשים בשתי גישות:
- Webhook מהספק — הספק מודיע על שינוי סטטוס. האפשרות הטובה ביותר, אך לא כל הספקים תומכים בה.
- Polling — סוכן Bitrix שואל את הסטטוס כל N דקות לפי מספר מעקב. עובד עם כל ספק, אך יוצר עומס על ה-API.
מה לעשות כאשר ה-API הלוגיסטי נכשל?
ממשקי API לוגיסטיים אינם יציבים ויש להם מגבלות ספציפיות:
- הגבלת קצב (rate limiting) — אנו עוצרים בין בקשות, שומרים במטמון נתוני עזר (רשימת נקודות איסוף, תעריפים). לדוגמה, CDEK מגביל ל-100 בקשות לדקה.
- שגיאות כתובת — הספק אינו יכול לקבוע את אזור המשלוח לפי כתובת. יש צורך בממשק משתמש לתיקון ידני עם התראה למנהל.
- בקשות חסומות — אם הלוגיסטיקה חוסמת בקשה (נתונים שגויים), המנהל חייב לראות זאת ב-CRM, ולא ללמוד על כך מהלקוח.
לטיפול בחריגים, אנו משתמשים בתור עם ניסיונות חוזרים (השהיה אקספוננציאלית עד 5 פעמים: 1, 2, 4, 8, 16 דקות) והתראות CRM. אם לאחר כל הניסיונות ה-API אינו זמין, נוצרת משימה עבור המפעיל עם הקשר השגיאה המלא.
מה כלול בעבודה
- ניתוח ממשקי ה-API של המערכת הלוגיסטית שלך ובחירת תרחישים
- פיתוח adapter עם תור אסינכרוני וניסיונות חוזרים
- הגדרת שדות עסקה, תהליכים חכמים ותהליכים עסקיים של Bitrix24 (Bizproc) ללוגיסטיקה אוטומטית
- יצירת ווידג'ט לבחירת נקודת איסוף (אם נדרש)
- התראות אוטומטיות ללקוח באמצעות SMS ודוא"ל לפי סטטוסים
- בדיקות על בקשות אמיתיות בסביבת בדיקה
- תיעוד טכני והדרכת עובדים
- אחריות ל-6 חודשים על האינטגרציה לאחר המסירה
שלבי פיתוח
| שלב | תוכן | משך |
|---|---|---|
| ניתוח | בחירת ספק, תרחישים, מפרט טכני | 3–5 ימים |
| פיתוח adapter | מחברי API מרכזיים | 1–2 שבועות |
| אינטגרציית CRM | שדות, תהליכים חכמים, אוטומציות | שבוע |
| ווידג'ט נקודת איסוף | מפה עם בחירה | 3–5 ימים |
| התראות | SMS/דוא"ל לפי סטטוס | 3–5 ימים |
| בדיקות | בקשות אמיתיות בסביבת בדיקה | שבוע |
אינטגרציה שהושלמה מקצרת את הזמן מיצירת עסקה לבקשת משלוח משעות לשניות — ומבטלת שגיאות הזנה ידניות. הזמינו אינטגרציה — קבלו פתרון עובד עם אחריות ל-6 חודשים. צרו קשר להערכת פרויקט: נבחר את הפתרון האופטימלי במפתח.