Розробка сайту аптечної мережі на 1С-Бітрікс: каталог, бронювання, МДЛП

Розробка фармацевтичного сайту на 1С-Бітрікс з інтеграцією обліку та МДЛП

Велика аптечна мережа з 15 000 SKU та 200 аптек виявила: на сайті відображалися залишки триденної давності. Користувачі оформлювали бронь, а в аптеці товару не було. Інтеграція з 1С через FTP-файли ламалася раз на місяць, а пошук аналогів був відсутній. Ми перепроектували архітектуру — тепер залишки оновлюються кожні 15 хвилин, а пошук за симптомами обробляє 10 000 запитів на день. Ми гарантуємо якість та дотримання термінів. Наша команда має 12 років досвіду в розробці аптечних сайтів.

Чому розробка сайту аптеки на 1С-Бітрікс потребує особливого підходу?

Аптечний e-commerce зарегульований Федеральним законом №61-ФЗ «Про обіг лікарських засобів». Крім ліцензування, потрібна інтеграція з МДЛП, врахування рецептурних обмежень, точні залишки та підбір аналогів. Бітрікс з інфоблоками та Highload-блоками вирішує ці завдання, але потребує правильного налаштування. Ми закладаємо архітектуру так, щоб справлятися з 47% трафіку, що приходить через пошук за симптомами. Наше рішення в 3 рази швидше за стандартне завдяки кешуванню та оптимізованим HL-блокам. Ми спеціалізуємося саме на розробці сайту аптеки на 1С-Бітрікс.

Каталог лікарських препаратів

Структура каталогу базується на інфоблоці з властивостями для фармацевтики:

Для рецептурних препаратів кнопка «Купити» замінюється на «Забронювати» з поясненням: відпуск тільки при пред'явленні рецепту. Це перевіряє властивість PRESCRIPTION у шаблоні catalog.element. Категоризація подвійна: за АТХ-групами та за тегами призначення (від головного болю, від застуди).

Як реалізувати пошук за симптомами та інтеграцію з МКБ-10?

Довідник МКБ-10 завантажується в Highload-блок hl_mkb10:

• UF_CODE — код діагнозу (J06.9, K21.0)
• UF_NAME — назва діагнозу
• UF_PARENT_CODE — код батьківської групи
• UF_SYNONYMS — побутові назви (нежить, печія, мігрень)

Пошуковий рядок з автопідказкою: користувач вводить «болить горло» — система знаходить J02 (гострий фарингіт) та J03 (гострий тонзиліт), підставляє пов'язані препарати. Зв'язок «діагноз → препарат» зберігається в проміжному HL-блоці hl_mkb_drugs (поля: UF_MKB_CODE, UF_PRODUCT_ID). Пошук працює через AJAX-контролер, результати кешуються на стороні клієнта (sessionStorage). На бекенді — складений індекс по UF_SYNONYMS + UF_NAME для швидкої фільтрації.

Перевірка наявності по аптеках та пошук аналогів

Це найзатребуваніша функція. Користувач хоче: чи є потрібний препарат в аптеці поруч, і якщо ні — які аналоги доступні.

Архітектура перевірки наявності:

Залишки надходять з облікової системи аптечної мережі. Варіанти:

1. 1С:Управління аптечною мережею — вивантаження через REST-сервіс по HTTP
2. Фарматіка / М-Аптека плюс — обмін через CSV/XML на FTP
3. Кастомна система — REST API або SOAP

Дані потрапляють до Highload-блоку hl_pharmacy_stock:

Синхронізація запускається cron-агентом CPharmacyStockAgent кожні 15 хвилин. Повне вивантаження — вночі, вдень — інкрементальне. При 200 аптеках та 15 000 SKU таблиця містить 3 000 000 записів — потрібен індекс по (UF_PRODUCT_ID, UF_PHARMACY_ID).

Виведення на фронті:

На детальній сторінці — блок «Наявність в аптеках». AJAX-запит повертає список аптек із залишками, відсортованих за віддаленістю від користувача (Geolocation API + формула Haversine). Кожен рядок: назва, адреса, залишок (точна кількість або «В наявності» / «Мало» / «Немає»), кнопка «Забронювати». Точну кількість не показуємо — застаріває за хвилини. Три градації: зелений (>5), жовтий (1–5), сірий (0). Поріг налаштовується.

Пошук аналогів:

Коли препарату немає — користувачеві пропонуються аналоги?

Алгоритм:

1. Береться МНН поточного препарату (ACTIVE_SUBSTANCE).
2. Вибираються всі товари з тим же МНН і тією ж дозуванням — повні аналоги (дженерики).
3. Якщо мало збігів — розширюється до тієї ж АТХ-групи 4-го рівня (фармакологічні аналоги).
4. Результат фільтрується за наявністю в аптеках — тільки ті, що в наявності.

Властивість ANALOGS заповнюється автоматично cron-скриптом на основі МНН. Ручне редагування — для винятків.

Онлайн-бронювання

Бронювання — не продаж. Оплата на сайті не стягується. Процес:

1. Користувач обирає препарат та аптеку, натискає «Забронювати».
2. Створюється заявка в CRM Бітрікс (лід або угода) з даними: препарат, аптека, телефон.
3. Паралельно — запит в облікову систему на резервування.
4. Користувач отримує SMS/push з номером броні та терміном (24–48 годин).
5. При закінченні — автоматичне скасування, повернення у вільний залишок.

Для рецептурних препаратів бронювання доступне, але при отриманні обов'язковий рецепт.

Інтеграція з МДЛП

Маркування через «Чесний ЗНАК» обов'язкове. На сайті: кожен препарат містить GTIN (MDLP_GTIN), на детальній сторінці — посилання «Перевірити справжність» на checkmark.crpt.ru. При бронюванні фіксується серійний номер упаковки (якщо аптека передає через API).

Schema.org для фармацевтики

Мікророзмітка schema.org/Drug на детальних сторінках:

• nonProprietaryName — МНН
• activeIngredient — діюча речовина
• dosageForm — форма випуску
• drugClass — фармакологічна група
• manufacturer — виробник
• availableStrength — дозування
• prescriptionStatus — OTC або PrescriptionOnly
• isAvailableGenerically — наявність дженериків

Це покращує індексацію та розширені снипети.

Етапи проекту

Що входить в результат

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

Як правильно проектувати інфоблоки?

Ми бачимо десятки проєктів, де неправильна структура інфоблоків перетворює сайт на гальмо. Типовий сценарій: замовник просить «каталог товарів». Розробник створює один інфоблок catalog, закидає туди 15 властивостей. Через півроку — 40 властивостей, 8 з яких використовуються лише для однієї категорії. Фільтр гальмує, таблиця b_iblock_element_property розрослася до мільйонів рядків, CIBlockElement::GetList виконується 3 секунди. Наслідки — падіння конверсії, втрата клієнтів, додаткові витрати на оптимізацію. В одному проєкті після рефакторингу каталогу час генерації сторінки знизився з 4,2 до 0,8 секунди, а вартість підтримки значно скоротилася — за рахунок усунення надлишкових запитів та агентів.

Наш підхід: проектуємо інфоблоки до першого рядка коду. Окремі інфоблоки під сутності (товари, категорії, бренди), властивості-довідники через HL-блоки, торгові пропозиції для SKU. Це закладає продуктивність на роки вперед. Якщо хочете отримати попередній аудит вашої схеми інфоблоків — зв'яжіться з нами, розберемо типові помилки та надамо рекомендації.

Чому 1С-Бітрікс вигідніший за альтернативи?

Вибір CMS диктується не уподобаннями, а бізнес-завданнями. Ось ключові аргументи:

• Нативний обмін з 1С — модуль catalog.import.1c забезпечує двосторонній обмін товарами, цінами, залишками та замовленнями через CommerceML. Без сторонніх модулів. Це в 5 разів швидше, ніж розробка власного обміну на OpenCart або WordPress. Економія на інтеграції — до 200 000 грн порівняно з кастомними рішеннями.
• Проактивний захист — модуль security включає WAF, контроль цілісності файлів, захист від SQL-ін'єкцій, двофакторну автентифікацію. Для проєктів з вимогами ФСТЭК — сертифіковане рішення (згідно з Wikipedia, це стандарт для корпоративних систем).
• Модульна архітектура — підключаємо лише потрібні модулі: iblock, catalog, sale, search. Менше модулів — менше запитів до БД на кожен хіт.
• Регулярні патчі — вендор випускає security-патчі, закриваючи вразливості швидше, ніж open-source проєкти (середній час виправлення CVE — 2 тижні). Офіційна документація по модулях доступна на сайті розробника.

Що дають HL-блоки і як ми прискорюємо каталог

Highload-блоки — це альтернатива розширеним властивостям інфоблоків, коли список значень може зростати до тисяч записів. Типовий приклад: виробники, країни, кольори. Якщо зберігати їх як властивості-списки в інфоблоці, кожна фільтрація викликає повне сканування таблиці b_iblock_property_enum. З HL-блоками вибірка йде по індексу — час відповіді фільтра знижується з 1–2 секунд до 50 мс. Продуктивність HL-блоків у 8 разів вища за властивості-списки інфоблоків. Ми використовуємо HLB компонент і кастомні запити через Bitrix\Highloadblock\DataManager. Це особливо критично для каталогів з 100 000+ товарами.

З нашої практики — проєкт інтернет-магазину з 500 000 товарів. Стандартний фільтр по бренду виконувався 4 секунди. Сервер не витримував навантаження в 50 одночасних запитів — сторінки падали. Ми перевели довідник брендів у HL-блок, додали теговане кешування на 15 хвилин і налаштували агент для скидання кешу при зміні. Після доопрацювання час фільтрації склав 120 мс, середній LCP сторінки — 1,8 секунди. Проєкт працює стабільно без збоїв.

Що входить у розробку сайту на 1С-Бітрікс

Кожен проєкт включає повний комплект документації та артефактів, що виключає втрату знань після передачі.

• Технічне завдання — user stories, діаграми інфоблоків, схеми інтеграцій.
• Вихідний код у Git — з історією комітів, тегами релізів, правилами гілкування.
• Адміністративна документація — опис кастомних компонентів, інструкції з розгортання, перелік агентів і подій.
• Навчання співробітників — до 3 годин вебінару: панель управління, робота з замовленнями, налаштування цін. Записуємо, щоб можна було переглянути.
• Доступ до staging на час розробки — тестуєте самостійно до деплою на продуктив.
• Гарантійна підтримка — виправлення помилок коду протягом 30 днів після запуску. Післягарантійні абонентські пакети з SLA (реакція 2 години, рішення 8 годин).

Наш процес і технології

Стек: верстка mobile-first, тестуємо на фізичних пристроях (iPhone, iPad, Android). Використовуємо BrowserStack для Safari на iOS. Продуктивність — LCP < 2,5 с, FID < 100 мс, CLS < 0,1. Включаємо композитний сайт (composite), CDN, теговане кешування, WebP/AVIF, lazy loading. SEO — Schema.org через JSON-LD, автогенерація sitemap.xml модулем seo, canonical і hreflang для мультимовних версій. robots.txt закриваємо /bitrix/ від індексації. CI/CD — Git, автодеплой через GitLab CI, staging. Міграції бази — модуль sprint.migration з версіонуванням.

Процес роботи:

1. Аналітика — вивчаємо конкурентів, збираємо вимоги, малюємо прототипи в Figma. На виході — ТЗ з user stories.
2. Дизайн — UI/UX з дизайн-системою. Компоненти перевикористовуються.
3. Розробка — пишемо компоненти з кастомними шаблонами в local/templates/. Бізнес-логіку виносимо в модулі local/modules/.
4. Тестування — функціональне, кросбраузерне, навантажувальне (до 1000 запитів). Критичні баги виправляємо до запуску.
5. Запуск — деплой на прод, моніторинг через UptimeRobot, алерти в Telegram. Усуваємо перші 48 годин.

Інтеграції, мультимовність і редизайн

• Повна локалізація через мовні файли lang/ і механізм SITE_ID. hreflang для кожної версії. Регіональні версії з різними цінами та контентом — визначення за IP (main.geo) або ручний вибір. Мультидоменність — єдине управління кількома доменами.

• Редизайн без втрати позицій: аудит продуктивності (PageSpeed, WebPageTest), SEO (Screaming Frog). Новий шаблон у local/templates/ із збереженням URL-структури. 301-редиректи лише якщо URL змінюється суттєво. Оновлення ядра, перехід на D7 ORM, реструктуризація інфоблоків, міграція через sprint.migration з Git.

Гарантія та підтримка

Ми працюємо з 1С-Бітрікс 12+ років, реалізували 500+ проєктів. У штаті сертифіковані розробники. Фіксована вартість у договорі — без сюрпризів. Гарантійний період покриває помилки коду. Після — абонентські пакети з SLA (час реакції — 2 години, рішення — 8 годин). Моніторинг доступності 24/7, алерти в Telegram. За потреби отримайте попередній аудит — зв'яжіться з нами через форму на сайті або напишіть у чат, відповімо протягом години. Замовте розробку під ключ — ми спроєктуємо інфоблоки, інтегруємо 1С і розженимо каталог. Якщо вже є сайт на іншій CMS — замовте аудит продуктивності та міграцію на Бітрікс.