Маркбэйс — операционная платформа для торговли и процессов

UAM — единая дверь в экосистему: без неё каждый модуль рискует «своим» логином и обходом политик. Сессии, контекст компании и WaySen ID связывают публичные витрины, кабинет и внешние продукты (в т.ч. спутники) в одну картину пользователя.

Регистрация, приглашения и смена ролей согласованы с реестром и тарифом: подключение модуля к компании — не «тихий» токен, а явная запись в контуре доступа. Именно поэтому внедрение идёт от Auth, а не наоборот.

Security дублирует намерение «не ломать Auth»: rate limit, политики и аудит снижают риск обхода UAM и злоупотребления API. События безопасности остаются прослеживаемыми — важно и для внутреннего расследования, и для требований к логам.

Связка с модулями — через единый слой на границе backend: микросервисы не придумывают свою модель угроз, а опираются на общий контур.

Billing переводит «подключили модуль» в измеримую коммерцию: лимиты, планы, периоды. Кошелёк и прикладные списания сидят на этой опоре, иначе легко получить бесконтрольный рост нагрузки и расхода.

По контракту с App и Registry активация функции в UI согласуется с тем, что реально разрешено тарифом — без «серых» флагов в отдельных сервисах.

Единый баланс объясняет клиенту, за что списалось и почему лимит ИИ или услуги остановился. Без него модульные подписки и нейросети превращаются в набор несоизмеримых счетов.

Связь с Billing и публичной страницей кошелька на сайте ВЭЙСЭН даёт прозрачность для финдирекции и для пользователя экосистемы.

Registry — навигатор по живой архитектуре: какие сервисы доступны компании, какие домены и интеграции одобрены. Это связующее звено между инженерным реестром платформы и тем, что пользователь реально видит в меню App.

Мультивитрины и split-БД опираются на согласованные привязки shop_id ↔ компания — Registry участвует в том, чтобы подключения не расходились с каноном платформы.

Вместо «у каждого модуля свой cron» — единый планировщик: регламенты, ретраи, порядок джобов. Это снижает дублирование и облегчает сопровождение ночных выгрузок, сверок и уведомлений.

Связан с LogCenter и модулями, которым нужны фоновые сценарии: от синхронизаций Integrations до отчётов.

App — «рабочий стол» экосистемы: не набор разрозненных админок, а единая оболочка с виджетами modouls. Контекст компании и роли подтягиваются из UAM; пользователь переключается между заказами, складом и CRM без повторного входа.

Видимость модулей и экранов опирается на Registry и тариф: отключённый модуль не превращается в битую ссылку, а исчезает из когерентного меню.

Модули порождают события; Notifications доставляет их в согласованные каналы — без отдельного «служебного мессенджера» в обход политик. Сотрудник видит единую ленту, а не пачку писем от неизвестных сервисов.

Связь с CHATS и ботами SHOP: разные сценарии, но одна идея — не потерять сигнал о заказе, срыве срока или обращении клиента.

Файлы — клей для ЭДО, чатов, витрин и ИИ: одна зона хранения, разные разрешения. Модуль не копирует вложения в «свой S3» — иначе нарушается целостность и retention по LogCenter.

ВЭЙГЕН, Молвинка и документы в CRM ссылаются на одни и те же объекты, а не на дубли с разной судьбой.

Настройки компании — единая «визитка» для печатных форм, витрин и договоров. Расхождение реквизитов между Shop и Finance — частая боль; здесь правда задаётся один раз и течёт вниз по модулям по контракту.

Бренд и юридический контекст стыкуются с Documents и SHOP: одна организация — одна логика НДС и подписи.

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

Согласовано с дизайн-системой платформы; виджеты могут выводиться в разные разделы App без копирования кода страниц.

Shop переводит каталог и промо в продажи: витрины, мультидомены и каналы Telegram/MAX строятся на общем Storefront API — покупатель видит согласованные цены и доступность.

В связке с Orders и Logistics заказ «знает» витрину (shop_id) и компанию; это основа канона мультивитрин и складских сценариев без дублирования номенклатуры.

Orders — центральный узел торгового контура: спецификации ссылаются на master-номенклатуру, статусы питают Finance, склад и доставку. Без единого заказа разъезжаются деньги и отгрузка.

События заказа идут в Notifications и при необходимости в Process Center для межфункциональных регламентов.

MPLAZA — потребительский и партнёрский слой поверх общих данных: другой продуктовый цикл, чем у внутреннего MARKET, но та же идея master-каталога и shop_id.

Delgram как публичная витрина показывает, как экосистема выходит наружу без «второго ERP»: заказы, гео и идентификация согласованы с платформой.

Finance закрывает деньги по сделке: эквайринг, проводки, согласование с суммами заказа. Это не «отдельная бухгалтерия», а операционный финконтур вокруг Orders и Wallet.

Глубина интеграций с банками и провайдерами — по тарифу и проекту; связь с Documents и Kassa включается там, где нужна юридическая значимость потока.

Документы следуют за сделкой: счета, акты, УПД — с реквизитами из Company Settings и статусами из Orders. ЭДО-провайдеры подключаются через Integrations.

Без этого контура коммерция остаётся «оплатили где-то», а не юридически замкнутым циклом.

Kassa замыкает розничный и онлайн-платёж на ФН и онлайн-кассу там, где это подключено по договору и интеграции. Связь с Finance обеспечивает совпадение сумм чека и заказа.

Конкретные модели оборудования и регламенты ФН — зона интеграции и сопровождения, не «галочка в админке».

Integrations — мост во внешний мир: маркетплейсы, банки, ЭДО, кассы. Каждый коннектор — явный контракт и наблюдаемость, а не обмен файлами без трассировки.

Опирается на master-номенклатуру и заказы: выгрузки и статусы не живут в отрыве от Orders и каталога.

MARKET отделяет закупку у поставщиков от продажи конечному клиенту: другие статусы, другие договоры, связка с Product Import и RFQ.

Пересечение с розницей идёт через номенклатуру и склад, а не через ту же витрину SHOP.

Constructor адресует долгие сделки: от эскиза до спецификации и счёта без переноса таблиц. Проектные объекты должны ссылаться на те же SKU и услуги, что потом попадут в Orders.

Дорожная карта экранов и глубина — по версии модуля и внедрению.

Сервисный маркетплейс связывает специалистов и заказчиков внутри экосистемы: профили, отзывы и заказы на услуги согласованы с CRM и уведомлениями.

Дополняет Constructor: где нужен человек, а не только чертёж и смета.

Импорт — противоядие от «второго каталога в Excel»: правила маппинга и обновления держат карточки синхронными с ERP поставщика и с вашей master-номенклатурой.

В связке с MARKET и Shop обеспечивает единый источник для продаж и закупок.

Logistics связывает заказы с точками хранения и отгрузки: master-склад в App и зеркало в сервисе логистики по канону платформы. Устойчивая связка shop_id ↔ компания нужна, чтобы не смешивать юридический контекст и остатки между витринами.

Отгрузки и маршруты до ПВЗ стыкуются с Orders и Delivery; глубина интеграций с перевозчиками задаётся внедрением.

Delivery отвечает за котировку в корзине и исполнение после оплаты: статусы курьера, ПВЗ, трекинг. Для покупателя это продолжение витрины — один UX от корзины до «заказ доставлен».

Технически опирается на Logistics для точек отгрузки и на интеграции со службами там, где они подключены.

SKLAD углубляет учёт поверх базовых остатков: зоны, ячейки, задания, инвентаризация. Имеет смысл при физическом складе средней и большой сложности; для лёгких кейсов часто хватает master-склада и Logistics.

Резервирование и отгрузка согласуются с Orders, чтобы не продавать «воздух» при корректных правилах.

POWER закрывает производственный контур: маршруты, выпуск, обслуживание оборудования, OEE. Связь с каталогом и складом исключает отдельный «производственный справочник» вне master-данных.

Отгрузка готовой продукции стыкуется с Orders и логистикой так же, как у торгового склада.

CRM удерживает воронку и историю касаний без второго справочника контактов: сделки ссылаются на тех же клиентов, что и заказы и счета. Это основа для B2B и сервисных компаний с длинным циклом.

Активности и документы стыкуются с CHATS и Orders — менеджер видит цепочку, а не разрозненные вкладки.

HRM описывает организацию внутри компании: отделы, роли, зоны ответственности. Это опора для маршрутов согласования и для понятного доступа в App — без «админка знает одно, HR другое».

Связь с UAM и политиками: роли в бизнесе и технические роли согласуются в рамках одной компании.

Process Center задаёт регламенты между модулями: когда сделка тянет закупку, производство и отгрузку, оркестратор не даёт процессу «зависнуть» между сервисами без статуса.

Работает поверх событий Orders, CRM и Logistics; глубина сценариев зависит от внедрения.

ВЭЙГПТ — выделенный слой ИИ с собственным продуктовым контуром и политиками: маршрутизация моделей, лимиты тарифа, аудит. Модули не ходят в «голый» LLM мимо Auth и биллинга.

ВЭЙГЕН, Assistant и спутники вызывают сценарии через этот слой — так сохраняется единая модель безопасности и стоимости.

ВЭЙГЕН закрывает маркетинговую рутину: контент-планы, генерация текста и медиа, сценарии публикаций. Медиа уходит в FILES; расход нейросети — через ВЭЙГПТ и кошелёк.

Для команды это единый контур «придумать — согласовать — выгрузить» без отдельных подписок на десяток сервисов.

Assistant встраивается в операционные экраны: подсказки по заказам, клиентам и каталогу без выхода из App. Запросы маршрутизируются через политики ВЭЙГПТ и лимиты компании.

Это не замена сотруднику, а ускоритель с формализованными границами — без обхода ролей и ACL.

Единый поиск по заказам, товарам, клиентам и документам снижает фрагментацию: меньше «я знаю, что это в другом модуле».

Индексация и права — в контексте компании и ролей; технически стыкуется с Analytics и каталогами.

SEO-модуль поддерживает находимость товаров и страниц: фиды, sitemap, правила индексации там, где подключён Shop. Это часть «одного каталога — много каналов».

Связан с Search и внешними площадками через Integrations при необходимости.

Молвинка — социальный слой экосистемы: лента, профили, посты. Товары в постах подтягиваются через кэш MPLAZA; медиа — через FILES; данные ленты живут в БД модуля FEED, не размывая операционный каталог.

Публичный контур и `/modules/feed` в App используют единый Auth — пользователь не создаёт «ещё один аккаунт для ленты».

ВЭЙВЭЛ — вертикаль здоровья и активности с offline-first клиентом: тренировки, питание, анализы, программы. Нейропомощник идёт через ВЭЙГПТ с лимитами и политиками; идентификация — общая с Маркбэйс.

Публичный контур etostor.ru и целевой бренд waywell.ru показывают, как спутник может иметь свой UX, оставаясь в экосистеме доступа и биллинга.

РЕГпет развивает сценарии для владельцев питомцев: заказы и интеграции — в общей логике платформы (roadmap открытых витрин и покупок).

Как и другие спутники, опирается на Auth и заказы там, где контур включён — без отдельной «теневой» коммерции.

CHATS централизует переписку с клиентами и внутри процессов: вложения из FILES, уведомления через Notifications — без параллельного корпоративного мессенджера «в обход» учётной записи.

Сделки CRM и заказы остаются связанными с тем же контактом, что и чат — контекст не теряется при смене канала.

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 и спутниками при выводе новых сервисов на пользователя.