Веб-приложение для выдачи спецодежды: учет и списание

Какая боль у учета спецодежды и что нужно закрыть

Учет спецодежды кажется простым, пока не нужно быстро ответить на два вопроса: кому и что выдали, и когда это пора менять. Если ответы ищутся в тетради, Excel и переписках, ошибки становятся нормой. В итоге страдают и люди (не тот размер, нет в наличии), и компания (лишние закупки, штрафы, споры).

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

Что важно закрыть в первую очередь

Если вы делаете систему для выдачи спецодежды, начните с того, что дает быстрый эффект и реже ломается:

• карточка сотрудника (ФИО, подразделение, должность, размеры, нормы выдачи);
• выдача со склада (что, сколько, когда, кому и кто выдал);
• учет остатков (приход, расход, текущий остаток);
• сроки носки и даты замены (чтобы видеть просрочки и «что горит»).

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

Кто реально будет пользоваться системой

Обычно в процесс вовлечены несколько ролей. Кладовщик фиксирует выдачу и остатки. HR поддерживает актуальные данные сотрудников и переводов. Специалист по охране труда следит за нормами и сроками носки. Руководитель смотрит, где риски и перерасход.

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

С чего начать: данные и структура без усложнений

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

Для большинства задач хватает пяти сущностей: сотрудник, склад (и остатки), номенклатура, выдача, списание.

Карточка сотрудника не должна превращаться в анкету на десятки полей. Держите только то, что реально нужно для выдачи и контроля сроков: уникальный идентификатор (табельный номер или другой), ФИО, подразделение, должность и набор размеров. Размеры лучше хранить раздельно по типам, а не одной строкой: рост, размер одежды, обуви, перчаток, головного убора. Тогда вы сможете подбирать позиции и строить отчеты без ручных проверок.

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

Связка «выдача - склад - партия» закрывает главный спорный момент: что именно ушло со склада. В выдаче фиксируйте сотрудника, дату, склад, позицию, размер, количество и партию (или конкретный приход). Например: выдали Иванову И.И. ботинки 42 размера со склада №1 из прихода от 12.01, 1 пару. Это пригодится и для плановой замены, и для списания.

Размеры: как хранить и не запутаться

Размеры - первая точка, где учет быстро превращается в хаос: один пишет «52-54», другой «52», третий «L». В системе лучше сразу заложить правило: размеры храним в едином формате и только из справочников, а любые пояснения уводим в комментарии.

Сначала определите, какие параметры вам действительно нужны. Чаще всего хватает базового набора: одежда (размер и рост, если используете), обувь, перчатки, головной убор. Если есть нюансы посадки, добавьте короткое примечание вроде «любит свободнее», но не превращайте это в «второй справочник».

Чтобы избежать каши, не делайте одно поле «Размер». Используйте связку «тип размера» + «значение»: типы вроде «обувь», «перчатки», «куртка», а значения - строго из заранее созданного списка. Это дает два результата: меньше ошибок при вводе и нормальные отчеты (например, сколько пар 42 размера нужно заложить в закупку).

Дисциплина данных, которая реально спасает:

• один формат на тип (например, обувь только число, без «р-р» и без диапазонов);
• исключения - в комментарий, а не в справочник;
• историю не перетираем: меняем значения через новую запись с датой.

Если у сотрудника разные размеры для летних и зимних комплектов, храните не «один размер на человека», а профили по категориям. Это нормально и часто встречается.

Еще одна полезная мелочь: разделяйте «размер на примерке» и «размер выдан». Добавьте короткое поле «почему отличается». Тогда, если выдали куртку на размер больше из-за посадки, это будет объяснимо и для склада, и для охраны труда.

Выдача по складу: простая логика без лишних шагов

Логика выдачи чаще всего ломается, когда пытаются смешать «план» и «факт». Удобнее держать два слоя: остаток и резерв. Остаток показывает, сколько реально лежит на складе. Резерв - сколько уже «занято» под будущую выдачу, но еще не отдано.

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

Выдача в интерфейсе должна занимать минуту. Поля, без которых не обойтись: позиция, размер, количество, дата, склад (если их несколько) и сотрудник. Размер всегда выбирается из справочника, а не вводится руками, иначе очень быстро появятся дубликаты вроде «50-52», «50/52» и «50-52 рост 176».

Основание выдачи лучше фиксировать типом операции. Обычно достаточно трех:

• первичная выдача (новому сотруднику или по нормам);
• замена по сроку носки (плановая);
• внеплановая замена (порча, утеря, перевод, смена условий).

Статусы тоже нужны, но только те, которые реально помогают. Чаще всего хватает четырех: «черновик» (создает резерв), «выдано» (уменьшает остаток), «отменено» (снимает резерв или откатывает операцию), «возвращено» (если учитываете возврат на склад).

Сроки носки и замена: правила расчета, которые работают

Чтобы система не была «табличкой ради таблички», сроки носки должны считаться одинаково для всех. Самое важное - договориться, от какой даты идет расчет и где живут правила.

От какой даты считать следующую замену

Есть два частых варианта: от даты выдачи или от даты ввода в эксплуатацию. Если выдают и сразу начинают носить, проще считать от выдачи. Если бывает «выдали заранее», полезно фиксировать отдельную дату начала использования.

Практичное правило: храните обе даты, а расчет делайте по «в эксплуатации». Если она пустая, берите дату выдачи.

Как хранить срок носки, чтобы не путаться

Срок носки удобнее хранить как число + единицу измерения (дни или месяцы), привязанную к позиции номенклатуры. Не пытайтесь сразу описать все исключения сложными формулами.

Если у вас есть сезонность и условия (лето/зима, улица/помещение, обычные/вредные), оформляйте это как понятные категории. Важно помнить: «6 месяцев» зимой и «один зимний сезон» - не одно и то же. Если реально работает сезонный учет, лучше считать по датам сезона, а не просто прибавлением месяцев.

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

Досрочную замену оформляйте новой выдачей с причиной. Старую запись не переписывайте. Тогда видно, что произошло, как часто это повторяется по модели или участку, и где проблема в закупке или условиях труда.

Автоматические напоминания о замене: логика и тексты

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

Кого и когда уведомлять

Практичный минимум - три сценария: предупреждение заранее, напоминание в день замены и просрочка.

• За 14 дней: сотруднику и на склад, чтобы подготовить нужный размер.
• В день замены: сотруднику и складу, чтобы закрыть выдачу.
• Просрочка: сотруднику и охране труда; руководителю - если просрочка держится несколько дней.

Тексты уведомлений, по которым можно действовать

Рабочая формула: что заменить + где и когда + что сделать дальше. Не пишите «пора обновить СИЗ» без деталей.

Примеры:

• «Через 14 дней нужна замена: перчатки, размер M. Придите на склад до 12.02 и оформите выдачу».
• «Сегодня день замены: куртка зимняя, размер 50. Подтвердите получение после выдачи».
• «Просрочка 5 дней: каска, размер 58. Оформите замену или укажите причину (нет на складе, отпуск)».

В интерфейсе рядом с уведомлением полезно иметь простое действие: «Оформить выдачу», «Отложить» (с причиной), «Сообщить о нехватке».

Журнал отправок и защита от дублей

Чтобы не спамить и разбирать спорные случаи, ведите журнал отправок: получатель, сценарий (14 дней, день замены, просрочка), объект (конкретная выданная позиция), дата/канал, статус и ключ уникальности (например, сотрудник + выдача + тип + дата). Перед отправкой система проверяет, не отправлялось ли уже такое уведомление.

Списание: как оформить акт и не потерять историю

Списание лучше оформлять отдельным документом, а не «править задним числом» выдачи. Так сохраняется история: кто носил, сколько времени, что именно списали и почему.

Акт списания нужен не только «когда порвалось». Частые случаи: естественный износ, порча (масла, кислоты, прожоги), утрата, смена должности или условий, когда комплект больше не подходит и его нельзя вернуть в оборот.

Чтобы акт был полезным, в нем должны быть ответы на три вопроса: что списали, по какой причине и кто подтвердил. Обычно достаточно:

• даты и номера акта (и подразделения, если важно);
• причины списания и короткого комментария;
• состава комиссии (ФИО и роли);
• строк по позициям (номенклатура, размер, количество, состояние);
• основания (привязка к конкретной выдаче или инвентарной единице).

Частая ошибка - списывать «со склада» без связи с реальной выдачей. Правильнее привязывать строки акта к конкретным выдачам сотруднику (или к конкретному экземпляру, если ведете учет по серийным номерам). Тогда нельзя списать больше, чем реально выдано, и всегда видно, у кого вещь была на момент списания.

Отдельно разделяйте возврат и списание. Возврат возвращает вещь в оборот и увеличивает складской остаток. Списание выводит вещь из оборота навсегда. Если после возврата комиссия решила списать вещь, это делается отдельным шагом с понятной причиной.

Пошаговый план создания приложения: от первого экрана до запуска

Чтобы система не превратилась в «монстра», держите фокус на минимальном наборе функций и доведите его до работы на реальных данных. Логика учета почти всегда одна: кто получил, что именно, на какой срок, и что делать, когда срок вышел.

Что сделать за 1-2 недели

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

1. Зафиксируйте роли и ответственность: кто оформляет выдачу, кто задает нормы и сроки, кто согласует списание, кто контролирует просрочки.
2. Сведите обязательные поля в один список: сотрудник (идентификатор, ФИО, подразделение), складская позиция (наименование, размер, остаток), выдача (дата, количество, срок носки, дата следующей замены), списание (причина, акт, ответственные).
3. Сделайте 3-4 экрана: карточка сотрудника, склад/остатки, форма выдачи, список списаний.
4. Запишите правила: от какой даты считается замена, что считается просрочкой, когда допустима досрочная замена, какие причины списания разрешены.
5. Добавьте «сигналы»: напоминания о замене и простой отчет по просрочкам по подразделениям.

Тест на реальности и запуск

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

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

Частые ошибки и ловушки при учете спецодежды

Даже простая система становится источником споров, если в основе лежат «кривые» данные и нет связей между событиями.

Чаще всего учет ломают такие вещи:

• размеры хранят «как получится», и их невозможно фильтровать и сводить;
• у сотрудника нет стабильного идентификатора, из-за чего появляются дубли;
• списание живет отдельно от выдачи, история рвется;
• остатки расходятся с фактом из-за неверных возвратов, отмен и замен;
• напоминания уходят всем подряд, без фильтра по статусу сотрудника и по факту уже выполненной замены.

Подстраховка простая: договоритесь о минимальных правилах данных до массового ввода. Размеры - в справочник. Табельный номер (или другой уникальный ключ) - обязательный. Каждое действие должно ссылаться на предыдущее: выдача, потом возврат/отмена/списание, без редактирования «задним числом».

Чек-лист перед внедрением и следующие шаги

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

Чек-лист перед внедрением

• У каждого сотрудника заполнены ключевые размеры и есть поле для примечаний.
• У каждой позиции задан срок носки и понятное правило замены.
• Выдача уменьшает остаток, а отмена или возврат корректно возвращают остаток (проверьте на одном товаре несколько раз).
• Акт списания хранит причину, дату и ответственных, история сохраняется даже после исправлений.
• По сотруднику можно быстро увидеть: что выдано сейчас, что просрочено, что скоро под замену, что списано.

Если все сходится, запускайте пилот на одном складе и одном подразделении. Так вы поймаете «живые» проблемы без массового сбоя.

Следующие шаги после пилота

Дальше улучшения добавляйте по очереди, чтобы не потерять контроль: роли и права (особенно на списание и правку задним числом), отчеты по просрочкам и ближайшим заменам, шаблоны причин и комментариев, уведомления по понятным правилам.

Если хотите быстро собрать MVP и обкатать процесс на пилоте, это удобно делать на TakProsto (takprosto.ai): можно набросать сущности и экраны через чат, а потом постепенно добавлять правила сроков, напоминания и документы списания. При необходимости исходный код можно экспортировать и развивать дальше уже силами команды.