[EWM] BAPI_OUTB_DELIVERY_CONFIRM_DEC usuwanie i zakładanie kolejnych HUs w VEKP

[wojtas7]

Mamy taki scenariusz że pakujemy dostawę wychodząca w HUsy i one są meldowane z powrotem do ERPa każdorazowo. Do jednej dostawy mamy > 1 HUs. Za każdym kolejnym HU, BAPI_OUTB_DELIVERY_CONFIRM_DEC powoduje że wpis z VEKP jest usuwany i zakładany od nowa (VENUM jako klucz powstaje nowy). Ostatecznie przy Goods Issue wyksięgowaniu, przychodzą ponownie wszystkie HUsy i są usuwane i zakładane ponownie.

Ze względu na proces potrzebujemy mieć oryginalne HUsy a nie ciągle zakładane od nowa. Na końcu status powinien być 0050 (WA gebucht) i już. Ale standard usuwa wszystkie HUsy i zakłada od nowa.

Czy to można wysterować żeby zachowywało się inaczej i nie kasowało HUsów w VEKP?

[dominik.tylczynski]

Dlaczego musisz identyfikować HU po wartości pola VENUM, a nie po EXIDV? VENUM to jest co prawda pole kluczowe w VEKP, ale identyfikatorem HU jest EXIDV.

[wojtas7]

Proces jest taki że z magazynu automatycznego wyjeżdżają pojemniki (HUsy) do robota, który je paletyzuje (kładzie na palety).
Każdy wyjeżdżający pojemnik jest meldowany z powrotem do ERPa z EWM i dopisywany do deliverki wychodzącej (pakowany).
Automatycznie tworzy się transport (VT01N w jobie), do którego są pakowane HUsy -> właśnie te nowo założone.
Następnie przy przycisku Transport Beginn w transporcie po spakowaniu, idzie moduł funkcyjny Z do EWM, z triggerem księguj Goods Issue.
Następnie EWM standardowo wysyła BAPI przez qRFC do ERPa do zaksięgowania deliverki. I za każdym razem wszystkie HUsy są usuwane i zakładane od nowa, traci się połączenie HUsa z transportem.

[dominik.tylczynski]

Coś mocno niestandardowo wygląda mi ten proces, takie duże Z

O ile się orientuję EWM wysyła jednostki obsługi / HUs do ERP w momencie zaksięgowania wydania w EWM. Robi to raz a skutecznie.
Pakowanie dostawy wychodzącej / HUs przypisane do dostawy są widoczne w transporcie standardowo, bez żadnego dodatkowego pakowania w transporcie. Zatem jakkolwiek by się zmieniał układ HUs w dostawie, powinny być one widoczne z poziomu transportu. Mówię tutaj o standardowym ekranie pakowania transportu.

Przypuszczam, że masz napisane rozszerzenie, które na bieżąco przesyła HUs z EWM do ERP do dostawy wychodzącej. Trzeba by zajrzeć pod maskę tego rozszerzenia i zmodyfikować je tak, aby tylko dopisywało nową jednostkę obsługi, bez kasowania i ponownego tworzenia już istniejących HUs.

[wojtas7]

No właśnie czy to jest rozszerzenie czy nie, to do końca nie jestem pewien. Po prostu przy określonym rodzaju wysyłki jest budowany transport, i wtedy jest coś takiego w standardzie jak Teilrückmeldung. To jest standard bo w nagłówku BAPI jest struktura nawet HEADER_CONTROL i jest pole POST_GI_FLAG, i dopiero na koniec naszego procesu pojawia się w tym miejscu "X". Także całkiem ciekawie to działa, BAPI_CONFIRM_DEC nie potwierdza a jedynie wysyła HUsy. Do tego, co ciekawe, przy pierwszym HU, przy komisjonowaniu, przysyła BAPI_DELIVERY_CHANGE i robi splitta, a kolejne ilości pakowane do kolejnych HUsów już przychodzą w BAPI_CONFIRM_DEC.

Poradziłem sobie tak, że w samym BAPI_CONFIRM_DEC w enhancement sprawdzam czy HUsy mają status 0020 w VEKP i usuwam z interfejsu kolejne. Do tego export to memory i głęboko w bebechach w module funkcyjnym V51P_FIND_HEADER kolejne enhancement, import from memory żeby rozpoznać, i zmieniam tam strukturę do UPDATE = "X", zmieniam status z 0020 na 0050 i działa. Karkołomne ale działa.... Ogólnie wszystko na poziomie tabel dzieje się w tej grupie funkcyjnej.

[wojtas7]

W tym naszym zagmatwanym procesie chodzi też o to, że w transporcie pakujemy HUsy na kolejne HUsy - pojemniki na palety. Stąd ten link jest potrzebny nie można usuwac i zakładać nowych HUsów za kazdym razem..