Как спроектировать B2B-кабинет для дилеров: цены, остатки, документы и роли
Какие процессы нужно описать до разработки B2B-кабинета, как разделить роли и источники данных и по каким сценариям принимать результат.
В этой статье
Если перенести обычный интернет-магазин в закрытый раздел и добавить поле «ИНН», B2B-кабинет не получится. Дилеру нужны его цены, договоры, лимиты, остатки по складам, повтор заказа и документы. Внутри одной компании закупщик, бухгалтер и руководитель должны видеть разные действия.
Проектирование начинается не с главной страницы кабинета, а с пути заказа и модели доступа. Иначе красивый интерфейс быстро обрастает ручными согласованиями, а менеджеры продолжают обмениваться таблицами по почте.
Опишите участников и их решения
Компания-клиент — не один пользователь. У неё может быть несколько юридических лиц, договоров и адресов доставки. Пользователь действует от имени организации и получает роль.
Роль | Что ей нужно | Что ей часто нельзя |
|---|---|---|
Закупщик | Каталог, цены, корзина, повтор заказа | Менять договор и финансовый лимит |
Согласующий | Утверждать заказ и видеть отклонения от правил | Редактировать справочник товаров |
Бухгалтер | Счета, акты, взаиморасчёты | Менять состав уже согласованного заказа |
Руководитель клиента | Лимиты, пользователи, история и отчёты | Управлять настройками поставщика |
Менеджер поставщика | Клиенты, исключения, комментарии и статусы | Входить под пользователем без аудита действий |
Матрица прав должна проверяться на сервере. Скрытая кнопка в интерфейсе не запрещает прямой запрос. Для важных операций сохраняют кто, когда и от имени какой организации изменил данные.
Разделите общие и персональные данные
Описание товара и изображение обычно общие. Цена, доступный склад, минимальная партия, кратность упаковки и возможность отсрочки зависят от договора. Если смешать их в одной сущности, обновление каталога начнёт затирать персональные условия.
Каталог отвечает на вопрос, что можно заказать.
Соглашение определяет цену, валюту, скидку, минимальную сумму и доступный ассортимент.
Склад и резервирование определяют, сколько можно подтвердить и к какой дате.
Организация и договор определяют реквизиты, лимит и способ оплаты.
Пользователь и роль определяют, что можно видеть, создавать и согласовывать.
Источник каждого слоя фиксируют отдельно. Например, номенклатура и остатки приходят из 1С, маркетинговые описания редактируются на сайте, а кредитный лимит рассчитывает учётная система. Фраза «двусторонний обмен» не заменяет эти правила.
Покажите покупателю происхождение цены и наличия
В B2B цена часто вычисляется после выбора организации, договора, количества и склада. Кабинет должен объяснять, почему она такая: персональная цена, ступень объёма, акция или ручное согласование. Нельзя показывать ориентировочную цену как окончательную, если её ещё подтвердит менеджер.
Остаток тоже требует определения. «В наличии» может означать физическое количество, доступное с учётом резервов, квоту клиента или возможность поставить со склада партнёра. Покажите дату актуальности и ожидаемый срок, если данные обновляются пакетно.
Спроектируйте заказ как процесс
Пользователь выбирает организацию и договор до расчёта персональных условий.
Кабинет проверяет кратность, минимальную партию, лимит и доступность.
Если нужно согласование, заказ получает отдельное состояние и не уходит в отгрузку.
После утверждения фиксируются состав, цена и версия условий.
Учётная система возвращает подтверждение, резерв, документы и изменения отгрузки.
Отмена, частичная поставка и возврат сохраняются как события, а не затирают историю.
Повтор заказа должен создавать новую корзину по текущим условиям, а не копировать старую цену. Пользователю полезно видеть, какие позиции изменились, сняты или требуют согласования.
Документы — не папка с PDF
Счёт, акт, накладная и сверка относятся к конкретным юридическому лицу, договору и заказу. Поиск должен учитывать период, номер, статус и тип документа. Пользователь не должен получить документ другой организации из-за подмены ID в адресе запроса.
Если документы формируются не сразу, интерфейс показывает состояние подготовки и не предлагает скачивать пустой файл. Повторная генерация не должна создавать разные версии без понятной даты и статуса.
Что проверить на приёмке
Пользователь с двумя организациями видит правильные договоры и цены после переключения.
Закупщик не может утвердить заказ обходным запросом, если действие доступно только согласующему.
Повтор старого заказа пересчитывает условия и показывает отличия.
Изменение остатка и лимита приходит в согласованный срок, а устаревшее значение не выдаётся за актуальное.
Два одновременных заказа не резервируют один и тот же остаток без контроля конфликта.
Документы доступны только пользователям нужной организации и фиксируются в журнале скачивания.
Недоступность 1С не удаляет заказ: он получает понятное состояние и повторяется без дубля.
Первая версия B2B-кабинета может быть небольшой: персональный каталог, заказ, согласование и документы. Но модель организаций, ролей, договоров и источников данных нужно заложить сразу. Эти сущности трудно безболезненно добавить после того, как права и цены уже размазаны по интерфейсу и интеграциям.
Moving a standard online store to a restricted section and adding an "INN" field does not create a B2B portal. Dealers need their own prices, contracts, limits, warehouse stock, order repetition, and documents. Within a single company, a purchaser, accountant, and manager must see different actions.
Design begins not with the portal's homepage, but with the order path and access model. Otherwise, a beautiful interface quickly accumulates manual approvals, and managers continue exchanging tables via email.
Describe participants and their decisions
A client company is not a single user. It may have multiple legal entities, contracts, and delivery addresses. A user acts on behalf of the organization and is assigned a role.
Role | What they need | What they are often not allowed to do |
|---|---|---|
Purchaser | Catalog, prices, cart, reorder | Change contract and financial limit |
Approver | Approve orders and view rule violations | Edit product catalog |
Accountant | Invoices, acts, settlements | Change the composition of an already approved order |
Client Manager | Limits, users, history, and reports | Manage supplier settings |
Supplier Manager | Customers, exceptions, comments, and statuses | Log in as a user without action auditing |
The permission matrix must be validated on the server. A hidden button in the interface does not prevent a direct request. For critical operations, record who, when, and on behalf of which organization changed the data.
Separate shared and personal data
Product descriptions and images are typically shared. Prices, available stock, minimum order quantity, packaging multiples, and payment terms depend on the contract. If mixed in a single entity, catalog updates will begin to overwrite personal conditions.
The catalog answers what can be ordered.
The agreement defines the price, currency, discount, minimum order amount, and available assortment.
Warehouse and reservation determine how much can be confirmed and by what date.
Organization and contract define the billing details, limit, and payment method.
User and role define what can be viewed, created, and approved.
The source for each layer must be recorded separately. For example, product catalogs and stock levels come from 1C, marketing descriptions are edited on the website, and credit limits are calculated by the accounting system. The phrase "two-way exchange" does not replace these rules.
Show the buyer the origin of prices and availability
In B2B, prices are often calculated after selecting the organization, contract, quantity, and warehouse. The dashboard must explain why a price is set that way: personal pricing, volume tier, promotion, or manual approval. Do not display an estimated price as final if it still requires manager confirmation.
Stock status also requires clear definition. "In stock" may mean physical quantity available after accounting for reservations, a customer quota, or the ability to ship from a partner warehouse. Show the data freshness date and expected delivery time if updates occur in batches.
Design the order as a process
The user selects the organization and contract before calculating personalized terms.
The cabinet checks multiples, minimum batch size, limit, and availability.
If approval is required, the order receives a separate status and does not proceed to shipment.
After approval, the composition, price, and version of terms are fixed.
The accounting system returns confirmation, reservation, documents, and shipment changes.
Cancellations, partial shipments, and returns are saved as events and do not overwrite history.
Reordering must create a new cart based on current conditions, not copy old prices. Users benefit from seeing which items have changed, been removed, or require approval.
Documents are not a PDF folder
Invoices, acts, waybills, and reconciliations belong to a specific legal entity, contract, and order. Search must account for period, number, status, and document type. Users must not receive a document from another organization due to ID substitution in the request URL.
If documents are not generated immediately, the interface displays the preparation status and does not offer to download an empty file. Regeneration must not create different versions without a clear date and status.
What to check during acceptance testing
A user with two organizations sees the correct contracts and prices after switching.
A purchaser cannot approve an order via a bypass request if the action is available only to an approver.
Repeating an old order recalculates terms and displays differences.
Changes to stock and limits arrive within the agreed timeframe, and outdated values are not presented as current.
Two simultaneous orders do not reserve the same stock without conflict control.
Documents are accessible only to users of the relevant organization and are logged in the download journal.
1C unavailability does not delete an order: it receives a clear status and retries without creating a duplicate.
The first version of the B2B cabinet may be small: a personal catalog, order, approval, and documents. However, the model for organizations, roles, contracts, and data sources must be established from the start. These entities are difficult to add painlessly after rights and prices have already been scattered across the interface and integrations.
Обсуждение 0
Делись опытом и задавай вопросы. Комментарии без ссылок появляются после проверки редактором.
Пока никто не написал. Начни обсуждение.