Разработка локальной веб-системы учета расходных материалов

Введение

Эффективное управление расходными материалами является важной частью повседневной деятельности организаций, в которых одновременно выполняются хозяйственные, санитарные и обслуживающие процессы. Перчатки, маски, средства гигиены, салфетки, моющие средства, бумага и другие позиции расходуются регулярно, поэтому даже небольшая ошибка в учете может привести к несвоевременному пополнению запасов. Потребность в материалах изменяется в зависимости от числа проживающих, режима ухода, графика уборки и других факторов. Следовательно, простой перечень остатков без истории движения не обеспечивает необходимой прозрачности учета [1, 2].

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

Целью исследования является разработка локальной веб-системы учета расходных материалов, обеспечивающей единый источник данных, регистрацию движения материалов, контроль минимальных остатков и подготовку заявок на пополнение. Для достижения цели необходимо проанализировать предметную область, определить функциональные требования, спроектировать структуру данных и архитектуру, реализовать программный прототип и проверить его работоспособность.

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

Результаты исследования

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

Ключевой элемент системы — журнал движения. Каждая операция содержит идентификатор расходного материала, тип движения, количество, остаток после операции, дату, документ и комментарий; при необходимости указывается получатель материала. Благодаря этому изменение складского остатка становится проверяемым: пользователь может определить, какая операция изменила состояние конкретной позиции. Подобный принцип соответствует общим подходам к проектированию информационных систем и реляционных баз данных [3, 4].

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

Таблица 1

Сравнение вариантов автоматизации учета

Архитектура разработанного решения построена по принципу локального веб-приложения. Пользователь работает через браузер, серверная часть принимает HTTP-запросы и обращается к базе данных SQLite. Клиентская часть реализована средствами HTML, CSS и JavaScript. Такой вариант объединяет простоту локального запуска с возможностью разделить интерфейс, прикладную логику и хранение данных. Серверная часть реализована на Python с использованием стандартных библиотек, что уменьшает количество внешних зависимостей и упрощает перенос проекта [5, 6].

SQLite выбран в качестве хранилища, поскольку база размещается в одном файле и не требует отдельной службы СУБД. Для демонстрационной и локальной системы это существенно упрощает развертывание. При этом SQLite поддерживает SQL-запросы, внешние ключи и транзакции, необходимые для сохранения целостности данных [7]. Ограничением выбранного решения является невозможность ориентироваться на высокую многопользовательскую нагрузку, поэтому система рассматривается как локальный прототип, а не как промышленная распределенная платформа.

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

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

Практическая реализация включает серверный файл app.py, пользовательскую страницу index.html, клиентский сценарий static/app.js, таблицу стилей static/styles.css и локальную базу database.sqlite. Интерфейс разделен на рабочие области «Склад», «Постояльцы», «Движение», «Заявки» и «Отчет». Такое разделение соответствует последовательности ежедневных операций и позволяет пользователю быстро находить нужное действие.

Тестирование проводилось на уровне API и пользовательского интерфейса. Проверялись запуск сервера, открытие главной страницы, загрузка справочников, создание расходного материала, проведение списания, запрет списания сверх остатка, формирование заявки по низким остаткам и защита статических путей. Использовались автоматический smoke-тест, ручной просмотр интерфейса и контроль API. Основные сценарии были выполнены успешно: главная страница возвращала код 200, справочник загружался, новая запись создавалась, некорректное списание отклонялось, заявка формировалась, а обращение к защищенному пути блокировалось [8].

Таблица 2

Результаты функциональной проверки

Информационная безопасность рассматривается с учетом локального режима работы и наличия сведений о проживающих. Приложение не публикуется в интернет и доступно по локальному адресу, что уменьшает сетевую поверхность атаки. Вместе с тем должны соблюдаться базовые меры защиты файловой системы: ограничение доступа к рабочей папке, резервное копирование базы и отказ от использования реальных персональных данных при учебной демонстрации. На уровне приложения применяются параметризованные SQL-запросы и проверка пользовательского ввода. Такой набор мер соответствует базовым принципам защиты информационных систем и рекомендациям по безопасности веб-приложений [9, 10].

Перспективными направлениями развития являются добавление авторизации, разграничения ролей администратора и обычного сотрудника, журнала действий, поставщиков, печатной формы заявки и инструментов резервного копирования. При переходе от учебного прототипа к реальной эксплуатации потребуется также усилить требования к защите персональных данных и регламентировать порядок работы с резервными копиями [11].

Заключение

В результате исследования разработана локальная веб-система учета расходных материалов, объединяющая справочник материалов, журнал движения, контроль минимального остатка, формирование заявок и отчетные показатели. Выбранная архитектура на базе Python, HTML, CSS, JavaScript и SQLite позволяет запускать приложение без отдельного сервера и демонстрировать полный цикл учета на одном рабочем компьютере.

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