Что нужно было сделать
Маленькое кафе живёт на бумажках и договорённостях. Заказ официант несёт на кухню голосом, повар держит очередь в голове, склад — в тетради у управляющего, а сколько кто отработал и сколько ему причитается, вспоминают в конце месяца.
Что из этого получается:
- Заказы теряются и путаются, гость ждёт дольше, чем нужно
- Кухня и бар не видят, что готовить первым — очередь не выстроена
- Остатки не сходятся: списания «по памяти», закуп на глаз
- Приход поставки — это ручной ввод десятков позиций с бумажной накладной
- Смены и выплаты персоналу считаются вручную и спорно
Задача: собрать одну систему, в которой работают все — от гостя за столом до управляющего, — и убрать из неё ручной ввод везде, где его может взять на себя машина.
Как мы это видим
Спроектировали единое приложение с шестью ролями: у каждой свой экран и только то, что ей нужно в работе.
- Гость — сканирует QR на столе и заказывает со своего телефона: меню с фото, комментарий к заказу («без лука»), лента блюд в стиле Reels с лайками и вкладкой «Хиты». Стол из QR запоминается на три часа.
- Официант — светофор столов: свободен, готовится, готов. Лента «К подаче» со звуком, дозаказ к существующему заказу, перенос гостя на другой стол, закрытие отдельного заказа.
- Кухня и бар — доски с карточками блюд: очередь по FIFO, время готовки на каждой позиции, карточка уходит с доски, только когда блюдо готово и заказ закрыт.
- Склад — приход, остатки, корректировки, тех-карты блюд с автосписанием и список закупа по дням.
- Менеджер и админ — смены и расчёт оплаты, выручка дня, статистика по проданным позициям.
Как мы это строили
Самая интересная часть — приёмка поставки. Кладовщику незачем вбивать накладную руками: он фотографирует её, а разбор берёт на себя нейросеть.
Как работает ИИ-приёмка:
- Фото уходит в фоновую задачу — Celery-воркер обрабатывает скан, статус виден в интерфейсе, повторный запуск ничего не ломает.
- Vision-модель читает накладную — один запрос через OpenRouter с жёсткой JSON-схемой ответа: поставщик, дата, итог и каждая позиция с количеством, единицей и ценой. Схема strict — модель не может вернуть «прозу» вместо данных, а в промпте прямо запрещено выдумывать позиции.
- Единицы приводятся к базовым — килограммы в граммы, литры в миллилитры, упаковки в штуки. Если семейство единиц не сошлось (в чеке килограммы, а товар штучный) — строка помечается на ручную проверку.
- Позиции сопоставляются со складом — сначала по запомненным названиям из прошлых накладных, потом нечётким сравнением с бонусом за вхождение подстроки: поставщики пишут сокращения по-своему. У каждой строки своя оценка уверенности, ниже порога — «не найдено».
- Последнее слово за человеком — система готовит черновик, кладовщик правит и подтверждает. Остатки меняются только после подтверждения, а исправленное название запоминается и в следующий раз распознаётся точно.
Остальная архитектура: Django 5 и DRF, PostgreSQL, Redis и Celery на бэкенде; React с TypeScript и Vite на фронте, установка как PWA. Движения остатков и токенов кошелька пишутся отдельными проводками, а не «пересчётом на лету». Оплата — через провайдера с webhook и юридическими страницами для приёма онлайн-платежей. Прод разворачивается в Docker за nginx. Трафик к LLM идёт через отдельный туннель: OpenRouter недоступен из России, при этом база и хранилище работают напрямую.
Что получилось
Получилась операционная система заведения: заказ, кухня, склад, смены и деньги — в одном приложении, без бумажек и ручного ввода.
Что работает:
- Гость заказывает по QR со своего телефона — официанту не нужно нести бумажку
- Кухня и бар работают по доскам с приоритетом и таймингами
- Поставка принимается с фотографии накладной, а не набивается руками
- Тех-карты списывают продукты автоматически, закуп собирается по дням
- Смены, дневная оплата и процент от выручки считаются в системе
- Приложение ставится на телефон как обычное — без публикации в сторах
Система развивается вместе с заведением: каждая новая механика — от «стоп-листа» блюд до штрафов за смену — прилетает в тот же продукт, а не в новый файл Excel.
