Один контур: компания, витрина, заказ, склад, доставка, документы, деньги, ИИ — связаны через единые данные и роли. Каждый модуль работает автономно, но пользователь видит один кабинет и одну логику процесса.
Маркбэйс нужно читать не как длинный список сервисов, а как рабочую систему: вход, кабинет, витрина, заказ, склад, доставка, деньги, документы, ИИ и контроль качества соединены в один процесс.
Пользователь видит понятный путь, а внутри работают независимые модули: каждый отвечает за свою зону, но данные и роли не распадаются на хаос.
1 вход
без повторных логинов
1 заказ
деньги, склад и доставка связаны
1 контроль
логи, мониторинг и безопасность
Суть
Маркбэйс создаётся как экосистема продуманных продуктов и модулей, чтобы последовательно закрывать потребности пользователей компании и её клиентов — от входа и ролей до master-каталога, заказов, оплаты, склада, доставки, документов, коммуникаций и наблюдаемости. Это не один монолит «на все случаи», а связка сервисов с явными границами: операционный клиент (App), десятки модулей modouls и ядро markbaseCORE (Auth/UAM, биллинг, кошелёк, реестр, безопасность, планировщик и др.). Потребность не «добивается» точечными костылями — под неё выделяется контур в архитектуре и коммерческой модели; компания подключает нужное по тарифу и наращивает полноту без смены платформы. Сквозные данные и роли согласованы между сервисами, чтобы пользователь не терял контекст при переходе от витрины к заказу, оплате и отгрузке.
Технически это не монолит: типичный модуль — отдельный backend в каталоге modouls, в продакшене — отдельный контейнер (Docker) со своим сетевым портом в стеке, отдельная БД или схема, свой префикс API. Модуль можно разворачивать на отдельном хосте или в отдельном кластере: граница процессов и данных между сервисами сохраняется. Общий боевой контур платформы собирается из множества контейнеров (ядро, прикладные сервисы, ingress и др.): это снижает «радиус поражения» — сбой или перегрузка одного узла не должна выводить из строя всю экосистему целиком при корректной балансировке, очередях и мониторинге (функционально зависимые сценарии могут быть ограничены до восстановления связи). Запросы к публичному слою распределяются через балансировщик между несколькими экземплярами — типичный приём для доступности и горизонтального масштабирования. Связность экосистемы даёт единый вход (Маркбэйс id / UAM), общие контракты HTTPS между сервисами, тариф и биллинг компании. Так архитектура остаётся масштабируемой и заменяемой по частям; для пользователя это один цифровой контур компании.
Шесть опор
Опоры для руководителя и ИТ: от архитектуры до доставки. Формулировки согласованы с описанием экосистемы и реестром модулей.
Каждый сервис — отдельный контур деплоя: свой контейнер и порт в стеке, своя БД или схема; при необходимости модуль можно вынести на отдельный сервер без смешения процессов с «соседом». Для сотрудника и клиента это по-прежнему один кабинет компании.
Витрина SHOP, Telegram и MAX, внешние площадки через INTEGRATIONS и потребительский слой MPLAZA строятся на идее единого master-данных, а не дублирования карточек вручную.
Типовые сценарии торговли, склада, доставки и документов закрываются готовыми модулями и настройкой; кастом развивается там, где это даёт отличие на рынке, а не «переписывание ERP с нуля».
Маркбэйс id / UAM задают вход и контекст компании; модули не внедряют параллельную аутентификацию. Данные разграничиваются по ролям и организациям; каналы и хранение стыкуются с договорным и правовым контуром (в т.ч. требования законодательства РФ к персональным данным — детали фиксируются в оферте и политиках для вашего контура).
Подключение FINANCE, POWER, CRM, аналитики и интеграций наращивает полноту без миграции на другую систему; отдельные спутниковые продукты команды описаны в разделе «Экосистема».
Связка Orders, Logistics, Delivery и складского контура (в т.ч. master-склад компании в App по канону платформы) поддерживает прозрачный путь товара до покупателя или ПВЗ.
Сценарии внедрения
Не исчерпывающий список — ориентиры для диалога о внедрении. Детализация уточняется по тарифу и актуальной документации модулей.
Сеть витрин, промо и сезонные коллекции без расхождения остатков с реальностью.
POWER для маршрутов и производственных заказов, SKLAD для глубины WMS, единая номенклатура.
MPLAZA как потребительский слой: заказы, гео и сценарии продавцов поверх общих принципов учёта.
Заказы на услуги, CRM, документы и коммуникации в одном контуре ролей.
Для торгового и производственного бизнеса важно связать каталог и заказы с реальными точками хранения, правилами отгрузки и доставки до покупателя или пункта выдачи (ПВЗ). В контуре платформы это опирается на модули Orders, Logistics, Delivery и складской контур (включая master-склад компании в App по канону экосистемы), вместо разрозненного учёта в таблицах.
Глубина сценариев зависит от подключённых модулей и тарифа: мультивитрины, привязка к компании (shop_id), расчёт доставки, интеграции с курьерскими службами и маркетплейсами подключаются по мере внедрения. Здесь мы не смешиваем дорожную карту с тем, что уже в продакшене у клиента: сверяйте возможности с документацией модулей и карточками продуктов на этом сайте.
Сердце экосистемы
Поставщики дают прайсы в разных форматах. Маркетплейсы — со своими категориями и обязательными полями. Импорт и Shop приводят всё к вашим справочникам: одна точка правды для продаж и аналитики.
Самые сильные сигналы автоматики — связываем через Product Import.
Алиасы брендов и дерево категорий сходятся к одной записи без дублей.
Полная автоматика на грязных данных недостижима — гигиена через настраиваемые правила.
Центр исполнения
Один заказ связывает клиента из CRM, состав из каталога, оплату через Finance, отгрузку через Logistics, доставку через Delivery, документы через Documents, чеки через Kassa и уведомления.
Notifications и асинхронные очереди делают цепочку устойчивой к временным сбоям.
Витрина, кабинет и склад видят одно и то же состояние заказа.
Заказы с сайта и маркетплейсов попадают в общую модель — менеджер не живёт в двух мирах.
Каналы продаж
Сайт SHOP, маркетплейсы Ozon / WB / Я.Маркет, Telegram и MAX как каналы витрины, потребительский маркетплейс Delgram, B2B-контур — всё работает на одной модели компании. Никакой второй базы данных под каждый канал.
Выгружаем карточки и остатки — и забираем заказы и категории с площадки в общую модель.
Telegram, MAX — каналы витрины на общем Storefront API, а не три независимых каталога.
Потребительский маркетплейс платформы на модуле MPLAZA — без отдельного учёта.
Архитектурные принципы
Два принципа сосуществуют: согласованные данные и роли для пользователя — и независимые деплой и БД для инженерии.
| Для заказчика | Техническая опора |
|---|---|
Один логин и компания Сотрудники и роли в рамках одной организации на платформе. | Auth Markbase, сессии и контекст компании по канону _shared/auth в репозитории платформы. |
Заказ, оплата и исполнение согласованы Витрина, заказы, расчёт доставки и отгрузки — в одной цепочке процессов. | Shop / Orders / Finance / Delivery / Logistics — контрактные API между сервисами. |
Модульность без «растворения» в монолите Можно подключать возможности поэтапно, а не покупать всё сразу. | Отдельный деплой, health-check, БД; активация по тарифу. |
От потребности к продукту Типовые задачи бизнеса закрываются предметными продуктами экосистемы (магазин, заказы, финансы, склад, ИИ, спутники) — с понятной ценностью для пользователя. | Реестр модулей платформы, контракты между сервисами; новые потребности — через модули и интеграции, а не разрастание одного узла. |
Логическая карта
Упрощённая карта помогает удержать общую картину перед разбором отдельных контуров. Детали по каждому модулю — в каталоге ниже.
Упрощённая схема; полный реестр модулей и портов — в документации платформы.
Идентификация и клиент
Коммерция и витрины
Операции
Данные и ИИ
Спутниковые продукты
Сплошные связи в операционном клиенте: один вход → модули торговли и заказов → склад и логистика; пунктирные линии на полной диаграмме означают опциональные интеграции по тарифу (ИИ, внешние площадки, спутники).
Главная идея
«Не админка — нервная система бизнеса»
— экосистемный взгляд на торговлю
Контуры подробно
От общей картины к деталям: учёт номенклатуры, витрины, логистика, финансы, ИИ, ядро; затем уведомления и файлы, наблюдаемость, лояльность и контейнеры. Тексты согласованы с реестром модулей.
Ниже разбор идёт от крупного к деталям: сначала — как модули складываются в цельную картину для компании, затем — предметные контуры (товар, витрина, логистика, деньги, ИИ). Чтобы сразу опереться на осязаемые примеры: коммерческая B2B/B2C-витрина на инфраструктуре Маркбэйс и нейросетевой продукт экосистемы.
Платформа Маркбэйс — операционный контур торговли и смежных процессов: один вход и организация, master-данные товара, заказы, оплата, склад и доставка, документы и интеграции — без набора несвязанных «островов». Публичный продукт и документация для пользователей — на markbase.ru. Живой пример полноценной клиентской витрины и оптового контура на том же стеке модулей Shop и смежных сервисов — карточка проекта Коммерческая платформа vde76.ru. Отдельный контур нейросетей с политиками тарифа и безопасности — ВЭЙГПТ (публичное приложение и документация подключаемого ИИ). Дальше по странице — якорные разборы зон и полный каталог модулей со ссылками на карточки продуктов на сайте ВЭЙСЭН.
Центральная идея платформы — одна «правда» по номенклатуре: карточки товаров и услуг, атрибуты, медиа и ценовые правила живут в контуре, из которого питаются витрины, заказы и склад.
В операционном клиенте компании каталог и настройки согласованы с модулями Shop и Orders: спецификации заказа ссылаются на те же сущности, что и публичная витрина, поэтому не нужно вручную синхронизировать три разных справочника.
Услуги (сложные тарифы, пакеты, сопутствующие позиции) описываются в той же модели данных, что и товары, с разграничением по типу номенклатуры и правилам отображения на каналах продаж.
Глубина атрибутов, вариантов, комплектов и производственных связей зависит от подключённых модулей (в т.ч. POWER, Product Import) и тарифа — конкретный набор полей сверяется с актуальной документацией и внедрением.
Модуль Integrations закрывает внешние контуры: маркетплейсы, банковские и кассовые сервисы, ЭДО-провайдеры и другие API — с учётом тарифа, лимитов и политик безопасности платформы.
Выгрузка остатков и цен, приём заказов и статусов от площадок строится на общих master-данных компании, чтобы не разъездались каталог на сайте и карточка на маркетплейсе.
Технически каждый внешний контур подключается как отдельный проект интеграции с явными контрактами и мониторингом — это снижает риск «немого» обмена файлами без трассировки.
Logistics связывает заказы, точки хранения и отгрузку: master-склад компании в App и зеркало в логистическом контуре — по единым правилам платформы (склады, мультивитрины, привязка к компании).
Для сети витрин и каналов важна устойчивая связка «витрина (shop_id) ↔ компания»: иначе рассыпаются права, остатки и юридический контекст сделки.
Модуль отвечает за сценарии отгрузки, маршруты до ПВЗ и согласование с заказами; глубина интеграций с перевозчиками определяется внедрением.
Constructor — контур для долгих сделок и проектной торговли: визуальное проектирование, сметы и привязка изделий и услуг к спецификациям.
Типичный сценарий — от черновика проекта до счёта и заказа с детализацией по позициям, без переноса таблиц между «оценкой» и учётной системой.
Дорожная карта и доступные экраны модуля уточняются по версии платформы и тарифу.
В продуктовой модели Shop боты в мессенджерах — это каналы одной витрины на общем API, а не отдельные мини-магазины с ручным переносом каталога.
Покупатель получает те же цены, промо и доступность, что и на сайте, если политики канала это допускают; оформление заказа уходит в общий контур Orders.
Настройка шаблонов, уведомлений и ограничений канала задаётся в модуле и конфигурации витрины.
Shop обеспечивает публичный e-commerce: каталог, корзина, оформление заказа, промо и SEO-опора там, где модуль подключён.
Несколько витрин на разные бренды или рынки строятся в рамках общей модели компании и тарифа, с разделением доменов и политик.
Связка с Finance, Documents и Kassa включается по мере подключения финансового и кассового контура.
Импорт номенклатуры от поставщиков и обмен с внешними учётными системами опираются на модуль Product Import и интеграционные сценарии.
Маппинг полей и правила обновления позволяют не плодить дубликаты карточек при регулярных выгрузках из ERP или Excel.
Экспорт для аналитики, партнёров или маркетплейсов использует те же master-идентификаторы, что и внутренние заказы.
Под «учётом» после импорта/экспорта имеется в виду операционная картина: заказы, оплаты, отгрузки и статусы — в одной цепочке без разрозненных таблиц.
Orders и Finance дают сквозную трассировку от заявки до денег; Logistics и Delivery дополняют её физическим движением товара.
Для производственных компаний картину дополняет POWER: выпуск, списания и связь с каталогом.
Модуль Documents закрывает подготовку и обмен документами в связке со сделками и реквизитами компании.
Интеграции с провайдерами ЭДО подключаются через модуль Integrations; набор форматов и сценариев согласуется при внедрении.
Единый контекст компании из App снижает риск расхождения реквизитов в печатных формах.
Kassa — контур кассовых операций и соответствия требованиям к фискализации при подключённом оборудовании и договорённостях с провайдерами.
Связка с Finance и Orders обеспечивает согласованность сумм чека, оплаты и заказа.
Конкретные модели ФН, онлайн-касс и регламенты обновлений задаются интеграцией и поддержкой — не «магической» настройкой одной галочки.
Торговый контур объединяет розничные витрины, оптовые порталы и внутренний модуль MARKET для закупок и RFQ — с разделением продуктовых циклов.
Розница и маркетплейсный потребительский слой строятся на master-данных; B2B-закупки не смешиваются с витриной «для конечного покупателя».
TORG и Process Center поддерживают исполнение и оркестрацию между модулями там, где это включено.
Finance отвечает за денежные потоки компании: эквайринг, проводки и согласование с заказами и документами.
Единый кошелёк и биллинг платформы задают рамки списаний за модули и сервисы; клиентские платежи ведутся в прикладном контуре модуля.
Юридически значимые сценарии требуют явного подключения документов и кассы.
Analytics, Search и SEO дают управленческую видимость и находимость товаров без выгрузки «в сторонний BI» как единственного варианта.
Отчёты строятся по данным модулей с учётом прав и контекста компании.
SEO и фиды поддерживают индексацию и внешние каналы при подключённом Shop.
Delivery рассчитывает и исполняет доставку: от котировки в корзине до статусов у курьера или ПВЗ.
Связка с Logistics обеспечивает корректные точки отгрузки и маршруты; набор служб и глубина трекинга зависят от интеграций.
Для покупателя это единый UX с витриной и заказом.
SKLAD углубляет складской учёт: зоны, ячейки, задания и инвентаризация — поверх базовой модели остатков.
Подключение SKLAD имеет смысл при физическом складе средней и большой сложности; для лёгких сценариев часто достаточно master-склада и логистики.
Согласованность с Orders исключает «продажу воздуха» при корректной настройке резервирования.
CRM и HRM держат клиентов, сделки и сотрудников в общем контексте компании; CHATS дополняет переписку без параллельного «рабочего мессенджера».
Process Center позволяет описывать регламенты между модулями, когда сделка затрагивает закупку, производство и доставку.
Уведомления централизованы через модуль Notifications.
POWER закрывает производственные маршруты, выпуск, обслуживание оборудования и показатели эффективности там, где модуль включён для производителя.
Связь с каталогом и складом исключает второй «производственный справочник» вне master-данных.
Объём функций и интеграций с логистикой уточняется по документации модуля.
markbaseCORE даёт единый вход (UAM), безопасность API, биллинг, кошелёк, реестр модулей и планировщик — без дублирования auth в каждом модуле.
App (frontend) собирает виджеты модулей в единый рабочий стол; Widget System и Company Settings задают единообразие экранов и реквизитов.
FILES и LogCenter закрывают медиа, вложения и наблюдаемость по канону платформы.
Модуль Notifications централизует доставку событий заказов и модулей в согласованные каналы; FILES — единая зона медиа и вложений для витрин, ЭДО, чатов и ИИ.
События из Orders, CRM и складских модулей не расходятся по десяти «отдельным почтовикам»: пользователь видит управляемую ленту и настройки каналов. Это снижает потерю статусов и повышает скорость реакции поддержки и менеджмента.
FILES исключает ситуацию, когда каждый модуль хранит копии вложений у себя: одно медиа товара, одна политика доступа и сроков хранения — по канону платформы. Связка с Documents, CHATS и генеративными сценариями (ВЭЙГЕН) опирается на те же идентификаторы файлов.
Эксплуатация распределённой экосистемы опирается на Monitoring (метрики и health), LogCenter (централизованные журналы) и Scheduler (единый планировщик регламентов и ретраев).
Monitoring отвечает на вопрос «жив ли сервис и где узкое место» до того, как это почувствует покупатель на витрине. LogCenter собирает трассировку для разбора инцидентов и требований к аудиту рядом с Security и Compliance.
Scheduler заменяет набор несогласованных cron в каждом модуле: ночные выгрузки на маркетплейсы, сверки, отчёты и повторы после сбоев выполняются предсказуемо и наблюдаемо.
Модуль лояльности с QR и бонусный контур ядра поддерживают удержание и промо-механики в связке с заказами и тарифом; Captcha защищает вход и формы от автоматизации.
Loyalty QR раскрывает сценарии карт и сканирования в торговой точке или на кассе без отдельной «программы лояльности в Excel». Bonus на уровне ядра согласует начисления с биллингом и планировщиком.
Captcha работает совместно с Security и UAM: баланс между устойчивостью к ботам и удобством живого пользователя.
Каждый прикладной модуль в типовой развёртке — отдельно живущий сервис: собственные процессы в Docker, выделенный порт внутри стека, отдельная база или схема данных. Текущий продакшен платформы распределён по нескольким контейнерам; при росте нагрузки или систематических инцидентах топология и ресурсы дооптимизируются по регламентам эксплуатации — без «ломки» всей архитектуры за один шаг: добавляются экземпляры, узлы в балансировке и наблюдаемость.
Изоляция на уровне процессов означает: падение или деградация одного модуля не обязана «тащить за собой» все остальные контуры — при условии корректной конфигурации маршрутизации, очередей повторов и мониторинга. Исключение — явные продуктовые зависимости (например, оплата недоступна — часть сценария заказа временно ограничена до восстановления канала).
Балансировка нагрузки позволяет распределять входящие запросы между несколькими серверами или экземплярами приложений: это повышает доступность и отказоустойчивость — пользовательские запросы обслуживаются оставшимися узлами, если один из них выходит из строя. Параметры балансировки, состав пула и health-checks задаются в инфраструктуре вашего провайдера (панель, API, инфраструктура как код); в баланс могут входить как узлы облака провайдера, так и выделенные серверы при единой схеме маршрутизации.
Горизонтальное масштабирование: если проекту нужно больше пропускной способности, в пул добавляются новые экземпляры сервисов или узлы — увеличиваются доступные мощности без замены единственного «центрального» сервера целиком. Такой подход сочетается с модульной топологией Маркбэйс: нагрузку можно наращивать точечно по тем сервисам, где она возникает.
Защита и хранение данных строятся в связке технических мер и правового оформления: шифрование транспорта (HTTPS), разграничение доступа по ролям и контексту компании (мультитенант), централизованные журналы для разбора инцидентов, резервное копирование и политики хранения — по регламентам эксплуатации конкретного контура. Обработка персональных данных и иной информации с ограниченным доступом должна опираться на законодательство Российской Федерации: цели и правовые основания — в документах оператора (оферта, политика конфиденциальности, согласия субъектов там, где это требуется); учёт режима оператора персональных данных и реестровых требований при необходимости для вашей модели закрепляется официально в договоре и локальных политиках, а не только маркетинговым текстом на сайте. Конкретный уровень защиты, локализация и комплект документов согласуются при внедрении.
Каталог модулей
Для каждого модуля — развёрнутое описание роли в экосистеме и блок «Связи в экосистеме».
Сервисы общего назначения: идентификация, безопасность, мониторинг, реестр модулей, биллинг, кошелёк, планировщик задач — см. таблицу в реестре платформы.
9
модулей
Сессии, регистрация, компании, настройки платформы; единая точка входа для App и модулей.
UAM — единая дверь в экосистему: без неё каждый модуль рискует «своим» логином и обходом политик. Сессии, контекст компании и Маркбэйс id связывают публичные витрины, кабинет и внешние продукты (в т.ч. спутники) в одну картину пользователя.
Регистрация, приглашения и смена ролей согласованы с реестром и тарифом: подключение модуля к компании — не «тихий» токен, а явная запись в контуре доступа. Именно поэтому внедрение идёт от Auth, а не наоборот.
Связи в экосистеме
Контур защиты API: rate limit, политики доступа, аудит событий безопасности.
Security дублирует намерение «не ломать Auth»: rate limit, политики и аудит снижают риск обхода UAM и злоупотребления API. События безопасности остаются прослеживаемыми — важно и для внутреннего расследования, и для требований к логам.
Связка с модулями — через единый слой на границе backend: микросервисы не придумывают свою модель угроз, а опираются на общий контур.
Связи в экосистеме
Тарифы компании, лимиты, подписки — опора для списаний и модульных лицензий.
Billing переводит «подключили модуль» в измеримую коммерцию: лимиты, планы, периоды. Кошелёк и прикладные списания сидят на этой опоре, иначе легко получить бесконтрольный рост нагрузки и расхода.
По контракту с App и Registry активация функции в UI согласуется с тем, что реально разрешено тарифом — без «серых» флагов в отдельных сервисах.
Связи в экосистеме
Баланс экосистемы: пополнения и списания в контуре платформы; связка с биллингом.
Единый баланс объясняет клиенту, за что списалось и почему лимит ИИ или услуги остановился. Без него модульные подписки и нейросети превращаются в набор несоизмеримых счетов.
Связь с Billing и публичной страницей кошелька на сайте ВЭЙСЭН даёт прозрачность для финдирекции и для пользователя экосистемы.
Связи в экосистеме
Каталог модулей, разрешение подключений и доменов — «карта» доступных сервисов.
Registry — навигатор по живой архитектуре: какие сервисы доступны компании, какие домены и интеграции одобрены. Это связующее звено между инженерным реестром платформы и тем, что пользователь реально видит в меню App.
Мультивитрины и split-БД опираются на согласованные привязки shop_id ↔ компания — Registry участвует в том, чтобы подключения не расходились с каноном платформы.
Связи в экосистеме
Единый планировщик фоновых задач и регламентов по экосистеме.
Вместо «у каждого модуля свой cron» — единый планировщик: регламенты, ретраи, порядок джобов. Это снижает дублирование и облегчает сопровождение ночных выгрузок, сверок и уведомлений.
Связан с LogCenter и модулями, которым нужны фоновые сценарии: от синхронизаций Integrations до отчётов.
Связи в экосистеме
Метрики, health-check сервисов, опора для алертов и эксплуатации.
Monitoring даёт единую картину живости сервисов: без него инциденты обнаруживаются по жалобам пользователей, а не по сигналам. Связка с LogCenter и Security формирует контур наблюдаемости платформы.
Для заказчика это про предсказуемость работы витрины и кабинета в пиковые часы; для инженеров — основа для SLA и регламентов реагирования.
Связи в экосистеме
Защита форм и публичных endpoint от автоматических атак.
Капча снижает риск спама и перебора без ломания UX для живых пользователей: подключается там, где модель угроз это требует.
Работает в связке с Security и публичными сценариями регистрации.
Связи в экосистеме
Бонусные программы уровня ядра: начисления и сценарии с планировщиком.
Bonus задаёт единый контур маркетинговых и удерживающих механик на стороне платформы, чтобы не плодить «свои бонусы» в каждом модуле.
Связан с Billing и заказами там, где списание или начисление привязано к покупке.
Связи в экосистеме
Оболочка markbase.ru: главный кабинет, backend ядра, уведомления, файлы — точка сборки виджетов и контекста компании.
5
модулей
Главный операционный клиент: виджеты модулей, навигация, контекст компании.
App — «рабочий стол» экосистемы: не набор разрозненных админок, а единая оболочка с виджетами modouls. Контекст компании и роли подтягиваются из UAM; пользователь переключается между заказами, складом и CRM без повторного входа.
Видимость модулей и экранов опирается на Registry и тариф: отключённый модуль не превращается в битую ссылку, а исчезает из когерентного меню.
Связи в экосистеме
Централизованные уведомления: inbox, e-mail, Telegram и др. каналы по политикам модуля.
Модули порождают события; Notifications доставляет их в согласованные каналы — без отдельного «служебного мессенджера» в обход политик. Сотрудник видит единую ленту, а не пачку писем от неизвестных сервисов.
Связь с CHATS и ботами SHOP: разные сценарии, но одна идея — не потерять сигнал о заказе, срыве срока или обращении клиента.
Связи в экосистеме
Единое хранилище файлов и зоны доступа для модулей без дублирования вложений.
Файлы — клей для ЭДО, чатов, витрин и ИИ: одна зона хранения, разные разрешения. Модуль не копирует вложения в «свой S3» — иначе нарушается целостность и retention по LogCenter.
ВЭЙГЕН, Молвинка и документы в CRM ссылаются на одни и те же объекты, а не на дубли с разной судьбой.
Связи в экосистеме
Реквизиты, НДС, брендинг и кросс-модульные настройки компании.
Настройки компании — единая «визитка» для печатных форм, витрин и договоров. Расхождение реквизитов между Shop и Finance — частая боль; здесь правда задаётся один раз и течёт вниз по модулям по контракту.
Бренд и юридический контекст стыкуются с Documents и SHOP: одна организация — одна логика НДС и подписи.
Связи в экосистеме
Переиспользуемые виджеты и единый паттерн экранов для модулей без «отдельного UI на каждый сервис».
Виджетная архитектура удерживает UX целостным: новый модуль не строит экран с нуля, а подключает блоки в общую сетку. Это ускоряет внедрение и снижает когнитивную нагрузку на пользователя.
Согласовано с дизайн-системой платформы; виджеты могут выводиться в разные разделы App без копирования кода страниц.
Связи в экосистеме
Согласованный контур витрины, заказа, оплаты и документов; MPLAZA — маркетплейсный слой поверх master-данных.
11
модулей
Каталог, корзина, checkout, витрины и каналы продаж (в т.ч. Telegram / MAX по продуктовой модели).
Shop переводит каталог и промо в продажи: витрины, мультидомены и каналы Telegram/MAX строятся на общем Storefront API — покупатель видит согласованные цены и доступность.
В связке с Orders и Logistics заказ «знает» витрину (shop_id) и компанию; это основа канона мультивитрин и складских сценариев без дублирования номенклатуры.
Связи в экосистеме
Заказы, спецификации, исходящие события для оплаты, склада и доставки.
Orders — центральный узел торгового контура: спецификации ссылаются на master-номенклатуру, статусы питают Finance, склад и доставку. Без единого заказа разъезжаются деньги и отгрузка.
События заказа идут в Notifications и при необходимости в Process Center для межфункциональных регламентов.
Связи в экосистеме
Маркетплейс: составные товары, B2B/B2C, публичная витрина delgram.ru в контуре платформы.
MPLAZA — потребительский и партнёрский слой поверх общих данных: другой продуктовый цикл, чем у внутреннего MARKET, но та же идея master-каталога и shop_id.
Delgram как публичная витрина показывает, как экосистема выходит наружу без «второго ERP»: заказы, гео и идентификация согласованы с платформой.
Связи в экосистеме
Финансовые операции, эквайринг, связка с юридически значимыми потоками оплаты.
Finance закрывает деньги по сделке: эквайринг, проводки, согласование с суммами заказа. Это не «отдельная бухгалтерия», а операционный финконтур вокруг Orders и Wallet.
Глубина интеграций с банками и провайдерами — по тарифу и проекту; связь с Documents и Kassa включается там, где нужна юридическая значимость потока.
Связи в экосистеме
ЭДО и документооборот в контуре заказов и компании.
Документы следуют за сделкой: счета, акты, УПД — с реквизитами из Company Settings и статусами из Orders. ЭДО-провайдеры подключаются через Integrations.
Без этого контура коммерция остаётся «оплатили где-то», а не юридически замкнутым циклом.
Связи в экосистеме
Кассовые сценарии и соответствие требованиям к фискализации там, где модуль подключён.
Kassa замыкает розничный и онлайн-платёж на ФН и онлайн-кассу там, где это подключено по договору и интеграции. Связь с Finance обеспечивает совпадение сумм чека и заказа.
Конкретные модели оборудования и регламенты ФН — зона интеграции и сопровождения, не «галочка в админке».
Связи в экосистеме
Внешние площадки, банки, ЭДО-провайдеры — по проектным интеграциям и тарифу.
Integrations — мост во внешний мир: маркетплейсы, банки, ЭДО, кассы. Каждый коннектор — явный контракт и наблюдаемость, а не обмен файлами без трассировки.
Опирается на master-номенклатуру и заказы: выгрузки и статусы не живут в отрыве от Orders и каталога.
Связи в экосистеме
B2B-закупки, RFQ и сделки с поставщиками — отдельный цикл от розничной витрины.
MARKET отделяет закупку у поставщиков от продажи конечному клиенту: другие статусы, другие договоры, связка с Product Import и RFQ.
Пересечение с розницей идёт через номенклатуру и склад, а не через ту же витрину SHOP.
Связи в экосистеме
Визуальное проектирование и сметы; связка проекта со спецификациями по дорожной карте модуля.
Constructor адресует долгие сделки: от эскиза до спецификации и счёта без переноса таблиц. Проектные объекты должны ссылаться на те же SKU и услуги, что потом попадут в Orders.
Дорожная карта экранов и глубина — по версии модуля и внедрению.
Связи в экосистеме
Маркетплейс специалистов (модель Profi.ru) в контуре платформы.
Сервисный маркетплейс связывает специалистов и заказчиков внутри экосистемы: профили, отзывы и заказы на услуги согласованы с CRM и уведомлениями.
Дополняет Constructor: где нужен человек, а не только чертёж и смета.
Связи в экосистеме
Импорт номенклатуры от поставщиков с маппингом на master-каталог.
Импорт — противоядие от «второго каталога в Excel»: правила маппинга и обновления держат карточки синхронными с ERP поставщика и с вашей master-номенклатурой.
В связке с MARKET и Shop обеспечивает единый источник для продаж и закупок.
Связи в экосистеме
Master-склад компании в App; зеркало в логистике; расчёт доставки, маршруты и сценарии выдачи (в т.ч. ПВЗ) — в единой модели витрина ↔ компания (shop_id). Набор каналов доставки и глубина интеграций зависят от тарифа и внедрения.
4
модулей
Склады компании, отгрузки, связь с заказами и витринами.
Logistics связывает заказы с точками хранения и отгрузки: master-склад в App и зеркало в сервисе логистики по канону платформы. Устойчивая связка shop_id ↔ компания нужна, чтобы не смешивать юридический контекст и остатки между витринами.
Отгрузки и маршруты до ПВЗ стыкуются с Orders и Delivery; глубина интеграций с перевозчиками задаётся внедрением.
Связи в экосистеме
Расчёт и исполнение доставки, интеграция с курьерскими сценариями.
Delivery отвечает за котировку в корзине и исполнение после оплаты: статусы курьера, ПВЗ, трекинг. Для покупателя это продолжение витрины — один UX от корзины до «заказ доставлен».
Технически опирается на Logistics для точек отгрузки и на интеграции со службами там, где они подключены.
Связи в экосистеме
WMS: зоны, ячейки, инвентаризация — углублённый складской контур.
SKLAD углубляет учёт поверх базовых остатков: зоны, ячейки, задания, инвентаризация. Имеет смысл при физическом складе средней и большой сложности; для лёгких кейсов часто хватает master-склада и Logistics.
Резервирование и отгрузка согласуются с Orders, чтобы не продавать «воздух» при корректных правилах.
Связи в экосистеме
Производство, OEE, обслуживание — там, где включено для производителей.
POWER закрывает производственный контур: маршруты, выпуск, обслуживание оборудования, OEE. Связь с каталогом и складом исключает отдельный «производственный справочник» вне master-данных.
Отгрузка готовой продукции стыкуется с Orders и логистикой так же, как у торгового склада.
Связи в экосистеме
Клиенты, сделки, сотрудники и регламенты — без дублирования «второго» каталога людей и компаний.
3
модулей
Клиенты, сделки, активности и документы по продажам.
CRM удерживает воронку и историю касаний без второго справочника контактов: сделки ссылаются на тех же клиентов, что и заказы и счета. Это основа для B2B и сервисных компаний с длинным циклом.
Активности и документы стыкуются с CHATS и Orders — менеджер видит цепочку, а не разрозненные вкладки.
Связи в экосистеме
Сотрудники, отделы, роли и зоны ответственности.
HRM описывает организацию внутри компании: отделы, роли, зоны ответственности. Это опора для маршрутов согласования и для понятного доступа в App — без «админка знает одно, HR другое».
Связь с UAM и политиками: роли в бизнесе и технические роли согласуются в рамках одной компании.
Связи в экосистеме
Оркестрация бизнес-процессов между модулями.
Process Center задаёт регламенты между модулями: когда сделка тянет закупку, производство и отгрузку, оркестратор не даёт процессу «зависнуть» между сервисами без статуса.
Работает поверх событий Orders, CRM и Logistics; глубина сценариев зависит от внедрения.
Связи в экосистеме
Нейросетевой шлюз и прикладные модули генерации — с лимитами тарифа и политиками безопасности.
5
модулей
Автономный слой ИИ для бизнес-сценариев: маршрутизация моделей, политики, отдельный продукт app.waygpt.ru.
ВЭЙГПТ — выделенный слой ИИ с собственным продуктовым контуром и политиками: маршрутизация моделей, лимиты тарифа, аудит. Модули не ходят в «голый» LLM мимо Auth и биллинга.
ВЭЙГЕН, Assistant и спутники вызывают сценарии через этот слой — так сохраняется единая модель безопасности и стоимости.
Связи в экосистеме
SMM и генерация контента в контуре платформы: медиа, сценарии, связь с ВЭЙГПТ и FILES.
ВЭЙГЕН закрывает маркетинговую рутину: контент-планы, генерация текста и медиа, сценарии публикаций. Медиа уходит в FILES; расход нейросети — через ВЭЙГПТ и кошелёк.
Для команды это единый контур «придумать — согласовать — выгрузить» без отдельных подписок на десяток сервисов.
Связи в экосистеме
Универсальный прикладной ассистент для Shop и CRM в App — ускорение рутины по политикам тарифа и безопасности.
Assistant встраивается в операционные экраны: подсказки по заказам, клиентам и каталогу без выхода из App. Запросы маршрутизируются через политики ВЭЙГПТ и лимиты компании.
Это не замена сотруднику, а ускоритель с формализованными границами — без обхода ролей и ACL.
Связи в экосистеме
Универсальный поиск по сущностям платформы, доступный из клиента.
Единый поиск по заказам, товарам, клиентам и документам снижает фрагментацию: меньше «я знаю, что это в другом модуле».
Индексация и права — в контексте компании и ролей; технически стыкуется с Analytics и каталогами.
Связи в экосистеме
Индексация, sitemap, фиды — в контуре витрин и магазина.
SEO-модуль поддерживает находимость товаров и страниц: фиды, sitemap, правила индексации там, где подключён Shop. Это часть «одного каталога — много каналов».
Связан с Search и внешними площадками через Integrations при необходимости.
Связи в экосистеме
Отдельные продукты с собственными публичными контурами, но единой идентификацией и правилами экосистемы.
3
модулей
Социальная лента; товары в постах через MPLAZA; отдельная БД модуля FEED.
Молвинка — социальный слой экосистемы: лента, профили, посты. Товары в постах подтягиваются через кэш MPLAZA; медиа — через FILES; данные ленты живут в БД модуля FEED, не размывая операционный каталог.
Публичный контур и `/modules/feed` в App используют единый Auth — пользователь не создаёт «ещё один аккаунт для ленты».
Связи в экосистеме
Здоровье и активность: offline-first клиент, нейропомощник через ВЭЙГПТ; публичный контур etostor.ru.
ВЭЙВЭЛ — вертикаль здоровья и активности с offline-first клиентом: тренировки, питание, анализы, программы. Нейропомощник идёт через ВЭЙГПТ с лимитами и политиками; идентификация — общая с Маркбэйс.
Публичный контур etostor.ru и целевой бренд waywell.ru показывают, как спутник может иметь свой UX, оставаясь в экосистеме доступа и биллинга.
Связи в экосистеме
Экосистема для питомцев; дорожная карта публичной витрины по продукту.
РЕГпет развивает сценарии для владельцев питомцев: заказы и интеграции — в общей логике платформы (roadmap открытых витрин и покупок).
Как и другие спутники, опирается на Auth и заказы там, где контур включён — без отдельной «теневой» коммерции.
Связи в экосистеме
Наблюдаемость, отчётность, процессы между модулями (Process Center, Control Plane, TORG) и сопровождение без параллельных «островов» логов.
9
модулей
Диалоги и сообщения между пользователями компании и клиентами — с FILES и уведомлениями.
CHATS централизует переписку с клиентами и внутри процессов: вложения из FILES, уведомления через Notifications — без параллельного корпоративного мессенджера «в обход» учётной записи.
Сделки CRM и заказы остаются связанными с тем же контактом, что и чат — контекст не теряется при смене канала.
Связи в экосистеме
Отчёты и KPI по данным платформы.
Analytics собирает управленческую видимость из данных модулей с учётом прав и компании — без обязательной выгрузки «во внешний BI» как единственного пути.
Стыкуется с Search/SEO и торговыми модулями для воронок, маржи и операционных SLA.
Связи в экосистеме
Централизованное логирование и архивация по канону платформы.
LogCenter — единая наблюдаемость: логи сервисов, ретенция и архивы по правилам платформы. Это опора для расследований и аудита, особенно рядом с Security.
Модули отправляют события в общий контур вместо локальных «tail -f» на каждом сервере.
Связи в экосистеме
Поддержка пользователей компании.
Контур сопровождения конечных пользователей платформы: обращения, статусы, эскалации. Связан с CHATS и CRM там, где нужно перевести тикет в сделку или заказ.
Дополняет Compliance и LEGAL при разборе инцидентов и обращений по данным.
Связи в экосистеме
Контуры соответствия требованиям и политикам.
Compliance формализует политики хранения, обработки данных и регламентов — в связке с Security и LEGAL. Для заказчика это не «галочка», а согласованный контур с документацией платформы.
Работает поверх LogCenter и модулей, где есть ПДн и договорные обязательства.
Связи в экосистеме
Управление конфигурацией и политиками исполнения в операционном контуре платформы.
Control Plane задаёт, как именно исполняются политики и конфигурации в распределённой системе: без неё каждый модуль рискует «своей» версией флагов.
Связан с Registry, Scheduler и техоперациями: единая точка для изменений, которые должны доехать до всех сервисов согласованно.
Связи в экосистеме
Торговые операции и сценарии исполнения между модулями коммерции.
TORG описывает торговые операции и исполнение между Shop, Orders, Finance и смежными сервисами — чтобы статусы и переходы были единообразны, а не зашиты в каждом модуле по-разному.
Дополняет Process Center там, где речь именно о коммерческом исполнении, а не о произвольном BPM.
Связи в экосистеме
Юридические документы и шаблоны в экосистеме.
LEGAL держит шаблоны оферт, согласий и регламентов, согласованные с публичными страницами и продуктами. Связка с Company Settings и Documents избегает расхождения «на сайте одно, в счёте другое».
Используется Compliance и спутниками при выводе новых сервисов на пользователя.
Связи в экосистеме
Физические карты и QR, сценарии лояльности на кассе и в рознице.
Модуль поддерживает удержание клиента через карты и QR без параллельной «программы лояльности» в отдельной таблице: начисления и списания стыкуются с заказами и кассой там, где контур подключён.
Дополняет Bonus на уровне ядра и Kassa для розничных сценариев.
Связи в экосистеме
Подключение контура, перенос данных, интеграции с поставщиками и маркетплейсами, автоматизация процессов, а также настройка поисковой оптимизации (SEO), ответов в нейровыдаче (AEO) и индексации витрин — оформляются как отдельные услуги с понятным составом работ и заявкой с сайта.
Вопросы и возражения
Короткие ответы в логике продукта — без юридических гарантий и без обещаний, зависящих от договора и конкретной установки.
Модульность как раз для этого: можно начать с витрины, каталога и заказов и не включать производство, сложные закупки или весь набор интеграций. Платформа не заставляет «нажать все кнопки сразу». Рост подключается, когда появляется боль: второй склад, маркетплейсы, ЭДО, ИИ — без смены платформы.
Допустимо: тариф и подключение модулей завязаны на организацию. Важно понимать, что ядро (вход, компания, базовые правила) и часть общих сервисов — фон для любого модуля; это не «лишняя тяжесть», а то, без чего нельзя безопасно разделить данные клиентов и компаний.
Риск есть, если включить поток «в бой» без правил. Поэтому в концепции платформы есть нормализация, сопоставление справочников, этап проверки перед принятием чужих карточек с площадки и участие человека там, где данные грязные. Автоматика ускоряет; ответственность за качество входа не исчезает.
Архитектурное требование — разделение контекстов организаций и опора на вход и тариф, а не на произвольный выбор в чате. ИИ не должен иметь произвольный доступ к исходному коду продуктов; использование ассистента привязано к политике платформы и настройкам. Если в ответе появилось что-то похожее на чужие данные — это инцидент для поддержки, а не норма.
Коммерческая модель строится на тарифах и лимитах для организации и на подключённых модулях; расширенные функции и ИИ могут учитываться отдельно (баланс, лимиты). Конкретные цифры и пакеты — только из актуального прайса и договора; маркетинговый текст не заменяет оферту.
Зависит от объёма номенклатуры, качества исходных данных, числа интеграций и готовности команды. Реалистичный подход — фазы: сначала каталог и заказы, затем склады и доставка, затем маркетплейсы и документы. Срок в днях здесь не задаётся, чтобы не вводить в заблуждение.
Любая SaaS-среда создаёт связность процессов с поставщиком платформы; разумный ответ — ясные контракты на доступ к данным и экспорт, поэтапное внедрение и сохранение критичных выгрузок по регламенту. Маркетинговый текст не подменяет юридический блок экспорта; вопрос закрывается на этапе договора.
Да: в каталоге услуг выделена категория «Маркбэйс: внедрение и развитие» — подключение и перенос данных, сопровождение, автоматизация, API поставщиков, маркетплейсы, настройка SEO и AEO для витрин. Карточки услуг содержат состав работ и форму заявки.
В инженерном контуре платформы ведётся реестр модулей, карта связки витрины и компании (shop_id) и единые правила складов и логистики. На сайте ВЭЙСЭН — публичная витрина команды и каталог услуг по внедрению.
Единая навигация: обзор платформы, экосистема, проекты, услуги и заявка.