KRNL
KRNL ist unser selbst entwickeltes Prozess-ERP — schlank, deutsch,
sprachgesteuert. Es baut die bei uns genutzten Odoo-Funktionen mit eigenem
Code nach:
- Verkauf — Verkaufsaufträge (v. a. aus Shopify), Bestätigung erzeugt Lieferung und Fertigungsauftrag
- Fertigung — Produkte mit Varianten, Stücklisten inkl. „Auf Varianten anwenden" und Phantom-Baugruppen, Fertigungsaufträge (druckbar, mit Barcode), Arbeitsplätze mit Arbeitsgängen und Zeiterfassung, Backflush, Demontage
- Einkauf — Lieferanten, Bestellungen (E-Mail-Versand, Sperren, Stornieren), Wareneingang, Lieferantenrechnungen mit 3-Wege-Abgleich, Wechselkurse, Einstandskosten (Fracht/Zoll auf den Warenwert)
- Lager — Bewegungs-Ledger (Eingang, Ausgang, Fertigung, Inventur, Ausschuss, Retoure), Bestände mit Prognose, Barcodes
- Bewertung — laufende Bestandsbewertung nach gleitendem Durchschnitt (AVCO), unveränderliche Wertschichten, Eröffnungsbewertung
- Personal — Mitarbeiter, Kommen/Gehen (auch per Ausweis-Scan), Schichtplan und Abwesenheiten mit Überschneidungsschutz, Arbeitszeit fließt in die Fertigungskosten
- Reparatur — Reparaturaufträge mit Teileverbrauch (einbauen / ausbauen / wiederverwenden)
- Versand — DHL-Direktanbindung (Label, Tracking, Retouren, Zolldaten) und Fulfillment-Rückmeldung an Shopify; Versandregeln wählen Kleinpaket/Paket nach Gewicht, SKU und Zone, Kartonagen liefern Verpackungsgewicht und werden beim Warenausgang als Verbrauch gebucht, Massendruck mit Filtern und Sammel-PDF am Packtisch
- Scanner-Arbeitsplatz — Belege per Barcode öffnen, Positionen scannen, Doppelscan bestätigt und bucht
- Auswertungen — Inventarwert, Produktion, verbaute Komponenten, Abverkaufsquote; Kennzahlen: Deckungsbeitrag, Rohertrag, Lagerumschlag und Reichweite, Liefertreue, RMA-Quote — mit Diagrammen
- KI-Analyse — Ad-hoc-Auswertungen, Tabellen und Diagramme auf Zuruf: Claude-Agent mit Nur-Lese-Zugriff; anlegen darf er nur aus einem festen Katalog (inkl. Produkte mit kompletter Variantenmatrix) und erst nach Bestätigung — Vorschläge lassen sich vorher Feld für Feld oder per Zuruf an die KI überarbeiten
- Rollen & Kommentare — Lager-/Fertigungs-/Büro-/Admin-Rollen mit passendem Menü; Verlauf + Kommentare an jedem Beleg
- Tickets — Bugtracker im System: Fehler melden über ein Slide-out am rechten Bildschirmrand (Seite vorbelegt, ohne die Arbeit zu verlassen); die Ticketliste zeigt ID, Status, Behebungsvermerk und den verlinkten GitHub-Commit — abgearbeitet von der Entwicklung auf Zuruf direkt über die Datenbank
- Beschaffung — Meldebestände (Min/Max) mit Vorschlagsliste; ein Klick erzeugt Bestellung oder Fertigungsauftrag
- Lose & Seriennummern — Rückverfolgung je Produkt (Chargen oder Serien), FIFO-Zuteilung, Rückverfolgungsansicht
- Ereignis-Monitor — jede Shopify-/DHL-/Mail-Transaktion protokolliert; Queue mit Backoff, Fehler am Beleg sichtbar
- Shopify-Bestandsabgleich — verfügbare Mengen werden an den Shop gemeldet; Handkorrekturen im Shop fallen als Abweichung auf und werden überschrieben
- Shopify-Produkt-Sync — Produkte in beide Richtungen anlegen und laufend abgleichen (Titel, Preise, SKU/Barcode); Bestellungen, Kunden und Stornos/Erstattungen kommen per Webhook in Sekunden an
- Vollständige Stammdaten — Kategorien, Steuern, Zahlungsbedingungen (inkl. Skonto), Incoterms, Tags, Kontakt-Hierarchie
Die Oberfläche funktioniert auf Monitor, Tablet und Telefon — am Packtisch
ersetzt das Telefon den Zweitbildschirm. Betrieb wahlweise per Docker,
hinter VPN oder auf Vercel mit Supabase (Anleitung).
Ausführliche Schritt-für-Schritt-Anleitung mit Rundgang durch die
Beispieldaten und Fehlerbehebung: docs/lokal-starten.md
Einstieg in die gesamte Dokumentation (Konzepte, Module, Entscheidungen):
docs/README.md — jede Entscheidung ist datiert im
Entscheidungslog begründet.
Schnellstart mit Docker (empfohlen zum Ausprobieren)
Voraussetzung ist nur Docker Desktop bzw. Docker Engine mit Compose:
SEED_DEMO=true docker compose up --build
Beim ersten Start werden Datenbank, Schema, Administrator und — wegen
SEED_DEMO=true — die Beispieldaten angelegt; das dauert ein paar Minuten.
Ohne die Variable startet das System bewusst leer (nur Administrator):
Beispieldaten kommen nie automatisch, nur auf diesen ausdrücklichen
Wunsch. Danach:
http://localhost:3000 · [email protected] / erp-admin
Mit Beispieldaten liegen zum Ausprobieren der Rollen zwei weitere Demo-Konten
bei: [email protected] und [email protected] (Passwort jeweils wie beim
Administrator).
Ist Port 3000 belegt: ERP_PORT=3001 docker compose up --build
(Windows PowerShell: $env:ERP_PORT=3001; docker compose up --build —
SEED_DEMO entsprechend als $env:SEED_DEMO='true').
Dauerhaft geht beides auch als Zeile in der Datei .env
(ERP_PORT=3001, SEED_DEMO=true).
Beispieldaten nachträglich in ein laufendes, leeres System holen:
docker compose exec app node --experimental-strip-types scripts/seed.ts --demo
Zugangsdaten für Shopify, DHL, E-Mail und KI
Die Anmeldedaten der externen Dienste liest Compose aus der Datei .env — die
Vorlage .env.example wird nicht gelesen, sie muss einmal kopiert werden:
cp .env.example .env # dann Schlüssel eintragen
docker compose up -d --build
Ohne .env läuft KRNL vollständig, nur die externen Anbindungen sind
deaktiviert (die Seite „KI-Analyse" sagt das ausdrücklich, wenn
ANTHROPIC_API_KEY fehlt). DATABASE_URL, PORT und NODE_ENV aus der
.env werden für den Container bewusst überschrieben: dort gilt die Datenbank
aus dem Compose-Netz und Port 3000.
docker compose down # anhalten (Daten bleiben erhalten)
docker compose down -v # anhalten und alle Daten verwerfen
docker compose logs -f app
Schnellstart ohne Docker
Voraussetzung: Node 22+ und ein erreichbarer PostgreSQL 16+.
npm install
cp .env.example .env # DATABASE_URL eintragen
npm run db:migrate # Schema anlegen
npm run db:seed -- --demo # Administrator + Beispieldaten
npm run dev # http://localhost:3000
Anmeldung mit den beim Seed ausgegebenen Zugangsdaten
(Standard: [email protected] / erp-admin — bitte danach ändern). Der
erste Login richtet den zweiten Faktor ein (Authenticator-App, Pflicht für
alle — umschaltbar unter Einstellungen → Sicherheit); dafür muss
SESSION_SECRET oder ZWEIFAKTOR_SCHLUESSEL in der .env stehen.
Die Beispieldaten enthalten eine Tastatur mit drei Farbvarianten und eine
Stückliste mit 20 Positionen, in der Gehäuse und Keycaps je Farbe gefiltert
sind. Damit lässt sich der Kernablauf sofort durchspielen:
Auftrag bestätigen → Fertigungsauftrag prüfen (nur die passenden Farbteile) →
fertig melden → Lieferung wird versandbereit.
Befehle
| Befehl | Zweck |
|---|
npm run dev | Entwicklungsserver |
npm run build / npm start | Produktions-Build und -Start |
npm run db:migrate | Ausstehende Migrationen einspielen |
npm run db:reset | Schema verwerfen und neu aufbauen (nur Entwicklung) |
npm run db:seed [-- --demo] | Administrator anlegen, optional Beispieldaten |
npm test | 312 Tests (brauchen eine erreichbare Datenbank) |
npm run test:prozesse | 46 Prozessläufe end-to-end gegen eine Wegwerf-Datenbank |
npm run lint | Linter (Biome) |
npm run check | Linter + Typprüfung + Tests + Prozessläufe — läuft auch in der CI |
npm run funktion <name> | Aktuelle Fassung einer SQL-Funktion finden |
Dokumente
Aufbau
src/
app/(erp)/… Seiten je Modul (Server Components + Server Actions)
app/api/… Webhooks, Cron, Barcode-Auflösung, Label-Auslieferung
db/migrations/ SQL-Migrationen — Schema UND Fachlogik
modules/prozesse/ Aktions-Registry + Torwächter — das Herzstück
modules/ki/ Chat-Agent, Sprachmodus, KI-Katalog
modules/ integrationen (Shopify), versand (DHL), demo, auth, lager, shared
tests/ Tests gegen eine echte Postgres-Datenbank
Die Buchungslogik liegt bewusst als Postgres-Funktionen in den Migrationen:
Bestandsbuchungen, Statusübergänge und Belegnummern laufen damit atomar in
einer Transaktion. Die Anwendungsschicht ruft sie auf und kümmert sich um
Anmeldung, Eingabeprüfung und Darstellung.
Grundregel: Jede Bestandsänderung ist eine Bewegung in stock_moves.
Bestände werden nie direkt geschrieben, sondern aus erledigten Bewegungen
fortgeschrieben — abgesichert durch einen Invariantentest.
