Moiomo

Hallo zusammen, hier einmal mein Projektantrag wenn jemand zeit hat und sich den mal anschauen könnte und ein kleines Feedback gibt wäre es gut. Danke im Vorraus Der Text für das Projektziel kann ich leider nicht länger oder ausführlicher schreiben da dieser auf 3000 Zeichen limitiert ist. 1 Thema der Projektarbeit Entwicklung eines Odoo-Moduls zur automatisierten RMA-Erfassung und Lagersteuerung 2 Geplanter Bearbeitungszeitraum Beginn: 05.03.2026 Ende: 23.04.2026 3 Ausgangssituation Die Systemhaus GmbH (im Folgenden Systemhaus genannt) ist ein IT-Dienstleister mit Firmensitz bei Hanover. Seit über 30 Jahren unterstützt das Unternehmen kleine und mittelständische Betriebe mit IT-Lösungen und persönlicher Betreuung. Das Systemhaus betreut unteranderem bei einem Kunden vollumfänglich die IT-Struktur und ist ihr fester Partner für die Modernisierung der Systeme. Die Firma mit Sitz in der nähe von Braunschweig ist auf den internationalen Vertrieb von Produkten spezialisiert und gehört aufgrund der hohen Auftragszahlen im Bereich der ERP-Systeme zu den wichtigsten Großkunden des Systemhauses. Das Projekt wird innerhalb der Abteilung für Softwareentwicklung des Systemhauses realisiert. Der Anlass für das Projekt war ein schwerwiegender Cyberangriff bei unserem Kunden im vergangenen Jahr, bei dem kritische Systeme verschlüsselt wurden. Infolgedessen entschied sich die Firma, den geplanten Umstieg von der Altsoftware SoftEngine Webware (SE-Suite) auf das moderne ERP-System Odoo sofort durchzuführen, um die Betriebsfähigkeit mit einer sicheren Architektur wiederherzustellen. Obwohl Odoo bereits erfolgreich eingeführt wurde, bietet der Standard-Funktionsumfang keine ausreichende Lösung für das spezifische Retourenmanagement des Kundens. Im aktuellen Odoo-Standard zeigt sich die Problematik vor allem darin, dass kein geführter Prozess existiert, um Rücksendungen effizient über eine einfache Referenznummer, wie die Bestell- oder Lieferscheinnummer, zu identifizieren. Dies zwingt die Mitarbeiter dazu, Artikel und Mengen für jede Retoure mühsam manuell aus den bestehenden Lieferungen herauszusuchen, was bei der Menge an täglichen Vorgängen eine enorme Fehlerquelle für falsche Artikelnummern oder Mengenüberschreitungen darstellt. Darüber hinaus bietet der Odoo-Standard keine integrierte Logik, um Artikel während der physischen Rücknahme qualitativ zu bewerten und nach A-, B- oder C-Ware zu differenzieren. Da das System diese Qualitätsunterschiede nicht nativ verarbeiten kann, fehlen automatisierte Lagerreaktionen komplett. In der Praxis bedeutet dies, dass jeder Artikel nach der Prüfung manuell durch einen Mitarbeiter in das entsprechende Ziellager, etwa das Hauptlager für A-Ware umgebucht oder bei defekter C-Ware aus dem Lager entfernt werden muss. Auch die notwendige Dokumentation, wie das Hinterlegen von Fotos zur Beweissicherung oder Prüfberichten, ist im Standardprozess nicht zentral an einem übersichtlichen RMA-Vorgang gebündelt, was die Kommunikation und spätere Nachvollziehbarkeit erheblich erschwert. Die Nutzung eines bereits existierenden RMA-Tools aus der Odoo Community wurde nicht in Betracht gezogen. Gegen eine solche Drittanbieter-Lösung sprachen zum einen die hohen Anschaffungs- und potenziellen Lizenzkosten bei begrenzten Laufzeiten. Zum anderen bieten diese Tools oft nicht die nötige Flexibilität für individuelle Anpassungen. Eine starre Community-Lösung hätte zur Folge, dass sich die gesamte Lagerabteilung des Kunden an die vorgegebenen Prozesse der Software anpassen müsste, anstatt dass die Software die bewährten internen Abläufe unterstützt. Um eine langfristige Abhängigkeit von externen Anbietern zu vermeiden und eine exakt auf die Bedürfnisse des Kunden zugeschnittene, wartungsfreundliche Lösung zu erhalten, ist die Eigenentwicklung eines individuellen RMA-Moduls technisch und wirtschaftlich die sinnvollste Entscheidung. Dieser hohe manuelle Aufwand führt derzeit noch zu massiven Verzögerungen und gefährdet durch die fehlende Systemkontrolle die Konsistenz der Lagerbestände. 4 Projektziel Das Ziel des Projekts ist die Konzeption und Realisierung eines maßgeschneiderten RMA-Moduls innerhalb des ERP-Systems Odoo, um den Retouren Prozess zu digitalisieren und zu automatisieren. Das Projekt unterteilt sich in zwei Kernphasen, die strukturierte Datenerfassung und die logikbasierte Abwicklung der Warenströme. Das Projektziel ist erreicht, wenn das RMA-Modul die beschriebene Funktionalität vollständig innerhalb von Odoo abbildet, von der Rücksendeerfassung bis zur automatisierten Lagerbuchung inklusive Qualitätsklassifizierung. Teil 1 ist die Datenerfassung und Validierung Im ersten Modulabschnitt wird eine Eingabemaske entwickelt, die eine referenzbasierte Erstellung von Retouren ermöglicht. Der Anwender greift dabei auf existierende Lieferscheindaten (Stock Pickings) zu, wodurch Artikelpositionen, Mengen und Referenznummern automatisiert, geladen werden. Die Software unterstützt den physischen Wareneingang durch eine übersichtliche Abgleichfunktion der vorliegenden Artikel. Ein wesentlicher Bestandteil ist die Implementierung einer Validierungslogik: Das System erlaubt die Erfassung von Teilmengen, unterbindet jedoch technisch die Eingabe von Mengen, welche die ursprünglich gelieferte Anzahl überschreiten. Zur Optimierung der Kommunikation mit BackOffice und Buchhaltung werden strukturierte Felder für Rücksendegründe und interne Notizen integriert, um manuelle Rückfragen zu eliminieren. Teil 2 die Prozesslogik und Bestandsführung Der zweite Teil fokussiert sich auf die technische Verarbeitung und Qualitätsbewertung der Ware. Kernstück ist eine komplexe Mengen-Splitting-Logik zur Klassifizierung der Rückläufer in A-, B- und C-Ware. Das Modul ermöglicht es, eine einzelne RMA-Position auf diese Klassen aufzuteilen (z. B. 5 Einheiten in 2x A- und 3x B-Ware). Basierend auf dieser Einstufung löst das System automatisierte Folgeprozesse in der Odoo-Bestandsführung aus. A-Ware wird unmittelbar auf den verfügbaren Lagerplatz zurückgebucht. Bei B-Ware wird automatisch ein Service-Ticket zur technischen Prüfung oder Neuverpackung erstellt. Außerdem wird ein Automatisierter Ausbuchungsprozess (Verschrottung) aus dem Bestand vorgenommen bei C-Ware. Durch die enge zusammenhänge von physischer Sichtung und digitaler Erfassung werden manuelle Fehlbuchungen reduziert, die Transparenz erhöht und die Durchlaufzeiten im Reklamationsmanagement erheblich verkürzt. 5 Zeitplanung 1. Projektplanung (5 Stunden) Wirtschaftlichkeitsanalyse: Durchführung einer Kosten-Nutzen-Analyse sowie einer Make-or-Buy-Entscheidung bezüglich der Odoo-Eigenentwicklung (3 Std.) Projektmanagement: Erstellung der Ressourcenplanung und Definition der Meilensteine (2 Std.) 2. Technischer Entwurf (10 Stunden) Datenmodellierung: Entwurf der Datenbankstruktur (ER-Modell) für die neuen Odoo-Models (4 Std.) Prozessdesign: Erstellung von UML-Diagrammen (Aktivitäts- und Sequenzdiagramme) zur Visualisierung der Lagerlogik und des Formular-Ablaufs (4 Std.) UI-Konzeption: Spezifikation der Odoo-Views (XML-Templates) für eine intuitive Benutzerführung (2 Std.) 3. Implementierung (40 Stunden) Entwicklung RMA-Erstellungs-Formular: (16 Std.) Implementierung der Models zur temporären Datenerfassung (6 Std.) Programmierung der Validierungslogik für Belegreferenzen und Mengenbegrenzung (10 Std.) Entwicklung RMA-Verarbeitungs-Modul: (20 Std.) Umsetzung der Workflow-Steuerung und des Statusmanagements (Eingang, Bewertung, Abschluss) (12 Std.) Automatisierung der Lagerbuchungen (8 Std.) Sicherheitskonfiguration: Definition der Zugriffsberechtigungen und Record Rules (4 Std.) 4. Qualitätssicherung (5 Stunden) Testing: Durchführung von Modul- und Integrationstests in einer Entwicklungsumgebung (3 Std.) Bugfixing: Fehlerbehebung und finale Code-Optimierung (2 Std.) 5. Einführung & Kundenintegration (5 Stunden) Anwender-Leitfaden: Erstellung einer technischen Dokumentation und einer Schritt-für-Schritt-Anleitung für die Endbenutzer (3 Std.) Einweisung: Durchführung einer Schulung für den Kunden/Fachbereich zur Bedienung des neuen RMA-Prozesses (2 Std.) 6. Projektdokumentation (15 Stunden) IHK-Dokumentation: Erstellung des detaillierten, prozessorientierten Projektberichts inklusive technischer Erläuterungen und Anlagen (15 Std.)