Личный кабинет дилера на Laravel: цены, согласования и заказы в 1С

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

Разберём разработку кабинета дилера на Laravel через одну закупку: кто вправе заказать, какую цену увидит, что произойдёт при согласовании и как данные попадут в 1С. Покажем реальные экраны Bagisto B2B как примеры решений. Они помогают обсуждать требования, но не означают, что любая установка Laravel уже содержит эти функции.

Начните с повторяющейся закупки, а не списка разделов

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

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

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

Разделите компанию, договор и пользователя

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

На официальном экране Bagisto B2B права роли разложены по действиям: профиль компании, предложения, сообщения и заказы. Это пример интерфейса настройки. В проекте на Laravel такой экран ещё нужно связать с серверными проверками доступа и правилами конкретной компании.

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

Запишите порядок выбора цены до проектирования каталога

У дилера может быть индивидуальная цена по договору, скидка группы, порог количества и отдельное предложение менеджера. Эти правила способны противоречить друг другу. В задании должен быть их приоритет, срок действия и поведение при смене договора. Формулировка «поддержать персональные цены» оставляет главное решение открытым.

Учебный пример: базовая цена — 1 200 ₽, цена группы — 960 ₽, при количестве от 12 штук — 920 ₽, договорная цена — 850 ₽. Товар продаётся упаковками по шесть. Если договор имеет приоритет и покупатель заказывает 18 штук, стоимость товара — 15 300 ₽. Запрос на 14 штук должен вызвать согласованное действие: предложить изменить количество либо оформить исключение. Незаметно увеличить заказ до 18 нельзя.

В Bagisto Company Catalog есть отдельная настройка ступеней количества. На скриншоте показана форма добавления таких условий, а не рассчитанный прайс из нашего примера. Для российского магазина отдельно согласуют источник договорных цен в 1С, единицы измерения и правила округления.

Цена должна совпадать в каталоге, поиске, корзине, выгрузке и заказе. Если в кабинете есть кеширование, требуется проверить, что персональный ответ одного дилера не попадёт другому. Когда условия изменились во время заполнения корзины, покупателю нужно показать изменение и пересчитать заказ по заранее установленному правилу.

Дайте закупщику быстрый способ собрать большой заказ

Розничный сценарий «открыть карточку — выбрать — добавить» плохо подходит человеку, у которого готов список из десятков артикулов. Для него полезнее поиск по SKU, загрузка файла с количеством, повтор предыдущей покупки и сохранённые списки закупки. Какие способы нужны, лучше выяснить по реальным файлам дилеров.

На примере Quick Order в Bagisto B2B видны ввод нескольких артикулов, загрузка CSV и список выбранных товаров. Это готовый образец обсуждения интерфейса: закупщик должен видеть, какие строки приняты и что с ними произойдёт при добавлении в корзину.

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

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

Разведите черновик, предложение и подтверждённый заказ

Черновик ещё редактируется. Коммерческое предложение фиксирует согласуемые условия. Подтверждённый заказ запускает обязательные действия в выбранной модели: резерв, обработку или подготовку отгрузки. Если назвать все три состояния словом «Заказ», участники будут по-разному понимать, можно ли менять сумму и кто уже должен действовать.

В официальном примере Quotation Handling показаны сведения о предложении, компании, товарах и сроке действия. Экран полезен как пример сохранения договорённостей. Конкретный проект должен определить, какая версия предложения была принята, кем и когда, а затем связать её с созданным заказом.

Представим, что руководитель согласовал 15 300 ₽, после чего закупщик увеличил количество. Для такого изменения заранее выбирают правило: повторное согласование, разрешённое отклонение или запрет изменения. Автоматическое сохранение старого одобрения для любой новой суммы создаёт управленческую ошибку даже при технически исправном сайте.

Условия после истечения срока предложения также нужно описать: что пересчитывается, можно ли продлить срок, кто подтверждает новую цену. В истории должны оставаться основания решения. Внутреннее согласование в кабинете не следует автоматически приравнивать к юридически значимому подписанию документа.

Свяжите кабинет с учётом через понятные состояния

До разработки договоритесь, где ведутся организации, договоры, цены, кредитные условия, остатки и документы. Если источник договоров — 1С, сотрудники не должны независимо менять те же реквизиты на сайте без процедуры согласования. Иначе покупатель будет видеть условия, которых нет у бухгалтерии.

У каждого заказа нужен устойчивый идентификатор, по которому сайт и 1С узнают повторную передачу. Отправка запроса не равна подтверждённому созданию документа. Кабинету могут понадобиться состояния «Сохранён на сайте», «Передан в учёт», «Принят» и «Требует внимания». Названия выбирают под процесс; главное — не показывать покупателю успех раньше подтверждённого результата.

Отдельно определите правило резерва. Витрина может показывать наличие, но резерв возникает только в той системе и в тот момент, которые назначены источником истины. При задержке обмена нужен понятный ответ: заказ принят к проверке либо покупка временно ограничена. Технические форматы и повторы разобраны в статье об интеграции Laravel с 1С.

Показывайте лимит и документы без двусмысленности

Если дилеры покупают с отсрочкой, интерфейс должен различать разрешённый лимит, задолженность, уже принятые обязательства и доступную сумму. Учебный пример: лимит 300 000 ₽, долг 220 000 ₽, ещё не отгруженные заказы занимают 50 000 ₽. Если правило компании учитывает обе суммы, свободно 30 000 ₽, а не 80 000 ₽. Следующая закупка на 40 000 ₽ требует выбранного бизнесом исключения или другого способа расчёта.

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

Для документов укажите тип, номер, дату, заказ и организацию. Покупателю нужен актуальный файл и понятная версия; менеджеру — возможность установить, что было выдано. Прямая ссылка должна проходить проверку прав. Размещение файла в трудноподбираемой папке само по себе не защищает документы. Автоматический юридически значимый обмен с оператором ЭДО оценивается как отдельная интеграция.

Выберите основу по собственным исключениям

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

Скриншоты Bagisto показывают существующие возможности конкретного продукта. Из них не следует готовность вашего обмена с 1С, российских документов или требуемой схемы согласования. Эти пункты проверяют на контрольном наборе до выбора архитектуры. Общий состав заказной разработки описан в материале о магазине на Laravel с админкой.

Ограничьте первую версию завершённой цепочкой закупки

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

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

В смете разделите проектирование процесса, дизайн, серверную часть, интеграции, данные, проверку и обучение. Заказная разработка магазина в CAPS начинается от 600 000 ₽; это ориентир для обсуждения соответствующего проекта, а не фиксированная цена любого личного кабинета. Итоговую стоимость и срок определяет состав работ.

Как принять кабинет и что прислать для оценки

Попросите закупщика и менеджера пройти контрольную покупку без подсказок разработчика. Затем повторите её с изменением цены, недостатком остатка, недоступной 1С и запрещённой ролью. Полезный результат — правильный заказ и понятное объяснение исключения, а не только красивый экран с успешным сообщением.

Скачать таблицу требований и приёмки кабинета дилера. В неё включены компании и роли, договорные цены, упаковки, файл заказа, согласование, обмен, лимиты и документы. Рядом с каждым сценарием можно записать, кто подтверждает результат и что предъявляет подрядчик.

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