Satıcıda münferit ödeme işaretini zorunlu yapmak: OBD3 alan durumu neden yetmez, VENDOR_ADD_DATA BAdI ile kontrol ve uzun metinli hata iletisi.
Satıcı ana verisinde münferit ödeme işaretini zorunlu yapmak: hesap grubu alan durumu neden yetmiyor, VENDOR_ADD_DATA BAdI ile kontrol, ECC 6.0'da geliştirme uygulaması kabı ve kullanıcıya yol gösteren uzun metinli ileti.
Bu yazı ECC 6.0 EhP8 üzerinde yazıldı. Kullanılan işlemler: FK01, FK02, XK01, SE91, SE19 ve Class Builder.
Neden böyle bir kurala ihtiyaç var?
Otomatik ödeme programı (F110) normalde bir satıcının aynı gün vadesi gelen bütün faturalarını tek bir havalede toplar. Muhasebe açısından pratik görünür, ama bankadan dönen hesap özetinde tek bir tutar, satıcının ekstresinde ise beş ayrı fatura vardır; mutabakat yapan kişi hangi faturanın hangi ödemeyle kapandığını ayrıca eşleştirmek zorunda kalır.
Satıcı ana verisindeki Münferit ödeme işareti bu davranışı değiştirir: işaret açıkken F110 o satıcının her açık kalemini ayrı bir ödemeyle öder. Her havale tek bir faturaya karşılık geldiği için hem banka mutabakatı hem satıcı mutabakatı kolaylaşır. Bu yazıda kullandığım deneme şirketinde (TR10) kural basit: yurtiçi, yurtdışı ve personel satıcılarının hepsinde bu işaret açık olmalı. Sorun, işaretin bir onay kutusu olması ve kullanıcının onu unutmasının çok kolay olması.
Yazının sonunda, işaret boş bırakılırsa satıcının hiç kaydedilmemesini sağlayan küçük bir geliştirme kurmuş olacağız. Yol boyunca SAP'nin standart araçlarının nerede yettiğini, nerede yetmediğini ve ECC 6.0'da klasik BAdI'lerin değişen davranışını da göreceğiz.
Önce standart yolu deneyin: hesap grubu alan durumu
Bir ana veri alanını zorunlu yapmanın ilk adresi hesap grubunun alan durumudur (OBD3, satıcı hesap grupları). Aynı hedefin ikinci yarısı olan Çift fatura kontrolü için bu yol çalışıyor: alan durumunda kendi satırı var ve "Zorunlu grş" seçildiğinde sistem gerçekten işaretlemeyi dayatıyor.
 |
Ekran 1: OBD3, Şirket kodu verileri |
Bunu doğrulamak için FK01 ile çift fatura kontrolünü işaretlemeden bir satıcı kaydetmeyi denedim. Sistem "Tüm zorunlu alanları doldurun" iletisiyle kaydı durdurdu ve imleci doğrudan onay kutusuna götürdü:
 |
| Ekran 2: zorunlu yapılan onay kutusu boş bırakılınca kayıt reddediliyor. |
Münferit ödeme için aynı yol işe yaramıyor. Ekran 1'de görüldüğü gibi bu işaret gruplama anahtarı ve ödeme biçimi eki ile aynı alan durumu satırını paylaşıyor. Satırı zorunlu yaparsak üç alan birden zorunlu olur; gruplama anahtarı ile ödeme biçimi eki ise bizim kurguda boş kalması gereken alanlar (gruplama anahtarı zaten münferit ödemeyle çelişen bir gruplama mantığı getirir). Yani standart araç bu alan için fazla kaba. Kuralı kod ile koymamız gerekiyor.
Seçenekler: BAdI mi, müşteri çıkışı mı?
Satıcı ana verisi kaydedilmeden önce ek kontrol yapmanın ECC'de iki bilinen yolu var:
| Yöntem | Nerede | Artısı | Eksisi |
|---|---|---|---|
| BAdI VENDOR_ADD_DATA, yöntem CHECK_ALL_DATA | SE19 | Çoklu kullanıma açık; başka ekipler kendi uygulamalarını ayrı ayrı ekleyebilir. Nesne yönelimli, okunması kolay. | ECC 6.0'da geliştirme noktasına taşındığı için kurulumda bir ek adım (geliştirme uygulaması kabı) var. |
| Müşteri çıkışı EXIT_SAPMF02K_001 | CMOD, uzantı SAPMF02K | Eski ve yaygın; çok sayıda örnek bulunur. | Bir CMOD projesine bağlı; aynı çıkışı kullanan bütün kontroller tek bir include içinde toplanmak zorunda. |
Ben BAdI'yi seçtim. İkisinin de çalıştığı nokta aynı: satıcı kaydedilmeden hemen önce, bütün ekranlardaki veriler toplanmışken.
Adım 1: İleti sınıfını ve iletiyi tanımlayın (SE91)
Kod bir hata iletisi verecek, iletinin de bir ileti sınıfında durması gerekiyor. Şirket koduna ait uyarlama ve geliştirme iletilerini bir arada tutmak için ZTR10 adında bir ileti sınıfı açtım.
 |
Ekran 3: SE91 başlangıç ekranı: ileti sınıfı adını yazıp "Create". |
 |
Ekran 4: Özellikler: kısa metin. Paket sorulduğunda deneme sisteminde "Local Object" ($TMP) yeterli. |
İletiler sekmesinde bu yazının konusu olan ileti 002 numarada. &1 ve &2 yer tutucularını kod dolduracak: birincisine hesap grubu, ikincisine şirket kodu gelecek.
 |
Ekran 5: ZTR10 iletileri. 002: "&1 hesap grubunda münferit ödeme işaretli olmalı (şirket kodu &2)". |
Adım 2: BAdI uygulamasını yaratın (SE19)
SE19'da alt bölümdeki Create Implementation kısmında Classic BAdI seçilir, BAdI adı olarak VENDOR_ADD_DATA yazılır ve Create düğmesine basılır. Uygulamaya ad verirken şirket kodunu ve amacını içeren bir ad seçmek, aylar sonra SE19'da listeye baktığınızda işinizi kolaylaştırır: ZTR10_VENDOR_CHECK.
 |
Ekran 6: SE19: Classic BAdI, VENDOR_ADD_DATA. |
 |
Ekran 7: Uygulama adı. |
Beklenmedik pencere: "uygulamanın geçişi yapılacak"
Kısa metni girip kaydettiğimde, paket sorusundan sonra şu bilgi penceresi geldi:
 |
Ekran 8: Klasik BAdI uygulaması yeni geliştirme çerçevesine taşınıyor. |
ECC 6.0 ile SAP, BAdI'leri "Enhancement Framework" adlı yeni bir yapıya taşıdı. VENDOR_ADD_DATA artık aynı adlı bir geliştirme noktasının (enhancement spot) içinde. Klasik yolla yarattığımız uygulama da bir geliştirme uygulaması (enhancement implementation) kabının içine yerleştirilmek zorunda; sistem hangi kabı kullanacağımızı soruyor:
 |
Ekran 9: Mevcut kaplar: hepsi SAP'nin ya da ülke yerelleştirmelerinin (Katar, Kore, İspanya, IS-Oil...). |
Listedekilerden birini seçmek, kendi kodunuzu SAP'nin bir yerelleştirme paketinin içine koymak demek; bir güncellemede neyin nereden geldiğini karıştırırsınız. Doğru olan kendi kabınızı yaratmak: alttaki Yarat (boş sayfa) düğmesi.
 |
Ekran 10: Yeni geliştirme uygulaması: ZTR10_EI_VENDOR. |
 |
Ekran 11: Yeni kap listede seçili; yeşil onayla devam. |
Adım 3: Yöntemin imzasına bakın, sonra kodu yazın
Uygulama ekranındaki Interface sekmesi, sistemin bizim için önerdiği sınıfı (ZCL_IM_TR10_VENDOR_CHECK) ve BAdI'nin yöntemlerini listeler. Bizim kullanacağımız ilki: CHECK_ALL_DATA ("Final Checks").
 |
Ekran 12: Arayüz sekmesi. Uygulama henüz etkin değil: "Uygulama çağrılmıyor". |
Yönteme çift tıklayınca Class Builder açılır. Kodu yazmadan önce Signature düğmesiyle parametrelere bakmak iyi bir alışkanlık: sürümden sürüme ad değişebiliyor ve tahmine dayalı kod derlenmez.
 |
Ekran 13: CHECK_ALL_DATA imzası: I_ACTIVITY (işlem türü), I_LFA1 (genel veri), I_LFB1 (şirket kodu verisi)... |
Kod şu:
METHOD if_ex_vendor_add_data~check_all_data.
* TR10: ZYIC / ZYDS / ZPER satıcılarında münferit ödeme zorunlu
CHECK i_activity <> 'A'. " görüntülemede çalışma
CHECK i_lfb1-bukrs = 'TR10'. " şirket kodu verisi yoksa atla
CHECK i_lfa1-ktokk = 'ZYIC'
OR i_lfa1-ktokk = 'ZYDS'
OR i_lfa1-ktokk = 'ZPER'.
IF i_lfb1-xpore IS INITIAL.
MESSAGE e002(ztr10) WITH i_lfa1-ktokk i_lfb1-bukrs.
ENDIF.
ENDMETHOD.
Satır satır neden böyle:
- I_ACTIVITY <> 'A': FK03 gibi görüntüleme işlemlerinde kontrol çalışmasın. Değerler: H yaratma, V değiştirme, A görüntüleme.
- I_LFB1-BUKRS = 'TR10': kural yalnız bu şirket koduna ait. Ayrıca XK01'de yalnız genel veriyle (şirket kodu girmeden) açılan bir satıcıda I_LFB1 boş gelir; bu satır o durumda da kontrolü güvenle atlar.
- Hesap grubu filtresi: bir defalık (CPD) satıcılar kural dışında tutuluyor; onlarda adres ve banka bilgisi belgeye yazılır, kalemler zaten ayrışır.
- XPORE: münferit ödeme işaretinin teknik adı (LFB1 tablosu). Boşsa E tipi ileti kaydı durdurur.
 |
Ekran 14: Kontrol (Ctrl+F2) ve etkinleştirme (Ctrl+F3) sonrası yöntem "Active". |
Adım 4: İki kez etkinleştirin
En sık atlanan adım burası. Yöntemi etkinleştirmek, sınıfı derler ama BAdI'nin onu çağırmasını sağlamaz. Class Builder'dan geri dönüp uygulamanın kendisini de (araç çubuğundaki kibrit simgesi) etkinleştirmek gerekir. Doğru sonucun işareti, "Runtime Behavior" alanında "Uygulama çağrılıyor" yazması:
 |
Ekran 15: Uygulama "Active", çalışma zamanı davranışı "Uygulama çağrılıyor". |
Test: kural çalışıyor, ama dikkat edilmesi gereken bir ekran davranışı var
Testi, hiç hareket almayacak bir deneme satıcısında yaptım: FK02 ile yalnız şirket kodu düzeyindeki Ödeme işlemleri ekranını açıp münferit ödeme işaretini kaldırdım ve kaydettim.
 |
Ekran 16: FK02: yalnız şirket kodu verileri → Ödeme işlemleri. |
 |
Ekran 17: İleti geliyor ve kayıt duruyor. Ama ekrandaki alanlar girişe kapanmış durumda. |
Kural çalışıyor. Ancak dikkatli bakarsanız ileti geldikten sonra ekrandaki alanların gri olduğunu, yani girişe kapandığını görürsünüz. İleti bir alan kontrolünden değil, bütün ekranlardan sonra çalışan genel bir kontrolden geldiği için SAP ekranı kilitliyor; Enter tekrar aynı iletiyi getiriyor. Geri düğmesine basınca şu pencere çıkıyor:
 |
Ekran 18: "Veriler önce saklansın mı?" |
Bu pencerede hangi düğmeye basıldığı çok önemli:
| Düğme | Sonuç |
|---|---|
| Evet | Kayıt yeniden denenir, aynı ileti tekrar gelir. |
| Hayır | İşlemden çıkılır; o ana kadar girilen bütün veriler kaybolur. FK01'de yeni bir satıcıyı baştan sona girmiş biri için en kötü sonuç. |
| İptal et | Çıkış iptal edilir, kullanıcı düzenlemeye geri döner; münferit ödemeyi işaretleyip kaydedebilir. |
Yani sorun teknik değil, "hangi düğmeye basılacağını bilmek" sorunu. Bu noktada iki tasarım seçeneği vardı: iletiyi uyarıya (W) çevirip kuralı bir hatırlatmaya indirgemek ya da hata iletisini korumak ve kullanıcıya ne yapacağını iletinin kendisinde söylemek. Kuralın gerçekten zorlayıcı kalmasını istediğim için ikincisini seçtim.
Son dokunuş: iletiye uzun metin ekleyin
SE91'de 002 numaralı iletide Self-Explanatory işaretini kaldırıp Long Text ile açıklama ekledim. Düzenleyici SAP'nin standart şablonuyla açılır; &CAUSE&, &SYSTEM_RESPONSE&, &WHAT_TO_DO& ve &SYS_ADMIN& başlıklarının altına ilgili metni yazmak yeterli. Başlık satırlarına dokunmayın: sistem onları kullanıcının dilinde "Tanı", "Sistem aktiviteleri", "Prosedür" gibi başlıklara çevirir.
 |
Ekran 19: Uzun metin: neden, sistem yanıtı, yapılacaklar ve teknik bilgi. |
Kullanıcı durum çubuğundaki iletiye çift tıkladığında artık ne yapacağını görüyor:
 |
Ekran 20: İletinin yardım penceresi. "Prosedür" bölümü İptal et adımını açıkça söylüyor. |
&SYS_ADMIN& bölümüne kontrolün hangi BAdI uygulamasında ve hangi sınıfta yazıldığını not ettim. Aylar sonra "bu ileti nereden çıkıyor?" sorusuna yanıt arayan kişi (çoğu zaman siz) için çok değerli.
Özet ve dikkat edilecekler
- Önce standart araca bakın. Onay kutularında bile hesap grubunun "zorunlu" ayarı çalışabiliyor (çift fatura kontrolü örneği). Kod yalnız standart araç yetmediğinde.
- Münferit ödeme alan durumunda başka iki alanla aynı satırı paylaştığı için ayrı zorlanamıyor; VENDOR_ADD_DATA → CHECK_ALL_DATA bu iş için doğru yer.
- ECC 6.0'da klasik BAdI uygulaması bir geliştirme uygulaması kabı ister. SAP'nin kaplarını değil, kendi kabınızı yaratın.
- İki etkinleştirme: yöntem (sınıf) ve uygulama. "Uygulama çağrılıyor" yazısını görmeden test etmeyin.
- Bu yöntemdeki E iletisi ekranı kilitler; kullanıcı Geri → İptal et ile düzenlemeye dönebilir, Hayır girilen verileri siler. Bunu iletinin uzun metninde açıkça yazın.
Bir sonraki adım, kural altında açılmış satıcılarla F110'u çalıştırıp münferit ödemenin ödeme önerisinde nasıl göründüğünü incelemek olacak.
Bu yazı, IDES sisteminde CATR hesap planıyla kurulan TR10 şirket kodu serisinin bir parçası. Serinin diğer yazıları için TR10 etiketli yazılara bakabilirsiniz.
İlgili yazılar
- Otomatik Ödeme Programının Çalıştırılması (F110)
- Satıcılara İlişkin Hesap Gruplarının Tanımlanması (OBD3)
- SAP FI'da Alan Durum Grubu: OBC4, OBC5 ve Kayıt Anahtarı
- Doğrulamada İleti Sınıfının Değiştirilmesi (RGUGBR28)
SAP, SAP SE'nin ticari markasıdır. Bu yazıdaki ekranlar bir deneme sisteminden alınmıştır.
YORUMLAR