ERP Test Base

Интеграция — Админка ↔ KDS ↔ POS

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

Интеграция: Админка ↔ KDS ↔ POS

End-to-end: «открыть кафе и принять заказ с приготовлением»

Тестируется не одна фича, а связка трёх клиентов через event-flow и REST-вызовы.
Типичные баги — интеграционные: рассогласование данных между клиентами, race conditions, неправильные статусы, propagation delays.

Зачем тестировать в связке

Каждый клиент по отдельности можно тестировать в своей зоне (T1/T2/T3). Но в реальной работе они связаны:

СвязьЧто передаётся
Catalog → POSТовары, цены, флаги requires_kitchen / kitchen_station_id, стоп-листы, прейскурант
Catalog → KDSНастройки KDS (звуки, auto-logout), пороги цвета станций, состав группы модификаторов
POS → KitchenOrder создан → in_progress → отображается на нужной станции
Kitchen → POSOrder отмечен «готов» → POS показывает «к выдаче»
Админка → KDSRevoke устройства, изменение настроек, добавление/удаление станций
Админка → POSДеактивация сотрудника, изменение PIN, изменение прав

Этот документ тестирует связку, а не отдельные модули.

Prerequisites

Setup в админке (один раз перед серией тестов)

  • ИП-владелец залогинен
  • Создана 1 ТТ, привязан POS-терминал (по fs_number)
  • Создан Cashier с PIN, permission pos.access, привязан к ТТ
  • Создан KDS-сотрудник с PIN, permission kds.access, привязан к ТТ (если KDS Phase 2)
  • Создана кухонная станция «Hot Kitchen» с порогами yellow_threshold_minutes=5, red_threshold_minutes=10
  • Создана вторая станция «Bar» (для multi-station сценариев)
  • (Phase 2) Зарегистрировано KDS-устройство, привязано к ТТ

Setup каталога (через админку)

  • Категория «Завтраки»
  • Товар «Бургер»: requires_kitchen=true, kitchen_station_id = Hot Kitchen, vat_rate=vat20, payment_subject=goods
  • Товар «Капучино»: requires_kitchen=true, kitchen_station_id = Bar
  • Товар «Бутылка воды»: requires_kitchen=false (продаётся как good)
  • Группа модификаторов «Молоко» (для Капучино): обычное / соевое / овсяное
  • Прейскурант с ценами на все 3 товара + опции модификаторов
  • Прейскурант привязан к ТТ

Учётки

РольНазначение
Franchise (ИП-владелец)Админка
Cashier (PIN)POS-терминал
KDS employee (kds.access)KDS-устройство
Manager (опционально)Админка для отмен заказов и просмотра

Test Scenarios

TC-INT-001 — Заказ с приготовлением (happy path)

Goal: Полный цикл заказа от приёма до выдачи через все три клиента.

Priority: P0 · Regression: yes

Steps:

  1. Cashier на POS: PIN-логин на терминале
  2. Cashier: открывает смену
    • ✓ Смена открыта, X-отчёт пустой, фискальный модуль готов
  3. Cashier: создаёт заказ — добавляет «Бургер» × 1
    • ✓ Позиция в заказе с правильной ценой из прейскуранта
  4. Cashier: добавляет «Бутылка воды» × 1
  5. Cashier: оплата картой
    • ✓ Чек печатается, фискализируется
    • ✓ Заказ → статус in_progress
  6. Kitchen (KDS / Kitchen Queue): заказ появляется на станции «Hot Kitchen»
    • ✓ Виден только «Бургер» (вода requires_kitchen=false, не идёт на кухню)
    • ✓ Ячейка нейтрального цвета (зелёная/белая)
    • ✓ Звуковое уведомление о новом заказе
  7. Kitchen: ждёт 5+ минут
    • ✓ Ячейка переходит в yellow
  8. Kitchen: повар отмечает «принят» / начинает готовить
    • ✓ Статус позиции на KDS: «в работе»
  9. Kitchen: через ~3 минуты отмечает «готов»
    • ✓ На POS появляется уведомление «Бургер готов к выдаче»
    • ✓ Заказ → статус ready
    • ✓ Позиция исчезает с экрана KDS (или уезжает в раздел «закрытые»)
  10. Cashier на POS: отмечает «выдан клиенту» / закрывает заказ
    • ✓ Заказ → статус closed
  11. Cashier: закрывает смену → Z-отчёт
    • ✓ Фискальный Z-отчёт, выручка совпадает с суммой заказов

TC-INT-002 — Заказ только без приготовления

Goal: Заказ из good-товаров не идёт на кухню.

Priority: P1

Steps:

  1. POS: заказ только из «Бутылка воды» × 2
  2. Оплата
    • ✓ Заказ может пропустить in_progress или быть в нём <1 сек
  3. KDS: заказ не появляется ни на одной станции
  4. Cashier: «выдан» → closed

TC-INT-003 — Stop-list блокирует на POS

Goal: Товар в стоп-листе недоступен кассиру.

Priority: P0 · Regression: yes

Steps:

  1. Админка: ставит «Бургер» в стоп-лист на ТТ
  2. POS: ждёт ~30 сек / делает refresh меню
  3. POS: пытается создать заказ с «Бургер»
    • ✓ Товар не виден в меню ИЛИ показан с пометкой «недоступен», нельзя добавить
  4. Админка: снимает стоп
  5. POS: refresh
    • ✓ «Бургер» снова доступен

Известный баг: BUG-049 — Manager не может управлять стоп-листами на своей ТТ (403). Если делает Manager, ожидаемое поведение — нужна возможность.

TC-INT-004 — Несколько кухонных станций (multi-routing)

Goal: Заказ корректно расщепляется на несколько станций.

Priority: P0 · Regression: yes

Steps:

  1. POS: один заказ — «Бургер» + «Капучино»
  2. Оплата → in_progress
  3. KDS станции «Hot Kitchen»: видит только «Бургер»
  4. KDS станции «Bar»: видит только «Капучино»
  5. Hot Kitchen отмечает «Бургер готов»
    • ✓ Заказ ещё в in_progress (Капучино не готов)
  6. Bar отмечает «Капучино готов»
    • ✓ Заказ → ready (обе позиции готовы)
  7. POS: уведомление «весь заказ готов»

TC-INT-005 — Заказ с модификаторами на KDS

Goal: KDS видит детали состава для приготовления.

Priority: P1 · Regression: yes

Steps:

  1. POS: «Капучино» + модификатор «соевое молоко» + (если есть) «без сахара»
  2. Оплата
  3. KDS станция Bar: видит «Капучино — соевое молоко, без сахара»
    • ✓ Все выбранные опции модификаторов отображены повару
  4. (Если каталог обновился) — повар видит актуальный набор опций без рестарта приложения

TC-INT-006 — Отмена заказа во время приготовления

Goal: При отмене заказа кухня узнаёт.

Priority: P0

Steps:

  1. POS: заказ в in_progress, KDS видит позицию
  2. POS / Manager: отмена заказа с указанием причины
  3. KDS: позиция исчезает / помечается «отменён»
    • ✓ Звуковое уведомление об отмене (если был включён звук)
  4. Заказ → cancelled, позиция не списывается

TC-INT-007 — Изменение каталога во время активной смены

Goal: Изменения в админке доходят до POS/KDS без рестарта.

Priority: P1

Steps:

  1. Cashier открыл смену, видит меню
  2. Админка: меняет цену «Бургер» в прейскуранте (например, 350 → 400)
  3. POS: создаёт новый заказ с «Бургер»
    • ✓ Цена обновлённая (400) ИЛИ задокументировать что нужен refresh
  4. Админка: добавляет новую опцию модификатора «Молоко» — «миндальное»
  5. POS: создаёт новый заказ
    • ✓ Новая опция видна
  6. KDS: при принятии заказа видит «миндальное молоко» в составе

TC-INT-008 — KDS device revoke (force logout)

Goal: Админ принудительно отключает KDS-устройство.

Priority: P1 · применимо если KDS Phase 2 запущен

Steps:

  1. Setup: KDS залогинен на устройстве, активная сессия
  2. Админка: открывает список KDS-устройств
  3. Админка: DELETE на устройстве (revoke)
  4. KDS: на следующем heartbeat (≤2 мин) получает 401
    • ✓ Выкидывает из приложения, показывает «устройство деактивировано»
  5. KDS: для повторного входа нужна повторная регистрация устройства

По спеке (BR 5.1): публикуется событие user.kds_device.revoked, pos-bff consumer завершает WebSocket-сессии. На стороне UI — мгновенный logout.

TC-INT-009 — Изменение KDS-настроек на лету

Goal: Изменение настроек применяется без перезагрузки KDS.

Priority: P2

Steps:

  1. KDS: повар работает, звуки включены
  2. Админка: меняет KDS-настройки франшизы — отключает звук
  3. KDS: получает событие catalog.kds_settings.updated
    • ✓ Настройка применена (звук отключён) без рестарта приложения

По спеке: в P0 consumer не реализован — KDS делает re-pull при «Применить». В P1 — pos-bff broadcast’ит в WebSocket.

TC-INT-010 — Изменение порогов цвета станции

Steps:

  1. Админка: меняет для Hot Kitchen yellow=2min, red=4min
  2. KDS: получает обновление (re-pull или push)
  3. POS: создаёт новый заказ
  4. KDS: цвет ячейки переходит yellow за 2 мин (не за 5)

TC-INT-011 — Network failure recovery

Goal: KDS теряет связь и восстанавливается без потери заказов.

Priority: P1

Steps:

  1. Pre-: заказ в in_progress отображён на KDS
  2. KDS: разрыв сети (выключить Wi-Fi на устройстве)
  3. POS: создаёт новый заказ
  4. KDS: показывает статус «офлайн» / «нет связи»
  5. KDS: восстановление сети
  6. ✓ KDS подтягивает пропущенные заказы / синхронизируется
  7. ✓ Не дублирует уже отображённые

TC-INT-012 — RBAC между POS и KDS

Goal: Права на POS и KDS разделены.

Priority: P1 · Regression: yes

Steps:

  1. Сотрудник X — только pos.access, без kds.access
    • ✓ Логин на POS — да
    • ✓ Логин на KDS — 403 «Нет доступа»
  2. Сотрудник Y — только kds.access
    • ✓ Логин на KDS — да
    • ✓ Логин на POS — 403
  3. Сотрудник Z — pos.access + kds.access
    • ✓ Логин на оба

TC-INT-013 — Force logout деактивированного сотрудника

Goal: При деактивации Cashier на POS все сессии завершаются.

Priority: P1

Steps:

  1. Cashier работает на POS, есть открытая смена и активный заказ
  2. Админка: деактивирует Cashier
  3. POS: следующее действие
    • ✓ 401 / выкидывает на логин с сообщением «учётка деактивирована»
  4. ✓ Открытая смена не теряется (можно закрыть под другим Cashier)

TC-INT-014 — Удаление сотрудника во время приготовления

Edge case.

Steps:

  1. Cashier создал заказ с приготовлением, вышел из смены
  2. Админка: удаляет / деактивирует Cashier
  3. KDS: завершает приготовление, отмечает «готов»
    • ✓ Заказ обрабатывается без ошибок (нет dangling reference на удалённого Cashier)
  4. ✓ В отчёте смены сохраняется кто принимал заказ (исторические данные)

TC-INT-015 — Stop-list появляется во время активного заказа

Edge case.

Steps:

  1. POS: создал заказ с «Бургер» в in_progress
  2. Админка: ставит «Бургер» в стоп-лист
  3. KDS: заказ продолжает отображаться (он уже принят)
    • ✓ Не пропадает с кухни, повар готовит
  4. POS: новые заказы — «Бургер» уже недоступен

Известные баги, влияющие на эту связку

BugImpact на интеграцию
BUG-060Меню в карточке ТТ → 500 в админке. Не блокирует POS-меню (отдельный API), но не позволяет владельцу проверить «как выглядит меню»
BUG-061Меню — нет кнопки добавить товар. Может быть: меню вычисляемое автоматом, а кнопка не нужна. Уточнить логику
BUG-062Меню — отображаются модификаторы вместо описания. Косметика
BUG-066«Склад не найден для ТТ» в Приёмках. Если склад не автосоздаётся при ТТ → блокирует автосписание ингредиентов после продажи (Phase 2 фича)
BUG-021Clock in/out отсутствует. POS-смена через ФЯ работает, но фактическое отработанное время кассира не фиксируется автоматически — только ручной ввод

Out of scope

  • Фискализация чеков на ОФД — работа фискального ядра K10, тестируется отдельно (Honest Mark integration)
  • Webhook-обмен с агрегаторами (Я.Еда, Маркет Деливери) — отдельный документ, M2 skeleton
  • Автосписание со склада при продаже — Phase 2, не реализовано
  • Возвраты после closed — Phase 2

Acceptance criteria

Связка считается рабочей если:

  • TC-INT-001 проходит без ошибок (полный happy path)
  • TC-INT-003 (стоп-лист) — propagation ≤30 секунд
  • TC-INT-004 (multi-станции) — корректное расщепление позиций
  • TC-INT-006 (отмена) — реакция на KDS ≤10 секунд
  • TC-INT-008 (revoke) — KDS вылетает за ≤2 минуты (при наличии Phase 2)
  • TC-INT-012 (RBAC) — все 3 комбинации прав работают как ожидается
  • Никаких 500/422 на happy path

Кто прогоняет

Эта серия — cross-team, не одного тестировщика. Варианты:

  • A) Один тестер с тремя устройствами (или одной машиной с 3 окнами): админка в одном браузере, POS в Tauri / отдельном окне, KDS на планшете или вкладке. Самый чистый вариант
  • B) Парный тест: один за POS, другой за админкой/KDS, синхронизация по тимс-чату
  • C) Триплет: T1 в админке, T3 на POS, тест-лид на KDS — для high-pressure прогонов

Рекомендую вариант A для системного прогона + B/C для exploratory или regression после критичных фиксов.

Вид графа

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