Разберем, как спроектировать веб-приложение для выдачи спецодежды: карточка сотрудника, складская выдача, сроки носки, напоминания о замене и акт списания.
Учет спецодежды кажется простым, пока не нужно быстро ответить на два вопроса: кому и что выдали, и когда это пора менять. Если ответы ищутся в тетради, Excel и переписках, ошибки становятся нормой. В итоге страдают и люди (не тот размер, нет в наличии), и компания (лишние закупки, штрафы, споры).
Проблема обычно не в отсутствии данных. Они есть, но разъезжаются по разным местам и быстро теряются: размеры меняются, даты выдачи записывают «примерно», остатки на складе не сходятся с фактом, а подписи и подтверждения лежат отдельно или вообще отсутствуют. Потом сложно доказать, что именно выдали, на какой срок носки и почему предмет списан.
Если вы делаете систему для выдачи спецодежды, начните с того, что дает быстрый эффект и реже ломается:
Печатные формы, сложные правила по профессиям, интеграции и расширенные отчеты лучше добавлять позже, когда базовый контур стабильно работает.
Обычно в процесс вовлечены несколько ролей. Кладовщик фиксирует выдачу и остатки. HR поддерживает актуальные данные сотрудников и переводов. Специалист по охране труда следит за нормами и сроками носки. Руководитель смотрит, где риски и перерасход.
Типовая ситуация: сотрудника перевели в другой цех, а размер в старой таблице не обновили. На складе выдали не тот размер, возврат не оформили, остатки «поплыли», а через три месяца никто не помнит точную дату выдачи. Система должна предотвращать это за счет одного источника правды и понятных подсказок: что нужно сделать сейчас, чтобы не было проблем потом.
Чтобы приложение не превратилось в «вечную доработку», начните с простой модели данных и только потом добавляйте автоматизацию. Практичный ориентир: любой документ должен отвечать на три вопроса - кому выдали, что именно, с какого склада и из какой партии.
Для большинства задач хватает пяти сущностей: сотрудник, склад (и остатки), номенклатура, выдача, списание.
Карточка сотрудника не должна превращаться в анкету на десятки полей. Держите только то, что реально нужно для выдачи и контроля сроков: уникальный идентификатор (табельный номер или другой), ФИО, подразделение, должность и набор размеров. Размеры лучше хранить раздельно по типам, а не одной строкой: рост, размер одежды, обуви, перчаток, головного убора. Тогда вы сможете подбирать позиции и строить отчеты без ручных проверок.
В номенклатуре важны поля, которые помогают избегать путаницы на складе: название, единица учета (шт, пара, комплект), срок носки и размерный ряд. Если один и тот же «Костюм летний» бывает в разных размерах, не «зашивайте» размер в название. Проще хранить размер как вариант (атрибут) и вести остатки по размерам корректно.
Связка «выдача - склад - партия» закрывает главный спорный момент: что именно ушло со склада. В выдаче фиксируйте сотрудника, дату, склад, позицию, размер, количество и партию (или конкретный приход). Например: выдали Иванову И.И. ботинки 42 размера со склада №1 из прихода от 12.01, 1 пару. Это пригодится и для плановой замены, и для списания.
Размеры - первая точка, где учет быстро превращается в хаос: один пишет «52-54», другой «52», третий «L». В системе лучше сразу заложить правило: размеры храним в едином формате и только из справочников, а любые пояснения уводим в комментарии.
Сначала определите, какие параметры вам действительно нужны. Чаще всего хватает базового набора: одежда (размер и рост, если используете), обувь, перчатки, головной убор. Если есть нюансы посадки, добавьте короткое примечание вроде «любит свободнее», но не превращайте это в «второй справочник».
Чтобы избежать каши, не делайте одно поле «Размер». Используйте связку «тип размера» + «значение»: типы вроде «обувь», «перчатки», «куртка», а значения - строго из заранее созданного списка. Это дает два результата: меньше ошибок при вводе и нормальные отчеты (например, сколько пар 42 размера нужно заложить в закупку).
Дисциплина данных, которая реально спасает:
Если у сотрудника разные размеры для летних и зимних комплектов, храните не «один размер на человека», а профили по категориям. Это нормально и часто встречается.
Еще одна полезная мелочь: разделяйте «размер на примерке» и «размер выдан». Добавьте короткое поле «почему отличается». Тогда, если выдали куртку на размер больше из-за посадки, это будет объяснимо и для склада, и для охраны труда.
Логика выдачи чаще всего ломается, когда пытаются смешать «план» и «факт». Удобнее держать два слоя: остаток и резерв. Остаток показывает, сколько реально лежит на складе. Резерв - сколько уже «занято» под будущую выдачу, но еще не отдано.
Простой вариант: хранить фактический остаток по каждой позиции и размеру, а резерв считать из выдач в статусе «черновик». Так не нужна отдельная таблица резерва и меньше риск рассинхронизации.
Выдача в интерфейсе должна занимать минуту. Поля, без которых не обойтись: позиция, размер, количество, дата, склад (если их несколько) и сотрудник. Размер всегда выбирается из справочника, а не вводится руками, иначе очень быстро появятся дубликаты вроде «50-52», «50/52» и «50-52 рост 176».
Основание выдачи лучше фиксировать типом операции. Обычно достаточно трех:
Статусы тоже нужны, но только те, которые реально помогают. Чаще всего хватает четырех: «черновик» (создает резерв), «выдано» (уменьшает остаток), «отменено» (снимает резерв или откатывает операцию), «возвращено» (если учитываете возврат на склад).
Чтобы система не была «табличкой ради таблички», сроки носки должны считаться одинаково для всех. Самое важное - договориться, от какой даты идет расчет и где живут правила.
Есть два частых варианта: от даты выдачи или от даты ввода в эксплуатацию. Если выдают и сразу начинают носить, проще считать от выдачи. Если бывает «выдали заранее», полезно фиксировать отдельную дату начала использования.
Практичное правило: храните обе даты, а расчет делайте по «в эксплуатации». Если она пустая, берите дату выдачи.
Срок носки удобнее хранить как число + единицу измерения (дни или месяцы), привязанную к позиции номенклатуры. Не пытайтесь сразу описать все исключения сложными формулами.
Если у вас есть сезонность и условия (лето/зима, улица/помещение, обычные/вредные), оформляйте это как понятные категории. Важно помнить: «6 месяцев» зимой и «один зимний сезон» - не одно и то же. Если реально работает сезонный учет, лучше считать по датам сезона, а не просто прибавлением месяцев.
Сроки и замена должны считаться по каждой вещи отдельно. Куртка, брюки, ботинки, перчатки - это разные позиции с разными сроками. Поэтому выдачу фиксируйте строками: одна строка - одна позиция, один размер, один срок.
Досрочную замену оформляйте новой выдачей с причиной. Старую запись не переписывайте. Тогда видно, что произошло, как часто это повторяется по модели или участку, и где проблема в закупке или условиях труда.
Напоминания работают только тогда, когда понятно: кому они приходят, что именно нужно сделать и где это отметить. Разведите роли: сотрудник подтверждает получение, склад готовит выдачу, охрана труда контролирует просрочки, руководитель получает сигнал, если ситуация затягивается.
Практичный минимум - три сценария: предупреждение заранее, напоминание в день замены и просрочка.
Рабочая формула: что заменить + где и когда + что сделать дальше. Не пишите «пора обновить СИЗ» без деталей.
Примеры:
В интерфейсе рядом с уведомлением полезно иметь простое действие: «Оформить выдачу», «Отложить» (с причиной), «Сообщить о нехватке».
Чтобы не спамить и разбирать спорные случаи, ведите журнал отправок: получатель, сценарий (14 дней, день замены, просрочка), объект (конкретная выданная позиция), дата/канал, статус и ключ уникальности (например, сотрудник + выдача + тип + дата). Перед отправкой система проверяет, не отправлялось ли уже такое уведомление.
Списание лучше оформлять отдельным документом, а не «править задним числом» выдачи. Так сохраняется история: кто носил, сколько времени, что именно списали и почему.
Акт списания нужен не только «когда порвалось». Частые случаи: естественный износ, порча (масла, кислоты, прожоги), утрата, смена должности или условий, когда комплект больше не подходит и его нельзя вернуть в оборот.
Чтобы акт был полезным, в нем должны быть ответы на три вопроса: что списали, по какой причине и кто подтвердил. Обычно достаточно:
Частая ошибка - списывать «со склада» без связи с реальной выдачей. Правильнее привязывать строки акта к конкретным выдачам сотруднику (или к конкретному экземпляру, если ведете учет по серийным номерам). Тогда нельзя списать больше, чем реально выдано, и всегда видно, у кого вещь была на момент списания.
Отдельно разделяйте возврат и списание. Возврат возвращает вещь в оборот и увеличивает складской остаток. Списание выводит вещь из оборота навсегда. Если после возврата комиссия решила списать вещь, это делается отдельным шагом с понятной причиной.
Чтобы система не превратилась в «монстра», держите фокус на минимальном наборе функций и доведите его до работы на реальных данных. Логика учета почти всегда одна: кто получил, что именно, на какой срок, и что делать, когда срок вышел.
Сначала договоритесь о правилах, а уже потом рисуйте экраны. Иначе каждый отдел будет «добавлять еще одно поле», и вы застрянете.
Не ждите идеала. Возьмите 5-10 реальных сотрудников из разных подразделений и прогоните типовые случаи: выдача по размеру, замена раньше срока, ошибка в размере, списание порванной вещи. В системе должно быть видно, что именно произошло и почему: плановая замена это или внеплановая.
После теста обычно всплывают 2-3 правки: не хватает одного поля (например, «место хранения»), нужна защита от случайного списания, требуется печатная форма акта. Внесите правки, обучите 1-2 пользователей, назначьте дату перехода и ведите учет в одном месте, без параллельных таблиц.
Даже простая система становится источником споров, если в основе лежат «кривые» данные и нет связей между событиями.
Чаще всего учет ломают такие вещи:
Подстраховка простая: договоритесь о минимальных правилах данных до массового ввода. Размеры - в справочник. Табельный номер (или другой уникальный ключ) - обязательный. Каждое действие должно ссылаться на предыдущее: выдача, потом возврат/отмена/списание, без редактирования «задним числом».
Перед запуском важна не «красота интерфейса», а то, что учет не ломается на реальных сценариях: новые сотрудники, смена размеров, отмена выдачи, пересчет сроков, списание.
Если все сходится, запускайте пилот на одном складе и одном подразделении. Так вы поймаете «живые» проблемы без массового сбоя.
Дальше улучшения добавляйте по очереди, чтобы не потерять контроль: роли и права (особенно на списание и правку задним числом), отчеты по просрочкам и ближайшим заменам, шаблоны причин и комментариев, уведомления по понятным правилам.
Если хотите быстро собрать MVP и обкатать процесс на пилоте, это удобно делать на TakProsto (takprosto.ai): можно набросать сущности и экраны через чат, а потом постепенно добавлять правила сроков, напоминания и документы списания. При необходимости исходный код можно экспортировать и развивать дальше уже силами команды.
