Hej,
Mam taką zagwozdkę może ktoś natchnie jakiś nowy pomysł..
Obieg dokumentów w SD -> zlecenie sprzedaży -> dostawa wychodząca. Do dostawy wychodzącej powstaje komunikat wyjściowy, z zetowym programem, do stworzenia faktury proformy.
Problem polega na sytuacji, kiedy użytkownik jest w edycji zlecenia w VA02, komunikat do dostawy powstaje i robi się zielony, mimo że faktury nie udało mu się stworzyć z powodu locka. Dorobiłem enhancementem logowanie i moduł funkcyjny BAPI_BILLINGDOC_CREATEMULTIPLE zwraca błąd VF 342 = sales order is locked.
Stwierdziłem że skoro tak, to w programie drukującym sprawdzę czy lock jeszcze jest, jak jest to dam komunikat na czerwono i job za 15 minut będzie znowu próbował go odpalić i jak tylko użytkownik wyjdzie z VA02, to faktura powstanie. Jednakże mam przypadki na produkcji, że jednak mój zetowy kod sprawdził locka i stwierdził, że go nie ma (ENQUEUE_EVVBAKE / DEQUEUE_EVVBAKE) i pozwolił uruchomić tworzenie faktury, w którym jednak BAPI zwróciło błąd 342.
Program do output type jest standardowy: /BEV1/VD_BEW_LIEF_BACKGROUND który odpala tak:
CALL FUNCTION '/BEV1/VD_PRINT_BEW_LIEF' IN BACKGROUND TASK
AS SEPARATE UNIT
EXPORTING
i_nast = nast
screen = us_screen.
i potem w include /BEV1/LVDBEWF01 próbuje stworzyć fakturę, ale mu się nie udaje i standard nic z tym nie robi, komunikat jest zielony mimo że faktury nie udało mu się stworzyć.
Więc program drukujący skopiowałem na Z, dorobiłem sprawdzanie lock, ale nadal to nie trybi. Dziwne?
Zastanawiam się czy ENQUEUE_EVVBAKE ze _scope = 2 i DEQUEUE_EVVBAKE ze _scope = 3 jest prawidłowe, ale wydaje mi się że tak bo gdybym sam sobie locka zakładał, to tysiące faktur by się nie zakładało poprawnie. Tak samo COMMIT WORK nie powinienem dawać w samym programie drukującym raczej..
Czy IN BACKGROUND TASK AS SEPARATE UNIT może tu mieć aż takie znaczenie?
Zastanawiam się czy nie zastapić sprawdzania locka, odpaleniem BAPI_BILLINGDOC_CREATEMULTIPLE w trybie testowym... i jak mu się nie uda to komunikat na czerwono do kolejnej próby.
thx
SD / Lock objects -> output type
-
- Posty: 8353
- Rejestracja: wt kwie 03, 2007 4:05 pm
- Has thanked: 1924 times
- Been thanked: 1477 times
- Kontakt:
Re: SD / Lock objects -> output type
Przede wszystkim nie kombinowałbym ze ściąganiem blokad czy oczekiwaniem na ich ściągnięcie.
Skoro output type jest przetwarzany poprzez wywołanie:
to to wywołanie kończy się powodzeniem po jego zapisaniu w kolejce RFC. Przypuszczam, że w tym momencie output type dostaje zielony status. Samo zapisanie wywołania nie oznacza, że to wywołanie zostało przetworzone z powodzeniem. Musiałbyś sprawdzić status przetwarzania RFC w SM58. Niestety nie mam teraz dostępu do systemu z programem /BEV1/VD_BEW_LIEF_BACKGROUND, zatem tak trochę na czuja oceniam sytuację.
Możesz też zrobić własny output type i tworzyć fakturę przy pomocy BAPI_BILLINGDOC_CREATEMULTIPLE. Dobry sposób na problem blokad jest w programie /SPE/STO_ID_PROCESSING, który przetwarza output type SPED z dostawy wychodzącej, aplikacja V1. Zobacz procedurę STO_ID_CREATION - ten kawałek kodu:
załatwia temat blokad. Przekierowuje przetwarzanie output type do oddzielnej LUW, jeśli output type jest przetwarzany w update task'u, czyli z czasem 4. Stosowałem to podejście do różnych automatyzacji procesów przez output types. Działa niezawodnie. Możesz go po prostu skopiować na początek własnej procedury przetwarzającej output type i tworzącej fakturę.
Skoro output type jest przetwarzany poprzez wywołanie:
Kod: Zaznacz cały
CALL FUNCTION '/BEV1/VD_PRINT_BEW_LIEF' IN BACKGROUND TASK
AS SEPARATE UNIT
EXPORTING
i_nast = nast
screen = us_screen.
Możesz też zrobić własny output type i tworzyć fakturę przy pomocy BAPI_BILLINGDOC_CREATEMULTIPLE. Dobry sposób na problem blokad jest w programie /SPE/STO_ID_PROCESSING, który przetwarza output type SPED z dostawy wychodzącej, aplikacja V1. Zobacz procedurę STO_ID_CREATION - ten kawałek kodu:
Kod: Zaznacz cały
DATA: lf_leave TYPE xfeld.
* (0) Redirect this NAST processing to separate LUW - in case it is
* called with processing time 4 (Immediate) in the update task
CALL FUNCTION '/SPE/CALL_PROC_IN_NEW_LUW'
EXPORTING
is_nast = nast
IMPORTING
ef_leave = lf_leave.
IF NOT lf_leave IS INITIAL.
* Per default we set the status on error, so that it can be reprocessed
* in error processing (RSNAST0F) if there is any syntax error / update
* termination / ... in the decoupled NAST processing.
rc = 4.
EXIT.
ENDIF.
-
- Posty: 1061
- Rejestracja: pt mar 14, 2008 12:51 pm
- Has thanked: 71 times
- Been thanked: 315 times
Re: SD / Lock objects -> output type
Dziękuję za pomoc, dobry hint.
Skopiowałem standardowy program /bev1/vd_bew_lief_background właśnie po to żeby móc dodatkowe rzeczy sprawdzać, ale odpalanie tworzenia faktury zostawiłem tak jak w standardzie, bo w środku jest COMMIT WORK AND WAIT. więc wolę to tak zostawić niż mieć commita w output type.
No i ja nie ściągam locków, tylko sprawdzam czy da się założyć, jak da się tzn że jest niezablokowany, ściągam locka i odpala się standard.
Pokrótce:
ZSD_VD_BEW_LIEF_BACKGROUND
Więc rozumiem że pomaga w takiej sytuacji Twoja rada czyli odpalenie na początku programu drukującego
w miejsce sprawdzania locka? Tylko czy komunikat stanie się czerwony jeśli faktura nie zostanie założona? Raczej nie bo w środku tego modułu jest próba księgowania faktury i nic więcej, nie ma żadnego błędu logowanego gdy nie ma faktury.
W środku dzieją się jakieś cuda w /SPE/CALL_PROC_IN_NEW_LUW
w środku sprawdza czy deliverka jest zablokowana. Ale w moim przypadku błąd jest taki że user blokuje zlecenie sprzedaży. Czyli kopiować też /SPE/CALL_PROC_NAST na z i dodać tu moje lock objecty ale do VBAKa a nie do LIKPa?
Skopiowałem standardowy program /bev1/vd_bew_lief_background właśnie po to żeby móc dodatkowe rzeczy sprawdzać, ale odpalanie tworzenia faktury zostawiłem tak jak w standardzie, bo w środku jest COMMIT WORK AND WAIT. więc wolę to tak zostawić niż mieć commita w output type.
No i ja nie ściągam locków, tylko sprawdzam czy da się założyć, jak da się tzn że jest niezablokowany, ściągam locka i odpala się standard.
Pokrótce:
ZSD_VD_BEW_LIEF_BACKGROUND
Kod: Zaznacz cały
ENQUEUE_EVVBAKE
DEQUEUE_EVVBAKE
CALL FUNCTION '/BEV1/VD_PRINT_BEW_LIEF' IN BACKGROUND TASK
AS SEPARATE UNIT
EXPORTING
i_nast = nast
screen = us_screen.
Więc rozumiem że pomaga w takiej sytuacji Twoja rada czyli odpalenie na początku programu drukującego
Kod: Zaznacz cały
* (0) Redirect this NAST processing to separate LUW - in case it is
* called with processing time 4 (Immediate) in the update task
call function '/SPE/CALL_PROC_IN_NEW_LUW'
exporting
IS_NAST = NAST
importing
EF_LEAVE = LF_LEAVE.
W środku dzieją się jakieś cuda w /SPE/CALL_PROC_IN_NEW_LUW
Kod: Zaznacz cały
* ... otherwise start new LUW (tRFC) to process this message
CALL FUNCTION '/SPE/CALL_PROC_NAST'
IN BACKGROUND TASK
AS SEPARATE UNIT
EXPORTING
is_nast = is_nast
if_shared_locking = if_shared_locking.
CALL FUNCTION 'ENQUEUE_EVVBLKE'
EXPORTING
mode_likp = lf_lock_mode "^_n_1457487
vbeln = lf_vbeln
-
- Posty: 561
- Rejestracja: śr kwie 04, 2007 4:32 pm
- Lokalizacja: Poznań
- Has thanked: 9 times
- Been thanked: 165 times
- Kontakt:
Re: SD / Lock objects -> output type
Może nie uważałem ale po co w programie ZSD_VD_BEW_LIEF_BACKGROUND wywołujesz moduły ENQUEUE_EVVBAKE i DEQUEUE_EVVBAKE?
Pozdrawiam,
Jacek Witczak
http://novertio.pl
Jacek Witczak
http://novertio.pl
-
- Posty: 1061
- Rejestracja: pt mar 14, 2008 12:51 pm
- Has thanked: 71 times
- Been thanked: 315 times
Re: SD / Lock objects -> output type
Cały problem na tym właśnie polega - dorobiłem to ponieważ zdarzały się przypadki, że użytkownik siedział w VA02, przychodził trigger z EWM, który wypełniał warunek, żeby powstał komunikat wyjściowy do zrobienia faktury, odpalał się standardowy program, komunikat robił się zielony, a faktura nie powstała.
Nie ma nigdzie w tym programie standardowym sprawdzania czy udało się stworzyć fakturę, czy nie, i dodatkowo odpala się to w background tasku więc program drukujący traci dostęp do tego komunikatu ewentualnego.... a tu można by ustawić komunikat na czerwono w sytuacji błędu, żeby za kolejnym odpaleniem joba móc go zreprocesować. Gdy jest zielony to lipa - system myśli że faktura już jest.
W samym programie zaraz po odpaleniu BAPI, dorobiłem enhancementem logowanie błędów do tabeli zetowej i sobie oglądam, i pojawiają się wpisy z błędami VF 342 - "Der Beleg & ist zur Zeit in Bearbeitung". Sam program sprawdza locka ale na dostawie, a nie na zleceniu.
Więc ucieszony dorobiłem w programie drukującym na początku sprawdzanie czy zlecenie jest zablokowane, i jak jest ustawiam na czerwono.
No ale ten filtr mój coś jest dziurawy i dalej przepuszcza w programie drukującym od czasu do czasu, próbuje zrobić fakturę, zapisuje ten sam błąd do tabelki zetowej, i komunikat jest zielony a faktury brak.
Ten program drukujący to jakaś lipa ogólnie jest no ale mam go użyć.... Sprawdziłem to BAPI i w środku uprawnienia rzeczywiście są ENQUEUE_EVVBAKE więc teoretycznie dobrze zrobiłem...
Nie ma nigdzie w tym programie standardowym sprawdzania czy udało się stworzyć fakturę, czy nie, i dodatkowo odpala się to w background tasku więc program drukujący traci dostęp do tego komunikatu ewentualnego.... a tu można by ustawić komunikat na czerwono w sytuacji błędu, żeby za kolejnym odpaleniem joba móc go zreprocesować. Gdy jest zielony to lipa - system myśli że faktura już jest.
W samym programie zaraz po odpaleniu BAPI, dorobiłem enhancementem logowanie błędów do tabeli zetowej i sobie oglądam, i pojawiają się wpisy z błędami VF 342 - "Der Beleg & ist zur Zeit in Bearbeitung". Sam program sprawdza locka ale na dostawie, a nie na zleceniu.
Więc ucieszony dorobiłem w programie drukującym na początku sprawdzanie czy zlecenie jest zablokowane, i jak jest ustawiam na czerwono.
No ale ten filtr mój coś jest dziurawy i dalej przepuszcza w programie drukującym od czasu do czasu, próbuje zrobić fakturę, zapisuje ten sam błąd do tabelki zetowej, i komunikat jest zielony a faktury brak.
Ten program drukujący to jakaś lipa ogólnie jest no ale mam go użyć.... Sprawdziłem to BAPI i w środku uprawnienia rzeczywiście są ENQUEUE_EVVBAKE więc teoretycznie dobrze zrobiłem...
-
- Posty: 8353
- Rejestracja: wt kwie 03, 2007 4:05 pm
- Has thanked: 1924 times
- Been thanked: 1477 times
- Kontakt:
Re: SD / Lock objects -> output type
Właśnie podałeś kluczową informację - że tworzysz fakturę na podstawie trigger'a z EWM, a blokada jest z powodu innej sesji, gdzie użytkownik jest w VA02.wojtas7 pisze: ↑śr kwie 14, 2021 1:54 pm Cały problem na tym właśnie polega - dorobiłem to ponieważ zdarzały się przypadki, że użytkownik siedział w VA02, przychodził trigger z EWM, który wypełniał warunek, żeby powstał komunikat wyjściowy do zrobienia faktury, odpalał się standardowy program, komunikat robił się zielony, a faktura nie powstała.
To co pisałem wcześniej o wykorzystaniu mechanizmu z output type SPED dotyczy sytuacji, gdzie przetwarzasz output type natychmiast, ale jeszcze pozostała blokada z przetwarzania dokumentu, który wyzwolił ten output. Tak właśnie jest w przypadku SPED, który ma utworzyć dostawę przychodzącą po zaksięgowaniu wydania dostawy wychodzącej.
W Twoim przypadku output type wywołuje tworzenie faktury poprzez przetwarzania funkcji /BEV1/VD_PRINT_BEW_LIEF w kolejce RFC - to właśnie robi wywołanie:
Kod: Zaznacz cały
CALL FUNCTION '/BEV1/VD_PRINT_BEW_LIEF' IN BACKGROUND TASK
AS SEPARATE UNIT
EXPORTING
i_nast = nast
screen = us_screen.
Możesz też zaplanować okresowe zadanie w tle z raportem RSARFCEX, które będzie ponownie przetwarzać błędy tworzenia faktury.
-
- Posty: 561
- Rejestracja: śr kwie 04, 2007 4:32 pm
- Lokalizacja: Poznań
- Has thanked: 9 times
- Been thanked: 165 times
- Kontakt:
Re: SD / Lock objects -> output type
Ja na Twoim miejscu bym posłuchał Dominika bo sprawdzenie blokady na VBAK w programie ZSD_VD_BEW_LIEF_BACKGROUND nie zawsze działa (swoją drogą ciekawe dlaczego) - może sprawdzenie blokady przy pomocy modułów do zakładania/zdjęcia blokady to jest taki mały overkill bo mamy przecież do dyspozycji moduł funkcyjny np. ENQUEUE_READ, który (z grubsza biorąc) jest tym co widać na ekranie transakcji SM12 i jego można spokojnie używać do kontroli blokad w danym momencie w systemie.
Pozdrawiam,
Jacek Witczak
http://novertio.pl
Jacek Witczak
http://novertio.pl
-
- Posty: 1061
- Rejestracja: pt mar 14, 2008 12:51 pm
- Has thanked: 71 times
- Been thanked: 315 times
Re: SD / Lock objects -> output type
Super wskazówki, bardzo dziękuję, bardzo
Mam pytania jeszcze:
Odpalenie modułu funkcyjnego w nowym wątku RFC:
W jaki sposób spowodować że taki task w SM58 będzie wisiał jako błędny? Po prostu MESSAGE E ?
Mam pytania jeszcze:
Odpalenie modułu funkcyjnego w nowym wątku RFC:
Kod: Zaznacz cały
CALL FUNCTION '/BEV1/VD_PRINT_BEW_LIEF' IN BACKGROUND TASK
AS SEPARATE UNIT
EXPORTING
i_nast = nast
screen = us_screen.
-
- Posty: 8353
- Rejestracja: wt kwie 03, 2007 4:05 pm
- Has thanked: 1924 times
- Been thanked: 1477 times
- Kontakt:
-
- Posty: 1061
- Rejestracja: pt mar 14, 2008 12:51 pm
- Has thanked: 71 times
- Been thanked: 315 times
Re: SD / Lock objects -> output type
Wyciągnąłem też wniosek że RFC w SM58 będzie na czerwony gdy komunikat typu E jest w taki sposób odpalany:
I w tym module standardowym brakuje sprawdzania czy udało się stworzyć fakturę czy nie, dodatkowo nie chcemy drukować nic a on zapodaje SapScripta. Skopiowałem to na zetowy moduł, wywaliłem drukowanie i dorobiłem ten NAST_PROTOCOL_UPDATE gdy nie ma faktury - powinno śmigać
Kod: Zaznacz cały
CALL FUNCTION 'NAST_PROTOCOL_UPDATE'
EXPORTING
msg_arbgb = syst-msgid
msg_nr = syst-msgno
msg_ty = syst-msgty
msg_v1 = syst-msgv1
msg_v2 = syst-msgv2
msg_v3 = syst-msgv3
msg_v4 = syst-msgv4
EXCEPTIONS
OTHERS = 1.