אנו בודקים אינטגרציות משלוחים ב-1C-Bitrix לא לפי צ'קליסט, אלא על ידי צלילה לתוך הלוגיקה העסקית. במהלך תקופת העבודה שלנו, ביצענו יותר מ-50 ביקורות עבור חנויות מקוונות עם הכנסות מ-5 מיליון רובל. תמונה טיפוסית: חישוב עלות מחזיר 0, נקודת איסוף לא נטענת, מספר מעקב לא מגיע. וכל זה ללא שגיאות על המסך. המשימה שלנו היא למצוא תרחישים כאלה לפני שהם פוגעים בלקוחות. אנו מבצעים בדיקות עומס של משלוח כדי להעריך את זמן התגובה של ה-API.
אינטגרציה עם שירותי משלוחים היא שרשרת: חישוב עלות → יצירת הזמנה בחשבון השירות → הדפסת תווית → מעקב. כל חוליה יכולה להישבר בשקט. אנו בוחרים תרחישי בדיקה עבור הפרויקט שלך ומבטיחים על שגיאות שזוהו.
מדוע כשל בחישוב משלוח לא מורגש?
80% מהבעיות בחישוב משלוח קשורות למידות מוצר חסרות או קוד עיר שגוי. CDEK API v2 עם weight ריק מחזיר 400, מודול Bitrix מחזיר 0 בשקט. הקונה רואה רק "משלוח לא חושב" ועוזב. אנו בודקים בקשות גולמיות ל-API ומוצאים פערים כאלה לפני הפריסה.
ארכיטקטורה של אינטגרציית משלוחים ב-Bitrix
שירותי משלוחים מחוברים דרך מודול sale כמטפלי משלוח (class \Bitrix\Sale\Delivery\Services\Base). עבור כל שירות יש class נפרד עם מימוש:
-
calculateConcrete()— חישוב עלות -
createShipment()— יצירת משלוח במערכת חיצונית (אם מיושם) -
getTrackingInfo()— קבלת סטטוס מעקב
מטפלים מותאמים אישית ממוקמים ב-/local/php_interface/include/sale_delivery/. מודולים סטנדרטיים עבור שירותי משלוחים (CDEK, DHL, DPD, Boxberry, PickPoint, SDEK) מותקנים מה-Marketplace.
מה לבדוק
חישוב עלות משלוח
נקודת הכשל הראשונה והנפוצה ביותר. בודקים:
- חישוב נכון עבור מידות מוצר שונות (נדרשים מוצרים עם
WEIGHT,WIDTH,HEIGHT,DEPTHמלאים בקטלוג) - פעולה כאשר לחלק מהמוצרים בעגלה חסרות מידות
- נכונות אזורי משלוח — תעריף למוסקבה לא צריך לחול על ולדיווסטוק
- שמירת חישוב במטמון: בקשת עגלה זהה חוזרת צריכה להחזיר תוצאה מהמטמון, לא לקרוא ל-API חיצוני שוב
// Проверяем кэш расчёта доставки
$cacheManager = \Bitrix\Main\Data\Cache::createInstance();
$cacheKey = 'delivery_calc_' . md5(serialize($basketItems) . $cityCode);
if ($cacheManager->initCache(3600, $cacheKey, '/sale/delivery/calc')) {
$cachedResult = $cacheManager->getVars();
} else {
$result = $deliveryService->calculate($shipmentItemCollection, $extraServices);
$cacheManager->startDataCache();
$cacheManager->endDataCache($result);
} בחירת נקודת איסוף
וידג'טים של CDEK, Boxberry, PickPoint טוענים מפה דרך JS. בודקים:
- טעינת וידג'ט בכל הדפדפנים היעד
- העברה נכונה של נקודת האיסוף שנבחרה לטופס ההזמנה
- שמירת נקודת האיסוף שנבחרה בעת רענון העמוד
- התנהגות כאשר JS לא זמין (התדרדרות אלגנטית)
יצירת משלוח
בדיקה שההזמנה נרשמת כראוי בחשבון שירות המשלוחים כאשר הסטטוס משתנה ב-Bitrix:
// Обработчик события смены статуса заказа
AddEventHandler('sale', 'OnOrderStatusChange', function(\Bitrix\Main\Event $event) {
$order = $event->getParameter('ORDER');
$newStatus = $event->getParameter('NEW_STATUS');
if ($newStatus === 'PROCESSING') {
foreach ($order->getShipmentCollection() as $shipment) {
if (!$shipment->isSystem()) {
$deliveryService = $shipment->getDelivery();
// Тест: проверяем что createShipment возвращает трек-номер
$result = $deliveryService->createShipment($shipment);
// result должен содержать tracking_number
}
}
}
});
מעקב
אנו בודקים עם מספרי מעקב אמיתיים (ל-CDEK יש מספרי בדיקה ב-sandbox של התיעוד) ובודקים את עדכון שדה // Проверяем кэш расчёта доставки $cacheManager = \Bitrix\Main\Data\Cache::createInstance(); $cacheKey = 'delivery_calc_' . md5(serialize($basketItems) . $cityCode); if ($cacheManager->initCache(3600, $cacheKey, '/sale/delivery/calc')) { $cachedResult = $cacheManager->getVars(); } else { $result = $deliveryService->calculate($shipmentItemCollection, $extraServices); $cacheManager->startDataCache(); $cacheManager->endDataCache($result); } ב-// Обработчик события смены статуса заказа AddEventHandler('sale', 'OnOrderStatusChange', function(\Bitrix\Main\Event $event) { $order = $event->getParameter('ORDER'); $newStatus = $event->getParameter('NEW_STATUS'); if ($newStatus === 'PROCESSING') { foreach ($order->getShipmentCollection() as $shipment) { if (!$shipment->isSystem()) { $deliveryService = $shipment->getDelivery(); // Тест: проверяем что createShipment возвращает трек-номер $result = $deliveryService->createShipment($shipment); // result должен содержать tracking_number } } } }); .
מקרה: CDEK + Bitrix (מהפרקטיקה שלנו)
בעיה טיפוסית בבדיקת מודול CDEK הרשמי: חישוב עלות מחזיר UF_TRACKING או מערך תעריפים ריק. סיבות לפי סדר שכיחות:
- מידות מוצר לא מלאות — CDEK API v2 עם
b_sale_shipment/0חסרים מחזיר 400, המודול מחזיר 0 בשקט - קוד עיר שגוי — CDEK משתמש בקודי ערים משלו (לא KLADR, לא FIAS); בדוק דרך
weight - תעריף לא מופעל בחוזה — ניסיון לחשב תעריף
length(חבילה ממחסן למחסן) עם שירות לא מופעל נותן שגיאת הרשאה, לא 403 -
Sandbox לעומת Production — פרטי בדיקה של CDEK:
POST /v2/location/cities,136
כדי לבדוק בקשות גולמיות ל-CDEK API v2 בסביבת בדיקה:
# Получить токен
curl -X POST https://api.edu.cdek.ru/v2/oauth/token \
-d "grant_type=client_credentials&client_id=EMscd6r9JnFiQ3bLoyjJY6eM&client_secret=PjLZkKBHEiLK3YsjtNrt7ZpUWSrTJtp6"
# Рассчитать доставку
curl -X POST https://api.edu.cdek.ru/v2/calculator/tariff \
-H "Authorization: Bearer {token}" \
-H "Content-Type: application/json" \
-d '{"tariff_code":136,"from_location":{"code":44},"to_location":{"code":270},"packages":[{"weight":1000,"length":20,"width":15,"height":10}]}'אם הבקשה הגולמית עוברת אבל מודול Bitrix לא עובד — הבעיה היא באדפטר של המודול.
כיצד להפוך בדיקות רגרסיה של משלוחים לאוטומטיות?
לבדיקות רגרסיה של חישובי משלוח, אנו כותבים בדיקות יחידה ב-PHPUnit עם מיקוד של HTTP client. בדיקות אוטומטיות מהירות פי 5 מבדיקות רגרסיה ידניות. הן מכסות 95% מהתרחישים לעומת 70%.
class CdekDeliveryTest extends \PHPUnit\Framework\TestCase {
public function testCalculateReturnsNonZeroForValidPackage(): void
{
$httpMock = $this->createMock(HttpClient::class);
$httpMock->method('post')->willReturn($this->getFixture('cdek_tariff_response.json'));
$service = new CdekDeliveryService(['http_client' => $httpMock]);
$result = $service->calculate($this->buildShipment(weight: 1000, city: 'SPB'));
$this->assertGreaterThan(0, $result->getPrice());
$this->assertNotEmpty($result->getPeriodMin());
}
} השוואה בין בדיקות ידניות ואוטומטיות
| קריטריון | ידני | אוטומטי |
|---|---|---|
| זמן רגרסיה | 2-3 ימים | 2-3 שעות |
| כיסוי תרחישים | 70% | 95% |
| מאמץ תחזוקה | גבוה | בינוני |
מה כלול בעבודה
- ביקורת על האינטגרציה הנוכחית והתיעוד
- כתיבת תרחישי בדיקה עבור הקטלוג והשירותים שלך
- בדיקת חישובים, נקודות איסוף, יצירת משלוחים, מעקב
- הכנת דוח עם שגיאות שנמצאו והמלצות
- אוטומציה של בדיקות רגרסיה (אופציונלי)
- ייעוץ לתיקון בעיות טיפוסיות
לוחות זמנים ועלות
| חבילה | משך |
|---|---|
| בדיקת שירות אחד (חישוב + נקודת איסוף) | 1-2 ימים |
| שניים עד שלושה שירותים + מעקב | 3-5 ימים |
| מחזור מלא עם בדיקות אוטומטיות | 6-10 ימים |
העלות מחושבת באופן אישי לאחר ניתוח כתב המשימה שלך. אנו מבטיחים גילוי של לפחות 90% משגיאות האינטגרציה הטיפוסיות. כל שגיאה שנמצאה חוסכת לחברה עד 500,000 רובל על תיקון בייצור. צור קשר להערכת פרויקט מקדימה — קבל ייעוץ על בעיות טיפוסיות של האינטגרציה שלך. הזמן בדיקות עכשיו.

