Учёт склада без кода: как собрать приложение с базой

Чтобы сделать учёт склада без кода, опишите в промпте, что вы храните, какие операции с этим происходят и кто их выполняет, а ИИ-билдер соберёт приложение сам. В Zugo сборка стоит 6 кредитов и занимает около минуты. Базу и вход сотрудников даёт коннектор Supabase, готовый код выгружается в GitHub.

Складской учёт это не список товаров. Это журнал операций, из которого остаток вычисляется, а не хранится. Разница определяет, будет приложение полезным или превратится в таблицу с кнопками.

Когда таблица перестаёт справляться?

В момент, когда с одним файлом начинают работать двое. Пока склад ведёт один человек, электронная таблица честно выигрывает: она быстрее, гибче и ничего не стоит. Ломается она на конкурентном доступе и на истории.

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

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

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

Что написать в промпте?

Билдер придумает раскладку экранов и оформление. Модель данных и правила операций он не угадает, поэтому их надо назвать прямо. Ключевая фраза здесь про журнал операций.

Сделай веб-приложение «учёт склада».
Сотрудники входят по почте. Роли: кладовщик и менеджер.
Товар: название, артикул, единица измерения, категория,
место хранения (стеллаж и полка), минимальный остаток.
Операции: приход, расход, перемещение, инвентаризация.
У каждой операции: товар, количество, дата, автор, комментарий.
Остаток НЕ хранится полем, а считается как сумма операций
по товару.
Экран «Товары»: список с текущим остатком, поиск по названию
и артикулу, фильтр по категории и месту.
Экран «Операция»: быстрая форма прихода и расхода в два поля.
Экран «Журнал»: все операции по дате с фильтром по товару
и сотруднику.
Экран «Ниже минимума»: товары, у которых остаток меньше
минимального.
Тон интерфейса: плотный, рабочий, крупные кнопки под телефон.

Фразу про то, что остаток считается из операций, не выбрасывайте. Без неё вы получите поле «количество», которое кто-то будет править руками, и через месяц вернётесь ровно к проблеме таблицы.

Какие экраны нужны и что на них?

Экран операции должен быть самым быстрым. Кладовщик вводит движение стоя, с телефона, часто одной рукой, и любой лишний шаг приводит к тому, что операцию отмечают «потом», а потом не отмечают вовсе.

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

Где хранить данные и как пускать сотрудников?

Коннектор Supabase здесь не опция, а основа. Он даёт настоящую базу Postgres и вход по почте под вашим аккаунтом: журнал операций живёт в ваших таблицах, вы можете смотреть его через дашборд, делать SQL-выгрузки и не зависеть от подписки на один инструмент.

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

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

Экспорт кода в GitHub стоит сделать сразу, как только приложением начали пользоваться всерьёз. Данные ваши в Supabase, код ваш в репозитории, и ни то, ни другое не зависит от подписки: подробности в статье экспорт приложения в GitHub.

Сколько это стоит в кредитах?

Free даёт 5 кредитов, чего не хватает на одну полную сборку: это способ посмотреть на процесс. Pro стоит $25 в месяц и даёт 200 кредитов, Business стоит $99 в месяц.

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

Как доводить учёт под свой процесс?

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

Каждое изменение это одна правка за 3 кредита: «добавь товару поле „срок годности" и покажи в списке позиции, у которых он истекает в ближайшие тридцать дней». Очень специфичная логика доводится именно так, серией правок, а не одним огромным промптом.

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

Как провести первую инвентаризацию в приложении?

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

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

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

После первой инвентаризации станет ясно, каких полей не хватает. Чаще всего выясняется, что нужно место хранения точнее, чем «склад», и что у части позиций есть единица измерения, которая не сводится к штукам. Оба изменения это по одной правке за 3 кредита.

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

Где ИИ-билдер упрётся?

• Сканирование штрихкодов. Работа с камерой и сканером через браузер ограничена. Полноценный терминал сбора данных это отдельная задача и другое оборудование.
• Обмен с бухгалтерской системой. Выгрузка накладных в конкретную учётную программу по её API это работа разработчика. Код проекта выгружается в GitHub и передаётся ему.
• Партионный учёт и себестоимость. FIFO, средневзвешенная, резервы под заказы: собрать можно, но это долгая серия правок, и промышленную систему это не заменит.
• Офлайн-работа. Склад без стабильного интернета требует локального хранения и синхронизации, а это осознанная архитектура, а не один промпт.

Zugo не заменяет команду разработки на большом складском продукте. Он закрывает первый этап: рабочий журнал операций с ролями и историей за минуту вместо месяца.

С чего начать?

Соберите версию с двумя экранами: список товаров с остатком и быстрая форма операции. Заведите двадцать реальных позиций и поработайте неделю. Через неделю вы точно назовёте три недостающих поля, и это знание точнее любого списка требований, придуманного заранее.

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