Внутренняя система учёта расходных материалов — SRS-сборка¶

Эта страница собирает разделы для спецификации требований к ПО: от контекста и проблемы до безопасности, качества и эксплуатации.

Содержание¶

Краткое описание
Контекст и проблема
Цели, требования и ограничения
Роль и обязанности
Модель системы
Архитектура и интеграции
Безопасность, качество и эксплуатация

Краткое описание¶

Статус¶

partial implementation / historical project

Роль¶

инициатор, автор концепции, разработчик прототипа

Стек¶

Тип: Internal automation / early ERP-like inventory system; Период: ранний этап перехода от администрирования инфраструктурой к разработке внутренних систем

Ценность проекта¶

Лёгкая внутренняя ERP-подобная система для учёта расходных материалов ИТ-отдела - остатки, история движения и планирование закупок.

Контекст и проблема¶

Контекст¶

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

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

Проблема¶

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

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

Цели, требования и ограничения¶

Цели и нецели¶

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

Требования¶

Система должна была позволять:

вести справочник расходников;
фиксировать поступления;
учитывать выдачу и списание;
видеть текущие остатки;
анализировать динамику потребления;
поддерживать планирование закупок;
снизить зависимость от ручного учёта и разрозненных таблиц.

Частично реализованный объём¶

Концепция внутренней системы учёта расходников.
Базовая структура справочников и операций.
Подход к фиксации поступлений и расхода.
Табличная модель для практического учёта.
Использование накопленных данных для планирования закупок.
Переход от хаотичного ручного учёта к более структурированной модели.

Ограничения¶

Роль и обязанности¶

Проект был начат как самостоятельная разработка с нуля, но не оформлен, как законченная ERP-система. Однако проект важен не как завершённый production-продукт, а как ранняя точка перехода от роли системного администратора к роли человека, который проектирует и создаёт прикладные ИТ-системы.

Модель системы¶

Доменная модель¶

В основе решения лежала простая, но прикладная доменная модель:

расходный материал;
тип расходника;
модель оборудования;
совместимость расходника и оборудования;
складской остаток;
поступление;
выдача;
списание;
подразделение или место использования;
история движения;
плановая потребность;
закупочная заявка или закупочная потребность.

Модель данных¶

Диаграмма классов¶

classDiagram
    class ConsumableItem {
      id
      name
      sku
      type_id
    }

    class ConsumableType {
      id
      name
    }

    class EquipmentModel {
      id
      vendor
      model
    }

    class StockMovement {
      id
      type
      quantity
      date
      item_id
      consumer_id
      comment
    }

    class Department {
      id
      name
    }

    class Place {
      id
      name
      department_id
    }

    class ConsumerEquipment {
      id
      name
      place_id
      model_id
    }

    ConsumableItem --> ConsumableType
    ConsumableType --> EquipmentModel
    StockMovement --> ConsumableItem
    StockMovement --> ConsumerEquipment
    ConsumerEquipment --> Place
    Place --> Department

API-контракты¶

Архитектура и интеграции¶

Архитектура¶

Архитектурный подход¶

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