# ZEENO ERP POS

## OpenCode GPT-5.5 Master Blueprint

Version: 1.0

---

# PROJECT GOAL

Build a world-class ERP + POS system for Trading, Wholesale, Distribution and Retail businesses using modern Laravel architecture.

The software must be enterprise-grade, modular, scalable, maintainable, and production-ready.

This project should never be treated as a CRUD application.

Every module must follow accounting principles, inventory principles, clean architecture, and modern UI standards.

---

# TECHNOLOGY STACK

## Backend

* PHP 8.3
* Laravel
* MySQL 8
* Laravel Eloquent
* Laravel Service Layer
* Repository Pattern
* Policies
* Middleware
* Events
* Notifications
* Queues
* Scheduler

## Frontend

* Blade
* Livewire
* Alpine.js
* Tailwind CSS
* Vite
* ApexCharts
* SweetAlert2
* Flatpickr
* TomSelect
* Lucide Icons

---

# DEVELOPMENT RULES

Always follow these rules.

Never ignore them.

## Rule 1

Controllers must remain thin.

No business logic.

## Rule 2

Business logic belongs inside Services.

## Rule 3

Database access belongs inside Repositories.

## Rule 4

Always validate using Form Requests.

## Rule 5

Never use raw SQL when Eloquent is appropriate.

## Rule 6

Always use transactions for:

* Sales
* Purchases
* Stock
* Vouchers
* Payments
* Returns

## Rule 7

Never create duplicate document numbers.

## Rule 8

Never allow unbalanced accounting entries.

## Rule 9

Never edit posted transactions.

Use reversal entries.

## Rule 10

Every stock movement creates stock ledger entries.

## Rule 11

Every financial transaction creates journal entries.

## Rule 12

Always support:

* Multi Company
* Multi Branch
* Multi Warehouse
* Fiscal Year

---

# UI DESIGN

Design must look like:

* Oracle Fusion
* Microsoft Dynamics 365
* Odoo Enterprise
* SAP Fiori

Avoid old Bootstrap admin templates.

Use:

* large spacing
* rounded cards
* modern typography
* minimal borders
* fast navigation
* keyboard shortcuts
* responsive layouts

---

# PROJECT STRUCTURE

```text
app/

Actions/
DTOs/
Enums/
Events/
Exceptions/
Helpers/

Http/
Controllers/
Middleware/
Requests/
Resources/

Livewire/

Models/

Policies/

Repositories/

Services/

Support/

Observers/

Notifications/
```

---

# MODULE ORDER

Develop modules in this exact order.

## Phase 1

Authentication

Company

Branch

Warehouse

Fiscal Year

Settings

Roles

Permissions

Dashboard

---

## Phase 2

Chart of Accounts

Voucher Types

Journal Entry

Cash Voucher

Bank Voucher

Ledger

Trial Balance

---

## Phase 3

Categories

Brands

Units

Items

Warehouses

Opening Stock

Stock Ledger

Stock Adjustment

Stock Transfer

---

## Phase 4

Customers

Sales

POS

Receipts

Sales Return

---

## Phase 5

Suppliers

Purchase Orders

Goods Receipt

Purchase Invoice

Purchase Return

Supplier Payment

---

## Phase 6

Reports

Financial Statements

Inventory Reports

Sales Reports

Purchase Reports

Management Dashboard

---

## Phase 7

Approval Workflow

Notifications

Barcode

Batch

Expiry

Serial Numbers

Audit Logs

FBR Integration

---

# ACCOUNTING RULES

Only Level 4 accounts receive postings.

Every sale creates:

Customer/Cash

↓

Sales

↓

Tax

↓

Inventory

↓

Cost of Goods Sold

Every purchase creates:

Inventory

↓

Supplier

↓

Input Tax

---

# INVENTORY RULES

Never update stock directly.

Always create stock ledger.

Stock balance updates from ledger.

Support:

FIFO

Weighted Average

Batch

Expiry

Serial

Warehouse

Rack

Bin

---

# DATABASE RULES

Use:

* Foreign Keys
* Indexes
* Soft Deletes
* UUID where required
* Decimal for money
* Transactions

Never use FLOAT for financial values.

---

# CODING STANDARDS

Follow PSR standards.

Use:

CamelCase classes.

snake_case database.

Meaningful variable names.

Small methods.

Reusable services.

No duplicated code.

---

# UI RULES

Every page contains:

Header

Breadcrumb

Search

Filters

Table

Pagination

Export

Print

Three-dot Action Menu

Responsive Layout

Dark Mode Ready

---

# POS RULES

POS must support:

Barcode

Touch Screen

Keyboard Shortcuts

Multiple Hold Sales

Split Payment

Cash

Bank

Card

Wallet

Customer Credit

Thermal Printer

A4 Invoice

Offline Draft

---

# REPORT RULES

Every report supports:

Date Range

Branch

Warehouse

Company

Export PDF

Export Excel

Print

Search

Grouping

Sorting

Drill Down

---

# SECURITY

Role Permission

Branch Restriction

Warehouse Restriction

Audit Logs

CSRF

XSS

SQL Injection Protection

Session Timeout

Password Hashing

2FA Ready

---

# BEFORE EVERY TASK

GPT-5.5 must:

Understand the requested module.

Read previous related files.

Think about accounting.

Think about stock movement.

Think about reporting.

Think about permissions.

Think about future modules.

Only then generate code.

---

# OUTPUT FORMAT

For every generated module produce:

1. Database Migration

2. Model

3. Relationships

4. Repository

5. Service

6. Form Request

7. Controller

8. Livewire Component

9. Blade Views

10. Routes

11. Seeder

12. Factory

13. Policy

14. Tests

15. Documentation

Never skip any layer.

---

# QUALITY CHECKLIST

Before finishing any module verify:

✓ No duplicated code

✓ Uses Services

✓ Uses Repository

✓ Uses Transactions

✓ Uses Validation

✓ Uses Policies

✓ Uses Clean UI

✓ Responsive

✓ Accounting correct

✓ Inventory correct

✓ Report ready

✓ Production ready

---

# FINAL INSTRUCTION

You are building an enterprise ERP.

Prioritize correctness over speed.

Never generate placeholder business logic.

Always think about future modules before implementing the current one.

Every decision should support a scalable ERP that can grow for many years.
