CO_ZV_ORDER_POST w przychodzącym IDocu jak używać?

Jeśli programujesz, administrujesz, integrujesz i masz wątpliwość lub obawę, to właśnie najlepsze miejsce dla Ciebie. Pisz śmiało...
wojtas7
Posty: 1074
Rejestracja: pt mar 14, 2008 12:51 pm
Has thanked: 72 times
Been thanked: 318 times

CO_ZV_ORDER_POST w przychodzącym IDocu jak używać?

Post autor: wojtas7 »

Hej,

Scenariusz jest taki, że z zewnętrznego systemu planistycznego przychodzą IDoci do zmiany zleceń produkcyjnych. Każdy Idoc = jedno zlecenie PP.

Problem jest taki że na ileśset zleceń, nie wszystkie mają prawidłowe statusy (uruchamia się ATP a status z niemieckiego NMVP zostaje aktywny). Analiza kodu i debugowanie pojedynczych IDoców nie wskazuje na żadne nieprawidłowości, status NMVP powinen być ściągany i w debugu jest, natomiast żonglowanie komendami WAIT UP TO 1 SECONDS oraz zmiana dwóch parametrów modułu do zmiany zleceń CO_ZV_ORDER_POST uruchamiany z zetowego modułu przetwarzającymi idoci, IV_COMMIT_WORK_AND_WAIT i PROCESS_AT_COMMIT - wpływa na ilość błędnych statusów na zleceniach, ale nie likwiduje problemu całkowicie. Z tego co sądzę, parametr COMMIT_FLAG powinien być zawsze przekazany "X", mimo że sam z siebie nie daje to COMMITa.

Czy zgodnie ze sztuką, powinno to być tak zrobione, że ani w zetowym module funkcyjnym przetwarzającym inbound Idoci, nie powinno być żadnego COMMIT WORK /AND WAIT, a COMMIT następuje po przetworzeniu IDoca i nadaniu np statusu 51/53?

Zastanawiam się jaka jest logika i czemu służą te parametry IV_COMMIT_WORK_AND_WAIT w module CO_ZV_ORDER_POST:

Kod: Zaznacz cały

          
          IF NOT lv_commit_work_and_wait IS INITIAL.
            COMMIT WORK AND WAIT.
          ELSE.
            COMMIT WORK."<================================================
          ENDIF.
z kolei to się uruchomi tylko w przypadku gdy PROCESS_AT_COMMIT = " ". Natomiast PROCESS_AT_COMMIT ma taką logikę w kodzie:

Kod: Zaznacz cały

    IF process_at_commit EQ space.
      PERFORM order_post ON COMMIT.                         "1179350
    ELSE.
      PERFORM order_post.
    ENDIF.
Jaka jest logika zastosowania tych parametrów w tym module funkcyjnym? Nie mogę znaleźć nigdzie na ten temat dokumentacji.

Tutaj problem jest taki, że w zetowym module funkcyjnym do przetwarzania IDoców, trzeba uruchomić zmianę zlecenia dwukrotnie, więc pomiędzy nimi musi być COMMIT WORK AND WAIT. Nie mam też pomysłu jak śledzić ewentualny log błędów, chodzi typowo o taki błąd że kod daje zmianę statusu a mimo to w niektórych przypadkach nie odnosi to skutku i zostaje NMVP.

Czy w takim scenariuszu należałoby zawsze jeszcze uruchamiać moduł STATUS_UPDATE_DIALOG po CO_ZV_ORDER_POST?

Ale najbardziej mnie zastanawiają te parametry z commitem.

Dzięki
dominik.tylczynski
Posty: 8384
Rejestracja: wt kwie 03, 2007 4:05 pm
Has thanked: 1951 times
Been thanked: 1482 times

Re: CO_ZV_ORDER_POST w przychodzącym IDocu jak używać?

Post autor: dominik.tylczynski »

Do sprawdzania kontroli dostępności zleceń produkcyjnych jest funkcja BAPI_PRODORD_CHECK_MAT_AVAIL. Może użyj jej zamiast CO_ZV_ORDER_POST.
Natomiast do modyfikacji zleceń jest funkcja BAPI_PRODORD_CHANGE.
wojtas7
Posty: 1074
Rejestracja: pt mar 14, 2008 12:51 pm
Has thanked: 72 times
Been thanked: 318 times

Re: CO_ZV_ORDER_POST w przychodzącym IDocu jak używać?

Post autor: wojtas7 »

dominik.tylczynski pisze: śr maja 29, 2024 8:33 am Do sprawdzania kontroli dostępności zleceń produkcyjnych jest funkcja BAPI_PRODORD_CHECK_MAT_AVAIL. Może użyj jej zamiast CO_ZV_ORDER_POST.
Natomiast do modyfikacji zleceń jest funkcja BAPI_PRODORD_CHANGE.
Dzięki ale to raczej nie wchodzi w grę, z przyczyn historycznych ten moduł CO_ZV_ORDER_POST jest używany i jest tak ozetowany że to raczej tak musi zostać...
dominik.tylczynski
Posty: 8384
Rejestracja: wt kwie 03, 2007 4:05 pm
Has thanked: 1951 times
Been thanked: 1482 times

Re: CO_ZV_ORDER_POST w przychodzącym IDocu jak używać?

Post autor: dominik.tylczynski »

Historia to ważna rzecz bez wątpienia :wink:
Moim zdaniem warto jednak przemyśleć podejście do przetwarzania. Teraz załatasz ten jedne problem, ale pewnie za chwilę wyjdzie coś innego.
Jestem przekonany, że obie funkcje BAPI finalnie wywołują CO_ZV_ORDER_POST.
wojtas7
Posty: 1074
Rejestracja: pt mar 14, 2008 12:51 pm
Has thanked: 72 times
Been thanked: 318 times

Re: CO_ZV_ORDER_POST w przychodzącym IDocu jak używać?

Post autor: wojtas7 »

A czy mogę prosić o teorię, jeśli chodzi o commit w module do idocow?
dominik.tylczynski
Posty: 8384
Rejestracja: wt kwie 03, 2007 4:05 pm
Has thanked: 1951 times
Been thanked: 1482 times

Re: CO_ZV_ORDER_POST w przychodzącym IDocu jak używać?

Post autor: dominik.tylczynski »

wojtas7 pisze: czw maja 30, 2024 9:56 am A czy mogę prosić o teorię, jeśli chodzi o commit w module do idocow?
Teoria jest opisana na SAP Help Ensuring Data Consistency

Sprowadza się to do prostej kwestii - moduł funkcyjny przetwarzający IDoc nie powinien w żaden sposób bezpośrednio czy pośrednio wywoływać COMMIT WORK. Zatem nie należy również stosować CALL TRANSACTION, które robi COMMIT WORK w tle. Co prawda, SAP wykorzystuje CALL TRANSACTION w niektórych scenariuszach np. IDoc ORDERS tworzący zlecenia sprzedaży jest przetwarzany przez CALL TRANSACTION do VA01. Ta transakcja została jednak specjalnie dopasowana do przetwarzania IDoc'ów - SAP Help Using Call Transaction

To zalecenie wynika z konieczności zachowania spójności między danymi modyfikowanymi przez funkcję przetwarzającą IDoc'a a statusem IDoc'a. Funkcja przetwarzająca IDoc nie modyfikuje statusu IDoc'a a tylko zwraca jego status do warstwy ALE. Warstwa ALE natomiast zapisuje m.in. status w odpowiednich tabelach. Ładnie ilustruje to poniższy diagram: SAP po polsku, nauka SAP, SAP dla początkujących, SAP, S/4HANA, SAP ERP, SAPFORUM, FORUMSAP, HANA, SAP CLOUD PLATFORM, ABAP, EWM


Teoria teorią, ale czasami inaczej niż przez CALL TRANSACTION się nie da. Moim zdaniem można tak robić, przy zachowaniu świadomości ryzyka niespójności danych. Ryzyko jest minimalne - IDoc musiałby zostać poprawnie przetworzony przez CALL TRANSACTION, ale aktualizacja jego statusu w warstwie ALE musiałaby się z jakiegoś powodu się wywalić. Przyznam, że nie widziałem jeszcze takiego przypadku - teoretycznie jest możliwy, w praktyce nie występuje :wink: