# AIDB Personal Cabinet and Intercompany Canon

## Статус

Статус: Stage 4 business flows canon draft.

Дата: 2026-05-20.

Этот документ фиксирует архитектуру личных кабинетов, intercompany-связей, логики представителей, комиссий и supplier/client proposal flow в AIDB.

Документ не описывает реализацию кода.

## 1. Назначение

Этот canon закрывает:

- client/supplier/representative personal cabinet model;
- representative/commission logic;
- intercompany relations;
- supplier/client proposal logic;
- history of relations;
- границу между личным кабинетом, storefront, commercial proposal и внутренней рабочей средой.

## 2. Единый personal-cabinet module

Личные кабинеты реализуются как один системный модуль:

```text
system/applications/personal-cabinet/
```

Это одно приложение с ролевыми поверхностями, а не три независимых приложения.

Обязательные поверхности:

- client cabinet;
- supplier cabinet;
- representative cabinet.

Одна учетная запись может иметь несколько ролевых поверхностей, если это разрешено отношениями и правами.

## 3. Personal cabinet boundary

Personal cabinet - это приложение для внешнего или ограниченного участника.

Он не заменяет:

- Shell;
- Gate;
- внутренний staff workspace;
- business-contour application;
- AppMarket;
- storefront.

`Gate` отвечает за вход.

`Shell` отвечает за внутреннюю рабочую среду.

`personal-cabinet` отвечает за ролевую внешнюю поверхность участника.

Внешний клиент, поставщик или представитель не получает внутренние staff-права только потому, что у него есть кабинет.

## 4. Participant roles

### 4.1. Client

Клиент в личном кабинете может видеть:

- свою историю отношений;
- заказы;
- запросы;
- документы;
- статусы;
- счета и платежные состояния, если они подключены;
- доступные действия по своим отношениям.

Клиент может:

- отправить запрос;
- ответить на предложение;
- принять или отклонить условия, если это разрешено процессом;
- загрузить документы, если это разрешено.

Клиент не управляет чужой витриной и не меняет карточку поставщика.

### 4.2. Supplier

Поставщик в личном кабинете может видеть:

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

Поставщик может:

- создать или обновить свою карточку;
- отправить карточку как коммерческое предложение;
- ответить на запрос уточнения;
- отозвать предложение до принятия, если правила процесса это разрешают;
- вести fulfillment по своим заказам, если это разрешено.

Поставщик не публикует себя на чужой витрине напрямую.

Публикацию делает владелец витрины после рассмотрения.

### 4.3. Representative

Представитель или комиссионный участник в личном кабинете может видеть:

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

Представитель может:

- связать клиента с business-center, business-level, business-contour или поставщиком, если это разрешено;
- связать поставщика с целевым владельцем;
- сопровождать предложение;
- получать комиссию по правилам отношения.

Представитель не получает автоматически право менять цену, карточку, публикацию или коммерческие условия.

Такие права должны быть выданы отдельно.

## 5. Intercompany relation model

Intercompany - это структурная связь между бизнесовыми участниками AIDB.

Связь может существовать между:

- business-center;
- business-level;
- business-contour;
- внешним поставщиком;
- внешним клиентом;
- представителем;
- комиссионным участником.

Бизнес-контур может быть:

- поставщиком;
- клиентом;
- внутренним исполнителем;
- внешним участником;
- источником коммерческого предложения;
- получателем коммерческого предложения, если это разрешено его ролью.

Минимальные типы intercompany relations:

- `supplier_relation`;
- `client_relation`;
- `representative_for_client`;
- `representative_for_supplier`;
- `commission_relation`;
- `internal_executor_relation`;
- `partner_relation`.

Одна связь может иметь несколько ролей, но роли должны быть явными.

Не использовать неявное правило "участник может все".

## 6. Relation ownership

Каждая relation должна иметь:

- `relation_id`;
- owner;
- counterparty;
- relation type;
- role scope;
- status;
- allowed actions;
- financial rules, если применимо;
- document references;
- history.

Owner relation - это сторона, которая управляет отношением внутри своего бизнесового пространства.

Counterparty - это связанная сторона.

Структурная правда relation хранится в базе.

Файлы relation хранятся в `children/` у разрешенного владельца или в разрешенной подзоне документов/ uploads.

Не создавать глобальную файловую свалку всех intercompany documents.

## 7. Relation statuses

Рекомендуемые статусы отношения:

- `invited`;
- `active`;
- `restricted`;
- `terminated`;
- `blocked`;
- `history_only`.

`history_only` не должен удалять историю.

Удаление или блокировка связи не должны стирать историю заказов, предложений, документов и комиссий.

## 8. Supplier proposal logic

Supplier proposal - это коммерческое предложение со стороны поставщика или внутреннего источника.

Базовый поток:

1. Поставщик создает или обновляет карточку.
2. Поставщик выбирает разрешенный целевой контур.
3. Поставщик отправляет карточку как `commercial_proposal`.
4. Целевой владелец получает предложение.
5. Целевой владелец рассматривает, принимает, отклоняет или запрашивает уточнение.
6. При принятии владелец может создать `publication_view`.
7. Источник остается связан с предложением, публикацией, заказами и расчетами.

Если `central_offer_intake_enabled = true`, поставщик может отправлять предложения в centralized intake business-center, если ему разрешен этот маршрут.

Если `central_offer_intake_enabled = false`, поставщик не имеет общего маршрута в business-center и может работать только через прямую разрешенную relation или другой локальный сценарий.

## 9. Client proposal and request logic

Client proposal/request - это входящий клиентский запрос, интерес или встречное предложение.

Он отличается от supplier proposal.

Client proposal/request может быть создан:

- из публичной витрины;
- из client cabinet;
- через представителя, если это разрешено;
- через внутреннего сотрудника владельца.

Client proposal/request должен хранить связь:

- с клиентом;
- с публикацией, если запрос пришел через витрину;
- с целевым владельцем;
- с ответственным контуром или исполнителем;
- с supplier proposal, если запрос связан с опубликованным предложением поставщика.

Client proposal/request не должен автоматически менять публичную цену, карточку или условия поставщика.

Он открывает обработку, согласование или заказный процесс.

## 10. Representative and commission logic

Representative relation должна быть явной.

Представитель может быть связан:

- с клиентом;
- с поставщиком;
- с commercial proposal;
- с publication_view;
- с order/request;
- с business relation.

Commission logic не должна жить в чате или в произвольном комментарии.

Она должна быть структурным правилом relation.

Минимальные поля commission rule:

- `commission_rule_id`;
- `representative_id`;
- `relation_id`;
- commission scope;
- calculation type;
- commission base;
- rate or fixed amount;
- currency;
- trigger event;
- start date;
- end date, если есть;
- status;
- history.

Разрешенные calculation types:

- `percentage`;
- `fixed_amount`;
- `tiered`;
- `manual_review`.

Разрешенные trigger events:

- accepted order;
- paid invoice;
- delivered service;
- completed fulfillment;
- manual owner approval.

Комиссия не должна начисляться только по факту просмотра публикации.

Комиссия должна быть привязана к явному business event.

## 11. Commission boundary

Нужно разделять:

- базовую цену предложения;
- публичную цену витрины;
- внутреннюю цену;
- commission base;
- итоговое начисление представителя.

Представитель не управляет этими ценами автоматически.

Представитель может иметь право предложить условия, но владелец отношения или витрины должен принять их по процессу.

Комиссия не должна менять исходную карточку или публичный вид.

Комиссия связывается с relation/order/request/proposal как отдельное финансовое правило.

## 12. History of relations

История отношений обязательна.

Она должна фиксировать:

- создание relation;
- приглашение;
- принятие;
- изменение статуса;
- изменение scope;
- отправку supplier proposal;
- входящий client proposal/request;
- запросы уточнения;
- принятие или отклонение;
- создание publication view;
- заказы;
- документы;
- commission events;
- fulfillment events;
- закрытие или архивирование relation.

История хранится структурно.

Файлы истории, документы и вложения хранятся в разрешенных `children/` подзонах.

## 13. Personal cabinet data visibility

Личный кабинет показывает только данные, которые разрешены отношением и ролью.

Клиент видит свои заказы, документы, запросы и статусы.

Поставщик видит свои предложения, статусы, публикации на основе его предложений и связанные заказы.

Представитель видит только связи, сделки, статусы и комиссии, в которых он участвует.

Владелец business-center или другой владелец отношения может видеть полную картину в рамках своих прав.

Нельзя открывать внешнему участнику внутренний staff workspace без отдельного назначения прав.

## 14. Storage boundary

Структурная правда хранится в базе:

- users;
- external participants;
- relations;
- role scopes;
- proposals;
- requests;
- orders;
- statuses;
- history;
- commission rules;
- commission events.

Файловые материалы хранятся в `children/`:

- документы;
- вложения;
- uploads;
- exports/imports;
- signed files;
- relation files;
- proposal attachments.

Runtime state хранится отдельно и не смешивается с постоянными документами.

## 15. Storefront boundary

Storefront показывает публичные `publication_view`.

Personal cabinet показывает личные данные участника.

Intercompany хранит структурные связи между участниками.

Commercial proposal передает карточку на рассмотрение.

Эти слои связаны, но не являются одним и тем же объектом.

## 16. `central_offer_intake_enabled` in cabinets

Если `central_offer_intake_enabled = true`, supplier cabinet может показывать маршрут подачи предложения в business-center, если поставщик имеет разрешение.

Если `central_offer_intake_enabled = false`, supplier cabinet не должен показывать общий centralized intake route для этого business-center.

Representative cabinet может отправлять или сопровождать предложение только если relation явно разрешает такое действие.

Client cabinet может создавать запросы независимо от centralized supplier intake, если витрина или relation разрешает клиентские запросы.

## 17. Что не входит в этот Stage 4 документ

Этот документ не фиксирует:

- конкретные API routes;
- database schema;
- payment provider;
- tax/accounting implementation;
- legal contract generator;
- dispute resolution workflow;
- notification channels;
- frontend layout личного кабинета.

Эти зоны закрываются в Stage 5 или более поздних implementation stages.

## 18. Спорные места

Коротко зафиксированные нерешенные места:

- юридическая модель договоров не фиксируется в Stage 4;
- налоговая и бухгалтерская логика не фиксируется в Stage 4;
- dispute workflow не фиксируется в Stage 4;
- точный порядок settlement и payout не фиксируется в Stage 4;
- multi-currency settlement требует отдельного решения позже.

## 19. Критерий готовности

Personal cabinet and intercompany архитектура считается закрытой для Stage 4, если:

- personal-cabinet зафиксирован как один системный модуль;
- client, supplier и representative surfaces разведены;
- внешний кабинет не смешан с Shell, Gate, AppMarket и storefront;
- intercompany relation model описан;
- supplier proposal и client proposal/request разведены;
- representative/commission logic зафиксирована структурно;
- история отношений обязательна;
- structural data, files и runtime не смешиваются.