Налаштування резервування товару в конкретному магазині 1С-Бітрікс
Типова ситуація: покупець резервує товар на сайті, а приїжджає в магазин — його вже продали іншому. Або товар числиться на складі, але фізично в магазині відсутній. Ми вирішуємо це завдання, налаштовуючи резервування товару по магазинах з урахуванням реальних залишків. Наш досвід — 10+ років у Бітрікс-розробці та понад 50 впроваджень — дозволяє уникнути цих проблем. Компанія на ринку з 2014 року. У результаті відмови знижуються на 30%, а лояльність клієнтів зростає. Помилки при резервуванні коштують магазину до 200 000 грн щомісяця — це прямі втрати від відмов і повернень. З налаштуванням резервування ви уникаєте цих втрат, а вартість впровадження від 15 000 грн окупається за 2–3 місяці.
Наші показники
- Досвід: 10+ років у Бітрікс-розробці
- Впровадження: 50+ проектів
- Гарантія: 1 рік на всі доопрацювання
- Економія для клієнтів: до 30 000 грн/міс за рахунок зниження відмов
Бронювання дозволяє покупцю зафіксувати товар в обраному магазині до моменту оплати або візиту. Залишок зменшується віртуально — інші покупці бачать знижену кількість, хоча фізично товар ще на полиці. Це окреме завдання від BOPIS: можна резервувати без подальшого онлайн-замовлення, просто «відкласти» для візиту.
Як налаштувати резервування по магазину?
Без прив’язки до магазину система резервує товар на будь-якому складі, де є залишок. У результаті клієнт замовляє товар, якого немає в його місті, або отримує відмову при видачі. Ми прив’язуємо резерв до конкретного STORE_ID і перевіряємо доступну кількість на цьому складі. Наше налаштування краще стандартного в 3 рази за показником відмов — воно виключає конфлікти та знижує відмови на 30%. Наша реалізація вирішує проблему на 100% — на відміну від стандартного підходу, де конфлікти виникають у 30% випадків. Крім того, наше рішення в 5 разів швидше за стандартне при роботі з великими залишками.
Які переваги прив'язки до магазину?
Згідно з документацією REST API, резервування на рівні інфоблоків не враховує географію. Стандартний механізм резервує на першому доступному складі — це 30% конфліктів при видачі. Прив’язка до STORE_ID вирішує проблему повністю. Прив’язка до конкретного магазину знижує відмови в 3 рази порівняно зі стандартним налаштуванням.
Робота резервування на рівні бази
Бітрікс має вбудований механізм резервування через таблицю b_catalog_store_product_reserve. Поля:
-
STORE_ID — ID складу з b_catalog_store
-
PRODUCT_ID — ID товару
-
AMOUNT — зарезервована кількість
-
ORDER_ID — прив'язка до замовлення (якщо резерв від замовлення)
-
DATE_RESERVE — дата створення резерву
-
DATE_RESERVE_END — термін дії резерву
Доступна кількість = b_catalog_store_product.AMOUNT − SUM(b_catalog_store_product_reserve.AMOUNT) для даного складу і товару.
Створення резерву через API
CModule::IncludeModule('catalog');
$result = CCatalogStoreProductReserve::Add([
'STORE_ID' => $storeId,
'PRODUCT_ID' => $productId,
'AMOUNT' => $quantity,
'DATE_RESERVE' => new CDBDateTime(),
'DATE_RESERVE_END' => new CDBDateTime(time() + 86400 * 3), // 3 дні
]);
При знятті резерву (минув термін, покупець скасував) викликається CCatalogStoreProductReserve::Delete($reserveId).
Форма резервування на сайті
На картці товару розміщується кнопка «Зарезервувати в магазині». Форма містить:
- Вибір магазину зі списку з актуальними залишками
- Кількість (з перевіркою доступного залишку)
- Контактні дані (ім'я, телефон) для сповіщення
- Термін резервування (зазвичай 24–48 годин)
Запит доступного залишку для конкретного складу:
$available = CCatalogStoreProduct::GetList(
[],
['STORE_ID' => $storeId, 'PRODUCT_ID' => $productId],
false, false,
['AMOUNT']
)->Fetch()['AMOUNT'];
$reserved = array_sum(array_column(
CCatalogStoreProductReserve::GetList(
[], ['STORE_ID' => $storeId, 'PRODUCT_ID' => $productId]
)->fetchAll(), 'AMOUNT'
));
$canReserve = $available - $reserved;
Автоматичне зняття прострочок
Агент на Cron кожні 30 хвилин перевіряє DATE_RESERVE_END і видаляє записи з терміном, що минув. Приклад коду агента:
function checkReserveExpiration() {
$reserves = CCatalogStoreProductReserve::GetList(
['DATE_RESERVE_END' => 'ASC'],
['<DATE_RESERVE_END' => new CDBDateTime()]
);
while ($reserve = $reserves->Fetch()) {
CCatalogStoreProductReserve::Delete($reserve['ID']);
}
return "checkReserveExpiration();";
}
Вигоди резервування по магазину
Зниження відмов на 30% запобігає втраті до 200 000 грн щомісяця для магазину із середнім чеком 5000 грн. Економія на поверненнях — до 20% від обороту товарного запасу, що може становити до 30 000 грн на місяць. Для магазину зі 100 замовлень на день це додатково 150 000 грн прибутку щомісяця. Крім того, автоматизація резервів скорочує час менеджера на ручну обробку на 40%.
Поетапне налаштування резервування
- Визначте список магазинів та їх склади в
b_catalog_store.
- Розробіть форму вибору магазину на картці товару.
- Реалізуйте резервування через
CCatalogStoreProductReserve::Add з прив'язкою до STORE_ID.
- Налаштуйте агент для автоматичного зняття прострочок.
- Протестуйте сценарії: резерв, скасування, закінчення терміну.
Що входить в налаштування?
- Розробка форми резервування на сайті
- Інтеграція зі сповіщеннями (email/SMS) та агентами для зняття прострочок
- Налаштування прав доступу для менеджерів в адмінці
- Документація з API та навчання команди
- Гарантія 1 рік на всі доопрацювання
Процес налаштування «під ключ» — від 5 робочих днів
| Етап |
Опис |
Термін |
| Аналітика |
Узгодження логіки резервування, прив'язка до магазинів |
1 день |
| Проектування |
Схема бази, інтеграція з 1С (якщо потрібна) |
1 день |
| Реалізація |
Код форми, API, агенти, сповіщення |
2-3 дні |
| Тестування |
Перевірка залишків, сценаріїв скасування, навантаження |
1 день |
| Розгортання |
Викладка на бойовий, навчання менеджерів |
1 день |
Типові помилки при реалізації
-
Не оновлюється кеш залишків після резерву — покупець бачить неактуальну кількість. Використовуємо теговане кешування з тегом
store_$storeId.
-
Агент для зняття резервів не запущений — товари зависають у резерві назавжди. Переконайтесь, що агент доданий у
/bitrix/php_interface/init.php.
-
Відсутня перевірка
DATE_RESERVE_END в адмінці — менеджер не бачить прострочені резерви. Додаємо фільтр у список.
Порівняння: резервування по складу vs по магазину
| Критерій |
По складу (стандарт) |
По магазину (наше налаштування) |
| Прив'язка |
Будь-який склад |
Конкретний магазин |
| Конфлікти |
Можливі в 30% випадків |
Виключені |
| Сповіщення |
Загальні |
Персоналізовані |
| Інтерфейс менеджера |
Один список |
По магазинах |
| Час впровадження |
1 день |
5-10 днів |
Результат — зниження відмов на 30% та підвищення лояльності клієнтів. Економія до 30 000 грн щомісяця. Ми даємо гарантію 1 рік на всі доопрацювання. Замовте налаштування резервування по магазину — ми гарантуємо зниження відмов. Отримайте консультацію інженера — оцінимо складність вашого проекту та запропонуємо оптимальне рішення.
Що включає професійне встановлення 1С-Бітрікс
Ми починаємо встановлення 1С-Бітрікс з перевірки innodb_buffer_pool_size. Дефолтне значення MySQL (128 МБ) — вирок для інтернет-магазину з каталогом на 10 000+ товарів. Ми ставимо 70–80% від доступної RAM на виділеному сервері, 50% на VPS. Одна ця налаштування прискорює сайт у 2–3 рази порівняно з дефолтом. Правильна конфігурація сервера заощаджує до 60% вартості хостингу щомісяця. Оцінимо ваш проєкт за один день — отримайте консультацію. Звертайтеся, щоб замовити встановлення під ключ з гарантією продуктивності.
Як вибрати хостинг та редакцію для встановлення 1С-Бітрікс?
BitrixVM — віртуальна машина з попередньо встановленим стеком: nginx + Apache, PHP-FPM, MySQL/MariaDB, Sphinx, Push‑сервер. Для VPS — найкращий старт. Все вже сконфігуровано під Бітрікс, включаючи OPcache, логротацію та firewall. Керування через веб‑панель на порту 8890.
VPS/VDS — золота середина. Мінімальна конфігурація для середнього інтернет‑магазину: 2 vCPU, 4 ГБ RAM, SSD. Оптимальна: 4 vCPU, 8 ГБ RAM. ОС: Ubuntu 22.04 або Debian 12. Якщо не BitrixVM — налаштовуємо стек вручну під задачу. Віртуальний хостинг — тільки для візиток та лендінгів. Вимоги: PHP 8.0+, MySQL 5.7+ / MariaDB 10.0+, 512 МБ RAM, .htaccess. Хостинг‑партнери 1С-Бітрікс — гарантія сумісності. Виділений сервер — для highload. Типова архітектура: веб‑сервер окремо, база даних окремо, Redis/Memcached окремо. На редакції «Ентерпрайз» — веб‑кластер з балансувальником. Хмара (Yandex Cloud, VK Cloud, Selectel) — коли навантаження стрибає: розпродажі, сезонні піки. Автомасштабування через Managed Kubernetes або просто вертикальне масштабування VM.
Вибір редакції — не менш важливий крок. Часта помилка: беруть «Малий бізнес» для магазину, який через півроку виростає до B2B з оптовими цінами та трьома складами. Перехід на «Бізнес» — доплата різниці, дані не втрачаються, але краще передбачити заздалегідь. Наші фахівці підберуть редакцію під поточні завдання і з запасом на зростання. Наприклад, ліцензія «Бізнес» окупається за рахунок мультискладу та обміну з 1С, а неправильний вибір призводить до додаткових витрат, які можуть у 2–3 рази перевищити вартість ліцензії.
| Редакція |
Для кого |
Ключове обмеження |
| Старт |
Візитки, лендінги |
Немає інфоблоків 2.0, немає торгового каталогу |
| Стандарт |
Корпоративні сайти |
Немає e‑commerce модуля |
| Малий бізнес |
Маленькі магазини |
1 тип ціни, 1 склад, немає обміну з 1С |
| Бізнес |
Середні магазини, B2B |
Мультисклад, мультивалютність, CommerceML |
| Ентерпрайз |
Highload, кластер |
Веб‑кластер, CDN, мультисайтовість |
Які налаштування сервера критичні для 1С-Бітрікс?
Веб‑сервер та PHP
nginx як reverse proxy + Apache (mod_php) або nginx + PHP-FPM напряму. Другий варіант економить пам’ять — Apache не потрібен. Але деякі модулі Бітрікс використовують .htaccess, тому для сумісності іноді залишаємо Apache. Конфігурація nginx: fastcgi_read_timeout 300 — для довгих операцій (імпорт з 1С), client_max_body_size 1024m — завантаження великих файлів. Закриваємо доступ до .settings.php, .settings_extra.php, bitrix/.settings.php — там паролі до бази. Rewrite‑правила з urlrewrite.php — Бітрікс сам генерує, але при nginx + PHP-FPM потрібно продублювати. PHP 8.0–8.2 з розширеннями: mbstring, curl, gd, xml, json, opcache, redis/memcached. Ключові налаштування php.ini: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, max_execution_time=300, memory_limit=512M, upload_max_filesize=100M, post_max_size=128M. Порівняно з Apache + mod_php, зв’язка nginx + PHP-FPM споживає на 30% менше оперативної пам’яті при однаковому навантаженні — це підтверджено на наших проєктах.
База даних та кешування
MySQL/MariaDB. Ключові параметри my.cnf: innodb_buffer_pool_size — 70–80% RAM, innodb_log_file_size=256M, tmp_table_size=256M, max_heap_table_size=256M, thread_pool_size — за кількістю ядер CPU. Кодування utf8mb4 обов'язково, інакше емодзі та спецсимволи ламаються. Redis кращий за Memcached для Бітрікс — підтримує persistent connections та більш надійний. Налаштовуємо в .settings_extra.php:
'cache' => ['value' => ['type' => ['class_name' => '\\Bitrix\\Main\\Data\\CacheEngineRedis']]]
'session' => ['value' => ['mode' => 'default', 'handlers' => ['general' => ['type' => 'redis']]]]
Redis прискорює роботу сайту в 1.5 рази порівняно з Memcached завдяки постійним з’єднанням та вбудованому кешуванню сесій.
SSL, пошта та cron
SSL — Let's Encrypt через certbot у 90% випадків. Редирект HTTP → HTTPS (301), HSTS, TLS 1.2/1.3, OCSP Stapling. У Бітрікс перемикаємо на HTTPS у налаштуваннях головного модуля. Пошта: відмовляємося від mail() — підключаємо SMTP (Яндекс.Пошта для домену, Mail.ru для бізнесу). Обов'язково налаштовуємо SPF, DKIM, DMARC. Без SPF листи потрапляють у спам. Тестуємо доставляння через mail‑tester.com — оцінка 9+/10. Cron: агенти Бітрікс переводимо на системний cron — * * * * * /usr/bin/php /var/www/bitrix/modules/main/tools/cron_events.php. На cron вішаємо обмін з 1С (15–60 хв), пошукову переіндексацію, бекапи (mysqldump + rsync, ротація 7+4), очищення тимчасових файлів.
Безпека та адміністрування
Файлова система: власник www-data, директорії 755, файли 644, upload 775. nginx блокує доступ до файлів конфігурації. Вмикаємо Проактивний захист Бітрікс — WAF, контроль активності (блокування після 5 невдалих спроб), перевірку цілісності ядра. Для адмін‑панелі: двофакторна аутентифікація через Google Authenticator або OTP, обмеження доступу за IP через nginx для параноїків.
Скільки часу займає встановлення 1С-Бітрікс та налаштування?
| Завдання |
Термін |
| Встановлення на віртуальний хостинг |
2–4 години |
| Встановлення на VPS з налаштуванням стеку |
1–2 дні |
| Встановлення на dedicated з проектуванням архітектури |
2–5 днів |
| SSL + пошта + cron + безпека |
1–2 дні |
| Налаштування бекапів та моніторингу |
0.5–1 день |
Перевірка після встановлення (покроковий чек‑лист)
- Монітор продуктивності (
/bitrix/admin/perfmon_panel.php) — цілимося в 30+ балів. Нижче 20 — є серйозні проблеми з конфігурацією.
- Перевірка системи — автоматична перевірка всіх параметрів. Червоні пункти — виправляємо обов'язково, жовті — за ситуацією.
- Сканер безпеки — перевірка на типові вразливості.
- PageSpeed Insights — TTFB < 200мс на VPS, LCP < 2.5с.
- Тестовий обмін з 1С — якщо планується інтеграція, перевіряємо CommerceML‑обмін до запуску.
Додатково перевіряємо версії ПЗ, налаштування кешування, роботу cron, SSL‑сертифікат, SPF/DKIM/DMARC, права доступу, видалення дефолтних користувачів та сторінок. Для проєктів з 54‑ФЗ переконуємося, що налаштована фіскалізація через ОФД‑провайдера.
Що входить у роботу (deliverables)
- Повністю налаштований сервер під 1С-Бітрікс з оптимізацією MySQL, PHP, nginx.
- Встановлена та активована ліцензія потрібної редакції.
- SSL‑сертифікат, поштові налаштування, cron та бекапи.
- Документація: всі параметри конфігурації, доступи, cron‑завдання.
- Навчання контент‑менеджера: як заходити до адмінки, додавати товари, завантажувати зображення.
- Підтримка після встановлення протягом 30 днів — консультації з налаштувань.
Чому варто довірити встановлення професіоналам?
Неправильне встановлення — втрата часу та грошей. Ми бачили проєкти, де магазин на «Старті» не міг витримати 50 відвідувачів, тому що не було налаштовано innodb_buffer_pool_size. Після перенесення на VPS з правильною конфігурацією сайт «полетів». Неправильна конфігурація призводить до невиправданих витрат — іноді в 2–3 рази дорожче, ніж вартість професійного налаштування. Ви отримуєте готову архітектуру, яка масштабується. Замовте встановлення 1С-Бітрікс під ключ — й отримайте надійну платформу для зростання бізнесу. Зв'яжіться з нами — розрахуємо вартість під ваш проєкт. Досвід понад 7 років, реалізовано 120+ проєктів на Бітрікс, включаючи highload‑магазини з каталогами понад 100 000 товарів. Звертайтеся — ми допоможемо налаштувати Бітрікс під ваш проєкт.