Пошагово разбираем, как сделать веб-приложение для учета инструмента: сущности, выдача и возврат, залоги, фотофиксация состояния и напоминания.
Когда учет ведется в тетради или таблице, проблемы повторяются по кругу: инструмент «теряется» между людьми и объектами, по возврату начинаются споры «так и было» про царапины и поломки, а про просрочку вспоминают слишком поздно. Веб-приложение для учета инструмента решает это не «умными алгоритмами», а понятными правилами: кто взял, что именно, в каком состоянии и когда должен вернуть.
Такой учет нужен не только прокату. Он одинаково полезен складу и кладовщику, сервисной бригаде на выездах, небольшому производству, где один набор ходит по сменам, и мастерской, где инструмент постоянно передают из рук в руки.
Для первого релиза не пытайтесь закрыть все сразу. Достаточно операций, которые дают большую часть эффекта:
Сразу фиксируйте то, что потом трудно восстановить: идентификатор инструмента или комплекта, ответственного, место, срок возврата, залог (если есть), а также состояние до и после. «Приятные дополнения» лучше отложить: расширенные отчеты, сложные роли, интеграции, автоматические расчеты износа.
Пример из жизни: бригада берет перфоратор на объект на 3 дня. Без учета в четверг никто не помнит, у кого он. С учетом видно: кто взял, до какого срока, и есть фото состояния при выдаче и возврате.
Чтобы веб-приложение для учета инструмента не превращалось в хаос, заранее договоритесь, что считается единицей учета и какие данные фиксируются всегда. Эти сущности лучше завести отдельно (справочники и документы), а не хранить «все в одном комментарии».
Инструмент - это конкретная вещь, которую можно выдать, вернуть, потерять или списать. У нее должен быть уникальный идентификатор, чтобы не путать похожие позиции.
Комплект (набор) - это группа инструментов, которую удобно выдавать целиком (например, «набор электрика»). Важно хранить состав набора и правила: какие элементы обязательны, какие допускают замену, и что считать «неполным возвратом».
Минимального набора полей обычно достаточно:
Состояние удобнее вести отдельной записью осмотра. Тогда появляется история: когда и кем зафиксировано, что именно было не так, и какие фото приложены. Часто хватает короткой шкалы (например, «как новый», «нормальный износ», «поврежден»), а детали храните в описании дефектов.
Залог - это не просто сумма, а обязательство со статусами: внесен, удержан частично, возвращен, удержан полностью. В карточке залога обычно нужны сумма и валюта, способ внесения (наличные, перевод), привязка к конкретной выдаче и отметка о возврате.
В учете полезно разделять два слоя: операции (что люди делают) и события (что система фиксирует в истории). Операции простые: выдать, принять назад, отправить напоминание. События нужны для разборов, когда возник спор.
Роли лучше обозначить сразу, потому что они определяют ответственность. Во многих командах хватает трех: кладовщик оформляет выдачу и возврат, мастер получает инструмент и отвечает за срок, админ настраивает правила и смотрит отчеты. Если кладовщика нет, роли можно объединить, но в журнале все равно должна оставаться отметка, кто выдал и кто принял.
Выдача - это запись, где понятно: кому, что и на каких условиях. Минимум: получатель, список инструментов или комплект, дата и время, срок возврата, кто выдал. Часто добавляют комментарий (например, «на объект Пушкина, 12») и сумму залога, если он берется именно в момент выдачи.
Возврат фиксирует фактическую дату, кто принял и что именно вернулось. Важно поддержать расхождения сразу: не вернули часть комплекта, вернули другой серийный номер, появился дефект, не хватает расходника. В таких случаях фиксируйте причину и решение по залогу: вернуть полностью, удержать часть, удержать до выяснения.
Пример: мастер вернул перфоратор вовремя, но без кейса. В возврате отмечается расхождение и удержание из залога за утерю.
Напоминание лучше хранить как событие, а не как «отправленное сообщение». Тогда видно причину (скоро срок, просрочка, не закрыта выдача), дату отправки, канал (SMS, мессенджер), статус (запланировано, отправлено, ошибка, прочитано). Это помогает понять, почему люди «не получали» уведомления и какие правила реально работают.
Чтобы веб-приложение для учета инструмента выдерживало спорные случаи, начните с простой, но честной модели: отдельно справочники (что у вас есть) и отдельно события (что произошло).
Базовый набор таблиц обычно такой:
Заложите важную связь: один и тот же инструмент может входить в комплект, но иногда его выдают отдельно. Поэтому выдача должна уметь ссылаться либо на комплект, либо на отдельный инструмент. А состав комплекта при выдаче лучше фиксировать как фактический (чтобы потом не спорить, что именно было внутри в тот день).
Историю состояния не перезаписывайте. Делайте отдельные осмотры («осмотр при выдаче», «осмотр при возврате») с заметкой и фото. Тогда видно, когда появилась царапина и кто ее заметил.
Статусы держите простыми: на складе, выдан, на ремонте, списан.
Чтобы веб-приложение для учета инструмента не превратилось в набор разрозненных таблиц, начните с четырех экранов. Они закрывают большую часть ежедневных задач: найти предмет, понять его текущее состояние, выдать и принять обратно.
Список нужен для быстрого поиска по номеру, названию или штрихкоду. Важно, чтобы он отвечал не только «что есть», но и «где это сейчас».
Хватает поиска, фильтров по статусу, быстрых действий («выдать», «принять», «карточка») и индикатора просрочки, если срок возврата уже прошел.
Карточка нужна, когда возник спор или нужно принять решение. Здесь должны быть фото, текущее состояние, активная выдача (если есть) и история: кому, когда, на какой срок, с какими комментариями и снимками.
Экран выдачи делайте коротким: выбрать инструмент или комплект, указать срок, залог и человека, который берет. В конце - подтверждение и фиксация стартового состояния (обычно хватает 1-2 фото и короткой заметки).
Возврат удобнее делать как маленький осмотр: чек по ключевым пунктам (целостность, комплектность, работоспособность), фото, комментарий. После финализации система обновляет статус, закрывает выдачу и фиксирует решение по залогу.
Если вы собираете веб-приложение для учета инструмента через чат, начните с простого: кто и что может делать. Обычно есть кладовщик (выдает и принимает), руководитель (видит отчеты, решает спорные случаи) и сотрудник (получает и подтверждает возврат).
Дальше зафиксируйте сущности и поля, чтобы в формах ничего не потерялось. Для операций «Выдача» и «Возврат» сразу задайте обязательные поля, статусы и ограничения (например, нельзя выдать инструмент, который уже «на руках»).
Проверьте, что через формы проходит минимальный набор данных:
Затем соберите две формы: «Выдача» и «Возврат». В требованиях сразу перечислите проверки: обязательные поля, запрет на отрицательное количество, предупреждение при просрочке, подтверждение при смене состояния на «повреждено». Если есть сомнения, добавьте черновик операции и отдельную кнопку «Подтвердить».
В конце добавьте журнал операций. Важно, чтобы из карточки инструмента открывалась история: выдачи, возвраты, залоги, изменения состояния - с автором и временем. На тестах удобно пользоваться снапшотами и откатом, если вы поменяли логику и получили лишние статусы.
Фото в учете инструмента нужны не для красоты, а чтобы закрывать споры: что выдали, в каком виде вернули, и когда появилась царапина или скол. Если фото делаются по одним правилам, люди меньше спорят и быстрее принимают возврат.
Обычно снимают:
Фото делайте при выдаче и при возврате обязательно. Плюс отдельный осмотр при ремонте или списании, чтобы зафиксировать причину и состояние до и после.
Хранение проще строить через сущность «осмотр»: у осмотра есть дата и автор, он привязан к операции (выдача или возврат), и к нему прикреплены фото. Тогда вы открываете операцию и сразу видите снимки «до» и «после», а не ищете файлы по папкам.
Минимум: загрузка нескольких фото, предпросмотр, комментарий и обязательность фото при дефектах. Например, если при возврате выбран статус «есть дефекты», фото становится обязательным.
Залог работает только тогда, когда его правила понятны до выдачи. В веб-приложении для учета инструмента залог лучше вести как отдельную сущность: кто внес, за что, сколько, и при каких условиях деньги возвращаются.
Проще выбрать один подход и закрепить его в настройках:
Если у вас есть и инструмент, и комплект, продумайте, как не брать залог дважды. Частый вариант: у комплекта залог основной, а у инструментов внутри залог равен нулю, пока они выданы как часть комплекта.
Чтобы не было споров, у залога должны быть понятные статусы: внесен, к возврату, возвращен, удержан частично, удержан полностью. Удержание привязывайте к осмотру и конкретным фактам.
Для операции по залогу обычно хватает: суммы и способа внесения, суммы удержания, короткой причины, подтверждения (кто решил и когда), и ссылки на осмотр (фото и комментарий).
Пример: выдали набор с перфоратором и двумя аккумуляторами, залог 3000 ₽. При возврате один аккумулятор вздулся. Осмотр фиксирует фото и комментарий, удержали 1200 с причиной, остальное вернули.
Напоминания работают, если они предсказуемы и не превращаются в спам. Начните с трех моментов и не усложняйте, пока процесс не приживется:
Кому отправлять зависит от стадии. До срока обычно достаточно получателя. В день срока можно добавить кладовщика, чтобы он видел нагрузку. После просрочки подключайте руководителя, но только если просрочка реальная (например, больше 2 дней) и нет отметки о продлении.
Текст напоминания должен отвечать на три вопроса: что, когда и что делать дальше. Минимум: что выдано (инвентарный номер), срок и величина просрочки (если есть), действие («Продлить», «Запросить перенос»), контакт для вопросов, и статус залога, если он влияет на возврат.
Чтобы настроить это без сложной автоматизации, держите правило в виде таблицы (срок, уровень эскалации, частота) и запускайте один ежедневный процесс, который ищет выдачи со сроком «завтра/сегодня/просрочено».
Представим мастерскую, где есть комплект «Перфоратор SDS+». Внутри: перфоратор (серийный номер), кейс, 2 аккумулятора, зарядка и набор буров. Для элементов хранится состояние (например, «исправен», «есть царапины», «скол») и фото.
Мастер Иван берет комплект на объект на 2 дня. Сотрудник на выдаче открывает карточку, проверяет список, делает 2-3 фото (общий вид и крупно кейс/корпус) и фиксирует стартовое состояние. Залог ставят 3000 ₽ со статусом «принят».
Иван возвращает вовремя, но одного аккумулятора нет, а на кейсе трещина. Это лучше фиксировать не словами, а конкретными фактами:
Если Иван просит продлить срок на 1 день, он делает запрос, а подтверждает ответственный (кладовщик или руководитель). В истории должно быть видно: кто продлил, на сколько и почему.
После этого кейс переводится в «ремонт», а комплект получает запрет на выдачу, пока не закрыли недостачу или ремонт. В крайних случаях элемент помечают как «списан», чтобы он не появлялся в новых выдачах.
Основные проблемы начинаются не с интерфейса, а с доказательств. Когда через месяц возникает спор, важны точные записи: что выдали, в каком виде, кто принял и что решили по залогу.
Чаще всего ломают процесс так:
Небольшой пример: сотрудник вернул набор в пятницу вечером, а в понедельник обнаружили, что не хватает головки на 10 мм. Если нет записи «кто принял» и фото именно в момент возврата, спор превращается в догадки.
Простое правило, которое держит систему в форме: каждое действие создает событие, у события есть ответственные, статус и сумма залога (если он есть), а также фото и комментарии осмотра.
Перед первым рабочим днем договоритесь о правилах: кто может выдавать инструмент, где он хранится, и что считается «нормальным состоянием». Чем яснее договоренности, тем меньше спорных случаев.
Проверьте перед запуском:
Практический тест: сделайте контрольную выдачу на 1-2 инструмента, затем возврат с небольшим отличием (например, царапина или отсутствующая насадка) и убедитесь, что процесс ведет вас по шагам и ничего не дает забыть.
Чтобы запустить учет без месячной подготовки, начните с минимума: поля и статусы, которые реально используют кладовщик и мастер. Если о поле спорят больше часа, оно почти наверняка лишнее для первого релиза.
Для старта достаточно четырех экранов:
Дальше развивайте систему только по факту реальной боли. Если начали теряться мелкие позиции в наборах - добавляйте QR-метки и сканирование. Если руководителю нужны цифры - делайте отчеты. Если много филиалов - думайте об интеграциях.
Если вам подходит формат сборки через диалог, TakProsto (takprosto.ai) позволяет описать сущности и сценарии словами и собрать первые экраны в режиме планирования. А когда логика стабилизируется, полезны экспорт кода, развертывание и хостинг, кастомные домены и снапшоты с откатом - чтобы безопасно менять правила выдачи, возврата и залога без остановки работы.
