Ziel dieses Projekts ist es, einen neuen Standort in die bestehende SAP Landschaft des Unternehmens zu integrieren. Hierzu mussten die bestehenden Prozesse der neuen Produktionsstätte analysiert und bewertet werden und diese mit den bestehenden Prozessen harmonisiert werden. Eine Herausforderung bestand darin, die Prozesse vor Ort anzupassen und zu optimieren. Um dies gewährleisten zu können, mussten die bestehenden Schnittstellen erweitert, Alt-Daten aufbereitet und migriert werden. Eine Teilaufgabe besteht darin, die bestehenden Formulare an die neuen Templates anzupassen und dabei die rechtlichen, lokalen Gegebenheiten zu berücksichtigen.
Im Rahmen der Stammdatenverwaltung wurde eine Lösung zur automatisierten Erweiterung von Business Partner Sichten entwickelt. Ziel war die vollständige Eliminierung manueller Pflegeprozesse nach der Neuanlage von Geschäftspartnern. Die Herausforderung bestand in der konsistenten Übernahme komplexer Default-Strukturen (u. a. KNVI, KNVV, KNVP, LFM1) sowie der Differenzierung zwischen Initialanlage, Updates und Deaktivierungsszenarien.
Auswirkung dieser Entwicklung:
Verantwortlichkeiten:
Im bestehenden Retourenprozess wurde die Entscheidung über die weitere Verarbeitung von retournierten Waren (z. B. Umlagerung, Ausschuss, Reparatur) bereits frühzeitig im Retourenauftrag getroffen, konnte jedoch systemseitig nicht durchgängig genutzt werden. Dies führte zu manuellen Nacharbeiten, redundanten Prüfprozessen und erhöhtem Abstimmungsaufwand zwischen Service, Logistik und Qualitätsmanagement. Ziel des Projekts war die durchgängige technische Abbildung dieser Folgeentscheidungen über den gesamten Prozess hinweg ? vom Retourenauftrag bis zur automatisierten Weiterverarbeitung in Logistik und Qualitätsmanagement.
Auswirkung dieser Entwicklung:
Verantwortlichkeiten:
In diesem Projekt wurde ein externes Kundenportal mithilfe eines OData-Service angebunden. Dazu wurden im SAP-System Kundendaten und ihre dazugehörigen technischen Plätze, mithilfe von CDS-Views, modelliert und als CDS-Referenzen im Service integriert. Über Filterfunktionen war es möglich, die technischen Plätze auf die aktuelle Kundensicht einzuschränken, sodass die REST-Anfragen nur die Daten übermittelten, die tatsächlich gefordert waren. Da technische Plätze über eine hochkomplexe Hierarchie verfügen, war es notwendig, das Datenmodell mithilfe einer Vater-Kind-Beziehung zu erzeugen. Dadurch konnten die Daten im Frontend, in vereinfachter Form visualisiert werden. Eine Besonderheit war die Implementierung der Rollen und Rechte, über die gewisse Personenkreise im Frontend nur ausgewählte Sichten einsehen und Aktivitäten ausüben durften.
Im Rahmen eines FI-nahen Reporting-Szenarios wurde eine performante Lösung zur Nachkalkulation und Plausibilitätsprüfung von Preisfindungen entwickelt. Ziel war die Verarbeitung großer Datenmengen aus SAP (RSEG) und Non-SAP Quellen in einem gemeinsamen Datenmodell, um fehlerhafte Preisfindungen automatisiert zu identifizieren. Die zentrale Herausforderung bestand in der effizienten Aggregation und Verarbeitung massiver Datenvolumina sowie der Parallelisierung der Preisfindungslogik.
Auswirkung dieser Entwicklung:
Verantwortlichkeiten:
Die Anforderung des Endbenutzers war es, eine App zur Verwaltung von Ansprechpartnern für Lieferanten bereitzustellen. Da die Transaktion BP (Business Partner) die Pflege nur über mehrere Schritte und Sichten ermöglichte, bestand der Wunsch, diesen Prozess zu vereinfachen. Als Grundlage diente eine Fiori-App, die eine Übersicht der Lieferanten (Business Partner) darstellte. Mit einem Klick auf einen ausgewählten Lieferanten war es möglich, zur Übersicht aller Ansprechpartner (Business Partner) eines Lieferanten zu navigieren. Hier konnten entweder weitere Ansprechpartner hinzugefügt oder gelöscht werden. Da Legacy-Code zum Einsatz kam, fiel die Wahl auf ein Unmanaged Scenario mit RAP. Wie weiter oben schon erwähnt, war die Pflege eines Ansprechpartners nur über mehrere Aktionen möglich. Das bedeutete, dass nach jeder Aktion ein Commit erfolgen musste. Im RAP-Umfeld war jedoch der Standard für das Durchführen eines Commits verantwortlich. Ein Commit aus dem Code heraus war nicht erlaubt. Als Workaround wurde der Aufruf eines RFC-fähigen Bausteins durchgeführt, der die Aktionen in einem separaten Task ausführte und anschließend einen Commit durchführte.
Im Rahmen dieses Projektes wurden Standorte von Lieferanten aus dem SAP (S4/HANA) an ein Third Party Tool zur Risikomanagementanalyse übertragen. Dieses Tool kann nicht nur einzelne Standorte als Lieferketten abbilden, sondern auch im Falle von Katastrophen auf Lieferengpässe hinweisen und/oder alternative Lieferketten darstellen. Verantwortliche Benutzer werden über Aktivitäten per Mail informiert, sollte z.B. eine Naturkatastrophe oder ein Krieg gewisse Regionen beeinflussen, die von der Lieferkette abhängig sind. Die Lieferantendaten wurden mithilfe einer REST-Schnittstelle an die CPI (Cloud Plattform Integration) gesendet, die wiederum für die Verbuchung der Daten zuständig war. Dabei galt es, die Datenstruktur bereits im SAP-Umfeld und die Zielstruktur anzupassen. Die Daten Lieferantendaten selbst mussten mithilfe von Wareneingängen und Bestellungen auf einen gewissen Zeitraum eingeschränkt werden, um sicherstellen zu können, dass die Lieferketten auf einem aktuellen Stand verbleiben. Über ein Fehlerprotokoll werden Datenverantwortliche darüber informiert, wenn die Stammdaten über eine unzureichende Datenqualität besitzen. Mit diesem Hebel sind die Datenverantwortlichen dazu verpflichtet, die Daten vollständig zu pflegen.
Der Arbeitsauftrag bestand in der massentauglichen Harmonisierung von Standardpreisen. Als Grundlage galt hierzu der GLD-Preis einzelner Artikel. Unter der Berücksichtigung eines vorgegebenen Schwellwerts, mussten Artikel mit einer Abweichung im Standard- und GLD-Preis ermittelt, verarbeitet und aktualisiert werden. Wurde der Schwellwert unter- bzw. überschritten, so durften keine Aktualisierungen erfolgen. Angelegt an eine SAP-Standardtransaktion wurde eine Report erzeugt, der die genannten Kriterien erfüllte.
Im Rahmen dieser S/4HANA Einführung, galt es Bestandsentwicklungen aus der Beschaffung (Purchase To Pay) zu erfassen, diese an die neuen Anforderungen (Cloud Readiness) zu konzipieren und in das Zielsystem zu übertragen. Damit das bewerkstelligt werden konnte, wurden die Entwicklungen in Webservices transformiert und die Kommunikation mithilfe einer Middleware bewerkstelligt. Anbindung eines Warenkorbsystems (Third-Party Non-SAP) an das SAP-System. Im selben Rahmen wurden Warenkörbe an das SAP-System übermittelt und als Bestellanforderungen angelegt. Es galt die relevanten Daten zu identifizieren und eine geeignete Datentransformationsschicht zu erstellen. Zugriffskontrollen wurde mithilfe eines technischen Users bewerkstelligt.
Profil
Senior Developer mit Integrations- & Performance-Fokus
Methoden:
Agile, Scrum, Testdriven Devel-opment, UML, Wasserfall
Backend & Architektur
Integration & APIs
Frontend
SAP UI5 | Fiori
Performance & Datenverarbeitung
SAP Kontext
Ziel dieses Projekts ist es, einen neuen Standort in die bestehende SAP Landschaft des Unternehmens zu integrieren. Hierzu mussten die bestehenden Prozesse der neuen Produktionsstätte analysiert und bewertet werden und diese mit den bestehenden Prozessen harmonisiert werden. Eine Herausforderung bestand darin, die Prozesse vor Ort anzupassen und zu optimieren. Um dies gewährleisten zu können, mussten die bestehenden Schnittstellen erweitert, Alt-Daten aufbereitet und migriert werden. Eine Teilaufgabe besteht darin, die bestehenden Formulare an die neuen Templates anzupassen und dabei die rechtlichen, lokalen Gegebenheiten zu berücksichtigen.
Im Rahmen der Stammdatenverwaltung wurde eine Lösung zur automatisierten Erweiterung von Business Partner Sichten entwickelt. Ziel war die vollständige Eliminierung manueller Pflegeprozesse nach der Neuanlage von Geschäftspartnern. Die Herausforderung bestand in der konsistenten Übernahme komplexer Default-Strukturen (u. a. KNVI, KNVV, KNVP, LFM1) sowie der Differenzierung zwischen Initialanlage, Updates und Deaktivierungsszenarien.
Auswirkung dieser Entwicklung:
Verantwortlichkeiten:
Im bestehenden Retourenprozess wurde die Entscheidung über die weitere Verarbeitung von retournierten Waren (z. B. Umlagerung, Ausschuss, Reparatur) bereits frühzeitig im Retourenauftrag getroffen, konnte jedoch systemseitig nicht durchgängig genutzt werden. Dies führte zu manuellen Nacharbeiten, redundanten Prüfprozessen und erhöhtem Abstimmungsaufwand zwischen Service, Logistik und Qualitätsmanagement. Ziel des Projekts war die durchgängige technische Abbildung dieser Folgeentscheidungen über den gesamten Prozess hinweg ? vom Retourenauftrag bis zur automatisierten Weiterverarbeitung in Logistik und Qualitätsmanagement.
Auswirkung dieser Entwicklung:
Verantwortlichkeiten:
In diesem Projekt wurde ein externes Kundenportal mithilfe eines OData-Service angebunden. Dazu wurden im SAP-System Kundendaten und ihre dazugehörigen technischen Plätze, mithilfe von CDS-Views, modelliert und als CDS-Referenzen im Service integriert. Über Filterfunktionen war es möglich, die technischen Plätze auf die aktuelle Kundensicht einzuschränken, sodass die REST-Anfragen nur die Daten übermittelten, die tatsächlich gefordert waren. Da technische Plätze über eine hochkomplexe Hierarchie verfügen, war es notwendig, das Datenmodell mithilfe einer Vater-Kind-Beziehung zu erzeugen. Dadurch konnten die Daten im Frontend, in vereinfachter Form visualisiert werden. Eine Besonderheit war die Implementierung der Rollen und Rechte, über die gewisse Personenkreise im Frontend nur ausgewählte Sichten einsehen und Aktivitäten ausüben durften.
Im Rahmen eines FI-nahen Reporting-Szenarios wurde eine performante Lösung zur Nachkalkulation und Plausibilitätsprüfung von Preisfindungen entwickelt. Ziel war die Verarbeitung großer Datenmengen aus SAP (RSEG) und Non-SAP Quellen in einem gemeinsamen Datenmodell, um fehlerhafte Preisfindungen automatisiert zu identifizieren. Die zentrale Herausforderung bestand in der effizienten Aggregation und Verarbeitung massiver Datenvolumina sowie der Parallelisierung der Preisfindungslogik.
Auswirkung dieser Entwicklung:
Verantwortlichkeiten:
Die Anforderung des Endbenutzers war es, eine App zur Verwaltung von Ansprechpartnern für Lieferanten bereitzustellen. Da die Transaktion BP (Business Partner) die Pflege nur über mehrere Schritte und Sichten ermöglichte, bestand der Wunsch, diesen Prozess zu vereinfachen. Als Grundlage diente eine Fiori-App, die eine Übersicht der Lieferanten (Business Partner) darstellte. Mit einem Klick auf einen ausgewählten Lieferanten war es möglich, zur Übersicht aller Ansprechpartner (Business Partner) eines Lieferanten zu navigieren. Hier konnten entweder weitere Ansprechpartner hinzugefügt oder gelöscht werden. Da Legacy-Code zum Einsatz kam, fiel die Wahl auf ein Unmanaged Scenario mit RAP. Wie weiter oben schon erwähnt, war die Pflege eines Ansprechpartners nur über mehrere Aktionen möglich. Das bedeutete, dass nach jeder Aktion ein Commit erfolgen musste. Im RAP-Umfeld war jedoch der Standard für das Durchführen eines Commits verantwortlich. Ein Commit aus dem Code heraus war nicht erlaubt. Als Workaround wurde der Aufruf eines RFC-fähigen Bausteins durchgeführt, der die Aktionen in einem separaten Task ausführte und anschließend einen Commit durchführte.
Im Rahmen dieses Projektes wurden Standorte von Lieferanten aus dem SAP (S4/HANA) an ein Third Party Tool zur Risikomanagementanalyse übertragen. Dieses Tool kann nicht nur einzelne Standorte als Lieferketten abbilden, sondern auch im Falle von Katastrophen auf Lieferengpässe hinweisen und/oder alternative Lieferketten darstellen. Verantwortliche Benutzer werden über Aktivitäten per Mail informiert, sollte z.B. eine Naturkatastrophe oder ein Krieg gewisse Regionen beeinflussen, die von der Lieferkette abhängig sind. Die Lieferantendaten wurden mithilfe einer REST-Schnittstelle an die CPI (Cloud Plattform Integration) gesendet, die wiederum für die Verbuchung der Daten zuständig war. Dabei galt es, die Datenstruktur bereits im SAP-Umfeld und die Zielstruktur anzupassen. Die Daten Lieferantendaten selbst mussten mithilfe von Wareneingängen und Bestellungen auf einen gewissen Zeitraum eingeschränkt werden, um sicherstellen zu können, dass die Lieferketten auf einem aktuellen Stand verbleiben. Über ein Fehlerprotokoll werden Datenverantwortliche darüber informiert, wenn die Stammdaten über eine unzureichende Datenqualität besitzen. Mit diesem Hebel sind die Datenverantwortlichen dazu verpflichtet, die Daten vollständig zu pflegen.
Der Arbeitsauftrag bestand in der massentauglichen Harmonisierung von Standardpreisen. Als Grundlage galt hierzu der GLD-Preis einzelner Artikel. Unter der Berücksichtigung eines vorgegebenen Schwellwerts, mussten Artikel mit einer Abweichung im Standard- und GLD-Preis ermittelt, verarbeitet und aktualisiert werden. Wurde der Schwellwert unter- bzw. überschritten, so durften keine Aktualisierungen erfolgen. Angelegt an eine SAP-Standardtransaktion wurde eine Report erzeugt, der die genannten Kriterien erfüllte.
Im Rahmen dieser S/4HANA Einführung, galt es Bestandsentwicklungen aus der Beschaffung (Purchase To Pay) zu erfassen, diese an die neuen Anforderungen (Cloud Readiness) zu konzipieren und in das Zielsystem zu übertragen. Damit das bewerkstelligt werden konnte, wurden die Entwicklungen in Webservices transformiert und die Kommunikation mithilfe einer Middleware bewerkstelligt. Anbindung eines Warenkorbsystems (Third-Party Non-SAP) an das SAP-System. Im selben Rahmen wurden Warenkörbe an das SAP-System übermittelt und als Bestellanforderungen angelegt. Es galt die relevanten Daten zu identifizieren und eine geeignete Datentransformationsschicht zu erstellen. Zugriffskontrollen wurde mithilfe eines technischen Users bewerkstelligt.
Profil
Senior Developer mit Integrations- & Performance-Fokus
Methoden:
Agile, Scrum, Testdriven Devel-opment, UML, Wasserfall
Backend & Architektur
Integration & APIs
Frontend
SAP UI5 | Fiori
Performance & Datenverarbeitung
SAP Kontext