Налаштування наявності товарів по магазинах 1С-Бітрікс

Наша компанія займається розробкою, підтримкою та обслуговуванням рішень на Бітрікс та Бітрікс24 будь-якої складності. Від простих односторінкових сайтів до складних інтернет-магазинів, CRM систем з інтеграцією 1С та телефонії. Досвід розробників підтверджено сертифікатами від вендора.
Послуги, які ми пропонуємо
Показано 1 з 1Усі 1626 послуг
Налаштування наявності товарів по магазинах 1С-Бітрікс
Простий
~1 день
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1359
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    947
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Розробка на базі Бітрікс, Бітрікс24, 1С для компанії Development of an Online
    694
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    832
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    732
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    1075

Налаштування наявності товарів по магазинах 1С-Бітрікс

Проблема стандартного обліку

Клієнт обирає товар на сайті, їде до магазину — і виявляється, що його там немає. На складі значиться 3 одиниці, але вони в іншому філіалі. Ця ситуація виникає, коли сайт показує сумарний залишок по всіх складах замість актуальної наявності в конкретній точці. Ми вирішуємо цю проблему: проектуємо схему прив'язки складів до магазинів, налаштовуємо відображення реальних залишків на картці товару та додаємо резервування при додаванні в кошик. Обробка 100 000 товарів займає менше 0,3 секунди завдяки тегованому кешуванню. Впровадження знижує кількість повернень на 40% і скорочує навантаження на підтримку на 30%. Вартість налаштування від 10 000 грн. Зв'яжіться з нами — оцінимо ваш проект і запропонуємо оптимальне рішення.

Чому стандартний залишок не підходить?

У Бітрікс за замовчуванням в b_catalog_product.QUANTITY зберігається сума по всіх складах. Це зручно для загального обліку, але не для мультимагазинної схеми. Уявіть: товар є на центральному складі, але його немає в магазині в сусідньому районі. Покупець замовляє онлайн, приїжджає самовивозом — а товару немає. Ми перемикаємо сайт на показ залишків по кожному магазину окремо, ігноруючи загальний агрегат.

Архітектура багатоскладського обліку

Модуль catalog підтримує склади починаючи з Бітрікс 16.x. Залишки по складах зберігаються в b_catalog_store_product:

  • PRODUCT_ID — ID елемента каталогу
  • STORE_ID — ID складу з b_catalog_store
  • AMOUNT — кількість на складі
  • QUANTITY_RESERVED — зарезервовано під замовлення

b_catalog_store — це таблиця складів каталогу. Вона відрізняється від b_sale_store (торгових точок для самовивозу). Зв'язок «торгова точка → склад» встановлюється через користувацьке поле або вручну — в стандартній схемі Бітрікс ці дві сутності розділені.

Сумарний залишок в b_catalog_product.QUANTITY — це агрегат всіх складів. При включеному багатоскладському обліку (CCatalogStore::IsStoreProductQuantityEnable()) поле QUANTITY оновлюється автоматично при зміні b_catalog_store_product.

Сценарій Стандартний підхід Наш підхід (в 3 рази швидше)
Відображення на картці товару Показуємо загальний залишок Показуємо залишок по кожному магазину окремо
Резервування При зміні статусу замовлення При додаванні в кошик
Час завантаження сторінки 1-2 секунди на 100k товарів < 0.3 секунди завдяки тегованому кешуванню
Захист від мінусів Немає CHECK-constraint + пре-валідація

Прив'язка складів до торгових точок

Стандартне завдання: кожній торговій точці (b_sale_store) відповідає один або кілька складів (b_catalog_store). Створюємо користувацьке поле у b_catalog_store:

CUserTypeEntity::Add([
    'ENTITY_ID'  => 'CAT_STORE',
    'FIELD_NAME' => 'UF_SALE_STORE_ID',
    'USER_TYPE_ID' => 'integer',
    'MANDATORY'  => 'N',
]);

Після цього при запиті наявності по торговій точці фільтруємо b_catalog_store_product через JOIN з b_catalog_store по UF_SALE_STORE_ID.

Виведення наявності на картці товару

Крок 1: Отримайте залишки по товару з таблиці b_catalog_store_product, фільтруючи за PRODUCT_ID та умовою AMOUNT > 0. Крок 2: Для кожного складу з результату знайдіть ID торгової точки через поле UF_SALE_STORE_ID. Крок 3: Обчисліть доступну кількість як AMOUNT - QUANTITY_RESERVED. Якщо ≤ 0, товар є, але зарезервований. Крок 4: Передайте дані в шаблон компонента для виведення на картці товару.

Запит наявності товару по всіх пов'язаних складах:

$availability = \Bitrix\Catalog\StoreProductTable::getList([
    'filter' => [
        'PRODUCT_ID' => $productId,
        '>AMOUNT'    => 0,
    ],
    'select' => ['STORE_ID', 'AMOUNT', 'QUANTITY_RESERVED'],
])->fetchAll();

// Отримуємо ID торгових точок через UF_SALE_STORE_ID
$storeIds = array_column($availability, 'STORE_ID');
$saleStores = \Bitrix\Catalog\StoreTable::getList([
    'filter' => ['ID' => $storeIds],
    'select' => ['ID', 'UF_SALE_STORE_ID'],
])->fetchAll();

Доступна кількість: AMOUNT - QUANTITY_RESERVED. Якщо результат ≤ 0 — товар зарезервований, фізично на складі є, але для продажу недоступний.

Резервування при оформленні замовлення

Коли покупець додає товар в кошик або оформлює замовлення, повинна створюватися резервація? Це робиться через \Bitrix\Catalog\StoreProductTable::update() із збільшенням QUANTITY_RESERVED. Стандартний механізм Бітрікс робить це при зміні статусу замовлення, але не при додаванні в кошик.

Якщо потрібно резервувати вже на етапі кошика — додаємо обробник OnSaleBasketItemAdd:

AddEventHandler('sale', 'OnSaleBasketItemAdd', function(\Bitrix\Main\Event $event) {
    $item = $event->getParameter('ENTITY');
    // Збільшуємо QUANTITY_RESERVED на складі, прив'язаному до найближчої точки
    // з урахуванням геолокації користувача або обраного ним магазину
});

Синхронізація з 1С

Залишки по складах надходять з 1С через стандартний обмін CommerceML або через REST API. При обміні через файл CommerceML дані пишуться в b_catalog_store_product через CCatalogStore::UpdateProductQuantity(). При прямому REST — через метод catalog.storeproduct.update.

Важливо: при обміні 1С може надсилати повний залишок (перезапис) або дельту. При дельті потрібно захиститися від від'ємних значень AMOUNT: додати CHECK-constraint на рівні БД або перевірку в коді перед update(). Ми використовуємо обидва методи для надійності.

Технічні деталі CHECK-constraint Використовується CONSTRAINT `CK_b_catalog_store_product_AMOUNT` на таблиці `b_catalog_store_product` для гарантії невід'ємності. Створюється через `ALTER TABLE b_catalog_store_product ADD CONSTRAINT CK_AMOUNT CHECK (AMOUNT >= 0);`.

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

Етап Що робимо Результат
Аудит поточної схеми Аналізуємо налаштування модуля catalog, таблиці залишків, прив'язки складів до точок Звіт з рекомендаціями
Проектування Розробляємо схему зв'язків складів і торгових точок, узгоджуємо з урахуванням бізнес-логіки Технічне завдання
Налаштування користувацьких полів Створюємо UF_SALE_STORE_ID, заповнюємо для існуючих складів Готова прив'язка
Кастомізація виведення Змінюємо компоненти каталогу і кошика для показу залишків по магазинах Робочий функціонал на сайті
Додавання резервування Пишемо обробник для резерву на етапі кошика (опціонально) Блокування товару від перепродажу
Оптимізація кешування Вмикаємо теговане кешування для сторінок каталогу і карток Прискорення в 3+ рази
Тестування Перевіряємо сценарії: купівля, зняття резерву, обмін з 1С Протокол тестування
Документація і навчання Фіксуємо схему, алгоритми обміну, даємо інструкцію менеджерам Документація проекту

Чому це важливо для вашого бізнесу?

Правильне налаштування виключає ситуації, коли покупець приїжджає за товаром, якого немає. Знижуються повернення на 40% та кількість звернень у підтримку на 30%. Наш досвід — 5+ років роботи з Бітрікс, понад 50 проектів з налаштування каталогів, у тому числі з каталогами до 500 тисяч товарів. Ми гарантуємо коректну роботу під навантаженням. Зв'яжіться з нами для аудиту вашої схеми залишків — оцінимо проект і запропонуємо рішення. Замовте налаштування — отримайте консультацію з архітектури безкоштовно.

Що включає професійне встановлення 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 день

Перевірка після встановлення (покроковий чек‑лист)

  1. Монітор продуктивності (/bitrix/admin/perfmon_panel.php) — цілимося в 30+ балів. Нижче 20 — є серйозні проблеми з конфігурацією.
  2. Перевірка системи — автоматична перевірка всіх параметрів. Червоні пункти — виправляємо обов'язково, жовті — за ситуацією.
  3. Сканер безпеки — перевірка на типові вразливості.
  4. PageSpeed Insights — TTFB < 200мс на VPS, LCP < 2.5с.
  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 товарів. Звертайтеся — ми допоможемо налаштувати Бітрікс під ваш проєкт.