ERP Test Base

2026-05-07-waiter-table-walkthrough

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

2026-05-07 — Прогон сценария «официант ↔ стол» перед демо

⏸️ ЗАМОРОЖЕНА 2026-05-12. Регрессия F66-F76 не доведена до конца. Причина: переключились на тестирование прод-стенда admin.nirbi.ru без интеграции POS/KDS. Вернёмся к этой сессии когда снова дойдём до POS/KDS флоу. Контекст состояния — см. memory project_pos_kds_regression_2026_05_07.md.

Стенд: demo3@nirbi.ru / <password — см. private/creds.md> (свежая франшиза для проверки полного потока с нуля) Контекст: перед демо клиенту прогоняли сценарий «менеджер назначает официанта на стол → официант пробивает заказ → закрытие смены». Прогон через web-POS (erp-test.nirbi.ru/pos/) и веб-админку (/admin/).

В рамках этой сессии создан baseline-сетап demo3:

  • 4 категории: Салаты, Супы, Горячее, Закуски (плюс существовавшие Напитки, Бургеры)
  • 15 товаров с ценами через прейскурант
  • 7 кастомных ролей: Менеджер, Кассир, Официант, Повар, Курьер, Бариста, Кладовщик
  • 8 сотрудников с PIN, привязанных к ТТ «Демо ТТ 1»
  • demo3 Owner: PIN 8888, привязан к ТТ «Демо ТТ 1»

🐛 BUG — пользовательские проблемы для починки

F66 — Текст ошибки «Доступно только менеджеру ТТ» — у пользователя, который уже является менеджером

Severity: 🟡 Major Status: open Зона: pos/tables

Что: при попытке сменить официанта на столе, если у роли пользователя нет нужного permission’а, POS показывает сообщение «Действие доступно только менеджеру ТТ». На практике это может увидеть пользователь, который и есть «Менеджер» (по названию роли) — реально проверка идёт по конкретному permission’у pos.settings.edit, а не по имени роли.

Влияние: пользователь читает «нужна роль менеджера», смотрит на свою — там уже «Менеджер», решает что приложение сломано, идёт в техподдержку.

Воспроизведение:

  1. Создать кастомную роль «Менеджер» с типичным набором POS-прав, но без pos.settings.edit
  2. Назначить её сотруднику
  3. Войти в POS под этим сотрудником, открыть стол с активным заказом
  4. Нажать «Сменить официанта» → выбрать любого
  5. Видим ошибку «Действие доступно только менеджеру ТТ»

Ожидание: текст ошибки честно говорит, какого права не хватает («Недостаточно прав для управления столами») или кому обратиться, но не вводит в заблуждение про «роль менеджера».

Факт: misleading сообщение, привязанное к фиксированной формулировке роли.

Где смотреть:

  • pos-bff handler для PATCH /pos/api/v1/pos/tables/{id}/waiter — error response при недостатке прав
  • Заменить код MANAGER_REQUIRED на INSUFFICIENT_PERMISSIONS с указанием требуемого permission’а
  • Связано с PROPOSAL-1 (нейминг permission’а — отдельный вопрос)

F67 — Имя официанта не появляется автоматически нигде (ни в POS, ни на KDS)

Severity: 🔴 Critical Status: open Зона: pos/tables, orders/lifecycle, kds

Что: официант на POS выбирает свободный стол → «Открыть заказ» → пробивает позиции → отправляет на кухню. На схеме зала стол меняет цвет на «Занят», но в карточке стола имя официанта не появляется (поле «Кто обслуживает» пустое). На странице заказа №007 в POS — «ОФИЦИАНТ: не назначен». На KDS у заказа имени официанта тоже нет нигде.

Чтобы появилось имя — кто-то должен зайти в карточку стола в POS и явно «Назначить официанта». На рабочей точке этим вручную никто не занимается.

Влияние:

  • Менеджер на схеме зала не видит, кто из официантов работает за каким столом → не может координировать смену
  • Если нужно передать стол другому официанту — непонятно, у кого забирать
  • Отчёты по официантам строить не на чем (см. PROPOSAL-2)

Воспроизведение:

  1. Войти в POS как официант (роль с pos.access + pos.orders.create)
  2. Открыть смену
  3. На карте зала выбрать свободный стол → «Открыть заказ»
  4. Добавить позиции, отправить «На кухню»
  5. Вернуться на карту зала, открыть карточку этого стола
  6. Видим: статус «Занят», заказ привязан, но имени официанта нет (поле пустое)
  7. Открыть страницу заказа /pos/orders/{id} — поле «ОФИЦИАНТ: не назначен»
  8. Открыть KDS под поваром — у заказа имени официанта тоже нет

Ожидание: при создании заказа за столом тот, кто его открыл, автоматически назначается на стол как обслуживающий официант. Имя видно везде — в карточке стола, на странице заказа, на KDS у повара.

Факт: связь стол ↔ официант устанавливается только вручную, авто-привязки нет; имя нигде не показывается.

Где смотреть:

  • pos-bff POST /pos/api/v1/pos/orders/open — при создании заказа с table_id устанавливать tables.current_waiter_id = <текущий пользователь>, если он пуст
  • БД: поле tables.current_waiter_id уже есть, но не пишется при открытии заказа
  • KDS-сборка: проверить пробрасывание waiter-name в карточку заказа (если planned, но не передаётся)
  • Связано с PROPOSAL-2 (надо ли вообще хранить waiter на столе или дублировать на заказе)

F69 — Z-отчёт можно сформировать без предупреждения о висящих неоплаченных заказах

Severity: 🔴 Critical Status: open Зона: pos/shift, orders/lifecycle

Что: кассир в конце дня нажимает «Закрыть смену» → видит экран Z-отчёта с «Продажи: 0 шт · 0,00 ₽» → жмёт «Сформировать Z-отчёт» → смена закрыта. Но в реальности на ТТ за столом висит непробитый/неоплаченный заказ на 670 ₽ (status accepted, paid_at: null). Стол остаётся occupied.

Влияние:

  • На следующий день новый кассир видит «занятый» стол с непонятным заказом из вчера, не знает что с ним делать
  • Бухгалтерия видит «по факту еду съели» (в KDS заказ был), но в выручке его нет
  • Кассир уходит домой, не подозревая что что-то не так

Воспроизведение:

  1. Открыть смену в POS
  2. За столом открыть заказ, отправить на кухню (но не оплачивать)
  3. Жмём «Закрыть смену»
  4. На экране Z-отчёта — продажи 0₽, никаких предупреждений
  5. «Сформировать Z-отчёт» → смена закрыта
  6. Через API проверить: заказ всё ещё status: accepted, paid_at: null, стол status: occupied

Ожидание: перед закрытием смены — блокирующее предупреждение «На ТТ N открытых заказов на сумму M ₽. Закройте или отмените их перед закрытием смены». Желательно — показать список столов/заказов.

Факт: смена закрывается беспрепятственно, заказы остаются висящими.

Где смотреть:

  • pos-bff endpoint закрытия смены — добавить проверку открытых заказов (status IN (new, accepted, ready) && store_id)
  • Экран /pos/shift/close — добавить блок «Открытые заказы» перед кнопкой Z-отчёта
  • Связано с PROPOSAL-3 (полный сценарий передачи смены)

F70 — В POS «Назначить официанта» показывает всех сотрудников с POS-доступом, не только официантов

Severity: 🟡 Major Status: open Зона: pos/tables, auth-rbac

Что: менеджер на POS открывает стол → «Назначить официанта» → видит 8 человек: Demo3 Owner (Администратор), Анна Админова (Админ), Борис Баристов (Бариста), Иван Иванов (Админ), Кира Кассирова (Кассир), Михаил Менеджеров (Менеджер), Олег Официантов (Официант), Пётр Поваров (Повар). Должны быть только сотрудники с ролью «Официант».

Влияние:

  • Менеджер легко тыкает не туда (особенно при схожих именах) — назначает повара / бариста / админа на стол
  • Дальше у этого «официанта» появляются столы в его POS-сессии, что вообще ему не нужно
  • Если по этому потом строится отчёт — в отчёте «продажи официанта» появляется повар

Воспроизведение:

  1. Войти в POS как менеджер с pos.settings.edit
  2. Открыть любой стол → «Назначить официанта»
  3. Видим список из всех сотрудников с pos.access, без фильтрации по типу роли

Ожидание: список содержит только сотрудников с ролью «Официант» (или с конкретным permission pos.orders.create без pos.shift.* — в зависимости от того, как формализовать «официант»).

Факт: включаются все, кто может зайти в POS.

Где смотреть:

  • pos-bff endpoint списка сотрудников для модала «Назначить официанта»
  • Фильтрация: либо по role-id с конкретной ролью «Официант» (если решено хранить как системную), либо по permission’у уровня официанта
  • Связано с PROPOSAL-1 (вопрос — где определять «кто официант»: в коде, в роли, в флаге сотрудника)

F71 — Резерв стола в админке открывает нативный браузерный prompt() с одним полем

Severity: 🟢 Minor (зависит от PROPOSAL-1 — может вообще не нужен в админке) Status: open Зона: admin/stores/tables

Что: в админке Карточка ТТ → Столы → выбрать свободный стол → "Забронировать" открывается стандартный браузерный диалог с подписью «Примечание брони (кто, на сколько)» и одной строкой ввода. Без полей гость / время / число человек / телефон. Без UI приложения.

Влияние:

  • Выглядит как баг сайта, не как функция приложения
  • Пользователь в недоумении что вводить в одно поле
  • Невозможно сохранить структурированную информацию (имя, телефон, время начала/окончания)

Воспроизведение:

  1. Войти в админку как demo3@nirbi.ru
  2. Открыть карточку ТТ → вкладка «Столы»
  3. Кликнуть на свободный стол → в правой панели «Забронировать»
  4. Видим нативный browser prompt() (не модал приложения)

Ожидание: кастомный модал приложения с полями: гость, телефон, число человек, время начала, длительность.

Факт: заглушка через prompt().

Где смотреть:

  • Admin SPA, компонент управления столами в карточке ТТ
  • ВАЖНО: до решения по PROPOSAL-1 (оставлять ли оперативные действия со столами в админке вообще) — не дорабатывать резерв здесь. Если решение «убрать оперативку из админки» — баг закрывается удалением кнопки.

F72 — KDS показывает «Стол FB» вместо номера стола №26

Severity: 🟡 Major Status: open Зона: kds, orders/lifecycle

Что: на экране KDS у заказа в подписи стола отображается FB — это последние 2 символа table_id (67e0aa8e-99b9-4c1d-acbf-b311d0079cfb), а не реальный номер стола (№26). Повар видит «Стол FB» и не понимает, за каким столом готовить.

Влияние:

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

Воспроизведение:

  1. Создать в POS заказ за столом №26 (или любым с реальным номером)
  2. Отправить на кухню
  3. Открыть KDS под поваром
  4. Видим в подписи заказа «Стол FB», а не «Стол №26»

Ожидание: на KDS подпись стола = реальный номер стола (например «Стол №26» или «#26»).

Факт: показываются последние 2 hex-символа UUID.

Где смотреть:

  • KDS-сборка / контракт pos-bff → KDS для поля стола: вместо UUID-короткой формы передавать tables.number (или label если задан)
  • Order-service: убедиться что в WebSocket/REST для KDS отдаётся реальный номер стола, а не id

F73 — Таймер на KDS показывает «через 114 мин» для блюда со временем готовки 10

Severity: 🟡 Major Status: open Зона: kds, catalog/products

Что: на главном экране KDS у карточки заказа отображается «через 114 мин» (время идёт на убывание). Для блюда с заявленным временем приготовления 10 (минут? секунд?) это нерелевантное число — повар не понимает, к чему таймер.

Похоже, KDS берёт время не из assembly_time блюда, а из yellow_threshold_minutes / red_threshold_minutes станции «Кухня» (default ~120 минут) — отсчитывает «до жёлтого предупреждения».

Влияние:

  • Повар видит «осталось 114 мин» — приоритизирует другие заказы как «более срочные»
  • Нет связи с реальным assembly_time блюда
  • В реальной кухне таймер должен отражать «успеваешь / не успеваешь приготовить» по конкретному блюду

Связано:

  • F61 (stage4) — единицы assembly_time без явного unit (UI «N мин», в БД _seconds). Если KDS пытается читать assembly_time и трактует как минуты, возможно это часть проблемы.

Воспроизведение:

  1. Создать товар с assembly_time = 10 (в админке поле «Время приготовления (мин)»)
  2. Заказать его в POS
  3. Открыть KDS
  4. Видим таймер «через 114 мин» (или близкое — порог станции по умолчанию)

Ожидание: таймер отражает оставшееся время приготовления конкретного блюда (от assembly_time), либо подпись чётко говорит «до жёлтого предупреждения станции», а не выглядит как срок готовки.

Факт: таймер привязан к порогам станции, не к блюду. Подпись неоднозначна.

Где смотреть:

  • KDS-сборка: что именно показывается в этом таймере, какое поле
  • Связка kitchen_stations.yellow_threshold_minutes ↔ KDS UI
  • Зависит от решения по F61 (в каких единицах хранится assembly_time)

F74 — На схеме зала нет визуальной индикации «готово к выдаче» — стол всегда красный пока занят

Severity: 🟡 Major Status: open Зона: pos/tables, orders/lifecycle

Что: на схеме зала в POS используется только 2 цвета: зелёный = свободен, красный = занят. Никакого 3-го цвета (например жёлтого) для «есть готовые позиции, нужно выдать клиенту» нет. Повар на KDS закончил приготовление — стол на схеме зала остаётся таким же красным, как когда блюдо ещё готовилось.

Влияние:

  • Официант, обходя зал, не видит на каком столе уже готово к выдаче — приходится открывать каждый красный стол по очереди
  • Готовое блюдо стоит на раздаче и остывает, пока официант не догадается проверить
  • Снижается качество обслуживания и увеличивается время выдачи

Воспроизведение:

  1. Открыть заказ за столом, отправить на кухню
  2. На схеме зала видим стол красный
  3. Повар на KDS отметил все позиции «Готово»
  4. Возвращаемся на схему зала — стол всё ещё красный, никакой индикации «готово»

Ожидание: когда у заказа появляются готовые позиции (или все готовы) — стол подсвечивается отдельным цветом (жёлтый / мигающий / иконка). Официант видит на обзоре, какой стол требует внимания.

Факт: только 2-цветная схема (зелёный/красный), 3-го состояния нет.

Где смотреть:

  • POS схема зала — компонент рендера стола
  • Логика цвета: учитывать current_order_id + kitchen_status всех позиций (если хотя бы одна ready и не выданы — другой цвет)
  • Связано с F51 (вкладка «Готовы» смешивает) и PROPOSAL-5 (явная фаза handover)

F75 — Заказ автоматически становится «Выдан» после готовности кухни — без действия официанта

Severity: 🔴 Critical Status: open Зона: orders/lifecycle, pos/tables

Что: когда повар на KDS отмечает «Готово» на последней кухонной позиции заказа, в POS статус заказа сразу становится «Выдан». Никто не нажимал «Выдать клиенту», блюдо не унесли на стол гостя — а в системе оно уже «вручено». При этом заказ ещё не оплачен (висит «Ожидает оплаты на Касса 3в1»).

Влияние:

  • Audit trail неверный: в БД написано «выдан» в момент готовности, не в момент реального handover
  • Если блюдо потерялось на раздаче или клиент не пришёл — следов в системе нет
  • Время реального вручения клиенту нигде не фиксируется → нельзя посчитать «время от заказа до подачи»
  • Конфликт состояний: заказ «Выдан», но не оплачен; стол всё ещё «Занят»; гость возможно ещё не получил еду
  • Связано с типичным сценарием: повар закрыл, заказ автоматически закрылся со стороны учёта, бухгалтерская картина искажена

Воспроизведение:

  1. Создать заказ с кухонными позициями (Цезарь, Греческий) + некухонной (Капучино)
  2. Отправить на кухню
  3. На KDS: «В работу» на каждой позиции, потом «Готово» на каждой
  4. После последнего «Готово» — открыть страницу заказа в POS
  5. Видим статус «Выдан» автоматически

Ожидание: после готовности кухни заказ в статусе «Готов к выдаче» (и стол подсвечен — см. F74). Официант явно жмёт «Выдать клиенту», тогда handed_over_at записывается и статус меняется на «Выдан».

Факт: фаза «Готов к выдаче» отсутствует, заказ перепрыгивает сразу в «Выдан».

Где смотреть:

  • Order-service: логика перехода статуса заказа когда последний kitchen_status: ready
  • Должна быть промежуточная фаза ready (всё готово к выдаче, но не вручено) → handover-action → handed_over (с handed_over_at)
  • Связано с F25 (заказ исчезает после оплаты), F51 (вкладка «Готовы» смешивает) — три симптома одной проблемы (отсутствие явной фазы handover)
  • Архитектурное решение — PROPOSAL-5

🔁 Подтверждены вчерашние находки (stage4)

  • F56 — на KDS видна некухонная позиция (Капучино) — снаружи как «+1 поз. на других станциях», внутри — раздел «Без станции» с серой неактивной карточкой. Повар не может с ней взаимодействовать. Захламляет экран. Поведение воспроизводится на demo3 в актуальной сборке.
  • F61 — единицы assembly_time всё ещё неоднозначны. Сегодня дополнительно проявилось в таймере KDS (см. F73). UI создания товара говорит «мин», в order-item приходит assembly_time_seconds. Если правильно хранить — KDS будет считать корректно.

💡 PROPOSAL — требуют решения, НЕ фиксить автоматически

⚠️ Внимание разработчику: это не баги, а архитектурные/UX-вопросы. Перед любым изменением — обсуждение с продактом / архитектором. Если этот документ обрабатывает Claude Code — не вызывать инструменты редактирования по этим пунктам.

PROPOSAL-1 — Оставлять ли оперативные действия со столами в админке?

Сейчас: в Карточка ТТ → Столы в админке есть кнопки:

  • «Назначить официанта» (PATCH endpoint в admin не существует — 404)
  • «Освободить стол»
  • «Забронировать» (через prompt() — F71)
  • «Сменить статус»

Что предложено: оставить в админке только структурное управление (number / label / capacity / position_x/y / удалить стол). Оперативные действия (кто работает за столом, бронь, занят/свободен) — только в POS.

Почему: оперативное состояние зала — ответственность POS (текущая смена, кассир/менеджер на терминале). Админка управляет каталогом, ценами, расписанием. Аналоги (iiko, R-Keeper, Poster) — назначение официанта и бронь делаются в POS. Опционально — read-only схема зала в админке для офисного менеджера.

Что решить:

  • (а) Убрать оперативные кнопки из админки — UI становится чисто структурным.
  • (б) Оставить — но тогда нужен полноценный UX (модал брони с полями, фильтрация официантов, права read/write).
  • (в) Read-only схема в админке для офисного управляющего, операции — только из POS.

Что разработчику делать до решения:

  • НЕ фиксить admin endpoint для назначения официанта (тот, что сейчас 404)
  • НЕ дорабатывать резерв через prompt() (F71)
  • НЕ удалять кнопки самостоятельно

Связанные находки: F66 (нейминг permission), F71 (prompt резерв)

PROPOSAL-2 — Как хранить связь «заказ ↔ официант» для отчётности

Сейчас: в схеме orders нет поля waiter_id. Есть только:

  • created_by — кто создал заказ (может быть кассир, не обязательно официант)
  • accepted_by — кто принял
  • tables.current_waiter_id — кто сейчас за столом (живёт только пока стол занят)

При смене официанта посередине обеда / закрытии стола — информация о том, кто обслуживал этот заказ, теряется.

Что предложено варианты:

  • (а) Добавить orders.waiter_id (snapshot на момент создания/закрытия заказа)
  • (б) Вести отдельную таблицу истории order_waiter_assignments — кто когда обслуживал
  • (в) Ограничиться created_by — кто открыл, тому и идёт продажа (даже если стол передавали)

Что решить:

  • Какая модель отчёта «продажи по официантам»? Один на заказ или несколько с распределением?
  • Влияет на формулы зарплаты, расчёт чаевых, KPI официантов
  • Если бизнес-кейс «передача стола между официантами» важен — нужна история (б)
  • Если упрощённый формат «кто открыл = тот и работал» — достаточно (в)

Что разработчику делать до решения:

  • НЕ добавлять поле waiter_id в orders без согласования
  • НЕ менять источник для отчёта по официантам (если он есть)

Связанные находки: F67 (auto-link официанта на стол)

PROPOSAL-3 — Что делать с открытыми заказами/столами при закрытии смены

Сейчас: смена закрывается беспрепятственно (см. F69). Открытые заказы остаются accepted, paid_at: null, столы остаются occupied. Передача между сменами не предусмотрена.

Что предложено варианты:

  • (а) Минимум: блокирующее предупреждение «N открытых заказов» (это покрывает F69)
  • (б) Принудительно закрывать заказы при закрытии смены (с пометкой «закрыт принудительно»)
  • (в) Передача заказов на следующую смену (новый кассир принимает «дежурство»)
  • (г) В выходной день (последняя смена) — особый сценарий: нужно ли что-то особое?

Что решить:

  • Какой бизнес-флоу передачи смены в реальной кофейне/ресторане у клиента?
  • Должен ли уходящий кассир обязательно закрыть/отменить все заказы перед уходом?
  • Или приходящий кассир принимает open orders как часть приёма дежурства?

Что разработчику делать до решения:

  • Минимум — реализовать F69 (блокирующее предупреждение)
  • Большие изменения (автозакрытие, передача) — НЕ делать без решения продукта

Связанные находки: F69

PROPOSAL-4 — Резерв стола: модель и UX

Сейчас: резерв реализован минимально — tables.reserved_note (одна строка) + reserved_until. UI в админке через prompt() (см. F71). UX в POS не проверен.

Что предложено: полноценная модель резерва, если функция нужна:

  • Поля: гость (имя или ссылка на customer), телефон, число человек, время начала, длительность, статус (создан / клиент пришёл / no-show / отменён)
  • UI: кастомный модал, не prompt()
  • Уведомления: оповещать назначенного официанта при наступлении времени резерва
  • Пересечения: блокировать резерв на занятое время / пересекающиеся столы
  • Привязка к CRM: автоматически создавать запись клиента
  • Перенос: возможность отодвинуть время

Что решить:

  • Нужен ли резерв на этапе MVP вообще? (Может быть out-of-scope для первого релиза)
  • Если нужен — какой минимальный функционал?
  • Где живёт UI: админка, POS, оба?
  • Связь с CRM (если она есть на этом этапе)

Что разработчику делать до решения:

  • НЕ дорабатывать prompt() в админке (F71)
  • НЕ расширять схему tables полями резерва без обсуждения

PROPOSAL-5 — Явная фаза «Готов к выдаче → Выдан клиенту» в lifecycle заказа

Сейчас: в lifecycle заказа нет явной фазы handover между «готов» и «закрыт». Симптомы во многих местах:

  • F75 (сегодня) — заказ автоматически становится «Выдан» когда повар закрыл кухню; никто его не выдавал
  • F25 (stage4) — после оплаты заказ исчезает с активного списка POS, найти можно только в «Возвратах»
  • F51 (stage4) — вкладка «Готовы» на POS смешивает «готов к выдаче» и «уже закрыт»
  • F74 (сегодня) — на схеме зала нет визуальной индикации «готово к выдаче», стол остаётся красным

Все четыре — симптомы одной архитектурной проблемы: фазы handover в системе нет.

Что предложено: ввести явную фазу ready (всё готово к выдаче, не унесено) и явное действие «Выдать клиенту»:

  • Поле orders.handed_over_at: timestamp NULL (сейчас, видимо, заполняется неявно или нет)
  • Статус ready после готовности всех кухонных позиций — заказ не закрывается, но и не «выдан»
  • Кнопка «Выдать клиенту» на POS (карточка заказа / на столе) — переводит в handed_over (записывает handed_over_at)
  • На схеме зала — отдельный цвет/индикатор для «готов к выдаче» (фикс F74)
  • Закрытие заказа (closed) — после оплаты И после handover, не одного из них

Что решить:

  • Принять архитектурно: добавить фазу ready → handed_over → closed?
  • Или: заказ закрывается строго оплатой (handover отдельно учитывать только метрикой)?
  • Когда происходит closed — после оплаты ИЛИ после handover ИЛИ оба обязательно?
  • В случае delivery (курьер) — фаза in_delivery уже есть, не сломать совместимость
  • Влияние на отчётность: «время от заказа до подачи», «время простоя на раздаче»

Что разработчику делать до решения:

  • НЕ менять lifecycle заказа точечно (например «не переводить в Выдан автоматически» — это локально решит F75, но не закроет F25/F51/F74 системно)
  • НЕ добавлять кнопку «Выдать клиенту» в POS без понимания общей модели
  • F74 (цвет на схеме зала) — зависит от наличия фазы ready. До решения по этому PROPOSAL — не вводить новый цвет

Связанные находки: F25, F51, F74, F75

Связи между находками

  • F67 + PROPOSAL-2 — оба про связь «официант ↔ заказ». F67 решается локально (auto-link при открытии), но PROPOSAL-2 даёт правильную модель данных надолго.
  • F69 + PROPOSAL-3 — F69 минимальный фикс «не дать закрыть смену с висящим заказом», PROPOSAL-3 — полный сценарий передачи смены.
  • F71 + PROPOSAL-1 + PROPOSAL-4 — резерв в админке. F71 закрывается либо удалением UI (PROPOSAL-1), либо переделкой (PROPOSAL-4).
  • F66 + PROPOSAL-1 — F66 это плохой текст ошибки. Если PROPOSAL-1 решит «оставить кнопки в админке + перенести на правильный endpoint» — текст ошибки всё равно надо чинить.
  • F25 + F51 + F74 + F75 + PROPOSAL-5 — все про отсутствующую фазу handover. Системное решение в PROPOSAL-5, локальные симптомы фиксить только в рамках общей картины.
  • F73 + F61 — F73 (таймер 114 мин на KDS) тянет проблему из F61 (единицы assembly_time). Если решить F61 — таймер на KDS встанет ровно.

Что Александр (POS-desktop) проверит после фиксов

Когда придёт сборка с фиксами F67/F69/F70/F72/F73/F74:

  • Открыть стол как официант → проверить что имя официанта появилось на столе автоматически (POS + KDS) (F67)
  • Закрыть смену с открытым заказом — должно блокировать с предупреждением (F69)
  • Назначить официанта на стол — в выпадашке только официанты (F70)
  • На KDS у заказа подпись стола = реальный номер, не двухсимвольный код (F72)
  • На KDS таймер = реальное время приготовления блюда, не порог станции (F73)
  • На схеме зала — стол меняет цвет когда позиции готовы (F74, зависит от PROPOSAL-5)

Для F75 — отдельный PROPOSAL-5 (архитектурное решение), Александр проверит после когда модель определена.

PROPOSAL’ы — после продуктового решения, отдельный цикл.

Источники

  • Стенд: https://erp-test.nirbi.ru/admin/ и https://erp-test.nirbi.ru/pos/
  • Аккаунт: demo3@nirbi.ru / <password — см. private/creds.md> (свежая франшиза, отдельная от admin@erp.local)
  • Связанные документы: overview, lifecycle, orders, index
  • Канон формата багов: BUGS-FOR-DEV-stage4.md

Вид графа

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