163 lines
7.9 KiB
Markdown
163 lines
7.9 KiB
Markdown
# MRP Codex
|
|
|
|
Foundation release for a modular Manufacturing Resource Planning platform built with React, Express, Prisma, SQLite, and a single-container Docker deployment.
|
|
|
|
Current foundation scope includes:
|
|
|
|
- authentication and RBAC
|
|
- company branding and theme settings
|
|
- CRM customers and vendors with create/edit/detail workflows
|
|
- CRM search, filtering, status tagging, and reseller hierarchy
|
|
- CRM contact history, account contacts, and shared attachments
|
|
- inventory item master, BOM, warehouse, stock-location, and stock-transaction flows
|
|
- sales quotes and sales orders with searchable customer and SKU entry
|
|
- file storage and PDF rendering
|
|
|
|
## Workspace
|
|
|
|
- `client`: React, Vite, Tailwind frontend
|
|
- `server`: Express API, Prisma, auth/RBAC, file storage, PDF rendering
|
|
- `shared`: shared TypeScript contracts and constants
|
|
|
|
## Local Development
|
|
|
|
1. Use Node.js 22 for local development if you want Prisma migration commands to behave the same way as Docker.
|
|
2. Install dependencies with `npm.cmd install`.
|
|
3. Copy [`.env.example`](D:\CODING\mrp-codex\.env.example) to `.env` and adjust values if needed.
|
|
4. Generate Prisma client with `npm run prisma:generate`.
|
|
5. Apply committed migrations with `npm run prisma:deploy`.
|
|
6. Start the workspace with `npm run dev`.
|
|
|
|
The frontend runs through Vite in development and is served statically by the API in production.
|
|
|
|
Seeded admin credentials for first login:
|
|
|
|
- email: `admin@mrp.local`
|
|
- password: `ChangeMe123!`
|
|
|
|
## Docker
|
|
|
|
Build and run:
|
|
|
|
```bash
|
|
docker build -t mrp-codex .
|
|
docker run -p 3000:3000 -v mrp_data:/app/data mrp-codex
|
|
```
|
|
|
|
Command-line build notes:
|
|
|
|
- The Dockerfile is intended to be built directly from the repo root with `docker build`
|
|
- `puppeteer` browser download is disabled during image build because the runtime image installs system Chromium
|
|
- You can override the Node base image version if needed:
|
|
|
|
```bash
|
|
docker build --build-arg NODE_VERSION=22 -t mrp-codex .
|
|
```
|
|
|
|
The container startup script runs `npx prisma migrate deploy` automatically before launching the server.
|
|
|
|
This Docker path is currently the most reliable way to ensure the database schema matches the latest CRM and inventory migrations on Windows.
|
|
|
|
## Persistence And Backup
|
|
|
|
- SQLite database path: `/app/data/prisma/app.db`
|
|
- Uploaded files: `/app/data/uploads`
|
|
- Backup the entire mounted `/app/data` volume to preserve both records and attachments.
|
|
|
|
## CRM
|
|
|
|
The current CRM foundation supports:
|
|
|
|
- customer and vendor list, detail, create, and edit flows
|
|
- search by text plus status and state/province filters
|
|
- customer reseller flag, reseller discount, and parent-child hierarchy
|
|
- contact-history timeline entries for notes, calls, emails, and meetings
|
|
- multiple account contacts with role and primary-contact tracking
|
|
- shared file attachments on customer and vendor records
|
|
- commercial terms fields including payment terms, currency, tax exempt, and credit hold
|
|
|
|
Recent CRM features depend on the committed Prisma migrations being applied. If you update the code and do not run migrations, the UI may render fields that are not yet present in the database.
|
|
|
|
## Inventory
|
|
|
|
The current inventory foundation supports:
|
|
|
|
- protected item master list, detail, create, and edit flows
|
|
- SKU, description, type, status, unit-of-measure, sellable/purchasable, default cost, default price, and notes fields
|
|
- BOM header and BOM line editing directly on the item form
|
|
- searchable component lookup for BOM lines, designed for large item catalogs
|
|
- SKU-first searchable component lookup for BOM lines, with SKU shown in the picker and description kept separate in the selected row
|
|
- BOM detail display with component SKU, name, quantity, unit, notes, and position
|
|
- protected warehouse list, detail, create, and edit flows
|
|
- nested stock-location management inside each warehouse record
|
|
- inventory transaction posting for receipts, issues, and adjustments
|
|
- item on-hand quantity, stock-by-location balances, and recent stock history
|
|
- item-level file attachments for drawings and support documents
|
|
- seeded sample inventory items and a starter assembly BOM during bootstrap
|
|
- seeded sample warehouse and stock locations during bootstrap
|
|
|
|
This module introduces `inventory.read` and `inventory.write` permissions. After updating the code, restart the server against the migrated database so bootstrap can upsert the new permissions onto the default administrator role.
|
|
|
|
`defaultPrice` now flows from inventory items into quote and sales-order line entry when a SKU is selected. Users can still override the line price after selection.
|
|
|
|
## Sales
|
|
|
|
The current sales foundation supports:
|
|
|
|
- quote and sales-order list, detail, create, and edit flows
|
|
- searchable customer lookup instead of static customer dropdowns
|
|
- SKU-searchable line entry for quote and order lines
|
|
- status quick actions directly from quote and order detail pages
|
|
- quote conversion into a sales order
|
|
- line-level unit prices populated from the selected inventory item default price
|
|
|
|
This module introduces `sales.read` and `sales.write` permissions. After updating the code, restart the server against the migrated database so bootstrap can upsert the new permissions onto the default administrator role.
|
|
|
|
Moving forward, any UI that requires searching for records or items should use a searchable picker/autocomplete rather than a static dropdown. Filter controls can remain dropdowns, but non-filter lookup fields such as SKU pickers, customer selectors, vendor selectors, and similar operational search inputs should not be implemented as long static selects.
|
|
|
|
## UI Density
|
|
|
|
The active client screens have been normalized toward a denser workspace layout:
|
|
|
|
- form controls and action bars use tighter padding
|
|
- CRM, inventory, warehouse, settings, dashboard, and login screens use reduced card spacing
|
|
- headings, metric cards, empty states, and long-text blocks were tightened for better data density
|
|
|
|
This denser layout is now the baseline for future screens. New pages should avoid reverting to oversized card padding, tall action bars, or long static dropdowns for operational datasets.
|
|
|
|
## Branding
|
|
|
|
Brand colors and typography are configured through the Company Settings page and the frontend theme token layer. Update runtime branding in-app, or adjust defaults in the theme config if you need a new baseline brand.
|
|
|
|
Logo uploads are stored through the authenticated file pipeline and are rendered back into the settings UI through an authenticated blob fetch, so image preview works after save and refresh.
|
|
|
|
## Migrations
|
|
|
|
- Create a local migration: `npm run prisma:migrate`
|
|
- Apply committed migrations in production: `npm run prisma:deploy`
|
|
- If Prisma migration commands fail on a local Node 24 Windows environment, use Node 22 or Docker for migration execution. The committed migration files in `server/prisma/migrations` remain the source of truth.
|
|
|
|
As of March 14, 2026, the latest committed domain migrations include:
|
|
|
|
- CRM status and list filters
|
|
- CRM contact-history timeline
|
|
- reseller hierarchy and reseller discount support
|
|
- CRM commercial terms and account contacts
|
|
- CRM lifecycle stages and operational metadata
|
|
- inventory item master and BOM foundation
|
|
- warehouse and stock-location foundation
|
|
- inventory transactions and on-hand tracking
|
|
- sales quote and sales-order foundation
|
|
- inventory default price support
|
|
|
|
## UI Notes
|
|
|
|
- Dark mode persistence is handled through the frontend theme provider and should remain stable across page navigation.
|
|
- The shell layout is tuned for wider desktop use than the original foundation build, and now exposes CRM, inventory, settings, and planning modules from the same app shell.
|
|
- The active module screens now follow a tighter density baseline for forms, tables, and detail cards.
|
|
- The client build still emits a Vite chunk-size warning because the app has not been code-split yet.
|
|
|
|
## PDF Generation
|
|
|
|
Puppeteer is used by the backend to render HTML templates into professional PDFs. The Docker image includes Chromium runtime dependencies required for headless execution.
|