Налаштування узгодження замовлення для B2B на 1С-Бітрікс
Уявіть: менеджер створює замовлення на 150 000 гривень, але воно йде в пустку — немає автоматичного сповіщення, немає статусу. Керівник дізнається про нього через тиждень у пошті, а на той момент постачальник уже відмовився від броні. Багато хто стикається з такою проблемою. Ми налаштовуємо повний цикл узгодження замовлень на 1С-Бітрікс, щоб виключити втрати. У цій статті розберемо налаштування статусів, сповіщень та багаторівневого узгодження на реальних прикладах.
Чому ручне узгодження — зло?
Ручна обробка замовлень породжує хаос: замовлення губляться, дублюються, терміни затягуються. За даними досліджень, до 30% замовлень губляться при ручній обробці в B2B. Автоматизація на Бітріксі дає чіткий статус кожного замовлення (APPROVAL, APPROVED, REJECTED), автоматичні сповіщення з прив'язкою до поштових подій та аудит усіх дій (хто, коли, що змінив). Це знижує навантаження на закупівельників до 40%.
Як працює узгодження замовлень у B2B?
Стандартний сценарій: співробітник створює замовлення зі статусом «На узгодженні» → сповіщення йде керівнику → керівник у кабінеті підтверджує або відхиляє → при підтвердженні замовлення переходить в обробку, при відхиленні — співробітнику приходить сповіщення з причиною. Складніші схеми враховують суму (до 50 тисяч — без узгодження, від 50 до 200 тисяч — один рівень, від 200 тисяч — два рівні) або категорію товарів.
| Характеристика | Однорівнева схема | Багаторівнева схема |
|---|---|---|
| Кількість узгоджувачів | 1 | 2+ |
| Гнучкість правил | Базова | Висока (сума, категорія) |
| Термін впровадження | 1 тиждень | 2-3 тижні |
| Ризик помилок | Мінімальний | Середній |
Самописна схема на колінці поступається нашому налаштуванню на Highload-блоках у 3 рази за швидкістю впровадження — ми вже відлагодили шаблони. На одному з проектів (мережа оптової торгівлі) ми налаштували багаторівневе узгодження через Highload-блоки, що скоротило час обробки замовлення з 8 секунд до 1.2 секунди.
Як налаштувати статуси замовлень для узгодження?
У Бітріксі замовлення має статус (b_sale_status). Додаємо кастомні статуси:
-
APPROVAL— очікує узгодження -
APPROVED— узгоджено, передано в обробку -
REJECTED— відхилено
Додавання статусів: CSaleStatus::Add() або через панель управління Магазин → Налаштування → Статуси замовлень. При створенні замовлення співробітником (не власником компанії) — обробник OnSaleOrderSaved перевіряє роль користувача. Якщо роль вимагає узгодження і сума вище порогу — статус замовлення змінюється на APPROVAL, стандартна обробка тимчасово призупиняється.
Як налаштувати покроковий процес узгодження?
Ось проста інструкція для типової однорівневої схеми:
- Створіть кастомні статуси: APPROVAL, APPROVED, REJECTED у розділі «Статуси замовлень».
- Призначте права: для ролі «approver» дайте доступ на зміну статусу.
- Налаштуйте поштову подію
B2B_ORDER_APPROVAL_REQUESTз шаблоном листа, що містить суму та посилання. - Напишіть обробник на подію
OnSaleOrderSaved: якщо замовлення створено користувачем з роллю «employee» і сума > порогу, змініть статус на APPROVAL. - Створіть сторінку в кабінеті користувача зі списком замовлень у статусі APPROVAL. Додайте кнопки «Узгодити»/«Відхилити».
- При натисканні викликайте
CSaleOrder::UpdateStatus()і надсилайте сповіщення ініціатору.
Сповіщення та інтерфейс узгодження
При переході в APPROVAL — поштова подія B2B_ORDER_APPROVAL_REQUEST йде узгоджувачу. У листі: список позицій, сума, посилання на сторінку узгодження. Сторінка узгодження в кабінеті — список замовлень у статусі APPROVAL для поточного користувача (або для компанії, якщо в нього роль approver). Кнопки: «Узгодити» / «Відхилити» з полем причини. При натисканні — AJAX-запит до обробника, який змінює статус замовлення через CSaleOrder::UpdateStatus() і надсилає сповіщення творцю.
Які бувають рівні узгодження?
Для дворівневої схеми — Highload-блок order_approvals: UF_ORDER_ID, UF_APPROVER_ID, UF_LEVEL (1, 2), UF_STATUS, UF_COMMENT, UF_DATE. Замовлення переходить в основну обробку тільки коли всі записи зі статусом approved. При відхиленні на будь-якому рівні — замовлення отримує статус REJECTED, ланцюжок переривається.
Детальна діаграма статусів
- Нове замовлення (N) → перевірка правил → якщо потрібне узгодження → APPROVAL
- APPROVAL → якщо всі узгодили → APPROVED; якщо відхилено → REJECTED
- APPROVED → в обробку
- REJECTED → можливе повторне надсилання
Що входить у налаштування?
| Етап | Результат |
|---|---|
| Аналіз бізнес-процесів | Схема ролей та порогів |
| Проектування | Макет узгодження |
| Реалізація | Статуси, обробники, HL-блоки |
| Сповіщення | Поштові шаблони, події |
| Тестування | 10+ сценаріїв |
| Навчання | Інструкції для менеджерів |
Гарантуємо коректну роботу під навантаженням до 10 000 замовлень на день. Наш досвід — понад 10 років на ринку, 40+ проектів по Бітрікс, сертифіковані спеціалісти. Зв'яжіться з нами для розрахунку — ми підберемо оптимальну схему узгодження замовлень під ваш бізнес. Отримайте консультацію з автоматизації B2B-процесів на Бітрікс.
Налаштування однорівневого узгодження: 1 тиждень. Багаторівнева схема з гнучкими правилами: 2-3 тижні. Вартість розраховується індивідуально під ваш сценарій.
Додаткові матеріали: CommerceML — стандарт обміну даними з 1С, REST API Бітрікс24 для інтеграції із зовнішніми системами.







