Witam,
Mam pytanie odnośnie pola BUDAT. W trakcie wprowadzania dokumentu system podpowiada datę systemową do tego pola. Poproszono mnie o sprawdzenie, czy jest możliwe, żeby w polu BUDAT nie podpowiadała się żadna data, żeby użytkownik musiał sam świadomie ją uzupełnić.
Czy jest taka możliwość? Jeśli tak, to poproszę o wskazówki
Pole BUDAT
-
- Posty: 8356
- Rejestracja: wt kwie 03, 2007 4:05 pm
- Has thanked: 1924 times
- Been thanked: 1477 times
- Kontakt:
Re: Pole BUDAT
Na szybko wygooglowałem cos takiego:Olesia pisze:Czy nikt nie jest mi w stanie pomóc?
Zależy mi bardzo na wskazaniu rozwiązania
this field gets its value in Include MF05AO00_BELEGKOPF_VORSCHLAG ==> module belegkopf_vorschlag output ==> line 19:
bkpf-budat = sy-datlo.
(this means the posting date is set to the local date of the user.)
Technically it would be easy to comment this line, but it means, that we change the standard source code, which is something we like to avoid
hope this helps
Re: Pole BUDAT
Dziękuję za odpowiedź.
Nigdy nie grzebiemy w standardach, więc ta opcja odpada.
Przeszukiwałam system i niczego nie znalazłam, stąd moje pytanie na forum. Właściwie to trochę się spodziewałam takiej odpowiedzi
Jeszcze raz dzięki za pomoc
Nigdy nie grzebiemy w standardach, więc ta opcja odpada.
Przeszukiwałam system i niczego nie znalazłam, stąd moje pytanie na forum. Właściwie to trochę się spodziewałam takiej odpowiedzi
Jeszcze raz dzięki za pomoc
-
- Posty: 213
- Rejestracja: czw lip 10, 2014 7:53 pm
- Has thanked: 21 times
- Been thanked: 258 times
Re: Pole BUDAT
Da się to jeszcze obejść bez modyfikacji standardu:
Na końcu form pbo_belegkopf_vorschlag jest miejsce na Implicit Enhancement.
W tym miejscu możnaby było dopisać własną logikę, która musiałaby zawierać minimum taką linię.
clear bkpf-budat.
Oczywiście należy to opatrzyć warunkami/ własną tabelą konfiguracyjną itd. ale jest to wykonalne bez modyfikacji standardu (aczkolwiek nie jest to najpiękniejsze rozwiązanie).
Na końcu form pbo_belegkopf_vorschlag jest miejsce na Implicit Enhancement.
W tym miejscu możnaby było dopisać własną logikę, która musiałaby zawierać minimum taką linię.
clear bkpf-budat.
Oczywiście należy to opatrzyć warunkami/ własną tabelą konfiguracyjną itd. ale jest to wykonalne bez modyfikacji standardu (aczkolwiek nie jest to najpiękniejsze rozwiązanie).
Marek Turczyński
-
- Posty: 8356
- Rejestracja: wt kwie 03, 2007 4:05 pm
- Has thanked: 1924 times
- Been thanked: 1477 times
- Kontakt:
Re: Pole BUDAT
Moim zdaniem taka modyfikacja standardowej logiki przy pomocy implicit enhancment jest gorszym rozwiązaniem niż wprost naprawa kodu SAP.
Sent using Tapatalk
Sent using Tapatalk
-
- Posty: 213
- Rejestracja: czw lip 10, 2014 7:53 pm
- Has thanked: 21 times
- Been thanked: 258 times
Re: Pole BUDAT
Zgadza się - dlatego, że implicit enhancement nie jest wykazywany podczas upgrade, natomiast modyfikacja tak. Dllatego takich implicit enhancementów należy się zwykle wystrzegać. Dlatego jest to rozwiązanie ostateczne, gdzie ktoś naprawdę nie chce zmodyfikować standardu to jest to możliwy workaround. Natomiast, należy korzystać tylko z tego typu rozwiązań w ostateczności.
Marek Turczyński
Re: Pole BUDAT
Dziękuję Panowie za wskazówki
Póki co, porozmawiam jeszcze z kolegami, chociaż jak pisałam nie ruszamy standardów.
Na szkoleniach uczulano nas, żeby tego nie robić. Zalecano ewentualne tworzenie Z*-wych kopii.
W jakich przypadkach uzasadnione jest modyfikowanie standardowych kodów?
W przypadku zmodyfikowania tego standardu, jakie mogą być negatywy?
Póki co, porozmawiam jeszcze z kolegami, chociaż jak pisałam nie ruszamy standardów.
Na szkoleniach uczulano nas, żeby tego nie robić. Zalecano ewentualne tworzenie Z*-wych kopii.
W jakich przypadkach uzasadnione jest modyfikowanie standardowych kodów?
W przypadku zmodyfikowania tego standardu, jakie mogą być negatywy?
Re: Pole BUDAT
Prosiłabym o odpowiedź na pytania:dominik.tylczynski pisze:Moim zdaniem taka modyfikacja standardowej logiki przy pomocy implicit enhancment jest gorszym rozwiązaniem niż wprost naprawa kodu SAP.
Sent using Tapatalk
W jakich przypadkach uzasadnione jest modyfikowanie standardowych kodów?
W przypadku zmodyfikowania tego standardu, jakie mogą być negatywy?
Waham się, czy nie zrobić wyjątku i poprosić programistę o zmianę tego konkretnego standardu
-
- Posty: 1061
- Rejestracja: pt mar 14, 2008 12:51 pm
- Has thanked: 71 times
- Been thanked: 315 times
Re: Pole BUDAT
Ale masz doświadczenie przy upgrade, że jakaś implementacja implicit enhancement była problematyczna? Przecież konieczność zgodności wstecz powoduje, że takie rozszerzenia działają automatycznie po upgrade, tak samo jak user exity czy BADI.Akarin pisze:Zgadza się - dlatego, że implicit enhancement nie jest wykazywany podczas upgrade, natomiast modyfikacja tak. Dllatego takich implicit enhancementów należy się zwykle wystrzegać.
oczywiście pozostaje pytanie, co za kod został wstrzyknięty do implicit enhancement, jesli jakieś export to memory i takie zawiadiackie logiki na ekranach no to oczywiście że może się to posypać.
-
- Posty: 8356
- Rejestracja: wt kwie 03, 2007 4:05 pm
- Has thanked: 1924 times
- Been thanked: 1477 times
- Kontakt:
Re: Pole BUDAT
Masz rację, że samo implicit enhancement przetrwa upgrade. SAP sobie z tym poradzi. Jednak tak jak napisałeś problem polega na tym jaki kod zostanie zaimplementowany w takim rozszerzeniu. Widziałem już rzeczy niewiarygodne, np. skopiowanie do rozszerzenia całej procedury SAP po to, aby zmienić w niej jedną czy dwie linie kodu. Wszystko po to, aby niby nie zmieniać standardu. Wtedy wszystkie poprawki z not czy patch'y nie są aplikowane do takiej kopii.wojtas7 pisze:Ale masz doświadczenie przy upgrade, że jakaś implementacja implicit enhancement była problematyczna? Przecież konieczność zgodności wstecz powoduje, że takie rozszerzenia działają automatycznie po upgrade, tak samo jak user exity czy BADI.
oczywiście pozostaje pytanie, co za kod został wstrzyknięty do implicit enhancement, jesli jakieś export to memory i takie zawiadiackie logiki na ekranach no to oczywiście że może się to posypać.
Jako że nad taką kreatywnością nie da się zapanować, uważam że w ogóle nie należy używać implict enhancements.
Generalnie cały enhancement framework został przygotowany przez SAP, aby implementować rozwiązania branżowe i dodatkowe funkcje biznesowe. To nie powinno być wykorzystywane do rozszerzeń klienta.
Sent from my iPad using Tapatalk
-
- Posty: 213
- Rejestracja: czw lip 10, 2014 7:53 pm
- Has thanked: 21 times
- Been thanked: 258 times
Re: Pole BUDAT
Sam implicit nie, ale kod w nim zawarty już tak. Widziałem przypadki implementacji kodu typu - skopiuj kod standardowy, zmień 2 linijki, nie oznacz ich i na końcu dodaj komendę RETURN, przez co standardowy kod nie był wykonywany. Również wyłączenia standardowego kodu poprzez dwa implicity if 1 =2. i endif. Przy upgradzie bezpośrednio tego nie zobaczysz, ale w momencie rozpoczęcia testów już tak.wojtas7 pisze:Ale masz doświadczenie przy upgrade, że jakaś implementacja implicit enhancement była problematyczna? Przecież konieczność zgodności wstecz powoduje, że takie rozszerzenia działają automatycznie po upgrade, tak samo jak user exity czy BADI.Akarin pisze:Zgadza się - dlatego, że implicit enhancement nie jest wykazywany podczas upgrade, natomiast modyfikacja tak. Dllatego takich implicit enhancementów należy się zwykle wystrzegać.
oczywiście pozostaje pytanie, co za kod został wstrzyknięty do implicit enhancement, jesli jakieś export to memory i takie zawiadiackie logiki na ekranach no to oczywiście że może się to posypać.
Także na implicity należy uważać, bo czasami kod w nich zawarty naprawdę robi problemy.
A nie było tak, że to BTE były właśnie po to wymyślone? Z informacji dotyczących enhancement framework wynika, że rozwiązania branżowe miały być dostarczane przez funkcje biznesowe i przez BTE.Generalnie cały enhancement framework został przygotowany przez SAP, aby implementować rozwiązania branżowe i dodatkowe funkcje biznesowe. To nie powinno być wykorzystywane do rozszerzeń klienta.
Implicity są wykorzystywane nawet w implementacjach SAP robionych przez same SAP (widziałem takie przypadki).
Marek Turczyński
-
- Posty: 8356
- Rejestracja: wt kwie 03, 2007 4:05 pm
- Has thanked: 1924 times
- Been thanked: 1477 times
- Kontakt:
Re: Pole BUDAT
Moim zdaniem przez lata SAP rozwijał różne techniki rozszerzeń - były user exit'y (głównie w SD), potem customer exit'y i BTE (głównie w FI), potem BADI (dają możliwość wielokrotnej implementacji i filtrowania, ale mają spory narzut na wydajność; SAP zmigrował przynajmniej część customer exit'ów do BADI) i wreszcie enhancement'y explicite i implicite (SAP znowu zmigrował przynajmniej część BADI do enhancement).Akarin pisze:A nie było tak, że to BTE były właśnie po to wymyślone? Z informacji dotyczących enhancement framework wynika, że rozwiązania branżowe miały być dostarczane przez funkcje biznesowe i przez BTE.
Implicity są wykorzystywane nawet w implementacjach SAP robionych przez same SAP (widziałem takie przypadki).
Tak naprawdę, mówiąc o enhancement framework, trzeba mówić o switch & enhancement network, bo te switch'e są tutaj bardzo ważne. Pozwalają one jednym ruchem włączyć cały zbiór rozszerzeń nie tylko kodu, ale również ekranów i obiektów słownika danych. To jest bardzo użyteczna funkcja, bo wcześniej nie było możliwość spakowania w całość dużego rozszerzenia i prostego jego aktywowania.
Funkcje biznesowe natomiast to są rozszerzenia funkcjonalne dostarczane właśnie przy pomocy enhancement'ów i włączane switch'ami.
Kiedyś, gdzieś na stronach SAP czytałem, że przed switch & enhancement framework nie można było uruchomić kilku rozszerzeń branżowych w jednym systemie, czyli przykładowo jeśli ktoś miał Retail, to nie mógł uruchomić Oil&Gas na tym samym systemie. Zatem firma taka jak Orlen, która z jednej strony działa w Oil&Gas, a z drugiej prowadzi sieć stacji benzynowych ze sprzedaż detaliczną mogłaby mieć problem.