Deep research бэклога PayKeeper — апрель 2026
Контекст решения
- Партнёрство с PayKeeper (вендор фискализации + эквайринга + 3-в-1 терминала + кассового ПО).
- Отказ от PBF Group — PayApp SDK на K10 тупик (см. ADR-014).
- Принципиальное решение — не делаем свой POS. Касса = ПО PayKeeper. Мы трансформируемся в чистый ERP (каталог, склад, техкарты, франшиза, лояльность, отчётность).
- Источник — бэклог PK
доработки кассы 3 в 1.xlsx(апрель 2026). Показывает какие фичи PK заявляет как свои + квартальные планы на 2026.- Этот документ — основной референс по партнёрству с PayKeeper. Предыдущие артефакты (ADR-016, Roadmap 2026, Требования 1-й очереди) удалены как устаревшие после смены парадигмы на «их POS + наш ERP».
0. Что изменил новый бэклог
Актуальные сопутствующие артефакты в vault:
| Документ | Актуальность |
|---|---|
| gap-analysis.md | Базово актуален. Разрывы P0 (модификаторы, иерархия, прейскуранты, стоп-листы per-store) остаются блокерами |
| partnership-roadmap-2026.md | Базово актуален — двухэтапная модель партнёрства |
| vision-pos-platform.md | Устарел — описывает гибрид «наш POS + их фискальный модуль». Требует переписывания |
Весь подкаталог _assets/paykeeper/*.yaml | Актуальны — OpenAPI-спеки PK |
Новый xlsx — официальный «фичелист PK» с планом на 2026 по кварталам, и в нём нет ни модификаторов, ни иерархии категорий, ни per-store прейскурантов, ни стоп-листов per-store. То есть критичные для общепита P0-разрывы из gap-analysis PK в свой roadmap не включил. Это ключевой сигнал для планирования.
1. Матрица: бэклог PK ↔ наш скоуп
Статусы из xlsx:
- ✓ — готово
- «В работе, Nкв» / «В плане, Nкв» — их roadmap 2026
Каждый пункт маркирован одной из меток:
- 🟢 OWN-BY-PK — отдаём полностью, выпиливаем из своего скоупа
- 🟡 HYBRID — PK делает базовую, у нас — франшизная версия, есть риск коллизии
- 🔴 ERP-UNIQUE — PK не покрывает, остаётся уникальным у нас
- ⚪ IGNORE — PK делает, нам не релевантно
1.1 Типы оплат
| PK фича | Статус PK | Метка | Комментарий |
|---|---|---|---|
| Наличные, карта, СБП, смешанная | ✓ | 🟢 | Полностью PK. Webhook payment.received приносит payment_method |
| Разделение платежа, предчек, отложенный чек | 2кв | 🟡 | Нужно для dine-in (планшет официанта Q1-2027). Ждём 2кв и спросим спецификацию |
| Собственные типы оплат, бонусы, пищевые карты | 3кв | 🟡 | Коллизия с нашим Loyalty. Не ждём — наша скидка уже зашита в cart (final price) |
| Предоплата/постоплата/кредит (ФЗ-54) | 2кв | 🟢 | Нужно для онлайн-заказов Q3. Подтвердить на kick-off что tag 1214 поддерживается |
| Чеки коррекции, возврат прихода | ✓ | 🟢 | — |
1.2 Сканирование и маркировка
| PK фича | Статус PK | Метка |
|---|---|---|
| 2D-сканер ШК, маркировки | ✓ | 🟢 |
| Разрешительный режим ЧЗ | ✓ | 🟢 |
| Оплата по активной метке | ✓ | 🟢 |
Закрывает ТС ПИоТ целиком. У нас в Catalog Service остаётся только флаг is_marked (уже есть).
1.3 Скидки и лояльность
| PK фича | Статус PK | Метка | Комментарий |
|---|---|---|---|
| Ручная скидка на чек в % / рублях | 2кв | 🟡 | На кассе кассир может дать разовую скидку в обход нашего Loyalty. Нужен маппинг: либо запретить, либо проводить обратным webhook |
| Карты программы лояльности и купоны | 2кв | 🟡 | Их собственный модуль. Наш путь — свой Loyalty Service, финальная скидка едет в cart |
| Акции | 2кв | 🟡 | То же |
| Дисконтная и балльная программы | 4кв | 🟡 | То же, но разобраться нужно только если партнёр-франчайзи захочет их модуль |
Стратегия по лояльности
Свой Loyalty Service (уникальное для франшизной сети — бонусы действуют во всей сети, сегментация клиентов по BR 3.1). В
cartdeep link уходит финальная цена после применения нашей логики. Их модули лояльности не используем. Риск: кассир нажимает «Скидка на чек» на их UI → сумма в чеке ≠ в нашем Order. Мера: в настройках ролей PK отключаемdiscount.manualдля кассиров нашей сети, либо принимаем webhook и post-factum корректируем.
1.4 POS-операции
| PK фича | Статус PK | Метка |
|---|---|---|
| Редактируемая цена товара | ✓ | 🟢 (маппим на is_open_price) |
| Лимиты на возвраты | ✓ | 🟢 |
1.5 Документы и отчёты на кассе
| PK фича | Статус PK | Метка | Комментарий |
|---|---|---|---|
| Справочник товаров, кассовые чеки | ✓ | 🟢 | Локально на кассе |
| X / Z отчёты, сверка итогов | ✓ | 🟢 | BR 2.2 теряет актуальность в части формирования на кассе — отчёт формирует PK, у нас только потребление webhook shift.closed и отображение в админке |
| Инвентаризация, оприходование | 3кв | ⚪ | Их базовый учёт номенклатуры, не нужен — у нас Warehouse для общепита |
| Заказ на закупку | 4кв | ⚪ | То же |
| Отчёт по продажам / по товарам | 3кв | 🟡 | Для партнёра-франчайзи может быть достаточно их отчёта. Для франшизы — только наш агрегированный по всей сети |
1.6 Управление и ЛК PayKeeper
| PK фича | Статус PK | Метка | Комментарий |
|---|---|---|---|
| Справочник товаров | ✓ | 🟡 | Принимает импорт из нашего Catalog. Мастер — у нас |
| Аналитика по чекам | 2кв | 🟡 | Их фича дублирует наш TransactionJournalPage. Оставляем свою, но для партнёра-франчайзи их ЛК тоже доступен (удобно для бухгалтера) |
| Дистанционная настройка | ✓ | 🟢 | Их TMS |
| Сотрудники | ✓ | 🟡 | Мастер — наш User Service (с pos.access). В LK PK зеркалируем |
| Точки продаж | 4кв | 🟡 | Мастер — наш Store Service. Их справочник — вторичный. Маппинг терминал ↔ наш store_id хранится у нас |
| Права и роли | ✓ | 🟡 | PK — плоские булевы флаги. У нас permission-based. Адаптер транслирует маппинг. См. gap-analysis §3.5 |
| Рабочие места | 4кв | ⚪ | Их внутренняя сущность (рабочее место кассира). Нас не касается если не влияет на webhook identifiers |
| Конструктор чеков | 4кв | 🟢 | Брендирование чека (лого ТСП, реклама). Отдаём им |
| Мониторинг рабочих мест | 4кв | 🟢 | Их TMS-дашборд |
| Резервное копирование в облако | ✓ | 🟢 | Их |
| Realtime данные об операциях | ✓ | 🟢 | Ключевая фича. Webhook чеков = наша главная ниточка. Подтвердить на kick-off формат |
| Чеки окончательного расчёта | ✓ | 🟢 | — |
| Возвраты из ЛК | ✓ | 🟢 | = Admin-initiated refund — ключевая нужная фича, заявлена как готовая |
| Чеки коррекции из ЛК | ✓ | 🟢 | — |
| Импорт товаров | ✓ | 🟢 | Готово, API есть (ims-api /products/import) — см. README. Но errors[] в ответе отсутствует (P1 из gap-analysis §3.9) |
| Приём оплаты через ИЭ | ✓ | 🟢 | Invoice-engine, оплата по ссылке |
| Экспорт операций и чеков | ✓ | 🟢 | Формат обсуждать — CSV или JSON API |
| Автоматическая массовая коррекция | ✓ | 🟢 | — |
1.7 Интеграции с внешними системами
| PK фича | Статус PK | Метка | Комментарий |
|---|---|---|---|
| Выгрузка в Excel, обмен с 1С, API | ✓ | 🟢 | |
| Подключение сайта / мобильного | ✓ | 🟢 | Оплата заказа с сайта через облачную кассу PK |
| Подключение iiko | ✓ | 🟡 | Стратегически важно для партнёров-франчайзи, уже сидящих на iiko, — путь миграции. Но в нашей целевой картине iiko заменяем мы |
| Подключение Yclients, МойСклад, Битрикс24 | ✓ | ⚪ | Не наша аудитория. Но знание даёт нам конкурентный ответ если партнёр просит |
| Фискализация чеков по оплатам на сайте | ✓ | 🟢 | Закрывает Q3 онлайн-заказов целиком |
| Оплата заказов с сайта или внешней CRM на кассе | ✓ | 🟢 | — |
1.8 Модуль лояльности PayKeeper
См. §1.3 — полностью 🟡, мы строим свой.
1.9 Выплаты
| PK фича | Статус PK | Метка | Комментарий |
|---|---|---|---|
| Выплаты на карту на кассе / через ЛК | ✓ | 🟢 | Дополнительная фича — мы можем использовать для курьеров/самозанятых (см. Aggregator) |
| 2FA, повтор выплаты | ✓ | 🟢 | — |
1.10 TMS и удалённое управление
| PK фича | Статус PK | Метка |
|---|---|---|
| TMS собственной разработки | ✓ | 🟢 |
| Провижининг, авторегистрация ККТ, EMV-профили, удалённое конфигурирование | ✓ | 🟢 |
Вся IT-эксплуатация касс — их зона. Нам не нужно делать MDM для терминалов, это стратегический плюс.
1.11 Мобильное приложение PayKeeper
| PK фича | Статус PK | Метка | Комментарий |
|---|---|---|---|
| Realtime данные по чекам | ✓ | 🟢 | Приложение менеджера-владельца — видит выручку в моменте |
| Формирование любых чеков из мобильного | ✓ | 🟢 | Как аварийный запасной канал для кассира (если основной терминал недоступен) |
| Создание заказов и отправка на оплату на кассу | ✓ | 🟢 | Опционально — может использоваться для courier-out-of-cash flow |
| Разделение прав пользователей приложения | ✓ | 🟢 | Маппится на нашу ролевую модель |
Потенциал переиспользования: предложить партнёрам-франчайзи их приложение как «быстрый дашборд выручки», без необходимости строить своё. Экономия для нас.
2. Что уникально для ERP (🔴 ERP-UNIQUE)
Всё, что PK принципиально не делает и не планирует — наша ниша:
| Область | BR / спеки | Комментарий |
|---|---|---|
| Франшизная иерархия (франшизы, ЮЛ, партнёры) | BR 1.1, Юрлица | PK не знает про цепочку «франшиза → партнёр → ТТ» |
| Permission-based ролевая модель со scope | BR 1.4.4, Roles | PK — плоские флаги, адаптер транслирует |
| Модификаторы товаров | BR 1.8, 1.8.1, 1.9.2 | У PK плоский каталог. Ключевой P0-разрыв |
| Иерархия категорий (дерево) | BR 1.7 | У PK плоские теги |
| Per-store прейскуранты | BR 1.10 | У PK одна цена |
| Стоп-листы per-store | BR 1.13 | У PK глобальный is_visible |
| Техкарты + полуфабрикаты | BR 1.9, 1.9.1 | PK инвентаризация 3кв — базовая, без техкарт общепита |
| Ингредиенты, списание по продаже | BR 1.11, 1.14 | Только у нас |
| Авторекомендация закупок | Warehouse Phase 2 | Только у нас |
| Зоны доставки, ETA | Store Service | Только у нас |
| Агрегаторы доставки | Aggregator Service, BR 3.1 | Только у нас |
| Клиенты / CRM / группы клиентов | BR 3.1 CRM | Частично перекликается с их лояльностью, но наша модель сегментов — шире |
| Онлайн-заказы (модель заказа) | Order Service, BR 2.1 | Оформление заказа — у нас; фискальный чек — через их облако |
| KDS, планшет официанта, киоск self-service | Roadmap Q4 / Q1-2027 | Только у нас. Требуют от PK API инициации платежа с внешнего устройства (киоск) и мульти-терминала на одной ТТ |
| Франшизная отчётность, роялти | Не готово | Только у нас |
| Графики смен, учёт времени, зарплата | BR 1.4.1 | Только у нас |
3. Что выпиливается из нашего скоупа (🟢 OWN-BY-PK)
Прямая экономия — функциональность, которую можно снять с наших roadmap/репозиториев целиком:
3.1 erp-pos репозиторий — в архив
- Заморозка решена принципиально 2026-04-17, подтверждена новым бэклогом PK.
- В свете нового бэклога — не разморозим. Этап «собственный POS» полностью отменён.
- Действие: тег
v0-own-pos-before-paykeeper, веткаarchive/own-pos, README репозитория — «проект заморожен». - Что бросаем:
- Весь RN-клиент (15 экранов).
- PayApp Intent bridge, HttpFiscalCoreClient, RefundClient, BatchReconcileClient.
- USB-deliverable в
obsidian_erp/эквайринг/usb-deliverable/. - ADR-014 (PayApp headless тупик) — закрыть, проблема решена отказом от PayApp.
3.2 Спеки POS в vault — архив
08-Specs/POS/(4 файла: Fiscal Core Integration, Marking Integration, PayApp SDK Integration, Sale Flow) — перенести в_reference/archived/POS (own-built)/.09-Frontend Specs/POS/— та же судьба.- BR 2.2 — переписать: вместо «формируем X/Z на кассе» → «потребляем webhook
shift.closedи визуализируем агрегаты в админке».
3.3 Фичи которые НЕ делаем
| Фича | Почему не делаем | Вместо этого |
|---|---|---|
| Эквайринг / PCI-DSS | PK | Храним pk_payment_id в order_payments |
| Фискализация 54-ФЗ, ФН, ОФД | PK | Храним fn, fd, fp из webhook |
| Честный Знак ТС ПИоТ | PK | Флаг is_marked в каталоге, код уезжает в PK |
| Интеграция с Ingenico/АТОЛ/ГНИВЦ | PK | — |
| TMS для касс (MDM) | PK | — |
| Конструктор чеков (логотипы ТСП) | PK | — |
| Резервное копирование чеков | PK | — |
| Брендирование POS UI | PK | — |
| Выплаты физлицам на карту | PK | Используем их API для курьеров |
| Мобильное приложение кассира / менеджера смены для просмотра чеков | PK | Предлагаем партнёрам-франчайзи их приложение |
4. Что ждём от PayKeeper (остаётся из gap-analysis, с новыми акцентами)
Критичные P0-разрывы из gap-analysis — не закрыты их бэклогом:
| # | Разрыв | В xlsx? | Критичность |
|---|---|---|---|
| 3.1 | Модификаторы в каталоге и на mPOS | ❌ | P0. Без поддержки — кассир PK не собирает заказ, всегда через наше приложение |
| 3.2 | Иерархия категорий (parent_id) | ❌ | P0 |
| 3.3 | Per-store прейскуранты | ❌ | P0 |
| 3.4 | Стоп-листы / availability per-store | ❌ | P0 |
| 3.5 | Роли с привязкой к терминалам | Частично (права ✓, привязка к терминалам — ?) | P0 — уточнить |
| 3.6 | Webhook возврата / отмены / коррекции | Частично (возврат из ЛК ✓, webhook — ?) | P0 — уточнить |
| 3.7 | API списка платежей GET /payments?from=...&to=... | «Экспорт операций и чеков» ✓ — формат уточнить | P0 |
| 3.8 | Sandbox + тестовые ФН/карты | ❌ | P0 |
| 3.10 | ФН/ФД/ФП/номер смены в payload webhook | Не детализировано, только «realtime данные об операциях» ✓ | P1 |
| 3.11 | API и webhook по сменам (shift.opened/closed/expiring) | Не детализировано | P1 |
| 3.12 | Документированная multi-tenancy модель | ❌ | P1 |
| 3.13 | Весовой товар + протокол весов | ❌ | P1 |
| 3.14 | Алкоголь/табак/ЕГАИС | ❌ | P1 |
Вывод: бэклог PK подтверждает готовность интеграционного каркаса (webhook, импорт товаров, возвраты из ЛК), но не решает ресторанно-специфичные разрывы. Наш обходной путь остаётся: всегда передавать cart с finalized-ценами из нашего приложения, терминал PK не используется в standalone-режиме.
Новая позиция на kick-off
Раз мы не делаем свой POS, но PK не поддерживает модификаторы/иерархию/прейскуранты — значит у кассира на 3-в-1 нет способа самостоятельно набрать заказ для нашей ERP. Это значит заказ всегда инициируется снаружи (наш web, мобильное приложение, киоск, QR-меню клиента, облачный приёмник заказа от агрегаторов), а терминал только принимает оплату по готовому
cart(через invoice deep link или облачную кассу). Это фундаментальное ограничение UX — нужно явно согласовать с бизнесом (коллегой) до запуска пилота.
5. Новые возможности из бэклога (не было в gap-analysis)
| Фича PK | Применение у нас |
|---|---|
| «Разделение платежа, предчек, отложенный чек» (2кв) | Dine-in: официант открывает предчек, клиент оплачивает позже, можно разделить на компанию. Ранее требовало собственной реализации — теперь ждём их |
| «Предоплата/постоплата/кредит ФЗ-54» (2кв) | Онлайн-заказы Q3: чек предоплаты при оплате на сайте. Один из ключевых блокеров снимается на их стороне |
| «Подключение сайта или мобильного приложения» ✓ | Облачная касса для онлайн-оплат — то же, не нужно строить |
| «Подключение iiko» ✓ | Возможный путь миграции для партнёров, уже сидящих на iiko |
| «Выплаты на карту, 2FA, повтор без карты» ✓ | Курьеры агрегаторов, самозанятые подрядчики |
| «Мобильное приложение PK (realtime чеки)» ✓ | Лёгкий дашборд для партнёра-франчайзи без допразработки |
| «Оплата по активной метке» ✓ | NFC-кольца/стикеры, возможность добавить в лояльность |
6. План действий
6.1 Сразу (эта неделя)
-
Актуализировать стратегический контекст в vault:
- Обновить Vision POS Platform — сейчас описывает гибрид «наш POS + их фискальный модуль», переделать под чистую ERP-модель (их полный POS + наш ERP).
- Подготовить kick-off-повестку для PayKeeper (см. п.2) как отдельный файл в этой папке.
- Создать BR
Bx.x Интеграция с PayKeeper Phase 1в07-Tasks/Business Requirements/с финальным списком требований (после kick-off).
-
Kick-off с PayKeeper — сформировать список вопросов из двух источников:
- §4 выше (наши P0-разрывы: модификаторы, иерархия, прейскуранты, стоп-листы per-store, webhook возвратов, sandbox).
- Открытые пункты бэклога без детализации: формат webhook, API импорта ошибок, sandbox, тарификация TPS, multi-tenancy.
-
Обновить ADR:
- ADR-014 → закрыть, проблема снята отказом от PayApp.
6.2 Q2 2026 (май-июнь) — пилот PayKeeper
Цель: 1-2 собственные кофейни на PayKeeper full-stack, наш ERP как master-data.
Наш side:
- Новый сервис
paykeeper-adapter(Spring Boot, БД для mapping/outbox/webhook_log):- Webhook-приёмник
POST /webhooks/paykeeper/successс HMAC. - Outbox → PK (каталог, сотрудники, стоп-листы).
- Deep link generator для invoice.
- Reconciliation scheduler.
- Webhook-приёмник
- Catalog Service достройка (из gap-analysis §2.1):
products.vat_rate,products.payment_subject,measure_pk_override,payment_type.- Kafka-события
catalog.*. - Outbox-паттерн.
- User Service: события
user.employee.*, outbox. - Order Service: поля
pk_payment_id,pk_fop_receipt_key,pk_user_login,pk_terminal_id, consumerpayment.received. - Store Service: таблица
store_pk_mapping(store_id, pk_terminal_logical_id, pk_merchant_id). - Admin: раздел «Интеграции → PayKeeper», блок «Фискальные атрибуты» в карточке товара, permission
integrations.edit.
PayKeeper side (ждём от них):
- Sandbox + OpenAPI.
- Webhook чеков с полным составом + ФН/ФД/ФП.
- Admin-refund API (из xlsx ✓ — уточнить sync/async и формат).
- API списка платежей для reconciliation.
- Подтверждение multi-tenancy модели.
6.3 Q3 2026 (июль-сентябрь) — расширение
- Онлайн-заказы через облачную кассу PK (✓ в xlsx).
- Предоплата/постоплата/кредит (2кв у PK — к этому моменту готово).
- Агрегаторы доставки — заказы из Яндекс.Еды пробиваются через тот же фискальный узел.
- CRM + Loyalty v1 — свой модуль, передаём финальную цену в cart.
6.4 Q4 2026 — киоск self-service + маркировка
- Киоск self-service (наше приложение на 15-19” экране) — оплата через терминал PK без кассира. Ждём от PK API инициации платежа с внешнего устройства.
- Полный ЧЗ flow — сканирование DataMatrix на киоске, передача в PK.
6.5 Q1 2027 — KDS + планшет официанта + лояльность v2
- Планшет официанта для dine-in (использует PK «разделение платежа / предчек» из 2кв).
- KDS на монитор кухни.
- Loyalty v2 с сегментами, промокодами, персональными скидками.
7. Открытые решения (требуют согласования)
| # | Вопрос | Варианты | Рекомендация |
|---|---|---|---|
| 1 | Admin-Franchise использует свою аналитику по чекам или их «Аналитика по чекам» (2кв)? | Наша / PK / обе | Наша — нужна франшизная агрегация. PK для партнёра-франчайзи опционально |
| 2 | Скидки на чеке — кассиру можно применять вручную на PK-терминале? | Да / Нет | Нет (отключить в ролях PK). Вся лояльность через наш Loyalty |
| 3 | Инвентаризация PK (3кв) — используем? | Да / Нет | Нет. У нас Warehouse для общепита с техкартами — их не заменяем |
| 4 | Можно ли заказ инициировать только с нашего приложения? | Да (кассир PK UI не используется) / Нет | Да — вынужденно, пока PK не сделает модификаторы (P0 разрыв 3.1) |
| 5 | Мобильное приложение PK для менеджеров смены — предлагаем или делаем своё? | PK / Своё | PK на старте, своё только если сильно не хватит функциональности |
| 6 | Когда заморозка erp-pos → полное удаление? | Сразу / После пилота PK / После первого коммерческого клиента PK | После первого коммерческого клиента на PK (страховка от срыва партнёрства) |
| 7 | Что с партнёрами-франчайзи на iiko? Миграция через iiko-коннектор PK? | Да / Нет / Потом | Потом. Первые клиенты — «с нуля» на нашем стеке |
8. Экономия по сравнению с вариантом «свой POS»
| Направление | Оценка трудозатрат при «своём POS» | Экономия с PK |
|---|---|---|
| Разработка RN-клиента кассы | 4-6 мес. × 2 FTE | -100% |
| Интеграция с ФЯ (ru.armax.cashbox) | 1-2 мес. × 1 FTE | -100% |
| Интеграция с эквайрингом (PayApp) | 2-3 мес. × 1 FTE (в тупике, ADR-014) | -100% |
| Маркировка ЧЗ / ТС ПИоТ | 2-3 мес. + сертификация | -100% |
| TMS / MDM для терминалов | 2-3 мес. | -100% |
| Мобильное приложение менеджера | 2 мес. | -100% (используем PK mobile) |
| Сертификация 54-ФЗ | Отдельный юридический проект | -100% |
| Итого | ~12-18 мес. работы команды | Высвобождается под уникальную ERP-функциональность |
9. Риски
| Риск | Вероятность | Митигация |
|---|---|---|
| PK не даст модификаторы → кассир не может собрать заказ standalone | Высокая | Принципиальное решение: заказ инициируется только из наших приложений. Фиксируем в ADR |
| PK webhook чеков окажется неполным (нет модификаторов, нет скидок) | Средняя | Двусторонний sync: наш order_id → PK, в webhook возвращается → связь в Order Service |
| PK sandbox недоступен или ограничен | Средняя | Уточнить на kick-off. Альтернатива — mock-адаптер в тест-окружении |
| Разрыв партнёрства с PK через 6-12 мес. | Низкая | Интеграционный слой изолирован в paykeeper-adapter — ниже риск при замене вендора. Плюс зафиксированный archive/own-pos как страховка |
| Партнёр-франчайзи требует iiko-совместимую модель | Средняя | PK ✓ подключение iiko. Используем PK как переходник до миграции партнёра на наш стек |
Наша ERP-роль в чеке (tag 1203 ИНН кассира) не поддерживается на стороне PK | Низкая | Уточнить на kick-off |