Франчайзинговая платформа: устройство, подключение франчайзи и требования к нему¶
Дата: 11 сентября 2026 года
Назначение документа¶
Документ описывает устройство франчайзинговой платформы: как работает система, как в неё заводится франчайзи, что франчайзи обязан оформить и подключить до запуска, как проходят деньги и как разделена ответственность между головной компанией и партнёром.
Документ самодостаточен: для его понимания не требуется чтение других материалов.
Решения, зафиксированные здесь, являются принятыми. Головная компания выступает владельцем платформы и единственным лицом, принимающим решения по её устройству.
Условные обозначения¶
Значительная часть работы франшизы происходит за пределами платформы: в iiko, в кабинетах ЮKassa и оператора фискальных данных, в банке и в бумажном документообороте. Чтобы не создавать ложных ожиданий от интерфейса, такие действия помечены явно:
| Пометка | Значение |
|---|---|
| [платформа] | Выполняется в Админке ГК или Личном кабинете франчайзи |
| [вне платформы] | Выполняется в другой системе, в банке или на бумаге; кнопки в интерфейсе для этого нет и не планируется |
| [не согласовано] | Решение ещё не принято; описан вариант и его альтернативы |
Отсутствие пометки означает, что речь идёт об описании устройства, а не о действии.
Термины¶
| Термин | Значение |
|---|---|
| ГК | Головная компания — владелец бренда и платформы |
| ФЧ | Франчайзи — партнёр ГК, работающий через собственные юридические лица |
| Юридическое лицо | Организация или ИП франчайзи; сторона договоров с iiko, ЮKassa и ОФД, продавец для покупателя |
| Ресторан | Точка продаж на платформе, привязанная к организации iiko конкретного юридического лица |
| Витрина | Публичный сайт и приложение сети |
| Админка ГК | Интерфейс сотрудников головной компании |
| Личный кабинет ФЧ | Интерфейс сотрудников франчайзи |
Главный принцип: платформа не участвует в расчётах¶
Это ключевое положение, определяющее всю остальную конструкцию.
Платформа не является продавцом, платёжным агентом и получателем денег покупателя.
Покупатель ──── деньги ────▶ ЮKassa франчайзи ────▶ расчётный счёт франчайзи
│ │
│ └── чек пробивает касса франчайзи через его ОФД
│
└── заказ, статус, уведомления ──▶ платформа ГК
Из этого следует:
- Продавцом в оферте, чеке и платёжных документах является юридическое лицо ФЧ, которому принадлежит ресторан заказа. ГК продавцом не выступает.
- Деньги покупателя поступают напрямую на счёт ФЧ по его собственному договору с ЮKassa. Средства не проходят через счета ГК и не аккумулируются платформой.
- Фискальный чек формирует ФЧ на своей ККТ через своего оператора фискальных данных. Платформа чек не пробивает и не является его отправителем.
- Возврат денег выполняет ФЧ со своего счёта и по своим реквизитам. Платформа лишь фиксирует факт и статус возврата.
- Роялти, паушальный взнос, компенсация скидок и любые взаиморасчёты ГК с ФЧ выполняются вне платформы — на основании отдельных договоров и обычных банковских переводов. Платформа не переводит деньги между ГК и ФЧ и не удерживает комиссию из платежа покупателя.
- Роялти считается от всей выручки ресторана по данным iiko, а не от заказов сайта. Платформа видит только собственный канал продаж и не является источником данных для расчёта роялти.
Роль платформы в денежном контуре ограничена тремя функциями: подставить в платёж реквизиты нужного юридического лица, показать покупателю ссылку на оплату и сохранить статус платежа для отчётности. Все обязательства по платежу возникают между покупателем и франчайзи.
Что представляет собой система¶
Единая сетевая платформа под одним брендом и одним доменом, обслуживающая рестораны разных юридических лиц.
Витрина сети (один домен, один бренд)
│
┌───────────────────┼───────────────────┐
│ │ │
Ресторан ФЧ-1 Ресторан ФЧ-2 Ресторан ГК
юрлицо А, iiko А юрлицо Б, iiko Б юрлицо ГК, iiko ГК
ЮKassa А, касса А ЮKassa Б, касса Б ЮKassa ГК, касса ГК
Для покупателя это одна сеть: одна учётная запись, один каталог, один интерфейс, одна поддержка бренда. Юридическое лицо продавца показывается в момент оформления заказа и в чеке.
Для бизнеса это набор независимых юридических контуров, объединённых общей витриной и общими правилами.
Структура сети¶
Франчайзи
└── Юридическое лицо ← сторона договоров, продавец, получатель денег
└── Подключение к iiko ← договор ФЧ с iiko
└── Организация iiko ← импортируется из iiko автоматически
└── Ресторан ← точка на витрине
Правила:
- один франчайзи может работать через несколько юридических лиц;
- одно юридическое лицо принадлежит ровно одному франчайзи;
- у юридического лица может быть несколько подключений к iiko;
- ресторан навсегда привязан к одной организации iiko и, следовательно, к одному юридическому лицу;
- перенос ресторана между юридическими лицами невозможен: старый ресторан закрывается, создаётся новый.
Последнее правило существует потому, что смена юридического лица означает смену продавца, счёта, кассы и договоров. Это другой субъект, а не изменённая карточка прежнего.
Уровни хранения настроек¶
Каждая настройка живёт ровно на одном уровне. Это определяет, кто её задаёт и кто за неё платит.
| Настройка | Уровень | Кто задаёт | Кто платит |
|---|---|---|---|
Учётные данные iiko Transport (apiLogin) |
Юридическое лицо | ФЧ | ФЧ |
Реквизиты ЮKassa (shopId, секретный ключ) |
Юридическое лицо | ФЧ | ФЧ |
| Доступ к данным ОФД для показа чеков покупателям | Юридическое лицо | ФЧ | ФЧ |
| Юридические реквизиты продавца: наименование, ИНН, КПП, адрес | Юридическое лицо | ФЧ, проверяет ГК | — |
| Оферта, политика возврата, контакты продавца | Юридическое лицо | ФЧ, утверждает ГК | — |
| Расписание, зоны доставки, время приготовления, самовывоз | Ресторан | ФЧ | — |
| Стоп-листы и остатки | Ресторан | приходят из iiko ФЧ автоматически | — |
| Ассортимент, цены, фотографии, описания блюд | Сеть, с допустимыми отклонениями по ресторану | ГК | ГК |
| Telegram-канал операционных уведомлений персонала | ФЧ или ресторан | ФЧ | ГК |
| Учётная запись SMS-провайдера, имя отправителя | Глобально | ГК | ГК |
| Боты Telegram и MAX для клиентских уведомлений | Глобально | ГК | ГК |
| Подсказки адресов, капча, карты, почтовый сервер | Глобально | ГК | ГК |
| Домен, бренд, дизайн витрины, мобильное приложение | Глобально | ГК | ГК |
| Инфраструктура, база данных, мониторинг, резервные копии | Глобально | ГК | ГК |
Принцип разделения: всё, что вытекает из отдельного договора и отдельного юридического лица, хранится на уровне этого юридического лица. Всё, что является общим свойством бренда и сети, задаётся глобально и остаётся под контролем ГК.
Секреты — учётные данные iiko, ЮKassa и оператора фискальных данных — вводит только франчайзи. После сохранения они не показываются никому, включая сотрудников ГК. Требования к их хранению для разработчиков — в модели франчайзинга.
Требования к франчайзи до запуска¶
Ниже — полный перечень того, что ФЧ обязан предоставить или оформить самостоятельно. Без любого из обязательных пунктов ресторан не может быть активирован на витрине.
Всё перечисленное оформляется [вне платформы]: договоры заключаются с iiko, ЮKassa, оператором фискальных данных и банком напрямую, кассовая техника регистрируется в налоговой. Платформа эти подключения не создаёт и не ускоряет — она лишь принимает уже полученные реквизиты и проверяет, что они работают.
Юридические требования¶
| Требование | Обязательность | Комментарий |
|---|---|---|
| Зарегистрированное юридическое лицо или ИП | Обязательно | ИНН 10 или 12 цифр, КПП для организаций, юридический адрес |
| Договор коммерческой концессии с ГК | Обязательно | Основание для использования бренда и платформы |
| Расчётный счёт | Обязательно | Получатель денег покупателей |
| Публичная оферта и политика возврата | Обязательно | От имени юридического лица ФЧ, шаблон предоставляет ГК |
| Согласование обработки персональных данных покупателей | Обязательно | ФЧ обрабатывает данные покупателя в объёме, необходимом для исполнения заказа |
Требования к системе учёта¶
| Требование | Обязательность | Комментарий |
|---|---|---|
| Действующий договор с iiko | Обязательно | Заключает ФЧ от своего юридического лица |
| Лицензия iiko Transport (iikoCloud API) | Обязательно | Без неё платформа не может передавать заказы |
apiLogin iiko Transport |
Обязательно | Вводится франчайзи в Личном кабинете, после сохранения не показывается |
| Настроенная организация и терминальная группа в iiko | Обязательно | Импортируются платформой автоматически |
| Настроенные типы оплаты в iiko | Обязательно | Наличные, карта курьеру, онлайн-оплата; идентификаторы у каждого аккаунта iiko свои |
| Заведённая номенклатура, соответствующая меню сети | Обязательно | Соответствие проверяет ГК до активации |
| Доступ бухгалтерии ГК к отчётности продаж iiko | Обязательно | Предоставляется [вне платформы] средствами самой iiko; нужен для расчёта роялти по всей выручке, включая зал |
| Проведение всей выручки через iiko | Обязательно | Зал, доставка, самовывоз, телефон, агрегаторы, банкеты |
Требования к приёму платежей¶
| Требование | Обязательность | Комментарий |
|---|---|---|
| Договор с ЮKassa | Обязательно | Заключает ФЧ от своего юридического лица |
shopId и секретный ключ ЮKassa |
Обязательно | Вводятся франчайзи, после сохранения не показываются |
| Подключённый в ЮKassa способ оплаты: банковские карты | Обязательно | — |
| Подключённый в ЮKassa СБП | Рекомендуется | — |
| Настроенные возвраты в кабинете ЮKassa | Обязательно | Возврат выполняет ФЧ |
Требования к кассе и фискализации¶
| Требование | Обязательность | Комментарий |
|---|---|---|
| Зарегистрированная ККТ на юридическое лицо ФЧ | Обязательно | Онлайн-касса для доставки и самовывоза |
| Договор с оператором фискальных данных | Обязательно | — |
| Настроенная схема фискализации онлайн-оплат | Обязательно | ФЧ определяет, чек формирует ЮKassa или его собственная касса |
| Доступ к данным ОФД по кассам ресторанов франшизы | Обязательно | Используется только для показа чека покупателю в его заказе; для контроля выручки не применяется |
Организационные требования¶
| Требование | Обязательность | Комментарий |
|---|---|---|
| Ответственное лицо и его рабочая почта | Обязательно | На неё отправляется приглашение в Личный кабинет |
| Телефон ресторана для покупателей | Обязательно | Публикуется на витрине |
| Адрес, часовой пояс и график работы точки | Обязательно | — |
| Зоны доставки и условия | Обязательно | — |
| Персонал, курьеры и оборудование точки | Обязательно | Зона ответственности ФЧ |
Как заводится франчайзи¶
Процесс состоит из семи шагов. Первые два выполняет ГК, следующие — ФЧ, финальную проверку и активацию — снова ГК.
0. ФЧ заключает договоры и получает реквизиты [вне платформы]
↓
1. ГК создаёт франчайзи [платформа]
↓
2. ГК создаёт юридическое лицо и приглашает [платформа]
администратора ФЧ
↓
3. ФЧ принимает приглашение и задаёт пароль [платформа]
↓
4. ФЧ создаёт подключение к iiko своего [платформа]
юридического лица
↓
5. Платформа импортирует организации iiko [платформа]
и создаёт черновики ресторанов
↓
6. ФЧ заполняет настройки ресторана и вводит [платформа]
платёжные реквизиты
↓
7. ГК проверяет готовность и активирует ресторан [платформа]
на витрине
Нулевой шаг обычно занимает больше времени, чем все остальные вместе: регистрация кассы, договор с iiko и подключение ЮKassa зависят от внешних организаций и не ускоряются со стороны платформы.
Шаг 1. Создание франчайзи¶
Сотрудник ГК в Админке создаёт карточку франчайзи с наименованием партнёра. Франчайзи создаётся активным. Физическое удаление не поддерживается: партнёра можно только отключить, сохранив всю историю.
Шаг 2. Юридическое лицо и приглашение¶
Сотрудник ГК создаёт внутри франчайзи юридическое лицо с реквизитами: наименование, ИНН, КПП, юридический адрес. Пара ИНН и КПП уникальна во всей системе, поэтому одно юридическое лицо нельзя завести дважды или привязать к двум франчайзи.
Затем ГК отправляет приглашение первому администратору ФЧ на его рабочую почту. Сотрудник ГК не создаёт, не задаёт и не видит пароль франчайзи.
Шаг 3. Принятие приглашения¶
Администратор ФЧ переходит по ссылке из письма и задаёт собственный пароль. Ссылка одноразовая и действует 72 часа. После этого он входит в Личный кабинет франчайзи и видит только данные своего франчайзи.
Шаг 4. Подключение iiko¶
Администратор ФЧ выбирает своё юридическое лицо и создаёт подключение к iiko, указав имя
подключения и apiLogin, полученный от iiko. Учётные данные принадлежат юридическому лицу, потому
что договор с iiko заключён именно им.
Платформа проверяет, что юридическое лицо принадлежит этому франчайзи и что и юридическое лицо, и франчайзи активны. Подключить чужое юридическое лицо технически невозможно.
Одно юридическое лицо может иметь несколько подключений — например, если у ФЧ несколько аккаунтов iiko.
Шаг 5. Импорт организаций и черновики ресторанов¶
Платформа обращается к iiko и импортирует список организаций подключения. Импорт повторяется по расписанию, чтобы данные оставались актуальными. Для каждой новой организации создаётся ресторан в статусе «черновик»: он существует в системе, но недоступен покупателям.
Если организация исчезает из ответа iiko, ресторан не закрывается автоматически — это может быть временный сбой. Ресторан становится недоступным, а решение о закрытии принимает сотрудник ГК отдельной командой.
Шаг 6. Настройка ресторана и реквизитов¶
Администратор ФЧ заполняет по каждому ресторану:
- публичное название и адрес;
- часовой пояс и график работы;
- зоны доставки и условия;
- время приготовления и параметры самовывоза;
- реквизиты ЮKassa своего юридического лица;
- доступ к данным ОФД для показа чеков покупателям;
- контактный телефон точки.
Платёжные и кассовые реквизиты задаются один раз на юридическое лицо и применяются ко всем его ресторанам.
Шаг 7. Проверка и активация¶
Сотрудник ГК проверяет комплектность: юридические реквизиты, наличие всех обязательных доступов, соответствие номенклатуры iiko меню сети, корректность зон доставки. После проверки ресторан активируется и появляется на витрине.
До активации ресторан не принимает заказы и не виден покупателям.
Разделение ролей после запуска¶
| Область | ГК | ФЧ |
|---|---|---|
| Бренд, витрина, домен, мобильное приложение | Владеет и развивает | Использует |
| Меню сети, цены, фотографии, описания | Определяет | Исполняет |
| Ассортимент точки в пределах меню сети | Утверждает правила | Управляет стоп-листами через iiko |
| График работы, зоны доставки, время приготовления | Утверждает правила | Настраивает |
| Приём и приготовление заказа | — | Полностью отвечает |
| Доставка и курьеры | — | Полностью отвечает |
| Приём денег покупателя | Не участвует | Полностью отвечает |
| Фискальный чек | Не участвует | Полностью отвечает |
| Учёт всей выручки в iiko | Контролирует и сверяет | Полностью отвечает |
| Возврат денег | Не участвует | Полностью отвечает |
| Клиентские уведомления: SMS, Telegram, MAX | Владеет каналами и оплачивает | Использует |
| Единая клиентская база сети | Владеет | Получает доступ только к данным своих заказов |
| Поддержка покупателя по бренду и витрине | Первая линия | — |
| Поддержка покупателя по конкретному заказу | Эскалация | Разбор и решение |
| Инфраструктура, хранение данных, безопасность | Полностью отвечает | — |
| Персональные данные покупателей | Оператор | Обрабатывает в объёме исполнения заказа |
Как проходит заказ и деньги¶
1. Покупатель выбирает адрес и ресторан на витрине сети
2. Платформа определяет юридическое лицо продавца по ресторану
3. Покупатель видит наименование и ИНН продавца до подтверждения заказа
4. Платформа создаёт платёж в ЮKassa по реквизитам этого юридического лица
5. Покупатель оплачивает; деньги поступают на счёт франчайзи
6. Платформа получает подтверждение оплаты и сохраняет статус
7. Заказ передаётся в iiko франчайзи
8. Франчайзи готовит и доставляет заказ, пробивает чек на своей кассе
9. Платформа отслеживает статус заказа в iiko и уведомляет покупателя
Определение продавца происходит до создания платежа и не может измениться после его начала. Переназначить заказ на ресторан другого юридического лица нельзя: это означало бы, что деньги получил один продавец, а обязательство исполняет другой. Если ресторан не может исполнить оплаченный заказ, выполняется возврат и оформляется новый заказ.
Чек покупателю¶
Фискальный чек формирует касса франчайзи [вне платформы]. Платформа чеки не выпускает и продавцом не является. Обязанность выдать чек покупателю лежит на франчайзи и исполняется его кассой независимо от того, показывает платформа чек или нет.
Дополнительно платформа старается показать покупателю его чек прямо в заказе на сайте. Для этого она забирает чеки из данных оператора фискальных данных франчайзи и сопоставляет их с заказами.
| Шаг | Где выполняется |
|---|---|
| Касса франчайзи пробивает чек, чек уходит оператору фискальных данных | [вне платформы] |
| Платформа получает чеки по кассам ресторанов франшизы | [платформа] |
| Платформа сопоставляет чек с заказом | [платформа] |
| Покупатель видит ссылку на свой чек в заказе | [платформа] |
Передать номер заказа в чек iiko не умеет, поэтому чек находится сравнением состава. Правила сопоставления:
- Рассматриваются только чеки касс того ресторана, в котором оформлен заказ. Чек другого юридического лица к заказу привязан быть не может.
- Отбираются чеки с совпадающей суммой, признаком оплаты и временем в пределах окна вокруг заказа.
- Состав чека сравнивается с составом заказа целиком, включая модификаторы: соусы, борта, топпинги и отдельные строки, которыми касса разбивает позицию.
- Чек привязывается к заказу, только если совпадение полное и подходящий чек ровно один.
- Если не совпал ни один чек или подошло несколько одинаковых — не привязывается ничего.
Пятое правило существеннее, чем кажется. Два одинаковых заказа из одного ресторана в одно время дают два неразличимых чека, и точность сравнения здесь не помогает: угадать, какой чей, невозможно. Показать покупателю чужой чек хуже, чем не показать никакого, поэтому в спорной ситуации платформа не показывает ничего.
Следствие: чек в заказе появляется не всегда. Это не является сбоем и не нарушает закон — свой чек покупатель в любом случае получает от кассы франчайзи. Отображение чека на сайте является удобством, а не способом исполнения обязанности продавца.
Сам способ получения чека может упроститься: у iiko уточняется, отдаёт ли отчётность её сервера фискальные реквизиты закрытого заказа. Если отдаёт, ссылка на чек будет собираться из этих реквизитов напрямую — сопоставление по составу станет ненужным, а доступ к данным оператора фискальных данных перестанет быть требованием к франчайзи.
Возвраты¶
Возврат инициируется в Личном кабинете ФЧ [платформа], исполняется в ЮKassa франчайзи и уходит на карту покупателя с его счёта [вне платформы]. Корректировочный чек пробивает касса франчайзи [вне платформы]. ГК в возврате деньгами не участвует. Платформа фиксирует основание, сумму и статус возврата для отчётности обеих сторон.
Отчётность и сверка¶
Платформа предоставляет:
- франчайзи — реестр его заказов, платежей и возвратов, созданных на витрине;
- ГК — сводный реестр по всей сети без доступа к платёжным секретам франчайзи.
Эти реестры закрывают только онлайн-канал: заказ на витрине, платёж в ЮKassa и заказ в iiko должны сходиться по сумме и количеству. Это операционная аналитика собственных продаж платформы и не более того. К начислению роялти реестры отношения не имеют.
Выручка и база для расчёта роялти¶
Ресторан продаёт не только через сайт. Выручка формируется в нескольких каналах, и большая её часть может вообще не проходить через платформу.
| Канал продаж | Где фиксируется | Видит ли платформа | Входит в базу роялти |
|---|---|---|---|
| Заказ на сайте или в приложении сети | Витрина, ЮKassa, iiko, ККТ | Да | Да |
| Гость в зале ресторана | iiko, ККТ | Нет | Да |
| Самовывоз, оформленный на кассе | iiko, ККТ | Нет | Да |
| Заказ по телефону, принятый оператором | iiko, ККТ | Нет | Да |
| Заказ через агрегаторы доставки | iiko, ККТ | Нет | Да |
| Продажа навынос, банкет, кейтеринг | iiko, ККТ | Нет | Да |
Гость может прийти в ресторан, поужинать на пять тысяч рублей и рассчитаться на кассе. Платформа об этой продаже не узнает никогда, но роялти с неё платится так же, как с заказа на сайте.
Поэтому база для расчёта роялти — данные iiko, а не реестр сайта. Сайт является одним из каналов продаж и учитывается внутри общей выручки, а не отдельно от неё.
Источники данных о выручке¶
| Источник | Что показывает | Роль в расчёте |
|---|---|---|
| iiko франчайзи | Полная управленческая выручка по всем каналам и типам оплаты | Единственный источник, база начисления роялти |
| Реестр платформы | Заказы и платежи только онлайн-канала | В расчёте роялти не используется; аналитика онлайн-продаж |
Фискальные данные для контроля выручки не используются. Касса ресторана управляется iiko: чек пробивается той же системой, в которой оформлена продажа, поэтому продажи в обход iiko с пробитым чеком не существует как сценария. Фискальные данные повторяют то, что уже есть в iiko, и второго независимого источника не образуют.
Чеки, которые платформа получает от оператора фискальных данных, служат единственной цели — показать покупателю его чек в заказе. В расчёте роялти они не участвуют.
Обязанности франчайзи по учёту выручки¶
- Вся выручка ресторана без исключений проводится через iiko: зал, доставка, самовывоз, телефонные заказы, агрегаторы, банкеты.
- Каждая продажа фискализируется на ККТ этого юридического лица.
- ГК предоставляется постоянный доступ к отчётности продаж iiko франчайзи.
- Закрытие периода в iiko выполняется в срок, установленный договором.
- Продажи мимо iiko или мимо кассы являются нарушением договора концессии независимо от суммы.
Как считается роялти¶
Расчёт роялти целиком происходит [вне платформы]. Ни один шаг не является кнопкой в админке, и такой кнопки не появится.
| Шаг | Где выполняется | Кто выполняет |
|---|---|---|
| 1. Закрытие расчётного периода в iiko | в iiko | ФЧ |
| 2. Выгрузка выручки ресторана за период | отчётность iiko | Бухгалтерия ГК |
| 3. Исключение оговорённых договором позиций: возвраты, списания, служебные операции | расчёт по договору | Бухгалтерия ГК |
| 4. Начисление роялти по ставке договора концессии | расчёт по договору | ГК |
| 5. Выставление счёта и закрывающих документов | бухгалтерия и документооборот | ГК |
| 6. Оплата роялти | банковский перевод | ФЧ |
Платформа не участвует ни в одном из этих шагов. Она не выгружает выручку из iiko, не хранит её, не считает базу и не формирует отчёт для начисления.
Причина простая: платформа обслуживает один канал продаж из нескольких и по определению не знает полной выручки ресторана. Полные данные есть в iiko, и работать с ними должны бухгалтеры ГК и ФЧ средствами самой iiko. Дублировать эти данные в платформе означало бы создать второй, заведомо неполный источник истины о выручке и спровоцировать споры о том, какой из них правильный.
Всё, что платформа даёт по выручке, — аналитика собственных онлайн-продаж для операционных решений: динамика заказов, средний чек витрины, доля каналов оплаты. Это управленческая информация, а не финансовый документ.
Клиентская база и изоляция данных¶
Покупатель регистрируется в сети, а не у конкретного франчайзи. Одна учётная запись работает во всех городах и ресторанах. Первый заказ в ресторане другого франчайзи не создаёт нового покупателя.
Правила доступа:
- сотрудник ФЧ видит только заказы ресторанов своего франчайзи;
- сотрудник ФЧ не может искать покупателей по всей сети;
- сотрудник ФЧ не видит историю заказов покупателя у других франчайзи;
- в Личный кабинет ФЧ передаётся минимум данных покупателя, необходимый для исполнения заказа;
- область доступа вычисляется сервером по ресторану и не принимается от клиента.
Отключение франчайзи убирает его рестораны с витрины и запрещает новые заказы, но не удаляет учётные записи покупателей и их историю.
Жизненный цикл и выход из франшизы¶
Отключение франчайзи¶
Отключение франчайзи немедленно закрывает доступ его сотрудникам, останавливает синхронизацию с iiko и делает его рестораны недоступными на витрине. Собственные статусы ресторанов при этом не переписываются: после обратной активации восстанавливаются только те точки, которые были активны сами по себе.
Закрытие ресторана¶
Закрытие ресторана окончательно и необратимо. Закрытый ресторан остаётся в системе ради истории своих заказов, платежей и чеков.
Смена юридического лица¶
Ресторан не переносится между юридическими лицами. Старый ресторан закрывается, для нового юридического лица создаётся новое подключение iiko и новый ресторан. Совпадение адреса не создаёт между ними связи.
Расторжение договора¶
При выходе из франшизы франчайзи отключается, а его сотрудники теряют доступ в Личный кабинет [платформа]. Рестораны убираются с витрины, новые заказы не принимаются.
Выгрузка данных франчайзи при расторжении не предусмотрена. История заказов, платежей и возвратов остаётся в системе и принадлежит сети: она нужна для отчётности, налоговых проверок и разрешения споров с покупателями. Данные покупателей сети партнёру не передаются в любом случае.
Собственные операционные и финансовые данные у франчайзи остаются в его iiko и его кабинетах ЮKassa и ОФД — эти системы принадлежат ему и после расторжения.
Расторжение договора концессии, финальные взаиморасчёты и закрытие обязательств перед покупателями по оплаченным заказам выполняются [вне платформы].
Состояние реализации¶
| Возможность | Состояние |
|---|---|
| Франчайзи и юридические лица | Реализовано |
| Учётные записи сотрудников ГК и ФЧ, роли, приглашения, вход | Реализовано |
| Админка ГК: контур входа | Реализовано |
| Личный кабинет ФЧ: вход, юридические лица, подключения iiko | Реализовано |
| Подключения iiko и импорт организаций | Реализовано |
| Защищённое хранение учётных данных iiko | Запланировано до подключения боевых аккаунтов |
| Создание ФЧ, юридического лица и приглашения из Админки ГК | В работе |
| Рестораны: создание, настройка, активация, закрытие | Запланировано |
| Витрина и учётные записи покупателей | Запланировано |
| Каталог, меню и стоп-листы | Запланировано |
| Заказы | Запланировано |
| Платежи и реквизиты ЮKassa на уровне юридического лица | Запланировано |
| Получение чеков из ОФД и сопоставление с заказами | Запланировано |
| Реестры и аналитика онлайн-канала: заказы, платежи, возвраты | Запланировано |
Открытые вопросы¶
[не согласовано]
Четыре задачи не имеют решения на момент написания документа. У всех одна причина: каждый франчайзи работает в собственном аккаунте iiko, а одинаковые по смыслу объекты в разных аккаунтах имеют разные идентификаторы и разные названия. Сеть требует единообразия, iiko франчайзи о существовании сети не знает.
Решение по каждому пункту нужно принять до запуска витрины: все четыре влияют на то, уедет ли заказ в iiko и сойдётся ли его сумма.
Единое меню сети¶
Меню должно существовать на уровне сети: одна карточка блюда, одно название, одно описание и фото, согласованная цена. Но заказ уходит в iiko конкретного франчайзи, где это же блюдо имеет собственный идентификатор и, скорее всего, другое название. Совпадения не будет даже при одинаковом ассортименте.
Значит, между каталогом сети и номенклатурой каждого ресторана нужна таблица соответствия. Что требует решения:
- по какому ключу сопоставлять: по артикулу или коду номенклатуры, который ГК обяжет франчайзи проставить одинаково, либо вручную при подключении ресторана;
- кто заполняет соответствие и кто отвечает за его полноту;
- сопоставление нужно не только для блюд, но и для размеров, модификаторов, соусов, бортов и комбо — объём работы кратно больше, чем список позиций меню;
- что происходит с позицией, для которой соответствие не заполнено: блюдо скрывается на витрине для этого ресторана или ресторан не активируется, пока меню не сопоставлено полностью;
- как обнаруживать расхождения потом, когда франчайзи переименует или пересоздаст позицию у себя.
Скидки и акции сети¶
Акция сети должна применяться к заказу на витрине и корректно уехать в iiko: без этого сумма заказа на сайте и сумма в iiko разойдутся, а расхождение ломает и чек, и сверку с платежом.
Скидки в iiko тоже имеют собственные идентификаторы в каждом аккаунте, поэтому одной акции сети должна соответствовать заведённая скидка в iiko каждого ресторана. Что требует решения:
- кто заводит скидки в iiko франчайзи: сам франчайзи по инструкции ГК или ГК с доступом к его iiko;
- как проверяется, что скидка заведена и заведена правильно, до запуска акции;
- что делает платформа, если у ресторана нужной скидки нет: не отправляет заказ, отправляет без скидки или не показывает акцию в этом ресторане;
- допустимо ли передавать скидку суммой вместо ссылки на скидку iiko и приемлемо ли это для учёта франчайзи;
- кто несёт стоимость сетевой акции и как она компенсируется.
Порядок запуска акции получается обратным привычному: сначала одинаковые скидки заводятся во всех аккаунтах iiko, и только потом акция включается на витрине.
Один покупатель и несколько баз iiko¶
Покупатель сети единый, но база гостей в каждом iiko своя. Один и тот же человек будет разными гостями в разных аккаунтах, и связать их между собой средствами iiko нельзя. Что требует решения:
- привязывается ли заказ к гостю в iiko вообще или уходит без привязки;
- если привязывается, кто создаёт гостя в iiko франчайзи и по какому признаку он ищется повторно;
- где живёт программа лояльности: в платформе на уровне сети или в iiko каждого франчайзи;
- что делать с бонусами и картами гостя, уже накопленными в iiko франчайзи до входа во франшизу.
Пока лояльность не спроектирована, простейший вариант — отправлять заказы без привязки к гостю iiko, сохраняя историю покупателя только в платформе.
Типы оплаты¶
Проблема того же рода и обнаружена в текущей системе: идентификаторы типов оплаты iiko зашиты в код и принадлежат аккаунту головной компании. У франчайзи со своим договором iiko они будут другими.
Каждому способу оплаты витрины — онлайн, наличные курьеру, карта курьеру — должен соответствовать тип оплаты в iiko конкретного ресторана. Без этого заказ либо не создастся, либо создастся с неверным типом оплаты и испортит франчайзи учёт выручки. Требуется решить, кто заполняет это соответствие и проверяется ли оно при активации ресторана.
Не блокируют запуск витрины¶
Юридические вопросы и коммуникации:
- Допустимо ли одно имя отправителя SMS для заказов разных юридических лиц?
- Нужны ли отдельные согласия на рекламные рассылки и кто обрабатывает отказ от них?
- Кто утверждает шаблоны сообщений покупателям и нужно ли указывать в них продавца?
- Кто указывается продавцом в выгрузке каталога для маркетплейсов, если рестораны принадлежат разным юридическим лицам?
Эксплуатация:
- Какие гарантии доступности ГК даёт ФЧ по сайту, платежам, уведомлениям и поддержке?
- Кто разбирает сбои iiko, ЮKassa или ОФД конкретного ФЧ и что видит покупатель, если iiko одного ФЧ недоступна?
- Сколько хранятся заказы и данные ФЧ после выхода из франшизы?
- Нужна ли детализация расходов на SMS по каждому ФЧ, если оплачивает их ГК?
Отложенные решения¶
Следующее сознательно не входит в первую очередь и будет спроектировано отдельно:
- программа лояльности и бонусы уровня сети;
- промокоды и правила компенсации скидок между ГК и ФЧ;
- телефония и автообзвон;
- географическая модель городов, пригородов и зон обслуживания.
До появления этих возможностей действуют правила: бонусы и промокоды на витрине не выпускаются, телефония остаётся вне платформы.
Ограничения, принятые окончательно¶
В отличие от отложенных решений, следующее не появится в платформе и не подлежит пересмотру при планировании:
- Платформа не принимает и не переводит деньги. Все расчёты идут напрямую между покупателем и франчайзи, а между ГК и франчайзи — вне платформы.
- Ресторан не переносится между юридическими лицами. Смена продавца оформляется закрытием ресторана и созданием нового.
Связанные документы¶
- Франшиза на iikoChain — место продуктов iiko во франшизе.
- Модель франчайзинга — техническая реализация для разработчиков.
- Что в legacy мешает франшизе — ограничения текущей системы.