IST-Analyse: Alt-ERP „LCCargo"#

Kontext-Dokument. Bevor Caja gebaut wird, ist hier festgehalten, was das bestehende ERP fachlich kann — die Geschäftslogik im IST-Zustand. Sie ist Teil der Anforderungsbasis: Caja muss die bewährten Abläufe übernehmen und die bekannten Schwächen beheben. Quelle: Quellcode-Analyse des Alt-ERP („LCCargo / envioslccargo", Bitbucket). Eine vollständige technische Detailanalyse (inkl. Schema, Security-Audit) liegt intern im Repo unter docs/legacy-ist/.

1. Was ist das Alt-ERP?#

Ein ASP.NET-MVC-Websystem für See-Fracht in die Dominikanische Republik, ursprünglich von der Vorgängerfirma „LC Cargo" entwickelt und von Dominicano Express übernommen (die ausgelieferte Konfiguration trägt bereits die Firmendaten Tannenstrasse 98, 8424 Embrach). Produktiv 2018–2025, letzte Erweiterung Januar 2025.

Technologie (vollständig End-of-Life): ASP.NET MVC 5, Entity Framework 6, SQL Server, AngularJS 1.x (Support-Ende 2021), Crystal Reports, Forms-Authentifizierung, IIS/Windows. → Keine Migration des Stacks — Caja ist ein Neubau (Next.js · Supabase · Vercel). Übernommen wird die Fachlogik, nicht der Code.

Funktionaler Umfang: Das Alt-ERP deckt im Kern einen Ausschnitt des geplanten Caja-Umfangs ab — im Wesentlichen Logistik/Tracking, einen einfachen Kundenstamm, eine volumenbasierte Preisrechnung und eine Rollenverwaltung. Es kennt keine Offerten, kein Finanz-Ledger, kein Affiliate-Programm, kein WhatsApp/OCR und keine MWST — genau die Bereiche, die Caja neu schafft.

2. Das Datenmodell in einem Bild#

Das ganze Alt-ERP dreht sich um eine zentrale Entität: Invoice = Sendung + Rechnung in einem.

Invoice (Sendung + Rechnung)
├── 1..n  Paket (Box-/Barrel-Typ, Maße, Gewicht CH + RD, Preis, Container-Nr.)
├── Absender (Person, Pflicht)        ── Snapshot in die Sendung kopiert
├── Empfänger (Person, optional)      ── Snapshot in die Sendung kopiert
├── 3 Fahrer-Rollen (Abholung / Versand / Zustellung)
├── Status (10 Stück, mit Sortierreihenfolge)
├── Status-Historie (Tracking-Timeline)
├── Änderungs-Historie (wer hat wann was geändert)
└── Liefernachweis: Unterschrift + Paketfoto

Person ist polymorph: Mitarbeiter, Absender, Empfänger und Fahrer sind alle dieselbe Tabelle, unterschieden über einen Typ + Fahrer-Flags. Empfänger sind über eine Beziehung („RelatedPerson") an „ihren" Absender gebunden — daraus ergibt sich die Mandanten-Isolation (ein Kunde sieht nur seine eigenen Sendungen und Empfänger).

Caja-Mapping: Invoice → Modul 5 (Logistik & Tracking) + Modul 6 (Finanzen); Person → Modul 1 (CRM); Preise → Modul 3; Rollen → Modul 8.

3. Die Stammdaten im IST (direkt übernehmbar)#

Sendungs-Status (10)#

Caja sieht 10 Tracking-Schritte pro Box vor (inkl. DR_DEPOT, Entscheid 2026-06-28) — die obigen 10 IST-Status wurden in der Gap-Analyse darauf gemappt. Es gibt im Alt-ERP keine erzwungene Reihenfolge (jeder Übergang ist möglich); Caja erzwingt die Reihenfolge.

Verpackungstypen (8)#

3× Barrica (Fass: groß/mittel/klein), 4× Caja (Kiste: lang-groß, lang-mittel, quadratisch, rechteckig), 1× „Otro" (Sonstiges) — jeweils mit Icon.

Rollen (4)#

Administrador (nicht löschbar), Empleados, Clientes, Choferes (Fahrer). Feingranulare Berechtigungen über ~19 einzelne Aktionen (Sehen/Bearbeiten/Löschen je Bereich, Drucken, Preis ändern, Unterschrift, Tracking/Historie sehen).

4. Geschäftsregeln, die Caja übernehmen muss#

Diese im Code verankerten Regeln sind bewährt und gehören in die Anforderungen:

1. Preis = volumenbasiert: Preis = aufrunden( Menge × (Breite × Höhe × Länge / 100) × Preis-pro-m³ ). Das Gewicht ist NICHT preisrelevant — es dient nur Doku/Zoll. Der Divisor 100 ist eine firmenspezifische Tarifeinheit (kein echter Kubikmeter). → In Caja serverseitig berechnen (im Alt-ERP läuft die Rechnung nur im Browser).
2. Snapshot-Prinzip: Absender-/Empfängerdaten werden beim Anlegen der Sendung kopiert. Spätere Stammdaten-Änderungen wirken nicht rückwirkend auf bestehende Sendungen (historische Korrektheit der Belege).
3. Zwei Wiegepunkte: Gewicht bei Aufgabe (CH) + Nachwiegung bei Ankunft (RD) — beide getrennt erfasst (seit 2025).
4. Löschsperre: Sendungen ab Status „Transit RD / Lager RD / Ausgeliefert" sind nicht mehr löschbar.
5. 3 Fahrer-Rollen pro Sendung: Abholung, Versand, Zustellung — je optional, je aus einem gefilterten Fahrer-Pool.
6. Status-Benachrichtigung an den Absender bei Anlage + jedem Statuswechsel — außer bei „Zahlung ausstehend". → In Caja um WhatsApp als Kanal erweitern.
7. Container-Nummer pro Paket; das Zuweisen einer Container-Nr. markiert das Paket automatisch als „versendet".
8. Mandanten-Isolation: Kunden sehen nur ihre eigenen Sendungen und die an sie gebundenen Empfänger.
9. Liefernachweis: Unterschrift (auf dem Bildschirm gezeichnet) + Name des Unterzeichners + Paketfoto.
10. Doppeltes Audit: Statuswechsel landen in einer Tracking-Historie; jede Feldänderung in einem Änderungsprotokoll (wer/wann/was).
11. Zoll/Aduana: eigene Belege (PDF + Excel) auf Basis von Ausweisnummern, Paketbeschreibungen, Container-Nr. und RD-Gewicht.
12. Vier Belegtypen: Einzelrechnung, Sendungsliste, Zoll-Rechnung, Zoll-Excel.

5. Bekannte Schwächen (in Caja gezielt beheben)#

Ohne technische Details (vollständiges Audit intern):

• Preisberechnung nur im Browser — leicht manipulierbar, keine serverseitige Autorität.
• Massen-Statuswechsel schreibt keine Historie und sendet keine Benachrichtigung (anders als der Einzel-Edit) — inkonsistent.
• Anlagedatum geht beim Bearbeiten verloren (wird jedes Mal überschrieben).
• Sortierung der Sendungsliste funktioniert nicht (fest auf „neueste zuerst").
• Berechtigungen für Tracking/Historie/Unterschrift/Preis werden nur im UI ausgeblendet, nicht serverseitig durchgesetzt.
• Sicherheit insgesamt entspricht nicht heutigem Standard (Auth, Rechtevergabe, Datei-Upload, Verschlüsselung) — wird in Caja durch Supabase Auth + RLS + moderne Verfahren vollständig abgelöst.
• Kein Finanz-Ledger, keine MWST, keine Offerten, kein Affiliate — die zentralen Caja-Neuerungen existieren im Alt-ERP nicht.

6. Nächster Schritt: Gap-Analyse#

Auf Basis dieser IST-Aufnahme folgt die Caja-Gap-Analyse: jede IST-Geschäftsregel wird gegen die Caja-Module (Modul 1, Modul 3, Modul 4, Modul 5, Modul 6, Modul 8) und das konsolidierte Schema gemappt — abgedeckt / teilweise / fehlt — mit konkreten Ergänzungsvorschlägen. Offene Geschäftsentscheide (Status-Set, Tarifmodell, 3-Fahrer-Logik, Pflichtfelder) werden dabei zur Klärung markiert.