Розробка кастомної PIM-системи для 1С-Бітрікс

Архітектура кастомної PIM на Бітрікс: від атрибутів до синдикації

Уявіть каталог із 15 000 товарів, кожен із 60 унікальними атрибутами. Стандартні інфоблоки гальмують, адміністраторам не вистачає гнучкості, а інтеграція з маркетплейсами перетворюється на пекло. Ми побудували 15 кастомних PIM-систем на 1С-Бітрікс і виконали понад 30 впроваджень. Маємо 7+ років досвіду в розробці на Бітрікс та 5+ років на ринку. Кастомна PIM вирішує ці завдання без переходу на сторонній софт — Бітрікс стає єдиною мастер-системою для даних про товари. Product Information Management (PIM) — це підхід, який ми адаптуємо під екосистему 1С-Бітрікс, зберігаючи швидкість впровадження та відсутність ліцензійних відрахувань. Як зазначено в документації 1С-Бітрікс, інфоблоки v2.0 підтримують EAV-модель, але при масштабуванні ми використовуємо гібридний підхід.

Як влаштована архітектура даних?

Стандартний інфоблок зберігає властивості в b_iblock_element_property за моделлю EAV. При 50+ атрибутах і високому трафіку це створює проблеми продуктивності. Для кастомної PIM використовуємо гібридний підхід: фіксовані атрибути (назва, опис, зображення) — у полях інфоблоку, а динамічні — у кастомних таблицях.

CREATE TABLE b_pim_attribute (
    ID INT AUTO_INCREMENT PRIMARY KEY,
    IBLOCK_SECTION_ID INT,
    CODE VARCHAR(100) NOT NULL,
    NAME VARCHAR(255) NOT NULL,
    TYPE ENUM('string','number','boolean','list','multilist') DEFAULT 'string',
    IS_REQUIRED TINYINT(1) DEFAULT 0,
    IS_FILTERABLE TINYINT(1) DEFAULT 0,
    SORT INT DEFAULT 100,
    INDEX idx_section (IBLOCK_SECTION_ID)
);

CREATE TABLE b_pim_attribute_value (
    ID INT AUTO_INCREMENT PRIMARY KEY,
    PRODUCT_ID INT NOT NULL,
    ATTRIBUTE_ID INT NOT NULL,
    VALUE_STRING VARCHAR(1000),
    VALUE_NUMBER DECIMAL(15,4),
    VALUE_BOOLEAN TINYINT(1),
    INDEX idx_product_attr (PRODUCT_ID, ATTRIBUTE_ID)
);

CREATE TABLE b_pim_attribute_option (
    ID INT AUTO_INCREMENT PRIMARY KEY,
    ATTRIBUTE_ID INT NOT NULL,
    VALUE VARCHAR(500) NOT NULL,
    SORT INT DEFAULT 100
);

Такий підхід дозволяє задавати атрибути на рівні категорії без зміни схеми інфоблоку. Детальніше про CommerceML.

Як налаштувати кастомну PIM

Крок 1: Спроектувати схему атрибутів: визначити фіксовані та динамічні атрибути для кожної категорії. Ми готуємо прототип таблиць.

Крок 2: Розгорнути кастомні таблиці: виконати міграції для створення b_pim_attribute, b_pim_attribute_value та індексів.

Крок 3: Налаштувати адміністративний інтерфейс: використовувати наш компонент на основі bitrix:main.ui.grid для керування атрибутами.

Цей процес займає 2–3 дні для досвідченого розробника.

Чому кастомна PIM вигідніша за готові рішення?

Кастомна PIM на Бітрікс швидша за Akeneo в 2-3 рази, впроваджується в 2–3 рази швидше і не вимагає ліцензійних відрахувань. Порівняння PIM vs Akeneo показує явні переваги. Оптимізація запитів підвищує продуктивність каталогу. Порівняння вартості:

Економія на ліцензіях може досягати $15 000–$30 000 на рік, окупаючи розробку за перший рік. Наприклад, для каталогу 50 000 SKU економія становить понад $20 000 на рік. Вартість розробки базової версії кастомної PIM — від $5 000, розширеної з повною синдикацією — від $10 000.

function buildYmlOffer(int $productId): array
{
    $connection = \Bitrix\Main\Application::getConnection();
    $values     = $connection->query(
        "SELECT a.CODE, v.VALUE_STRING, v.VALUE_NUMBER
         FROM b_pim_attribute_value v
         JOIN b_pim_attribute a ON a.ID = v.ATTRIBUTE_ID
         WHERE v.PRODUCT_ID = {$productId}"
    );
    $params = [];
    while ($row = $values->fetch()) {
        $params[$row['CODE']] = $row['VALUE_STRING'] ?? $row['VALUE_NUMBER'];
    }
    return $params;
}

Інтерфейс керування атрибутами та синдикація контенту

Кастомний адміністративний розділ на базі компонента bitrix:main.ui.grid:

// /local/modules/company.pim/admin/attributes.php
require_once $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_admin_before.php';

$APPLICATION->SetTitle('PIM: Керування атрибутами');

$sectionId = (int)$_GET['section_id'];
$connection = \Bitrix\Main\Application::getConnection();
$attributes = $connection->query(
    "SELECT * FROM b_pim_attribute WHERE IBLOCK_SECTION_ID = {$sectionId} ORDER BY SORT"
);

Інтерфейс дозволяє менеджеру:

• Додавати атрибути до категорії без зміни структури БД
• Задавати тип, обов'язковість, можливість фільтрації
• Сортувати атрибути перетягуванням
• Копіювати набір атрибутів у дочірню категорію

Форма редагування товару відображає динамічні атрибути поточної категорії. Валідація обов'язкових атрибутів виконується при збереженні.

Кастомна PIM експортує дані в формати: Яндекс.Маркет (YML), Ozon, Wildberries (JSON), Google Merchant. Виконується експорт YML Ozon Wildberries за допомогою підготовлених шаблонів. Синдикація контенту відбувається автоматично за графіком.

Процес, обсяг робіт та тестування

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

• Технічне завдання та прототип схеми даних
• Розробка core-функціоналу (таблиці, форма редагування, валідація)
• Кастомний адміністративний інтерфейс з сортуванням та копіюванням атрибутів
• Експортери для маркетплейсів (YML, JSON, XML)
• Документація, доступ до системи та передача вихідних кодів
• Навчання адміністраторів роботі з системою
• Гарантійна підтримка протягом місяця

Процес і терміни роботи:

Загальна тривалість — від 2 до 8 тижнів залежно від обсягу функціоналу. Зв'яжіться з нами для точної оцінки вашого проекту.

Як ми тестуємо продуктивність: Проводимо навантажувальне тестування за допомогою ab та jmeter, імітуючи 500 одночасних запитів. Перевіряємо час генерації YML-фіду (менше 10 секунд для 50 000 товарів). При необхідності додаємо теговане кешування.

Типові помилки при розробці:

• Використовувати лише властивості інфоблоків (EAV) для всіх атрибутів — призводить до гальмування при масових вибірках.
• Не створювати індекси на кастомних таблицях — запити стають повільними вже на 10 000 товарів.
• Забути про асинхронне збереження атрибутів — блокує інтерфейс при редагуванні.

Часті питання

Що таке кастомна PIM? Кастомна PIM (Product Information Management) — це система управління продуктовою інформацією, розроблена індивідуально під завдання бізнесу. В контексті 1С-Бітрікс це означає, що Бітрікс стає мастер-системою для всіх даних про товари, дозволяючи керувати атрибутами, валідувати їх та синдикувати на канали продажів.

Коли потрібна кастомна PIM на Бітрікс? Коли торговий каталог перевищує 10 000 товарів з великою кількістю атрибутів, стандартні інфоблоки перестають справлятися. Кастомна PIM виправдана, якщо команда працює в екосистемі Бітрікс, бюджет на готове рішення обмежений, або вимоги до атрибутів унікальні і не покриваються типовими PIM.

Скільки часу займає розробка? Базова версія з динамічними атрибутами та формою редагування — 2-3 тижні. Повноцінна система з валідацією, сортуванням та синдикацією — 4-8 тижнів.

З якими маркетплейсами інтегрується? Кастомна PIM вміє експортувати товари в Яндекс.Маркет (YML), Ozon, Wildberries та Google Merchant через підготовлені шаблони. Можлива інтеграція з будь-яким каналом, що підтримує XML або JSON.

Які переваги перед готовими рішеннями? Відсутність ліцензійних відрахувань, повна гнучкість під бізнес-процеси, не потрібен окремий сервер, а час впровадження в 2-3 рази менший. При каталозі до 100 000 SKU продуктивність не поступається комерційним PIM.

Замовте розробку

Оцінимо ваш проект за 1 день, підготуємо комерційну пропозицію з точними термінами. Отримайте консультацію інженера — напишіть нам.

Розробка та налаштування модулів 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 день. Пишіть — розповімо, що входить у розробку під ключ. Зв'яжіться з нами для консультації за вашим проєктом. Замовте розробку модуля під ключ — отримайте готове рішення з документацією та підтримкою.