B2B eCommerce development Baku — это не задача «разместить каталог и добавить корзину». Для дистрибьютора, оптовой компании или производителя платформа должна учитывать коммерческие отношения с конкретным клиентом: от имени какой организации действует пользователь, какие товары ему доступны, какая договорная цена применима, кто имеет право подтвердить заказ и можно ли передать его в ERP.

Как правило, B2B-платформа не заменяет ERP. ERP остаётся системой учёта для номенклатуры, клиентских счетов, договоров, цен, кредитного контроля, заказов, отгрузок и счетов. Цифровой B2B-слой даёт клиентам безопасный self-service доступ к разрешённым данным и процессам, снижая объём повторного ввода заказов из email, звонков и таблиц.

Чем B2B-заказ отличается от обычного интернет-магазина

В B2C-магазине посетители нередко видят один каталог, одну цену и небольшой набор способов доставки. В B2B итог зависит от аккаунта клиента. Один и тот же товар может быть доступен одной организации и закрыт другой; цена может определяться договором, группой клиента, объёмом, единицей измерения, филиалом, валютой или условиями поставки.

Поэтому при формировании каждой строки заказа система должна установить:

  • какая организация, юридическое лицо или филиал является покупателем;
  • разрешено ли этому аккаунту просматривать и заказывать товар;
  • какие цена, скидка, единица измерения, налог и условия доставки действуют;
  • достаточен ли доступный для продажи остаток на нужную дату;
  • разрешает ли кредитный статус продолжить заказ, требует проверки или блокирует его;
  • нужно ли согласование внутри компании клиента, проверка продавцом или немедленное создание заказа в ERP.

Эти правила нельзя надёжно реализовать как набор условий на страницах интерфейса. Их необходимо моделировать как контролируемые бизнес-правила с понятными статусами, владельцами и журналом действий.

Ключевые функции серьёзной B2B-платформы

Корпоративные аккаунты и роли закупки

У одного клиента могут быть несколько покупателей, согласующих лиц, филиалов, центров затрат и адресов доставки. Пользователь должен быть связан с организацией, но его доступ не должен автоматически распространяться на все её данные. Например, закупщик создаёт черновики, руководитель утверждает заказы выше лимита, финансовый сотрудник видит документы, а локальный администратор управляет пользователями только своего подразделения.

Проверка прав должна выполняться на сервере для каждого объекта и действия: просмотра цены, открытия документа, изменения адреса, утверждения или отмены заказа. Скрыть кнопку в интерфейсе недостаточно. Если пользователь меняет идентификатор заказа в адресе или API-запросе, он не должен получить доступ к данным другой компании. При проектировании такой логики полезны веб-платформы и приложения POLADO, а для понятных рабочих экранов с множеством ролей — UI/UX и продуктовый дизайн.

Индивидуальные каталоги и договорные цены

Customer-specific pricing portal не должен хранить только одно значение цены у товара. Коммерческая цена может определяться договором, ценовой группой, программой лояльности, объёмной ступенью, вариантом товара, упаковкой, акцией или условиями поставки. Покупатель должен видеть понятный результат, а бизнес — понимать основание цены: договорная, объёмная, предварительная или требующая согласования.

Надёжнее не переносить сложную ценовую формулу в браузер. Портал может обращаться к сервису ценообразования ERP в реальном времени, использовать синхронизированную проекцию цен или комбинировать оба подхода. Но окончательная проверка должна выполняться авторитетной коммерческой системой при принятии заказа. Это предотвращает расхождения при изменении договоров, прайс-листов и мастер-данных.

Каталог также должен фильтроваться до добавления товара в корзину: по доступности для аккаунта, ассортименту, территории, статусу товара и правилам распределения. Разрешённые замены следует показывать как контролируемые альтернативы, а не подменять товар незаметно.

Согласование заказов: не письмо, а модель состояний

Approval order workflow development означает определение статусов и разрешённых переходов, а не только отправку уведомления по email. Заказ может находиться в состояниях «Черновик», «Отправлен», «Ожидает согласования клиента», «На проверке продавца», «Кредитная блокировка», «Принят ERP», «Частично принят», «Отклонён», «Отменён» и «Исполнен».

Допустим, закупщик отправляет заказ выше корпоративного лимита. Он должен попасть согласующему лицу. Если после согласования меняются количество, адрес или дата доставки, система обязана применить заранее определённое правило: вернуть заказ на повторное согласование, разрешить изменение в пределах допуска или направить на проверку продавцу. В журнале следует хранить исполнителя, время, прежний и новый статус, причину и изменённые позиции. Это создаёт проверяемый процесс вместо неструктурированной переписки.

Кредитный статус, остатки и доставка

Статус «в наличии» редко отвечает на реальную B2B-потребность. Важно различать доступный для продажи, зарезервированный, доступный на конкретном складе, распределяемый по квоте и ожидаемый товар. Платформа должна обещать только то, что может подтвердить бизнес-процесс. Если данные об остатках обновляются с задержкой, это нужно учитывать в финальной проверке заказа.

Кредитный контроль также требует аккуратного UX. Необязательно раскрывать каждому закупщику лимит или задолженность, но нужно ясно сообщить результат: заказ принят к обработке, ожидает финансовой проверки или требует связи с ответственным сотрудником. Допустимые способы доставки могут зависеть от графика маршрута, минимальной суммы, зоны склада, температурного режима, ограничений на опасные грузы и договорных условий перевозки.

Архитектура ERP-интегрированной B2B-платформы

Сначала зафиксируйте владельца каждого типа данных. Типовое разделение выглядит так:

  • ERP: номенклатура, счета клиентов, договоры, цены, остатки, кредитный статус, официальные заказы, счета и статус исполнения.
  • B2B-платформа: пользовательские учётные записи, связи пользователь—компания, корзины, списки покупок, маршруты согласования, интерфейс и уведомления.
  • Интеграционный слой: адаптация API, аутентификация, очереди, повторные попытки, идемпотентность, мониторинг и сверка.

Далее определите, какие данные должны быть актуальны в момент запроса. Изображения и описания товаров обычно можно синхронизировать. Для окончательной цены, кредитного статуса и доступности может понадобиться запрос в реальном времени. На практике часто подходит гибридная схема: данные для поиска и просмотра синхронизируются, а коммерчески критичные параметры повторно проверяются при оформлении.

Особое внимание требуется при передаче заказа. У каждого заказа портала должен быть постоянный внешний идентификатор, а создание заказа в ERP должно быть идемпотентным. Если пользователь повторно нажмёт кнопку, сработает retry после тайм-аута или потеряет соединение уже после принятия заказа ERP, в ERP не должен появиться дубль. Храните идентификатор портала, номер документа ERP, историю попыток передачи и ответ системы. Для мониторинга интеграций, безопасных релизов и дальнейшего сопровождения используйте техническую поддержку и консалтинг.

Исключения нужно проектировать заранее

Ценность B2B-системы определяется не только успешным сценарием. Нужно заранее обработать отсутствие договорной цены, кредитную блокировку, недоступное количество, снятый с продажи товар, неподходящий адрес доставки, частичное подтверждение, запрос замены и временную недоступность ERP.

У каждого исключения должны быть владелец, следующий шаг и ясное сообщение для клиента. Например, позиция без цены становится запросом на коммерческую проверку; кредитный вопрос попадает в финансовую очередь; при недоступности ERP заказ может иметь статус «получен, ожидает обработки», а не ложное подтверждение; частично подтверждённый заказ должен отдельно показывать принятые, отложенные и отклонённые количества. Внутренним командам нужны очереди с кодами причин, сроками, ответственными и безопасными действиями, а не ещё один общий почтовый ящик.

Что выбрать: слой eCommerce над ERP, расширение портала или отдельную платформу?

  • Слой eCommerce над ERP подходит, когда главная задача — повторные заказы, персональные каталоги, договорные цены и прозрачность статусов, а ERP предоставляет достаточные интерфейсы и процесс относительно стандартизирован.
  • Расширение существующего клиентского портала подходит, если клиенты уже используют его для документов, сервисных обращений или информации по счёту, и заказ логично становится частью того же защищённого опыта.
  • Специализированная операционная платформа нужна при нескольких юридических лицах, сложных отношениях производителя, дистрибьютора и покупателя, нестандартном распределении товара, многоуровневом согласовании, заказах через полевых продавцов или значительном количестве межсистемных исключений.

Чек-лист перед стартом разработки

  1. Какие ERP, WMS, CRM и финансовые системы являются источником данных для заказа?
  2. Где поддерживаются иерархия клиента, роли пользователей, лимиты согласования и адреса?
  3. Какая задержка обновления допустима для каталога, цен и доступности?
  4. Какие условия требуют проверки человеком или согласования?
  5. Как будут отражаться изменения заказа, частичные поставки, замены, отмены и возвраты?
  6. Что произойдёт, если ERP приняла заказ, но портал не получил ответ?
  7. Какие данные должны быть скрыты от закупщика, пользователя филиала и другой организации?
  8. Какая команда отвечает за каждое исключение и какие действия необходимо журналировать?

Правильно спроектированная B2B-платформа не исключает отдел продаж и операционные команды. Она сокращает повторный ввод, рутинные уточнения цен и запросы статуса, позволяя людям сосредоточиться на исключениях и отношениях с клиентами. Если вы хотите перевести повторные заказы из email, звонков и таблиц в контролируемый цифровой канал без замены ERP, POLADO поможет описать процесс, определить границы интеграции и реализовать поэтапную платформу заказов.