Розробка сайту оптової компанії на 1С-Бітрікс

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

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

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

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

  • image_website-b2b-advance_0.png
    Розробка сайту компанії B2B ADVANCE
    1262
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Розробка веб-сайту для компанії ФІКСПЕР
    851
  • 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
    585
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    751
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    657
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    989

Розробка сайту оптової компанії на 1С-Bitrix

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

B2B-каталог: типи цін та оптові правила

Основа B2B-каталогу — множинні типи цін. У таблиці b_catalog_group створюються цінові групи:

  • Роздрібна — базова, видна неавторизованим користувачам (якщо каталог відкритий).
  • Малий опт — для дилерів категорії C.
  • Середній опт — для дилерів категорії B.
  • Великий опт — для дилерів категорії A.
  • Спеціальна — індивідуальні ціни для ключових клієнтів.

Кожен тип ціни прив'язується до групи користувачів через налаштування модуля catalog. Авторизований дилер з групи «Великий опт» бачить свою колонку цін — решта приховані. Настройка виконується в розділі «Торговий каталог» → «Типи цін» → «Групи покупців».

Додаткові параметри на рівні товару:

  • Мінімальна партія — властивість інфоблока, числова. У компоненті корзини контролюється: неможливо замовити менше вказаної кількості.
  • Кратність замовлення — властивість інфоблока. Кількість в корзині округляється до найближчого кратного значення (наприклад, упаковка по 12 штук).
  • Одиниця виміру — штатне поле модуля каталогу (b_catalog_measure): штуки, упаковки, паллети.

Авторизація дилерів та розподіл доступу

Реєстрація дилера — не самостійна, а по заявці. Схема:

  1. На сайті — форма заявки: ІНН, назва компанії, контактна особа, сфера діяльності, передбачуваний обсяг закупок.
  2. Заявка потрапляє в CRM або в адмінку (розділ «Користувачі» → «Заявки на реєстрацію»).
  3. Менеджер перевіряє контрагента, створює облікову запис та призначає групу (малий/середній/великий опт).
  4. Дилер отримує доступ до особистого кабінету та бачить каталог зі своїми цінами.

Розподіл асортименту (не тільки цін) реалізується через права доступу до розділів інфоблока. Наприклад, група «Великий опт» бачить розділ «Екслюзивні колекції», недоступний малим дилерам.

Особистий кабінет: документообіг

Особистий кабінет дилера виходить далеко за межи стандартного sale.personal.section. Ключові розділи:

  • Історія замовлень — з фільтрацією за датою, статусом, сумою. Повторне замовлення в один клік.
  • Рахунки на оплату — PDF-документи, сформовані модулем sale або передані з 1С.
  • Акти зверки — файли, завантажені менеджером або генеровані автоматично з 1С.
  • Накладні та УПД — прив'язані до замовлень, доступні для скачування.
  • Кредитний ліміт — відображення поточного ліміту, використаної суми та доступного залишку.
  • Відстрочка платежу — інформація про строки та умови.

Документи зберігаються в Highload-блоці Documents: тип документа, номер, дата, файл, прив'язка до замовлення та контрагента. Завантаження з 1С — через REST API за розкладом.

Формування PDF рахунків на стороні Bitrix — через бібліотеку mPDF або TCPDF, підключену в обробнику події OnSaleOrderSaved. Шаблон рахунку включає реквізити компанії, таблицю товарів, итоги, QR-код для оплати.

Інтеграція з 1С: CommerceML + REST

Обмін з 1С — ядро оптового сайту. Два канали:

CommerceML (штатний обмін):

  • Номенклатура → інфоблок товарів.
  • Ціни за типами → b_catalog_price.
  • Залишки по складах → b_catalog_store_product.
  • Замовлення: Bitrix → 1С (виконання) та назад (статуси, відпускання).

REST API (для оперативних даних):

  • Актуальні залишки — запит до 1С при відкритті карточки товару (з кешуванням на 5–10 хвилин).
  • Кредитний ліміт контрагента — запит при авторизації та при оформленні замовлення.
  • Документи — виконання нових рахунків та актів за розкладом.

Deep-dive: B2B-корзина з завантаженням Excel та типами цін

Стандартна корзина Bitrix розрахована на роздрібного покупця: вибрав товар, натиснув «В корзину», перейшов до оформлення. У B2B-сценарії закупщик працює інакше. Він приходить з готовим списком з 50–200 позицій та хоче завантажити його за одне дію.

Швидке замовлення по артикулу

На сторінці «Швидке замовлення» — текстове поле, куди вводяться пари «артикул — кількість» по одній на рядку:

ART-001 24
ART-002 48
ART-003 12

При відправленні серверний обробник аналізує рядки, шукає товари за властивістю ARTICLE в інфоблоці (через CIBlockElement::GetList з фільтром), перевіряє наявність та додає в корзину через \Bitrix\Sale\Basket::addItem(). Якщо артикул не знайдений — рядок підсвічується червоним з поясненням.

Завантаження Excel-файлу

Більш просунутий варіант — завантаження XLS/XLSX. Обробник на стороні сервера:

  1. Прийом файлу — через стандартне завантаження Bitrix (CFile::SaveFile).
  2. Аналіз — бібліотека PhpSpreadsheet (підключається через Composer). Очікуваний формат: стовпець A — артикул, стовпець B — кількість. Перший рядок — заголовок (пропускається).
  3. Валідація — перевірка кожної рядки: існування артикулу, доступність товару для групи користувача, відповідність мінімальної партії та кратності.
  4. Формування результату — таблиця з колонками:
Артикул Назва Запрошено Скоригуєно Залишок Ціна Сума Статус
ART-001 Товар А 24 24 150 OK
ART-002 Товар Б 48 48 30 Частково (зал. 30)
ART-999 12 Не знайдений
  1. Підтвердження — користувач бачить результат, коригує кількість, підтверджує додавання в корзину.

Обробка типів цін в корзині

При додаванні товару в корзину ціна визначається автоматично на основі групи користувача. Логіка:

  • Визначається група авторизованого користувача (CUser::GetUserGroupArray()).
  • По групі визначається доступний тип ціни (CCatalogGroup::GetGroupsList()).
  • З b_catalog_price вилучається ціна товару за потрібним типом.
  • Якщо для товару налаштовані скидки за кількість (модуль «Правила корзини» — sale.discount), вони застосовуються при перерахунку.

Додаткова логіка — пороговий скидки: при замовленні на суму свище певного порогу автоматично застосовується додаткова скидка. Налаштовується через правила корзини з умовою «Сума корзини більше N».

Кредитний ліміт при оформленні

На етапі оформлення замовлення перевіряється кредитний ліміт контрагента. Дані беруться з 1С через REST API. Якщо сума замовлення перевищує доступний ліміт — виводиться попередження, але замовлення можна надіслати (на розсуд менеджера). Реалізація — обробник події OnSaleOrderBeforeSaved, який виконує запит до 1С та записує результат у властивість замовлення.

Технічна зведення

Компонент Рішення
Каталог bitrix:catalog з фасетним індексом
Фільтрація bitrix:catalog.smart.filter + AJAX
Корзина Кастомний компонент з підтримкою Excel
Інтеграція CommerceML (каталог) + REST API (залишки, ліміти)
Документи Highload-блок + mPDF
Права доступу Групи користувачів → типи цін + розділи інфоблока

Оптовий сайт на Bitrix — це переважно backend: обмін з 1С, типи цін, права, документообіг. Фронтенд вторинний — інтерфейс повинен бути функціональним та швидким, а не ефектним.