Послуги з розробки B2B-порталів на 1С-Бітрікс

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

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

Ціноутворення: де 80% складності B2B-порталу

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

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

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

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

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

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

Дилерський кабінет: самообслуговування без дзвінків менеджеру

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

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

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

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

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

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

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

Інтеграція з 1С: становий хребет

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

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

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

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

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

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

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

Терміни

Типовий B2B-портал — 2–4 місяці:

1. Аудит процесів (1–2 тижні) — як працюєте з дилерами зараз? Які прайси, документи, інтеграції?
2. Проєктування (2–3 тижні) — архітектура, прототипи кабінетів, специфікація обміну з 1С
3. Розробка (4–8 тижнів) — кабінети, цінові механіки, інтеграції, документообіг
4. Тестування (1–2 тижні) — функціональне, інтеграційне, навантажувальне. На реальних прайсах і даних із 1С
5. Пілот (2–3 тижні) — 5–10 ключових дилерів, зворотний зв'язок, доопрацювання

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