Розробка сайту заходів на 1С-Бітрікс — це побудова транзакційної системи: реєстрація, продаж квитків, генерація QR-кодів, особистий кабінет, інтеграція з CRM і платіжними шлюзами. Помилка на старті, наприклад зберігання доповідачів, розкладу та квитків в одному інфоблоці, призводить до болючої міграції даних через півроку, коли запускається другий захід. Ми вирішуємо ці проблеми, спираючись на багаторічний досвід та перевірені архітектурні рішення.
Які мінімальні інфоблоки потрібні?
Для сайту заходів потрібні мінімум чотири інфоблоки. Можна обійтися трьома, склеївши розклад з заходами — але при появі багатоденних конференцій з паралельними потоками це рішення розвалюється.
Інфоблок «Заходи» (тип events) — основна сутність. Властивості: DATE_START, DATE_END (тип «Дата/час», обов'язковий індекс на b_iblock_element_property), VENUE (прив'язка до Highload-блоку майданчиків), CAPACITY (перевіряється в OnSaleOrderBeforeSaved), STATUS (список станів), STREAM_URL (доступ після оплати), SCHEMA_ORG (обчислюване поле для JSON-LD).
Інфоблок «Спікери» — окремий, з множинною прив'язкою до заходу. Містить фото, біо, компанію, посаду та посилання на соцмережі.
Інфоблок «Розклад» — кожен елемент = слот з часом, прив'язкою до заходу та спікера, типом (доповідь, воркшоп, перерва).
Інфоблок «Квитки» — товари торгового каталогу. Кожен тип квитка — окремий елемент з властивостями EVENT_ID, TICKET_TYPE, AVAILABLE_SEATS, VALID_UNTIL.
Чому не Highload-блоки? Для спікерів і розкладу даних мало, а інфоблоки дають готові компоненти та візуальний редактор. Highload виправданий для майданчиків (500+ записів) і логів check-in.
Як організувати продаж квитків на Бітрікс?
Це центральна і найскладніша частина. Квиток — товар у каталозі, але з нестандартною логікою: прив'язка до дати, іменні, обмежені за кількістю.
Товар = елемент інфоблоку «Квитки», підключеного до торгового каталогу. Кожен тип квитка на кожен захід — окремий товар. Конференція на 500 осіб з трьома типами квитків — три товари, кожен зі своїм залишком на складі.
Складський облік автоматично зменшує залишок при додаванні в кошик. Коли залишок = 0, кнопка «Купити» замінюється на «Квитки розпродано» — перевірка через CCatalogProduct::GetByID() у шаблоні.
Процес оформлення замовлення включає кастомний крок з полями учасника, оплату через ЮKassa, Stripe або PayPal, і подію OnSalePaymentEntitySaved, яка генерує QR-код і надсилає email. Промокоди реалізуються через catalog.discount з умовою за промокодом.
Обробник OnSaleOrderBeforeSaved відхиляє замовлення, якщо місць немає. Додаткове резервування — зменшення QUANTITY при додаванні в кошик з поверненням через 30 хвилин по агенту. 1С-Бітрікс: Агенти у цьому випадку знімають резерв. Це запобігає подвійним продажам при високому навантаженні.
Особистий кабінет і сповіщення
Для безкоштовних заходів — кастомний компонент із записом у Highload-блок і створенням ліда в CRM через REST API. Для платних — автоматична реєстрація при оплаті.
Особистий кабінет учасника на sale.personal.section з кастомним шаблоном: список заходів, історія замовлень, завантаження PDF-квитка з QR-кодом, доступ до трансляції (посилання з'являється за 30 хвилин до початку), сертифікат учасника.
Таймер зворотного відліку — JS на setInterval з серверним часом. Трансляція — компонент з перевіркою доступу: авторизація, оплачений квиток, час. При невідповідності — редирект на покупку.
Email-сповіщення через модуль 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), бекенд (2–4), фронтенд (2–3), інтеграції (1–2), тестування (1–2), запуск (3–5 днів). Орієнтовні терміни залежать від масштабу:
| Масштаб проєкту | Орієнтовні терміни |
|---|---|
| Один захід, реєстрація без оплати | 3–5 тижнів |
| Захід з продажем квитків та QR | 6–9 тижнів |
| Платформа серії заходів з особистим кабінетом | 8–12 тижнів |
Що входить в роботу
| Етап | Результат |
|---|---|
| Аналіз вимог | Технічне завдання, прототип |
| Проектування архітектури | Схема інфоблоків, HL-блоків, агентів |
| Розробка компонентів | Бекенд-логіка, шаблони, API |
| Інтеграції | Платіжні системи, CRM, 1С, СДЕК |
| Генерація QR | Бібліотека endroid/qr-code |
| Check-in | Вхід по QR, верифікація |
| Тестування | Навантажувальне (імітація 500 покупок) |
| Документація та навчання | Адміністративна інструкція |
| Гарантійна підтримка | 1 місяць після запуску |
Автоматизація продажу квитків окупається вже після двох заходів за рахунок скорочення ручної праці. Отримайте консультацію з архітектури вашого сайту заходів — наші інженери підберуть оптимальну структуру інфоблоків та інтеграцій. Зв'яжіться з нами, щоб обговорити ваш проєкт.