Moiomo

Moin, ich wollte mal fragen was ihr denkt welche UML-Diagramme man besonders Intensiv noch üben sollte für die AP2. Ist es auch wichtig nicht so oft genutzte Diagramme wie Sequenzdiagramm intensiv zu lernen oder reicht bei denen zu sagen "Ja kenn ich habe ich mal gesehen und wie man es umsetzt weiß ich theoretisch auch"? Danke für eine Rückmeldung

@adam1 @VenomVelvet Danke für eure Kommentare. Leider sind wir nur ein sehr kleines Unternehmen mit ca 10 Leuten da ist das Problem das mein Ausbilder auch mein Chef bzw der Inhalte des Betriebes ist. Dokumentiert habe ich eigentlich alles es lief ja meistens über Teams oder Outlook kalender. Dann wäre das nächste wohl die Schule wo ich mich melden kann, da wenn ich bei der IHK etwas melde fällt es ja direkt auf mich da wir nur 2 Azubis haben und ich glaube dann da noch mehr ärger habe! Trotzdem danke für euere Rückmeldung

Moin zusammen, ich bin noch Azubi Fachinformatiker AE und brauche mal eure Meinung zu meiner aktuellen Situation. Ich sitze gerade an meiner Projektdoku (Abgabe ist der 23.04.). Anfang April habe ich meinem Ausbilder/Chef den aktuellen Stand geschickt und um Feedback gebeten. Gelesen, aber keine Antwort. Heute habe ich ihn nochmal erinnert und extra den Screenshot der IHK-Fristen mitgeschickt – wieder gelesen, wieder keine Reaktion. Das Problem ist, dass er fast nie im Büro ist. Er ist ständig bei Kunden vor Ort oder in irgendwelchen Meetings. Wenn man ihn dann doch mal kurz erwischt, heißt es immer nur: „Keine Zeit“. Ehrlich gesagt kommt es mir das so rüber, als wäre ihm meine Ausbildung und mein Abschluss völlig egal. Ich habe das Gefühl, ich bin eigentlich nur als günstige Arbeitskraft da, die ihre Aufgaben erledigen soll, aber wenn es um meine Prüfung geht, interessiert es niemanden. Ist das bei euch auch so extrem? Dass man so kurz vor der Deadline komplett allein gelassen wird, während der Chef/Ausbilder nur dem Tagesgeschäft hinterherrennt? Ich hab echt keine Lust, meine Note zu riskieren, nur weil im Betrieb keiner seinen Pflichten nachkommt. Wie würdet ihr euch an meiner Stelle verhalten?

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.)