B2B‑портал на 1С‑Битрикс
Проектируем закрытый контур для оптовых клиентов, дилеров и менеджеров: персональные цены, остатки по складам, повтор заказа, документы, согласование закупок и обмен с учётной системой. До оценки фиксируем роли, источники данных, правила доступа и границы ответственности сайта и ERP.
Контур портала
B2B‑проект начинается не с каталога, а с модели отношений между компанией, клиентом и учётной системой.
Роли и организации
Разделяем пользователей, компании, подразделения, договоры, менеджеров и права на документы. Один человек может работать от нескольких юридических лиц, если это предусмотрено правилами.
Персональные условия
Цена, валюта, скидка, минимальная партия, кратность и доступность товара определяются не интерфейсом, а согласованным источником и приоритетом правил.
Каталог и остатки
Фиксируем структуру SKU, склады, резервы, аналоги, комплекты и сроки поставки. Показываем время актуальности данных, если обмен не работает в реальном времени.
Заказ и согласование
Поддерживаем черновик, повтор заказа, загрузку по артикулу, лимиты, согласование внутри компании клиента и передачу заказа менеджеру или в ERP.
Данные и интеграции
Для каждой сущности описываем источник, получателя, ключ сопоставления и правило конфликта.
Номенклатура
Товары, предложения, свойства, единицы, упаковки и изображения загружаются идемпотентно: повторный пакет не создаёт дубли.
Цены и остатки
Определяем типы цен, договорные условия, склады, резервы и допустимую задержку обновления. Расхождение данных попадает в журнал, а не скрывается.
Контрагенты и договоры
Сопоставление строится по стабильному внешнему идентификатору. Изменение реквизитов не должно создавать новую организацию без правила.
Заказы и документы
Статусы, оплаты, отгрузки, счета, УПД и акты выводятся только в подтверждённом составе и с разграничением доступа.
Безопасность и контроль
Закрытый интерфейс не равен защищённому порталу. Проверяем доступ на каждом серверном запросе.
Авторизация
Политика паролей, восстановление доступа, блокировка, при необходимости второй фактор и журнал значимых входов.
Разграничение
Проверяем чтение и изменение цены, заказа, договора и документа от имени каждой роли отдельными тестовыми учётными записями.
Аудит действий
Фиксируем изменение состава заказа, согласование, выгрузку документа и административные операции в согласованных границах.
Персональные данные
Состав, сроки хранения и правовые основания определяет владелец данных. В интерфейсе и интеграциях передаём только необходимый минимум.
Что принимаем
Приёмка строится по сквозным сценариям и контрольным наборам данных.
Сценарии ролей
Клиент, закупщик, согласующий и менеджер видят только разрешённые функции и данные.
Контроль обмена
Начальная загрузка, изменение, повтор пакета, ошибка связи и восстановление проходят по заранее описанным тестам.
Нагрузочный профиль
Измеряем критичные операции на согласованном каталоге и количестве пользователей; абсолютные показатели фиксируются только после замера.
Передача
Код, настройки, карта обменов, инструкции, журнал известных ограничений и план поддержки передаются владельцу проекта.
Когда это правильный выбор
До оценки сверяем не только желаемый результат, но и более простой или безопасный способ решить задачу.
Подходит
У компании есть повторные оптовые продажи, договорные цены, несколько ролей клиента и данные, которые должны приходить из 1С или ERP.
Лучше начать с кабинета
Если клиенту нужны только история заказов, документы и обращения без оптового каталога и сложного согласования.
Нужен discovery
Если правила цен, договоров и полномочий существуют только в знаниях менеджеров и ещё не описаны как данные и решения.
Не подходит как витрина
Если задача сводится к публичному каталогу и форме заявки, полноценный B2B‑контур создаст лишнюю стоимость владения.
Из чего складывается оценка
Точная цена появляется после проверки входных данных. До этого показываем факторы и выбранную модель расчёта, а не ложную фиксированную цифру.
Роли и полномочия
Количество типов организаций, пользователей, согласований и исключений определяет объём доменной логики и тестов.
Каталог и цены
SKU, склады, виды цен, договоры, партии и правила доступности влияют на модель данных и обмен.
Документы и процессы
Счета, акты, лимиты, взаиморасчёты и закупочные маршруты оцениваются как отдельные сценарии.
Интеграционный контур
Число систем, направлений, частота, объём, повторы и мониторинг формируют самостоятельную часть сметы.
Проектный маршрут
Каждый этап имеет вход, передаваемый результат, ответственного и критерий перехода к следующему.
Контекст
Собираем цель, аудиторию, текущее состояние, доступы, зависимости и известные ограничения конкретной услуги.
Требования
Переводим пожелания в роли, сценарии, данные, интерфейсы и критерии, по которым можно принять результат.
Архитектура
Определяем границы модулей, источник данных, интеграции, кеширование, безопасность и точки отказа.
Оценка
Смета связывает этап с результатом, показывает внешние расходы, исключения и условие пересмотра.
Реализация
Изменения выполняются в пользовательском коде и по возможности на тестовой среде, проходят review и миграции.
Тестирование
Позитивные, негативные, ролевые, адаптивные и регрессионные сценарии соответствуют риску изменения.
Запуск
Резервная копия, контрольный список, окно публикации, smoke‑test и rollback согласуются до изменения продакшена.
Передача
Заказчик получает код, настройки, доступы, инструкции, список изменений, ограничения и понятный следующий backlog.
Частые вопросы
Ответы помогают заранее определить границы задачи и данные, которые потребуются для оценки.
Можно сделать B2B‑портал без полной замены текущего сайта?
Да. Закрытый контур можно выделить в отдельный раздел или проект, если единая авторизация, каталог и интеграции допускают такое разделение. Решение принимается после аудита текущей архитектуры.
Как рассчитывается стоимость?
Смета зависит от числа ролей, бизнес‑правил, сущностей обмена, документов, сценариев заказа, объёма миграции и нагрузки. Сначала формируем карту требований, затем разделяем обязательный запуск и последующие этапы.
Нужен ли обмен в реальном времени?
Не всегда. Для каждой сущности выбирается подходящий режим: событие, очередь, регламент или пакет. Частота определяется бизнес‑риском устаревших данных и возможностями учётной системы.
Можно обещать совместимость с любой 1С?
Нет. Конфигурацию, версию, доработки, формат обмена и права необходимо проверить. До этого корректно говорить только о проектировании интеграции, а не о готовой совместимости.
Что происходит при ошибке обмена?
Сообщение не должно теряться. Нужны журнал, идентификатор операции, повторная доставка, защита от дублей и понятное действие для ответственного сотрудника.
Связанные направления
Перейдите к соседней задаче или посмотрите общий состав проекта и действующие ориентиры стоимости.
Начнём с границ задачи
Укажите адрес сайта или тип нового проекта, ожидаемый результат и известные ограничения. Ответим с уточняющими вопросами и предложим разумный следующий шаг.