Doğrulamada İleti Sınıfının Değiştirilmesi (RGUGBR28)

GGB0'da değiştirilemeyen doğrulama ileti sınıfını RGUGBR28 ile değiştirmek: Boole sınıfı, deneme çalıştırması, TK301 hatası ve ortak sınıf riski.

GGB0'da gri gelen ileti sınıfı alanını RGUGBR28 programıyla değiştirmek: Boole sınıfı, deneme çalıştırması, TK301 paket hatası ve aynı sınıfı kullanan diğer doğrulamalar.

TR10 şirket kodu için yazdığım belge kalemi doğrulaması, iletisini başka doğrulamalarla ortak kullanılan Z1 ileti sınıfından alıyordu. İletileri TR10'a özel bir sınıfta toplamak istedim. Ancak GGB0 ekranında ileti sınıfı alanı gri geliyor ve değiştirilemiyor. Bu yazıda ileti sınıfının neden doğrudan değiştirilemediğini, SAP'nin bunun için sunduğu RGUGBR28 programını ve yol üzerinde karşılaştığım iki engeli anlatıyorum.

Sorun: İleti sınıfı alanı değiştirilemiyor

Bir doğrulamanın ileti sınıfı, doğrulama yaratılırken bir kez belirlenir ve doğrulamanın bütün adımları için geçerlidir. Adımın İleti ekranında yalnızca ileti tipi ve ileti numarası seçilebilir; sınıf bilgisi salt okunur gelir.

Ekran 1: GGB0: ZTR10 doğrulamasının 001 adımı Z1 sınıfının 024 numaralı iletisini kullanıyor.

Kalem düğmesi: İleti sınıfının yanındaki kalem düğmesi yanıltıcı olabilir. Bu düğme sınıfı değiştirmez; yalnızca mevcut sınıfın iletilerinin bakım ekranını açar.

Çözüm: RGUGBR28 programı

SAP, bu iş için RGUGBR28 (VSR: Boole sınıfları için ileti sınıfının değiştirilmesi) programını sunar. Program SA38 ile çalıştırılabilir; GGB0'da Environment menüsündeki Change Message Class seçeneği de aynı programı çağırır.

Seçim ekranında dört alan vardır:

• Boole sınıfı: Doğrulamanın ait olduğu uygulama alanı ve çağrı noktası. Mali muhasebe için değerler aşağıdaki tabloda.
• Eski ileti sınıfı: Doğrulamanın bugün kullandığı sınıf (örnekte Z1).
• Yeni ileti sınıfı: Geçilecek sınıf (örnekte ZTR10).
• Deneme çalıştırması: İşaretliyken hiçbir şey değişmez, yalnızca etkilenecek doğrulamalar listelenir.

Boole sınıfı	Mali muhasebe çağrı noktası
008	Belge başlığı
009	Belge kalemi
015	Eksiksiz belge

Dikkat: Programda doğrulama adı için bir seçim alanı yoktur. Değişiklik tek bir doğrulamaya değil, seçilen Boole sınıfında eski ileti sınıfını kullanan bütün doğrulamalara uygulanır. Bu yüzden ilk çalıştırmayı mutlaka deneme modunda yapmak gerekir.

Ekran 2: RGUGBR28 seçim ekranı, deneme çalıştırması işaretli.

Ön hazırlık: Yeni ileti sınıfı

Programı çalıştırmadan önce yeni ileti sınıfının SE91'de yaratılmış olması gerekir. Burada iki noktaya dikkat edilmeli.

İleti numaraları taşınmaz. Program yalnızca sınıf bilgisini değiştirir; adımlardaki ileti numaraları olduğu gibi kalır. Eski sınıfta 024 olan ileti yeni sınıfta 001 numarasıyla yaratıldıysa, adım yeni sınıfta 024'ü arar ve bulamaz. İki yol var: iletileri yeni sınıfta aynı numaralarla yaratmak ya da programdan sonra adımlardaki ileti numaralarını tek tek düzeltmek. Ben ikinci yolu seçtim.

Sınıf taşınabilir bir pakette olmalı. Bu, karşılaştığım ilk engeldi.

Engel 1: TK301, ileti sınıfı $TMP paketinde

ZTR10 ileti sınıfını yaratırken yerel nesne olarak kaydetmiştim. Yerel nesneler $TMP paketinde tutulur ve taşıma isteğine eklenemez. Sistem bu nedenle işlemi TK301 iletisiyle kesti.

Ekran 3: TK301: ZTR10 nesnesi $TMP paketinde olduğu için isteğe eklenemiyor.

Çözüm, ileti sınıfının nesne dizini girişini değiştirip onu bir Z paketine almaktır:

1. SE91'de ileti sınıfını açın.
2. Menüden Goto → Object Directory Entry yolunu seçin.
3. Değiştir moduna geçin, paket alanındaki $TMP yerine kendi geliştirme paketinizi yazın (örnekte ZFI0) ve kaydedin.
4. Sistem bir Workbench isteği sorar; ileti sınıfı bu isteğe eklenir.

Ekran 4: SE91: Goto → Object Directory Entry.

Ekran 5: Nesne dizini girişi: R3TR MSAG ZTR10, paket $TMP.

Ekran 6: Paket ZFI0 olarak değiştiriliyor.

Aynı değişiklik SE03 işlem kodundaki nesne dizini girişlerinin değiştirilmesi aracıyla da yapılabilir (nesne tipi R3TR MSAG).

Programın çalıştırılması

Paket sorunu çözüldükten sonra deneme çalıştırması işaretini kaldırıp programı gerçek modda çalıştırdım.

Ekran 7: RGUGBR28 gerçek çalıştırma: Boole sınıfı 9, Z1 sınıfından ZTR10 sınıfına.

Program çalışırken iki pencere çıktı.

İlki bir veri tutarsızlığı bilgisiydi: SM11 doğrulamasında adım numarası boş bir kayıt olduğunu söylüyor. Bu ileti sınıf değişikliğiyle ilgili değil, SM11 doğrulamasının kendi kayıtlarıyla ilgili; aşağıda ikinci engel olarak ele alıyorum.

Ekran 8: Veri tutarsızlığı bilgisi: SM11 doğrulaması, boş adım.

İkincisi bir teyit penceresiydi. İleti sınıfları üst birimden bağımsız olduğu için sistem, değişikliğin diğer üst birimleri de etkileyebileceğini hatırlatıyor.

Ekran 9: Teyit penceresi: diğer üst birimler de etkileniyor.

Evet ile devam edince sonuç listesi geldi. Listede iki bölüm var: bulunduğunuz üst birimde değiştirilen doğrulamalar ve aynı ileti sınıfını kullanan diğer üst birimlerdeki doğrulamalar. Bende ikinci bölüm boş geldi.

Ekran 10: Sonuç listesi: SM11 ve ZTR10 doğrulamalarının ileti sınıfı değiştirildi.

Engel 2: Aynı sınıfı kullanan diğer doğrulamalar

Sonuç listesinde yalnızca ZTR10 değil, SM11 doğrulaması da var. İkisi de 009 Boole sınıfında ve Z1 ileti sınıfını kullandığı için program ikisini birden ZTR10 sınıfına geçirdi.

Bunun sonucu şu: SM11'in adımları artık ZTR10 sınıfından ileti okuyor, ama ileti numaraları eskisi gibi duruyor. Yeni sınıfta o numaralar yoksa ya da başka bir metne denk geliyorsa, SM11 tetiklendiğinde boş ya da ilgisiz bir ileti çıkar. Programdan sonra yapılacaklar:

• Listede çıkan her doğrulamanın her adımını GGB0'da açıp ileti numarasını kontrol edin.
• Eksik iletileri SE91'de yeni sınıfa ekleyin ya da adımdaki numarayı düzeltin.
• Veri tutarsızlığı bilgisi çıkan doğrulamayı değiştir modunda açıp adımlarını gözden geçirin ve yeniden kaydedin.

Not: Bir doğrulamayı ortak sınıfta bırakmak istiyorsanız, RGUGBR28 bunu ayırt edemez. O durumda en temiz yol, ayrılacak doğrulamayı baştan yeni sınıfla yaratmaktır.

Kontrol ve test

GGB0'da ZTR10 doğrulamasının 001 adımına döndüğümde ileti sınıfı artık ZTR10 olarak geliyor. İleti numarasını da yeni sınıftaki karşılığı olan 001 ile değiştirdim.

Ekran 11: GGB0: aynı adım artık ZTR10 sınıfının 001 numaralı iletisini kullanıyor.

Son adım kayıt testi. FB50'de TR10 şirket kodunda, iş alanı girmeden bir SA belgesi kalemi girdim. İleti yeni sınıftan, hesap numarası değişkeni dolu olarak geldi.

Ekran 12: FB50: iş alanı girilmeyen kalemde ZTR10 001 iletisi.

İletinin metnini görmek yeterli değil; belgeyi kaydetmeyi de deneyin. İleti tipi E olan bir doğrulamada sistem, eksik alan doldurulmadan belgeyi kaydetmemelidir.

Özet

1. Yeni ileti sınıfını SE91'de yaratın ve $TMP yerine taşınabilir bir pakete atayın.
2. Doğrulamanın kullandığı iletileri yeni sınıfa ekleyin; mümkünse aynı numaralarla.
3. RGUGBR28 programını önce deneme modunda çalıştırıp etkilenecek doğrulamaları görün.
4. Listede beklemediğiniz doğrulama yoksa gerçek modda çalıştırın.
5. Etkilenen bütün doğrulamaların adımlarında ileti numaralarını kontrol edin.
6. Bir kayıt işlemiyle iletiyi ve belgenin engellendiğini test edin.

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

• Doğrulamada Break Point Kullanımı ve Hata Ayıklama
• Belge Ayrıştırma (Document Splitting): Tüm Yönleriyle
• FI Modülünde İş Alanı Oluşturma Süreci (OX03)
• SAP FI'da Alan Durum Grubu: OBC4, OBC5 ve Kayıt Anahtarı

---

SAP, SAP SE'nin ticari markasıdır. Bu yazıdaki ekranlar bir deneme sisteminden alınmıştır.