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.
Kod: Zaznacz cały
IF process_at_commit EQ space.
PERFORM order_post ON COMMIT. "1179350
ELSE.
PERFORM order_post.
ENDIF.
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