Аудит карты YUMA POS Full Map — 2026-05-12

1. Карта противоречит сама себе

Четыре места, где разные страницы карты говорят разное:

Цеха (bo_kitchens) — на одной странице помечено «готово», на странице изменений за 11.05 — «частично, нужно доделать».
Список клиентов / группы клиентов — на странице изменений «выделено в Customer Service, готово», на странице плана — «в работе».
Кухонный экран — рядом стоят два маркера: «работает в проде» и «под вопросом, в разработке».
3 фиксированные роли в MVP — на странице состава MVP, хотя сама модель ролей в коде давно переписана на гибкие permissions (BR 1.4.4).

2. Где карта говорит больше, чем есть

Карта обещает	По факту
Кухонный экран — «работает в проде»	Код полный (PIN, мульти-станция, статусы, звук, техкарты). Но нет ни одного релизного тега, последние коммиты — dev-фиксы. Спека (BR 5.1) — в драфте. То есть «работает у нас на стенде» — да, «выпущено в прод» — нет.
AI Photo Studio — «в проде»	Сам сервис фото-генерации действительно работает (photo.nirbi.ru). Но интеграция в ERP (BR 2.6) — в планах, не закрыта.
Customer Service — список клиентов, кредитный лимит, баллы, история заказов, импорт XLSX	Есть только: ФИО, телефон, email, день рождения, пол, заметки, адреса доставки, статические/динамические группы. Нет: кредитного лимита, баллов лояльности, истории заказов, импорта XLSX.
Агрегаторы доставки — Яндекс.Еда, Delivery Club, Chibbis, DLVRY, Яндекс.Доставка	Реально подключены только Яндекс.Еда и Netmonet. Остальные — пустые заглушки. Плюс отправка статусов в Яндекс пока в режиме «log-only» (HTTP-вызов не делается, ждём API-контракт).
Netmonet — «зелёный, готово»	По vault спека (BR 3.2) — в работе. Часть, где Netmonet шлёт нам входящие события, заблокирована — ждём контракт от их стороны.
24/7 точки — новая фича	В коде поля графика есть, но специальной логики «если время открытия = времени закрытия, то это 24/7» нет. Это просто соглашение, которое нигде не enforce’ится.
3 фикс. роли в MVP (Админ/Менеджер/Кассир)	Система давно переписана на гибкие permissions. Жёсткие роли удалены ещё в BR 1.4.4.
POS Phase 1 — «всё готово»	Phase 1 (планы столов, типы заказа) действительно закрыт. Но Phases 2–5 (доп. позиции, скидки, PIN менеджера, агрегаторы) — описаны на бумаге, не сделаны.
Семья ИИ-агентов: 5 в работу	Из 5 — два (Подели №17 и Постинг в соцсети №19) не имеют ни спеки, ни задачи в vault. Только идея.

3. Где карта говорит меньше, чем есть (PK блокеры)

Это самое важное место для разговора с PayKeeper. Карта помечает несколько пунктов как «нет/частично», но по факту это уже сделано на нашей стороне:

Блокер на карте	Реальный статус
P3 — Фискальных реквизитов нет в webhook (54-ФЗ риск)	Все реквизиты ловятся (номер ФН, номер ФД, фискальный признак, регистрационный номер ККТ, номер смены, номер чека, ссылка на чек). Карта использует юридическую терминологию 54-ФЗ, а в payload PK поля называются короче — это одни и те же данные, просто разные имена. Плюс есть резервный pull через отдельный API чеков.
P4 — Webhook возвратов и коррекций «не описаны»	Webhook возвратов реально приходит, обрабатывается, мы умеем считать «полный/частичный возврат» и различать «возврат из PK ЛК» vs «возврат, инициированный из нашего ERP». Коррекции тоже ловятся через специальный флаг.
P1 — Cross-device push «архитектурный блокер»	Не архитектурный. Способ доставки счёта на терминал у PK есть, мы им пользуемся, событие «оплата прошла» приходит. Открытый узкий вопрос — приходит ли отдельный сигнал «счёт доставлен на терминал» (а не только «оплачен»).
P5 — Получение списка платежей «вероятно есть»	Метод есть, мы его реально используем — каждую ночь автоматически забираем «зависшие» платежи и просим PK их перешлать. Полностью рабочий механизм.
2-stage платежи (резерв + списание) — «на вырост»	На нашей стороне списание после резерва уже готово через очередь команд. Не хватает только способа со стороны PK инициировать сам резерв.
Идемпотентность webhook’ов — «нужен event_id»	Дедупликация уже работает по идентификатору платежа/чека. `event_id` от PK был бы будущим улучшением, но не критическим пробелом.
P6 — Webhook каталога PK→ERP «блокер MVP»	На стороне PK действительно нет. Но у нас уже работают два механизма-страховки: полная ночная сверка каталога и поиск устаревших связок каждый час с автоматическим переcинком. То есть отсутствие webhook не парализует работу.

Блокеры, где карта говорит корректно:

P2 — нет API смен фискального накопителя. Подтверждено. PK говорит «касса сама следит за сменами», но риск «касса заблокировалась через 24 часа» остаётся — митигируется тем, что кассир закрывает смену вручную каждый день.
P7 — нет автоматизации онбординга личного кабинета. Подтверждено: 3 ручных шага. Для первых пилотных точек неважно, для масштабирования на 10+ точек — нужно.

4. Что у нас уже работает, но на карте не отражено

Эти элементы интеграции с PayKeeper реально работают, но на карте про них нет ни слова:

Возвраты, инициированные из нашего ERP — можно нажать «вернуть» в админке, и адаптер сам передаст команду в PK. Не только обратное направление (PK уведомил нас об отмене).
Пост-фактум фискализация наличных — если кассир принимает наличные через ERP, чек пробивается отдельной командой в PK. 54-ФЗ compliance.
Двухуровневый fallback каталога — ночной полный пересинк + ежечасный поиск устаревших связок. Полностью покрывает отсутствие webhook каталога от PK.
Полная синхронизация сотрудников из PK — забираем список кассиров из их ЛК, сопоставляем с нашими сотрудниками. Это закрытая отдельной спекой задача (BR 3.5).
SSE-канал admin → POS реального времени — карта упоминает один раз, но не раскрывает, что это реально работает: изменение в админке (стоп-лист, столы, заказ из агрегатора) долетает на POS-кассу за секунды, без обновления страницы.
Очередь команд с экспоненциальными повторами — если PK API недоступен, мы не теряем команды, а ретраим по схеме «10 сек → 30 сек → 2 мин → … → 24 часа», максимум 10 попыток.
Дополнительный pull-добор данных платежа — у PK в webhook нет RRN-кода и иногда нет номера карты, мы их подтягиваем отдельным запросом сразу после получения уведомления.
Логирование всех webhook’ов — для дебага сохраняем тело, заголовки, подпись, ошибки — полная история.

5. Что не отражено вообще ни в карте, ни в vault

Эти моменты важны для разговора с PayKeeper, но нигде не зафиксированы:

SLA на надёжность webhook от PK — сколько раз они ретраят, какая гарантия доставки, какие rate limits?
Политика хранения и retention webhook на их стороне — если наш сервис лежал час, что мы потеряем?
Sandbox PayKeeper общий с другим нашим проектом (Koala_TG_app) — переключать webhook между проектами без согласования нельзя, это операционный риск.
K10-F как касса PayKeeper, а не наша — карта показывает «Касса 3в1 (Unitodi K10-F)» как готовое железо, но не уточняет, что это устройство PayKeeper’а. Стороннему читателю не очевидно, что мы сами не делаем POS на K10 (ADR-014 закрыл это направление в апреле).

6. Открытые вопросы для CPO

Карте 3 недели, vault и код опередили её. Пересинхронизировать под актуальные BR 3.3/3.4/3.5 и POS Phase 2–5?
P3 (фискальные реквизиты) — терминология карты («fn_number/fd_number/fp_sign») и поля PK выглядят как разные вещи, но это одно и то же. Это ошибка переноса терминов или CPO действительно видела версию документации PK, где этих полей не было?
P4 (возвраты) — endpoint у нас есть, обработка есть. Подтвердить с PK: уведомления возвратов фактически приходят сейчас в проде или только в sandbox?
P1 (cross-device) — основной flow работает. Узкий вопрос: получаем ли мы отдельный сигнал «счёт доставлен на терминал»? Если нет — это малый риск, не «архитектурный».
P5 (список платежей) — реализация полная, на карте знак вопроса можно снимать.
P6 (webhook каталога) — наш fallback закрывает отсутствие. Переоценить приоритет: всё ещё «блокер MVP» или «на вырост»?
Netmonet — зелёный или жёлтый? По спеке — wave 2 заблокирована ожиданием их контракта.
3 фикс. роли в MVP на странице состава — переписать под текущую модель (permissions) или оставить как историческое?
Подели и Постинг в соцсети — идеи без задач или просто не успели завести в vault?
bo_kitchens — готово или частично? Карта противоречит сама себе.
bo_cust_list / bo_cust_groups — готово или в работе? Карта противоречит сама себе.
«5 минут до закрытия счёта» — откуда цифра? У нас в настройках другие тайминги, явного подтверждения PK в vault нет.
Customer Service — в карте обещаны баллы лояльности, кредитный лимит, история заказов. Их в Customer Service нет. Это сознательное проседание скоупа или забыли удалить со страницы?
Пост-фактум фискализация наличных через ERP — работает в коде, но на карте не упомянута. Скрытая фича или scope-проседание?

7. Что подтверждается без оговорок

Автосписание со склада при закрытии заказа — работает, заявка с восстановлением при возврате тоже.
Миграция кухонных станций (убрали поле is_default) — выполнена.
POS Phase 1 (планы столов + типы заказа) — соответствует коду.
External Menu Builder (BR 4.1) — TV-канал, JSON-экспорт, переопределение названия/цены, live stop-list — всё в коде.
Permission-based ролевая модель (BR 1.4.4) — применена в коде, enum жёстких ролей удалён.
AI Photo Studio как сервис (4 режима генерации) — реализован и работает на отдельном поддомене.
Стек KDS — Tauri 2 + React 18, Android APK + Windows.

Сводная таблица расхождений

Слой	Совпадает	Карта оптимистична	Карта пессимистична	Противоречит себе	Не упомянуто
MVP scope	Кухонные станции, External Menu, склад с авто-списанием, POS Phase 1, SSE-канал realtime, permissions	KDS «в проде» (нет релиза), Photo Studio integration «в проде», Customer Service «готов», 4 несуществующих агрегатора, Netmonet «зелёный»	—	3 фикс. роли (устарело)	Order Phases 2–5, импорт сотрудников из PK
Plan B Roadmap	v2-2 кухонный блок	bo_kitchens DONE, клиенты IN PROGRESS	—	bo_kitchens vs изменения 11.05	2 ИИ-агента без спек
Журнал изменений	ADR-020, миграция 037, POS Phase 1, BR 5.1, AI Photo Studio	клиенты «готово», Netmonet «разблокировано»	—	—	дубли ADR-021/022 в vault
PK блокеры	P2, P7 — корректны	P1 «архитектурный», P6 «блокер MVP» (есть fallback)	P3, P4, P5, capture, идемпотентность — уже реализовано	—	возвраты из ERP, пост-фактум чек, очередь команд, ночная сверка каталога, добор данных

ERP Platform Docs

Проводник

Аудит карты YUMA POS — 2026-05-12