📦 Order Entry System Replacement Project

Project Codename: MoreDynamic (Replacement for Microsoft Dynamics)
Primary Platforms: 🤖 Android & 🪟 Windows
Core Requirement: ⚡ OFFLINE MODE SUPPORT & SPEED are critical.

---

📖 Overview

This project aims to build a bespoke web application to replace the legacy Microsoft Dynamics system for order entry and product SKU management. The application must be performant, robust, and capable of handling complex catalog data while functioning seamlessly in offline environments.

⚠️ IMPORTANT: This document serves as the Source of Truth for all project specifications. Contributors should refer to this strictly for feature requirements.

---

🛑 Key Features & Requirements

1. 📱 Frontend Order Entry (The "Field" View)

Target Users: Salespeople

• Authentication:
  • Standard Log in.
  • ✅ "Remember Me" functionality to persistent sessions.
• Performance: Must be optimized for speed.
• Offline Capability: Full CRUD operations on quotes/orders while disconnected, syncing when connection is restored.

2. 🗄️ Database Architecture (3 Core Pillars)

The system requires three newly created, high-performance databases designed for rapid related-data recall.

🏛️ DB 1: Accounts & Quotes

• Purpose: Central hub for customer data and their specific transaction history.
• Data Points:
  • Customer/Account Details (Contact Info, etc.)
  • Quotes associated with Accounts.
• Quote Metadata Requirements:
  • CreatedBy (User ID)
  • Status (Sold / Not Sold / Draft)
  • Revision # (User-defined)
  • Timestamps (Initial Creation Date, Last Edit Date)
  • Contents (List of Product #s + Quantities)
  • Pricing Conditions:
    • System defaults applied initially.
    • Mutable: Salespeople can alter conditions per quote.
    • Persistence: Alterations must be stored with the quote to ensure exact recall when duplicating/editing later.

🤝 DB 2: Internal Agreements (The "Override" Engine)

• Purpose: A rule engine that overrides standard pricing conditions based on pre-approved contracts.
• Capabilities:
  • Price Overrides: Set specific guide prices or lock prices to a fixed value.
  • Windows: Define price validity windows (e.g., specific dates or volume tiers).
  • Catalog Restrictions: Limit the visible product list for a specific agreement.
  • Scope: Can be applied per Site/Location within a larger multi-location deal.

👕 DB 3: Item Master / Product Catalogue

• Purpose: The universe of all sellable items.
• Datatypes: Must be extremely robust to handle diverse product categories.
• Examples:
  • Apparel:
    • Standard Sizes (S, M, L, XL)
    • Specific Dimensions (32x30, 34x32)
    • Variants (Mens, Womens, Long, Short)
    • Colors
    • Product Numbers
  • Facilities: Mats, Mops, Rugs.
  • Chemicals: Soaps, Cleaning Agents.
  • Services: Cleaning Services (Time-based or Flat rate).

---

🔐 Administrator "Back Door" & Dashboard

Target Users: Admins / Managers

• Dashboard View: High-level view of Quotes grouped by User/Salesperson.
• Management Functions:
  • Full edit access to DB 3 (Products) & DB 2 (Internal Agreements).
  • Ability to add/remove products and modify agreement logic.
• History & Auditing:
  • View Edit History.
  • View Export History.

---

📤 Exporting & Logging Specifications

Export Formats

Quotes must be exportable in two distinct ways:

1. 📄 PDF: A formal, document-style export.
2. 📝 Preformatted Text: Plain text block suitable for in-app emailing or Copy/Paste.

The "IT Support" Log 🪵

To assist the internal IT team and reduce "lost file" support tickets, a specialized log is required for Admin view.

• Constraint: Do NOT cache the full content of the export (privacy/storage efficiency).
• Requirement: Log the metadata of the export event:
  • Who exported it.
  • When it was exported.
  • Format used (PDF vs Text).
  • 📍 Location Path: If exported to PDF, strictly record the directory path where the file was saved.

---

👨‍💻 Proposed Tech Stack & Architecture

To achieve the requirement of a Web Application that functions as a Native App (Android Play Store & Windows Standalone) with Offline First capabilities for massive datasets:

🏗️ Application Core

• Framework: Next.js (using TypeScript).
  • Configuration Note: Will use Static Exports (output: 'export') to generate HTML/CSS/JS bundles compatible with Capacitor and Electron wrappers, ensuring the app runs locally without a server.

📦 Platform Packaging (The "Native" Wrapper)

Primary Recommendation: Tauri v2.0

• Why: It is the most optimal solution today for a "write once, deploy native" strategy.
  • Unified Tooling: A single CLI builds both the Android APK and the Windows .exe (MSI/NSIS). No need to maintain separate Capacitor and Electron projects.
  • Performance: Uses the native OS webview (WebView2 on Windows) and a Rust-based backend, resulting in an application size ~90% smaller than Electron and significantly faster.
  • Security: High security default; explicitly allows specific native API access (like Filesystem/SQLite) while blocking others.
  • Next.js Compatibility: Fully compatible with Next.js Static Exports.

Standard Alternative: Capacitor + Electron

• Use this if: The development team is strictly JavaScript/TypeScript capable and wants to avoid the minimal Rust configuration required by Tauri.

⚡ Offline Data Strategy (The "Million Record" Engine)

Standard web storage (LocalStorage/IndexedDB) will NOT be sufficient for hundreds of thousands of records.

• Local Database: SQLite.
  • Implementation: A native SQLite instance access via Tauri Plugin SQL (or Capacitor SQLite).
  • Why: It is the only local storage solution capable of indexing and querying millions of rows with sub-second latency on mobile devices.
• Data Synchronization Layer: WatermelonDB (or similar "Local-First" ORM).
  • Why: Built specifically for React (fully compatible with Next.js Client Components) to handle massive datasets lazily. It only loads the exact data needed for the current screen, keeping the UI at 60fps even with huge databases.

☁️ Backend (Master Source)

• Database: PostgreSQL (The 3 Core Databases).
• API Architecture Options:
  • Option A: Node.js (TypeScript)
    • Pros: Unified language with frontend (TS). Fast iteration. Huge ecosystem.
    • Cons: Single-threaded nature can struggle with massive concurrent sync operations compared to compiled languages.
  • Option B: Go (Golang)
    • Pros: Industry standard for high-throughput microservices. Incredible concurrency (Goroutines) for syncing thousands of offline clients simultaneously.
    • Cons: Verbose error handling (if err != nil) can bloat code. Garbage Collection pauses (though minimal) exist, unlike Rust.
  • Option C: Rust (The Synergistic Choice) 🦀
    • Pros: Strongly Recommended. Since Tauri already requires a Rust backend for the local app, using Rust (Actix/Axum) for the cloud API creates a unified language ecosystem.
    • Advantage over Go: Offers comparable performance but with unmatched memory safety and the potential to share data structures/logic between the Local Tauri Backend and the Cloud API.
    • Cons: Steeper learning curve (Borrow Checker) leads to slower initial development velocity compared to Node/Go. Compile times are significantly slower.

✅ Feasibility & Performance Validation

• Speed Requirement: By bypassing the browser's storage limits and using Native SQLite (via Tauri's Rust backend or Capacitor's Native Bridge), the app can index and filter 100,000+ items directly on the device CPU, not the browser thread.
• IT Logging Requirement:
  • Tauri/Electron: Both provide full OS-level filesystem access, allowing precise logging of file paths (e.g., C:\Users\Alec\Documents\Quotes\Q1.pdf) to the audit log.
• Hardware Acceleration:
  • UI Rendering: The WebView (Tauri/Android) automatically leverages the device GPU for smooth scrolling and animations. Custom GPU compute logic is not required for database operations (SQLite is CPU-optimized and sufficient).
  • Logic: Data filtering remains a CPU-bound task; standard SQLite indexing is faster than attempting to offload string queries to a GPU.

---

🛡️ License & Privacy

⚠️ PROPRIETARY SOURCE CODE While this repository is publicly visible for portfolio/specification purposes, the source code and intellectual property contained herein are strictly private.

• Unauthorized copying, modification, distribution, or use of this software is prohibited.
• intended for internal company use or future commercial distribution by the owner.

---