טריגר התראה על הגעת מלאי ב-1C-Bitrix

הגדרת טריגר הגעת מלאי: התראה אוטומטית ב-1C-Bitrix

תארו לעצמכם: מוצר אזל מהמלאי, עשרות משתמשים לחצו על "עדכן אותי כשחוזר למלאי," המחסן התחדש, אבל אף אחד לא מקבל אימייל. הסיבה היא חוסר קישור בין אירוע החידוש לרשימת ההמתנה. במאמר זה, נפרק כיצד להגדיר טריגר הגעת מלאי ב-1C-Bitrix: מקטלוג פשוט ועד ניהול מלאי רב-מחסני עם אינטגרציית 1C. יישמנו מנגנונים כאלה על 30+ פרויקטים—נשתף תקלות אופייניות ופתרונות אופטימליים. לפי תיעוד Bitrix הרשמי, אירוע CATALOG_QUANTITY הוא כלי מפתח למעקב אחר שינויי מלאי. אבל הוא לבדו לא מספיק: צריך לטפל כראוי במנויים ובלוגיקת רב-מחסנים. הניסיון שלנו מראה שיישום נכון מקצר את זמן התגובה להגעת מלאי פי 3 בהשוואה לבדיקה ידנית.

איך עובד ניהול מלאי ב-Bitrix

ב-Bitrix, כמויות מוצרים נמצאות בשני מקומות בהתאם לתצורה. בקטלוג פשוט (ללא ניהול מלאי), שדה b_catalog_product בטבלת CCatalogProduct::Update() משמש. הוא מתעדכן ישירות דרך catalog או באמצעות סנכרון 1C. בניהול מלאי רב-מחסני (מודול קטלוג + מחסנים), נתונים נשמרים בטבלת b_catalog_store_product עם שדות PRODUCT_ID, STORE_ID, AMOUNT. הכמות הכוללת מסוכמת. במהלך סנכרון 1C דרך CommerceML, נתונים נכתבים ל-b_catalog_store_product. המטפל הסטנדרטי לשינויי מלאי הוא OnProductUpdate במודול הקטלוג. הוא מופעל בכל פעם שרשומה ב-catalog משתנה, כולל כמות. עם זאת, לניהול מלאי רב-מחסני זה לא מספיק—האירוע לא עוקב אחר שינויים לכל מחסן בנפרד. ההשוואה פשוטה: מטפל b_catalog_product עובד מיידית אבל רק על המלאי הכולל, בעוד סוכן (בודק כל 5 דקות) מכסה את כל המחסנים אבל עם עיכוב.

הנה דוגמה למטפל בסיסי:

AddEventHandler('catalog', 'OnProductUpdate', function($id, $fields) { if (isset($fields['QUANTITY']) && $fields['QUANTITY'] > 0) { // Товар поступил на склад — была нулевая позиция checkAndNotifyWaitlist($id); } }); 

בעיה: AddEventHandler('catalog', 'OnProductUpdate', function($id, $fields) { if (isset($fields['QUANTITY']) && $fields['QUANTITY'] > 0) { // Товар поступил на склад — была нулевая позиция checkAndNotifyWaitlist($id); } }); מופעל על כל שינוי במוצר, לא רק על חידוש מלאי. כדי לסנן ספציפית לאירוע "הגיע מאפס," צריך להשוות את הערך הקודם. לפני אירוע PHP, הנתונים עדיין ב-DB, אז קראו את הערך הישן ב-OnProductUpdate:

AddEventHandler('catalog', 'OnBeforeProductUpdate', function($id, &$fields) { $old = \Bitrix\Catalog\ProductTable::getByPrimary($id, ['select' => ['QUANTITY']])->fetch(); $fields['_OLD_QUANTITY'] = (float)($old['QUANTITY'] ?? 0); }); 

למה המטפל הסטנדרטי לא מתאים לניהול מלאי רב-מחסני

עם ניהול מלאי רב-מחסני, אירוע OnBeforeProductUpdate לא מופעל כאשר AddEventHandler('catalog', 'OnBeforeProductUpdate', function($id, &$fields) { $old = \Bitrix\Catalog\ProductTable::getByPrimary($id, ['select' => ['QUANTITY']])->fetch(); $fields['_OLD_QUANTITY'] = (float)($old['QUANTITY'] ?? 0); }); משתנה. לפעולות מחסן, צריך להירשם לאירועים ברמה עמוקה יותר במודול הקטלוג—או להשתמש ב-hook לאחר כתיבת מסמך מחסן דרך OnProductUpdate. גישה חלופית: סוכן שבודק b_catalog_store_product כל 5 דקות עבור כמויות שאינן אפס של מוצרים ברשימת ההמתנה. פחות אלגנטי, אבל עובד בצורה אמינה יותר עם סכמות עדכון מלאי לא סטנדרטיות (למשל, UPDATE ישיר דרך מחבר 1C). לפי הניסיון שלנו, סוכן מתמודד עם העומס ב-90% מהמקרים, בעוד מטפל מסמכים מגיב פי 10 מהר יותר אבל דורש יישום זהיר יותר.

השוואת גישות: סוכן מול מטפל מסמכים

איך לאחסן מנויים להתראות הגעה

למודול catalog אין מנגנון מובנה של "עדכן כשחוזר למלאי." צריך טבלה מותאמת אישית:

CREATE TABLE bl_stock_notify ( id SERIAL PRIMARY KEY, product_id INT NOT NULL, user_id INT, email VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT NOW(), notified_at TIMESTAMP, UNIQUE (product_id, email) ); 

הטופס באתר כותב לטבלה זו. המפתח הייחודי \Bitrix\Catalog\Document\DocumentTable מגן מפני כפילויות במנויים חוזרים.

מטפל חידוש מלאי

function checkAndNotifyWaitlist(int $productId): void { $connection = \Bitrix\Main\Application::getConnection(); $waitlist = $connection->query( "SELECT * FROM bl_stock_notify WHERE product_id = {$productId} AND notified_at IS NULL" )->fetchAll(); if (empty($waitlist)) { return; } $product = \CIBlockElement::GetByID($productId)->GetNextElement(); $name = $product->GetField('NAME'); $url = $product->GetField('DETAIL_PAGE_URL'); foreach ($waitlist as $row) { \Bitrix\Main\Mail\Event::send([ 'EVENT_NAME' => 'STOCK_ARRIVED', 'LID' => SITE_ID, 'C_FIELDS' => [ 'EMAIL' => $row['email'], 'PRODUCT_NAME' => $name, 'PRODUCT_URL' => 'https://' . $_SERVER['SERVER_NAME'] . $url, ], ]); $connection->queryExecute( "UPDATE bl_stock_notify SET notified_at = NOW() WHERE id = {$row['id']}" ); } } 

השוואת גישות: קטלוג פשוט מול ניהול מלאי רב-מחסני

מה כלול: תוצרים

• פיתוח והתקנה של מטפלי (product_id, email) ו-function checkAndNotifyWaitlist(int $productId): void { $connection = \Bitrix\Main\Application::getConnection(); $waitlist = $connection->query( "SELECT * FROM bl_stock_notify WHERE product_id = {$productId} AND notified_at IS NULL" )->fetchAll(); if (empty($waitlist)) { return; } $product = \CIBlockElement::GetByID($productId)->GetNextElement(); $name = $product->GetField('NAME'); $url = $product->GetField('DETAIL_PAGE_URL'); foreach ($waitlist as $row) { \Bitrix\Main\Mail\Event::send([ 'EVENT_NAME' => 'STOCK_ARRIVED', 'LID' => SITE_ID, 'C_FIELDS' => [ 'EMAIL' => $row['email'], 'PRODUCT_NAME' => $name, 'PRODUCT_URL' => 'https://' . $_SERVER['SERVER_NAME'] . $url, ], ]); $connection->queryExecute( "UPDATE bl_stock_notify SET notified_at = NOW() WHERE id = {$row['id']}" ); } } עם בדיקת מעבר "0 → N".
• יצירת טבלת OnProductUpdate ואינטגרציית טופס המנוי באתר.
• הגדרת תבנית האימייל b_catalog_product בלוח הניהול.
• לתצורות רב-מחסניות: יישום סוכן או מטפל מסמכי מחסן.
• לוגיקת חידוש חלקי: בחירת אסטרטגיה (הודע לכולם או ברצף).
• תיעוד גישה ובדיקות בסביבת staging.
• תמיכה ל-14 יום לאחר ההשקה.

תהליך

1. ניתוח: לימוד תצורת Bitrix הנוכחית שלך, סכמת סנכרון 1C, עומס מסד נתונים.
2. עיצוב: בחירת השיטה האופטימלית (מטפלים או סוכן), הסכמה על לוגיקת תור ההתראות.
3. יישום: כתיבת קוד, יצירת טבלת SQL, הגדרת אירועי אימייל.
4. בדיקות: אימות על עותק קטלוג, סימולציית הגעת מלאי, מעקב אחר שליחת אימיילים.
5. פריסה וניטור: מעבר לסביבת production, רישום טריגרים ראשונים.