Public Assistance Request, 72-Code Classification & Controlled Resource Allocation Platform

Case Management · RBAC · Budget Governance · Cash & In-Kind Assistance · Windows → Laravel Migration

Project positioning

This project began as a Windows desktop application with a UI built using Bunifu, and was later redesigned as a Laravel-based web application.

The software was commissioned for the cultural organization of Astan Quds Razavi to structure, classify, distribute, and track public assistance requests.

The core challenge was not merely to create an online request form.

The real work was to convert an executive-level operational concept into a structured system that could answer questions such as:

• What type of request has been submitted?
• Which organizational category should it belong to?
• Which employee is authorized to handle it?
• What type of assistance can be provided?
• How much cash or how many physical resources are available?
• What is the employee’s monthly authority or allocation?
• How much has already been consumed?
• How much remains?

In direct discussions with the head of the cultural organization, the operational ideas were converted into a structured 72-code accounting / operational classification model.

The result was a system combining:

• public request intake,
• structured classification,
• case management,
• role-based access control,
• delegated spending/resource authority,
• cash and non-cash resource management,
• monthly allocation limits,
• and centralized administrative oversight.

Classification

• Project Type: Public Assistance / Case Management Platform
• Organization Context: Astan Quds Razavi — Cultural Organization
• Initial Version: Windows Desktop
• Initial UI Framework: Bunifu
• Later Version: Laravel Web Application
• Primary Domain: Public Assistance Request Management
• Secondary Domains: Resource Allocation, Accounting Classification, RBAC, Budget Governance
• Classification Model: 72-Code Accounting / Operational Structure
• Assistance Types: Cash and Non-Cash Resources
• Examples of Non-Cash Resources: Books, Food Packages, Other Allocated Goods
• Access Model: User / Role / Permission / Allocation Limits
• Portfolio Relevance: Very High
• Suggested CV Relevance: Tier A — Enterprise Workflow, Business Logic, Domain Modeling, Laravel

Executive Summary

The organization received a wide range of public requests through paper forms and other intake channels.

The problem was that these requests were inherently unstructured.

A person could ask for:

• financial support,
• books,
• food packages,
• another available resource,
• or another form of assistance.

The organization needed more than a database table containing free-text requests.

It needed a system that could convert incoming requests into a controlled operational workflow.

The conceptual lifecycle became:

Public Request
      ↓
Structured Intake
      ↓
72-Code Classification
      ↓
Responsible Employee / Unit
      ↓
Permission Check
      ↓
Available Resource Check
      ↓
Assistance Decision
      ↓
Cash / In-Kind Allocation
      ↓
Balance Reduction
      ↓
Case History / Oversight

The Real Engineering Problem

At first glance, the project looks like a request form.

In reality, it was a combination of:

CASE MANAGEMENT
+
ACCOUNTING CLASSIFICATION
+
RESOURCE GOVERNANCE
+
RBAC
+
ALLOCATION CONTROL

The form was only the entry point.

The real system value existed behind it.

Domain Analysis

One of the strongest parts of the project was the transition from informal organizational knowledge to a structured digital model.

The process was approximately:

Executive / Operational Ideas
           ↓
Direct Discussion
           ↓
Requirement Interpretation
           ↓
Business Classification
           ↓
72 Structured Codes
           ↓
Software Rules

This means the project involved real domain engineering, not only implementation.

72-Code Classification Model

The 72-code structure transformed diverse public requests into a model that could be handled consistently.

Conceptually:

Unstructured Human Request
            ↓
Request Type Identification
            ↓
Classification Code
            ↓
Organizational Responsibility
            ↓
Permitted Resource Type
            ↓
Processing Rule

The system could therefore process requests through a predictable internal model instead of relying only on free-text interpretation.

Why the 72 Codes Matter

Without structured classification:

Request A
Request B
Request C

could all be interpreted differently by different employees.

With a shared coding model:

Request
   ↓
Code
   ↓
Known Category
   ↓
Known Responsibility
   ↓
Known Processing Logic

This improves consistency.

Accounting / Operational Meaning

The coding model was tied to the way the organization controlled assistance and resources.

The codes were not merely visual labels.

They were part of the operational and accounting structure of the system.

They could be used to connect a request to:

• a category,
• a responsible role,
• an assistance type,
• and a controlled allocation.

Case Management Model

Each public request can be represented as a case.

A conceptual case model:

Case
├── Applicant
├── Request Data
├── Classification Code
├── Assigned Employee / Unit
├── Status
├── Assistance Type
├── Allocated Resource
├── Quantity / Amount
├── Decision
└── Processing History

This is more accurate than describing the system as a simple form application.

Applicant Intake

The web interface included a structured request form.

The visible fields show that the system collected controlled applicant information instead of relying on one free-text field.

This approach helps transform an incoming request into a processable case.

Conceptually:

Applicant Information
        +
Request Type
        +
Classification
        ↓
Structured Case

Request Sources

The organization could receive requests through different channels.

The software’s purpose was to normalize those requests into the same operational model once they entered the system.

The exact historical list of intake channels should not be expanded beyond the available evidence.

Assistance Was Not Only Cash

A major architectural feature was that the organization distributed both financial and non-financial assistance.

Examples included:

• cash,
• books,
• food packages,
• other allocated goods/resources.

This means the correct domain concept is not only:

Budget Management

but more broadly:

Resource Allocation

Resource Model

A resource could conceptually be modeled as:

Resource
├── Type
├── Unit
├── Available Quantity / Amount
├── Allocation Scope
└── Consumption History

Examples:

Cash          → currency
Books         → units
Food Packages → units
Other Goods   → units / defined measurement

Cash vs In-Kind Assistance

The system therefore needed to support two different operational behaviors.

Cash

Available Monetary Allocation
        ↓
Authorized Employee
        ↓
Approved Amount
        ↓
Remaining Monetary Balance

In-Kind Resource

Available Quantity
        ↓
Authorized Employee
        ↓
Granted Quantity
        ↓
Remaining Stock / Allocation

Delegated Authority

Employees were not given unlimited access to organizational resources.

Instead, they received controlled authority.

The user described this as a type of:

تنخواه / delegated monthly allocation

Conceptually:

Employee
   ↓
Role
   ↓
Permission
   ↓
Monthly Allocation / Authority
   ↓
Available Resource Types
   ↓
Allowed Assistance

Monthly Limits

One of the important control mechanisms was the ability to give employees a limited monthly amount or quota.

This made it possible to decentralize service delivery while still keeping central governance.

Why Delegated Limits Matter

Without limits:

Employee
→ unrestricted spending / allocation

With limits:

Employee
→ defined authority
→ defined resource scope
→ defined monthly ceiling

This allows distributed execution without losing organizational control.

RBAC

The web version included online management of:

• users,
• access levels,
• roles,
• service permissions.

This is effectively a Role-Based Access Control (RBAC) layer.

Conceptual RBAC Model

User
  ↓
Role
  ↓
Permissions
  ↓
Allowed Request Categories
  ↓
Allowed Resource Types
  ↓
Allocation Limits

Example Permission Logic

A user might conceptually have permission to:

View Category X
Process Category X
Allocate Books
Allocate Food Packages
Use Cash up to Defined Limit

while another user might have:

Read Only
Management Oversight
Cross-Department Visibility

Exact historical permission names should only be documented where preserved.

Organizational Responsibility

A structured classification model allows requests to be routed toward the responsible employee or unit.

Conceptually:

Request Code
    ↓
Responsible Area
    ↓
Authorized User

This reduces arbitrary handling.

Resource Allocation Logic

When an employee processes a request, the system must consider:

Is the user authorized?
Is this request category allowed?
Is this resource type available?
Is sufficient balance available?
Is the monthly limit exceeded?

Only after those checks should allocation occur.

Validation Flow

Request
   ↓
Classification
   ↓
Permission Check
   ↓
Resource Check
   ↓
Limit Check
   ↓
Allocation

Resource Consumption

Every approved assistance action reduces an available balance.

Opening Allocation
      ↓
Assistance 1
      ↓
Assistance 2
      ↓
Assistance 3
      ↓
Remaining Allocation

This makes the system useful for both operational staff and management.

Inventory-Like Non-Cash Resources

Books and food packages behave more like inventory than cash.

For those resources, the system needs quantity-aware logic.

Conceptually:

Books
Opening Quantity: 100
Allocated: 15
Remaining: 85

Financial-Like Resources

Cash behaves more like a budget.

Conceptually:

Monthly Cash Authority
Opening Amount: X
Spent: Y
Remaining: X - Y

Unified Resource Abstraction

A strong modern architecture can represent both under one abstraction:

Allocation Resource
├── Type
├── Unit
├── Opening Balance
├── Consumed Balance
└── Remaining Balance

This lets the same workflow handle:

• currency,
• units,
• packages,
• other resources.

Employee Wallet / Allocation Concept

A useful conceptual representation is:

Employee Allocation
├── Cash
├── Books
├── Food Packages
└── Other Resources

Each employee only sees or uses what has been assigned to them.

Management Oversight

Central management needs visibility into:

• who received which allocation,
• how much was consumed,
• which cases were handled,
• which resources remain.

This creates accountability.

Auditability

The system is much stronger if every assistance action can answer:

Who?
What?
When?
For Which Case?
Using Which Resource?
How Much / How Many?
Under Which Classification?

This is a key enterprise principle.

History

A case history should preserve important actions.

Conceptually:

Case Created
Classified
Assigned
Reviewed
Resource Allocated
Completed

Historical implementation details should be documented only when preserved.

Version 1 — Windows Desktop

The first implementation was a Windows application.

The UI was created with Bunifu.

The visible login interface demonstrates the desktop phase of the project.

Desktop Architecture Character

Conceptually:

Windows Client
     ↓
Authentication
     ↓
Application Logic
     ↓
Data Store

The exact historical database technology should not be inferred unless separately documented.

Why Start with Desktop

The desktop version provided a controlled internal application for the initial workflow.

It was useful for validating:

• forms,
• classification,
• user access,
• operational logic.

Version 2 — Laravel Web Application

The later version moved to a web architecture based on Laravel.

This changed the operational model significantly.

Conceptually:

Browser
   ↓
Laravel Application
   ↓
Centralized Business Logic
   ↓
Centralized Data

Benefits of Web Migration

The web version offered practical advantages:

• centralized deployment,
• simpler user access,
• easier account management,
• easier permission management,
• reduced desktop installation dependency,
• easier future expansion.

Desktop → Web Evolution

The project history can be described as:

Windows Prototype / Internal Tool
            ↓
Operational Learning
            ↓
Web-Based Enterprise Platform

Migration Value

This project therefore demonstrates more than building two UIs.

It demonstrates:

• evolving a working business model,
• validating workflows,
• moving to a more maintainable deployment architecture.

Laravel as Business Logic Layer

The Laravel version was well suited to the system because the application had substantial business rules.

Examples:

• permissions,
• resource limits,
• request classification,
• user management,
• workflow rules,
• allocation validation.

These belong naturally in a centralized backend.

Suggested Laravel Domain Modules

A clean architecture could divide the application into:

Requests
Applicants
Classification
Users
Roles
Permissions
Resources
Allocations
Budgets
Inventory
Reporting
Audit
Administration

Request Module

Responsibilities:

• create request,
• update request,
• classify request,
• assign request,
• track status.

Applicant Module

Responsibilities:

• applicant identity,
• contact information,
• relationship to requests.

Classification Module

Responsibilities:

• 72-code structure,
• category hierarchy,
• code descriptions,
• organizational ownership.

Resource Module

Responsibilities:

• define resource types,
• define units,
• maintain balances,
• track availability.

Allocation Module

Responsibilities:

• assign resources to employees,
• enforce limits,
• record consumption.

User / RBAC Module

Responsibilities:

• users,
• roles,
• permissions,
• organizational scope.

Audit Module

Responsibilities:

• action history,
• who changed what,
• allocation history.

Reporting Module

Management may need reports across:

• request categories,
• employees,
• assistance types,
• resource consumption,
• remaining balances.

These are natural capabilities of the domain, although exact historical report screens should only be claimed where documented.

Reporting Dimensions

Useful dimensions include:

By Code
By Employee
By Resource Type
By Time Period
By Request Status

Budget Governance

For cash allocations, a modern version should maintain:

Opening Budget
Allocated to Employees
Consumed
Remaining

Stock Governance

For non-cash resources:

Opening Stock
Distributed
Remaining

Mixed Resource Dashboard

A management dashboard could show:

Cash Remaining
Books Remaining
Food Packages Remaining
Other Resources Remaining

Transaction Model

Every assistance action should be treated as a transaction.

Conceptually:

Allocation Transaction
├── case_id
├── employee_id
├── resource_id
├── quantity / amount
├── timestamp
└── reason / note

Atomicity

For modern implementation, allocation should be atomic.

Example:

Check Balance
↓
Create Allocation
↓
Reduce Balance

should occur in one database transaction.

This prevents partial updates.

Concurrency

If multiple employees allocate from the same resource pool simultaneously, the application must prevent overspending or negative stock.

Modern implementation should use:

• database transactions,
• row locking / appropriate concurrency control.

Negative Balance Protection

The system should never allow:

Remaining Balance < 0

unless explicitly permitted by management policy.

Periodic Reset / Renewal

Because some employee limits were monthly, modern implementation should support period-aware allocations.

Conceptually:

Allocation Period
├── start_date
├── end_date
└── limit

Carry-Over Policy

Whether unused allocation carries into the next month is a business rule.

The current source information does not specify this.

Do not invent it.

Approval Layers

The available information confirms employee limits and access control.

It does not fully document whether every case required multi-stage approval.

Therefore multi-stage approval should be treated as a V2 option, not a historical claim.

Duplicate Request Detection

A modern V2 could detect duplicate or repeated requests using:

• applicant identity,
• time period,
• request category.

This is a modernization recommendation only.

Fraud / Abuse Prevention

The historical system’s controlled allocations already reduce some misuse risk.

A modern version could add:

• duplicate detection,
• anomaly reporting,
• approval thresholds,
• full audit trails.

Important Ethical Boundary

The platform should be described as a system for:

structuring requests and controlling organizational resources

not as an automated system that decides who is “deserving.”

The software supports organizational processing.

It should not be presented as an algorithmic welfare eligibility engine.

Human Decision Role

A safe and accurate model is:

Software
→ organizes information
→ enforces permissions
→ tracks resources

Human Staff
→ evaluates the request
→ makes the assistance decision

Data Privacy

Public-assistance requests may contain personal information.

A modern system should therefore use:

• least-privilege access,
• encrypted transport,
• secure password storage,
• audit logs,
• data-retention policy.

These are modernization requirements, not confirmed historical features.

Sensitive Data Access

Not every employee should see every request.

RBAC should control:

Who can view?
Who can edit?
Who can allocate?
Who can report?

Security Logging

Important events:

Login
Failed Login
Role Change
Allocation Change
Case Update
Resource Adjustment

Authorization Should Be Server-Side

In the Laravel version, permissions should be enforced in backend policies/middleware, not only by hiding buttons.

Suggested Modern Laravel Architecture

HTTP / Livewire / API
        ↓
Application Services
        ↓
Domain Rules
        ↓
Repositories / Eloquent
        ↓
Database

Policies

Laravel Policies can enforce:

• case access,
• allocation permissions,
• management actions.

Form Requests

Laravel Form Requests can validate:

• applicant data,
• request code,
• resource amount,
• allowed quantities.

Domain Services

Complex allocation logic should not be placed directly inside controllers.

Use services such as:

RequestClassificationService
ResourceAllocationService
BudgetControlService

Example Allocation Service Logic

1. Confirm user permission
2. Confirm case status
3. Confirm resource eligibility
4. Confirm available balance
5. Confirm monthly limit
6. Create allocation transaction
7. Update balance
8. Write audit event

Database Model — Conceptual

users
roles
permissions
role_user
permission_role

applicants
requests
request_codes
request_statuses

resources
resource_types
resource_balances

employee_allocations
allocation_periods
assistance_transactions

audit_logs

72 Codes Table

Conceptually:

request_codes
├── id
├── code
├── title
├── parent_id
├── responsible_unit
└── active

The exact historical schema may differ.

Resource Table

resources
├── id
├── name
├── type
├── unit
└── active

Employee Allocation

employee_allocations
├── employee_id
├── resource_id
├── period_id
├── allocated_amount
├── consumed_amount
└── remaining_amount

Case Allocation History

A case may have one or more assistance transactions if organizational policy allows it.

Conceptually:

Case
  ↓
Assistance Transactions

Historical multiplicity should not be overstated without evidence.

API Opportunity

A modern version could expose controlled APIs for:

• request submission,
• status tracking,
• resource dashboards.

This is a V2 direction.

Public Portal vs Internal Portal

A strong modern separation is:

Public Request Portal
        ↓
Internal Processing Portal

Public users submit.

Authorized employees process.

Public Request Status

A V2 could allow applicants to track request status with a secure reference.

This is a modernization idea, not confirmed historical functionality.

Notification Layer

A modern system could notify staff about:

• new requests,
• nearing allocation limits,
• low stock,
• pending cases.

Resource Forecasting

Once transaction history exists, management can forecast resource demand.

Example:

Average Monthly Book Distribution
Average Food Package Distribution
Cash Consumption Trend

This is a natural V2 analytical capability.

Dashboards

Possible management cards:

Open Requests
Processed Requests
Cash Remaining
Books Remaining
Food Packages Remaining
Employees Near Monthly Limit

Analytics

Useful trends:

• request count by classification,
• assistance type distribution,
• monthly resource consumption,
• employee allocation usage.

Evidence Strategy

The currently available screenshots support two distinct historical phases.

Evidence A — Web Request Form

The web screenshot shows:

• online request submission,
• structured fields,
• request type selection,
• public-facing intake.

Recommended caption:

Laravel-based public request intake interface for structured assistance cases.

Evidence B — Windows Desktop Login

The desktop screenshot shows the earlier Windows implementation.

Recommended caption:

Initial Windows desktop version built with a custom Bunifu-based interface before the workflow was migrated to Laravel.

Evidence Story

Use the two images together:

Version 1
Windows / Bunifu
       ↓
Version 2
Laravel / Web

This visually proves the evolution of the project.

Historical vs Modern Boundary

Confirmed Historical Capabilities / Facts

• commissioned for the cultural organization of Astan Quds Razavi,
• public assistance request management,
• initial Windows desktop application,
• Bunifu-based desktop UI,
• later Laravel web version,
• direct requirement discussions with the head of the organization,
• conversion of operational ideas into a 72-code accounting/operational model,
• online user management,
• access-level management,
• controlled employee authority,
• monthly limited resource/budget access,
• cash assistance,
• non-cash assistance,
• resources such as books and food packages.

Modern V2 Recommendations

• explicit domain modules,
• transactional allocation service,
• stronger audit logging,
• concurrency control,
• dashboard analytics,
• anomaly detection,
• API separation,
• applicant status tracking,
• automated notifications.

These must be labeled as modernization ideas rather than historical implementation.

What Not to Overclaim

Do not claim:

• that the software autonomously decided who deserved assistance,
• that all requests were automatically approved,
• that every request used multi-stage approval,
• that all 72 codes are currently known or preserved,
• that specific fraud-detection algorithms existed historically,
• that every resource behaved exactly like inventory.

My Role

A precise portfolio description:

I worked directly with organizational leadership to translate an informal public-assistance process into a structured 72-code operational/accounting model, then implemented the workflow first as a Windows application and later as a Laravel-based web platform with user access control and controlled cash/non-cash resource allocation.

Engineering Highlights

• Converted executive-level operational concepts into a structured domain model.
• Designed a 72-code classification structure.
• Modeled public requests as processable cases.
• Implemented controlled user/role access.
• Supported delegated monthly employee authority.
• Supported both cash and non-cash assistance.
• Managed consumable resources such as books and food packages.
• Built an initial Windows/Bunifu application.
• Migrated the workflow to a Laravel web application.
• Centralized user and access management.
• Connected request handling to organizational resource governance.

Business Analysis Highlights

This project demonstrates:

CONVERSATION
→ REQUIREMENTS
→ DOMAIN MODEL
→ BUSINESS RULES
→ SOFTWARE

That is one of the strongest parts of the project.

Career Evidence

This project demonstrates experience with:

• Laravel
• Windows Desktop Applications
• Bunifu UI
• Business Process Modeling
• Domain Analysis
• Case Management
• RBAC
• Resource Allocation
• Budget Governance
• Cash & In-Kind Assistance
• Workflow Automation
• Desktop-to-Web Migration
• Enterprise Business Logic

CV Relevance

Tier A — Domain Modeling & Enterprise Workflow

This project is valuable because the difficult part was not the form.

The difficult part was turning organizational rules into a reliable digital model.

The project combines:

SOFTWARE ENGINEERING
+
BUSINESS ANALYSIS
+
ACCESS CONTROL
+
RESOURCE GOVERNANCE

Interview Story

Situation

The organization received many different public assistance requests through informal and paper-based channels.

Employees needed a way to process these requests while management still retained control over budget and physical resources.

Task

The process needed to be converted into a structured system that could classify requests, assign responsibilities, control employee authority, and track the consumption of both cash and non-cash resources.

Action

I discussed the operational model directly with the head of the cultural organization and translated the concepts into a 72-code accounting/operational classification structure.

I first implemented the workflow as a Windows desktop application using Bunifu.

Later, I rebuilt the system as a Laravel web application with centralized user management, access levels, and controlled employee allocations.

The resource model supported not only money, but also physical assistance such as books and food packages.

Result

The organization gained a structured workflow for handling public requests while maintaining control over who could allocate which resources and within what limits.

Suggested Website Full Description

Overview

The Astan Quds Razavi Public Assistance Management System was created to structure and control how public requests were received, classified, processed, and fulfilled.

The system evolved from an initial Windows/Bunifu desktop application into a Laravel-based web platform.

Domain Modeling

A major part of the project was requirement analysis.

Through direct discussions with organizational leadership, an informal operational model was converted into a structured 72-code classification system.

Public Request Management

Incoming requests were transformed into structured cases instead of remaining as unorganized paper or free-text requests.

Controlled Assistance

Employees were given defined access levels and limited monthly authority.

The system could control the use of both:

• cash,
• non-cash resources.

Examples of non-cash resources included books and food packages.

Access Control

User management and access levels were centralized in the web version so that different employees could receive different responsibilities and resource limits.

Desktop-to-Web Evolution

The first version was built as a Windows application using Bunifu.

The later Laravel version centralized the workflow and made user/access management easier to maintain.

Short Website Card Copy

Astan Quds Razavi Public Assistance Management System

Translated a public-assistance workflow into a 72-code operational/accounting model and implemented controlled cash and non-cash resource allocation, first as a Windows application and later as a Laravel web platform.

Alternative One-Liners

Domain-oriented

Translated an informal public-assistance process into a structured 72-code case-management and resource-allocation platform.

Laravel-oriented

Rebuilt a desktop assistance-management workflow as a Laravel platform with RBAC, monthly allocation limits, and cash/non-cash resource control.

Business-analysis-oriented

Worked directly with organizational leadership to turn operational concepts into a structured 72-code digital workflow.

Resource-oriented

Built a controlled assistance platform where authorized employees could allocate limited monthly cash and physical resources such as books and food packages.

Suggested Website Slug

/projects/public-assistance-resource-allocation

Alternative:

/projects/astan-quds-public-assistance-system

Cover Direction

Title

Public Assistance & Resource Allocation Platform

Subtitle

72-Code Classification · RBAC · Cash & In-Kind Assistance

Supporting Line

Windows → Laravel · Controlled Monthly Allocations

Visual Direction

A premium square technical cover should show:

• incoming public request,
• structured classification blocks,
• 72-code concept,
• employee permission layer,
• cash and physical resource icons,
• controlled allocation,
• Laravel/web transition.

Primary story:

REQUEST
→ CLASSIFY
→ AUTHORIZE
→ ALLOCATE
→ TRACK

Avoid making the cover look like:

• a donation website,
• an online payment app,
• a generic CRM.

The central idea is:

structured case management and controlled organizational resource allocation.

Relationship to the Other Institutional Projects

This project is distinct from the Digital Library family.

It demonstrates another dimension of institutional software:

Digital Library
→ Information Access

Public Assistance System
→ Operational Workflow + Resource Governance

This diversity is useful in a portfolio because it demonstrates the ability to model very different domains.

Modernization Direction

A modern V2 could be rebuilt around:

• Laravel,
• PostgreSQL,
• strict RBAC,
• transactional allocation services,
• immutable audit events,
• resource-ledger accounting,
• dashboard reporting,
• queue-based notifications.

Resource Ledger

A particularly robust V2 design would use a ledger.

Instead of only storing current balance:

Current Balance = 100

store transactions:

+100 Opening
-10 Case A
-5 Case B
+20 Additional Allocation

Then:

Balance = SUM(transactions)

This improves auditability.

Event History

A modern system can generate events:

RequestCreated
RequestClassified
RequestAssigned
AllocationGranted
ResourceConsumed
CaseClosed

This provides a strong audit trail.

Reporting From the Ledger

The ledger can support:

• monthly employee usage,
• resource consumption,
• historical balance reconstruction.

Integrity Rules

Modern V2 should enforce:

• no negative stock,
• no overspending,
• no unauthorized allocation,
• no allocation outside the allowed period.

Testing Strategy

Unit Tests

• 72-code classification rules,
• permission checks,
• monthly limit calculations,
• resource balance calculations.

Integration Tests

• create request,
• classify request,
• allocate resource,
• deduct balance,
• write audit event.

Authorization Tests

• unauthorized user cannot allocate,
• authorized user cannot exceed limit,
• management can view permitted reporting scope.

Example Test Scenario

Given:
Employee monthly book allocation = 20

When:
Employee grants 5 books

Then:
Consumed = 5
Remaining = 15

Overspend Test

Given:
Cash remaining = 100

When:
Employee attempts allocation = 150

Then:
Reject transaction

Permission Test

Given:
Employee has no permission for resource X

When:
Employee attempts allocation

Then:
Reject

Final Portfolio Statement

The project began as a request-management application, but its true value came from the business model behind it.

The system converted:

UNSTRUCTURED PUBLIC REQUESTS
+
ORGANIZATIONAL KNOWLEDGE
+
ACCOUNTING CLASSIFICATION
+
EMPLOYEE AUTHORITY
+
CASH / PHYSICAL RESOURCES

into a controlled digital workflow.

The strongest way to describe the project is:

I translated an informal public-assistance process into a structured 72-code case-management and resource-allocation system, then implemented it first as a Windows application and later as a Laravel web platform with controlled user permissions and monthly cash/non-cash allocation limits.