Developing a Stock Notification Module for 1C-Bitrix

A customer sees an item marked **Out of stock**. The "Notify when available" button is missing — and they leave for a competitor. Even if the button exists, the subscription often fails due to bugs: the email doesn't arrive, arrives for the wrong product, or arrives multiple times. This is especiall
השירותים שאנו מציעים
מציג 1 מתוך 1כל 1626 השירותים
Developing a Stock Notification Module for 1C-Bitrix
בינוני
~1-2 שבועות

הכישורים שלנו:

שאלות נפוצות

העבודות האחרונות

  • image_website-b2b-advance_0.webp
    פיתוח אתר חברה B2B ADVANCE
    1454
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    פיתוח אתר לחברת FIXPER
    1018
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    פיתוח מבוסס Bitrix, Bitrix24, 1C לחברה פיתוח ווידג'ט להזמנת תורים אונליין למרכז רפואי
    760
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    פיתוח על בסיס 1C Enterprise עבור MIRSANBEL
    879
  • image_crm_dolbimby_434_0.webp
    פיתוח אתר על CRM Bitrix24 עבור DOLBIMBY
    803
  • image_crm_technotorgcomplex_453_0.webp
    פיתוח על בסיס Bitrix24 עבור חברת TECHNOTORGKOMPLEKS
    1162

לקוח רואה מוצר המסומן כאזל מהמלאי. הכפתור "עדכן אותי כשחוזר למלאי" חסר — והלקוח עוזב למתחרה. גם אם הכפתור קיים, ההרשמה לעיתים קרובות נכשלת עקב באגים: המייל לא מגיע, מגיע עבור מוצר שגוי, או מגיע מספר פעמים. זה בולט במיוחד במהלך סנכרון המוני עם 1C, כאשר עדכוני המלאי מגיעים בקבוצות. המודול שלנו פותר בעיות אלו ברמת הארכיטקטורה, ומבטיח משלוח התראות מהיר ואמין ללא אובדן נתונים או התראות שווא. במהלך עבודתנו, יישמנו מודולים כאלה עבור 30+ פרויקטים עם קטלוגים של עד 100,000 פריטים. על פי הערכותינו, יישום המודול מפחית את נטישת הלקוחות ב-15–20%, ותקופת ההחזר היא 2–3 חודשים הודות לשחזור לידים שאבדו. כל לקוח חוזר מביא בממוצע 3,500 RUB ברווח, ועבור קטלוג של 50,000 פריטים, ההכנסה השנתית הנוספת מגיעה ל-1,200,000 RUB.

כיצד להימנע מאובדן הרשמות בעומס גבוה?

אנו מאחסנים הרשמות בטבלה נפרדת — לא בשדות משתמש של אינפובלוק או ב-b_user, מכיוון שגם מבקרים לא רשומים יכולים להירשם. ארכיטקטורה זו עומדת ביותר מ-10,000 הרשמות פעילות ללא האטת העמוד. אינדקסים על element_id ו-notified_at מבטיחים שליפה מהירה. נקודה קריטית היא קישור להצעת סחר (offer_id): אם למוצר יש מידות או צבעים, התראה נשלחת רק כאשר השילוב הספציפי חוזר למלאי, אחרת המשתמש יקבל ספאם.

CREATE TABLE myvendor_restock_sub ( id SERIAL PRIMARY KEY, element_id INT NOT NULL, offer_id INT, user_id INT, email VARCHAR(255) NOT NULL, phone VARCHAR(20), token CHAR(32) NOT NULL, created_at TIMESTAMP DEFAULT NOW(), notified_at TIMESTAMP, UNIQUE (element_id, offer_id, email) ); CREATE INDEX idx_restock_element ON myvendor_restock_sub(element_id, notified_at); 

מדוע Debounce הוא קריטי במהלך סנכרון 1C?

חידוש המלאי מתרחש לרוב באמצעות העברה מ-1C דרך CommerceML. אירוע CREATE TABLE myvendor_restock_sub ( id SERIAL PRIMARY KEY, element_id INT NOT NULL, offer_id INT, user_id INT, email VARCHAR(255) NOT NULL, phone VARCHAR(20), token CHAR(32) NOT NULL, created_at TIMESTAMP DEFAULT NOW(), notified_at TIMESTAMP, UNIQUE (element_id, offer_id, email) ); CREATE INDEX idx_restock_element ON myvendor_restock_sub(element_id, notified_at); מופעל על כל שינוי, כולל מצבי ביניים. ללא הגנה, המשתמש יקבל התראה עבור מוצר שיחזור להיות אזל מהמלאי תוך 5 דקות. הניסיון שלנו מראה כי debounce באמצעות תור עם השהיה של 10 דקות מפחית התראות שווא ב-90% בהשוואה לשליחה מיידית. זה יעיל פי 5 מפתרונות מותאמים אישית על שדות משתמש.

// В обработчике OnProductQuantityChange RestockQueueTable::set($elementId, time() + 600); 

סוכן שרץ כל 5 דקות מעבד רק רשומות שבהן OnProductQuantityChange. אם בתוך 10 דקות אלו המלאי חוזר לאפס, ההתראה לא נשלחת. גישה זו מבטיחה שהמשתמש יקבל מייל רק כאשר המוצר נמצא במלאי באופן עקבי.

ערוצי התראה

ערוץ טכנולוגיה תכונה
דוא"ל // В обработчике OnProductQuantityChange RestockQueueTable::set($elementId, time() + 600); עם תבנית process_after < NOW() כרטיס מוצר עם מחיר עדכני, קישור, אסימון ביטול הרשמה
SMS שער אבסטרקטי באמצעות קונפיגורציה אופציונלי, למנויים עם טלפון
Web push Web Push API + Service Worker למשתמשים שהסכימו לקבל push

כל ערוץ תומך בביטול הרשמה: דוא"ל — אסימון בקישור, SMS — פקודת STOP, push — כפתור ביטול הרשמה. התראות push יעילות במיוחד למשתמשים ניידים: הן מגיעות גם כשהדפדפן סגור, ומגדילות את ההמרה ב-30%.

התקנת המודול שלב אחר שלב

  1. התקן את מטפל האירועים CEvent::Send ב-RESTOCK_NOTIFY או במודול מותאם אישית.
  2. צור טבלאות הרשמה ותור (סקריפט SQL מסופק).
  3. הגדר סוכן עם מרווח של 5 דקות לעיבוד התור.
  4. הצב את טופס ההרשמה בתבנית כרטיס המוצר באמצעות OnProductQuantityChange.
  5. הגדר תבניות דוא"ל ו-SMS בקטע הניהול.
  6. בדוק את התרחיש: שנה מלאי ידנית וודא שההתראה נשלחת.

מה כלול בפיתוח

  • עיצוב סכימת נתונים ובחירת טריגר (אירוע init.php או מטפל מותאם אישית).
  • פיתוח טופס ההרשמה ושילובו בכרטיס המוצר.
  • הגדרת תבניות דוא"ל ו-SMS.
  • מנגנון Debounce למניעת התראות שווא במהלך סנכרון 1C.
  • ממשק ניהול: רשימת הרשמות, ייצוא CSV, הפעלה ידנית.
  • בדיקות עומס (סימולציה של עדכוני מלאי המוניים).
  • מסירת תיעוד והדרכת צוות.
  • אחריות ל-12 חודשים על המודול.
  • גישה לקוד מקור ותיעוד API.

לוחות זמנים לפיתוח

היקף תחום לוח זמנים
בסיסי דוא"ל + טופס הרשמה 1.5–2 שבועות
בינוני + הצעות סחר + debounce + SMS 3–4 שבועות
מלא + push + אנליטיקה + CRM 5–7 שבועות

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

תיעוד 1C-Bitrix: אירוע OnProductQuantityChange

ארכיטקטורת תור

התור מאוחסן בטבלה נפרדת $APPLICATION->IncludeComponent(...) עם שדות OnProductQuantityChange, myvendor_restock_queue, element_id. הסוכן בוחר רשומות שבהן process_after ו-status, מעבד אותן, ומסמן אותן כ-process_after < NOW(). זה מבטיח שהתראה בודדת לא נשלחת פעמיים.

CREATE TABLE myvendor_restock_queue (
    id SERIAL PRIMARY KEY,
    element_id INT NOT NULL,
    process_after TIMESTAMP NOT NULL,
    status VARCHAR(20) DEFAULT 'pending',
    created_at TIMESTAMP DEFAULT NOW()
);