<sharix-knowledge-meta>
{
    "id": "ShariXKnowledgeCancellationPolicyTarget",
    "page": "sharixopen:knowledge:domain:cancellation_policy_target",
    "area": "open",
    "type": "requirement",
    "title": "Отмена заказа: ориентир политики и будущей разработки",
    "status": "review",
    "schema_version": 1,
    "relations": {
        "related_to": [
            "ShariXKnowledgeOpenKnowledgeDomainOrderticket",
            "ShariXKnowledgeOpenKnowledgeDomainOrderconcurrency",
            "ShariXKnowledgeOpenKnowledgeDomainParticipants"
        ],
        "depends_on": [
            "ShariXKnowledgeOpenKnowledgeModulesBackenddbsynce"
        ],
        "verified_by": [
            "ShariXKnowledgeVerification"
        ]
    },
    "extensions": {
        "taxonomy": {
            "domain": "orders",
            "lifecycle": "not_applicable",
            "component": "dbsynce, handlers_backend, handlers_examples",
            "parents": [
                "ShariXKnowledgeOpenKnowledgeDomainStart"
            ],
            "terms": [
                "product_sharix_open",
                "audience_developer",
                "audience_reviewer",
                "audience_service_owner",
                "audience_support",
                "audience_ai",
                "material_requirement",
                "topic_orders_lifecycle",
                "topic_orders_payments",
                "topic_orders_execution"
            ]
        },
        "classification": {
            "schema": "sharix.knowledge.classification.v1",
            "products": [
                "sharix_open"
            ],
            "audiences": [
                "developer",
                "reviewer",
                "service_owner",
                "support",
                "ai"
            ],
            "material": "requirement",
            "topics": [
                "orders/lifecycle",
                "orders/payments",
                "orders/execution"
            ],
            "tag_terms": [
                "product_sharix_open",
                "audience_developer",
                "audience_reviewer",
                "audience_service_owner",
                "audience_support",
                "audience_ai",
                "material_requirement",
                "topic_orders_lifecycle",
                "topic_orders_payments",
                "topic_orders_execution"
            ],
            "registry_document": "ShariXKnowledgeClassification"
        },
        "source_evidence": [
            {
                "repository": "sharix-open-backend",
                "path": "lib/order_actions.py",
                "commit": "b70f6989f4c8616725b38f72fc15b8981a5dc47b",
                "sha256": "27ce243408a46f1b700d94bf78a25c68ef21d51078bb03627174e4a424d82ef0",
                "url": "https://git.sharix-app.org/ShariX_Open/sharix-open-backend/src/commit/b70f6989f4c8616725b38f72fc15b8981a5dc47b/lib/order_actions.py"
            },
            {
                "repository": "sharix-open-backend",
                "path": "lib/order_permissions.py",
                "commit": "b70f6989f4c8616725b38f72fc15b8981a5dc47b",
                "sha256": "9c1636daa80c4da68c3ae5cf347e279127d142eeff91e969559e8bd54ca3d81d",
                "url": "https://git.sharix-app.org/ShariX_Open/sharix-open-backend/src/commit/b70f6989f4c8616725b38f72fc15b8981a5dc47b/lib/order_permissions.py"
            },
            {
                "repository": "sharix-open-backend",
                "path": "lib/payments/facade.py",
                "commit": "b70f6989f4c8616725b38f72fc15b8981a5dc47b",
                "sha256": "57d0d71939f5bcd391090ca473008f2283e8d7fdb369486ff044e1fcf9cd3876",
                "url": "https://git.sharix-app.org/ShariX_Open/sharix-open-backend/src/commit/b70f6989f4c8616725b38f72fc15b8981a5dc47b/lib/payments/facade.py"
            }
        ],
        "editorial_review": {
            "date": "2026-10-31",
            "state": "future_design_guidance_not_implemented",
            "owner_direction": "Текущий подбор не завершён корректно; политика отмены — ориентир дальнейшей разработки",
            "runtime_checked": false
        }
    },
    "content_sha256": "dc34321226dac1e30ea723419c21a5c3bb242fe9718170ca19871f8abd44257b",
    "schema": 1
}
</sharix-knowledge-meta>
====== Отмена заказа: ориентир политики и будущей разработки ======
~~NOCACHE~~

**Назначение:** [[sharixopen:knowledge:classification:materials#trebovanija|Требования]]. **Продукт:** [[sharixopen:knowledge:classification:products#sharix_open|ShariX Open]].

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

**Темы:** [[sharixopen:knowledge:classification:topics#zhiznennyj_cikl|Заказы → Жизненный цикл]] · [[sharixopen:knowledge:classification:topics#finalizacija_oplaty|Заказы → Финализация оплаты]] · [[sharixopen:knowledge:classification:topics#ispolnenie|Заказы → Исполнение]].


**Навигация:** [[sharixopen:knowledge:domain:start|Доменная модель]] → Отмена и затраты.

**Состояние:** требования к дальнейшему проектированию, редакция для обсуждения. Полная политика платной отмены, расчёт удержания и её сквозное применение этой страницей не объявляются реализованными. Документ не вводит тариф и не разрешает списания.

===== Концепция отмены — поясняющее описание =====
После принятия обязательства сервис может оплачивать подготовку, удерживать доступность, закупать материалы или направлять исполнителя. Поэтому отмена, бесплатная для клиента, не обязательно бесплатна для сервиса. Кто покрывает затраты — тариф, сервисная компания, партнёр или клиент в допустимых пределах — определяется отдельно.

Нужно различать:
  * момент, после которого трудно заново занять освободившееся время;
  * момент возникновения невозвратных затрат по данному заказу;
  * допустимое основание и размер удержания;
  * прекращение исполнения, отмену процессного заказа и расчёт денег.

Экономическая потеря и юридически допустимое удержание не равны автоматически. Упущенная маржа не должна молча превращаться в штраф.

===== Подтверждённая текущая граница =====
В ''dbsynce/lib/order_actions.py'' действие ''cancel_order_as_client'' проверяет разрешение, получает допустимый целевой статус и вызывает каноническую смену состояния. ''get_client_cancel_target_status'' в ''order_permissions.py'' различает TEMPLATE → CLOSED и BOOKED → CANCELLED; эта клиентская операция не является общим способом отменить заказ в любом состоянии.

В ''lib/payments/facade.py'' выбирается платёжный backend по режиму и заказу. Наличие этого фасада не доказывает расчёт поздней отмены, законность суммы, успешный возврат или списание. Просмотренные операции не дают основания считать полный механизм этой страницы готовым. Поведение конкретной установки и платёжного адаптера проверяется отдельно.

===== От чего зависит граница отмены =====
^ Тип работы ^ Существенное событие ^ Что требуется знать ^
| Дистанционная консультация | Подготовка специалиста и возможность заново занять интервал. | Какие расходы уже возникли; насколько реально заместить заказ; не подменять риск пустого окна автоматическим удержанием. |
| Выездная работа | Начало согласованной подготовки, закупка, выезд. | Кто и когда подтвердил действие, его стоимость, возможность остановить/вернуть/использовать ресурс иначе. |
| Индивидуальное изготовление | Закупка специального материала и начало необратимой обработки. | Привязка к заказу, остаточная ценность, возврат поставщику, согласованные этапы. |
| Помещение или событие | Удержание мощности и обязательства перед поставщиками. | Условия услуги и специальные нормы; правило другой отрасли нельзя переносить автоматически. |

Нельзя вводить один общий порог «за N часов» для всех услуг. Календарное время описывает риск восстановления мощности; фактические действия описывают уже возникшие затраты. Ранний заказ со специальной закупкой может иметь невозвратную часть раньше обычного; поздняя отмена без понесённых затрат не создаёт произвольную сумму сама по себе.

===== Что согласовать в политике сервиса =====
  * область: услуга, тариф, тип заказчика, территория и применимые правила;
  * что означает отмена, перенос, неявка, отказ исполнителя и невозможность оказания услуги по вине сервиса;
  * какие события меняют условия и какие документы подтверждают затраты;
  * что ещё можно вернуть, остановить, повторно использовать или компенсировать другим способом;
  * какой текст показывается до принятия заказа и при последующей отмене;
  * кто рассматривает исключения и спорные суммы;
  * кто отвечает за прекращение исполнения, освобождение мощности и финансовое урегулирование.

Для отношений с потребителем в РФ необходимо учитывать право на отказ и подтверждение фактических расходов по конкретному договору; см. [[https://zpp.rospotrebnadzor.ru/news/regional/518450|разъяснение Роспотребнадзора]]. Специальные отраслевые правила проверяются отдельно на момент реализации. Экономическое обоснование порога не заменяет эту проверку.

===== Целевой сценарий =====
  - Получить актуальный заказ, роль действующего лица и применимую редакцию условий.
  - Прочитать подтверждённые события, уже выполненную часть, затраты и доступные возвраты. Не определять всё только по текущему Ticket.status.
  - Показать расчёт: основание, состав, предполагаемое удержание, возврат и неизвестные величины. Отсутствие основания не считать разрешением на списание.
  - Дать участнику понятный способ подтвердить допустимую операцию или направить вопрос ответственному. Установленное право на отказ не блокировать требованием предварительно согласиться со спорной суммой.
  - Проверить актуальность редакции заказа и расчёта при выполнении. При существенном изменении заново показать условия; устаревший расчёт не применять молча.
  - Канонически зафиксировать прекращение/изменение исполнения и отдельно состояние финансового урегулирования. Отмена процесса не равна подтверждённому возврату денег.
  - Выполнить предусмотренные финансовые операции с устойчивым обозначением попытки и сверкой внешнего результата; при неопределённом ответе не повторять списание или возврат вслепую.
  - Освободить относящиеся к заказу резервы, остановить неактуальные ожидания, пересмотреть доступ/коммуникации и уведомить участников о подтверждённом результате.

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

===== Требуемые сведения для проектирования =====
^ Группа ^ Предлагаемые сведения, ещё не объявленные полями API ^
| Условия | Идентификатор/версия политики, применимость, согласованный текст и момент его принятия. |
| События | Подготовка, закупка, выезд, этап исполнения, поступление отказа; источник, время и подтверждение. |
| Расчёт | Валюта, оплаченная/выполненная часть, конкретные затраты, возвратная стоимость, допустимое удержание и основание каждого элемента. |
| Операция | Редакция заказа, идентификатор попытки, actor, подтверждение, решение ответственного и причина исключения. |
| Платёж | Ссылка на фактический платёж, состояние запроса и подтверждённый исход возврата/списания; без секретов платёжного средства. |

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

===== Критерии приёмки будущей реализации =====
  * Отмена до затрат, после закупки, после выезда и после части исполнения даёт объяснимый, различающийся результат.
  * Используемая иначе или возвращённая поставщику часть уменьшает остаточную потерю; двойное возмещение исключено.
  * Перенос, отказ исполнителя, неявка и срыв по вине сервиса не смешаны с добровольной отменой клиента.
  * Операция на границе времени проверена в согласованном часовом поясе; изменение события во время расчёта не теряется.
  * Повторное нажатие, параллельное изменение и потеря ответа не создают двойного финансового действия.
  * Участник может увидеть основание суммы и обратиться к ответственному; спорная сумма не выдаётся за подтверждённую.
  * Проверены права заказчика, получателя и сотрудников: техническая возможность прочитать заказ не даёт права списывать средства.

===== Порядок разработки и связь со знаниями =====
Перед кодом согласовать предметную политику и правовую применимость. Затем определить владельцев данных и канонические операции, совместимость API/UI/обработчиков, переходы и платёжные адаптеры. Изменения обработчиков фиксировать в Blockly и генерируемом Python; проверять внешние события и ручные решения.

Связанные контракты: [[sharixopen:knowledge:domain:order_ticket|Order и Ticket]], [[sharixopen:knowledge:domain:order_concurrency|конкурентные действия]], [[sharixopen:knowledge:development:practice|процесс разработки]]. Развёрнутое экономическое объяснение и учебные расчёты размещаются в Moodle; Wiki хранит ориентир продукта и критерии будущей реализации.

**Для нейросети:** не реализовывать один глобальный таймер штрафа вместо этой политики; не выдавать предложения полей за существующий API и не считать успешную отмену доказательством возврата. Передавать человеку проверяемые сценарии, ограничения, источники правил и понятный состав изменения.

Сервисная компания здесь — сторона отношений, а не отдельная роль пользователя. Распределение действий сотрудников описано в [[sharixopen:knowledge:domain:participants|справочнике участников и конкретных ролей]].

~~SHARIX_KNOWLEDGE_RELATED~~