<sharix-knowledge-meta>
{
    "id": "ShariXKnowledgePartnerRequestScenario",
    "page": "sharixopen:knowledge:scenarios:partner_request",
    "area": "open",
    "type": "procedure",
    "title": "Подача и обработка заявки партнёра",
    "status": "review",
    "schema_version": 1,
    "relations": {
        "related_to": [
            "ShariXKnowledgeScenarios",
            "ShariXKnowledgeOpenKnowledgeModulesBackenddbsynce",
            "ShariXKnowledgeOpenKnowledgeArchitectureModelownership",
            "ShariXKnowledgeHub",
            "ShariXKnowledgeNegRequestPendingBPMN",
            "ShariXKnowledgeOpenKnowledgeModulesHandlers",
            "ShariXKnowledgeOpenKnowledgeDevelopmentAcceptance"
        ],
        "depends_on": [
            "ShariXKnowledgeOpenKnowledgeModulesBackenddbsynce"
        ]
    },
    "extensions": {
        "taxonomy": {
            "domain": "use_cases",
            "lifecycle": "implemented",
            "parents": [
                "ShariXKnowledgeScenarios"
            ],
            "terms": [
                "audience_service_owner",
                "audience_administrator",
                "audience_support",
                "audience_developer",
                "audience_ai",
                "product_sharix_open",
                "material_scenario",
                "topic_service_partner_onboarding",
                "topic_security_permissions",
                "topic_handlers_relationships",
                "ticket",
                "blockly",
                "generated_python",
                "bpmn"
            ],
            "component": "webapp-base, dbsynce, tickets"
        },
        "glossary": [],
        "editorial_review": {
            "date": "2026-10-31",
            "scope": "rewrite",
            "batch": 5,
            "style": "Конкретика, перечисления, видимая и машинная навигация; закрытые детали остаются в intrawiki."
        },
        "source_review_20261031": {
            "kind": "source_analysis_not_runtime_acceptance",
            "sources": [
                {
                    "repository": "sharix-open-webapp-base",
                    "commit": "5be0ba7a95ca5869bfbaebbe11c5b9f16f20568d",
                    "path": "sharix_admin/views/cooperate.py",
                    "sha256": "5731b603f1bbf00639ee59c29ee8c33a862eb2f8e1fff6114251d778c9d5da44"
                },
                {
                    "repository": "sharix-open-webapp-base",
                    "commit": "5be0ba7a95ca5869bfbaebbe11c5b9f16f20568d",
                    "path": "sharix_admin/views/feature_access.py",
                    "sha256": "abdf34ea69ea091fff359d958ebf183e5879cb3059411d2f81048853da94b0b3"
                },
                {
                    "repository": "sharix-open-webapp-base",
                    "commit": "5be0ba7a95ca5869bfbaebbe11c5b9f16f20568d",
                    "path": "sharix_admin/views/base.py",
                    "sha256": "6348afc41acdbafdea16ab3fc5b099564df885eaf9f095e48674f2b7af3ab442"
                },
                {
                    "repository": "sharix-open-webapp-base",
                    "commit": "5be0ba7a95ca5869bfbaebbe11c5b9f16f20568d",
                    "path": "sharix_admin/forms/company.py",
                    "sha256": "adb9c9a5c9e4c2187b0fed4f2cdc8e8d3756356034e9e9536ccb7a4dabd137b7"
                },
                {
                    "repository": "sharix-open-webapp-base",
                    "commit": "5be0ba7a95ca5869bfbaebbe11c5b9f16f20568d",
                    "path": "sharix_admin/forms/role_choices.py",
                    "sha256": "b3acfb891a5ac71dd75ec0086902955433ebcb21e1d5afba32e098812d221182"
                },
                {
                    "repository": "sharix-open-webapp-base",
                    "commit": "5be0ba7a95ca5869bfbaebbe11c5b9f16f20568d",
                    "path": "sharix_admin/forms/legal_entity_validation.py",
                    "sha256": "d408eb777e875a4e5959fcfd5e4b6478b8c133351a22c610c5d67c87d8aedce2"
                },
                {
                    "repository": "sharix-open-webapp-base",
                    "commit": "5be0ba7a95ca5869bfbaebbe11c5b9f16f20568d",
                    "path": "sharix_admin/urls.py",
                    "sha256": "ad4a527e8b06b167405fc88e0480895b032da4c9f7d0e4c17b573a8c0f23b1fd"
                },
                {
                    "repository": "sharix-open-webapp-base",
                    "commit": "5be0ba7a95ca5869bfbaebbe11c5b9f16f20568d",
                    "path": "core/urls.py",
                    "sha256": "5997b9600b4ef8be878201d83923edc961e881cac2c0245c7486f64d4e35e7e1"
                },
                {
                    "repository": "sharix-open-backend",
                    "commit": "778a3280cee115ba0efe3fdff7b0e708b0c10093",
                    "path": "models/company.py",
                    "sha256": "817a170624b0ba0018e124499efa417e892287f19b171ebc1922561005d01f56"
                },
                {
                    "repository": "sharix-open-backend",
                    "commit": "778a3280cee115ba0efe3fdff7b0e708b0c10093",
                    "path": "lib/partner_requests.py",
                    "sha256": "72e01fee168a1c43982f65951a8e7bb44def62ad8acd86976f6a95ddb84d3cbd"
                },
                {
                    "repository": "sharix-open-backend",
                    "commit": "778a3280cee115ba0efe3fdff7b0e708b0c10093",
                    "path": "lib/ticket_gen.py",
                    "sha256": "7bdf92007916aec7e968a45f142e5f98fffb5dfe9b61ee7fcae3c65c826dfbde"
                }
            ]
        },
        "hierarchy_review": {
            "date": "2026-10-31",
            "canonical_parent_id": "ShariXKnowledgeScenarios",
            "page_url_preserved": true,
            "kind": "article_and_navigation"
        },
        "classification": {
            "schema": "sharix.knowledge.classification.v1",
            "products": [
                "sharix_open"
            ],
            "audiences": [
                "service_owner",
                "administrator",
                "support",
                "developer",
                "ai"
            ],
            "material": "scenario",
            "topics": [
                "service/partner_onboarding",
                "security/permissions",
                "handlers/relationships"
            ],
            "tag_terms": [
                "audience_service_owner",
                "audience_administrator",
                "audience_support",
                "audience_developer",
                "audience_ai",
                "product_sharix_open",
                "material_scenario",
                "topic_service_partner_onboarding",
                "topic_security_permissions",
                "topic_handlers_relationships",
                "ticket",
                "blockly",
                "generated_python",
                "bpmn"
            ],
            "registry_document": "ShariXKnowledgeClassification",
            "state_meaning": "lifecycle относится к описываемому коду, а status к редакции документа; implemented не означает успешный runtime тест"
        },
        "classification_review": {
            "date": "2026-10-31",
            "source": "Содержание текущей страницы и проверенный словарь классификации",
            "body_scope": "classification_and_navigation_only"
        }
    },
    "content_sha256": "36aec52bc51b5c805491e27ee84c412491bb749ae93317cbd252ea46061fe3d6",
    "schema": 1
}
</sharix-knowledge-meta>
====== Подача и обработка заявки партнёра ======
~~NOCACHE~~

**Назначение:** [[sharixopen:knowledge:classification:materials#scenarij_processa|Сценарий процесса]]. **Продукт:** [[sharixopen:knowledge:classification:products#sharix_open|ShariX Open]].

**Для кого:** [[sharixopen:knowledge:classification:audiences#vladelec_servisa|Владелец сервиса]] · [[sharixopen:knowledge:classification:audiences#administrator|Администратор]] · [[sharixopen:knowledge:classification:audiences#podderzhka|Поддержка]] · [[sharixopen:knowledge:classification:audiences#razrabotchik|Разработчик]] · [[sharixopen:knowledge:classification:audiences#nejroset|Нейросеть]].

**Темы:** [[sharixopen:knowledge:classification:topics#podkljuchenie_partnjora|Сервис → Подключение партнёра]] · [[sharixopen:knowledge:classification:topics#polnomochija|Доступ → Полномочия]] · [[sharixopen:knowledge:classification:topics#neg_request|Обработчики → NEG_REQUEST]].


**Навигация:** [[sharixopen:knowledge:start|База знаний]] → [[sharixopen:knowledge:scenarios:start|Сценарии]] → Заявка партнёра.

Сценарий описывает регистрацию партнёрского кабинета 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 код выполняет следующие шаги:

  - Сохраняет Company с repr текущего пользователя и первоначальным статусом deactivated.
  - Создаёт ST_REQUEST активации компании и сохраняет ссылку Company.ticket_status.
  - Обеспечивает запрос полномочия PARTNER-ADMIN.
  - Обеспечивает дополнительные запросы полномочий для выбранных auto_roles.
  - Исторический код при METASERVICE-PROVIDER отдельно создавал employee Relationship с NEG_REQUEST; по уточнению владельца ниже этот шаг не является внешним условием допуска и удаляется подготовленной правкой.
  - Обеспечивает contract Relationship с собственным NEG_REQUEST.
  - Вызывает предусмотренные действия по требованиям для созданных объектов.

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

^ Объект/результат ^ Ticket ^ Что не следует считать завершённым вместе с ним ^
| Проверка Company | ST_REQUEST активации партнёра | Полномочия и договорное Relationship имеют отдельные запросы. |
| Полномочие пользователя | ACCESS_REQUEST, связанный с Permissions | Членство в группе само по себе не подтверждает активное предметное полномочие. |
| Договорная связь | NEG_REQUEST, связанный с Relationship | Не подменяет ST_REQUEST компании. |
| Связь исполнителя с партнёром | Отдельный NEG_REQUEST при выборе роли исполнителя | Не подменяет ACCESS_REQUEST на METASERVICE-PROVIDER. |

После блока сохранения код отдельно пытается назначить 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 описано в [[sharixopen:knowledge:scenarios:neg_request_pending|PENDING: уведомление и API scope]]. Его нельзя скрывать общим утверждением «все заявки автоматически обрабатываются».

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

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

===== Связанные материалы =====
  * [[sharixopen:knowledge:modules:backend_dbsynce|Общие данные сервиса]].
  * [[sharixopen:knowledge:architecture:model_ownership|Ответственность за модели]].
  * [[sharixopen:knowledge:modules:handlers|Устройство обработчиков]].
  * [[sharixopen:knowledge:development:acceptance|Приёмка и уровни подтверждения]].

===== Исходники, сверенные 31.10.2026 =====
Проверены опубликованные исходники указанных commits. Это анализ кода, а не подтверждение состояния сервера или выполнения процесса в установленной системе.
  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-webapp-base/src/commit/5be0ba7a95ca5869bfbaebbe11c5b9f16f20568d/sharix_admin/views/cooperate.py|sharix-open-webapp-base: sharix_admin/views/cooperate.py]].
  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-webapp-base/src/commit/5be0ba7a95ca5869bfbaebbe11c5b9f16f20568d/sharix_admin/views/feature_access.py|sharix-open-webapp-base: sharix_admin/views/feature_access.py]].
  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-webapp-base/src/commit/5be0ba7a95ca5869bfbaebbe11c5b9f16f20568d/sharix_admin/views/base.py|sharix-open-webapp-base: sharix_admin/views/base.py]].
  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-webapp-base/src/commit/5be0ba7a95ca5869bfbaebbe11c5b9f16f20568d/sharix_admin/forms/company.py|sharix-open-webapp-base: sharix_admin/forms/company.py]].
  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-webapp-base/src/commit/5be0ba7a95ca5869bfbaebbe11c5b9f16f20568d/sharix_admin/forms/role_choices.py|sharix-open-webapp-base: sharix_admin/forms/role_choices.py]].
  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-webapp-base/src/commit/5be0ba7a95ca5869bfbaebbe11c5b9f16f20568d/sharix_admin/forms/legal_entity_validation.py|sharix-open-webapp-base: sharix_admin/forms/legal_entity_validation.py]].
  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-webapp-base/src/commit/5be0ba7a95ca5869bfbaebbe11c5b9f16f20568d/sharix_admin/urls.py|sharix-open-webapp-base: sharix_admin/urls.py]].
  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-webapp-base/src/commit/5be0ba7a95ca5869bfbaebbe11c5b9f16f20568d/core/urls.py|sharix-open-webapp-base: core/urls.py]].
  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-backend/src/commit/778a3280cee115ba0efe3fdff7b0e708b0c10093/models/company.py|sharix-open-backend: models/company.py]].
  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-backend/src/commit/778a3280cee115ba0efe3fdff7b0e708b0c10093/lib/partner_requests.py|sharix-open-backend: lib/partner_requests.py]].
  * [[https://git.sharix-app.org/ShariX_Open/sharix-open-backend/src/commit/778a3280cee115ba0efe3fdff7b0e708b0c10093/lib/ticket_gen.py|sharix-open-backend: lib/ticket_gen.py]].

===== Уточнение владельца: внутренняя связь employee и внешний допуск =====
**Нормативное уточнение от 31.10.2026, а не сообщение о развёрнутом исправлении.** Employee обозначает внутреннюю связь человека с юридическим лицом. Представитель компании, исполнитель, администратор и другие связанные с ней люди могут иметь такую запись. Эта связь остаётся в ведении юридического лица; Сервис или Платформа не должны превращать её наличие в самостоятельный внешний допуск.

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

Contract обозначает внешнее договорное отношение компании с Сервисом и не заменяет внутренний employee. Участник, не являющийся представителем компании по договору, получает свою область через собственное разрешение; отношение «сам с собой» для этого не требуется. ACCESS_REQUEST и NEG_REQUEST имеют разные предметы и могут идти в разные списки, даже если решения принимает один человек.

Запрос роли Сервиса не должен автоматически создавать внешний NEG_REQUEST(employee). Исторические записи сохраняются: это уточнение не разрешает удалять, автоматически активировать или массово восстанавливать отношения. Подготовленная правка API и проверок должна пройти отдельное применение и runtime-приёмку; эта страница сама по себе не подтверждает состояние серверов.

~~SHARIX_KNOWLEDGE_RELATED~~