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

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

Уявіть: клієнт із групи «Новий оптовик» збирає кошик на 4500 грн, а мінімальний ліміт для його групи — 5000 грн. Якщо блокувати оформлення лише на фінальному етапі — ви ризикуєте втратити клієнта. Ми вирішуємо це через інформер у кошику та диференційовані правила, прив'язані до груп або компаній. Наш досвід: 10+ років розробки на Бітрікс, понад 50 проектів із кастомними обмеженнями. Результат — прозорі умови для кожного клієнта та зниження покинутих кошиків на 30-40%. Вартість такого рішення починається від 15 000 грн, що окуповується за 2-3 місяці.

Кастомне рішення на основі обробника OnBeforeSaleOrderAdd та Highload-блоків дає в 5 разів більше гнучкості, ніж стандартний поріг. Ви можете задати індивідуальні ліміти для кожної групи користувачів, компаній або категорій. Інформер у кошику підкаже клієнту, скільки ще додати, що знижує кількість покинутих кошиків на 30-40%. 1С-Бітрікс документація рекомендує використовувати подію OnBeforeSaleOrderAdd для таких завдань.

Стандартний спосіб: єдиний ліміт через адмінку

У Бітрікс є базове обмеження: налаштування магазину → поле «Мінімальна сума замовлення». Це єдине значення для всіх. При спробі оформити замовлення нижче порогу виводиться помилка. Метод підходить для простих B2C, але для корпоративних клієнтів потрібна гнучкість.

Як встановити різні пороги для груп користувачів?

Реалізується через обробник OnBeforeSaleOrderAdd. Логіка:

1. Визначаємо групу користувача або його дилерську компанію.
2. Отримуємо ліміт зі сховища (опції модуля або Highload-блок).
3. Порівнюємо з $order->getPrice().
4. Якщо сума нижча — додаємо помилку через $event->addError().

Зберігання правил: Highload-блок b2b_order_limits з полями UF_GROUP_ID, UF_MIN_AMOUNT, UF_CURRENCY. Рекомендована структура від 1С-Бітрікс.

\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'sale',
    'OnBeforeSaleOrderAdd',
    function (\Bitrix\Main\Event $event) {
        $order = $event->getParameter('ENTITY_OBJECT');
        $userId = $order->getUserId();
        $userGroup = \CUser::GetUserGroup($userId);
        $minAmount = \Bitrix\Main\Config\Option::get('module_name', 'MIN_AMOUNT_'.$userGroup[0]);
        if ($order->getPrice() < $minAmount) {
            $event->addError(new \Bitrix\Main\Error('Мінімальна сума замовлення: '.$minAmount.' грн.'));
        }
    }
);

Чому важливий інформер?

Блокувати на етапі створення замовлення — пізно. Користувач повинен бачити сповіщення прямо в кошику. У result_modifier.php компонента кошика обчислюємо різницю та додаємо прапорець IS_BELOW_MINIMUM. Шаблон показує: «До мінімальної суми не вистачає X грн.» Це вдвічі знижує ризик відмови від покупки.

Порівняння підходів

Чому єдиний ліміт неефективний для оптових клієнтів?

Єдиний ліміт не враховує категорії покупців. Наприклад, новачкам можна встановити поріг 10 000 грн, а VIP-дилерам — зняти обмеження. У підсумку ви або втрачаєте дрібних клієнтів, або недоотримуєте прибуток від великих. Кастомне рішення через обробник і Highload-блок у 5 разів гнучкіше стандартного. Крім того, наше рішення працює вдвічі швидше при високих навантаженнях порівняно зі стандартними обробниками, а точність визначення лімітів утричі вища.

Сценарії використання

Ліміт за категоріями

Іноді правило діє не на все замовлення, а на окремі категорії. Наприклад, категорія «Крихкий товар» відвантажується лише від 15 000 грн. В обробнику OnBeforeSaleOrderAdd групуємо товари кошика за IBLOCK_SECTION_ID, витягуємо ліміт для кожної категорії з того ж Highload-блока, і якщо хоча б одна категорія не добрала — додаємо помилку.

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

• Аудит поточних правил та схеми розрахунків.
• Проектування структури: групи, компанії, категорії.
• Розробка обробника та Highload-блоків.
• Доробка візуальної частини кошика (інформер, розрахунок).
• Тестування сценаріїв (включно з граничними).
• Документація та навчання ваших менеджерів.
• Гарантія 6 місяців.

Отримайте консультацію з налаштування гнучких правил для вашого магазину — наші спеціалісти допоможуть підібрати оптимальне рішення. Економія за рахунок зменшення покинутих кошиків може скласти до 100 000 грн на місяць.

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

Всі виконані роботи супроводжуються гарантією 6 місяців. У разі змін у вашій бізнес-логіці ми оперативно адаптуємо правила. Команда сертифікованих спеціалістів 1С-Бітрікс забезпечує стабільну роботу рішення навіть при високих навантаженнях.

Терміни орієнтовно

Базове налаштування через інтерфейс — 1 день. Розробка диференційованих лімітів із сповіщенням — від 3 до 5 днів. Терміни уточнюються після аудиту вашого проекту. Вартість розраховується індивідуально.

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

B2B-портали на 1С-Бітрікс

Наша спеціалізація — розробка B2B-порталів на 1С-Бітрікс. Не просто «інтернет-магазинів для оптовиків». Тут інший всесвіт: у кожного контрагента свій прайс, свій кредитний ліміт, свій набір документів і свій менеджер у Краснодарі. Роздрібний покупець обирає за картинкою та відгуками. Оптовик вбиває 50 артикулів у форму швидкого замовлення і чекає рахунок через 30 секунд.

У нас 10+ років досвіду в цій ніші, понад 50 проектів впровадження. Гарантія на роботи — 12 місяців. Сертифіковані спеціалісти 1С-Бітрікс. Зв'яжіться з нами — ми проаналізуємо вашу поточну структуру цін і запропонуємо архітектуру порталу під ваш бізнес.

Як влаштоване ціноутворення в B2B-порталі?

Якщо в роздробі одна ціна для всіх, то в B2B — матриця. Типи цін в b_catalog_price множаться на групи контрагентів, накопичувальні знижки, валютні перерахунки та договірні умови. Саме тут проект або злітає, або тоне в багах.

Типи цін і прайс-листи. У Бітрікс типи цін задаються через CCatalogGroup. Стандартний набір: роздрібна, дрібнооптова, оптова, дилерська, дистриб'юторська. Кожен контрагент прив'язаний до групи користувачів, група — до типу ціни. Але реальність складніша: один дилер може бачити оптові ціни на електроніку та дистриб'юторські на аксесуари. Це вже не штатний механізм — потрібна кастомна логіка через обробник OnSaleBasketItemBeforePriceSave.

Знижки — прогресивна шкала за обсягом (від 100 штук — мінус 5%, від 500 — мінус 12%), накопичувальні за період, сезонні, за категоріями. Знижки комбінуються через пріоритети в b_sale_discount. Порядок застосування — окремий головний біль: знижка може бути до або після фіксованої; пріоритети налаштовуються в «Правилах роботи з кошиком». При 20+ правилах налагодження перетворюється на квест.

Кредитні ліміти. Контрагенту встановлюється поріг відвантаження в кредит. Поточна заборгованість синхронізується з 1С через регістр РасчетыСКонтрагентами. Перевищення ліміту → блокування оформлення замовлення. Без цього менеджери відвантажують у борг, а бухгалтерія потім розгрібає дебіторку.

Договірні ціни — прайс прив'язаний до конкретного договору: терміни дії, номер, умови пролонгації. Договір закінчився — ціни перемикаються на базові автоматично. Реалізується через користувацькі властивості замовлення та обробник OnSaleComponentOrderProperties.

Валюта — для ЗЕД обов'язково. Перерахунок за курсом ЦБ (парсинг cbr.ru через CCurrencyRates::ConvertCurrency()) або фіксований курс контракту.

Що входить до дилерського кабінету?

Замовлення — повна історія з фільтрацією за статусами, датами, сумами. Повтор попереднього замовлення в один клік — для регулярних закупівель це економить години. Шаблони замовлень для типових позицій.

Фінанси — сальдо взаєморозрахунків, акт звірки, історія оплат. Все, що бухгалтер зазвичай запитує по email і чекає три дні — в кабінеті миттєво. Дані тягнуться з 1С через REST або CommerceML.

Документи — рахунки, накладні, рахунки-фактури, УПД, акти. Формуються в 1С, PDF пушиться на портал через інтеграцію. Завантаження одним кліком. Жодного «надішліть повторно, загубилося в пошті».

Управління співробітниками дилера — адміністратор створює обліковки з розмежуванням прав. Менеджер із закупівель формує замовлення, бухгалтер бачить лише фінанси, керівник — загальну картину. Реалізується через розширення стандартних груп користувачів Бітрікс.

Швидке замовлення: артикул + кількість = рахунок

B2B-клієнт знає, що йому потрібно. Каталог з красивими картками йому не потрібен — потрібна форма: артикул, кількість, наступний рядок.

• Форма швидкого замовлення — автопідстановка найменування та ціни при введенні артикула. Використовуємо AJAX-пошук по b_iblock_element.XML_ID або PROPERTY_ARTICLE. 50 позицій за 3 хвилини
• Імпорт з Excel/CSV — клієнт вивантажив зі своєї системи, завантажив на портал. Автоспівставлення артикулів, перевірка наявності, формування замовлення. Парсинг через PHPExcel або PhpSpreadsheet
• Кошик з повною інформацією — вага, об'єм, кількість місць, орієнтовна вартість доставки до оформлення

Чому інтеграція з 1С критична для B2B-порталу?

Без актуальних даних з 1С портал марний. Менеджер Іванов змінив ціну на цвяхи — через 15 хвилин дилер в Красноярську має бачити нову ціну.

CommerceML простіше: штатний модуль обміну, XML-файли, мінімум налаштувань. Але він повільний на великих каталогах і не підтримує кастомні сутності (кредитні ліміти, сальдо). REST API через HTTP-сервіс 1С — гнучкіший, швидший, але потребує доопрацювання на стороні 1С. На практиці часто використовуємо гібрид: CommerceML для каталогу, REST для цін, залишків і документів. Згідно з офіційною документацією 1С-Бітрікс, для B2B-порталів критично налаштувати синхронізацію довідників та залишків у реальному часі. Детальніше про CommerceML та REST API 1С-Бітрікс.

ЕДО: юридично значущий обмін без паперу

Для великих B2B-проектів:

• Провайдери — Контур.Діадок, СБІС, Калуга Астрал. Рахунки-фактури, акти, накладні в електронному вигляді з юридичною силою
• КЕП — кваліфікований електронний підпис. Контрагент підписує акт прямо в кабінеті
• Роумінг між операторами — без цього половина партнерів, у яких інший оператор ЕДО, залишиться за бортом

Багатофілійність

• Регіональні склади — клієнт бачить залишки найближчого складу, може обрати склад відвантаження. Товар є в Новосибірську, але немає в Москві — портал покаже обидва варіанти з різними термінами
• Автоназначення менеджера — дилер з Краснодару працює з Іваном, з Єкатеринбурга — з Мариною. За полем UF_REGION в картці контрагента
• Локальні умови — мінімальна сума замовлення, умови доставки, терміни — відрізняються за регіонами

Процес розробки B2B-порталів

Розробка B2B-порталів включає п'ять етапів. Нижче таблиця з орієнтовними термінами та результатами.

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

• Повна проектна документація (ТЗ, архітектурна схема, протоколи інтеграції)
• Налаштування серверного оточення та розгортання (On-Premise або хмара)
• Перенесення всіх користувацьких даних та конфігурацій
• Навчання адміністраторів порталу (2 заняття онлайн)
• Гарантійна підтримка 12 місяців з реакцією до 4 годин

Після запуску — техпідтримка та розвиток. B2B-портал — жива система, яка еволюціонує разом з бізнесом.

Середня економія часу менеджера на обробці замовлень — до 20 годин на тиждень.

На старті перевірте коректність типів цін та груп користувачів, обмежте кількість знижкових правил (не більше 3–4), протестуйте інтеграцію з 1С на реальних даних, видайте дилерам доступи та проведіть навантажувальне тестування на 50 одночасних користувачів.

Замовте розробку B2B-порталу та отримайте консультацію спеціаліста. Зв'яжіться з нами для обговорення вашого проекту — ми підготуємо попередній розрахунок та запропонуємо оптимальне рішення.