Internal Consumables Accounting System — architecture review¶

This page assembles sections relevant to architecture review: goals, requirements, and constraints; system model; architecture and integrations; security, quality, and operations; and decisions, trade-offs, and risks.

Contents¶

Summary
Goals, Requirements, and Constraints
System Model
Architecture and Integrations
Security, Quality, and Operations
Decisions, Trade-offs, and Risks

Summary¶

Status¶

partial implementation / historical project

Role¶

initiator, concept author, prototype developer

Stack¶

Type: Internal automation / early ERP-like inventory system; Period: early transition stage from infrastructure administration to internal systems development

Project value¶

A lightweight internal ERP-like system for IT department consumables accounting - tracking stock levels, material movement history, and procurement planning.

What this demonstrates¶

ExpendIt demonstrates my early transition from an infrastructure-focused role to internal systems development and system analysis.

The project already contained elements that later became part of my professional profile:

analysis of a real operational pain point;
identification of domain entities;
an attempt to build an accounting model;
intention to replace a manual process with a structured system;
practical automation for internal users;
attention to data, operation history, and planning.

The project was not completed as a mature product, but it became an important step toward systems thinking, software development, and my later transition into systems analysis.

Goals, Requirements, and Constraints¶

Goals and Non-Goals¶

Create an internal tool for consumables accounting that would allow the IT department to track stock, record movements, and support procurement planning instead of manual spreadsheet accounting.

Requirements¶

The system was intended to allow the IT department to:

maintain a consumables directory;
record receipts;
account for issuance and write-offs;
view current stock levels;
analyze consumption dynamics;
support procurement planning;
reduce dependence on manual accounting and fragmented spreadsheets.

Partially implemented scope¶

Concept of an internal consumables accounting system.
Basic structure of directories and operations.
Approach to recording receipts and consumption.
Spreadsheet-based model for practical accounting.
Use of accumulated data for procurement planning.
Transition from chaotic manual accounting to a more structured model.

Constraints¶

System Model¶

Domain Model¶

The solution was based on a simple but practical domain model:

consumable item;
consumable type;
equipment model;
compatibility between consumables and equipment;
stock balance;
receipt;
issue;
write-off;
department or place of use;
movement history;
planned demand;
purchase request or procurement need.

Data Model¶

Class Diagram¶

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 Contracts¶

Architecture and Integrations¶

Architecture¶

Architectural Approach¶

The project was conceived as a layered modular monolith: application logic, data model, simple user interface, and persistence layer were intended to be separated by responsibility, but without premature architectural complexity.

Integration Flows¶

Security, Quality, and Operations¶

Security and Access Model¶

Non-Functional Requirements¶

Failure Modes¶

Sizing and Cost Notes¶

Decisions, Trade-offs, and Risks¶

Key Decisions¶

Trade-offs¶

Modular monolith without premature complexity¶

Application logic, data model, simple user interface, and persistence layer were separated by responsibility, avoiding distributed architecture and premature abstraction for an internal prototype.

Early prototype vs finished ERP¶

At the current maturity level, the project is more accurately described as an early internal automation prototype rather than a completed ERP system.