פיתוח מודול מעקב משלוחים עבור 1C-Bitrix

פיתוח מודול מעקב משלוחים עבור 1C-Bitrix

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

אוטומציית משלוחים: למה זה הכרחי

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

יישום טכני

מקורות נתונים

מספר המעקב מופיע בהזמנה לאחר העברתה לחברת המשלוחים. ב-Bitrix הוא נשמר בשדה TRACKING_NUMBER של הטבלה b_sale_order_delivery או במאפיין הזמנה מותאם אישית. מודולי משלוחים (DPD, CDEK, Boxberry, דואר רוסיה) מאחסנים את מספר המעקב בצורה שונה — זה נלקח בחשבון בעת יישום מתאמים.

עדכון סטטוס

משימת cron רצה כל 30 דקות כברירת מחדל; ניתן להגדיר את המרווח לפי העומס. הסקריפט בוחר הזמנות בסטטוסים המעידים על משלוח פעיל (DELIVERY, DELIVERING), מקבל סטטוסים עדכניים מהספק עבור כל אחת, משווה לסטטוס האחרון שנרשם ב-b_tracking_status. אם הסטטוס השתנה, נכתבת רשומה חדשה והדגל DeliveryProviderInterface מוגדר ל-0. במעבר הבא מתבצע איטרציה על רשומות עם local/modules/vendor.tracking/ ├── lib/ │ ├── Provider/ # Адаптеры для API служб доставки │ │ ├── CdekProvider.php │ │ ├── DpdProvider.php │ │ └── RussianPostProvider.php │ ├── TrackingService.php # Оркестратор │ └── StatusMapper.php # Нормализация статусов ├── install/ │ └── db/install.sql └── cron/ └── update_statuses.php ונשלחות הודעות. כך הלקוח יודע על תנועת החבילה תוך שעה מהאירוע.

תמיכה בחברות משלוחים

המודול יכול לחבר כל שירות דרך ממשק מתאם אחיד. מתאמים מפותחים עבור ממשק ה-REST או SOAP הספציפי של הספק. זה מאפשר שימוש במספר שירותים בו-זמנית באתר אחד והוספה מהירה של חדשים ללא שינוי בליבת המודול. לדוגמה, בפרויקטים עם 3+ ספקים, אנו משתמשים ב-b_tracking_status משותף.

ארכיטקטורת המודול

local/modules/vendor.tracking/
├── lib/
│   ├── Provider/ # Адаптеры для API служб доставки
│   │   ├── CdekProvider.php
│   │   ├── DpdProvider.php
│   │   └── RussianPostProvider.php
│   ├── TrackingService.php # Оркестратор
│   └── StatusMapper.php # Нормализация статусов
├── install/
│   └── db/install.sql
└── cron/
    └── update_statuses.php

טבלה interface DeliveryProviderInterface { public function getStatuses(string $trackingNumber): array; public function getProviderCode(): string; } — היסטוריית סטטוסים לכל הזמנה:

שילוב API

כל ספק מיישם את הממשק:

interface DeliveryProviderInterface {
    public function getStatuses(string $trackingNumber): array;
    public function getProviderCode(): string;
}

CDEK משתמש ב-REST API v2. אסימון דרך POST /v2/oauth/token, סטטוסים דרך GET /v2/orders?cdek_number={number}. התשובה מכילה מערך statuses עם שדות code, name, date_time, city. עוד על CDEK API — בויקיפדיה.

דואר רוסיה מספק שירות SOAP בכתובת https://tracking.russianpost.ru/rtm34. המתודה getOperationHistory מחזירה XML עם פעולות עבור המשלוח. ניתוח דרך SoapClient או ניתוח XML ישיר עם SimpleXMLElement. פרוטוקול SOAP מתואר בתיעוד Microsoft.

DPD — REST API, מעקב דרך GET /api/tracing/order/{trackingNumber}.

נורמליזציית סטטוסים

לכל ספק יש קודי סטטוס משלו. StatusMapper ממפה אותם לסט אחיד:

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

בעיות טיפוסיות ופתרונותיהן

תנאי מרוץ בעת כתיבת סטטוסים — כאשר מספר חבילות נתונים מגיעות בו-זמנית, עלולות להיווצר כפילויות. אנו משתמשים ב-INSERT ... ON DUPLICATE KEY UPDATE עם אינדקס ייחודי על ORDER_ID + EVENT_TIME. מגבלות קצב API — ל-CDEK יש מגבלה של 5 בקשות בשנייה, לדואר רוסיה — 10. למודול יש תור מובנה עם פסק זמן וניסיון חוזר. הודעות כפולות — נפתרות דרך הדגל NOTIFIED, שנבדק לפני השליחה.