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

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

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

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

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

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

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

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

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

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

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

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

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

1. Общие положения.
2. Специальные термины Категории.
3. Спецификация Категории.
4. Ход оказания услуги.
5. Требования к Партнерам.
6. Требования к Исполнителям.
7. Требования к Клиентам.
8. Требования к ресурсам.
9. Стандарты качества.
10. Запреты, безопасность и инциденты.
11. Отчетность и закрывающие документы.

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

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

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

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

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

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

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

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

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

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

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

1. Описать фактический сценарий услуги.
2. Подготовить паспорт Категории.
3. Подготовить специальные термины.
4. Подготовить правила Категории.
5. Подготовить закрывающие документы.
6. Обновить перечень Категорий в общих документах Сервиса.
7. Обновить Политику конфиденциальности, если появились новые данные.
8. Настроить поля Заказа, статусы, тарифы, требования и отчеты.
9. Провести тестовую генерацию.
10. Провести тестовый Заказ, отмену, частичное выполнение и инцидент.
11. Опубликовать документы и зафиксировать редакцию.

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

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

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