ייעול תהליך העבודה: מסמכי משלוח אוטומטיים ב-Bitrix

תארו לעצמכם: חנות מקוונת עם 200 הזמנות ביום. כל משלוח דורש חשבונית, אישור וחשבונית מס. מנהלים משקיעים 10 עד 20 דקות לכל הזמנה בהזנת נתונים ידנית. תכפילו במספר ההזמנות, ותקבלו עד 67 שעות בחודש — כמעט שבועיים של עובד אחד. יצירה אוטומטית של מסמכי משלוח ב-1C-Bitrix מקצרת זמן זה לשניות, ומבטלת שגיאות הזנה. עבור חנות טיפוסית עם 200 הזמנות/יום, האוטומציה חוסכת כ-$3.1k–4.5k בשנה, ומפחיתה את זמן עיבוד המסמכים ב-99%. שיעור השגיאות יורד ב-95%. אנו צוות עם ניסיון של למעלה מ-8 שנים בפיתוח 1C-Bitrix (CMS ו-Bitrix24). במהלך תקופה זו, יישמנו יותר מ-120 פרויקטים, כולל אינטגרציות עם 1C, CRM ושערי תשלום. הגדרת יצירת מסמכים אוטומטית היא אחת המשימות הנפוצות שאנו פותרים תוך 3-5 ימים. קבלו ייעוץ לפרויקט שלכם — האוטומציה מחזירה את ההשקעה תוך 2-3 שבועות.

לפי תיעוד Bitrix, האירוע OnSaleStatusOrderChange מופעל בכל שינוי סטטוס הזמנה.

למה לבצע אוטומציה של יצירת מסמכי משלוח?

יצירה ידנית של מסמכים במהלך משלוח היא מקור לשגיאות ובזבוז זמן. המנהל מזין נתונים מההזמנה ל-Excel או 1C, עושה טעויות ב-SKU או במחירים, ומבצע עבודה מחדש. אוטומציה זו מייעלת את ניהול ההזמנות ב-Bitrix על ידי ביטול הגורם האנושי: מסמכים נוצרים לפי כללים מוגדרים בעת שינוי סטטוס. זה חשוב במיוחד עבור חנויות עם זרימת הזמנות גדולה — מ-50 ליום ומעלה. שגיאות במסמכים מובילות להחזרות ולחוסר שביעות רצון של לקוחות.

הגדרת יצירת מסמכים אוטומטית

נקודת הכניסה היא אירוע OnSaleStatusOrderChange של מודול sale. הוא מופעל בכל שינוי סטטוס. פרמטרים: ORDER_ID, STATUS_ID (סטטוס חדש), OLD_STATUS_ID. המטפל נרשם ב-/bitrix/php_interface/init.php או במודול:

AddEventHandler('sale', 'OnSaleStatusOrderChange', 'generateShipmentDoc'); function generateShipmentDoc($orderId, $newStatus, $oldStatus) { if ($newStatus !== 'S') return; $order = \Bitrix\Sale\Order::load($orderId); if (!$order) return; generateInvoiceForOrder($order); } 

ב-API החדש של Bitrix (D7), האירוע נקרא AddEventHandler('sale', 'OnSaleStatusOrderChange', 'generateShipmentDoc'); function generateShipmentDoc($orderId, $newStatus, $oldStatus) { if ($newStatus !== 'S') return; $order = \Bitrix\Sale\Order::load($orderId); if (!$order) return; generateInvoiceForOrder($order); } ומעביר את אובייקט ההזמנה — מומלץ להשתמש בו במקום הישן. הוא מופעל בכל שמירת הזמנה, ולכן יש לבדוק בנוסף את שינוי הסטטוס.

בדיקת DEDUCTED הקריטית

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

מבנה משלוח במודול המכירות

משלוח ב-Bitrix הוא אובייקט DEDUCTED='Y'. כל הזמנה יכולה לכלול מספר משלוחים. טבלת \Bitrix\Sale\Shipment מאחסנת משלוחים עם שדות: b_sale_shipment, ORDER_ID, DELIVERY_ID, STATUS_ID, PRICE_DELIVERY, CURRENCY (DEDUCTED — סחורה שנמחקה מהמחסן). פריטי משלוח — Y: b_sale_shipment_item, SHIPMENT_ID, BASKET_ID, QUANTITY. בעת יצירת מסמך משלוח, יש לקרוא מ-RESERVED_QUANTITY, לא מ-b_sale_shipment_item — עם משלוחים חלקיים, הכמויות עשויות להיות שונות.

יצירת חשבונית PDF

ליצירת PDF, אנו משתמשים בספריית mpdf החיצונית. ל-Bitrix אין מחולל PDF מובנה למסמכים, אך קיים מנגנון לטפסי הדפסה דרך רכיב DEDUCTED. יצירת PDF תכנותית דרך mpdf:

function generateInvoiceForOrder(\Bitrix\Sale\Order $order) { $shipmentCollection = $order->getShipmentCollection(); $items = []; foreach ($shipmentCollection as $shipment) { if ($shipment->isSystem()) continue; foreach ($shipment->getShipmentItemCollection() as $shipmentItem) { $basketItem = $shipmentItem->getBasketItem(); $items[] = [ 'name' => $basketItem->getField('NAME'), 'quantity' => $shipmentItem->getQuantity(), 'price' => $basketItem->getPrice(), 'sum' => $basketItem->getPrice() * $shipmentItem->getQuantity(), ]; } } ob_start(); include __DIR__ . '/templates/invoice.php'; $html = ob_get_clean(); $mpdf = new \Mpdf\Mpdf(['utf-8', 'A4']); $mpdf->WriteHTML($html); $pdfContent = $mpdf->Output('', 'S'); $fileId = \CFile::SaveFile([ 'name' => 'invoice_' . $order->getId() . '.pdf', 'type' => 'application/pdf', 'content' => $pdfContent, ], 'sale/invoices'); saveInvoiceFile($order->getId(), $fileId); } 

שיטות לשמירת PDF שנוצרו

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

אנו ממליצים על טבלה מותאמת אישית — היא לא מאבדת נתונים בעדכונים ואינה דורשת מודולים נוספים. גישה זו גם מקלה על ייצוא מסמכי Bitrix והגדרת אירועי מכירה.

משלוח מסמכים למנהל

לאחר היצירה, המסמך נשלח למייל המנהל או ל-CRM. דרך אירוע function generateInvoiceForOrder(\Bitrix\Sale\Order $order) { $shipmentCollection = $order->getShipmentCollection(); $items = []; foreach ($shipmentCollection as $shipment) { if ($shipment->isSystem()) continue; foreach ($shipment->getShipmentItemCollection() as $shipmentItem) { $basketItem = $shipmentItem->getBasketItem(); $items[] = [ 'name' => $basketItem->getField('NAME'), 'quantity' => $shipmentItem->getQuantity(), 'price' => $basketItem->getPrice(), 'sum' => $basketItem->getPrice() * $shipmentItem->getQuantity(), ]; } } ob_start(); include __DIR__ . '/templates/invoice.php'; $html = ob_get_clean(); $mpdf = new \Mpdf\Mpdf(['utf-8', 'A4']); $mpdf->WriteHTML($html); $pdfContent = $mpdf->Output('', 'S'); $fileId = \CFile::SaveFile([ 'name' => 'invoice_' . $order->getId() . '.pdf', 'type' => 'application/pdf', 'content' => $pdfContent, ], 'sale/invoices'); saveInvoiceFile($order->getId(), $fileId); } , זמין sale_order_documents — ממנו נלקח המנהל האחראי מ-OnSaleOrderSaved (שדה ORDER_ID) ונשלח מייל דרך b_sale_order עם תבנית מסוג RESPONSIBLE_ID או תבנית מותאמת אישית. חלופה היא אינטגרציה עם מודול \Bitrix\Main\Mail\Event::send(): בעת שינוי סטטוס, נוצרת משימה למנהל עם קישור למסמך. המשימה נשארת עד לסיום, בעוד מייל עלול ללכת לאיבוד.

מה כלול בעבודת ההגדרה

• ביקורת של סטטוסי הזמנות ותוכניות משלוח קיימות
• פיתוח מטפל לפי הלוגיקה שלכם (סטטוסים, משלוח חלקי)
• תבנית מסמך PDF עם עיצוב (שם, מחירים, SKU, חתימות)
• בחירה והגדרה של מיקום אחסון קבצים (מאפיין, טבלה, CRM)
• הגדרת התראות (מייל, משימות) למנהלים
• תיעוד הפתרון והדרכת צוות
• תמיכה טכנית לאחר ההשקה — אחריות לחודש

שלבי יישום

1. ניתוח — אנו חוקרים את שרשרת ההזמנה-משלוח, מזהים נקודות כניסה (סטטוסים, שדות משתמש)
2. עיצוב — אנו בוחרים את האירוע, טבלת האחסון, שיטת יצירת PDF
3. יישום — אנו כותבים קוד, בודקים על הזמנת בדיקה
4. בדיקות — אנו מריצים משלוחים חלקיים, מלאים והחזרות
5. פריסה — אנו מעלים לסביבת הייצור, מגדירים רישום שגיאות
6. קבלה — אנו מציגים את התוצאה, מקבלים משוב

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

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

טעויות נפוצות וכיצד להימנע מהן

הטעות הנפוצה ביותר היא היעדר בדיקת הדגל SALE_NEW_ORDER. כתוצאה מכך, נוצר מסמך עבור משלוחים ללא מחיקות בפועל. אנו תמיד בודקים דגל זה לפני היצירה. בעיה נפוצה נוספת היא קריאת נתונים מ-tasks במקום מ-DEDUCTED במהלך משלוח חלקי. כמות הסחורה בעגלה עשויה להיות שונה מהכמות שנשלחה, ולכן אנו משתמשים בטבלת b_sale_basket. חשוב גם לקשור את תבנית המסמך לסוג המשלוח; אחרת, שירותי משלוח שונים יקבלו את אותו פורמט. רישום כל השגיאות הוא דרישת חובה לאבחון מהיר. בעומס גבוה, יש צורך בנעילה לפי מזהה הזמנה כדי למנוע יצירה כפולה.

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