פיתוח אתרי אירועים ב-1C-Bitrix: כרטיסים, QR, CRM, אזור אישי

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

אילו בלוקי מידע מינימליים נדרשים?

אתר אירועים דורש לפחות ארבעה בלוקי מידע. אפשר להסתפק בשלושה על ידי הדבקת לוח הזמנים לאירועים, אבל ברגע שמפעילים כנסים רב-יומיים עם מסלולים מקבילים, הגישה הזו נשברת.

בלוק מידע אירועים (סוג events) — הישות הראשית.

מאפיינים: DATE_START, DATE_END (סוג 'Date/Time', חייב להיות מאונדקס על b_iblock_element_property), VENUE (קישור ל-Highload-block של מקומות), CAPACITY (נבדק ב-OnSaleOrderBeforeSaved), STATUS (רשימת מצבים), STREAM_URL (נגיש לאחר תשלום), SCHEMA_ORG (שדה מחושב עבור JSON-LD).

בלוק מידע דוברים — נפרד, עם קישור מרובה לאירועים. מכיל תמונה, ביוגרפיה, חברה, תפקיד וקישורים חברתיים.

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

בלוק מידע כרטיסים — מוצרים של קטלוג המסחר האלקטרוני. כל סוג כרטיס הוא אלמנט נפרד עם מאפיינים EVENT_ID, TICKET_TYPE, AVAILABLE_SEATS, VALID_UNTIL.

למה לא Highload-blocks? עבור דוברים ולוח זמנים נפח הנתונים קטן, ובלוקי מידע מספקים רכיבים מוכנים ועורך ויזואלי. Highload מוצדק עבור מקומות (500+ רשומות) ויומני צ'ק-אין.

איך לארגן מכירת כרטיסים ב-Bitrix?

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

מוצר = אלמנט של אינפובלוק 'כרטיסים' המחובר לקטלוג המסחר האלקטרוני. כל סוג כרטיס לכל אירוע הוא מוצר נפרד. כנס ל-500 איש עם שלושה סוגי כרטיסים משמעו שלושה מוצרים, שלכל אחד מהם מלאי מחסן משלו.

חשבונאות מחסן מפחיתה אוטומטית את המלאי כאשר פריט מתווסף לעגלה. כאשר המלאי מגיע לאפס, כפתור 'קנה' מוחלף ב'אזל מהמלאי' — נבדק באמצעות CCatalogProduct::GetByID() בתבנית.

תהליך ההזמנה כולל שלב מותאם אישית עם שדות משתתף, תשלום דרך YooKassa, Stripe או PayPal, ואירוע OnSalePaymentEntitySaved שמייצר קוד QR ושולח דוא"ל. קודי קופון מיושמים דרך catalog.discount עם תנאי קוד קופון.

המטפל OnSaleOrderBeforeSaved דוחה את ההזמנה אם אין מקומות. הזמנה נוספת: הפחתת QUANTITY בעת הוספה לעגלה עם שחרור לאחר 30 דקות באמצעות סוכן. סוכני 1С-Битрикс במקרה זה משחררים את ההזמנה. זה מונע מכירה כפולה בעומס גבוה.

חשבון אישי והתראות

עבור אירועים בחינם — רכיב מותאם אישית שכותב ל-Highload-block ויוצר ליד ב-CRM דרך REST API. עבור אירועים בתשלום — הרשמה אוטומטית עם התשלום.

חשבון אישי של משתתף מבוסס על sale.personal.section עם תבנית מותאמת אישית: רשימת אירועים, היסטוריית הזמנות, הורדת כרטיס PDF עם QR, גישה לשידור (הקישור מופיע 30 דקות לפני ההתחלה), תעודת משתתף.

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

התראות דוא"ל דרך מודול 'subscribe': אישור הרשמה, כרטיס לאחר תשלום (עם PDF), תזכורת 24 שעות (סוכן), שינוי בלוח הזמנים (מטפל OnAfterIBlockElementUpdate).

SEO ולוח שנה

Schema.org Event — ב-result_modifier.php אנו מייצרים סימון JSON-LD עם השדות name, startDate, location, offers, performer. השדה availability מתחלף באופן דינמי בין InStock ל-SoldOut.

לוח שנה לאירועים: קומפוננטה מותאמת אישית + FullCalendar.js — אינטראקטיבי, נשמר במטמון, נטען פי 3 מהר יותר מהסטנדרטי עם 50 אירועים. עבור רשימות פשוטות מספיק ה-iblock.element.list הסטנדרטי.

אילו שלבים כוללת פיתוח אתר לאירועים?

התהליך מחולק לשבעה שלבים: תכנון (1–2 שבועות), עיצוב (1–2), backend‏ (2–4), frontend‏ (2–3), אינטגרציות (1–2), בדיקות (1–2), השקה (3–5 ימים). לוחות הזמנים המשוערים תלויים בהיקף:

מה כלול בעבודה

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