Usunięta dostawa VL02n

[BST]

Witam wszystkich.
Mam pytanie w jakiej transakcji lub tabeli podejrzeć usunięte dostawy.

[mgabryel]

Po usuniętej dostawie niewiele zostaje, można podejrzeć w VL22, kto ją usunął.

W MB51 można dodatkowo sprawdzić po polu Referencja, czy były jakieś ruchy materiałowe dla usuniętej dostawy.

[BST]

Dziękuję, o to mi chodziło.

[dominik.tylczynski]

Po usuniętej dostawie niewiele zostaje, można podejrzeć w VL22, kto ją usunął.

Faktycznie pozostaje nie wiele. Pozostają jednak dokumenty zmian, które wyświetla właśnie transakcja VL22. Te same dokumenty można wyświetlić w VL03N - na pierwszym ekranie należy podać nr usuniętej dostawy i od razu z tego ekranu wybrać opcję: Environment -> Changes.

[dzonyiks]

Trochę słabo, że nie można odzyskać usuniętej dostawy wychodzącej. Ostatnio przez pomyłkę zamiast usunąć pozycję usunałem cała dostawę

[dominik.tylczynski]

Trochę słabo, że nie można odzyskać usuniętej dostawy wychodzącej. Ostatnio przez pomyłkę zamiast usunąć pozycję usunałem cała dostawę

No cóż... trzeba było uważać...

Sent using Tapatalk

[urbi]

Cześć,

Sorki za odkop, ale mam podobny problem, a nawet dwa różne:
1) User usunął dostawę wychodzącą z HU w środku.. Dostawa usunięta całkowicie, HU zostało przypisane do dostawy więc aby usunąć HU assignment trzeba wejść do dostawy co jest niemożliwe.

Jak teraz uwolnić HU aby można było użyć tego materiału?
Próbowałem przenieść po prostu cały storage unit na lokację magazynową ale nic z tym nie można zrobić bo zawsze chce wejść do deliverki żeby usunąć assignment..

#EDIT: Rozwiązałem za pomocą edycji tabeli w SE16N_INTERFACE.
Pozostaje druga sprawa...

2) Potrzebuję usunąć deliverkę, która ma utworzony i procesowany transfer order lecz przy confirmation w transfer orderze widnieje napis "Delivery not yet updated".

W LX47 widzę, że powodem jest brak HU i sprawdzając deliverkę, faktycznie, ktoś usunął HU.
Potrzebuję po prostu wywalić tę deliverkę lecz nie mogę z powodu WM Status "B".

Mogę to zrobić za pomocą SE16N_INTERFACE tj. zmiana tego pola na "C" w tabeli i po prostu wywalenie deliverki, ale czy jest to zgodne z dobrymi praktykami?

Dzięki za pomoc!

[marcus]

Cześc,
a nie jest przypadkiem tak, że WM status "B" mówi o tym,że istnieje otwarte zapotrzebowanie/zlecenie przeniesienia, które trzeba by było wystornować? Jakby sprawdzic obieg dokumentów i odnaleźć ten dokument to można by go spróbować wystornować w LT15 i status powinien zmienić si na "A".

[urbi]

Cześc,
a nie jest przypadkiem tak, że WM status "B" mówi o tym,że istnieje otwarte zapotrzebowanie/zlecenie przeniesienia, które trzeba by było wystornować? Jakby sprawdzic obieg dokumentów i odnaleźć ten dokument to można by go spróbować wystornować w LT15 i status powinien zmienić si na "A".

Widnieje Transfer Order, który jest już potwierdzony i zakończony aczkolwiek w headerze przy "confirmation" pokazuje się żółty trójkąt jak na poniższym screenie.

Powoduje to, że status WM nie jest zmieniony na "C".

Jak się okazało ktoś jakimś cudem usunął HU z deliverki i nie mogę zlokalizować tych quantów.

A użycie LT15 kończy się informacją, że TO jest aktualnie potwierdzone i nie można usunąć .

[dominik.tylczynski]

Na moje oko masz włączoną funkcjonalność Delayed Update of Outbound Delivery

Sprawdź i przetwórz te aktualizacje w LX47. Jeśli faktycznie to jest to, to powinieneś zaplanować regularne przetwarzanie LX47 przy pomocy okresowego zadania w tle.

[urbi]

Na moje oko masz włączoną funkcjonalność Delayed Update of Outbound Delivery

Sprawdź i przetwórz te aktualizacje w LX47. Jeśli faktycznie to jest to, to powinieneś zaplanować regularne przetwarzanie LX47 przy pomocy okresowego zadania w tle.

Mamy joba na LX47, ale w tym przypadku pokazuje brak update i text: "HU does not exist" dlatego nie zadziałało w przypadku naszej deliverki... Ktoś wywalił HU z deliverki.
Z tego co User mówił, deliverka nie jest już nam potrzebna więc moim pomysłem jest manualna zmiana statusu na "C" lub "A" dla deliverki i po prostu delete. Ale... czy tak powinno to wyglądać zgodnie ze sztuką?

[dominik.tylczynski]

Oczywiście, że tak to nie powinno wyglądać, ale co poradzisz, czasem tak się zrobi, że inaczej nie można. Zmień status dostawy na C, skasuj ją i upewnij się, że nie masz zapasu w WM w typie 916 w dynamicznej lokalizacji o numerze równym numerowi dostawy.

[dominik.tylczynski]

I pamiętaj jeszcze o usunięciu z LX47 rekordu opóźnionej aktualizacji tej dostawy.

[urbi]

I pamiętaj jeszcze o usunięciu z LX47 rekordu opóźnionej aktualizacji tej dostawy.

Jak mogę ten rekord usunąć?

[dominik.tylczynski]

Method of delayed outbound delivery update
The delayed update of the outbound delivery is initiated from the TO update (function module L_TA_QUITTIEREN), here, function module L_TO_PASS_DN or L_TO_PASS_DN_INT is called in BACKGROUND TASK. Thus, the outbound delivery update is carried out in a own task. Every outbound delivery update initiated in such a way is a qRFC and can be found in Transaction SMQ1 under the following key:

• 'TO_LATE' + warehouse number + transfer order number

Zatem nieprzetworzony rekordu opóźnionej aktualizacji dostawy wyświetlony w LX47 powinien być również widoczny w SMQ1 z wyżej opisanym kluczem. Rekord możesz skasować w SMQ1.