Ми часто стикаємося із завданням налаштування оптових цін в 1С-Бітрікс. Типова ситуація: клієнт хоче, щоб чим більше покупець бере, тим дешевше йому обходиться кожна одиниця. Базова механіка проста, але реалізація в Бітріксі потребує розуміння трьох різних підходів. Вибір неправильного — часта причина проблем із продуктивністю або некоректного розрахунку. Наприклад, при великій кількості товарів квантовані ціни можуть уповільнити каталог, тому ми оптимізуємо кешування та використовуємо індекси. У нас за плечима понад 50 успішних проєктів з Бітрікс і 10+ років досвіду. Ми гарантуємо, що запропонуємо оптимальне рішення під вашу архітектуру.
Які проблеми вирішуємо?
Оптові ціни за обсягом можуть бути реалізовані кількома способами, але кожен має нюанси. Розберемо типові сценарії.
Квантовані ціни: вбудований механізм
Модуль catalog підтримує ступінчасті ціни через таблицю b_catalog_price. Для одного товару задаються кілька рядків з одним типом ціни, але різними діапазонами QUANTITY_FROM і QUANTITY_TO. Чим більша кількість — тим нижча ціна. Налаштування в панелі: картка товару → вкладка «Ціни» → додавання рядків через інтерфейс або програмно через CCatalogProductPrice::Add(). При додаванні в кошик Бітрікс автоматом підбирає потрібний рядок — додатковий код не потрібен.
Знижки за сумою кошика
Якщо ціна залежить від загальної суми замовлення, використовуємо модуль знижок (CCatalogDiscount). Створюємо правило типу «На кошик» з умовою ORDER_PRICE > N і знижкою X%. Кілька рівнів: 50 000 → 5%, 100 000 → 8%, 200 000 → 12%. Налаштування: Магазин → Правила роботи з цінами. Важно виставити прапорці «Зупиняти подальше застосування» за пріоритетом.
Знижки за обсягом у категорії
Складний сценарій: знижка на товари з категорії X при сумі більше Y. Розширені умови знижки покривають це через умову «Розділ інфоблоку». Якщо потрібна нестандартна логіка (кілька категорій, вагові коефіцієнти) — реалізуємо через обробник OnSaleBasketBeforeSaved.
Як відобразити таблицю цін на вітрині?
Покупець повинен бачити ціни при різних обсягах до додавання в кошик. У bitrix:catalog.element в result_modifier.php підтягуємо всі рядки b_catalog_price з QUANTITY_FROM > 0, формуємо масив QUANTITY_PRICES і виводимо таблицею:
| Кількість |
Ціна за од. |
| 1-9 |
1 200 грн. |
| 10-49 |
1 050 грн. |
| 50+ |
900 грн. |
Чому стандартних інструментів може не вистачити?
У реальних проєктах часто зустрічаються гібридні схеми: знижка накопичується за видами товарів, застосовується тільки для певних груп користувачів або залежить від історії замовлень. У таких випадках ми проєктуємо кастомну систему на базі подій OnSaleBasketBeforeSaved і OnOrderSave. Приклад із практики: інтернет-магазин будівельних матеріалів, де оптова ціна рахувалася як сума замовлень за останній місяць з коефіцієнтом на категорію. Рішення потребувало 10 днів розробки, включаючи тести та документацію.
Як вибрати відповідний механізм?
| Механізм |
Коли застосовувати |
Приклад |
Складність |
| Квантовані ціни |
Проста знижка від кількості одного товару |
1-9 шт: 1000 грн, 10+: 850 грн |
Низька |
| Знижка на кошик |
Знижка від загальної суми замовлення |
При сумі >5000 грн: знижка 5% |
Середня |
| Кастомна логіка |
Складні правила з категоріями, вагами, історією |
Знижка на категорію "Кріплення" при сумі замовлення >3000 грн |
Висока |
Як ми це робимо?
- Аналізуємо бізнес-логіку: за яким параметром знижка (кількість, сума, категорія).
- Проєктуємо архітектуру: стандартний інструмент або кастомний обробник.
- Реалізуємо: налаштування інтерфейсу або написання коду.
- Тестуємо на граничних випадках — наприклад, при кошику з кількох товарів з різними одиницями виміру, дробових кількостях або змішаних кошиках. Для складних сценаріїв використовуємо агенти для перерахунку цін при зміні кошика, що знижує навантаження на сервер.
- Деплоїмо та супроводжуємо.
Орієнтовні терміни
- Налаштування ступінчастих цін через інтерфейс + імпорт: від 3 до 5 днів.
- Розробка кастомної логіки з відображенням: від 1 до 2 тижнів.
Вартість розраховується індивідуально після оцінки обсягу робіт.
Що входить в роботу?
- Документація з налаштувань та API.
- Передача доступів та вихідних кодів.
- Навчання ваших менеджерів роботі з інструментом.
- Підтримка протягом 30 днів після запуску.
Оцінимо ваш проєкт безкоштовно. Зв'яжіться з нами для консультації. Отримайте консультацію інженера безкоштовно – розповімо, який підхід підходить саме вам.
Приклад кастомного обробника OnSaleBasketBeforeSaved:
// Код для кастомної знижки на категорію
AddEventHandler('sale', 'OnSaleBasketBeforeSaved', 'CustomDiscountHandler');
function CustomDiscountHandler(Basket $basket) {
foreach ($basket as $item) {
// Логіка перевірки категорії та суми
}
}
Детальніше: OnSaleBasketBeforeSaved
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 хвилин дилер в Красноярську має бачити нову ціну.
| Дані |
Напрямок |
Механізм |
| Каталог, характеристики |
1С → Портал |
CommerceML або REST, 15–60 хв |
| Ціни за типами та контрагентами |
1С → Портал |
REST API, за подією або розкладом |
| Залишки по складах |
1С → Портал |
REST, 5–15 хв або realtime через HTTP-сервіс 1С |
| Замовлення |
Портал → 1С |
REST, реальний час |
| Статуси, відвантаження |
1С → Портал |
За подією |
| Взаєморозрахунки |
1С → Портал |
1–2 рази на день |
| Документи (PDF) |
1С → Портал |
За подією |
CommerceML простіше: штатний модуль обміну, XML-файли, мінімум налаштувань. Але він повільний на великих каталогах і не підтримує кастомні сутності (кредитні ліміти, сальдо). REST API через HTTP-сервіс 1С — гнучкіший, швидший, але потребує доопрацювання на стороні 1С. На практиці часто використовуємо гібрид: CommerceML для каталогу, REST для цін, залишків і документів. Згідно з офіційною документацією 1С-Бітрікс, для B2B-порталів критично налаштувати синхронізацію довідників та залишків у реальному часі. Детальніше про CommerceML та REST API 1С-Бітрікс.
ЕДО: юридично значущий обмін без паперу
Для великих B2B-проектів:
- Провайдери — Контур.Діадок, СБІС, Калуга Астрал. Рахунки-фактури, акти, накладні в електронному вигляді з юридичною силою
- КЕП — кваліфікований електронний підпис. Контрагент підписує акт прямо в кабінеті
- Роумінг між операторами — без цього половина партнерів, у яких інший оператор ЕДО, залишиться за бортом
Багатофілійність
- Регіональні склади — клієнт бачить залишки найближчого складу, може обрати склад відвантаження. Товар є в Новосибірську, але немає в Москві — портал покаже обидва варіанти з різними термінами
- Автоназначення менеджера — дилер з Краснодару працює з Іваном, з Єкатеринбурга — з Мариною. За полем
UF_REGION в картці контрагента
- Локальні умови — мінімальна сума замовлення, умови доставки, терміни — відрізняються за регіонами
Процес розробки B2B-порталів
Розробка B2B-порталів включає п'ять етапів. Нижче таблиця з орієнтовними термінами та результатами.
| Етап |
Термін |
Результат |
| Аудит процесів |
1–2 тижні |
Схема бізнес-процесів, карта інтеграцій |
| Проектування |
2–3 тижні |
Архітектура, прототипи, специфікація обміну з 1С |
| Розробка |
4–8 тижнів |
Кабінети, цінові механіки, інтеграції, документообіг |
| Тестування |
1–2 тижні |
Функціональне, інтеграційне, навантажувальне на реальних даних |
| Пілот |
2–3 тижні |
5–10 дилерів, зворотний зв'язок, доопрацювання |
Що входить в роботу:
- Повна проектна документація (ТЗ, архітектурна схема, протоколи інтеграції)
- Налаштування серверного оточення та розгортання (On-Premise або хмара)
- Перенесення всіх користувацьких даних та конфігурацій
- Навчання адміністраторів порталу (2 заняття онлайн)
- Гарантійна підтримка 12 місяців з реакцією до 4 годин
Після запуску — техпідтримка та розвиток. B2B-портал — жива система, яка еволюціонує разом з бізнесом.
Середня економія часу менеджера на обробці замовлень — до 20 годин на тиждень.
На старті перевірте коректність типів цін та груп користувачів, обмежте кількість знижкових правил (не більше 3–4), протестуйте інтеграцію з 1С на реальних даних, видайте дилерам доступи та проведіть навантажувальне тестування на 50 одночасних користувачів.
Замовте розробку B2B-порталу та отримайте консультацію спеціаліста. Зв'яжіться з нами для обговорення вашого проекту — ми підготуємо попередній розрахунок та запропонуємо оптимальне рішення.