Отмена заказа: ориентир политики и будущей разработки

Назначение: Требования. Продукт: ShariX Open.

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

Темы: Заказы → Жизненный цикл · Заказы → Финализация оплаты · Заказы → Исполнение.

Навигация: Доменная модель → Отмена и затраты.

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

Концепция отмены — поясняющее описание

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

Нужно различать:

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

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

Подтверждённая текущая граница

В 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 часов» для всех услуг. Календарное время описывает риск восстановления мощности; фактические действия описывают уже возникшие затраты. Ранний заказ со специальной закупкой может иметь невозвратную часть раньше обычного; поздняя отмена без понесённых затрат не создаёт произвольную сумму сама по себе.

Что согласовать в политике сервиса

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

Для отношений с потребителем в РФ необходимо учитывать право на отказ и подтверждение фактических расходов по конкретному договору; см. разъяснение Роспотребнадзора. Специальные отраслевые правила проверяются отдельно на момент реализации. Экономическое обоснование порога не заменяет эту проверку.

Целевой сценарий

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

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

Требуемые сведения для проектирования

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

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

Критерии приёмки будущей реализации

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

Порядок разработки и связь со знаниями

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

Связанные контракты: Order и Ticket, конкурентные действия, процесс разработки. Развёрнутое экономическое объяснение и учебные расчёты размещаются в Moodle; Wiki хранит ориентир продукта и критерии будущей реализации.

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

Содержание