Blog

Case study: Replikacja obszarów MRP pomiędzy SAP MDG i SAP ECC

  • Jakub Świerczek

    4 min czytania
Case study: Replikacja obszarów MRP pomiędzy SAP MDG i SAP ECC Data utworzenia: 28 września 2022

Wielu klientów decyduje się na wdrożenie narzędzia MDG (Master Data Governance) jako pierwszy krok, poprzedzający przekształcenie systemu SAP R/3 do S/4 HANA.

Jednakże pomimo tego, że integracja danych podstawowych z systemem SAP ECC jest jednym z głównych celów, dla których powstało narzędzie MDG, to niestety wciąż istnieją obiekty danych podstawowych, dla których nie ma standardowego rozwiązania ich replikacji do SAP ECC. Przykładem mogą być obszary MRP, o które możliwe jest rozszerzanie danych podstawowych materiału.

Z artykułu dowiesz się:

  1. Z jakimi problemami borykał się nasz klient i jakie rozwiązanie docelowe w zakresie MDG zostało wybrane, aby uniknąć konieczności podwójnego utrzymywania tych samych danych w dwóch różnych systemach?
  2. Jak wyglądało wdrożenie i z jakich etapów się składało?
  3. Jakie korzyści z punktu widzenia biznesu zyskał nasz klient?

Jeden z naszych klientów zgłosił wymóg przeniesienia funkcjonalności rozszerzania materiałów do obszarów MRP z aktualnego systemu SAP ECC do nowo wdrożonego narzędzia MDG.  Dzięki temu rozwiązaniu użytkownicy mogliby rozszerzyć dany materiał o obszar MRP od razu podczas rozszerzenia takiego materiału o zakład (w ramach tego samego CRa). Samo włączenie funkcjonalności rozszerzenia obszaru MRP po stronie MDG nie stanowiło problemu, jednak nasz zespół projektowy zdał sobie sprawę, że obiekt ten nie jest replikowany z S/4 MDG do SAP ECC, który z kolei jest wciąż używany jako system transakcyjny klienta.

Powodem tego jest fakt, że obszary MRP są uznawane przez SAP jako obiekt zewnętrzny należący do Planowania Zapotrzebowań Materiałowych (MRP) i dlatego nie są uwzględniane w IDocu o type MATMAS, który jest typem komunikatu używanym do przesyłania zmian danych podstawowych materiału. Co więcej, ogólne wykorzystanie ALE (Application Link Enabling) i DRF (Data Replication Framework) dla obszarów MRP nie jest obecnie możliwe, ponieważ nie istnieje żaden inny typ IDoca do ich dystrybucji. SAP oficjalnie to potwierdza w poniższych notach OSS:

  • 2268203 – Not possible to Update / Transfer MRP Area when using Message Type MATMAS.
  • 2816571 – Functional Restrictions in MDG for Material on SAP S/4HANA 1909.
  • 425493 – MM17: MRP area cannot be mass maintained.

Rozwiązanie:

W momencie zgłoszenia wymagania przez klienta, nasz zespół BPX rozpoczął analizę stanu obecnego, aby dowiedzieć się, jak wygląda aktualny proces i jaki jest najlepszy sposób wdrożenia rozwiązania docelowego. Ostateczną decyzją na jaką się zdecydowano było rozszerzenie struktury standardowego IDoca o typie MATMAS05 o nowe segmenty, które będą przechowywać dane obszaru MRP (MDMA).

Wdrożenie rozwiązania można podzielić na trzy etapy:

  1. Dostosowanie struktury IDoca o typie MATMAS w obu systemach SAP.
  2. Zmiana kodu ABAP w odpowiednim wyjściu użytkownika po stronie MDG, aby uwzględnić logikę przetwarzania dla nowego, niestandardowego segmentu.
  3. Aktualizacja modułów funkcyjnych po stronie SAP ECC, aby pobierały dane z przychodzących obiektów IDoca MATMAS i tworzyły lub zmieniały dane obszaru MRP.

Korzyści z rozwiązania:

Dostosowanie istniejącego IDoca (MATMAS) pozwoliło nam na redukcję kosztów wdrożenia. Ponadto mogliśmy dostarczyć rozwiązanie w krótkim terminie, ponieważ zostały wykorzystane istniejące rozwiązania integracyjne, a użytkownicy byli już zaznajomieni z całym ich przebiegiem. Co za tym idzie klient nie musiał zmieniać własnych procesów i mógł łatwo przetestować rozwiązanie.

Z punktu widzenia działalności biznesowej, wdrożone rozwiązanie pozwala klientowi na utrzymanie obszarów MRP w narzędziu S/4 MDG wraz z wszystkimi innymi danych podstawowymi materiałów. Powoduje to brak konieczności podwójnego utrzymywania tych samych danych w dwóch różnych systemach (MDG i ECC). Utrzymanie MDG jako jedynego źródła dla całego obiektu danych podstawowych materiału ogranicza również liczbę potencjalnych błędów popełnionych przez użytkownika i zapewnia synchronizację obu systemów. Użytkownicy końcowi zgłosili również, że całe rozwiązanie pomogło skrócić czas tworzenia danych podstawowych materiału.

  • Autor:

    Jakub Świerczek

    Konsultant SAP MD

Spodobał Ci się artykuł? Udostępnij go!

Dziękujemy

Zobacz ostatnie wpisy

To dzięki Wam dążymy do doskonałości, w dostarczanych projektach i wspólnych wyzwaniach. Zapraszamy do czytania naszego bloga, dzięki któremu dowiesz się więcej o naszych realizacjach i doświadczeniu. Przeczytaj artykuły poświęcone cyfrowej transformacji biznesu, o systemach ERP i Business Intelligence. Poznaj ciekawe zastosowania technologii przyszłości w praktyce.

  • Blog

    Organizacja i optymalizacja pracy w firmie – przejrzyste kokpity menedżerskie i kompleksowe zarządzanie procesami HR z aplikacją TETA ME

    Czytaj więcej

  • Blog

    Qlik, Power BI, Tableau – porównanie narzędzi i przegląd najważniejszych funkcji

    Czytaj więcej

  • Blog

    Zapobieganie efektowi Forward Buy: zwiększ zyski dzięki wsparciu promocji

    Czytaj więcej

  • Blog

    Wnioski urlopowe w TETA ME

    Czytaj więcej

Skontaktuj się z nami

Porozmawiajmy! Interesują Cię nasze rozwiązania? Nasi eksperci odpowiedzą na wszystkie Twoje pytania.




    Administratorem Twoich danych osobowych jest BPX S.A. (KRS: 0000274149), a szerszą informację o przetwarzaniu danych osobowych przez BPX S.A. możesz znaleźć w Polityce Prywatności.

    • SAP
    • Qlik
    • Infor
    • enova365
    • Teta
    • Visual Fabriq
    • RGM
    • Power BI
    • Semarchy
    • K4 Inphinity
    • Vizlib
    • Tricentis Tosa