Как просьба друга «настроить кассу» закончилась open‑source ERP, тринадцатью российскими интеграциями и нейросетью, которая теперь считает закупки, ищет косяки в учёте и пишет владельцу в Telegram.

Есть у меня друг. Назовём его Артём.

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

Примерно за месяц до открытия Артём пришёл ко мне с классической фразой:

— Слушай, тыжепрограммист. Помоги систему настроить. Ну чтобы касса, кухня, заказы — всё нормально работало.

Если вы когда‑нибудь были «тем самым знакомым программистом», то примерно понимаете, чем обычно заканчивается слово «помоги». Сначала задача выглядела просто: выбрать что‑нибудь вроде iiko, поставить, настроить и забыть.

В итоге я полез смотреть, как вообще устроен ресторанный софт, перебрал несколько систем, остановился на open source, русифицировал его, прикрутил российские кассы, банки, 1С, маркировку, агрегаторов доставки, а потом зачем‑то решил, что обычной автоматизации мне уже мало.

Так в ресторане появился DeepSeek, который скоро заменит Артема, а может и всех остальных. Сам будет заказывать еду, сам кушать....ну это я отвлекся.

Сразу важный момент. Я не писал ресторанную ERP с нуля. Это был бы отличный способ потратить много времени и получить плохую кассу. Я взял готовую open‑source систему и начал допиливать её под конкретный ресторан. И вот здесь всё стало интереснее.

Почему я не поставил iiko и не пошёл домой

Первой мыслью была, конечно, iiko или r_keeper. Артём её видел у знакомых рестораторов и примерно этого и ожидал. Я посмотрел рынок чуть внимательнее.

Система

Модель

Цена владения

Исходники

Можно глубоко переделывать

iiko

лицензия + подписка

высокая

нет

через API/партнёров

r_keeper

лицензия

высокая

нет

ограниченно

Quick Resto

SaaS

средняя

нет

в рамках платформы

Poster

SaaS

средняя

нет

API

URY

open source

бесценно

да

практически как угодно

Сразу оговорюсь: я не хочу сказать, что iiko или r_keeper плохие. У них своя аудитория, огромная установленная база и куча вещей, которые давно обкатаны в реальных заведениях.

У меня была другая задача. Мне хотелось иметь доступ не только к кнопкам настройки, но и к данным, логике и коду. Если завтра я решу, что заказ должен обрабатываться каким‑то совершенно нестандартным способом, я не хочу сначала выяснять, разрешил ли мне это вендор.

Плюс ресторан один и только открывается. Ежегодная подписка в такой ситуации ощущается немного иначе, чем для сети из пятидесяти заведений.

После перебора вариантов я остановился на URY — open‑source системе автоматизации ресторана на базе ERPNext + Frappe. И вот тут оказалось, что я выбрал небольшой конструктор ERP. Под капотом Python, MariaDB, Redis, очереди, документы, склад, закупки, права доступа, отчёты. Уже есть POS, кухонный дисплей, заказы навынос и доставка.

То есть основная скучная работа кем‑то уже сделана. А скучную работу я очень люблю, когда её уже сделал кто‑то другой. Оставалось только адаптировать всё это к российскому ресторану. Как выяснилось, слово «только» здесь было лишним.

Поставил URY. Открыл. Загрустил

Разворачивается всё довольно нормально. Docker, bench, несколько вечеров — и у меня уже работал POS, заказы улетали на кухню, печатались тикеты. А потом я посмотрел на систему глазами российского ресторатора, и понял, что международный open source очень хорошо знает, что такое ресторан.

Но почти ничего не знает о том, что такое ресторан в России. Не было:

  • 54-ФЗ и нормальной фискализации;

  • АТОЛ и ШТРИХ‑М;

  • наших банков и СБП;

  • обмена с 1С;

  • Честного знака;

  • ЕГАИС;

  • Меркурия;

  • Яндекс Еды, Деливери;

  • нормальной русификации.

В общем, касса есть. Работать нельзя. Получился вполне конкретный список того, чем я буду заниматься следующие вечера.

Русский язык оказался самым безобидным

Frappe умеет локализацию, переводы лежат в.csv. Казалось бы: прогнал строки, перевёл, закончил. Нет. Перевод интерфейса — это как раз самая простая часть.

Потом начинаются даты, рубли, копейки, разделители, ФИО, печатные формы, склонения.

«1 заказ», «2 заказа», «5 заказов».

И отдельно любимое развлечение всех, кто хоть раз связывался с чековыми принтерами: кириллица и ESC/POS. Если не угадал кодовую страницу — ресторан внезапно начинает печатать древние письмена.

Чтобы очередное обновление URY не убивало мои правки, русификацию я вынес в отдельное Frappe‑приложение. Потом туда же постепенно поехали остальные доработки. Это оказалось правильным решением. Апстрим можно обновлять отдельно, свой зоопарк — отдельно.

Потом я немного познал российский ресторанный IT

Самой длинной частью оказались интеграции.

Касса: АТОЛ, ШТРИХ‑М, ОФД и 54-ФЗ

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

А у железа есть прекрасная особенность: оно иногда читает документацию совсем не так, как её читаете вы.Поэтому каждый шаг пришлось нормально логировать. Особенно ситуации, когда касса уже что‑то сделала, а приложение по какой‑то причине считает иначе.

Добавьте сюда возвраты и офлайн‑режим — и обычная кнопка «Оплатить» быстро перестаёт быть обычной кнопкой.

Т‑Банк, Сбер и СБП

Дальше платежи.

Подключил эквайринг Т‑Банка и Сбера плюс СБП по QR.

Здесь главный вопрос уже не в красивой форме оплаты, а в том, чтобы платёж, заказ и фискальный чек не начали жить каждый своей жизнью. Если банк говорит «оплачено», ресторан должен ровно один раз закрыть заказ и ровно один раз пробить нужный чек. К концу смены бухгалтерия почему‑то любит, когда цифры совпадают.

1С

Без неё статья про российскую автоматизацию была бы неполной.

Настроил обмен номенклатурой и выгрузку документов, чтобы бухгалтеру не приходилось руками повторять то, что уже есть в ресторанной системе. Обмен идёт через промежуточные документы и синхронизацию по расписанию.

Честный знак, ЕГАИС и Меркурий

А вот здесь начинается территория, где лучше десять раз проверить, чем один раз потом объяснять, почему система решила сделать именно так.

  • Честный знак — коды маркировки на приёмке и продаже.

  • ЕГАИС — алкоголь, УТМ, списания.

  • Меркурий — ВСД и приёмка продуктов животного происхождения.

Каждая система со своими форматами, сертификатами и особенностями.

На этот блок в итоге ушло примерно столько же времени, сколько на всё остальное вместе.

И да: яжепрограммист, а не специалист по фискальному законодательству. Всё, что касается 54-ФЗ, ЕГАИС, Честного знака и Меркурия, мы дополнительно сверяли со специалистами.

Повторять подобную интеграцию по принципу «ну вроде чек напечатался» я бы не советовал.

Яндекс Еда и Деливери

Последними в эту компанию приехали агрегаторы. Логика простая: если у ресторана есть свой зал и доставка, повару совершенно незачем смотреть в три разных планшета. Поэтому заказы агрегаторов падают в ту же систему и в тот же KDS, туда же приезжают стоп‑листы и статусы.

На этом этапе получилось примерно то, чего Артём хотел в самом начале. Касса работает. Кухня видит заказы. Склад есть. Платежи есть. Бухгалтерия получает данные. Доставка приезжает в одну систему. Можно было наконец остановиться. Разумеется, я не остановился.

А зачем тогда мы вообще собираем столько данных?

Через ERP проходят практически все события ресторана: продажи; блюда; время заказа; складские движения; списания; закупки; оплаты; возвраты.

И в какой‑то момент я поймал себя на простой мысли. Мы очень старательно собираем огромное количество данных, чтобы потом человек открыл отчёт и снова принимал решение примерно «на глаз».

Например: сколько продуктов заказать на следующую неделю?

Можно посмотреть прошлую. Потом вспомнить, что в пятницу был дождь. Потом что в эти выходные праздник. Потом что одно блюдо внезапно начали хорошо заказывать.

А можно хотя бы попробовать заставить машину собрать всё это в одно место.

Так рядом с ERP появился DeepSeek.

Сразу скажу: никакой магии «я дал нейросети базу, и она стала директором ресторана» здесь нет.

Там, где нужна арифметика, её считает обычный код. Там, где нужно что‑то записать в систему, это делает обычный код. LLM я использую там, где нужно интерпретировать данные, искать необычное и формировать понятный человеку результат.

Мне так спокойнее.

Сколько людей придёт завтра

Первая задача — прогноз загрузки.

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

Для прогноза я собираю историю заказов по дням, день недели, выручку, погоду, праздники и акции. Упрощённый вариант выглядит так:

import frappe
import json
from openai import OpenAI

client = OpenAI(
api_key=frappe.conf.deepseek_key,
base_url=“https://api.deepseek.com”,
)

def build_features():
rows = frappe.db.sql(“‘’
SELECT
DATE(creation) d,
DAYOFWEEK(creation) dow,
COUNT(*) orders,
SUM(grand_total) revenue
FROM tabPOS Order
WHERE creation >= DATE_SUB(NOW(), INTERVAL 56 DAY)
GROUP BY d
ORDER BY d
‘‘’, as_dict=True)’”

weather = get_pogoda()
holidays = get_ru_holidays()

return {
“history”: rows,
“weather”: weather,
“holidays”: holidays,
}


def forecast_demand():
features = build_features()

prompt = (
“На основе истории продаж, прогноза погоды и календаря ”
«спрогнозируй на 7 дней число гостей, выручку и позиции »
«с повышенным спросом. Верни строгий JSON.\n\n»
f“Данные: {json.dumps(features, ensure_ascii=False, default=str)}”
)

resp = client.chat.completions.create(
model=“deepseek‑chat”,
messages=[{“role”: “user”, “content”: prompt}],
response_format={“type”: “json_object”},
temperature=0.2,
)

forecast = json.loads(resp.choices[0].message.content)

frappe.get_doc({
“doctype”: “AI Demand Forecast”,
“payload”: json.dumps(forecast, ensure_ascii=False),
}).insert()

return forecast

Это, конечно, упрощённый пример. Смысл не в конкретном промпте, а в связке данных из ERP с внешними факторами. Сам прогноз сам по себе особой пользы не даёт.

Красивый график с числом гостей не покупает продукты. Поэтому следующим шагом я связал прогноз с техкартами и остатками.

«Сколько покупать мяса?» оказалось полезнее красивого AI‑чата

Система знает ожидаемый спрос.

Система знает состав блюд.

Система знает остатки.

Значит, можно посчитать, сколько продуктов понадобится, вычесть то, что уже лежит на складе, и сформировать заявку поставщику. Именно здесь я специально не даю LLM самостоятельно заниматься финансовой математикой.

Расход по техкарте, остатки и количество считает код. DeepSeek помогает разобрать прогноз и подготовить результат для человека. На выходе владелец получает черновик закупки.

!!Пока именно черновик!!!

Нажать кнопку и купить продукты без человека нейросети я не даю. Не потому, что это невозможно. Просто мне пока не хочется однажды выяснить, зачем ресторан заказал палету кинзы.

Слышу некомой вопрос из зала: «Почему дипсик?». Ну, во‑первых мне нравится как он работает и сколько стоит API, во‑вторых при сильном желании можно дистилированную версию разместить на своем сервере, ну а в‑третьих можно модуль совсем немного изменить для работы с Клод или ГПТ.

Потом DeepSeek получил вторую работу — искать странности

Когда есть продажи, склад и касса, появляется ещё одна интересная задача: искать расхождения.

Раз в день я отдаю модели свежие движения и прошу посмотреть, нет ли чего‑то подозрительного.

Например:

  • себестоимость блюда заметно выросла;

  • списаний по позиции неожиданно больше, чем должно быть;

  • фактический расход расходится с расчётным по техкарте;

  • появилось много возвратов или ручных корректировок.

Важно: DeepSeek здесь не прокурор и не бухгалтер.

Он не говорит: «Иван украл три килограмма сыра».

Он говорит: «Вот этот участок выглядит странно, посмотри».

Дальше разбирается человек.

Мне этот вариант нравится гораздо больше идеи «ИИ полностью управляет рестораном». Пока что хороший автоматический фонарик полезнее плохого автоматического директора.

Владелец всё равно не хочет открывать ERP

Можно сделать сколько угодно красивых дашбордов, но у маленького ресторана есть одна проблема.

Владелец не сидит весь день за компьютером

Он может быть на кухне, в зале, разговаривать с поставщиком или вообще заниматься чем‑то, что не имеет отношения к ERPNext. Зато Telegram у него почти всегда под рукой.

Поэтому основные результаты я вынес в бота. Утром он получает прогноз и черновик закупки.

Вечером — выручку, количество чеков, средний чек и то, что нашёл автоматический аудит.

Примерно так:

def send_daily_digest():
forecast = frappe.get_last_doc(“AI Demand Forecast”)
stats = today_stats()
alerts = ai_audit_alerts()

text = (
f"📊 Сегодня\n"
f“Выручка: {stats.revenue:,.0f} ₽ ”
f“({stats.delta:+.0%} к прошлой неделе)\n”
f“Чеков: {stats.orders}\n”
f“Средний чек: {stats.avg:,.0f} ₽\n\n”
f"🔮 Завтра: около {forecast.guests} гостей\n"
f"🛒 Черновик закупки: {forecast.purchase_items} позиций\n"
)

if alerts:
text += “\n⚠️ Стоит посмотреть:\n”
text += “\n”.join(f“• {item}” for item in alerts)

send_telegram(frappe.conf.owner_chat_id, text)

Плюс можно руками спросить что‑нибудь простое: текущую выручку, топ блюд за неделю и так далее.

Получился забавный эффект.

Под капотом довольно большая ERP, база, Redis, интеграции, фискализация, API банков и DeepSeek. А пользователь видит несколько сообщений в Telegram. Наверное, так и должна выглядеть нормальная автоматизация.

Где заканчивается DeepSeek и начинается обычный код

Это место я специально хочу выделить, потому что вокруг LLM сейчас очень легко сделать красивую презентацию и очень плохую систему. Я для себя оставил два правила.

1. Деньги без человека не двигаем

Закупку DeepSeek предлагает.

Цену может предложить.

Но финальное действие пока подтверждает человек.

2. LLM не считаем калькулятором

Закупки, остатки, себестоимость и прочие числа считаются обычным кодом по данным из ERP.

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

LLM умеет очень уверенно нести ерунду.

Поэтому чем ближе задача к деньгам, тем меньше у неё должно быть возможности «догадаться».

Что получилось

Система сейчас работает в реальном ресторане Артёма.

Из заметного:

Закупки стали менее похожи на гадание.

Раньше значительная часть решения принималась по опыту и ощущениям. Теперь есть расчёт на основе истории, прогноза и текущих остатков.

Расхождения стали видны раньше.

Автоматический аудит уже находил вещи, которые иначе могли всплыть только на инвентаризации.

Владельцу не нужен отдельный ритуал «зайти посмотреть отчёты».

Основная информация сама приходит в Telegram.

Нет ежегодной лицензии за саму платформу.

Остаются сервер, железо и моя работа, яжепрограммитс, а еще и школьный друг, а еще и человек, который за скидку потом в ресторане и по собственной любознательности тратит свой отпуск на автоматизацию ресторана Артема! Да на таких людях как ты пахать нужно, хотел сказать Артем, но скромно сказал спасибо.

Последний пункт, кстати, важно не забывать.

Open source бесплатный примерно до того момента, пока вы не начинаете считать собственное время. Вендору вы платите деньгами. Здесь я заплатил вечерами и теперь ещё имею удовольствие всё это поддерживать.

Зато исходники, данные и вся логика принадлежат ресторану, и я могу менять систему так глубоко, как понадобится.

Что дальше

Мне интересно не столько прикручивать к ресторану очередной чат с нейросетью, сколько постепенно отдавать автоматике конкретные рутинные решения.

Следующие вещи напрашиваются сами:

  • автоматическая закупка по проверенным сценариям, где человеку показываются только исключения;

  • акции в часы, когда спрос стабильно проседает;

  • анализ цен и меню конкурентов;

  • данные с камер: загрузка столов, очереди, время ожидания;

  • нормальные A/B‑тесты меню, цен и акций.

Часть этого вообще не требует LLM. И это, пожалуй, один из выводов всей истории. Не нужно пытаться засунуть DeepSeek в каждый if.

Где хватает SQL — должен быть SQL.

Где нужна формула — должна быть формула.

Где нужно найти аномалию или собрать из большого количества данных понятное объяснение — вот там уже интересно подключать модель.

В начале Артём попросил меня просто «настроить кассу».

Кассу я, кажется, уже настроил.

Теперь интересно посмотреть, сколько работы управляющего можно убрать из ежедневной рутины, не превратив ресторан в эксперимент над посетителями.

Если тема интересна, могу отдельно разобрать техническую часть российских интеграций: 54-ФЗ, ЕГАИС, агрегаторы, обмен с 1С и все грабли, которые там встретились.

А ещё отдельно можно написать про сам прогноз: какие данные действительно помогают, где DeepSeek начинает фантазировать и как вообще проверять, что его советы лучше старого доброго «повару кажется, что в субботу будет много гостей».

Я только начинаю использовать свой https://github.com/webzuweb/URY‑RU, очень буду рад любой звезде или дальнейшему использованию моих наработок. Если Вы прочитали эту статью, потому что тоже хотите перчинки в автоматизации ресторана или кафе и продолжите проект радости моей не будет предела.