====== Методические рекомендации по использованию шаблонов документов ShariX Open ======

Эта памятка предназначена для команд, которые уже понимают основы ShariX Open и хотят быстро проверить, что документы конкретного Сервиса подготовлены корректно.

Главный принцип: **базовые положения ShariX Open не переписываются под каждую услугу**. Юрист готовит специальные положения Сервиса и Категорий услуг, а разработчик обеспечивает корректную генерацию документов из конфигурации, профилей Сервиса и профилей Категорий.

===== 1. Как устроена модель документов =====

  * **Платформенный уровень** — общие документы ShariX Open. Их не надо копировать и переписывать в каждом Сервисе.
  * **Сервисный уровень** — документы конкретного Сервиса: оператор, режим работы, роли, платежная модель, Категории услуг, общие требования.
  * **Уровень Категории услуг** — специальные правила конкретной услуги: Поездка, Поручение, аренда помещения, аренда ТС, аренда инструмента и т. п.
  * **Уровень Заказа** — карточка Заказа, статусы, поля, отчет, счет, акт, жалоба, инцидент, цифровые следы.

Идея структуры: общая база стабильна, а специфика услуги описывается через Категории. Это позволяет добавлять новые услуги без переписывания всей правовой базы.


===== 1.1. Нормативная сверка =====

Перед публикацией проверьте, какие нормы реально применимы к Сервису:

  * ГК РФ — договоры, оферта, агентская модель, услуги, аренда, ответственность;
  * Закон о защите прав потребителей — информация о Сервисе, Партнере, Исполнителе, цене, возвратах и претензиях;
  * 149-ФЗ — информация и информационные системы;
  * 152-ФЗ — персональные данные;
  * 63-ФЗ — электронная подпись и юридически значимые цифровые действия;
  * 54-ФЗ и 161-ФЗ — платежи, чеки, возвраты, платежная инфраструктура;
  * 289-ФЗ о платформенной экономике — ориентир по платформенной модели, доступу, личному кабинету, рейтингу и жалобам; перед применением проверьте актуальное вступление в силу;
  * специальные нормы по конкретной Категории: транспорт, аренда, лицензии, страхование, безопасность и т. п.

Не вставляйте этот список в каждый договор автоматически. Используйте его как чек-лист для проверки модели.

===== 2. Кто что делает =====

^ Участник команды ^ Что делает ^ За что отвечает ^
| Юрист | Готовит правовую модель, специальные положения, Категории услуг, требования, запреты, платежную и риск-модель | Чтобы документы соответствовали фактической работе Сервиса и не противоречили ShariX Open |
| Разработчик | Настраивает источники данных, плейсхолдеры, таблицы, генерацию, ссылки, версии, интерфейсные статусы | Чтобы итоговые документы генерировались корректно и совпадали с интерфейсом |
| Владелец продукта | Описывает фактический сценарий услуги, роли, путь Заказа, тарифы, ограничения | Чтобы юрист и разработчик не угадывали бизнес-модель |

===== 3. Не трогайте базовую часть шаблонов =====

Нельзя без необходимости менять общие положения шаблонов. Дописывать нужно в предусмотренные места:

  * параметры Сервиса;
  * роли;
  * Категории услуг;
  * требования к документам, разрешениям и допускам;
  * платежную модель;
  * специальные положения Сервиса;
  * документы Категорий услуг;
  * закрывающие документы по Категориям.

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

===== 4. Документы, которые обычно нужны =====

^ Документ ^ Назначение ^
| Термины и определения Сервиса | Общий словарь Сервиса, без перегруза специальными терминами отдельных Категорий |
| Политика конфиденциальности Сервиса | Общая модель обработки персональных данных и специальные данные по Категориям |
| Пользовательское соглашение и правила использования Сервиса | Общие роли, Заказы, платежи, рейтинг, ограничения, Категории |
| Соглашение Сервиса с Партнером | Подключение Партнера, ресурсы, Исполнители, тарифы, расчеты |
| Соглашение Сервиса с Исполнителем | Общие условия доступа Исполнителя к Сервису |
| Соглашение Партнера с Исполнителем | Правовая связь Партнера и Исполнителя в рамках Сервиса |
| Соглашение с Корпоративным клиентом | Представители, лимиты, корпоративные Заказы, документы и расчеты |
| Соглашения для административных ролей | Доступ, полномочия, запреты, журналирование, ответственность |
| Правила оказания услуг Категории | Главный документ по конкретной услуге |
| Закрывающие документы по Категории | Отчет/акт, счет, расчет отмены, частичного выполнения, расходов |

===== 5. Самое важное — Категории услуг =====

Категория услуг должна отвечать на вопросы:

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

==== Мини-структура правил Категории ====

  - Общие положения.
  - Специальные термины Категории.
  - Спецификация Категории.
  - Ход оказания услуги.
  - Требования к Партнерам.
  - Требования к Исполнителям.
  - Требования к Клиентам.
  - Требования к ресурсам.
  - Стандарты качества.
  - Запреты, безопасность и инциденты.
  - Отчетность и закрывающие документы.

===== 6. Пример: Assist =====

==== Категория «Поездка» ====

В общих документах Сервиса достаточно указать, что есть Категория «Поездка». В правила Категории нужно вынести:

  * Водителя;
  * Партнера-перевозчика;
  * Транспортное средство;
  * Маршрут;
  * Место подачи и место назначения;
  * требования к Водителю и ТС;
  * запрет требований нарушить ПДД;
  * ожидание, остановки, багаж, дополнительные расходы;
  * Отчет о поездке и основания оплаты при отмене.

==== Категория «Поручение» ====

В правила Категории нужно вынести:

  * Предмет поручения;
  * Результат поручения;
  * Лимит расходов;
  * Дополнительные расходы;
  * Запрещенное поручение;
  * право Исполнителя отказаться от незаконного, опасного или неопределенного поручения;
  * Отчет о поручении, чек, фото, подтверждение передачи.

===== 7. Примеры для аренды =====

==== Аренда помещения ====

Проверьте, что описаны:

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

==== Аренда транспортного средства ====

Проверьте, что описаны:

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

==== Аренда инструмента ====

Проверьте, что описаны:

  * комплектность;
  * состояние при передаче и возврате;
  * инструкция безопасности;
  * залог;
  * повреждение и утрата;
  * запрет использования не по назначению;
  * запрет передачи третьим лицам.

===== 8. Что не стоит писать =====

^ Неудачная формулировка ^ Почему плохо ^ Как лучше ^
| «Сервис ни за что не отвечает» | Не соответствует роли Сервиса, если он организует доступ, оплату, данные и статусы | Разделить ответственность Сервиса, Партнера, Исполнителя и Клиента |
| «Исполнитель обязан выполнить любое поручение Клиента» | Риск незаконных и опасных заданий | Исполнитель выполняет только законные, безопасные и определенные Заказы в пределах Категории |
| «Блокировка без объяснения причин» | Риск произвольной санкции | Основания, фиксация, уведомление, процедура обращения |
| «Рейтинг автоматически прекращает доступ» | Оценка может быть ошибочной или недобросовестной | Оценка отдельно, жалоба отдельно, инцидент отдельно; санкция после проверки |
| «Сервис сам оказывает все услуги» | Может расширить ответственность Оператора | Указать, кто фактически оказывает услугу и кто организует цифровую среду |
| «Все данные можно передавать всем участникам» | Нарушает минимизацию и разграничение доступа | Доступ только по роли, Заказу, безопасности, расчетам и закону |
| «Счет подтверждает оказание услуги» | Счет подтверждает сумму, а не факт выполнения | Факт подтверждает отчет/акт, статус и цифровые следы |

===== 9. Проверка перед публикацией =====

  * Все плейсхолдеры заполнены.
  * Нет тестовых значений.
  * Реквизиты Оператора совпадают во всех документах.
  * Ссылки на документы открываются.
  * Категории совпадают в Терминах, Пользовательском соглашении и соглашениях ролей.
  * Для каждой Категории есть правила и закрывающие документы.
  * Платежная модель совпадает с фактическим движением денег.
  * В интерфейсе есть обязательные поля Заказа.
  * Статусы в интерфейсе совпадают с документами.
  * Отмена, частичное выполнение и инцидент фиксируются.
  * Ограничение доступа имеет основание и журнал события.
  * Рейтинг не применяется как автоматическая санкция без процедуры.
  * Персональные данные не собираются «на всякий случай».
  * Указаны редакция и дата документов.

===== 10. Короткий порядок добавления новой Категории =====

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

===== 11. Главная формула проверки =====

Для каждого существенного действия в Сервисе задайте вопрос:

  **действие — субъект — основание — документ — данные — последствие — доказательство — способ оспаривания**

Если один из элементов отсутствует, правовая архитектура недособрана.