Назначение: Сценарий процесса. Продукт: ShariX Open.

Для кого: Владелец сервиса · Администратор · Поддержка · Разработчик · Нейросеть.

Темы: Сервис → Подключение партнёра · Доступ → Полномочия · Обработчики → NEG_REQUEST.

Навигация: База знаний → Сценарии → Заявка партнёра.

Сценарий описывает регистрацию партнёрского кабинета ShariX Open через CooperateView. Компания, полномочия представителя и договорная связь проходят отдельные проверки. Сообщение об отправке формы не означает завершённой активации всех объектов.

• Маршрут: sharix_admin:cooperate_request, локальный путь cooperate-request/.
• Префикс кабинета: определяется SHARIX_ADMIN_PATH в URL-конфигурации установки; фиксированный адрес для всех установок здесь не задаётся.
• View: sharix_admin/views/cooperate.py, класс CooperateView.
• Форма: sharix_admin/forms/company.py, CooperateCompanyForm.
• Общие запросы: dbsynce/lib/partner_requests.py и dbsynce/lib/ticket_gen.py.

Для доступа нужны:

• вход в учётную запись;
• разрешённый режим ALLOW_PARTNER_REQUEST;
• доступ по ключу страницы cooperate_request;
• существующий контекст Metaservice.

При отсутствии Metaservice показывается предусмотренная страница необходимости настройки. Скрытый пункт меню не является самостоятельной проверкой прав: допуск проверяет серверный слой.

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

Поля компании:

• legal_name — наименование;
• inn — ИНН;
• kpp — КПП;
• ogrn — ОГРН;
• bank_name — банк;
• bik — БИК;
• rs — расчётный счёт;
• ks — корреспондентский счёт;
• address — адрес;
• tax_method — система налогообложения.

Проверка реквизитов выполняется серверной формой. Например, ИНН должен содержать 10 или 12 цифр; КПП при указании — 9 цифр, а для ИП с 12-значным ИНН не используется. Это техническая валидация ввода, а не подтверждение проверки самой компании.

В auto_roles можно выбрать дополнительные роли:

• PARTNER-SUPERVISOR;
• PARTNER-SUPPORT;
• PARTNER-TECHSUPPORT;
• METASERVICE-PROVIDER.

Обязательные согласия — accept_partner_agreement и accept_client_agent_agreement. Они относятся к показанным документам; отсутствие клиентской ошибки не заменяет серверной проверки согласий.

Внутри transaction.atomic код выполняет следующие шаги:

1. Сохраняет Company с repr текущего пользователя и первоначальным статусом deactivated.
2. Создаёт ST_REQUEST активации компании и сохраняет ссылку Company.ticket_status.
3. Обеспечивает запрос полномочия PARTNER-ADMIN.
4. Обеспечивает дополнительные запросы полномочий для выбранных auto_roles.
5. При METASERVICE-PROVIDER отдельно обеспечивает employee Relationship с собственным NEG_REQUEST.
6. Обеспечивает contract Relationship с собственным NEG_REQUEST.
7. Вызывает предусмотренные действия по требованиям для созданных объектов.

Типы запросов различаются:

После блока сохранения код отдельно пытается назначить PARTNER-ADMIN и выбранные роли через assign_role_and_refresh. Ошибка этого шага показывается пользователю; затем форма сообщает об отправке заявки. Поэтому сообщение об успехе нужно читать вместе с возможными ошибками назначения.

Helpers ensure_partner_permission_request и _ensure_relationship_request ищут соответствующее активное состояние или открытый PENDING/ACCEPTED-запрос для того же объекта. Это предотвращает часть повторных связанных запросов.

Однако form_valid начинает с нового сохранения Company. Из защиты helper не следует идемпотентность всей отправки формы. После обрыва или неопределённого ответа сначала проверяют, создана ли компания и какие запросы уже существуют. Повтор формы может создать ещё одну компанию.

Для contract Relationship нужен найденный пользователь группы METASERVICE-ADMIN. Его отсутствие вызывает конкретную ошибку подготовки договорной связи; это не решается случайным выбором ID другого пользователя. Реквизиты и остальные необходимые записи проверяют по состоянию установки.

• Представителя и реквизиты созданной Company.
• Статус Company и связанный ST_REQUEST.
• Каждое Permissions и его ACCESS_REQUEST.
• Contract Relationship и соответствующий NEG_REQUEST.
• Employee Relationship, если выбрана роль исполнителя.
• Требования и результаты их проверки.
• Членство пользователя в нужных группах и обновлённый контекст доступа.
• Доступность нужного кабинета под учётной записью заявителя.

Рассмотрение заявки компании, решение по полномочию и активация Relationship — разные действия. Текущее ограничение ручной ветви NEG_REQUEST описано в PENDING: уведомление и API scope. Его нельзя скрывать общим утверждением «все заявки автоматически обрабатываются».

• Ошибка поля или согласия: исправить указанный ввод в форме.
• Недоступна страница: проверить вход, ALLOW_PARTNER_REQUEST, доступ к странице и Metaservice.
• Ошибка назначения роли: проверить уже сохранённые объекты и состояние групп/каталога учётных записей; не начинать с повторной отправки формы.
• Неизвестен результат отправки: установить наличие Company и связанных запросов до повторного создания.
• Запрос существует, но результат не достигнут: определить конкретный тип, статус и обработчик, а не вручную активировать все сущности сразу.

Полный браузерный сценарий и реальная выдача ролей на сервере при этой source-проверке не выполнялись. Модули и поля сверены с Git; фактическую конфигурацию проверяют отдельно.

• Общие данные сервиса.
• Ответственность за модели.
• Устройство обработчиков.
• Приёмка и уровни подтверждения.

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

• sharix-open-webapp-base: sharix_admin/views/cooperate.py.
• sharix-open-webapp-base: sharix_admin/views/feature_access.py.
• sharix-open-webapp-base: sharix_admin/views/base.py.
• sharix-open-webapp-base: sharix_admin/forms/company.py.
• sharix-open-webapp-base: sharix_admin/forms/role_choices.py.
• sharix-open-webapp-base: sharix_admin/forms/legal_entity_validation.py.
• sharix-open-webapp-base: sharix_admin/urls.py.
• sharix-open-webapp-base: core/urls.py.
• sharix-open-backend: models/company.py.
• sharix-open-backend: lib/partner_requests.py.
• sharix-open-backend: lib/ticket_gen.py.