ERP Test Base

2026-05-06-pos-coordination-playbook

время чтения ~4 мин.

Playbook — POS-сессия для F25, F27, F37, F40, F42

Цель: подтвердить что 5 POS-багов всё ещё актуальны (или найти что один починили походя), сразу собрать репро-данные для stage4.

Координация

  • Связь: чат
  • Стенд: один и тот же erp-test.nirbi.ru. Я через admin SPA, Александр через POS-desktop под PIN.
  • Перед стартом: Александр входит на POS под PIN 1234 (или 4321), я под admin@erp.local в админке.
  • Кому какие действия: каждый кейс ниже расписан как «🤖 Claude», «👤 Александр», «👀 Оба смотрят».

Темп

Каждая F — минут 5–10. Полная сессия ~45 мин.

Кейс 1 — F25 «Заказ исчезает с POS после оплаты» 🔴

Гипотеза: после оплаты заказ убирается из активного списка, кассир не видит его до выдачи.

Шаги:

  1. 👤 Александр: создаёт заказ на POS — 2 позиции, takeaway. Не оплачивает. Сообщает мне order_number.
  2. 🤖 Claude: GET /orders?status=new — нахожу заказ по номеру, фиксирую id, status, created_at.
  3. 👤 Александр: оплачивает картой/наличными.
  4. 👀 Оба: сразу после успешной оплаты:
    • Александр: что в активном списке POS? Заказ виден / исчез / висит «оплачен»?
    • Claude: GET /orders/{id} → status, paid_at, completed_at.
  5. 👤 Александр: пытается найти заказ через любые экраны POS (поиск, история, закрытые).

Что фиксируем: исчез ли заказ, через какие экраны его можно найти, что говорит API в момент исчезновения.

Done = баг открыт: заказ исчез сразу после оплаты И не найден через UI (только через admin или историю).

Кейс 2 — F27 «Нет UI кнопки отмены на POS» 🔴

Гипотеза: API POST /orders/{id}/cancel работает, но в POS UI нет соответствующей кнопки ни в одном статусе.

Шаги:

  1. 🤖 Claude: создаю в admin четыре заказа в разных статусах:
    • new — только создан
    • accepted — принят кухней
    • ready — готов
    • handed_over — выдан (В крайнем случае Александр сам создаёт через POS поочерёдно — но тогда дольше.)
  2. 👤 Александр: для каждого заказа открывает карточку на POS и ищет кнопку «Отменить» / «Отказаться» / красную опцию.
  3. 👀 Оба фиксируем по статусам:
    • new → есть/нет
    • accepted → есть/нет
    • ready → есть/нет
    • handed_over → есть/нет

Done = баг открыт: ни в одном статусе нет кнопки в UI POS. (API при этом отменит — POST /orders/{id}/cancel 200, проверим параллельно).

Кейс 3 — F37 «Нет журнала закрытых заказов смены» 🔴

Гипотеза: на POS есть только агрегированная аналитика (выручка, количество), но нет списка закрытых заказов смены, чтобы можно было найти конкретный по номеру/времени.

Шаги:

  1. 👤 Александр: проходит по всем меню POS — ищет:
    • «История заказов»
    • «Закрытые заказы»
    • «Журнал смены»
    • «Чеки»
    • Поиск заказа по номеру
  2. 👀 Оба: фиксируем что нашли. Если есть только аналитика (выручка/количество без детализации) — F37 подтверждён.

Done = баг открыт: нет ни одного экрана POS, где видно список закрытых заказов смены с возможностью открыть детали.

Кейс 4 — F40 «Menu-availability игнорирует окно» 🟡

Гипотеза: категории с настроенным окном доступности либо всегда скрыты, либо всегда видны — окно не учитывается.

Текущие настройки (получено через /admin/catalog/menu-availabilities):

  • Завтрак 07:00–12:00 → категория «Кофе» (fccb7038-...)
  • Десерты вторая половина дня 14:00–22:00 → категория «Десерты» (10c0f0e3-...)

Шаги:

  1. 🤖 Claude: проверяю текущее время на стенде через GET /api/v1/health или ответ заголовка. Например, сейчас 12:55 МСК.
    • Кофе должна скрываться (вышла из окна 07–12)
    • Десерты должны скрываться (ещё не начались 14–22)
  2. 👤 Александр: открывает на POS список категорий — сообщает видны ли «Кофе» и «Десерты» прямо сейчас.
  3. 🤖 Claude: меняю окно, например для «Завтрак» ставлю 00:00–23:59 → должно стать видимо во всё время.
  4. 👤 Александр: обновляет POS (если нужно — pull-to-refresh / релогин), смотрит появилась ли «Кофе».
  5. 🤖 Claude: возвращаю окно как было.

Done = баг открыт: видимость не меняется при изменении окна (или категория скрыта всегда).

Кейс 5 — F42 «Нет подсказки max_amount на POS» 🟢

Гипотеза: при выборе модификатора с max_amount > 1 UI POS не показывает кассиру лимит, кассир ткнёт лишнее → ошибка.

Шаги:

  1. 🤖 Claude: нахожу/создаю товар с модификатором имеющим max_amount: 3 (например, «Соусы», макс 3 шт).
  2. 👤 Александр: добавляет этот товар на POS, открывает выбор опций.
  3. 👀 Оба: видна ли где-то подсказка «макс 3» / «осталось N» / счётчик 0/3?
  4. 👤 Александр: пробует тыкнуть 4 раза на одну опцию или 3+1 на разные. Что показывает UI?

Done = баг открыт: нет визуальной подсказки max_amount, юзер не знает лимит до тыка.

Что я подготовлю заранее

Чтобы не тратить сессию на setup:

  • Кейс 2 (F27): 4 заказа в разных статусах. Прокачать через admin — POST /orders/{id}/accept, POST /orders/{id}/ready, POST /orders/{id}/handover.
  • Кейс 5 (F42): убедиться что есть товар с модификатором max_amount=3. Если нет — создать.
  • Кейс 4 (F40): знать тек.время стенда + готовить swap-окна для теста.

Чек-лист готовности

Перед стартом подтверждаем:

  • Александр на POS под PIN, видит товары
  • Я залогинен в админке (admin@erp.local)
  • У ТТ Арбат есть видимые товары для POS
  • Прейскурант default привязан хотя бы неявно
  • PayKeeper отвечает (для F25 — оплата нужна)

Куда писать находки

  • В рамках сессии — обмениваемся в чате, я в реальном времени фиксирую observations.
  • После сессии — оформляю в sessions/2026-05-06-pos.md + сразу перехожу к stage4.

Вид графа

Обратные ссылки