W pierwszej części serii SAP EWM dla początkujących, poznaliśmy system od strony teoretycznej. Wiemy już co sprawia, że jest on tak wyjątkowy i wiemy jak wyglądałaby rzeczywistość bez posiadania modułu magazynowego. Powiedzieliśmy sobie, że EWM-ka komunikuje się z systemem ERP za pomocą interfejsu qRFC. Teraz pojawia się pytanie jak ta komunikacja dokładnie wygląda? Jakie konfiguracje powinniśmy wykonać aby system ERP zaczął „gadać” z systemem EWM. Czy jeśli posiadamy moduł EWM wbudowany w S/4 HANA to komunikuje się on z pozostałymi modułami tak samo jak w przypadku instalacji zdecentralizowanej? Zerknijmy w podstawową konfigurację systemu EWM jaką należy wykonać po każdej instalacji systemu.

Słowem wstępu wspomnę tylko, że jeśli pracujesz na już istniejącym serwerze S4HANA to zapewne te kroki zostały już wcześniej przez kogoś wykonane i nie musisz konfigurować nic nowego. Konfigurację połączenia między systemami wykonywane są przez zespół SAP BASIS, którego rolą jest przygotowanie podłoża do dalszej konfiguracji systemu a także dbanie o to by komunikacja między systemami przebiegała prawidłowo. Wstępna konfiguracja systemu wymaga wykonania konfiguracji zarówno po stronie ERP jak i EWM (systemu klienta jak i systemu zdalnego). Zacznijmy zatem od ustawień po stronie systemu S4HANA.

Konfiguracja po stronie SAP ERP.

1. Definicja sytemu logicznego dla mandanta S/4 HANA (BD54)

Pierwszym krokiem jest utworzenie systemu logicznego dla systemu S/4 HANA. System logiczny będzie niezbędny do definicji miejsca przeznaczenia RFC oraz utworzenia kanału dystrybucji (o tym później). Mówiąc prościej definicja tego wpisu umożliwi nam utworzenie pomostu pomiędzy systemem źródłowym a tym, z którym chcemy się połączyć. Definicji systemu logicznego możemy dokonać za pośrednictwem transakcji BD54 lub poprzez ścieżkę menu widoczną niżej (przewodnik konfiguracji SPRO):

Ciekawostka: Możliwe że w niektórych poradnikach w sieci natkniesz się na inną ścieżkę menu w SPRO niż ta wskazana przeze mnie. To nie jest żaden błąd. Zerknij w notę SAP 2472074 która mówi że w systemach od wersji SAP_BASIS_756 opis gałęzi menu SPRO: SAP NetWeaver został zamieniony na ABAP Platform.

W trakcie edycji zauważysz, że system informuje o tym, że próbujesz zmieniać tabelę niezależną od mandanta. Te ostrzeżenie oznacza, że każda dokonana zmiana będzie miała wpływ na wszystkich pozostałych klientów w systemie. To z kolei oznacza, że każda zmiana musi być starannie przemyślana. Jak wspomniałem wcześniej system logiczny jest pomostem pomiędzy „dwoma światami” więc każda pomyłka przy próbie edycji może prowadzić do poważnych niespójności.

System logiczny można by porównać do adresu IP w sieci, którego celem jest unikalna identyfikacja umożliwiająca połączenie się z nim. Oczywiście opisywany krok nie jest specyficzny tylko dla konfiguracji połączenia z EWM ale z wszelkimi innymi systemami. SAP rekomenduje aby tworząc system logiczny użyć takie samo nazewnictwo jakie będzie użyte dla miejsca przeznaczenia RFC. Nazewnictwo rekomendowane przez SAP to:

ABCCLNT100 gdzie ABC stanowi ID systemu a CLNT100 jest numerem klienta (rysunek 8 pokazuje skąd wziąć ID systemu).

Wskazówka: jeśli chcesz sprawdzić nazwę aktualnego systemu logicznego, w którym się znajdujesz skorzystaj z modułu funkcyjnego: (SE37) OWN_LOGICAL_SYSTEM_GET, inną opcją może być odczytanie tabeli T000 w transakcji SE16 (to będzie wpis z Twoim numerem mandanta).
Aby sprawdzić z jakimi systemami logicznymi „partnerskimi” się łączysz skorzystaj z tabeli: (SE16N) TBDLS.

2. Definicja fikcyjnego systemu logicznego dla modułu EWM (BD54).

W następnym kroku utworzymy tzw. fikcyjny logiczny system dla EWM-ki. Ten krok niczym nie różni się od poprzedniego. Po prostu tworzymy drugi wpis, który niezbędny będzie do utworzenia kanału dystrybucji potrzebnego do konfiguracji połączenia qRFC. Zarówno w przypadku wbudowanej czy zdecentralizowanej instalacji wymagane jest tworzenie systemu logicznego dla EWM. Z tą różnicą, że dla EWM wbudowanej w SAP S/4 HANA system logiczny jest tylko fikcyjny (bo jest na tym samym serwerze) a w wersji zdecentralizowanej rzeczywisty (na oddzielnym serwerze). W obydwu przypadkach ten krok jest niezbędny do nawiązania komunikacji pomiędzy EWM i SAP S/4 HANA.

3. Przypisanie logicznego systemu do mandanta – SPRO lub SSC4

Jak już mamy utworzone systemy logiczne to możemy zabierać się za ich przypisywanie do mandanta. W tym celu uruchamiamy transakcję SCC4 lub idziemy do menu wskazanego na rysunku 1 (przypisanie systemów logicznych do mandanta). Tworzymy wpis z nazwą mandanta:

Po dwukrotnym kliknięciu przechodzimy do szczegółów wpisu, w którym definiujemy rolę jaką mandant pełni w systemie (czy jest to mandant konfiguracyjny, szkoleniowy itd.). Wprowadzamy również nazwę systemu logicznego zdefiniowanego w poprzednich krokach.

Po zdefiniowaniu systemu logicznego i jego przypisaniu do mandanta, możemy wreszcie przejść do ustawień miejsca przeznaczenia qRFC. Czym właściwie jest qRFC? Remote Function Call jest metodą komunikacji między systemami SAP. Jego rolą jest wywołanie funkcji, które wykonają się po stronie zdalnego systemu. Taką funkcją może być odczyt tabeli z bazy danych lub zmiana statusów dokumentów dostaw. Można by rzec, że RFC jest furtką do innego zdalnego systemu. Zapraszam do tego linka, jeśli chcielibyście poczytać o RFC nieco więcej.

4. Definicja miejsca przeznaczenie RFC (SM59)

RFC używa architekturę serwera klienta do nawiązania połączenia między systemami. System, który wysyła żądanie jest zwany systemem klienta a odbiorca żądania (ten który tą żądanie przetwarza) jest serwerem RFC. Komunikacja jest oparta na protokole TCP/IP, który umożliwia szybką wymianę danych transakcyjnych, danych podstawowych oraz wykonywanie programów i funkcji na zdalnym serwerze (w naszym przypadku EWM). Do zdalnej komunikacji między systemami potrzebny jest również użytkownik i hasło. Można by to wyobrazić sobie w taki sposób, że RFC jest autobusem, w którym musimy przewieźć pasażera, który wykona misję specjalną jak już dojedzie do celu. Tym pasażerem, komandosem jest użytkownik z pełnymi uprawnieniami, który będzie wykonywał czynności na terenie do którego zostanie wysłany 🙂 Misją może być odczytanie ilości zapasów posiadanych w systemie EWM na zlecenie działu sprzedaży. Przypuśćmy że chcieliby odczytać ile zapasów i w jakich lokalizacjach znajduje się w magazynie. Jako ciekawostkę wspomnę że podczas testów migracji EWM do systemu S/4 HANA mieliśmy potężny problem z uruchomieniem urządzeń pick-by-voice po stronie systemu S4. Okazało się, że podczas migracji systemu zapomniano tylko o jednym użytkowniku. To był właśnie nasz komandos odpowiedzialny za wymianę danych między system EWM a serwerem Pick by Voice.

Teraz wyobraźmy sobie, że nasz komandos musi wykonać bardzo dużo zadań w systemie zdalnym i z jakiegoś powodu napotyka na trudności (np. chwilowy brak połączenia). Po usunięciu usterki chcielibyśmy aby nasze opóźnione już zadania zostały wykonane w takiej samej kolejności jak zostały zainicjowane na początku. Zadanie musi czekać na swoją kolej. Do tego właśnie wykorzystuje się metodę zwaną qRFC (q = queue czyli po polsku kolejka). Rolą wspomnianych kolejek (queue) jest zarządzanie żądaniami wysyłanymi do systemu docelowego w sposób zorganizowany.

Konfiguracje, które zrobiliśmy do tej pory miały na celu przygotowanie podłoża niezbędnego do zdefiniowania połączenia z systemem EWM. Przejdźmy zatem do kolejnego kroku jakim jest definicja miejsca przeznaczenia RFC. Idziemy do transakcji SM59 lub korzystamy z menu jak niżej (w SAP Easy Access):

Nazwa miejsca przeznaczenia dla komunikacji qRFC (destination) powinna być taka sama jak system logiczny zdefiniowany w poprzednim kroku (zwłaszcza jeśli konfigurujemy EWM w wersji wbudowanej), niestety w moim przypadku BASIS zdefiniował nazwę miejsca przeznaczenia inaczej:

W tym kroku musimy utworzyć dwa wpisy dla klienta oraz dla systemu docelowego EWM. Zarówno w jednym i drugim wybieramy rodzaj połączenia oraz wprowadzamy nazwę serwera docelowego (adres IP dla klienta i nazwę hosta dla EWM). Rodzaj połączenia 3 – oznacza połączenie do systemu ABAP przy użyciu protokołu TCP/IP. Bardzo istotną kwestią jest status rozdziału obciążenia, który dla klienta systemu ERP musi być ustawiony na „TAK”. Rozłożenie obciążenia jest koncepcją służącą do rozłożenia obciążenia serwerem pomiędzy różnymi instancjami systemu SAP w sposób zapewniający jak największą wydajność. Musimy pamiętać o tym, że w SAP możemy posiadać więcej tego typu połączeń, np. z aplikacją FIORI, z NWBC, z serwerem wydruku formularzy PDF itd. Rozłożenie obciążenia ma tutaj zatem ogromne znaczenie, ponieważ zapobiega przeciążeniu serwera systemu ERP. Serwer aplikacji określany jest automatycznie w zależności od aktualnego przeciążenia. Dla systemu EWM opcja może być ustawiona jako „NIE”. Więcej na temat poczytacie tutaj.

W zakładce „logowanie i bezpieczeństwo” wprowadzamy dane użytkownika SAP do zdalnego logowania (wspomnianego wcześniej komandosa).

W przypadku trudności z określeniem ID systemu lub nazwy serwera aplikacji można skorzystać SAP Logon PAD. Po wciśnięciu prawego przycisku myszki wystarczy wybrać „właściwości”. W kolejnym oknie pojawią się dane niezbędne do skonfigurowania połączenia.

W transakcji SM51 natomiast możemy znaleźć do jakiego serwera podłączony jest serwer aplikacji:

Po wykonaniu niezbędnych kroków konfiguracyjnych możemy wykonać test połączenia. Wystarczy wcisnąć przycisk widoczny na zdjęciu niżej. System spróbuje zainicjować połączenie z systemem docelowym sprawdzając w ten sposób poprawność adresu IP.

Wspomnieliśmy wcześniej o tym, że użytkownik zdefiniowany w połączeniu RFC musi posiadać odpowiednie uprawnienia. To jest powód dla którego, oprócz testu połączenia, powinniśmy dokonać jeszcze testu uprawnień. Taki test możemy wykonać z poziomu menu jak niżej:

Mamy już skonfigurowane połączenie z systemem ERP, teraz powyższe kroki należy wykonać również dla systemu EWM. Jak już wspomniałem wcześniej konfiguracja połączenia EWM będzie się różnić tym, że status rozdziału obciążenia serwera powinien być ustawiony na „NIE”. Dodatkowo będziemy musieli ustawić numer instancji (który weźmiemy z SAP logon PAD – rysunek 8).

5. Opracowanie miejsca przeznaczenia RFC dla wywołania metody (BD97)

Kolejnym krokiem konfiguracji jest opracowanie miejsca przeznaczenia komunikacji RFC dla synchronicznego wywołania metody. Dokonujemy tutaj przypisania systemu zdalnego SAP EWM do systemu S/4HANA.

Transakcja BD97 lub raport: RBDSDEST (w transakcji SE38):

Kolejnym krokiem jest uruchomienie raportu /SCWM/R_ERP_RFC_DEST w celu przypisania miejsca przeznaczenia RFC do logicznego systemu znajdującego się w tym samym mandancie. W tym celu konieczne jest uruchomienie SE38 i wprowadzenie logicznego systemu ERP jako miejsca przeznaczenia:

Po uruchomieniu raportu pojawi się komunikat informujący że jest to już program wycofany, ale to w niczym nie przeszkadza. Raport ten robi tą samą robotę co poniższe działanie przewodnika konfiguracji SPRO:

Celem powyższego kroku (zarówno raportu /SCWM/R_ERP_RFC_DEST jak i omawianego działania w SPRO) jest przypisanie domyślnego systemu zdalnego EWM do logicznego systemu ERP w S4. Jeśli przejdziemy przez te działanie w customizacji to nie będziemy musieli dokonywać przypisania w transakcji BD97. System czyta standardowe miejsce przeznaczenia RFC z transakcji BD97 tylko w przypadku gdy pominiemy krok wskazany z powyższym działaniu IMG.

Należy mieć na uwadze, że jeśli posiadaliśmy już wcześniej zdefiniowane miejsca przeznaczenia RFC w transakcji BD97 i w przewodniku konfiguracji wprowadzimy inne miejsca przeznaczenia RFC dla tego samego systemu logicznego to może dojść do niespójności. To z kolei będzie prowadziło do przerwania istniejących zakolejkowanych już komunikatów w transakcji SMQ1. To jest powód dla którego dopiero po „wyczyszczeniu” wszystkich nieprzetworzonych komunikatów w SMQ1 powinniśmy dokonywać zmian we wskazanym działaniu w SPRO.

Jak już wcześniej wspomnieliśmy, pamiętaj, że jeśli ominiesz ten krok to system odczyta miejsce docelowe RFC z transakcji BD97. Na uwagę również zasługuje fakt, iż wpis który tutaj tworzymy nie jest obiektem transportowalnym, pomimo tego że jest tworzony w przewodniku customizacji SPRO. To oznacza, że przez ten sam krok trzeba będzie przejść w każdym systemie osobno.

Ostatnim krokiem jest kontrola wpisów w tabeli TBLSYSDEST i jego celem jest tylko sprawdzenie czy nasze działania w customizacji zostały poprawnie zapisane w tabeli przechowującej miejsca przeznaczenia RFC.

Po przejściu do transakcji SE16N i wczytaniu zawartości tabeli system wyświetli wpisy zawierające miejsca przeznaczenia RFC systemu logicznego:

6. Definiowanie kolejki dla transferu do SAP EWM

Kolejnym krokiem konfiguracji będzie zdefiniowanie kolejki po stronie S/4HANA dla transferu do SAP EWM. Wykonujemy tutaj konfigurację komunikacji z EWM-ką za pośrednictwem kolejek, definiując czy przetwarzanie kolejki jest kontrolowane przez system wysyłający, czy odbierający. Systemem odbierającym jest SAP EWM ponieważ dane do tego systemu są przekazywane za pomocą qRFC z systemu S/4HANA. Przechodzimy do poniższego menu w przewodniku konfiguracji SPRO:

W standardowym systemie typ kolejki ustawiony jest jako „kolejka wejściowa” i wyłączone jest „działanie kolejki zbiorczej”. Typ kolejki „wejściowa” oznacza, że przetwarzanie kolejek jest sterowane przez system odbierający. Poprzez dodanie nowych wpisów wprowadzamy system docelowy (SAP EWM) pamiętając aby był to ten sam system, który wprowadziliśmy poprzednio jako przeznaczenie RFC. Następnie po wybraniu typu kolejki decydujemy jaki wybrać poziom agregacji kolejek czy ilość równolegle przetwarzanych zbiorczych kolejek.

7. Konfiguracja programu automatycznego harmonogramowania kolejek (SMQS)

Następnie należy ustawić harmonogram dla kolejek wychodzących (QOUT) w SAP EWM w celu umożliwienia automatycznego przetwarzania zakolejkowanych komunikatów wychodzących. Uruchamiamy transakcję SMQS – rejestracja miejsca przeznaczenia (docelowego sytemu ERP).

W górnej części transakcji zobaczymy informację programu harmonogramowania tj. datę ostatniej aktualizacji, ID hosta itp. Nie należy się przejmować statusem pracy harmonogramu „INACTIVE”. Taki status widoczny jest zawsze i zmienia się tylko w momencie przybycia komunikatu do kolejki.

W dolnej części okna znajdziemy liczbę wpisów dla miejsc przeznaczenia RFC dla których możemy wykonać rejestrację lub wyrejestrowanie. Zwróć uwagę na kolmumnę typ: R lub U oznacza (registered, unregistered). W celu zarejestrowania (dodania) miejsca przeznaczenia (systemu ERP) klikamy w przycisk rejestracja. Pojawi się okienko pop-up, w którym wprowadzamy miejsce przeznaczenia RFC oraz parametry widoczne na zdjęciu niżej:

Na pierwszy rzut oka może się wydawać, że rejestracja miejsca przeznaczenia wykonywana jest tylko raz przy pierwszej implementacji systemu. Otóż nie, ponieważ opcja wyrejestrowania docelowego miejsca RFC i ponowna jego rejestracja wykorzystywana jest dosyć często. Wyobraźmy sobie sytuację, w której następuje jakaś awaria i pojawia się potrzeba zatrzymania kolejek wychodzących. Powstałe komunikaty mogą zostać zatrzymane po stronie systemu źródłowego  (poprzez wyrejestrowanie) w celu debugowania. W takim przypadku żaden z komunikatów qRFC/tRFC korzystający z aktualnie wyrejestrowanego miejsca przeznaczenia RFC nie będzie przetwarzany. Po korekcie błędów można dokonać ponownej rejestracji miejsca przeznaczenia RFC. Znam przykład z życia wzięty, w której konsultant SAP zatrzymał (wyrejestrował) kolejki RFC i wykorzystując transakcję do migracji zapasów dodał zapasy do magazynu jednocześnie usuwając je z innych lokalizacji, po czym zarejestrował kolejki RFC ponownie. Podobno dzięki temu uniknął ruchów po stronie ERP (sumarycznie nie zmienił ilości zapasów). Proszę nie pytać dlaczego nie użył /SCWM/ADHU lub /SCWM/ADPROD (podobno istniały jakieś powody) 😉

Więcej na temat administrowania kolejkami wyjściowymi poczytamy tutaj.

Zarejestrowaną kolejkę można już monitorować w transakcji SMQ1. Wprowadzamy numer klienta/mandanta oraz jeśli jest potrzeba to nazwę kolejki lub miejsca przeznaczenia. System wyświetli kolejki dla kryteriów zdefiniowanych w pierwszym ekranie:

Zauważymy różne nazwy kolejek skonfigurowane dla mandanta, którego wybraliśmy (o nazewnictwie mówiliśmy wcześniej). Ponadto na liście znajdziemy numer mandanta, nazwę kolejki oraz miejsce przeznaczenia RFC oraz liczbę wpisów dla danej kolejki. Po dwukrotnym kliknięciu w kolejkę wyświetli się lista komunikatów ze szczegółowymi danymi oraz z opisem błędu (błąd będzie podświetlony na czerwono). Po ponownym dwukrotnym kliknięciu w komunikat przejdziemy do kolejnego okna, w którym można debugować, ponownie przetworzyć lub też usunąć wpis (ostrożnie z tą opcją).

Przeszliśmy szybko przez proces konfiguracji kolejek wychodzących, więc możemy skupić się na konfiguracji kolejki przychodzącej.

W tym celu uruchamiamy transakcję SMQR (QIN-harmonogram). Zauważymy różne nazwy kolejek, które chcielibyśmy monitorować w harmonogramie kolejek wejściowych. Zasada działania jest taka sama jak w przypadku kolejek wyjściowych, tylko że tutaj odbywa się rejestracja kolejek w drugą stronę.

Aby umożliwić wyświetlanie kolejek według zdefiniowanych nazw wystarczy kliknąć w „rejestracja”. Będziemy mogli wtedy zarejestrować kolejkę ze zdefiniowaną przez nas nazwą. Zastosowanie oddzielnego nazewnictwa dla różnych procesów przychodzących znacznie ułatwia pracę podczas monitorowania kolejek. Można przydzielić osoby odpowiedzialne za nadzorowania kolejek wygenerowanych przez różne obszary biznesowe (np. dostawy-DLV, wysyłki-TU, quality-management-QM itd.)

Więcej na temat transakcji SMQR możesz poczytac tutaj. Monitorowanie komunikatów z kolejek wejściowych odbywa się podobnie jak w przypadku wyjściowych, z tą różnicą, że tutaj używamy transakcji SMQ2.

Konfiguracja po stronie EWM

9. Definiowanie własnego systemu biznesowego.

Te działanie ma na celu zdefiniowanie klucza systemowego dla EWM, który przechowywany jest w tabelach obiegów dokumentów międzysystemowych.

Za pomocą przycisku „nowe wpisy” dodajemy wpis z nazwą systemu biznesowego EWM:

10. Przypisanie systemu biznesowego do systemu logicznego – SPRO.

Teraz potrzebujemy podlinkować nowo utworzony system biznesowy z systemem logicznym. W tym celu przechodzimy do menu „definiowanie systemu biznesowego” korzystając ze ścieżki menu z poprzedniego kroku i przypisujemy system logiczny do biznesowego:

11. Opracowanie gospodarczej grupy systemów – SPRO.

Kolejnym krokiem do wykonania po stronie systemu EWM jest utworzenie gospodarczej grupy systemów. Celem tego działania jest przypisanie gospodarczej grupy systemów do systemu ERP do którego chcemy się podłączyć. Inaczej rzecz ujmując tworzymy obszary o takiej samym nazewnictwie co zagwarantuje nam użycie tych samych nazw w danych podstawowych oraz ich synchronizację w połączonych systemach.

Dodajemy nowy wpis i wprowadzamy nazwę dla zespołu systemów gospodarczych (jest to 10-znakowa alfanumeryczna nazwa).

Kolejnym krokiem jest przypisanie systemu logicznego i typu kolejki do wcześniej utworzonego zespołu systemów gospodarczych. Przechodzimy zatem do customizacji i dokonujemy przypisania definiując jednocześnie typ kolejki istotny dla mapowania systemów (wejściowa lub wyjściowa). Jeśli wiemy, że będziemy przesyłać ogromne ilości danych do systemu ERP to powinniśmy wybrać typ „kolejki wejściowe” (przychodzące) w celu jego równomiernego obciążenia. Dodatkowo w kolumnie „wsk. SAP” wstawiamy „X” co oznacza, że źródłowym systemem jest właśnie system SAP a w kolumnie „wersja” wstawiamy jego wersję (patrz niżej). Wszystkie parametry wprowadzone w tym punkcie mają istotny wpływ na działanie programu harmonogramowania (QIN scheduler) kolejek w monitorze qRFC po stronie ERP.

Jeśli wybierzesz Kolejki przychodzące po stronie SCM, musisz wprowadzić niezbędne ustawienia dla Harmonogramu kolejkowania (QIN) w monitorze qRFC po stronie ERP. Kolejki, które system ERP ma obsłużyć automatycznie, muszą zostać zarejestrowane w Harmonogramie QIN. Więcej na temat konfiguracji QIN scheduler’a poczytamy tutaj.

12. Sterowanie kolejkami RFC

W tym kroku definiujemy sposób komunikacji EWM z systemem S4 HANA. Definiujemy tutaj kolejki ale w stronę przeciwną niż robiliśmy to w pierwszej części tego poradnika. Konfiguracja ta zapewni nam że oba systemy się dogadają między sobą. Komunikacja odbywa się za pomocą komunikatów RFC dotyczących:

• Komunikatów w referencji do dostaw
• Raportowaniu zmian ilościowych w dostawach
• Raportowaniu ruchów magazynowych dla dostaw (które muszą zostać zarejestrowane w S4 HANA)
• Raportowanie różnic inwentaryzacyjnych do systemu ERP
• Raportowanie ruchów ad-hoc korygujących stany magazynowe (wszelkie korekty, złomowania itd.)

Przechodzimy zatem do ścieżki menu wskazanej niżej:

Wprowadzamy nowe wpisy wprowadzając nazwę systemu biznesowego oraz typ kolejki w sposób analogiczny do tego wskazanego w pierwszej części poradnika:

Zakończenie

To tyle jeśli chodzi o pierwszą część podstawowej integracji systemu EWM. Tak naprawdę to jest tylko początek, w którym przygotowujemy podłoże pod konfigurację systemu SAP Extended Warehouse Management. W kolejnym kroku przyjrzymy się dalszym etapom integracji obydwu systemów tj, konfiguracji kanału dystrybucji oraz mapowaniu dokumentów dostaw z S4HANA do EWM, mapowanie składów, magazynów itd. Niestety z powodu zbyt dużej ilości informacji podzieliłem wpisy na części (nie chciałem zanudzać Was zbyt długim czytaniem). Oczywiście kroki konfiguracyjne dla obydwu systemów stale ewoluują i mogą ulec zmianie. Jeśli znajdziecie lepszy, alternatywny sposób do wskazanych wyżej metod proszę o tym poinformować w komentarzach. Dziękuje bardzo za czytanie i do przeczytania następnym razem 😉

Zostaw to pole puste

Chcesz być informowany o nowych wpisach?

Ja nie spamuje! Przeczytaj zasady polityki prywatności tego bloga.

Sprawdź swoją skrzynkę odbiorczą (albo katalog na spam) i potwierdź swoją subskrypcję.