Падача - сервис управления общепитом

Маленькое кафе живёт на бумажках и договорённостях. Заказ официант несёт на кухню голосом, повар держит очередь в голове, склад — в тетради у управляющего, а сколько кто отработал и сколько ему причитается, вспоминают в конце месяца.

Что из этого получается:

Заказы теряются и путаются, гость ждёт дольше, чем нужно

Кухня и бар не видят, что готовить первым — очередь не выстроена

Остатки не сходятся: списания «по памяти», закуп на глаз

Приход поставки — это ручной ввод десятков позиций с бумажной накладной

Смены и выплаты персоналу считаются вручную и спорно

Задача: собрать одну систему, в которой работают все — от гостя за столом до управляющего, — и убрать из неё ручной ввод везде, где его может взять на себя машина.

Спроектировали единое приложение с шестью ролями: у каждой свой экран и только то, что ей нужно в работе.

• Гость — сканирует QR на столе и заказывает со своего телефона: меню с фото, комментарий к заказу («без лука»), лента блюд в стиле Reels с лайками и вкладкой «Хиты». Стол из QR запоминается на три часа.

• Официант — светофор столов: свободен, готовится, готов. Лента «К подаче» со звуком, дозаказ к существующему заказу, перенос гостя на другой стол, закрытие отдельного заказа.

• Кухня и бар — доски с карточками блюд: очередь по FIFO, время готовки на каждой позиции, карточка уходит с доски, только когда блюдо готово и заказ закрыт.

• Склад — приход, остатки, корректировки, тех-карты блюд с автосписанием и список закупа по дням.

• Менеджер и админ — смены и расчёт оплаты, выручка дня, статистика по проданным позициям.

Самая интересная часть — приёмка поставки. Кладовщику незачем вбивать накладную руками: он фотографирует её, а разбор берёт на себя нейросеть.

Как работает ИИ-приёмка:

1. Фото уходит в фоновую задачу — Celery-воркер обрабатывает скан, статус виден в интерфейсе, повторный запуск ничего не ломает.

2. Vision-модель читает накладную — один запрос через OpenRouter с жёсткой JSON-схемой ответа: поставщик, дата, итог и каждая позиция с количеством, единицей и ценой. Схема strict — модель не может вернуть «прозу» вместо данных, а в промпте прямо запрещено выдумывать позиции.

3. Единицы приводятся к базовым — килограммы в граммы, литры в миллилитры, упаковки в штуки. Если семейство единиц не сошлось (в чеке килограммы, а товар штучный) — строка помечается на ручную проверку.

4. Позиции сопоставляются со складом — сначала по запомненным названиям из прошлых накладных, потом нечётким сравнением с бонусом за вхождение подстроки: поставщики пишут сокращения по-своему. У каждой строки своя оценка уверенности, ниже порога — «не найдено».

5. Последнее слово за человеком — система готовит черновик, кладовщик правит и подтверждает. Остатки меняются только после подтверждения, а исправленное название запоминается и в следующий раз распознаётся точно.

Остальная архитектура: Django 5 и DRF, PostgreSQL, Redis и Celery на бэкенде; React с TypeScript и Vite на фронте, установка как PWA. Движения остатков и токенов кошелька пишутся отдельными проводками, а не «пересчётом на лету». Оплата — через провайдера с webhook и юридическими страницами для приёма онлайн-платежей. Прод разворачивается в Docker за nginx. Трафик к LLM идёт через отдельный туннель: OpenRouter недоступен из России, при этом база и хранилище работают напрямую.