ERP Test Base

BUGS-FOR-DEV-stage5

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

Багфиксы — стадия 5 (2026-05-07)

Продолжение серии stage1/2/3/4. Тема дня — прогон сценария «официант → стол → кухня → выдача» перед демо клиенту. Прогон через web-POS + KDS на ПК (нативная сборка) + админку.

Стенд: https://erp-test.nirbi.ru/admin/ и /pos/. Аккаунт: demo3@nirbi.ru / <password — см. private/creds.md> (отдельная свежая франшиза для онбординга с нуля). KDS — нативное desktop-приложение на ПК.

⚠️ КОНТРАКТ ЧТЕНИЯ — ВАЖНО

Документ содержит два вида находок, не путайте:

  • 🐛 BUG — есть однозначная сломанная функциональность, известно «что починить». Можно фиксить.
  • 💡 PROPOSAL — архитектурный/UX-вопрос, требует продуктового решения. Перед любым изменением — обсуждение с продактом / архитектором. НЕ ФИКСИТЬ АВТОМАТИЧЕСКИ.

Если этот документ обрабатывает Claude Code — по разделу PROPOSAL не вызывайте инструменты редактирования, только покажите вопросы пользователю.

📋 Сводка найденного

🐛 BUG (фиксить):

IDSeverityКраткоЗона
F66🟡 MajorТекст «Только менеджеру ТТ» — пользователю, который и есть менеджер. Misleadingpos/tables
F67🔴 CriticalИмя официанта не появляется автоматически нигде (POS-карточка стола, страница заказа, KDS)pos/tables, orders/lifecycle, kds
F69🔴 CriticalZ-отчёт смены формируется без предупреждения о висящих неоплаченных заказахpos/shift, orders/lifecycle
F70🟡 MajorВ POS «Назначить официанта» показывает всех сотрудников с pos.access, не только официантовpos/tables, auth-rbac
F71🟢 MinorРезерв стола в админке через нативный prompt(). Зависит от PROPOSAL-1admin/stores/tables
F72🟡 MajorНа KDS подпись стола = последние 2 hex-символа table_id (FB), а не реальный номер №26kds, orders/lifecycle
F73🟡 MajorТаймер на KDS «через 114 мин» для блюда со временем приготовления 10 — нерелевантно. Тянется из порогов станции, не из assembly_time. Связано с F61kds, catalog/products
F74🟡 MajorНа схеме зала только 2 цвета (зелёный/красный). Нет визуальной индикации «готово к выдаче». Зависит от PROPOSAL-5pos/tables, orders/lifecycle
F75🔴 CriticalЗаказ автоматически становится «Выдан» когда повар закрыл кухонные позиции. Никто блюдо не выдавал. Связано с F25, F51orders/lifecycle, pos/tables

🔁 Подтверждения вчерашних находок (без новых ID):

  • F56 — на KDS видна некухонная позиция (Капучино) — снаружи как «+1 поз. на других станциях», внутри раздел «Без станции» с серой неактивной карточкой. Воспроизводится в актуальной сборке.
  • F61 — единицы assembly_time без явного unit. Сегодня дополнительно проявилось в таймере на KDS (см. F73).

💡 PROPOSAL (требуют решения, НЕ фиксить):

IDКраткоСвязанные BUG
P1Оставлять ли оперативные действия со столами в админке?F66, F71
P2Как хранить связь «заказ ↔ официант» для отчётностиF67
P3Что делать с открытыми заказами/столами при закрытии сменыF69
P4Резерв стола: модель и UXF71
P5Явная фаза «Готов к выдаче → Выдан клиенту» в lifecycle заказаF25, F51, F74, F75

🔴 Critical

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

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

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

Эффект: менеджер на схеме зала не видит, кто из официантов работает за каким столом → не может координировать смену. Передача стола другому официанту — непонятно, у кого забирать. Отчёты по официантам строить не на чем (см. P2). Повар на KDS не знает, кому позвонить если возник вопрос по блюду.

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

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

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

Кассир в конце дня жмёт «Закрыть смену» → видит экран 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

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

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

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

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

Эффект:

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

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

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

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

  • Order-service: логика перехода статуса заказа когда последний kitchen_status: ready
  • Не фиксить точечно «не переводить в Выдан автоматически». Это локально решит F75, но не закроет F25 / F51 / F74 системно — это архитектурный вопрос (PROPOSAL-5): нужна явная фаза ready → handover → closed

🟡 Major

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

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

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

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

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

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

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

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

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

Эффект: менеджер легко тыкает не туда (особенно при схожих именах) — назначает повара / бариста / админа на стол. У этого «официанта» появляются столы в его POS-сессии. Если по этому потом строится отчёт — в отчёте «продажи официанта» появляется повар.

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

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

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

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

Эффект:

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

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

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

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

На главном экране 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 и трактует не в тех единицах — это часть проблемы.

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

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

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

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

Эффект:

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

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

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

🟢 Minor

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

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

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

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

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

💡 PROPOSAL — требуют решения, НЕ ФИКСИТЬ АВТОМАТИЧЕСКИ

⚠️ Этот раздел — НЕ задачи на фикс. Это вопросы к продакту/архитектору. Если читаете через 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)
  • НЕ удалять кнопки самостоятельно

**Также по неймингу permission'ов:** сейчас pos.settings.editотвечает за управление столами. Это неинтуитивно. Стоит ввести отдельныйpos.tables.manageилиtables.assign_waiter` и обновить RBAC-матрицу. Но это часть общего дизайна прав — обсуждать вместе.

Связанные BUG: F66, F70, F71

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 без согласования
  • НЕ менять источник для отчёта по официантам (если он есть)

Связанные BUG: F67

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

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

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

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

Что решить:

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

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

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

Связанные BUG: 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 полями резерва без обсуждения

Связанные BUG: F71

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. До решения — не вводить новый цвет

Связанные BUG: F25, F51, F74, F75

🔗 Связи между находками (важно для приоритизации)

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

🎯 Приоритизация для разраба

Если время ограничено, начинать с самого болезненного:

  1. F75 — заказы помечаются как «Выдан» без выдачи (audit trail сломан, бухгалтерия искажена). НО — это PROPOSAL-5, нужно сначала продуктовое решение.
  2. F69 — закрытие смены теряет заказы. Минимальный фикс (предупреждение) можно делать прямо сейчас.
  3. F67 — имя официанта нигде не видно. Локальный фикс (auto-link) можно делать сейчас, не дожидаясь PROPOSAL-2.
  4. F72 — на KDS подпись стола нечитаемая. Чисто фронтовый фикс.
  5. F66, F70 — фиксить вместе с архитектурным решением по PROPOSAL-1.

PROPOSAL’ы 1-5 — выносить на встречу с продактом/архитектором, не пилить вслепую.

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

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

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

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

📂 Источники

  • Сессия: sessions/2026-05-07-waiter-table-walkthrough.md
  • Findings index: findings.md (F66, F67, F69-F75 добавлены сегодня)
  • Прошлые стадии: archive/BUGS-FOR-DEV-stage{1,2,3,4}.md
  • Зоны: zones/stores/overview.md, zones/orders/lifecycle.md, zones/pos/orders.md, zones/kds/overview.md, zones/auth-rbac/index.md
  • Стенд: https://erp-test.nirbi.ru/admin/ и /pos/. Аккаунт demo3@nirbi.ru / <password — см. private/creds.md> (отдельная тестовая франшиза).

Вид графа