Веб-приложение для дарк-кухни поможет выстроить приемку по партиям и срокам годности, автоматизировать списания и настроить алерты по просрочке.
В дарк-кухне склад живет в темпе смены: привезли коробки, часть ушла в производство, что-то осталось в холодильнике, а потом внезапно выясняется, что «пахнет не так». Без учета партий и сроков годности проблемы обычно всплывают не на приемке, а когда уже поздно: заказ почти собран, ингредиент оказался просрочен, и нужно срочно переделывать, возвращать деньги или объясняться с гостем.
Ручные таблицы и переписка в чатах редко выдерживают реальность кухни. Таблица быстро превращается в «один файл на всех», где никто не уверен, кто и когда правил остатки. Чат удобен, пока мало поставок, но поиск «какая партия сыра пришла во вторник» занимает больше времени, чем сама готовка. Хуже всего, когда данные фиксируют по-разному: один пишет «молоко 10 л», другой - «молоко, 2 коробки». Через неделю это уже невозможно сверить.
Чтобы навести порядок, достаточно закрыть базовые процессы:
Дальше речь про простое веб-приложение для дарк-кухни: кладовщик быстро принимает поставку, повар так же быстро списывает в смене, а менеджер заранее видит риски по просрочке.
Приложение помогает только тогда, когда заранее понятно, кто им пользуется и какие решения он принимает за минуту, а не за полчаса.
Обычно есть три роли:
День изо дня повторяются одни и те же действия: принять поставку (партии, сроки, количество, документ), посмотреть остатки, списать продукты (в готовку, по порче, по пересорту), проверить, что скоро испортится, и закрыть смену, быстро увидев отклонения.
Самые быстрые решения на кухне почти всегда про сроки. Утром пришло молоко с разными датами, а на складе уже есть открытая партия. Повару нужно одним взглядом понять, что брать первым. Менеджеру - увидеть, сколько уйдет в списание, если не использовать сегодня.
Отчеты лучше держать простыми. На практике хватает четырех экранов: «просрочено и скоро истекает», «списания за день/неделю», «остатки по складу», «остатки по ингредиенту с партиями».
Чтобы учет работал в реальной смене, модель данных должна быть простой и строгой. Главная идея: срок годности хранится не у ингредиента «вообще», а у конкретной партии. Один и тот же сыр может прийти сегодня и через неделю - и эти поставки портятся в разные даты.
Минимальный набор сущностей для веб-приложения для дарк-кухни:
Партия - центральная точка: к ней привязываются остатки, списания и алерты.
Обязательные поля партии лучше сделать неизменяемыми после создания (или менять только с правами):
Приемка создает поставку и партии (если они новые), а затем - движения, которые увеличивают остаток. В карточке приемки достаточно поставщика, даты и времени, количества и единиц. Цена не всегда нужна, но ее удобно держать опционально, если позже захотите считать себестоимость.
Остаток по партии лучше не сводить к одной цифре без истории. Практичнее хранить текущий остаток (для скорости) и историю движений (для разбора ошибок). Движение - это запись вида: дата-время, партия, плюс или минус, причина (приемка, списание, инвентаризация), пользователь.
Пример: пришли 10 кг курицы партией K-102 с годностью до 25.01. Списания в течение дня уменьшают именно эту партию. Следующая поставка курицы будет отдельной партией со своим сроком и остатком. Так алерты по просрочке не путают свежие и старые остатки.
Приемка должна занимать минуты и не зависеть от памяти сотрудника. Обычно это один экран, где человек фиксирует то, что реально важно для безопасности и учета: партия и срок годности.
Форма должна быть короткой, но строгой. Минимальный набор, без которого приемку нельзя сохранить:
Партия может создаваться автоматически при приемке (если такой еще нет). Если поставка приходит частями, полезно разрешить выбирать уже существующую партию и докидывать количество.
Проверки должны ловить ошибки в момент ввода: понятный формат даты, срок годности не «в прошлом», количество больше нуля. Если срок годности сегодня или завтра, покажите заметное предупреждение, но дайте сохранить: такие ситуации встречаются.
Чтобы уменьшить клики, добавьте быстрые шаблоны для частых поставок: ингредиент, типовая фасовка, единицы. Тогда сотрудник меняет только номер партии, дату и количество.
Сканирование и печать этикеток можно оставить опцией без сложных интеграций: ввод кода партии сканером как обычной клавиатурой и кнопка «распечатать этикетку» для локального принтера. Важно, чтобы партия и срок годности оказались на контейнере сразу - дальше списания идут быстрее и точнее.
Списание на кухне должно занимать секунды. Если повар отвлекается на поиск партии и ручные расчеты, ошибки почти гарантированы. Сделайте списание одной короткой формой: товар, количество, причина, комментарий (по желанию).
Причины лучше зафиксировать заранее и сделать обязательными. Обычно хватает четырех типов: на производство (в блюдо), порча (упало, разморозилось, потекло), возврат (поставщику или со смены), инвентаризация (выравнивание факта и учета). Тогда потом можно объяснить, почему расход «не бьется».
Чтобы не заставлять человека выбирать партию вручную, используйте правило FEFO: сначала списываем то, что раньше испортится. Пользователь вводит товар и количество, а система предлагает партии в правильном порядке и показывает подсказки: остаток в партии, дата приемки/производства, срок годности. Если одной партии не хватает, система добирает следующую и заранее предупреждает, что списание пойдет из двух партий.
Защита от типовых ошибок:
И обязательно ведите журнал списаний: кто, когда и что списал, по какой причине, из каких партий. Если вы считаете себестоимость, можно хранить и суммы. Пример: во время сборки заказа соус оказался испорчен. Повар выбирает «порча», вводит 1 кг, система списывает из партии с ближайшим сроком и оставляет запись в журнале.
Алерты работают только тогда, когда по каждой партии есть точные данные: дата приемки (или производства), срок годности и текущий остаток. Дальше все сводится к простым правилам, одинаково понятным кладовщику и повару.
Просрочка - партия, у которой срок годности меньше текущей даты. «Скоро истечет» - партия, у которой до конца осталось N дней. N лучше сделать настраиваемым (например, 1, 3 или 7 дней) и, при желании, разным для групп: молочке обычно нужно более раннее предупреждение, чем сухим продуктам.
Минимальный набор алертов:
Показывайте алерты в двух местах: на главном экране (кратко) и в ежедневном отчете (с партиями, остатками и сроками). Так просрочка не «прячется» на складе, которым пользуются нерегулярно.
Чтобы уведомления не раздражали, добавьте фильтры: склад, группа ингредиентов, поставщик, статус партии. Полезное правило: не повторять один и тот же алерт чаще раза в сутки, если по партии не было изменений.
Действия должны быть в один-два клика: «Списать» (с причиной), «Поставить в приоритет» (для истекающих) или «Проверить качество» (если нужна ручная отметка). Пример: утром система видит, что партия сливок истекает через 2 дня, и предлагает приоритет. Вечером, если остаток не уменьшился, это повторится в отчете, но без лишних всплывающих уведомлений.
Если вы делаете веб-приложение для дарк-кухни через чат с AI, результат зависит от того, насколько четко описан процесс. Думайте не про «модули», а про работу смены: что человек видит на экране и что должен успеть сделать за минуту.
Начните с простых формулировок: «Экран приемки», «Экран списания», «Экран предупреждений». Сразу отметьте обязательные поля: партия и срок годности (без них нельзя сохранить). Укажите, какие поля подтягиваются автоматически (например, единица измерения ингредиента), а какие вводятся вручную.
Перед генерацией логики перечислите сущности и связи: ингредиент - партия - приемка - движения - списание. Затем задайте правила, которые нельзя нарушать: FEFO (расходуем то, что раньше испортится), запрет отрицательных остатков, обязательность партии и срока годности, и что делать, если срок не указан (обычно - не принимать).
Дальше просите собрать единый поток, а не разрозненные экраны: приемка создает партии и увеличивает остатки, списание уменьшает остатки по правильным партиям, алерты ежедневно проверяют «скоро истекает» и «просрочено», везде фиксируются причина и автор действия.
В конце прогоните 3-5 тестовых ситуаций и уточните пограничные случаи: частичное списание партии, приемка с одинаковым сроком, отмена приемки, нулевой остаток, просрочка в день смены. Это быстро выявляет, где система «додумала» не то.
Чтобы AI не фантазировал, дайте опору: что вы строите, какие экраны нужны, какие таблицы в базе, какие правила нельзя нарушать. Один хороший запрос экономит часы правок.
Самый простой способ - писать промпт как мини-техзадание: цель, роли, экраны, данные, правила, затем короткие тест-кейсы. Формулировки вида «Обязательные поля», «Ошибка если», «Список статусов» превращают желания в требования.
Вот шаблон, который удобно вставлять в TakProsto (или любой чат с AI) и заполнять под себя:
Цель: собрать модуль склада для дарк-кухни: приемка ингредиентов, списания, алерты по просрочке.
Роли:
- Кладовщик: приемка, печать/просмотр партий
- Повар: списания
- Админ: настройки порогов алертов, справочники
Экраны:
1) Приемка поставки (быстрый режим и подробный режим)
2) Список партий + фильтры (по ингредиенту, сроку, статусу)
3) Списание (выбор партии, количество, причина)
4) Алерты (что просрочено/скоро истечет, подтверждение действий)
Таблицы:
- ingredients(id, name, unit)
- deliveries(id, supplier, delivered_at)
- batches(id, ingredient_id, delivery_id, qty, unit, produced_at, expires_at, status)
- writeoffs(id, batch_id, qty, reason, created_at, user_id)
Правила:
- Обязательные поля: ingredient_id, qty, unit, expires_at, status.
- Ошибка если: expires_at < delivered_at; qty <= 0; списание больше остатка партии.
- Список статусов партии: active, near_expiry, expired, written_off.
Примеры данных:
- 5 ингредиентов: курица, сыр, молоко, салат, соус
- 2 поставки: Поставщик А (сегодня), Поставщик Б (вчера)
- 3 партии с разными сроками: истекает завтра, через 7 дней, уже просрочена
Тест-кейсы:
- Приемка партии без expires_at должна давать ошибку
- Просроченная партия не доступна для списания
- Алерт срабатывает за N дней до expires_at
Вывод:
- Сгенерируй структуру UI и API, и опиши проверки на фронте и бэке.
- Дай 2 варианта интерфейса: быстрый и подробный.
Когда нужно поправить результат, не пишите «сделай лучше». Укажите конкретно, что неверно (например, разрешил списывать просрочку), где именно (экран/метод), и какой итог вы ждете (новое правило, новый статус, другое поле). Так правки будут точечными.
Самая частая проблема - когда «партия» и «срок годности» не обязательные поля. В момент приемки кажется, что так быстрее, но через неделю остатки уже не сходятся: часть товара в системе «общая», часть «по партиям», и вы не понимаете, что нужно списать первым.
Вторая ошибка - хранить срок годности текстом в заметке: «годен до 12/02» или «срок 5 дней». Для человека это понятно, но для системы нет. Алерты и правила списания тогда не работают, потому что нет нормальной даты, с которой можно сравнить.
Еще часто делают списания «в один клик», но забывают про причину и автора. В итоге вы видите только минус на складе и не понимаете, это была порча, возврат, пересорт, готовка без техкарты или ошибка. Минимум, который спасает нервы: кто списал, когда, сколько и почему.
И наконец, отсутствие истории движений. Если нет журнала «приход - расход - корректировка», любой спор превращается в гадание: остаток есть, но откуда он взялся, неизвестно.
Перед тем как выкатывать веб-приложение для дарк-кухни на смену, проверьте не дизайн, а то, что спасает от списаний, путаницы и конфликтов между кухней и складом.
Прогоните сценарий на 2-3 тестовых поставках (мясо, молочка, соусы) и убедитесь, что:
Мини-сценарий для теста: приняли 10 кг курицы партией K-241, срок годности через 2 дня. Списали 3 кг на заготовки и 1 кг как брак. Остаток должен стать 6 кг, а на следующий день партия должна попасть в список «истекает».
Утро, 09:20. Курьер привозит молоко для соусов и напитков. В одной поставке две партии: A - 12 литров со сроком годности до 25 января, B - 18 литров до 27 января. Важно занести их отдельно, а не одной строкой.
Кладовщик открывает приемку, выбирает товар «Молоко 3,2%» и добавляет две позиции. В каждой обязательны: номер партии, срок годности, количество, единица измерения. Перед сохранением система проверяет базовые вещи: дата не «в прошлом», количество больше нуля, нет дубля партии внутри этой приемки. После сохранения остатки на складе показываются раздельно: A - 12 л, B - 18 л.
В течение смены повар списывает молоко в производство. Он видит общий остаток (30 л), а система автоматически выбирает партию с ближайшим сроком годности: сначала A. При необходимости сотрудник может переключить партию вручную (например, если упаковка повреждена), но по умолчанию работает принцип «сначала истекает - сначала используем».
Вечером, 18:00, срабатывает алерт: «Партия A истекает завтра». Старший смены открывает карточку партии и выбирает действие: поставить в приоритет, оформить списание по порче или отметить проверку качества.
В конце дня менеджер видит сводку: сколько списали и по каким причинам, какие партии подходят к сроку, что уже просрочено и какие действия подтверждены. Так смена превращается в понятный учет: приемка фиксирует партии, списания идут по срокам, алерты заранее подсказывают, где можно успеть спасти продукт.
Начните с MVP, который проживет первую неделю на кухне. Важно, чтобы приемка, списания и алерты работали без сбоев и не требовали долгого обучения.
Минимальный состав MVP:
Дальше добавьте то, что защищает от ошибок и споров: роли и права доступа (кладовщик, повар, менеджер), журнал действий (кто принял партию, кто списал, кто менял критичные поля).
Если вы собираете такое веб-приложение через TakProsto, удобно начать с описания экранов и правил простыми фразами, а потом попросить собрать проект на React с бэкендом на Go и базой PostgreSQL. Когда MVP начнет жить, пригодятся снапшоты и откат для безопасных изменений, а при необходимости - экспорт исходников и перенос развертывания. Платформа TakProsto (takprosto.ai) как раз рассчитана на сборку приложений через чат, что хорошо подходит для быстрых внутренних инструментов кухни и склада.
Начните с простого: фиксируйте срок годности у каждой партии при приемке. Тогда в момент сборки заказа не придется гадать, что можно использовать, а что уже нельзя, и меньше шансов внезапно остановить смену из‑за просрочки.
Потому что у одного и того же ингредиента бывают разные поставки с разными датами. Если срок хранится «у ингредиента в целом», система не сможет правильно подсказать, какую упаковку использовать первой, и алерты будут путать свежие остатки со старыми.
Сделайте строгий минимум: ингредиент, номер партии, срок годности, количество и единица. Поставщика или документ можно хранить опционально для разборов, но без партии и срока приемка не должна сохраняться.
Проверьте формат даты, запретите количество меньше или равно нулю и не давайте сохранить срок «в прошлом» без явного подтверждения. Отдельно полезна проверка на дубликаты партии внутри одной приемки, чтобы не задвоить приход.
Используйте правило FEFO по умолчанию: списывайте сначала то, что испортится раньше. Повар вводит ингредиент и количество, а система сама распределяет расход по партиям в правильном порядке и предупреждает, если расход затрагивает несколько партий.
Сделайте причины обязательными и короткими: производство, порча, возврат, инвентаризация. Это помогает объяснять расхождения без поиска виноватых и быстро видеть, где реальные потери, а где корректировки учета.
Запретите отрицательные остатки и добавьте защиту от повторной отправки (двойной клик, плохой интернет). Если смена закрыта, запретите редактирование старых списаний и разрешайте только корректировку отдельной операцией, чтобы история не «плыла».
По умолчанию достаточно двух статусов: «просрочено» и «скоро истечет» с порогом в N дней. Не повторяйте один и тот же алерт чаще раза в сутки, если партия не менялась, и показывайте алерты там, где их реально увидят в начале смены.
Держите один журнал складских движений с датой-временем, пользователем, партией, знаком плюс/минус и причиной. Это позволяет быстро восстановить цепочку «пришло — списали — скорректировали» и разбирать спорные случаи без ручных пересчетов.
Опишите роли, экраны, обязательные поля и правила, которые нельзя нарушать, а затем дайте 3–5 тестовых ситуаций из смены. Чем точнее вы зададите «ошибка если» и «по умолчанию делаем так», тем меньше AI будет додумывать, и тем быстрее вы получите рабочий поток приемки, списаний и алертов в TakProsto.