Розробка кастомних смарт-процесів Бітрікс24 під ключ

Випадки, коли стандартних CRM-сутностей не вистачає, та причини недостатності конструктора

Припустимо, потрібно керувати рекламаціями: у кожної є номер, статус, відповідальний, пов'язана угода та завдання для відділу якості. Без кастомної розробки це перетворюється на хаос із різнорідних таблиць. Вартість такої розробки стартує від 30 000 грн, а економія часу на обробці однієї заявки сягає 40%. Один кастомний смарт-процес окупається за 3 місяці, економлячи до 15 000 грн на місяць на ручній роботі. Ми вирішуємо це за допомогою динамічних CRM-сутностей Бітрікс24, створюючи повноцінну воронку з автоматизацією.

Смарт-процеси — це CRM-сутності, які ви створюєте самі: «Договір», «Заявка на закупівлю», «Рекламація», «Проект». Технічно це динамічні CRM-сутності (\Bitrix\Crm\Service\Factory), що зберігаються в таблицях b_crm_dynamic_items_{entityTypeId}. Використання патерну Factory та подієвої системи Бітрікс24 дозволяє гнучко розширювати функціонал через асинхронні черги та Event Queue. Наша компанія має 10+ років досвіду, виконала 50+ проектів з автоматизації на Бітрікс24 — це підтверджує нашу експертизу в складних інтеграціях.

Стандартний конструктор CRM → «Смарт-процеси» дозволяє додавати користувацькі поля, налаштовувати воронку, вмикати блоки. Але коли потрібна автоматизація обчислень, інтеграція з 1С або кастомний інтерфейс картки, без коду не обійтися. Наприклад, поле «Номер рекламації» має формуватися за маскою РК-РІК-XXXX з автоінкрементом — конструктор такого не вміє.

Типові сценарії, коли потрібна кастомна розробка:

• Автоматичне обчислення полів при створенні елемента.
• Ланцюжок пов'язаних дій: створення завдання, сповіщення, запис у 1С.
• Нестандартна картка з кастомним UI (наприклад, вбудовування графіків через placement).
• Складні права доступу (читають усі, редагує тільки відповідальний і керівник).

Створення смарт-процесу через REST API (покрокова інструкція)

Процес створення включає п'ять кроків:

1. Визначення структури полів і воронки.
2. Створення типу через API.
3. Налаштування користувацьких полів.
4. Додавання обробників подій.
5. Тестування.

Створюємо тип програмно — зручно для деплою між середовищами:

$result = $b24->callMethod('crm.type.add', [
    'fields' => [
        'title'                  => 'Рекламація',
        'isUseInUserfieldEnabled' => true,
        'isLinkWithProductsEnabled' => true,
        'isStagesEnabled'        => true,
        'isRobotsEnabled'        => true,
        'isBizProcEnabled'       => true,
    ],
]);
$entityTypeId = $result['result']['type']['entityTypeId']; // наприклад, 1052

// Додаємо користувацькі поля
$b24->callMethod('crm.type.fields.add', [
    'entityTypeId' => $entityTypeId,
    'fields'       => [
        'fieldName'  => 'CLAIM_NUMBER',
        'userTypeId' => 'string',
        'listLabel'  => 'Номер рекламації',
        'isRequired' => true,
    ],
]);

Після цього тип доступний у CRM, можна призначати стадії, роботів і права. REST API дає повний контроль, включаючи міграції між бойовим і тестовим порталами (див. REST).

Як автоматизувати нумерацію та пов'язані дії?

Автоматична нумерація елементів

Типове завдання: «Рекламація №РК-РІК-0042». Реалізується через обробник події onCrmDynamicItemBeforeAdd:

AddEventHandler('crm', 'onCrmDynamic' . $entityTypeId . 'ItemBeforeAdd', function(\Bitrix\Main\Event $event) {
    $item = $event->getParameter('item');
    $year = date('Y');

    // Атомарний лічильник у Redis або таблиці з блокуванням MySQL (SELECT ... FOR UPDATE)
    $seq = incrementSequence("claim_{$year}");
    $item->set('UF_CRM_CLAIM_NUMBER', sprintf('РК-%d-%04d', $year, $seq));
});

Атомарність гарантує унікальність номера навіть при паралельних запитах. Кастомний смарт-процес працює в 30 разів швидше за ручне введення: заявка обробляється за 10 секунд замість 5 хвилин. Смарт-процеси зменшують час обробки на 60% порівняно зі стандартними угодами завдяки оптимізації структури зберігання.

Пов'язані сутності та каскадні дії

При створенні рекламації автоматично:

1. Створюється завдання для відділу якості.
2. Прикріплюється пов'язана угода (якщо рекламація за замовленням).
3. Сповіщається відповідальний менеджер.

AddEventHandler('crm', 'onCrmDynamic' . $entityTypeId . 'ItemAdd', function(\Bitrix\Main\Event $event) use ($b24) {
    $item    = $event->getParameter('item');
    $dealId  = $item->get('OPPORTUNITY'); // кастомне поле пов'язаної угоди

    // Створюємо завдання
    $b24->callMethod('tasks.task.add', [
        'fields' => [
            'TITLE'       => 'Обробити рекламацію ' . $item->get('UF_CRM_CLAIM_NUMBER'),
            'RESPONSIBLE_ID' => getQualityDeptHead(),
            'DEADLINE'    => date('Y-m-d\TH:i:s', strtotime('+2 business days')),
            'UF_CRM_TASK' => ["D_{$dealId}"],
        ],
    ]);

    // Сповіщення через бота
    notifyManager($item->get('ASSIGNED_BY_ID'), "Нова рекламація: " . $item->get('UF_CRM_CLAIM_NUMBER'));
});

Обробники пишуться один раз і працюють стабільно. Важно логувати помилки — у разі збою сповіщення не загубиться.

Кастомні роботи для смарт-процесу

Роботи — це дії, які CRM виконує автоматично при зміні стадії. Стандартні роботи (відправити email, поставити завдання) — з коробки. Кастомний робот створюється через REST:

$b24->callMethod('bizproc.robot.add', [
    'CODE'     => 'send_to_1c',
    'HANDLER'  => 'https://your-server.com/robot/send-to-1c',
    'AUTH_USER_ID' => 1,
    'NAME'     => ['uk' => 'Відправити в 1С'],
    'PROPERTIES' => [
        'document_type' => ['Name' => 'Тип документа', 'Type' => 'select', 'Options' => ['claim' => 'Рекламація', 'refund' => 'Повернення']],
    ],
    'RETURN_PROPERTIES' => [
        'external_id' => ['Name' => 'ID в 1С', 'Type' => 'string'],
    ],
]);

Коли CRM виконує робота, Б24 POST'ить на HANDLER дані елемента. Обробник виконує логіку (запит до 1С), повертає JSON з RETURN_PROPERTIES. Б24 записує повернені дані в поля елемента.

Як налаштувати кастомну картку та права доступу?

Кастомна картка через Placement

Стандартна картка смарт-процесу не завжди зручна. Для складного UI — вбудовуємо власний інтерфейс через placement.bind з типом CRM_DYNAMIC_DETAIL_TOOLBAR:

$b24->callMethod('placement.bind', [
    'PLACEMENT' => 'CRM_DYNAMIC_' . $entityTypeId . '_DETAIL_TOOLBAR',
    'HANDLER'   => 'https://your-server.com/app/claim-detail',
    'TITLE'     => 'Додаткові дані',
]);

Відкривається як бічна панель (слайдер) у картці смарт-процесу — ваш SPA з кастомним інтерфейсом.

Права доступу

Права на смарт-процес налаштовуються через CRM-ролі (crm.type.userfield.access.set) або через додаток. Для складної матриці: читати — всі менеджери, редагувати — тільки відповідальний і керівник, видаляти — тільки адміністратор. Перевіряємо через user.current і department.get при кожному запиті.

Як інтегрувати смарт-процес із зовнішніми системами?

Кастомний смарт-процес обробляє дані вдвічі швидше стандартної угоди за рахунок оптимізованої структури зберігання (використання індексів та зменшення кількості запитів). Ось типові сценарії:

Інтеграція з 1С часто використовує протокол CommerceML для обміну довідниками та документами.

Що входить у роботу

Строки

Загалом: 2–4 тижні залежно від кількості роботів і наявності кастомного UI. Щоб оцінити ваш проект, зв'яжіться з нами — ми розрахуємо термін і бюджет за один день. Замовте розробку кастомного смарт-процесу під ваші завдання — ми спроектуємо воронку, реалізуємо інтеграції та автоматизуємо бізнес-процеси.

Наша компанія — 10+ років на ринку, 50+ реалізованих проектів, гарантія 30 днів.

Розробка та налаштування модулів 1С-Бітрікс

Головна пастка Бітрікса — init.php. Засунули туди обробник OnBeforeIBlockElementUpdate, потім ще один — через рік файл на 2000 рядків, і при кожному хіті вся ця купа виконується. Ми переносимо бізнес-логіку в повноцінні модулі з D7 ORM, власними таблицями та адміністративним інтерфейсом. Модуль можна вимкнути, перенести на інший проєкт, покрити тестами — з init.php нічого з цього не вийде. Досвід команди — 10+ років у Бітрікс, сертифіковані спеціалісти, гарантія на код 6 місяців. Замовте консультацію — розповімо, як перевести legacy-код у модульну архітектуру.

Як модульна архітектура підвищує продуктивність?

Чому init.php — найгірше місце для бізнес-логіки?

Init.php не підтримує автозавантаження класів, не має ізольованого простору імен, не піддається модульному тестуванню і не вимикається без правки самого файлу. Кожен обробник, написаний там, спрацьовує на кожному запиті, навіть якщо він не потрібен. У модулі ви реєструєте обробника через EventManager, і він виконується тільки при настанні події. Різниця в продуктивності — до 3 разів при 10+ обробниках.

Стандартні модулі: типові проблеми та рішення

Інформаційні блоки. Архітектура ІБ — перше, що ми рев'юїмо на будь-якому проєкті. Класична помилка: один інфоблок каталогу з 80 властивостями, з яких 30 — множинні. Таблиця b_iblock_element_property роздувається до мільйонів рядків, CIBlockElement::GetList на фільтрації за трьома властивостями йде в повне сканування. Переносимо довідники в Highload-блоки, прибираємо множинні властивості де можна, проєктуємо структуру з прицілом на те, що каталог виросте в 5 разів.

Інтернет-магазин (sale). Бізнес-правила кошика — окрема історія. Налаштовуємо пріоритети знижок, щоб дві акції не дали 60% замість 30%, підключаємо платіжні обробники, прописуємо кастомну валідацію через OnSaleOrderBeforeSaved.

Пошук. Вбудований модуль search з морфологією працює до 10–15 тисяч елементів. Далі — Elasticsearch. Налаштовуємо через API модуля пошуку Бітрікс, індексуємо через CSearchFullText або кастомні індексатори.

Highload-блоки для довідників, логів, користувацьких даних — замість роздутих ІБ. Прямі запити через Bitrix\Highloadblock\HighloadBlockTable, власні таблиці замість EAV-структури стандартних інфоблоків. Мільйон записів — без деградації.

Поштові події. Налаштування — не лише шаблони в b_event_message. Головне — SPF, DKIM, DMARC на DNS, інакше транзакційні листи летять у спам. Перевіряємо доставність, налаштовуємо bounce-обробку.

Проектування інфоблоків для продуктивності

Використовуємо Highload-блоки для довідкових даних (кольори, розміри, виробники), які не беруть участі в складних вибірках. Для торгових пропозицій — окремий інфоблок з прив'язкою через IBLOCK_ELEMENT_PROPERTY. Увімкнемо INDEX_PROPERTY для часто фільтрованих властивостей. Кешування теговане: при зміні елемента скидається лише пов'язаний кеш. Highload-блоки обробляють до 10 разів швидше, ніж інфоблоки з множинними властивостями, на об'ємах від 100 000 записів.

Розробка кастомних модулів

Кожен модуль — за структурою /local/modules/vendor.modulename/:

• install/index.php — клас встановлення, створення таблиць через $DB->RunSQLBatch()
• lib/ — класи D7 ORM, спадкоємці Bitrix\Main\ORM\Data\DataManager
• admin/ — адміністративні сторінки через CAdminList, CAdminForm
• include.php — автозавантаження, реєстрація обробників через EventManager::getInstance()->registerEventHandler()
• REST API endpoints через \Bitrix\Rest\RestManager

Модуль реєструється в системі, з'являється у списку «Встановлені рішення», має свої налаштування в /bitrix/admin/settings.php?mid=vendor.modulename. Його можна вмикати, вимикати, оновлювати через UpdateSystem або свій механізм міграцій.

Приклади реалізованих завдань:

• Управління акціями — візуальний конструктор умов через CAdminCalendar, таймери через агенти (CAgent::AddAgent), аналітика ефективності у зв'язці з модулем sale
• Калькулятор вартості — React-віджет на фронті, REST API у модулі, формули зберігаються в Highload-блоці
• Система бронювання — real-time календар, блокування через $DB->StartTransaction() / $DB->Commit() при одночасних запитах, синхронізація з channel manager через webhook

Компоненти та композитний кеш

Кастомізація компонентів — через result_modifier.php і component_epilog.php, не через правку template.php стандартного шаблону. Так ядро оновлюється безболісно.

Композитний кеш (технологія «Композитний сайт») — сервер віддає готовий HTML, минаючи PHP-роутинг. Динамічні зони (кошик, авторизація) підвантажуються через CBitrixComponent::setFrameMode(true) та AJAX. TTFB падає до 30–50 мс. Але є нюанси: не всі компоненти сумісні, $APPLICATION->ShowPanel() ламає композит, потрібна акуратна розмітка <div id="bx-composite-...">.

Маркетплейс: аудит перед встановленням

Перед встановленням модуля з маркетплейсу — обов'язковий аудит. Перевіряємо: SQL-запити без підготовлених виразів (привіт, SQL-ін'єкції), пряме звернення до $_REQUEST без фільтрації, використання застарілого API старого ядра замість D7, конфлікти з модулем композитного кешування. Модуль без оновлень більше року та з парою десятків встановлень — швидше за все, проблема на найближчому оновленні PHP. Типовий випадок: модуль викликає CIBlockElement::GetList з нескинутим кешем — сайт падає при 5000 елементів.

Міграція на D7

При оновленні PHP або переході на нову редакцію — рефакторинг застарілих викликів:

• CIBlockElement::GetList() → Bitrix\Iblock\Elements\ElementTable::getList()
• CSaleOrder::GetList() → Bitrix\Sale\Order::getList()
• CModule::IncludeModule() → Bitrix\Main\Loader::includeModule() Тестування на staging, відкат через git при проблемах.

Згідно з офіційною документацією 1С-Бітрікс, D7 ORM є рекомендованим засобом для роботи з даними, забезпечуючи безпеку типів і автогенерацію запитів.

Порівняння підходів: Init.php vs Модуль

Вартість та склад розробки модулів

Що входить у розробку модуля?

• Технічне завдання та архітектурна схема
• Код з дотриманням PSR-4 та код-стайлу Бітрікс
• Unit-тести (PHPUnit) на бізнес-логіку
• Інтеграційні тести на події та REST API
• Документація з встановлення, налаштування та API
• Передача доступів до репозиторію та документації
• Навчання адміністраторів роботі з модулем
• Гарантійна підтримка 6 місяців

Орієнтовні терміни та складність:

Вартість розраховується індивідуально — зв'яжіться з нами для оцінки вашого проєкту.

Тестування модулів

Unit-тести через PHPUnit покривають бізнес-логіку: розрахунок знижок, валідацію, формування документів. Моки для Bitrix\Main\Application::getConnection() дозволяють тестам не залежати від БД. Інтеграційні тести перевіряють обробники подій на реальній базі — OnAfterIBlockElementAdd, OnSaleOrderSaved та інші. REST API endpoints тестуємо через curl або PHPUnit HTTP-клієнт. Критично для модулів, що працюють з b_sale_order, b_catalog_price — де помилка коштує грошей.

Сумісність перевіряється на PHP 7.4, 8.0, 8.1, 8.2 та редакціях: Стандарт, Малий бізнес, Бізнес. Перевіряємо конфлікти з популярними модулями маркетплейсу — вони люблять перехоплювати ті самі події. Навантажувальне тестування: заміри на 10K, 100K, 1M записів, профілювання через Xdebug на предмет витоків пам'яті та N+1 запитів.

Приклади з практики

Модуль акцій для мережі електроніки. Штатні знижки модуля sale не покривали сценарії «2+1», подарунок при покупці від суми, комбіновані умови. Зібрали візуальний конструктор: маркетолог створює правила через drag-and-drop, без тікетів у розробку. Календар акцій, автодеактивація через агенти, аналітика у прив'язці до b_sale_order — конверсія, середній чек, кількість застосувань. Час запуску нової акції впав з двох днів до півгодини.

Калькулятор для будівельників. Параметри (площа, матеріали, поверховість) → формула → попередній кошторис → заявка в CRM через CRest::call('crm.lead.add'). Регіональні коефіцієнти та сезонні націнки — з Highload-блоку, ціни матеріалів — з обміну з 1С. Кількість цільових заявок зросла на третину: клієнти бачать розбивку за статтями до дзвінка менеджеру.

Бронювання для мережі готелів. Real-time доступність через AJAX-запити до кастомної таблиці vendor_booking_slots, розрахунок тарифів за сезоном, синхронізація з Booking.com через channel manager API. Блокування номера при одночасному бронюванні — через SELECT ... FOR UPDATE у транзакції. Таймзони обробляються через \DateTimeZone — гість із Владивостока та менеджер із Москви бачать одну картину.

Оцінимо проєкт за 1 день. Пишіть — розповімо, що входить у розробку під ключ. Зв'яжіться з нами для консультації за вашим проєктом. Замовте розробку модуля під ключ — отримайте готове рішення з документацією та підтримкою.