ABAP – edytowanie tabel SAP i eliminacja niespójności (EWM)
Dzisiaj chciałbym podzielić się świeżo nabytą wiedzą na temat edycji tabel ABAP w SAP, za pośrednictwem transakcji SE16 (w SAP EWM). Skąd w ogóle wziął się taki pomysł? Otóż od momentu implementacji EWMki, raz na jakiś czas pojawia się temat braku spójności w tabelach danych podstawowych. Zapewne można by ten temat podmieść pod dywan, gdyby nie fakt, że magazyn często cierpi na brak dostępnych miejsc składowania.
Spis treści
1. Wstęp
Nic bardziej nie irytuje, niż sytuacja w której stoisz przed pustym miejscem składowania i nie możesz nic na nim umieścić, bo system wskazuje iż miejsce jest zajęte. Sprawdzasz wszystkie otwarte zadania magazynowe. Widzisz, że dla miejsca składowania nie ma żadnego planowanego ruchu. Żadna blokada nie jest aktywna. Więc co jest grane?
Otóż rozchodzi się o brak spójności w bazie danych SAP, powodujący, że z pustego miejsca składowania, nie została usunięta wartość dla liczby HU. W tabeli miejsca składowania LAGP znajduje się pole ANZLE odpowiedzialne za wyświetlenie liczby HU. To pole jest automatycznie aktualizowane podczas umieszczenia lub wydawania zapasów. Z jakiegoś powodu jednak, nie zawsze jest ono prawidłowo aktualizowane (może przez wystornowane zadania ze statusem „oczekujący” w procesie przychodzącym)? A może chodzi o jakąś lukę w procesie wydania? Przyczyny do tej pory nie udało się znaleźć. Ale przejdźmy do rzeczy.
Patrząc na rysunek poniżej zauważyć można, że w nadrzędnym oknie liczba HU wynosi 1. Wyświetlając natomiast zapasy fizyczne, dla tego miejsca składowania nie widać żadnego zapasu (patrz okno podrzędne).
Być może niektórzy już wiedzą o istnieniu transakcji /SCWM/CHM_LOG służącej do wyświetlania i analizy tego typu niespójności. Czasami program ten okazuje się pomocny, ponieważ za jego pomocą można zaktualizować niezmienione statusy zleceń magazynowych lub inne niezgodności w danych podstawowych lub wyeliminować błędy w dokumentach. W powyższym przypadku jednak wspomniana transakcja nie pomaga.
2. Edycja tabel w SAP
Szukając rozwiązania problemu, przyszedł mi do głowy nieco niebezpieczny, wręcz niedopuszczalny dla użytkowników na moim poziomie, pomysł. A może by tak spróbować zmienić wartość dla tego wpisu w tabeli, po prostu ją edytując? Dlaczego pomysł nazwałem niedopuszczalnym? Ponieważ stanowczo odradza się takich zabiegów, nawet doświadczonym konsultantom, chyba, że naprawdę nie ma już żadnej innej opcji. Bezpośrednia ingerencja w tabele SAP nie pozostawia po sobie żadnego śladu, jest praktycznie nie do namierzenia, a może spowodować poważne niespójności – z tego względu nie jest zalecana. Ale co tam? W środowisku testowym można spróbować 😉
W kilku wątkach SAP Community opisana została metoda próby edycji tabeli bezpośrednio w transakcji SE16N za pomocą polecenia &SAP_EDIT. Zgodnie z notą 1420281 od wersji SAP ECC 6.0 EHP6, możliwość edycji tabel została zdezaktywowana. Jednak autor bloga: https://blogs.sap.com/2013/09/23/activate-sapedit-in-se16n-sap-ecc-60/ znalazł na to sposób. Temat również był poruszany na naszym, polskim forum SAP.
Problem w tym, że w SAP EWM to nie działa, a już nie wspomnę o tym, że wspomnianej transakcji tam nie ma. W EWM-ce dostępna jest tylko transakcja SE16 (bez N).
Szukając w sieci znalazłem również inny sposób, który chciałbym zaprezentować tutaj.
Gdy znamy już nazwę tabeli, którą chcemy edytować, przechodzimy do transakcji SE16. Ja wykorzystałem tabelę odpowiedzialną za przechowywanie danych miejsca składowania /SCWM/LAGP. Wprowadzamy niezbędne dane i klikamy enter:
System wyświetli nam listę pól zawartych w tabeli. Tutaj możemy zdefiniować wejściowe parametry jakie chcemy wyświetlić w przeglądzie danych. Po ich zdefiniowaniu przechodzimy dalej. Ja wybrałem dla testu tylko jedno miejsce składowania.
Jak widzicie na zdjęciu niżej, opcja edycji bądź zmiany tabeli jest nieaktywna więc o próbie naniesienia zmian nie ma mowy.
Teraz należy przejść do trybu debugowania za pomocą kodu /h (więcej na temat kodów wprowadzanych w pasku komend poczytasz tutaj). Gdy pojawi się komunikat informujący o aktywnym trybie debugowania, po prostu przejdź do wpisu tabeli.
Teraz musisz odszukać fragment kodu: if code ’ SHOW’ (możesz to zrobić za pomocą CTRL+F).
Lub po prostu poprzez kliknięcie przycisku powrotu w górnym panelu debugera:
Zostaniesz nakierowany na fragment kodu jak niżej:
Teraz wystarczy kliknąć dwukrotnie w znaleziony fragment kodu, aby móc zmienić wartość zmiennej z SHOW na EDIT:
W tym celu klikamy w zakładkę „zmienne 1” (Variables 1), a następnie w symbol zmiany:
Zmieniamy wartość zmiennej na „EDIT”:
UWAGA!! Tutaj wskazówka, o której pierwotnie zapomniałem napisać a na którą zwróciła uwagę Ola (autorka bloga: Klinika SAP CRM)
Wciskamy ikonę kontynuacji w górnym pasku ABAP debugera:
Zostaniemy przeniesieni z powrotem do uprzednio wyświetlanej tabeli, z tą różnicą, że będzie ona już edytowalna.
Testowo usunąłem wartość w polu ANZLE (pole odpowiedzialne za wyświetlaną ilość HU w miejscu składowania) i pozostawiłem jako puste.
Po zapisaniu zmian, wpis tabeli został poprawnie zaktualizowany.
Sprawdzając ponownie miejsce składowania w monitorze do zarządzania magazynem (/SCWM/MON) spotkała mnie miła niespodzianka. Miejsce stało się dostępne dla umieszczania w magazynie, ponieważ wartość dla liczby HU wynosiła 0.
Powyższy sposób zaczerpnięty został z blogu SAP Community, który znajdziecie tutaj.
Polecam również obejrzeć film:
3. Alternatywne (bardziej bezpieczne) rozwiązanie
Jak już wspomniałem wcześniej, powyższa metoda jest tylko ostatecznością i poza systemem testowym nie zostało wprowadzone. Szukając rozwiązań w sieci udało się znaleźć inny, bardziej bezpieczny sposób eliminujący problem wspomniany we wstępie wpisu. Otóż, na blogu SAP Community pewien dobry człowiek udostępnia kod programu zawarty również w nocie: 2333338.
Wspomniane rozwiązanie rozwiązuje problem, który dosyć często pojawia się w EWM (Maximum volume (incl. tolerance) for HUXXXXXXX was exceeded by 198.134 M3. Message No. /SCWM/HUGENERAL064). Jak się okazało był on również lekarstwem na wspomnianą dolegliwość.
Oczywiście jako użytkownik bez klucza developerskiego nie mogłem ot tak sobie stworzyć transakcji. Mogłem za to wysłać jej kod wraz z notą do działu wsparcia SAP. Tam ktoś po prostu wkleił kod w nowoutworzony program w transakcji SE93. Następnie, po kilku testach, został on również przeniesiony do serwera produkcyjnego. I tak o to jest.
Odpalamy transakcję SA38 i wklejamy nazwę raportu ZRECALCULATE_CAPA (chyba, że ktoś zdefiniował inną nazwę dla tego programu). Następnie przechodzimy dalej:
I wprowadzamy parametry wyboru. W moim przypadku wprowadziłem cały typ magazynu, w którym występowały wspomniane dolegliwości (1). Ważnym polem w ekranie selekcji programu jest GP_SIM. Jeśli chcemy wprowadzić zmianę w życie, musimy pozostawić je puste. Domyślnie jest zaznaczone jako aktywne i oznacza tryb symulacji. Następnie wciskamy przycisk wykonanie. Można również spróbować go uruchomić jako background job wykonywany cyklicznie. Mamy również możliwość zdefiniowania czy program powinien wykonać aktualizacje samych miejsc składowania, bez HU (GP_BINO) lub tylko HU + miejsca puste (GP_ANZLE).
Jako wynik powinniśmy otrzymać log informujący o poprawnych zmianach, jak widzimy poniżej:
4. Stanowisko SAP na temat edycji tabel w SAP EWM
Zgłębiając temat edycji tabel, zapytałem kilku znajomych, doświadczonych konsultantów czy stosują takie praktyki u siebie. Każdy z nich stanowczo odradzał edycji tabel, przyznając, że nigdy tego nie robił (co oczywiście jest zrozumiałe). Swędzący punkt, w obszarze mózgu odpowiedzialnym za ciekawość, wciąż dawał o sobie znać. Próbowałem więc odnaleźć odpowiedź na pytanie: czy jest to kategorycznie zakazane czy nie? Jakie stanowisko w tym temacie przyjęła sama firma SAP. Udało się! Już nie swędzi 😉 Natknąłem się na notę 2866475 – EWM related correction can only be done by SAP.
Wskazany dokument wyraźnie wskazuje, że po stronie klienta jest znajomość sposobów rozwiązania problemów spowodowanych niespójnościami (za pomocą odpowiednich kroków naprawczych), a po stronie SAP jest ewentualna edycja tabel, jeśli te sposoby nie pomogą. Wspomniana nota wskazuje również kolejne dokumenty, opisujące alternatywne metody rozwiązań.
Nota | Opis |
1884981 | Sending / resending messages from EWM to ERP |
1583833 | Check Monitor: Release all HUREF checks for customers |
1381841 | Correction report for Handling Unit Reference |
2557754 | How to execute /SCWM/ERP_STOCKCHECK |
2540396 | Inconsistencies in available stocks table /SCWM/AQUA |
1943193 | Instructions for check monitor in EWM |
1532672 | Correction of capacity data |
2333338 | CHM: Capacity correction |
2356457 | Serial numbers remain in /SCWM/SERI after goods issue |
2437553 | Error in /SCWM/TU: Saving not possible as unprocessed GI exists; restart GI |
1266686 | Report for Post-processing delivery PGI update |
Jeśli żadna z nich nie pomoże, należy to odpowiednio udokumentować i wysłać zgłoszenie do SAP. To pomoże znaleźć główną przyczynę błędu, do której SAP wprowadzi poprawkę.
5. Podsumowanie
Musisz być świadomy tego, że jak już wspomniałem wcześniej, bezpośrednia edycja tabel w SAP jest bardzo niebezpieczna. Wpis ten ma charakter ciekawostki, którą możesz spróbować na serwerach testowych, szczególnie dla tabel danych podstawowych. Stanowczo odradzam próby edycji tabel będących obiektem konfiguracji. Prawie zawsze w sieci znajdzie się sposób na rozwiązanie wszelkich problemów systemowych, ale praktycznie nie da się znaleźć rozwiązań dla problemów spowodowanych przez edycję tabel. Paradoks jest taki, że aby myśleć o edycji tabel, najlepiej byłoby być doświadczonym ABAPowcem. Z kolei będąc taką osobą, czytanie wpisów tego typu jest zbędne. Ktoś mógłby zapytać: więc dla kogo ten wpis? I jaki jest jego sens? Otóż, uruchamia on wyobraźnie. System SAP, z którym codziennie pracujesz jest tylko narzędziem do wprowadzania danych do tabel w bazie danych. Każdy obiekt, czy to danych podstawowych, czy dokument zawiera się w jakiejś tabeli, która posiada swoje pola. Za pośrednictwem odpowiednich transakcji, my jako użytkownicy końcowi, po prostu tworzymy wpisy, bądź edytujemy te istniejące i zmieniamy wartości pól w odpowiednich tabelach. W większości jest tak, że jeden obiekt wyświetlany w transakcji, korzysta z kilku współpracujących tabel. Jeśli zmieniłbyś wartość dla pola w którejś z nich to może wywołać jakieś problemy w zupełnie innym obiekcie. Może dwa zupełnie różne obiekty pechowo korzystają z tej samej tabeli? Dlatego zanim zaczniesz myśleć o jakimkolwiek edytowaniu, czy wykorzystywaniu tabel (np. w raportach SQVI), powinieneś rozumieć wszelkie powiązania, czy zachodzące korelacje między nimi. Warto wziąć sobie do serca wspomnianą notę i zamiast próbować takich praktyk w celu naprawiania niespójności we własnym zakresie, warto go zgłosić do SAP. To może pomóc w eliminacji błędu raz na zawsze, na czym skorzystają też inni klienci.
Witam Panie Marku,
Coś było modyfikowane na stronie? – header z tą bardzo cienką czcionką nie wygląda dobrze.
Może kwestia tła..?
Edge/Chrome/Opera
Na komputerze
Na mobilu – SAP Podstawy /SAP ERP ..generalnie nagłówki są wytłuszczone i w kolorze białym ..
wygląda elegancko
Dzień dobry – tak jest dobrze 🙂
pozdr
RW
Może ciekawostką być jeszcze to, że gdy edytujemy tabele i w kodzie dla zmiennej CODE wpiszemy nie EDIT, a edit, to będziemy mogli usunąć cały rekord. Tak przynajmniej jest w SAP CRM. Tutaj istnieje takie małe niebezpieczeństwo.
Czyli co…. 😉
Znowu mam się przebijać mozolnie przez CEWB, celem modyfikacji tysięcy rekordów…;)?
Ach te SAP Best Practice…
Żartuję oczywiście. Jak trzeba elegancko, to trzeba elegancko.
Pozdrawiam.
Może ciekawostką być jeszcze to, że gdy edytujemy tabele i w kodzie dla zmiennej CODE wpiszemy nie EDIT, a edit, to będziemy mogli usunąć cały rekord. Tak przynajmniej jest w SAP CRM. Tutaj istnieje takie małe niebezpieczeństwo.