B2B-портал самообслуговування: ролі покупців і повторні замовлення

Закупівельник повторює минуле замовлення, але тепер працює з іншою філією, а частину товарів продають новими упаковками. Якщо B2B-портал самообслуговування лише копіює старий кошик, помилка переходить у закупівлю. Надійний кабінет спочатку перевіряє, від чиєї компанії діє людина, що їй дозволено та які умови чинні зараз. Саме ці правила варто описати до вибору платформи й дизайну.

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

Почніть із компанії, філії та конкретної людини

Одна юридична особа може мати кілька місць доставки та різних працівників із закупівель. Не зводьте їх до одного логіна «відділ закупівель». Компанія визначає договірний контекст, філія — доступний асортимент і адресу, а користувач — автора конкретної дії. Ці зв’язки потрібні і для зручності, і для розбору помилок: хто створив замовлення та для якого підрозділу.

У документації Shopify B2B компанія, її локація та покупець описані як окремі сутності. Локація може мати власні ціни, адреси й умови оплати. Це приклад моделі даних, а не вимога обирати Shopify. Для вашого порталу спочатку з’ясуйте, де вже зберігаються ці зв’язки та хто має право їх змінювати.

Показуйте активну філію поруч із кошиком. Після перемикання контексту перевіряйте адресу та прайс заново. Сам доступ до філії ще не означає права робити закупівлі від її імені.

Розділіть робочі ролі та межі делегування

Ролі покупців у B2B-кабінеті варто будувати навколо дій, а не назв посад. Людина може переглядати каталог, готувати кошик, оформлювати закупівлю, читати рахунки або керувати колегами. Це різні дозволи. В Adobe Commerce, наприклад, права компанії окремо охоплюють оформлення, перегляд замовлень і керування користувачами. Конкретний набір залежить від рішення та налаштувань.

Умовну стартову матрицю нижче уточніть разом із покупцями. Позначка «за правилом» означає окреме налаштування, а не автоматичний доступ.

Адміністратор клієнта не повинен видавати собі всі права

Делеговане адміністрування означає, що клієнт сам підтримує список працівників, але тільки в установлених продавцем межах. Запишіть, які ролі він може призначати, до яких філій додавати людей і чи може створювати іншого адміністратора. Якщо право керувати колегами автоматично дає право витрачати кошти, межа відповідальності стає нечіткою.

Запрошення має вести до персонального облікового запису з визначеним терміном прийняття. Для тимчасового заміщення зберігайте дату завершення повноважень і того, хто їх надав. Не вирішуйте відпустку закупівельника передачею його пароля. Після повернення працівника тимчасові дозволи мають припинятися за заздалегідь визначеним правилом.

Перевіряйте дозвіл у момент дії

OWASP розрізняє автентифікацію й авторизацію: успішний вхід підтверджує особу, але не дозвіл на будь-яку операцію. Для порталу це означає перевірку доступу до конкретного замовлення, документа та філії на сервері. Прихована кнопка не замінює такої перевірки.

Окремий сценарій — працівника заблокували, коли його кошик уже відкритий. Система має повторно перевірити повноваження перед відправленням, а не довіряти старому екрану. Так само перевіряйте завантаження рахунка за прямим посиланням. Зміна ролі повинна впливати на доступ, а не лише на вигляд меню після наступного входу.

Повторюйте склад закупівлі, а не минулі умови

Надійне повторне замовлення починається з нової чернетки на основі історії. Старий документ залишається історичним фактом, а новий кошик перевіряється за поточними правилами. Ціна, мінімальна партія, кратність упаковки, доступність товару та адреса могли змінитися. Покупець має побачити різницю до відправлення, а не після отримання рахунка.

Розділіть результат перевірки на зрозумілі групи: готове до закупівлі, потребує виправлення та недоступне. Для кожного проблемного рядка потрібне пояснення і дія. «Не вдалося повторити» не допомагає зрозуміти, чи зник артикул, чи бракує права на каталог. Не підміняйте товар аналогом і не збільшуйте кількість до упаковки без явного рішення користувача.

Навіть у готових платформах поведінка повтору має нюанси. Документація Adobe про повторні замовлення описує перевірки доступності й те, що вже наявні товари кошика можуть залишатися після додавання повтору. Тому в прийманні перевірте не лише порожній кошик: дізнайтеся, чи система додає рядки, об’єднує їх або створює окрему чернетку.

Умовний приклад: заміна закупівельника та нова упаковка

Припустімо, мережа майстерень замовляє витратні матеріали у дистриб’ютора. Це навчальний сценарій, не кейс GL.ua. Закупівельниця філії «Північ» у відпустці, її тимчасово заміщує колега. Йому дозволили купувати лише для цієї філії до визначеної дати, без доступу до рахунків інших підрозділів і без права запрошувати нових працівників.

Колега відкриває попереднє замовлення: рукавички, серветки та очищувач. Рукавички тепер відвантажують іншими упаковками, очищувач недоступний, а серветки можна купити на чинних умовах. Правильний результат — нова чернетка з усіма рядками й позначеними розбіжностями. Серветки готові; для рукавичок потрібно обрати допустиму кількість; очищувач не можна непомітно вилучити із закупівлі.

Після виправлення покупець бачить підсумок змін і підтверджує новий склад. Якщо він перемикається на філію «Захід», портал не дозволяє використати кошик поза наданими повноваженнями. Якщо термін заміщення минув до відправлення, дія зупиняється з поясненням. Менеджер отримує звернення про виняток, але не мусить вручну відновлювати всю закупівлю з листування.

Критерій приймання: закупівля проходить від імені правильної філії, заборонена дія не створює документа, зміни не губляться. Визначте також, кому передаються чернетки після завершення заміщення.

Після натискання кнопки покупцю потрібен визначений результат

Самообслуговування не завершується повідомленням «запит надіслано». Покажіть окремо прийняття порталом, передачу в облікову систему та підтвердження замовлення. Якщо відповідь затримується, поясніть поточний стан і наступну дію. Покупець не повинен здогадуватися, чи треба натиснути кнопку ще раз або телефонувати менеджеру.

У технічному завданні визначте спільний ідентифікатор операції та правило розпізнавання повторної відправки. Це запропонована вимога до інтеграції, не автоматична властивість будь-якого порталу. Перевірте ситуацію, коли облікова система прийняла документ, але відповідь не дійшла. Повторна спроба має спершу з’ясувати результат, а не безумовно створити нове замовлення.

Межі відповідальності між системами варто розглядати окремо від ролей покупця. Якщо незрозуміло, де зберігається головний статус, допоможе матеріал про те, коли інтернет-магазину потрібна OMS. А нестандартна закупівля з індивідуальними умовами належить до іншого процесу — погодження B2B-пропозиції. Не змішуйте ці маршрути в одній кнопці «повторити».

Проведіть передзапусковий тест під робочими ролями

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

1. Увійдіть як закупівельник однієї філії та спробуйте відкрити замовлення іншої, зокрема за прямим посиланням. Очікування — відмова без розкриття документа.
2. Запросіть колегу через адміністратора покупця. Перевірте дозволену область і спробу видати ширші права, ніж має право делегувати адміністратор.
3. Відкрийте кошик, потім відкличте право оформлення. Спроба відправлення має пройти нову перевірку й завершитися контрольованою відмовою.
4. Повторіть закупівлю зі зміненими ціною, упаковкою та доступністю. Звірте кожен рядок і пояснення; випробуйте також непорожній кошик.
5. Імітуйте втрату відповіді після прийняття документа обліковою системою. Перевірте повторну спробу, пошук результату та відсутність зайвого замовлення.
6. Завершіть термін заміщення, заблокуйте користувача й перевірте доступ до документів. Звірте журнал дій та маршрут передачі незавершених чернеток.

Для відхилень призначте відповідальних і повторні тести. Доступ до чужих документів, закупівля поза повноваженнями або непомітна втрата рядків — причини відкласти запуск.

Як обмежити строки, витрати та операційні ризики

Строки залежать від готовності довідника компаній, якості історії замовлень і правил у вашій ERP — системі обліку ресурсів підприємства. Спочатку перевірте одну наскрізну закупівлю на тестових даних. Далі розширюйте ролі, філії й винятки. Календарна оцінка до перевірки інтеграції приховує головну невизначеність: чи можна отримати актуальні умови та однозначний результат відправлення.

У кошторис включайте аналіз повноважень, очищення зв’язків між клієнтами й філіями, інтерфейс розбіжностей, інтеграцію, тести доступу, журналювання та навчання. Окремо оцініть підтримку, ліцензії, інфраструктуру й зміни правил після запуску. Не плутайте економію на ручному введенні з гарантованим скороченням усіх витрат: частина роботи переміститься в підтримку даних і доступів.

Якщо регулярних закупівель мало, а умови щоразу індивідуальні, повний портал може бути передчасним. Почніть із персональної історії та контрольованого створення чернетки. За складних філіальних структур потрібне гнучкіше рішення, але сам вибір Drupal чи іншої платформи не створює правильної моделі прав. Її доведеться спроєктувати та перевірити.

Після пілота вимірюйте частку закупівель без ручного втручання та причини зупинок. Порівнюйте однакові типи замовлень, щоб відрізнити проблему інтерфейсу від застарілого каталогу.

Починати варто з карти повноважень і одного складного повторного замовлення, а не з переліку бажаних віджетів. Для обговорення розробки B2B-кабінету з GL.ua (Глянець) підготуйте структуру філій, перелік ролей і знеособлений приклад закупівлі зі змінами. На цій основі можна визначити межі пілота та предметно оцінити інтеграцію.