Toos Foam Business Management & Accounting System

Overview

Toos Foam Business Management & Accounting System was a custom operational application created for a company involved in the production and sale of foam products and AAC / Hebel construction materials.

The system was not developed from a generic accounting-package requirement. It was built around the workflows and expectations of the business owner.

The owner described what the company needed operationally and, in many cases, also described how the visual output should look. My responsibility was to translate those requirements into a working digital system.

The project included:

customer management,
product management,
sales,
orders,
quotations / pro-forma invoices,
invoice creation,
printable color invoices,
receivables and payables,
cash / financial tracking,
inventory,
debtor / creditor information,
reporting,
and business-specific document output.

The project also included visual work such as the company logo, splash-screen assets, and invoice design.

Business Context

The company operated in a domain where physical goods, customers, orders, stock, sales, and financial records needed to stay synchronized.

The software therefore had to bridge several operational concerns:

Customer
   ↓
Quotation / Order
   ↓
Product / Inventory
   ↓
Sale
   ↓
Invoice
   ↓
Receivable / Payment
   ↓
Accounting Record
   ↓
Report

The system was designed around the actual flow of the business rather than around an abstract bookkeeping model.

Original Problem

The business needed a practical system that could manage daily commercial activity without requiring multiple disconnected tools.

The system needed to answer operational questions such as:

Which customers have active orders?
What products were sold?
What inventory remains available?
Which invoices are outstanding?
Which customers are debtors?
Which suppliers or accounts are creditors?
What payments have been received?
What orders are pending?
What quotations were issued?
What should appear on the printed invoice?
How can the company’s visual identity remain consistent across software and printed documents?

This required the application to combine business logic, data storage, reporting, and document presentation.

Historical Architecture

The original system was implemented using a practical stack appropriate for the period.

Application Layer

PHP
CodeIgniter
browser-based application logic

Client Delivery

web application workflow
WebView-style usage where needed to provide a desktop-like application experience

Data Layer

A relational database was used to support business entities and transactions.

The exact historical database engine should only be stated if the original source or configuration files are recovered.

Historical Architecture Concept

        Business User
             ↓
      WebView / Browser UI
             ↓
     CodeIgniter Application
             ↓
     Business / Accounting Logic
             ↓
         Database
             ↓
     Reports / Invoice Output

The application was intentionally pragmatic.

For the requirements and technology available at the time, the goal was to deliver a usable business system quickly rather than over-engineer the platform.

Functional Scope

1. Customer Management

The system supported customer-related business operations such as:

customer records,
contact information,
sales history,
orders,
invoices,
receivable status,
debtor / creditor context.

The objective was to keep operational and financial information connected to the same customer record.

2. Product Management

The system maintained business products related to foam and AAC / Hebel sales.

Product information could be used across:

inventory,
quotations,
orders,
invoices,
and reporting.

3. Inventory Management

Inventory was part of the operational workflow.

The system supported visibility into available stock and the relationship between products, sales, and orders.

The exact historical stock-calculation rules should be reconstructed from surviving code or data before publishing deeper implementation details.

4. Orders

Orders connected customers with requested products and quantities.

This created a bridge between:

Customer Demand
      ↓
Order
      ↓
Inventory / Fulfillment
      ↓
Sale
      ↓
Invoice

5. Quotations / Pro-Forma Invoices

Before final invoicing, the system could support quotation / pro-forma workflows.

This allowed the company to prepare commercial offers before converting them into final sales documents.

6. Invoicing

Invoice generation was one of the most visible parts of the system.

The requirement was not simply to output a plain accounting document.

The customer specifically wanted a colored invoice matching the visual design.

That created a combined design-and-software problem:

Business Data
     +
Accounting Rules
     +
Visual Invoice Design
     ↓
Printable Branded Invoice

The final output needed to be both functionally correct and visually aligned with the company identity.

Branded Document Generation

This project is particularly useful as evidence of document-generation work.

The invoice was first treated as a designed artifact.

Then the software had to populate that design with live business data.

This required coordination between:

layout,
typography,
color,
company identity,
customer information,
product lines,
quantities,
prices,
totals,
and print output.

The resulting document was therefore not just a generic system report.

It was a business document with a deliberate visual identity.

7. Receivables and Payables

The system supported tracking of financial obligations.

Relevant concepts included:

outstanding customer balances,
money owed to the company,
amounts payable,
payment status,
account relationships.

This gave the company visibility beyond individual invoices.

8. Cash / Financial Tracking

Operational financial records were connected to business transactions.

The exact accounting depth should be described only as far as historical evidence supports.

The project can safely be described as a business accounting and financial tracking system, without claiming compliance with accounting standards that have not been independently verified.

9. Debtor / Creditor Tracking

The application helped identify financial position by counterparty.

This made it possible to understand which accounts were:

debtor,
creditor,
settled,
or still outstanding.

10. Reporting

The application provided business reports over the recorded operational data.

Potential report domains included:

sales,
customers,
invoices,
outstanding amounts,
inventory,
orders,
and financial summaries.

Precise historical report names should be added only after inspecting recovered source or screenshots.

Visual Identity Integration

The project also involved visual implementation.

Work included:

company logo realization,
splash-screen design,
application branding,
invoice visual design,
and print-oriented assets.

The company owner provided ideas and direction.

My role was to translate those ideas into usable digital assets.

That distinction is important:

The visual concept was client-directed; the digital realization and integration into the software were part of my work.

Logo & Splash Work

The surviving files include logo and splash-related design assets.

These were part of the overall business-system delivery rather than a disconnected graphics exercise.

The visual identity was carried into:

the application,
startup / splash presentation,
invoices,
and printed outputs.

This helped create a consistent experience between the software and the company’s external documents.

My Role

My role covered the technical and digital implementation of the project.

Responsibilities included:

gathering requirements directly from the business owner,
translating operational requirements into software features,
application design,
database-oriented business modeling,
CodeIgniter development,
business logic implementation,
customer workflows,
product workflows,
order workflows,
sales workflows,
accounting / financial tracking,
inventory functionality,
reporting,
invoice generation,
printable document design,
application branding,
logo digital realization,
splash-screen work,
deployment,
testing,
and user support.

The company owner provided the operational requirements and visual ideas.

I implemented those requirements digitally and converted them into the working system.

Ownership Positioning

Recommended wording for public use:

The business owner defined the operational requirements and many of the visual ideas. I translated those requirements into the application architecture, business workflows, digital assets, reporting, and working software.

This avoids claiming authorship of client-originated ideas while still accurately representing the implementation responsibility.

What Made the Project Interesting

1. Business Logic + Visual Design

Most projects separate graphic design and accounting software.

This project required both.

The invoice had to be:

financially correct,
data-driven,
printable,
and visually aligned with the company’s requested design.

2. Client-Driven Requirements

The project was developed directly from the business owner’s operational expectations.

This meant requirements were often expressed in business language rather than technical specifications.

Part of the work was converting statements such as:

“I want the invoice to look exactly like this.”

into:

data fields,
business rules,
report structure,
layout rules,
and print logic.

3. Multiple Business Domains in One Application

The system crossed several domains:

CRM
+
Sales
+
Orders
+
Inventory
+
Accounting
+
Reporting
+
Document Generation

Even at modest scale, this requires consistent data relationships.

4. Print Output as a Product Feature

Print was not an afterthought.

The invoice itself was part of the delivered product.

That makes the project relevant to later document-generation and reporting work.

Outcome

The application was created for real company use.

It integrated business operations, financial tracking, and branded document output into one system.

The project represents a period in which rapid business application development with CodeIgniter provided a practical way to deliver customized software without the overhead of heavier platforms.

The surviving design files provide direct historical evidence of the visual and document-output work.

Evidence Available

Current evidence includes:

historical project folder dated January 31, 2014,
logo assets,
Photoshop source files,
splash / visual assets,
invoice design files,
invoice imagery,
project-related graphics.

Potential additional evidence may include:

source code,
database dumps,
executable/client files,
screenshots,
printed invoices,
deployment archives.

If recovered, those assets should be added to the portfolio Evidence section.

V2 — Modern Rebuild

The modern rebuild should preserve the original business problem while replacing the historical implementation.

Recommended positioning:

Toos Foam Operations, Accounting & Invoicing Platform

The V2 should no longer depend on a WebView-style delivery model.

A modern Laravel application can provide a cleaner architecture with browser-native responsive access.

V2 Architecture

                 Responsive Web UI
                        ↓
                 Laravel Application
                        ↓
       ┌────────────────┼────────────────┐
       │                │                │
       ▼                ▼                ▼
   Sales          Inventory        Accounting
   Orders         Products         Payments
   Quotes         Stock            Balances
       │                │                │
       └────────────────┼────────────────┘
                        ↓
                   PostgreSQL
                        ↓
        ┌───────────────┼───────────────┐
        ▼               ▼               ▼
      Redis          Queues        PDF / Reports

V2 Recommended Stack

Backend

Laravel
PHP 8.x
service-oriented application layer where appropriate
queues
scheduler
event-based workflows

Database

PostgreSQL

Cache / Queue

Redis

Frontend

Recommended default:

Laravel Blade / Livewire

A SPA should only be introduced if the interaction complexity justifies it.

Infrastructure

Docker
CI/CD
environment-based configuration
automated backups
structured logging
health checks

V2 Core Modules

Customer Management

customer profiles,
contacts,
addresses,
financial position,
invoice history,
order history.

Product Management

products,
categories,
units,
prices,
status,
inventory relationships.

Inventory

stock movements,
incoming inventory,
outgoing inventory,
adjustments,
stock history,
stock balance.

A movement-ledger model is preferable to simply storing a mutable quantity.

Sales

quotations,
orders,
sales,
invoices,
payments,
returns where required.

Accounting

A modern rebuild can structure financial records more explicitly.

Possible scope:

receivables,
payables,
cash movements,
customer balances,
supplier balances,
payment allocation,
transaction history.

If full double-entry accounting is required, it should be modeled deliberately rather than implied.

V2 Invoice Engine

The branded invoice remains one of the strongest continuity points between V1 and V2.

The modern engine can support:

HTML-based invoice templates,
PDF generation,
print CSS,
company branding,
configurable invoice numbering,
tax fields where applicable,
totals,
discounts,
customer details,
product lines,
QR / barcode support if later needed,
archived immutable invoice versions.

The original 2014 visual invoice can be recreated as a historical theme.

Document Versioning

A modern accounting system should avoid silently changing historical invoices after business data changes.

Recommended approach:

Invoice Created
      ↓
Invoice Snapshot
      ↓
Finalized
      ↓
Immutable Business Document
      ↓
PDF Archived

This provides stronger traceability.

RBAC

Potential roles:

Administrator
Accountant
Sales
Warehouse
Manager
Read-Only / Auditor

Permissions should be action-based rather than relying only on interface visibility.

Examples:

customers.view
customers.manage
orders.create
invoices.finalize
payments.record
inventory.adjust
reports.view
users.manage

Audit Trail

Important operations should be auditable:

invoice creation,
invoice cancellation,
price changes,
stock adjustments,
payment recording,
balance changes,
user changes,
permission changes.

Each event should preserve:

user,
time,
action,
entity,
previous value where relevant,
new value where relevant.

Reporting V2

A modern dashboard can include:

sales over time,
outstanding receivables,
overdue balances,
top customers,
top products,
inventory valuation,
low-stock warnings,
order status,
cash-flow summaries,
invoice status.

Reports should remain drillable back to the underlying transactions.

Search

Global search can provide quick access to:

customers,
invoices,
orders,
products,
payments.

Search should support invoice numbers, customer names, product names, and account references.

V2 Testing Strategy

Unit / Domain Tests

totals,
discounts,
payment allocation,
balance calculations,
stock movements,
order transitions.

Feature Tests

customer creation,
quotation generation,
order processing,
invoice finalization,
payment recording,
report authorization.

Regression Tests

Historical bugs discovered during reconstruction should become permanent automated tests.

Data Migration

If the original database survives, migration should be treated as a dedicated engineering process.

Legacy Database
      ↓
Staging Import
      ↓
Data Mapping
      ↓
Validation
      ↓
Normalization
      ↓
V2 Import
      ↓
Reconciliation

Accounting balances should be reconciled before declaring migration complete.

Security

A modern rebuild should include:

authenticated access,
RBAC,
CSRF protection,
server-side validation,
secure password storage,
login throttling,
audit logging,
encrypted transport,
backup strategy,
secrets outside source control.

Engineering Highlights

Translated owner-defined business requirements into a complete operational application.
Combined customer, product, sales, order, inventory, financial, and reporting workflows.
Built a CodeIgniter-based custom business application during the 2014 period.
Integrated branded visual identity into application and print outputs.
Designed and implemented color invoice generation based on a client-directed visual design.
Connected live business data to printable document output.
Delivered a system for real company use rather than a demonstration-only prototype.
Created a clear modernization path from CodeIgniter/WebView-era architecture to a maintainable Laravel platform.

Career Evidence

This project demonstrates:

End-to-End Ownership
Business Process Digitalization
Full-Stack Development
Business Analysis
Data Modeling
Accounting / Financial Workflow Implementation
Sales Systems
Inventory Systems
Document Automation
Reporting
Client Requirements Translation
Visual / Software Integration
Legacy Modernization
Product Engineering

CV Relevance

Tier B — Portfolio Evidence

This is a strong portfolio project because it demonstrates a complete real-world business system and direct translation of business requirements into working software.

It can support Tier A stories when discussing:

end-to-end ownership,
business process digitalization,
document generation,
legacy modernization,
or direct client requirement handling.

For an architecture-focused CV, larger enterprise systems should still receive priority.

Interview Story

Situation

A foam and AAC / Hebel production and sales company needed a practical system to manage daily business operations and accounting-related workflows.

Task

The owner provided business requirements and specific ideas for how the software and printed invoice should work and look.

Action

I translated those requirements into a CodeIgniter-based application covering customers, products, orders, sales, inventory, financial tracking, reporting, and invoice generation. I also created the digital branding assets and implemented a color printable invoice that reflected the requested visual design.

Result

The company received a single custom system combining operational workflows, financial tracking, and branded business documents. The project later became a useful example of how business requirements, software engineering, and document design can be integrated into one product.

Suggested Website Full Description

Overview

Toos Foam Business Management & Accounting System was a custom business application developed in 2014 for a company producing and selling foam products and AAC / Hebel construction materials.

The system combined customer management, sales, orders, inventory, financial tracking, reporting, and branded invoice generation.

Unlike a generic accounting package, the application was designed directly around the company owner’s operational requirements.

The Challenge

The business needed several workflows to remain connected.

Customer records, products, stock, orders, invoices, balances, and printed documents could not operate as isolated systems.

The project also had a strong visual requirement: the company wanted a color invoice that matched a specific visual design.

This meant the application had to combine data accuracy with visual output.

Original Solution

The original system was built with CodeIgniter and delivered through a web / WebView-oriented workflow appropriate for the period.

The application centralized the company’s operational information and generated branded documents directly from live business data.

My Role

The business owner defined the operational requirements and many visual ideas.

I converted those requirements into:

software structure,
business workflows,
application logic,
database-driven features,
reports,
invoice generation,
branding assets,
and the final working software.

Version 2

The modern rebuild replaces the historical CodeIgniter/WebView architecture with a Laravel-based platform.

The new system is designed around:

responsive access,
explicit domain modules,
PostgreSQL,
RBAC,
auditability,
automated testing,
PDF generation,
immutable finalized invoices,
Docker,
and maintainable deployment workflows.

Engineering Highlights

Customer and counterparty management
Product and inventory workflows
Quotations and orders
Sales and invoicing
Receivables / payables
Financial tracking
Debtor / creditor visibility
Reporting
Branded printable invoice generation
Client-directed visual identity integration
Legacy-to-Laravel modernization path

Short Website Card Copy

Toos Foam Business Management & Accounting System

A custom 2014 business application for foam and AAC/Hebel production and sales, integrating customers, inventory, orders, financial tracking, reporting, and branded color invoice generation.

Alternative One-Liners

Architecture-oriented

Designed and implemented a custom business system integrating sales, inventory, accounting workflows, reporting, and branded document generation.

Business-oriented

Digitized the core sales and accounting workflows of a foam and AAC/Hebel business through a custom CodeIgniter application.

Document-oriented

Built a business application that converted live accounting and sales data into branded, color-printable invoices matching the client’s requested design.

Modernization-oriented

Modernizing a 2014 CodeIgniter/WebView business system into a testable Laravel platform with RBAC, audit trails, inventory, accounting workflows, and PDF invoicing.

Suggested Website Slug

/projects/toos-foam-business-accounting-system

Alternative:

/software/toos-foam-operations-accounting

Cover Direction

Title

Toos Foam Business Management & Accounting System

Subtitle

Sales · Inventory · Accounting · Invoicing · Reporting

Visual Direction

A professional industrial-business software cover showing:

foam / AAC material stacks in a subtle industrial background,
business dashboard,
invoice document,
inventory blocks,
customer / sales flow,
accounting figures,
document-generation pipeline.

The cover should communicate software and business operations rather than function as a logo showcase.

The historical company logo can appear only where legally and contextually appropriate.

Evidence Gallery Recommendation

For the website, use a dedicated evidence section.

Suggested gallery:

Historical Assets

original logo image,
PSD source screenshot,
splash-screen assets,
invoice design,
historical folder/file screenshot.

Software Evidence

If recovered:

application screenshots,
source tree,
CodeIgniter controllers/models,
database schema,
invoice-generation source,
historical build/deployment files.

V2 Evidence

architecture diagram,
repository,
database migrations,
automated test report,
generated PDF invoice,
responsive UI screenshots.

Evidence Label

Recommended label for the current project:

Partially Verified — Historical design files and dated project assets available; software artifacts should be added if recovered.

This separates the historical facts supported by surviving files from details reconstructed through project memory.

Final Portfolio Statement

The most important part of this project is not the framework used in 2014.

It is the translation from real business requirements into an integrated working system.

The owner described what the business needed.

Those ideas had to become:

Data
+
Rules
+
Screens
+
Transactions
+
Reports
+
Invoices
+
Visual Identity

The project combined software development, business-process understanding, accounting-oriented workflows, reporting, and print design in a single delivery.

The modern reconstruction preserves those original business requirements while replacing the historical implementation with a cleaner, testable, auditable Laravel architecture.

Tags: Database Design Enterprise Software Reporting